経営者のためのSDLC入門：発注前に知るべき開発6工程

アプリ開発をベンダーに発注しようと考えているなら、契約書にサインする前に理解しておきたい概念が一つあります。SDLC（Software Development Life Cycle、ソフトウェア開発ライフサイクル）です。技術的に聞こえますが、本質はシンプルで、アプリがアイデアの段階から日々使われ、保守されるまでに通る一連の工程のことです。経営者がSDLCを理解するのは、プログラマーになるためではありません。何が妥当か、自社が何を準備すべきか、そしてどんなときに疑うべきかを知るためです。

Rancangin Aja（RAT）では、クライアントのプロジェクトでも、Cuplikin やKosProといった自社プロダクトでも、すべてのプロジェクトでこの工程を実践しています。本記事では、六つの工程を発注者である経営者の視点から解説します。

なぜSDLCは開発者だけでなく、経営者にとっても重要なのか

失敗するソフトウェアプロジェクトが、プログラマーのコーディング能力不足で失敗することはめったにありません。多くの場合、原因は次のようなものです。

• 要件が最後まで本当の意味で明確にならなかった。
• 発注者が成果物を見るのが最後になり、想像していたものと違っていた。
• テストが行われず、顧客が使い始めてからバグが見つかった。
• 完成後、誰も保守をしなかった。

これらはすべてプロセスの問題であり、SDLCはそれを防ぐために設計されたプロセスです。ベンダーが自社の開発工程を説明できないなら、それは注意すべき初期サインです。その他の警告サインについては、ソフトウェア開発会社選びのチェックリストで解説しています。

工程1：ディスカバリー（課題の理解）

何が行われるか： ベンダーがたくさんの質問をします。ユーザーは誰か。解決したい課題は何か。現在の業務はどう回っているか。どんなシステムがすでにあるか。何をもって成功とするか。

発注者が準備すべきこと：

• 現在の業務プロセスの説明。「見せたくない」部分や手作業の部分も含めて。
• 実際のデータのサンプル。Excelファイル、チャットのスクリーンショット、領収書の写真など。
• すでに使っているシステムの一覧（ECモール、POS、会計ソフトなど）。
• アプリを使う人と、その人たちのITへの慣れ具合。
• 制約条件。予算、期限、社内ルールなど。

妥当な成果物： 課題、目標、ユーザー、優先順位を付けた機能一覧、そして今回はあえて対象外とする事項をまとめた簡潔な文書。加えて、費用と期間の初期見積もり。

よくある失敗： 発注者が課題ではなく機能リストを持ってくることです。その結果、機能は多いのに何の課題も解決しないアプリができあがります。良いベンダーは、この段階で「なぜですか？」という質問を繰り返し、少し「うるさい」くらいに掘り下げてきます。

工程2：計画と設計

何が行われるか： 工程1で整理した要件を設計に落とし込みます。ユーザーフロー、ワイヤーフレーム（画面のラフスケッチ）、ビジュアルデザイン、そして技術アーキテクチャ（どの技術を使い、データをどう保存し、何と連携するか）です。

発注者が準備すべきこと：

• 設計をレビューしてフィードバックする時間。考えを変えるのに最もコストがかからないのがこの工程です。
• ロゴ、ブランドカラーなどのブランド素材（あれば）。
• 一部の機能を諦める必要がある場合の、優先順位の判断。

妥当な成果物： ワイヤーフレームまたはクリックできるプロトタイプ、主要画面のビジュアルデザイン、簡潔な技術文書。小規模なプロジェクトであれば、かなりシンプルなもので構いません。

よくある失敗： 設計をよく見ないまま承認し、アプリができあがってから「なぜこのボタンはここにあるのか」となることです。設計段階での変更は数分で済みますが、コードを書いた後の変更には数日かかります。

最初のバージョンのスコープを決めるのもこの段階です。私たちの経験では、リリースされない大きなバージョンよりも、きちんと動く小さな最初のバージョンのほうがはるかに優れています。決め方についてはMVPか完成版かで解説しています。

工程3：開発（構築）

何が行われるか： 開発者が設計に基づいてコードを書きます。優れたチームでは、これを スプリント と呼ばれる短い作業サイクル（通常1〜2週間）で進め、各スプリントの最後にデモを行います。

発注者が準備すべきこと：

• デモに参加すること。本当に、これが発注者としてできる最も重要なことです。
• 質問にすばやく答えること。開発者が回答を3日待てば、3日が失われます。
• 実際のコンテンツとデータ。商品写真、価格表、ページの文章など。
• 必要なアクセス権。ECモールのアカウント、決済代行サービス、WhatsApp Business（インドネシアで主流のビジネス向けチャット。日本でいうLINE公式アカウントに近い存在）など。

妥当な成果物： 各スプリントの終わりに試せるアプリ、簡潔な進捗報告、そして発注者がアクセスできるリポジトリ（GitHubなど）に保存されたコード。

よくある失敗： 定期的なデモがなく、最後になってから方向性がずれていたと分かることです。あるいは、スケジュールや費用への影響を意識しないまま、発注者が変更を求め続けることです。どちらも、週次デモのリズムと変更に関する明確なルールで防げます。

正直なところ： プロジェクト途中での変更はごく普通のことで、良いことも多くあります。実際のアプリを見て初めて、本当のニーズが分かるからです。問題は変更そのものではなく、時間と費用への影響がオープンに話し合われないことです。RATでは、変更依頼に対して「はい」と答えて黙って遅延させるのではなく、「対応できます。X日かかり、費用はYです。進めますか？」とお答えしています。

工程4：テストと品質保証（QA）

何が行われるか： さまざまな観点からアプリをテストします。機能は動くか、想定外の入力に対応できるか、さまざまなスマートフォンやブラウザで動くか、データは安全か、動作は速いか。

両方とも必要なテストが二種類あります。

• 開発者による 自動テスト：コードをテストするためのコードです。新しい変更で、すでに動いている部分が壊れないようにします。
• 発注者側のチームによる 手動テスト（UAT、ユーザー受け入れテストと呼ばれることが多い）：経営者とチームが、日常業務と同じようにアプリを使ってみます。

発注者が準備すべきこと：

• 経営者だけでなく、実際にアプリを使うことになるチームのメンバー。
• 現実的なシナリオ。「チャットで受けた注文を発送まで処理してみる」など。
• 明確なバグ報告。何をしたか、何を期待したか、何が起きたか、スクリーンショット。

妥当な成果物： テスト済みシナリオの一覧、発見されたバグとその対応状況の一覧、そして「リリース可能」なバージョンのアプリ。

よくある失敗： 時間が足りなくなり、この工程が削られることです。その結果、バグを見つけるのは顧客になります。ベンダーの見積もりが極端に安い場合、削られているのはこの工程であることがよくあります。

工程5：デプロイ（リリース）

何が行われるか： アプリを本番サーバーに設置し、ドメインを向け、モバイルアプリをGoogle PlayとApp Storeに申請し（審査には数日かかることがあります）、旧データを移行し、チームへの研修を行います。

発注者が準備すべきこと：

• ホスティング、ドメイン、Google Play、Apple Developerのアカウントを、ベンダー名義ではなく 自社名義 で用意すること。
• 切り替え計画。一度にすべて切り替えるのか、一部から始めるのか。
• チーム研修の時間。

妥当な成果物： 稼働中のアプリ、利用者向けドキュメント、引き渡したアカウントと認証情報の一覧、そして問題が起きたときの対応手順をまとめた簡単なガイド。

よくある失敗： アカウントとコードをベンダーが握っていることです。関係が悪化すれば、手元には何も残りません。コードとアカウントの所有権が自社にあることを、ディスカバリーの段階から確認しておきましょう。

工程6：保守

何が行われるか： アプリを監視し、新たに見つかったバグを修正し、Android・iOS・ブラウザの変化に合わせてシステムを更新し、ユーザーのフィードバックに基づいて新機能を追加します。

発注者が準備すべきこと：

• 月額または年額の予算。契約内容にもよりますが、一般的な目安は年間で開発費の10〜20%程度です。
• 問題の報告やフィードバックの集約を担う、社内の窓口担当者一名。

妥当な成果物： 定期報告（稼働率、修正したバグ）、合意した時間内での対応、継続開発がある場合は機能のロードマップ。

よくある失敗： 保守は不要だと考えることです。保守されないアプリは、通常6〜12か月以内に問題が出始めます。ライブラリが古くなり、外部サービスのAPIが変わり、セキュリティ対策が遅れていきます。

各工程の費用やリリース後の月額費用については、インドネシアのアプリ開発費用の内訳をご覧ください。

まとめ：各工程で発注者が準備すべきこと

AIはSDLCをどう変えるのか

プロジェクトにAI（チャットボット、文書アシスタント、業務自動化など）が含まれる場合も、工程はほぼ同じですが、いくつか追加があります。

• ディスカバリーでは： データ監査を行います。AIはデータなしでは機能しないため、どんなデータがあるか、どれくらい整理されているか、誰が管理しているか、といった質問が加わります。
• 設計では： 「AIが間違えたらどうするか」を設計します。人へのエスカレーション経路は、後付けではなく最初から設計しておく必要があります。
• 開発では： プロンプトの反復と評価 と呼ばれるサイクルが加わります。AIへの指示を実データでテストし、精度を測定し、改善し、それを繰り返します。テストに似ていますが、開発期間を通じて継続的に行われます。
• テストでは： 機能のテストに加え、御社の業務で実際に寄せられる質問のセットを使って、AIの回答品質をテストします。
• 保守では： 顧客の質問の傾向は変わっていくため、API利用料と回答品質を継続的にモニタリングします。

すでに稼働しているアプリがあり、作り直さずにAIを追加したい場合は、プロセスが少し異なります。詳しくは既存アプリをAIに移行するためのロードマップで解説しています。

RATでのSDLCの進め方

簡単にまとめると次のとおりです。最初のディスカバリーは無料。コードを1行も書く前に、発注者にレビューしていただく設計。週次デモ付きのスプリント。自動テストと、御社チームとのUAT。すべてのアカウントを御社名義にしたうえでのリリース。そして、その後の保守はオプションです。すべての作業は当社のチームが自ら行い、実際に作業するエンジニアと直接やり取りしていただけます。サービスの詳細はこちらをご覧ください。

次のステップ

SDLCを理解していれば、より落ち着いてベンダーを評価できます。何が妥当か、何を準備すべきか、いつ質問すべきかが分かるからです。アプリのアイデアがあり、自社の場合はどんな工程になるのかを知りたい方は、無料相談を予約するか、WhatsAppまたはメール（hello@rancanginaja.com）でご連絡ください。工程の流れ、スケジュールの目安、準備していただくことをご説明します。