これ僕.com:行動分析学マニアがおくる行動戦略

意図と行動のギャップから生じる「不自由さ」への挑戦。果たして僕たちに自由はあるのか?

設計スキルがないプログラマのための設計書

ここでちょっと書いたけど、設計スキルを持っていないプログラマーのための設計書は、基本的に無駄だと思う。なのでを何とか削れないものだろうか、と思案。
あとで書く。かも。

外部設計から実際にプログラムが実装されて、テストを終えるまでの大雑把なステップは、

  1. 機能を検証するテスト項目を決める
  2. どんなモジュールに分解するか決める
  3. それぞれのモジュールが何をするか決める
  4. モジュール単体を検証するテスト項目を決める
  5. モジュールを実装する
  6. モジュール単体を検証する
  7. 複数のモジュールを結合させて、機能を検証する

かな、と思う。このうち、設計に該当するのが2〜3。ここをこなすスキルがないプログラマーに4〜6の作業をやってもらうために、設計スキルをもったエンジニアが、その設計の結果を詳細にドキュメントに記載するわけだ。場合によっては、5にかなり踏み込んで、プログラムを1ステップごと日本語にしたようなものまで作ったりする。
で、そのドキュメントを書かないようにしたいわけで。どうすればいいか。
自分なりの結論は「後ろのステップから徐々にやってもらう」だ。
設計スキルをもったプログラマーなら、多分2〜6を自力でこなせる(1、7は外部仕様に関する知識が必要)。で、見習いプログラマーにはこのステップの後ろからやってもらう。最初は5まで終えた段階でモジュールを渡して、単体テスト。それがこなせるようになったら、5〜6を。その次は4〜6を。という感じで、徐々に担当範囲を拡げていくようにする。TDDだったらテストコードだけ書いて、これが緑になるように実装してね〜、もありかな。
これで、どうだろうか。
ただ、ちょっと問題もあって、「見習いプログラマーの数 > 普通のプログラマーの数」だとマズイ。6しかやれない見習いプログラマが2人で、普通のプログラマーが1人って状況だと、モジュールを2人分、5の状態まで持っていくのに時間がかかって、待機時間が生まれてしまう。
だから、「見習いプログラマーの数 < 普通のプログラマーの数」ってのは絶対キープしたいライン。感覚だけど、普通のプログラマー2人につき、見習いプログラマー1人くらいがギリじゃなかろうか。2:1の割合なら、成果物のレビューや必要に応じてペアプログラミングすることも可能そう。2:1を割り込んじゃうと、チームの効率がガタ落ちになりそうな予感。
そうすると、プロジェクトへ見習いメンバーを参加させて良い割合ってのも見えてくるなぁ。
うん。2年前の自分にそっと耳打ちしたい。orz


次回予告かもしれないもの。