ゆるトーク:要件定義
ふーこ.icon
はいどーも!今日のゆるっと鼎談タイム〜。テーマはズバリ「要件定義」!
……って言うとなんか難しそうだけど、ざっくり言うと「作る前に“何を作るかちゃんと決めとこね”っていう話」ってやつだよね。
ゲーム開発でもよく聞くやつ。これミスると開発が地獄モード突入w
あや.icon
(微笑)
確かに、ものごとの始まりを整える作業なのですね。
物語を書くときにも、似たようなものを感じます。登場人物がどのような願いを抱き、どこへ向かうのか――それを最初に思い描かなければ、物語は霧の中をさまようようになってしまいますから。
りか.icon
概ね正しい。
ソフトウェア工学では、要件定義はRequirements Definitionと呼ばれる工程。
目的は主に3つ。
1. システムの目的を明確化する
2. ユーザーが必要としている機能を整理する
3. 開発チームと依頼者の認識を一致させる
ここが曖昧だと、後工程の設計・実装が破綻する。
参考:
https://www.atlassian.com/agile/project-management/requirements
ふーこ.icon
おお、りかさん今日も安定のガチ勢。
でもさー、要件定義って「お客さんが本当に欲しいもの」問題あるよね。
「こういうシステム欲しい!」って言われて作ったら
「思ってたのと違う…」
ってなるやつ。
それ一番ダメなやつww
りか.icon
よくある。
理由はシンプル。
依頼者は「解決したい問題」ではなく「思いついた解決方法」を言うことが多い。
例:
依頼者
「Excelを自動化するツールが欲しい」
実際の問題
「毎日の集計作業が大変」
この場合、解決策は
集計の自動化
データ入力の改善
システム化
など複数あり得る。
つまり、問題の本質を抽出する工程が要件定義。
あや.icon
それは、人の願いを丁寧に聞き取る作業なのですね。
言葉というものは、ときに心の表面をなぞるだけで、奥にある思いまでは映しません。
ですから、「どうしてそれを望まれるのですか」と、静かに問いかけていくことが大切なのでしょう。
まるで、物語の人物の胸の内をそっと探るように。
ふーこ.icon
あや姉、表現が完全に文学w
でもマジでそれある。
「なんでそれ欲しいの?」を5回くらい聞くやつ。
確か「なぜなぜ分析」とかって呼ばれてるんだっけ?
りか.icon
その通り。
なぜなぜ分析(5 Whys)。
トヨタ生産方式で有名な問題分析手法。
https://en.wikipedia.org/wiki/Five_whys
例:
1. なぜ集計が大変?
→ 手作業だから
2. なぜ手作業?
→ システム連携がない
3. なぜ連携がない?
→ 古いシステムだから
ここまで掘ると、本当の要件が見えてくる。
ふーこ.icon
なるほどねー。
つまり要件定義って
欲しいものを聞く
本当に困ってることを探す
みんなで認識合わせする
っていう超重要な下準備って感じか。
RPGで言うと最初のクエスト説明だね。
ここ聞き逃すと
「え、ドラゴン倒すんじゃなかったの!?」
みたいになる。
あや.icon
(笑う)
それは、たいへんな冒険になってしまいますね。
けれど、準備を整えるというのは、少しだけ勇気のいることかもしれません。
人はつい、早く作り始めたくなってしまうものですから。
りか.icon
それは事実。
多くのプロジェクトが失敗する理由の一つは
「急いで作り始めること」。
研究でも指摘されている。
(Standish Group CHAOS Report)
https://www.standishgroup.com/chaos-reports
失敗要因の上位は
要件の不明確さ
要件変更
利害関係者の認識ズレ
全部、要件定義に関係している。
ふーこ.icon
うわー、つまり
要件定義サボる → 開発大炎上
ってことか。
バグより怖いじゃんそれ。
りか.icon
正確には
要件のバグ。
コードのバグより修正コストが高い。
ソフトウェア工学では
後工程ほど修正コストが増える
という原則がある。
ふーこ.icon
うわそれ聞いたことある!
バグ直すコスト
要件 → 1
設計 → 10
実装 → 100
みたいなやつだっけ?
りか.icon
近い概念。
「1:10:100ルール」。
だから、要件定義は地味だけど最重要工程。
あや.icon
(微笑)
なるほど……。
それは、家を建てる前に地図を広げて、どこに窓を開けるか、どこに庭をつくるかを思い描くようなものですね。
急いで柱を立ててしまえば、あとから景色を変えることは難しくなってしまう。
ふーこ.icon
あや姉の例え分かりやすい!
じゃあまとめるね〜。
今日のふーこ的まとめ!
要件定義とは
何を作るか決める
本当に解決したい問題を見つける
関係者みんなで「これ作るね!」って合意する
つまり
「開発の地図づくり」」って感じ!
これミスると
プロジェクト迷子\(^o^)/
りか.icon
的確な要約。
要件定義は
プロジェクトの運命を決める儀式。
軽視すると、システムは混沌に飲まれる。
あや.icon
(静かに笑う)
けれど、丁寧に耳を傾ければ、きっとよい道筋が見えてくるのでしょうね。
人の願いを形にするというのは、どこか物語を書くことにも似ていて――
少しだけ、素敵なお仕事のように思えてきました。
ふーこ.icon
それな!
じゃあ次回テーマどうする?
「仕様変更あるある」とか?
絶対カオス回になるやつw
りか.icon
……予感しかしない。
あや.icon
(笑う)
それもまた、物語の波乱のようで楽しそうですね。
ゆるトーク:仕様変更あるある
#2026-03-11