こんにちは、Webディレクターの因幡です。
私はこれまでに、数多くの企業様のWeb制作やシステム開発プロジェクトに携わってきました。
その経験のなかで痛感しているのが「要件定義」の大切さです。Web制作プロジェクトでは必ずおこなう作業ですが、この要件定義を適切におこなえるかどうかで、プロジェクトの結果が左右されるといっても過言ではありません。
今回は、そもそも要件定義とは何なのか、一般的な流れやおこなう目的について解説したうえで、適切に要件定義をおこなうための5つのコツについて説明します。
※当記事は2022年6月22日に開催したセミナー「IT苦手なあなたでも円滑にシステム要件定義をするコツ」の登壇内容を文章化し、一部改変したものです。
目次
要件定義とは？
要件定義とは、Web制作やシステム開発プロジェクトを進めるにあたり、「何を実現するのか」を明らかにする工程です。プロジェクトの一連の流れのなかで、具体的な制作作業に着手する前に取り組むことが一般的です。
プロジェクトの具体的な流れを例に挙げると、次のようになります。
- 企画・提案
- 要件定義
- 設計
- 制作・開発
- テスト
- リリース
- 保守・運用
プロジェクトの規模によって、要件定義に要する時間は異なります。数週間で完了することもあれば、大規模プロジェクトの場合は数ヶ月かかる場合もあります。
要件定義のプロセスとゴール
一般的な要件定義の流れをご説明します。
まず、プロジェクトの責任者であるプロジェクトオーナー（LIGのような制作会社の場合、お客様がこれにあたります）から、「要求」をヒアリングします。その要求を実現する方法を考え、プロジェクトオーナーに「提案」します。その際の提案内容を記載したものが、要件定義書の草案にあたります。
提出した要件定義書の草案に対して、プロジェクトオーナーからフィードバックを受けたら、その部分を見直し、「再提案」します。プロジェクトオーナーの要求を満たせる要件定義書が完成し、すべての記載内容に対して承認を得れば、要件定義書の完成です。
この「要件定義書の完成」および「プロジェクトオーナーによる承認」が、要件定義というプロセスにおける物理的なゴールです。
良い要件定義とは？要件定義の3つの目的
では、要件定義の物理的なゴールを達成すれば、それは「良い要件定義ができた」と言えるのでしょうか。
実は、そうではありません。定番のフォーマットでそれらしい資料をそろえれば要件定義書は完成しますし、プロジェクトオーナーの承認も得られるかもしれません。しかし、それでは良い要件定義ができたとは言えないのです。
良い要件定義をおこなうには、要件定義の本来の目的をきちんと果たすことが重要です。要件定義の本来の目的とは、次の3点です。
目的1. プロジェクトにおける実現内容ついて、メンバー共通の認識を持つ
プロジェクトには多くのメンバーが関わります。プロジェクトオーナーを筆頭に、ディレクター自身はもちろんのこと、デザイナー、フロントエンドエンジニア、バックエンドエンジニア、インフラエンジニア、ライター、フォトグラファー、イラストレーターなどなど、各分野のプロフェッショナルが集います。
もし、これらのメンバー間でプロジェクトに対する認識が共有できていないと、のちの工程のどこかでトラブルが発生する確率が高くなります。
たとえば、設計を終えて制作・開発に着手するタイミングで、エンジニアから実現性に無理があることを指摘されたり、開発を終えてプロジェクトオーナーに見せた際、「イメージと違う」と言われたりするかもしれません。
そのようなトラブルは、要件定義の段階でしっかりとメンバー間の認識を合わせていなかったから起こることが多いのです。プロジェクトを成功させるためには、要件定義資料やコミュニケーションを通して、メンバー全員が同じ実現イメージを持てるようにすることが大事です。また、「実現すること」だけでなく、「実現しないこと」も同時に明らかにしておくと良いでしょう。
目的2. 実現内容が、ビジネス上の目的に沿っているかを検証する
要件定義では、「実現すること」の内容について、それがビジネス上の目的を果たすうえで適切か、あるいはビジネスを成り立たせるうえで過不足がないか、を精査する必要があります。
この点をしっかり検証しておかないと、プロジェクトの進行とともに要望がどんどん増えてしまい、収拾がつかなくなる恐れがあります。
企業がWebサイトやシステムを開発するときには、必ずビジネス上の目的があるはずです。たとえば、プロモーションやブランディング、売上の創出、業務効率化などです。そういった目的を見据えて、「目的に対して実現内容が適切か」「優先順位は整理できているか」という点は常に意識しましょう。
目的3. 実現に必要なコストを算出し、実現性を精査する
プロジェクトを実現するには必ずコストがかかります。ここでいうコストとは、費用、期間、人的リソースなどすべてを含みます。また、クリエイター側（制作会社側）だけでなく、プロジェクトオーナー側（お客様側）に発生するコストもあります。
当然ですが、リソースが不足していればプロジェクトはうまくいきません。コストを算出した結果、予算や期限からはみ出してしまう場合は、収まるように実現内容を見直す必要があります。
要件定義の隠れた4つめの目的：チームビルディング
前項で説明したとおり、要件定義には3つの重要な目的がありますが、それらの目的を果たす過程で常に意識すべき、隠れた4つめの目的があります。要件定義を進めるうえでのコミュニケーションを通して、プロジェクトに関わるメンバー間で良質な信頼関係を築き、チームビルディングすることです。
プロジェクトオーナーからクリエイターまで、意見や質問を遠慮なく交わし、課題を迅速に共有できる関係を築き、プロジェクトをスムーズに進行するための土台を作りましょう。
要件定義における5つのコツ
では、良い要件定義をおこなうには、どのような点に注意すべきなのでしょうか。ここでは、重要な点として5つを紹介します。
1. まず外堀を埋める
「外堀」とは、制作物そのものではなく、その外側にある要素のことです。Web制作プロジェクトにおける要件定義では、ついつい「画面仕様書（ワイヤーフレーム）」や「機能仕様書」をいきなり作ってしまいがちです。しかし、それは「何を作るのか」を決めているだけであって、要件定義の本来の目的である「何を実現するのか」ではありません。
そこで、まずは制作物の外側の世界から要件定義を始めます。どんな人が関わり、どんなビジネスで必要になるシステムなのか。この点を明らかにしたうえで、制作物の内容に入っていくのです。
外堀を明らかにするための手法としておすすめするのが「ビジネスモデル図」、または「システム全体図」を作成することです。誰がシステムを管理し、誰が顧客となって、どのようにお金や商品が動くのか。そのビジネスの中でシステムはどんな役割を果たすのか。そのような全体図を作成し、ビジネスモデル全体を把握するところから始めましょう。
このとき、ポイントになるのが「自分自身がシナリオライターになったつもりで考える」ことです。ビジネスの流れをストーリーとして捉えて整理することで、ドラマの人物相関図のような図が完成します。すると、ビジネスの全体像を把握しやすくなり、具体的にどこにどんなシステムが必要なのかがイメージできます。
また、ビジネスモデル図を作成することで、プロジェクトオーナーがクリエイター側に伝え漏れている事実に気づけることもあります。
もう1つのおすすめなのが、「業務フロー図」を作ることです。業務フロー図とは、「人やシステムが何をするのか」を書き起こした図です。たとえば、「ユーザーがログインページにアクセスしたら、システムがログインフォームを表示する」、「ユーザーがIDとパスワードを入力したら、システムAがシステムBに問い合わせをおこない、システムBがIDとパスワードの検証結果を返答する」といったような流れです。必ず「人」か「システム」が主語となり、「人の業務（行動）」か「システムの業務（処理）」が述語となります。
この工程もまた、シナリオライティングに例えることができます。少し違う点があるとすれば、行動／処理結果によって分岐パターンがあるなら、それも明らかにする必要がある点です。
業務フロー図を作成することで、ビジネスが成立するためには、人やシステムがそれぞれ何をすればいいのかを洗い出すことができます。つまり、「運用に必要な人的リソース・体制」と「システムに必要な機能」が明らかになります。
2. プログラミングとは何かを知っておく
多くのWeb制作・システム開発においては、エンジニアによるプログラミングという工程が必要です。ディレクター自身がプログラミングをできる必要はありませんし、私もできませんが、「プログラミングとは何か」という点は理解しておく必要があります。
プログラミングとは「コンピュータシステムに渡す業務マニュアルを書く作業」だと考えてください。システムに対して「こんなときは、こうしてね」という命令を事細かに漏れなく書いていくことがプログラミングなのです。ただし、コンピュータは人間の言葉が理解できませんから、コンピュータにわかる言語で書く必要があります。これが、プログラミング言語と呼ばれるものです。
ここで、注意したいのは、「システムが何をするべきなのかを考えるのは、必ずしもエンジニアの作業ではない」ことです。というのも、プログラミングには大きく2つの工程があります。
1つは、「システムに何をさせたいのか」を考えること。もう1つは、システムにさせたいことをプログラミング言語で記述することです。この2つは別のスキルであり、必ずしも1人のエンジニアがどちらも得意としているとは限らないということに注意が必要です（ちなみにSler業界においては前者をシステムエンジニア、後者をプログラマーと呼ぶことが多いようです）。
制作・開発に携わるエンジニアに実際どこまで依頼できるのかを、ディレクターがしっかり把握している必要があります。ここに認識の齟齬があると、プロジェクトは円滑に進みません。
よくあるケースとしては、「システムに何をさせたいのかを考える」作業について、ディレクターはエンジニアがやってくれると思っていて、エンジニアはディレクターがやってくれると思っていたりします。すると、非常に大事な作業を、気づいたら誰もやっていないという事態が発生します。
理想的なのは、ディレクターとエンジニアが協力してこの課題に取り組むことです。実際のところ、「システムに何をさせたいのかを考える」にあたっては、エンジニア・非エンジニアの両方の目線が不可欠なのです。
3. 技術用語に依存しない
良い要件定義のポイントとして、「メンバー全員が共通認識を持つ」ことが大切だと述べました。そのためには、なるべく難しい技術用語を使わないことが大事です。
たとえば、「CMS」という言葉であれば、「CMSを導入します」だけではなく、「サイトの一部を、専門知識がなくてもブラウザから編集できるようにします」というような表現を加えるといいでしょう。
誰もが同じように理解できる表現を用いることで、認識齟齬のトラブルを避けられます。
4. 作った経験よりも使った経験を活かす
Webサイトの制作経験やシステム開発の経験はもちろん大事ですが、もっと大事なのは自らがユーザーとして使った経験を活かすことです。たとえば、ECサイトであれば、自分がユーザーとして登録・利用し、手続きの流れや傾向をつかんでいることは何よりも武器になります。
また、要件定義の際、事例を挙げてゴールを探っていく手法も有効です。たとえば、「あのサイトみたいにしたい」という意見がプロジェクトオーナーから出て、自分がそのサイトを使ったことがあれば、ユーザーの視点から良い要件定義をおこなえるでしょう。
さらに、制作が完了してからではなく、要件定義の段階で評価がおこなえるので、作業工程における手戻りを防ぐ効果も期待できます。
5. チームメンバーから学ぶ姿勢で取り組む
各分野のプロフェッショナルを集めてプロジェクトを進めるのだから、ディレクター自身はそれほど知識がなくてもいいと思われるかもしれませんが、そうではありません。ディレクターは総合的に判断することが仕事であり、そのためにはプロジェクト全体に対する幅広い知識が求められます。
まずは検索したり、入門書を読んだりして、必要な知識の習得に努めるべきでしょう。
そのうえで、一度学んだはずの知識でも、常識がどんどん変わっていくのがITの世界です。専門家からの提案や課題の提起には、謙虚な気持ちで耳を傾けましょう。
さいごに
要件定義とは、いわばプロジェクトという名の航海に出発するための大船を作る作業です。ディレクターは要件定義を自分一人でおこなうのではなく、プロジェクトオーナーから各クリエイターに至るまで、メンバー全員を巻き込んで取り組むようにしましょう。
LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。
