セルバのエンジニアが要求定義・要件定義で気をつけていることを徹底解説

こんにちは。代表の中山です。

セルバでは受託・自社サービス共にクライアントワークが多いため、ディレクターだけではなく、エンジニアもディレクション能力を向上できるような仕組みにしています。

評価制度の軸も、「一人で何人月規模の案件を任せられるか」に比重をおいています。

システム化する上で欠かせない要件定義について社内勉強会を開いており、今回はその内容を記事化しました。
少し長い記事となりましたが、要件定義をされている方、いずれは上流工程もこなせるエンジニアになりたい方はもちろん、付き合いのある開発会社がきちんと要件定義をしてくれているか見極めたい方も、ぜひ最後まで読んで役立ててください。

要件定義の流れ

要件定義の流れは、下記の図のようになることが多いです。

要件定義を行うにあたっての前提4つ

要件定義を行うにあたり、下記の4つは大前提として守りましょう。

これまでのやり方を周到する

各案件・各チームによって、案件発生から発注確定までに作成する資料・記入すべき資料があります。
まずはそれらがどのようなルールになっているか確認しましょう。

既存のシステムと先方の業務・立場について理解する

まず「既存システムがどんなシステムなのか」「先方の担当の業務チームの誰がいつ何をしているのか」は理解しておきましょう。
そこが不明なまま開発を進めてしまうと、先方の目的を汲めなかったり、担当者からなかなか返事が来なかったりと後々困ったことになります。

要件定義と見積もりを出したら、「先方の社内ではどういったフローで発注に至るのか」についても知っておきましょう。
もし失注したとしても、どの時点で躓いたのかがわかれば同じことを繰り返さずに済みます。

そのシステムで動いている他の案件について理解する

大抵のシステムは、既に同じ仕組みで動いているシステムが存在します。
特に自社が得意としている案件であれば、過去の実績で類似のものがある可能性が高いので、確認してみましょう。
自社の実績に近いものがなければ、他社の案件でもよいです。

あまり昔に作られたものだと、現在は使えなくなっている技術も多いので、現在進行形で動いている機能修正・新規機能開発がどのようなものであるか知っておきましょう。

誰にでもわかる言語で伝える

エンジニアにありがちなのが、クライアントがわからない専門用語を多用して説明しまうことです。
自社の業界やエンジニアの間では当たり前に使われている専門用語でも、エンジニアでない方や、他業界のクライアントからすると馴染みがないことも少なくありません。
逆に、クライアントとのやり取りで自分の知らない専門用語が出てきたときは、わからないままにしないことも重要です。

また、一見意味が通じているようでも「自社とクライアントで認識が違う」ということもあります。
なるべく専門用語は使わず、誰にでもわかる言語で伝えるようにして、認識違いが起きていると感じたら早めに確認しておきましょう。
過去のやり取りがテキストで残っているならそれを確認し、双方の認識を揃えます。

ここを怠ると、開発が進んで戻れない段階になってから「思っていたものと違う」となり、自社とクライアントの双方に損害が発生する可能性が高くなります。

要件定義は大枠から決めていく

要件定義を行う時は、いきなり細かいことから詰めてはいけません。
大枠から決めていき、最後に細かなところを決めます。

ここで重要になるのが大きな単位を細かく分けることと、その切り口です。

困難な案件だったとしても、上記のように分割してみると、どこが困難なのかがわかりやすくなります。

最終的にクライアントに提出する資料

新規のシステム案件では、以下のような資料を状況に応じて作成して、クライアントに提出します。
継続案件でも、場合によっては必要になることがあります。

案件やチームによって、内容のレビューが必要になったり、提出の方法は変わります。
上長とよく話し合った上で決めましょう。

概要書

「そもそも何の話なのか」ということをまとめます。
意外なことに、参加者によって『今回の話が何であるか』の認識が結構違うので、関係者全員が当然わかっているだろうという前提で進めるのは危険です。

現状分析と課題まとめ

「今のシステムの何が問題でリニューアルするのか」
「ご要望の新システムがなぜ必要なのか」
これらの意識を先方の担当者と合わせるようにします。

システムはあくまで課題解決のための手段であり、システムを導入すること自体が目的になっては意味がありません。

エンジニアの間で有名な「顧客が本当に必要だったもの」というシステム開発の要件定義の難しさを表した風刺画がありますが、あれはまさに現状分析と課題を明確にしていなかったから起こることです。

新システムを用いた業務フローの定義

先程の「現状分析と課題まとめ」とも繋がりますが、業務フローの全体を把握し、どの部分を新システムに任せるのかを定義する必要があります。
そのため、他の社内システムと連携する必要があることが多いです。

また、セルバではWebシステム（Webサイト）の開発を行っていますが、クライアントは「自分がサイトを運営する」という概念がそもそもないことも多いです。
Webサイトはリリースしたら終わりではなく、リリースしてからが本番ということも伝えておく必要があります。

業務要件定義、システム化の範囲

先程の「新システムを用いた業務フローの定義」と繋がりますが、業務フローの全体のうち、システムでどこまでできるようにするかを定義します。
システム化する範囲の認識は早めにクライアントと合わせておかないと、後から揉めることが多い部分です。

機能要件

「要件定義」と聞いて多くの人が想像するのはここではないでしょうか。
資料としては一番のメインとなる部分です。
（案件によって内容は変わります）

クライアントの「この機能が欲しい」という希望をそのまま実現しようとすると、予算内では実現不可能なこともよくあります。
そんなときでもクライアントの課題や業務フローが明確になっていれば、予算内で実現可能な別の機能を提案出来ます。

画面設計

「どのようなページにどのような内容をどのように掲載するか」「ページ内にこの内容を表示するならどのような機能が必要か」を定義します。

現実問題として『画面を見ないとわからない』と言われることが多いです。

システム設計

機能要件に合わせて、システムの設計をしていきます。

サーバーなどもここで提案します。
新規案件では、クライアントの方からサーバーを指定されることもあります。

非機能要件

機能以外の部分で、クライアントから要求されていることを明確にしておきます。

具体例を挙げると
『扱うデータが異様に多い』
『セキュリティーに非常にこだわっている』
『品質について証拠を求められている(第三者レビュー)』
などがあります。

ここも詰めておかないと後から揉めることが多い部分なので、言った言わないにならないようにしっかり詰めておきましょう。

前提条件・制約条件

得意分野や資格によって開発会社ができることは変わりますし、リニューアルの場合は以前のシステムにあった機能がなくなる（なくさざるを得ない）ことがありますが、クライアントがそれをご存知とは限りません。

などがありがちです。

前述の「業務要件定義、システム化の範囲」とも繋がりますが、今回作るシステムの範囲と、自社がどの業務まで担うのかを明確に定義しておく必要があります。

検収要件

納品時に、テスト仕様書の有無と粒度を確認されるケースがあります。
あらかじめ「こういうテストをします」とサンプルのテスト仕様書を渡しておくとよいです。

最終見積もり

先に概算見積もりを出すこともありますが、上記の全てをタスクとして見たときに出てきた項目をすべて列記し、それぞれに工数をつけます。
見積金額は単価×工数で決まるので、ここで最終的な見積もりをクライアントに提出することになります。

スケジュール

スケジュールは他の案件との兼ね合いもあるため、見積工数ベースではなくあくまで工期ベースで作成します。
現実的には一つの案件に1日の稼働時間すべてを使えるわけではなく、クライアントから差し込みで至急対応しないといけないタスクが発生することもよくあるので、それを見越してバッファ（予備の時間）を取ったスケジュールを組みます。

要求定義

要件定義の前に定める必要があるものとして、「要求定義」があります。
要件定義と混同されがちで少しややこしいですが、クライアントが望むシステムを作るためにも重要な過程になります。

要求定義とは

要求定義とは、簡単に言えば「クライアントの要求を整理して形にしたもの」です。

要求定義書は本来クライアントが出すものです。現実的にはプロジェクト管理ツールを通して先方が提示する内容です。
社内の事情や業務の都合を反映していただく必要があります。

過去に記録が残っていない状態で

と言われたことは多々あるので、口頭で解決していても記録するようにしましょう。
※複数案件が同時に走っている場合は、既にいただいている発注・検討中の要件とかぶっていないか要確認。

ポイントは今回の対応範囲を確定することです。
上記の例では一見すると代理店管理と代理店権限の話だと思われましたが、『代理店の営業成績』『企業サポート管理』といった代理店管理外に波及していないか確認しています。

このように、初見で想定した機能以上のものを求められているというのは非常によくあります。
発生する業務から、システムですべての業務が達成できるかよく検討しましょう。

議事録をとり、確認する

話の出発点は口頭であることも多いです。
電話やWEBミーティングで要望を仰った場合、『結局何の話だったのか』ということの無いように議事録を取ります。
そしてその議事録は関係者に必ず共有し、漏れや間違いがないか確認します。

先方に検討してもらいたいことをまとめ、先方に質問する

議事録やチャット、電話、メールなどで要望を告げられたとしても、『結局先方は何がしたいのか』がはっきりしないことが多いかと思います。
先方がおっしゃる内容が間違いなく理解できているか、すべて言語化できているか、よく確認する必要があります。

質問の粒度と回数はそのクライアントによります。これまでのやり取りを確認しましょう。

上記の例では「ああ、これは代理店権限がシステムを触るという話なのだな」と大枠がつかめたら代理店権限について詰めていきましょう。

要件定義

要求定義が済んだら、いよいよ要件定義に入ります。

要件定義とは

改めて要件定義とは、先方の要求定義に対し『実際に自社がやること』であり『見積根拠』です。

過去にも

と言われたことはありますが、セルバがクライアントに対してする契約の主体はあくまで要件定義です。
そのためにも必ず『要件定義が何であるか』は明確にする必要があり、見返せるようにしておく必要があります。
※プロジェクト管理ツールやチャットで、会話の流れで要件定義を行うこともあると思いますが「どの書き込みが要件定義であるか」は明確にしてください。

先方に完璧な要求定義書を作ってもらうのはさすがに無理があります。
先方の考慮漏れはすべて要件定義を作成する際にフォローしましょう。

要件定義をする前に確認すること

①実現性の確認

• 実装が本当に可能か、調査が必要ではないか
• 先方が望むスケジュールで完成するか
• スケジュール内のエンジニア、コーダー・デザイナーの予定は本当に空いているか

②上長に要求事項がまとまったこと、これから要件を作成することを報告

ここから先は契約の話であることを意識してください。
勝手に話を進めてはいけません。

③現在仕様の確認

仕様書だけではなく、コードから実装を見ておきます。

例えば、先程の例題のように「代理店権限を追加する」という話ならば、現在の権限管理がどうなっているか確認しておきましょう。

要件定義で記述する内容

要求定義から対応する機能を検討し、さらにそれらを整理・細分化していきます。
そのため必ず考え、記入する順番は1から順番に5へと向かいます。

また『こういう機能もいりそうだけど』というのが思いつくと思います。
①～⑤まで作成するのがあまり時間がかからないのであれば、一度要件定義に入れておき、先方に提案という形で説明します。
多くの場合、要件定義は1回で決まるものではありません。

自社の作業の範囲

必ず自社の作業範囲を明確にします。

例えば、デザイン・コーディングが別会社である場合、各ページの何がデザイン会社担当で何が自社担当であるかを明確にします。
先方がデザインを作ると言っている場合は特に要注意。
別会社が絡む場合、どのような開発であったかよくよく確認しましょう。
セルバの場合、デザインが他社担当であったときトラブルになりがちです。責任範囲を明確にしましょう。

よくあるけど忘れがちな要件

• テキスト変更に伴うレイアウト修正
• 仕様変更に伴うメール文面の変更
• GoogleSearchConsoleなど外部サービスの設定変更作業
• 既存データのコンバート作業
• 既存データに影響が出ていないかの検証作業
• クライアント以外の会社との打ち合わせ

見積もりの作成

見積もりの作成において重要となる「工数」ですが、こちらについては下記の記事でも解説していますので、合わせてご覧ください。

社内工数

まずは社内工数で考えます。
セルバでは3年目の技術者が対応した場合の時間で考えます。
特に機能要件の見積項目は、その機能が完成するまでの工数であるため、以下のような時間をすべて含みます。

社外工数

上記の社内工数が計算できたら、次に対社外工数を考えます。
基本的には社内工数を1.3倍にして算出しますが、これまでの状況を踏まえて余裕を持った工数を算出した方がよい場合もあります。
特に不確定要素がある場合、デザインが絡む場合は余裕を持った工数にすべきです。
また改修が既存機能に大きく影響を与える可能性がある場合は、確認工数を大きくとりましょう。

ただし、継続案件である場合、先方もそれぞれの機能がどれぐらいの見積もりになるか予測していることが大半です。
そこから大きく離れると指摘を受けることになります。
そのために過去同種の見積がどのような工数になっているか、よく確認しておくことが重要です。

実際にどのような項目にするかは案件とチームによりますので、他の見積もりをよく観察しましょう。

スケジュールの作成

工数の見積もりができたら、それをもとにスケジュールを組んでいきます。

工数ベースではなく、工期で考える

前述の通り、1日の稼働時間の全てをその案件のために使えることは稀です。
現実的には他の案件にも対応しなければいけないことがほとんどなので、その案件に全力投球しないと実現できないようなスケジュールはやめましょう。

リリース日の指定がある

ただ、そうは言っても先方の都合もあります。

案件によっては、これらを実現を約束することが発注条件になっています。
そうでなくても、ほとんどの場合リリース時期については要望があります。
リリース時期に制約があるかはよく確認しましょう。

スケジュール作成時に考慮すべきこと

ここでいうスケジュールとは、「発注をいただいてから、仕様作成～開発～社内確認～受入テスト～リリースのスケジュール」です。
スケジュールを作成するときは、下記について考慮しましょう。

スケジュールは発注日と着手可能日から考える

着手可能日までに発注日期限が自然と必要になります。
「このスケジュールはいつまでに発注された場合のスケジュールであるか」を明記しましょう。

何人で着手できるかを先に検討しておく

ある程度以上の規模である場合、複数人のアサインは可能であるか上司に確認を取りましょう。

社内テストの後、受入テスト期間を十分にとる

先方のテストとそのチェックバック対応期間は、過去の案件の実績からどれぐらいになるか検討しましょう。
またテストに何か条件が付けられている場合は、テスト条件を明確化しておきましょう。

例えば、代理店も実際に触って確認するような場合は、代理店のテスト期間の設定も必要になってきます。

リリースが先方の要望する期日に間に合わない場合

先方の要望する期日にリリースするのはどうしても間に合わない、ということがわかった場合、下記のような「間に合わせるためにできる対策」があれば提案しましょう。

現実的にどうやっても間に合わせることが無理な場合は、交渉が必要になります。
その場合は、下記について交渉してみましょう。

見積書と要件定義の提出

スケジュールが組めたら、いよいよ見積書と要件定義をクライアントに提出します。

クライアントに提出前に上長に確認してもらう

クライアントに提出する前に、見積もりの内容・金額・スケジュールの確認を上長にしてもらいましょう。
場合によっては、先方への説明の機会を設定してもらう必要があります。

クライアントに提出する

提出と言っても、ほとんどの場合はプロジェクト管理ツールやチャット等にやり取りの一環として内容を記述することになると思います。
ただし、画面イメージ主体であったり、表を用いたほうが説明しやすい場合はエクセルなどの他の資料を用いるとよいでしょう。
各チームがこれまでどうしているかを確認し、先方が最も理解しやすい方法を選択してください。

提出した見積はどのチームも何かしらの手段で管理していると思います。
そのチームのルールに則り、提出済みの見積リストに追記しましょう。

見積書と要件定義を受け取った後、先方は何をしているか

ほとんどの会社は発注をすぐには出来ません。
社内の他のすべての見積もりとの優先度を決めて、発注したい案件をまずは社内稟議にかけます。
担当者の上司、部長、経理等がOKを出して、初めて発注が可能となります。

逆に言えば、あなたが作成した見積書、要件定義、スケジュールは先方の担当者がこれらの人を説得する資料として使われます。
あなたが提出した相手である担当者が内容を理解していなければ、上司等を説得するなど出来ようもありません。
提出した資料は単なる事実確認ではなく、様々な権限者を説得するための資料であることを意識しましょう。

まとめ

要件定義をミスすると、自社・クライアントの双方がシステム構築費用と費やした時間を無駄にします。
今回紹介したポイントを意識して、ぜひ要件定義に取り組んでください。

セルバでは無料相談を実施しています。
今まで70件以上のポータルサイトを構築してきた実績があり、その中には月商5億を超えるサイトもあります。
また、自社で運営している「セルワーク薬剤師求人」でも、1年で売上を月200万円⇒700万円にした実績があります。

まだ構想段階でも歓迎していますので、WEBサイトの立ち上げについてはこちらからお問い合わせください。

また、今回の記事を見て開発会社選びに不安を感じることもあると思います。
そんなときはセルバまでお問い合わせいただければ、開発会社の選定代行を無料でさせていただきます。