内製か外注か、そして契約と法務。開発期をやり切るための実務ガイド

検証期でAIを使った試作を動かし、「これはいけるかもしれない」という手応えと、自己資金300万円の中でどこまで作れるかという費用感をすでに掴んだ人に向けたガイドです。試作の作り直しや検証のやり直しはここでは扱いません。ここから先にあるのは、「その試作を、実際に人に使ってもらえる形にする」ための実務です。なお、以降の金額例はすべて自己資金300万円をモデルケースとした試算です。自分の自己資金がこれと違う場合は、同じ計算式に自分の金額を当てはめて置き換えてください（150万円が予算なら開発費配分もおおよそ半分、500万円ならおおよそ1.6倍、という具合です）。

具体的には、まず試作の続きを自分で作り込むのか、開発会社に外注するのかを見極めます（A）。外注する場合は発注の準備を整え（B）、発注先を見極めて契約を結び（C）、開発が進んでいる間の進行管理と、公開に向けた法務・お金の整備を並行して進めます（D）。このガイドの終着点は「公開直前」です。特商法の表示や利用規約が整い、決済の準備ができ、契約書にサインが済んだ状態がゴールになります。

このガイドで扱うのは意思決定の手順であり、個別の契約書の条文や税務の詳細な計算方法ではありません。判断に迷った時点の「次にやること」を、担当のコラムに委ねながら進めます。

まず、自分がどのタイプの読者かによって読む場所を決めてください。 会社員として本業のかたわらでこのサービスを進めている人は、A1〜A17、B1〜B3・B6〜B8、D1〜D17を中心に読めば十分です。A18〜A20（他店舗展開・マルチテナント化・SaaS化）、B4・B5（専門用語が多い業界向け）、D18〜D20（専門職の業法）は自分に該当しないので、見出しだけ確認して読み飛ばしてかまいません。士業や医療職として専門知識をツール化しようとしている人は、A11〜A13・A17を重点的に読み、A18・A19（店舗の他店舗展開）は基本的にスキップしてよい範囲です。実店舗を営みながらDXを進めている人は、A18〜A20が応用編ではなく本編にあたります。A1〜A17は判断の型として一通り目を通しつつ、自分の状況に近い実例が出てくるA18以降を主眼に読んでください。B〜D章でも同様に、専門用語が多い業界向けの内容(B4・B5)や専門職の業法(D18〜D20)には目印を添えているので、自分に関係が薄いと感じたら読み飛ばして構いません。全部を同じ濃度で読む必要はなく、自分のペルソナに近い項目を優先して、それ以外は見出しだけ確認する読み方でも十分にガイドとして機能します(A5・A6のように会社員向けの色が強い項目は、本業を持たない読者にとっては見出しの一行だけ拾えば足りることが多いはずです)。

このガイドの全体地図

• A. 内製か外注かを判断する（A1〜A20）
• B. 発注の準備をする（B1〜B8）
• C. 発注先を見極め、契約する（C1〜C10）
• D. 進行を管理し、法務・お金を整える（D1〜D22）

A. 内製か外注かを判断する

検証期の試作はすでに動いています。ここからの分かれ道は、「その試作を自分の手で公開レベルまで仕上げるか」「どこかで開発会社にバトンタッチするか」です。この判断を先送りにしたまま時間だけが過ぎていく人が実は一番多いので、A1〜A20では判断材料を順番に積み上げ、最後にハイブリッドという第三の道まで示します。自己資金300万円という前提で言えば、内製に振り切れば開発費はほぼゼロで済む代わりに数ヶ月〜半年の時間を投じることになり、全部外注すれば公開までの期間は短縮できる一方で300万円のうち150万円〜250万円程度が開発費に消え、法務・決済・広告に回せる予算が薄くなります。士業や医療職のように決済・セキュリティ・法律が絡む機能(A11〜A13で扱う範囲)を外注する場合は、一般的なCRUD画面の外注より単価が上がりやすく、同じ150万円〜250万円という枠の中でも実装できる機能数は目減りすると考えておいたほうが安全です。この「時間で払うか、お金で払うか」のバランスを見極めるのがA章全体の目的です。なお、A5〜A8は「時間とお金のどちらを優先するか」という同じテーマを、時間の総量(A5)、実行可能性(A6)、学習コストとの比較(A7)、心理的な引っかかり(A8)という4つの異なる角度から順に掘り下げる構成になっています。似た話が続くように感じたら、それは重複ではなく角度の違いだと捉えて読み進めてください。

A1：判断のための5つの質問

内製か外注かは「なんとなく不安だから外注」「お金がないから内製」で決めるものではありません。時間・スキル・お金・リスク・将来の拡張性という5つの軸で機械的に採点すると、感覚に頼らない判断ができます。5つの質問とは、①週にどれだけ開発に使える時間があるか、②必要な技術要素のうち自分でできないものはどれだけあるか、③外注した場合の見積もり額が自己資金のうちどの程度を占めるか、④セキュリティや法律が絡む機能をミスしたときの損失リスクはどれくらいか、⑤将来的に機能を拡張したりチームを増やしたりする可能性があるか、の5点です。それぞれに◯△✕で自己採点し、✕が多いほど外注寄り、◯が多いほど内製寄りという単純な物差しとして使えます。③の質問は、このガイドではモデルケースとして自己資金300万円を例に計算していますが、実際に紙に書き出すときは自分の口座残高や使ってよい上限額に置き換えて計算してください。

やること：

1. 自分の可処分時間（週何時間を開発に使えるか）を紙に書き出す
2. 現在のスキルで実装できる機能とできない機能をリストに分ける
3. 5つの質問に対する回答を一つずつ埋めていく

詳しくは → 内製すべきか外注すべきか、判断のための5つの質問

完了の目安： 5つの質問すべてに自分なりの回答が書けた状態。

A2：内製できる現実的な範囲を見積もる

「全部自分で作れるはず」という楽観と、「エンジニアじゃないから何もできない」という悲観の両方が判断を狂わせます。実際に自分の手で作れる範囲を、機能単位で現実的に線引きすることが次の一歩です。例えば会員登録画面やお知らせ一覧のようなCRUD中心の画面は、AIでのバイブコーディングである程度形になっている人が多い一方、決済連携や検索の絞り込みロジックのような「動くけれど壊れやすい」部分は、公開後にユーザーが増えた途端にバグが表面化しやすい典型パターンです。もう少し具体的に言うと、会員登録画面の「メールアドレスの重複チェック」は試作段階では正常系しか試していないことが多く、同じメールで2回登録しようとしたときにエラーメッセージが出ず無言で失敗する、といった不具合が本番で初めて発覚しがちです。画像アップロード機能も同様に、試作では自分のスマホで撮った数枚の写真しか試していないため、ユーザーが大きすぎるファイルをアップロードした場合の上限チェックや、対応していない拡張子を弾く処理が抜け落ちたまま公開してしまうケースがよくあります。こうした「エラー処理・境界値の考慮が抜けている機能」は、試作の一覧を作る段階で意識的に洗い出しておくと、後の外注判断がスムーズになります。

やること：

1. 試作ですでに動いている機能をリストアップする
2. その機能ごとに「このまま公開レベルにできる」「作り直しが必要」「専門知識が要る」で分類する
3. 分類結果を保存し、外注が必要な部分の初期リストにする

詳しくは → 非エンジニアが自分で作れる現実的な範囲の見積もり方

完了の目安： 試作の機能一覧が3分類に仕分けられている状態。

A3：ノーコードでどこまでできるか

検証期でノーコードツールを使った人も、AIでのバイブコーディングで試作した人も、「ここから先はノーコードの限界を超えるのか」を見極める必要があります。限界を知らずに突き進むと、後から作り直しになるコストが跳ね上がります。よくある限界の例は、無料〜低価格プランのレコード数上限(数千件を超えると有料プランへの移行が必須になる)、外部APIとの連携数の制限、そして独自の決済フローや複雑な権限管理が必要になった瞬間です。これらに当たった機能だけを切り出して外注する、という判断が現実的です。

やること：

1. 現在使っているノーコードツールの料金プランと機能上限を確認する
2. 想定ユーザー数が増えたときにそのツールで耐えられるかを試算する
3. 超えそうな機能があれば、その部分だけを外注候補としてメモする

詳しくは → ノーコードだけで、どこまでの機能が実現できるか

完了の目安： ノーコードで完結できる機能と、限界を超える機能の境界線が明確になっている状態。

A4：スキルギャップを正直に確認する

「あと少し勉強すればできそう」という感覚は、実際にやってみると大抵外れます。会社員として働きながらこのプロジェクトに取り組んでいる人ほど、自分のスキルを客観視する機会が少ないため、ここで一度立ち止まって確認します。

やること：

1. 必要な技術要素（認証、決済、データベース設計など）を洗い出す
2. それぞれについて「今できる」「調べればできる」「専門家でないと難しい」で自己評価する
3. 「専門家でないと難しい」に分類したものは、A11・A12で扱う外注検討リストに移す

詳しくは → 「自分にできるか」を正直に見積もる、スキルギャップの確認方法

完了の目安： 技術要素ごとの自己評価が一覧化されている状態。

A5：時間の見積もり方（トータルの必要週数を出す）

会社員として本業を持ちながら週末や平日夜にこのプロジェクトを進めているペルソナの人にとって、「時間が足りるか」は内製か外注かを分ける決定的な要因です。感覚で「頑張ればできる」と考えるのではなく、実際に使える時間を数字で出すことが重要です。A5では「残りの作業量に対して、そもそも何週間かかるのか」という総量の見積もりを扱い、次のA6では「週末という限られた時間帯で、そのペースを実際に維持できるのか、体調不良や飲み会でゼロになる週をどう織り込むか」という実行可能性を扱います。総量を計算しても、実行できなければ絵に描いた餅になるため、この2つはセットで初めて意味を持つと考えてください。専門職として本業の合間に進めている人や、店舗営業の合間に進めている人にとっても、この「総量→実行可能性」の2段階思考は同じように使えます。士業・医療職の場合は繁忙期(確定申告期、診療報酬改定期など)、店舗経営者の場合は繁忙シーズン(年末年始、地域イベント時期など)を可処分時間からあらかじめ差し引いておくと、A6での補正がより正確になります。

やること：

1. 平日・週末それぞれで開発に充てられる時間を1週間分記録する
2. 過去の検証期の作業時間と比較し、今後も同じペースを維持できるか確認する
3. 残りの開発項目にかかる想定時間を合計し、可処分時間で割って必要な週数を出す

詳しくは → 本業を続けながら開発する時間、どう見積もるか

完了の目安： 「あと何週間で完成しそうか」という数字が出ている状態。

A6：週末開発の現実的なペース（そのペースを維持できるか検証する）

週末だけで開発を進める場合、平日にフルタイムで働ける人と同じ感覚で計画を立てると、ほぼ確実にスケジュールが崩れます。過去に別のアイデアで挫折した経験がある人は特に、ここで無理のないペースを再設定する価値があります。A5で出した「あと何週間」という数字は、体力や集中力が万全な週を前提にした理論値になりがちです。A6ではそこに、飲み会や体調不良、家庭の予定で開発時間がゼロになる週が月に1〜2回は必ずあるという現実の変動を織り込み、理論値を1.3倍〜1.5倍に補正するくらいの余裕を持たせることをおすすめします。例えば「残り10週間で完成」という理論値が出た場合、1.3倍補正なら13週間、1.5倍補正なら15週間を実際の見通しとして公開予定日に反映させる、という使い方です。過去に別のアイデアを週末開発で進めて途中で止まった経験がある人にとっては、この「理論値をそのまま信じて計画を立てて、結局は崩れる」というパターンそのものが今回の失敗の再現になりかねません。A5の理論値だけを見て安心せず、A6の補正を必ずセットで行うことが、同じ轍を踏まないための実務的な予防線になります。

やること：

1. 直近1ヶ月の週末の作業実績（何時間、何を進めたか）を振り返る
2. 平均的な週末の生産性を基準にして、月間で進む機能数の目安を立てる
3. そのペースで公開予定日に間に合うか、間に合わない場合は外注する範囲を広げるか検討する

詳しくは → 週末だけの個人開発、現実的に進むペースはどれくらいか

完了の目安： 「このペースなら公開まであと何ヶ月」という現実的な見通しが立っている状態。

A7：学習コストと外注費を比較する

「自分で勉強すれば無料でできる」という考え方は、学習にかかる時間のコストを見落としています。学習コストを外注費と同じ土俵で比較すると、判断がぐっと明確になります。目安として、決済連携のような技術要素をゼロから学んで実装できるようになるには早くても20〜40時間程度かかることが多く、本業の時給換算(例えば時給3,000円相当と仮置きする)で計算すると6万円〜12万円分の時間コストになります。一方、同じ機能を経験のある開発会社に外注すると、規模にもよりますが数万円〜十数万円程度で収まることも珍しくありません。自己資金300万円のうち、この手の「学べばできるが時間がかかる」機能をいくつ内製するかで、開発全体に使える時間の残量が大きく変わってきます。

会社員としてこの試算をする場合、「本業の時給」という考え方自体がピンとこない人も多いはずです。副業として進めている以上、失っているのは給料ではなく「その週末に他のことをする時間」だからです。その場合は金額換算よりも、「学習に充てる20〜40時間は、週末の可処分時間(仮に週10時間なら2〜4週間分)をまるごと溶かす量だ」という時間の実感で比較したほうが判断しやすくなります。残り10週間で完成させたい計画のうち3〜4週間が一つの技術の習得だけで消えるとしたら、それは「詰む」水準の負荷だと捉えて、外注に振るかどうかを判断してください。

一方、士業・医療職などの専門職は、本業の実質時給が3,000円よりもかなり高いことが多く(弁護士・医師であれば5,000円〜1万円を超えることも珍しくありません)、この仮定のまま計算すると学習コストを過小評価してしまいます。本業の時給が高い専門職ほど、同じ20〜40時間の学習でも機会損失の金額は10万円〜40万円規模に跳ね上がりやすく、外注したほうが総合的に安く済む逆転が起きやすいと考えておいてください。

やること：

1. 未経験の技術を習得するのにかかりそうな時間を見積もる
2. その時間を自分の時給換算(本業の時給や機会損失で構わない。副業で時給換算がピンとこない場合は、可処分時間が何週間分溶けるかで比較してもよい)で金額に置き換える
3. 同じ機能を外注した場合の見積もり額と比較する

詳しくは → 自分で作る場合の「学習コスト」を、外注費と比較する視点

完了の目安： 学習コストと外注費、どちらが総合的に安いかの比較結果が出ている状態。

A8：自分で作れば安いが時間がかかるトレードオフ

内製は金銭的に安く済む一方で時間がかかり、外注は早く進む一方でお金がかかります。この単純なトレードオフを整理する際、すでに投じた時間や労力への未練（サンクコスト（埋没費用））に引きずられていないかも確認しておく必要があります。サンクコストに引きずられているサインは意外とわかりやすく、例えば「もう半年もこのコードを書いてきたから今さら外注するのはもったいない」「せっかく勉強したこの技術を使わないと無駄になる」というように、判断基準が「これから先どちらが合理的か」ではなく「これまで何を投じたか」にすり替わっていたら要注意です。過去に別のアイデアで途中挫折した経験がある人ほど、今回は最後までやり切りたいという気持ちが強く働き、この罠にはまりやすい傾向があります。それでも自分では踏ん切りがつかないと感じたら、判断を一人で抱え込まず、利害関係のない第三者(このプロジェクトに感情移入していない友人や、B1で相談する開発会社そのもの)に「今の状態を客観的に見てどう思うか」を聞いてみるのも有効です。当事者には見えなくなっている「これから先の合理性」を、外の視点が言い当ててくれることがあります。

やること：

1. 「内製で進めた場合」と「外注した場合」のスケジュールを並べて書く
2. 公開が半年遅れることの機会損失（市場の変化、競合の参入リスクなど）を考慮する
3. すでに投じた時間を理由に内製にこだわっていないか、一度冷静に問い直す

詳しくは → 自分で作れば安いが時間がかかる。トレードオフの考え方

完了の目安： 時間とお金、どちらを優先するかの方針が自分の中で定まっている状態。

A9：判断を先延ばしにしてしまう理由

内製か外注かを決めきれずに、両方を中途半端に進めてしまう人は少なくありません。先延ばしにする心理的な理由を知ることで、自分がその罠にはまっていないかを確認できます。典型的なのは「もう少し情報を集めてから」と言いながら同じような記事や動画を何週間も見続けてしまうパターンと、「今月は忙しいから来月決めよう」を毎月繰り返してしまうパターンの2つです。どちらも、判断そのものよりも判断を先延ばしにする行為が習慣化してしまっている状態で、情報や時間が今より増えたところで決断の質が上がるわけではない、という点に自分で気づけるかどうかが分かれ目になります。

やること：

1. これまでの自分の行動を振り返り、判断を避けてきた場面がなかったか思い出す
2. 先延ばしの典型パターン（情報収集をし続ける、決断の期限を設けないなど）に自分が当てはまるか確認する
3. 判断の期限を具体的な日付でカレンダーに入れる

詳しくは → 内製か外注かの判断を、先延ばしにしてしまう理由

完了の目安： 判断を下す期限が決まっている状態。

A10：完璧に自分で作ることにこだわらない

「せっかく試作まで自分でやったのだから、最後まで自分で作りたい」という気持ちは自然ですが、それが判断を歪めることがあります。完璧な内製にこだわらない考え方を持っておくと、後々の判断が楽になります。例えば「認証機能だけは自分で書いたコードを本番で使いたい」というこだわりが、実際にはセキュリティリスクを抱えたまま公開日を先延ばしにしているだけ、というケースは珍しくありません。こだわりを持つこと自体は悪いことではありませんが、それが「サービスを早く安全に世に出す」という本来の目的とぶつかっていないかを、この段階で一度点検しておく価値があります。

やること：

1. 「全部自分で作る」ことへのこだわりが判断に影響していないか自問する
2. 一部を外注しても、サービス全体のオーナーシップは自分にあることを再確認する
3. こだわりを手放してもよい部分（後述するA11〜A13で扱うような専門性の高い部分）を先に決める

詳しくは → 「完璧に自分で作る」にこだわりすぎないほうがいい理由

完了の目安： 「ここは人に任せてもいい」と思える部分が一つ以上見つかっている状態。

A11：セキュリティに関わる部分は外注する

ここからA12・A13は、専門性への感度が高い読者にも直結する内容です。士業や医療職の顧客情報を扱うサービスであれば、なおさらセキュリティの実装を自己流で済ませるリスクは大きくなります。認証まわりや個人情報の保存方法など、セキュリティに直結する部分は、自分の理解が浅いまま実装してしまうと事故につながります。A11ではまず「セキュリティに関わる機能そのものを洗い出し、自分の理解度で線引きする」という切り口を扱い、次のA12は同じ線引きを「法律が関わる機能」という切り口でもう一度行います。セキュリティと法律は重なる部分も多いですが(例えば決済情報の保存はセキュリティであり資金決済法の対象でもある)、それぞれ別の専門家(エンジニア／弁護士)が必要になるため、あえて別ステップとして扱っています。士業・医療職向けに補足すると、セキュリティ実装を含む外注費用は一般的なCRUD機能の外注より高くなりがちで、目安として数十万円単位の上乗せになることも珍しくありません。この上乗せ分を見込んだ上で、次のA12・A13で範囲を絞り込んでいきます。

やること：

1. サービス内でセキュリティに関わる機能（ログイン認証、個人情報の保存、通信の暗号化など)を洗い出す
2. それぞれについて、自分が仕組みを正確に説明できるか自問する
3. 説明できない部分は外注候補としてリストに残す

詳しくは → セキュリティに関わる部分は、なぜ自分で作らないほうがいいか

完了の目安： セキュリティに関わる機能のうち、外注すべき部分が明確になっている状態。

A12：法律が関わる機能は専門家に頼む

決済機能や契約に関わる機能は、単なる技術実装以上に法律の知識が求められます。士業や医療職の読者は、自分の業界の法律には詳しくても、決済や個人情報保護の法律には詳しくないことが多く、ここでの見誤りは事業の存続に関わります。

やること：

1. サービス内で法律が関わりそうな機能（決済、会員契約、返金処理など)をリストアップする
2. それぞれについて、関連する法律（特商法、資金決済法など）に心当たりがあるか確認する
3. 心当たりのない機能は、実装を専門家や実績のある開発会社に任せる方針を立てる

詳しくは → 法律が関わる機能（決済・契約周り）を専門家に頼む理由

完了の目安： 法律が関わる機能について、自作せず専門家に任せる方針が固まっている状態。

A13：専門家に頼むべき機能の見分け方（決済・個人情報を深掘りする）

A11・A12で洗い出した項目のうち、実務でつまずく人が最も多いのが決済と個人情報の取り扱いです。A13ではこの2つに絞り、「なんとなく怖いから全部外注」ではなく、どこまでが自分でも対応可能でどこからが専門家必須なのかの線引きを深掘りします。目安として、Stripeのような決済代行サービスの標準的なチェックアウト機能をそのまま使うだけなら実装のハードルは高くありませんが、独自のポイント制度や分割払い、複数事業者間での売上按分のようなロジックが絡むと専門知識が必要になります。士業や医療職が一人で相談・診療サービスを提供する場合は、課金対象が自分ひとり(自分への相談予約・決済のみ)であることが多く、複数事業者間の按分のような複雑さは発生しにくいシンプルなケースに該当することがほとんどです。一方で、他の専門家にも自分のプラットフォームに参加してもらい、成果報酬を分配するような仕組みを考え始めた瞬間に、独自ロジック側に一気に踏み込むことになります。自分がどちらに近いかをまず見極めてください。個人情報についても、氏名・メールアドレス程度の保有であれば一般的な対策で足りますが、医療情報や資格情報のような機微情報を扱う場合は、A11・A12よりさらに一段厳しい基準で外注先を選ぶ必要があります。

やること：

1. 決済まわりの機能を「決済代行サービスの標準機能で済む部分」と「独自のロジックが必要な部分」に分ける
2. 個人情報の取り扱いを「氏名・メールアドレス程度」と「機微情報を含む」に分ける
3. 独自ロジックや機微情報を扱う部分だけを専門家依頼の対象に絞り込む

詳しくは → 決済・個人情報。専門家に頼むべき機能の見分け方

完了の目安： 専門家に頼むべき機能とそうでない機能の線引きができている状態。

A14：全部自分か全部外注かの間の選び方

ここまでの検討で、多くの人は「全部自分で作る」でも「全部外注する」でもない、その中間のどこかに落ち着くはずです。その中間のどこに位置取るかを決めるのがこのステップです。例えば「画面の8割は自分で作れるが、決済と認証だけはプロに任せる」という組み合わせもあれば、「コア機能だけ自分で握り、それ以外はほぼ外注する」という組み合わせもあり、正解は一つではありません。大切なのは、なんとなく成り行きで境界線が決まるのではなく、A1〜A13で積み上げてきた判断材料に基づいて、自分の言葉で「なぜここまでは自分で、ここからは外注なのか」を説明できる状態にしておくことです。

やること：

1. これまでのステップで作った「自分でできる」「外注が必要」の分類を並べて見比べる
2. 外注が必要な機能の割合が全体の何割になるか計算する
3. その割合に応じて、次のBに進むか、そのまま内製を続けるかを決める

詳しくは → 全部自分で作るか、全部任せるか。その間の選び方

完了の目安： 自分の立ち位置(全内製・一部外注・全外注)が決まっている状態。

外注する範囲がある程度見えてきたら、次は発注先そのものの見極め方に目を向けておくと後の工程がスムーズです。→ 開発会社選びで見るべきポイント

A15：ハイブリッドな進め方を作る

一部だけを外注する「ハイブリッド」な進め方は、費用を抑えつつ専門性が必要な部分の品質を確保できる、多くの個人開発者にとって現実的な落としどころです。ここではその具体的な設計方法を扱います。

やること：

1. 外注する範囲と内製する範囲の境界線を機能単位で明文化する
2. 外注部分と内製部分がどう連携するか(API経由でつなぐなど)を簡単に図示する
3. 境界線の管理者(基本的には自分)を明確にしておく

詳しくは → 一部だけ外注する「ハイブリッド」な進め方の作り方

完了の目安： ハイブリッドで進める場合の役割分担図ができている状態。

A16：核となる機能は自分で・周辺は外注

ハイブリッドで進める場合、多くの人が悩むのが「どこを自分で作り、どこを外注するか」の具体的な線引きです。サービスの核となる部分は自分の理解を深めるためにも自分で持ち、周辺機能は外注するという分担が一つの型として機能します。

やること：

1. サービスの中で「ここが差別化のコア」と言える機能を1〜2個に絞る
2. コア機能は内製、それ以外の周辺機能(通知、管理画面など)は外注候補にする
3. コア機能の実装を優先的に自分のスケジュールに組み込む

詳しくは → 核となる機能は自分で、周辺機能は外注する分担の考え方

完了の目安： コア機能と周辺機能の分担リストができている状態。

A17：専門知識ツールの内製外注判断

士業や医療職などの専門知識をツール化しようとしている読者にとって、「専門知識そのものをどう実装するか」と「システムの土台をどう作るか」は別の問題です。専門知識部分と技術基盤部分、それぞれの内製外注判断を分けて考える必要があります。ここで多くの専門職読者がつまずくのは、「専門知識部分は自分が内容を作る」と決めた後の、その内容を開発会社に伝える工程です。頭の中にある診断ロジックをそのまま口頭で説明しても、開発会社はコードに落とし込めません。まずは自分の判断プロセスを、条件分岐が一目でわかる決定木や、「症状Aかつ既往歴Bなら選択肢C」のような条件分岐表の形に一度書き出し、例外パターン(通常のルールに当てはまらないケース)も別途リストアップしておくことで、初めて開発会社に「実装可能な仕様」として渡せます。

条件分岐表は、専用ツールを使わなくても表計算ソフト(Excel、Googleスプレッドシートなど)の表で十分です。イメージとしては、列に「症状」「既往歴」「年齢」といった判断材料を並べ、右端の列に「出力(選択肢)」を置く形式で、1行が1つの分岐パターンに対応します。例えば「症状=発熱あり／既往歴=なし／年齢=65歳未満→選択肢A(一般的な注意喚起を表示)」「症状=発熱あり／既往歴=糖尿病あり／年齢問わず→選択肢B(受診を強く推奨する表示に切り替え)」のように、2〜3行のサンプルを実際に書き出してみると、自分の頭の中の判断がどこまで単純なルールに落とせて、どこからが「その場の総合判断」で言語化しにくいかが見えてきます。言語化しにくかった行こそが、後述の「例外パターン」としてリストに残すべき部分です。

もう一つ、専門知識の構造化と並行して詰めておきたいのが「そこに法的なグレーゾーンがないか」という論点です。例えば弁護士が作る法律相談ツールであれば、一般的な法律知識を提示するだけの機能なのか、個別の事案に当てはめて結論めいたものを示す機能なのかで、弁護士法72条との距離が変わります。医療職であれば、一般的な健康情報の提供なのか、個々の症状から診断に近い判定を下す機能なのかで、医師法17条との距離が変わります。決定木や条件分岐表を書き出す際、どの分岐が「一般的な情報提供」に留まり、どの分岐が「個別の判断」に踏み込んでいるかを分けてマークしておくと、後述のD18〜D20で業法上の制約を確認する作業がスムーズになります。この構造化の作業自体は技術知識を必要としないため、外注前に自分の手で済ませておく価値があります。

やること：

1. 専門知識が直接反映される部分(診断ロジック、チェックリストの内容など)を洗い出す
2. その判断プロセスを決定木や条件分岐表の形に書き出し、例外パターンも棚卸しする。表計算ソフトで「判断材料の列+出力の列」の形式にし、2〜3行のサンプル行を先に埋めてみると全体像が掴みやすい。書き出す際、どの分岐が「一般的な情報提供」でどの分岐が「個別の判断」に近いかも一緒にマークしておく
3. 技術基盤部分(ログイン、決済、インフラ)は通常の外注判断基準に沿って別途検討する

詳しくは → 専門知識ツールの一部機能、内製と外注どちらに向いているか

完了の目安： 専門知識部分(決定木・条件分岐表として整理済み。「情報提供」と「個別の判断」の分岐マーク済み)と技術基盤部分、それぞれの担当が決まっている状態。

ここから先のA18〜A20は、店舗や地域密着型の事業を営みながら「自分の店のツールを他店にも広げられないか」を考えている読者にとっては、応用編ではなくむしろ本編にあたる3ステップです。すでに他店舗展開が頭の中にあるなら、ここを読み飛ばさずじっくり読んでください。会社員としてこのガイドを読んでいる方や、士業・医療職として専門知識ツールを検討している方にとっては、A18〜A20は基本的に自分に関係のない範囲です。見出しだけ確認して、次のBに進んでかまいません。

A18：他店舗展開できるか判断する

実店舗や地域密着型の事業を営む読者は、自分の店のために作ったツールが「他の店でも使えるのでは」と考えることがよくあります。この可能性を早い段階で判断しておくと、後の設計方針が大きく変わります。

技術面でまず確認したいのは、今のツールが「自分の店専用の前提」に依存していないかです。よくある依存の例として、在庫マスタの商品名やカテゴリが自分の店の品揃えを前提にコード内に直接書き込まれている(いわゆるハードコード)、店の営業時間や定休日が変数ではなく固定値として埋め込まれている、顧客データのテーブルが「1店舗ぶんしか存在しない」前提の構造になっている、といった状態です。こうした依存がある場合、他店に渡す前に「店ごとに設定を切り替えられる」形に作り直す必要があり、これがA19で扱うマルチテナント化の技術的な出発点になります。逆に言えば、店名や商品情報が設定ファイルやデータベースの値として外出しされているなら、他店展開の技術的なハードルはかなり低いということです。まずは自分のツールがどちらの状態かを、A19に進む前に一度確認しておいてください。

他店展開を考えるときに現実的に悩ましいのが、声のかけ方です。相見積もりや開発会社との打ち合わせの中で自分の店名や業態を出してよいか、近隣の商店会や同業者ネットワークに話を持ちかけるとして完全な競合店(同じ商圏で同じ客を取り合う店)にまで声をかけるのは避けたほうがよいか、といった実店舗特有の悩みが出てきます。目安としては、直接の競合ではない別エリア・別業態の店から声をかけ始めると、情報が競合に流れる心配をせずに反応を確かめられます。商工会議所や商店会の集まりに一度顔を出し、「こういうツールを作ったのだが興味がある店はあるか」と軽く尋ねてみるだけでも、実際の需要感がつかめます。声をかける際は、いきなり金額の話をする必要はありません。最初の段階では「こういう課題をこう解決するツールを作った、興味はあるか」という機能紹介とデモ画面を見せる程度に留め、値付けの話は興味を示した相手が出てから個別に詰めるのが現実的です。デモ画面は、自分の店の実データをそのまま見せると生々しすぎることがあるので、店名や数字をダミーに置き換えた説明用の画面を別途用意しておくと声をかけやすくなります。

やること：

1. 今作っているツールが自分の店特有の仕組みに依存していないか確認する(店名・商品情報・営業時間などがコードに直接書き込まれていないか、顧客データが1店舗前提の構造になっていないか)
2. 近隣の商店会や同業者ネットワークで、同じ悩みを持つ店がどれくらいありそうか考える(直接の競合は避け、別エリア・別業態の店から声をかけるのが現実的)
3. 他店展開を視野に入れるかどうかを、この時点で一度仮決めする。仮決めできたら、声をかける際に見せるデモ画面(店名・数字をダミー化したもの)の準備に着手する

詳しくは → 自分の店のために作ったツール、他店にも展開できるか判断する視点

完了の目安： 他店舗展開を目指すかどうかの仮の方針が決まっている状態。

A19：マルチテナント化の基本

他店舗展開を目指す場合、技術的には複数の店舗が同じシステムをそれぞれ独立して使える仕組み、いわゆるマルチテナント化構成が必要になります。これは店舗経営者の読者にとって聞き慣れない概念かもしれませんが、後から追加するより最初に設計しておく方がずっと楽です。具体的なイメージとしては、A店のシフト表や予約台帳がB店のスタッフからは見えないようにする、A店の顧客情報とB店の顧客情報が混ざらないようにする、といった「店舗ごとにデータの壁を作る」設計がマルチテナント化の中身です。自分の店1店舗分として作ったシステムに後から店舗を追加しようとすると、データベースの構造そのものを作り直すことになりがちなので、他店展開の可能性が少しでもあるなら、最初の要件定義の段階で開発会社にその前提を伝えておくことが重要です。

コストの目安としては、最初からマルチテナント前提で設計・実装する場合、1店舗分のシステムだけを作る場合と比べて開発費が2割〜4割程度上乗せになることが多いというのが一つの相場感です。一方、1店舗分として作り切ったあとに後付けでマルチテナント化しようとすると、データベース設計をほぼ作り直すことになり、追加開発期間として当初の開発期間の半分〜同程度(例えば3ヶ月で作ったシステムなら追加で1.5ヶ月〜3ヶ月)を見ておく必要があるケースが珍しくありません。この差が「最初に伝えておく価値」の中身です。自己資金300万円のうち他店展開の可能性がある場合は、最初の見積もり依頼の時点で「将来的に複数店舗展開の可能性がある」と一言添え、上乗せ分を含めた見積もりを取っておくと、後で慌てずに済みます。

技術面の目処が立った先で、実際に踏み出すかどうかを左右するのは、むしろ「貸し出す条件」の生々しい部分です。よくある相場観としては、月額利用料を店舗あたり数千円〜2万円程度のサブスクリプションで設定するケースが多く、初期費用(導入時の設定作業やデータ移行の手間賃)を数万円程度別途もらう形にする例もあります。サポート面では、自分がすべての問い合わせ対応を引き受けると本業を圧迫するため、「操作マニュアルとFAQページを用意し、それでも解決しない場合だけ個別に連絡してもらう」という一次対応の仕組みをA19の段階からセットで検討しておくと、A20のSaaS化を考える段階になってから慌てずに済みます。他店からの利用料をいくらに設定し、サポートをどこまで自分で背負うかは、次のD14で扱う税務上の扱い(その利用料が既存の確定申告にどう乗るか)とも密接に関わるため、あわせて確認しておいてください。

やること：

1. 「店舗ごとにデータを分ける」という要件を、自分の店の場合(例:A店のシフト表がB店から見えないようにする)に置き換えて説明できるようにする
2. 他店舗展開を仮決めした場合、この要件を外注の要件定義に含める
3. マルチテナント化にどの程度追加コストがかかりそうか、発注先候補に概算を聞く(目安:最初から前提に含めるなら+2〜4割、後付けなら当初開発期間の半分〜同程度の追加期間)。あわせて、他店に貸し出す際の月額利用料の相場感(目安:店舗あたり数千円〜2万円程度+初期費用数万円)と、サポートをどこまで自分で担うかの方針も仮決めしておく

詳しくは → 複数店舗で使えるツールにする、マルチテナント化の基本

完了の目安： マルチテナント化が必要かどうかと、その概算コストが把握できている状態。

A20：社内ツールをSaaS化する

社内の業務改善のために作ったツールを、外部の店舗や企業にも使ってもらえるサービス(SaaS)として展開したいと考える読者もいるはずです。社内利用と外部提供では求められる品質基準が変わるため、どこを作り直すべきかの見極めが必要です。他店舗展開(A18・A19)が「同業種の店舗に横展開する」話であるのに対し、SaaS化は業種を問わず外部の利用者に開放する話という違いがありますが、「自分専用に作ったものの前提を壊して他人が使える形にする」という作業の性質は共通しています。

あなたの場合はどちらを読むべきかの目安を先に示しておきます。展開先が「同じ業種の店舗(例えば飲食店主が近隣の飲食店に貸す)」に限られるなら、A18・A19の内容だけで実務上は完結し、A20を読み進める必要はありません。一方、展開先を「業種を問わず誰でも」に広げたい(例えば店舗業務の枠を超えて、まったく異なる業種の会社にも使ってもらいたい)と考え始めた場合にだけ、A20が本編になります。多くの店舗経営者はA18・A19の範囲で十分なので、ここで一度立ち止まって自分がどちらを目指しているかを確認してから読み進めてください。

やること：

1. 社内限定を前提に作った部分(エラー処理の甘さ、UIの簡素さなど)を洗い出す
2. 外部の利用者が使うことを想定して、作り直しが必要な部分に優先順位をつける
3. 作り直しの範囲を次のBの発注準備に反映する

詳しくは → 社内ツールをSaaS化するときに、作り直すべき部分の見極め方

完了の目安： SaaS化にあたって作り直すべき部分のリストができている状態。

B. 発注の準備をする

Aで外注する範囲が決まったら、次は実際に開発会社に相談する準備です。準備が不十分なまま相談に行くと、開発会社側も的確な提案ができず、見積もりの精度も落ちます。B1〜B8では、相談前に整えておくべき資料と伝え方を扱います。なおB4・B5は専門用語が多い業界(士業・医療職など)向けの内容が中心です。一般的なサービスを作る場合はB1〜B3、B6〜B8を中心に読めば十分です。

B1：相談前に決めておきたいこと

開発会社に相談する前に、自分の中で決めておくべきことがいくつかあります。これを曖昧にしたまま相談すると、開発会社側の質問に答えられず、有意義な打ち合わせになりません。

やること：

1. サービスの目的とターゲットユーザーを一文で言えるようにする
2. 予算の上限と希望する公開時期を決める
3. 検証期の試作物(画面や動くもの)を見せられる状態にしておく

詳しくは → 開発会社に相談する前に、決めておきたい3つのこと

完了の目安： 目的・予算・時期の3点が言語化されている状態。

B2：手書きワイヤーフレームを作る

言葉だけでサービスのイメージを伝えるのは難しく、開発会社との認識のずれの原因になります。デザインツールを使いこなせなくても、手書きのワイヤーフレームで十分に意図は伝わります。

やること：

1. 主要な画面(トップ、登録、主要機能の画面)を紙またはシンプルな作図ツールで描く
2. 画面遷移の矢印を書き加え、どの画面からどこに移動するかを示す
3. 描いたワイヤーフレームを写真に撮るかスキャンして共有できる状態にする

詳しくは → 初回相談を実りあるものにする、手書きワイヤーフレームの作り方

完了の目安： 主要画面のワイヤーフレームが一式そろっている状態。

B3：まだ固まっていないアイデアの伝え方

過去に別のアイデアで挫折した経験を持つ読者は特に、「アイデアがまだ固まりきっていない自分が相談してもいいのか」と不安に感じがちです。しかし、固まっていない部分をそのまま正直に伝える技術さえあれば、相談は十分に有意義になります。

やること：

1. 「確定している部分」と「まだ迷っている部分」を分けてメモする
2. 迷っている部分について、開発会社に意見を求めたいことを明示する
3. 打ち合わせの冒頭で「まだ固まっていない部分がある」と先に伝える

詳しくは → まだ固まっていないアイデアを、開発会社にどう伝えるか

完了の目安： 確定部分と未確定部分の仕分けが終わっている状態。

B4：専門分野の業務知識を正確に伝える（士業・医療職・店舗業務も対象）

士業や医療職などの専門職の読者にとって、自分の業界の当たり前は開発会社にとって当たり前ではありません。専門分野の業務知識を正確に伝える工夫をしておかないと、できあがったものが実務に合わないというミスマッチが起きます。これは士業・医療職に限った話ではなく、実店舗を営む読者にも同じことが言えます。例えば「レジ締めの流れ」や「予約台帳の運用」のような日常業務は、店主にとっては当たり前すぎて説明が省略されがちですが、開発会社にとっては初めて聞く業務フローです。「開店前の在庫確認→レジ開設→営業中の会計処理→閉店後のレジ締めと売上集計」のように、時系列に沿って一つひとつの作業を言葉にすることで、開発会社側もどこにシステムを噛ませればよいかをイメージしやすくなります。

複数店舗への展開を考えている店主の場合は、この業務フローの説明にもう一段情報を足しておく必要があります。「自分の店ではこう運用しているが、他店では担当者が違う」「うちはレジ締めを店長が行うが、他店ではアルバイトが行う可能性がある」といった、店舗ごとに運用が変わりうる部分をあらかじめ開発会社に伝えておくと、A19で検討したマルチテナント化の要件定義がスムーズになります。伝え方の例としては、「今は自分の店1店舗の運用ですが、将来的に他店にも同じ仕組みを貸し出すことを考えています。その場合、レジ締めの担当者や在庫の項目は店ごとに違う可能性があるので、店ごとに設定を変えられる形にしておきたいです」のように、現状の業務フローと将来の展開予定をセットで伝えると、開発会社側も設計の初期段階からその前提を織り込めます。

やること：

1. 自分の業務フローを、専門用語を使わずに箇条書きで書き出す
2. その業務フローの中で、システム化したい部分に印をつける
3. 業界特有のルール(規制、慣習など)があれば、それも書き添える。複数店舗への展開を考えている場合は、店舗ごとに運用が変わりうる部分(担当者、確認項目など)も書き添え、将来の展開予定と合わせて開発会社に伝える

詳しくは → 専門分野の業務知識を、開発会社に正確に伝える工夫

完了の目安： 業務フローの説明資料が一つにまとまっている状態。

B5：事前に用語集を渡す

専門用語が多い業界であるほど、開発会社との会話にすれ違いが生まれやすくなります。専門用語が多い業界の読者は、打ち合わせの前に簡単な用語集を渡しておくことで、限られた打ち合わせ時間を本質的な議論に使えます。

やること：

1. 自分の業界で頻出する専門用語を10〜20個リストアップする
2. それぞれに一般の人にもわかる説明を一文で添える
3. 打ち合わせの前日までに開発会社に共有する

詳しくは → 専門用語が多い業界の発注で、事前に用語集を渡すべき理由

完了の目安： 用語集が完成し、開発会社に送付済みの状態。

B6：技術的な説明で誤解しやすい点

プログラミングができない発注者は、開発会社からの技術的な説明を字面通りに受け取ってしまい、後から「そういう意味だったのか」と気づくことがよくあります。特に要件定義の場面で起きやすい誤解のパターンを知っておくと、トラブルを未然に防げます。

やること：

1. 開発会社との会話で出てきた専門用語は、その場で意味を確認する
2. 「できます」という返答の範囲(何がどこまでできるのか)を具体的に聞き返す
3. 打ち合わせ後、自分の理解をメールなどの文章で相手に確認してもらう

詳しくは → エンジニアではない発注者が、技術的な説明で誤解しやすい点

完了の目安： 打ち合わせで出た技術的な説明について、認識のずれがないことを文章で確認できた状態。

B7：簡易RFPの型

要件を整理した文書、いわゆるRFP（提案依頼書）があると、開発会社からの提案の質が大きく上がります。分厚い正式な文書である必要はなく、個人でも書ける簡易な型で十分です。

やること：

1. サービスの目的、主要機能、予算感、希望スケジュールを1枚にまとめる
2. これまでのステップで作った資料(ワイヤーフレーム、業務フロー、用語集)を添付資料としてまとめる
3. 複数の開発会社に同じ資料を配布できる状態にする

詳しくは → 個人でも書ける、簡易RFPの型

完了の目安： 簡易RFPが1つのファイルとして完成している状態。

B8：RFPは必要か、現実的な進め方

RFPを作ることが目的化してしまい、なかなか発注先探しに進めない人もいます。個人開発の規模感では、正式なRFPが必須というわけではなく、現実的な進め方を選ぶことが大切です。

やること：

1. 自分のプロジェクト規模(予算、機能数)に対してRFPがどこまで必要か再確認する
2. 小規模な場合は、B7の簡易RFPで十分か、口頭説明とワイヤーフレームだけで進めるかを判断する
3. 判断した進め方で、次のCの発注先探しに進む準備を整える

詳しくは → RFP（提案依頼書）は必要か。個人発注の現実的な進め方

完了の目安： RFPをどの程度作り込むかの方針が決まり、発注先探しに進める状態。

C. 発注先を見極め、契約する

準備が整ったら、いよいよ発注先を探し、契約に進みます。C1〜C10では、開発会社との打ち合わせで確認すべきこと、危険なサインの見抜き方、そして契約書の読み方までを扱います。ここでの見極めの精度が、開発期全体の成否を左右します。特にC8・C9の契約書まわりは、A章で内製か外注かを迷った時間以上に、後々の事業の存続を左右する局面です。

C1：初回打ち合わせで必ず聞くこと

初回の打ち合わせは、開発会社があなたを評価する場であると同時に、あなたが開発会社を評価する場でもあります。聞くべきことをあらかじめ決めておかないと、その場の雰囲気に流されて重要な確認を忘れてしまいます。士業や医療職として顧客の機微な情報(カルテ相当の情報、訴訟記録に類する情報など)を扱うサービスを発注する場合は、初回打ち合わせの前に秘密保持契約(NDA)を結べるかどうかも、通常の質問リストに追加で確認しておいてください。打ち合わせの中でサービスの詳細な仕組みや想定データ構造を説明する以上、契約前の段階からある程度踏み込んだ話をすることになりますが、NDAなしにその内容を話してよいかは慎重に判断すべき点です。具体的な顧客情報そのもの(実名や実データ)は、NDA締結前の打ち合わせでは出さず、構造やダミーデータの範囲にとどめるのが無難です。

やること：

1. 過去の類似案件の実績を具体的に聞く
2. 開発チームの体制(誰が担当するか、途中で変わることはあるか)を聞く
3. 契約後のコミュニケーション方法と頻度を聞く。機微な情報を扱うサービスの場合は、契約前にNDAを結んでもらえるかもあわせて確認する

詳しくは → 開発会社との初回打ち合わせで、必ず聞くべきこと

完了の目安： 初回打ち合わせで聞くべき質問リストを使って実際に質問できた状態。

C2：提案書で見るべきポイント

複数の開発会社から提案書が届くと、金額の大小だけで比較したくなりますが、それでは適切な判断はできません。提案書の中身を見るべきポイントを押さえておくことが大切です。

やること：

1. 提案書に書かれている機能の範囲が自分の要望と一致しているか確認する
2. スケジュールの根拠(なぜその期間なのか)が説明されているか確認する
3. 見積もり金額に含まれるものと含まれないものの線引きを確認する

詳しくは → 開発会社を見極めるために、提案書で見るべきポイント

完了の目安： 各社の提案書を同じ基準で比較できる状態。

C3：危険な開発会社のサイン

発注後にトラブルになる開発会社には、契約前の段階で見抜けるサインがあることが多くあります。過去に痛い思いをした経験がなくても、これらのサインを知っておくことでリスクを減らせます。具体的な相場感として、着手金は契約金額の30%〜50%程度が一般的な範囲ですが、契約書も交わさない段階で着手金の全額または大半を強く要求してくる場合や、実績を尋ねても具体的な社名・案件名を一切出さずにはぐらかす場合は、警戒したほうがよいサインです。逆に、着手金の分割や出来高払いに柔軟に応じる開発会社は、それだけ自社の実力に自信があるとも言えます。

初めて開発を発注する人にとっては「30%」でも「70%」でもどちらも高く感じられ、判断がつきにくいのが正直なところです。結局いくらが妥当なのか結論が欲しい場合の目安としては、初回の見積もり交渉で「着手金は10〜20%、残りは中間金と納品時払いに分割できないか」とまず提示してみることをおすすめします。この水準を提示して難色を示さない会社であれば、資金繰りに無理のない範囲でリスクを分散できますし、逆にこの提示に強く抵抗して「全額前払いでなければ受けない」と譲らない会社は、それ自体が交渉の初手として警戒材料になります。相場の中央値である30%〜50%にこだわりすぎず、初回発注ではリスクを抑えた10〜20%の提示から交渉を始め、そこから相手の反応を見て着地点を探るという進め方が、初めての発注では現実的です。

やること：

1. 質問への回答が曖昧だったり、都合の悪い質問をはぐらかす様子がないか確認する
2. 契約前に高額な着手金(目安として契約金額の50%を超えるような要求)を強く求めてこないか確認する。初めての発注で相場観がつかめない場合は、まず「着手金10〜20%、残りは中間金・納品時払い」を自分から提示してみて、相手の反応を見ながら交渉する
3. 実績や体制について確認可能な情報を出し渋らないか確認する

詳しくは → 危険な開発会社のサイン。契約前に見抜きたいチェックポイント

完了の目安： 検討している開発会社にこれらの危険なサインがないことを確認できた状態。

C4：規模別の発注先の向き不向き

大手の開発会社、中堅の開発会社、個人開発者。それぞれに向き不向きがあり、自分のプロジェクトの規模や性質に合った相手を選ぶことが重要です。

やること：

1. 自分のプロジェクトの予算規模と必要な体制の大きさを整理する
2. 大手・中堅・個人開発者それぞれのメリットとデメリットを比較する
3. 自分のプロジェクトに最も合いそうな規模感の候補を2〜3社に絞る

詳しくは → 大手・中堅・個人開発者、規模別に見る発注先の向き不向き

完了の目安： 発注先候補が規模感を踏まえて2〜3社に絞られている状態。

C5：相見積もりの取り方

複数の開発会社から見積もりを取る際、条件がバラバラだと単純比較ができません。相見積もりを取るときは、各社に同じ条件を伝えることが前提になります。

やること：

1. B7・B8で作った資料(簡易RFPまたは同等の説明資料)を各社に同じ内容で渡す
2. 見積もり依頼の際に、含めてほしい機能の範囲を明確に伝える
3. 回答期限をそろえて依頼する

詳しくは → 相見積もりを取るとき、条件をそろえるための伝え方

完了の目安： 2〜3社から同じ条件での見積もりが揃っている状態。

見積もりを受け取ったら、金額の大小だけでなく内訳まで踏み込んで比較することが欠かせません。姉妹サイトの解説記事も参考になります。→ 見積書の内訳の読み方

C6：見積書の内訳の読み方

見積書の合計金額だけを見て一喜一憂するのではなく、内訳を読み解くことで、その金額が妥当かどうかを判断できます。自己資金300万円で個人開発を進める場合、開発費に充てられる現実的な上限は150万円〜200万円程度に収まることが多く、残りは決済審査、法務文書の整備、公開後数ヶ月分の運用費に確保しておく必要があります。見積もりがこの上限を大きく超える場合は、機能を削るか、A14〜A16で検討したハイブリッドの内製範囲を広げて外注部分を絞り込む調整が現実的です。

やること：

1. 見積書に記載されている工数(人日・人月)と単価を確認する
2. バッファ(予備費)がどの程度含まれているか確認する
3. 工数の内訳が自分の要望した機能と対応しているか照らし合わせる

詳しくは → 見積書の内訳（工数・単価・バッファ）の読み方

完了の目安： 見積書の内訳を見て、金額の妥当性を自分なりに説明できる状態。

C7：予算を先に伝えるか隠すか

発注前の駆け引きとして、自分の予算を先に開発会社に伝えるべきか、隠して見積もりを取るべきかは意見が分かれるところです。どちらの戦略にもメリットとデメリットがあります。

やること：

1. 予算を先に伝えた場合と隠した場合、それぞれのメリット・デメリットを整理する
2. 自分のプロジェクトの性質(予算に余裕があるか、厳密に決まっているか)を踏まえて戦略を選ぶ
3. 選んだ戦略に沿って、実際の見積もり依頼のコミュニケーションを行う

詳しくは → 予算を先に伝えるべきか、隠すべきか。発注前の駆け引き

完了の目安： 予算開示の戦略を決め、実際の見積もり依頼に反映できた状態。

C8：契約の基本（請負・準委任）

発注先が決まったら、いよいよ契約です。契約形態には主に請負契約と準委任契約の2種類があり、それぞれ責任の所在や進め方が異なります。この違いを理解しないまま契約書にサインするのは避けたいところです。ここで見落としがちなのが、契約書の名目上は請負契約なのに、実際の進め方は準委任契約のように仕様変更を都度受け入れながらなし崩し的に進んでいるケースです。この状態だと、完成責任の所在が曖昧なまま工数だけが膨らみ、いざ納期になっても「まだ完成していない」という水掛け論になりかねません。

自分がこの罠に陥っているかどうかを判定する具体的な目安として、「見積もり確定後に『ここもついでに直してほしい』という依頼を出し、それに対して開発会社が追加見積もりを出さずに無償で対応し続けている状態」が続いていないかを確認してください。1回だけの軽微な修正であれば通常の範囲内ですが、これが毎週のように繰り返され、その都度開発会社が「今回はサービスします」で応じている状態は、契約書の請負という建付けが実質的に崩れているサインです。この状態に心当たりがある場合は、C9の検収基準の確認と合わせて、追加分をどう扱うか(D1で扱うスコープクリープ対策とも直結します)を一度開発会社と明文化しておくことをおすすめします。

やること：

1. 請負契約と準委任契約、それぞれの特徴(成果物責任の有無など)を確認する
2. 自分のプロジェクトの性質(仕様が固まっているか、柔軟に進めたいか)に合う契約形態を考える
3. 開発会社が提示している契約形態と、実際の進め方(仕様変更への対応方針)が一致しているかを確認する。目安として「ついでの追加依頼に開発会社が無償対応し続けている」状態が常態化していないかをチェックする

詳しくは → 個人が開発を発注するときに知っておきたい契約の基本（請負・準委任）

完了の目安： 自分の契約が請負・準委任のどちらか、そしてその意味を理解できている状態。

C9：契約書で必ず確認したい条項

契約書は分量が多く、隅々まで読み込むのは大変ですが、必ず確認しておくべき条項がいくつかあります。特に知的財産権の帰属と検収の基準は、後々のトラブルに直結します。検収基準が「発注者が満足するまで」のような曖昧な表現になっていると、開発会社側はいつまで経っても検収完了を認めてもらえず、逆に発注者側は納品物に不満があっても「契約上は完成している」と押し切られる、どちらの立場からも危険な状態になります。「トップページと主要3機能が仕様書通りに動作すること」のように、検収の合否を客観的に判定できる基準になっているかを必ず確認してください。損害賠償の上限額や、公開後に不具合が見つかった場合の検収後の瑕疵対応期間(一般的には検収後3ヶ月〜1年程度が目安)についても、金額の記載だけでなく実際に機能する条項かどうかを見ておくと安心です。

やること：

1. 成果物の著作権・知的財産権が誰に帰属するかの条項を確認する
2. 検収の基準(何をもって完成とするか、客観的に判定できる書き方になっているか)と検収期間を確認する
3. 保守・瑕疵対応の範囲と期間、損害賠償の上限額を確認する

詳しくは → 契約書で必ず確認したい条項（知的財産権・検収・保守）

完了の目安： 契約書内の重要条項をすべて確認し、疑問点を開発会社に質問し終えた状態。

C10：初めての発注でやりがちな失敗

初めて開発を発注する人が陥りがちな失敗パターンには、共通点があります。相見積もり（相見積もり）の取り方から契約の締結まで、よくある失敗を先に知っておくことで、同じ轍を踏まずに済みます。

やること：

1. よくある失敗パターン(口約束で済ませる、契約書を読まずにサインするなど)を一通り確認する
2. 自分がこれまでのステップで、同じ失敗をしていないか振り返る
3. 契約締結前の最終チェックリストとして活用する

詳しくは → 初めての発注でやりがちな失敗と、避け方

完了の目安： 契約締結前の最終確認が終わり、契約書にサインできる状態。

D. 進行を管理し、法務・お金を整える

契約が済んだら開発が始まりますが、発注者側の仕事はここで終わりではありません。D1〜D22では、開発が進んでいる間の進行管理と、公開に向けて並行して整えるべき法務・お金の実務を扱います。範囲が広いため、進行管理(D1〜D2)、著作権・アカウント資産(D3)、利用規約・プライバシー(D4〜D8)、特商法・決済(D9〜D13)、事業形態・税務(D14〜D17)、専門職の業法(D18〜D20)、その他の法務(D21〜D22)の順に進めます。

D章は項目数が多いため、優先度の目安も示しておきます。「これだけは公開前に絶対」に当たるのはD4(利用規約・プライバシーポリシーの最低ライン)、D9(特商法の表示)、D11・D12(決済サービスの選定と審査)です。これらが欠けていると、サービスをそもそも公開できないか、公開後すぐに法令違反の指摘を受けるリスクがあります。「時間があれば早めに」に当たるのはD3・D14〜D17(著作権・事業形態・税務)で、公開直後でなくても数週間〜数ヶ月以内に対応すれば実務上は間に合うことが多い項目です。D18〜D22は該当する読者(専門職・アプリ配信を予定している人)のみ優先度を上げてください。

D1：追加依頼が積み重なる前に決めること

開発が進む中で、「これも追加でお願いしたい」という要望が次々出てくるのは自然なことです。しかしそれが積み重なると、いわゆるスコープクリープによってスケジュールと予算が際限なく膨らみます。特に週末に時間を割いて開発の進捗を追っている読者は、追加要望のたびに開発会社との調整に時間を取られると、本業との両立が苦しくなります。C8で触れた「ついでの追加依頼に無償対応し続けている状態」に心当たりがある場合は、このD1のタイミングで対応フローを明文化し、悪循環を断ち切ってください。

やること：

1. 契約時点での機能範囲を文書で明確にしておく
2. 追加依頼が発生した場合の見積もり・承認フローをあらかじめ決めておく
3. 追加依頼が出るたびに、それが本当に公開前に必要かを一度立ち止まって判断する

詳しくは → 「これも追加でお願い」が積み重なる前に、決めておくべきこと

完了の目安： 追加依頼が出た際の対応フローが決まっている状態。

D2：納期が遅れ始めたときの確認事項

開発の進行中、納期が遅れ始めることは珍しくありません。焦って開発会社を問い詰めるのではなく、発注者側として確認すべきことを順番に押さえることが、冷静な対処につながります。士業・医療職の読者で、D18の業法確認を業界団体に照会中の場合は、その照会自体が数週間〜数ヶ月かかることがあり、開発の遅延要因になり得ます。遅延の原因を切り分ける際は、開発会社側の事情だけでなく、自分側の照会待ちが公開スケジュールを圧迫していないかもあわせて確認してください。

やること：

1. 遅延の原因(発注者側の要望変更か、開発会社側の事情か)を確認する
2. 遅延によって当初の公開予定日にどの程度影響するかを確認する
3. 今後の進捗確認の頻度を見直す必要がないか検討する

詳しくは → 納期が遅れ始めたとき、発注者側がまず確認すべきこと

完了の目安： 遅延の原因と今後の見通しを開発会社と共有できている状態。

D3：ソースコードの著作権とアカウント資産の帰属

開発を外注した場合、完成したソースコードの著作権が誰のものになるかは、契約書に明記されていなければ発注者に自動的に移るわけではありません。C9で確認した条項の内容を、ここでもう一度実務目線で確認します。著作権と並んで実務上揉めやすいのが、開発に使ったアカウント類の名義です。GitHubなどのコードリポジトリのオーナー権限、ドメイン名の登録者情報、クラウドホスティングサービスの契約者名義が開発会社側のアカウントのまま進んでしまうと、契約終了時にサービスを丸ごと人質に取られたような状態になりかねません。著作権が発注者に譲渡されていても、こうしたアカウント資産が開発会社名義のままでは実質的に乗り換えができないため、契約の早い段階で「誰の名義でアカウントを作るか」を取り決めておくことが重要です。

やること：

1. 契約書内の著作権譲渡に関する条項を再確認する
2. 譲渡されるのがソースコード全体か、一部のライブラリ等は対象外かを確認する
3. GitHubリポジトリのオーナー権限、ドメイン・サーバーのアカウント名義が自分(発注者)であることを確認し、将来他の開発会社に乗り換える場合もソースコード一式を受け取れることを確認する

詳しくは → 開発を外注したとき、ソースコードの著作権は誰のものか

完了の目安： 著作権の帰属とアカウント資産の名義について契約書上の記載を理解し、必要なら修正を依頼できた状態。

D4：利用規約・プライバシーポリシーの最低ライン

サービスを公開する前に、利用規約とプライバシーポリシーを用意する必要があります。ここから先は開発の進行と並行して進める法務・お金の整備です。まずはこの2つの文書に最低限何を書けばよいかを押さえます。

やること：

1. 同業や類似サービスの利用規約・プライバシーポリシーを参考として集める
2. 自分のサービスで扱う情報(氏名、メール、決済情報など)を整理する
3. 最低限必要な項目のチェックリストを作る

詳しくは → 公開前に用意する利用規約・プライバシーポリシーの最低ラインは

完了の目安： 利用規約とプライバシーポリシーに何を書くべきかのチェックリストができている状態。

D5：利用規約に必ず入れる条項

利用規約は自由に書けるものですが、必ず入れておきたい条項がいくつかあります。抜け漏れがあると、後にトラブルが起きたときにサービス側を守る根拠がなくなってしまいます。

やること：

1. 免責事項(サービスの不具合やユーザーの損害についての責任範囲)を明記する
2. 禁止事項(不正利用、迷惑行為など)を具体的に列挙する
3. 退会・アカウント削除の手続きと、それに伴うデータの扱いを明記する

詳しくは → 利用規約に必ず入れておきたい条項（免責・禁止事項・退会）

完了の目安： 利用規約の必須条項がすべて盛り込まれている状態。

D6：プライバシーポリシーに書くべきこと

個人開発のサービスであっても、ユーザーの個人情報を扱う以上はプライバシーポリシーの整備が欠かせません。何をどこまで書くべきかを具体的に確認します。

やること：

1. 取得する個人情報の項目(氏名、メール、決済情報、利用履歴など)を列挙する
2. 個人情報の利用目的を具体的に記載する
3. 第三者への提供の有無(決済代行会社への提供を含む)を明記する

詳しくは → 個人開発サービスのプライバシーポリシー、何をどこまで書くか

完了の目安： プライバシーポリシーの記載内容が固まっている状態。

D7：個人情報を扱う最低限のルール

プライバシーポリシーに書く内容が決まったら、実際の運用でも最低限守るべきルールを押さえておく必要があります。特に、医療職や士業として顧客の機微な情報を扱う可能性のある読者は、通常のサービス以上に慎重な運用が求められる場合があります。例えば弁護士であれば弁護士法上の守秘義務、医療職であれば診療情報の第三者提供に関するガイドラインが、一般的な個人情報保護法の水準に上乗せされる形で関わってきます。こうした業界固有のルールは一般論だけでは判断しきれない領域なので、自分が所属する士業の会(弁護士会、税理士会など)や医療系の職能団体に、システム化にあたって追加で守るべき基準がないかを確認しておくと安心です。問い合わせる際は「守秘義務の対象となる情報をクラウドサービス(具体的なサービス名を挙げる)に保存してよいか」「システム開発を外部の開発会社に委託する場合、委託先にも守秘義務が及ぶことをどう担保すればよいか」「情報漏えいが起きた場合、会則上の報告義務はあるか」のように、Yes/Noで答えられる具体的な質問の形にしておくと、職能団体側も的確に回答しやすくなります。

職能団体への確認と並行して詰めておきたいのが、開発期特有の悩みである「テストフェーズで開発会社に何を見せるか」です。決済や予約のフローを開発会社と一緒に確認する段階では、必ず一度は実際に近いデータでテストする局面が訪れます。ここで実在の顧客の氏名・カルテ内容・訴訟記録をそのまま使ってしまうと、それだけで守秘義務違反や個人情報保護法上のリスクを抱えることになりかねません。実務上の心構えとしては、テスト環境では「山田太郎」のような架空の氏名と、症状・案件内容も実在しない設定を使ったダミーデータで通しきることを原則にし、どうしても実データでの検証が必要な場面(例えば大量データでの検索速度確認など)が出た場合は、氏名やカルテ内容などの機微な項目だけをダミー値に置き換える処理(マスキング)をしてから開発会社に渡す、という一段階を必ず挟んでください。C1で確認したNDAの締結は、この段階での話し合いを安全に行うための前提にもなります。

やること：

1. 個人情報へのアクセス権限を持つ人(自分以外に開発会社の担当者などがいれば)を整理する
2. 個人情報を保存するサーバーやサービスのセキュリティ設定を確認する
3. 自分の業界特有の情報保護に関するルール(守秘義務、診療情報の提供制限など)があれば、所属する職能団体や業界団体に、具体的な質問の形(保存先クラウドの可否、委託先への守秘義務の担保方法、漏えい時の報告義務の有無など)で確認する。あわせて、開発会社とのテストフェーズでは実データではなくダミーデータを使う方針を決め、やむを得ず実データに近いものを使う場合は氏名・機微情報をマスキングしてから渡す運用にする

詳しくは → 個人情報を扱うサービスで、最低限守るべきルール

完了の目安： 個人情報の取り扱いに関する最低限のルールが運用に反映されている状態。

D8：情報漏えい時の対応方針

個人開発のサービスであっても、情報漏えいが起きる可能性はゼロではありません。起きてから慌てないために、対応方針をあらかじめ用意しておきます。

やること：

1. 情報漏えいが疑われた場合の初動(影響範囲の確認、開発会社への連絡)を決めておく
2. ユーザーへの通知が必要になった場合の連絡手段を確認する
3. 対応方針を簡単なメモとして手元に残しておく

詳しくは → 個人開発でも用意しておきたい、情報漏えい時の対応方針

完了の目安： 情報漏えい発生時の初動対応がメモとして準備できている状態。

D9：特商法の表示

有料サービスを提供する場合、特定商取引法に基づく表記に基づく表示が必要です。何を書けばよいか、最低限の項目を押さえておきます。物販の通信販売と違い、SaaSやデジタルコンテンツのサブスクリプションでは独自につまずきやすいポイントがあります。一つは「役務の提供時期」の書き方で、モノを発送する通販とは異なり、契約成立と同時にオンラインでサービス利用が開始される旨を明記する必要があります。もう一つは返金特約で、月額課金の途中解約時に日割り返金するのか、それとも「返金不可、ただし解約後は次回請求が発生しない」という扱いにするのかを明確にしておかないと、後述のD13のサブスク運用ルールと矛盾する記載になりがちです。この2点はD13と合わせて一度に整合性を確認しておくと手戻りがありません。

士業や医療職が個別相談やチャット相談のような役務を提供する場合は、もう一つ確認しておきたい論点があります。それは、提供している役務が「一般的な情報提供サービス」なのか「個別コンサル的な役務」なのかによって、特商法上の記載内容(役務の内容の説明の仕方など)が変わりうるという点です。この「情報提供」と「個別の判断・助言」の境界線そのものは、後述のD19でより詳しく扱います。特商法表示を書く段階でこの境界がまだ自分の中で整理できていない場合は、先にD19を読んでから戻ってくると二度手間になりません。

やること：

1. 特商法の表示に必要な項目(事業者名、連絡先、価格、支払い方法など)を確認する
2. 役務の提供時期の書き方と返金特約の内容を、D13で決めるサブスク運用ルールと矛盾しないように整理する
3. サービスサイト内に特商法表示ページを設置する。個別相談・コンサル的な役務を提供する場合は、D19の「情報提供」と「個別の判断」の区分を先に確認してから表示内容に反映する

詳しくは → 有料サービスに必要な特定商取引法の表示、何を書けばいいか

完了の目安： 特商法表示ページの内容が確定している状態。

D10：特商法で住所を公開したくない場合

個人事業主としてサービスを運営する場合、特商法表示に自宅住所を公開することへの抵抗を感じる人は多いはずです。この対処法を知っておくと、公開への心理的なハードルが下がります。

やること：

1. 住所公開を避けられる制度上の対処法があるか確認する
2. バーチャルオフィスなど代替手段を使う場合のコストと注意点を確認する
3. 自分にとって現実的な対処法を選び、特商法表示に反映する

詳しくは → 個人事業主が特商法表示で住所を公開したくない場合の対処法

完了の目安： 住所公開の方針が決まり、特商法表示に反映できる状態。

D11：決済サービスの選び方

有料サービスを展開する場合、決済サービスの選定が必要です。Stripeをはじめとする複数の選択肢があり、何を基準に選ぶべきかを確認します。

やること：

1. 候補となる決済サービスの手数料体系を比較する
2. サブスクリプション課金や都度課金など、自分のサービスの課金形態に対応しているか確認する
3. 開発会社に、選んだ決済サービスとの連携実績があるか確認する

詳しくは → 個人が決済機能を導入するとき、何を基準に選ぶべきか

完了の目安： 決済サービスの選定が完了し、開発会社に実装を依頼できる状態。

D12：決済審査の準備

決済サービスを導入するには、多くの場合審査が必要です。審査に通るために、事前にどのような準備が必要かを確認しておきます。エスクローサービスのような仕組みを使う場合は、その説明も審査で求められることがあります。

やること：

1. 決済サービスの審査に必要な書類(本人確認書類、事業内容の説明など)を確認する
2. サービスサイトに特商法表示や利用規約など審査で求められる情報が揃っているか確認する
3. 審査の想定期間を確認し、公開スケジュールに余裕を持たせる

詳しくは → 決済サービスの審査に通るために、事前に準備しておくこと

完了の目安： 決済審査に必要な準備が整い、審査を申請できる状態。

D13：サブスク課金の運用ルール

サブスクリプション型の課金を導入する場合、MRR（月次継続収益）やチャーンレート（解約率）といった指標を意識した運用ルールをあらかじめ決めておくと、公開後の管理がスムーズになります。

やること：

1. 課金サイクル(月次・年次)と解約の受付方法を決める
2. 無料トライアル期間を設ける場合、その期間と自動課金開始のタイミングを決める
3. 解約時のデータ保持期間や返金対応の方針を、D9の特商法表示の返金特約と一致させて決める

詳しくは → サブスク課金を導入するときに決めておくべき運用ルール

完了の目安： サブスク課金の運用ルールが一式決まっている状態。

D14：個人事業か法人か

サービスを立ち上げるにあたり、個人事業のまま進めるか法人化するかは多くの人が悩むポイントです。自己資金300万円前後で立ち上げる規模感であれば、必ずしも最初から法人化が必要というわけではありません。すでに実店舗を個人事業や法人として経営している読者の場合は、新しいサービスを「既存の屋号の中の新規事業」として扱うのか、それとも別会社・別屋号として切り出すのかという論点が加わります。既存事業と会計を分けたい、既存事業の負債やリスクを新サービスに波及させたくないという場合は、たとえ小規模でも別法人化や個人事業の開業届の追加を検討する価値があります。逆に、既存店の集客と一体で運営するなら、既存の屋号のまま新規事業として届け出るほうがシンプルです。他店舗への貸し出しでA19のような月額利用料が発生する場合、その利用料は多くのケースで既存の事業所得と合算して扱われます(雑所得として切り離す必要が生じるかどうかは所得の継続性や規模によるため、金額が大きくなってきたら税理士に確認してください)。まずは「新サービスの収入も含めて一つの確定申告にまとめる」のが原則になる、とだけ押さえておけば実務上は十分です。

士業(税理士・行政書士・社会保険労務士など、すでに個人事業主として資格業務を開業している場合が多い)の読者にとっても、考え方の骨格は実店舗の場合と同じです。「資格業務の事務所」という既存の屋号の中で新サービスを新規事業として扱うか、別法人・別屋号として切り出すかという二択になります。資格業務の収入とツール事業の収入を合算して確定申告する(既存の屋号内で扱う)場合、ツール事業が初年度赤字であっても資格業務の黒字と損益通算されるため、税負担が軽くなりやすいという実店舗と同じメリットが働きます。逆に、ツール事業を法人として切り出す場合は、資格業務側の収益とは損益通算ができなくなる点、そして法人化に伴い社会保険への加入義務が生じ得る点も、実店舗のケースとまったく同じ論点として当てはまります。

ただし、別法人化にはメリットだけでなくデメリットもあります。代表的なのは、新サービスが赤字の間、既存店(または既存の資格業務)の黒字と損益通算(黒字と赤字を相殺して税負担を軽くすること)ができなくなる点です。個人事業のまま「既存の屋号の中の新規事業」として扱えば、新サービスが赤字でも確定申告上は既存の所得と合算されるため、初年度から税負担が軽くなることがあります。また、法人化すると社会保険への加入義務が生じる場合があり、これまで発生していなかった保険料の事業主負担分が新たなコストとして乗ってきます。既存事業と切り離すメリット(リスク遮断、会計の明確化)と、これらのデメリット(損益通算不可、社会保険コスト)を天秤にかけて判断する必要があるため、迷う場合は顧問税理士(いない場合はD16で扱う税務知識を踏まえた上で、早めに税理士に相談すること)に相談することをおすすめします。

やること：

1. 個人事業と法人、それぞれの手続きの手間とコストを比較する
2. 想定している売上規模や取引先(法人相手かどうか)を踏まえて検討する
3. すでに別事業(実店舗、あるいは士業・医療職の資格業務など)を営んでいる場合は、既存事業の中でやるか別事業として切り出すかも合わせて検討する。他店舗展開や複数の専門家への貸し出しで利用料収入が発生する場合、その収入が既存の確定申告に合算されるのが原則になる点も確認する。切り出す場合は損益通算ができなくなる点、社会保険コストが増える可能性がある点も踏まえて現時点での判断を一度仮決めする

詳しくは → 個人事業か法人か。サービス立ち上げ時の判断ポイント

完了の目安： 個人事業か法人か、公開時点での方針が決まっている状態。

D15：法人化するタイミング

個人事業として始めた場合でも、事業が成長すれば法人化を検討するタイミングが来ます。公開前の今のうちに、その目安を知っておくと将来の判断がスムーズです。

やること：

1. 法人化を検討する一般的な目安(売上規模、取引先からの要望など)を確認する
2. 自分のサービスが将来その基準に達しそうか、大まかなイメージを持っておく
3. 法人化のタイミングの目安を、今後の運用計画のメモに残しておく

詳しくは → 個人事業で始めたサービス、法人化するタイミングの目安

完了の目安： 法人化を検討するタイミングの目安がメモとして残っている状態。

D16：副業の税務知識

会社員として働きながらサービスを立ち上げる読者にとって、副業としての税務知識は避けて通れません。最低限押さえておくべきポイントを確認します。特に気になるのは「会社に副業がバレるか」という点だと思いますが、これは主に住民税の通知経路に関わります。副業の所得を確定申告する際、住民税の徴収方法を「自分で納付(普通徴収)」に選択すれば、給与天引き(特別徴収)にならないため、会社の給与担当者に副業分の住民税額が伝わりにくくなります。実際の操作としては、確定申告書(第二表)の「住民税・事業税に関する事項」欄に「自分で納付」を選ぶチェック欄があるので、そこにチェックを入れて提出する形になります(申告書の様式は年度によって多少変わることがあるため、実際に記入する際は当該年度の様式で欄の名称を確認してください)。

ただし自治体の運用によっては、この「自分で納付」を選んでも給与所得と合算されて特別徴収の通知が会社に届いてしまうケースがあり、これが不安を消しきれない一番の理由です。合算されやすいと言われる典型的なパターンは、副業が給与所得(アルバイト等)である場合(給与所得同士は制度上合算されるルールの自治体が多い)と、自治体側の処理が住民税の申告書とマイナンバー情報の突合の過程で「普通徴収」チェックを見落とす、あるいはシステム上の運用で反映されないケースです。今回のような個人開発サービスの所得は事業所得または雑所得に当たるため、給与所得同士の合算パターンには通常該当しませんが、それでも自治体側の実務ミスは起こり得るため、確定申告書を提出した後、5月〜6月頃に会社から届く住民税決定通知の内容に変化がないかを一度自分で確認しておくと安心です。心配な場合は、確定申告の前に自分が住む市区町村の住民税課(役所の税務担当窓口)に直接電話し、「副業所得分の住民税を普通徴収にしたいが、給与所得分と分離して処理されるか」を確認しておくと、通知が届いてから慌てずに済みます。

もう一つの目安が確定申告のラインで、給与所得者の場合、副業の所得(収入から経費を引いた額)が年間20万円を超えると確定申告が必要になります。

やること：

1. 副業の所得区分(雑所得・事業所得など)の基本を確認する
2. 確定申告が必要になる所得の目安(給与所得者は副業所得が年間20万円超で申告要)と、住民税の徴収方法(確定申告書第二表の「住民税・事業税に関する事項」欄で「自分で納付」を選べるか)を確認する。不安な場合は確定申告前に自分の自治体の住民税課へ直接電話し、普通徴収が給与所得分と分離して処理されるか確認しておく
3. 経費として計上できそうな支出(開発費、決済手数料など)を記録しておく習慣をつける

詳しくは → 副業でサービスを立ち上げた場合の、最低限の税務知識

完了の目安： 副業の税務に関する最低限の知識が身についている状態。

D17：インボイス制度との関わり

インボイス制度は個人のサービス立ち上げにも関わってきます。特に法人の取引先を想定している場合は、早めに理解しておく必要があります。

やること：

1. インボイス制度の基本的な仕組みを確認する
2. 自分のサービスの取引先(個人向けか法人向けか)によって影響の大きさが変わることを確認する
3. 適格請求書発行事業者になるかどうかを検討する

詳しくは → インボイス制度、個人のサービス立ち上げにどう関わるか

完了の目安： インボイス制度への対応方針が決まっている状態。

D18：業法上の制約確認

士業や医療職などの専門職がサービスを作る場合、その業界特有の業法上の制約が関わってくることがあります。専門職の読者にとって、これは最も注意が必要な領域の一つです。よくある論点を一般論として挙げると、弁護士以外の者が報酬を得て法律事務を取り扱うことを規制する弁護士法72条(非弁行為規制)、行政書士の独占業務との線引きに関わる行政書士法、医師以外による医業類似行為を規制する医師法17条、医薬品的な効能効果を標榜する表現を規制する薬機法の広告規制などが典型例です。自分のサービスがこうした規制の対象になり得るかどうかは業種と提供内容によって大きく変わるため、ここではあくまで「どの法律が関係し得るか」の見当をつける材料として捉え、実際の適法性の判断は必ず自分の業界団体や顧問弁護士・行政書士に確認してください。確認を依頼する際は、「このサービスは○○という機能で、利用者から個別の状況(症状・案件の詳細など)を入力してもらい、AIやロジックが選択肢を提示する。これは医師法17条(または弁護士法72条)の規制対象になり得るか」のように、機能の具体的な動作と気になっている条文をセットで質問すると、一般論ではなく自分のケースに即した回答を得やすくなります。A17で作った決定木・条件分岐表があれば、そのまま質問の添付資料として使えます。

照会にかかる時間の見込みも、公開スケジュールを立てるうえで重要です。弁護士会や医師会のような職能団体への照会は、内容によって数週間で回答が来ることもあれば、委員会での検討を要する場合は数ヶ月かかることもあります。D2で扱った「納期が遅れ始めたときの確認事項」は開発会社側の遅延を主に想定していますが、この業法照会の待ち時間が公開日のボトルネックになるケースも実務上は多いため、A17の決定木・条件分岐表が完成した時点で、開発の契約と並行してできるだけ早く照会を出しておくことをおすすめします。照会の返答を待っている間に開発だけが先に完成してしまうと、いざ公開直前になって機能の一部を止めざるを得ない事態にもなりかねません。

やること：

1. 自分の資格・業種に関連する業法(弁護士法72条、行政書士法、医師法17条、薬機法の広告規制など)に心当たりがあるか確認する
2. サービスの内容(情報提供なのか、個別相談に応じるのかなど)によって制約が変わることを確認する
3. 不明な点は、A17で作った決定木・条件分岐表を添えて、「この機能はこの条文の規制対象になり得るか」という具体的な質問の形で、所属する業界団体(弁護士会、医師会など)や顧問弁護士・行政書士に確認する。回答まで数週間〜数ヶ月かかる場合があるため、開発の契約と並行してできるだけ早く照会を出しておく

詳しくは → 士業・専門職がサービスを作る際に確認すべき業法上の制約

完了の目安： 自分の業界に関わる業法上の制約について、確認すべき事項がリスト化できている状態。

D19：資格が必要な業務とアプリの境界線

専門知識をアプリ化する際、「どこまでがアプリで提供してよい情報提供で、どこからが資格保有者でなければ行えない業務なのか」という境界線は、慎重に見極める必要があります。この境界を越えると、無資格での業務提供とみなされるリスクがあります。目安として、一般的な知識や統計情報を提示するだけの「情報提供」と、個々の利用者の状況に当てはめて結論を出す「個別の判断・助言」の間には明確な違いがあり、後者に近づくほど資格保有者本人の関与が必要になりやすいと考えられています。

具体的なイメージを対比すると分かりやすくなります。「一般的な情報提供」の典型例は、例えば法律分野であれば「離婚時の財産分与の一般的な考え方や、法律上の原則を説明する」、医療分野であれば「発熱時に一般的に見られる症状の経過や、市販薬の一般的な使用上の注意を説明する」というように、誰に対しても同じ内容を提示するもので、利用者個別の状況を入力させてそれに応じた結論を出す機能は含みません。一方、「個別の判断・助言」に近づく例は、法律分野であれば「あなたが入力した離婚原因と婚姻期間、財産の内訳から、財産分与の見込み額を算出して提示する」、医療分野であれば「あなたが入力した症状・年齢・既往歴から、受診すべきかどうかを判定して個別に回答する」というように、入力された個別の事情に基づいて具体的な結論やアドバイスを出す機能です。前者は多くの場合セーフな情報提供に留まりますが、後者に近づくほど、実質的に資格保有者が行う個別相談・診断に近づき、業法上のリスクが高まります。

この境界線は、A17で専門知識を決定木・条件分岐表に落とし込んだ際に一緒にマークした「情報提供」「個別の判断」の仕分けとそのままつながっています。A17の段階で仕分けが済んでいれば、D19ではその仕分けを見直しながら、どの分岐が業法上グレーかを確認する作業になるはずです。ただしこの線引きは業種・提供内容によって個別性が高く、一般論だけで安全側に倒しきれない領域でもあるため、境界が曖昧だと感じた機能は必ず弁護士や所属する業界団体に個別に確認する対象として扱ってください。

やること：

1. 提供しようとしている機能を「一般的な情報提供」と「個別の判断・助言」に分類する(A17で作った決定木・条件分岐表の仕分けをそのまま活用する。目安として、誰に対しても同じ内容を返す機能は前者、利用者個別の入力に基づいて結論を出す機能は後者に近い)
2. 個別の判断・助言に該当しそうな機能があれば、それが資格保有者の業務範囲に当たらないか、顧問弁護士や業界団体に確認する
3. 境界線が曖昧な機能については、専門家への確認が必要な項目としてメモに残す

詳しくは → 資格が必要な業務を、アプリ経由で提供してよいかの境界線

完了の目安： サービス内の機能が「情報提供」と「個別助言」のどちらに当たるか整理できている状態。

D20：アドバイス系サービスの免責表現

専門知識を活かしたアドバイス系のサービスを提供する場合、免責表現を適切に入れておくことがトラブル予防につながります。免責表現は法的な効力を過信せず、あくまでユーザーへの適切な期待値設定として位置づけます。

やること：

1. サービスが提供する情報が「一般的な情報」であり「個別の専門的助言に代わるものではない」ことを明記する箇所を決める
2. 重要な判断が必要な場面では、専門家への相談を促す文言を入れる
3. 免責表現の内容について、可能であれば顧問弁護士など専門家に確認する

詳しくは → アドバイス系サービスに入れておきたい免責表現の考え方

完了の目安： 免責表現の文言が用意され、サービス内の適切な箇所に配置する準備ができている状態。

D21：商標調査の基本

サービス名を決める前に、その名前がすでに商標登録されていないかを確認しておく必要があります。公開後に名前を変更することになれば、大きな手戻りになります。

やること：

1. 検討しているサービス名で商標検索を行う
2. 同じ業界・分野で似た名前がすでに使われていないか確認する
3. 気になる点があれば、商標に詳しい専門家(弁理士など)への相談を検討する

詳しくは → サービス名を決める前に確認したい商標調査の基本

完了の目安： サービス名の商標上のリスクを確認し終えた状態。

D22：アプリストア審査の基本

スマホアプリとしてサービスを配信する場合、各ストアの審査を通過する必要があります。ここでのアプリストア審査の基本を押さえておくと、公開直前になって慌てずに済みます。

やること：

1. 配信予定のストア(App Store、Google Playなど)の審査ガイドラインの概要を確認する
2. 審査で指摘されやすいポイント(プライバシーポリシーの記載、決済方法など)を事前にチェックする
3. 審査にかかる期間を確認し、公開スケジュールに反映する

詳しくは → スマホアプリを配信する場合に確認すべきストア審査の基本

完了の目安： アプリストア審査に向けた事前チェックが完了している状態。

開発期の完了条件

印刷して使える形式のチェックリストとして、開発発注前チェックリスト、自分でやるか外注するか判断チェックリスト、公開前・法務とお金チェックリストも用意しています。

• 内製か外注か、あるいはハイブリッドかの方針が決まり、必要なら発注先との契約が締結されている
• 開発の進行管理の体制(追加依頼の扱い、遅延時の確認事項)が機能している
• 利用規約・プライバシーポリシー・特商法表示が用意され、サービスサイトに設置できる状態になっている
• 有料サービスの場合、決済サービスの選定と審査対応が完了している
• 個人事業か法人か、税務・インボイス制度への対応方針が決まっている
• 士業・医療職など専門職の場合、業法上の制約と免責表現の確認が済んでいる
• サービス名の商標リスク確認、必要であればアプリストア審査への準備が済んでいる

次のステップへ

契約・法務・お金の整備が終わり、あとは公開のタイミングを迎えるだけになったら、開発期は完了です。次のガイドでは、最初のユーザーをどう獲得するか、公開後に集まってくるフィードバックをどう受け止めて次の一手につなげるか、そして毎月かかり続ける運用費をどう管理し、継続するか撤退するかをどんな基準で判断するかを扱います。ここまでで整えてきた土台の上で、いよいよサービスを世の中に出す段階に進みます。