2. 結果ベースのアプローチ
詳細な手順を決めたいと願う人達の発想の根底にあるのは、つまるところ「過去の成功体験をコピーする」という発想です。同じ手順を確実に踏んでいけば、一定の成果は実現できるという期待が、この「コピー化」に拍車をかけます。
しかし、所詮他人は他人、「今開発に携わっている人達」と「その時点で採用する技術やビジネス的背景」を基準に物事を考えなければ意味がない……これがアジャイルの根本です。アジャイラーは、詳細な手順よりもその意義を説くプラクティスを重視します。
面白いのは、実際にアジャイルをやっている人達から、「なんのためにそのプラクティスをやっているのか」「効果がなにか」かが実はよく分からないという言葉を聞くことが少なからずあることです。彼らの関心が、技術の「新規性」により強く向いているのかもしれません。よくよく話しを聞いてみると、いわゆる「チェックリスト・アジャイル」（どのプラクティスを実施しているかに焦点が当たっていて、その効果や結果がなおざりになっているアジャイル）になっています。
開発プロセスが形骸化する原因の一つは、その意味や効果が意識されず（あるいは忘れられて）無味乾燥な作業の羅列になってしまうことです。定義の細かさに差はあれど、この点についてはアジャイルか否かは関係ありません。
IBM Rationalでは、この「結果・目的」とその「実現手段の関係性」に関する概念モデルを定義しています（図3）。この概念モデルは3つの層からなります。
- 「経営層としてのゴール設定」を表現するビジネス目標（Business Objectives）
- ビジネス目標の実現としての「IT部門のゴール設定」である運用目標（Operational Objectives）
- 運用目標の実現としての「プラクティス/プロセスの期待効果」であるプロセス/プラクティス構成（Practice Configuration）
この概念モデルに則って、典型的な価値とそれを実現するプラクティスおよびその効果測定用のメトリクスとを体系づけたのが、価値トレーサビリティツリー（Value Traceability Tree：VTT）です（図4）。これら概念モデルとVTTは、ツールの機能というよりも、より効果的なプロセスやプラクティスの選択および運営を支える理論的背景の意味合いが強いと言えます。
なによりも重要なのは、（プラクティスでさえ）無味乾燥な段取りとなりかねない「標準化」に対して、常に「価値」や「効果」について開発チームの意識合わせをし、実現へのモチベーションを維持する助けとなるという点です。
もちろんこれらの定義に則って、RTCやRational Insightというツールでは各種のメトリクスを取ることができるのですが、このあたりの「見える化」関連のお話は、次回のお題としておきます。
3. Waveアプローチ
プロセス改善という意味でアジャイルのアプローチが新鮮だったのは、プロセスを最適化するのは開発チーム自身である、という考え方でした。その意味では標準化チームの役割は、従来「主導する」人達であったものが「サポートする」という役割に変わるべきなのでしょう。
しかし、その一方で、チーム主導だけでは決めきれない規定というものもあります。それなりの規模のシステム開発では、開発チームが国境をまたがって開発するが故に、「輸出入管理」や「安全保障」関連の規定に抵触するようなケースが見られます。「効率」「品質」「イノベーション」はもちろん大事ですが、ビジネスとして成立させるために守らねばならぬことも多々ある、ということです。
このような状況下でイメージしている改善の進め方が、表題のWave（つまり波）です。
前述したように、あるビジネス領域では（多くはコンプライアンスの観点から）守るべき規範が存在し、それに合わせる形で標準的なプロセスが決められます。これを定義するのは標準化チームの主要な仕事の一つとなるでしょう。
これに加えてプロジェクトでの適用が始まると、以下の活動が見られます。
- 開発チームは振り返りの中でプロセスの改善点を見出し、プラクティスの取捨選択も含めて、自身のプロセスを修正する
- 標準化チームはサポーターとしてチームのプロセス改善を支援する。場合によっては改善案を提案する
- 標準化チームは、あるチームで改善されたプロセス要素で共通的な高い効果が期待できるモノを標準プロセスに取り込むと共に、他チームにも紹介することで、知識の共有を促進するハブとなる
ここではプロセス改善を主導「する」「される」ではない、「共同作業」の関係性が発生します。改善のサイクルも「振り返り」が1つの機会となるので、従来に比べれば短期間で改善施策が次々と打たれます。また、標準化チームがハブとなって、良い結果をもたらす改善施策が、他チームへとどんどん拡がっていく……この次々と施策が拡がっていく様子を、「波」に見立てているのです（図5）。
RTCとRMCの連携は、このWave型のプロセス定義・運営・改善のサイクルを次のようにサポートすることができます。
- 標準規定としてRMCで定義されたプロセス定義を、RTCのプロセス・テンプレートとして利用することができます。プロジェクトでのRTC利用開始時にテンプレート利用することで、必要なプロセス規定を短時間で定義することができます
- RTCでは、標準規定に加えてチームの振り返りを反映したプロセスのカスタマイズを施すことができます。一群のタスクを追加定義し、その効果が他チームでも有効性が期待できる場合には、一部のタスクグループをテンプレート化して、他チームへ流通させることができます
- 同じプロセステンプレートを適用したプロジェクトが複数あっても、『（1）「受動的」アプローチ』でご紹介した、事前条件・事後条件などのコントロールはプロジェクトごとにカスタマイズすることができます。自社のエンジニアだけで開発する場合とマルチベンダーでの共同開発と比較した場合、運営ルールは異なることが普通です。そのようなバリエーションにも対応することができます
まとめ：整理体系化することは「非アジャイル的」か？
「手順化する」や「標準化する」というフレーズを耳にすると、アジャイラーからの反発を喰らうこともめずらしくありません。現実を無視した重厚長大なプロセスに対するアンチテーゼとして「人を重視する」アジャイルが産まれたきたという出自を考えれば、この反発は理解できます。
その一方で、あまりに「人に頼り過ぎるリスク」も、存在します。さまざまな国籍・文化的技術的背景を持つ人達が共同作業をする上では、何らかの進め方の規範なくしてチームを運営することは、不可能とは言わないまでもかなり難しいのではないでしょうか？ 前述した国境をまたがった法的な課題に至っては、「そもそものアジャイルとは？」云々とはまったく別次元の話として、考慮せざるを得ません。
つまるところ、整理体系化することそのものが悪なのではなく、目的や価値という観点を失わずに持ち続けることができるか？ その観点に従って自分達でコントロールできる自由度を持つことができるか？ が、本当のポイントであるような気がします。
だとすると、結果や効果を共有することそれ自体が、チームの自由度の高さを保証する「保険」のようなものなのではないでしょうか？ ……ということで、次回はメトリクス絡みの話へと進んでいきましょう。
残すところ後1回、次回はすぐに出ますよ、すぐに（だってもう書いてあるんだもん）。
