はじめに
最近、「アーキテクトの教科書」という本を買ったので、読んで思ったことを書き連ねていきます。
kindle版を買いましたが、ちゃんと文を認識してマーカーを引けるタイプなので、読みやすいです。
第1章は「アーキテクトの仕事」です。
現実のソフトウェア開発ではリリースを重ねるごとに生産性が落ちてしまいます
アジリティが落ちる要因で説明されている文章です。本書では、これが発生する原因として「技術的負債」が挙げられております。
ただし、これはプログラマ達だけの問題ではないでしょう。
- 本当は不必要な（重要ではない）機能を実装するという決断をする
- 納期は変えずに、仕様変更を行う
- 本質的ではないところに、必要以上にこだわってしまう
- リファクタリングのための時間を与えない、確保しない
このようなマネジメント側の要因によっても、「技術的負債」が生まれることがあるため、注意が必要です。
多種多様性
プログラミング言語、DB、JavaScriptライブラリなど、昨今は様々な技術が登場しており、それぞれが異なる特徴を持っています。
それらを適材適所で組み合わせて使っていきましょう、という考えは間違いではないのですが、場合によっては理想論に見えてしまうことがあります。
企業は、限られたリソース（人材、予算、時間）を使って、ソフトウェア開発に取り組んでいるため、同一のテクノロジーに集約して行った方が効率的に物事を進められることがあります。
（個人的には、Webアプリを作るときのバックエンドは、理由がなければJavaScriptを採用したいと考えています。もちろんGo言語などで書いた方が早く動作することは知っています）
マイクロサービスという言葉がありますが、これは、優秀なエンジニアを潤沢に抱えている組織にはふさわしいですが、そうでない組織が下手に手を出すと、悪化することがあります。
理想を学ぶことは重要ですが、それを状況に応じて使い分けられる能力も重要かなと思います。
ビジネスの理解
軽視されがちですが、確かにアーキテクトとして重要な資質かなと感じました。
ビジネスに対する理解が浅かったり、関心が薄い方というのは、どうしても使いたい技術や試したい開発手法ばかりに意識が行きがちです。
とはいえ、アーキテクトばかりのせいでもないかなと思うこともあります。ビジネス側の人が、開発側に、情報共有をしないことがあるからです。
- この製品は、市場でどのような位置付けにしたいのか
- どのようなターゲット層に売っていきたいのか（誰のどのような問題を解決したいのか）
- 売価、利益率
など
これらの情報を開発者に与えずに、ただ機能を次々に実装させたところで、ユーザに刺さるプロダクト・サービスを作り上げることはなかなか難しいです。