学習記録：12月17日(月)：はじめよう！要件定義 Chapter-05 要件定義、その前に ＆ Chapter-06 ［準備編］企画を確認する
これは 俺のインプットアウトプット記録 Advent Calendar 2018 の17日目のエントリーです。
さて、明日は 徹底的に要件定義について学ぶ研修 があり、その教材の元になっているのが、この はじめよう！要件定義 という書籍だったりします。
ですので今日はMySQLはいったんおやすみし、前回の 学習記録：12月10日(月)：はじめよう！要件定義 Chapter-03＆Chapter-04 に引き続き要件定義の学習を進めます。
Chapter-05 要件定義、その前に
というわけで前章までは
- UI
- 機能
- データ
を決める、という流れで、実際に詳細を見ていきますというところで終わっていました。
UI定義という工程
UIが決まった、というゴールに到達するには、何をどうすればいいかと問われます。
どんな材料を使って成果物（ゴール）に向かうのか。それをまずUI定義から始めるということかな、と理解してます。
要件定義の旅への出発準備
目玉焼きという成果を出すには卵という材料が必要なのと同じく、定義されたUIという成果を出すにも材料が必要と書かれています。
そこで材料を揃えるための要件定義の旅、その出発の準備をするとあり、要件定義そのものではないとあります。
要件定義を行うために必要な材料を揃えるための作業がしばらく続くとあり、僕自身、要件定義を「何を持って完了とするか」を曖昧なまま今まで来てしまったので、非常に楽しみな内容です。
現実のプロジェクトあるある
要件定義と称して、要件定義の準備を行なっているケースが非常に多い、とあります。
よって、これから出てくる準備段階を要件定義としてやってしまっているってことは、要件定義の前工程である準備を先送りした事実の現れである、という理解を僕はしました。
そんなプロジェクトは好ましい状態じゃないよね、ということで次に続きます。
Chapter-06 ［準備編］企画を確認する
僕は企画の部署に所属していたことがあるのでなんとなくわかるのですが、要件の前に企画が必ずあるんですよね。なのでそのことかなと思いつつ読み進めてみます。
ゴールを確認する
ソフトウェアを作る、というゴールを確認すると、依頼する・作るからには、思いつきだけじゃない、 企画意図が明確に定義されている はずとあります。
本当にその通りだと思いますし、思いつきだけで作ったプロダクトで成功した物を僕はみたことがありません。
以前、事業コンテストをきっちり行なっていた会社でも、思いつきだけではなく、役員全員に対しプレゼンをし、利益の可能性、市場の状態、人員確保、スケジュール、損益分界点など、裏付けの情報を含めてしっかりやっていました。
また、そうじゃないと予算など確保できないよね、とあり、その通りだよなと思います。
で、ソフトウェアはその企画意図を達成できるものじゃなきゃいけないし、企画意図から外れた要件を定義してしまったら、いくら要件定義通りに作っても納得が得られない、ということになるとあります。
当たり前の話ですけど、新規事業でも、受託の要件定義でも、できてない場面たくさんあるし、たくさん見てきたなー、と思い出します。
企画書を確認できない＝ゴールの定義が不明瞭
企画確認は企画書を見るのが手っ取り早い。しかし現実では見ることができない場面がある、とあります。
- 社内秘なので企画書を外部に見せられない
- そもそも企画書がない
大雑把にいうとこの2つですとあり、そうだよなって思います。
重要なこと
企画書が見られない場合、それに代わるものが存在しない、つまりゴールが不明瞭である状態が問題であるとあります。
不明瞭とは、これを見ればわかるよ、という状態が得られないこと。それにより
- 毎回口頭で解説を受けることになる
- 記録に残らない
- 時間の経過で簡単に変わってしまうことになる
- 口頭の内容がブレる
- 説明が面倒で端折る
ことで、結果として内容理解が関係者でバラバラになる。それぞれの「今回のゴール」がバラバラになり、理解の個人差が混乱を招くとあります。
全くその通りだし、ゴールが曖昧なままなのは、社内の他のチームから見ても不安になりますし、「何を目的にして、何を利益に還元するのだろう」と疑問にも思います。
次は「企画書を作成するためにまとめる項目」が具体的に出てきます。
企画書を作成するためにまとめる項目
バラバラになる問題は、プロジェクトマネジメントの問題で、要件定義の作業の問題ではないとあります。そりゃそうですよね。仕組みや組織の問題ってことでいいのかな。
しかし材料を揃えないといけない。揃わないと不明瞭な要件定義のまま進むことになる。
ゆえに、関係者全員がひと目で「理解を共有できる」企画書を作る必要があり、その最低限の項目が列挙されています。
- プロジェクトの名称
- なぜこのプロジェクトをやるのか
- 目的
- 何を
- 目的達成のために作るもの
- 作るものの説明
- 作るものを利用する人
- 利用する人が得られる便益
- どのように
- 作るための体制
- 期限
この程度で構わない、と文中にありますが、この程度が全然できてないの多いよなーと思ってたら、次の文に このようなサマリーが存在しないプロジェクトが実に多数見受けられます とあってわかりみが深かったです。
なので、企画会議に出た人以外は、企画意図を理解する手がかりがないまま進んでしまう、つまり 企画者が後工程に対して理解不足である とあります。
これ、エンジニアでもマーケターでもディレクターでもなんでも、職種に関係なく、理解不足な場面あるよなって思いましたし、企画意図って上述の項目全部に理由があるはずで、それが 解説できなかったらその時点でその企画はダメなんだろうなあ と思いました。
僕が思うこと
名前って大事だよなって思います。業務システムで曖昧なまま進むのをみたことありますが、呼び方ひとつ取っても曖昧で、なんというか情熱というか、気持ちが入りにくいんじゃないかなって思ったりします。
目的はもっと大事というか、これ企画する一番最初にあるよねって思いますし、 目的ないのはただの趣味 だよなって思ったりもします。
また、目的達成のために作るものは何で、その内容はどんなもので、利用する人、つまりターゲットだと思いますが、そのターゲットはどんな人たちなのか。
で、その ターゲット＝利用する人が何を得られるのか。押し付けじゃないよね、使って幸せになれるよね、って話だよな って思いながら読みました。
この辺に 無理なこじつけがある場合は、企画そのものに無理がある んだろうなあ、と思ったりもします。
また、企画といってもゼロスタートのサービスじゃなく、 既存サービスの新機能にも同じことが言える と思います。
以前、人材系のサービスに関わっていたときのプロジェクトマネージャは非常に優秀な人で、 各部署で企画が立ち上がったら片っ端からエンジニアを派遣し、スピーディーに実現可能性について即答できる状況を作った りしてました。
エンジニアだからといって企画、要件定義に関わらなくていいてことは全くなくて、むしろそこから関わることで、熱量や背景、歴史、目的、つまり 企画意図が正しく伝わり、同じ方向のゴールをみてプロジェクトが進められる んだろうなって思います。
読んでみて
ずっと自分の中にあった 思いつきだけじゃない、様々な根拠に裏付けられた企画意図 があるのが大前提だよな、という思いが、ここで見事に解説されていて、頷きしかないなって思いました。
そして、世の中にはそういった、思いつきだけで突っ走っては消えていくサービスが多いよな、ということも思いました。
それが良い悪いはさておき、思いつきだけで走るのは博打以外の何者でもなく、それが道楽ならいいですけど、利益をあげる必要がある場所で開発に関わるなら、 勝算のある博打を打つ 必要があるよなって強く思いました。
また、自分の今までの事業や企画に対する思いが間違えていなかった。それを確認できただけでも、読んでみて得られることは大きかったです。
次以降、読み進めるのが非常に楽しみですし、明日から始まる研修が楽しみで仕方ありません。
というわけで今週は要件定義週間になりそうです！
