第11回（最終回）：連載のふりかえり、アジャイルのこれから
今回は「第11回（最終回）：連載のふりかえり、アジャイルのこれから」についてご紹介します。
関連ワード （不確実性の時代に、アジャイル開発で向き合っていこう、開発等） についても参考にしながら、ぜひ本記事について議論していってくださいね。
本記事は、ZDNet Japan様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。
現代社会は多くのものがソフトウェアで成り立っており、絶えず変化するニーズに応じられる柔軟でスピーディーな開発が求められています。その一方、何が正解（ゴール）なのかが分からない、という不確実性の時代でもあります。不確実性に対処するには「アジャイル開発」が最も有望ですが、その成功裏の実践には、従来の常識の解体と再構築が必要です。エンタープライズにおけるアジャイル開発の実践が待ったなしの状況の中、理論、課題、近年の動向も踏まえ、実例を交えながら幅広く解説します。
全10回の予定で開始した本連載は、筆者の見込みの甘さから途中1回増えて全11回となりました。いわば反復が1回増える形となったわけですが、そのような変化に柔軟に対応いただいたZDNET Japan編集部に感謝しつつ、これまでの内容をふりかえりたいと思います。特に、話の流れや分かりやすさを優先した結果書ききれなかったこと、読者からいただいた質問に対する筆者の考えなどを、連載の流れに沿って紹介していきます。
第1回から第3回では、従来型開発手法の構造的な問題と、それらの問題を解決するために採用された新しいやり方、それが今日「アジャイル手法」と呼ばれる形に昇華されていく過程を解説しました。具体的には、第3回で紹介した米国のソフトウェアプログラマーE. Raymond氏による書籍「伽藍とバザール」（光芒社、1999年）、すなわち「Linux」開発に端を発する、伽藍（がらん）を作るがごとくアーキテクチャーに基づきチームを組成し、細かく分担してミスをチェックする命令型の「伽藍方式」から、バザール（市場）のように公開されたソースコードに対し自由に機能を追加したり、障害を取り除いたりしていく「バザール方式」への移行です。
この手の対比は受け手にとっての分かりやすさを優先し、単純な二元論で語られがちですが、前者が徹底的に“悪”であり、その裏返しとしての後者を“善”と捉えるのはやや極端に過ぎます。
20世紀末の1990年代半ば当時は、システム全体の見取り図（アーキテクチャー）を検討・考案するアーキテクトという役割が脚光を浴び、最初にしっかり設計する「Big Design Up Front（BDUF）」という考え方が強かったのは事実で、その弊害やアーキテクト偏重に対する反動の端的な表れの一つといえるでしょう。一方で、アジャイルにおけるアーキテクチャーの考え方、すなわち反復の都度、追加・変更されるさまざまなフィーチャー（機能）に合わせてアーキテクチャーを斬新的に進化させるというやり方にも限界があります。
例えば、「ディシプリンド・アジャイル（Disciplined Agile：DA）」が「アーキテクチャ・スパイク」（アーキテクチャーが重要なユーザーストーリを実現していく上で理にかなった構造となっているかを早期に検証する）といったプラクティスを提唱するのもまさにそのような理由によるものです。
2001年9月11日の米国同時多発テロ事件の発生に伴い、G. W. Bush米大統領（当時）は「Good against Bad」（善に対する悪（の枢軸の挑戦））という明快な二元論を用いることで同盟国の賛同と協力を得ました。このやり方の是非については、筆者が当時一緒に働いていたオーストラリアをはじめその他の同盟国の同僚たちとの間でも頻繁に話題に上りました。ITの世界の例で言えば、ソフトウェアとハードウェアの進化の波に伴いハードウェア端末が進化すると、その能力を生かすべくエッジ側にロジックを持たせるアーキテクチャーがはやり、逆に、サーバー側の技術が向上すると中央集中処理のアーキテクチャーがはやるといった、時世に応じたトレンドです。
二元論に基づいて盲目的に善悪を決めるのではなく、あくまで相対的に捉えること、たまたまそのタイミングで振り子がどちらに振れているのか、といった観点が重要と感じます。
第3回の内容でもう一点補足があります。スマートフォンへの移行期における従来型携帯電話を提供していた大手企業の開発方式についてです。これまでの通説は、その企業では従来型の開発方式からアジャイル方式への切り替えが行われず、結果としてスマートフォンという新たな市場において重要な位置を占めることがかなわなかったというものでした。この点に関して、2023年邦訳版が出版されたTasktop Technologiesの最高経営責任者（CEO）、M. Kersten博士の書籍「Project to Product（フローフレームワークでデジタルディスラプション時代に成功する方法）」（パレード、2023年）において、事実はやや異なることが紹介され、関係者の間で話題を呼びました。
Kersten博士は同著の中で、実際に同社の開発現場で起こっていたことを次のように分析しています。同社は当然のようにアジャイル開発方式を採用していたが、「開発が反復的に行われているか」「スクラムの原則に従っているか」といった“代理指標”、つまり、所定の方法や決まったモデルに準拠しているかどうかを重要視し、その活動を通じて得られる成果という“本質”の部分に目を向けていなかったというのです。
つまり、“代理指標”だけを見れば同社のアジャイルトランスフォーメーションは成功したとみなすことができるが、その変革による実際のビジネス成果がなかったこと、さらには、開発とビジネスが切り離され、ビジネスの成果とソフトウェアの生産指標との結びつきは、明示されていないか、あるいは存在しないかのどちらかだ、と結論づけています。なお、Kersten博士の同著は、開発方式をアジャイルにしただけではもはや不十分であるとし、その先にある世界に読者を誘ってくれますが、これについては後述します。
第4回および第5回では、アジャイルに関するよくある誤解として、設計書などの文書作成に関する考え方や従来型との対比における品質面でのアドバンテージについて解説しました。連載の中では「品質（Q）」に重点を置いて解説しましたが、余計なものを作らないという意味での「コスト（C）」と、リリース時期の予見性として「納期（D）」の観点でもアドバンテージがあることを改めて強調しておきたいと思います。