こんにちは、岩松です。ここしばらくゲームに集中してましたが、ようやく満足したので家での筋トレを再開しています。好きなYouTuberはなかやまきんに君さんです(パワー)。
「Assured」では毎月様々な取り組みをしているので「Assured Tech Blog 社外報」として、一つの記事にまとめてご紹介してみることにしました！「Assured」開発チームも日々頑張ってるんだなとお見知りおきくだされば幸いです🙌
ポストモーテムを開始
2022年1月の正式リリース以降、機能リリースを重ねてきましたが、サービス利用の増加に伴い、より安定した高いレベルでのシステム運用を目指して、ポストモーテムを始めることにしました。目的を整理しておくと
- メンバー全員が問題を正しく認識し、再発を防止していけること
- 未来の仲間が過去の記録を参照できること
となります。SRE(Site Reliability Engineering)を専門として経験したメンバーがおらず、チームにSREの役割があるわけでもないので、まずは「ゆるくミニマムに始める」ということを意識しました。
ドキュメントのフォーマットはGoogle版をベースとして、以下のようにしています。
- サマリー - インシデントの記録 - 事象のタイムライン - インパクト - 発生要因 - 対応内容 - 検出方法 - インシデント後の振り返り - うまくいったこと - うまくいかなかったこと - 幸運だったこと - 学んだこと - 再発防止に向けた行動
何かしらトラブルが起こればこのフォーマットをNotionで記入し、メンバー全員で事象を振り返るというのが一連の流れです。今は記入自体に手間はかけず「再発防止に向けて何をすべきか」を考えていくことを重視しています。
ちなみに今のチームにSREの役割はないと書きましたが、実は副業のSREとして「Assured」へ関わる方がおり、再発防止に向けた施策を一緒に検討し実装したりしています。こういった取り組みもいずれご紹介できれば！
プランニングの本格化
チーム開発の記事でもご紹介したように「Assured」では「ゆるスクラム」を採用し厳密な見積もりを避けてきました。これは 運用の厳密さよりも、各々が自律的に開発タスクを進めコードを書く時間を捻出することに重きを置いた からなのですが、チームで開発を進める体制づくりが進んだ結果、工数の予想/実績にズレが生じやすくなってきました。結果として事業目標が設定しづらいという問題が発生するのですが、これはメンバー間の知識差が原因ではないかと考えたため、プランニング(見積もり)に時間をかけてみることとしました。
- タスク(ユーザーストーリー)の理由や背景、必要性を確認する
- タスクを完了する上で必要な作業を洗い出す
- 必要に応じて、より具体的な作業内容を確認する
- 作業ごとにポイント(ストーリーポイント)を割り振る
これらをチーム全員で行うことにより、作業を遂行する上で何をしなければいけないのか、どの程度の複雑さなのか認識を揃えるようにしました。実際に工数の予想/実績問題を解決できるかどうかはこれから確認するのですが、メンバー間の認識を揃え安心して開発を進められるようになったのは大きな変化です。
このチームでちゃんとしたプランニングは初めてということもあり、この会ではそれなりの時間を要しました。しかし都度話し合いに時間をかけすぎるわけにもいかないので、プランニングに対する振り返りも実施しました。こうやって徐々にチームとしての型を作りつつあります。
Wevox Values Card を使った相互理解促進
「Assured」の開発チームに役割としての上下関係はなく、全員がフラットな関係で開発を進めています。これにより少ないコミュニケーションコストで物事を進めることはできますが、時には意見がぶつかり、お互いを尊重しすぎてしまったり、議論の決め手を欠くという場面がありました。
役割を明確にして意思決定を早めることもできますが、今はまだ各々の役割を決めずにベンチャー感のあるチームでありたい…。そこでまずは意思決定を進める上の遠慮を減らしていこう！ということで「Wevox Values Card」というゲームを利用して相互理解を深めてみることにしました。
このゲームは、様々な価値観に関する言葉が書かれたカードを山札から引いていき、自分の手札へ加えていきます。そして手札が5枚になるよう自分が大事にする価値観を選んでいくというルールです。
結果だけ見ると、お互いがそれぞれ共感できる価値観が選ばれていると感じました。結果的に価値観の近いメンバーが集まっていることがわかったと言えるのですが、改めて振り返るとこのゲームの真価はゲームの過程にあると思います。
実際に遊んでみると似たような価値観を引いてしまったり、捨てがたい価値観ばかり残ったりして、どの価値観を捨てるか悩むシーンが発生します。その過程で「〜と思ったのでこれを残す/捨てる」と自分なりの考えを説明することで「この人はこう考えるんだな」「こういった価値観を大事にするんだな」という面が見えてきます。このように価値観を判別するための思考過程が垣間見えることこそ、相互理解を助けるのではないかと感じました。
結果だけ見ることに意味がないというわけでもなく、こういった価値観を集積することで「バリュー」「クレド」といった組織としてのあり方も考えやすくなりそうだなと思いました。現時点では開発チームだけでこういった言葉を作る予定はありませんが、そういった観点でも面白いゲームだと思います。
おわりに
これまで新規事業として「とにかく作ること」「早く物事を進めること」を意識した結果、個人の力に依存する傾向が強かった「Assured」開発チームですが、ユーザーが生まれたことで運用の比重が高まり、開発がマルチタスク化しチーム力が求められるようになりました。ここ直近の活動を見れば、そういった状況に対する改善活動が主だったなと気付かされます。
個人的にはSaaS開発は機能開発・運用・チームづくりと様々な観点で動かなければいけない点が面白いところだと思っています。「Assured」はようやくこれら全てを0から作っていけるフェーズに入ったところです。こういったフェーズを一緒に楽しんでみたいなと思われた方がいれば、ぜひお話してみませんか？
エンジニアチーム紹介ページ
