はじめに
こんにちは。RettyのWeb・Appチームマネージャーのケイです。
Retty Advent Calendar 2021の21番目記事です。
この記事では、今年から始めたエンジニアリング部門の技術課題解決Working Groupの取り組みに関して紹介します。社内やサービスに似たような動きを取られたい方に少しでも参考になればと思います。
技術課題解決Working Groupとは
サービスを運用していると、様々な技術課題は付き物だと思います。 日々変化する技術や古くなってしまった仕組み、プロダクトの変化により、変えるべきなのに変えずになんとか運用しているもの、スロークエリなど様々な軸で技術関連課題は尽きないと思います。
Rettyは実は11年目に突入するサービスで、長年運用している分様々な技術課題が存在します。
うまく対応出来ている組織もあると思いますし、Rettyでも優先的に対応する必要があるものは部門、チーム、個人で対応しています。
しかし、優先順位が高くない技術課題というのも存在します。 いつかは解決したい、解決することで開発体験が向上するとか、デリバリー改善に役立つなど、メリットはありますが部門を上げて対応するほどでもないものの中で、特定チーム単体や個人ではなく複数チームや個人が議論して方針を決めて時間をかけて進めて行く必要があるものもあります。
そういう技術課題はどこかが担当していくと決まってもないものが多く、課題感は感じているんだけどなかなか手が手でないものがほとんどです。
そういった課題を、EM・MGRからのトップダウンではなく、メンバー自ら課題を選び、Working Groupを組み進めていき解決まで持ち込むのがこの技術課題解決Working Groupです。
課題解決以外の目的
このWG活動は技術課題を解決するという単純な目的以外にも何個かの目的があります。
開発体験の向上
メンバーが現場で課題感を感じているが、事業・施策展開などで解消できないものが対象になるので、エンジニア自らが困ってるものや、解消したいとモチベーションがあるものが対象になりやすいと思います。 そういった課題を自ら解決するので、比較的に身近な課題感を解消することで開発体験の向上につながると思います。
課題解決の全フローをメンバー自らやっていく貴重な経験
経験豊富なベテランばかりではないので、普段の施策展開、運用だけではない簡単に解決出来ていない課題を定義から解決まで経験する貴重な経験が出来ます。
技術課題を自ら解決出来るという自信
EMやMGRからの指示で動くのではなく、自ら考えて進めて解決出来る経験は良い成功体験になると思っています。 必ず解決できるとは限らないが、解決出来るように進めていくのもいい経験になると思います。
進め方
では実際どういう進め方をしているのかを紹介します。
全体像
大きく4個のフェーズで分けて進めています。それぞれのフェーズにはアウトプットが存在して、基本はそのアウトプットを成果として評価対象にもしています。
各フェーズ毎には適した・参加したいメンバーが異なることもありますし、業務状況的にWG活動が厳しくなる場面もあるので、メンバーの出入りはいつでも出来るようにしています。
メンバー自ら解決していく活動ではありますが、完全に自由にするのではなく、一定の条件下で活動することにしています。
- かけられる時間は上限を設ける
週に1−2時間程度にしています。普段の業務に支障がなければそれ以上でもいいですが、このWG以外でも採用やメンタリング、勉強会など様々な活動に参加しているメンバーも多く、ある程度限度を設けてその時間を超えるものはWGでやるものではなくプロジェクト化などで正式に必要な時間やメンバーを配属させる形にしていくことにしています。
- 各フェーズでは成果物を作る
WG活動はメンバー自ら行いますが、各フェーズの最後には必ず成果物を作り、EMに共有するようにしています。 各フェーズごとの様々な方向性や進め方、その結論に対するレビューが出来るのと、 業務時間を使って遂行するものなので成果物を作るのが当たり前と意識を根付かせるためでもあります。
フェーズ
各フェーズごとの内容とフォーカスするポイントを説明します。
WG立ち上げ
日々の開発現場で見つかった技術課題を解決するためのWGを立ち上げます。 Slackで思っている課題感を話し、それに反応して集まった人たちで構成するような形です。
課題定義
WGが立ち上がったら、課題を定義します。
課題感を持って立ち上げたので、その課題感をしっかり「課題」として定義する必要があります。
- どんな事象が発生しているのか
- どういう影響が発生しているのか
- 原因は何か
- 課題解決の結果何がどれぐらいよくなるのか
- それはWG活動で解決出来る課題か
などを議論したり調査していきます。
その結果を言語化し、アウトプットとしてEMに共有、EMがその課題を理解することでこのフェーズは完了となります。
このフェーズでは主にこの課題によって困ってる事象とその範囲、改善時に達成したい状態を描くことにフォーカスしています。
対応方法決定
課題定義が出来たら、対応方法をWG内で議論していきます。
このフェーズでは、対応方法と範囲が抽象化・肥大化しないようにフォーカスを絞り、小さく対応していくことを意識しています。 抽象化しすぎるとメンバー同士で解決出来る範囲を超えて組織や戦略の変化が必要になることがあり、肥大化すると影響範囲と使う時間が膨大になるため、どれもWGでやり遂げることが難しくなります。そうなるとこのWGの遂行でメンバーが得られる自分たちで最後までやるという経験できなくなります。
そのため以下のようなことを意識するようにしています。
- 対応方法は実際対応出来る部分と、エスカレーションしてPJ化するものに分ける
- WGでは実際対応出来る範囲の対応にフォーカスして、対応方法を決めていく
- 対応方法を小さく設定し、少ない時間を使ってゆっくり進めていくようにする
このフェーズはWG活動の中も得られるものが多いフェーズだと思っています。 上記の意識している内容は実はWGのためだけでなく、現在運用中のサービスの技術課題を解決していくために必要なことであるからです。
さっと議論して解決できるのか、周りを巻き込んだり上位レイヤーの意思決定などが必要かを考えたり、対応するとしたらどこまでをやるのかを決めたり、一気に全部作り直すのはリスクもコストも高く、小さく着実に進めていくことで実現出来るということを、EMからのトップダウンではなくメンバー自ら経験出来るので、技術課題を解決出来るそれ以上の価値のある活動になります。
対応
対応方法決定フェーズで決めた方針をEMと共有しGOサインが出たら対応していきます。 方法と規模によってはより適したメンバーがアサインされたり、PJ化してQの目標として設定してしっかり時間を使っていくようにするなど、解決に向けて適した方法と体制を作ります。 ものによってはすぐ対応してわかりやすい結果が出るものや、小さく長くやり続ける必要があるものもあるので、WGによってはすぐ終わるものも、半年以上かかっているものもあります。
実際の成果と変化
成果
2021年に入ってこの活動をはじめ、以下のような成果が出ています。
- 古いバッチサーバを新しいバッチサーバに移管
- ログの整備とログ収集仕組みの再検討
- 開発環境の快適化運動
- 外部とのデータ連携仕組みのリニューアル
上記のように実際改善・解決に繋げられたものが複数結果が出ているので、課題解決という目的は一定の成果があると思います。
変化
現場で課題感を感じた際、個人やチームですぐ対応できるものでなければWGでやるかの選択肢をメンバーが思うようになりました。 また、一部ではありますがメンバー自ら課題の規模感、対応方法を想像し、WG内で解決するか、エスカレーションしてPJ化していくかを考えて動き出すこともありました。
これまではエスカレーションによるEM・MGRの判断待ちになることが多かったですが、WGを設置して解決に持っていくか、という発想が芽生えたのが何より良い変化だと思います。
今後のための課題
上述の通り、WGは非常にいい取り組みだと思いますが、何個か課題が見つかっています。
- WGで解決できずエスカレーションしたものは今までと変わらない
対応方法がWGで収まらないものになり、EM・MGR層にエスカレーションしたけど、今まで進められてなかった理由は事業・施策展開などの環境によるもので、その環境が変わってるわけではないので実際対応まですぐ持ち込めないこともあります。その規模のものは動かすのが難しくなるのは当然ではありますが、せっかくWGで進めたものなのでしっかり時間をかけてでも進めていきたいと思っています。
- 常設は難しい
事業や施策展開の状況によって、全社的に開発メンバーに負荷が高くなるタイミングもあり、常時運用するのは難しいと思います。 現在は私の新規WG展開しましょう！と声掛けからWGの募集が始まる流れになっていますが、私が声掛けしなくても余裕が出来たらメンバー自ら課題発見からWG設置行けるような文化にしていきたいと思っています。
終わりに
技術課題解決WGは、技術課題の解決をトップダウンではなくボトムアップで行い、技術課題の解決とともにメンバーのスキル・PJ推進・やり抜く力の底上げを狙った取り組みです。 少ない時間で改善と経験を作っていくための仕組みとして一つ良い事例だと思いますので、この記事を読んでいる方々も同じ課題感がございましたら、お試しいただければいかがでしょうか。
お読みいただきありがとうございました。
