RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

「カンバンでチームのアウトプットは安定するのか?」に取り組んだ1年のふりかえり【はいくる通信 第6話】

id:radiocat です。カンバンは「チームの現状を良くしたい、何かを変えたい」という思いがカタチとして表れるツールであることを、この1年を通して感じています。

私は2019年4月から現在のチームのマネジメントに携わり、「チームのアウトプットを安定させる」ことを目指してこの1年間を取り組んできました。今回はその1年間をふりかえってみたいと思います。今年度、 配配メールクルメル の開発チーム(略して「はいくる開発チーム」)は約半数の新しいメンバーが私と同時にJOINして新チーム体制がスタートしました。

いにしえの開発プロセスの中に一筋のカンバン

配配メールは10年以上の歴史を持つメール配信の老舗サービスです。当時から稼働している機能がいまだに多数存在しているレガシーなシステムなので、開発スタイルもレガシーな流れを受け継いでいました。半年程度先までのタスクが担当者にアサインされ、古来伝来のガントチャートでリーダーが日々の状況をキャッチアップして進捗管理していました。

f:id:radiocat:20200325011952p:plain
古来伝来のエクセルガントチャート

そんな開発スタイルの中で少し異質だったのがカンバンの存在でした。スケジュールはガントチャートで管理しているはずですが、カンバンはどのような目的で使っているのか聞いてみると、各担当者がスケジュールを意識して個人レベルのタスク管理を徹底することで、スケジュールを維持するのが目的でした。

f:id:radiocat:20200325194323p:plain:w300
1年前のカンバン

しかし改めて振り返ってみるとこのカンバンの運用には課題がいくつかありました。

  • タスク管理は個人任せ
    • ガントチャートのマスタスケジュールからカンバンへの落とし込みは担当者に依存しており、目測を誤るとスケジュールが守れない
  • 人ごとにレーン分け
    • 全員の状況がわかるようになっていても、みんな自分のレーンに関心が集中しており、他のメンバーの進捗状況に目を向ける余裕はない
  • 見えているのは1日分
    • 1日の状況からは今後のスケジュールが予測しづらく、全体のスケジュールに関心を持つリーダーの不安は解消されない

このような課題を抱えながら、はいくる開発チームは新体制で開発を続けていました。

カンバン駆動で漕ぎ着けた史上最大級のリリース

配配メールは2019年秋に『 Bridge 』という新しいプランをリリースしました。新しいプランは配配メールが配信ツールからマーケティング・サービスへと進化するための高度な機能を提供するという、新チームが始まる前から企画されていた過去最大規模のプロジェクトでした。リリースを控え開発が終盤を迎えた頃、懸念していた課題が問題として顕在化していました。難易度の高い機能のいくつかで開発に大きな手戻りが発生し、スケジュールをリカバリするため、チームは担当者のフォローやタスクの組み換えに追われていました。このタイミングでの開発プロセスの変更にはリスクもありますが、このままの進め方では状況の改善が難しいと判断し、できる範囲で課題を改善することにしました。言わば「走りながらフォームを変えて制限時間内にゴールを目指す」作戦です。

1週間スプリントの導入

リリースが迫ってきている中でこれ以上の大きな手戻りは致命的なので、タスクを個人任せにせずチーム全員で助け合って進める必要がありました。しかし、それまでの進め方では熟練者ですら全体状況を見渡すのが難しくなっていました。そのため、スケジュールから逆算した1週間先の目指すべき状態を明確にし、チーム全体で1週間分の計画を立てて進めることにしました。そして、計画した1週間分のタスクを前出のカンバンのウラに貼り出しました。

f:id:radiocat:20200325201344p:plain:w500
カンバンのウラを計画に使用

この時点では特定の人に属人化したタスクが多数あったため、「人ごとのレーン分け」はいったんそのまま受け入れました。ただし、誰でもできるタスクは無理に誰かに割り当てるのではなく、できる人ができるタイミングで受け取ってどんどん進めていくことにしました。また、属人化したタスクも含めて毎朝全体の状態を全員でチェックして誰かのタスクが遅れそうならフォローしあってチーム全体で1週間後のゴールを目指すことにしました。

こうして、カンバンを軸とした、1週間の計画と全員で状況を確認する朝会が功を奏し、新プランはこの秋に無事リリースを迎えました。

www.hai2mail.jp

共用カンバンからチームのカンバンへ

「人ごとにレーン分け」の課題が残されたカンバンは、このあとチームを2つのグループに分けることで解消しました。新体制となって半年のまだまだ未成熟なチームでは、総勢8人という体制の中でお互いをフォローしあうには、全体を見渡すにしても助けを求めるにしてもサイズが大きすぎると考えました。4人でコンパクトに使うことになったカンバンは、人ごとにレーンを分けなくても全体の状況を見渡しつつ、個人のタスクが管理できるようになりました。複数人が個人タスクを扱っていた共用カンバンから、全員で一緒にタスクを扱うチームのカンバンに変わったのです。

f:id:radiocat:20200325201517p:plain
個人の共用カンバンからチームのカンバンへ

これにより、これまで概ね半年サイクルだったリリースサイクルを3ヶ月に短縮し、新プランをリリースしたあとも機能をアップデートし続けることができています。

可視化から言語化

カンバンを使って開発タスクや課題が可視化されただけでなく、課題に向き合って気づきを得たことでその取り組みを言語化してアウトプットできるようにもなりました。以下は取り組みを推進したメンバーが 弊社主催のMeetup で発表したスライドです。

speakerdeck.com

課題の改善に取り組むだけでなく、それを振り返って改めて言語化することも大切なことです。チームにはまだまだ課題がありますが、このように取り組みを振り返って一つの区切りをつけることで、新たなステージへの次のチャレンジに向かうことができます。

何かを変えたいという思いからカンバンが生まれ変化が起きた

思えば、1年前チームが使っていたカンバンは今となっては使いにくいものでした。 しかし、それは言い換えれば「何かを変えたいけど変えれない」状態が使いにくいカンバンとして表れていたとも言えます。うまくいかないから止めるのではなく、うまくいかないことをいかにうまく活かすかが改善であると気づけたのがこの1年の学びです。

チームで計測したあるパフォーマンス指標に目を向けると、タスクが個人に依存して乱高下していたパフォーマンスは、カンバン駆動で改善に取り組んで以降は安定しています。

f:id:radiocat:20200324201954p:plain
チームのパフォーマンス

前述のとおりチーム体制と開発する機能の難易度が変わったため高低差は一概に比較できませんが、この指標をもっと高い位置で安定させていくことが次のステージのチャレンジです。

配信ツールからマーケティング・サービスへ

メール配信は受信側に依存することが多い不確実性の高い技術です。新プランをリリースした現在の配配メールは、単にメールを届けるだけにとどまらず、お客様のマーケティングを支えるサービスとして活用されています。マーケティングもまた不確実性の高いビジネスの手法です。

  • 届くかわからない
  • 読むかわからない
  • クリックするかわからない
  • サイトを再訪するかわからない
  • 熱感が上がるかわからない
  • 購入意志を持つかわからない

不確実性と向き合い、これらの「わからない」を「わかる」に変えていくことが、今後の私たちのチャレンジです。

取り組みを発信していきます

私たち「はいくる開発チーム」は、同じような課題に取り組んでいる中小企業のエンジニアチームが”楽”になることを目指して、自分たちの取り組みを発信しています。今後、以下のイベントでも取り組み事例をお伝えする予定です(新型コロナウィルスの影響によりイベントの開催は現時点では不透明ですが、何らかの形で事例はお伝えできると思います)。よろしければご参加ください。

2020.agilejapan.jp

www.scrumosaka.org

Copyright © RAKUS Co., Ltd. All rights reserved.