本来の業務要件は何？
前回、前々回に見ていただいたトラブル例の根本的な原因について私は以下のように考えます。
「本来の業務要件を確認せずに実装してしまったこと」
即ち「業務要件情報」から劣化した「システム要件」のみをインプットとして対応を行ったというイメージです。
詳しく見ていきましょう。業務要件はお客様サイドで生まれて人伝えに我々のところまでやってきます。子供のころにやった「伝言ゲーム」の例でも分かるように業務要件は我々の所に来る前にシステム要件と名前を変えつつ通常「情報の劣化」が発生します。
今回の例ですと「業務要件」は、
・商品コードが10の商品は在庫過多のため当分の間2割引とする
・商品コードが33の商品はキャンペーン期間中につき2割引とする
であったにもかかわらず、システム要件は、
・ 商品コードが10と33の場合は2割引きとする
となってしまい「情報の劣化」が発生していました。
この「情報の劣化」は最初の対応時点ではトラブルを発生させませんでしたが、その後の対応（商品コードが33の商品を元に戻す）の時にトラブルを発生させてしまいました。このトラブルを防ぐ方法として前回の記事で書いた「ヒアリング」は、根本的には「情報の劣化を補った」という対応になります。
またシステムの実装段階でもこの劣化は発生します。仮に改修を行う担当者が、
・商品コードが10の商品は在庫過多のため当分の間2割引とする
・商品コードが33の商品はキャンペーン期間中につき2割引とする
という業務要件を理解していたとしても、最初の例のように、
商品コードが10もしくは33の場合に2割引とする
というコード修正を行ってしまえば台無しです ┐(´～｀)┌
情報の劣化をできるだけ防ぐアプローチを！
システム開発から保守フェーズまで、すべての局面でこの「情報の劣化」は発生します。もちろん100％劣化させないことは不可能（もしくは不必要）ですが、
・ 情報劣化は常に発生する可能性があること
・ 必要な情報の劣化が進めば何らかのトラブルを引き起こすこと可能性が高いこと
を認識し、「情報の劣化」を極力発生させないようにすることがトラブルを未然に防ぐ有効なアプローチとなるはずです。
情報の維持管理について
劣化に注意を払い必要な情報を獲得したらその情報を維持管理する必要があります。維持管理対象となる情報の保管先は概ね以下の通りです。
・ ソースコード ・・・ (各種設定情報やコメントを含む)プログラム（コード）を見れば業務要件が解る
・ ドキュメント ・・・ ソースコードで解らない部分は、設計書や運用マニュアルなどのドキュメントを見れば解る
・ XXXさんの頭 ・・・ ソースコードでもドキュメントでも解らない場合は、XXXさんに聞けば解る
もちろん、保管先として最も効率的なのは「ソースコード」であり、「ソースコード」では表せない情報をドキュメントとして維持管理し、極力「XXXさんの頭」が唯一の保存先という情報が無いようにすべきことは、ご理解いただけることと思います。
コメント