システム開発を依頼する前に整理しておくと、話がスムーズに進むこと

はじめに

最近、毎月参加している富士市の経営者交流会で、「業務をシステム化したい」という相談を受ける機会が増えました。

ある方は自社サービスを専用アプリにしてサブスク化したいと考えていました。別の方は、毎月手作業で行っている集計業務をなんとか自動化できないかと悩んでいました。業種も規模もさまざまですが、共通しているのは「何かシステムを入れたい」という熱量を持っていることです。

ただ、もう少し詳しく話を聞いていくと、共通してある部分が整理されていないことに気がつきます。

それは、「今の業務が具体的にどう回っていて、どこに問題があるのか」という部分です。

「こんなシステムが欲しい」というイメージはある。でも、その手前にある現状の業務フローや課題が言葉になっていない。この状態で開発会社（システムを作ってくれる会社）に相談しても、話がかみ合わなかったり、見積もりの精度が下がったりしがちです。

この記事では、システム開発を開発会社に依頼する前に整理しておくと、その後の話がスムーズに進むポイントをお伝えします。私自身、化学メーカーの研究開発部門で働いていたとき、会社の方針で全社的にシステムが導入され、現場で使う立場としてその過程を経験しました。そのときの実感も含めてお話しします。

なぜ「開発会社に相談する前」の準備が大事なのか？

開発会社に早く相談すること自体は悪いことではありません。ただ、準備が整っているかどうかで、その後の進み方がまったく変わります。

開発会社はシステムを作る技術のプロですが、あなたの会社の業務のプロではありません。「こんな感じのものが欲しい」というざっくりした要望だけでは、開発側も何を提案していいか判断しにくいのが正直なところです。

逆に、「今はこういう業務フローで、ここに月○時間かかっている。ここを改善したい」と伝えられれば、開発会社は具体的な解決策を提示しやすくなります。見積もりの精度も上がりますし、複数社に相見積もりを取る場合にも比較がしやすくなります。

つまり、事前の整理は開発会社のためではなく、発注する側が損をしないための準備です。

発注側が陥りやすい4つの落とし穴

システム開発の相談を受けたり、自分自身の経験を振り返ったりする中で、発注側に共通しやすいパターンがあります。これを知っておくだけでも、準備の方向性が見えてきます。

「こんなシステムが欲しい」から始めてしまう

これは最もよくあるパターンです。展示会で見たツール、同業者が使っているサービス、ネットで見かけた事例。こうした「手段」との出会いがきっかけで、「うちもあれが欲しい」となるケースは少なくありません。

ただ、本来の出発点は「今の業務のどこに問題があるか」です。手段から入ると、自社の課題に合わないシステムを作ってしまったり、必要のない機能に予算を割いてしまったりするリスクがあります。

「何を作るか」の前に、「なぜ作るのか」を言語化しておくと、開発会社との最初の打ち合わせが格段に実りあるものになります。

現状の業務フローが言語化できていない

「なんとなく不便」「手間がかかっている気がする」という感覚はあるものの、具体的にどの作業に誰がどれくらい時間をかけているのか、整理されていないケースも多いです。

開発会社からすると、ここが見えないままでは設計のしようがありません。結果として、ヒアリングに時間がかかるか、開発会社が「たぶんこういうことだろう」と推測で進めることになります。どちらも手戻りの原因になります。

完璧なフロー図を用意する必要はありません。手書きのメモでもいいので、「誰が」「何を」「どの順番で」やっているかを一度書き出しておくだけで、話の精度がまったく変わります。

「作れば使われる」と思っている

システムは完成がゴールではなく、現場で使われて初めて意味があります。ところが、導入後のことが抜け落ちているケースは意外と多いです。

誰がデータを入力するのか。日常業務の中で、その入力作業をいつやるのか。ITに不慣れな社員もいる中で、操作に戸惑ったとき誰がフォローするのか。こうした「運用」の視点が欠けたまま開発を進めると、完成したシステムが社内に定着せず、結局元のやり方に戻ってしまうことがあります。

開発を依頼する前に、「このシステムを日常的に使う人は誰で、その人たちは使いこなせそうか」を考えておくだけでも、開発会社への要件の伝え方が変わってきます。

維持にかかるコストを見落としている

システムの費用というと、多くの方が「作るのにいくらかかるか」を気にされます。もちろん初期費用は大きな判断材料ですが、見落とされがちなのが毎月・毎年かかるランニングコストです。

サーバー代、ドメイン費用、セキュリティアップデート、クラウドサービスのライセンス料、不具合対応の保守費用。これらは、システムを動かし続ける限り発生し続けます。

ホームページでも「作って終わりにしてしまう」問題はよくありますが、業務システムの場合はさらに深刻です。なぜなら、ホームページが止まっても業務は回りますが、業務システムが止まると仕事そのものが止まる可能性があるからです。

初期費用とランニングコストをセットで把握しておくことが、長期的に後悔しないための前提になります。

私が化学メーカー時代に経験したこと

ここで少し、私自身の経験をお話しさせてください。

以前、大手化学メーカーの研究開発部門で働いていたとき、会社の方針で全社的にノーコードツールが導入されました。それまで使っていたシステムが終了し、その代替として選ばれたものです。私は導入を決めた側ではなく、研究開発の現場で使う側の人間でした。

ノーコードツールは「プログラミングの知識がなくても、社内で業務アプリを作れる」という触れ込みで選ばれたものです。実際、簡単なアプリなら直感的に作ることもできました。

ただ、実務で使い込んでいくと、標準機能ではカバーしきれない場面が出てきます。私がいた部署では、ツールの機能に合わせて業務フローや承認フローを変更するという本末転倒なことも起きました。

また、「社内で開発・カスタマイズできる」というのが導入の決め手のひとつだったのですが、実際にはプログラミングに明るい社員がいなかったり、本来の業務が忙しくて手が回らなかったりで、結局は外部の開発会社にカスタマイズを依頼するケースが出てきました。

問題はその先です。外注したものの、微妙に仕様が意図と違う。修正を依頼する。また費用がかかる。このサイクルが繰り返される部署もありました。

振り返ると、ツールそのものが悪かったわけではないと思っています。導入前に各部署の業務フローを十分に棚卸しできていなかったこと、「誰がどう使うか」の運用設計が甘かったことが根本にありました。

この経験は、今の私がクライアントにシステム化の相談を受けたときに、「まず業務の棚卸しから始めましょう」とお伝えする理由のひとつになっています。

開発会社に相談する前に整理しておきたい5つのこと

ここまで読んで、「準備が大変そうだ」「うちにはハードルが高いかも」と感じた方もいるかもしれません。ただ、安心してください。すべてを完璧に揃えてから相談する必要はありません。まずできる範囲で整理するだけでも、開発会社との最初の打ち合わせは格段にスムーズになります。仕様が固まりきっていなくても進められる方法は、この記事の最後でもご紹介します。

ここでは、整理しておくと話が進みやすくなるポイントを5つにまとめます。

1. 今の業務フローを書き出す

紙でもExcelでも構いません。「誰が」「何を」「どの順番で」やっているかを書き出してみてください。図にする必要はなく、箇条書きでも十分です。

これがあるだけで、開発会社は「ここをシステム化するとこれだけ効率が上がります」という具体的な提案をしやすくなります。

2. 「困っていること」を具体的に言語化する

「なんとなく不便」ではなく、できるだけ具体的に言葉にしてみてください。

「月末の受注集計に毎回3日かかっている」「担当者が休むとその業務が完全に止まる」「同じデータを3つのExcelに手入力している」。こうした具体的な課題があると、開発会社は優先順位をつけた提案ができます。

3. そのシステムを誰が使うのかを明確にする

経営者だけが見るダッシュボードなのか、現場の社員が毎日使う業務アプリなのかで、設計の方向性はまったく違います。

使う人のITリテラシーもさまざまです。パソコンに不慣れな方が使う前提なら、画面の設計や操作の複雑さに配慮が必要になります。「誰が、どんな場面で使うか」を伝えるだけで、使い勝手の良いシステムに近づきます。

4. 既存の手段で本当に足りないかを検証する

「システムを開発する」という選択肢は、手段のひとつに過ぎません。

Excelの関数やマクロを使った運用改善で十分なケースもありますし、Googleスプレッドシートの共同編集で解決できることもあります。既存の無料・低コストなツールで課題が解消できるなら、それに越したことはありません。

開発会社に相談すれば、こうした代替手段も含めて提案してくれるところもあります。ただ、自分たちでも一度「本当に開発が必要か？」を検討しておくと、判断の軸がブレにくくなります。

5. 初期費用だけでなく「毎月いくらかかるか」を把握する

システム開発にかかる費用は、初期の開発費だけではありません。運用が始まると、サーバー費用、セキュリティの保守、機能追加や不具合対応のメンテナンス費などが継続的に発生します。

開発会社に見積もりを依頼する際は、「初期費用」と「月額の運用保守費用」の両方を確認するようにしてください。この2つをセットで把握しておくことで、「作ったはいいけど維持できない」という事態を避けられます。

いきなり本開発でなくてもいい

ここまで読んで、「準備が大変そうだ」と感じた方もいるかもしれません。

実は、すべてを完璧に整理してから開発に入る必要はありません。仕様が固まりきっていない段階でも、まずプロトタイプ（試作品）を小さく作ってみて、実際に触りながら「ここは違う」「こっちの方がいい」を確認していく進め方もあります。

私自身、クライアントワークでもこの方法を取り入れています。仕様書だけでは見えなかった課題が、プロトタイプを触ることで一気に明確になったケースは少なくありません。

プロトタイプを使った開発の進め方については、以下の記事で詳しくお伝えしています。 →「仕様が固まらないまま始めたシステム開発をプロトタイプで乗り越えた話」

まとめ

システム開発を成功させるために最も大切なのは、技術でもツール選びでもなく、「発注する前の準備」です。

自社の業務を棚卸しして、課題を具体的に言語化し、誰がどう使うかを想定し、予算をランニングコストまで含めて把握する。この準備があるかないかで、開発会社から返ってくる提案の質が大きく変わります。

そして、発注前の整理は開発会社のためではありません。自分たちが納得のいくシステムを手に入れるための、最初の一歩です。

「何から整理すればいいか分からない」という場合は、壁打ち相手としてお気軽にご相談ください。業務の棚卸しから一緒に整理するところからお手伝いできます。

また、開発会社と契約を結ぶ段階で注意すべきポイントについては、こちらの記事でまとめています。 →「その契約書、サインして大丈夫ですか？ホームページ制作で実際にあったトラブルと確認すべきポイント」