ふわっとした要件の危険なプロジェクトを始まる前に交通整備してみた

「なんか、いい感じに走る乗り物ほしいんです。予算はないのでミニマムで、できる機能だけでいいので。」

（そんなこと自信満々でいわれても…）

というような、曖昧な要件で開発相談を受けたことがある人は私だけではないだろう。

システム開発を外部に出すことの苦悩

まずもって、「いい感じに走る乗り物」がいかに広義であるか考えたい。

• タイヤの数は一輪車？二輪車？三輪車？四輪車？
• 最高スピードは2〜30km？100km？200km？
• 外装は？窓はあるない？
• ハンドルは？ブレーキは？
• どこを走る想定？

「いい感じに走る乗り物」を作るにあたっても、決めるべきことは山ほどある。

そのはずなのに、社内に専門部署がない会社ほど、本来社内で決めるべき思考まで外部に丸投げしてしまうことは多い。

よくよく深掘りしてみると、欲しいのは“自動車”だったりするわけだが、「予算がないので自転車の予算で最低限の車を作って」、みたいなことを言っているケースも多々ある。

そこで終わればまだ良いが、いざプロジェクトが始まって要件定義してみると、今までの社会では見たことのないような乗り物の要望が出てくることもある。

それって果たして元来欲しかった「いい感じに走る乗り物」なんだろうか…。

乗り物をどんなシーンで使ってどうビジネス展開させたいのか、そのこと自体を考えてない相談者は少なくない。

さらには、乗り物であることが定義できるコア機能を担保する予算がないのであれば夢物語に終わってしまう。

「最悪タイヤはなくてもいいんで走る乗り物作ってください！」と言われているようなものだ。

予算を重視するなら、そもそも「いい感じに走る乗り物」ではない代替案でビジネス課題の解決を促す必要がある。

自分たちがまだ何も考えてないということを自覚させる

初めの頃は、私自身、お客様が考えられてない部分を「よしなに」やってあげることさえも自分の仕事だと勘違いしてしまっていた。

けど、それで「よしなに」作られたビジネスは一体誰のビジネスなんだろうか？

ビジネスを考えることさえも外注してしまったら、その会社はなんのために存在しているのか…。

ここ最近は、コロナ禍で焦り始めた非IT業界からの、そんな曖昧な開発相談が増えてきたので、私はまず、相談相手が「何も考えてない」ということを自覚できるよう促すことにした。

ヒアリングでの質問攻め

初めてのアポか、概要を聞いた上での2回目くらいのアポで、必ず確認するヒアリングシートを活用している。

• サービスのビジネスモデル（マネタイズ）
• システム化にあたってドメインなど
• サービス名、ロゴ、コンセプト、キーカラーなど
• サービス利用の登場人物やなんとなくのユースケース

Web制作・開発業界では開発前に決まってて当たり前でしょ、と思われるだろうが、この段階でこれらが”全く未定”だとか“社内協議中”なんて言われることは稀じゃない。

プロジェクト憲章の作成

あまりにも決まってないな、という時にはプロジェクト憲章の雛形を渡して埋めていってもらう。そうすることで、自分たちがいかに考えられていないかに気付き始める。

プロジェクト憲章に書くべきとされていることはたくさんあるけれど、絶対に必要な箇所でも埋めるよう努力してもらうことでお互いの理解はより深まるように感じる。

＊ 参考にした書籍

契約スコープの確認

さらには、こういう相談をしてくる人たちに限って納期をとても急いでいる、ということが多い。とにかく早くビジネスを前に進めたい。（何も決まってないけど）早くリリースしたいから開発始めてください！と前のめりに焦っているケースだ。

相手がシステム開発の発注未経験である場合、何をどこまで作るのか、という契約の仕方も素人であることが多い。

要件定義/設計の主担当がどちらか？

画面内コンテンツのライティングや画像素材の準備は？

開発/検証/本番環境（ドメイン・サーバー）の準備や費用負担は？

ソースコード/課題管理ツールの登録や費用負担は？

外部APIの利用申請に関する必要書類の準備や費用負担は？

利用規約やプライバシーポリシー等の準備や費用負担は？

決済処理や権利周りに関する弁護士の必要有無

結合/受入テストの担当範囲や保証カバレッジ、ブラウザは？

本番リリース後の運用保守の有無

その他ステークホルダーとの注意事項等

これらを深堀していくと、ようやく「あ、システムを開発し始める前にこんなに考えるべきことがあったのか」と冷静になってもらえるものである。

IT化を考えるための補佐にまわる

とはいったものの、システム開発の経験のない担当者が、システムにすることを想定して要件を導き出すまでには相当高い壁がある。

だからこその私たちの出番。

それこそが私たちがいる価値であり、頼ってもらうべき部分だ。

私たちが良かれと思って相手が思考することまで奪ってしまうことは相手のビジネスのためにならない。

システム化するまでに何も考えてこなければ、リリース後にグロースさせることもできっこないのだから。

ふわっと要件から交通整備までの3STEP

1. 自分たちに何が足りてないのか自覚させる
2. IT化するにあたって必要な情報を見える化する
3. どの課題がビジネスサイドで、どの課題が開発会社なのか一緒に決める

こうすることで、発注する側も“自分たちの不足を開発会社が補ってくれている”、という意識ができるし、そこに対する対価にも疑念を抱かれにくい。

こちらが説明責任を怠れば、当然何をしているか分からないから「なんかシステム開発ってめっちゃお金取られる、詐欺だ」みたいに言う人が出てきたりする。

でも、何をしているかわかってもらえていれば、決して高くない必要経費だと理解してもらえることは多い。

ちなみにこれは最近本当にあった話。

なんだか相手の要件がフワフワしてると「こっちで決めてあげたほうが早い」、なんて思ってしまいそうだけど。自己満で勝手に開発を始めてはいけない。

まずは相手に自覚させること、それがスタート地点になるんだと改めて気付かされた出来事だった。