| « 2005年8月22日 | 2005年8月23日の投稿 |
2005年8月25日 » |
前回、「EoM(保守容易性)が良い設計の基準だ、そして、EoM＝EoT+EoCだ」という議論を書いた。ここまでの議論は、ソフトウェアの設計についてのものであり、開発の「プロセス」（あるいはプラクティス）とは無関係に進めてきた。ここで、１つの経験則を使って、プロセスの方（鏡の反対側）を見てみたい。その経験則とは、
コーンウェイの法則：
ソフトウェアの構造は開発チームの構造に一致する。コンパイラを４チーム編成で作れば、４パスコンパイラになる
である。（※この法則は、ソフトウェアとチームの「構造」（organization）について述べたものだが、ここでは、プロセスについて拡大解釈する）
この法則を使うと、３つの設計品質についての方針は、そのまま、プロセスについての方針にミラーコピーできる。
- EoTの高いプロセスが、良いプロセス。
- EoCの高いプロセスが、良いプロセス。
- EoMの高いプロセスが、良いプロセス。EoM＝EoT＋EoC
EoTに関するプロセスの命題は、テストというより、「テスティング」という活動が、プロセスの中で最も重要な位置を占めることになることを宣言している。これには、例えばテストの回帰・自動化、テストによるシステムの動くドキュメンテーション、テストによる複数モジュールのインターフェイス合意（Strata）、テストによる進捗管理（バーンダウンチャート）、品質保証部門の関わり方、テスト戦略から始めるアーキテクチャ設計、などが含まれるだろう。
EoCに関するプロセスの命題は、反復型の開発、顧客との頻繁な会話、イテレーション計画、リファクタリング期間の設置（技術的負債の短期返済）、などが含まれるだろう。
そして、これらが目指すのは、やはり、EoM（保守容易性）なのだ。プロセスには、保守のためのドキュメンテーション方針、要員交代の場合の教育、フェイストゥフェイスでのナレッジ共有や引き継ぎ（例えばペアプログラミング）、「見える化」、情報のコードの共同所有などによるリスク分散（ハネムーンナンバー(*1)を１にしない）。そして、職場での燃え尽き（デスマーチ）を防ぐこと、などが含まれる。
EoMをベースにしたプロセスのポイントは、多くがアジャイル開発からヒントが得られる。しかし、これはたまたま、ぼくがアジャイル開発ムーブメントに身をおいているからだと思う。例えば、CMMの視点からも、EoMをベースにしたプロセスが設計できると思う。
ここで言いたかったのは、設計だけでなく、プロセスもまた、EoMを基準に考えることが、現在の開発においてはより重要性が増している、ということだ。
このアイディア（コンウェイの法則による、設計とプロセスの双対関係）は、2001年に平澤章さんと「オブジェクト指向シンポジウム」において、「RUP&XPオブジェクト指向開発プロセスの新構図」（まだ、PDFが、ここに残ってましたhttp://www.objectclub.jp/community/XP-jp/xp_relate/pdf/rup_xp.pdf)というセッションをやっているときに降臨したものでうす。RUPは「分割」を好む。XPは「共同」を好む。これは、ソフトウェア設計における「凝集度」と「結合度」の議論と似ており、XPチームはとても凝集度が高いシステムを作る傾向にあり、RUPはチームは結合度の低いシステムを作る傾向があるのではないか？という仮説です。
ハネムーンナンバー(*1)： チームメンバーが急に結婚が決まって、１週間ハネムーン旅行に行くことができるか。何人まで、急に抜けられるか、というメトリクス。チームのナレッジ共有度を示す。この人しかできない、という仕事があると、ハネムーンナンバーは１になる。
| « 2005年8月22日 | 2005年8月23日の投稿 |
2005年8月25日 » |
顧客に“ワォ！”という体験を提供――ザッポスに学ぶ企業文化の確立
ちょっとした対話が成長を助ける――上司と部下が話すとき互いに学び合う
悩んだときの、自己啓発書の触れ方
考えるべきは得意なものは何かではなく、お客さまが高く評価するものは何か
なんて素敵にフェイスブック
部下を叱る2つのポイント
第6回 幸せの創造こそ、ビジネスの使命