この記事について
タイトル通り、2023年に提案されて改善した事を発表するのですが、裏返すと「そんなこともできてなかったのか」と見える内容もあるかもしれません。ネガティブに受け取られる可能性もあるかもしれませんが、IVRyのオープンな社風や、常に改善と変革に前向きな姿勢をアピールするためにも、この記事を執筆することにしました。
なお、課題を発見・解決しながら会社を大きくしていきたいエンジニアの皆さんは、ぜひブログ一番下のIVRyの採用情報から応募してください！
また、同じような課題を抱える方々にお役に立てれば幸いです。
Design Doc書いた方が良くないですか？
2023年のIVRyのエンジニアチームは、コードを書く前の段階の議論をドキュメントに残す文化がありませんでした。正確にはそう言った活動を全くしていないわけではなく、案件や人によって書く書かないがまちまちでした。
その課題を指摘され、導入されたのが、Design Docですす。
Design Docは簡潔に言えば、コードを書く前に設計の素案を書き、チームで議論するためのドキュメントです。
Design Docの詳細はここでは触れませんが、下記にリンク集を入っているので深く知りたい方は是非チェックしてください！
IVRyでは、Design Docを書く目的を以下の通りと定めています。
- 修正しやすい段階で、設計をチームでレビューしておくことで手戻りが少なくなる
- 設計の合意形成
- 懸念事項の明確化
- 有識者にレビューしてもらうことでその知識を設計に反映させる
- 設計について議論する場所の集約
- ドキュメントを残すことで、新しいプロジェクトメンバーがキャッチアップしやすくなる
この文化はIVRyで浸透しており、現在は設計が絡む実装は必ずDesign Docを書いて合意を取ってからコードを書くようになりました。この文化がチームが増える前に浸透したことで、開発効率が向上し、手戻りもかなり少なくなりました。
さらに副次的な効果として、コードを見なくてもDesign Docを見ることで、直接関与していないチームも何を作っているかが把握できるようになり、具体的な取り組んでいることの共有にも非常に有効な施策になりました。
朝会(進捗報告)無くても回るんじゃないですか？
毎朝行っていた朝会に関する話題です。やった事、やる事、困っている事、などを共有する場として毎朝行っていました。ただ、人数増加に伴い全員参加で朝会を行うと、ただ進捗を報告するだけの会になってきていました。
IVRyはプロジェクト制という組織構造を採用しており、プロジェクト間の兼務も多いため、朝会を綺麗にチーム分割することは非常に難しい状況でした。
(プロジェクト制については下記を参照)
どうすればいいかずっと悩んでいた時に、「朝会は必要なメンバーが必要に応じて、任意で開催すれば良いのではないか」という意見をもらいました。もっと平たく言えば「朝会はなくても良い」という意見です。
かなり大きな改変で、徐々に無くしていく？という意見もでたのですが、最終的にはIVRyらしく「思い切って2週間朝会無しを試して振り返りをしよう」という結論になりました。
予め懸念事項を洗い出して振り返る
良い動きができたなと思ったのが、後から振り返るだけではなく、朝会を無くす「前」に予測される懸念事項をチームメンバーから集約して、それをドキュメントにまとめ、２週間後のKPTでその懸念事項がどうだったかを振り返ったことです。このおかげで建設的な議論と決定ができたと思います。
あらかじめ出た懸念事項として
- チームの進捗状況が把握できない
- リリース状況が把握できない
などがありました。2週間試した結果、朝会をやらなくても下記を守れば問題が無いのでは？という結論になりました。
朝回を無くす代わりに守ること
- 週に１回のプランニングでスプリントでのやることの合意を取る
- これまでも合意を取っていたが、朝会での進捗共有が無いのでこの時点で「やり切る」前提の合意をとる
- プランニングで約束したものは基本的にリリースされる前提とすることでリリース物の把握ができる
- 上記の合意を取った上で、タスクが消化できないアラートは自ら発信する
- 差し込みのタスクが入った場合も、自ら相談してタスクを整理する
- 必要だと感じた時は、進捗の共有は任意で開催する
上記の決定のもと、最終的に朝会を消滅することになりました。消滅後はIVRyのエンジニアメンバーそれぞれのセルフマネジメント力を高めて開発をする必要があります。朝会が必要だと感じて朝会を開催しているチームもありますし、必要なメンバーで必要な進捗の共有を定期・不定期で開催もできていますし、このまま今後も朝会は消滅したままチーム運営していくと思います。
(この朝会の消滅に関しては、2023年11月から試して執筆時点ではまだ1ヶ月ほどしか試せていないので、別の形の何かに変わる可能性もあります。)
毎日リリースしません？（今取り組み中）
これはまだ実現できていないことですが、IVRyは来年リリース頻度を増やす取り組みを行う予定です。リリース頻度をなぜ増やした方がいいのかについては、IVRyのエンジニアがブログを書いているので、ぜひそちらをご覧ください。
これまでのIVRyはスプリントと同じ周期である１週間に1回のリリースを行っていました。電話という高いサービスレベルを維持するための目的からきており、リリース前に必ずQAを通してからリリースしていました。
ただ、このサービスレベルはサービスによって強度を変えられるはずですし、頻度を高くした方がむしろサービスレベルを高くする事もあります。
この改革を行うためには、テストを高速化したり、切り戻しの速度を早くしたり、リリース運用を整えたり、いくつかの課題があるため、この課題に取り組んで実現をしたいと思っています。
雑談少なくないですか？
最初に誤解を解いておくと、チーム内の関係は良好であり、むしろ仲が良いチームだと思っています!笑
ここで言う雑談とは、「今のチーム運営の〇〇の部分を変えたいんですよねー」とか「最近この〇〇っていうサービスがイケててー」など、特にどの会議でも話題に上げないが、新たなビジネスやチームやソフトウェアの改善に繋がりそうな雑談を指しています。
「こうした雑談はもっと多くした方が良いよ」という指摘を受け、早速IVRyでも試してみました。まず、週に一回コーヒータイムという時間を作り、オフラインで皆んなでコーヒーを飲む時間を作りました。この時間は忙しい人は参加しなくても良く、完全任意です。このコーヒータイムでチーム横断で話すことで、難しい課題の道筋が簡単に見えたり、他のメンバーが前職で取り組んでいた取り組みを聞いて参考にしたり、とても良いフィードバックが生まれる雑談の時間になっています（現在も継続中です）。
また、もう少し狭い話題の議論をするために「雑談会」という名目で、チームを絞った雑談も始めました。例えば、私が所属しているバックエンドチームでは「このRailsの書き方についてどう思いますか？」や「Railsのrubocopの規制を緩和しませんか？」など、より細かい話題の雑談を行っており、これもチームの共通認識を作るのにとても役立っています。
雑談とても大事です。
QAをQAだけに任せてたらスケールしなくないっすか？
IVRyは電話を扱う高いサービスレベルを維持する目的で、従来はリリース前に必ずQAを行っていました。しかし、開発メンバーが増加し、また作る機能も増えたため、この機能を1人のQAエンジニアが行うことはほぼ不可能です。さらに、このことはリリース頻度にも影響を及ぼし、機能の提供速度にも影響します。
そこで導入したのが、機能ごとにQA担当を持ち回るという運用です。例えば、LPの改修であればPdMがQAを行い、フロントエンドに関連する修正はフロントエンドチームがQAを行ったり(PdMやバックエンドが行っても良い)、機能単位でQA担当を決定するようにしました。IVRy全体のシステムに影響を及ぼすような修正は引き続きQAチーム（現在は1人）がQAを行っています。
このことは、IVRyのQAエンジニア関連のブログでも触れていますので、そちらもぜひ見てください！
最後に
最後までご覧いただき、ありがとうございました。もし同様の課題を抱えている場合は、参考にしていただければと思います。
そして、現在のIVRyもまだまだ課題が存在します。私たちとともに課題を解決しながらIVRyを共に発展させるメンバーを大募集しています！ぜひ気になった方は採用情報をご覧ください！
Discussion