― 動いているシステムより、動かし続けられるシステムのほうが価値がある。
§ 01 / 引き継げないシステムは、負債になる
システムを作った担当者が退職した、あるいは開発会社との取引が終わった。その瞬間に誰も中身が分からない状態になるケースは、中小企業で頻繁に起きます。
こうなると、小さな修正にも「調査費」が乗ります。作り直したほうが安い、という判断になることさえあります。作る費用より、引き継げないコストのほうが高くつきます。
§ 02 / 最低限これだけあれば引き継げる、4 点
大量の設計書は要りません。実務で効くのは次の 4 つです。
- システム構成図（1 枚） … 何がどこで動いているか。サーバー、データベース、外部サービス
- アカウント・権限の一覧 … どのサービスを、誰の名義で契約しているか。これが最重要
- 業務フローとの対応 … どの画面が、どの業務のどの工程に対応するか
- 運用手順書 … 定期作業、障害時の連絡先、バックアップの場所と復旧手順
② のアカウント一覧を持っていない会社は非常に多いです。担当者の個人アカウントでドメインやサーバーを契約していて、退職と同時に管理不能になる事故は実際に起きます。
§ 03 / 詳細設計書は、たいてい要らない
「ドキュメントを残す」というと分厚い設計書を想像しがちですが、中小企業の実務ではほとんど読まれません。
- 書くのに時間がかかり、費用が上がる
- 改修のたびに更新されず、すぐ実物とズレる
- ズレた設計書は、無いより有害
コードとデータベースの構造は現物が正なので、そこは実物を読めば分かります。実物から読み取れないもの、つまり「なぜそうしたか」「どこと契約しているか」「業務のどこに対応するか」を残すのが正解です。
§ 04 / 外注するときに、納品物として求めるもの
契約時に納品物として明記しておくべき項目です。
| 納品物 | 目的 |
|---|---|
| ソースコード一式とリポジトリの権限 | 他社でも引き継げる状態にする |
| システム構成図 | 全体像の把握 |
| アカウント・契約の一覧 | 支払いと権限の掌握 |
| 運用手順書 | 日常運用と障害対応 |
| 環境の再構築手順 | 最悪の場合に作り直せる |
とくに リポジトリの権限は要注意です。開発会社のアカウント配下にあると、取引終了時に取り出せなくなります。発注側の組織アカウントで持つのが原則です。
§ 05 / 更新され続ける形にする
ドキュメントが死ぬのは、更新されなくなるからです。続く形にする工夫があります。
- 1 ファイルに集約する（分散すると更新されない）
- 改修のたびに更新する運用にする（改修の完了条件に含める）
- 書く量を絞る（多いほど更新されない）
理想的な設計書より、更新され続ける 1 枚のほうが実務では価値があります。
§ 06 / A.I.M の考え方
A.I.M の受託開発では、業務の棚卸しから入り、引き継げる形で納品することを前提にしています。ソースコードとリポジトリ権限、構成図、アカウント一覧、運用手順を納品物に含め、将来ほかの会社に引き継ぐ場合でも困らない状態でお渡しします。作ったシステムが御社の資産として残ること、それ自体を成果物の一部と考えています。
関連サービス: システム受託開発 / 自社サービス（SaaS） / お問い合わせ