要件定義とは？
橋本：皆さんこんにちは。パラダイスウェアの橋本です。
中島：中島です。
古長谷：古長谷です。
橋本：だれプロラジオ、第3回ですね。
中島：3回ですね。
橋本：今回のテーマは。
古長谷：3回目は、『要件定義あるある』です。
橋本：要件定義あるある。要件定義ってめちゃくちゃ大事なんだけど、これも調査とか統計で、失敗プロジェクトをどこで失敗してるかっていう調査とか、いろんな調査あるんですけど、7-8割が要件定義のミスなんですよね。
「要件定義」って分かりづらい言葉のイメージだと思うんですけど、結局ゴールを決めることなんですよね。例えばアプリを作りたいですっていう話があって、予算は例えば今回1,000万円です、みたいな話とかで、いつリリースしましょう、じゃあ6月にしますとか、そういうのを決めていって、その中でできることは何かっていうのを、多分リストとかになると思うんですけど、それを決めていくのが要件定義なんですよね。
そして、普通に考えるとこれを後出ししたりとか、ぐちゃぐちゃにしたらゴール分かんなくなるから、プロジェクトが失敗するに決まってるじゃないです。
中島：迷子になりますからね。
要件定義でありがちなこと
橋本：でもそれをする人が大変多くてですね。何でそうなんだろうっていうのはあるんですよね。例えばお金払う側は「このプロジェクトにうちは3億円かけとるんや」、「俺の進退出世がこれにかかっとるんや」って思う気持ちは分かるけど、でも「今回やれる範囲って決めましたよね」って言ったあとに、「やっぱりこれもやってほしいんだよね」みたいな話って、結局食堂に行って、「おばちゃん、カレー」って言ったあとに、「やっぱりラーメンも」みたいな話と一緒で。
中島：「いや、キーマカレーのつもりでいたんですけど」みたいな話もありますよね。
古長谷：「チキンカレーですよ」
橋本：「食堂だからここは！」みたいな（笑）。
中島：「キーマはないわ！」みたいな。仮に「キーマカレーですね」って要求飲んだとしても、「いや、そこは卵乗せるでしょ、普通！」みたいな話もあったり。「いや、聞いてませんよ」みたいな（笑）。
古長谷：さらに「これ、オーガニックじゃないんですか」って聞かれたりします（笑）。
橋本：もう材料からつくり直す！
古長谷：単価が全然違います。
中島：いや、もう「ガッシャーン！」みたいなね。なりますよ（笑）。
橋本：だから、シンプルに話せば普通に分かることだと思うんだけど、なぜかやってくる人多いですよね。
中島：そうなんですよね。
橋本：Web とか IT のシステムってよく建物に例えられるんですけど、「今回は4階建てのビルで造りますね」って言って造ってたら、「やっぱり11階建てにしてほしいんだよね」みたいな話とかは、そんなの工事としてまず成立しない。「ええ？ それ基礎からやり直さないといけないですけど…」みたいな。
中島：そうなんですよ。「え、地下駐車場って入ってますよね？」みたいな話とかあるんですよ。（笑）
古長谷：初耳ですよね。
中島：「いや、初耳ですけど！」っていう（笑）。
橋本：「4階建てのビルに地下駐車場いるかね？」みたいな話とかもね（笑）。
中島：あります。
橋本：そんなことをやると、当然てんやわんやになる。だからそれをちゃんと説明してはねつけるのも PM の役割なんですけど、要件定義って理解されてないよねっていう話です。
要件定義の段階からデザインが必要
中島：デザイナーの観点から言うと、最近やっぱ要件定義からデザイナーが入っていかないと、デザイナーが入る意味がないみたいな案件が非常に多いなって感じているのは…。
橋本：僕はほぼ入れる。
中島：そうですよね、そうなんですよ。やっぱり、アプリとかウェブサービスとか非常に複雑なものの設計はデザインからやっぱりデザイナーが入っていかないと、さっきの建物で言うと、「4階建てなのにトイレは4階に1個しかありません」みたい話で、「おいおいおいおい！」みたいなことになったりするんですよね。
それなので、やっぱり要件定義が終わってからデザイナーが入っても、意外ともう本当に見た目のことを整える以外にデザイナーの出る幕がなくなってしまうので、それってもう全然デザインの意味がないと言っても過言ではないぐらいですね。やっぱりデザイナーって最近のそういうアプリケーション、サービスを設計する要件定義の段階では、デザイナーが上流から入るのはマストかなっていうのは非常に強く感じるんですよね。
橋本：「使いやすさ」みたいなのって、今はものすごく大事ですね。その技術とかノウハウを知ってるのはやっぱりすごく重要です。昔はディレクターがピクセル単位で画面遷移図を描いて、「ここにボタンを配置してください」まで決めないと私はデザインやりませんみたいな人が多かったんですよ。今もいると思うんですけど、それって単純にオペレーターだし、今はブートストラップとか出てきてるから、それだったらもうブートストラップ使うわ、みたいな話になるので。だからデザインとかもやることがどんどん上流に行ってるんですね。
中島：そうですね。やっぱり見た目を整えるだけの人と、そういうところまで分かる人っていうのはすごく分かれてきてるんですよね、くっきり今。
橋本：その見た目整えるだけの人って今もいる？
中島：やっぱりポスターとか紙の宣伝、パブリシティとかそういうところではやっぱりいるんですけど、やっぱり僕らのような開発とかの世界のデザイナーって、やっぱそういうとこ分んないと全然使いものにならないじゃないですか。
橋本：「昔はピクセル単位で指定してください、ちゃんと」ってすごく怒られたよ。（笑）今はそんなの考えられない。
中島：そうですね。「ピクセル単位で指定してくれ」って言うようなデザイナーを使いたいとも思わないですよね、やっぱり。ディレクターとか。
橋本：マネジメントコストがかかってしょうがない。
中島：かかってしょうがないです。だから、ワイヤーをひく人ってのも、スケジュールの観点から見ても、結構みんなどこもかしこも燃えてるんで。だからちゃんとしたワイヤーがまずないですっていうとこから、つまり要件定義から入っていくんで、デザイナーが簡単なワイヤーと画面遷移とかを考えながらデザインしていくっていう案件も多いですよね、やっぱり。
橋本：スケジュール的にワイヤーをきっちり作ると、ディレクターなりPMなりSEなり、いろんな呼び方あるんですけど、それを担当する人の作業量が結構膨大になるので、そこでスケジュールが結構決まっちゃうみたいなとこがありますよね。きっちり進めるときはそのやり方も大事だったりするんだけど、結構半年とか、僕担当した案件だと3、4カ月でサービス上げます、みたいな世界だと、その作業やってると行程の3分の1は画面遷移図作ってるみたいな世界になっちゃうんですよ。最近よく言うリーンスタートアップ型のプロジェクトでやるときは、最後はあとで詰めていきましょうみたいな感じでやったりはします。
要件定義の定義も様々！
橋本：要件定義って、僕とかは基幹システムのやつとかもやってたりするので、要件定義の定義がプロジェクトによって全然違う。
中島：要件定義の定義ですね。
橋本：それこそリーンでやる場合とかで予算も少なくて、スケジュール長くとれないから、とりあえず出すことを念頭にやります、みたいな話だと、ドキュメントを書いてる時間が必然的に少ないんですよね。全部が全部そうじゃなくて、ある部分は箇条書きで済ませるとかあるんですよ。それでプロジェクト内で合意できていて、認識のすれ違いがないようにしておく。これも要件定義なんだけど、別の基幹システムとかだと、データベースに何千万件も顧客情報が入っていて、一つ処理を変えるだけでものすごい何億っていう処理が発生する、みたいな世界だと、それこそIF文の部分をちゃんとチェックしないと、要件に沿った処理が行われない、みたいな話になるので、何が要件定義かっていうのも実はプロジェクトによって全然違う。
中島&古長谷：違いますね。
中島：本当に違いますね。
橋本：この辺がすごくPMの経験が出るところですね。
古長谷：3カ月でとにかく急いで何か作んなきゃいけないっていうときに「ガントチャート作って全部何か資料作って教えてくれ」って、「それで1カ月終わってしまうんです」ってところもあるので。
橋本：あるある。教科書読んだばっかりだとそうなっちゃうね。別に特定のノウハウ体系をディスるつもりはないんだけど、PMBOKとかね、大規模プロジェクトのノウハウなんですよ。100人、200人とかが大規模開発、何カ月もかけて、だから案件単位で言うと億から2桁億円以上のプロジェクトを標準化するためのノウハウとして提供されてるので、そのPMBOKでこういうフレームワーク使いましょうねっていうのをきっちりやってると、たぶん世の中的に、日常的に多くの人がやっているプロジェクトのサイズとマッチしないですっていうのがあるんですね。ただ、フレームワークを知ってることは大事なんだけど、でもそのプロジェクトは、ここは大事だからきっちりやりましょう、みたいな。そこら辺が結構難しい。
古長谷：年間単位で契約してるお客様とかもちろん年度当初に月次の報告とか、そういうのは作るんですけど、そうじゃなくてとにかくリリースが迫ってるっていうときは、本当に押さえなきゃいけないポイントと数字だけ、お金的な部分だけっていうので手一杯なこともあるので。
中島：なりますよね。
橋本：でもね、1日24時間しかないから、稼働しすぎると人って参ってくるので、そういうことを考えると使える時間を何に使うかっていう、最大限有効に使って、決めないといけないことをきっちり詰めていくのが要件定義なんですよね。
古長谷：そこで必ず押さえなきゃいけないところって、私が思ってるのは「稼働」に関するもの。誰をアサインするかと、その人がやるべきことで数字が見えてくる。そして、納期とクオリティのイメージを、私はブランディングなので、イメージ写真だったりとかですり合わせてく。これだけは絶対死守するってところがあるんですよ。他に、ここだけは押さえといたほうがいいってありますか？
橋本：システムとかサービスだと、機能一覧とか、画面遷移とか。結構画面遷移も作っておかないと、普通こうだろ、みたいなのが抜けてたりする。
中島：合わないんですよね。「普通こうだろ」は通用しないっていうのは後々出てきますね。
橋本：「ログアウトどこでやるの？」みたいな。よくある。
中島：「あ、ログアウトね」、みたいなね。
橋本：とか。「これ退会できないですよね」とか。いきなり課金やりたいって言って課金入れたんだけど、これ課金どうやって止めるんすかね、みたいな。「いや、もうお問い合わせで」みたいな。いや、ありえないありえない。多分法律的に駄目なんじゃないかな。あと、アプリだと課金停止の導線をちゃんと作んないとアプリの審査通らないとか。
中島：通らないですもんね。
橋本：そういうこととかもすごく影響しますよね。
ビフォー・アフターの要素は重要！
橋本：あとは、要件定義で絶対ぐらいやっといた方がいいのは、ビフォーアフター。「今こうで、これやるとこうなりますよ」っていう二通りをちゃんと作っておく。コンサル用語だと、As-is, To-beとか言ったりするんだけど、「今こうだからこうしますよ」で、「今こうだから」をちゃんとやらないプロジェクトが結構多いんですよ。そうなると例えば業務改善のツール作りますとか導入をしますっていったときに、「今」が分かってないから、「導入したあとにこうなります」って言っても、担当者たちは「え、どうすればいいの、実際に」みたいな感じになったりとか、結構そういうトラブル多いですよ。
中島：できあがったもん見たらめんどくさくなってるだけじゃないか、みたいなね。
橋本：本当そういうの多くて。
中島：誰も幸せにならないっていう。
古長谷：何のためだったんだろう。
橋本：よくある、社会問題というかニュースとかになったりとかしてる話だと、電子カルテですね。医療カルテのシステムを作ったら、その主担当というか、プロジェクト主幹の、例えば外科みたいなところは使いやすくなってるんだけど、眼科がとても使いづらくなってて、みたいな話とかって、これはビフォー、つまりAs-isをちゃんと洗い出してないから、「このシステムを使ってるのは誰か」、そして、「どういう業務に影響するのか」みたいなことをちゃんとやってないので、「失敗してます」とかなるんですよ。あとさっきのアプリとか、例えばECサイトのアプリ作りますみたいな話をしたときに、どういうECサイトにするかはみんなものすごく熱中して考えるんだけど、ECサイトって在庫管理とか、顧客管理とか、問い合わせ対応とか、はたまた流通の話とか。
中島：後ろにガーッとありますからね。
橋本：その管理画面っていつ誰が作るんですかね。「ああーっ!!」みたいな。（笑）
古長谷：鳥肌です。
橋本：csvダウンロードしてエクセルでやりましょうとか。いやいや。本当にこういう話すごく多いんですよ。だから、要件定義あるあるでよくある失敗って、何をちゃんと限られた時間の中で作るかってのもあるけど、ビフォーをちゃんと洗い出しましょうみたいなのが重要ですね。
中島：やっとかないととんでもないことに。
橋本：そうですね。
中島：あと、僕みたいなデザイナーとか末端の開発者の方なんかの気持ちを代弁すると、100メートル何秒で走れるから、1キロ何秒で走れるよね、みたいなことを言われると、いやいやいやいや、それはまた全然別の話ですよねっていうスケジュールの切り方をしてくる方が本当にいらっしゃるので、いや、もう本当に人間なんでね、こう、ありますから、やっぱり。長くロングタームで走るときにどういうスケジュールで開発を進めていったらいいのか、みたいな人間のマネジメントも考えたスケジュールになってることが好ましいですね。
橋本：じゃあスケジュールの回でまた。
中島：そうですね。それはスケジュールの回でまた。
橋本：第3回だれプロラジオ、終わりたいと思います。ありがとうございました。
中島：ありがとうございました。
