スキル差を考慮した『見積工数』と『手戻り回数』の実験【結論:ばらつき】

前回の記事では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倍以内におさまっています。
見積以下とはなんと幸せなことか。

モジュール数が小さいと運任せなところがあるようですね。
しかし、規模も小さいのでダメージは局所的です。

まとめ

焦って設計がおざなりになるケースが良くあります。
一応念を押しておきますが、「設計書書かずにプログラミング」では奇跡は起きません。

そのため設計に力を入れチームのプログラミング力を上げる必要があります。
しかし設計書を書いても、チームのプログラミング力が上がらなければ設計書の意味がありません。

スキルが低い人のばらつきが怖くそれを最小にすることが設計の役割と考える方が良さそうです。

おわり

PR

コメント

“スキル差を考慮した『見積工数』と『手戻り回数』の実験【結論:ばらつき】” への2件のフィードバック

  1. gauraのアバター
    gaura

    はじめまして。gauraと申します。

    確認なのですが、前提条件として、設計書があればどのエンジニアも1回の開発作業で完成させるということを置いているのでしょうか?

    というのも、この記事の議論では、設計書とスキルと完成確率の関係が明示されてないように思うのです。
    そして記事の初めの話を考えると、考えるべきポイントはそこだったような気がするんですね。

    あとこの記事、ちょっとがんばれば良い考えが浮かびそうな気がするんでがんばってください。応援します。

    1. ¥552(税込)のアバター

      gaura様、コメントありがとうございます。
      ニートとここの管理人をやっております、¥552(税込)と申します。
      頂いた質問にご回答いたします。

      >確認なのですが、前提条件として、設計書があればどのエンジニアも1回の開発作業で完成させるということを置いているのでしょうか?

      どんなエンジニアでも1回で成功させられるとはさすがに思えません。
      しかしながら設計書を記述することでスキルのバラつきを平滑化できると考えています。
      「何とか、設計書を用いてチームのレベルを平均0.4のスキル(つまり2.5回に1回成功させられるレベルまで)持ち上げることができないものか。」というのが僕の想いです。

      >設計書とスキルと完成確率の関係

      ご指摘の通り関係は表すことができていません。
      というのも、どのような設計書を書くかにより大きく変わります。
      ですのでせめて、1観点を示せればよいかなと思っています。

      具体的には
      「プログラミング工程の手戻りバラつきを抑えられるように設計書を書いてはどうですか?(2.5回に1回位の成功確率目指して)」
      と言えてれば良いかなと思っています。当たり前ですけど。

      少し話は脱線しますが、「設計書なんて必要ない。俺は今までそうやってきた」タイプが上や下にいると厄介です。
      設計書を書くにあたり上から下から「方針・観点・粒度」という抽象的な言葉で揚げ足を取られ、焦って設計工程をおざなりにしてしまいます。
      そういった方に設計の意義を、ほんの少しご提示できていれば幸いです。
      規模が大きくなると奇跡は起きない
      を示せたのは少し収穫かなと思っています。

      これからも色んな方面からマネジメントについて検討していきたいと思います。
      つたない文章にお時間頂きありがとうございます。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です