アーキテクチャ。コードの保守性。こういう伝統的な「ソフトウェア品質」から、いつの間にか関心を失った。関心がないというと大げさでコードやデザインはクリーンなほうがマシに決まっているとは思うが、それらを積極的に、優先して良くする気概がない。

ある程度歴史や規模のあるコードベースだと、アーキテクチャやコード品質は良くも悪くもどこかに落ち着いていて、それを動かすのは大仕事である。日々の仕事では、そうして着陸した「品質」の前提からハズレないよう空気を読んでコードを書く。多くの場合「一貫性」は他の指標より重要だし、規範から外れたことをしようとすると仮にそれが「正しい」としても時間がかかるから。

そうした中規模以上（数十万行から数百万行）のコードベースに対し一貫した形で品質を動かそうと思うと、コード全体をなんとなく把握しないといけない。イニチアシブを仕切る力も必要。

素朴に考えると、コードの成長と歩みを共にしてきた古株はそうした「品質改善」に向いている。ただ実際は古株であるほど眼の前のコードの品質を内面化してしまっており、動かそうと思わないことが多い。かといって品質に対しモダンな価値観、高い標準を持つ部外者がやってきても、新参者はコードの全貌を把握しておらず仕切りをする組織経験値もない。だから一貫性を実現できない。

古株が勉強熱心で段々と品質への価値観を近代化したり、新参者が心を折らずに踏みとどまってある程度の理解とカルマに達すると、中規模コードベースの品質を良くする余地はある。そういうことは、たまにおこるが、頻繁にはおこらない。

中規模を超えた大規模コードベースになると、そもそも全貌を把握した古株がいなかったり、新参者が勢いで全貌を把握することもできなかったりと、希望はより薄れる。「インフラ部門」みたいのができて専業でアーキテクチャ改善を始めたりするが、それらはドメインに依存しないツールやフレームワークの更新に留まりがち。無いよりは良いけど。

一方: 新機能を足す。遅いものを速くする。ソフトウェア開発には伝統的なソフトウェア品質を動かす以外にも楽しみは色々ある。これらは伝統的品質の改善に比べ個人で結果を出しやすい。

それにさ: 伝統的ソフトウェア品質の信奉者はしばしば「ソフトウェア開発の最大の敵は複雑さだ」と言う。自分も 15 年くらい前はそう信じ、保守性の高いクリーンなコードのことばかり考えていた。でもそれ、ほんと？

今の自分に確信はない。敵、他にも色々いるじゃん？マーケットリーダーの競合とか、新規参入してきた disruptor とか、インフレとか、新しい法令とかさ。ああいうの、複雑さより手強くない？

・・・なんてのは冗談としても、ソフトウェア開発チームのコントロールできる範囲にだって、他の敵は色々あるでしょう。たとえば遅さとか、UI のダサさとか、プラットホーム新バージョンの非互換な挙動変更とか。

これらが「複雑さ」より重要と主張する気はないが、複雑さ以外にも倒すべき敵は沢山いるとは思う。自分の関心は段々と自力で倒せそうなそうな別の敵に移っていったのだろう。

自分の隣の同僚は、わりかし伝統的な複雑さと戦っている。仕様が複雑になりつづける UI に対し、その複雑さを飼いならすための再利用可能なインフラを提案し、API を考えたりしている。

その仕事は重要だし、それを楽しんでいる同僚をかっこいいとも思うが、自分でやりたいとは思えない（出来ないという事実はさておいて）。やれといわれたら困ってしまうだろう。まして、より大きなスコープで何らかの品質を動かすような仕事なんて近づきたくもない。

伝統的品質に関わる仕事への興味も能力もない自分に気づいて、悲しいような後ろめたいような気持ちになった。アーキテクトとか、むかし憧れたことなかったっけ？なんとか関心を取り戻し、少しはその手の仕事をやってみた方がいいのだろうか。宿題リストの下の方に入れておく。

一方で、他人と違うところに関心を見いだせた誇らしさも少しある。ソフトウェア開発、複雑さの相手以外にも楽しいことあるよ。そういうのが好きでもいいんだよ。昔の自分にそう伝えたい。