SIG
先号　　　次号

「品質管理の原点について」

株式会社CIJ　小川　泰子　[プロフィール]　：9月号
　何を書いたらよいか困りましたが、「初心忘れるべからず」ということで、私がIT業界に入り立ての頃に学んだ中で、一番印象に残っている品質管理のことを書くことにします。
　数学科出身の私がこの業界に入ったのはメインフレーム全盛期で、当時まだ新しかった職種「プログラマ」としてメーカのソフトウェア開発専門の事業部に入社し、1ヶ月ほどの技術教育の後、オンラインコントロールプログラムを開発する部署に配属されました。現場では、「アセンブラ言語から、高級言語(PL/I言語)への開発言語の移行期でした。開発においては、当時の高額なマシンを使用するのは最後の行為であり、事前に十二分な机上デバッグにて静的なバグは全て潰しておくことが強く求められました。このような時代ですので、テスト中のプログラムのソースコードに手を加えるということは、重大なリスク行為として、たとえ「コメント一文字を修正する」だけでも、「プログラム変更票」というドキュメントを書いて、リーダの承認を得て行うことが徹底されていました。ソースコードを修正することは、モジュールを作り直すことであり、プログラムの稼働環境が変わることで、システムに大きな影響を与える可能性がある。ソースコードに手を入れることの重大さを叩き込まれました。
　この「プログラム変更票」作成時に、「不具合の事実を追究し、対策を検討する」プロセスを経験したことで、品質管理の原点を教わることができたと考えており、そのことを記載したいと思います。
　「プログラム変更票」は、「現象」「原因」「修正内容」の3点を明記することになっており、最初に「現象」欄、プログラム変更の発端となる「不具合現象」を記載します。この欄を正確に記載すること、思いこみなく、客観的に正確に現象を捉えることが、誤りなく不具合改修を果たすための前提条件であることを学びました。「現象」の捉え方に不備・不足があると、永久に問題は解決できない。下手をするとデグレード、修正不十分の繰り返しで泥沼にはまってしまうかもしれない。「不具合現象を正しく知ること」、それは「数学の応用問題を正確に読み取ることが正解を導く最大の近道である」と同じように、不具合の原因を突き止める近道であると知ることができました。
　次は、「原因」欄、この原因調査も見落としなく、慌てずに行うことが重要と知りました。せっかく、「現象」欄に現象を正しく捉えて記載することができても、対策を急ぐあまり、慌てて、最初に見つけた原因に飛びつき、他の原因を見落とすという落とし穴があることを知りました。
　最後に、「修正内容」欄、修正前後のフローチャートを記載することが自己レビューとして、修正誤りや不十分に気づく重要なプロセスであることを身をもって体験しました。
　「プログラム変更票」の3点セット(現象、原因、修正内容)を正しく書くことの重要性を叩き込んでくれた先輩に感謝し、自分も「「プログラム変更票」が正確にかけるようになれば一人前」と後輩に説明したものです。
　現在の開発スピードからは、このようなドキュメントをこつこつ書き自己レビューした上で、上長のレビューを受けて修正するというプロセスを踏むことは、難しいかもしれません。
　しかし、「不具合の現象を正確に客観的に把握することの重要性」や原因調査において「思いこみで、複合的な原因を見落とすことがあり得る」ということを認識することは、ソフトウェア開発において共通に求められる知識だと思います。ソフトウェアが社会のインフラを担う様なシステム開発においては引続き必要なプロセスであり、そのトラブルが企業活動や市民の社会生活に甚大な影響を及ぼす現代だからこそ、開発手法に関係なくプログラマに求められ品質管理の原点と認識します。
以上


　 IT-SIG，内容にご意見ある方、参加申し込みされたい方は こちらまでメールください。歓迎します。
SIG推進部会は こちら
ITベンチマーキングSIGホームページは こちら
ページトップに戻る