そのシステム開発、本当に必要ですか——「言われた問題」を疑い、開発しない選択肢まで考えるDXの進め方

要件定義・業務整理公開日:2026年7月23日
徐 聖博
徐 聖博

株式会社シンシア 代表取締役社長

Share
目次開く
  1. 「言われた問題」をそのまま解いてはいけない
  2. 問題の本質に降りる3つの問い
  3. ① その問題は、誰の・どんな損失なのか
  4. ② 一つ上の階層に原因はないか
  5. ③ その業務は、そもそも無くせないか
  6. 「開発しない」が正解のケースもある
  7. DXを一緒に考えられる開発パートナーの見極め方
  8. まとめ — システムは手段、問いの立て方が成果を決める
  9. 次に読むべき記事

シンシアへのご相談

要件整理の壁打ちを依頼する

「何を作ればいいか整理できていない」段階からお声がけください。要件定義・業務整理の壁打ち相談を無料で承っています。

要件整理の壁打ちを依頼する

まだ検討段階の方は 質問だけでもOK(電話番号は任意)

この記事は、業務の課題をITで解決したいと考えている経営者・発注担当者の方に向けて、シンシア代表の徐 聖博が書いています。

この記事でわかること

  • 「言われた問題」をそのまま解くシステム開発が失敗しやすい理由
  • 問題の本質に降りるための3つの問い
  • システムを作ることが正解ではないケースと、「開発しない」という選択肢
  • 開発パートナーを見極めるときに確認すべきこと

「言われた問題」をそのまま解いてはいけない

「請求書の処理に時間がかかっているので、自動化するシステムを作ってほしい」——こうした相談を受けたとき、開発会社には2つの選択肢があります。言われたとおりに請求書処理システムの見積もりを出すか、その前に一度立ち止まるかです。

私は後者であるべきだと考えています。なぜなら、相談として持ち込まれる「問題」は、多くの場合すでに誰かの解釈を一度通過した二次情報だからです。「請求書処理が遅い」の裏側を掘っていくと、実は上流の受注データが部署ごとにバラバラの形式で入ってくることが真因で、直すべきは請求書処理ではなく受注の入口だった——という構図は、実務では珍しくありません。

問題には階層があります。目の前の症状の一つ上には業務プロセスの設計があり、さらにその上には組織の役割分担や、そもそもその業務が必要かという問いがあります。下の階層で症状だけを解くと、システムは完成しても業務は楽にならず、「作ったのに使われないシステム」がまた一つ増えることになります。

問題の本質に降りる3つの問い

では、どう掘ればよいか。私が相談を受けたとき、実際に使っている問いは次の3つです。

① その問題は、誰の・どんな損失なのか

「時間がかかっている」「ミスが多い」を、誰が・月に何時間・いくらの損失という形まで具体化します。ここが曖昧なまま進むと、投資対効果の判断ができないだけでなく、実は大した損失ではなかったという結末もあり得ます。数字にした瞬間に優先順位が変わることは、よくあります。

② 一つ上の階層に原因はないか

症状が出ている工程ではなく、その手前の工程・データの入口・業務ルールを疑います。「なぜその作業が発生しているのか」を2〜3回繰り返すだけで、真因が別の場所にあると分かるケースは多い。前述の請求書の例のように、下流の自動化より上流の標準化のほうが、安くて効果が大きいことがあります。

③ その業務は、そもそも無くせないか

最も見落とされる問いです。効率化の対象になっている業務自体が、過去の経緯で残っているだけで、ルールを変えれば丸ごと消せる——ということがあります。無くせる業務を高速化するシステムほど、無駄な投資はありません。

「開発しない」が正解のケースもある

この3つの問いを通すと、相談の一定割合は「システムを新しく作る」以外の答えに落ち着きます。

  • 業務ルールや運用の変更で解決する — 承認フローを1段減らす、入力フォーマットを統一する、といった変更だけで症状が消えるケース
  • 既製のSaaSで足りる — 会計・勤怠・在庫のような汎用領域は、作るより既製ツールの導入・設定のほうが早くて安い
  • 今は何もしないのが最善 — 損失を数字にしてみたら投資に見合わなかった、事業の変化を待つべきタイミングだった、というケース

私たちは開発会社なので、正直に言えば「作る」ほうが売上になります。それでも「これは作らないほうがいい」と伝えるのは、症状に合わせて作ったシステムは定着せず、結局その発注者との信頼ごと失うことを、経験として知っているからです。逆に、業務の言語化と整理まで一緒にやった案件は、要件定義の精度が上がり、作ると決めた範囲が小さくても確実に使われるものになります。

DXを一緒に考えられる開発パートナーの見極め方

「言われたとおりに作る」会社と「本質から一緒に考える」会社は、商談の初期に見分けられます。確認すべきはシンプルです。

  • 課題の背景を掘る質問をしてくるか — 機能の話より先に「なぜその業務があるのか」「誰がどれだけ困っているのか」を聞いてくるか
  • 開発以外の選択肢に言及するか — 運用変更や既製ツール、「やらない」を含めた比較を出せるか
  • 小さく検証する提案があるか — 最初から大きな見積もりではなく、業務フローの可視化や小さな試作から入る提案ができるか

この観点は、開発会社の選び方の記事で書いた「要件定義のサポート力」をさらに一段掘ったものです。パートナー選びとは、実は「自社の問題の本質を一緒に疑ってくれる相手」を選ぶことだと私は考えています。

「そもそも何を解決すべきか」から一緒に考えたい方へ

シンシアでは、システムを作るかどうかの判断も含めて、業務課題の整理・DXの進め方の壁打ちを無料で承っています。「開発しないほうがいい」と正直にお伝えすることもあります。

業務課題・DXの無料相談を申し込む

まとめ — システムは手段、問いの立て方が成果を決める

IT化・DXの成否は、技術選定よりも前の「何を問題と定義するか」でほぼ決まります。言われた問題をそのまま解かず、損失を数字にし、一つ上の階層を疑い、無くせないかを問う。その結果として「開発しない」も含めた選択肢を一緒に並べられるパートナーと組むこと——それが、使われないシステムに投資しないための、最も確実な方法だと考えています。

次に読むべき記事

Share

シンシアへのご相談

要件整理の壁打ちを依頼する

「何を作ればいいか整理できていない」段階からお声がけください。要件定義・業務整理の壁打ち相談を無料で承っています。

要件整理の壁打ちを依頼する

まだ検討段階の方は 質問だけでもOK(電話番号は任意)

この記事が役に立ったら、Google で優先表示を

Google 検索の「優先するソース」に blog.xincere.jp を追加すると、シンシアの新着記事がトップニュースなどで見つけやすくなります。

Google で優先ソースに追加

著者について

徐 聖博のプロフィール写真
徐 聖博
株式会社シンシア 代表取締役社長

株式会社シンシア(Xincere, Inc.)代表取締役。中国生まれ・3歳から日本で育ち、日本語・中国語・英語を操るトリリンガル。大学院でコンピュータサイエンス(進化型ニューラルネットワーク)を研究し、GREE・メドレー・カウンティア・Indeed Japan などで検索エンジン開発やスタートアップの立ち上げ・グロースを経験。2020年に「人の価値をテクノロジーで最大化する」という想いでシンシアを創業した。エンジニア歴15年以上、代表でありながらほぼ毎日コードを書く現役エンジニアとして、基幹システム開発からAIエージェント活用まで顧客の事業成長に並走している。創業に込めた思いはnoteの創業ストーリーに綴っている。

人気記事

    お問い合わせ

    システム開発やAI推進についてのご相談はこちらから

    無料相談を予約する