出会う順番って大事だよね

要はちゃんとしたアーキテクトに出会ったことが無いこと、そしてアーキテクチャが必要となるほど大きな開発に携わっていない*1ことが要因。アーキテクチャやアーキテクトの必要性を否定的には思わない。
という前提の下、ぐだぐだと書く。

Aさんの場合

ビジネスロジックとUIの分離すらできていない、技術的負債がたんまり溜まったソフトウェア製品があった。
それを前にして、Aさんはアーキテクチャの重要性を説き、製品アーキテクチャの全体像を数ヶ月間かけて検討し、資料にまとめ上げたのだ。
結果どうなったか。
誰もそのアーキテクチャなど使わなかった。
何故かといえば、その人は一度も製品のコードを書くこともせず、そもそも実態を理解していないためだったと自分は思う。
プレゼンテーション層にはUIを含める。サービス層にはインターフェースを定義しプレゼンテーション層とビジネスロジック層を結びつける機能を用意する。ビジネスロジック層には製品の処理アルゴリズムを含めるのも良い。*2ただ、それを見せられた開発者はぽかーんとするばかりであった。ただただ「じゃあ現状のコードをどう落とし込むの？」という視点がAさんにはなかった。
コードレベルで現状の状態をどう分離するか、どう境界を引くのかの理解がまず必要だった。まぁコードが分からないのだから当然なのだが、それでよくアーキテクチャを作ろうとしたな、という感じさえする。
開発者を不幸にするアーキテクチャは数あれど、そもそも使用すらされなかったアーキテクチャは世界初だと思う。

Bさんの場合

鳴物入りでアーキテクトの肩書も付け入ってきたBさん。
今度は新規開発なのだ、Aさんのような問題は起きないだろう。
そう思った自分が甘かった。
そもそもにおいて規模の小さい開発内容であった。
人が余っているという理由だけで、実行ファイル1つで済むアプリケーションが5つ6つと増えることになった。
アーキテクトは分散して開発できることを強調していたが、それが目的ではなかった。
コンポーネントの分割すら不要な規模なので、むしろアプリケーション連携の実装に手間取ったり、それぞれが同じエラー処理を含めていたり、一気貫通でやるべき処理をわざわざ分割しているのでバグの特定が困難になった。
はじめから一つのアプリケーションでなら起き得なかったことばかりだ。
繰り返しになるが、Bさんは作るべき内容を理解していたのか疑問だ。
分散して開発することが目的になっていて、本来の目的を見失っていたのではないか。
幸いこちらはAさんと違って、きちんと開発者を不幸にしたが。

共通しているのは、現実や実態に目が行っていない点だ。
アーキテクトとしてはなるほど、基本を押さえられていて良いのかもしれない。
ただ、設計のための設計を目的にしてはいけない。
などと、最近Clean Architectureを読んでて思った。

Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

本当に良いアーキテクチャは開発者を楽にするらしい。
そのような事例やそれを実現するアーキテクトにまずは出会いたい。

*1:いや、本来はどんなものであれ必要だと思うよ

*2:なんか小泉構文っぽいな