業務改善のすすめ（品質改善編）

１．品質改善の必要性

ITシステムの需要は個人・企業を問わずに増加してきており、社会インフラなど多岐にわたって利用されています。ITシステムを利用することで便利になる反面、システム障害が発生した場合の影響範囲は深刻で、例えば「キャッシュカードでお金が引き出せない」「公共交通機関が利用できない」といった事態になってしまいます。「ワンストライクアウト」という言葉でも表現されていますが、たったひとつの不具合で企業の信用は失墜してしまうのです。

ITシステムの品質が万全でなければならないことは、開発に携わる者として重々わかっています。

100%完璧なITシステムを開発できれば問題ないのですが、さまざまな人間が開発するために間違いが入り込む可能性もあります。この間違いが入り込まないように、品質を維持・向上させるための改善活動が必要なのです。

２．品質に関する問題点とその原因

（１）品質のバラツキ

ITシステムは同じ開発者がいつまでも開発するわけではありません。開発時期や開発規模、役割分担などにより、さまざまな開発者がITシステム開発に携わります。

長年使い続けているITシステムは品質が安定していると思われがちですが、開発者が変わることにより品質悪化となるケースが見受けられます。

この原因のひとつに、開発者のスキルのバラツキがあげられます。経験年数の長い熟練した開発者であれば、どの範囲まで影響があるかなど記憶しているため、改修範囲や改修にともなう影響範囲を見誤ることがほとんどありません。ところが、新たな開発者では影響範囲が判断しきれず、結果的に不具合を発生させてしまうのです。

（２）前工程での品質の重要性

ITシステムを開発する際、開発規模に基づいてコストを算出して、客先との見積合意が得られたら開発をスタートします。

計画に基づいて開発を進めていくのですが、要件定義や機能設計など前工程の品質が悪いと、後工程での品質にも悪影響をおよぼし、結果的に当初見積り以上のコストがかかってしまうケースがよく見受けられます。出荷後の市場で不具合が発生した場合は、システム修正だけでなく現場対応も必要となり、莫大な対応コストがかかってしまいます。

前工程での品質が悪くなる原因として、客先要件が確定せずに機能仕様や開発範囲があいまいになっていることがあげられます。後工程は、要件に基づいて作成した機能設計書、詳細設計書をもとに、プログラミング・テストを行う工程であるため、前工程での品質がITシステム全体の品質を左右すると言っても過言ではありません。

（３）開発環境と本番環境の違い

ITシステムの開発時点では、試験環境下でシステムの動作検証を行います。ネットワーク環境やサーバ環境など、本番を想定して構築した試験環境下では品質も問題なく稼働できているにもかかわらず、いざ本番環境下で稼働させてみると、「ネットワーク接続ができなくなりオフライン状態となる」「システムが途中で停止する」などの不具合が発生することが見受けられます。

この原因として、本番環境下での動作検証が計画されていないため、ネットワークオフライン時の切替やサーバダウン時のバックアップ切替等の動作確認が不十分であることがあげられます。

また、試験環境下では本番と同様のデータ量を生成することができず、システムのキャパシティ確認が不十分であることもあげられます。

３．業務改善のポイント

（１）安定した品質を確保する

品質管理の一環として、組織として品質を維持・向上させるための取り組みが必要です。

ドキュメント化、マニュアル化はもとより、レビューの観点をチェックシートとしてまとめて、誰が開発しても同じ品質を維持できるように、レビューチェックリストに基づいたレビューを行うことをおすすめします。

筆者はウォーターフォール型の開発手法で開発をしていますが、開発工程毎（機能設計・詳細設計・プログラミング・単体テスト・結合テスト・総合テスト）にレビューチェックリストを準備しています。

設計時によくあるミスをレビューチェックリストに記載する、テストケース作成時に抜け漏れの発生しやすい項目をレビューチェックリストに記載するといった取り組みを組織的に行うのです。これにより、熟練した開発者のノウハウを共有することができ、新たな開発者であっても品質のバラツキを抑えることができます。

（２）要件定義段階での品質確保

客先との要件定義においては、利用者の目的、背景を含めて相互理解を深めてドキュメント化するようにしましょう。

ITシステムであれば、使用方法や処理データの内容、さらにはシステムのキャパシティを定義するために、１時間あたりの処理データ量やシステム稼働時間なども定義します。あらかじめ要件定義書の雛形として項目を列挙しておき、客先とともに内容を擦り合わせすることで、要件上の抜け漏れや解釈間違いをお互いに防ぐことが可能となります。必ずドキュメント化して内容を共有し、要件定義の合意サインをもらうようにしましょう。

また、機能設計・詳細設計の段階で要件に対する是正事項が発見された場合は、設計を中断して要件定義に立ち返りましょう。後工程になればなるほど、手戻り工数が多くなり、コストも膨れ上がってしまいますので、気づいた時点で前工程に戻ることが重要です。

（３）利用者視点での品質を意識する

利用者視点に立てば、安心・安全にITシステムを利用できることが重要です。

システムを止めない、サービスを止めない、障害発生時のリカバリーやデータバックアップは万全にするといったことも大切な要素です。そのためにも、実際の稼働を想定した運用テストを必ず行いましょう。実際の利用者が使用する前に、本番環境を使って行うことをおすすめします。

筆者が担当しているITシステムでは、本番稼働の前に客先従業員だけに絞って運用テストを行っています。万一不具合があったとしても、実際の利用者には影響がないことが最大のメリットです。

可能な限り運用テストで、オフライン等のエラー発生時の稼働確認やシステムのキャパシティ確認を行いましょう。

４．実施する際の留意点

（１）常に改善する意識を

品質を向上させる方法がないか、手順ややり方など改善するところがないか、日頃から目を向けて、組織的に改善提案＆実行する風土を作ることが大切です。

「人が変われば品質が変わる、時が経てば技術動向や開発手法も変わる」といったことも意識して、環境の変化にも影響を受けないように高い品質を維持させることを心がけましょう。

（２）あえて作らない

客先要望だからといって何でもシステム化することが得策とは言えません。

ITシステム化することで逆に手間がかかってしまい、使いものにならない余計な開発を行ってしまうケースも見受けられます。要件定義段階で利用シーンも想定しながら、本当にシステム化が必要か議論することが大切です。

また、ITシステムの構造化にも目を向けましょう。品質が安定している機能や構造はパッケージ化して、この部分には改修を加えないようにする工夫も、品質を維持・向上させるためには必要です。

５．おわりに

ITシステム開発での品質改善における取り組みについて解説しました。ITシステム企業を取り巻く環境は変化し続けていることから、筆者自身も品質改善・品質向上に向けた取り組みを継続しています。

本記事が、ITシステム開発の品質改善において、少しでも参考になれば幸いです。