SSブログ

開発スピードが遅い?速い? [プログラマー現役続行]

ソフトウェア開発グループあるいはソフトウェア開発組織の開発スピードが遅いとか速いとはか、何を基準に判断するのでしょうか。

人が単純な作業を行わずに、自動化できる部分を徹底的に自動化した場合、残っている部分が本当の意味では、その組織での開発スピードです。

たとえば、システム全体のビルド作業を手作業で週に一回行っており、開発メンバーは、単体テストも書かずに、高残業をしながら一週間に多くの機能を実装したと報告する開発を考えてみます。もちろん、他のモジュールとのビルドもしていないし、ビルドするのは翌週の月曜日ということになります。これは、80/90年代によく行われた開発スタイルです。

一方で、Jenkinsを使用しながら継続的インテグレーションを行い、自動実行される単体テスト・システムテストを作成しながら、システム全体の機能のデグレードや副作用が起きていないかを常に検証しながら、開発メンバーがあまり残業をしない開発と比較してみるとどうでしょうか。

機能の作り込みスピードは、一見すると前者の開発の方が速いように見えます。しかし、それは、システム全体を結合して、システムテストに入るまでのことです。システムテストに入ってしまったら、作り込まれたソフトウェアの品質はスケジュールに対して嘘をつきません。つまり、品質が悪ければ、多くの不具合が報告されて、当初の立てられたテストスケジュールはあっさりと延長されます。

後者の開発の場合、開発のスピードを左右するのは、開発メンバーのソフトウェアエンジニアとしてのスキルレベルです。スキルが低い人は、低い人なりの成果しか出せません。見かけ上、多くの機能を作りこんだと報告することはできません。スキルの高い人であれば、実際に動作して検証済みの難易度の高い機能を同じ期間に多く作り込んでいきます。

製品開発の観点から、前者の開発では、開発部門が順調に開発していると報告しても、最後のシステム全体のテストが非常に長くなってしまうため、QA部門が開発部門を信頼せずに、経験的に製品のテスト期間を長く設定した計画になります。後者の開発では、本質的に開発方法が異なっていますが、そのような製品開発を経験したことがない場合には、同じ長さのテスト期間が必要だということになりがちです。しかし、従来と比べて、開発部門の開発量は増えていますので、開発部門による開発期間は長くなり、開発部門の開発スピードが遅すぎるという批判になってしまうことが考えられます。

前者の開発では、スキルが低い人がいても、見かけ上分かりにくいです。そして、スキルが低い人が作ったモジュールが原因でプロジェクトが火事場になるのは、プロジェクトの後半になります。さらに、火事になってから、マネージャが「火事の原因は、担当者のスキルが低かったから」と報告して、担当者を変えて火消ししようとすることが多いと思います。結果として、プロジェクトの終盤で、別の人に全部書き直されてしまうモジュールがあったりするかもしれません。

後者の開発で注意しなければならないのは、エンジニアのスキルと育成です。本質的にスキルが低い人の集団では困るわけです。開発しながらでも、スキルが確実に向上していってもらう必要があります。見方を変えると、個々のエンジニアのスキルが見えやすい開発と言えます。

開発グループや開発組織の開発スピードが遅いと言う場合には、いったい何を意味しているのかをよく考えてみる必要があります。

Facebook コメント