新規開発と既存開発の両方を経験した際、開発における視点やアプローチが明らかに違うと感じたため、備忘録としてまとめておく。

新規開発と既存開発では何が違うのか？

新規開発から携わっている場合、すべての情報を把握している前提で設計を行うことができる。
全体を理解しているため、調査に要する工数がほとんどなく、設計がスムーズに進められる。
つまり、ホワイトボックス的なアプローチが可能である。

既存システムの開発に携わる場合、自分がすべての情報を把握できていない前提で進めることになる。
そのため、影響調査や改修箇所の特定など、多くの調査が必要となり、ここに多くの時間を要する。
つまり、ブラックボックス的なアプローチを取らざるを得なくなる。

これらの違いはシステムのブラックボックス化が進行しているかどうかによる。
ブラックボックス化が進行している場合は、自身がすべての情報を把握できていない前提で設計・開発を進めることになる。

ブラックボックス化したときの向き合い方

未知への対処

ブラックボックス化が進むと「わからないこと」が増え、対応に困ることが多い。
「わからないこと」については、以下の2種類があるだろう。

• Unknown-Unknowns（未知の未知）が多く存在する
  • いわゆる「罠」であり、非常に厄介
  • 認知できないため、計画に織り込むことが難しい
• Known-Unknowns（既知の未知）も多く存在する
  • 全体量やスコープは認知できているが、詳細は不明な状況
  • 計画は狂う可能性はあるが、一応立てることができる

まずはこの2種類を認知し、それぞれに対処する必要がある。
そしてどちらの場合も「計画」に基づくアプローチが難しくなることを理解しておくことが重要だ。
未知が多い状況下で無理な計画を強行すれば、必ず破綻を招く。

情報の突合による信頼性の担保

ブラックボックス化が進んだ場合、情報の信頼性が十分でないことが課題となる。
しかし、このような場合でも個々の情報を突き合わせることで、単体以上の信頼性を実現することができる。¹

例えば、以下のような情報源があり、それぞれ異なる信頼性があるとする。

• ドキュメント：信頼性70%
• ソースコード：信頼性85%
• リバースエンジニアリング（動作解析）：信頼性90%

ドキュメントは古いかもしれないし、レビューされていないかもしれない。ソースコードも解釈を誤るかもしれない。
そういった個々の情報は信頼性が不十分でも、複数の情報を突き合わせることで信頼性を高めることができる。
例えば「ソースコードを呼んで理解した内容」と「リバースエンジニアリング（実際に動かしてみた内容）」を突き合わせれば、信頼性は98.5%（1-0.15*0.10＝0.985）となる。
あとはそのシステムで求められる信頼性に応じて、突き合わせる情報の数を増やせばよい。

このとき重要なことは、できるだけ独立した情報源を突き合わせることだ。
出所が同じ情報であれば、いくら突き合わせても情報の信頼性は上がらない。
今は生成AIも利用できるため、一般的な情報であれば情報源の一つとして活用する余地があるだろう。

知らないと困ることを形式知としてドキュメント化する

ブラックボックス化が進んでいるときは、体系化・形式知化されたドキュメントも存在しないことが多い。
このような場合には、重要なドキュメントを書き起こしていくことが重要だ。

どのようなドキュメントを書き起こすとよいかについては、後述。

教訓

メンバーが入れ替わるにつれて、ブラックボックス度が上がることを理解しておく

メンバーが入れ替わるごとにシステムはブラックボックス化していくため、ブラックボックス化を完全に防ぐことは難しい。
ブラックボックス化が進むとシステムの開発速度を数倍レベルで低下するので、できるだけ進行させないことは重要だ。
しかし、それでもブラックボックス化は進行する。

ブラックボックス化が進んだ場合は、モードを切り替えて対応することが特に重要になるだろう。

知らないと困る対象を認知するためのドキュメントを作る

要するにUnknown-Unknown（未知の未知）をKnown-Unknown（既知の未知）にするためのドキュメントを作成するということだ。ここでいうドキュメントは別に自動生成でも構わない。
こういったドキュメントが存在するだけで、システムのブラックボックス度は抑えられるだろう。

システムの持ち物を把握できる一覧表

以下のようなシステムの持ち物を把握できるようにしておくことも重要だ。

• システム構成図（デプロイ対象物や、利用しているSaaSなどわかるもの）
• API一覧
• バッチ処理一覧

「自分たちが管轄している範囲はどこまでなのか？」が認識できないと、計画や見通しも立てられなくなる。
しかしそれさえ認知できていれば、あとは人海戦術で割り振って対応することも可能となる。

システム間のインタフェース仕様

外部システムとの連携については、どこかで一元管理できる構成にしたり、ドキュメントにまとめておくのが望ましい。
以下の情報が揃っているとよいだろう。

• 連携先システム
• インタフェース仕様（API/DB、データフォーマット）
• IN/OUT
• 連携タイミング

これらの情報がないとシステム改修時や障害対応時の影響範囲が分からないため、適切な対応を取ることが難しくなる。

システムで扱う対象の状態（ステータス）

システムで扱う対象の状態（ステータス）について、以下を把握できるようにしておく。

• 状態の種類と定義
• 状態の遷移条件
• 状態の遷移時、付随的に実行されること

概要を理解するには状態遷移図で十分だが、漏れなく網羅するには状態遷移表のほうが好ましい。

バッチ処理の依存関係

バッチ処理が存在する場合は、依存関係がわかるようにしておく。

• バッチの実行条件・実行順序
• バッチ間のデータの依存関係

これらがわからないと、障害等の発生時に影響範囲が把握することが難しい。

---

1. 個人的にこれを「ゼロ知識開発」と呼んでいる ↩︎