第三者に品質保証をしてもらうことを前提とすると、先ず始めに、第三者にテストをしてもらえるようなテスト仕様を作成し、設計作業のテストを委託することから始める必要がある。
これが出来ることが前提で、次に、第三者に品質保証作業を委託する。
これは、これまでに述べてきた品質保証作業を代行してもらえればよい。
と言うことであるが、もっとも大切な品質の質の向上という点では、次に述べるプロセスの改善が必要である。
バグは、一連の作業が上手く流れていない結果として招き入れられている。
したがって、結果を変えたければ過程、すなわちプロセスを変えなければならない。
ソフトウェア開発に於けるプロセスは、組織の体制や作業手順、さらには各人の発想パターンがそれに該当する。
これらが同じである限り、同じようなバグが入り込む。
特に明確な作業手順を持たない開発組織の場合、各人の思考パターンがプロセスの大きな割合を占めてしまう。
バグ発生の仕組みが、パラメータのチェック漏れにあると判明した場合も、なぜチェックが為されなかったのか、さらにはどうして最初に設計書が書かれなかったのかが問われなければならない。
そうして初めて、どうすれば設計書が書けるのか、どうすればレビューが出来るのかといったプロセスの改善に至ることが出来る。
そうやって真の原因に至れば、何らかのプロセスが変更される筈である。
こうした真の原因に至らないかぎり、同じような性質のバグが毎回侵入してくる。
そしてそのような組織では、「ソフトウェアの開発は、誰がやってもこんなもんだ。バグなんて無くならない」ということになってしまう。
何故、改革／改善ができないかの「問題」は以下の３つの領域に存在し、一つの問題が他領域の問題の「原因」となっている。
特に、プロセスに関する問題の殆どは、他の２つの領域に起因する問題の影響を受けている。
したがって、３つの領域に対して同時に働き掛けないと、期待する結果が得られない。
・プロセス（仕事の仕方の領域）
・アーキテクチャの領域
・意識／組織の領域
殆どの改革／改善の取り組みはこの領域である。
作業手順の確立や、ＣＭＭの取り組み、それらの取り組みを支援する各種の手法や技法の修得などが含まれる。
以下に、その中の代表的なものを列挙。
○作業の手順的なものとしては、
・要求仕様の作成と管理
・スケジュールの立案と進捗管理
・作業手順の確立
・協力会社管理
・構成管理と変更制御の仕組み
・レビューの仕方・運用
・チームの運営と組織内の協調の仕組み
・成果物、およびプロセスデータの測定と判断の仕組み等
○技法的なものとしては、
・レビュー技法
・サイズの見積もり技法
・スケジュールの見積もり技法
・分析・設計技法
・テスト技法等
これらの技法の習得や、作業手順の確立を実現するには、次の２つの領域に大きく依存する。
・アーキテクチャの領域
・意識／組織の領域
アーキテクチャ領域の問題というのは、
・そのシステムの設計思想が間違っていた
・使用している言語が障害になっていた
・あるいは、システム構成上、拡張性などの品質が考慮されていなかった等。
例えば、適切なＯＳやリアルタイムモニターが搭載されていないという状況や、システムの殆どがＣで書かれているような状況では、製品の表面上は簡単な機能の変更のように見えても、実際の変更作業は大変な作業になることが考えられる。
また、グローバルデータが氾濫していて、内容の更新のタイミングが把握できないような状況とか、流れの制御の為に「フラグ」が多用されていた、関数の呼び出し構造が複雑で、図式化出来ないような状況では、一つの修正行為が、新たな不具合を作り込んでしまう可能性が高く、プロセスの「変更制御」の取り組みも出来ない。
このような時、プロセスの改善とは、別に、アーキテクチャの問題を特定し、その状況の改善に同時に取り組む必要がある。
この種の改革／改善の取り組みにおいて問題となるのがこの領域である。
先ず、意識の領域に関する問題としては、
・どうせ書いたって誰も見やしないじゃないか
・レビューなんてやったって時間がもったいない
・「その日の遅れがその日に分かる」ような詳細なスケジュールなんて書いてられない
・そんな時間があったら、１行でもコードを書いているほうがまし
・どうせ予定と一致することなんてありえないのだから、適当でいいじゃない等
言うまでもなく、このような考え方の下では何も変わらないし、何も取り組めないことは言うまでもない。
実際には、このようなあからさまな抵抗を示すことは少ないが、多くは、“やり過ごし”という“手法”が使われる。
それだけに逆に厄介である。
要は、仕事の意義とか、何のために新しい技術を身に付けるのか、何のためにプロセスを改善するのか、という点に関して、一定の理解と認識がないと、何も進めることはできない。
組織やチームの在り方とか、成果物の測定やプロセスの測定の意味も、その上でなければ理解できない。
「幸福」の原点が、仕事を上手く仕上げるところにあるということに合意が出来なければ、一緒に仕事をしていくことも、一緒にこの種の改革／改善に取り組むことも出来ない。
そのためにも、意識の領域に潜む問題をクリアしていかなければならない。
ただ、この領域の問題の幾つかは、組織の領域の問題から派生している。
次に、組織の領域の問題としては、
・評価基準や
・それに伴う昇進・昇給の仕組み
・減点主義的風潮の存在
・“言い出しっぺ”が損をする仕組みなど
が挙げられる。
この種の取り組みのためには、現実の仕事の合間を縫って勉強しなければならず、そのことが評価される仕組みが無かったり、取り組みが当初の目論見通りの効果を上げなかったときは、その責任を追及されたり、評価を下げるような仕組みの下では、この種の取り組みに対して「忙しさ」を理由に“やり過ごす”しかない。
この種の取り組みは、実に複雑で厄介である。
したがって、「組織」はむしろ、そのような人を積極的に「支援」し、「評価」すべきである。
この領域のもう一つの問題は、それぞれの人の「役割；守備範囲と責任範囲等」が明確にされていないことである。
