スクラム開発

minne Webチームの運用・改善タスクへの試み

スクラム開発

minne 事業部 Web チームのエンジニアリングリードを担当している @ebihara99999 です。

エンジニアは普段の仕事の中で様々な種類の業務を行います。サービスの開発はもちろんのこと、コードレビューや運用・障害対応なども行わなければいけませんし、問い合わせが来たら調査も行う必要があります。場合によっては社内勉強会・オンボーディング・研修・評価資料の準備・面談などの開発・運用とも直接関係ない業務もあるでしょう。

このような状況の中で、minne の Web 開発チーム(「Webチーム」といいます)では、問い合わせに繋がる不具合の調査・修正、ライブラリアップデート、その他改善タスク等のアプリケーション運用に関するタスクが宙に浮いてしまい、開発タスクと運用タスクをバランス良く進められていませんでした。

開発タスクと運用タスクに関する優先度を決める際、どのような基準で運用タスクの優先度を判断するか、そしてどのような時間配分で開発タスクと運用タスクに対応するかという指針が存在しない点が、それらの取り組み方の不均衡を生む原因ではないかと考えました。

そこで、優先度や時間配分を判断する際に必要な基準を定め明文化したので、こちらではその紹介をさせて頂きます。

Web チームの業務分類と時間配分について

時間配分について、サービス開発の時間とその他の業務の時間を 1 対 1 の割合で分担することを考えました。1 日で言えば 4 時間をサービス開発に関するタスク、残りの 4 時間をその他の業務に使うという形です。

ペパボはフレックス制なので、厳密には 1 日の業務時間の分担は上記のようにはなりませんし、業務の都合に応じて一日単位で見ると厳密に半分半分にするというわけにはいかないでしょう。したがって、厳密なルールにはせず数日単位で 1 対 1 の割合になっていれば良い、という形を考えました。

それに伴い、時間配分が妥当なのかを考えるため、Web チームのタスクを洗い出し業務分類を行いました。さらに、洗い出した業務がサービス開発の時間/サービス開発以外の時間のどちらに属するべきなのか判断しました。

なお、ロードマップやプロダクトバックログに非機能要件に関するアイテムを加えることやアーキテクチャー滑走路を作成することも考えましたが、既にプロダクトバックログが肥大化しそのメンテナンスコストが重くなっている現状を考慮し現実的な案ではないと判断しました。

具体的な業務分類とその分担

次に、業務分類とその対応をどの時間で行うかを説明します。1 日をサービス開発としての時間とそれ以外の時間に分けることは前述の通りですが、後者の時間を「Web エンジニアとしての時間」と呼びます。比較的裁量があり技術寄りのタスクも多いからです。

あるタスクをサービス開発の時間とするか Web エンジニアとしての時間かを判断する基準は、OKR の文脈におけるスクラムチームの Key Result を達成するものであるか否かとタスクのボリュームを基準とします。

具体的な業務分類とその分担は以下の通りです。

業務分類とどの時間で対応するかに関する画像

分類が難しいものについて、工数を基準に割り当てを行いました。比較的工数が大きいものについてはサービス開発の時間、そうでないものをWebエンジニアとしての時間で行うことに決めました。Webエンジニアとしての時間で問い合わせ対応等を行っている兼ね合いから、このような配分にしています。

さらに、緊急度/優先度が最大のものに加え、全社的な取り組みは無条件で両方から工数負担するように判断しました。これにはメンバーがペパボの全社的な取り組みに参加することを促進する目的があります。

まとめ

開発タスクと運用タスクの兼ね合いについては多くの開発チームの悩みの種だと思います。細かい業務の種類・量はチーム体制や会社によって異なりますが、アップグレードやセキュリティ対策のスプリントバックログへの追加基準は比較的汎用的に使えるものになっており、同じ悩みを持つチームの参考になれば嬉しいです。

こちらで紹介した取り組みの成果については、また半年後にペパボのテックブログで報告したいと考えています。