こんにちは・こんばんは・おはようございます、System Platform領域所属の
id:aerealです。
前回このブログに記事を書いた時の所属から変わり、チームトポロジーを参考に編成された新たな領域でチームを横断した関心事に取り組んでいます。
当社ClassiはRubyを主要な開発言語として採用し、各種Ruby関連のイベントに参加・協賛するなど「Rubyの会社」という印象を持たれているのではないでしょうか。
実際、今もClassiの屋台骨を支えているシステムはRubyで書かれていますし、今後1〜2年でそれが大きく覆ることは考えにくいでしょう。
そんなClassiに新たにGoという選択肢を有力なものとして加えるための過程と取り組みについて紹介します。
Classiの技術選定と手札たる要件
Classiの技術選定に対するスタンスと題したVPoTの丸山が書いた記事にあるように、この記事を執筆している現在は「この技術領域にはこれを使ってね」といった強い制約はありません。
一方で先の記事でもやる気のあるメンバーがめっちゃ新しい技術スタックでキラキラした開発をおこなったけど、それをメンテ、運用できる知見は誰ももっていないあるいはだれにも継承されず、あとには触るに触れないコンポーネントが残った……
と触れられているように、闇雲に採用技術を発散させることを一概によしとできません。
このトピックに対し私なりに出した答えが社内コミュニティができて盛り上がっている状態になれば、技術選択の第一候補として置いてよいだろうというものです。
そもそもスキルや知識を持った開発者が存在しさえすれば良いのなら「新しい技術スタックが採用されたが、次第に腫れ物になってしまった」という出来事は起きないはずです。 たとえ提唱者が退職その他の理由で離れてしまったとしても、採用や育成をすればカバーできるはずです。
そこで私は「触るに触れないコンポーネント」ができあがってしまう力学に目を向けました。 そこからClassiの事例や自身の経験に照らして、なぜ触れない・触りたくないと思うかを考えると新しい技術に触れるリスクや恐怖が期待されるおもしろさやメリットを上回って見えるからだという仮説を導きました。
我々ソフトウェアエンジニアはプロダクト開発を通して顧客に価値を届けることが大前提で、他に求められる種々の資質などは細分化された結果のものです。
価値の中には提供速度や信頼性・安定稼働といった要素も当然含まれます。これらを満たすため、新しい技術を採用したコンポーネントを保守しつづけることを諦め、より廃止ないし・よりコンサバな技術セットで作り直すという判断に至るのでしょう。
またリスクや恐怖がおもしろさやメリットを上回って 見える ということも肝だと考えます。
人間は未知に対する恐怖心を抱えがちです。栄枯盛衰の激しい業界に身を置く我々Webエンジニアであっても多かれ少なかれそれは避けられないはずで、恐怖心は認知バイアスを呼びます。
認知バイアスがかかった状態では望ましい判断を選びにくくなってしまいます。
冷静かつ丁寧に事実を集め評価すれば悪くない選択肢だったとしても、負の側面が大きく見えるのなら「失敗だった」という判断になりえます。
またバイアスだけではなく感情的な要素も無視できないでしょう。「新しい技術を試行錯誤するおもしろさに立ち会えず、ただ尻拭いをさせられている」という意識は事実や理屈でそう覆せるものではありません。
これらのことから特定の誰かではなく社内でうっすらと盛り上がっている・ムーブメントが起きているという状況を作ることができたらもはやその新しい技術は未知のものではなく「自分はよく知らないけど社内ではよく聞くアレ」になります。
また、そういった状況を作ることができれば提唱者個人の負荷も減るでしょう。
取り組み
実際にGoの社内コミュニティを作るためにやってきた取り組みを紹介します。
Slackチャンネル
何はなくともまずSlackチャンネルです。5年以上前に作られたけど過疎ってarchiveされたチャンネルを掘り起こし #go-zassou として復活させました。
とはいえunarchiveしたからすべて良しとは当然なりませんので、まずは自分がGo関連のニュースや記事を紹介することから始めました。
おもしろそうなライブラリを紹介したり、カンファレンスの発表資料を紹介したり、内容は様々です。 とにかくチャンネルに人がいる感を高めるために「こういうところがおもしろそう」というコメントを添えて隔日〜週数回ペースを当初保ちました。
また社内でGoを採用したコンポーネントの開発に関する相談や質問は積極的に他のチャンネルからこちらに誘導しました。
たいへん地味でしたが、ここ数ヶ月では自分以外のメンバーが興味をもったニュースや記事を紹介してくれたり、自発的に質問してくれるようになったので、archiveされて存在がなかったころに比べたら盛り上がっていると言ってよいのではないでしょうか。
もくもく会、A Tour of Goをやる会
筆者以外はGo初学者であったり過去に趣味で触っていたけれど今はご無沙汰しているといったメンバーが多いです。
そんなメンバーのキャッチアップを盛り上げるためにA Tour of Goをやる会を不定期で開催しました。
それぞれ進度は異なるので画面共有して同時に進行したりはせず各々で進める、いわゆるもくもく会形式をとりました。
気軽に質問できる環境を提供することが目的で「そういう会があるなら」と参加してくれたメンバーも一定いたので成功したといえるのではないでしょうか。
ライブコーディング
ライブコーディングに参加することで、細かいエディタやツールの使い方からいわゆるGoらしい書き方・設計の勘所など情報量の多いインプットを得ることができるでしょう。
基礎知識を得た状態から次に実践的な開発に入る上でライブコーディングは広く満遍なくとっかかりを得るのに適しています。
またライブコーディングに参加できなかったメンバーにはGoogle Meetの録画機能を使って動画も共有しています。
野良レビュー
私個人が開発に関わっていないGoを採用したコンポーネントも登場してきたので、一通りのコードリーディングをしてコミットも見ています。
本番提供するサービスとしてより望ましい・より高い品質を狙える点はたくさんありますし、それらを一度にくまなく説明しきることは難しいので、ベストエフェートで発見次第、Issueを立てたりPull Requestを送っています。
カロリーの高い取り組みなので新しい言語や技術を導入する際にはこれくらいやるべきとは言えませんが、個人的にいろんなコードを読むのが好きな性質なので自分の楽しみになる上に実利も備えられてラッキーくらいの気持ちでやっています。
成果
- 本番投入サービス開発経験: 1人→5人
- 本番投入サービス: 1つ→3つ
数字でみるとこのような結果になりました。
また嬉しいことにサービス開発を通じてライブラリを作ってくれたメンバーも現れました。
https://github.com/minhquang4334/goapartment
マルチテナント構成のDBに対しテナントに応じた接続を提供するライブラリで、ちょうどマルチテナントDBを擁するClassiにとって今後必要になることが明らかだったので、そこにチャレンジしてくれたことと品質に驚き感謝しています。
今後
まだまだ精力的に盛り上げているのは私個人なので、私がClassiからいなくなってもGoの新規採用が続く状況になったとはいえないでしょう。
ただ、既にGoを採用したコンポーネントのメンテナンスに意欲を向けてくれる状況にはなっているのではないでしょうか。
実際にそういったシチュエーションを迎えていないので評価は難しいのですが、実際に使う・読み書きするというコンテキストでGoの話題を口にしているメンバーは増えたので良い方向に変わっていると信じています。
