開発会社に初めて相談する前に:用意しておく資料と、決めておくこと
開発会社に初めて相談するときに必要なのは、きれいな要件定義書ではありません。今使っている画面や Excel、紙の帳票といった「現物」と、今回の相談で何を持ち帰りたいか、誰が出るか、どこまで自社で担うかという「決めごと」です。この記事では、IPA(情報処理推進機構)の要件定義ガイドで示されている工程の考え方をもとに、初回の相談の前に用意する資料、決めておくこと、渡してよい情報の線引き、当日の進め方と聞くことを、そのまま使える準備シートにまとめます。
業務システムを作りたい、今の Excel 管理をやめたい、という話が社内で出たとします。最初に悩むのは、「開発会社に何を持って相談に行けばいいのか」ではないでしょうか。
資料をきちんと作ってからでないと失礼ではないか。何も決まっていないのに相談してよいのか。逆に、準備に時間をかけすぎて、相談するのがどんどん先に延びてしまう。こうした迷いは、初めて発注する会社ではよく聞く話です。
この記事は、初めて開発会社に相談する情報システムの担当者や、事業の責任者に向けて書いています。扱うのは、相談の前の数日から当日までのことです。
- 初めての相談が、開発の流れのどこに当たるか
- 持っていく資料(現物)
- 社内で決めておくこと
- 渡してよい情報の線引き
- 当日の進め方と、開発会社に聞くこと
- そのまま使える「初回相談の準備シート」
目的や数字、業務の流れといった「社内でまとめておく中身」は、要件定義とは:開発会社に頼む前に、社内でまとめておくことで7つに分けて詳しく書きました。この記事では、その中身を持って、実際に相談の場に出るまでの段取りを扱います。
結論:完成した要件ではなく「現物」と「決めごと」を持っていく
初めての相談の前にやることは、次の5つです。
- 今使っている画面、Excel、紙の帳票を集める(現物の資料)
- 今回の相談で何を持ち帰りたいかを決める
- 相談に出る人を決める(決める人と、現場が分かる人)
- 自社でどこまで担うかと、外せない条件を決める
- 渡してよい情報と、まだ渡さない情報を分ける
要件を文章でまとめるのは、このあとの要件定義の段階で、開発会社と一緒に進めればかまいません。初回の相談で大事なのは、開発会社が「この会社は何に困っていて、どこに向かいたいのか」を、短い時間で正しくつかめることです。そのために一番役に立つのは、上手な説明よりも、実際に使っているものそのものです。
初めての相談は、開発の流れのどこに当たるか
まず、初めての相談が、システムを作る流れのどの段階の話なのかを確かめておきます。ここが分かると、相談の場で何が決まり、何が決まらないのかの見当が付きます。
IPA の「ユーザのための要件定義ガイド 第2版」は、システム開発の初めの工程を、企画、要件定義、基本設計(外部設計)の順に並べています。企画の工程については、次のように書いています。
企画工程では、一般的に経営上のニーズ、課題を実現、解決するための新たな業務の全体像と実現に向けたシステム構想を立案する。
(IPA「ユーザのための要件定義ガイド 第2版」 第3章 3.1)
初めての相談は、この企画の工程の中にあります。何を作るかを決める場というより、「どの方向に進むか」と「どう進めるか」を考え始める場です。
費用についても、同じガイドに目安となる書き方があります。
本ガイドでは、要件定義工程の終了時に、設計から移行・運用準備までのコストを概算レベルで見積もることを想定している。
(同 第3章 3.1)
要件定義が終わった時点でも、費用は「概算」です。初めての相談の時点では、まだ要件定義も始まっていません。ですから、初回の相談で正確な金額が出ないのは自然なことです。初回で確かめたいのは、金額そのものよりも、「どんな進め方で、どの段階で、どのくらいの確かさの金額が出るのか」です。これを知っておくと、社内で予算の話をするときにも、「いつ、どのくらいの精度の数字が出る予定か」を説明できます。
持っていく資料:説明より「現物」
ここからは、相談の前に集める資料です。どれも新しく作る必要はありません。今あるものを集めて、見せられる形にするだけです。
1. 今使っている画面・Excel・紙の帳票
システムに置き換えたい業務で、今使っているものを集めます。
- 今使っているシステムの画面(スクリーンショット)
- 管理に使っている Excel やスプレッドシート
- 紙の帳票(注文書、日報、チェック表など)
- 取引先とやり取りしている書類やメールの例
開発会社は、これを見ると、項目の数、入力の手間、どこで転記や二重入力が起きているかを、すぐにつかめます。「顧客の管理をしたい」と口で説明するより、今の Excel を1枚見せるほうが、話は何倍も早く進みます。
ただし、ここで注意があります。中に入っているお客様の名前や連絡先などは、そのまま見せないでください。扱い方は、後の「渡してよい情報の線引き」で詳しく書きます。項目名(列の見出し)が残っていれば、中身は架空の値に置き換えても十分に伝わります。
2. 業務の流れのメモ
誰が、いつ、何を使って、どんな作業をしているかを書いたメモです。きれいな図でなくてかまいません。ホワイトボードに書いて写真を撮ったものでも、手がかりになります。
業務の流れの書き出し方は、同じ日に公開した記事「業務の流れを図にする」で詳しく扱っています。この記事では、相談に持っていくときの注意だけ書きます。それは、流れの中で困っている所に、印を付けておくことです。流れの図だけを見せると、開発会社は「全部をシステムにしたいのか」と受け取るかもしれません。困っている所に印があれば、どこから手を付けるべきかの話にすぐ入れます。
3. 困りごとの大きさが分かる数字
困っている所について、頻度と時間を書いておきます。
- 転記の作業に、毎日どのくらいの時間がかかっているか
- 月末の集計に、何人が何日かけているか
- 入力のミスや問い合わせが、月に何件くらいあるか
正確な数字でなくてかまいません。「だいたい毎日2時間くらい」でも十分です。数字があると、開発会社は「どこに手を入れると効果が大きいか」を一緒に考えられます。社内でシステムにお金をかける理由を説明するときにも、この数字が土台になります。
4. 関わる人と、使う人の一覧
システムに関わる人を、部署と役割で書き出します。
- 毎日使う人(何人くらい、どの部署か)
- ときどき使う人(管理職、経理など)
- 社外で使う人(取引先、お客様)
- 結果だけ見る人(経営層など)
使う人の数や場面は、システムの作り方を大きく左右します。事務所のパソコンで使うのか、外出先のスマートフォンで使うのかでも、画面の作り方が変わります。
5. 社内の決まりごと
意外に見落とされるのが、社内の手続きの決まりです。
- 稟議や決裁の流れ(いくら以上だと誰の承認が要るか)
- 予算を取る時期(年度の始まり、半期ごとなど)
- 社外のサービスを使うときの決まり(情報システム部門の確認、セキュリティの確認書など)
これを先に伝えておくと、開発会社は、社内の手続きに合わせた進め方や資料の出し方を考えられます。「見積もりはもらったが、社内の決裁の形に合わず、作り直してもらった」という手戻りも防げます。
決めておくこと:相談の場で迷わないために
資料と並んで大事なのが、社内で決めておくことです。こちらは中身の話ではなく、相談の進め方についての決めごとです。
1. 今回の相談で、何を持ち帰りたいか
初回の相談の目的を、ひとことで決めておきます。たとえば、次のどれかです。
- そもそもシステムで解決できる課題かどうかを知りたい
- どんな進め方があるのか、選択肢を知りたい
- 費用と期間の大まかな幅を知りたい
- 今あるシステムを直すか、作り直すかの考え方を聞きたい
目的が決まっていないと、相談の1時間が、開発会社の会社紹介を聞いて終わってしまうことがあります。最初に「今日はこれを知りたい」と伝えれば、開発会社もそれに合わせて話を組み立てられます。
2. 相談に出る人
相談には、できれば次の2種類の人が出るようにします。
- 決める人:予算や進め方を最終的に決める人(事業の責任者、経営層など)
- 現場が分かる人:今の業務を毎日やっていて、困っている所を具体的に話せる人
担当者一人で相談に出ると、「それは上に確認します」「現場に聞いてみます」が続き、話が深まりません。初回だけでも、決める人に少し顔を出してもらえると、その後の進み方が大きく変わります。全員がそろわないときは、聞いておきたいことを事前に二人から集めておきます。
3. 自社でどこまで担うか
システムを作る仕事のうち、どこまでを自社で担い、どこからを開発会社に頼みたいのかを考えておきます。
たとえば、クリーヴァが開発を担当している株式会社日本能率協会マネジメントセンター様の「Knotter」では、プロダクトの方向性を決め、「どのようなものをつくりたいか」「どのように実現したいか」という要件を整理するところまでをお客様が担当し、そこから実際に形にしていく開発をクリーヴァが担当しています。
反対に、「何を作ればよいかから一緒に考えてほしい」という頼み方もあります。どちらがよいということはありません。自社の人の手が空いているか、社内に業務やシステムに詳しい人がいるかで変わります。大事なのは、それを相談の場で伝えることです。開発会社は、分担のしかたによって、進め方も体制も見積もりの組み方も変えます。
4. 外せない条件と、まだ決めていないこと
条件を、「外せないもの」と「まだ決めていないもの」に分けて書いておきます。
外せない条件の例
- 使い始めたい時期と、その理由(繁忙期の前、年度の始まりなど)
- 予算の上限(社内で決まっている場合)
- つなぐ必要がある今のシステム(会計ソフト、販売管理など)
- 社内の決まりで守る必要があること(データを置ける場所など)
まだ決めていないことの例
- 全部を一度に作るか、一部から始めるか
- 作るか、既製のサービスを使うか
- スマートフォンでも使うか
止まったら困る時間帯や、同時に使う人の数といった、システムの「機能以外」の条件も、分かる範囲で書いておくと役に立ちます。こうした条件は、IPA が「非機能要求グレード」という道具をまとめているほど、発注する側と開発会社の間で食い違いが起きやすい所です。IPA はその目的を、次のように書いています。
「非機能要求」についてのユーザと開発者との認識の行き違いや、互いの意図とは異なる理解を防止することを目的とし
初回の相談で細かい水準まで決める必要はありません。「夜間や休日は使わない」「止まると出荷が止まる」といった、業務から見た一言があれば十分です。
5. 何社に相談するか
一社だけに相談して決めるか、何社かに相談して比べるかも、先に決めておきます。比べる場合は、どの会社にも同じ資料を渡すと、返ってきた答えを比べやすくなります。
先ほどの「Knotter」の事例でも、お客様は何社かに相談したり、Web で探したりする中で、要望を一番汲み取ってくれた会社を選んだと話しています。相見積もりの取り方と比べ方は、別の記事で詳しくまとめます。
渡してよい情報の線引き
相談の前に、情報の渡し方を決めておきます。開発会社とはまだ契約を結んでいない段階なので、何でも渡してよいわけではありません。
秘密保持の約束を先に結ぶ
社外に出していない業務の中身、取引先との条件、新しい事業の計画などを話す場合は、相談の前に秘密保持の契約(NDA)を結んでおくと安心です。初回の相談の前に結べるかを、日程を決めるときに開発会社に聞いておきます。自社のひな形があればそれを使い、なければ開発会社のものを読んで確かめます。
秘密保持の契約があっても、話す内容は必要な範囲にとどめるのが基本です。初回の相談で必要なのは、業務の流れや困っている所であって、取引先の名前や金額の細部ではありません。
個人情報が入ったデータは、そのまま渡さない
一番気を付けたいのが、お客様や従業員の個人情報です。今使っている Excel をそのまま送ると、名前や連絡先、購入の履歴まで渡ってしまうことがあります。
個人情報の保護に関する法律(個人情報保護法)は、本人の同意なく個人データを第三者に渡すことを、原則として禁じています(第27条第1項)。利用目的の達成に必要な範囲で、個人データの取扱いを委託することに伴って渡す場合は、渡す先を第三者として扱わないと定められています(同条第5項)。ただし、その場合でも、委託する側には委託先を監督する義務があります。
個人情報取扱事業者は、個人データの取扱いの全部又は一部を委託する場合は、その取扱いを委託された個人データの安全管理が図られるよう、委託を受けた者に対する必要かつ適切な監督を行わなければならない。
初回の相談は、まだ委託の契約を結ぶ前の段階です。迷ったら、個人情報は渡さないと決めておくのが安全です。具体的には、次のようにします。
- Excel は、項目名(列の見出し)を残し、中身は架空の値に置き換える
- 画面のスクリーンショットは、名前や連絡先の部分を塗りつぶす
- どうしても実際のデータを見せたいときは、送らずに、画面を見せながら説明する
データの件数(何件くらいあるか)や、項目の数は、個人情報ではないので伝えてかまいません。むしろ、データ移行の手間を見積もるうえで大事な情報です。
当日の進め方:1時間の例
ここでは、初回の相談を1時間とした場合の例を挙げます。限られた時間を生かすために、次のような流れを用意しておくと、話がそれにくくなります。開発会社にも、事前にこの流れを伝えておくとよいでしょう。
| 時間 | 内容 | ねらい |
|---|---|---|
| 最初の5分 | 今日の目的を伝える | 「今日はこれを知りたい」をそろえる |
| 15分 | 今の業務と困っている所を説明する | 現物の資料を見せながら話す |
| 15分 | 開発会社からの質問に答える | 開発会社が知りたいことを出してもらう |
| 15分 | 進め方の選択肢を聞く | 段階の分け方、分担、次に何をするか |
| 最後の10分 | 次にやることを決める | 誰が、いつまでに、何をするか |
ポイントは、開発会社からの質問の時間を取ることです。開発会社が何を聞いてくるかで、その会社が何を大事にしているかが分かります。業務の流れや困りごとを深く聞いてくる会社もあれば、画面や機能の話から入る会社もあります。どちらが正しいということではありませんが、自社の課題に合った聞き方をしてくれるかは、相談先を選ぶときの手がかりになります。
開発会社に聞くこと
初回の相談で、開発会社に聞いておきたいことを挙げます。全部を聞く必要はありません。今回の目的に合わせて選んでください。
進め方について
- 今回の課題なら、どんな段階に分けて進めることが多いか
- 最初の段階では何をして、何ができあがるのか
- 要件定義はどのように進めるのか(打ち合わせの頻度、出てくる資料)
- 小さく作って試す進め方はできるか
費用と期間について
- どの段階で、どのくらいの確かさの金額が出るのか
- 費用が変わるのは、どんな条件のときか
- 使い始めるまでの期間の目安は、何によって変わるか
体制について
- 誰が担当になり、どんな人が関わるのか
- 自社側には、どのくらいの時間と、どんな役割を求められるか
- 打ち合わせや連絡は、どんな方法で行うのか
作ったあとについて
- 使い始めたあとの保守や改修は、どう頼めるのか
- 作ったものの権利(ソースコードなど)は、どう扱われるのか
最後の権利の話は、初回の相談では少し早いと感じるかもしれません。けれども、将来、別の会社に保守を頼むことになったときに大事になる点です。詳しくは開発会社を途中で変えるとき:引き継ぎで渡すものと、確かめることで書いたので、気になる方は読んでみてください。
初回相談の準備シート
ここまでの内容を、そのまま使える1枚にまとめます。社内で埋めて、相談の数日前に開発会社に送っておくと、当日の話がぐっと深くなります。空欄があってもかまいません。空欄は「相談の場で一緒に考えたいこと」と書いておけば十分です。
| 項目 | 書くこと | 例 |
|---|---|---|
| 今回の目的 | この相談で何を持ち帰りたいか | 進め方の選択肢と、費用の大まかな幅を知りたい |
| きっかけ | なぜ今、相談するのか | 担当者が退職し、Excel の管理が回らなくなった |
| 困っている所 | 頻度と時間 | 受注の転記に毎日2時間、月に数件の入力ミス |
| 今使っているもの | 画面、Excel、紙 | 販売管理ソフト、在庫の Excel、FAX の注文書 |
| 使う人 | 部署、人数、使う場所 | 営業5名が外出先で、事務2名が事務所で |
| 相談に出る人 | 名前と役割 | 業務課長(窓口)、現場の担当者1名 |
| 決める人 | 最終的に決める人 | 社長 |
| 自社で担うこと | どこまで自社でやるか | 業務のまとめは自社、画面と仕組みは相談したい |
| 外せない条件 | 時期、予算、つなぐシステム | 来年4月から使いたい、会計ソフトとつなぎたい |
| まだ決めていないこと | 一緒に考えたいこと | 一部から始めるか、全部作るか |
| 社内の手続き | 決裁、予算の時期 | 300万円以上は取締役会、予算は2月に確定 |
| 渡さない情報 | 今回は見せないもの | 顧客の名前・連絡先(項目名だけ見せる) |
| 何社に相談するか | 比べるかどうか | 3社に同じ資料で相談する |
あわせて、当日の持ち物の一覧です。
- 今使っている画面のスクリーンショット(個人情報は塗りつぶした)
- 管理に使っている Excel(中身は架空の値に置き換えた)
- 紙の帳票の写真か写し
- 業務の流れのメモ(困っている所に印を付けた)
- 困りごとの頻度と時間のメモ
- 上の準備シート
- 開発会社に聞くことの一覧
- 必要なら、秘密保持の契約を結んだ
つまずきやすい所
初めての相談で、よくあるつまずきと、防ぎ方を挙げます。
機能の一覧だけを持っていく
「顧客管理」「見積もりの作成」「売上の集計」と、ほしい機能を並べた一覧だけを持っていくと、話は機能の有無の確認で終わりがちです。
IPA の要件定義ガイドは、要求には「〜を実施したい」という手段の要求と、「〜を達成したい」という目的の要求の2種類があり、その違いを意識することが大事だとしています。
「自動集計する機能を作成したい」は要求である。これを実現して何を達成したいのか。「工数を削減したい」これも要求である。
(IPA「ユーザのための要件定義ガイド 第2版」 第4章 4.1 勘どころ①)
機能の一覧は、手段の要求です。それぞれの機能に「何のためか」を一言添えておくと、開発会社は、もっと手間の少ない別の手段を提案できるようになります。
全部決めてから相談しようとして、遅れる
準備に時間をかけすぎて、相談が何か月も先に延びるのも、よくあることです。この記事で挙げた資料は、今あるものを集めるだけで、数日あれば用意できます。分からないことは「分からない」と書いて持っていけば十分です。決めることの多くは、相談のあとの要件定義で、開発会社と一緒に進められます。
現場の人が出ていない
担当者だけで相談に出ると、業務の細かい所を聞かれたときに答えられず、話が止まります。現場の人が出られないときは、事前に現場で困っていることを聞き取り、メモにしておきます。
その場で金額を求める
初回の相談で「結局いくらかかりますか」と金額だけを聞くと、開発会社は、条件の分からないまま幅の広い数字を出すしかありません。その数字が社内で一人歩きすると、あとで実際の見積もりとの差を説明するのに苦労します。先に書いたとおり、初回で確かめたいのは「どの段階で、どのくらいの確かさの金額が出るか」です。
個人情報の入ったファイルを送ってしまう
急いでいると、今使っている Excel をそのまま送ってしまいがちです。送る前に、中に何が入っているかを一度開いて確かめる習慣を付けておきます。シートが何枚もある Excel では、見えていないシートに名簿が残っていることもあります。
相談のあとにすること
相談が終わったら、その日のうちに次のことをします。
- 聞いたことを社内で共有する:決める人が出られなかった場合は特に、聞いた進め方の選択肢と、次にやることを短くまとめて伝えます。
- 次の段階を決める:多くの場合、次は要件定義の進め方と契約の話になります。何をどこまで決めるのか、期間はどのくらいかを、開発会社と相談します。
- 比べる場合は、同じ形でまとめる:何社かに相談したなら、それぞれの答えを、同じ項目(進め方、分担、費用が出る段階、体制)で並べて比べます。
要件定義で何を決めるのかは、要件定義とは:開発会社に頼む前に、社内でまとめておくことにまとめています。何社かに同じ条件で提案を頼みたい場合は、提案依頼書(RFP)を作ることもあります。RFP の書き方は、別の記事でまとめる予定です。
小さく作って確かめながら進める方法に興味があれば、MVP とは:小さく作って確かめる開発の進め方も参考になると思います。
クリーヴァに相談するとき
クリーヴァでも、初めての相談は、要件がまとまっていない段階からお受けしています。事例のページでも、「何が課題かまだ整理できていない」という段階でも問題ありません、とお伝えしています。
この記事の準備シートは、クリーヴァに相談いただくときにもそのまま使えます。埋まっている所が少なくてもかまいません。空欄の所から、一緒に整理していきます。
おわりに
初めて開発会社に相談するとき、きれいな資料はいりません。今使っているものをそのまま見せ、今回の相談で何を知りたいかを伝え、決める人と現場の人が同じ場にいる。それだけで、初回の相談はずっと実りのあるものになります。
準備に必要なのは、数日です。完璧に決めてから動くより、今あるものを持って早めに相談するほうが、結果として早く、無駄の少ない進め方にたどり着けます。この記事の準備シートと持ち物の一覧を、相談の前に一度使ってみてください。