「システムを作りたいんですが、要件定義書を用意してくださいと言われまして...そんなの書けませんよ」
システム開発会社に相談に行った社長が、困り果てて私たちのところに来る。これもよくあるパターンです。 従来のシステム開発（ウォーターフォール型）では、「何を作るか（仕様）」を発注側が100%正確に定義することが前提とされます。しかし、これは専門家でない中小企業の担当者にとって、あまりに酷な要求です。
そもそも、最初から完璧な正解（要件）がわかっているなら苦労はしません。「何が正解かわからないから、それを探すところから手伝ってほしい」というのが本音ではないでしょうか。
1. 「仕様書通りに作ります」は無責任の証
一般的なSIer（システムインテグレーター）は、「要件定義書に書いてあることは実装します。書いてないことはやりません」というスタンスです。これは契約上は正しいですが、ビジネスのパートナーとしては冷たすぎます。
例えば、要件定義書に「顧客一覧画面を表示する」と書いてあれば、そのまま作ります。しかし、本当に必要なのは「半年以上注文がない休眠顧客をピックアップして営業リストにする機能」だったかもしれません。
仕様書に書かれていないから作らない。結果、使えないシステムができる。この不幸なミスマッチは、開発側が「言われたことだけやる」姿勢でいる限りなくなりません。
2. INDUXのアプローチ：対話の中から仕様を「発見」する
私たちINDUXは、お客様に完璧な仕様書を求めません。むしろ、「仕様書は書き上げないでください」と言うことさえあります。
代わりに重視するのは、徹底的な「ヒアリング」と「プロトタイピング」です。
INDUXの開発スタイル
- 現場インタビュー：社長だけでなく、現場の方に「今、何が一番面倒ですか？」「理想はどういう状態ですか？」と聞き回ります。
- モックアップ（試作）の提示：「口で説明するより見たほうが早いですよね」と、紙芝居レベルの画面イメージやすぐに触れる試作品をすぐに作って見せます。
- 走りながら直す：「触ってみたら、ここのボタンは右にあったほうがいいな」という気づきを、その場で仕様に取り込みます。
私たちは、「仕様書通りに作る会社」ではなく、「お客様と一緒に仕様書を作る会社」です。業務のプロであるお客様と、デジタルのプロである私たちが対話を重ねることで初めて、本当に使えるシステムの形が見えてくるのです。
3. 翻訳者としてのコンサルタント
製造現場には専門用語が飛び交い、独特の商習慣があります。一方で、ITエンジニアも専門用語で話します。 この両者の言葉は往々にして通じ合いません。「在庫」という言葉一つとっても、経理上の在庫なのか、実在庫なのか、予約済み在庫を含むのかで意味が異なります。
INDUXのコンサルタントは、この両者の言葉を翻訳します。
「現場が言っている『段取り替え』というのは、システムで言うとパラメータ設定の変更にあたりますね」といった具合に、両者の認識ズレを防ぎながら、要件を固めていきます。
「要件定義ができない」と悩む必要はありません。それはプロである私たちが引き出します。
あなたには、「会社をこうしたい」「現場をこう変えたい」という想いさえあれば十分です。その想いを、動くシステムという形にするのが、私たちINDUXの仕事です。
御社のDX、私たちが伴走します
「何から始めればいいかわからない」「現場の抵抗が心配」
そんなお悩みをお持ちの製造業経営者様、まずは一度お話をお聞かせください。
INDUXは、システム導入だけでなく、現場への定着まで責任を持って支援します。