VPoTの丸山です。本日はClassiがいまのところどういうスタンスで技術選定に臨んでいるのかについてお話しします。これは「いまのところ」のスタンスであり、未来永劫このようなスタンスでいくかどうかというのは定かではありませんが、考え方のひとつとして参考になれば幸いです。
技術選定にハードリミットはかけない
結論から言うと、Classiでは「この技術スタックを必ず使ってください」という制限はかけていませんし、かけるつもりもいまのところありません。その理由は大きくふたつあります。
ひとつは、組織全体の視点でみた時に、技術スタックに関する健全な新陳代謝の機会を奪わないため、もうひとつは、メンバーレベルの視点でみても、複数の技術に触れる機会が成長につながるからです。
新陳代謝を行う機会を奪わない、というのは、どういうことでしょうか。
ひとつの技術スタックを極めていくことにも良い点はあります。ノウハウ、知識が集約されるので、高い効率で業務を進めていくことができるのはその最たる例でしょう。一方、すべての技術にはその得意とするところと苦手とするところがあります。たとえば、Go言語などは、高い並行性が求められるような要件に対しては得意だが、一方でコレクション処理を楽にかけた方が嬉しいような領域については少し苦手とするところ（まあ腕力でかけばいいので、そんなに問題にならない、という見方もできますが）でしょう。そして、プロダクトに技術的に必要とされることは決して現在過去未来を通じて一定ではありません。世の趨勢が変わり始めたときに、求められる要件に柔軟に対応していくためには、社内での技術の新陳代謝が健全に行われる必要があるでしょう。これはそんなに難しく考えなくても、たとえばEC2でapp serverを動かしていたのをECS Fargateで動かすようにしていくというような例を考えたらわかりやすい話だと思います。実行基盤のみに限らず、フレームワークや言語などについても「変化のための余白」を残しておくことは重要です。
もちろん、これが「正解のスタンス」だとは思っておらず、Classiにとってはそのほうがよい、というだけなので、採用戦略や、現在のメンバーの人数など様々な変数を見た結果、ノウハウ、知識が集約されるメリットを取るような判断も十分にあり得るはずです（この技術といえばこの会社！ というのは強いですよね）。
では「メンバーにとっても複数の技術に触れる機会が成長につながる」というのはどういうことでしょうか。
この話題は、事実判断ではなくてかなり価値判断よりの話になってしまうのですが、すくなくとも私は、異なった思想をもった言語や、異なった思想をもったフレームワーク、あるいは実行環境を学んだときが、エンジニアとして非連続な成長を実感できるときでした。それもそのはずで、エンジニアリングというのは常に判断の連続です。ある変数の名前をどういう名前にするのかだって判断ですし、どういうクラスをつくてどうモデリングするのかも判断の連続です。「正解」が用意されていてそれを選べばいいだけの仕事ではなく「より良い方法」を常に探し続けるのがエンジニアの仕事のはずです。そのとき、異なった考え方、異なった視座を身につけていることは、とても強力な武器になります。ひとつの問題を複数の視点から検討することで、「より良い正解」に辿り着けるはずです。言い方を変えれば、ひとつの見方しかできないエンジニアは「正解」に従うことしかできないが、複数の見方を身につけている場合複数の選択肢から「より良い正解」を導ける可能性がぐんと上がるはずです。
もちろん、業務で使っている技術スタック以外にもプライベートで学習することでこのような複数の見方を身につけることは可能ですが、結局のところ業務で扱うのが一番よく身に付く、というのはあると思います。
別の考え方として「ひとつの技術を深く掘っていった方が、隣接領域をすぐに理解できる」という考え方もあり、それはそれで十分に合理的な考え方だと思いますが、少なくとも弊社としては「業務で複数の考え方に触れるチャンスがある（必ずしも全員が触れるわけではないが……）」というほうがより良いだろう、という価値判断をしています。
どうやってガバナンスを効かせるか
一方、技術スタックを制限しない場合、無制限に好き勝手技術スタックを選択されてしまうと、今度は管理上の問題が生まれます。「やる気のあるメンバーがめっちゃ新しい技術スタックでキラキラした開発をおこなったけど、それをメンテ、運用できる知見は誰ももっていないあるいはだれにも継承されず、あとには触るに触れないコンポーネントが残った……」というような話は、残念ながらよく聞く話ではないでしょうか。
いまのところ、Classiでは「新しいことやるときは相談してね」くらいのゆるいガバナンスで運用しており、大きな問題につながっていませんが、そろそろこのあたりのガバナンス設計あるいは知識の流通の設計を始めていかないと、結局のところ先に見たメリット（組織としても新陳代謝ができるし、個人の成長にもつながるよね）も得られないという未来が見えつつあります。そのあたりはマネージャー陣と相談しながら、今後の課題として取り組んでいく必要がありそうです。
まとめ
今回はClassiの技術選定に対するスタンスと、今後課題になりそうな部分を紹介しました。技術選定についてはかなりいろいろな要因が絡む難しい話題であり、それこそその組織の置かれている状況によって「より良い解」が異なるトピックです。Classiのスタンスをあくまで一例として紹介しましたが、なにか参考になるような部分が少しでもあれば幸いです。
