プログラマーやめましたコンテンツへスキッププログラマーやめましたプログラマー業界の裏話。マネジメント論Tweet前回の記事では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は目を覆いたくなりますね。トラウマがよみがえります。スキル0.1は一体何なんでしょうね。国立競技場の建設ですか?・・・いや、やめましょう。僕もあまり人のこと言えません。グラフにするとこんな感じです。利益が出る方向への上がり幅はあまりありませんが、遅れが出る方向への落ち込み具合は凄いです。先ほどは平均で算出した為、均されましたが、こちらでは平均をとらず同じ能力を持つ人が同じ仕事をやった場合のバラつきについてみてみます。スキル0.3で検証モジュール数10、モジュール数に対し1.4倍~7.8倍のバラつき。モジュール数100、モジュール数に対し2.4倍~4.4倍のバラつき。モジュール数1500、モジュール数に対し3.06倍~3.56倍のバラつき。モジュール数が増えるに伴い、遅れ度合いに安定感が出てきます。期待したのですが、モジュール数1500では1度も奇跡は起きませんでした。1500回プロジェクトやっても、全て遅れます。スキル0.4で検証モジュール数が10の場合を除き、全て3倍以内におさまっています。見積以下とはなんと幸せなことか。モジュール数が小さいと運任せなところがあるようですね。規模も小さいのでダメージは局所的です。まとめ焦って設計がおざなりになるケースが良くあります。一応念を押しておきますが、「設計書書かずにプログラミング」では奇跡は起きません。設計に力を入れチームのプログラミング力を上げる必要があります。設計書を書いても、チームのプログラミング力が上がらなければ設計書の意味がありません。らしくまとめてみましたが、スキル0.4の人はおよそ2.5回に1回完成させるので、3倍の見積で利益を出すのは当たり前です。偉そうに語っていますが、1記事当たり5時間以上かけてこのブログ全体の収入は17円です。マネジメントについて語るのやめようかな。gauraと申します。確認なのですが、前提条件として、設計書があればどのエンジニアも1回の開発作業で完成させるということを置いているのでしょうか?というのも、この記事の議論では、設計書とスキルと完成確率の関係が明示されてないように思うのです。記事の初めの話を考えると、考えるべきポイントはそこだったような気がするんですね。あとこの記事、ちょっとがんばれば良い考えが浮かびそうな気がするんでがんばってください。AMgaura様、コメントありがとうございます。ニートとここの管理人をやっております、¥552(税込)と申します。頂いた質問にご回答いたします。>確認なのですが、前提条件として、設計書があればどのエンジニアも1回の開発作業で完成させるということを置いているのでしょうか?どんなエンジニアでも1回で成功させられるとはさすがに思えません。設計書を記述することでスキルのバラつきを平滑化できると考えています。「何とか、設計書を用いてチームのレベルを平均0.4のスキル(つまり2.5回に1回成功させられるレベルまで)持ち上げることができないものか。」というのが僕の想いです。>設計書とスキルと完成確率の関係ご指摘の通り関係は表すことができていません。いうのも、どのような設計書を書くかにより大きく変わります。1観点を示せればよいかなと思っています。具体的には「プログラミング工程の手戻りバラつきを抑えられるように設計書を書いてはどうですか?(2.5回に1回位の成功確率目指して)」と言えてれば良いかなと思っています。話は脱線しますが、「設計書なんて必要ない。俺は今までそうやってきた」タイプが上や下にいると厄介です。いう抽象的な言葉で揚げ足を取られ、焦って設計工程をおざなりにしてしまいます。いった方に設計の意義を、ほんの少しご提示できていれば幸いです。規模が大きくなると奇跡は起きないを示せたのは少し収穫かなと思っています。これからも色んな方面からマネジメントについて検討していきたいと思います。つたない文章にお時間頂きありがとうございます。コメントをキャンセルメールアドレスが公開されることはありません。プログラマーやめましたプログラマー業界の裏話。