不確実性の時代に、アジャイル開発で向き合っていこう 第1回：アジャイル開発への移行の必要性と普及のための条件：ZDNET Japan
[コジーの今週気になるＤＸニュースVOL20230117-02]

梗概

　現代社会は多くのものがソフトウェアで成り立っており、絶えず変化するニーズに応じられる柔軟でスピーディーな開発が求められています。その一方、何が正解（ゴール）なのかが分からない、という不確実性の時代でもあります。不確実性に対処するには「アジャイル開発」が最も有望ですが、その成功裏の実践には、従来の常識の解体と再構築が必要です。エンタープライズにおけるアジャイル開発の実践が待ったなしの状況の中、理論、課題、近年の動向も踏まえ、実例を交えながら幅広く解説します。

連載開始に当たって：背景と狙い

　ITシステム「2025年の崖」克服のために、デジタルトランスフォーメーション（DX）の取り組みが必要とされるなか、ウォーターフォールに代表される従来型のアプリケーション開発の進め方を見直すとともに、開発活動のハードルを下げ、生産性の向上が期待できる新たなテクノロジーを取り入れることが必要とされています。
出所：経済産業省の「DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～」に基づき、KPMG作成

　世の中全体のIT化が進み、今後ますます競争が熾烈化することが予想されるなか、日本企業が長年にわたり構築・運用してきたITシステムやその開発の進め方が、市場ニーズへの対応や業務改善の足かせとなっています。市場における中心プレイヤーとして生き残るためには、現在のビジネス環境とテクノロジー環境にあった開発の進め方への移行が不可欠です。端的に言えば、DXを推進していく上では、将来を正確に見通し、計画を立てられることが前提となる「ウォーターフォール型」はもはや現実的ではなく、フィードバックループを通じ、素早く状況に適応して価値を提供することに重きを置く「アジャイル型」への移行が必須といえます。
出所：KPMG作成

　1970年のウォーターフォール誕生から半世紀、2001年のアジャイルソフトウェア開発宣言からおよそ20年が経ち、日本においてもアジャイル開発の導入状況は20～40%程度とキャズム（普及する上で越えなければならない一線）を超え、レイトマジョリティーへの到達も近いと言われています（注1）。

　（注1）出典：市谷聡啓、新井剛、小田中育生（2020年）「いちばんやさしいアジャイル開発の教本　人気講師が教えるDXを支える開発手法」、 インプレス

　そのことを示す一例として、先人たちがアジャイル開発を浸透させた現場においては、近年、初めて触れた開発プロセスがアジャイルである、という「アジャイルネイティブ」とも呼ぶべきIT人材が増えてきています。これまで私たちは、アジャイル開発について説明する際、「アジャイル開発はウォーターフォールとは異なり」という前置きから入り、いわばウォーターフォールの前提となる考え方と対比させることで説得力を持たせてきましたが、もはやそれさえも通用しない、アジャイル開発が当たり前の時代が迫りつつあります。

　また、2025年の崖の一要因としても語られるIT人材の不足に伴い、その売り手市場傾向は今後ますます強まっていくことが予想されます。その不足分をオフショア開発などで埋めようにも、日本以上にアジャイルが浸透するオフショア諸国の企業が、果たしていつまで従来型のウォーターフォール請負開発の要請を受け入れるのか不透明な情勢です。

　このように、アジャイル開発が当たり前となりつつある中、本当の意味で浸透させていくには幾つか解決すべき課題があります。本連載では、これから初めてアジャイルに触れる人、アジャイルネイティブな人、上位マネジメント、現場ITエンジニアなど、経験や立場を問わず知っておいていただきたいポイントを主に3つの観点から解説します。

　1つ目は、アジャイル開発に対する本質的な、より深い理解です。

　アジャイルネイティブであるなしにかかわらず、開発のあり方に対する明確な課題意識から主体的にアジャイル開発を選択したわけではないため、「どうやるか（How）」は理解しているものの、「何故そうやるのか（Why）」の理解が欠落しており、それがプロセスの形骸化や肥大化を助長してしまい、効果を享受できないケースが多く見られます。その解決のためには、ウォーターフォールに代表される従来型の開発手法に対するアンチテーゼとして生まれたアジャイルが、従来型開発が抱える個々の課題をどのように捉え、解決しようとしているのかに着目し、理解を深めることが有効です。

　2つ目は、開発活動に当たってのマインドセット（考え方）の転換です。

　ソフトウェアやITを用いたソリューションは、案件ごとに異なる要件に対し、それを実現すべく多くの要素で構成される高度で複雑な構造物であり、フィードバックに基づく調整が不可欠です。

　そのようなソフトウェアやITソリューションを一度きりの設計・開発作業によって組み上げることは現実的ではないケースも多く、ましてや、それを直接的に開発活動に関わっていない人たちによる「外からのガバナンス」で実現することは困難です。

　2022年に開催されたAgile Japan 2022での基調講演において、「アジャイルソフトウェア開発宣言」の著者の1人であるAlistair Cockburn氏が強調していたように、「人とそのコラボレーションのあり方」は、ソフトウェア開発プロセスにおいて最も重要な要素です。アジャイルチームのメンバーには、アジャイルマニフェストの最初の価値宣言にも反映されているこの哲学、すなわち自己規律、自己組織化、自己認識が求められますが、優れたチームでは開発者たちが本来的に備えている自律性をどのように引き出しているのか、具体例を通じて紹介します。

3つ目は、アジャイル開発をどのようにエンタープライズ規模にスケールアップするかという点です。

　アジャイル（スクラム）は、もともと比較的小規模な開発のために考案された開発手法です。すなわち、スクラムは開発のサイクルを1チーム（5～9人程度）でどのように回すのかという点で示唆に富むものの、複数チームで開発を行う場合の回し方については触れられていません。

　さらには、「開発で実現する要件（ユーザーストーリー）をどのように洗い出すのか」「ソリューション全体のアーキテクチャーをどのように構想するのか」、といった開発の前段の活動、あるいは反復（スプリント）を通じて作成したソリューションを継続的にデリバリーしていくために必要な、作成したコードを効率的に統合・ビルドし、テストのためにデプロイする仕組みの構築や、リリース前に必要な作業をどのように実施すべきか、といった後段の活動についての言及がありません。

　スクラムで言及されていない部分を補い、アジャイル開発をエンタープライズ規模にスケールアップする方法として、ディシプリンドアジャイル（DA）やScaled Agile Framework（SAFe）といったフレームワークが考案され、浸透しつつあります。これらフレームワークの概要と利点を紹介します。

　本連載では、前述の3つのポイントについて解説する予定です（内容については多少変更する場合があります）。

　次回は、ウォーターフォール開発手法と、それに対するアンチテーゼとしての反復型開発、その発展形としてのアジャイルの生い立ちを見ていきます。ウォーターフォールの考案者はその手法がソフトウェア開発にうまく適合するか懸念を持っていたのですが、それを裏付けるように、反復型開発はなんとその実の息子によって考案されたという話とともに、アジャイルマニフェストの意味するところについて解説します。

岡本 修治（おかもと・しゅうじ）KPMGコンサルティング Technology Strategy & Architecture シニアマネジャー外資系総合ITベンダーにおいて大規模SI開発をはじめ、ソフトウェア開発プロセス／ツール展開のグローバルチーム、コンサルティング部門などを経て現職。金融、製造、情報通信など業界を問わずITソリューション選定、開発プロセスのアセスメント（評価）と改善、BPR支援などさまざまな経験を有し、中でも不確実性の時代と親和性が高いアジャイルトランスフォーメーションを通じた意識改革、開発組織の能力向上支援をライフワークとし注力している。