プログラマの思索

「コードコンプリート」第2版下巻を輪読した。
品質、テスト、デバッグの章を読んで、非常に参考になることばかりだった。

「コードコンプリート」を読むまで「プロセスで品質を作りこむ」という格言の意味が分からなかった。

整理するために感想を書いてみる。

【1】テスト自体はソフトウェア自体の品質を改善しない

「コードコンプリート」によると、テスト(単体・結合・システムテスト)をいくらやっても、一般に存在するエラーの高々50%しか検出されない。

テストの結果は品質の指標になるだけだ。
ソフトウェアの品質を上げたいなら、テストを増やすのではなく、開発プロセスを改善しなければならない、と。
その実例や測定結果も載せていた。

この指摘には衝撃を受けた。

どのプロジェクトでも、テストケースを増やしたら、ソフトウェア品質が上がっているように思えないだろうか？
それは、痩せるために体重計にのる回数を増やしているだけ。
痩せないのなら、新しい体重計を買うのではなく、ダイエット方法を見直さなければならない。

つまり、開発プロセスそのものを見直さなければ、品質は上がらない。

【2】ソフトウェア品質の原則～品質を改善すると開発コストは下がる

「コードコンプリート」によると、欠陥を検出したり修正するコストは後工程になるほどコストが高くなる。
エラーやバグが紛れ込んだ時期が早ければ早いほど、そして、ソフトウェアのほかのパーツに紛れ込んで見えなくなるほど、それを排除するコストは高くなる。

これをソフトウェア品質の原則と称して、色んな実例を載せている。

いわく、欠陥の低いプロジェクトは開発工数が短い。エラー排除はソフトウェア作業で最も高価で時間がかかる。

いわく、要求や設計の変更が原因でも、デバッグやテストが原因でも、コーディングのやり直しにかかる時間を減らすことが生産性と品質を上げる最善策だ。

いわく、品質の低いソフトウェアを開発して修正するよりも、品質の高いソフトウェアを開発する方が安価だ、と。

いわく、開発の早いPGは最も多く速く欠陥を検出し、修正した、と。

「コードコンプリート」には「悪魔のささやき」というブラックジョークがある。

・欠陥は憶測で探せ
・問題を理解しようとして時間を浪費するな
・真っ先に思いついた方法で解決せよ

この手法を意外に実行していないだろうか？

特に、プロジェクトリーダーは、納期を遵守するために、本来あるべきプロセスを省いてしまう時が多々ある。
その影響は、品質劣化という結果に直結する。

プロジェクト終盤でプロジェクトリーダーがよくやるパターンは、リリースする機能の数を減らして、限られた範囲の機能の品質を保持することに注力すること。

つまり、7つの品質特性のうち、信頼性を重視するために、スコープを狭くして作業工数を減らす方向へ持っていくことをよくネゴする。
そして、開発・検証プロセスはできるだけ省略しない。

但し、この手法が使えるには相当の政治力が必要。
スコープを狭くするとは、システムのあるべき機能を削るのだから、お客様の本来の業務の一部をシステムがサポートしないことを意味する。
信頼性を削ることと同じ。

この手法を「プロジェクトを成功させる 現場リーダーの「技術」 」では「ウルトラC的アクション」と言っている。
つまり、ゴールの前提条件を変えてしまうこと。
ゴールはお客様との合意の上にあるわけだから、お客様の要求を根本的に変更させるぐらいの相当の政治力を必要とする。

【3】品質改善のために、テストだけでなくソースインスペクション、ペアプロも組み合わせる

「コードコンプリート」では、テストだけでなく、ソースインスペクションなど他の手法も組み合わせることを推奨している。
特に、「コードコンプリート」によると、ソースインスペクションの効果を強調している。
「コードコンプリート」が説明するソースインスペクション方法はとても組織的だ。

モデラー、作成者、レビューアの3人が、設計書やチェックリストから、あくまでもソースの欠陥を検出することへ注力する。
そして欠陥を修正し、その結果を確認する。

ソースインスペクションを重視する理由は、そのプロセスが自ら最適化される仕組みがあるからだ、と「コードコンプリート」著者は言う。
つまり、標準的なチェックリストと標準的な役割によって体系化されるし、フィードバックを繰り返す過程でチェックリストが改善されるし、インスペクションの準備や修正の速さや効果度が監視されるので最適化される、と。

この表現は、CMMIのレベル3の標準的プロセスをイメージさせる。

つまり、インスペクションプロセスは、体系的(レベル3)で、繰り返し実行することが可能(レベル2)で、測定結果(レベル4)に基づいたフィードバックを使って自身を改善する(レベル5)。

このテクニックは他のプロセスにも応用できるし、「コードコンプリート」では「開発組織に当てはめたら、これらの考え方は組織に最高水準の品質と生産性をもたらすだろう」と言っている。

逆に、「コードコンプリート」ではウォークスルーは批判的だ。
効果が低いという測定結果も載せている。

「コードコンプリート」が否定的な観点を提示するのは、ソースインスペクションという焦点が曖昧で、公式なインスペクションに組織やメンバーが否定的な所ほどウォークスルーを使っているという経験談があるからだろう。

また、「コードコンプリート」では、「テストファーストプログラミングは過去10年間に登場したソフトウェアプラクティスの中で最も効果的なものの一つ」と言い切っている。

「コードコンプリート」では、XPを新しい分野の欠陥排除テクニックと呼び、その測定結果から、かなり効果的であると断じている。
実際、XPのプラクティスでは、ペアプロによるソースインスペクション、テスト駆動開発によるテスト重視、デイリービルドで回帰テストなど、意図的に複数のプロセスを組み合わせているからだ。

その意味では、XPを含めたアジャイル開発は、過去10年のソフトウェアの歴史で工学的に、あるいは経験で裏打ちされたプラクティスなのだ、とも言える。

「コードコンプリート」は上下2巻で1000ページ、1万円を越える大著だが、この本2冊で、プログラミング技術だけでなくソフトウェア工学の知識も殆どカバーする。
すごい本だと思う。

↓上巻はこちら