　機能要件はシステムが実現すべき具体的な機能であり、特に要望側がこだわる部分だ。例えばユーザーインタフェース（UI）は注目が集まりやすく、開発側から何も言わなくても要望側が率先して仕様を決めてくれる。一方で、こだわりが強い部分なので「やっぱりこうしたい」と後から言われる可能性は高い。要件確定時には「ここから先は変更できない」ということを伝え、ドキュメントに記載しておくことが大切だ。

　ここで開発側が意識すべきなのは“要望側がやりたいことを実現するために決めなければいけないこと”について気を配ることだ。

　「お気に入り機能」で例えると、「お気に入りに登録すると登録された商品をまとめて購入できる」といった基本的な仕様は問題ない。だが、「お気に入り登録をした商品が非掲載になった場合にどういった扱いにするか」といった細かいことを要望側は想定していない。開発側で決めてしまうことも可能だが、“もめる”ことにつながる可能性があるため、しっかりと確認することが重要だ。

非機能要件

　非機能要件はシステムのパフォーマンスやセキュリティなど、機能以外で求められる要件のことで、企業の規模や開発する体制によって決め方が異なる。大規模企業などは社内にガイドラインがあるので、そちらに従うのが一般的だ。スタートアップなどの小規模企業の場合、非機能要件は開発側だけで決めてしまうか、開発委託先に一任することが多い。そうした企業で要望側が言えるのは「情報漏えいは絶対させないでほしい」「アクセスが急増してもサーバがダウンしないようにして」といった漠然としたものだけだからだ。

　開発側で決める理由は他にもある。スタートアップでは要望側が目標値（サービスへのアクセス数など）を高めに設定しがちで、その目標に耐えられるスペックの環境を用意しようとすると非常にコストがかかる。著者の経験では、サーバなどのインフラ構成においてはまず最低限のものを構築し、ビジネスの状況に応じて増強するという方法が現実的だ。

　結果的に、ある程度のサーバダウンを許容することになるが、要望側がこうした背景を知らないと後でもめることになるため、「最初は計画通りに売り上げが立つかどうか分からないので最小構成にしている」といったことを伝えて、認識を合わせておくことが重要だ。インフラの細かい話を全て理解してもらうことは難しいが、こうした理屈は通じるはずだ。

テンションが高い要件／テンションが低い要件

　聞き慣れない表現だと思うが、要件には“テンション”が高いものと低いものがある。ここで言うテンションとは「要望側の責任者にとっての優先度」のことだ。相手の立場に合わせてテンションの高い要件と低い要件を区別してコミュニケーションを取ることが大切だ。

　ECサイトの構築プロジェクトを例に説明する。要望側の責任者はECサイトの売り上げに責任を持っている。一方で、オペレーションについては別部署が担当しているとする。

　こうしたプロジェクトにおいて、テンションの高い要件は「ECサイト利用者の購買意欲を促す仕組み」になる。具体的にはサイトのデザインや、購買導線などだ。テンションの高い要件について開発側は要望側に対して「一緒により良い要件を模索しましょう」といった姿勢を見せるのがよい。予算を割いたり、優先順位を上げたりといった会話で信頼を勝ち取れるはずだ。

　一方、別部署が担当している「オペレーションの負荷を減らす仕組み」はテンションの低い要件になる。デザインや購入導線が変わるとオペレーションにも影響が出るため、オペレーションの負荷を軽減する要件を考えたりプロセスを調整したりする必要がある。ただ、担当が異なるとどうしても優先度が落ちるため、その要件を「テンションの高い要件」と考える人を連れてきてバランスを取ることが大切だ。

　これはデザインなど表面的な要件を重視し、裏側の要件を低く見た例だが、逆のパターンもある。著者が聞いた話では、基幹システムの構築において経理出身の人がプロジェクト責任者になった際に、数値がズレないように「正確さ」が最重視された。その結果、営業が求める柔軟さが大きく損なわれ、業務負荷が増大してしまったケースがある。

　開発側は要望側の性質を踏まえ、テンションにかかわらず、バランス良く要件を決定することが重要になる。

4．要件定義の進捗状況を適宜伝える

　要件定義は抽象度の高い会話が多いため、認識違いが生まれやすい。そのため、進捗状況を要望側に伝えることが重要だ。

　著者が勧めるのは、要望を課題として表にまとめて管理するやり方だ。この方法は特にウオーターフォール方式でビッグバンリリース（大規模な変更や多数の機能を一度に公開する）するときに有効だ。エンハンス開発（既存システムの性能、機能改善をする開発）やアジャイル開発の場合は、一つ一つの案件規模が小さいため、課題管理ツールなどに論点を書く程度で問題ないと著者は考えている。

　課題管理表において明確にしておくべきことは以下の5点だ。

誰が担当者か
論点は何か（何を決めるのか）
目的は何か（何のために決めるのか）
進捗はどの段階にあるのか
結果（結論）はどうなったか

　注意点は2つ。1つは「担当者は個人にすること」。部署名や複数名にすると、回答責任が曖昧になってしまう。もう1つは「結果を明確にすること」だ。要望通りに開発することになった場合は問題ないが、「A要件とB要件を統合する」「議論の結果、やらないことにする」など結果には幾つかのパターンがある。特に「完了」は要注意だ。その完了が「要望通りにやる」のか、「やらないことにした」のか、「他のものと重複しているのでこの要件は完了扱いにする」なのかを区別する必要がある。

　一覧表で“完了”となっていたので要望側は要望通りに開発されると思っていたら、「やらないことが決まった」の“完了”だったという話はよくあることだ（当然、もめることになる）。

課題管理表の一例

　課題管理表はプロジェクト推進の中で価値を発揮するものなので、要望側は（開発経験者でもなければ）メリットを感じにくいだろう。だが、膨大な意思決定を繰り返していく中で、その価値を感じてもらえるはずだ。

　開発側にとっては、課題管理表は最初から絶大な効果を発揮する。個人的に一番大きい効果だと感じるのは「要望側の意識を変えられること」だ。要件定義の工程では要望側のタスクも多いが、「システム開発は開発側が進めるものだ」と考え、“お客さま感覚”になりやすい。しかし課題管理表があればそれを防げる。なぜなら課題管理表には自分が担当になっているたくさんのタスクがあるからだ。

　やるべき作業の認識を合わせる上でも課題管理表は有効だ。プロジェクトを始める段階では要望（課題）が100件近く出ることもある。開発プロジェクトを経験していない人は「そんなにたくさんあるのか」と驚く。しかし実際にはそれくらい、開発側と要望側でやるべきことだと認知している作業のボリュームに差があるということだ。

5．「仲良くなる」だけでは解決しない

　これまで論理的なアプローチで“もめる”をなくす方法を説明してきた。

　要望側へのアプローチを変える以外にも方法はある。例えば開発プロジェクト経験のある企画、プロダクトマネジャーなどの職種をチームに入れるのも効果的だ。開発側があれこれ言うよりも、利害関係のない第三者が説明する方が感情的になりづらいからだ。また、前職で開発に関わった経験がある人がいれば「自社の開発はレベルが低い」などと思われにくくなる。開発者としてやれるべきことはやるのは当然として、組織体制レベルでコミュニケーションを改善するのも、かなりの効果がある。

　一方、あまり有効ではない方法もある。それは「関係者全員が仲良くする」というアプローチだ。“もめる”のは感情的なぶつかり合いのため、互いの仲を良くすれば解決できると考える人もいるだろう。だが、要件定義とは要望側と開発側がそれぞれの立場から意見を述べ、それを機能として落とし込む作業だ。単に仲良くなるだけでは「気になるところはあるけれど、機嫌を悪くされたくないので言わないでおこう」などといった思考に陥り、本当に良いものを開発するのは難しくなる。まずは気兼ねなく意見を言い合える環境を作り、よいものづくりをする過程で友情が芽生えるのが理想だと著者は考える。

　ここまで前後編にわたって“もめる”を防ぐための方法について解説してきた。重要なのは「事実を誠実に伝え、プロジェクトを前に進めたい気持ちは要望側も開発側も一緒だと伝えること」だ。本稿を参考に、要望側と適切なコミュニケーションの仕組みを構築し、ビジネスの発展につながるプロダクト開発に挑戦してほしい。

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

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