こんにちは、パラダイスウェアの橋本です。
「誰も教えてくれないプロマネのコツ」シリーズ、第5弾の記事です。
今回も私が18年間、300以上のプロジェクトを担当する中で培ってきた要件定義のノウハウをズバッと大公開します。
大公開！ プロジェクトの難関「要件定義」をクリアできる進め方の5つのポイント
前回は、要件定義では「人間は物事を忘れるし気が変わる」や「全体よりも細部に意識が行ってしまう」というよくある問題をカバーするために、「ビジュアル化した資料を作成して合意を形成すること」が大事というお話をしました。
今回は「どんなプロジェクトでどんな要件定義資料を作ればいいのか？」というお話です。
- ビジュアル化（見える化）した資料を元に進める
- 必要なドキュメントを選択する（←今回の記事）
- 効率のいい合意形成を行う
- 実行チームの部隊編成を行う
- 実行チームに要件の過不足がないかを確認する
では早速ご紹介していきましょう。
2. 必要なドキュメントを選択する
ドキュメントをビジュアル化することが重要というお話は前回しましたが、今回は具体的にどんなドキュメント（資料）を作るべきかを選択することがポイントとなります。
下記の記事でもお話しましたが、要件定義は必ずしも常に十分な時間が取れるとは限りません。
「要件定義の失敗あるある」を回避してプロジェクトを成功させるコツとは？-誰も教えてくれないプロマネのコツ
https://mmth.pro/ja?p=637
世の中のプロジェクトは「年末で忙しいけど、来年度の予算の都合で来年4月にはプロジェクトを始めないといけない」とか「上から言われたから今年度中にリリースしないといけない」などの会計や社内政治の事情だけでスケジュールがなんとなく決まってしまっていて、「やるべきこと」を決めるための要件定義の期間が十分確保されていないことが多いのです
例えば、システム開発プロジェクトの「あるべき姿」として言えば、要件定義をじっくりやって、不確実性をあらかた潰してから実装に取り掛かるのが理想なのですが、現実のプロジェクトでは予算や社内外の政治やビジネス上の事情によって、ギリギリの時間で必要最低限の要件を詰め切ることが必要な状況がほとんどだと思います。
特に受託開発の場合などは、要件定義に取り掛かっているときはエンジニアなどの実装部隊が既にアサインされて待機状態になっていて、追い立てられるように要件定義をしなければならないことも多いでしょう。
こうした「現実のちょっと残念な事情」の中で走り切らなければならないのが要件定義のつらいところですが、そこでいかに「必要なドキュメントを選択するか」が極めて重要なポイントになるのです。
大工さんに例えて言えば、建てる家の種類に合わせて工具箱に入っている工具の中から、いかに効率的に目的を達成できる工具を選べるかがポイントになるようなイメージです。
ここはプロジェクトマネージャーの経験とスキルが大きく反映されるポイントですが、今回そのノウハウを大公開してしまいます。
工具選びがポイント
要件定義資料の基本セット
要件定義では限られた時間で多様な資料を作成し、多くの決め事をしなければなりませんが、アプリやシステム開発の場合、基本的には「人（ユーザ）」、「システム」、「ビジネス」の3領域を明確にする作業だと捉えると良いでしょう。
業務改善の場合は「人（業務担当者/意思決定者）」、「導入システム」、「ビジネス」と読み替えることになります。
新規事業を大きなビルを建てることに例えると、「人」はビルの利用者について、「システム」はビルの設計や建設について、「ビジネス」はビルの運営や利益の上げ方についての検討となります。
利用者のことを考えていないビルは流行らないでしょうし、設計や建設に問題があると利用されなくなります。運営や利益が確保されていないビルは寂れてしまうでしょう。
このように、新規事業や業務改善のプロジェクトでも、どれかの領域が十分に検討されていないと成功は難しくなります。
要件定義の3領域
ただ、日進月歩で技術が進歩する IT は十分に業界としての経験の下地があるビルの建設や運営と違って、「やってみないとわからない」部分も大きく、いきなり3つの要素がうまく絡み合った「スイートスポット」を最初から見つけられることはごく稀です。
また要件定義は時間も限られているため、いきなり正解を掴みに行くのではなく、プロジェクト実行後の仮説検証の土台になる検討を始めるつもりで取り掛かると良いでしょう。
では、それぞれの領域で検討すると良いドキュメントの種類についてご説明します。
「人（ユーザ）」領域を検討するための要件定義資料
「人（ユーザ）」領域を検討するための要件定義資料は下記のものが主なものとして挙げられます。
- 市場調査
- 競合調査
- ペルソナ設定
- カスタマージャーニーマップ
- 業務フロー図
- ユースケース図
「多いな！」と思う人もいるかもしれませんが、重要なのはまだ見ぬユーザをできるだけ具体的に描けるかどうかなので、必ずしも全ての資料を作成する必要はありません。
要件定義にかけられる時間との兼ね合いで必要最低限の資料を精度高く作っていくことがポイントです。
具体的なユーザを共有することで意思決定を正確にします
この記事では細かいドキュメントの書き方については触れませんが、ググっていただくとネットでも調べられるので興味のある方はぜひ調べてみてください。
ここでは、それぞれの資料の使い方と作成時のコツをご説明します。
◯ 市場調査
市場調査は一般向け（C向け）のアプリやサービスで特に重要な作業です。
業務用（B向け）ツールでも、多数の顧客に対して販売する場合は必要不可欠と言えるでしょう。
既に多くの人が認識している市場かどうか、参入する市場に強力なプレイヤーはいないかどうか。これらをチェックします。
例えば、新規事業として C向けの iOS/Android アプリを作ろうとする事業会社は多いですが、2015年の時点で App Store で83%のアプリが「ゾンビ化」している（誰にも発見されない）という話もあり、少なくとも同じカテゴリのアプリに勝てるかどうかなどを検討する必要があります。
Appleのアプリストアでは83%110万あまりのアプリが“ゾンビ（生ける屍）”化している | TechCrunch Japan
https://jp.techcrunch.com/2015/01/31/20150130zombie-apps-on-the-rise-83-of-apps-not-on-top-lists-up-from-74-last-year/
他にも、政府の統計や対象の業界の白書や書籍などを調べて、どれくらいのユーザニーズが期待できるかを検討します。
こうした調査に時間を費やすのはまどろっこしい気もしますが、ニーズが存在しないプロジェクトに何千万円や何億円も投資するのは大きな失敗になり得るため、じっくりやることが大事です。
例えば、あるレジャー用のアプリを課金モデルで検討する際に、日本全体で対象人口が何万人いて、そのうちの何％の人が知っていて、何％が課金してくれて、いくら払ってもらえるのか、などをパパッと計算することができれば、事業として成立するかどうかは見通しが立つでしょう。
今なら統計情報はネットでかなりの部分が調べられたり資料を取り寄せたりできるので、それほど多くの労力は必要とされないでしょう。
◯ 競合調査
競合調査は一般向け（C向け）のアプリやサービスでも、業務用（B向け）ツールでも重要な作業です。
極めて一般的な作業ですが、自分達のアイディアで浮かれているときには案外抜けがちです。
自分達が参入する領域にどんなプレイヤーがいるのかを、検索したり、できれば実際にユーザ登録や資料請求などをして調査を行います。
実際に使ってみると、各サービス/アプリの強みや弱みが見えてくるので、それを踏まえて、自分達は商品開発をする際にどんなところを押さえておかなければいけないかを検討します。
ある程度成熟している業界や強力なプレイヤーがいる場合は、ユーザから見た時に別の価値を提供できないと、体力（組織力や資金力）の勝負になって消耗戦に突入してしまうので気をつけましょう。
たまに「競合はいない！」と主張する新規事業担当者もいますが、その場合は単に調査が足りないか、ビジネス上のリスクが高すぎるか、収支が逆ザヤでビジネスにならないケースがほとんどなので要件定義の際によく調べることが重要です。
もちろん、スタートアップのように全く新しい市場を作るケースもありますが、それにはかなりの試行錯誤（＝時間と資金）が必要になるということを理解しておく必要があるでしょう。
競合調査も、今ならネットでかなりの部分を調べることが可能です。
◯ ペルソナ設計
ペルソナ設計は一般向け（C向け）のアプリやサービスでは一般的になりつつある手法です。
ペルソナ設計では、アプリやサービスを使う「まだ見ぬユーザ」がどんな人なのかを想定していく作業です。
ペルソナ設計 – Google 検索
https://www.google.com/search?q=%E3%83%9A%E3%83%AB%E3%82%BD%E3%83%8A%E8%A8%AD%E5%AE%9A
プロジェクト関係者で集まって、まだ見ぬユーザであるペルソナについてワイワイと意見を出し合って検討するのは楽しいプロセスでもあります。
ただ、市場調査を実施していないと、データ的な裏付けのない「ただの想像」で設計が進んでしまうので注意が必要です。
例えば、ペルソナAは対象とする市場の何割ぐらいを占める人なのか、その人を取り込むことによってどんなメリットがあるのかを想定していないと、仮説検証の土台になりません。
仮説検証の土台としてペルソナを作ることができれば、サービスのリリース後に「そのまま」の人が現れたりするので、とても手応えを感じやすい作業でもあります。
要件定義でペルソナを作ることが重要なのは、検討の際に「ペルソナAさんはこの機能を使ってくれるかな？」と関係者で考えることができる点です。
目の前に具体的なユーザ像がない状況で要件や仕様を検討すると、次第に「オレはこの機能が欲しい」、「私はこのデザインは譲れない」と自分目線で話が始まるようになり、収集がつかなくなりがちです。
ペルソナ設計資料は「こういう人のためにこれを作る」というイメージをプロジェクト内で共有するためにとても重要な資料となります。
どんな生活をして、何に関心があるのかを検討します
◯ カスタマージャーニーマップ
カスタマージャーニーマップは一般向け（C向け）のアプリやサービスで特に重要な作業です。
カスタマージャーニーマップでは、ペルソナ設計で想定した人々がどんなことを考えて、どんな悩みや課題を抱えていて、どんな行動をするのかを検討しながら、生活や仕事の流れで自分たちが提供するものとどんな接点があるのか、どんな価値を提供できるのかを文書化していきます。
カスタマージャーニーマップ – Google 検索
https://www.google.com/search?q=%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%83%BC%E3%82%B8%E3%83%A3%E3%83%BC%E3%83%8B%E3%83%BC%E3%83%9E%E3%83%83%E3%83%97
カスタマージャーニーマップもペルソナ設計と同様、最近はよく実施するプロジェクトを聞くようになりました。
カスタマージャーニーマップは多様な視点や想像力が必要なため、ワークショップなどでプロジェクトの初期に和気あいあいと関係者で集まってミーティングで作ることがありますが、しっかりとエクセルなどで文書化して後で活用できるようにしておかないと、後で「あれってどうなったんだっけ？」とただの思い出づくりになってしまうので要注意です。
アプリやサービスの初期開発の後の改善やマーケティングでも仮説の土台になる資料となるので、定期的に見直して軸がブレないようにすることが重要です。
生活や仕事の中でどのような位置づけのものを作るかを検討します
◯ 業務フロー図
業務系（B向け）のツールやサービスを開発する際に外せないのが業務ヒアリングです。
業務ヒアリングを行った後にこれを図式化するのが業務フロー図です。
業務改善のプロジェクトでも業務フロー図をまとめておかないと、現場のニーズにマッチしないツールを導入して不評を買ったり、却って業務効率を下げてしまうことにもなりかねません。
業務フロー図 – Google 検索
https://www.google.com/search?q=%E6%A5%AD%E5%8B%99%E3%83%95%E3%83%AD%E3%83%BC%E5%9B%B3
特に外注や業務委託でツールやサービスを開発する際には、要件を統括するリーダーやそのチームがちゃんと「現場」に入って業務を見ることが重要です。
経営トップが「ITで業務改革だ！」と言ったところで、日々仕事に追われている現場の担当者にとっては目の前の仕事をさばくことのほうが重要です。
そんな状況で、いきなり顔も知らない外注のIT企業の開発者からややこしいエクセルの質問表がメールで送られてきても、適切な回答を返そうと思うとは限りません。
また、同じ社内や部署にいても、立場が違えば「業務課題」の見え方や感じ方は違うことが通常なので、第三者のフラットな視点で現場を観察して、どこが業務のボトルネックになっているのかを俯瞰することが大事です。
実際に現場に足を何度も運んで、業務がどのように行われ、誰がどのように困っているのかを把握して解決策を作らなければ、何千万円何億円の予算を投じた業務ツールも「使えない」と判断されて無駄になってしまいます。
そんな大外しをしないためにも、まず最初にしっかり業務ヒアリングをしておく必要があります。
そして、ヒアリングした内容は業務フロー図などにまとめましょう。
業務フロー図には「正しい書き方」がありますが、後で関係者に認識の間違いなどがないか確認するのに利用するため、ITリテラシーが高くない関係者が多い場合は正しい書き方にこだわらず、理解しやすい書き方をすることがポイントです。
正確さとわかりやすさのバランスが重要です
◯ ユースケース図
ユースケース図は業務系（B向け）のツールやサービスを開発する際によく作成されますが、一般向け（C向け）のアプリやサービスでも必要な作業です。
ユースケース図では、実際に作成するアプリやシステムにどんな人がどんな形で関わるかを明確にします。
ユースケース図 – Google 検索
https://www.google.com/search?q=%E3%83%A6%E3%83%BC%E3%82%B9%E3%82%B1%E3%83%BC%E3%82%B9%E5%9B%B3
よくある失敗として、例えば ECサイトを構築する際にユーザから見える部分の設計などはちゃんとできているのに、ユースケース図を作成しなかったために問い合わせや在庫管理等の管理画面系のことがすっかり検討や見積りから抜けていて、突貫で使いにくいものを作ってしまったり、スケジュールや予算が逼迫してプロジェクト全体が炎上してしまうというようなパターンがあります。
ユーザに質の高いサービスやアプリを提供するには、業務に関わる担当者が効率的に仕事ができることも重要なポイントなので、ユースケース図を作成して実装するものの抜け漏れがないようにしましょう。
また、業務改善でツールを導入する場合も、ユースケース図を踏まえておかないと、「A部署の業務効率は半分になったけど、関連部署のB部署では業務量が3倍になってしまった」というような失敗に繋がりかねません。
それなりにサービスやアプリの開発の経験がある人でもこの検討が抜けて失敗しているのを見かけることがあるので、特に気をつけるべき作業と言えるでしょう。
ユースケース図も「正しい書き方」がありますが、これも正しさにこだわりすぎると内容が伝わりづらくなるため、共有する相手がわかりやすい書き方を心がけましょう。
プロジェクトに関連する外部のシステムや担当者も描くのがポイントです
以上、駆け足で各資料についてご説明してきましたが、上でお話した通り、全ての資料を作らなければならないわけではありませんし、それぞれのフォーマットが完璧なわけでもありません。
ペルソナ設計やカスタマージャーニーマップが日本のIT業界に浸透してきたのはおそらくここ5年ほどだと思いますし、それ以前は見込み客へのアンケートなど、別の方法で同様の検討を行っていました。
今後もきっとより効果的で効率の高い手法が開発されるでしょう。
重要なのは、限られた時間で人（ユーザ）がビジネスやシステムとどう関わるかをちゃんと検討するために、プロジェクトの性質や状況によって作成するべき資料を取捨選択をしていくことです。
今回挙げた資料を各領域のポイントに大まかに配置すると、下記のようになると思います。
自分たちが実施するプロジェクトでは何を検討しなければいけないかを考えながら、作るべき資料を選択すると時間を有効に使えるでしょう。
必要な資料を選択しましょう
「人（ユーザ）」領域を検討するための要件定義のポイント
一般ユーザ向け（C向け）でも業務用（B向け）でも、サービスやアプリ、システムは基本的に「人の役に立つ」ために作るものです。
特に初期開発の目の前にパソコンとホワイトボードぐらいしかない状況で、使ってもらえる人や売るべき相手の顔も見えないのにこれらの資料作成を進めるのは困難なのは事実ですが、少しずつでも検討を進めて「ユーザ像」の肉付けを進めていくことが大事です。
最初は雲を掴むようなしんどい気持ちになりますし、手間のかかる作業ではありますが、資料を作成することを目的にするのではなく、「誰のために何をやっているか」の認識を共有できるようになることを目的に進めていきましょう。
検討が完全に外れていなければ、軌道修正もできるようになりますし、オフィスに閉じこもりがちな IT の開発現場でも長期間モチベーションを持ってプロジェクトを進められるようになります。
次の記事では「システム」の要件定義で必要な要件定義資料についてご紹介します。
関連記事
「そもそも」が大事！ 「プロジェクトって何？」と訊かれて答えられますか？-誰も教えてくれないプロマネのコツ
https://mmth.pro/ja?p=533
プロジェクトはなぜ失敗しやすいのか？ その原因とは-誰も教えてくれないプロマネのコツ
https://mmth.pro/ja?p=569
「要件定義の失敗あるある」を回避してプロジェクトを成功させるコツとは？-誰も教えてくれないプロマネのコツ
https://mmth.pro/ja?p=637
大公開！ 要件定義のノウハウ（1） 要件定義はビジュアルでまとめよう！-誰も教えてくれないプロマネのコツ
https://mmth.pro/ja?p=720
ここで宣伝です
「作成した要件定義資料が行方不明になった…」「バージョンを取り違えてしまった…」
こうした状態を防ぐためにも、タスクと資料がセットで確認できるマンモスプロジェクトをぜひお試しください。
プロジェクトの全体像、共有できてますか？ マンモスプロジェクト（Mammoth Project）
https://mmth.pro/ja
