「はじめよう！要件定義～ビギナーからベテランまで」から学ぶ要件定義の始め方

はじめに
おすすめの読者層
要件定義とは
よくある問題
要件定義の始め方
おわりに

はじめに

こんにちは。rs_chankoです。

最近はもっぱらオフショア管理の業務をしています。
最初は納品物のチェックがメインだったんですが、ここ数か月、案件の依頼を出すことが増えました。

最初は見様見真似でリーダーのやっていることをやってみてはいろいろ指摘を受けていたのですが、
自分の持っている技法や観点では思うように内容を拾いきれず、依頼内容がいまいちになってしまうことが多いことに気付きました。
「このままではだめだ！」と思いいったん本を読んでみようということで要件定義についての本に手を出してみました。

作業依頼って要件定義の簡易版って感じなんですよね。体感的にですが。
そこで今回はその本がなかなか初級者に易しく、さっそく実践しているので記事にしてみようかなと思い書いているといったところです。

今回読んだ本はこちらです。(これもリーダーのお勧めで決めたのは秘密です。)
www.amazon.co.jp

表紙の通り、前半は目玉焼きを作る工程で要件定義とは何ぞやという説明がされている本です。(とってもとっつきやすい)

◆ 関連ブログも合わせてご参考ください。
・要件定義とは【まとめ】
・プロジェクトマネジメントTips 20選　～現場から語るプロマネの極意～

要件定義とは

そのまま要件を定義することなんですが、実際その「要件」を「定義する」とは何なんでしょうか。
■要件=注文
依頼する人(ユーザーや企画部など)が開発に対して「こういうものを作ってほしい」「こんな機能があったら便利」というところから、プロダクトの開発は始まると思います。
個人であればそのふわっとしたものからあれやこれやとつけたい機能をつけてアプリなりなんなりを作成しますよね。
ただグループや企業だと最初に認識を合わせておかないと大きな齟齬が起きたり、大量のバグの温床になりかねません。
そういったことを避けるために作ってほしい人が作る人に出す要望が要件になります。

例えばの話にはなりますが、なんでもできる万能な車を作ろうと考えています。
依頼主からの要望は * 空を10m飛びたい * ベースは日本製の一般車にしたい * 陸上は通常通り走れるようにする * ガソリンが燃料

これらの要望が要件です。

ただ、お客さんが要件を並べたらすべてが叶うというわけではありません。
魔法の力で何とか空を飛ぶ車は作ることができるとします。
日本製の車に空を飛ぶ拡張機能を付けました。
余分なパーツをつける場所もなくなり、完璧な形に仕上げることができました！

しかし、あとから依頼主が「水上も走れるようにできないかな」と言い出しました。
事前に決まっていればそれ用に作ることもできましたが、
空陸用に作り上げてしまったため、水上を走れるようにというのは叶えられませんでした。
このため、こちらの要望は諦めてもらうことにしました。

本来であれば、水上も走れるようにしたいと言うのは、要望をまとめる段階で出しておいてもらうべきです。
ただ、その部分を完璧に詰めずに車を作ってしまったため、依頼主は渋々諦めることになりました。

このような「できること」「してほしいこと」「できないこと」をはっきりとしておくことが要件定義なんですね。

よくある問題

現実的な開発の話に戻します。
事業部や取引先などから新しい製品や、新しい機能を作る話が開発に降りてくるでしょう。

要件定義の場を設けて、仕様についてまぁまぁ詰めた状態まで持っていったかなというところで、
「これやってください」が決まったとします。
開発者はそれを実現するために動くと思います。
ただ、次のような問題が往々にしてあるはずです。

要求が不足している

実際に作ってみたものはいいものの、既存の機能の考慮が足りていませんでした。
「あれ、この既存機能も新機能反映しないといけないんだっけ？」「え、無視していいんじゃないの？」
といった具合に後から要件の見直しをすることもあるんじゃないでしょうか

要求が曖昧

どんなものを作るかイメージはつきました。
イメージはついたものの、仕様が虫穴で「この条件は付けるべきなのか」「この時の動作はこれでいいのか」が分からず、設計段階で詰みますね。
もっと酷ければ実装してテストしているときに気付いたりすることもあります。

そもそも要求を叶えるのが不可能

要件定義の時点で不可能やないかーい！といった事態。
技術的な物だったり、既存機能を壊してしまったりなど、様々な理由でできないことがあったり。
基本はスタートの段階で気づくとは思いますが、作ってみて気づくなんてことも現場では起きますね。

要件定義ではじゃあいざ設計だ！実装だ！より前に今あるものに対してどのように対応していくのか、そこまで考える必要が出てきます。

今ある機能や実現したい機能と、バッティングする場合どちらを生かすか、どう共生させるか
実現したい機能が今の製品や機能に与える影響はどの程度がいいのか
そもそも実現したい機能の細かなつくりはどこまで考慮すればいいのか

これでいいのでは？で進めてしまうことで、正しく作ったつもりが依頼主との間で出来上がりに乖離が出てしまいますよね。
依頼主からの要求が足りていないのであれば要件定義の段階ですり合わせていくというフェーズが必要です。
各会社や個人で流儀や手法はあると思いますが、
画面のモックなどのイメージや、システム部分の仮設計を使いながら、不足している要求を引き出すことが開発側の要件定義です。

要件定義の始め方

まずは実現したいことを一覧にしてわかりやすくする必要があります。
書籍では企画書の作り方として書かれていましたが、ユーザーや事業部の望んでいるものがふわっとしているときには開発側でそこまでまとめる場合もあると思います。
書籍で書かれているような技法を、アレンジして業務に取り入れたりもしているため、
ブログ用にさらにアレンジして、書籍の技法を簡単にまとめてみました。

今回は記事用に遠い昔にアルバイト時代の店長にアプリを作って！と言われた際の要求をまとめてみます。(アプリ制作自体は諸事情あってやっていませんが。。。)
その時に店長が作ってくれといったアプリの要求は以下のようなものです。

外国人メンバーのためのマニュアルアプリ
- メンバー同士で注意点を共有できるように、記事を投稿できる
- いいねボタンみたいに参考になったよボタンを設置してポイント制にする

当時こんなふわっとしたオーダーだけでアプリ作って！と言われ困惑しましたが、それは置いておきます。

これだけ聞いた際にどんなことが実現できればいいかなと思ってヒアリングをしたので、そこから要求をまとめてみました。

概要	外国人・新人メンバーのための手順書・注意事項共有アプリ
目的	・会社から提供される手順書はつぶれた写真だったり、白黒で分かりにくい・文字での説明はついているけど、外国人にはニュアンスで伝わりにくい・上位メンバーが知ってるコツを集約してどのメンバーでもわかるように動画などで共有したい
現状	・紙のマニュアルのみで、上位メンバーがつきっきりで教える必要がある・複数のメンバーに手順書には書いていない同じ注意をしたことがある・メモを自発的にするメンバーと全くしないメンバーがいる
あるべき姿	・上位メンバーでない人でも教育ができるようになる・誰かに一度説明したら、メンバー同士にその内容が共有される・メモをしないメンバーでも手元に情報が残っている
目標達成に必要な要素	・twitterなどのように各メンバーが記事を投稿できるアプリ・動画付きで投稿ができる・参考になる度合いでソートすることができる(必要性の高いものから見ることができる)
無視していい要素	・投稿に対するコメント機能は必要ない

例なのでかなり荒いですがこんな感じで「できること」「してほしいこと」「できないこと(厳密にいえばしなくていいことですが)」を並べました。
視覚的に何をすればいいのかがわかるため、実現したいこと／実現できないことを早い段階で拾うことができるようになります。
これが要件定義の第一歩、スタートです。
こちらを元に実装や設計をする開発側と依頼主側で、実際に出来上がるもののイメージをすり合わせていきます。
出来上がってから「あれはできないの？」「これはできないの？」となってしまうと、最悪一から作り直して倍の工数がかかって納品が大幅に遅れてしまうと言うこともありますね。
そういうことを避けるためにも、じっくり要件定義で時間をかけて、設計、実装はすんなり、サクサク進めて後から余計な工程が起きないようにすることを心がけることが大事です。
そのためにも要件定義のスキルを習得して、確実な状態でのスタートを切れるようにすることが上手な開発の第一歩です！

おわりに

最近はあまり大きな機能を扱っていないので、例で程度示した程度の粒度のものを複数打っています。
仕事でもオフショア先に依頼する際にも上記のように文面を組み立ててパターン化して以来前の確認もしやすいようにしています。
なのであんまりテクいこと書けてないんですが、要件定義や作業の依頼に重要なのは上記の表みたいな内容だということが本を読んで確信を持てた、といった感じです。(やっていることが、世間的に使われるような技法だったと言う裏どり、心強く感じて大事だと思います。)

目的(何がしたいのか、)
現状(問題点、不足しているところ)
あるべき姿(問題が解消された状態、できるようになること)
必要な要素(あるべき姿にするためにすべきこと、付随してできるべきであること)
不要な要素(考慮する必要のないこと、対応できるけどしなくてよいこと)

この辺をはっきりしておくことでいざ設計だ！実装だ！ってなった時に迷うことも減りますし、
納品だ！って時に「いやそれは要件として提示されていないので」という材料になるんですね。
逆に言えばですが、はっきりしていないと「え、これは当然じゃないの？」と押し切られ、ネットでよく見るn次受けの地獄現場みたいなことが起こるんですよね。。。
自分の身を守るため、クライアントと良好な関係を築くためにも、要件定義の技法は自分の物にしていきたいと思いました。
皆さんも気持ちよく、無駄のないスマートな開発をするためにも、こちらの本読んでみてください。
使える技法から徐々に取り込んでいくことで現状を打破するきっかけになるかもしれませんね。。。

さらに細かいこと、設計チックな話は紹介した書籍に細かに書いてあるのでぜひ読んでみてください。
内容的にも読みやすいのでどんな方にもおすすめです。

まず第一に抑えるところ！的な記事になってしまいました。
あまり細かく書きすぎると盗作になってしまいそうなのでこんな感じで悪しからず…。

エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。

https://career-recruit.rakus.co.jp/career_engineer/
カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
forms.gle
イベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com