前回からちょっと時間が…
…空いてしまいましたが、この連載でも取り上げているIBM Rational Team Concert（以降RTC）とIBM Rational Method Composer（以降RMC）が、共に6月にバージョンアップし、ツール間の連携度合いが高まりました。実はこれを紹介したかったから、わざと間を空けていたのであって、決して目先の仕事に嵌まって原稿提出が遅れたわけではなく……（編集担当：「バシッ」）。
今回は、「開発プロセスを運営する」という観点でのお話しです。この話がしたかったから、わざわざ間を空けて……（編集担当：「ドスッ」）。
「開発プロセスを運営する」ということ
開発プロセスといえば標準化、これまで……いやいや、今でも、次のような進め方を目にするのではないでしょうか？
- 半年かそれ以上かけて開発現場の問題点を洗い出す
- 同時にCMMIやCOBIT、PMBOK、SWBOKと必要とおぼしき知識の習得に励む
- さらに半年かそれ以上かけて、標準となるべき手順、仕様書の書式の詳細を決める
かくして、着手してから1年半後から2年後くらいに、「これから10年使う開発標準や基盤環境」ができあがる……はずが、実際には現場の実態とかけ離れたルールブックができあがるという具合です。
ビジネスの変化に即応するスピード感やアジリティが強く求められる昨今、開発現場でのプロセスに対するアプローチも変わっていかねばなりません。
昨今のアジャイル開発の一般化を契機に、開発プロセスの定着と改善について、Rationalチームでは、次に紹介する3つのアプローチを提唱し、RTCとRMCとの連携によって、それを実現しようとしています。
プロセス運営の3つのアプローチ
1. 受動的アプローチ
まず最初に挙げるべきなのは、開発者の振るまいを「受動的」アプローチに変えたいという点です。
品質やコストに問題意識を持っているIT組織の多くが、（1）プロジェクト管理、（2）標準化を強化施策として挙げています。「より高品質＆より低コスト」を求めて、作業手順を詳細に定義し体系づけて、結果として水も漏らさぬ「百科事典」を作り上げるのです。
しかし、その手順にのって開発を進める方は地獄です。社内イントラネットやファイルサーバーで共有された標準規定書に準ずるための活動はすべて人に任されます。今着手しようとしている作業の詳細を手順書で探しだし、完了基準を達成しているかどうかを人が判断し、マスターソースの更新作業の条件を確認し……（少々大げさですが）あらゆる箇所でその手順を意識しなければなりません。
このように、これまでの開発プロセスの運営は、常に『適用される側がプロセスに準ずるために「能動的」に関わること』を求めてきました。
それに対して、「受動的」とは「必要があればツールがガイドしてくれる」という意味です。
具体的には、RTC単独あるいはRMCとの連携で次のようなサポートを実現しています。
- RMCで標準として定義された活動は、RTCのタスクとして登録される（図1）。開発者は、タスクの説明を見たければ社内イントラネットで公開されたプロセス定義の該当箇所を、RTCから直接参照することができる。このように必要なときに必要なガイドを最小限の手間で照会することができる
- 事前条件／事後条件を設定しツールに自動チェックさせる（図2）。例えば、ソース管理で共有領域を更新する場合には、「変更理由を明記するタスクが関連づけられていないと、ツールの側が更新を拒否」し、「その場合の対処法をガイド」してくれる
- タスクとソース（の変更部分）が常に関連づけられていることによって、CI時の各ビルドがどんなタスクの結果を反映しているのかの報告（ビルドレポートあるいはリリースレポート）を自動化してくれる
これまで「開発」という文脈で自動化というと、テストやコード生成の自動化が語られることが多いと思います。RTC＋RMCでは作業の流れやそれに関わる条件判定をツール側に任せることによって、「何か齟齬があったときに開発者に教えてくれる」受動化アプローチをとれるようにしているのです。
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回、次回はすぐに出ますよ、すぐに（だってもう書いてあるんだもん）。
