エンジニアの兼務 - 室長のひとりごち

今のところ、IT業界は盛況でエンジニアが足りない状況らしい。確かに、案件の引き合いは多く、始めなければならないのにエンジニアを手当できなく非常に困っているプロジェクトもあると耳に入ってくる。

2020年で一旦踊り場になるのではないかと思うのだが。

そうした状況で見かけたり、聞いたりするのがエンジニアのプロジェクトの兼務である。

大分前に、コアになる適用技術をリードできるアーキテクトを確保することが必須条件のプロジェクトを担当したこととがあった。丁度、同じ頃のタイミングに別のプロジェクトが並行して立ち上がった。不幸なことに同じ適用技術を採用したのであった。

どちらのプロジェクトも必要とするエンジニアは同じ自分になった。

さて、何が起きたか。

当然、エンジニアのリソースの奪い合いになるのである。自分ももう1つのプロジェクトのプロマネも笑顔でリソースの奪い合いを工数の按分、スケジュールのマイルストーンを盾に双方のためにプロジェクト最適化を図ろうとするのである。

もちろん、適用技術を持つエンジニアに対するリソースが合わせて１人月であれば、理屈としては按分でき、互いのプロジェクトは単にスケジュールを調整すればいい。

ただ、現実の世界ではそうはいかない。

そんな机上で考えたようにはいかない。

想定したより技術レベルが高いタスクになった、エンジニアが引いたスケジュールの見積もりが甘かった、などが起きる。

それも必ず起きる。

そうすると先に作業していた方に引っ張られるのである。割りを食うのはスケジュール上、後になっていたプロジェクト側である。何事も占有している方が強い。

では、なぜ複数のプロジェクトにエンジニアを兼務させると上手くいかなくなるのか。

それは、同時に二人必要な要求に対して兼務では問題を解決できないからである。

さらに、副作用として兼務は品質上のトラブルを引き起こすリスクを孕む。兼務のエンジニアはプロジェクトルームを行き来するたびに思考のスイッチを変える必要が出てくる。別のプロジェクトに行っていて戻ってきたら頭を切り替えなければならない。

さらに不在中にもプロジェクトは進んでいるから、スイッチを入れ直してログを追いかけるようとしても把握しきれないのである。

把握に余計な時間を取られるのは、通常、作業見積もりに考慮されていない。把握もしきれないから割り切りで走ってしまい、結果、不具合を引き起こす。

適用技術や難易度の高いコードを任せていると、根幹のところで不良が出るのである。

エンジニアの兼務はリスクである。重々、ご覚悟されたい。