要件定義は"輪郭づくり"。曖昧な種を形にする

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

Q:自己紹介やこれまでのキャリアをお願いします。

最初は地元のIT企業に就職して、レガシーなシステム開発をしていました。そこでプログラミングの基礎を学んだあと、東京へ出てSES経由で医療系の比較的大きなシステム案件に関わるようになりました。そこでWeb関連の知識や経験も多少積めたんですが、「もっとモダンな開発をやりたい」という思いがあって、KSRとご縁ができました。入社後はクライアントとのやり取りを通じて学びや失敗を重ねながら、いろんなシステムを作ってきました。最近では開発と並行してPM的な動きもしています。

Q:要件定義とは何をすることだと捉えていますか?

「作るものを決めるフェーズ」だと思っています。僕の関わる案件はアジャイル寄りの進め方が多くて、お客さんから最初に出てくる要望は「こういうサービスが欲しい」みたいな一言レベルのことも多いんです。それを明確にしていくのが要件定義かと。曖昧な種を、形のあるものにしていく作業ですね。

Q:そのとき大事にしている要素ってありますか?

まずは「本当にそれを作って嬉しい人がいるか」を考えながら話を聞きます。自分がそのサービスのユーザーになったつもりで、「これ自分なら使うかな?」と考えながら議論します。

もちろん僕が100%ユーザーになるわけではありませんが、仮に全然違う業種だったとしても、使う立場になったときに「こういう形のほうがいいんじゃない?」と感じれば提案します。その提案がクライアントの意図と違っていても、「そういう背景や思想があるのか」という新しい情報が得られます。そうやって、言葉にならない部分も掘り出していく感覚ですね。

Q:考えがまとまっていないクライアントに出会ったことはありますか?

あります。でも、それも一つの答えだと思っています。考えていない=優先度が低い、というサインかもしれません。そこは無理に深掘りせず、もっとフォーカスすべきポイントに時間を使ったほうがいい。逆に「ここは考えなきゃいけない」となれば、そこを明確にできただけでも進歩だと思っています。

Q:内部に要件定義できる人材がいない会社へ、どんなアドバイスができそうですか?

まずは、ビジネスとテクノロジーの両方が分かる人を一人置くことです。

やりたいことが曖昧なままPMを採用しても、多分会話がかみ合いません。それよりも、一緒にビジネスの方向性を考えながら、必要に応じて要件を詰めていける人、それは内部でも外部でも構いません。また、起点になれる人でも、その人がアドバイザー的な立場でも構いません。「今すべき方針はこれ」「進め方はこう」という指針を示し、進行中も方向が正しいか確認できる存在が必要です。

Q:要件定義をやらずに開発する人たちに「なぜ要件定義が大事なのか」を、Nishitaniさんならどう伝えますか?

要件定義をしないと、開発は博打になりますってことですかね。サービスオーナーの頭の中にだけある"全体像"が、他のメンバーに共有されないまま進んでしまうからです。そうなると、作業者は目の前の小さなパーツだけを作ることになり、いざ組み合わせたときに「なんか違う」になりやすい。

長期的に見ると、詳細な設計書までは不要でも、スライド1枚でいいから「全体の機能」「ユーザーに届けたい価値」くらいは共有したほうがいい。前後のつながりを意識できるだけで、完成度は全然違います。

Q:要件定義では言語化の力が求められると思いますが、普段からどう鍛えているんですか?

特別なトレーニングはしていません。でも、100点の資料を作る必要はないと思っています。ゼロからは動けないので、まずは10点でもいいからアウトプットを出す。図1枚でも、手書きでも構いません。それを見ながら仮説を立てて、間違っていたら修正する。少しずつ輪郭を整えていく。最近はAIやプロトタイピングツールもあるので、モックを作って見せることも多いです。

Q:伴走しながら輪郭を整えていく姿勢と覚悟を強く感じたのですが、日ごろから意識されてますか?

そうですね。最低限「画面がどういう構成で、機能が何か」が明確にならないと、開発は走り出せません。そこを一緒に作っていくのは、覚悟を持ってやっています。

Q:ユーザー視点においてはどのくらい意識していますか?

ペルソナ設計は本来PMの領域ですが、自分がそのサービスを使う立場になって考えることはよくあります。「これなら納得できる」というゴール感を持って、輪郭を整えるイメージです。

KSRはこれを当たり前のようにやっていますが、実は強みだと思います。ユーザー視点が抜けると、作る側も使う側も全員が不幸になる。だから、少しでも全員が幸せになる形を目指します。

Q:要件定義が上手い人とそうでない人にはどんな違いがあると思いますか?

あえて言うなら、「輪郭を作り続ける根気」と「勇気」でしょうか。「まだわかりません」と言い続けるのは意外と大変です。でも、質問をやめないことで少しずつ形が見えてくる。場合によってはこちらから叩き台を出して、「これは違う」「ここは合ってる」とフィードバックをもらうことも多いです。

ただ、業界特有の知識が必須な場合は別。銀行や医療など、制約が多い分野では、そのドメインを知っている人を最初から入れないと難しい場面もあります。

▶︎ 編集後記

Nishitaniさんの実践は、異なる前提が交差する現場で言葉の隙間を埋め、曖昧な要望を"動ける形"に整えることに尽きます。鍵は"輪郭づくり"。全体像1枚で価値と機能の地図を共有し、10点でもまず出して見せる。得られた反応で仮説とズレを"目で"合わせ、必要十分の納得がそろったらプロトタイプで合意を固める。さらに「ユーザー視点で輪郭を描き続ける勇気と根気」が、プロジェクトを前に進める力になる。技術とビジネスの間に立ち、両者を安心させる姿勢に、要件定義の本質があると感じました。