システムエンジニアを育てるプロジェクト編成


昨日、プロジェクトとしての個別最適化をしすぎるとシステムエンジニアが育たないなんてブログに書いたわけですが、じゃあどうしたらいいのよっていうのが今日の話です。



WBSを展開して工数を積んで山崩しすると上図になるので時期に必要なスキルを持っているメンバをアサインする、と。だから、いつも下流工程b仮担当している人は「上流工程ができる」か「上流工程をやらせてみよう」とアサインするマネージャやプロジェクトマネージャが思わないとその機会が永遠に来ない、なんてことになるわけです。


じゃあ「どうするのよ」と聞かれると「そーだなー」と考えるわけですが、単純な話で平準化する他ないんですね。ピークになっている山を削って水平に均す。



「いやいや、無理ムリ」と思うでしょ。ムリですね。何もプロジェクトのもろもろの環境を変えずにやるのはムリ。だって開発規模がこなせないもの。とは言え、今は「システムエンジニアが育たない」がテーマだからこのまま話を続けます。
#ゴリ押し


さて、この工数を均した場合はどうなのか、システムエンジニアは育つのか育たないのか、です。1番上の図のメンバからどこまでこの均した範囲に入るか。PMから2番目までが均したときのチームメンバになります。そのままPMから2番目までのメンバだとメンバの中で1番目と2番目のメンバは上流設計を経験していないので上流工程を経験できることになります。


ただ、山を均したので上流工程の凹んだところに入ってくるのは下流工程の作業です。上流工程の作業を1番目と2番目のメンバに切り出すということは、凹んだところに持ってきた下流工程の仕事を上流工程を担当するはずだったメンバが引き受けないと話がおかしくなります。


この工数を均して一定にしておくのってどこかで見たことがありませんか。


そう、維持管理なんですね。スキルが一部満たないメンバを育成するのには維持管理はメリットがある可能性がありそうです。じゃあといきなり突っ込んでいいのかどうかといえばそう簡単にいかないのが現実だったりしますが。


それは、そうそう維持管理で上流工程自体あるのか見極められていないとずっと下流工程だけで前と変わらない何てなってしまいます。維持管理でシステムエンジニアを育成しようと思ったときの課題は、


・追加機能開発などで上流工程が適当にあること
・アサインが恣意的にできること
・ローテーションが頻繁にできること
・技術的にシステムエンジニアの関心を惹きつけられること


あたりでしょうか。


維持管理で難しそうならどうしましょう。中小規模のプロジェクトでこの平準化したパターンでやるか、プロジェクトの当初メンバに育成したいシステムエンジニアを力量不足を承知の上でアサインすることになるでしょう。後者の場合は、育成とプロジェクトの2つの観点で通常よりインターバルの短いモニタリングと早いアクションが必要になりますけど。その覚悟とリソースの確保をできるなら。


中小規模でそんなリスクを取れないというなら複数のチームを作れる程度のプロジェクトの1つのチームの中でのアサインでそれをやるのでしょう。現実的にもそんな若くて経験の少ないメンバをサブリーダにしているチャレンジなケースもあるようだし。育成のつもりでアサインしているのかは知りませんが。


あと、もう1つの解をだすとすればそれがアジャイル開発なんじゃないでしょうか。理想としては固定のチームで、タスクは自分から手を挙げて、なので。