前回は要件定義について投稿いたしましたが、今回はその具体例として要件定義を行う際によくある事例の成功、失敗事例集としてそのときに私がどのように考え、どう行動して解決、今後に結び付けたかをご紹介致します。
目次
Contents
①クライアントとイメージが共有できていない
◆事例
・プロジェクトにて定められた要件定義書を元に要件定義を始めたが、お客様より「システム化した時にどうなるかイメージしにくい」「私がイメージしているものと齟齬があるようだ」とご指摘をいただいた。
・また、そのことが顕在化したのが、一通りのドキュメントの作成後であったため多くのドキュメントに修正の必要が生じた。
◆どのように考えたか
・プロジェクトに定義されたドキュメントだけでは、イメージ共有に不足があった。
主には、要件・機能が文字ベースで記載されていることが原因で、その実現方法は個々の想像によるものであったこと。特に運用主体や部署、メニューやデータ・多機能連携といった横断的なシステムの動きに対して、要件定義書は各個別の業務や機能について記載されており、複数ファイルで「点」での存在となってしまい「線」として、業務や機能・データの繋がりが掴めない/掴みづらいのではないかと考えました。
◆どう行動して解決、今後に結びつけたか
・プロジェクトで用意されているフォーマットの要件定義書を作成する前に簡単なイメージ資料(パワーポイント、エクセル、XD等)を作成し、それをもって速い段階でお客様と認識合わせを行い、ゴールにズレがないかを都度確認して解決に結びつけました。
・これでもイメージに乖離が生じてしまう場合は、プロジェクトの工数、期間にもよりますが、実際にサンプルのアプリを作成して画面表示イメージや情報がどのように遷移されていくかをお見せして、イメージの乖離が無いようにしました。
②システム化したい事がシステム化されていない
◆事例
①を踏まえて要件定義書を作成、イメージを共有してシステムを作った後であっても、運用開始後に「〇〇が出来ない」とご指摘をいただいた。
◆どのように考えたか
・要件の取りこぼし＝プロジェクト担当者・開発者のイメージするゴールとシステム利用者のイメージするゴールに乖離がある(要件が漏れている)と考えました。
◆どう行動して解決、今後に結びつけたか
・要件定義の打合せの際に、ご担当者様にご協力いただいたうえで、システム利用者にも同席してもらい、現場の直の声を伺うことによりゴールのイメージ（実際の運用での使われ方や求める機能）をすり合わせるようにしました。
・要件定義書だけではなく、別途システム化する要件をまとめた一覧を作成しました。
この一覧のポイントは「システム化する事」だけではなく、「システム化されない事」も一覧に記載するようにしました。
「システム化されない事」を記載することにより、私だけではなく、プロジェクト担当者、システム利用者の全員に共有でき、新たな気づきが生まれるきっかけや、要件として漏れていた部分を発見する事ができました。
例)
【要件】
〇〇〇情報を入力、参照したい
【一覧】
〇〇〇情報を画面より入力可能とする
〇〇〇情報を画面より検索可能とする
〇〇〇情報にファイル入出力機能はない
というような場合に「ファイル入出力機能がない？データ沢山あって一括で入力したいのに！」
という要件が発覚し、要件追加、次の契約で開発する運びとなりました。
③既存システムの有識者が少ない
◆事例
歴史のあるシステムの改修を行う場合は既存システムの有識者がおらず、プログラムはスパゲッティ状態、仕様はブラックボックス、ドキュメントもあまり残っておらず、開発者側が色々な設計書、ソース、実際に動作させてみて確認し、なんとか開発を行う…
場合によっては、認識できていない機能と修正対象の機能が絡み合っており、障害となってしまった。
◆どのように考えたか
・調査期間を多めにとる必要があると考えました。
・自社以外に他社に有識者がいないかと考えました。
◆どう行動して解決、今後に結びつけたか
・見積もりの段階で難解であることを伝え、前提条件として調査期間を多めにとるようにしました。
・協力会社他、競合先問わずに有識者を募り、協力を依頼しました。
④スコープが広く、要件変更が多発する
◆事例
特に大規模なシステムの更改の場合、業務手順・フロー自体を根本的に変更する、それが複数部署にまたがり個別部署での要望が発生する、機能の統廃合が必要になる…など、スコープが定まらず、要件変更が多発する。
◆どのように考えたか
・プロジェクト体制、役割分担/責任者の明確化とＷＢＳへのクリティカルパスの設定によってプロジェクト全体のコントロールが必要不可欠である。
・既存業務、機能の運用を理解し、担当者、ユーザー様とのギャップが無いようにする必要がある。
・システム更改後に、既存システムで出来ていたことが担保する必要があるものなのか、
担保する必要が無いものなのかを明確にする必要がある。
◆どう行動して解決、今後に結びつけたか
・既存業務機能で使いづらかった所、運用してこういう事がしたかった等の情報をヒアリングして整理して運用の理解を深め、システム更改後にヒアリング内容が網羅できているかの整理を実施しました。
・「既存業務機能」「システム更改後の業務機能」をマトリックス化し、業務機能を担保するもの、しないものを明確化しました。
おわりに
弊社はこれまでに様々なユーザ様のシステム開発を要件定義から携わらせて頂きました。
運用に則したシステム開発はもちろんの事、システムが運用を変え、効率化を図る意気込みで取り組んでおります。
「業務をシステム化したが思った通りのシステムとならなかった、システム化したが効率化の効果が得られなかった」などでお困りの際は弊社にぜひご相談ください。
記事 ： K.M
