成長か安定か:技術への挑戦とトレードオフ
技術選定やアーキテクチャは常にトレードオフの問題です。運用のシンプルさを追求することもあれば、リスクを取り、新しい技術に挑戦することもあります。しかしながら、ビジネスに携わるエンジニアの多くは3年ほど経験を積めば、運用の容易さを理由に技術の統一を主張する様になる傾向を感じます。
始めに伝えておくと、技術の統一は正論です。私が所属してきた組織でもそういった戦略が採られてきましたし、私自身、技術の統一を主張してきました。しかし、この考え方にもリスクが伴います。
それは成長の停滞、可能性の狭窄、仕事の新鮮さの喪失、他社と比較した技術の陳腐化による採用競争力の低下など、結果的に人材の流出を招く可能性があります。私自身、このような理由で前職を退職した経験があります。(運用の負荷を下げるつもりで技術を統一しましたが、結果的には組織の運用負荷を上げたでしょう)
知的好奇心を満たすようなテクノロジードリブンな姿勢は、チームに仕事の楽しさと共に新たなエネルギーをもたらします。問題はいつ挑戦するかです。組織で働く私達は意識して挑戦する姿勢を保たないと、実績のあるシステムの焼き増しという選択を採り、保守的になりがちです。
挑戦するタイミングはリスクが小さいほど良いです。技術や設計の選択があるならば、リスクの比較ができるでしょう。挑戦する事のリスクはもちろん、挑戦しない設計、技術選定に伴うリスクもまた天秤にかけるのが良いでしょう。
話は少し逸れますが、メンテナンスの容易さという観点では、変更のしやすさは特に重要です。私はこれまでにC、C++、Lua、Java、Scala、Kotlin、Python、PHP、Perl、Shell、Javascriptなど、多くの言語を業務で扱ってきました。その経験から言えば、言語選択はメンテナンスのしやすさに影響を与えますが、それが致命的な問題になることは少なかったです。メンテナンスのし辛さは適切ではないアーキテクチャ、モデリング、凝集度による影響の方が大きかったです。
小規模な開発では技術的な挑戦を奨励し、新しい技術を積極的に取り入れるべきだと私は考えます。しかし、それは一人ひとりが好き勝手に技術を選定するという意味ではありません。大前提としてシステムの要件に適合する事は必要です。その上で、チーム全体でその技術を学び、メンテナンスしたいと思える技術選定を目指すべきです。こうする事で、チームは技術的な革新を追求しつつも、運用の実現可能性と成長の機会を保持することができます。
同じシステムに、あるいは同じ様な構成のシステムに携わりたい人もいるでしょう。しかし私を始め、技術を探求するエンジニアはより多くの構成に触れ、新しい知識、経験を欲し、より優れたシステムを作りたい欲求を抱えています。私たちはCI/CDなどには怠惰である事を追求しますが、技術には貪欲でいたいのです。
Discussion