システムの問題に見えて、実は「判断」の問題かもしれません

システム刷新、クラウド移行、ベンダ選定、業務改善。ITに関する課題はさまざまですが、実際にご相談をいただく中で感じるのは、多くの問題がシステムそのものではなく「判断」に関係しているということです。

何を優先するべきか。どの選択肢を選ぶべきか。誰が判断するべきか。これらが曖昧なまま進んでしまうことで、プロジェクトの停滞やトラブルにつながるケースは少なくありません。

ここでは、実際に当社へ寄せられるご相談をもとに、よくあるケースをご紹介します。

1. ベンダーから3,000万円の提案が出てきたが判断できない

基幹システムの老朽化をきっかけに、ベンダーから刷新提案を受けた企業様からのご相談です。提案書は100ページ近くあり、見積金額は約3,000万円。担当者としては内容を理解しようと努力しているものの、「正直なところ、何が書いてあるのかよく分からない」という状態でした。

ベンダーに質問すると丁寧に説明してくれる。しかし説明を聞くほど、「なるほど」「確かに必要そうだ」と思う反面、「本当にそうなのだろうか」という疑問も残る。社内でも、「それだけの投資が必要なのか」「他に方法はないのか」という声が出始めていました。

特に経営層からは、「その金額をかけたら何が改善するの？」という当然の質問が出ます。しかし担当者自身も十分に説明できない。ベンダーを疑っているわけではない。ただ、判断材料が足りない。

そのため第三者の視点で、
・本当に全面刷新が必要なのか
・他の選択肢はないのか
・費用対効果をどう考えるべきか
を整理したいというご相談です。

2. 提案書を比較しても違いが分からない

複数社によるコンペを実施した企業様からのご相談です。提案書は揃った。プレゼンも終わった。しかし選べない。A社は業界実績が豊富。B社は価格が安い。C社は提案内容が先進的。それぞれ魅力がある。

選定委員会では、「どこも悪くないよね」という空気になっていました。しかし、「どこも悪くない」は、「選べない」と同じ意味でもあります。

詳しく伺うと、比較表は作られているものの、本当に重要な評価軸が定まっていませんでした。価格なのか。実績なのか。保守性なのか。将来性なのか。

比較する前に、「自社は何を重視するのか」を整理する必要があるケースです。

3. 現ベンダーに不満はあるが切り替える勇気が出ない

非常によくあるご相談です。長年付き合いのあるベンダー。大きなトラブルがあったわけではない。しかし、
・問い合わせの返答が遅い
・改善提案が出てこない
・担当者が頻繁に変わる
といった不満が積み重なっている。

社内会議では、「他社も検討した方が良いのでは」という声が出る。一方で、「でも一番システムを知っているのは今のベンダーですよね」という意見も出る。結果として何年も現状維持が続く。

実際には、ベンダーを変えるべきかどうかではなく、現在の関係性にどのような課題があるのかを整理することが先になるケースが少なくありません。

4. ベンダーごとに言うことが違う

システム刷新の検討を始めた企業様からよく聞く話です。A社に相談すると、「パッケージ導入が最適です」と言われる。B社に相談すると、「御社の業務は特殊なので個別開発が良いです」と言われる。さらにC社からは、「今ならSaaS活用が主流です」と言われる。どの話も筋が通っているように聞こえる。だからこそ困る。提案を聞けば聞くほど、何が正しいのか分からなくなってしまう。

実際には、各社とも間違っているわけではありません。問題は、自社として何を優先するのかが整理されていないことです。そのため技術比較ではなく、判断基準の整理から始める必要があります。

5. クラウド化を勧められているが必要性が分からない

近年増えているご相談です。保守期限やサーバ更新のタイミングで、「この機会にクラウドへ移行しましょう」という提案を受ける。確かにクラウド化にはメリットがある。しかし、担当者としては、「クラウドにすると何が良くなるんですか？」という疑問が残る。さらに経営層からは、「結局コストは下がるの？」という質問が出る。一方でベンダーからは、「今後はクラウドが前提です」という説明を受ける。結果として、クラウド化が目的になってしまう。

本来考えるべきなのは、自社の運用体制や事業計画に対して何が最適かです。技術トレンドではなく、経営判断として整理したいというご相談です。

6. システム刷新の話が3年進んでいない

最初に話が出たのは3年前。当時は、「このシステムもそろそろ限界ですね」という軽い問題提起でした。その後、現場ヒアリングをした。ベンダーにも相談した。予算案も作った。経営会議にも何度か上がった。しかし3年経った今も、何も始まっていない。

担当者様は苦笑いしながら、「実は毎年同じ話をしているんです」とおっしゃいました。詳しく話を聞くと、現場は使い勝手を改善したい。管理部門は属人化を解消したい。経営層はコスト削減を期待している。それぞれが違う目的で刷新を語っている。だから議論は進んでいるように見えて、実は前に進まない。

システムの問題ではなく、「何のために刷新するのか」が共有されていない状態でした。こうしたケースでは、システムの議論より先に、経営と現場の認識を整理することが重要になります。

7. 保守期限が迫っているが何から始めればよいか分からない

ある日、ベンダーから「現在ご利用中の製品は○年後にサポート終了となります」という連絡が来る。担当者としては焦ります。しかし、何をすれば良いのか分からない。ベンダーは刷新を提案する。経営層は費用を気にする。現場は今のままで良いと言う。結果として、誰も動けなくなる。

実際には、サポート終了とシステム刷新は同じ話ではありません。延命という選択肢もある。部分的な刷新という選択肢もある。クラウド移行という選択肢もある。

ところが多くの場合、最初から「全面刷新ありき」で話が進んでしまう。何が課題で、何が制約で、どこまで急ぐ必要があるのか。まず状況を整理したいというご相談です。

8. 担当者が退職しシステムの中身が分からなくなった

長年システムを担当していた社員が退職した。資料も残してくれた。引き継ぎも行った。それでも不安が消えない。なぜなら、引き継げるのは資料であって、判断の経緯ではないからです。

後任者が最初に困るのは、システムそのものではありません。むしろ、「なぜこうなっているのか」です。なぜこの仕様なのか。なぜこの運用なのか。なぜこのベンダーなのか。なぜ毎月この作業をしているのか。

ベンダーへ問い合わせると、「それは前任の担当者様と相談して決めました」と言われる。結果として、誰も変更を決断できない。だから、「怖いから触らない」という状態になる。

システムがブラックボックス化する背景には、技術的な問題よりも、意思決定の履歴が失われる問題が潜んでいることが少なくありません。

9. 現場から不満は出るが改善要望がまとまらない

現場へヒアリングをすると、次々に不満が出てくる。「入力が面倒」「検索しづらい」「処理が遅い」「画面が分かりにくい」。

しかし、改善案を聞くと話が止まる。実際には、現場が欲しいのは機能ではなく、仕事のしやすさだからです。

ある部署では欲しい機能が、別の部署では不要かもしれない。担当者ごとに考え方も違う。結果として、要望リストだけが増えていく。そして会議では、「全部必要です」という結論になる。しかし予算も時間も有限です。そのため、何を優先するのか。何を諦めるのか。判断基準を整理する必要があります。

10. システム刷新の目的そのものが曖昧になっている

プロジェクトの初期段階でよくあるケースです。関係者へ「なぜ刷新するのですか」と質問すると、それぞれ違う答えが返ってきます。

経営層は「人手不足に対応したい」と言う。現場は「今のシステムが使いづらい」と言う。情報システム部門は「保守が限界です」と言う。どれも間違いではありません。しかし、プロジェクトとしては危険な状態です。なぜなら、成功の定義が人によって違うからです。稼働後に「思っていたものと違う」が発生しやすい。

システムの設計に入る前に、何を実現したいのか。何を優先するのか。何を成功と呼ぶのか。そこを整理することが、実は最も重要な作業だったりします。

11. プロジェクト開始から2年経ったが運用開始できない

当初の計画では1年で稼働する予定だった。予算も確保した。ベンダーも決まった。キックオフも行った。ところが2年経った今も本番稼働していない。担当者様は、「こんなはずじゃなかったんですが…」とおっしゃいます。

よく話を聞くと、途中で何度も方向転換が発生している。業務変更が入った。組織変更があった。追加要望も増えた。その都度、「今のうちにやっておこう」という判断が積み重なる。

結果として、ゴールそのものが動いてしまう。気付けば、いつ終わるのか誰にも分からない。

こうしたケースでは技術の問題よりも、「何を諦めるか」を決められなくなっていることが少なくありません。

12. 要件変更が止まらない

要件定義は終わったはずだった。設計も始まっている。しかし会議のたびに、新しい要望が出てくる。現場に悪気はありません。むしろ、システムが具体化されるほど、本当に必要なものが見えてくる。だから、「やっぱりこの機能も欲しい」「この画面も変えたい」という話になる。

一方でベンダー側は、設計や開発を進めたい。結果として、現場は「柔軟に対応してほしい」、ベンダーは「仕様を確定してほしい」という対立構造になります。

実際には、要件変更そのものが悪いのではありません。どこまで変更を認めるのか。何を優先するのか。その判断ルールが曖昧なことが問題になるケースが多くあります。

13. 会議は増えているのに何も決まらない

毎週会議をしている。関係者も集まっている。議事録もある。一見するとプロジェクトは動いているように見える。しかし、半年後に振り返ると、何も決まっていない。そんなケースがあります。

会議では様々な意見が出ます。現場は使い勝手を主張する。管理部門は統制を求める。情報システム部門は運用負荷を心配する。どの意見も正しい。だから反対できない。結果として、「次回までに整理しましょう」が繰り返される。実際には会議が多いのではなく、意思決定の場が存在していないケースです。

14. 現場と経営層で意見がまとまらない

現場は困っている。だから改善したい。一方で経営層は、投資対効果を求める。

現場から見れば「毎日苦労しているんだから改善してほしい」、経営層から見れば「数千万円かける理由を説明してほしい」。どちらも正論です。しかし議論がかみ合わない。その結果、現場は「どうせ分かってもらえない」となり、経営層は「本当に必要なのか分からない」となる。

システム刷新の議論に見えて、実際には経営課題と業務課題の橋渡しが不足している状態です。

15. 開発会社との関係が悪化している

最初は良好な関係だった。期待も大きかった。しかしプロジェクトが進むにつれて、少しずつ空気が変わっていく。

現場からは「聞いていた話と違う」という声が出始める。ベンダーからは「追加要件なので費用が発生します」という説明が増える。会議では、お互いに言葉を選ぶようになる。やがて「あの会社は分かっていない」「お客様が決めてくれない」という不満が水面下で蓄積される。

実際には、どちらかが悪いわけではないケースも少なくありません。期待していた役割。認識していた責任範囲。成功のイメージ。そうした前提のズレが積み重なった結果として、関係が悪化していくのです。

16. システム担当者が一人しかいない

情報システム担当者は一人。障害対応も担当する。ベンダーとの窓口も担当する。社内問い合わせにも対応する。さらにプロジェクトも担当する。本人も限界を感じている。会社もリスクを感じている。しかし代わりがいない。

こうした状況では、重要な判断が特定の個人に集中しやすくなります。その人が休めない。退職できない。結果として、組織としての持続性に課題が生じます。

17. IT投資を説明できる人が社内にいない

経営会議で質問される。「結局、いくらかかるの？」「何が良くなるの？」「やらなかったらどうなるの？」

担当者としては必要性を感じている。しかし技術的な話を経営判断の言葉に変換できない。そのため、必要な投資なのに承認されない。あるいは逆に、十分な議論がないまま承認されてしまう。そんなケースもあります。

18. 情報システム部門がベンダー管理に追われている

本当は将来のIT戦略を考えたい。業務改善にも取り組みたい。しかし現実は、ベンダーとの調整。問い合わせ対応。障害対応。契約管理。日々の業務に追われてしまう。

気付けば、「考える仕事」より「さばく仕事」が増えている。そうした状態から抜け出したいというご相談も少なくありません。

19. RFPを作れと言われたが何を書けばよいか分からない

システム刷新やベンダー選定の話が進み、「まずはRFPを作りましょう」と言われる。最近ではインターネットでテンプレートも手に入る。AIに作らせることもできる。しかし実際に作り始めると手が止まる。何を書けばよいのか分からない。

そもそも、どこまで整理できていれば提案を依頼できるのかが分からない。現場へヒアリングをすると要望は大量に出てくる。経営層へ確認すると、予算や方向性について様々な意見が出てくる。情報システム部門は、技術的な制約や運用面の懸念を抱えている。結果として、情報は集まる。しかし整理できない。

実際には、RFPとは提案依頼書ではありますが、本質的には「自社が何を実現したいのか」を整理する作業でもあります。

そのため、RFP作成で苦労している企業様の多くは、文書作成に困っているのではなく、意思決定の整理に困っています。どのような提案を期待するのか。何を評価するのか。何を優先するのか。それらを整理した結果としてRFPが出来上がります。

私たちはRFPを書くこと自体よりも、その前提となる考え方や判断基準の整理をご支援しています。

20. 「このまま進めて大丈夫ですか」と相談したい

実は最も多いご相談です。システム刷新を決めたわけでもない。ベンダー選定を始めたわけでもない。プロジェクトが炎上しているわけでもない。しかし、何となく違和感がある。何となく不安がある。

担当者様からよく聞くのは、こんな言葉です。「ベンダーの話を聞いているのですが、正しいのか判断できなくて」「社内では前に進んでいることになっているのですが、少し気になっていて」「問題が何なのかも整理できていないのですが、一度相談できますか」

明確な課題が見えているケースもあります。一方で、課題そのものがまだ言語化できていないケースも少なくありません。むしろ後者の方が多いかもしれません。

私たちは特定の製品や開発手法を販売する会社ではありません。また、最初からシステム刷新ありきで考えるわけでもありません。だからこそ、「そもそも何が問題なのか」「本当にシステムの問題なのか」というところから整理することができます。

実際にご相談を受ける中でも、当初はシステムの課題だと思われていたものが、組織や業務の課題だったというケースもあります。逆に、運用の問題だと思われていたものが、システム構造の問題だったというケースもあります。

重要なのは、急いで答えを出すことではなく、正しい問いを見つけることです。私たちはシステムを売る会社ではなく、発注側の判断を支援する立場として、状況整理からお手伝いしています。

「何を相談すればよいか分からない」その段階でも構いません。まずは現在感じている違和感や不安をお聞かせください。

共通しているのは「システムの問題」ではなく「判断の問題」です

ここまでご紹介した20のケースは、一見すると別々の問題に見えるかもしれません。しかし実際には、

• 何を優先するべきか
• どの選択肢を選ぶべきか
• 誰が判断するべきか

という判断の問題に行き着くケースが少なくありません。

ベンダー選定に迷うのも。プロジェクトが停滞するのも。現場と経営層が対立するのも。背景には「判断材料の不足」や「判断軸の不一致」が存在していることがあります。

私たちはシステムを販売する会社ではありません。だからこそ、「どの製品を導入するべきか」よりも、「何を基準に判断するべきか」を整理するところからご支援しています。

当社がお手伝いできること

ご相談内容に応じて、以下のようなご支援を行っています。

システム構想支援

「何を作るべきか」「何を優先するべきか」がまだ整理できていない段階からご支援します。

例えば、

• システム刷新の方向性検討
• 現状課題の整理
• IT投資計画の策定
• 構想策定・ロードマップ作成

といったテーマを扱います。

このような方へ

• システム刷新の話が何年も進んでいない
• クラウド化の必要性を判断できない
• 投資の優先順位を整理したい
• ベンダー提案の妥当性を確認したい

【システム構想支援の詳細はこちら】

基幹システム再構築支援

老朽化やブラックボックス化した基幹システムの再構築を支援します。単なるシステム導入ではなく、業務・運用・組織体制まで見据えた支援を行います。

このような方へ

• 保守期限が迫っている
• 担当者が退職してしまった
• 現行システムの限界を感じている
• 再構築プロジェクトを立ち上げたい

【基幹システム再構築支援の詳細はこちら】

RFP・ベンダ選定支援

発注側の立場で、ベンダ選定を支援します。特定の製品や開発会社に依存しない立場から、判断材料を整理します。

このような方へ

• RFPを作成したい
• 提案書を比較しても違いが分からない
• ベンダ選定に不安がある
• 第三者の意見が欲しい

【RFP・ベンダ選定支援の詳細はこちら】

システムの相談ではなく、判断の相談をお受けしています

「システムを刷新するべきか分からない」「ベンダーの提案が妥当なのか判断できない」「何が問題なのか整理したい」そんな段階でも構いません。

むしろ、何を相談すればよいか分からない状態でご相談いただくケースも少なくありません。まずは現在の状況やお悩みをお聞かせください。

無料相談はこちら

判断材料の整理からお手伝いします

• ベンダー提案の妥当性確認
• IT投資の方向性整理
• プロジェクトの状況整理
• システム刷新の進め方検討

相談料は無料です。製品の販売や特定ベンダーへの誘導は行いません。まずは現在の状況やお悩みをお気軽にお聞かせください。