ディレクター、プロジェクトマネージャ、プロジェクトリーダーを目指す人に向けに、業務工程を噛み砕いて発信しています。

前回の記事に続き「要件定義」がテーマですが、今回は失敗例を紹介していきます。

1.要件定義工数を見積りに含まなかった

デザインやプログラム開発する工数だけを見積りに入れており、要件定義にかかる工数をスケジュールにも見積書にも含んでいない…という初歩的なミスです。

「発注しますので、制作着手してください！」と言われてすぐに作り始められるものではなく、まずは作るものを明確にするところからはじまるのでそれを踏まえたスケジューリングをしましょう。

また、会社によっては「制作一式 ◯◯円」という見積書の中に要件定義のコストを含んだり、出し方は様々ですが基本的に人が動く、時間を要する業務のため見積書にも計上しておくとよいです。

2.要件詰めが不十分で炎上

例えば「マイページ機能」という要件があったとします。
WEBサービスやアプリを良く触る人なら、プロフィールの表示やPUSH通知の設定なんかできるんだろうな、と想像をすると思いますが、プロフィール項目や設定項目の種類や、それぞれの有無ですらサービスによってバラバラです。

マイページの中で表示したい情報が何で、編集できるがどの情報で、設定できる項目に何が必要で、設定するとどんな事が起こるか、を洗い出し置かないとデザイナーさんは画面レイアウトができませんし、エンジニアさんもどんなロジックが必要か、フロントだけ作れば良いのかバックエンドも作るのかが判断できません。

その「マイページ」が何のために必要なのか？をきちんと把握した上で、必要な要素を洗い出しましょう。

また、要件の掘り下げができないまま、スケジュールを引いたり開発契約を結んでしまうと、いざ開発が始まってから「あれもやらなきゃいけなくなった」「スケジュールが間に合わない」「この予算じゃこの機能は作れない」が連発します。

関係者一同、良い事が一つもないです笑
最悪、損害賠償を求められる可能性もあります。

要件定義でどこまで掘り下げるか感覚値が身につくまでの間は、心配性なくらい確認を入れるのがちょうど良いです。

3.管理機能が見落とされがち

ユーザーが触る機能だけに目が行ってしまい、裏側に必要な機能に対する議論ができていないケースです。

簡単な例としては、「マイページ」にサイト管理者からのお知らせ画面はあるけど、サイト管理者がお知らせを配信する機能が無いなど。

これも開発中にトラブルになりやすい失敗例のため、機能毎に「この機能はユーザー側と管理側をそれぞれ作り込む必要があるか？」というチェックを必ず入れましょう。

4.自前開発か？他社製システムか？の検討がされていない

例えば「チャット機能をやりたい」という要件があった時に、

・チャットの仕組みを自前で組み上げる必要があるのか？
・他社が提供しているチャット用のライブラリやシステムを使用してもよいのか？

の選択肢によって開発者のやる事が大きく変わってくるため、この議論が無いまま予算確保するのはリスクです。

一昔前はECサイトなんかもそうで、EC用パッケージでコスト抑えて作るか、オリジナリティを出すために自前で作るかをはじめの段階で検討する事がよくありました。

予算とスケジュールにも大きく関わってくるため、自前開発だと重い…という機能がある場合は他社製のものを使っても良いのか？をあらかじめ聞いておく様にしましょう。

5.予算に見合わず徒労に終わる

200万円しか予算がないのに、要件定義したら2,000万円規模になってしまい「予算が無いため中止」となるケースがあります。こういう現象をわたしは「風呂敷の広げすぎ」と呼んでいる。

依頼をする側も、IT関連のサービス経験が少ない場合は話が大きくなりすぎてしまう事もあるので、要件定義をしながら予算と規模が見合っているのかチェックする癖をつけましょう。自分でチェックができない人はチェックできる人を巻き込みましょう。

予算にも収めつつ、先方の要求も満たせる方向に導けたらプロフェッショナルです。
依頼主とどうにも歩み寄れない場合は、早い段階で無理がある事を教えてあげましょう。

6.開発条件とアサインがミスマッチ

依頼主が開発会社だったりすると、要件の中に"どの言語/フレームワーク/バージョンで開発してほしいか？"が含まれている事があります。

が、そういった開発条件も要件の一つになるため取りこぼすと、

・アサインしたメンバーがそのスキルを持っておらず、人探しをやり直す
・別の条件で開発してしまい出来上がったものが納品できない

という事になる可能性もあります。

また、「アプリ開発」と言っても、WEBアプリなのかネイティブアプリ（iOS/Androidなど）なのかにもよって、アサインするエンジニアが異なります。

要件定義にエンジニアが参加するなり、依頼主から得た企画書などに書いてあれば問題になる事はありませんが、そういう事があるんだなという事だけは抑えておきましょう。

（番外編）依頼主の意向に沿ったハズが炎上

依頼主の要求に沿って要件を詰めた結果、トラブルに発展する事があります。

例えば、依頼主が↓だった場合、

要件定義は責任者であるBさんの意向にそって進めていくのが鉄則です。
そして要件に沿って設計〜開発をしていざ納品前のA社の検収（検品のような工程）に進んだ時に、"A社の合格が得られない"という事態に起こる事がまれにあります。

なぜこんな事が起こるのか？
検収に合格できないのは"要件を満たしていない（必要な機能が抜けている、理想通りの仕様になっていない等）"からになるのですが、こちら側の進め方に問題がない場合を除き、原因はA社側にあります。

a）A社内で決定権を持つ人が複数人居て、Bさんがタライ回しに合い社内コンセンサスが取れていない
b）Bさんのサービス構想が甘い、またWEBサービスやアプリサービスの開発経験が無い

こちらではどうしようもない問題ですが、、、事故率を下げる方法はあります。

aのパターンは、A社側に登場人物が多い場合であれば、決定権を持つ人を決めてくださいとA社に打診しておくと良いです。"Bさんが決定者でいいですよね？"という約束をしておくだけでも良いです。トラブルになった時にこちら側を守れる様に、体制図を書いてA社に共有しておくかチャット上でやりとりするなど何かしらの形で記録しておくと良いです。

bのパターンは、Bさんがサービスづくりの経験が豊富だったり、他社サービスをよく触っていたりする方であれば問題ないのですが、わたしの肌感としてそういう人が担当に就くのはそれほど多くないです。

このケースに限らずですが、受け身になり過ぎず一緒に考える姿勢でBさんとコミュニケーションを取ると要件が最適化できます。

資金力がない開発会社だとこういう事が原因で資金難に陥るリスクがあります。
依頼する側の方にこそこういった問題が起こり得る事をお伝えしたく、担当者への権限委譲をきちんとしてもらう、担当者のアサインを吟味する、という事をお願いできたらと思います。

失敗率を下げるためのコツ

地雷を踏む確率を下げるのが経験である事はそうなのですが、まずはこれだけでも実践してみると良いと思います。

・わからない事をほったらかしにしない事
発注側に聞き直すか、自分で調べてみるか、専門家に相談するか、等しながら依頼主のやりたい事を明確化する行動を取る事が大事です。

・要件にある機能を別サービスの機能に置き換えてみる
依頼主が求める機能はよほど独創性が高いものを除き、ほとんどが既存のサービスだったりアプリが持っている機能です。マイページはこのサービスの様にしたい、この機能はこのサービスの様にしたい、など他サービスのイメージして制作チームとコミュニケーションを取るだけでも炎上リスクは軽減できます。あとは、独創性が強い機能に対するヒアリングへ力を注ぎましょう！

まとめ

今まで実体験 or 目の当たりにした事のある失敗例を紹介しました。

思っていた以上の文量になってしまいましたが、この工程をおろそかにしてしまうと計画が崩れ＝炎上街道まっしぐらになる可能性があるので、上記で挙げたポイントを参考にして頂きつつ炎上案件が１つでも減ると良いなと思います。