プロセスを変えないで生産性を上げることを策略するのは精神論でしかない

ほら、良くあるじゃないですか。見積もったら見積もり規模とヘッドカウントが合わないから「生産性向上策をするとして。」っていう光景に遭遇して目が点になったり、対策案の策に「○○さんを投入して」って書いてあったり。


生産性を向上させるための方策=モノづくりの仕組みを変えないで生産性を上げるには、それ=成果物を生むエンジニアをスケールアウトする他ないです。その策もスケールアウトするエンジニア全員が相当出来て“コミュ力もある”エンジニアでないとエンジニアが増えるのでコミュニケーションのオーバーヘッドが増えるからコミュニケーションのやり取りの摩擦で生じるロスが無視できなかったりするんだけど、そんなこと=摩擦係数はゼロと見做すのか、握りつぶすのか、思いもよらないみたいだ。


生産性がそれまでと比較して向上するには、イノベーションを起こすか、ムダなものを省くかしかない。エンジニアを投入して生産される成果物が増えるのは、単なる母数の増加による生産量の増加であって、“生産する性能”が向上したわけではない。


残業や休日出勤でも生産性は向上しない。生産に費やす時間というコストを相応に投入しているのだから。厳密に言えば、稼働時間を高めれば機械だって疲労や負荷による故障を早めるように、エンジニアであっても疲労による集中力の低下が品質の低下を招くし、体力的にも精神的にもまいってしまうエンジニアがいても不思議ではないし、実際、入れ替わりに戦線を離脱し始めるものです。


生産性を上げるために、普段何も考えもしていない人たちがイノベーションを起こすのはそれこそ神業だとしか思えない。それより、モノづくりを根本から見直すことをした方が良いんです。それこそ、普段それをやることが当たり前、としてやっていることを「それ、成果物に直結しているんだっけ?」って疑うんです。


その手順、その設計書のドキュメント、必要なんだっけ。なくなったら、どの工程に「インパクトを与えるんだっけ?」って。


あと、同じデータを再投入している手順がないか、とかも。もしあれば、作業の手順がどこかでムダを生んでいるのかもしれないんですから。


エンジニアをスケールアウトすればするほど、エンジニアのスキルの観点での品質にばらつきが出るのは採用レベルの評価基準の軸がはっきりしていないか存在していないからです。これもしっかりした評価基準がないとプロジェクトの生産性は“低い方”に引っ張られるんです。TOCで言う、ボトルネックに引っ張られるんです。


生産性を向上したくても方策する自分自身にイノベーションを起こす才能がなければ、プロセスを見直すこと。そして、採用はたとえ計画のヘッドカウントが揃わなくても評価基準を必要なスキルレベルより下げないこと、です。


で、なければ精神論でしかないのでそのプロジェクトは負けることが想定されない“捷号作戦”でしかありません。
#轟沈。


失敗の本質―日本軍の組織論的研究 (中公文庫)
戸部 良一 寺本 義也 鎌田 伸一 杉之尾 孝生 村井 友秀 野中 郁次郎
中央公論社
売り上げランキング: 277


Kindle

失敗の本質
失敗の本質
posted with amazlet at 13.10.15
ダイヤモンド社 (2013-08-02)
売り上げランキング: 236