フリーエンジニアが生産性を考えるときの落とし穴

目的との適合性

生産性を高めるためと称して導入したツールや手法が、時として全く機能しないことがあります。そのような場合にはよくよく検証すれば、開発の目的と合致しないものを選択している場合が少なくありません。このように現場のエンジニアにとって「生産性を高める」ツールや手法というものは、その開発目的や開発現場と無関係に評価出来るものではありません。単純に開発速度を上げさえすればよい場合もあれば、品質の高さをシビアに求められる場合もあるのです。その意味では、現場を知らない者が有無を言わさず、具体的な使用言語やフレームワークの指示をトップダウンで与えるなどといったことをすれば、偶々最適な選択であった場合を除いて生産性を上げることは期待薄といえるでしょう。これでは現場の士気も上がらないかもしれません。

見えないコスト

また開発現場に立つエンジニアにとって、その開発がこれまでに実装経験のない新たな挑戦であるといった場合には、そのスキルや知識を上手く活用するまでにある程度の時間を掛ける必要があるでしょう。あるいはそうでなくても、関わる人が増えれば増えるほど、内部情報の共有や相互の調整に手間取るということがあります。そのため例えば単純に時間を短縮しようとエンジニアの人数を増やしても、チーム内相互のレベルや経験の違いなどから、思うように効果を得られない場合もあるのです。またシステムはエンジニアが開発して完成品を納入してそれで終わりではありません。そのシステムが無事運用されて、ビジネス上期待される効果を上げてこそ意味があるのです。そのためメンテナンス面も含めて導入後のフィードバックを適宜受けながら、クライアントにとって生産性が本当に上がっていることを確認することも大切でしょう。今ではクライアントも随分賢くなってきましたが、IT投資がどんぶり勘定で行われていた時期には、不相応に高価で機能水準の高いシステムが導入されながら、エンドユーザーにとって使い勝手が悪かったり、不必要な部分も多く、また後から後から機能を継ぎ足して重複したり無駄が増えてしまい、結果的に費用対効果を含めて考えれば、生産性を上げたとは言い難いものも少なくなかったのです。