要件定義は"翻訳"。言外の意図を掬い、"なんか違う"を防ぐ
日頃KSRで活躍されているsekiさんに、KSR SS事業部責任者の丸山がインタビューを行いました。
Q：sekiさんにとって「要件定義」とは？
一言で言えば、ビジネスサイドの「やりたいこと」をシステムサイドにちゃんと落としていく作業だと思っています。すごく広い領域になりがちで、だからこそ属人化しやすいし、組織ごとに品質のバラつきも出やすい。でも、KSRはこの要件定義の部分がすごく強いと感じていて、かなりレベルが高いなって思います。
Q：その「要件定義力」を分解すると、どんな要素になりますか？
大きく分けて3つあるかなと思っています。
ひとつは、クライアントが言っていることの真意をどれだけ汲み取れるかという、いわゆるコミュニケーションの部分。言葉を受け取るだけじゃなくて、相手の思考の前提にあるものを感じ取れるかどうか。
ふたつ目は、それを前提に「こういうシステム構成になるだろうな」と考えながら、ちゃんと形に落とし込んでいけるか。これに関しては設計の話でもあるし、エンジニアリング的な想像力も必要になります。
で、もうひとつすごく大事なのが、「言われた通りに作ったらたぶん失敗するよね」っていう違和感に気づける力です。要件通りに作っても、ユーザーにとっては全然嬉しくないとか、プロダクトとして破綻するようなケースって実際あるんですよね。ユーザー視点をちゃんと持って、そこに立ち返ることができるかが大事だと思っています。
Q：ビジネスサイドからの要件を表面上の言葉だけで解釈せずに、背景を汲み取るような力が大事ってことですね？
その通りですね。システム開発の現場では、クライアントから要望を受け、そのまま作ってしまうケースが少なくありません。結果として、完成品を見せたときに「なんか違う」と言われてしまうこともあるのですが、その「なんか違う」の正解はクライアント自身も明確に持っていないことが多かったりします。
だからこそ、こちらから問いを立て、背景を掘り下げ、本当に必要な形に導くことが重要です。KSRのチームはその点で妥協せず、本質的な合意形成まで持っていける力が強いと思います。
Q：なにかコツのようなものや意識していることはありますか？
結局どこまでいっても、ヒアリングの質と深さなんだと思っています。
他の制作会社さんでよくあるのが、「もらった要件に100％応える」っていうスタンスかと思います。でも、それだけだと背景にある課題や運用面の事情を見落としがちなんですよね。
たとえば「こうしたいんです」って言われても、実は裏で別の運用部隊がめちゃくちゃ工数かけてたりすることもあるので…。なので、どこまでも掘り下げる姿勢を大切にしていますね。
KSRのプロジェクトが安定して成果を出せるのも、ヒアリングにしっかり時間をかけ、背景理解を重視しているからだと思います。
Q：ユーザーの目線を意識したときに、少しでも違和感や不明点があれば、自分が納得できるまで聞き続けたりするんですか？
そうですね。大いにあります。
たとえば、以前「スタートアップ向けのDBサイトのようなものを作りたい」っていう案件があったんですが、それもただのDBじゃなくて、どういう目的で、誰に使ってもらいたいのかをかなり深掘りしました。ユーザー視点で見れば、「この検索機能って本当にこの形でいいんだっけ？」みたいな話も出てくるし、ビジネス側が思想強めだと「いや、こうだろ」って返されることもある。でも、逆に思想がふんわりしてると、「なんとなく他社がやってるから、うちもそうかな」みたいな曖昧なまま進めようとすることもあるんですよね。
そういうときに大事なのが、ユーザー視点で解像度を上げてあげることです。「誰の、何の課題を解決するプロダクトなのか」っていう軸に立ち戻るようにしています。そのうえで「エンドユーザーにとって本当に必要な体験は何か」「社内の利用者にとって負担が減る仕組みになっているか」を具体的に突き詰め、ユーザー目線でプロダクトに落とし込むようにしています。
Q：普段からシステムの使い方までをイメージしているかと思いますが、現代あらゆる言語があるなかで全部を理解しにいくのは難しくないですか？
確かに、最新の開発言語や環境が次々と出てくる中で、すべてをキャッチアップするのは現実的ではありません。ただし、根本となる基礎知識──たとえばDBのテーブル構造やAPIの仕組みなどは不変の部分です。
このベースを理解していれば、「このUIを実現するなら構成が破綻するはず」という違和感にすぐ気づけます。逆にここが弱いと、見た目だけで判断して無理な構成に走ってしまう。だからこそ、新技術を追いかけること以上に、土台となる知識をしっかり持つことが大切だと考えています。
Q：要件定義を提出しても、実際のイメージが難しいような非エンジニア系のクライアントの際は、どのように対応していますか？
そこはもう、「とにかく早く、目に見えるものを出す」っていうアプローチを取っています。やっぱり、構成図とかテキストで「こういう感じで作りますよ」と言っても、非エンジニアの方にはイメージが湧かないと思うんですよね。それはもう仕方ないと思います。
なので、まずは超ドラフトレベルでいいからワイヤーをさっと描いて、方向性を見せながら、ズレてないかを確認していきます。もしそこで「なんか違うな」となっても全然OKで、「どこが違うのか？」「実はこういうユーザーじゃなかったかも」みたいなディスカッションが生まれる。その会話を通して、またヒアリングを深めていく。その繰り返しで解像度が上がっていくんだと思っています。
Q：要件定義が大事だとは感じつつも、社内にその人材がいない企業にどのようにアドバイスしますか？
外部からの立場で言いにくい話ではあるんですが…。やっぱりプロダクトのコアに関わる部分は、内部に持つべきだと思っています。誰に向けて、何を解決するためのプロダクトなのかって、めちゃくちゃ大事な部分だと思っていて。そこが外部の人間だけで進むと、どうしても"他人事"になりがちなんですよね。
もちろん我々としても、クライアント様以上にユーザーのことを考えるつもりで動いていますけど、たとえばその会社が潰れるかも、という局面で、一緒に心中できるかといったら、それは難しい。だからこそ、志をともにできる人が社内にいるべきだと思います。
ただ、もし「何をやりたいか」は明確だけど、それをどう実現するかが分からないという場合は、その部分は外注でも全然いいと思っています。強い想いさえあれば、形に落とし込むところは僕らが引き受けられます。
Q：外注先を選ぶうえで、どんな点に気を付けるべきでしょうか？
クライアントと向き合うだけじゃなくて、ユーザーと向き合える人かどうか、そこが一番大きいと思っています。
「こういうもの作って」と言われたものを、そのまま作ってしまうと、たいていズレが起こるんですよ。だから「でもユーザー目線ではこうじゃないですか？」って提案できる人じゃないと、やっぱりプロダクトってうまくいかない。
逆に、「言われた通りに作るだけです」みたいなスタンスの外注先だと、認識のズレや手戻りがめちゃくちゃ増えて、なかなかうまく回らない印象がありますね。
ちゃんと一社員みたいな感覚で、自分ごととして動いてくれる人にお願いしたほうが、間違いは起きにくいと思います。
Q：ご自身は、どのようにして要件定義スキルを身に着けたのですか？
もともとWeb制作会社で営業として入社したのがキャリアの始まりです。けど、半年くらい経ったころに社内転職的な形でフロントエンドエンジニアに転向しました。
そこから1年半くらいは、Web制作の現場で開発やディレクションをやっていて、その時期にIT周りの知識が結構身についたと思います。
その後、求人サイトを運営する会社に転職して、グロースハック部門に所属しました。ちょうどプロダクトの大規模リニューアルが進んでいた時期で、「このプロダクト、どうあるべきか？」ってところから関われたのは大きかったですね。
要件定義って、実際にはディレクション・開発・マーケティングのスキルが全部混ざってるんです。でも、全部を専門でやる必要はなくて、それぞれの分野から「上澄み60%」くらいをきちんとすくってこれれば、PdMとしては十分戦えると思っています。
Q：最後に、どのようなお仕事をされていますか？
今はフリーで、PdMやWebマーケ支援を中心にやっています。
これまでの経験をベースに、浅く広く、中くらいの深さでいろんなプロジェクトに関わっていて。単発じゃなく、長く伴走していくようなスタイルが多いですね。
クライアントの「まだ言語化されてないやりたいこと」を一緒に深掘って、それをユーザー目線で設計に落とし込んでいく──その一連の流れこそが、僕の仕事の本質だなと思っています。
▶︎ 編集後記
sekiさんのインタビューからは、要件定義が単なる要望整理ではなく「共に創り上げるプロセス」であることが伝わってきました。クライアントの言葉の奥にある意図を掘り下げ、ユーザー視点に立ち返ることで、曖昧な要望も解像度を増して前進していける。要件定義こそがプロジェクトの成否を左右する大事な基盤であり、相談しながら進めることで形にできるのだと感じます。
