こんにちは、パラダイスウェアの橋本です。
「誰も教えてくれないプロマネのコツ」シリーズ、第三弾の記事です。
今回は「どうすれば要件定義をうまく成功させられるのか？」について、ズバッとお伝えします。
なぜ要件定義で失敗してしまうのか？
前回の記事では「プロジェクトは要件定義で失敗しやすい」というお話をしました。
そこでお伝えした通り、要件定義とは「プロジェクトで何をやるか、何を作るかを決めること」ですが、プロジェクトの工程としては一番最初に実施するフェーズとなります。
つまり、要件定義はプロジェクトで一番最初に実施することなのに一番難しい部分でもあるという、かなり厄介な性質を持っているのです。
弊社主催のプロジェクト計画webセミナーより
私は18年間のキャリアでたくさんのプロジェクトを見てきましたが、「要件定義の失敗あるある」は概ね下記の4つのパターンにまとめられると考えています。
- プロジェクト開始時点でなぜか焦っている
- 専門家の知見が欠けている
- 過剰要求になってしまっている
- 実行チームや下請けに丸投げしている
要件定義の失敗はこれらの要因を回避することで大幅に成功に近づけることができるのです。
では、順を追ってご説明しましょう。
1. プロジェクト開始時点でなぜか焦っている
現在の IT の技術環境では、プロジェクト開始時点で完璧な要件定義を行うことは極めて困難だと言っていいでしょう。
例えば、最新の技術を使って複雑なシステムやアプリケーションを構築するケースではそもそも実際に手を動かしてみないと判断できない要件もたくさんあり、実行フェーズに入る前に完璧な要件定義を行おうとすると、時間がいくらあっても足りません。
ただ、「時間をかけても完璧な要件定義ができない」ことは「要件定義に時間をかけなくていい」ということではありません。
例えばシステム開発なら「ここまで決まっていればエンジニアが実装に入れる」というレベルまでは要件をきっちり作らないと、後で行きあたりばったりになってしまい、プロジェクト全体が迷走してしまいます。
具体的に何をどこまで作るべきかは今後の記事でご紹介したいと思いますが、要件定義でやるべきことは「プロジェクトの関係者が”これで行ける”と合意を取れる内容を資料化して固めていく」ということなので、それには相応の時間が必要になります。
弊社主催のプロジェクト計画webセミナーより
しかし、世の中のプロジェクトは「年末で忙しいけど、来年度の予算の都合で来年4月にはプロジェクトを始めないといけない」とか「上から言われたから今年度中にリリースしないといけない」などの会計や社内政治の事情だけでスケジュールがなんとなく決まってしまっていて、「やるべきこと」を決めるための要件定義の期間が十分確保されていないことが多いのです。
仕事としてビジネス上の事情が重要なのはよく理解できますが、それを優先するあまりプロジェクトが失敗してしまっては元も子もありません。
どれくらい要件定義に時間をかけるべきかはプロジェクトにもよりますが、目安としては全体の工程の1/3、つまり半年のプロジェクトなら1-2ヶ月、1年のプロジェクトなら3ヶ月程度は要件定義に時間をかけるつもりで取り組みましょう。
2. 専門家の知見が欠けている
日本は IT人材の約7割が IT企業に集まっており、諸外国と比べても偏っている構成になっています。
そこで、事業会社が IT戦略を実施するときは外部の IT企業に仕事を発注する形になりますが、その発注の際にどうしても専門的な知見が欠けることが多くなってしまいます。
弊社実施の「明日から上手に開発会社と付き合っていくための7の方法」セミナーより
あまり表現は良くないですが、どうしても要件に「素人感」が出てしまうのです。
プロの目で見たときに、「その目的を実現するならもっと効率的で確実な方法がある」とか「そのアイディアは何年も前に複数の会社がやって失敗している」とか「その種類のアプリは世の中に山ほどあってとっくにレッドオーシャンになっている」とか「その要件ではセキュリティが担保されない」などの見解が出る要件資料は珍しくありません。
例えば、家を建てるときに一般の人が自分のスキルで設計図を書いて、それを元に建築会社が家を建てるということはあり得ないわけですが、システムやアプリの開発の現場では同じようなケースがとても多いのです。
よくあるパターンとしては、「アプリ開発の外注先を決めるためにコンペを開催することになったので、社内で要件資料を作ってプロジェクトを実施したが、その会社にとって本当に必要なのものはアプリではなかった」というようなケースです。
IT戦略として本当に必要なものが何かを決めるのは当然発注者や経営層のトップですが、それを実現するための手段や技術は IT の専門家の方が当然詳しいので、外部に発注するための要件を決める時は優秀な建築士に住みたい家を相談するような感覚で詰めていくのがいいでしょう。
3. 過剰要求になってしまっている
過剰要求もプロジェクトの失敗原因でよく見かけるパターンです。
例えば、ECサイトのアプリ版を作りたいという話で要件を聞いてみると、「イケてるUXで！」とか「在庫・出荷管理はシンプルに！」とか「コンテンツマーケティングと連動させたい！」とか「他の事業者も出品させたい！」とか「実店舗とも連動させたい！」とか「問い合わせ対応を簡単に！」とか「ポイントシステムも入れたい！」とか「決済はクレカ/代引き/銀行振込/QRコード決済/など全部のせで！」とか「業務担当者は増やせません！」とか「予算は3000万円です！」とか「今年度中にリリース必須です！」とか、要件てんこ盛りで出されるケースは非常に多いです。
弊社主催のプロジェクト計画webセミナーより
私も発注者の立場になることがあるので過剰要求を出してしまう気持ちはとてもよくわかります。また、普段ユーザとして Amazon や楽天などを使っていれば、それが当たり前の品質のように感じるのも理解できます。
しかし、Amazon や楽天がその品質を実現するまでには膨大な費用や人手、時間が投資されているので、その点を理解せず過剰な要件を提示し、それを受託側がハイハイ言って受け取ってしまうと、すぐにプロジェクトは破綻して何も実現しないまま投資が無駄になってしまうことに繋がります。
システムやアプリ開発の難しいところは、「機能や画面などが欠けている未完成のプロダクトはただのゴミになってしまう」というところです。
完成度60%のシステムは60%機能するわけではなく、ほとんど動かないソースコードのゴミの山になってしまうのです。
弊社主催のプロジェクト計画webセミナーより
こうした不幸な結末を避けるためには、限られた予算と時間、労力で「本当に何を実現するべきか」をとことん突き詰めていくことです。
要件が研ぎ澄まされてシンプルになっていればいるほど、そのプロジェクトの成功率は高いと言えるでしょう。
4. 実行チームや下請けに丸投げしている
上の 1-3 とも関連しますが、ネットでもよく批判される、いわゆる「丸投げ」も失敗に繋がります。
「御社に外注先を決めたから後はよろしく」とか「兼務で忙しいからそっちでよしなにやってください」などの発注者の態度を見かけることがよくありますが、企業のマネジメント層や発注担当者がこうしたオーナーシップに欠けたスタンスのプロジェクトはほぼ確実に失敗します。
オーナーシップとは、個々の従業員が自らに与えられた仕事や自身が属する組織と向き合う際の姿勢や関係性を表す言葉です。 – オーナーシップとは？意味やリーダーシップとの違いをご紹介 | BizHint（ビズヒント）- 事業の課題にヒントを届けるビジネスメディア
私の経験上、かなりシンプルなプロジェクトでも一度は予測できないトラブルに見舞われると想定しておいたほうがいいと思っています。
そして、トラブルの際に意思決定権を持つ人が普段向き合う姿勢を見せていないと、プロジェクトリーダーやメンバーが「トラブルの責任を背負わされる」と考えてしまい、意思疎通や情報共有が遅れて適切な対処に失敗してしまうことに繋がります。
もしあなたが事業会社の発注者なら、要件定義の資料は外部の専門家が固めていくとしても、その内容の確認や未決定事項についての判断は社内調整や稟議手続きも含めて進めていく必要があります。
特にプロジェクト開始当初の要件定義フェーズでは、発注者も受託側のチームも膝を突き合わせるような感覚で詰めて検討する体制を作ることが大事です。
要件定義をうまく成功させるには
ここまでのお話をまとめると、要件定義を成功させるには、「十分な工程を取って、初めから専門家の知見を入れて検討し、要件をとことん切り詰めて、チーム全体で進めること」が大事ということになります。
要件定義がうまくいけば、プロジェクトの成功確率もグンと上がります。
モヤモヤとした状況で要件を固めていくのはメンタル的にもしんどい部分がありますが、最初の難関を越えると楽になると信じて頑張りましょう。
次回は要件定義の進め方のコツについてお話しします。
関連記事
「そもそも」が大事！ 「プロジェクトって何？」と訊かれて答えられますか？-誰も教えてくれないプロマネのコツ
https://mmth.pro/ja?p=533
プロジェクトはなぜ失敗しやすいのか？ その原因とは-誰も教えてくれないプロマネのコツ
https://mmth.pro/ja?p=569
ここで宣伝です
プロジェクトの計画時点から成功に向けてあなたを支援するツール、マンモスプロジェクトをぜひお試しください。
プロジェクトの全体像、共有できてますか？ マンモスプロジェクト（Mammoth Project）
https://mmth.pro/ja
