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

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

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

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

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

社内用語

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

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

既存データの形式

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

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

業務手順の順序

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

組織構成と権限

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

なぜ気づかないのか

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

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

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

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

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

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

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

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

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

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

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

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

外販しないほうがよい社内ツール

「社内でうまく回っているから売れるのではないか」という発想には、判断すべき論点が一つ抜けています。うまく回っている理由が、プロダクトにあるのか、自社の運用にあるのかです。

社内ツールが機能しているのは、多くの場合、作った人が近くにいて、詰まったらその場で直し、例外は人が裏で処理しているからです。この三つが外部の顧客には付いてきません。同じものを渡しても、同じようには回りません。

次のいずれかに当てはまるなら、外販は勧めません。

• 例外処理を人が裏で肩代わりしている：その工数が、顧客の数だけ増えます。外販とは、その肩代わりを商品として売ることになります
• 困ったら作った人が直す前提で運用している：顧客が同じ状況になったとき、問い合わせ対応と改修が事業の主な活動になります。開発会社ではなく保守会社の事業構造です
• 同じ課題を持つ他社を、具体名で三社挙げられない：社内の課題が業界共通だという確信は、たいてい確かめられていません。売る前に、まず三社に話を聞く工程が要ります
• 既存事業の担当者が兼務で対応する計画になっている：外販は別事業です。問い合わせ対応も、契約も、請求も新しく発生します。兼務にすると、緊急度の高い本業の対応が常に優先され、立ち上げの判断は溜まったまま進みません

弊社にご相談いただいた場合も、この四つを先に伺います。技術的には外販可能な状態でも、事業として成立しないと判断できるなら、その旨をお伝えします。開発の受注としては、汎用化の改修を請けるほうが大きくなりますが、使われない汎用化ほど費用対効果の悪い投資はありません。

社内で便利に使い続けるという結論も、後退ではありません。自社の業務に最適化されたツールは、それ自体が十分な成果です。

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

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

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

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

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

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

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

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