開発会社に相談する前に、決めておくと話が早い3つのこと

開発会社への相談は、準備しすぎなくていいと思っています。立派な仕様書を作ってから来られる方もいますが、正直に言うと、その多くは作り直しになります。業務を知っているのは発注側で、画面に落とすのはこちらの仕事だからです。

ただ、これだけは決めておくと初回から話が進む、というものが3つあります。10年分の経験則というほど大げさなものではなく、相談を受けていて「ここが空白だと止まるな」と感じる場所です。

1. 使う人を、役割で分けておく

いちばん最初に聞くのは「誰が使いますか」です。ここで「社員が使います」と返ってくると、だいたいもう一段掘ることになります。

役割が違えば見る画面が違います。現場のスタッフが入力する画面と、事務所で一覧を見る画面と、管理者が設定する画面。同じシステムでも別物です。逆に、役割が2つしかないと分かれば、画面数はぐっと減ります。

おすすめは、実在の人を思い浮かべて書くことです。「営業の田中さんが外出先のスマホで日報を入れる」「事務の佐藤さんが翌朝まとめて確認する」。この粒度まで来ると、必要な画面がほぼ決まります。属性ではなく、実際の作業として書いてみてください。

取引先や顧客が使う画面がある場合は、必ずそう言ってください。社内だけで完結するシステムと、社外の人が触るシステムでは、作るときの注意点がまったく違います。

2. 「今回は作らない」を決めておく

見積もりがぶれる最大の原因はこれです。作りたいものの話だけが続くと、金額は上振れし続けます。

そもそも見積もりが何で決まっているのかは、MVP開発の費用は、何で決まるのかに構造から書いています。

私たちは初期の開発に、決済、公的な本人確認、複雑な承認ルート、大規模なデータ移行、基幹システム連携を含めていません。作れないからではなく、使ってもらえるかが分かる前に作る必要がないからです。

この考え方は発注側でも同じで、「あったらいいもの」と「無いと業務が回らないもの」を分けておくと話が早くなります。判断に迷ったら、こう考えてみてください。それが無いと、来月から使い始められませんか。答えが「使い始められる」なら、今回は外していい機能です。

外した機能が消えるわけではありません。使い始めてから必要性がはっきりしたものを、順番に足していきます。私たちの場合はリリース後12ヶ月が改善フェーズなので、そこで足します。

8週間の中で何を作り、何を後回しにしているかは、2ヶ月で作れるもの、作れないものに週ごとに並べました。

3. 何を見て「うまくいった」と言うのか

3つ目がいちばん抜けやすく、いちばん効きます。

作ったあと、何をもって成功と判断しますか。日報の転記が月20時間から2時間になったら成功なのか。予約の電話が半分になったら成功なのか。新サービスなら、最初の1ヶ月で何人が登録したら次に進むのか。

これが決まっていると、機能の優先順位が自動的に決まります。「転記時間を減らす」が目的なら、入力画面の使いやすさが最優先で、集計のグラフは後回しでいい。目的が決まっていないと、どの機能も同じくらい大事に見えて、全部を同時に作ることになります。

数字でなくても構いません。「現場から不満が出なくなったら」でも判断基準になります。誰が見て判断するのかまで決まっていれば十分です。

3つが決まっていると、何が変わるか

初回お打ち合わせは60分です。この3つが決まっていると、その60分のうち40分を「どう作るか」に使えます。決まっていないと、60分まるごと現状の整理で終わり、提案は次回になります。

私たちの場合、打ち合わせのあと3営業日以内に画面構成のラフと見積もりをお出ししています。その精度も、この3つが揃っているかどうかで変わります。

決めておくこと	決まっていないと	決まっていると
使う人と役割	画面数が見積もれない	必要な画面がほぼ確定する
今回作らない範囲	金額が上振れし続ける	予算内で優先順位を決められる
成功の判断基準	全機能が同じ優先度に見える	どこから作るかが自動で決まる

準備できていなくても、来てください

ここまで書いておいて何ですが、3つとも決まっていない状態で相談に来られる方のほうが多いです。それで困ることはありません。整理するところから一緒にやります。

持ってきていただきたいのは、アイデアメモ、紙に描いた画面、参考にしたいサービスのURL、あるいはいま使っているエクセル。そのどれかがあれば十分です。専門用語も要りません。

初回お打ち合わせから提案まで費用はいただかないので、相談だけで終わっても構いません。ラフを見て「やっぱりやめます」も、こちらとしては普通のことです。

提案のときは、画面構成のラフと見積もりに加えて契約書もお渡しします。契約書で見ておくとよい場所はシステム開発の契約書で、発注側が読むべき5つの場所に、画面構成の例は作れるものの例にまとめています。