日本企業の約6割がアジャイル開発に着手

　小さく始めて改善を重ねる、要件に変更があることを前提とするアジャイル開発の必要性が叫ばれて久しい。

　理由は明らかだ。環境変化が激しい状況下での目標達成のためには、仮説・検証の繰り返しの速さが成否のカギを握るため、アジャイル開発のほうが、要件を隅々まで事前に固めるウォーターフォール型よりも、ITの開発手法として格段に適している。

　昨今ではDXの要としても注目を集め、ガートナーが国内企業400社に対して2023年7月に実施した調査でも、すでに6割以上が何らかの形でアジャイル開発を取り入れているという。

　「ただその結果、開発の速さに運用側が追い付かない問題が顕在化し始めています」と語るのは、ガートナー シニア ディレクター,アナリストの米田英央氏だ。

　従来からの運用業務はウォーターフォール型開発を前提に、システムの安定稼働を最重視して業務が組まれていた。運用対象の基盤整備に多大な時間を要してしまうのも、そう設計されていたからである。

「しかし、アジャイル開発の広がりが状況を大きく変えました。開発速度が格段に向上したことで、運用業務がシステム開発、ひいては事業変革の足枷となりつつあります。その打開に向け、開発に追随できるだけの機敏さの取り込みが運用業務で急務となっています」（米田氏）

モノシリックからの脱却により開発手法が変化

　アジャイル開発時代の運用業務像のヒントは2001年に米国の専門家17名が発表した「アジャイルソフトウェア開発宣言」の次のフレーズに隠されているという。

　いわく、「包括的なドキュメントよりも動くソフトウェアを」「契約交渉よりも顧客との協調を」「プロセスやツールよりも個人と対話を」「計画に従うことよりも変化への対応」だ。

　米田氏は、「この宣言を通じて、アジャイル開発の目的は『ITで素早く顧客の目に見える価値を生むこと』であり、『今までとは異なるコミュニケーションや変化対応』に向けて、仕事を見直す必要性が謳われています」と説明する。

　その上で、アジャイル開発での運用業務の在り方として米田氏が提示したのが、開発手法の変化に伴いシステムの在り方が変わる中での「これまで明確に分けられてきた開発業務との一体化」だ。

　ウォーターフォール型開発によるモノシリックなシステムは、それゆえに1つの脆弱性がシステム全体に波及するリスクを抱えている。従来からの開発と運用の明確な分離は、その顕在化を避けるための施策でもあったのだという。しかし、アジャイル開発ではシステムは疎結合なコンポーネントの集合体として構成され、リスクはコンポーネントごとに封じ込められる。

「結果、リスクが大幅に低減し、運用と開発を分ける意味がなくなっています。そこで採るべき開発／運用手法となるのが、開発と運用を一体的に行うDevOpsです」（米田氏）

　アジャイル開発では業務目標も変わる。ウォーターフォール開発では開発部門と運用部門の仕事は、それぞれ「要件どおりの機能開発」と「運用部門は開発の要件どおりの運用」であった。だが、アジャイル開発では「コンポーネントの追加開発を通じた、開発宣言でも謳われている『ユーザーのため』の主体的なサービス提供が共通のミッション」となる。

　一連の仕事の流れも、要件定義から設計、開発と一方的に流れるスタイルから、新たなサービス開発に端を発し、それに対するユーザーからのフィードバックを基に、新たに必要な機能を判断して開発を繰り返すサイクルに一変することになる。 【次ページ】アジャイル開発では期限内の開発完了が最重要