ソフトウェア開発組織が持つべきカルチャー 005

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

ソフトウェアは、人が頭の中で考えたことを手を動かして作り出すものです。つまり、家内手工業なのです。そのため、個々のソフトウェアエンジニアのスキルが重要であり、スキルを積み上げていくことが必要です。Richard Gabrielは、 「The Poetry of Programming」と題するインタビューの中で次のように述べています。

Writing software is an art, and it takes about ten years to really get good at it.
ソフトウェアを書くことは芸術であり、本当にうまくなるには10年を要する。

Richard Gabriel, 「The Poetry of Programming」

ソフトウェア開発においては、個々のソフトウェアエンジニアのスキルを向上させる活動をしながら同時にソフトウェアを開発してく必要があります。

しかし、日本のメーカーは、ソフトウェア開発を労働集約型の開発であり、人を投入すれば何とかなると思っているために、単価だけを問題にしたり、まともな教育や指導（レビュー）を行うことなく、大量に経験の浅い人たちを投入したりすることがあります。

個々のソフトウェアエンジニアのスキルを測ることは容易ではありません。たとえば、一年間で開発組織全体として、どれだけスキルが向上したかを測定することは困難です。私の経験から言えば、個々のエンジニアのスキルは、成果物のレビューの場で本人の考え方を聞いたり、成果物の品質を直接目で見たり、学習態度や普段のコミュニケーションなど多くの側面から接して判断しないと分からなかったりします。

初心者5人が集まってソフトウェアを開発した場合と、スキルの高いエンジニアが5人で開発した場合、その生産性と品質の差は明らかです。しかし、労働集約型的な開発を行っている組織では、スキルの低いエンジニアを大量に投入したりします。そして、多くの障害を発生させて、デスマーチ・プロジェクトを繰り返す訳です。

初心者のスキルの低さをプロセスで補強しようとして、設計レビューやコードレビューを義務づけても、そもそもきちんとレビューできるスキルの高いエンジニアが参加しなければ、レビュー結果の成果物の品質が高くなることはありません。設計レビューやコードレビューというプロセスを実行することだけに主眼が置かれていれば、当然のことながら、レビューしたけどバグだらけということは起こりえます。

本来、レビューというのは、品質を作り込むためのものであると同時に、経験の浅い人のスキルを向上させるためのものでもあったりします。その両方の目的を果たすには、スキルの高いエンジニアがレビューに参加している必要があります。

スキル向上のための施策の方が、プロセスを定義してそれを強制的に実行させるという施策よりも優先されるべきです。スキルの高い組織であればプロセスは開発者自身により自然と改善されていくものです。逆に、スキルの低い組織はプロセスは固定化されて強化され、開発者のスキルは向上しないという悪循環に陥る可能性があります。

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