作り直しを提案されるのは、システムが悪いからではなく「今どうなっているかを読み解くコスト」が「作るコスト」を上回るときです。判断の材料はサーバーとコードを見れば出せます。発注側が確保しておくべきものは、ソースコード・過去の資料・そして業務を説明できる人です。
他社が作ったシステムの引き継ぎを相談すると、「これは直すより作り直した方が早いです」と言われることがあります。資産をそのまま活かしたい発注側からすれば、なぜそうなるのか納得しづらい提案です。「なぜ作り直しなのか」「なぜそんなに費用がかかるのか」という疑問は当然のものです。
この記事では、引き継ぎの相談を受けた開発会社がサーバーとコードの何を見て、どこで「作り直した方が早い」と判断しているのかを、実際の調査でよく出てくる状態に沿って説明します。判断の根拠が分かれば、提案が妥当かどうかを発注側でも検討できます。
「作り直した方が早い」とは、どういう判断か
作り直しの提案とは、既存システムを読み解いて安全に手を入れるコストが、同じものを新しく作るコストを上回っている、という判断です。システムの出来の善し悪しを評価しているのではなく、二つのコストを比べた結果です。
判断が分かれるのは「読み解くコスト」の側
新しく作るコストは、機能の数や画面の数からある程度見積もれます。一方で読み解くコストは、システムの状態によって大きく変わります。整理されたコードなら短時間で全体像がつかめますが、そうでなければ「今どう動いているか」を確かめる作業だけで日数を使います。この差が、同じ規模のシステムでも提案が分かれる理由です。
そして読み解くコストは、調査してみるまで正確には分かりません。だから見積もりの前に調査そのものの費用が発生することがあります。これは費用を上乗せしているのではなく、調べなければ見積もれないという構造によるものです。
調査で実際に見つかる状態
引き継ぎの相談でサーバーとコードを確認したとき、読み解くコストを押し上げるものとして次のような状態がよく見つかります。
- PHPのバージョンが古く、そのままでは動かせない — 実際に出てくるのはPHP 5系です。数年前まではCentOS 6のようにOS自体が保守切れという案件もありました。動作環境を用意するところから作業が始まります
- 使われている技術が更新できない — たとえばCakePHPで使われていた頃のSmartyのような、現在は主流でないテンプレート技術に依存しているケースです。WordPressの場合は、有償プラグインのライセンスとバージョンアップをどうするかの判断が必要になります（その機能に今もお金を払う価値があるか、という判断です）
- 同じ処理のファイルが何個もある — バージョン管理が使われていない場合に、同一ファイルの複数世代が残ります。加えて、リファクタリングや構造の把握がされないまま同じ処理がコピー＆ペーストで増えていることもあります。どれが実際に使われているのかを確かめないと手が付けられません
- 本番環境で直接編集されている — バージョン管理が無い場合は、ほぼ本番で直接運用されていると考えて動きます。制作会社が入っている場合でも、デザインの修正といった保守がそのまま本番を触る形になっていることがあります
- バックアップが無い、または戻せない — 「取っていない」だけでなく、取ってはいるが戻すリハーサルをしていないケースが多くあります。レンタルサーバー標準のバックアップは、サーバー側のトラブルには備えられますが、誤って削除したファイルを復元するといった用途は別途考える必要があります
- テスト環境が無い — 動作確認の場が本番しかない状態です（この場合にどう進めるかは後述します）
- データベースの設計が崩れている — 1つのテーブルに100列、200列とあるような状態です。正規化されておらず、「文章1」「文章2」のようにあらかじめ決め打ちで列を確保する設計になっていて、必要以上の列が並んでいることがあります。こうなると機能単位の修正では追いつきません
一つひとつは対処できるものです。問題はこれらが複合的に噛み合わさったときで、そうなると調査だけで相応の時間がかかり、見積もりの段階から費用が発生することになります。
テスト環境が無い場合はどうするのか
引き継ぎの場合、テスト環境が無ければこちらで用意します。ローカル環境や別のサーバーに、動作確認のための環境を構築するところから始めます。
ただし、そのまま同じものを再現できるとは限りません。.htaccess や Apache の設定のようにサーバーに依存しやすい部分が多く、画像などのアセットが大量にある場合はなおさらです。そうしたときは、本番環境で作業しても失敗しにくい手順を先に確立するか、完全な再現ではないと承知したうえで、規模を落とした似た環境で検証することになります。
いずれにしても、テスト環境が無い状態では確認にかかる手間が増えます。これも読み解くコストの一部です。
最も手がかりが少ないのは、記録が残っていないとき
特に読み解くコストが跳ね上がるのが、レンタルサーバーで動いていて、かつバージョン管理が使われていない組み合わせです。この場合「何が正しい状態だったのか」を示す記録がどこにもありません。
そのため、当時の担当者へのヒアリング、残っている資料、サーバー上で直接編集された痕跡、この三つを突き合わせて現状を推測する作業から始めることになります。これは開発ではなく開発の手前の作業ですが、ここが工程の大半を占めることがあります。結果として、推測を重ねて既存を活かすより、要件を確認しながらゼロベースで作り直した方が早く、間違いも少なくなります。
読み解きが難しいコードの例として、独特の命名や本来と異なる意味で使われた用語が多用され、しかもその使い方に一貫性がないものがあります。書いた人を責める話ではなく、当時の開発体制や引き継ぎの経緯がそのまま形になったものです。ただ、後から読む側にとっては、コードを読んでも意図が復元できないため、確認作業がどこまでも増えていきます。
逆に「直して使える」のはどんなシステムか
古いこと自体は、作り直しの理由になりません。構築時期が古くても、そのまま活かせるシステムには共通点があります。
フレームワークの作法に沿っている
WordPressやLaravelのような広く使われているフレームワークに則って作られていれば、初めて見る人でもどこに何が書かれているかの見当がつきます。独自の作法を覚える必要がないぶん、読み解くコストが小さく収まります。
構築後にあまり手が加えられていない
作られた当時のまま大きく改造されていないシステムは、バージョンアップによる再利用がしやすい傾向があります。逆に、長年にわたって場当たり的な改修が重ねられていると、当初の設計と現状がずれていき、全体像をつかむのが難しくなります。
なお、ソースコード自体が手元に無い場合は、そもそも改修という選択肢が取れません。この状況についてはソースコードが無いシステムの保守と引き継ぎで詳しく扱っています。
調査にかかる時間と、本当に難しいところ
サーバーやコードといった技術面の調査は、近年は開発支援ツールの補助もあり、一週間程度で見通しが立つことが多くなりました。バージョンアップの作業自体も、ひと昔前よりは進めやすくなっています。
技術よりも難しいのは、その機能が何に使われているかの理解
調査で最も時間がかかるのは、実は技術面ではありません。発注企業ごとの業務の理解です。その会社だけの特殊な業務フローや独自の仕組みが組み込まれていると、「機能としては何をしているか分かるが、実際に何のために使われているのか分からない」というものが必ず出てきます。
とりわけ、現在は使われていない機能や、もともと別の目的で作られた機能を流用して運用しているものは、コードをいくら読んでも判断がつきません。これは発注企業に聞かなければ分からない領域です。引き継ぎの調査に発注側の協力が必要になるのは、この部分があるためです。
発注側が今のうちに確保しておけるもの
引き継ぎや刷新を検討する段階で、発注側が用意できるものは限られていますが、あるかないかで調査の進み方が変わります。
- ソースコード — 手元にあるか、開発会社に預けたままか、所在を確認しておく
- 過去の資料 — 提案書、仕様書、操作マニュアルなど。内容が古くても手がかりになります
- 稼働しているサーバーへのアクセス手段 — 契約先とログイン情報の所在
- 業務を説明できる人 — 使われていない機能や独自の運用について答えられる担当者
特に最後の一つは、資料では代えがきかないものです。刷新を実際に進める段階でも、機能の一覧を作り「使っている・使っていない」を発注側と一緒に確認しておくと、どこに手をかけるべきかがはっきりします。
なお、見積もりの前段として実施する調査で何を成果物として受け取れるかは、老朽化システム刷新のPhase 1調査の中身で画面の棚卸し表などの実物を公開しています。刷新全体の進め方は老朽化システム刷新ガイドにまとめています。
まとめ
作り直しの提案は、システムへの評価ではなく、読み解くコストと作るコストを比べた結果です。判断の根拠はサーバーとコードを調べれば示せるものなので、提案を受けたときは根拠を尋ねてみてください。
そして、技術面の調査は進めやすくなった一方で、その会社だけの業務の理解は今も人が確かめるしかありません。発注側がソースコードと資料の所在を把握し、業務を説明できる人を用意できるかどうかが、引き継ぎがうまく進むかを大きく左右します。
現在お使いのシステムの引き継ぎや刷新でお困りのことがあれば、お問い合わせからご相談ください。
この記事をシェア
作り直しと言われたが、その判断が妥当か分からない
現在のシステムの状態を調査したうえで、改修で対応できるのか、作り直しが妥当なのかをご説明します。判断の根拠もあわせてお伝えします。現状の確認だけでも構いません。