アジャイル開発は大企業に不向きなのか？Google流のアジャイル開発とは？
昨今、大規模システムのアジャイル開発を検討しているエンタープライズ企業が増えていますが、ビジネス習慣、社内文化、人材など様々の課題で、アジャイル開発の普及があまり進んでいないのも事実です。また、積極的に試してみたが期待通りの効果が得られていないケースも存在しており、アジャイル開発は小規模のベンチャー企業には向いているものの、エンタープライズ企業に不向きではないかという懐疑の声も時々聞こえます。
今回は、エンタープライズアジャイルで世界的に有名なGoogle社のアジャイル開発のやり方について考察し、皆様と一緒にアジャイル開発のあるべき姿をもう一度考えてみたいと思います。
１．アジャイル開発は大企業に不向きなのか？
アメリカのＱ＆Ａサイト「Quora」にて、「なぜGoogleのような有力企業の開発者はアジャイル開発が無意味だと考えているか？（Why do some developers at strong companies like Google consider Agile development to be nonsense?）」という興味深い質問が投げられていました。
そのタイトルを読んで、「えっ、Googleでもアジャイルが無意味と思っている人がいるの？」、「やはりアジャイル開発はエンタープライズ企業に不向きでしょうね」と反応する方もいらっしゃるかもしれません。
ですが、答えはノーです。
この質問に対して、元GoogleエンジニアリングディレクターのDavid Jeske氏が自身の業務経験を基に回答してくれました。アジャイル開発はエンタープライズ企業に向いていないという誤解の解消、また、アジャイル開発の本質を理解するためには非常に参考になりますので、皆様にもその回答内容をご紹介したいと思います。
２．アジャイルの価値観とグーグルの考え方
１９９０年代から、ウォーターフォールに代表される当時の開発手法はビジネス変化のスピードに対応できておらず、サービスインまでの期間をより短縮し、要件変更をより柔軟に対応できる開発モデルが求められるようになりました。こうした業界のフラストレーションから、「アジャイルソフトウェア開発宣言」と「アジャイルソフトウェアの１２の原則」が生まれました。現在のアジャイル開発の指針となる存在です。
「アジャイルソフトウェア開発宣言」の四つの価値（抜粋）：
・プロセスやツールよりも個人と対話を
・包括的なドキュメントよりも動くソフトウェアを
・契約交渉よりも顧客との協調を
・計画に従うことよりも変化への対応を
Jeske氏は「アジャイルソフトウェア開発宣言」について、“The simple high level Agile Manifesto is something I think is close to the way Google engineers think about software development.”と肯定し、アジャイル開発宣言の価値観はGoogleエンジニアがソフトウェア開発に対する考え方にとても近いと共感しました。
続いてJeske氏はより詳細なアジャイル１２の原則をGoogleの企業文化と比較し、特に原則の中で下記のような個人のエンパワーメントを提唱している部分はGoogleの企業文化及び開発スタイルと非常に一致していると強調していました。
「アジャイルソフトウェアの１２の原則」抜粋：
・意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
・最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
・チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
・技術的卓越性と優れた設計に対する継続的注意が機敏さを高めます。
・シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
「これらの原則は賢いエンジニアにとってほぼ常識です。シリコンバレーがエンパワーメントと個人の信頼を中心とした文化を生み出しました」とJeske氏は主張しています。
Googleの成功には、意欲に満ちた人々を集め、メンバーの自主性を尊重し、自己組織化できるアジャイル文化の形成が欠かせない土台となっていると感心させられます。ルールやプロセス遵守を重視する日本企業にとって、組織としてのアジャイルマインド変革も極めて重要になります。メンバー意識を変えていないアジャイル開発は、単なる異なるルール・プロセスに変更した形式主義にとどまるのではないでしょうか。
３．アジャイル原則と現実とのギャップ
一方、Jeske氏はアジャイル原則の中で、下記のような「なるべく短期間で継続的に動くソフトウェアを顧客に提供する」という提唱部分について、短期集中型のスクラムプロセスは必ずしもGoogleの開発スタイルと一致していないともはっきりと認識しており、「これらのアイディアは素晴らしいですが、Googleのような企業が取り組む革新的なプロジェクトにとって、短期的な思考に集中してしまう問題が存在する」と指摘しました。
「アジャイルソフトウェアの１２の原則」抜粋：
・顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
・ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
・情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
・要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
・動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
Jeske氏はGoogleの事例を挙げながらこのように説明していました：
「スクラムのような顧客と直接的にやり取りして、短期間で継続的な反復の開発スタイルは、顧客の目で確かめる多くの機能を持ち、徐々に有用になっていくシンプルなソフトウェア開発に適しています。しかし、非常にシンプルなインタフェースを持ちながら、内部には複雑な機能が隠されているソフトウェアや、かなり完成度が高いものでなければ使えないソフトウェア、顧客自身でも想像つかないような画期的なソリューション開発にはあまり向いていないのです。」
「例えば、Bigtable（※１）とBorg（※２）のようなイノベーションには、設計の初期段階からかなりの時間を費やし、1週間以上のイテレーションでコンポーネントに取り組む必要があります。外部インタフェースが非常にシンプルで、内部は非常に複雑なため、プロジェクトの多くの作業は顧客の目に触れることさえなく、顧客の目に触れるストーリーを書く方法もありません。」
「この種のソフトウェアは、最初の実用版を顧客に提供するまでに8〜20ヶ月かかり、技術リーダーの極めて長期的な考え方を反映しています。彼らは、今週中に小さなニーズを満たすようなものに取り組むのではなく、クラスタソフトウェアの開発方法を根本的に変えるための基礎を築いているのです。このような（長期）投資は、Google社に素晴らしい利益をもたらしただけでなく、業界全体にも影響を与えています。」
「また、税務会計ソフトからコンピュータゲームまで、他の業界にも似たようなケースがあります。これらのソフトウェアは、部分的に完成した状態で顧客に提供するのには適していません。」
※１ Bigtable：Googleの大規模なサーバ上の大量のデータを管理するデータベースサービス。
※２ Borg：Googleによって開発された大規模なクラスタマネージャで、複数のマシンにプログラムの処理を分散するための基盤となるシステム。
４．Google流のアジャイル開発とは
上記に挙げられた事例で表しているように、すべてのアジャイル原則はすべてのプロジェクトに適用できるとは限りません。Jeske氏は上記のアジャイル原則をGoogleの企業文化と開発スタイルに沿って、Google流のアジャイル原則をまとめてくれました。
●「私たちの最優先事項は、顧客（と開発者）の生産性、そして情報の収集理解力を高めることで、最も重要で頻繁に出てくる課題に取り組み、最大の効果を生み出しています。顧客が求めるものを与えるのではなく、顧客を理解し、彼らの世界で革命を起こすのです。」
●「開発者はGoogleデザインドキュメント（かなり最小限の、しかし構造化されたデザインドキュメント）を作成し、プロジェクトを説明し、どのような目標を達成したいのか、なぜ他の方法ではできないのかを説明します。このドキュメントは、プロジェクトが進行する前にステークホルダーに配布し、初期のフィードバックを得るべきです。プロジェクトが成功するのはいつなのか、また、どのようにして成功に導くのかについて、明確かつ合意された理解を保証するために、書面による記録は不可欠です。」
●「プロジェクトのどの段階でも、大きな部品に関する重要な設計要素については簡潔に説明し、設計文書に記載する必要があります。」
●「イノベーションを起こすこと。完璧を目指すよりも、飛躍的な進歩を果たすことが重要です。完璧さよりは常に変更できる柔軟性を持つことが大事です。」
●「動作するソフトウェアを合理的な範囲で可能な限り早く提供します。顧客に提供する前に、製品が高い品質基準を満たしているかを確認すべきで、製品の品質はかかる時間よりも重要です。」
５．アジャイルのあるべき姿を再考
このように、Googleは自社ニーズに合わせて、アジャイル原則を柔軟に対応しています。ただし、「変化を歓迎し、顧客が仕事の中心である」、「開発をビジネスニーズと一致させる」という本質は変わっていません。
このような柔軟かつ堅実なアジャイル開発体制によって、Google社の世界中にいる数万人のエンジニアが、一日に約何万回にものぼるコード変更を行っていながら、優れた開発スピードを示すことができ、世界をリードする革新的なサービスを提供し続けられていると思います。
Jeske氏が提示してくれたGoogle流のアジャイル原則を何度も読みました。企業にとって、アジャイル開発のあるべき姿とそれを実現するために必要な考え方と取り組みとは何かを考えさせられます。
単なる短期間軽文書の開発プロセスは本当のアジャイルではありません。
ガイド・教科書の通りスプリントをまわしイベントや成果物を厳格に実行するのも本当のアジャイルとは言えません。
アジャイル適用可否は企業規模や業界とも関係ありません。
アジャイルの本質を振り返ってみると、「変化を歓迎し、顧客が仕事の中心である」という価値観が原点となり、顧客のことを理解しようとし、変化に応じて顧客の生産性やビジネス価値を高めようとする意欲です。
これを実現するために、自社と顧客のニーズに合わせて、最も効果的なコミュニケーション方法を合意し、最良のアーキテクチャを考え、無駄な作業を減らし、最適な開発プロセスに取り組むことで効率的にプロダクト（サービス）を提供することがアジャイル開発の本来あるべき姿ではないでしょうか。
