プロのトレーナーとコーチが何度も目にしてきたことがある。あまりにも多くのアジャイルチームがはまり込んでしまうパターン、すなわち、ワクワクするような、高度な「活躍」をする段階に進めず、ただの平均的な「導入」の段階で行き詰まってしまうという現象だ。読者の皆さんも考えてみてほしい。すべてのソフトウェア開発プロジェクトに共通することで、最大限にしたときに生産性が急上昇するものがあるかもしれない。実際、最も成功したチーム (アジャイルチームであれ従来からのチームであれ) の多くがソフトウェア開発の、一見単純ではあるが、よく忘れられる「秘伝」をすでに活用している。それは、頻繁にふりかえって学習する時間をつくることである。
何について学ぶのか？お互いのこと、テクノロジ、ドメイン、顧客など、すべてについてである。速く学習するチームは成功する。チームのパフォーマンスを妨げる目に見えない「学習ボトルネック」について詳しく知りたいのなら続けて読んでほしい。
仮想実験
ソフトウェア開発をより良くするために何ができるか？ソフトウェア開発で典型的なボトルネックは何か？すべてに共通するひとつの点があるか？本物の実験を実施することができた時代は、とっくに過ぎ去ってしまった。本物の実験を実施するためには、同じプロジェクトを2回構築しなければならないのだ。残念ながら今日のビジネス環境でこれをやるのは非常に高くつく。従って、共通する弱点が何なのか正確に把握するために、実際に実験を行なってみるのは今のところ非現実的である。
同時に、私たちは皆、専門家という立場でソフトウェアを開発した経験がある。そこで多くの学生に示した仮定の状況を紹介しよう。
学生 (彼らの多くはソフトウェアを構築することに関して20年以上の経験がある) にこの仮定の状況を示すと、彼らは大体、最初にかかった時間の20%から70%の範囲で答える。つまり、もともと構築するのに1年かかったシステムを再構築するのに、わずか2.5から8.5ヵ月しかかからないことになる。なんて大きい差なんだ！これだけソフトウェア開発に影響を及ぼすことができる要因が他にあるだろうか。私が顧客で、あなたやあなたのチームにソフトウェアシステムを構築するように頼んだと考えてください。あなたのチームはソフトウェアシステムの構築に着手します。テスト済みの動作するソフトウェアを提供するまでに丸1年 (12ヶ月) かかります。
次に、私はチームに感謝してソフトウェアを受け取り、それを捨てしまいます。それから私はあなたとあなたのチームにシステムを再構築するよう依頼します。あなたには、同じチームがあります。同じ要件があります。同じツールと同じソフトウェアもあります。基本的に、まったく同じ環境です (何も変わっていません)。
あなたとあなたのチームが再びシステムを構築するのにどのくらいの期間が必要ですか？
それでは何が問題なのか？2回目のときは何が異なっていたのか？チームは学習したのだ。彼らはチームとして互いについて学び、1年間かけて調和していった。彼らは本当の要求 (書かれていない要求も) について学んだ。また、彼らはツールセット (すべてのソフトウェア開発中に現れる特異性) を利用することを学んだ。基本的に、ソフトウェア・ソリューションを構築し提供するまで、よく分からないことに取り組んでいたのである。学習はソフトウェア工学の「ボトルネック」だ。[2]
学習が必要になると、仕事のかなりの割合を占めることになる。実際に、それは開発時間のおよそ30%から80%の割合を占めると推測される。そして、ここにアジャイルプラクティスがうまくいく主な理由がある。ここでいうアジャイルプラクティスはすべて変化に気づき対応することに関するものである。
アジャイルプラクティス (テストファースト開発や継続的インテグレーションに始まり、イテレーションやふりかえりに至るまで) はすべて、チームが速く学ぶことができるサイクルから成っている。あらゆる実行可能なプラクティスを反復することによって、アジャイルなチームはソフトウェア工学のボトルネックに本気で取り組み、学習を促進する。それが「科学的研究法」、「継続的改善」、「すべてをテストする」などと呼ばれることなのだ。
「学習はボトルネックである」という眼鏡を通してアジャイルを見る
アジャイルソフトウェア開発は効果的である。これは既成事実だ。何百もの成功事例が過去8年間にわたって実証されてきた。アジャイル開発に関して興味を引かれることの1つはプラクティスの大半が新しくないということだ。実際、それらは非常に古い。アジャイルは単に最もうまくいったソフトウェア開発のプラクティスの多くを抜き出して、それらを集めたものだ。事実、アジャイルマニフェストは何も新しいことは言っていない。90年代にすでにうまくいっていた数多くのライトウエイトな方法論に共通点を見出したのだ (Jim Highsmith氏 (source)[3] と Uncle Bob氏(source) [4] による2つの異なる説明がある)。最も効果的なプラクティスの多くについてよく考えてみると、いくつかの非常におもしろい共通点が明らかになる。
変化に気づき対応するためのサイクル
どうやって学ぶか？私たちは間違いから学習する(もし注意を払っていればであって、多くの人はそうではないが)。どうやってより速く学習するか。より多くの (小さい) 間違いを速く経験する。「フェイル・ファースト」だ。学習したことをすぐに活用することが、学習を確固たるものにして自分の中に「定着」させる秘訣である。学習したことをすぐに次のサイクルで適用することによって、学習の効果を (まるで複利のように) 増やしていく。私たちが何度も目にする非常に一般的なサイクルは、次のようなものだ。
1) 目的を決める。2) その目的を達成するために行動する。3) 行動した結果と最初の目的を比べる。4) それに応じて行動を変更し、(2)に戻る。ステップ(3)で学習し、ステップ(4)で適用する。
この単純なサイクルはアジャイル開発における多くのプラクティスの基礎になっている。
- テストファースト開発(TDD):
1) 失敗するテストを書く。 2) テストが通るようにコードを書く。 3) テストを実行する。(テストは通るか?) 4) まだテストが失敗しているなら、原因を調べて(2)に戻る。 - 毎日のサイクル
1) チームとしてその日のうちに完了させるタスクを決めて、毎日のスタンドアップミーティングで報告する。 2) タスクをこなす。 3) 翌日、進み具合と進捗の妨げになっていることを報告する。 4) 学んだことを翌日の計画に適用する。 - テスト駆動要件 (TDR)
1) 要件をテストとして定義する。 2) ソフトウェアを開発する。 3) テストを実行する。テストが通ったら完了。 4) テストが通らなかったら、原因を解明して、(2)に戻る。 - イテレーション
1) 「完了状態」を定義する。 2) イテレーションのバックログにある要件に取り組むことを明言する。 3) そのイテレーションでバックログを完了させるように取り組む。 4) 「完了状態」に対して各項目をテストしてイテレーションを終了し、完了のマークをつけるか、またはペンディングにして要件をバックログに戻す。 - デモ
通常、イテレーションの終わりに行われる。実装が完了したときに、想定していた要件が本当に目の前の問題を解決するかどうか、実際に顧客が試すことができる。1) (暗黙のうちに) 要件に盛り込むビジネスニーズ/価値を決定する。 2) 要件を定義する。 3) イテレーションの間、要件を構築する。 4) ビジネスニーズに対して実装された要件を評価する。 - ふりかえり
1) チームの進め方を決める。 2) イテレーションの間、そのやり方で進める。 3) プラクティスがどれくらいうまくいったかふりかえる。 4) より効果的なプロセスを作って、それを導入するためのアクション(担当者と期日も含む)を考え出す。 - リリース
1) リリースに向けたビジョンをつくり、リリースで満たすべきビジネスゴールを決める。 2) リリースバックログをつくる。 3) リリースを構築するために何度かイテレーションを行う。 4) 顧客の環境にデプロイし、次のリリースのためのフィードバックを集める。 - スクラムのスクラム
一度に複数のプロジェクトを扱う場合、各プロジェクトはそれぞれ自分達のサイクルがあり、同時に定例会で同期をとる(スクラムのスクラム)。定例会は各プロジェクトの代表者が他のプロジェクトに報告する場である。それは企業レベルで変化に気づき対応する機会を与えることになる。 - 管理テスト
1) プロダクトオーナーかビジネスステークホルダーと協力して、高い水準で、どうやってプロジェクトやリリースの成功を計測するか定義する。 2) チームが期待に沿って機能するように、これらの「テスト」を見えるようにしておく。 3) 管理テストの評価をふりかえりの中に組み入れる。 4) チームとプロダクトオーナーは、各イテレーションがこれらのテストに合うよう協力する。
さらに、これらのサイクルはお互いに影響し合う。実際、外側のサイクルの誤りを発見するような学習が起こって、絶えずお互いに影響し合っている。テスト駆動開発のループはテスト駆動要件の中で入れ子になる。つまり各要件ごとに、1つの要件を満たすためのいくつかのテスト駆動開発サイクルが起こる。したがって、例えば、テストが通らないのはコードが間違っているのかもしれないが、そうではなくて、これから構築する要件のために、以前の別の要件を破棄する必要があるのかもしれないのだ。だから、テスト駆動開発のループでは要件について学ぶことになる。同様にイテレーションはリリースの中で入れ子になっている。そこで、予測外の技術的な制限により1つ以上目標が達成できないイテレーションがあると、システムの重要な部分を完成させるための工数が追加で必要になる。チームは再び集まって、リリースバックログを考慮し、新しい情報に対応するため優先順位の付け直しとスコープの変更を行う。
サイクル：必要であるが、十分でない
サイクルは変化に気づいて対応するための2つの基本的な要件のうちの1つである。サイクルは機会を提供する。2つ目の要件はコミュニケーション(みんなを巻き込むことで学習効果を高めること)である。したがって、アジャイル開発の試みの中では「情報発信器」が重要視される。情報はチーム内のメンバーをはじめチームの垣根を越えて伝える必要がある。コミュニケーションがなければ、問題に気づかないかもしれない。コミュニケーションがなければ、問題に気づいても解決策を見つけることができない人は、解決策が分かっている、自分とは異なるスキルを持っている人から、何も教えてもらうことができないかもしれない。チーム環境では、与えられた問題を解決するのに誰が一番ふさわしいか必ずしも明白ではない。みんなに知らせることによって、あらゆる利害関係者から提案を引き出すのだ(チームの「専門家」からだけでなく)。時には初心者や部外者が「これまでとは全く違った視点で考える」ことができて、驚くことがある。
コミュニケーションは学習を促進し、強化する。そして、よく考えるためにきちんと立ち止まることで、「急げ、急げ！」という叫び声によってコミュニケーションがかき消されないようにできる。このように立ち止まるには、正式にふりかえりを行ったり、イテレーションの終わりに気軽に食事に行ったりすればよい。学習と改善について話し合えばよいのだ。またコミュニケーションは各サイクルの始め(目標を決めること)と終わり(テスト結果)に計画されたやり方で行うべきである。一方、各サイクルが進むにつれ、気軽な「浸透する」[5] コミュニケーションからも大きく得るものがある。
かなりの数のアジャイルプラクティスは、直接、コミュニケーション(公式なものも「浸透する」ものも)に注目している。
- 自己組織化チーム: チームが一緒に働くのは、起こる変化に一緒に対応するためである。
- 同じ場所に配置されたチーム: チームメンバは一緒に座って、日常的にグループで会話をする。会話は周りの人の耳にも入る。そして、各メンバは周りで何が起こっているのかなんとなく理解する。
- 様々な仕事をこなすチーム: 複数の専門分野を持つチームはエンド・ツー・エンドで問題を解決するために一緒に取り組む。一緒に働くことによって、各個人の専門知識を共有する。
- ペア・プログラミング: 1つのタスクを解決するために2人が一緒に作業するのは経験と専門知識を共有するのに非常に意味がある形である。
- .情報発信器: 「大きな目立つ図」である。この図の唯一の目的は通りがかりの人にいくつかの重要なデータを伝えることである。
- 示唆に富むドキュメント: アジャイルチームは話し合うためにドキュメントを一緒につくる。後で読むと、それらのドキュメントが議論全体とその状況を思い起こさせる。これらは、本来よく書かれている伝統的で壁越しに投げ渡すようなドキュメントよりもはるかに価値がある。正式なドキュメントというのは、あまりに力を入れすぎるので、実際に書かれている通りであるという(正しくない)確信をいだくことがあるのだ。
- スタンドアップ・ミーティング: アジャイルチームはちょうど完了したタスク、進捗の妨げになっているもの、次の1日のサイクルで完了させようと計画しているタスクを伝えることで毎日同期をとる。
上手にプラクティスを使っているなら、アジャイルチームはすべて(単に技術的なことだけでない)に関して素早く学習する。それは、設計(TDD、ペア・プログラミング、様々な仕事をこなすチーム)、要件(デモ、TDR)、製品(イテレーション、リリース)、人(ふりかえり、スタンドアップ・ミーティング)などである。
これはなぜ重要か？ プラクティスの理論
学習はソフトウェア開発で非常に重要な部分であるらしい。それはいいだろう。おそらく学習は今認めているよりもさらに重要である。しかし、だからどうしたというのだろうか？学習することで私のチームやあなたのチームがより良いソフトウェアを作り出す。それをどうやって手助けすることができるのか？前掲の「学習」のプラクティスのすべての例にもかかわらず、アジャイルチームは学習ボトルネックに影響される。緊急な要件の場合、(「まぁ、それは後でやるさ」と)学習ステップを省略して、短期的にうまく終わらせなければならないからだ。学習しないアジャイルチームは以下の兆候の一部あるいは全部を示す可能性がある。
- やる気の問題につながる疲労(本当に持続可能なペースで働いていない)
- 1回のイテレーションで「完了」できないことが続く
- 続けて約束を果たせない(いくつかの約束された機能やストーリーは着手もしていない)
- デプロイされたソフトウェアから、立て続けに多くの欠陥が見つかり、開発計画が頓挫する
- ふりかえりを過小評価するかやめてしまう(「だって、実際に私たちが認識している問題を解決していないじゃない」)
ボトルネックから目を離すな
以下の図について考えよう。各ステップは、ステップ名の下に括弧で示された速度が示されている。2つのステップ間で速度が合わないとき、在庫がたまる。したがって、ステップAがステップBより速いので、Aの余った製品はBによって処理されるのを待つ。システム全体のスループットは、ボトルネック[6]によって、常に制限される。システム全体のスループットを向上させたいならば、ほぼ例外なくボトルネックのパフォーマンスを向上させることに重点的に取り組む必要があるということだ。他のところで費やされる努力は、無駄で逆効果になることさえありうる。つまり、SSP(以下の図)では、改善することができる唯一の方法はステップDを調整することである。他のものに取り組んでも改善しないであろう。
学習が本当にソフトウェア開発のボトルネックであるならば、学習を優先順位の一番目にすべきである。それは、学習以外のことにどんなに努力を費やしたとしても生産性の向上は限られているということだ。逆に言えば、生産性を改善することは何かしら学習の度合いを改善してきたことになる。
さて、プロセスについてふりかえるとき、より多くの価値を提供する方法を熟考し、私たちが働いている企業に、通常いくつかの価値を提供していることを忘れてはならない。その価値はもちろん動作するソフトウェアだけでなく、メンテナンス可能で変更可能なソフトウェアとそういった仕事を持続する反応が速いチームである。最初の2つの優先事項は企業から求められるべきである。しかし、3番目は、単にプロ意識への期待であり、通常は開発組織のコントロールの範囲内にある。この最後の形をした価値(チームのアジャイルさ)は、実のところ組織の資産であり、個々のプロジェクトを超えて生き続ける。そして、以降のプロジェクトでより大きな利益を生み出し、速度が増すきっかけとなる。
アジャイルチームは成長して効率的なチームワークを発揮するために、6ヵ月以上を一緒に過ごす比較的安定した生命体でなければならない。そのようなチームを構築するには戦略的な視点が必要である。そして、それは各イテレーションにおいて仕事としてやるべきこととともに考慮されなければならない。このバランスが維持されなければ、チームはすぐにその仕事で失敗することになる。なぜならプロセス中の問題は解決されず、予測できる開発速度や品質の支障となるからである。
脆弱で一貫しないチームをつくるのを避けるために、私たちがプロセスについて考えるとき、次の2種類の質問をするべきだ。
- 「これは、次のイテレーションで開発速度にどう影響するか？」
そして - 「これは、学習にどう影響するか？」(言い換えると、以降のすべてのイテレーションとプロジェクトおいて私たちの開発速度と反応の仕方に影響するか)
私たちは、学習が「チーム」という企業資産を強化することを理解すると、ステークホルダーに学習のプラクティスがもたらす利益について説明できるようになる。「はい、ペア・プログラミングは一見したところコストが高く付くように見えます。長期的に見たとき、それがどのようにリスクを相殺して、目に見えるコストを上回るかについて説明させてください...」アジャイルの短いサイクルで「長期間」というのはわずか3週間から6週間ほどであることをお忘れなく。
ここからどこへ行くか
この記事を書く1つの目的があった。それは学習に関する理論や構造を分析することではなかった。そうできるし、実際そういうものは沢山あった。しかし、どれも異なるアジャイルプラクティスを分類ないし評価していなかった。それらは単なる例であったり、私たちが学べばすでに多くの学習方法があることを思い起こさせたりするものであった。私たちの目的は、学習を心と行動の第一線に導くことであった。なぜなら、それがアジャイルプラクティスの成功の鍵であると信じるからだ。単に心の中で学習し続けないで、それを前面に出しなさい。この記事は、アジャイルなやり方が既に多くの学習のプラクティスやメカニズムを提供しているということを思い出させる立場に立っている。それらすべてはチームとビジネスに役立つように効果的に使われているだろうか？
「学習はボトルネックである」という眼鏡を通して世の中を見よう。そうすれば、儀式的なアジャイルプラクティスの出番を大いに減らし、最大の効果を得るために全力を注ぐことができるのである。
脚注
- チーム開発のForming-Storming-Norming-Performingモデルは、Bruce Tuckman氏によって最初に提案された。 http://en.wikipedia.org/wiki/Forming-storming-norming-performing
- この仮説の話と「学習はボトルネックである」という考えはValtech Skill Developmentのビジネスプランニングと戦略の統括責任者であるAshley Johnson氏から来ている。
- 初期のライトウエイトな方法論に共通する1つの歴史に関しては、Jim Highsmith氏(source)の http://www.agilemanifesto.org/history.html を参照のこと
- 初期のライトウエイトな方法論に共通するもう1つの歴史に関しては、Uncle Bob Martin氏(source)の http://blog.objectmentor.com/articles/2007/07/10/the-founding-of-the-agile-alliance を参照のこと
- アジャイルチームの「浸透する」コミュニケーション(source)については http://www.agilemodeling.com/essays/communication.htm を参照のこと
- 制約理論に精通している読者はこの議論をなじみがあると感じるだろう。非線形のプロセスを考えるときは、いろいろな意味で全体的に単純化される。
- See Appropriate Agile Metrics: Using Metrics and Diagnostics to Deliver Business Value, Deborah Hartmann and Robin Dymond, 2006 http://www.berteigconsulting.com/archives/2005/01/agile_work_reso.php 適切なアジャイルのメトリクスを参照(source)すること。http://www.berteigconsulting.com/archives/2005/01/agile_work_reso.php
- カーゴカルト: 第二次世界大戦中に、多くの空軍基地は、産業化されていない人が住む熱帯の離島に建てられた。戦争の間、兵士は飛行場と管制塔を建設して、積荷でいっぱいの大きな飛行機を着陸させて、積荷を降ろす様々な活動に従事した。地元の住人たちはこの積荷を分け合った。戦後、兵士たちが立ち去って、地元の住人たちにもう積荷はなかった。それで、彼らは積荷でいっぱいの飛行機を戻って来させようとして、表面的な形で滑走路と管制塔を作り、儀式的な振舞いをするようになった。カーゴカルトは実体の代わりに形式的なものを採用して、そうするのが望ましい結果を引き起こすと信じているグループです。
著者について
Amr Elssamadisy氏(source)はソフトウェアの専門家である。ソフトウェアの構築は非常に困難なことであり、Amr氏はソフトウェアを開発するより良い方法を見つけて、それをコミュニティと共有することに取り組んでいる。今日、アジャイルなソフトウェアのプラクティスをうまく取り入れることで、顧客がより良いソフトウェアを構築するのを手助けしている。将来は、私たちがソフトウェアを構築するより良い方法を学ぶにつれ、確実に何か違ったものになるだろう。Amr氏は『Patterns of Agile Practice Adoption: The Technical Cluster(参考記事・英語)』の著者であり、InfoQのAgile Communityの編集者である。
Deborah Hartmann氏(source)はバイリンガルのアジャイルの専門家である。トレーナー兼コーチ。トロントに本拠を置き、国際的に活躍している。Deborah氏は仕事を企業にとって価値あるものにすることとチームを楽しくすることに取り組んでいる。彼女はアジャイルを採用する大小の企業のコーチをしている。2006年4月よりInfoQのAgile Communityの第一編集者を務める。カナダと米国でXPとBarCampのコミュニティのためのOpenSpace会議をファシリテートした。
原文はこちらです：http://www.infoq.com/articles/learning_is_the_bottleneck