システムは納品後の改善で育てる｜新規事業の考え方
新規事業のシステムは、納品した時点がゴールではなく、事業が本格的に始まるスタートラインです。この記事では、新規事業でなぜ納品後の改善が大切なのか、何を見てどう直していくのか、そして発注前に確かめておきたい体制を順に整理します。システム開発を外注する前後の各段階で、発注側が迷いやすい点を、私たちなりの視点でまとめました。
新規事業のシステムが「納品して終わり」になりにくい理由
作る前には、答えが分からない
業務の効率化であれば、今の業務の流れという「手本」があります。手本をシステムに置き換えれば、ある程度の正解に近づけます。
新規事業はそうはいきません。誰がどんな場面で使うのか、何に価値を感じてもらえるのか、どの機能が本当に使われるのか。これらは始める時点では仮説にとどまります。つまり、納品された時点のシステムは、仮説を形にした「最初の版」にすぎません。
実際の使われ方を見て、仮説が当たっていた部分と外れていた部分を知る。そのうえで必要な部分を直していく。この循環があって初めて、システムが事業の形に近づいていきます。
納品をゴールにすると起きやすいこと
納品をゴールと考えると、次のような状況が起こりやすくなります。
- 納品時点の仕様が「完成形」として扱われ、変えにくくなる
- 改善したい点が見つかっても、頼む窓口や進め方が決まっていない
- 作った人が離れ、設計意図が不明になる
- 小さな修正が、毎回大きな相談事になる
どれも、開発そのものの問題というより、納品後を考えずに進めたことで起こる問題です。要件を言葉だけで決めたことによる認識違いが、納品後に表面化することもあります。認識のズレについては、システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせで詳しく整理しています。
納品後の改善で、何を見ていくか
改善といっても、思いつきで機能を足していくわけではありません。見るべき観点を先に決めておくと、判断がぶれにくくなります。
実際の使われ方
最初に確認したいのは、想定した人が想定した場面で使っているかどうかです。
- どの機能がよく使われ、どの機能がほとんど触れられていないか
- 利用者が途中でやめてしまう画面はどこか
- 想定していない使い方をされていないか
想定外の使い方は、失敗ではなく手がかりです。事業の本当の価値が、最初の想定とは別の場所にあると気づけることもあります。
事業としての数字
システムの出来と、事業の成果は別のものです。利用の継続、問い合わせ、申し込みなど、事業として何を成果とみなすのかを決め、それをシステムの状況と合わせて見ます。
指標は事業ごとに異なります。大切なのは、納品前に「何が起きたら仮説が当たったと言えるか」を言葉にしておくことです。基準がなければ、改善の方向を決められません。
利用者と現場の声
数字で分かるのは「何が起きたか」であり、「なぜ起きたか」は分かりません。利用者の声や、運用する現場の感覚が、その理由を補う手がかりになります。数字と声の両方を見ることで、直す場所の見当がつきやすくなります。
優先順位のつけ方
改善したい点は、運用を始めると次々に出てきます。すべてに手を付けると、システムが膨らんで事業の軸が見えにくくなります。優先順位は、たとえば次の3つで考えると整理しやすくなります。
- 事業の仮説の検証で、重要度が高いか
- 利用者が実際に困っている問題か
- 小さく試して、結果を確かめられるか
一度に大きく変えるより、小さく直して反応を見て重ねるほうが、方向修正もしやすいです。
育てやすいシステムは作りから違う
納品後の改善のしやすさは、納品後に決まるわけではありません。どう作り始めるかで、かなりの部分が決まります。
最初から全部を作らない
最初から多くの機能を盛り込むと、どれが効いているのか分からなくなります。事業の核になる部分に絞って先に形にし、使われ方を見ながら広げていくほうが、新規事業には向いています。この考え方が、MVP（Minimum Viable Product、最小限の機能で価値を確かめる製品）と呼ばれる開発手法です。プロトタイプやモックとの違いは、プロトタイプとMVP・モックの違いを整理で、進め方はMVP開発・プロトタイプ開発の進め方で扱っています。
事業の核と、そうでない部分を分ける
システムの中には、事業の独自性そのものになる部分と、一般的な仕組みで足りる部分があります。事業の核にあたる部分は、事業の変化に合わせて直し続ける前提で作ります。一方、ログインや通知のような一般的な部分は、既存の仕組みで済ませるという割り切りもできます。見極め方は、スクラッチ開発とは？新規事業で独自に作る部分の見極め方が参考になります。
システムそのものを事業の中心に置く考え方は、新規事業のシステム設計とビジネスモデルの作り方で整理しています。
変更しやすい状態を保つ
改善を続けるには、システムの構造や中身が読み解ける状態であることが前提です。たとえば次のような点が挙げられます。
- 設計の意図や画面・データの構成が、文書として残っている
- 変更したときに壊れていないかを確かめる、テストの仕組みがある
- 機能ごとに整理され、一部だけ直しやすい
開発中は見えにくい部分ですが、納品後に毎月のように改善を重ねるほど、効いてきます。
実物で早く確かめる
仕様書や企画書で議論を重ねるより、動くものを触って判断するほうが、仮説の検証は早く進みます。動くシステムで確かめる手順は、新規事業のアイデア検証方法にまとめています。納品前から「触って確かめる」習慣を持っておくと、納品後の改善にもつながります。
発注前に確かめたい、納品後の体制
納品後のことは、発注してから考えるより、依頼先を選ぶ段階で確かめるほうが安全です。次の点を、聞いておくことをおすすめします。
確認したい項目
- 保守の範囲：不具合の修正や、システムを動かし続ける対応が、どこまで含まれるか
- 機能追加の進め方：改善依頼の窓口、手順、おおよその所要期間はどうなるか
- 設計の引き継ぎ：設計資料やテストなど、中身を把握するための情報を受け取れるか
- 成果物の扱い：ソースコードや動かす環境について、どこまで自社で扱えるのか
- 担当の継続性：作った担当と、納品後の担当が連続しているか
- 相談の頻度：定期的に見直す場があるか
契約の枠組みや支払い条件のように、依頼先ごとに違いが大きくなりやすい点も、事前に契約書などの書面で確認しておくと安心です。
社内の決裁者とも共有しておく
もう一つ大切なのが、社内での合意です。新規事業では、立案する現場と決裁する経営陣が同じ目的を見ていても、判断の材料や進める速度が異なるため、話が噛み合わないことがあります。「納品後も改善を続ける前提」を最初から共有しておかないと、「なぜ追加の対応が必要なのか」という議論になりがちです。
ズレているのは目的ではなく、進め方です。新規事業で経営陣と現場がすれ違う原因は進め方のズレで、決裁の通し方は稟議を通すシステム開発｜プロトタイプの使い方で扱っています。
依頼先選びの全体像は、システム開発会社の選び方｜新規事業で失敗しない7つの視点と、システム開発の外注ガイドにもまとめています。AIを使う開発会社に頼む場合の確認事項は、AI受託開発に依頼する前に確かめたい6つのことが役立ちます。
AI駆動開発で変わる納品後の改善
AIを活用した開発が広がり、設計から実装、テストまでの工程が速くなってきました。これは、納品後の改善にも関わる変化です。
小さな改善を回しやすくなる
従来、小さな機能追加でも工数がかかり、「まとめて大きく直す」運用になりがちでした。AIを開発工程に組み込むと、小さな変更を短い間隔で繰り返しやすくなります。新規事業のように、仮説を試して直すことが前提の取り組みとは相性がよい変化です。AIで新規事業の立ち上げがどう変わるかは、AI駆動開発で新規事業の立ち上げはどう変わるかで整理しています。
それでも、人の判断は残る
AIが速く作れることと、何を作るべきかを正しく決められることは別です。何を改善するかを決めるのは、事業を理解している人の役割です。出来上がったものの品質を最終的に判断するのも人です。この点はAI開発でも品質には人の確認が必要な理由に書いています。
AI駆動開発の全体像や役割分担は、AI駆動開発とは｜AIと人の役割分担と発注側の要点をご覧ください。複数のAIがチームのように動く仕組みと発注時の要点は、AIエージェントが開発チームになる仕組みと発注の要点で詳しく解説しています。
開発の速さが上がるほど、「何を、どの順で直すか」という優先順位を決める力が差になります。納品後の改善こそ、事業側と開発側が一緒に考えるべき場面だと私たちは考えています。
まとめ
新規事業のシステムは、納品して終わりではなく、使われ方を見ながら事業と一緒に育てていくものです。要点を整理します。
- 新規事業は始める時点では仮説が多く、納品は「最初の版」の完成にすぎない
- 納品後は、使われ方、事業の数字、利用者や現場の声を合わせて見る
- 優先順位は、仮説の確認に重要か、利用者が困っているか、小さく試せるかで決める
- 育てやすさは作り方で決まる。最初は核に絞り、変更しやすい状態を保つ
- 依頼先を選ぶ段階で、保守の範囲や機能追加の進め方、設計の引き継ぎを確かめる
- AI駆動開発で改善は回しやすくなるが、何を直すかの判断は人が担う
私たちJustFitは、株式会社LEGAREAが運営する完全オーダーメイドの受託開発サービスです。「先に作って、後から決める」という考え方で、構想をもとに約1ヶ月で動くプロトタイプを開発し、実物を見てから契約を判断していただけます。納品後も、システムの維持や不具合修正に加え、毎月ひとつの機能追加まで対応する伴走型の技術支援で、事業に合わせてシステムを育てていきます。仕様が固まっていない段階でも相談できます。詳細はJustFitのサービス紹介をご覧ください。