『「継続性アーキテクト」という生き方』を読んで
朝から311に思いも馳せましたが、記事の内容は無関係です。
個人的にとても刺さりました。わたしの頭の中をうまく言語化してくれています。
システムアーキテクチャの全体像を描ききれるような能力を身に着けたいということ。それから、システムアーキテクチャの根幹に関わるような部分での技術的な意思決定をできる裁量を得て、自身の能力を最大限に活かしたいということ。そして、その重要な役割に見合った待遇を得たいということ。
つまり「ぜんぶできる技術・裁量・待遇がほしい」ですね。
実際にソフトウェアアーキテクト（やそれに近い立場）として活動をしている人たちは、「本当にそれほどよい設計というものが必要とされているのか」「”Just enough” （ちょうどよい塩梅）な設計はどのくらいか」といった葛藤を抱えていたりする
そう、未熟ながら、痛いほどこの気持ちです。
一つ目の理由は、完成させてリリースすることではなく、サービスを成功させるということが仕事の中心になった
二つ目の理由として、ソフトウェアが完成しなくなった
そうですね。「しっかり設計して、大作を産みだす」時代ではないということだと思います。
弊社はアジャイルで成長してきましたし現在もそうですが、しかしながら現在、技術的負債に苦しめられている箇所が少なくありません。設計もアーキテクチャも、不要ではないどころかみんな必要としているのに、結果としてビジネススピードとの兼ね合いで「とりあえずこのパターンだけ通して」「ここは今回対象外で」ということになる。売上が少ない場所やその当時の情勢で関心が薄い部分と、主要な部分の仕様が解離するものの、後から見たときに経緯がわからない。仕様の統一感がない。レガシーシステムの上でこれが行われるので、割れ窓どころか尾崎豊ばりにパリッパリにガラス割れてます、みたいな状況で、開発者のモチベーションが下がっていく……みたいなことに、もしなったら、困りますよね（あくまで仮定の話ですよ、あくまで）。
最後に、「継続性のアーキテクト」が実現できる環境として以下のポイントが挙げられています。
- 今後長きにわたってニーズが増えるマーケットである
- マーケットの置かれた環境が変化していく
- 対象となるマーケットで1位になる力を持っている
- ビジネスモデルが変化していく
- システムが硬直化することを許容しない
上記を満たした環境が「継続性のアーキテクト」に向いていること自体に異論はありません。さて、個人的にはどうなんだろう、と考えを巡らせてみます。うーん、例によってあまり具体的なことは書けませんが、何点かは満たしているし、何点かは微妙なところ。
そもそもですが、まだ転職して一年未満だし、お仕事も新しく設計をするような機会は少ないんですよね。ただ、わたしが目指している一つの像が、今回ご紹介した記事にあるようなアーキテクトであることは間違いないかと思います。そのために日々がんばります。
