エンジニアは気軽に生産性を上げます、なんて言わない方が良い

生産性はいつ出てくるもの？
プロジェクトの見積もりでしばしば問題になるのが生産性だ。生産性とは特定のリソースを投入したときにアウトプットする出来高の効率である。ITプロジェクトならエンジニアが単位あたりにどれだけアウトプットするかということである。

生産性の対象になるもの
見積もりでのアウトプットは、ほぼソースコードのみに焦点が当てられもう一つのアウトプットであるドキュメントまで視野が及ぶことは稀だろう。そして、deliverableとしてカウントしない付帯作業やファシリテーションは全く考慮されない。

生産性を左右するパラメータ
エンジニアの技術力、適用するプログラミング言語などにより生産性が左右される。プログラミング能力が高いエンジニアのみでプロジェクトチームが編成できるなら平均的なプログラミング能力のエンジニアのプロジェクトチームより単位期間あたりにアウトプットされるソースコードは多くなる。

適用するプログラミング言語が機械語に近いか、所謂、人に理解しやすい高級言語かによりアウトプットされるソースコード量はプログラミング言語で出力されやすさで左右される。

開発環境も生産性を左右する。今時どのくらい残っているかわからないけれど、−実際、最近はさすがに聞かなくなったがJavaのコードを書くのにフレームワークを使わないこともある−、直書きすることもあるだろうし、フレームワークを使った場合とその差はあるものだ。

これらのパラメータでアウトプットされるソースコードは左右される。

俺たちの生産性ってどのくらい？
正直、どのくらいの組織で生産性をメトリクスとして収集しているのだろうか。メトリクスとして収集するアウトプットのプロジェクトの特性まで掌握しているのだろうか。

順調に終わったプロジェクトもあるだろうし、デスマのプロジェクトもあっただろう。デスマなら長時間労働が前提となるから特定期間でのアウトプット量は増えるのである。

先の生産性を左右するパラメータはどこまで考慮されるのか。

同じ組織だとしても、部門が違えば家風は違うのである。他部門の生産性のメトリクスは俺たちの部門にそのまま適用しちゃっていいの？って思うのが正しい。同じだよ、と言い切れるのは、相当の作業や開発ツールの標準化がされているからである。

同じ条件であっても生産性は向上しない
なら、すべてのメトリクスを取るための諸条件が同じなら、生産性を向上することが出来るのだろうか。それはできない。同じ条件下であるから成熟度は考慮しない。可能性があるのは精神論の部分だけである。

つまり、見積もり時に生産性のメトリクスがあったとしても、その条件が同じであるなら生産性の効率を上げることはできない。

どうしたら生産性は向上できるのか
プロジェクトでドキュメントやプログラミングをするための仕組みを変えるほかない。同じやり方なら生産性は変わらないのであるから、やり方を変えるのである。それなくて生産性は向上しないし、そのしくみは、プロジェクトに適用する前にプロトタイプであっても実証していなければプロジェクトの生産性はその改良前より悪化する可能性があるので注意が必要である。