技術基盤チームとして働いてみて
この記事は Sansan Advent Calendar 2016 - Qiita の代理記事です。年は明けてしまっていますが、残った枠が出ていたので埋めておこうかなと。
ここで話すこと
- 私が所属する部門で初めて技術基盤チームを置いたことの背景や、活動について
- 技術基盤チームを置いたことで、初めてチームが分割された時に起こったこと
弊社には運営するサービス + αの開発部門が存在するため、あくまでそのうちの一つの部門の話になります。
どういう部門の技術基盤チームか
所属する開発部門はエンジニアが入れ替わりはあれど 10 名程度所属しています。（インフラエンジニアさんは別に 2 名所属しています）
運営するサービスは足掛けでいうとおそらく運営開始からは 3 から 4 年経っていると思います。
私自身はその開発部門には 3 年程前から部署異動で参加しており、サービスの運営開始から半年から 1 年程経った時から加わっています。当時は弊社には珍しくパートナーさんがメンバーの大半を占めており、社員としては 4 人目の開発メンバーでした。
技術基盤チーム
途中で名称が変わったりしていますが、技術基盤チームとしては昨年の 6 月ぐらいに公式に動き始めました。
PM の役割も兼ねてくれているリーダーが一人と、私を含むプログラマが二人の 3 人体制です。
どうして作られたのか？
開発部門のリーダー（技術基盤のリーダーも兼務）の危機感によって作られたようです。
- サービス自体も運営開始から時間が経ち、少しずつ現状にフィットしない部分が顕在化し、開発スピードに影響してきていた
- 新メンバーを迎える事も少しずつ増えてきた
- 過去にリリースを優先する中で妥協した部分をそのまま流用するケースも出てきた（割れ窓が広がってきたとでも言うのでしょうか）
- サービス拡大する中で、現在進行でもリリースを優先するための妥協が目につくようになってきていた
- そういう事を開発メンバーも気にしており、KPT の場でも度々問題にあがっていたものの、事業優先の中で着手することがほぼできなかった
他にもあったかもしれませんが、リーダーの意図としては「分かりやすい形で別働隊を作らなければ、この状況は広がるばかりになってしまうから作った。」という感じだったと記憶しています。
設立に関して部門内での反応はどうだったか？
当時のサービスの状況としては、1 年程度取り組んでいたプロジェクトが一旦の収束をした中で、ある程度直近のやるべきことがみえていたという状況だったこともあり、企画・運用といった開発チーム以外からのリアクションはそれほどなかったように思います。（おそらく、そこでそのやるべきタスクが消化されない状況になっていれば変わったのだと思います。）
逆に、開発チームの方からのリアクションが大きかった
開発チームは長らく 1 チームでの活動で、週次の計画や振り返り・日々のサービス運用、コードレビューにいたるまで全て全員で行っていました。リーダーの意図としては技術基盤チームを作ったとしても、計画やアサイン以外はこれまで通り行うというものでしたが、一部からは「それでも分割には反対だ」という意見が出ていました。
当時のチーム分割に関する意見
実は技術基盤チームの話が出る前から「10 人は多すぎるのでチームを分割しよう」という話がちらほら出ていました。
- 事実上進行するプロジェクトに応じて複数チームで動いているような感じがあった
- そうなると、コードレビューもコンテキストが完全に共有しきれないので、結局そのプロジェクトメンバー内でレビューすることもあった
- サービスも大きくなってきて、全員が全てのコンポーネントを理解し、「いつでもどこでも誰でも同じ共通の見積もり規模で開発できる」というのは非現実的になってきた
- 何かの開発を始める時に開発者全員に説明をするための説明コストもばかにならなくなってきた
他にもあったと思います。ただ、どの問題をとっても「分割した方がいい」「いや、1 チームでもできる解決策はある」と双方に納得できる理由はあったため、決めきれないという状態でした。
が、最終的には「まずは半年やってみて状況を判断する」ということで技術基盤チームはスタートしました。
技術基盤チームとしてやったこと
世の中で「技術基盤」という用語を使った時に、どういう事をやるかは様々だと思います。インフラ的な事を指したり、CI/CD といった開発プロセスの整備を指したり、はたまた各プロジェクトを横断して関わり、共通に使える部分や、コアになる部分の開発を担ったり、組織によって担当することは異なると思います。
優先順位
私が所属した技術基盤チームでは以下の優先順位で動きました。
- 技術基盤チームだが、優先度の高い事業要求が入ればそれを優先して開発及び他チームへのヘルプに入る
- 技術基盤チームで選定したタスクを行う
はい、単に事業要求優先とうだけですね。これは、企画・運用チームや、開発チームに対する「あくまで我々は事業要求を優先する」というスタンスの提示でもありますし、実際 2 ヶ月程は事業要求に関するタスクも実施していました。
タスクの選定基準
タスクの選定としては大きく以下があります。1 を別にしましたが、実際には負債は解決すると Developer Experience にも寄与するものが多いので、軸としてはあまり変わらないかもしれません。
技術的負債
正直この用語を使うのもどうかと思いますが、ここで指しているのは大きく以下の 2 点です。
- 前クォーターなど、比較的最近にリリース優先などで意図的に積まれたもの
- サービスの開発・運用を続けていく中で、徐々に日々の開発を阻害してくるようになったもの
特に 2 に関しては以下の記事で出て来るような当時は要求に対して適していたものが、様々な理由で負債化していってしまったようなものを指します。
余談ですが、成長し続けるサービスを長く続けていると、技術の進化も当然ありますし、営業や顧客からの要望にどうしても急ぎで応えなければいけない時も多々有り、時間が経つと「どうしてこうなった」というコードは多々でてきます。
私自身弊社に入社した時には同じように C# 版のコードを見て「なんだこれは」と思い苦言や何の意味も無い正論を言った記憶もありますが、逆の立場になると本当に馬鹿な発言だったなと思います。
そして、逆の立場になって事業的にも安定した状況で入社してくる人にそういうことを言われると、なんというか辛い気持ちになってしまい、「ごめんね」としか言えないという。。
ある時点で「これが正しい」というのは簡単かもしれませんが、そこに歴史やコンテキストがあるものに対しては言葉や行動を選ばなければいけないなぁと思ったりする最近です。
DX (Developer Experience) と事業インパクト
この 2 軸自体はリーダーが提案してくれたもので、個人的にも違和感はありませんでした。開発しやすい環境作りに寄与したいものの、やはり事業的にも意味があればそれはより嬉しいものなので。
ここのタスクは本当に様々です。例えば以下のようなものですね。
- 遅くなってきた CI の速度アップ
- 手動で行っているリリース前の検証手順を自動化
- リードレプリカを手軽に使えるようにする
- DX が高い
- DB の schema migration を無停止で実施できるように
- リリースの手間が軽減される事に加えて、サービスの停止時間が短くなるので事業的にも貢献できる
- DB での障害発生時の影響を小さくするための施策
- これも障害時の手間の軽減に加えて、サービスの停止時間を短くできる可能性がある
他にも、Rails や Ruby などのバージョンを上げるなど、多岐に渡ります。それをチーム内で 2 軸にマッピングし、優先度を付けていきます。
実際にはクォーターでの時間は限られるため、単純に上からではなく、合計で 3 ヶ月に収まりそうなタスクをいくつか選び取ります。
成果としてはどうだったか？
まだ半年程度の活動でしたが、結果として現在も技術基盤チームは継続できています。
事業優先のタスクを 1/3 ぐらいやっていたり、実施できたタスクも比較的中小規模もものが中心でしたが、好評のものが多かったので選定自体は良かったのかなと思っています。
（特に複数 DB 用のライブラリを octopus から switch_point に変えたのは好評でした）
今期は、データを溜めていく部分の大きめの入れ替えを予定しているので、それが初めて 基盤 という名前らしい仕事になるのかもしれません。
チームを分割した事はどう影響したか
個人の感想にはなりますが、影響はあったように感じます。
- 技術基盤とそれ以外のチーム間でも当然ながら着手するプロジェクトの説明会は行うが、小粒のものは各チーム内で閉じることもあった
- なので、「ああ、こういうことやってるのね」というのをコードレビューで知るとかもあったり
- コードレビューを行う人の偏りは目立ってきており、油断するとレビューリクエストが溜まり続けるという事も散見された
- チーム横断して見る人も居れば、自分のプロジェクトの範囲中心にしか見ない人も
一方で、少しずつそれを皆が暗黙的に認めてきた中で、そういう動き方に対応したレビューリクエストの説明文の書き方になってきたようにも思います。多少面倒でも背景の説明や、コメントの充実がはかられているように思います。
チームとしての意識の分離
やはり発生していて、他チームの状況が少しずつ分からない事が増えてきたというのは事実です。一方で、それは自分のフォーカスするべきタスクに集中できる時間が増えているとも言えて一長一短だなと思いました。
この辺は個人的にも葛藤があって、時間をかけて他のプロジェクトも気にするようにすると気持ちはいいんだけれど、自分の仕事が進まない。だけど逆をやると申し訳ない気持ちになる。
半年を振り返ると、本当に最初から最後まで分からなかったプロジェクトもあれば、比較的気にできたプロジェクトもあるという感じで難しさを感じています。
現在は技術基盤チームのメンバーは他チームのコードレビューにも貢献できていますが、それがもしできなくなるような状況になったら、完全にチームを割るにせよ、また一つに戻すにせよ、立ち止まる必要があるのかもしれません。
リモートワーカーとしての立場
正直に言えば、対話が必要な人数が減ったのでコミュニケーションは楽になりました。これまでは、社内 SNS 等でできるだけ拾う必要があったものも、チームに朝会だけで必要十分な情報が得られるようになりました。
人数が多いと「できるだけ朝会は必要最低限に」という意識が働いてしまっていたのですが、人数が 3 人だと少々込み入った話をしても、それは間違いなく全員に関係あるので遠慮なく話を掘れるので、その点も話すためにいちいちリモート越しに人を招集しなくてもいいというメリットになりました。
レビューリクエストの説明が厚くなったのもダイレクトに嬉しいものでした。対面していれば「ここってなんでこうしたんだっけ？」と気になった事を聞くのは 2 秒ですが、リモートだとチャットも待ちになるので面倒なんですよね 😅
加えて、企画・運用との調整の繰り返しを行うサービス側とは違い、ある程度どうするかを決めれば、後は自分たちで調査と実装をしていくという事が多かったので、静かな環境で働ける身としては集中できている時間が長かったように思います。
技術基盤チームのメンバーはどう人事的に評価されたか
これまでもプロジェクトの成否で個人の人事的な評価をされるような事はありませんでしたので、技術基盤チームという直接的に事業に貢献することが少ない部門に移ったからといって、評価内容が変わることはありませんでした。（インフラエンジニアさんも多く所属しているので当然といえば当然ですが）
一方で、上長からは技術基盤として目の前のタスクだけではなく、チーム全体の技術面での貢献や、技術者としてリードする方法を考えていって欲しいとコメントを貰い、そういう意味ではこれまでとは違ったカットで個人の評価はされるようになっているのかもという印象を受けました。（言うてもチーム内では年長組なので、単純にしっかりしろってことなのかもしれませんが 😅）
余談
チームメンバー構成について
当時は、技術基盤チームはリーダーを含めて、開発チームで子供が居る 3 人が集まっていました。（現在は別チームに子供のいる人が加わったのでそうではないのですが）
これはリーダーが意図的にそうしたというよりは、集められたプログラマ二人が、その前からパフォーマンスのことを中心に見ていたり、ミドルウェアあたりのことをよく見ていた面子だったので自然とそうなったのだとは思います。
思い返してみると、私は部署異動前も含めると 7 年近く Web サービスを見ていましたし、もう一人の方も前職ゲームを運営していたりで、チームの中でそういう運用歴の長い二人が選定されたのかもしれません。
といいつつ、たぶん弊社はサービスとか目的に価値を置いている人が多いので、そこから離れてもやってくれそうな二人だったのかもしれません 😅
子育てエンジニアと技術基盤の仕事
企画よりの仕事をしていると、やはり KPI に早く反映したいしで「明日でもいいんだけど、今日やってしまうと嬉しいよなぁ」とついつい定時以降もやってしまうことが多かったのですが、そうすると子供をお風呂にいれるのに間に合わなくなってしまうんですよね。。（当時は子供は 20 時 - 21 時の間には寝てしまっていたので）
技術基盤チームでは、一旦そういうことからは離れたことに加えて、タスク自体が比較的大きいものが多いのでそれを計画して、その日に倒せる分だけ倒すというのがやりやすかったように思います。
とはいえ、これは部門としてもビッグプロジェクトが終わって比較的安定した時期にはいったからというのもあったからかもしれません。
私個人としてはちょうど 0 歳時を育てていた時期だったので、その仕事のやり方がとてもありがたかったですし、チームメンバーが皆子育てしている人という状況が単に心地よかったのかもしれません。
そういう意味では若くてガツガツしたチームとかに今後入ることがあったら、どう感じるのかなぁという。
