このエントリーをはてなブックマークに追加LINEで送る

第12章 品質管理

ハッピィ・エンジニアリング表紙

 大手SIのA社では、殿上人の事業部長様がプロジェクトの最初と最後だけおでましになり、プロジェクトメンバに訓示をする。

 

 「我が社が信用を得るには、高い品質が不可欠です。入念なレビューと十分なテストによって、お客様に高い品質のシステムを提供できるよう、心して作業してください。期待しています」

 

  雲の上にいる、プロジェクトマネージャ様も、部長の受け売りなのか、同じようなことを言っているのが聞こえた。

 

 「プログラマの作業など信用するな。事前のレビュー、事後のテストを徹底してこそ、品質要求が満足できるんだ」

 

 三次下請けのSEであるS君は、「そうかもしれない」と漠然と思っていた。設計書を書き上げて、さぁ、レビューだ。ところが…。

 

 まだ詳細な要件が出ていないのに、レビュー担当者が偉そうに、

 

「障害時対策はどうなっているんだ」

 

とか、

 

「この例外に対しての処理が書かれていないじゃないか」

 

とか、重箱の隅をつつきだす。

 

 S君は、心の中で叫ぶ。

 

 「まだ決まりきっていないことより、正常系の処理がきちんと設計されているかどうかを見てくれ。レビュー担当が、メインの処理ロジックについて質問してくれれば、すぐに答えられるのに」

 

 しかし、そんな心の叫びは無意味だ。
 S君が一週間、様々な観点から検討し、ユーザに質問し、やっと作り上げた設計である。S君は、プロジェクトメンバの誰よりも、このプログラムの機能や設計について熟知しているのである。S君が作り上げたロジックに誤りがあったとしても、S君自身がそれに気が付かないようであれば、第三者であるレビュー担当者が気付くわけがない。

 

 入念に検討したメインの処理ロジックについての評価を得ようとした。

 

「この処理は、このような工夫をしていて…」
「ふーん、なるほど、それでいいんじゃないの?こっちが言ってるのは、そういうことじゃなくってさ…」

 

 S君は疑問を抱いた。

 

「レビューで品質が良くなる…?」

 

 S君は、このプログラムの担当として、コーディングを終えた。デバッグも入念に行ったつもりである。テスト担当者にソースプログラムを引き継いだ。

 

 テスト工程に入り、いくつかのバグが摘出された。S君はプロジェクトリーダから叱責される。S君は当然、心の中で思う。

 

 「プログラムにバグは絶対に発生する。テストはバグを摘出するためのものだろう。出して当たり前だろう」

 

 プロジェクトは、誰もがそのような考えを持っていないかのような雰囲気が支配している。バグを発生させたことが悪いことのようだ。

 

 「何かがおかしい…。けど、カットオーバ後で、客先でトラブルが起きるよりは、なんぼかマシだしな」

 

 S君は自分を慰めてみる。

 

 でも甘かった。運用開始初日にダウン!しかもそれは、S君が担当したプログラムである。

 

「テストをしなかったのか!」

 

 SIベンダのプロジェクトマネージャ、リーダたちの怒声、罵声、大声…。
 プレッシャーを背中に受けながら、必死になって応急措置をほどこしているうちに、バグの原因に気が付いた。

 

「このパターンは抜けていた・・・」

 

 バグ修正が終り、S君は考えてみた。

 

「でも全てのパターンをテストし尽くすことなど可能なのか?」

 

 早速、入力データによる処理パターンを計算してみた。

 

10×7×8×9×…

 

 電卓の桁が足りないほどのパターンが生まれることが分かった。

 

「テストで品質が良くなる…?」

第12章 品質管理 ハッピィ・エンジニアリング記事一覧

12.1. 品質とは何か? ハッピィ・エンジニアリング

 欧米のシステム開発では、「品質の向上には多くのコストが必要になる」「スケジュールと品質は相反する項目である」という考え方が一般的である。ところが、古き良き日本のシステム開発には、「品質を高く保ちながら開発することこそが、コストダウンにつながる」という、素晴らしい(そして、ごく当然の)価値観が存在し...

≫続きを読む

12.2. テストのプロセス区分 ハッピィ・エンジニアリング

 最終的に信頼性を測る基準になるのはテストである。信頼性を確保するために、テストがどのような観点で、どのようなプロセス区分となっているかについて、再認識しておきたい。 プログラミングプロセスは、プログラマによるデバッグの終了をもって完了するプロセスである。テストプロセスはここから開始され、運用開始の...

≫続きを読む

12.3. 現状のシステム品質 ハッピィ・エンジニアリング

 現状におけるシステムの品質は、品質の要素の中で重要とされる「信頼性」を満たすことすらままならない状況がある。 品質への問題は、要件定義から運用開始に至るまでの間に原因が存在し、それぞれが複雑な関連を持ったうえで実際のトラブルとして顕在化する。話題を複雑化させないために、ここではまず、運用開始後のト...

≫続きを読む

12.4. 品質低下の根本要因 ハッピィ・エンジニアリング

 品質に対する古き良き価値観が失われつつあるのは、ゼネコン構造と下請けの連鎖企業教育の不備SIベンダのコストダウンに対する努力不足などが原因となっているように思われる。 ゼネコン構造と下請けの連鎖により、開発メンバのほとんどが、下請けである。下請けは、自らに与えられた作業を、要求されたスケジュール通...

≫続きを読む

12.5. 欠陥とは何か? ハッピィ・エンジニアリング

 品質向上のために重要なのは、欠陥を作らないことである。ソフトウェアは論理的なものであるため、欠陥が目に見える形になるのは開発したプログラムを動作させてからである。しかし、それ以前のプロセスから生まれた欠陥が、後のプロセスにおいて徐々に顕在化していくことは事実であり、欠陥を作らないように意識して開発...

≫続きを読む

12.6. 品質向上の手法 ハッピィ・エンジニアリング

 欠陥を作らないためには、そもそも「モノ作りをしない」ことが重要である。つまり、すでに完成した高品質な製品を導入するのが一番の早道である。しかし、現実問題として、それは難しい。パッケージの導入ですら、日本においては過剰なまでのカスタマイズをするのが一般的だ。 完成品に続く方法は「再利用」である。要件...

≫続きを読む

12.7. 品質は作り込まれる ハッピィ・エンジニアリング

品質とは、計画・設計・作り込みによって達成されるものであり、検査によってではない。A Guide To The Project Management Body Of Knowledge: Official Japanese Translation, Project Management Instit...

≫続きを読む

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング