人数が増えても工数は減らない
よほどの単純作業でもない限り、ほぼすべての仕事はそうだろうと思える。
能力差があるから、人数比というわけにはいかない。戦国時代の戦と同じ、武器や戦術が高度化するにつれて難しくなる。
人数増の効果をだしたいなら、基本は、ピラミッドの下を増やすことでしょう。しかし、「慣れる」という初期コストも必要だし、教育まで必要になる。当たり前ですね。
忙しい時はなかなか手ほどきも難しいからPC環境設定すら二日ぐらいかかることもある。最近はさすがにPC設定ごときで、ということで、バッチファイルで済むようにはなった。時間がある時に工夫しておく、というのはものすごく大事。
プロジェクトで忙しいと結束力が変に高まってるから、「部外者お断り」マインドになってしまうこともある。
増やさないとうまくいかない
しかし、「人を増やしてもうまくいかない」かもしれないが、「増やさないとさらにうまくいかない」と考えた方がいいだろう。
ソフトウェア開発で荒れるのは大体プロジェクト終盤だが、この時期は「情報整理するのがうまい」「交渉力がある」人をいれると改善するケースも多い。
「優先順位」を明確にして、リリース日程を組みなおす、とかだ。
「間に合うものは全部いれる」スタンスではいつまでたっても火の車だ。
評価部門がある世界なら、評価との調整次第で、日程を稼ぎ出すこともある。
機能によっては量産中に切り替える、という判断をすることもできるだろう。
交渉事は最後は人間の世界だから、交渉がうまい人によっては、「着眼点」を変えることでうまくいく例が多い。
交渉をしないまま、「約束は守る」的なスタンスを取り続けても疲弊していくし、「約束も守れない」可能性が高い。
何よりも「品質」の危うさがつきまとう。
再現性を重視する
こういう仕事の進め方は、うまくいったとしてもイリーガルなことだけに属人化しやすい。
データ取り、ルール化、ノウハウ化できる組織は強い。
「振り返り会」とか「反省会」とか「報告会」みたいなものがよくあるが、
ともすれば「強いチームだからできた」という「武勇伝」みたいな言い方になるとノウハウ化しづらい。
また、「役に立つことしかいうんじゃない」というマインドが強すぎると「いい話」ばかりいう傾向もある。
「失敗談から学ぶ」ことを前向きにとらえる風土も必要。
最近読んだ本で「コンサルティング会社 サバイバルマニュアル」もそういうニュアンスを感じた。
面白く読ませて頂いた。
コンサルタントの人間力、突破力の高さには感心した。
一方で、プログラムは「工業製品」と私は思うからこのやり方は「再現性」がなく、客観的には失敗プロジェクトと感じた。
一歩引いてみると、頑張っている割にはレベルが低く見えてくる。評価が分かれるところだろう。
燃えてるプロジェクトほど、客観視も含めて、冷静な第三者が入る意味はある。現状のやり方を変える、という意味合いだけでなく、「再現性を観測する」という意味だけでも投入する価値があると思う。
