この記事は、業務の課題をITで解決したいと考えている経営者・発注担当者の方に向けて、シンシア代表の徐 聖博が書いています。
この記事でわかること
- 「言われた問題」をそのまま解くシステム開発が失敗しやすい理由
- 問題の本質に降りるための3つの問い
- システムを作ることが正解ではないケースと、「開発しない」という選択肢
- 開発パートナーを見極めるときに確認すべきこと
「言われた問題」をそのまま解いてはいけない
「請求書の処理に時間がかかっているので、自動化するシステムを作ってほしい」——こうした相談を受けたとき、開発会社には2つの選択肢があります。言われたとおりに請求書処理システムの見積もりを出すか、その前に一度立ち止まるかです。
私は後者であるべきだと考えています。なぜなら、相談として持ち込まれる「問題」は、多くの場合すでに誰かの解釈を一度通過した二次情報だからです。「請求書処理が遅い」の裏側を掘っていくと、実は上流の受注データが部署ごとにバラバラの形式で入ってくることが真因で、直すべきは請求書処理ではなく受注の入口だった——という構図は、実務では珍しくありません。
問題には階層があります。目の前の症状の一つ上には業務プロセスの設計があり、さらにその上には組織の役割分担や、そもそもその業務が必要かという問いがあります。下の階層で症状だけを解くと、システムは完成しても業務は楽にならず、「作ったのに使われないシステム」がまた一つ増えることになります。
問題の本質に降りる3つの問い
では、どう掘ればよいか。私が相談を受けたとき、実際に使っている問いは次の3つです。
① その問題は、誰の・どんな損失なのか
「時間がかかっている」「ミスが多い」を、誰が・月に何時間・いくらの損失という形まで具体化します。ここが曖昧なまま進むと、投資対効果の判断ができないだけでなく、実は大した損失ではなかったという結末もあり得ます。数字にした瞬間に優先順位が変わることは、よくあります。
② 一つ上の階層に原因はないか
症状が出ている工程ではなく、その手前の工程・データの入口・業務ルールを疑います。「なぜその作業が発生しているのか」を2〜3回繰り返すだけで、真因が別の場所にあると分かるケースは多い。前述の請求書の例のように、下流の自動化より上流の標準化のほうが、安くて効果が大きいことがあります。
③ その業務は、そもそも無くせないか
最も見落とされる問いです。効率化の対象になっている業務自体が、過去の経緯で残っているだけで、ルールを変えれば丸ごと消せる——ということがあります。無くせる業務を高速化するシステムほど、無駄な投資はありません。
「開発しない」が正解のケースもある
この3つの問いを通すと、相談の一定割合は「システムを新しく作る」以外の答えに落ち着きます。
- 業務ルールや運用の変更で解決する — 承認フローを1段減らす、入力フォーマットを統一する、といった変更だけで症状が消えるケース
- 既製のSaaSで足りる — 会計・勤怠・在庫のような汎用領域は、作るより既製ツールの導入・設定のほうが早くて安い
- 今は何もしないのが最善 — 損失を数字にしてみたら投資に見合わなかった、事業の変化を待つべきタイミングだった、というケース
私たちは開発会社なので、正直に言えば「作る」ほうが売上になります。それでも「これは作らないほうがいい」と伝えるのは、症状に合わせて作ったシステムは定着せず、結局その発注者との信頼ごと失うことを、経験として知っているからです。逆に、業務の言語化と整理まで一緒にやった案件は、要件定義の精度が上がり、作ると決めた範囲が小さくても確実に使われるものになります。
DXを一緒に考えられる開発パートナーの見極め方
「言われたとおりに作る」会社と「本質から一緒に考える」会社は、商談の初期に見分けられます。確認すべきはシンプルです。
- 課題の背景を掘る質問をしてくるか — 機能の話より先に「なぜその業務があるのか」「誰がどれだけ困っているのか」を聞いてくるか
- 開発以外の選択肢に言及するか — 運用変更や既製ツール、「やらない」を含めた比較を出せるか
- 小さく検証する提案があるか — 最初から大きな見積もりではなく、業務フローの可視化や小さな試作から入る提案ができるか
この観点は、開発会社の選び方の記事で書いた「要件定義のサポート力」をさらに一段掘ったものです。パートナー選びとは、実は「自社の問題の本質を一緒に疑ってくれる相手」を選ぶことだと私は考えています。
「そもそも何を解決すべきか」から一緒に考えたい方へ
シンシアでは、システムを作るかどうかの判断も含めて、業務課題の整理・DXの進め方の壁打ちを無料で承っています。「開発しないほうがいい」と正直にお伝えすることもあります。
まとめ — システムは手段、問いの立て方が成果を決める
IT化・DXの成否は、技術選定よりも前の「何を問題と定義するか」でほぼ決まります。言われた問題をそのまま解かず、損失を数字にし、一つ上の階層を疑い、無くせないかを問う。その結果として「開発しない」も含めた選択肢を一緒に並べられるパートナーと組むこと——それが、使われないシステムに投資しないための、最も確実な方法だと考えています。