2023年11月16日・17日の2日間、Agile Japan 2023がリアルとオンラインのハイブリッドで開催されました。テーマは「Rebuild our Agile!」、Agileの「再会」「再構築」「再開発」という3つの要素で改めて未来へ向けて進化することをめざすイベントとなりました。
カンファレンスで登壇した伊山宗吉はNTTコムウェアでアジャイル開発をリードする立場から、7年近くにわたる活動のなかで感じた変化に鑑み、アジャイル開発の原点に立ち戻って、改めて大切にしたい考え方や取り組みを発表しました。
（講演資料はこちら）※外部サイト

アジャイル開発の成功と、上手くいかなかった時に起こった問題

NTTコムウェアは2016年のアジャイル開発推進組織の発足以来、多くのアジャイル開発の実績があります。私自身はアジャイル推進組織でコーチ、エバンジェリストの立場として、多数の案件に関わりさまざまなことを経験してきました。

こうした経験から、特に

• アジャイル宣言の価値や原則を落とし込めていない方
• チームで起きている問題の捉え方に悩んでいる方

に向けて、アジャイル開発の原点を見つめ直すことで、改めて得た学びの一部を共有します。

NTTコムウェアのアジャイル開発は2013年頃にスタートしましたが、その中には成功したチームもあれば、上手くいかなかったチームもあり、その成否を分けた要因について考えてきました。

上手くいかなかったチームには、開発前にいくつかの予兆がありました。「アジャイル開発そのものが目的化している例」、「そもそもアジャイル開発を間違った形で利用しようとした例」、「経験者が不足している中でアジャイル開発を始めてしまった例」、「そもそもアジャイル開発ではない従来型開発をアジャイルと称した例」など、後で思えば始まる前から「怪しい匂いが漂っていた」といえるでしょう。

開発中に継続が難しくなったチームや、従来開発に戻す選択をせざるを得ないチームもあり、その要因は多岐にわたりますが、「ビジョン・ゴールを合わせられていない」「リファクタリングや学習が後回しになる」「従来開発と同じでリスクを終盤まで残している」「ビジネス側と開発側の間に壁がある」などの問題があったことが挙げられます。

一方で、成功しているチームもあります。成功の要因を考えると、チームのなかで上記のような問題が起きていない、または起きたとしてもきちんと問題に向き合い、少しずつ改善していったためと推測できます。

また、成功したチームが共通して持っていた特徴には、次の3つがありました。

• ビジョンが共有されていた。
• 顧客と開発者の関係が密接であり、頻繁にコミュニケーションを取っていた。
• メンバーのモチベーションが高く、スキルアップに積極的に取り組んでいた。

では、成功したチームと上手くいかなかったチームの間で、いったい何が違っていたのでしょうか？アジャイル推進組織のコーチ、エバンジェリストの立場として、両方のチームを実際に間近で見るなかで、その原因について、考えを深めていきました。

その結果到達したのは、上手くいかなかったチームは「アジャイルの形をなぞっただけ」で、「大切な中身が欠けていた」のではないだろうか、ということでした。そこに思い至った時に出てきた疑問は以下の2つです。

• アジャイル開発において、大切な中身とはいったい何なのだろうか？
• それが欠けていたとすれば、どうすればそれを埋められるのだろうか？

アジャイル開発の原点に立ち戻って考える

私は「大切な中身が欠けていた」ということに思い至った時に、『アジャイルソフトウェア開発宣言』（2001年）より以前に登場していたスクラムやXP（エクストリームプログラミング）などのアジャイル開発フレームワークの考案者や実践者の書籍や論文を通じて、当時の考え方に触れることで、「アジャイル宣言の価値観や原則の意図をより深く理解できるようになるのではないか」と考えました。

1. 開発プロセスについて

まずはシステム開発のプロセスについてお話しします。突然ですが、皆さんはブラックボックスと聞いてどのようなものを思い浮かべるでしょうか。

どういうことかというと、生物学、化学などの他の産業プロセス制御では、

• 設計して繰り返し実行することで毎回同じ結果が得られる（予測可能な）場合
  →　定義されたプロセス

これに対し、

• プロセスが完全には解明されておらず単純計算できない（予測不可能な）場合
  →　経験的なプロセス

と呼びます。

そして、経験的なプロセスにおいては、入力と出力の間にあるプロセスをブラックボックスのように扱い、実験で取得したデータを元に制御するというアプローチが取られます。具体的には、反復試行で得られた経験的な結果が、制御装置の運転条件に落とし込まれ、実行には頻繁かつ継続的な測定、監視、制御が行われます。

実はこの考え方がアジャイル開発で最も利用されているフレームワークの「スクラム」に取り入れられていることをご存じでしょうか。最初に発表されたスクラムの論文、Ken Schwaberの著作『SCRUM Development Process』（1995年）に記述があります。該当箇所を抜き出し、私の翻訳で引用します。

• 本稿では、産業プロセス制御の概念をシステム開発の分野に適用する。
• 調査の結果、我々はシステム開発プロセスが経験的なものであると断言する
• スクラムは、システム開発プロセスが予測不可能で複雑なプロセスであり、全体的な進行として大まかにしか説明できないことを前提としている
• スクラムでは、これらのシステム開発プロセスを制御されたブラックボックスとして扱う
• 予測不可能性を管理し、リスクを制御するために制御メカニズムが使用される。その結果、柔軟性、応答性、信頼性が得られる。

ここには「スクラムはシステム開発という経験的プロセスを扱うために考えられたフレームワークである」ということの原点が記述されています。私はこの記述を見つけたことで、改めてスクラムから学びを得ることができました。「システム開発プロセスそのものが生物学や化学の分野と同様に複雑で予測不可能なため、経験的なアプローチを必要とする」ことを認識したことで、私の中でアジャイルおよびスクラムの価値や原則、フレームワークへの理解がより深まったのです。

そしてそれは、スクラムの3本柱「透明性・検査・適応」の重要性を再認識しただけでなく、「アジャイル開発は状況の透明性を高めて、頻繁にアウトプットし、評価しなければとても上手くいく気がしない」という私の考えをこれまで以上に強めることになりました。

この学びを踏まえて先ほどの上手くいかなかったチームを振り返ってみると、「新薬を開発する際に、用いる原料や合成手法の有識者が居ないにも関わらず、理論的な知識だけを頼りに開発過程や最終製品の効果、市場投入のスケジュールを計画しているようなもの」で、とてもリスクの高い選択をしていることに気づく必要があったのです。また、開発中に問題があったチームも、ビジョン・ゴールを合わせていないことから認識齟齬が生じ、期待と異なるものができあがってしまうリスクや、頻繁にデプロイやリリースができずにユーザーや関係者から適切なフィードバックを受ける機会が得られず、期待とのギャップに気づかないまま進んでしまうという従来型開発と同じリスクを終盤まで残してしまっていることに気づくべきだったのです。

2. 計画、品質について

続いてアジャイル開発の計画や品質に対してお話します。

Robert C.Martinの『Clean Agile 基本に立ち戻れ』（2020年）には利害関係者からの期待として次のような例が挙げられています。

• あなたの見積りが誠実であることを期待する
• 品質が高く、欠陥が少ないシステムを提供して欲しい
• 新しくリリースされるものは徹底的にテストされていることを期待する。資金や時間が足りないことを理由に、開発チームがテストを省略することは期待していない。
• ソフトウェアは変更しやすいことを期待している。

（第2章より引用）

これらの期待は至極真っ当なものであり、私も応えたいと考えます。まずはこの中から「見積り」と「計画」に関して見てみましょう。同書では次のような記述があります。

• マネージャーがチームに「進捗どうですか？」と聞くと、希望があるので「順調です」と答えてしまう。希望はソフトウェアプロジェクトをマネジメントするのに最悪の方法だ。アジャイルは早い段階から希望を殺し、継続的に冷たくて厳しい現実を提供する。
• アジャイルは速く進むことだと思っている人もいる。だが、そうではない。
• アジャイルとはどれだけうまくいっていないかをできるだけ早く知ることだ。
  できるだけ早く知りたいのは、そうすれば状況をマネジメントできるからだ。

（第1章より引用）

また、Kent Beck、Cynthia Andresの『エクストリームプログラミング』（2015年）には次のような記述があります。

• XPの計画づくりは活動であり、フェーズではない。プロジェクトマネージャーには、計画と現実を同期し続ける責任がある。

（第10章より引用）

ここでは、短期間かつ高頻度で開発プロセスを繰り返す中で、計画と現実を同期し続けることを、プロジェクトをマネジメントする者の「責任」であるとまで書かれています。

これらによって私が再認識したのは、

• 小さな反復は「チームが関係者と共に現実を認識し、適応するために再計画する」。
  そのためのデータを得る活動でもある。
• この「現実に適応」する考えは、プロダクトの成長にも適用できる。
  それ故、アジャイルは「開発」から「ビジネス」の手法に進化していった。

ということでした。

プロジェクト初期にはデータが不足し、計画は不確実性が高いのですが、小さな反復によってデータを得て、必要であれば方向転換も含めて再計画し続けることで現実とのブレを小さくしていき、完成見込みを見いだしていくということにつながります。不確実な計画をビジネス側が必達として扱うと、開発側は新しい要求の追加や変更を拒むようになり、開発側は変更や遅れへの対処としてバッファを設ける心理が働いてしまいます。その結果、ビジネス側と開発側の間の壁によって、プロダクトの価値向上の機会を失ってしまうことになるのです。

続いて、先述の利害関係者の期待の中から「品質」と「生産性」に関して考えてみましょう。アジャイル開発では、各反復の終了時点でリリースするかどうかビジネス判断が可能な動くソフトウェアが完成していることが期待され、これには、必要なテストを全てパスしている必要があります。仮に、反復の終盤になってからそれまでに行った変更の失敗に気づくと手戻りが大きく、完成が危うくなってしまうので、それを防ぐために小さく確実に進めていく「ベイビーステップ」のアプローチが大切であり、テストファーストプログラミング、継続的インテグレーションなどのプラクティスがあると書かれています。

継続的インテグレーションについては、Robert C.Martinの『Clean Agile 基本に立ち戻れ』（2020年）の第1章に次のように書かれています。

• 継続的インテグレーションは、チームが現在地を常に把握できるように、フィードバックループを何度も閉じることにフォーカスするプラクティスである。

ここから、継続的インテグレーションの重要性を改めて認識することができました。

• 技術的なプラクティスだと思われがちだが、実はチームのためのプラクティスに分類されるものであり、チームに対して頻繁かつ継続的なフィードバックを実現する。（開発者が行った変更に対するコンフリクトや自動テストの失敗にチームが即座に気づき、修正を行うことで、大きな手戻りを発生させずに品質を確保しながら開発を進めることができる）

ここまで認識を新たにした上で、継続的インテグレーションのフィードバックループを効果的に機能させるために、技術プラクティスが不可欠であることに改めて気づかされました。

これらのプラクティスこそがアジャイルの核心だからだ。
「TDD」「リファクタリング」「シンプルな設計」そしてもちろん「ペアプログラミング」。
これらがなければ、アジャイルは本来意図されたものではない、骨抜きにされた、役立たずなものになってしまうだろう。

（Robert C.Martin『Clean Agile 基本に立ち戻れ』（2020年）第1章より引用）

このように考えを整理していくと、改めて「TDD」「リファクタリング」「シンプルな設計」「ペアプログラミング」という技術プラクティスの役割をより明確に意識できました。

原点から得られた学びとこれから

ここまで、成功したチーム、上手くいかなかったチームに接してきた私の実感と原典からの引用を結び付けて紹介してきました。
これらの考察を通じて、考えてきたことをまとめると次のようになります。

アジャイル開発の原点に立ち返ることで、私自身がなかなか見いだせなかった納得感のある理解を得ることができ、その中から、形だけのアジャイルから中身のあるアジャイルへ、とまた一歩アジャイル開発推進の道筋が見えてきたと考えています。