プロジェクトとしての個別最適化をしすぎるとシステムエンジニアが育たない

on


昨日のブログでは「#システムエンジニアが育たない」としてツイートをまとめんですが、これって

「プロジェクトへのアサイン方法が間違ってるからじゃないの」


と思ったんですがどうでしょう。どうでしょうって聞かれても何が間違っているかわからないから「はっ、何が」ですよね。


まだまだ９０％以上は占めているだろうウォーターフォールの開発ライフサイクルを図示してみてみました。縦軸が規模、横軸が時間とします。１が所謂上流工程、２がみんな大好き詳細設計がある下流工程、３がテスト工程です。



図１プロジェクト開発ライフサイクル


これにアサインされるシステムエンジニアのヘッドカウントを入れてみましょう。



図２プロジェクトへの参加離脱


縦軸の規模＝システムエンジニアの人数としたとき、X軸は人数ですから時間軸の進行でプロジェクトメンバのプロジェクトへの参加離脱が生じることになります。例えば、３の人は下流工程からプロジェクトへ参画することになり、テスト工程の途中で離脱することになります。


これを見て何を思うか、です。


プロジェクトへのアサインは、プロジェクトが要求するスキルセットとレベルを充足するようにプロジェクトメンバを集めます。でなければ、プロジェクトの目的を達成できないからです。


これは明確にプロジェクトとしての個別最適化を示しています。このプロジェクトとしての個別最適化とはロールの固定を暗に含みます。だって、必要な「スキルとレベル」を持っているシステムエンジニアを調達するのですから。


これはプロジェクトメンバのアサインを恣意的にしなければシステムエンジニアの習得技術がロールを介した経験として更新されないことを意味します。


みなさん自身、プロジェクトでロールがここ数年ずっと一緒、変わらない、何てことありませんか。上手にロールをローテーションして新しい経験ができているでしょうか。もしくは自分で経験するテーマを設けられていますか。


この、プロジェクトでメンバのアサインを育成を念頭にロールを変えていく、経験を恣意的に積ませるアサインをしていくことをしなければシステムエンジニアが育つわけがないのです。