【システム開発・アプリ開発】公共機関が作った要件定義書は〇点！？13種の要件定義書を比較！【生成AI】

システム開発やアプリ開発において、要件定義書を作成します。
要件定義書の書き方などがわからない場合、ウェブサイトや書籍で調べると思いますが、そこに書かれている内容は一般論としての内容であるため、「自社のシステムに適用した場合どのように書けばいいのかわからない…」というお悩みはありませんか？
もし、実際の要件定義書が見られたら参考になるかもしれませんが、基本的に機密情報が入っているため公開されることはありません。

しかし、実は本物の要件定義書を確認する方法があります！

本投稿では、本物の要件定義書の見つけ方を解説しております。
また、13種の要件定義書の比較やChatGPTを使用して内容の評価も試しております。

要件定義書についてお悩みの方はぜひ最後までご覧ください！

※このコラムの内容は動画で公開しています。Youtube版はこちらをご覧ください。

要件定義書とは

要件定義書は発注者と開発者との間での合意を取るための重要な文書です。システム開発の成功の大部分を担うと言っても過言ではありません。システム開発においてとても重要な文章です。

要件定義はベンダーと行うことが多い

要件定義は、ITベンダーと一緒に行う場合が多いです。ITベンダーがその作業の舵取りはしてくれます。とは言っても、発注者側としても要件定義における最低限の知識を身につけることで、システム開発のプロジェクトの成功率を向上させることは間違いありません。

要件定義の内容について

要件定義で決めるべき内容などは、書籍やウェブサイトなどで情報を調査すると、基本的な内容やそれに関する解説というものは見つけることができます。
（要件定義に関する過去の投稿はこちら
→新規事業向けシステム開発の要件定義の極意 Part1【要件定義で行う作業の流れ】
→【ChatGPT活用】生成AIで要件定義はできるのか？【システム開発】）

しかし多くの場合、それらの情報は一般論としての説明なので、自社のシステムにどう適用すれば良いのか分からないと思います。これは発注者のみならず、SE経験が少ないエンジニアもそうでしょう。しかし、もし本物の要件定義書を見ることができれば、書き方のイメージも湧いてくるに違いありません。

ただ、通常要件定義書を公開しているような企業はありません。むしろNDA（秘密保持契約）を締結した上でITベンターと作成するような機密情報の類だからです。

本物の要件定義書から学ぶ

本物の要件定義書の入手方法

本物の要件定義書は一体どこにあるのか。実はこれ、企業の要件定義書ではありません。公共機関が入札などで使った際の要件定義書なんです。

実際に「要件定義書　省庁」と検索をしてみると、色々出てきます。

例えばこの経済産業省、次期Gビズインフォの構築・移行要件定義書というものをクリックしてみると要件定義書が出てきます。他にも、「要件定義書　市役所」で探してみても出てきます。

今回このような具合に、ネットを使って省庁や市役所などのシステム開発やアプリ開発の要件定義書を13見つけてきました。ネットで見つけた13の要件定義所の一覧がこちらです。

どれも同じ要件定義書とは言いながらも、これだけのページ数の違いがあります。ただ一概にページ数で比較できないのは、例えば横浜市の場合、別添えの資料が用意されています。たつの市においても同様です。

本物の要件定義書の章立てを比較

ではそれぞれの要件定義書において、どのような章立ての違いがあるのかを見ていきましょう。
以下は、各要件定義書の章立てだけを抜き出したものです。（編集の都合上、小さすぎ見づらくて申し訳ありません。Youtube版でご覧ください）

ざっとご覧いただいただけでも、同じ要件定義書と言いながら、かなり章立てが異なっているということがお分かりいただけたかと思います。

前項の表にある各ページ数ですが、やはりページ数が多いものについては章立ても多くなっているというのが実態です。国土交通省の建設キャリアアップシステムや、国際協力機構の新派遣システムの設計開発及び運用保守業務に関する要件定義書においてはどちらも100以上の項目に及んでいるということがわかります。

要件定義書に共通して記載されている章立て項目

開発するシステムの規模や内容によって、要件定義書の項目が変わってくるということは想像できるかと思いますが、13の要件定義書を比較した際に、どの要件定義書にも書かれている内容というものがあります。それは以下の3つです。

1. 業務要件
2. 機能要件
3. 非機能要件

実際に見てみましょう。

黄色の印をつけたところが上記3つの定義です。それぞれの定義の中での細かさというものは、システムの規模によって内容は変わってきます。実際このシステムのように、これだけ多くの定義がされていますが、では「全てのシステムにおいてこれだけの項目が必要か」というと、それは必ずしもそうではありません。

例えばこの建設キャリアアップシステムにおいて、登録機能者数・登録事業者数・現場契約登録者数・現場契約登録数などがありますが、システム利用者の規模という意味では書かれていて欲しいところではありますが、じゃあこの項目がそうかというと、これはあくまでもシステム独自の項目ですよね。

その他のシステムにおいても同じです。調達・派遣業務部内とか業務部外とか、これはこのシステム独自のものですから、必ずしもこの項目が他のシステムにあるということはありません。

開発とサービス導入

システムを開発する場合と、存在しているサービスを導入する場合とでは書き方も変わってきます。しかし、もしできればなのですが、ゼロから開発する場合を想定して要件定義をしておけば、開発の場合であっても、サービスを導入する場合であっても利用することはできます。とはいえ予算も決まっており、導入するシステムが汎用的なものであるならば、最初から既存のウェブサービスを導入するということが決まっているというケースも多々あります。

要件定義書のユニークな点

これらの要件定義書を見た時に見つけたユニークな点をいくつかご紹介します。
まずは国道交通省の要件定義書なのですが、そこにあったのがこの用語集です。

用語の定義というのは何気に重要です。発注者とITベンダーとの知識は違いますので、要件定義本文の前に用語を明確に定義しておくことで要件定義以降での勘違いなどを防ぎ品質を向上させることに役立ちます。これはぜひ定義しておいてもらえればと思います。

そして次はたつの市の要件定義書です。これは要件定義書だけで完結しておらず、仕様書・要件定義確認表・業務見積書という構成で、他の要件定義書と同じような内容を定義しているものです。例えば仕様書には、他の要件定義書の非機能要件で書かれていた内容が記載されていたりしますし、要件定義書は機能要件を主体にして書かれています。

そして佐賀市の要件定義書です。これはそんな大げさなことではないのですが、ここに書かれている「本事業における、システムの基本的な開発要件は以下のとおりとしますが、本事業の推進に効果的であると思われる独自の機能などがあれば、併せてご提案ください。」という一文。

発注者が要件定義書を作成することになった場合、有効な表現です。

それは自分たちで考えた要件で気がつかなかった点を見つけられる可能性もありますし、またベンダーからの提案力を図ることもできます。何気ない一言ですが是非これは添えておくのがいいかと思いますま。

また、これは直接要件定義書というわけではないのですが、筑西市のホームページにプロポーザル評価基準書というものがありました。それと評価項目一覧などです。このような内容に関しては、実際発注者がITベンダーを評価する際に参考になるのではないでしょうか。

AIで本物の要件定義所を評価する

では次にこれら13の要件定義書を、AIを使って評価させてみた結果をご紹介します。
その際使用したプロンプトはこちらです。

AIの評価結果

このプロンプトを使って要件定義書を添付して送った結果、AIがつけた評価点数はこちらです。

1つ以外は全て8.5という結果になりました。おそらく評価基準が明確ではなかったからなのかなと思います。これだと残念ながらあまり参考にはなりませんでした。

AIの総評

総評を見ると、実はこれらもどれも似たりよったりの内容でした。修正箇所の提案に関しても、どれも記載表現の修正案に留まっていて、こんな内容を追記すべきというようなものは残念ながらありませんでした。ただ、プロンプトを工夫すればもっと違う内容が返ってくるということは考えられるのですが、それはまた次回以降に試してみたいと思います！

まとめ

今回のまとめです。

企業の要件定義書は一般には公開されていませんが、省庁や市役所、公的機関の要件定義書はネットで検索すれば出てきますので、ぜひ一度検索し、本物の要件定義書の内容を読んでみて、自社のシステム開発の要件定義に役立ててください！