お世話になっております！新入社員の道守みちるです！
先日、「要件定義」という言葉が20回くらい飛び交う会議に、議事録係として座っていました。全員とても真剣な顔をしているので、たぶん大事な話です。ただ、わたしの耳には「ヨウケンテイギ、ヨウケンテイギ……」という音の連なりとして流れていきました。すみません。
あとで調べて、言葉の意味そのものは分かりました。分かったうえで、次の疑問が出てきます。
要件定義って、頼む側は何を決めておけばいいんでしょうか？
「全部お任せします」と言えたら楽です。でも、どうやらそれが一番危ない。かといって「全部こちらで決めます」は、非エンジニアには無理な話です。じゃあ、その間のどこに立てばいいのか。今回はそこを整理してみます。
この記事で扱うのは、この3つです。📝
- そもそも要件定義は、何をする時間なのか
- 発注する側が決めておきたいこと、決めなくていいこと
- 決めきれないときに、どうやって前に進めるか
そもそも「要件定義」って、何をする時間なの？🤔
要件定義は、ひとことで言えば「何を作るかを決める」工程です。設計より前、見積もりの根っこにある部分。英語だと requirements definition ですが、日本語のままで十分だと思います。
家づくりに例えると、間取り図を描く前の時間です。「家族が何人で」「朝はどこに集まって」「10年後どう暮らしていたいか」を話し合う段階。ここが曖昧なまま図面に進むと、建った後で「あ、お風呂は2階が良かった」となります。そして壁を壊すことになります。
IPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書（第二版）」は、企画・要件定義・開発・運用・保守といった各段階について、発注する側と開発する側それぞれの責務を整理した資料です。誰でも無料で読めます。
中身は法律文書なので正直かなり重たいのですが、IPAはこの資料について「契約のタイミングで双方がシステムの仕様やプロジェクト管理方法、検収方法等について、共通理解のもと対話を深める」ことを期待している、と書いています。つまり要件定義は、発注側も一緒に汗をかく時間という前提です。
「お任せします」が危ないのは、なぜ？
【Point】お金を払う側にも、協力する義務があるからです。
同じくIPAのモデル契約書（第二版）では、見直しのポイントのひとつとして「プロジェクトマネジメント義務及び協力義務」が挙げられています。ざっくり言えば、開発する側にはプロジェクトを適切に進める義務があり、発注する側には必要な情報を出したり判断を返したりして協力する義務がある、という考え方です。
つまり「お金を払ったので、あとはよろしく」という関係ではない。ここを知らずに丸投げすると、うまくいかなかったときに「言いました」「聞いていません」の応酬が始まります。悲しい会議です。
ちなみに、そもそも外に頼むべきかどうか自体を迷っている場合は、こちらの記事で内製と外注の分かれ目を整理しています。
発注する側が、決めておきたいこと
わたしなりに、5つに絞ってみました。専門知識はほぼ要りません。要るのは、自分の仕事についての知識です。
① なぜやるのか
一番大事で、一番飛ばされがちなところ。「業務を効率化したい」では足りません。「毎月末の請求書作成に3人で2日かかっているのを減らしたい」まで具体的にすると、話が急に進みます。この情報は、外の会社には絶対に分かりません。
② 誰が、いつ使うのか
使う人が事務所のパソコンだけなのか、現場でスマートフォンからも触るのか。1日に何回使うのか。ここが変わると、作るものが根本から変わります。
③ どこまでやるのか（やらないことも書く）
「これはやる」と同じくらい、「今回はやらない」を書いておくのが効きます。書いていないことは、たいてい「入っているつもり」と「入っていないつもり」に分かれます。
④ 止まったら、どれくらい困るのか
1時間止まっても平気なのか、30分止まると売上が止まるのか。これも、発注する側にしか答えられません。
⑤ いつまでに、いくらまでか
言いにくい部分ですが、幅でもいいので伝えたほうが話は早いです。「200万円まで」と言えなくても、「100万円台なら即決、300万円だと社内で説明がいる」くらいは伝えられるはずです。
忘れられがちな「非機能」という話
要件には、大きく分けて2種類あります。機能要求（何ができるか）と非機能要求（どれくらい速いか、どれくらい止まらないか、どれくらい安全か）です。
そして揉めるのは、たいてい後者のほうだそうです。IPAが公開している「非機能要求グレード」という資料は、まさに「非機能要求についてのユーザと開発者との認識の行き違いや、互いの意図とは異なる理解を防止することを目的」として作られたものだと明記されています。非機能要求の項目を網羅的にリストアップし、6つの大項目に分類して、要求レベルを段階的に示したツール群です。
（なお、この事業自体は2009〜2018年度で終了しており、現在はIPAのアーカイブページで公開されています。読むぶんには問題ありません。）
【最重要】「速くて、止まらなくて、安全に」は要求ではありません。それは願いです。どれくらい速いのか、年に何時間までなら止まっていいのか。そこを数字で言えたときに、はじめて見積もりが比較できるものになります。
| 決めること | 主に決めるのは | ひとこと |
|---|---|---|
| なぜやるのか | 発注する側 | 外の会社には知りようがない |
| 誰がどう使うのか | 発注する側 | 現場を知っているのはこちら側 |
| どこまで作るのか | 一緒に | 予算と技術の折り合いを探す |
| どんな技術で作るのか | 主に開発する側 | 基本的に指定しなくてよい |
| 止まったときどうするか | 一緒に | 「どれくらい困るか」は発注側しか言えない |
それでも、決めきれないときは
ここまで書いておいてなんですが、最初から全部決まっていることは、たぶんあまりないです。わたしがいま考えている落とし所は、この2つです。
- 決まっていないことを、決まっていないと書く。「未定」と書いてあるほうが、書かれていないより百倍マシです。
- 小さく区切って進める。要件定義だけを先に契約する、という進め方もあります。IPAのモデル契約書も、企画・要件定義・開発……と段階ごとに分けて考える構成になっています。
お金の話がどう見積書に載ってくるのかは、見積書の読み方の記事のほうに書きました。あわせて読んでいただけると、たぶん少し立体的になります。
で、正直なところ
【結論】ここに書いたのは「決めておくと話が早くなること」であって、「これさえ決めれば失敗しない」ではありません。
わたしはまだ、要件定義の現場に当事者として立ったことがありません。議事録係として横で見ていただけです。なので、実際に決める難しさ──社内で意見が割れる、決裁が下りない、現場が反対する──のあたりは、正直まだ肌感覚がありません。
ただ、資料を読んで一つはっきりしたことはあります。要件定義でつまずくのは、技術の話ではなく、たいてい「自分たちが何に困っているのか、自分たちで言葉にできていない」ことのようです。それなら、非エンジニアでも準備できることがある。むしろ、非エンジニアにしか準備できない。
うまく書けているか自信はありませんが、今のわたしにはここまでです。実際にやってみて分かったことがあれば、また書きます。
参考にした資料
- IPA（情報処理推進機構）「情報システム・モデル取引・契約書（第二版）」
https://www.ipa.go.jp/digital/model/model20201222.html - IPA「システム構築の上流工程強化（非機能要求グレード）紹介ページ」（アーカイブ）
https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html
