| « 2009年1月4日 | 2009年1月5日の投稿 |
2009年1月8日 » |
私の立場は「コーディングは設計（の一部）だ」(by Jack Reeves)である。ここでは、コーディング以前のラフな設計（例えばUMLのクラス図やシーケンス図レベルのアイディア、それがホワイトボードに描かれていようが、紙であろうが、JUDEであろうが、日本語であろうが）を、ここでは設計と呼ぼう。
設計とコーディングの距離が増えれば増えるほど、ムダが増える。私の主張は、できるだけ、１つの関連部分の設計とコーディングは、「一人の人」が「少しずつ」行ったほうがよい、ということだ。昔見た「詳細設計書」という細かい実装の詳細を日本語である人が書き、それを見て別の人がコードを書く、ということは避けたい。ここでの距離とは、
- 頭脳間距離。
- 時間的距離。
の２つ。
頭脳的距離は、物理的に書く人の頭脳の距離だ。1人の人が設計からコーディングまでを含めて担当すれば、この距離は0だ、別の頭脳が担当するならば同じ部屋にいた方がよい。また、そうでなければ、ブロードバンドなコミュニケーション手段がある方がよい。次に、時間的距離は、設計をしてからコーディングをするまでの時間の長さだ。最初に大きな設計をして、すごく時間がたってから実装する場合、時間的な距離が長い。でも、設計してすぐコーディングをする、あるいは行ったり来たりできれば、この距離は短い。これには、１つの設計単位（いわば、バッチサイズ）が小さいことが求められる。TDD(テスト駆動開発)は、私がこれまで経験した一番小さなバッチサイズだ。
この距離が短ければ、設計をラフにすることができる。ラフにすれば、実装時にやってみて分かった情報で設計を詳細化しながら進めることができる（決定を十分な情報が得られるまで遅らせられる）。この距離を長くとると、設計を詳細化する必要がある。その結果、出来上がった実装を二回繰り返すようなはめになるし、実装時にはじめてわかる詳細を無視した設計になるために無理な構造を作り出す。
この２つの距離を短くしよう。一筆書きで一気に全設計を書き上げて壁の向こうに投げようとせず、段階的詳細化を行う中で徐々に知識を得ながら自由度を狭めるような、漏斗型の設計とコミュニケーションが、もっとも効率的にリソースを使って、分かりやすく重複の少ないコードを生み出す。
さて、ここまでが理想の話。一人の人が全部できっこないし、ラフな設計だけで全員に意図を共有できるわけも無い。あなたの状況でできっこない。
どうしたらいい？考えよう。。。。
設計者が、常に同じ場所でコーディングに参加してもらうのはどうだろう？最初から全体を設計せず分割し、ちょっとずつ設計－実装して得た知識を次の設計に活かせないだろうか？デザインレビューを、実装者を交えてやったら、意図を伝えることのプラスにならないだろうか？ペアを組んで設計とコーディングを交互にやってみたらどうだろう？DSLをうまくつかって、ドメイン特化した開発環境をつくり、設計＝コーディングとなるような手法を作れないだろうか。
などなど。。。何か、設計とコーディングを結ぶ線を短くできないだろうか、と考えていこう。これは、アジャイルの宣伝ではなく、設計（デザイン）という活動を本質的なものにしたい、という技術的な思いだ。
| « 2009年1月4日 | 2009年1月5日の投稿 |
2009年1月8日 » |
顧客に“ワォ！”という体験を提供――ザッポスに学ぶ企業文化の確立
ちょっとした対話が成長を助ける――上司と部下が話すとき互いに学び合う
悩んだときの、自己啓発書の触れ方
考えるべきは得意なものは何かではなく、お客さまが高く評価するものは何か
なんて素敵にフェイスブック
部下を叱る2つのポイント
第6回 幸せの創造こそ、ビジネスの使命