コードを書く前に：私たちが必ずお客様にお聞きする5つの質問

多くのプロジェクトは、最初から「答え」から始まります。

「システムを作りたい」
「ダッシュボードが欲しい」
「ソフトウェアを機械と連携したい」

Simplicoでは、この最初の一歩をあえて少しだけゆっくり進めます。

それは、開発をしたくないからではありません。むしろその逆です。
私たちの経験上、

コードを書き始めるタイミングが早すぎることは、システム開発において最も高くつく失敗の一つだからです。

アーキテクチャ設計やデータベース、ハードウェア連携の話に入る前に、
私たちは必ず 5つの基本的な質問 から始めます。

これらは技術的な質問ではありません。
「考えを整理するための質問」です。

目的は一つ。
正しく動くが、目的を外したシステムを作らないためです。

質問1：このシステムは、どの「意思決定」や「行動」を楽にするべきですか？

多くの場合、お客様の要望は「機能」から語られます。
しかし私たちは「意思決定」に注目します。

ダッシュボードは目的ではありません。
APIも目的ではありません。
自動化でさえ、目的ではありません。

本当に重要なのは次の点です。

今、判断が遅い・不安定・属人化している意思決定は何か
その判断を行うのは誰か
判断が遅れたり誤った場合、何が起きるのか

良いシステムは意思決定を静かに支えます。
悪いシステムは、画面だけを増やします。

質問2：ソフトウェアが存在しなくても、この問題は残りますか？

この質問は、会話を一度立ち止まらせます。
それは健全なサインです。

もし明日、システムが存在しなかったら：

問題はまだ存在するでしょうか
それはプロセスの問題か、コミュニケーションか、責任範囲でしょうか

ソフトウェアは「現実を拡大」します。

整理されたプロセス → 速くなる
整っていないプロセス → 混乱が拡大する

だからこそ、ソフトウェアなしで問題を理解することが重要です。

質問3：情報はどこで始まり、どこで終わりますか？

製造業や複数部門、機械を含むシステム統合では、
問題の多くはコードではなく 境界の曖昧さ から生まれます。

私たちは次を整理します。

情報は誰・何から生まれるのか（人／機械／外部システム）
途中でどのように変化するのか
どこで判断・報告・アクションに変わるのか

これにより、

自動化すべき部分
人が担うべき部分
ハードウェア連携が本当に必要な部分

が自然に見えてきます。

良いシステムは境界を尊重します。
悪いシステムは、すべてを一つにまとめようとします。

質問4：今後2〜3年で「確実に変わる」ものは何ですか？

多くのシステムはすぐには壊れません。
事業が変わったときに、静かに使えなくなります。

私たちは次を確認します。

比較的変わらない部分
変化が予想される部分（数量、法規、取引先、設備、市場）

これが、

ハードコードを避ける箇所
設定として持たせる箇所
将来の設備更新に耐える設計

を決める基準になります。

柔軟性とは、すべてに備えることではありません。
どこを柔軟にするかを選ぶことです。

質問5：このシステムが「機能している」と、どうやって分かりますか？

提案書やKPIではありません。
日常業務の中でです。

何が楽になったか
何を説明しなくてよくなったか
どんな小さなストレスが消えたか

簡単に説明できない成功は、
たいてい複雑すぎるシステムの兆候です。

私たちが使う意思決定フロー

以下は、初期の打ち合わせでよく一緒に描くシンプルなフローです。

flowchart TD
  A["ビジネス上の課題・目的"] --> B{"意思決定の問題か？"}

  B -- "はい" --> C["誰が意思決定するのか？"]
  B -- "いいえ" --> D["プロセス・役割を先に整理"]

  C --> E["不足している情報は？"]
  E --> F{"ソフトウェアなしで解決可能か？"}

  F -- "可能" --> G["プロセス・ルール改善"]
  F -- "不可" --> H["システム境界を設計"]

  H --> I["ソフトウェア中心で設計"]
  I --> J["価値がある場合のみハードウェア連携"]