要件定義は"動ける条件"。混乱を整理し、合意へ導く

日頃KSRで活躍されている行川さんに、KSR SS事業部責任者の丸山がインタビューを行いました。

Q：「要件定義」とは何だとお考えですか？

僕のなかでは、「依頼する人が動くために必要な条件」を明文化することだと思ってます。

そもそも、何かを作るには"ゴール"があるわけで、要件ってそのゴールに向かって全員が動くために必要な道筋なんですよね。

ただし、それをどう伝えるかは、相手のスキルや職能によって変わる。

たとえば、ある程度慣れたメンバーなら、「今みんな忙しそうだから、ちょっと助けてくれる？」だけで動いてくれる。でも、まだ経験が浅い人に同じことを言っても、動けないんです。そういう時は、やることをA・B・Cに分解して、「あなたはAを担当して、期限はいつまでで、レビューはここで」とか、もっと細かく伝える必要がある。

つまり要件定義って、その人がきちんと前に進めるように道筋を整えること。

依頼相手ごとに適切な"動ける条件"を定義することなんじゃないかなと。

Q：要件がまとまらず、苦労されたプロジェクトの経験はありますか？

苦労しかしてないですね（笑）。

特にクライアントワークでは、まず「信頼関係をどう築くか」が最初の壁になります。要件定義って結局、相手が何に困ってて、何が得意かっていう理解が前提なんですよ。それがないと、やっぱり進まない。

社内だと「この人はこういうタイプだよね」とか、「こういう文化あるよね」で何となくやれるけど、外部クライアントだとそういう共通の"プロトコル"がない状態から始まる。そこで噛み合わないと、本当にしんどいです。

たとえばスタートアップだったら、こっちのスピード感とマッチすれば話が早い。でも、大企業だとまず使ってる言語すら違うし、「うちは発注先、そちらは受託先ですよね？」みたいな意識が強かったりして、そこの文化の違いが結構大きいんです。

だから、毎回「このプロジェクトでは、どこに着地させるのが双方にとっていいのか？」を模索しながら進めてます。失敗というよりは、"調整"の連続ですね。

Q：逆に、要件が明確になってうまく進んだプロジェクトにはどんな共通点がありましたか？

やっぱり、信頼関係をちゃんと築けたことですね。

たとえば、あるプロジェクトで、最初はクライアントの社長がPdMを兼任してたんですけど、デザイナーにも開発者にも、適切な伝え方ができてなくて、めちゃくちゃ混沌としてたんです。

でも途中で「これはさすがに厳しいね」となって、経験豊富なPdMを入れたんです。そしたら一気にスムーズになって。

そのPdMは開発経験もあったので、開発者ともデザイナーともちゃんと通訳ができる。結局、プロダクトって"目的から実行部隊まで"ちゃんとつなげられる人がいないと前に進まないんですよね。要は、要件定義で必要なのって「信頼」と「プロトコル」なんです。信頼があって、共通言語があって、初めて橋渡しが成立するんだと思います。

Q：要件定義の周辺で、信頼構築のために意識していることはありますか？

相手の「利害関係」を把握することです。

その人がなんでそのプロジェクトをやりたいのか。上司に認められて昇給したいのか、フリーランスで稼働時間を確保したいのかなど。背景はそれぞれ違います。

仕事って突き詰めればお金を稼ぐためですが、何にモチベーションがあるかを見ておかないと、会話の方向を間違えちゃう。僕はまずそこを見るようにしています。

Q：ビジネス側と開発側で認識がずれるポイントは、どこにあると思いますか？

よくあるのは、「なぜその機能をつけるのか」の目的が共有されていないケースですね。

開発者って、目的がわかってないとやる気にならないんですよ。言われたまま作っても、「なんのため？」って思ってしまう。

だから目的の共有がないと、進まない。で、進まない理由を、ビジネスサイドは「やる気がない」と捉えて、開発側は「意味が分からないのにやれるか」っていうズレが起きる。そもそも論点がかみ合ってないんです。

Q：ドキュメント化や設計において意識していることってありますか？

「どうせ読まれない前提」で書いてます（笑）。

特に初期フェーズだと、細かく書いたところで誰も読まない。2時間かけて丁寧に書いても、その2時間が無駄になるくらいなら、30分で3つに絞って大まかにまとめたほうがプロジェクトとしては効率的です。

課題はこれで、理由はこれとこれで、だからこういうアクションをとる。このくらいで十分だと思ってます。逆に信頼関係ができて、開発が粛々と進むフェーズに入ったら、ちゃんと読み込めるレベルで具体化します。

Q：まだ要件が固まっていない状態で相談してもいいのか迷っている非エンジニアの新規事業担当者の方に、アドバイスをお願いします。

それが"みんなのため"だったら、迷わず相談していいと思います。

自分のためだけだったら「もうちょっと自分で頑張ろう」っていう判断もあると思うけど、チーム全体の前進のためだったら、絶対に相談すべきです。

あと単純に、「分からない時は分からないでOK」。立ち止まるくらいなら、誰かに聞いてでも前に進めたほうがいいです。「みんなのために」っていう視点を持てれば、それってもう要件定義の入り口だと思うんですよね。

▶︎ 編集後記

行川さんの言葉から浮かび上がったのは、要件定義が単なるタスク分解や仕様書作成ではなく、「人が動ける条件を整える営み」であるという点でした。相手ごとの経験や背景に応じて、伝え方や粒度を変え、時には"信頼関係"や"共通言語"といった目に見えない基盤を築くことこそが重要だと強調されていました。さらに「みんなのためになるなら迷わず相談を」と語る姿勢は、要件定義を組織やチームの前進のための社会的プロセスとして位置づけているように感じます。混乱を整理し、共に歩みながら前へ進める――その姿勢が要件定義の価値を示していると実感しました。