■開発現場の悩み・問題点を解く ８ ～プロジェクトが遅れる ⑧ ～ （No.315）
品質問題，バグ多発，後戻りなど品質悪化でプロジェクトが遅れることがある。
品質問題は不可避，如何に素早く対処するか
新製品開発に於いて，品質問題がクローズアップされることはよくあることである。初めて製品化するのだから，いろいろな問題が出るのは致し方ない。むしろ，設計の工程で品質問題を洗いざらい出してしまうことの方が，市場での品質問題を考えれば被害が最小で食い止められる。つまり，品質問題の対策する費用を考えると，設計工程での費用は市場対策の何分の一，或いは何十分の一で済むと云われている。
元々の新製品開発プロジェクトの計画では，品質問題で時間を浪費することは入っていないのが普通である。多少の余裕はもちろんあるものの，品質トラブルで時間とパワーを要することは計算外である。しかし，多かれ少なかれ品質問題で時間を取られることは必然と云ってもよい。如何に素早く，問題が大きくならない内に芽を摘んでしまうことが重要である。
多少の品質劣化は目をつぶる程度であればよいが，致命的な品質問題は設計工程内で解決しておかなければならない。また，致命的な欠陥となると根深い問題が多く，多くの時間を取られることになる。当然，開発プロジェクトの計画変更を余儀なくされることになる。こうした事態を回避することができるのか？
実際こうした事態が発生すると，プロジェクトの遅延は不可避となる。後は，如何に遅延日程を少なくて済ませるかである。得てして，対処療法で簡単に片付けようとすると，後で手痛いトラブルを被ることが多い。だから，冷静に品質問題の深さを確認し，最優先課題として一番良い方法で抜本的な対策を講じることが結果的に最小限のロスで済ませることができる。必要なのは，冷静な判断力である。
バグ管理は必須
ソフトウェアのバグも，初期の段階でできる限り除去しておかないと，評価など設計の後半工程で取り除けばよいと考えていると，とんでもない日程遅れを発生させてしまうことになる。ソフトウェアのバグは設計では当然あるもので，評価で発見されるのは致し方ないことである。しかし，バグ発見を評価だよりにしていてはいけない。
これも上述の品質問題同様，如何に早期に検出させ対処するかで，開発プロジェクトの日程が守れるかどうかが決まる。つまり，ソフトウェア開発のどの段階でどれだけのバグを検出するか予測を立て，その予測と実績の推移を管理しながら開発を進めることである。もちろん，全く初めての開発は実績データも無いのでムリだが，通常は類似製品の開発事例があるはずなので，そのバグ検出実績から改良する目標値を定め，予測値を決めるのである。
こうしたバグ管理がきっちりできて進む開発プロジェクトは，日程管理も上手く行く場合が多い。開発プロジェクト全体が，管理された状態にあるので，大幅な狂いが生じないのである。日常の何気ない行動，管理状態におかれたプロジェクトこそが，素晴らしい開発プロジェクトなのである。
後戻りをしない対策を
品質問題を発生させ，或いは見つかり，随分前の工程からやり直しをした経験は技術者なら誰しも経験しているだろう。ソフトウェア開発などでは，初期段階のアーキテクチャーがきっちりできていないと，酷い目に遭うことが多い。
つまり，すべてがロジックであり，そのロジックが抜けなくできているかどうかで，善し悪しが決まる。もちろん，人間のやることなので，全く漏れなくできる訳ではない。しかし，後戻りを余儀なくされる場合を観察してみると，どこかで手抜きをしていたり，レビューをきっちりしていなかったり，外部に丸投げしていたり，とどこかにスキがある。先人の知恵で，同じ失敗を繰り返さないようルールが定められている。ところが，ついそのルールを違反した行為をやってしまうのである。それがアダとなる。
誰しも後戻りするロスは避けたいと思っている。しかし，気を付けていても同じような後戻りがしばしば発生する。今，目の前にあることだけに集中していると，その先で起こることが読めていないために，その時になって初めて気づく。その時点では遅い。後戻りを少なく，上手くプロジェクトを進める人は，常々先を読みながら進めている。次に起こることが判っているので，先に手を打っておく。だから慌てることもなく，飄々として事を確実に進めて行く。
このように，普段日頃から，リスクなど先読みをしたものの見方を訓練しておくと，かなり結果は違ってくる。もちろん，ルールなど基本的なことは忠実に行うことは当然である。急がば回れ，と云う諺があるように，急いでし損じることをしないようにすることも大切である。品質の重要さは何度か痛い目に遭って身に付くのかもしれない。
品質問題は疎かにしてはいけない
決められたルールを確実に遵守した方が日程が早い
[Reported by H.Nishimura 2013.04.01]
Copyright (C)2013 Hitoshi Nishimura
