はじめに
お久しぶりです。システム本部のデベロッパーエクスペリエンス室(以降DevX室)の新田です。このブログの立ち上げ記事である『はじめまして、カカクコムTechBlogです。』以来、2本目の記事となります。
我々DevX室は 「全体最適に向けた支援活動によって、エンジニアリングに集中できる環境を生み出しシステム本部の開発者体験を向上させる」 をミッションとして、システム本部に存在するたくさんのシステム部門を、横串で全体最適する活動を日々行なっています。
つまるところ開発活動はやっていない運営組織になるのですが、この度組織の活動をもっとアジャイルにやっていこうぜということで動き出しましたため、せっかくなのでブログにしたためようと思います。
では、なぜアジャイルにやっていこうぜということになったのか。DevXの成り立ちもふまえてご紹介します。
DevX室はこうして産まれた
DevX室はまだDevX室という名称が無かった頃、本部長であり心理的安全性を大切にしている安藤さんと、アカウント管理を令和最新にしたことで有名な三谷さんの二人体制で2年弱ほど活動していました。が、やはり開発者体験の向上を推進していくにはマンパワーが足りないというところで新田が参画し、その後は現室長の加藤さん、QAの専門家でありデブサミでも登壇した伊藤さんも加入。これまでシステム本部付だった我々はデベロッパーエクスペリエンス室となり、かなり急ピッチで人が増えていきました。
俺たちは困っていたし、もっと意識したいこともあった
超少人数だった組織が拡大し始めると何が起きるかというと、主に以下のようなことが発生します。
- タスクの管理方法が各々のやり方・粒度となっており、見える化されていない
- 他のメンバーのアウトプットとアウトプットの間の進捗が見えない
- 他のメンバーが何に困っているのかがわからない
- 誰がやってもいいタスクの実施が漏れていることに気づけない
特に4つ目がかなりまずく、具体的には利用しているSaaSの支払い期限が過ぎてしまい、先方に督促されてしまうという事態が1か月で2件発生してしまいました。
この事から、最低でも「開発組織で使用しているWrikeを利用してタスク管理をしていこう」ということをマストとして実施することとなりました。
また、せっかくWrikeを利用して取り組みを始めるのであれば、以下のことがらも意識したいと考えました。
- 「今やっているもの」「今期やるもの」「来期やりたいもの」「将来やりたいもの」の単位で、やることをすぐにわかるように可視化したい
- 新しい取り組みをやっているぞという感じを出したい、実験したい
- 我々は横展開組織であるので、取り組んでみた事柄を開発組織や企画組織・営業組織などへフィードバックしたい
- 月単位、四半期単位で「おお、結構成果を出せたな自分！」とハッピーな気持ちになるようにしたい
以上のことから、Wrikeを基盤にした組織アジャイルをやってみようと決定しましたが、あくまでアジャイルは目的ではなく手段であり、アジャイルをやりたいわけではないということ。一発で完璧なものをやれるわけじゃなく、やりながら改善していくということ。やってみてダメそうならやめればいいから気楽に始めることを室メンバー全員で改めて大事なこととして理解したうえで始めることとなりました。
やることを決めた
Wrikeを基盤にした組織アジャイルをやるぞと決まったので、より具体的に、いつ何をどこでやっていくのかを新田のほうでまとめていきました。
Wrikeを利用したタスク管理
当初のマスト要件であるWrikeを利用したタスク管理です。DevXスペースの中にバックログフォルダを作成し、以下のような階層構造でアジャイルライクなタスク設計をしました。
バックログ(フォルダ)
└ イニシアチブ(プロジェクト)
└ エピック(タスク)
└ ストーリー(タスク)
イニシアチブ
活動の柱になるテーマであり、一番大きな概念。DevX室には7本柱と呼ばれるミッションが存在するため、それらが該当する。なお室立ち上げ当初からミッションが追加されていった結果、2023年9月現在 7本柱は13個ある 。Wrikeのプロジェクトベースのカスタム項目タイプで作成する。エピック
イニシアチブのために活動する内容。このエピックが完了になると、誰が何をできるようになるのか、アウトカムをタイトルに明記する。Wrikeのタスクベースのカスタム項目タイプで作成する。ストーリー
エピックを達成するために必要な具体的な作業。最大でも1つのスプリントで完了できる粒度に切り出す。Wrikeのタスクベースのカスタム項目タイプで作成する。
これらを利用した例として、ブログ作成に伴うレビューの一部自動化をした際のタスク管理は以下のようになりました。
例
バックログ(フォルダ)
└ イニシアチブ : テックブログ・勉強会
└ エピック : 誤字脱字等の標準レビューを自動化し、レビュー工数の削減とブログ全体の文章品質の向上を実現する
├ ストーリー : textlintの実装
├ ストーリー : textlintで採用するルールセットの決定
├ ストーリー : プルリクマージ
└ ストーリー : wikiにtextlintのあれこれを記載する
上記構造をとることで、バックログフォルダをテーブルビューで見ることにより、バックログすべてを見ることができます。また、『現スプリントチェック』を入れ、フィルター調整で現行スプリントの確認もできます。
そしてガントチャートビューでエピックまで表示させることにより、「今やっているもの」「今期やるもの」「来期やりたいもの」「将来やりたいもの」が確認できるようになりました。
見せられるものだけ絞った(はずの)ガントチャートビューです
スプリントイベント
一般的なスクラムを参考にし、アジャイルを回していく上で以下のスプリントイベントをやっていくことにしました。
スプリントプランニング
スプリントを開始するためのスプリント定義。スプリント開始時に1回だけ実施し、実施時間は1〜1.5時間。以下を決定する。
- スプリントゴール
このスプリントが終わったときどうなっているのか。
- スプリントバックログ
そのために実施するタスクは何か。
デイリースクラム
朝会。毎朝実施し、実施時間は15分〜30分。スプリントバックログを見ながら以下を確認する。 - Good and News - 昨日やったこと - 今日やること - その他連絡事項
スプリントビュー
ステークホルダーへの進捗・状況報告。スプリントが終わる前に1回実施する。実施時間は0.5時間（1人5分）
デモをするのが一番早い。プレゼンでもOK。
レトロスペクティブ
スプリントの振り返り。KPTやYWT、FDLなどの振り返り手法を用いて実施することが多く、悪いこと探しになりにくいのでFDL(FunDoneLearn)が新田のおすすめ。スプリントを閉じるため、現スプリントを過去スプリントに持っていく。
スプリント終了時に1回だけ実施し、実施時間は1時間。
やらないことも決めた
上記のWrikeの利用方法とスプリントイベントというやることを決めましたが、あわせてやらないことも決めました。
タスクの見積もりとプランニングポーカー
DevX室のメンバーはあまりにも個々の専門性が違いすぎるため、同じタスクを誰がやるかによる速度の差が大きい。また、同様の理由により見積もりの全体合意にあまり意味がないため。
厳密なロール設定
横展開組織である以上、プロダクトオーナーが他部門のメンバー・マネージャーとなり、スケジュールの確保が難しい上に数が非常に多く、巻き込んでやっていくとアジャイルを回すためのコストがかかりすぎる。本部長を仮想プロダクトオーナーと考えておき、スクラムマスターは言い出しっぺでもある新田がしばらくの間は回していく。
また報告します
現在事前準備をようやく終えて、ついにスプリント1周目を実施している最中となります。何が良い感じになったか、またどういう課題が出てくるのかが非常に楽しみです。というかすでに課題がいくつか出てきているので、次スプリントではどのように解消できるかを考えているところです。
スプリントを繰り返した結果どのように変化していったのか、また数か月後にここで報告したいと思います。よろしくお願いいたします。
アジャイルに動き始めた我々と一緒に、開発組織課題を解決していきませんか？
我々デベロッパーエクスペリエンス室は 「全体最適に向けた支援活動によって、エンジニアリングに集中できる環境を生み出しシステム本部の開発者体験を向上させる」 をミッションとして、システム本部に存在するたくさんのシステム部門を横串で全体最適する活動を日々行なっています。 そういった課題解決…だいしゅき！ というあなたや、 QA活動…だいしゅき！ といったあなた。ぜひとも我々と一緒にやっていきませんか？すぐの転職は考えていないけれど興味があるかも、という方はカジュアル面談からでも大歓迎です。
開発者体験（Developer eXprience）を向上させる組織の立ち上げ担当【システム本部】 | 株式会社カカクコム
