要件が「現行踏襲」である案件の代表的なリスクとして、「現行の仕様を調査してその仕様に合わせる工数、が過小評価されやすい」というリスクがあります。
そして、要件が「新たな導線を追加する」である案件は、一見現行踏襲でないように見えて、実際は現行踏襲案件と同じようなリスクを抱えます。
今回は、私が体験した案件を例に出して説明します。
今回例として挙げるシステムは、「営業員がプランを勧めて、最終的にエンドユーザーが個人情報を入力する」という営業システムです。
この営業システムのUIは、前半の営業員画面と、後半のエンドユーザー画面に大別できます。
前半は営業員が使うことを想定したシンプルな画面であり、プランを表示・入力する機能があります。
後半はエンドユーザーが直接目にするリッチな画面であり、個人情報を入力する機能や、入力内容を確認する機能があります。
この営業システムについて、「営業員によるプランの勧誘もエンドユーザー画面上で行うようにして、エンドユーザーだけで操作が完結するようにしたい」という要件の保守案件が発生しました。
システム的に見た場合は、前半の営業員画面だけではなく、別のエンドユーザー画面（以下「新エンドユーザー画面」）でもプランの表示・入力を可能とする、というものです。言い換えれば、前半の導線を増やす、というものです。
ここまで説明したことを図に表すと以下の通りです。
新エンドユーザー画面もエンドユーザーが直接目にするため、リッチなUIが必要になります。要件として示されたデザイン案も、これまでシステムでは取り入れていなかったデザインが採用されていました。
そのため、見積もりの段階では、リッチなUIに対応することが焦点に置かれ、技術的なリスクが重く見られました。
しかし、技術的な問題は、一旦技術検証が済んでしまえば、その後にリスクとして顕在化することはありませんでした。
代わりに、実際にリスクとして顕在化し、工数増大の原因となったのは、現行踏襲のリスクでした。
新エンドユーザー画面では、営業員画面と同じ機能を提供する必要があります。
また、最終的には後半のエンドユーザー画面に合流するため、内部的なデータ構造も営業員画面と同じように保持する必要がありました。
更に、営業員画面と新エンドユーザー画面では、見せ方の違いにより入力順や入力内容が微妙に異なっていたため、単純な機能移植で済むというものでもありませんでした。
これらの要因により、「現行仕様をデータ構造まで踏み込むレベルで調査・理解した上で、営業員画面と新エンドユーザー画面の差異に気を付けながら仕様を策定する」という作業が発生しました。この作業の工数は、見積もり時点では過小評価されていました。
そして、設計工程の工数増加や、仕様考慮漏れによるテスト工程での大量のバグ検出に繋がりました。
いかがでしたでしょうか。
「要件が現行踏襲である案件は危ない」というのは良く言われることですが、要件に「現行踏襲」と書いてなくとも似たようなリスクを持つ案件というのも存在します。
この類のリスクは、「要件に現行踏襲と書いてあるか」という観点ではなく、「現行の仕様にどの程度合わせ込む必要があるのか」という観点で見つけるべきです。
これからも、今回のような教訓を広めていきたいと思います！
コメント