要件定義

要件定義はシステム開発費用の10%前後を占める

  • このエントリーをはてなブックマークに追加

「システム開発の見積もりで、実際の開発以外も結構費用かかるな」
「要件定義はシステム開発の見積もり全体のどれくらいの割合を占めているのだろう」

こんな疑問を持ったことはないだろうか。

実際、システム開発における見積もりをとると仕様策定などの名目で結構まとまった額を請求されることがある。

この記事では要件定義の見積もりの相場と、その内訳(何にどれくらいの費用がかかるのか)を解説していく。

また、システム開発者として何件も要件定義やその後の工程を担当してきた経験から、要件定義を外注する際に是非とも注意してほしいポイントを3つ紹介した。

この記事が、読者の方が納得してシステム開発を発注することに貢献できたら幸いだ。

1 要件定義の見積もりは全体の10%前後

要件定義はシステム開発費用全体の10%前後になるのが相場だ。

そもそもシステム開発における費用はそのほとんどが人件費である。

そして、要件定義はビジネスとシステムの両方に対する高度な理解があるハイレベルな人材が担うことがほとんどだ。そのため、総工数(工期 x 担当人数)的には他の工程と比べて少ないが全体の10%前後の費用がかかっている。

全体的なシステム開発費用の内訳は以下の通りだ。

2 要件定義の見積もりの計算方法を具体例を用いて解説

この章では、要件定義の費用が何にどれくらいかかるのかを具体的に説明していく。そのため、開発工数4ヶ月で500万円の案件を例に解説する。このプロジェクトの場合、要件定義にかかる費用は前開発費用の10%だと50万円と言うことになる。

2-1 「開発目的の整理」に10%の工数を利用する(5万円

この段階は発注者側が持っているシステム開発の目的や要求から、それを整理し開発の大枠の方針を打ち出すために使われる。

具体的には以下のように背景や課題感を整理し直し、やること・やらないことを大枠で定めていく。

2-2 「業務要件の特定」に40%の工数を利用する(20万円

この段階は前のステップで決められたシステムの大枠をもとに、システムの利用者の利用フローと要件を定義していく。一般的に成果物としてはシステム利用フロー図が作られる。

2-3 「機能要件の特定」に40%の工数を利用する(20万円

この段階は前のステップで作成された成果物に整合する形で、必要な機能のリストを作成する。

一般的には、以下のようなユーザーストリーをより詳細化したユーザーストーリーマップが成果物になる。

2-4 「非機能要件の特定」に10%の工数を利用する(5万円

この段階ではシステムの機能以外の要件を特定する。例えば、セキュリティや、稼働時間、障害発生時の体制などである。

3 要件定義を外注する際に、適切な見積もりをとるために知っておきたいこと

要件定義を外注する際に知っておいてほしいことを以下の観点で3つまとめた。
・外注する前に自社でやっておくべきこと
・外注する先の担当者の適性
・外注する工程

続く章で詳しく解説していく。

3-1 要件定義を外注する前に、システム開発の背景と要求事項は明確にするべき

要件定義を外注する前に、自社でシステム開発の背景と要求事項は明確にしておくべきである。これは「要件定義を外注する前に自社でやっておくべきこと」という観点でのポイントだ。

要件定義にはシステム開発の背景を整理し直し、要求を精査するという工程がある。要件定義を依頼する外部の人間に対してシステム開発の背景と要求事項を明確に共有できなければ、この工程がスムーズに進まない。

もしここの整理からやるとなると、当然要件定義の費用は嵩んでしまうことになる。そうならないためにも、自社でコントロール可能な部分はしっかりとやっておきたい。

3-2 要件定義はシステム開発経験者に頼むべき

要件定義を外注する際は、システム開発経験者に対してお願いするべきである。これは「外注する先の担当者の適性」という観点でのポイントだ。

要件定義はビジネスに対する理解だけではなく、システムに対する理解も求められる工程である。そのため、システム開発経験者に頼むのが良いということだ。むしろ、システム開発経験者でないと要件定義を効果的に行えないといった方が良いかもしれない。

システム開発に詳しくない人が要件定義をすると、「できない」ことが「できる」として要件になったり、やるべきことの工数がわからないために風呂敷を広げ過ぎてしまう事態になりかねない。その結果、要件定義の次の工程である設計工程で、システム開発者から要件に対して見直しの依頼が入ることになる。つまり、手戻りが発生するので無駄な工数が発生してしまうのだ。

実際、以前のプロジェクトでの話である。そのプロジェクトは、複数のサービスを一つに統合するというプロジェクトだった。要件定義はエンジニア経験がない方が担当していた。

その結果こんなことが起きた。前提の確認が漏れていた部分があったために、開発工数が当初想定から大幅に超過した。また、システムの裏側の作りが把握できていなかったために、要件定義時に決めた機能一覧のうちの一部にとてつもない工数がかかることが後になって判明し、結局リリース時には機能を一部削減する必要が生じた。

3-3 要件定義と設計の両方を請けてくれる人に頼むべき

要件定義を外注する際は、要件定義と設計の両方を請けてくれる人に頼むべきだ。これは「外注する工程」という観点でのポイントだ。

要件定義と設計は簡単に切り離して考えられない。さらに、両者を切り離した瞬間に要件定義をする担当者が要件について考え抜く圧力が無くなり、成果物が中途半端なものになってしまう可能性が高まる。

要件定義と設計の担当者が異なる場合、要件定義で決める開発内容と、設計をするのにインプットとして必要な開発内容の抽象度が合わない可能性があるからだ。つまり、要件定義で決めることが抽象的過ぎて、設計段階でも開発内容を具体化する作業が発生するということだ。

例えば、前の章でも紹介した複数サービスの統合案件でこんなことがあった。このプロジェクトでは要件定義と設計の担当者が分かれていた。

要件定義フェーズはかなりスムーズに前倒しで終了し、ざっくりと「サービスを統合する」という内容で合意されていた。

しかし、設計フェーズに入ると統合する部分と統合しない部分を精査する必要があったり、統合するためには開発側ではなく運営側に調整作業が発生したりした。結果として、設計フェーズは本来設定されていた期間を超過せざるを得なくなった。

つまり、後続の作業に責任を持たなくて良くなった瞬間に、先行する作業はいかに早く終わらせるかにフォーカスが入ってしまう。そのため、質の担保が難しくなるのだ。

まとめ

要件定義の見積もりについて、相場はシステム開発費用の10%程度であることをその内訳とともに紹介した。

また、要件定義を外注する際の注意点も3つ紹介した。

要件定義はシステム開発の成否を決める一番重要なフェーズである。そのため、読者の方がこの記事を参考にして、良いシステム開発者に要件定義をお願いできるようになれたら幸いだ。

  • このエントリーをはてなブックマークに追加