掲載内容は私個人の見解であり、所属する組織の公式見解ではありません。
皆さんは「アジャイル開発とはどんな開発ですか？」と問われたらどのように答えるでしょうか？
アジャイル開発が日本でも流行り出した10年ほど前の私であれば、「設計-開発-テストという工程を順番に実施するのではなく、開発項目に優先順位を付けて、短い開発期間優先順位を高いものから開発を積み上げていく開発です。」と答えていたでしょう。実際に生成AIに「アジャイル開発とはどんな開発ですか？」と問いかけてみると冒頭で以下のように回答がありました。
アジャイル開発とは、「計画→設計→実装→テスト」のサイクルを機能ごとに短期間で繰り返し、変化するニーズに柔軟かつ迅速に対応しながらソフトウェアを開発していく手法です。
世の中の文献でも似たようにアジャイル開発は紹介され、アジャイル開発をこれから始めようとする人達は、「短期間」や「迅速」という言葉に期待を寄せて、ウォーターフォール開発で実施してきた煩わしいプロセスを省いてスピーディに開発を進められると期待し、アジャイル開発の有識者に「どのプロセスを省けるのですか？」と相談してみると「従来の開発で実施してきたプロセスが、組織として必要なプロセスがあれば、アジャイル開発でもそのプロセスを実施すれば良い」と期待外れで煮え切らない回答を得ることになります。
これは私も実際に経験したことです。
結局のところアジャイル開発の本質を知らず、色々なことを誤解した結果、アジャイル開発を試して失敗することになります。私の周囲では、以下のような問題に遭遇するケースが多いです。
・アジャイル開発の迅速な開発に過度な期待をして、ウォーターフォール開発では短期で実現できない開発を企画した結果、企画した内容の大半を開発できずに企画内容を大幅に変更することとなった。
・設計を疎かにして、動くものを作り始めたが、考慮漏れが多発してプロダクトオーナーに受け入れられず、開発が遅延する。
・設計書を作成せずに実装を進めたため、リリース後の保守担当者から設計書を求められたが、設計書が無いため保守担当者から開発担当者にクレームが発生した。
何度か失敗した後に、私は以下の2つの書籍に出会うことになり、アジャイル開発について理解を深めることになります。
- 「正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について」市谷聡啓 氏著
- 「アジャイルソフトウェア開発 Agile Software Developmnt」アリスター・コーバーン氏著
1の本の中で2の本について以下のような説明があります。
先駆者の一人であるアリスター・コーバーンの記した書籍『アジャイルソフトウェア開発』によると、先駆者たちが同意したことは4つで、先に挙げた3つ(変化への対応、4つの価値、12の原則)の同意以外に「不同意の同意」というものがあったという。
アジャイル開発の説明で「不同意の同意」という説明を皆さんは聞いたことありますか？
私は上述の本の中でしか見たこと・聞いたことがなく、それがきっかけで引用されていた2の書籍を取り寄せて読むきっかけとなりました。
本投稿では簡単にアジャイル開発の本質について語ってみたいと思います。「今更、アジャイル？」と思われるかもしれませんが、一般の書籍で語られる単なる開発手法としてのアジャイル開発ではなく、アジャイル開発がどのような考え方でなぜ登場したのかについて深掘りしていきたいと思いますので、すでにアジャイル開発を実践している方にも改めて刺激となれば幸いです。
未知と伝達不能
人が何かを創造する時には、その人が経験したことの尺度でしか物事を考えられないので、経験したことが異なる人同士がコミュニケーションする場合、頭に描いたアイデアを詳しく他人に伝えても完全に同じアイデアを共有することはできません。
特にソフトウェアの開発においては、複数人のチームで開発し、チーム内には経験豊富なスキルの高い技術者もいれば、新人で未熟な技術者もいるため、チーム内で完全にこれから作るソフトウェアのイメージを共有することも困難です。
上記の2の本でも、序章は「導入：未知と伝達不能」で始まり、以下の書き出しから始まります。
序章「導入：未知と伝達不能」の書き出し
本章では、「これから経験することがわかるのか、そして経験を伝達できるのか」という2つの質問を設定する。「そんなことはできない」という簡単な答が、本章で解決しようとしている基本的なジレンマである。
未知で伝達不能であれば「的外れな要素に時間を費やすこと、および重要な要素を見逃すこと、どちらも大きな害をもたらす」と述べ、「誰にでも理解できる要求定義書や設計モデルを目指すのではなく、対象とする人にとって十分目的を果たすドキュメントだけを作るようになる。「コミュニケーションの不完全性を管理すること」が、アジャイルソフトウェア開発を習得するためのキーポイントである。」と述べています。
一方で、これから経験することを推測ことが可能で、その推測をチーム間で資料などで時間をかけて共有する方が手戻りが少なく開発できる場合もあります。それは既存の紙や手作業による作業をICTを使って自動化する場合です。
このようなデジタル技術の活用を世の中ではデジタイゼーションと呼び、従来のデジタイゼーションでICTが多く活用されてきました。言い方を変えれば、既存業務のデジタル化です。
既存の業務を忠実に漏れなく計画的にソフトウェアを開発するウォーターフォール開発が適していたのです。
しかし、クラウドの登場によりデジタル技術が今までよりも気軽に活用できる社会になったことで、デジタル技術は単なる既存業務の効率化にとどまらず、従来には無いサービスによって人間の生活を変化させるものとなりました。このようなデジタル技術の活用をデジタライゼーションと呼び、デジタライゼーションによりデジタル・ディスラプションという新規ビジネス形態が既存ビジネスを破壊する状態が増え、今までに人が経験したことのない社会の実現にICTを活用しようという取り組みが活発に行われるようにあったことで、アジャイル開発が必要となったのです。
このようなデジタライゼーションによるサービス提供により、人間の生活のあらゆる側面で影響を与えることを「デジタル・トランスフォーメーション」、いわゆるDXと呼び、2004年にスウェーデンのウメオ大学のエリック・ストルターマン・ベリクヴィスト（Erik Stolterman Bergqvist）教授の論文"Information Technology and the Good Life"の中で以下のように初めて「デジタル・トランスフォーメーション」という言葉に言及したと言われます。
「The digital transformation can be understood as the changes that the digital technology causes or influences in all aspects of human life.」
(デジタル・トランスフォーメーションは、デジタル技術が人間の生活のあらゆる側面にもたらす、あるいは影響を与える変化として理解することができます。)
以上のように、アジャイル開発は未知であり伝達不能なことをソフトウェアで実現する際に必要なソフトウェア開発の考え方なのです。
この未知であり伝達不能なことをソフトウェアで実現しようと考えると、以降で説明するアジャイル開発で必要とされる価値や原則は自然と理解できると思います。
日本生まれ米国育ちの開発手法
現在世界的に広まっている「アジャイル」の大きな潮流のきっかけの一つが、日本から生まれたことをご存じでしょうか？
ここで日本生まれ米国育ちの開発手法とも呼ばれるスクラム開発の登場について紹介したいと思います。
1986年
日本の野中郁次郎氏と竹内弘高氏が「The New New Product Development Game」という論文を発表し、論文の中でラグビーの「スクラム」に例えて、チームワークの重要性を説きました。
この論文では今日の競争の激しい市場で生き残るために、新製品開発には従来の「高品質(high quality)」「低コスト(low cost)」「差別化」だけではなく、「スピード(speed)」と「flexibility(柔軟性)」が不可欠であるとしています。
この中で従来のようなスペシャリストのグループが、次のスペシャリストのグループにバトンを渡していくようなリレー的な開発に対して、他分野に渡る知識を持ったメンバがチームを組んで最初から最後までチームで協力するようなラグビー的なアプローチの開発の方が今日の競争には適していると言っています。
このようなラグビー的なアプローチには以下の6つの特徴が示されており、以降で説明するアジャイル開発でもすべて当てはまる内容となっています。
ラグビー的なアプローチの6つの特徴
-
built-in instability
直訳すると「組み込まれた不安定性」です。
経営トップは、大まかな目標や戦略的な方向性を示すことで開発プロセスを開始します。
明確な新製品コンセプトや具体的な作業計画を指示することはあまり行わず、プロジェクトチームには幅広い自由度を与え、同時に非常に挑戦的な目標を設定します -
self-organizing project teams,
直訳すると「自己組織化されたプロジェクトチーム」です。
事前の知識が通用しない「ゼロ情報」の状態へと追い込まれるにつれて、自己組織化的な性格を帯びてきます。この状態では、曖昧さと揺らぎが蔓延します。放置されると、プロセスは独自の動的な秩序を形成し始めます。2プロジェクトチームはスタートアップ企業のように活動し始め、自発的に行動し、リスクを取り、独自のアジェンダを策定します。そしてある時点で、チームは独自のコンセプトを作り上げ始めます。
グループは、自律性、自己超越性、そして相互交流という3つの条件を満たしているとき、自己組織化能力を備えていると言えます。 -
overlapping development phases,
直訳すると「重複する開発フェーズ」です。
チームの自己組織化という特性は、独特のダイナミクス、つまりリズムを生み出します。チームメンバーはそれぞれ異なるタイムホライズン（研究開発チームが最も長いタイムホライズン、製造チームが最も短いタイムホライズン）でプロジェクトを開始しますが、期限を守るためには全員がペースを合わせなければなりません。また、プロジェクトチームは「情報ゼロ」の状態からスタートしますが、メンバーはすぐに市場や技術コミュニティに関する知識を共有し始めます。その結果、チームは一体となって機能し始めます。ある時点で、個人と全体は不可分になります。個人のリズムとグループのリズムが重なり合い始め、全く新しい脈動が生まれます。この脈動が原動力となり、チームを前進させます。 -
“multilearning,”
マルチラーニングです。
プロジェクトチームのメンバーは外部の情報源と緊密に連携しているため、変化する市場環境に迅速に対応できます。チームメンバーは継続的な試行錯誤を繰り返し、検討すべき選択肢を絞り込みます。また、幅広い知識と多様なスキルを習得することで、多様な問題を迅速に解決できる万能なチームを構築します。
このような実践による学習は、複数のレベル（個人、グループ、企業）と複数の機能にまたがるという2つの側面で現れます。私たちは、この2つの学習の側面を「マルチラーニング」と呼んでいます。 -
subtle control,
直訳すると「微妙なコントロール」です。
プロジェクトチームは大部分が独自に活動していますが、統制されていないわけではありません。経営陣は、不安定さ、曖昧さ、緊張が混沌と化すのを防ぐため、十分なチェックポイントを設けています。同時に、創造性や自発性を損なうような厳格な統制は避けています。その代わりに、「自制心」、「同僚からのプレッシャーによる統制」、「愛情による統制」を重視しており、これらを総称して「微妙な統制」と呼んでいます。 -
organizational transfer of learning.
直訳すると「学習の組織的な移転」です。
グループ内のマルチラーニングだけでなく、グループ外の人々に学習を移転します。
1993年
ジェフ・サザーランド氏らが、この野中・竹内両氏の論文に触発され、ソフトウェア開発プロセスに初めて「スクラム」の概念を適用し、最初の実装を行いました。
1995年
ジェフ・サザーランド氏とケン・シュエイバー氏が共同で論文「The SCRUM Development Process」を発表し、公式にスクラム開発手法を公開しました。これがスクラム開発の一般への最初の登場となります。
「高品質(high quality)」「低コスト(low cost)」「差別化」だではなく、競争の激しい分野の開発においては「スピード(speed)」と「flexibility(柔軟性)」が不可欠であり、スペシャリストのグループにバトンを渡していくようなリレー的な開発に対して、他分野に渡る知識を持ったメンバがチームを組んで最初から最後までチームで協力するような
ラグビー的なアプローチが適していると言うのです。
前節で説明した「未知と伝達不能」を見れば想像できると思います。
「これから経験することがわかるのか、そして経験を伝達できるのか」の問いに「そんなことはできない」という未知で伝達不能なソフトウェアを開発する場合、設計者がきっちり設計して開発者にバトンを渡し、開発者はきっちり開発してテスターにバトンを渡し、テスターはっきりテストを実施するという開発が適切かを考えれば、容易に適切とは思えないでしょう。
そもそも未知なるものをきっちり設計なんてできないので、実装者に意図が伝わる程度の最小限のドキュメントで設計者と開発者は認識合わせ氏、開発した動くものを設計者が確認して意図と違うようであれば、追加の最小限のドキュメントで改めて認識合わせして微調整し、最小限のテストを実施した上で顧客のフィードバックを受け、更に設計・開発・テストを短サイクルで回していくのが適切だと感じますよね。
今後のためにドキュメントが必要であれば開発がひと段落したら、ドキュメントを作る工程を設けて準備するということになります。
アジャイルアライアンスの設立につながる会議の開催
スクラム開発以外にもXPなどの開発手法がいくつか登場し、当時はこれを軽量級開発と呼んでいたそうです。
2001年に軽量級開発プロセスの提唱者17人がユタ州に集まり、お互いの共通点は何か、または見解の相違を認め合うかどうかを議論しました。
この会議の中で軽量(lightweight)という単語では不十分だと一致し、変化する要求に対してプロジェクトの期間内に対応することの重要性に同意して「アジャイル(Agile)」という単語を使うことが選択されました。
この会議に参加した17人の参加者の名前は以下です。冒頭で説明した「アジャイルオフトウェア開発 Agile Software Developmnt」の著者であるアリスター・コーバーン氏が参加しています。
ちなみに別の投稿で紹介しているマイクロサービスという言葉が広まったとされるマイクロサービスブログの投稿者であるMartin Fowler (マーチン・ファウラー)氏も会議に参加しています。
Kent Beck (ケント・ベック)、Ward Cunningham (ウォード・カニンガム)、Ron Jeffries (ロン・ジェフリーズ)、James Grenning (ジェームス・グレニング)、Robert C. Martin (ロバート・C・マーチン)、Jeff Sutherland (ジェフ・サザーランド)、Ken Schwaber (ケン・シュワバー)、Mike Beedle (マイク・ビードル)、Martin Fowler (マーチン・ファウラー)、Jim Highsmith (ジム・ハイズミス)、Alistair Cockburn (アリスター・コーバーン)、Jon Kern (ジョン・カーン)、Arie van Bennekum (アリエ・ファン・ベネクム)、Andrew Hunt (アンドリュー・ハント)、Dave Thomas (デイブ・トーマス) 、Brian Marick (ブライアン・マリック)、Steve Mellor (スティーブ・メラー)
会議の合意事項
この中で以下の4つのことが同意されています。いわゆるこれがアジャイル開発の本質ということになります。
【レベル1】変化に対応する必然性に同意
1986年に野中郁次郎氏と竹内弘高氏が公開した論文に記載されているように、今日の競争の激しい市場で生き残るためには、
絶えず変化するビジネス環境に俊敏に対応する必要があり、システム要求もビジネス解の変化に対応して変更し続けることになります。
アジャイル開発では変化に対応して、価値のあるソフトウェアを早く、継続的に提供していくことが求められます。
アジャイル開発に取り組む場合、よく「変化を楽しむように」と言われます。
【レベル2】4つの中核となる価値に同意
これは有名なアジャイルソフトウェア開発宣言で示される以下の4つの価値のことです。
アジャイルソフトウェア開発宣言の4つの価値
- プロセスやツールよりも個人と対話を
Individuals and interactions over processes and tools - 包括的なドキュメントよりも動くソフトウェアを
Working software over comprehensive documentation - 契約交渉よりも顧客との協調を
Customer collaboration over contract negotiation - 計画に従うことよりも変化への対応を
Responding to change over following a plan
見落としがちですが、4つの価値の後に以下のように記載されていることも忘れてはなりません。
That is, while there is value in the items on the right, we value the items on the left more.
いわゆる右側の項目にも価値がありますが、それよりも左側の項目にもっと価値があると言っていることです。
宣言でよく誤解を招くのが「包括的なドキュメントよりも動くソフトウェアを」です。
ソフトウェア開発者はプログラミングがしたくてソフトウェア開発者になったにも関わらず、ウォーターフォール開発を経験すると実際にプログラミングして動くソフトウェアを開発するまでに多くの資料を求められることに不満を持ちながら、企業で決められたプロセスなので仕方なく資料作成をしていることに渋々従います。
（何度か経験を積めば資料の必要性は理解できるものの、）アジャイル開発を煩わしい資料を作らず動くものを作れば良いのだと拡大解釈し、最終的に十分な設計をせずにソフトウェアを作って問題が発生して手戻りを繰り返して結果的に作業が一向に完了せずに失敗するケースを多く見かけます。
あくまでも「包括的な」の部分がポイントであり、過去のルールに縛られて形式だけで意味のないドキュメントを精密に作って周囲と合意するよりも、新たな機能で実際に動いたもので評価してみないと完成イメージが湧かない部分はドキュメント作成より動くソフトウェアで合意した方が良いよねという意味です。
更に「アジャイルソフトウェア開発 Agile Software Developmnt」には「ドキュメントのすすめ」として以下の記載があります。いわゆる完全なドキュメントを求めても無理なので最小限のドキュメントに留めることを考えるべきであるが、最小限のドキュメントとして新しいメンバが開発に参加したり、開発が完了してもゴールではなく次のエンハンスや保守が求められることを意識し、そういった場合に必要なドキュメントを用意しようということです。
アジャイルソフトウェア開発 Agile Software Developmnt」に記載されている「ドキュメントのすすめ」
- 完全な要求、コードと合っている設計書、プロジェクトの状態に合っているプロジェクト計画を求めるな。
- その代わり要件収集者には、設計者とコミュニケーションが取れる程度に要件を把握するように求めよう。要件収集者が直接訪問したり、タイプ入力ではなく短いビデオクリップなどの速いコミュニケーションメディアを使うとよい。
- 設計者全員が専門家で、近くに座っている場合は、ホワイトボードのスケッチ以上の設計書を作らないようにしよう。そしてホワイトボードの図を写真に撮るか、コピー機能付のホワイトボードを使おう。
- この設計チームに新しいメンバが参加することを考慮に入れよう。新しいメンバは、実際に多くの設計書を必要としている。
- 文章化は、プロジェクトの開発プロセスの線形パスに押し込むのではなく、リソースを競合する並行なプロジェクトスレッドとして行おう。
- 完全なことは、非現実的である。これを避けながら、2つの目標に適切に達する方法に対して、できるだけ独創的になろう。
- (誇張した形容詞を使うが)その状況で可能な最軽量の、最もずさんな方法論を探そう。そしてその方法論が、実際にコミュニケーションを行える程度に厳格であることを確認しよう。
他に日本語訳により誤解をされるのが「プロセスやツールよりも個人と対話を」です。
日本語訳だと「個人との会話を重要視しましょう」のように聞こえますが、英語は「Individuals and interactions over processes and tools」なので、「"個人"、そして、"対話"を重要視しましょう」という意味です。
プロセスを守っているかを重視するのではなく個人に信頼して作業を任せ、ツールの作法に従うよりも直接の対話を重要視しましょうということです。
【レベル3】4つの価値に合致する12のより詳細化された原則に同意
これはアジャイルソフトウェア開発宣言からもリンクされているアジャイルソフトウェアの12の原則のことです。
以下の12の原則が記載されています。
アジャイル宣言の背後にある原則
- 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
- 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
- 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
- ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
- 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
- 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
- 動くソフトウェアこそが進捗の最も重要な尺度です。
- アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
- 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
- シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
- 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
- チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
【レベル4】同意の不在がこの業界ではとっても健全なことであり、思考の世界で革新と競争を続けるべきだと合意
これが冒頭で記載した「不同意の同意」です。
アジャイル開発宣言が4つの価値と12の原則という、マインドセットのようなことしか決められていないのは、アジャイル開発の源泉は状況に合わせてやり方を柔軟に変えることで進化のスピードを早めることであるにもかかわらず、プロセスやツールまで合意いてしまうと、仮により良いプロセスやツールが登場した時に、合意したプロセスやツールが進化の足かせになってしまうため、プロセスやツールまで合意しないことが健全であり、より良いものを取り入れて思考の世界で革新と競争を続けるべきだと合意したということです。
アジャイル開発とは何かを示すことが難しいのは、4つの価値と12の原則しか決まっていないためです。ただ、これ以上のことを決めてしまうと、より良い方法が見つかった時に採用しないというアジャイル開発のマインドに反する状態になるため、これ以上は合意できなかったということです。
アジャイル開発の本質
アジャイル開発がどのように登場し、有識者の会議で軽量級開発の共通点を「アジャイル」と名付けたのかについて確認してきました。
アジャイル開発の本質が何かを感じ取っていただけたでしょうか？
アジャイル開発はウォーターフォール開発より生産性が向上すると思い込んでいる人もいますが、確かに未知なるソフトウェアを作る場合に無駄な機能を作り込まないという意味で生産性は上がるかもしれませんが、顧客が実施に使って無駄な機能だとフィードバックがあれば最悪破棄するかもしれません。
一方でウォーターフォール開発の場合、最初の契約時点で作るものを合意したら、その合意内容の一部が顧客にとっては実際な機能であっても契約通りに実装されて数年後に提供されるまで気づかないので、途中で破棄される機能がないという意味では開発期間中に作り込まれる機能数を生産性と捉えればウォーターフォール開発の方が生産性は高くなります。
また、アジャイル開発は開発者が採用する単なる開発手法でもありません。経営層が「今後のシステム開発はアジャイル開発でやれ！」と指示するものでもありません。
アジャイルマインドと最近言われるように、アジャイル開発はどちらかというとマインドセットです。
アジャイル宣言の「契約交渉よりも顧客との協調を」が象徴的ですが、システム開発の契約形態から考える必要があり、従来のシステム請負企業との契約が特定の成果物の完成を目的とする請負契約なのであれば、契約段階で何が納品物となるかという定義が必要となり、未知で伝達不能であるのに契約時点で作るものを決めることになってしまいます。
自社製品の開発であっても、経営者と開発者の間で、製品企画書で何を作るのか事細かく機能を説明して、機能ごとの開発に必要な費用の妥当性を提示して承認を得るようなプロセスで開発しているような企業においても製品企画のやり方を見直す必要があるでしょう。
これらは経営者・幹部社員のマインドを変えて、「プロセスやツールよりも個人と対話を」により企業の既存プロセスの変更を含めて組織全体で変革が必要となります。
アジャイル開発にチャレンジしようとする技術者の多少なりとも参考になれば幸いです。