上流で品質を作り込むことを狙い,設計レビューを強化する現場が増えている。しかし,長時間に及ぶレビューは現場の負荷を高め,メンバーを疲弊させる。それだけの労力を投じても,重大な設計ミスが必ずしも減らないのが現実だ。3人のITエンジニアが座談会でその実態を語った。(聞き手は中山 秀夫=日経SYSTEMS)

ITエンジニア3人の座談会

情報システムの信頼性に対する要求が厳しくなるなか,品質管理を強化し「設計ミス」をなくそうとする動きがあるようです。みなさんの現場では,いかがでしょうか?

Aさん:私は製造業のシステム部門に勤めています。設計の品質向上は,大きな課題になっていますね。テストでバグをつぶすのではなくて,もっと上流できっちり品質を作り込んでいこうという方針です。最近はレビューの強化に取り組んでいます。レビューの回数を増やしたのに加えて,設計レビューで有識者を必ず入れるルールになりました。

有識者は具体的にはどんな人ですか?

Aさん:当社のシステム部門は六つのグループに分かれていて,別グループの優秀なITエンジニアを指名することになっています。でも,そういう人は限られるので,どうしても特定の人に人気が集中しますね。私にも依頼がたくさん来ていて,レビュー会議に参加するのが大変です。実を言うと,「その日は予定があって」とウソをついて断ることがよくあります。そうでもしなければ,自分の仕事が滞りますから。私の周りでは,「レビュー疲れ」という言葉がはやっているくらいです(笑)。

Bさん:私はシステム・インテグレータで,サービス業や流通業のシステム構築を担当しています。当社でも,レビューに力を入れていますね。次工程への移行の判定が厳しくなったこともあり,基本設計工程と詳細設計工程の終盤に開くレビュー会議で,徹底的に設計書の欠陥を洗い出しています。そのせいで,レビュー会議がさらに長くなりました。午後6時~7時に始めることが多いのですが,いつも深夜0時を過ぎてしまいます。

「レビュー会議が“説明会”に」

どうしてそんなに長くなるのでしょうか?

Bさん:私は自分でも設計をするので,自戒の念を込めて言うのですが,設計書の品質が低いことが一因です。当社の社風で,設計担当者はほかの人に欠陥を指摘されても落ち込まない人が多い。むしろ,レビュー会議でどんどん欠陥を指摘してほしいと思っている。甘えているんですね。本来は,きっちり仕上げてから,レビュー会議に臨むべきなのでしょう。

Aさん:当社のレビュー会議も長くなることがあります。根深い欠陥が見つかったときなどは,いい代替案が見つからず,延々と議論が続きます。

Cさんの現場はどうですか?

Cさん:私はシステム・インテグレータで,アプリケーションの設計をしていて,主にレビューを受ける立場にあります。私が参加するレビュー会議はたいてい長くならず,たんたんと終わります。

Bさん:それはうらやましいですね。

Cさん:いえ,決していいレビュー会議とはいえません。設計担当者がほかのメンバーに設計内容を伝える“説明会”になっているのです。

●設計ミスの事例
●設計ミスの事例
[画像のクリックで拡大表示]

つまり,欠陥の指摘がなく,形骸化しているということですか?

Cさん:そうですね。「この設計内容はおかしいかもしれない」と思っても,牽制し合う雰囲気があって,口に出しづらいようです。欠陥の指摘がまったくないわけではありません。目次と中身の不整合とか,用語の不統一,あいまい表現,誤字・脱字などの指摘はポツポツ出ます。そういう欠陥は誰の目からも明らかだし,すぐ修正できるから大ごとにならない。だから,指摘しやすいようです。

レビュー会議が形骸化して困りませんか?

Cさん:とりあえず設計書が承認されて,次の工程に進めるのですが…。欠陥が後で見つかるので,やはり困りますね。私は設計担当者として,欠陥をもっと指摘してもらいたい。レビュー会議の形骸化は,会社も問題視しているようです。2年前に,検出した欠陥数を品質保証部門に報告する制度が導入されました。設計書1ページ当たりの欠陥数の基準値が設定されていて,それ以上の欠陥を見つけるまでレビュー会議を終われない,という決まりです。でもその制約はあまり意味がなくて,たいていは用語の不統一やあいまい表現などで規定の欠陥数をクリアできてしまいます。下手にそんな基準値を設けるから,レビュー会議をやった気になるのかもしれません。

「強化が空回りしている」

なるほど,せっかく検出する欠陥数の基準を設けたのに,設計ミスの削減につながっていない,ということですね。AさんとBさんの現場では,設計ミスは減ったのでしょうか?

Aさん:設計書の完成度は上がったと思います。用語の不統一やあいまい表現のような,設計書を見てすぐ分かる欠陥は検出して修正できています。でも,相変わらず,重大な欠陥を見逃しています。実は,昨年末に稼働させたコールセンター・システムの一つが,今年に入って突如ダウンし大問題になりました。後で調査して分かったのですが,問い合わせやクレームをエントリーするときの同時トランザクション件数の上限値が小さかったことが原因でした。完全な設計ミスです。それを設計書のレビュー会議で見逃した上に,なぜか限界値テストを怠ってしまった。私はこのシステムの担当ではなかったのですが,顧客や利用部門に迷惑を掛けてしまって,すごくショックでした。

レビューを強化しているというお話でしたが,十分な成果につながっていないということでしょうか?

Aさん:そういうことになりますね。回数を増やしたり,有識者を入れたりしているのですが,空回りしている感じがします。

Bさん:私のチームでも,重大な設計ミスは減っていないかもしれません。昨年秋に手掛けた販売管理システムの開発では,画面・帳票の設計ミスが問題になりました。取引先の企業名などに略称を利用できるようにしたところ,正式名称と略称の使い分けに関する設計ミスが数多く発生しました。この設計ミスが判明したのは,ユーザー・テストの段階で,大半の画面・帳票を作り直すことになりました。

レビュー会議では,誰も気付かなかったのですか?

Bさん:残念ながら,そうです。そのプロジェクトでも,深夜までレビュー会議を実施したのに見逃してしまった。ユーザー・テストで指摘を受けたときは,「まさか」という感じで,みんなあっけにとられていました。結局,レビュー会議に長い時間を掛けることで満足しているのかもしれません…。