# 自社開発したソフトウェアのトレーニングは誰が新人に教えるのか？

> Published: 2026-08-04
> Updated: 2026-08-04
> Author: Mathias Nielsen
> Category: POS
> Canonical: https://finalpos.com/ja/blog/who-trains-staff-software-you-built-in-house-ja

自作か購入かを巡る議論では、開発コストばかりが評価され、トレーニングはタダであるかのように扱われがちです。しかし、実際は違います。自社開発したソフトウェアを運用する場合、新しく入ったスタッフは開発者本人から使い方を教わることになり、そのツケは初出勤のシフトで回ってきます。

あなたです。自社開発したソフトウェアのトレーニングは、デフォルトではそれを開発した人（オーナー、プロンプトを入力して作成させたマネージャー、あるいはセットアップ方法を覚えている最後の従業員）が担当することになります。自作か購入かを巡る議論では、開発コストが時間や費用として計算される一方で、トレーニング費用はゼロとして扱われがちです。しかし現実は違います。トレーニングは新しい人がレジに立つたびに発生する継続的なコストであり、それをあらかじめ予算に組み込んでいる人はほとんどいません。

## 新人が自社ツールを初めて触るとき、実際に何が起きるのか？

「横に付いて教える」マンツーマンのトレーニングです。ツールを知っている人が知らない人の隣に立ち、操作を実況解説します。一度ならこれで機能します。問題は、一度で終わることが絶対にないという点です。米国労働統計局（BLS）が追跡している全業界の中で、小売業や接客業は一貫して最も離職率が高い部類に入ります[¹](https://www.bls.gov/jlt/)。そのため、実況解説は新しい人が入るたびに、しかも常に最悪のタイミング（シフトの最中、ピーク時、あるいは開発者の休日）で繰り返されます。

より深遠な問題は「暗黙知（文書化されず個人の頭の中にのみ存在するノウハウ）」です。自社開発ソフトウェアはこの暗黙知を集中させます。返金フローがなぜそのような仕組みになっているのかを知る人物は一人しかおらず、その人物には経営という本来の業務もあります。その人が休暇を取れば回答も休暇に入り、その人が辞めれば回答も消え去ります。エンジニアはこれを「バス因子（システムが動かなくなるまでに消えても大丈夫な人数のこと）」と呼びます。自作ツールのほとんどにおいて、その数値は「1」です。

![手書きのメモで埋め尽くされたチェックアウト画面。自社開発ソフトウェアの非公式なマニュアル](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/8b89e6457ddd2075-in-house-software-tribal-knowledge-sticky-notes.png)

## なぜ既製品のソフトウェアは自作ツールよりもトレーニングが容易なのか？

それは、既製品のほうが優れたソフトウェアだからではありません。「共有されたソフトウェア」だからです。一般的な POS や会計ツールには、ヘルプセンター、チュートリアル動画、コミュニティフォーラム、サポート窓口が備わっており、新しく採用した人が前の職場ですでに使ったことがある可能性も十分にあります。ユーザーベースの広さそのものがトレーニング部門の役割を果たしているのです。

一方、自社ツールのユーザーベースは「1」です。最初から使い方を知っている人など存在せず、解説動画もなく、フォーラムにエラーメッセージが掲載されたこともありません。すべての質問が同一人物へと集約されます。

それでも、自社開発を選ぶ価値がある場合もあります。私たち自身もその選択をし、[2026年に自社で内部ソフトウェアを開発すべきか？](/blog/build-its-own-internal-software) でその経験について書きました。また、[SaaSは死んだのか？](/blog/is-saas-dead-build-in-house) にあるより広い原則は今でも有効です。「自社を差別化する層は自作し、毎回正確であるべきインフラは購入する」という考え方です。しかし、AIによって開発コストが安くなったことで、ドキュメントのないツールが密かに中小企業の現場で急増しました。プロンプトはソフトウェアを書きますが、マニュアルまでは書きません。[POSをバイブコーディングする](/blog/vibe-coding-a-point-of-sale) でも別の角度から同じパターンを示しています。動くデモを作るのは簡単な部分であり、その周囲にあるすべてが本当の仕事なのです。

![新人スタッフが自分なしでトレーニングできるように、自社開発ソフトウェアの仕組みを文書化するビジネスオーナー](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/2dc2d84b9b1e2b30-documenting-in-house-software-runbook.png)

## 自社開発ソフトウェアをトレーニング可能にするには？

トレーニング資料を開発後の後回しの作業ではなく、開発プロセスの一部として扱います。主に以下の6つの実践でカバーできます。

- 開発しながらランブック（手順書）を作成する。タスクに5回のタップが必要なら、紙の上にも5行の記述が必要です。後で書こうとすると、永久に書かれません。
- タスクごとに1つの短い画面操作動画を録画する。2分の動画5本のほうが、20分のツアー動画1本より効果的です。新人が見返すのはツアー全体ではなく、返金手順の動画だからです。
- 新人からの質問はすべてドキュメントのバグとして扱う。口頭で一度答えたら、次の新人が実際に目にする場所にその回答を書き残します。
- 機能面を小さく保つ。画面数や例外処理を減らせば、教えることも減ります。カスタムソフトウェアが価値を発揮するのは、ボタンの数が多いからではなく、自社のプロセスに合致しているからです。
- 2人目のスーパーユーザーを指定する。その人が自分に連絡することなく、返金処理を含めたシフト全体を仕切れるようにすべきです。それができる人が現れるまで、バス因子は「1」のままです。
- 自ら変更内容を周知する。既製品ソフトウェアならリリースノートが発行されます。自作ツールは、使う人に何が変わったかを伝えない限り、静かに変更されてしまいます。

これらはどれも地味な作業です。しかし、同じ返金フローを9回も教え直すよりははるかに安上がりです。

![自社開発ソフトウェアの十分なトレーニングを受け、一人でカウンター業務をこなす新人スタッフ](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/f28aca1dcc8a0df0-new-hire-running-shift-alone.png)

## それで、自社開発したソフトウェアのトレーニングは誰が担当するのか？

自分の頭の中にある知識を、新人一人でも追える形に変換するまでは、あなた自身が担当します。そのためにはドキュメント作成の規律を守るか、裏で一貫性を保てるインフラ上にカスタムツールを構築する必要があります。これこそが、Final のようなプロンプトベースのプラットフォームを推奨する秘めた理由です。インターフェースは自社のビジネスに合わせて自在にカスタマイズできますが、その下にあるチェックアウト、返金、レポート機能はプラットフォーム上の全加盟店が使用する共通の文書化された仕組みであり、[チェックアウトフローのインストール](https://finalpos.com/help/install-a-checkout-flow) から [Merchant Hub のトラブルシューティング](https://finalpos.com/help/merchant-hub-faq-troubleshooting) まで網羅する公開ヘルプセンターによってサポートされています。上がカスタムで下が共通基盤であれば、カスタム構成であってもゼロからトレーニングを行う必要はありません。

目安となる原則：**最も新しいスタッフがあなたを探さずに返金処理を行えないのであれば、それはソフトウェアではなく「依存関係」が存在しているだけです。**そして、自作すべきかどうかをまだ検討している段階であれば、まずは [2026年に自社で内部ソフトウェアを開発すべきか？](/blog/build-its-own-internal-software) からご覧ください。

## FAQ

**Q: カスタム開発したソフトウェアの新人研修は誰が担当すべきか？**
A: 開発者が最初のスーパーユーザーをトレーニングし、その後はドキュメントが引き継ぎます。新人が入るたびに開発者本人が直接教える必要があるなら、トレーニングシステムは機能しておらず、離職のたびにその問題が露呈し続けることになります。

**Q: 自社開発ソフトウェアにはどのようなドキュメントが必要か？**
A: 各タスク（会計、返金、締め作業）の短いランブック、タスクごとの簡潔な画面録画、そして変更時にスタッフが把握できる変更履歴です。開発後に書くのではなく、開発中に作成します。

**Q: バス因子（bus factor）とは何か？**
A: システムが利用不能になるまでに離脱しても大丈夫な人数のことです。自給自足のビジネスツールのほとんどは、バス因子が「1」（開発した本人）となっています。

**Q: AIで開発したソフトウェアはスタッフのトレーニングを容易にするか、それとも難しくするか？**
A: 開発は容易になりますが、トレーニングは容易になりません。AIはソフトウェアを書きますがマニュアルは書かないため、ドキュメント作成を開発プロセスの一部として扱わない限り、仕様不明なツールが増殖することになります。

**Q: Final 上で構築された POS は、ゼロから自作したソフトウェアとどう違うのか？**
A: インターフェースは完全カスタマイズ可能ですが、チェックアウト、返金、レポート機能は公開ヘルプセンターでサポートされた共有・文書化済みの仕組みで動作するため、新人のトレーニングをゼロから始める必要がありません。