プロセス中心ではなく、スキル中心（4）

ソフトウェア開発は人が行う活動であり、手を動かしてプログラミングするという点では一種の家内手工業です。そのため、従事する人のスキルによって生産性、品質、および、技術的負債というのは大きく左右されます。したがって、本質的には個々のエンジニアのスキルを長期的に向上させることを組織として行っていく必要があります。

しかし、スキル向上は目に見えないし数値として測るのは難しいため、長期的視点に立ったスキル向上のための活動をソフトウェア開発組織としては避けたりする場合があります。代わりに、スキル向上以外の対策を真剣に検討することになります。たとえば、コードの品質を測るために静的解析ツール（カバレッジ測定、複雑度測定、FindBugsなど）だけに頼って品質を向上させようとします。そして、ツールが示す数値が開発プロセス内でのフェーズ移行基準として決められたりします。

本来、それらの指標は、開発者自身が客観的に自分が作成したコードの品質を確認するのを助けるためのツールであり、基準値をクリアーすれば品質が高いことを保証するものではありません。たとえば、コードカバレッジが100%というのはコードの品質を保証するものではありません※。
※ バグがあったり、品質が悪くても、コードカバレッジを100%にすることは可能です。

開発者が自分のコードの品質を確認すると言っても、開発者自身のスキルが高くなければツールが示すコードの状態を正しく解釈できなかったりします。たとえば、FindBugsが警告している内容の本質が分からずに、警告を消すための誤った修正を行ったりすることになります。そして、スキルの低いエンジニアは、コードの品質以前に指標をクリアーすることに注力することになります。

結果として、そのようなツールの導入だけでは、思ったほど品質が上がらなかったりして、結局は「ソフトウェアエンジニアのスキル」問題に戻ってしまいます。毎年、経験の浅い新卒新人の人達がソフトウェア開発組織には入ってくる訳であり、一時的にはツールやプロセスなどでスキル問題を回避しても、また同じ問題に直面することになります。

「プロセス中心ではなく、スキル中心（3）」