アジャイルに行こう!

設計からコーディングまでの「距離」

»

私の立場は「コーディングは設計(の一部)だ」(by Jack Reeves)である。ここでは、コーディング以前のラフな設計(例えばUMLのクラス図やシーケンス図レベルのアイディア、それがホワイトボードに描かれていようが、紙であろうが、JUDEであろうが、日本語であろうが)を、ここでは設計と呼ぼう。

設計とコーディングの距離が増えれば増えるほど、ムダが増える。私の主張は、できるだけ、1つの関連部分の設計とコーディングは、「一人の人」が「少しずつ」行ったほうがよい、ということだ。昔見た「詳細設計書」という細かい実装の詳細を日本語である人が書き、それを見て別の人がコードを書く、ということは避けたい。ここでの距離とは、

  1. 頭脳間距離。
  2. 時間的距離。

の2つ。

頭脳的距離は、物理的に書く人の頭脳の距離だ。1人の人が設計からコーディングまでを含めて担当すれば、この距離は0だ、別の頭脳が担当するならば同じ部屋にいた方がよい。また、そうでなければ、ブロードバンドなコミュニケーション手段がある方がよい。次に、時間的距離は、設計をしてからコーディングをするまでの時間の長さだ。最初に大きな設計をして、すごく時間がたってから実装する場合、時間的な距離が長い。でも、設計してすぐコーディングをする、あるいは行ったり来たりできれば、この距離は短い。これには、1つの設計単位(いわば、バッチサイズ)が小さいことが求められる。TDD(テスト駆動開発)は、私がこれまで経験した一番小さなバッチサイズだ。

この距離が短ければ、設計をラフにすることができる。ラフにすれば、実装時にやってみて分かった情報で設計を詳細化しながら進めることができる(決定を十分な情報が得られるまで遅らせられる)。この距離を長くとると、設計を詳細化する必要がある。その結果、出来上がった実装を二回繰り返すようなはめになるし、実装時にはじめてわかる詳細を無視した設計になるために無理な構造を作り出す。

この2つの距離を短くしよう。一筆書きで一気に全設計を書き上げて壁の向こうに投げようとせず、段階的詳細化を行う中で徐々に知識を得ながら自由度を狭めるような、漏斗型の設計とコミュニケーションが、もっとも効率的にリソースを使って、分かりやすく重複の少ないコードを生み出す。

さて、ここまでが理想の話。一人の人が全部できっこないし、ラフな設計だけで全員に意図を共有できるわけも無い。あなたの状況でできっこない。

どうしたらいい?考えよう。。。。

設計者が、常に同じ場所でコーディングに参加してもらうのはどうだろう?最初から全体を設計せず分割し、ちょっとずつ設計-実装して得た知識を次の設計に活かせないだろうか?デザインレビューを、実装者を交えてやったら、意図を伝えることのプラスにならないだろうか?ペアを組んで設計とコーディングを交互にやってみたらどうだろう?DSLをうまくつかって、ドメイン特化した開発環境をつくり、設計=コーディングとなるような手法を作れないだろうか。

などなど。。。何か、設計とコーディングを結ぶ線を短くできないだろうか、と考えていこう。これは、アジャイルの宣伝ではなく、設計(デザイン)という活動を本質的なものにしたい、という技術的な思いだ。

Comment(4)

コメント

everpeace

静的なデータの構造については現在もほとんど設計とコーディングの距離は近くできると
思うのですが、やはり手続きだったり関数だったりという「処理」の部分の設計とコーディング
の距離が、僕は遠く感じています。

となると、やはり「関数を設計する」とは何か?ひいては「計算とはなにか?」を考える必要があると思います。関数型言語にみるような「関数と関数を繋いで関数を作る」という行為が重要になってくると考えます。

なので、HaskellのArrowsのように関数どおしを繋ぐ感覚で新しく関数を生み出せるような、関数をドメインとしたDSLっぽいものといってよいのでしょうか・・・、を注目しています。

Arrows: A General Interface of Computation
http://www.haskell.org/arrows/

また、DSL処理系をできるだけ簡単に生み出せる、パーサーコンビネータのような手法もこれからは注目されてくるのだと思います。

「設計」とは?「コーディング」とは?は定義が難しいのでなんとなく
平鍋さんのおっしゃる思いと繋がっているか不安なのが心苦しいですが・・・・

平鍋

プログラム、と一口にいっても様々なタイプがありますからね。組込みと企業システム(IPAではETとITなどと言ったりしますが)では違いますし、ゲーム、科学計算、OS、でも全然違う気がします。

確かに、アルゴリズムの部品化は、それを支援するプログラミング要素がまだまだ不足している感じがしています。この部分はぼくも良く知りませんが。。。

ひらりんたろう

思い切ってコメントします。私も「コーディングは設計(の一部)だ」と似たような立場です。

コーディングは、設計のコンピュータ向けの表現であり、設計書(UMLのクラス図など)は、設計の人間向けの表現だと考えています。要は、同じ設計(の情報量のはず)なのだけど、伝える相手が違うという考えです。

それが、コンピュータ=頭が固いけど正確、人間=頭が柔らかいけど曖昧、という本質的な違いによる設計の表現の距離感を生んでいるのではないでしょうか。

人間がコンピュータに近づく(表記法がコードと等価(より厳密)に)、コンピュータが人間に近づく(コードが人間の言語と等価(より曖昧=抽象化?動的?)に)、この2つの歩み寄りがこのミスマッチを解決してくれる方向かもしれない、と思いますが。。。もしかしてこの話、方向ずれてたらすみません。

平鍋

ひらりんたろうさん、
>それが、コンピュータ=頭が固いけど正確、人間=頭が柔らかいけど曖昧、という本質的な違いによる

その通りだと思います。歩み寄りについてですが、人間は数千年の文明の歴史をもち、一方、コンピュータは高々50年ですから、そのデザインなどは誤差の範囲です。歩み寄るのはコンピュータの方で、それを含んで人間の文明が変わっていくのだと考えています。ですので、歩み寄るのはコンピュータ。そして、それを歩み寄らせるのは、人間だと思っています。

コメントを投稿する