要件定義は"指針"。Whyに立ち返り、迷走を防ぐ
日頃KSRで活躍されている久保田さんに、KSR SS事業部責任者の丸山がインタビューを行いました。
Q：久保田さんにとって要件定義とは?って言われたら何て言います？
むずいですけど、ざっくり言うと"指針づくり"です。プロジェクト全体で合意するための土台で、ここがしっかりしていればぶれにくい。最初に要件を洗い出すことでコストが下がるかもしれないし、納期も明確になる。ビジネスサイドとのすり合わせも進むし、チームが「いま何のためにこの作業をしているのか」を見失いにくくなる。細かいところで迷っても「ちょっと待って。最初の指針に立ち返ると、これやる意味ある？」と気づける。私のイメージでは"設計図"であり、"展開に合わせて行動を揃えるツール"ですね。
Q：その中で、要件定義をしてないから失敗した、これ要件定義ちゃんとしてないからだよみたいなエピソードってありますか？
よくあります。慣れていない人に任せると「どう作るか」から入っちゃう。作り手の論理に寄りすぎて、ユーザー目線だと「それ要る？」みたいな機能が混ざるんです。中盤〜後半で「欲しかったものと違う」に気づくか、最悪リリース後に使われない。実際、私のところに依頼が集中して、分散のために他のメンバーに振ると、既存のシステムを見て「こう作ればよさそう」と手段から入ってしまうことがある。そこで必ず問うのは「なんでそれなの？本当に必要？」です。要件定義が甘いと、この問答がプロジェクト後半に噴き出します。
Q：作り手の論理で、作り手もいいものを作ろうとしてるのに、なんか違うものができちゃうって何の力学が働くんでしょうね？
視野が狭くなるんですよね。設計や実装が面白くて"どう作るか"に没頭すると、"なぜ作るか"に戻る機会が減る。
いわゆるゴールデンサークルの「Why」に立ち返らないと、目的と手段が入れ替わる。私も若いころ、検索機能ひとつ作るのにクエリや部分一致の話ばかりしてしまってました。
でもユーザーにとって大事なのは「欲しい結果が出るか」。受託や SES だと"仕様が落ちてくる"スタイルで、自分事化しづらい分、この罠にハマりやすい。だからこそ、「一回外に出て目的を見直す」時間を、意図的に差し込む必要があると思っています。
Q：既に結構重要な要素も出てますけど、要件定義で他に大事なものってありますか？
何をするかって目的に立ち返るのが一番ですが、他で言うと本質まで掘ることです。ユーザーや顧客が「こうしたい」と言っても、本人も理由を言語化できていないことがある。ヒアリングだけでなく、行動観察や利用データも見て、「本当にやりたいことはこっちでは？」を一緒に確かめる。
とはいえ受託では、求められる深さのバランスもあると思います。どこまで掘るかは案件と関係性次第。だから"なぜ・何を"を本質レベルまで詰める意識を持ちつつ、現実的な線引きも同時に設計します。
Q：そもそも目的そのものを疑ったり、到達するための手段を疑う力であったり、究極的には「目的に立ち返る」ことがやはり重要ってことですね？
はい。最終的にそこです。データ分析やユーザーヒアリングといった手段はいろいろあっても、根っこは「なぜ」を繰り返すこと。さらに、成功に必要なのはバランス感覚です。リリース時期、コスト、スコープを並べて、オーバースペックやオーバーエンジニアリングを避ける。オーナーと「今回はどこまでやるか」を合意し、なぜそう判断したかを言語化してチームにも浸透させる。目的を深掘り→噛み砕き→合意形成、までやり切るコミュニケーション力が、要件定義では必須だ。
Q：非エンジニアの事業責任者って、コストやスケジュールなどのバランスはわかるけど、"要件定義ってできる気がしない"と感じがちに思います。この差分ってなんだと思いますか？
技術の視点が必要になるからです。要件は最終的に"どう実現するか"に落ちる。軽量に作るのか、セキュリティをどう担保するか、障害時の保守は…など、実装パターンの勘所は経験知が効く。ただ、そこはフレームワーク化・ナレッジ化で支援できます。判断の型やチェックリストがあれば、非エンジニアでも一定レベルまで担えるようになるはず。
Q：要件定義に悩む非エンジニアの新規事業担当・事業部長に、一言アドバイスするとしたらなんて言いますか？
最低限でいいので、技術を学んでください。"エンジニアに押し切られない"程度で十分です。セキュリティ、性能、可用性みたいなリスクの勘所を持って、「それ、なぜ？説明して」で対話できること。要件定義は役割分担の競技です。ビジネスの戦略は任せる。その代わり、僕らはその戦略を信じて走る。だから戦略はむやみに変えないでほしいし、変えるなら"なぜ"をセットで。お互いプロとしてリスペクトし合って進めるのが、一番の近道だと思います。
▶︎ 編集後記
久保田さんのお話から伝わってきたのは、要件定義を「作り方の議論」ではなく、常に目的に立ち返るための仕組みとして捉える姿勢です。手段に没頭しがちな現場にあえて「なぜ」を差し込み、合意形成までやり切る。さらに、コストや納期とのバランスを見極め、技術とビジネスを橋渡しする力は、プロジェクトを迷走させない大きな支えになっています。