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

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

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

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

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

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

未知への対処

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

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

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

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

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

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

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

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

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

教訓

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

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

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

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

要するにUnknown-Unknown（未知の未知）をKnown-Unknown（既知の未知）にするためのドキュメントを作成するということだ。ここでいうドキュメントは別に自動生成でも構わない。

例えば外部システムとの連携については、どこかで一元管理できる構成にしたり、ドキュメントにまとめておくことが望ましい。
連携先システム、インタフェース仕様（データフォーマット）、IN/OUT、連携時期などがわかるとよいだろう。
このようなドキュメントがないと、システム改修時や障害対応時の影響範囲が分からないため、適切な対応が取れなくなる。

またバッチ処理やAPIの一覧やシステム構成の全体像が把握できるようにしておくことも重要だ。
「自分たちが管轄している範囲はどこまでなのか？」が認識できないと、計画や見通しも立てられなくなる。
しかしそれさえ認知できていれば、あとは人海戦術で割り振って対応することも可能となる。