大企業とスタートアップを知る著者が解説 要件定義で「プロジェクトが崩壊する前にやるべきこと」とは：なぜ業務担当者と開発者は「もめる」のか（1）

開発において、要件定義は最も重要なステップだ。ツールやサービスが進化しても、ユーザーニーズを正確に理解し、プロダクトの方向性を決定する要件定義の本質は変わらない。業務と開発の視点の違いを乗り越え、円滑な合意形成をするにはどうすればいいのか。

[吉種 伸彰（ソーシャルインテリア），＠IT]

印刷

通知 連載「なぜ業務担当者と開発者は「もめる」のか」の新着をメールで通知

見るPost

Shareシェア

はてなブックマーク

SharePocket Button

　システムや製品、サービスといったプロダクト開発においてエンジニアが最初に取り掛かるのは要件定義だ。コーディング支援AI（人工知能）やローコード／ノーコード開発ツールといった開発作業を効率化、省力化する動きはあるが、どんなに技術が進化しても要件定義の重要さは変わらない。

　一方で、要件定義はトラブルが発生しやすい作業だ。「業務」と「開発」、それぞれ重視するものが異なる同士が意見をすり合わせるので、必然的に「もめる」ことは多くなる。どうすればもめることなく、要件定義を進めることができるのか。大企業とスタートアップという異なる環境で要件定義を進めてきた著者が、その秘訣（ひけつ）を解説する。

なぜ要件定義で「もめる」のか

　異なる意見をぶつけ合うことは悪いことではない。だが、感情的なぶつかり合いは避けるべきだ。

　特にスタートアップなど小規模な企業の場合は一人が抱えるタスクが多く、感情を抑えられなくなる場面はどうしても出てくる。著者の経験上、感情的になると、無理難題やビジネス上やる意味がないと思われる要求が開発に突き付けられたり、要件定義が不十分な状況で見積もりを催促させたりといったことが起きる。これは双方にとって不毛な時間だ。しかし、もめることなく意見をぶつけ合うことができれば、結果として良いプロダクト開発につながるはずだ。

　では、なぜもめるのか。不安や不満のきっかけになるのは、一般的に「実態が分からないこと」だ。

　事業部門からすれば「“開発”とは何をするものなのか」を理解するのは難しく、例えばPCの前で悩んでいるエンジニアを見ても「もしかして他の人ならもっと早くリリースできるのではないか？」と解釈してしまう。それが積み重なると「真面目にやっている自分だけが損をしている」といった気持ちになる。すると、開発部門から質問や提案を受けても「バグをなくして」「もっと速く作って」といった抽象的なことで圧力をかけることが目的になり、結果として良いプロダクトが作れない、といったことが起きてしまう。

　逆に言えば、開発が何をしているのか、どういった理由でそれをするのか、といったことを事業部門に理解してもらうことができれば、そうした問題を回避できる。開発の動きを理解してもらうには密なコミュニケーションが必要だ。ここからは、要件定義で業務担当者を味方につけるコミュニケーションの手法について説明する。

　説明するのは以下の5点だ。

1. 要件定義を始める前にやること
2. 「その要件の実現は難しい」の効果的な伝え方
3. 要件の種類ごとで対応を変える
4. 要件定義の進捗（しんちょく）を「自分ごと」にさせる
5. 関係者が「仲良くなる」では解決できない理由

　前編となる本稿は1．と2．を解説する。

1．要件定義を始める前に要望側のスタンスを変える

続きを読む

　事業部門などの要望を出す側（以下、要望側）のスタンスを変える必要がある。要望側は「自分たちのやりたいこと、やらなければならないことを伝えればよい」と思いがちだ。開発者や開発部門（以下、開発側）からすると他機能への影響や優先順位なども考慮しなければならない。こうしたズレをできるだけ早い段階ですり合わせることが重要だ。

「要求」と「要件」は違う

　すり合わせたいポイントは以下の3点だ。

• 「要求」と「要件」は違うということ
• 前の工程が終わってからじゃないと次の工程には進めないこと
• 要件定義は要望側と開発側とのすり合わせが必要だということ

開発の工程の前後関係を説明することは重要だ

2．「できない」を分解して伝える

　開発側はプロダクト全体への影響を考慮した上で、その要件ができるかできないかを判断する。だが、その判断をした理由の説明を省いて結論だけ述べてしまうと、要望側は「やりたくないから（もしくは手間がかかるから、面倒だから）やってくれないのではないか」などと解釈してしまう。だが、事細かに仕様や影響範囲の話をしても要望側には伝わらない。そこでお勧めなのが「できない」を分解して伝えることだ。

工数がかかるから「できない」

　工数がかかる要望を出されると、特にプロダクトマネジメントの経験が浅い開発者は反射的に「できない」と言ってしまいがちだ。だが、そのまま対応するのは無理でも、機能を減らす、納期を遅らせるといった調整をすれば、要望を受け入れられることが多い。そのため、以下のように伝えるのがいいだろう。

「開発は可能です。ただ、一定の工数がかかるので現在の納期には間に合いません。“A機能”とちょうど同じくらいの工数なので、そちらを開発しなければ対応できますが、そうした判断は可能ですか」

効果がないから「できない」

　要望側はプロダクトについて詳しくないため、感覚的な判断や部分最適の観点で要望を出すことがある。少し強めの表現をするなら「これをやる意味はあるのか？」と首をかしげるような要望だ。開発側は業務の当事者でなく、特別な感情はないため「やる必要がない」と客観的に判断できる。だが、その判断が顔に出てしまうのはよくない。要望側はそうした感情を繊細に感じ取ってしまうからだ。こうした要望については、ストレートに断るのではなく、素直にその疑念を伝えるのがよいだろう。

「開発は可能です。ただ、せっかく作るからには意義のあるものを作りたいと思っていますので、どのようなメリットがあるのかを教えてもらえますか」

　もしこの問いに対して相手が怒り出すようであれば、それはもう要件定義とは別の問題になる。質問するのは気まずいと思うかもしれないがそこは仕事と割り切り、フラットにメリットとデメリットを把握しよう。

　また、自身が開発側のリーダー層なのであれば以下のような回答も有効だ。

「開発できますが、リソースに空きがないので別の開発と入れ替える必要がありますね。経営層やCTO（最高技術責任者）も出席する会議がありますので、そちらでこの機能の有用性を説明していただいて、入れ替えの打診に協力してもらえませんか」

　議題に挙げることで、要望側も開発側も機能の有用性を客観的に判断できる。意味がある機能であれば開発の優先順位を入れ替えられるし、意味がない機能であればそこでストップをかけられる。余談だが、こうしたアプローチをすることで「要望側 対 開発側」という対立関係を避けられる。つまり「やりたかったんですけど、残念でした……」といったように“あなたのことを考えていますよ”というメッセージを伝えられる。

技術的に難しいから「できない」

　この回答は基本的にしてはいけないものと著者は考えている。開発のプロフェッショナルとしては、こうした「技術の壁」を超えることこそが役割だと考えているため、軽々しく「技術的にできない」と言わないエンジニアでありたいと思っている。

　とはいえ、要望側から技術的に高い水準の要求をされたらどうすればいいのか。その場合は、実現可能性はさておき、できるだけ具体的な数値で示すといいだろう。数値が非現実的なものであっても意味はある。例えば、以下のような回答が可能だ。

「実現可能ですが、競合も相当なコストをかけて実現している機能です。試算ではこの機能だけで3億円の追加投資がかかります。また、要件定義に3カ月は時間が必要です。捻出は可能でしょうか？」

　余談だが、著者も過去に「Googleと同じ水準の検索機能を付けてほしい」と言われ、冷や汗をかいたことがある。そのときはGoogleが検索サービスにかけている金額や時間を概算し、「同じ規模の予算と時間があればできます」と答えた。当然、一般的な会社の規模感とはそぐわない数値だったため、その要望は取り下げられた。

納期に間に合わないから「できない」

　これまでの「できない」とは違い、納期に関してはそのまま伝えるのが一番だ。慌てて作業したとしても意図したゴールにたどり着けるとは限らないし、根性論で乗り切ろうとしてもそういった方法はすぐに破綻してしまう。それよりは要望側と開発側がしっかりとコミュニケーションを取って、次善策を考える方が有益だ。

「納期を間に合わせたい理由は承知しています。しかし、申し訳ないですが増員してもその納期は達成できません。無理に進めても品質問題や納期遅延の可能性があります」

「ビジネスで達成したい目標は◯◯ですよね。それであれば“B機能”は開発しなくてもよいはずです。“B機能”の開発を諦めれば納期に間に合わせられます」

　残念ながら、こうした納期の懸念を伝えているにもかかわらず、押し切ろうとする要望側もいる。その場合は、どういったコミュニケーションをしたのか（納期が間に合わないと伝えたこと、無理に押し切られたこと）を記録に残すことが重要だ。その上で優先順位を入れ替える、開発する範囲を絞るなどの妥協案を提案するのがいいだろう。

閑話休題：妥協案はどのように提案する？

　ここで「妥協案」について少し深掘りしてみよう。納期が譲れない場合、何を譲るか（優先度を落とすか）を検討し、提案する必要がある。だが、妥協案として「品質」と「予算」を提示する場合は注意が必要だ。

　“品質を妥協する”とは「最低限動くものにはするが、使い勝手やパフォーマンスについては保証しない」ということだ。大体のケースでは「最低限動くなら」と要望側はすんなりと了解する。だが、受け入れテストの段階になると「使いづらい、反応が遅い」といった不満が続出する。要望側はなぜか「自分たちに関係のない部分の品質が落ちるはず」と認識していることが多く、実害が出ると途端に拒絶反応を示す。残念ながら開発にバグは付き物で、発生するバグの種類をコントロールできるわけではないので、基本的に品質を落とす妥協案は提示しない方がよい。どうしてもそれしか手段がない場合は実現する要件や機能の有無についての妥協案にするとよいだろう。

　同様に、“予算を妥協する”、つまり一時的に人員を追加して短期間で開発する案も注意が必要だ。この妥協案を提案すると、要望側は「明日から1人増やせば、納期を半分にできる」といった単純な計算をしがちだ。こうした場合、要望側からの理解を得るために例えば以下のような説明が有効だ。

「機能を分担するのは3つまで（3分割まで）が限界なので、仮に3人以上いたとしても効率は上がらないのです」

「エンジニアのオンボーディングに時間がかかるので、1カ月後のリリースまでに戦力にはならないのです」

　外部ベンダーに開発を委託している場合は、人を増やすお願いだけではなく、その背景（「納期に間に合わせたい」など）を伝えて、契約に盛り込むかどうかにかかわらずコミットを求めるべきだ。そうしないと「人員は増えたが納期は変わらない」といった悲劇が起こってしまう。例えば、以下のような回答をするとよい。

「“A機能”のリリースを1カ月前倒したいので、人を増やしたいと思っています。即戦力として参入できる人はいますか？」

---

　後編は要点定義を進める中で課題となる点について解説する。

吉種　伸彰（よしたね　のぶあき）

新卒で株式会社ビッグツリーテクノロジー＆コンサルティング（現：キャップジェミニ）に入社。SaaSの開発、運用プロジェクトにて、実装から開発ディレクションまで広く携わる。2021年3月に、ソーシャルインテリアに初のエンジニアとして入社。現在はシステム開発部のマネジャーとして、新規事業のシステム開発などに関わる。