「こんなアプリがあれば、今の業務がもっと楽になる」
「お客様に質問へ答えてもらい、その結果に合わせて提案内容を自動表示したい」
「社内で使っているExcelや紙の入力作業を、簡単なWebアプリにできないだろうか」
このようなアイデアを思いついたとき、多くの方が次に考えるのが開発会社への相談です。
しかし、そこで難しい問題が発生します。
自分が作りたいものを、開発会社へ正確に説明できないのです。
「入力フォームがあって、その内容を判定して、結果を表示するようなシステムです」と説明することはできても、実際にどのような画面が必要なのか、何を入力するのか、結果画面に何を表示するのか、データを保存するのか、管理者は何を確認したいのかまで聞かれると、急に答えられなくなることがあります。
そこで活用したいのが、AIによる発注前のアプリ試作です。
重要なのは、AIを「開発会社の代わり」にすることではありません。
AIを使って、まず自分が考えているものを簡単な形にしてみるのです。
実際に操作してみると、「この機能はいらなかった」「ここは絶対に必要だった」「この操作では使いにくい」「管理者側にも画面が必要だ」といったことが見えてきます。
つまりAIによる試作は、アプリを完成させるためだけの手段ではなく、頭の中にあるアイデアを、発注できるレベルまで具体化するための手段として利用できます。
この記事では、アプリ開発を外注する前にAIで試作品を作る意味と、どこまで作ればよいのか、試作から何を確認すればよいのかを具体的に解説します。
アプリ開発は外注する前にAIで試作できる
結論からいうと、現在はアプリのアイデアを簡単な試作品として先に形にしてみることが以前より容易になっています。
ここでいう試作品とは、正式な本番システムではありません。一般にプロトタイプと呼ばれるもので、入力画面、ボタン、簡単な画面遷移、入力内容に応じた処理、結果表示など、アプリの主要な動きを確認できる状態を指します。
本格的な開発では、セキュリティ、認証、データベース、権限管理、バックアップ、外部サービス連携、監視など、非常に多くの要素を考える必要があります。しかし発注前の段階で、そこまですべて作る必要はありません。
最初の目的は、「自分が考えているアプリは、実際にはどのようなものなのか」を確認することです。
最初から完成品を作る必要はない
AIでアプリ開発ができると聞くと、「それなら自社だけで完成まで作れるのではないか」と考えるかもしれません。もちろん、自社だけで開発できるケースもあります。しかし、それを最初の目標にする必要はありません。
試作段階では、完成度よりも発見できることの多さが重要です。
たとえば顧客向けの診断アプリを考えているとします。最初は、質問に回答する、回答内容を判定する、診断結果を表示する、という3つの動きだけでも十分です。
この状態で一度触ってみると、「質問数が多すぎる」「一問ずつ表示した方が答えやすい」「戻るボタンが必要だ」「結果画面だけではなくPDFで持ち帰りたい」など、紙に仕様を書いているだけでは分からなかった問題が出てきます。
これこそが試作品を作る価値です。
プロトタイプで確認したい3つのこと
- 1.どのような画面が必要なのか
入力画面、結果画面、管理者画面など、誰がどの画面を見るのかを確認します。 - 2.利用者がどの順番で操作するのか
何を最初に入力し、次に何を行い、最後にどのような結果が返ってくるのかを確認します。 - 3.入力した情報がどう処理されるのか
入力内容を保存するのか、判定するのか、AIへ渡すのか、別のシステムへ連携するのかなどを整理します。
この3つが見えてくるだけでも、開発会社との会話はかなり具体的になります。

AI開発は「外注の代替」ではない
この記事で最も伝えたいのは、この点です。AIでアプリを作ることと、開発会社へ依頼することを対立させる必要はありません。
「AIで内製するか」「開発会社へ外注するか」という二択ではないのです。
むしろ、AIで試作する → 必要な機能を整理する → 専門性が必要な部分を開発会社へ依頼する、という使い方ができます。
これまでアプリ開発では、発注者が頭の中のイメージを文章や打ち合わせで説明し、それを開発者が仕様へ落としていく方法が一般的でした。しかし、言葉だけでは認識のズレが発生しやすくなります。
一方、簡単でも動くものがあれば、「この画面のここを変えたい」「このボタンを押した後は、この画面に移動してほしい」「この項目は不要だった」と、具体的な話ができます。
AIによる試作は、開発会社を不要にするためではなく、開発会社とのコミュニケーションを具体化するためにも使えるのです。
なぜ文章だけでアプリの要件を決めるのが難しいのか
アプリを作った経験がない人にとって、完成する前にすべての仕様を決めるのは簡単ではありません。なぜなら、人間は実際に使ってみなければ気づけないことが非常に多いからです。
「欲しい機能」と「必要な機能」は違う
アプリ開発を考え始めると、さまざまな機能を追加したくなります。たとえば社内向けの業務管理アプリなら、ログイン、社員ごとの権限、検索、絞り込み、CSV出力、PDF出力、メール通知、チャット通知、ダッシュボード、グラフ、管理者画面など、思いつく機能はいくらでもあります。
しかし、本当に必要かどうかは別問題です。実際に簡単な試作品を触ってみた結果、「一覧があれば十分だった」「グラフは結局見なかった」「通知はメールだけでよかった」となることもあります。
反対に、「これは不要だと思っていたけれど、実際には必要だった」というケースもあります。つまり、機能の必要性は会議室の中だけで決めるより、一度使ってみた方が判断しやすいのです。
実際に触らなければ分からないことがある
たとえば入力フォームひとつでも、実際に操作すると多くのことが分かります。入力項目が20個あるフォームを作ったとします。仕様書を見ているだけなら、「必要な情報だから20項目で問題ない」と判断するかもしれません。
しかしスマートフォンで実際に入力すると、「長すぎる」と感じる可能性があります。すると、「本当に最初から必要なのはどの情報なのか」という別の問いが生まれます。
氏名とメールアドレスだけ先に入力してもらい、詳細情報は後で取得すればよいかもしれません。このように、試作品は新しい問いを発見するための道具でもあります。
「こうしたい」を仕様へ変換するのが難しい
経営者や業務担当者が考えているのは、通常「実現したいこと」です。たとえば、「お客様にいくつか質問へ答えてもらって、最適なサービスを紹介したい」という要望があります。
- 質問はいくつあるのか
- 一画面にすべて表示するのか
- 一問ずつ表示するのか
- 前の質問へ戻れるのか
- 回答途中で保存できるのか
- 判定方法は何か
- 結果はいくつのパターンがあるのか
- 結果画面に何を表示するのか
- 結果を保存するのか
- 管理者も確認するのか
ここまで考えて初めて、実際のシステム仕様に近づきます。AIで試作品を作ると、こうした曖昧な部分が目の前に現れます。これが発注前に試す大きなメリットです。
AIで試作すると「いらない機能」が見えてくる
アプリ開発では、機能を追加することばかりに意識が向きがちです。しかし、試作品を作る大きな価値は、削るべき機能を発見できることにもあります。ここでは想定例で考えてみましょう。
想定例1|最初はログイン機能が必要だと思っていた
顧客向けの簡単な診断サービスを作るとします。最初は、「利用者ごとにログインしてもらった方がいい」と考えたとします。
しかし実際に試作品を作って操作してみると、「最初からIDとパスワードを作ってもらうと、診断を始めるまでの負担が大きい」と気づくかもしれません。
診断結果を確認するだけであれば、最初はログインなしで利用してもらい、必要になった段階で情報を登録してもらう設計も考えられます。もちろん、本番システムでログインや本人確認が必要かどうかは、取り扱う情報やサービス内容によって異なります。
重要なのは、「必要そうだから入れる」から「本当に必要だから入れる」へ変わることです。
想定例2|詳細な入力項目を用意しすぎていた
営業案件を入力する社内アプリを考えたとします。最初は詳細に管理したいため、多数の項目を作ったとします。
- 会社名
- 担当者名
- 部署名
- 電話番号
- メールアドレス
- 商談日
- 商品
- 予算
- 確度
- 競合
- 次回予定
- 商談内容
しかし実際に営業担当者に操作してもらうと、「毎回これだけ入力するなら使わなくなる」という問題が見えてきます。
その結果、最初に登録する情報は5項目程度にして、必要な情報だけ後から追加する設計の方が現場に合うかもしれません。仕様書を作っている段階では「情報が多い方がよい」と思えても、試作すると「入力負担」という別の視点が出てきます。
想定例3|複雑な管理画面を作ろうとしていた
顧客から集めたデータを見るために、立派なダッシュボードを考えることもあります。グラフを複数表示し、条件検索ができ、さまざまな角度から分析できる画面です。
しかし、試作品を使ってみた結果、管理者が日常的に見たい情報が、「今日何件申し込みがあったか」「誰から申し込みがあったか」「対応済みかどうか」だけだったとしたら、大規模なダッシュボードは最初から必要ないかもしれません。
このように、AIで試作することは機能を増やす作業だけではありません。開発しなくてよいものを発見する作業でもあるのです。
逆に試作すると「本当に必要な機能」も分かる
不要な機能が見つかる一方で、試作することで初めて必要性に気づく機能もあります。
想定例1|入力途中の保存が必要だった
社内で長い情報を入力するアプリを作ったとします。最初は、「入力して送信するだけ」の設計だったとします。
しかし実際の業務を考えると、入力中に電話がかかってきたり、別の仕事へ移ったりすることがあります。すると、「途中保存が必要なのではないか」ということに気づきます。
これは画面を眺めているだけではなく、実際の業務の中で使うことを想像したときに発見しやすい要件です。
想定例2|結果を見るだけでなくPDF保存が必要だった
診断アプリで結果画面まで作ったとします。最初は画面に診断結果が表示されれば完成だと考えていました。
しかし実際に利用者の立場で操作すると、「この結果を社内会議で見せたい」「後から見返したい」「担当者へ送りたい」という要望が出てくることがあります。
- PDFにする
- メールで送る
- マイページへ保存する
そこで初めて、こうした次の要件が見えてきます。
想定例3|管理者側で結果を確認する必要があった
顧客向けの画面ばかり考えていると、利用者側の体験だけでアプリを設計してしまいがちです。しかし実際に試作すると、「お客様が回答した後、社内では誰が確認するのか」という問題が出てきます。
- 管理者用一覧
- 対応状況
- 担当者
- 検索
- 顧客情報の詳細表示
その結果、こうした運営側の仕組みが必要だと分かります。つまり、アプリに必要な機能は最初からすべて思いつくものではありません。使ってみることで発見する機能もあるのです。
発注前プロトタイプはどこまで作ればよい?
AIでアプリを作れるようになると、つい完成度を上げたくなります。しかし発注前の試作であれば、作り込みすぎる必要はありません。目的は本番公開ではなく、要件を具体化することだからです。
最初は「入力→処理→結果」の3段階でよい
最小構成としておすすめなのが、「入力 → 処理 → 結果」という3段階です。
たとえば診断アプリなら、入力では利用者が質問へ回答し、処理では回答内容をルールやAIで判定し、結果では診断結果を画面に表示します。
まずはここまで動けば、多くのことを確認できます。その後、「データ保存が必要だ」「PDFが必要だ」「管理画面が必要だ」という要件を追加していきます。
逆に最初から、認証、メール、PDF、決済、会員管理、管理画面、分析機能などを全部入れようとすると、本来の目的である「試す」ことより「完成させる」ことに時間を使ってしまいます。
見た目を作り込みすぎない
発注前の試作品では、デザインも必要最低限で構いません。もちろん実際に使う画面を想定して、ボタンの位置、文字の大きさ、入力欄の順番、スマートフォンでの見え方などを確認することは重要です。
しかし色や装飾、細かなアニメーションを完成品レベルまで調整する必要はありません。まず見るべきなのは、「この業務の流れで本当に使えるか」という部分です。
本番用のセキュリティまで最初から実装しない
試作品と本番システムは分けて考える必要があります。試作品が動いたからといって、そのまま顧客へ公開してよいとは限りません。
- 個人情報
- 顧客情報
- 決済情報
- 社内機密
- 認証情報
こうした情報を扱う場合は、本番環境で適切な設計が必要になります。試作では実データではなく、架空のデータやテストデータを使うことを基本にしてください。
AIでアプリを試作する基本的な7ステップ
では、実際にどのような順番で試作品を作ればよいのでしょうか。技術から考えるのではなく、業務から考えるのがポイントです。
STEP1|解決したい業務課題を一文にする
最初に「どんなアプリを作るか」を考えすぎないようにします。先に、「何を解決したいのか」を決めます。
- 問い合わせ内容を担当者が毎回手作業で分類している
- お客様へのヒアリング内容から毎回同じような提案を考えている
- 紙で回収した情報を後からExcelへ転記している
アプリは目的ではなく、課題を解決する手段です。ここが曖昧だと、試作品にもさまざまな機能を追加してしまいます。
STEP2|誰が利用するのかを決める
次に利用者を決めます。
- 顧客
- 営業社員
- 店舗スタッフ
- 管理者
- 経営者
複数の人が利用する場合は、利用者ごとに必要な画面が異なる可能性があります。顧客には入力画面だけ必要でも、管理者には結果一覧が必要かもしれません。
STEP3|何を入力するのか決める
利用者が最初に入力する情報を書き出します。ただし、最初からすべて入れる必要はありません。「このアプリが最低限動くために必要な情報は何か」という視点で絞ります。
- 業種
- 従業員数
- 現在の課題
- 利用しているツール
一度試作した後に、本当に必要かどうかを判断します。
STEP4|AIやシステムに何を処理させるのか決める
入力後に何が起きるかを決めます。
- 条件で分類する
- 点数を計算する
- AIに文章を生成させる
- 入力情報を整理する
- 適切な選択肢を表示する
ここも最初から複雑にする必要はありません。まずは最低限のロジックで動かします。
STEP5|最終的に何を表示するのか決める
利用者が最後に得るものを考えます。
- 診断結果
- おすすめプラン
- 見積もりの概算
- 次に行うべきこと
- 業務改善案
ここまで決まれば、「入力→処理→結果」の基本構造ができます。
STEP6|AIと会話しながら試作品を作る
ここからAIへ、「この内容で入力フォームを作りたい」「この選択肢を選んだ場合は、この結果を出したい」「結果画面を追加したい」などと指示して試作品を作っていきます。
一度ですべて正しく作る必要はありません。むしろ、「ここを変えて」「この入力欄はいらない」「この画面の前に確認画面を追加して」と対話しながら改善していくことが重要です。
STEP7|実際に触って修正点をメモする
試作品が動いたら、すぐに機能追加するのではなく、一度操作します。できれば実際に利用する人にも触ってもらいます。
- 迷った場所
- 面倒だった操作
- 不要だと思った項目
- 足りなかった情報
- 次にやりたくなった操作
このメモこそが、その後の開発要件を作る重要な材料になります。

試作品を作ったら「機能リスト」ではなく利用の流れを見直す
アプリの要件を考えるとき、多くの人が「欲しい機能一覧」を作ります。しかし、機能だけを並べると本当に必要なものが見えにくくなります。そこで試作品を作った後は、業務の流れに沿って確認してください。
誰が使うのか
最初に誰がアプリを開くのか。顧客なのか、社員なのか、管理者なのかを確認します。
いつ使うのか
問い合わせ前なのか、商談中なのか、作業終了後なのか。利用するタイミングによって、入力できる情報や使える端末も変わります。
何を入力するのか
その時点で利用者が持っている情報だけで操作できるかを確認します。後でしか分からない情報を最初から必須項目にしていると、実務では止まってしまいます。
何が返ってくるのか
入力後に利用者が何を得るのかを明確にします。「登録しました」と表示されるだけなのか、診断結果が出るのか、次に行うべきことが表示されるのかによって、アプリの価値は大きく変わります。
その後に誰が何をするのか
ここは特に重要です。アプリの処理が終了しても、業務そのものが終了するとは限りません。
- 営業担当者へ連絡する
- 見積もりを作る
- 面談を予約する
- 社内で結果を確認する
こうした業務が続くのであれば、その流れまで考える必要があります。アプリ単体ではなく、前後の仕事を含めて考えることで、本当に必要な要件が見えてきます。
AIで作った試作品を開発会社への発注に活用する方法
試作品ができたら、それを開発会社との打ち合わせ材料として利用できます。完成度が高い必要はありません。むしろ、「まだ決めていない部分」が残っていても問題ありません。
「こんな感じ」から「この動き」に変わる
試作品がない場合、「こんな感じの診断アプリを作りたい」という抽象的な説明になります。
しかし試作品があれば、「最初にこの5問へ回答します」「このボタンを押すと結果が表示されます」「結果は現在3パターンですが、最終的には5パターンにしたいです」と具体的に説明できます。
開発会社側も、発注者が何をイメージしているのか理解しやすくなります。
画面を見ながら要望を伝えられる
文章では説明しにくいことも、画面があれば簡単です。「この入力欄はいりません」「ここに写真を追加したいです」「この結果をPDFにしたいです」「この画面は管理者だけが見られるようにしたいです」と話せます。
特に非エンジニアの場合、専門用語で仕様を説明するより、実物を見ながら話した方が意思を伝えやすいことがあります。
未確定事項も明確になる
プロトタイプには、決まったことだけでなく、決まっていないことを発見する効果もあります。
- 結果を保存する必要があるか決めていない
- 誰が管理者になるか決めていない
- どこまで顧客情報を取得するか決めていない
未確定事項が明確になれば、専門家へ相談するときにも質問しやすくなります。
試作したからといって最後まで内製する必要はない
AIで試作品を作った結果、「ここまで自分たちでできるなら、そのまま完成まで進めなければならない」と考える必要はありません。試作と本番開発は分けて考えましょう。
内製か外注かは試した後に決めてよい
アプリのアイデアを考えた瞬間に、「これは内製」「これは外注」と決める必要はありません。まず簡単に試してみる。
その結果、「この程度なら社内で運用できそうだ」と分かることもあれば、「本番利用には専門家が必要だ」と分かることもあります。
先に作り方を決めるのではなく、先に必要なものを理解する。その後で、どう作るかを決めればよいのです。
専門性が必要な部分だけ依頼する選択肢もある
すべてを同じ方法で開発する必要もありません。画面や簡単な処理は社内で試作し、専門性が必要な部分だけ相談する方法もあります。
- 本人認証
- アクセス権限
- セキュリティ設計
- 決済
- データベース設計
- 外部システムとの連携
- 本番環境
- バックアップ
- 安定運用
- 監視
どこまで専門家へ依頼すべきかは、扱う情報や利用人数、サービス内容などによって異なります。この記事では内製と外注のどちらが優れているかを決めるのではなく、試作した後で必要な範囲を判断できるという点を重視しています。
試作品をそのまま本番利用しない判断も重要
AIを使って作ったアプリが実際に動くと、「もう完成した」と感じてしまうことがあります。しかし、動くことと、安全・安定して運用できることは同じではありません。
- 想定外の操作
- データ消失
- 権限管理
- 不正アクセス
- 大量アクセス
- 外部サービス停止
- 保守
- 更新
特に顧客情報や個人情報を扱う場合は、専門的な確認が重要です。
AIで発注前プロトタイプを作るときの注意点
AIで試作するときは、便利さだけでなく、目的を見失わないようにしましょう。
最初から完成品を目指さない
試作の目的は、要件を発見することです。完璧なデザインやすべての機能を作ることではありません。最初から完成品を目標にすると、試作品の修正に時間をかけすぎてしまいます。
機能を追加し続けない
AIへ頼めば比較的簡単に機能を追加できるため、「これもできるなら追加しよう」となりやすくなります。しかし機能が多いほど良いアプリになるとは限りません。追加する前に、「この機能は、どの業務課題を解決するのか」を確認してください。答えられない機能は、いったん追加しなくてもよいかもしれません。
実際の顧客情報や機密情報を安易に入力しない
試作段階ではテストデータを利用するのが基本です。利用するAIサービスや開発環境のデータ取り扱い条件も確認し、個人情報や社外秘情報を安易に入力しないようにしてください。
動いたことと品質保証を混同しない
一度正常に動いたからといって、すべてのケースで正しく動作するとは限りません。想定外の入力や複数人による利用など、本番では試作時と異なる状況が発生します。試作品はあくまで要件を考えるための材料として扱うことが重要です。
試作品そのものより「分かったこと」を残す
発注前プロトタイプで最も重要な成果物は、必ずしもアプリそのものではありません。
- 必要な機能
- 不要な機能
- 利用者
- 入力項目
- 結果
- 業務の流れ
- まだ決まっていないこと
- 専門家へ相談したいこと
こうした内容が整理された状態こそ、大きな成果です。
発注前に整理しておきたいプロトタイプ確認チェックリスト
試作品を作ったら、次の項目を確認してみてください。
- このアプリが解決する業務課題を一文で説明できる
- 誰が使うアプリなのか決まっている
- 最初に何を入力するのか決まっている
- 入力後に何が処理されるのか説明できる
- 最後に利用者へ何を返すのか決まっている
- 利用者が迷う画面を把握している
- 不要だと分かった入力項目が整理されている
- 不要だと分かった機能が整理されている
- 試した結果、新しく必要だと分かった機能が整理されている
- データを保存する必要があるか決まっている
- 誰が結果を確認するのか決まっている
- 管理者向け画面が必要か判断している
- アプリ利用後に続く業務を確認している
- まだ決まっていない事項を整理している
- 専門家に確認したい部分を整理している
すべてが決まっている必要はありません。むしろ、「ここはまだ分からない」という項目を見つけることも、発注前プロトタイプを作る目的の一つです。
よくある質問
プログラミング経験がなくてもAIでアプリを試作できますか?
簡単なWebアプリや入力・結果表示を中心とした試作品であれば、プログラミング経験が少ない人でもAIと対話しながら形にできるケースがあります。ただし、どの程度まで作れるかはアプリの内容によって異なります。最初から複雑なシステムを作ろうとせず、「入力→処理→結果」の最小構成から始めるのがおすすめです。
AIで作ったアプリをそのまま業務で使えますか?
試作品として動くことと、本番業務で安全・安定して使えることは別です。社内の限定的な用途で使えるケースもありますが、個人情報、顧客情報、決済、認証などを扱う場合は、セキュリティやデータ管理を含めた専門的な確認が必要になることがあります。まず試作品で要件を確認し、その後に本番利用の方法を判断してください。
試作品はどこまで完成させればよいですか?
発注前の確認が目的であれば、完成度を高くする必要はありません。まずは、「誰が何を入力し、何が処理され、何が返ってくるか」が確認できれば十分です。試して初めて必要だと分かった機能を、その後追加していくとよいでしょう。
AIで試作した後に開発会社へ依頼しても大丈夫ですか?
問題ありません。むしろ試作品があることで、作りたい画面や操作の流れを具体的に説明しやすくなる可能性があります。試作品を完成品として渡すというより、「この動きを実現したい」「ここはまだ決めていない」という会話の材料として活用するとよいでしょう。
試作段階で専門家に相談した方がよい部分はありますか?
個人情報や重要な業務データを扱う場合、認証、権限管理、決済、外部システム連携などを行う場合は、早い段階で専門家へ確認した方がよいケースがあります。自分たちだけで判断できないところを把握することも、試作品を作る意味の一つです。
まとめ|AIで試作してから、どう作るかを決めればよい
アプリを作りたいと思ったとき、最初から完璧な仕様書を作る必要はありません。また、「自社で開発するか」「開発会社へ外注するか」を最初に決める必要もありません。
まず、作りたいものをAIで小さく形にしてみる。そして実際に触ってみます。
すると、「これはいらなかった」「これは必要だった」「この操作では使いにくい」「この情報も保存したい」「ここから先は専門家に相談したい」ということが見えてきます。
アプリ開発におけるAIの価値は、単にプログラムを書いてくれることだけではありません。頭の中にある曖昧なアイデアを、触って確認できるものへ変えてくれることにも大きな価値があります。
試作品ができれば、開発会社へ相談するときも、「こんなシステムが欲しい」だけではなく、「この画面で入力し、この処理を行って、この結果を表示したい」と具体的に説明できるようになります。
そして、その段階で初めて、自社でどこまで進めるのか、どの部分を専門家へ依頼するのか、どの機能を本番システムへ入れるのかを判断すればよいのです。
作り方を先に決めるのではなく、まず作りたいものを先に形にする。AIを発注前のプロトタイプ作成に使うことで、アプリ開発のスタート地点そのものを変えられます。
作りたいアプリはあるけれど、何をどこまで依頼すればよいか分からない方へ
AIで試作品を作ってみたものの、「これをこのまま使ってよいのか分からない」「次にどこを専門家へ依頼すればよいのか分からない」「そもそも必要な要件が整理できているのか不安」という場合は、現在の試作品や業務内容をもとに整理してみる方法があります。
相談前に完璧な仕様書を作る必要はありません。次の情報があるだけでも、検討を進めやすくなります。
- 解決したい業務課題
- 誰が使うアプリなのか
- 現在作っている試作品
- 必要だと思っている機能
- 試して不要だと分かった機能
- まだ判断できていない部分
すべてを外注するか、すべて自社で作るかを最初に決める必要もありません。まずは、どこまで自社で進められ、どこから専門性が必要なのかを整理することから始めてみてください。
