理系のプロジェクトリーダならば、方程式が頭の中でくみたてられ、何がいけないのかわかると思うが、なぜか、文系の話術の巧みな者が日本の場合リーダをやっているケースがほとんどなのである。
なので今一度、日本の文系のプロジェクトリーダにも方程式が伝われば、いくぶん世の中ましになるかと思い、この記事を書くことにする。
ここでいうプロジェクトの失敗とは、納期が決まっている場合がほとんどのプロジェクトにあてはまることから、ここでは単純に時間がかかることであるとする。
小学校で習う公式として以下のものがある。
距離 ＝ 速さ × 時間 ... (式➀)
プロジェクトでいう距離とは、開発ボリュームのようなものである。
つまりこの小学生で習った公式は、プロジェクト開発においては以下のようになる。
※「速さ」とは、ギリギリ成功する速さという意味であるとする
開発ボリューム(距離) = 速さ(ギリギリ間に合う) × 納期(時間) ... (式➀´)
では、速さとは何かを語っていこうとおもう。
高校で習う物理学の方程式として以下の方程式がある。
速さ＝波長 × 周波数 ... (式②)
プロジェクト開発において波長とは、機能数であり、
プロジェクト開発において周波数とは、１カ月に何個の機能を実装できるのかということである。
速さ(ギリギリ間に合う)＝ 機能数(波長) × 1カ月で作れる機能数(周波数) ... (式②´)
機能数は固定であることを前提とするならば、考える余地があるのは、1カ月で作れる機能数についてであろう
機能数は固定であることを前提とするならば、考える余地があるのは、1カ月で作れる機能数についてであろう。いよいよ自分が言いたいことの核心に近づいてきた。
高校で習う物理の周波数についての方程式に以下のものがある。
周波数＝1/周期 ... (式③)
これをプロジェクト開発にあてはめると、周期とは１機能を作るための時間である。
つまりは、以下の関係がある。
1カ月で作れる機能数(周波数) = 1 / １機能を作るための時間(周期) ... (式③´)
これがゼネコン形式だと、もろもろの良くないこ現場のルールが発生し、のびのびになるが、
多重請負形式になれば、なるほど悪化するということをいいたい。
ゼネコン式の開発とは、多重請負形式の、業務発注状態である。
これが、高校で習う物理学の方程式と何の関係があるのかを述べたいと思う。
１つの成果物が納品されるまでの、時間を波長う
IT開発では作業者の成果物に対してレビューがある。
つまり、以下の方程式がある
成果物の時間＝開発者の実装時間＋レビューのトータル時間 ... (式④)
１機能を作るための時間(周期)＝開発者の実装時間＋レビューのトータル時間 ... (式④)
多重請負の数をｎとすると、だと、
多重請負の数をｎとすると、だと、n階層ごとの足し算をΣで表現すると。
レビューのトータル時間 = Σ(多重請負数n × １請負階層ごとのレビュー時間) ... (式⑤)
となる。 レビューを対面レビュー限定とすると、スケジュールの調整などで週一とかになるわけだ。
となる。 発注元は、「お客様だから偉い」みたいな空気があり、忖度ルールが多数ある。
忖度開発ルールと命名するとして、以下のものを目撃した
・レビューは対面レビュー限定
・業務の説明はしないが、提案資料を作成
※まだあるが、おもいだしたら記入していく
さらに悪いことに中間業者は、業務の知識もなければ、開発経験もないという状況でレビューの仕事をしたことにするために、報告書のフォントのサイズや色など、機能に関係のないことを指摘して仕事をした気分になってしまっているのだ。
