前回の記事ではTOC(「ザ・ゴール」で紹介されている理論)を元に、ボトルネックがプログラマーであるとお伝えしました。
その中でもプログラミング工程がボトルネックであるとしました。
では、「設計書を書かずにプログラミングすべき」ということでしょうか。
いくつかの視点で検証してみたいと思います。
検証の前提条件
10タイプのスキル別に検証します。
10のスキルタイプ
スキル(0.1):ド新人
スキル(0.2):中小企業ではちょっとどうかなってタイプ
スキル(0.3):中小企業では普通にできる中堅どころ
スキル(0.4):中小企業ではかなりできる上級者
スキル(0.5):中小企業にはほぼいない、いたら引っ張りだこ
スキル(0.6～1):マイクロソフトとかGoogleとかにいるんでしょうか
()内の数値は、「1度の作業でモジュールが完成する確率」を表しています。
0.1であれば10回に1回しか完成させられません。
1は100%完成します。
検証方法
スキル別にモジュールが完成するまでの回数を記録します。
例えばこんな感じ
1モジュール目（結果：3回）
1回目:失敗
2回目:失敗
3回目:成功
2モジュール目(結果：1回)
1回目:成功
：
以降も同じように検証し、モジュール数に達するまで繰り返します。
成功と失敗は乱数を使用しています。
スキルと完成までの回数の検証
ちなみに100回実施した平均値です。
実際やってみて気付いたのですが
10回に1回しか成功させられない人は、完成するまでにおよそ10倍かかります。
5回に1回しか成功させられない人は、完成するまでにおよそ5倍かかります。
当たり前です。
マクロ組んでまで何をやっているのか。
グラフにするとこんな感じです。
見積に対する遅れで検証
見積条件
※単価やリスクは企業によるかと思います。
単価は65万円～140万円位が多いのではないでしょうか。
ちなみに、300万円というところもあります。
いわゆる超有名企業です。
結果と考察
見積は正味時間の3倍とっていますが、平均である0.3の人でも遅れてます。
しかし、9.375人月の仕事を平均的なメンバーがやって、1ヵ月程度の遅れなら御の字です。
残業すれば納期に間に合い、原価率60%なので利益も出ます。
スキル0.2は目を覆いたくなりますね。125日遅れ。
トラウマがよみがえります。おぇ。
スキル0.1は一体何なんでしょうね。435日遅れ。
国立競技場の建設ですか？
・・・いや、やめましょう。
僕もあまり人のこと言えません。
とりあえずグラフにするとこんな感じです。
利益が出る方向への上がり幅はあまりありませんが、遅れが出る方向への落ち込み具合は凄いです。
同能力のスキルで完成までの回数を検証
先ほどは平均で算出した為、均されましたが、
こちらでは平均をとらず同じ能力を持つ人が同じ仕事をやった場合のバラつきについてみてみます。
スキル0.3で検証
モジュール数10、モジュール数に対し1.4倍～7.8倍のバラつき。
モジュール数100、モジュール数に対し2.4倍～4.4倍のバラつき。
モジュール数1500、モジュール数に対し3.06倍～3.56倍のバラつき。
モジュール数が増えるに伴い、遅れ度合いに安定感が出てきます。
ちょっと期待したのですが、モジュール数1500では1度も奇跡は起きませんでした。
1500回プロジェクトやっても、全て遅れます。
スキル0.4で検証
モジュール数が10の場合を除き、全て3倍以内におさまっています。
見積以下とはなんと幸せなことか。
モジュール数が小さいと運任せなところがあるようですね。
しかし、規模も小さいのでダメージは局所的です。
まとめ
焦って設計がおざなりになるケースが良くあります。
一応念を押しておきますが、「設計書書かずにプログラミング」では奇跡は起きません。
そのため設計に力を入れチームのプログラミング力を上げる必要があります。
しかし設計書を書いても、チームのプログラミング力が上がらなければ設計書の意味がありません。
スキルが低い人のばらつきが怖くそれを最小にすることが設計の役割と考える方が良さそうです。
おわり
コメントを残す