※ポエムです。というか、創作です。
『クリーンアーキテクチャ』には、こんな一節がある。
「ORMを永続化層として扱い、それをアプリケーションの中心に据える設計は、やがて破綻する」
実際、少人数での開発や立ち上げフェーズでは、データベース中心の設計は合理的に見える。
シンプルで、素早く形になり、要件も安定している。
何より、スピードが求められる現場においては、迷いのない選択だと思っていた。
だが、開発が続き、機能が増え、チームが拡大し、ユーザーの要求が変わり始めると、事態は変わってくる。気づけば、アプリケーション全体にデータアクセスロジックやDBエンティティがはびこり、コードは複雑化していた。保守性も再利用性も失われていく。構造を見失い始めたWebアプリは、やがて“修正できないシステム”へと変貌していった。
そしてそのタイミングで、こう言われる。「そんな拡張ができないなんて聞いていない」「急ぎで対応してくれ。現場は困惑する。あれほど丁寧に説明を重ねてきたのに彼らにとって耳が痛い話は、届いていなかったのだ。アジャイル開発の前提や、反復による進化の限界も理解されない。
やがてコードの質よりも提案力が問われ、最終的には政治力がものを言うようになる。これは、理不尽でもなんでもなく、会社組織における「自然な現象」なのかもしれない。私たち現場のエンジニアが提示した設計方針は、時間を経て外部のコンサルタントによって再提出され、“新たな提案”として受け入れられる。「それ、最初に俺たちが言ってた」と言っても、誰も信じてくれない。ボトムアップの提案は、トップダウンの決定の前に、何度でもかき消された。
そんなある日、「ITに明るい」と紹介された経営幹部が新たに加わった。
「元プログラマーで、今でも趣味でコードを書いているらしいよ。経営陣の中では珍しく、技術も分かる人物だし、君たちと話が合うはずだよ」。そう社長に紹介されて、期待とともに迎えられた人物のことを聞いて、私は嫌な予感しかなかった。
案の定だった。初めての会議でその人物はこう切り出した。
「システムAは、改修のたびに業務がストップするバグを引き起こしていると聞いています。だから今後は、コアには手を加えず、外側に“バイパス”を作るような形で、補助的なシステムBを構築し、そこから徐々に拡張していきたいと考えています」。
ちょっと待ってくれ。確かにシステムAはかつてバグで問題を起こしたが、今は違う。
地道なリファクタリングを経て、ここ1年は安定している。
人さえ増やせば、さらに改修にもはずみが付く。自社サの中でもっとも重要なシステムだからこそ、限られたリソースで最善の手を尽くしてきた。
でも経営陣は、この１年を無駄と思っていたことが発覚した。また人を雇うコストを過剰なものと見なしていた。
「過去の実績」よりも、「目に見える改革」の方が価値がある。
だから、バイパスを作り木の幹にしていくという遠回りな選択肢が正当化されてしまった。
しかもそのシステムBを作るのは、件の幹部が元いた会社のメンバー。
つまり、外注による“リプレース”である。
これでシステムが目に見えて改善すれば、経営陣は株主に胸を張れる。
現場の苦労や継続的な改善など、もはや彼らの視界にはない。
こうして、私たちが築いてきたコードベースは脇に置かれた。
いくら技術的に正しいと思っていても、組織がそれを選ばないのであれば、それは「正解ではない」のだ。
自分のコードにどれほど思い入れがあっても、それは自己満足に過ぎないのかもしれない。
少なくとも、やれることはやった。
誠実に、丁寧に、最善を尽くしてやってきた。
それでも、いやだからこそ、その努力が報われないと知ったとき、人は静かに決断する。
私はその後、静かにその組織を去った。誇りと少しの悔しさを抱えた複雑な思いを残して。
コメント