行き詰まったソフトウェア開発プロジェクトを立て直す方法（作り直すべきときの見極め方）

プロジェクトが一日で失敗することはまれです。少しずつ道を外れていき、一つひとつのサインにはもっともらしい説明がつきます。しかし重なると、見過ごすのは難しくなります。

• 納期が何度も延び、そのたびに理由が変わる。
• 不具合を直すたびに別の箇所が壊れ、同じ不具合が繰り返し出る。
• いつ公開できるのか、誰もはっきり答えられない。
• 開発者や開発会社の返信が遅くなる、または返信が来なくなる。
• コード、サーバー、アカウントにアクセスできない。
• 新しく入った開発者が「まず書き直さないと手を付けられない」と言う。

一つだけなら警告です。三つ以上当てはまるなら、必要なのは新しい締め切りではなく、立て直しです。

たとえば、フリーランスの開発者と連絡が取れず、サーバーのパスワードもその人しか知らないスタートアップは、コード自体に問題がなくても立て直しが必要です。

最初の1週間が、その後のすべての土台になります。技術的な作業に入る前に、次の四つを行います。

• 新機能を止める。不安定な土台の上に作り続けると、後の修正がすべて高くつきます。
• 権限を確保する。コード、サーバー、ドメイン、プロダクトが依存するすべてのサービスを自社で管理できているか確認します。
• 約束された内容と実際にあるものを記録する。提案書、契約書、デザイン、そして今実際に動いている機能の一覧を集めます。
• 成果物に結びつかない支払いを保留する。マイルストーンごとの支払いなら、明確な計画ができるまで次の支払いを止めます。

責任追及から始めないでください。誰がなぜこの状態にしたのかより、今何ができるのか、費用はいくらか、いつ動くようになるのかのほうがずっと重要です。

権限は、創業者が本当に必要なときに限って手元にないものです。次の一覧を一つずつ確認し、それぞれを今誰が管理しているかを書き出しましょう。

• 履歴がすべて残ったコードリポジトリ。最新版のzipファイルではありません。
• ホスティングとサーバーのアカウント。データベースとバックアップも含みます。
• ドメインのレジストラとDNS設定。
• モバイルアプリがある場合は、アプリストアの開発者アカウント。
• 外部サービス。決済、メール、アクセス解析、地図、AIのAPIなどです。
• デザインファイルと、既存のすべてのドキュメント。

リポジトリが他人のアカウントにある場合は、移管を依頼します。GitHubのドキュメントに、移管時に履歴、Issue、プルリクエストがどう引き継がれるかが説明されています。

相手が協力しない場合は、自社側から取り戻せるものから取り戻します。ドメインやホスティングは、自社のカードで支払われていたり、自社のメールアドレスで登録されていたりすることが多く、それが取り戻す糸口になります。

監査とは、前の委託先が説明したとおりではなく、プロダクトの実際の状態を体系的に確認することです。役に立つ監査は、次の領域をカバーします。

• アーキテクチャ。各部分のつながり方と、必要な機能を支えられる構造かどうか。
• コードの品質。読みやすさ、重複、変更を加えるときのリスク。
• セキュリティ。OWASP Top 10に挙げられているような一般的なリスクと、秘密情報や個人データの保存方法。
• インフラ。ホスティング、デプロイ、バックアップ、監視。
• テストとドキュメント。何があり、何が足りず、補うのにいくらかかるか。

監査の結果は、プロダクトの各部分について「残す」「直す」「書き直す」のいずれかを、理由とともに示すものであるべきです。そこまで来て初めて、実際のコードを反映した見積もりが出せます。

Sakuraでは、この順番を守っています。まず監査、見積もりはその後です。そうしなければ、コードが実現できない約束の上に立て直しの見積もりを出すことになるからです。

今まさにプロジェクトが止まっていますか。何が起きたのかお聞かせください。権限の確認と監査から始め、何を救えるかを率直にお伝えします。

ほとんどの場合、直すべきです。本番環境で動いている古いコードには、実際の問題に対する長年の細かな修正が積み重なっています。作り直すと、悪い部分と一緒にそれも捨てることになります。

Joel Spolskyは、有名なエッセイThings You Should Never Doでこの点を説明しています。彼はコードをゼロから書き直すことを「ソフトウェア企業が犯しうる最悪の戦略的ミス」と呼び、Netscapeを例に挙げました。書き直しに3年近くかかり、その間に競合が先を行ったのです。

もちろん、作り直しが正直な答えになる場合もあります。私たちの判断基準を表にまとめました。

作り直すと決めた場合でも、一度に行う必要はほとんどありません。Martin FowlerのStrangler Figパターンは、システムを少しずつ置き換える方法です。新しい部分を古い部分の横に育て、最後に古いコードを止めます。

前の開発者や開発会社と連絡が取れるなら、短く穏やかな引き継ぎが時間と費用を節約します。依頼するのは三つです。すべての権限、既知の問題の一覧、そしてプロダクトのデプロイ方法についての1時間の説明です。

話は事実に絞りましょう。人は責められていないと感じるほど多くを話してくれます。相手が覚えているコードの細部は、誰の責任かという議論よりずっと価値があります。

前のチームが協力しない場合は、待つ必要はありません。自社で管理しているアカウントを取り戻し、手元にあるもので監査を始め、いつ何を依頼したかを書面に残しておきます。

結論が出たら、決まった順番で進めます。公開が先、改善は後です。

• 安定させる。プロダクトが落ちる、データが失われる、決済が止まるといった重大な不具合を直します。
• 公開に必要なフローを仕上げる。公開に必要なものだけを完成させ、それ以外は後回しにします。
• デプロイと監視を整える。リリースを日常の作業にし、ユーザーから報告が来る前に問題に気づけるようにします。
• 公開する。残った問題のうち本当に重要なのはどれかを、実際のユーザーが教えてくれます。
• 改善する。残りの項目を、ビジネスへの影響が大きい順に進めます。

毎週、実際に操作して確かめられるバージョンを受け取ることで、立て直しの進み具合が見えるようになります。一度うまくいかなかったプロジェクトでは、報告を聞くだけでなく、毎週自分の目で進捗を確かめるべきです。

たとえば、開発会社が何度も納期を守れなかったスタートアップが監査を受けると、プロダクトの大部分は動いていて、公開を妨げているのは壊れた三つのフローだけだとわかることがあります。その三つを先に直せばプロダクトは公開でき、残りのバックログは実際の利用データをもとに計画できます。

監査で何が見つかるかによります。そのため、誠実な見積もりは監査の前ではなく後に出ます。コードを見ずに立て直しの見積もりを出す会社は、推測で話しています。

監査の後であれば、公開までの作業は通常、範囲を固定して見積もれます。本番公開までの明確な金額がわかり、その後の改善とは分けて考えられます。

立て直しそのものの見積もりを比較する場合も、ルールは他のプロジェクトと同じです。請負か準委任かについての記事で、それぞれのモデルが向いている場面を解説しています。

立て直したプロジェクトは、最初に欠けていた安全策を整える機会です。

• 所有権。リポジトリ、ホスティング、ドメイン、アプリストアのアカウントは自社名義で登録します。
• ドキュメント。作業と並行して書き、プロダクトが特定の個人に依存しないようにします。
• マイルストーン。テスト用リンクで動くバージョンのように、確認できる成果に対して支払います。
• 変更手続き。新しい要望は、誰かが作業を始める前に見積もりと承認を経ます。
• 公開後のサポート。修正と更新について明確な計画を立てます。たとえば月額のサポートプランです。

次の段階に向けて新しいチームを選ぶなら、開発会社の選び方の記事に、契約前に頼りないパートナーを見分けるための質問をまとめています。

プロダクトを再び前に進めたい場合は、短いブリーフをお送りください。権限の確認と監査から始め、大きな判断をする前に現状がはっきりわかるようにします。