社内でだけ通用するプロダクトの罠

社内で使うために作ったツールが、思いのほかうまく機能する。同じ課題を持つ他社にも売れるのではないか。こうした発想は自然ですが、実際に外部へ出そうとすると、想定を超える作り直しが必要になることがあります。

原因は技術力ではなく、社内で使うために取り込んだ暗黙の前提です。本記事では、その前提がどこに入り込むのかと、外販を視野に入れるなら何を分けておくべきかを整理します。

暗黙の前提はどこに入り込むか

社内前提への依存は、次の四箇所に集中します。

社内用語

画面のラベル、メニュー名、エラーメッセージに社内用語が入ります。「案件」「引合」「与信」といった言葉は、社内では通じますが、会社が違えば指す範囲が変わります。同じ「案件」が、ある会社では受注前の商談を指し、別の会社では契約後の作業単位を指します。

この依存が厄介なのは、画面の文言を置き換えるだけでは済まないことです。用語が違うということは、業務の単位の切り方が違うということであり、データ構造まで遡ることがあります。

既存データの形式

社内の既存システムや表計算ファイルの形式を前提にした取り込み処理は、外部では動きません。列の順序、日付の書き方、コードの体系、文字コード。これらは社内では固定されていますが、他社では違います。

データ移行の処理を「うちのファイルを読める」形で作ると、外販時には取り込み機能をほぼ作り直すことになります。

業務手順の順序

「申請 → 上長承認 → 経理確認 → 完了」という流れを固定して実装すると、承認が二段階の会社や、経理確認が不要な会社では使えません。順序が固定されているだけでなく、順序を変えられる設計になっていないことが問題です。

組織構成と権限

「部長は全件見られる」「拠点をまたぐ閲覧はできない」といった権限の設計は、自社の組織図を前提にしています。他社の組織構成は違い、そもそも部署という単位を持たない小規模な会社もあります。

なぜ気づかないのか

これらの依存は、社内で使っている限り問題として現れません。むしろ、社内に合わせるほど使いやすくなるため、依存を深める方向に改善が進みます。

さらに、社内から上がる要望がこの傾向を強めます。「うちの承認フローに合わせてほしい」「既存の台帳と同じ列順にしてほしい」という要望は、社内の利用者にとって切実で、対応すれば確実に喜ばれます。社内の声だけを判断材料にすると、依存は加速します。この非対称についてはドッグフーディングの限界と誤判断で扱っています。

想定例：社内の工程管理ツールを外販しようとした場面を考えます。機能としては十分でしたが、工程の名称が自社の製造ラインの呼び名に固定されており、工程の数も自社の構成に合わせて固定されていました。名称を設定可能にするだけでは足りず、工程の数と順序を可変にする必要があり、データ構造から見直すことになりました。実運用で得た業務の理解は残りましたが、実装は大部分を作り直す判断になりました。

外に出す予定があるなら、最初に分けておく

外販や他社への提供を視野に入れるなら、最初の段階で「自社固有」と「どの会社にも共通」を分けておきます。分けるとは、共通部分を作り込むことではなく、固有部分を後から差し替えられる位置に置くことです。

重要なのは、これらを最初から柔軟に作ることではありません。最初は自社の値を固定で入れておいて構いません。固定値をコードの深い場所に散らさず、一箇所にまとめておくことが要点です。この差が、後から変える費用を大きく左右します。

外に出す予定がないなら、汎用化しない

一方で、外販の予定がないのに汎用的に作ることは、費用と期間の無駄です。

使われない柔軟性は、複雑さだけを残します。設定項目が増え、テストの組み合わせが増え、不具合の原因が特定しにくくなります。「いつか外に出すかもしれない」という曖昧な期待で汎用化を進めると、社内での使い勝手も外販の可能性も両方中途半端になります。

判断は、曖昧なままにせず明示します。

• 社内専用と決める：自社の業務に最適化し、汎用化はしない
• 外販を視野に入れる：上記の四箇所について、後から変えられる位置に固定値を置く
• 判断を保留する：保留であることを記録し、判断の期限を決める

保留のまま進める場合でも、保留であると分かっていることに意味があります。決まっていない事実を共有していれば、後から依存が見つかったときに驚かずに済みます。

作り直しは負債ではなく前提の違い

依存が見つかって作り直しになったとき、それを開発の失敗と捉える必要はありません。社内向けとして正しく作られたものが、外販という別の要件を満たしていなかっただけです。

技術的負債は、後回しにした設計上の問題が積み上がった状態を指しますが、社内前提への依存はこれとは性質が違います。当時の要件に対しては正しい設計であり、要件が変わったことで合わなくなっただけです。両者を混同すると、「なぜこんな作りにしたのか」という不毛な議論になります。

作り直すかどうかの判断は、レガシーコードのモダナイズで扱う全面置き換えと段階移行の考え方と同じ枠組みで行えます。残せる部分（業務の理解、機能の輪郭、運用で分かった例外の一覧）と、作り直す部分（社内前提に縛られた実装）を分けて見積もります。

決めていない、という状態を避ける

社内でだけ通用するプロダクトになるのは、汎用化を怠ったからではなく、外に出すかどうかを決めないまま進めたからです。

社内専用と決めれば、自社に最適化することが正解になります。外販を視野に入れるなら、用語・データ形式・業務手順・権限の四箇所について、固定値を差し替えられる位置に置いておきます。どちらも選ばず曖昧なまま進めることだけが、後から高くつきます。

社内ツールの外販可否の見極めや、Webシステム開発・既存サービス改修・モダナイズについてご相談がありましたら、お問い合わせからお気軽にご連絡ください。