要件定義・基本設計の流れ、意識すること

この記事では、システム開発における要件定義・基本設計フェーズの流れと、意識することについて紹介します。

基本的なプロジェクト進行の手順と、対顧客との折衝を中心に扱っています。

ずばり、プロジェクトが炎上する確率を減らすために気を付けていることをまとめました。

これまで私がプロジェクトリーダーとしてアサインしたプロジェクトでは、大きな問題を起こすことなくシステムを納品できています。
（炎上したことがないとは言っていないです）

プロジェクト毎に優先事項やメンバーのレベルなど、状況は異なるものですが、この記事で紹介するポイントを押さえてプロジェクトを運営することで、プロジェクトが炎上する確率を低減できると考えています。

（とはいえ燃えるプロジェクトは燃えるので、意識しないよりは絶対マシ！ってくらいです）

【超大事】顧客との合意形成を取ること

上流工程で顧客にしっかり工数をとってもらい、要件・仕様を策定していきましょう。

要件定義・基本設計フェーズで取り決めた内容に不備がある場合、非常に高確率でプロジェクトは失敗となります。
要件定義で取り決めした内容が正しくない場合、最終的に開発したものが顧客と求めるものと全く違い、初めから作り直し。

責任の押し付け合いから最悪、法廷闘争に発展、なんてことも。。。

後から仕様変更が発生するのを抑えるためにも、顧客にしっかり検討してもらって仕様を決定していくべきです。

具体的には

開発工程以降で手戻りが出た場合は、貴社の負担も増えますので、なるべく上流工程でしっかり検討してください。

と上流工程の打ち合わせの初めに顧客の責任者に向けて説明しています。

こちらの都合だけ押し付けるのではなく、あくまでお互いにメリットがあることを伝えましょう。

また、実際に私はドキュメントの作成スケジュールが多少タイトになっても「打ち合わせの場で初めて話した内容についてはその場で決定させない」ことを徹底しています。

その場の顧客担当者の思いつきで決めた内容は、あとからひっくり変えることが多いためです。

アジェンダを事前に共有して、打ち合わせ前に検討が必要な議題については、一度顧客の社内で議論したうえで打ち合わせに臨んでもらうようにします。

これで下流工程以降の仕様変更がゼロになるとは言いませんが、上流工程で時間を取って検討することで顧客との関係構築ができるため、良い方向に働くことが多いと思っています。

ちょっと説明するだけでプロジェクトの成功率が上がる（炎上する率が下がる）ので、おすすめです。

基本的な要件定義の進め方は以下の通りです。

ちなみに、要件定義の成果物は「要件定義書」「業務フロー図」など、基本設計の成果物は各種基本設計書です。

サンプルやテンプレートなどは検索すればいっぱい出てきます。

「成果物」という言い回しをしていますが、「納品物」と呼んでいる開発会社もあります。
この辺りの話は要件定義の進め方とは別の話題ですので、別の記事にしますね。

①要望をヒアリング

初めに、顧客がどのような課題を抱えていて、どのように解決したいか確認します。

基本的に初回のキックオフの打ち合わせに、プロジェクト計画書を持参して読み合わせします。

基本的に要件定義前の営業段階で自社より何らかの提案をしていることが多いので、こちらから提案の内容で間違えないか確認する形になる場合もあります。

その辺りは事前に営業担当に確認するか、提案資料を確認しましょう。

個人的な感覚ですが、提案の内容とシステムにより実現したいことはずれがあることが結構多いです。

開発会社の営業のやり方などでも違いがあるかもしれませんが、変に認識にずれがあるまま進んで顧客との関係がこじれるよりは、確認しておくに越したことはないでしょう。

その他、いつごろからシステムを稼働したいか（納期）顧客の担当者が誰かなどについても確認します。

②業務フローを整理

AS-IS/TO-BEなどとよく言われていますが、現在どんな流れで業務を遂行しているところを、どのように変えるのかを資料に書き起こします。

要件をヒアリングした際の課題の掘り下げと、プロジェクトによって課題を解決した後の業務の流れを明確にすることで、プロジェクトのゴールを顧客と共有します。

大事なのは、顧客との間で現在の課題とそれを解決した業務フローを明確にすることです。

資料を作ったら顧客が勝手に確認してくれる！という考えは危険です。
ここですれ違いが起きていると大問題に発展する可能性が大です。

現在の業務フローのヒアリングして、課題を洗い出してから、それを解決する業務フローを書き出して、顧客とすり合わせしましょう。

私の勤務している会社では、よく簡単なフローチャートに書き起こして顧客と共有しています。

フローチャートに書き起こすことで、システムで担当することとシステム外の業務を明確にできるので便利です。

ただ、例えばシステム系でない企業が顧客の場合には、フローチャートに馴染みがない場合があります。
その場合は、文章に書き起こすなどした方がよいですね。

③非機能要件などを整理

これまで説明した、いわゆる機能要件に含まれない、システムの品質やセキュリティに対する要求は、非機能要件と言います。

具体的にはWEBシステムを構築する際のレスポンスにかかる時間や、システムが安定稼働する期間などがこれに当たります。

私の感覚的には大手のSIer案件の要件定義時にはしっかり扱いますが、中小のベンチャー企業の案件では、基本的に各ベンダーでテンプレートがあったり、場合によってはないこともあるかもしれません。

開発するシステムの属性によっては必ずしも大きな意味を占めるわけではないことが、比較的おざなりになりやすい理由でしょうか。

ベンダーの観点でいえば、納品後にシステムの品質が悪いとして、クレームの原因になりうるので、このタイミングでしっかり議論して、文章化しておいた方がよいです。

（文章化するとそれを満たさないといけなくなるので、トレードオフではあるんですけどね）

④要件・機能を文章化

ここまででまとめた要件を文章にまとめて、顧客と確認します。

具体的には、このタイミングで要件一覧を書き起こして顧客と共有しましょう。

開発する機能の単位で要件一覧に書き起こして、それぞれどんなことをする機能か、開発の規模感や重要度をまとめます。

あとで予算との兼ね合いで、機能を削減する必要が出た場合などに調整がしやすくなるので、一覧化しておくと便利です。

要件一覧を作成したら、顧客とのレビュー会を行います。

要件一覧の内容で問題ないか顧客に確認し、合意を取っておきましょう。

⑤基本設計

ここまでで洗い出した要件に従って、機能ごとに仕様書に書き起こして顧客と認識合わせをします。

私のところでは、基本的にWEBシステムの開発案件に携わりますが、「画面仕様書」「帳票仕様書」「インターフェース仕様書」「システム基盤仕様書」などを作成しています。

各仕様書の詳細については別に掘り下げて説明記事を書きますね（多分）

フルスクラッチの案件だと、このあたりで並行してフレームワーク等のミドルウェア選定も実施します。
JavaならSpring、Jakarta EE、Strutsあたりが有名どころです。

基本設計では、これ以降のフェーズで手戻りを低減させるために、各機能ごとに課題、不明点などをこちらで事前に予測し、ヒアリングを実施することが大切です。

ただ作った仕様書を持ち寄って、読み合わせするだけでは、顧客からフィードバックをもらえない場合も多々あるため、こちらから質問する形式にした方が後のフェーズでの手戻りを少なくできます。

また、こちらで疑問点を事前に用意してヒアリング形式にすることでコミュニケーションが生まれるため、顧客との関係構築を補助する側面も期待できるのでお勧めです。

質問が出なかった＝仕様書の内容で顧客は納得した、
ではないので、顧客からの質問がなければ、説明の内容を理解いただけていない可能性を考えましょう。

まとめ

以上、要件定義・基本設計の流れ、意識することでした。

大事なのは、プロジェクト初期の段階で顧客の担当者にも当事者意識を持ってもらって、こちらの提案を聞いてもらうだけではなく、しっかり検討してもらうことです。

要件定義・基本設計はミスっていると致命的な場合が多いので、慎重に進めていきましょう。

私個人の印象では、うまくいかないリーダの案件では、顧客に対して淡々を対応をして、関係構築がうまくいかないことが多い様に思います。

その結果、正確な顧客の要望をヒアリングできず、的外れな要件定義・基本設計を行ってしまい、後々それが発覚する。。。
みたいな。

もちろん顧客との関係構築ができなくても、うまくいく案件はもちろんあります。

顧客の責任者がまともにこちらとコミュニケーションを取ろうとしない場合もありますが。プロジェクトの成功率を上げるためには意識しておいた方がよいですよ。

炎上プロジェクトを減らすべく、気を付けてプロジェクトを運営していきましょう！