Cybozu生産性向上チームのインターンに参加しました
どうもこんにちは、最近はロボコンを引退したあともCI/CDとインフラ盆栽芸をしているマンゴーさんです。
9月頭の2週間で、サイボウズ株式会社の生産性向上チームにサマーインターンとして参加していました。
今回は、インターンの中でやったことや気づいたこと、考えたことについて書いていければと思います。
生産性向上チームについて
生産性向上チームは、サイボウズ株式会社の開発チームの中で、開発者の生産性向上を目指して活動しているチームです。
詳しい内容はこのスライドにまとめられています。
大まかに紹介するならば、「プロダクトの開発速度を上げること」や「社員の負担を減らすこと」を目標に、計測から改善までを全社一貫して行っているチームです。
開発体験をより良くする情報を探し、提供することから、開発で利用するCI/CDインフラの準備まで、幅広い内容で活動しています。
インターン参加まで
エントリーした理由
まずは、「生産性向上チーム」という（もしかするとよくわからない）チームに興味を持った理由を書いていきます。
CIを使うといったことは以前からやっていたのですが、「生産性向上」的な課題に興味を持ったのは、ロボコンでのチーム開発でした。
ロボコンでは、通常4人などのある程度の人数で開発をしています。そして、納期は大体の場合で短く、出来上がってくるソフトウェアの品質なども人によってバラバラです。
しかし、そうした状況下でもやはり品質はある程度でいいので高くあってほしいものです。
そのため、CI/CDの仕組みの導入を始めました。
その結果として、ロボコンでは、CIとしてコードのテストやLintを、CDとしては共通のライブラリをaptのレポジトリとして取り扱える仕組みを用意しています。
こうした仕組みが、ソフトウェア開発をしていくメンバーへの、品質への関心を高めてくれることにつながると良いなと思っています。
この仕組みを用意する中で、GitHub Actionsのセルフホストランナーなどを利用していたり、ロボットから得られるデータをソフトウェアの改善やモチベーションアップにつなげたいと考えたりしていました。
そうしたことが、実際の企業ではどういう形で行われているのかを知りたいというのがインターンへエントリーした動機になっています。
選考など
選考は書類選考と面接でした。「生産性向上」についての自分なりの意識をまとめておくと良いかもしれません。
インターンでやったこと
インターンは、2週間で完全にオンラインで行われました。その中で「GitHub Actionsセルフホストランナー」についてのチーム（レーン）で仕事をしていました。
仕事は（有名かもしれませんが）すべてモブプログラミングの形式で行われていました。チームによっては、普段はそうでないこともあるそうですが、インターン中はメンターとして付いてくださる関係でモブプロをやっていました。
また、チーム固有の面白い制度として「探求タイム」というものが用意されていました。これは、個々人で好きなことを調べて知見を広げようという時間で、某社の「20%ルール」に影響されて作ったとか…。
インターン中は、この時間で翌日のタスクに関係することを調べたり、はたまた自由に気になることを調べたりとしていました。
タスク: GitHub Actionsでよく使われているソフトウェアを集計しよう
今回は、ランナー基盤で動作しているActionsのWorkflowで、どのようなソフトウェアがよく使われている（ダウンロードされている）かを集計する機能を作成していました。
この背景として、チームがAWSを利用して構築しているランナー基盤で、NAT Gatewayの転送量によるコストが大きいので、削減したいということがありました。
何が転送量を占めているかというのはハッキリしていませんでしたが、そのうちの1つとして、実行時にダウンロードするソフトウェアが影響しているのではないか、と考えられました。
その仮説が正しいと示すため、また、対策を考えるために計測しようというのが今回のタスクでした。
なお、今までのコスト削減まわりの施策はセルフホストランナーのAWS費用を30%削減するまでの道のりなどを見てもらえばと思います。
このタスクでは、各種ツールセットアップ用のAction（@actions/setup-nodeなど）を対象にして集計をします。
転送量にどれくらい影響するかを調べたかったため、ダウンロード後の容量を調べることにしました。
ということでまず、ダウンロードされたものが、どこに保管されているかを調べました。
すると、公式で出ているソフトウェアについては、/opt/hostedtoolcache/{software name}/{version}に入っていることがわかりました。
さて、続いて、これをどうやって集計するかを考えました。
この集計のために新規で何かを開発することはあまりしたくなかったので、S3+Athenaの組み合わせでの解析を選択しました。
AthenaはS3にある各種データファイルに対して、SQLを用いてクエリを実行できるというサービスです。
これを使うことで、データを適当にS3に投入するだけで、統計分析ができます。
今回はGROUP BYなどのSQLをもちいて、どのソフトウェアがどの程度ダウンロードされているかを分析します。このクエリを作るところも、いろいろな案が出たりして苦労ポイントでした。
ここまで決めれば、あとは容量を記録し、S3に転送する機能を作成していくだけです。
機能自体は、Github Actionsのランナーにジョブの前後で任意のスクリプトを実行できる仕組みがあり、それによって呼び出されます。
この部分は、依存関係を増やしたくなかったこともあり、シェルスクリプトで作成していて、dfコマンドやjqコマンドにより成立しています（この部分の作成の調査で探求タイムを使ったりもしました）。
そして、そのスクリプトをランナーに使うEC2用のAMIに組み込み、staging環境での実験を行いました。
動作しているようだったので、インターン期間中にproduction環境への反映までを行うことができました。
反映後、AthenaのSQLを用いて調査も行い、とあるバージョンのPythonが頻繁にダウンロードされていることも判明しました。
タスク: よく使っているPythonをAMIに組み込む
頻繁にダウンロードされているPythonを予めダウンロードしておくことで、転送量を削減しようというタスクです。
これは、setup-pythonのActionを参考にして行いました。
Actionを参考にすると、まず/opt/hostedtoolcacheを確認してインストールがすでに行われているかを確認します。
続いて、GitHub Actionsの提供するレポジトリから、圧縮されたPythonをダウンロードし、その後中に含まれているsetup.shを適切に実行することで、インストールが行われます。
AMIに組み込む上で、インストール済みの判定を得られて、その上で正常に動作する状態にする必要があります。
AMI作成の仕組み上、setup-pythonのJavaScriptでできたスクリプトを動かすのは難しかったため、これをシェルスクリプトを使って表現し、AMIに組み込むことで転送量の削減を狙います。
タスク以外のことについて
開発タスク以外にも、インフラ部門との交流や、（オンラインとはいえ）昼食をともに食べたり、懇親会をしていました。
他部門のことだけでなく、仕事選びの軸や、前職の話など、いろんな事情を聴くことができて、たのしいだけではなく、有意義な時間だったと思います。
また、今後オフィスでの懇親会も予定されているので、いっぱい喋って相互理解を深められたらうれしいなと思っています。
振り返って
インターンは夏休み期間で2つ、ほぼ連続で行っていたこともあり結構大変でした。
そんな中でも、楽しく仕事を行えて、さらにある程度の成果という形で爪痕を残せたことはとてもうれしかったです。
メンターの方や人事の方など、協力していただきありがとうございました！
Discussion