i-plug TECH_BLOG

若い人材の可能性を拡げるOfferBoxとコレカナを開発している株式会社i-plugの開発ブログ

i-plugが、スクラム開発を導入するまでの話

f:id:iplugsakai:20201127110658p:plain

はじめに

今回は、i-plugがスクラム開発を導入するまでについて書きたいと思います。

i-plugでは、いくつかのチームが、それぞれにミッションを持ってOfferBoxの開発に取り組んでいますが、それぞれが、スクラム開発をベースにした開発プロセスを作っています。

その中でも、私が所属しているチームは、最初にスクラム開発を導入したチームがベースになっていて、2019年4月に導入して以来、1年半スクラム開発を継続しています。 (開始が少し前後していたり、スプリントを実行していない時期もありましたが、先日スプリントが80を超えました!)

  • 負荷の集中する人、そんな傾向のあるチーム
  • 名ばかりチームで、孤独に仕事をしていることに違和感を感じる人
  • 実際にスクラムを導入したい人

そんな方々に、今回のお話が届けばと思います。

自己紹介

サービス開発部 UXグループ エンジニアリングチームでチームマネージャーを務めている堺と言います。

i-plugでスクラム開発したいって言い出した張本人です。

前職では、サーバ・DB管理を主に、開発・運用全般に広く浅く顔を突っ込む人をやっていましたが、関西のアジャイル界隈で有名な方の入社がきっかけに、スクラム開発を学び、前職を飛び出して、i-plugにジョインしました。

i-plugでは、ディレクターをやったり、チーム横断でスクラムマスターをやったり、スクラムマスターとプロダクトオーナーを兼任したりと紆余曲折あり、2020年4月、新型コロナ禍の中、スクラムマスターとプロダクトオーナーを兼任したままチームマネージャーになりました。(1人3役超しんどi(ry

現状は現状で学びがあるので、いつかまとめて記事にしたいと思っています。

チームとしては、

  • OfferBoxのプラットフォーム価値を上げるための土壌作り
  • アプリケーションレベルでの信頼性の向上
  • ユーザーのニーズに対するソリューションの提供

をミッションに、日々開発に取り組んでいます。

なぜ導入したいと思ったか

入社当時のi-plugの開発体制&プロセス

f:id:iplugsakai:20201127105237p:plain

  • ディレクター:要件定義〜仕様策定、受入テストの実施、進行管理、他部署折衝
  • エンジニア:設計、実装、テスト。案件にもよるけど、1案件1エンジニア→1エンジニアが複数案件抱えることも
  • デザイナー:1デザイナー複数案件

※他部署からの依頼とかは一旦除く

複数案件を管理するディレクター、デザイナーによるUIデザインが完成しない辺りがボトルネック。要件定義に注力すると、受入が進まない。受入に注力すると、要件定義が進まない。

MTGは容赦なくやってくる。

また、エンジニアの手を空けないよう、さくっと要件定義できる案件を用意したりするが、 そういうのは、さくっと実装が終わって、受入確認待ちが増えて、ディレクターの首を締める。 もしくは、準備不足で途中で進められなくなって、ディレクターの確認待ちに戻り、首を締める。

たまに、ディレクターが知らない内に、エンジニアに直接案件が割り当てられる。

ざくっと、まとめると・・・

  • ディレクターへの負荷集中
  • 案件の属人化
  • 全ての職種がマルチタスク
  • ディレクターが、自分の使えるリソースを完全にはコントロールできない

という状況でした。

問題

このような状況では、以下の問題が生じます。

  • ユーザーへの価値提供の遅れ
  • 純粋に、自分がしんどい

理想の状態ってなによ?

理想の状態を考えるとたとき、以下を考えていました。

f:id:iplugsakai:20201127105133p:plain

  • 特定の職種に負荷が偏らない
  • 誰かがいなくても仕事が進む
  • 誰かが困っていたらヘルプができる
  • 優先順位の高い案件に集中する

要は、チームとして優先されるべき課題に一丸となって対応しようよ、ということですね。

えー、でもこんなの簡単にいうけど、難しいよー。

いや、なれるんだよ。そう、スクラムならね。

スクラム導入前にやったこと

スクラム開発なら解決できそうだとはいえ、今ままでのi-plugの開発とは違う価値観・やり方。「やれよ」で出来るものではない。ということは身を持って知っていた(参考)ので、段階を踏んで、導入します。

1.アジャイルコーチによる支援

まずはアジャイルコーチをお呼びし、自分たちのしごとのボトルネックを見える化しました。 ボトルネックを解消するために様々なプラクティスを紹介いただき、導入します。 例えば、開発プロセスのボトルネックを見える化するために、一緒にバリューストリームマップを作ったり、振り返りをうまくできるように、様々なフレームワークを使ってファシリテーションしてもらったりといったものです。 加えて、これまでの開発プロセスにおける困りごとについて、相談・客観的に答えてくれる相手がいなかったことも課題でしたので、壁打ち相手にもなっていただきました。  

2.カンバンの導入

続いて、カンバンを導入しました。 これまでアイプラグではJIRAを使っていましたが、オフィスの壁にふせんを貼って管理するように変えました。

これにより、優先度・進捗が可視化されたばかりでなく、同じフロアにいる他部署にもインパクトを与えられたかと思います笑

3.朝会(デイリースタンドアップ)の導入

これまで実施していなかった朝会も実施。導入したカンバンを使い、メンバー同士の状況を共有しました。メンバーの状況を把握することで、より優先度の高いタスクを終わらせるための相談も実施できるようになりました。 朝会は全員が立ちながらおこないましたので、やはり他部署へのインパクト(ry

4.ふりかえりの導入

週に一度、ふりかえりの時間を設けました。自分たちの仕事の仕方を自分たちで見直すことで、以下のようなメリットがありました。

  • チームの中だけで課題とアクションを考え、改善し続けることで、自己組織化が促される
  • 頻繁に実施することで、以前に決めたアクションが正しかったか、次になにをするか、を早く決めることができる

5.受入テストを、エンジニア主導に

以前の開発部では、受け入れテストをする際にディレクターが環境立ち上げ・テストデータ準備をしていました。これを、エンジニアが実演する形へ変更し、以下のような改善が生まれました。

  • 開発に使っていた環境・データがあるので、すぐに、もしくは、簡易な準備で実演することが可能となった
  • ディレクターの工数負荷を下げる
  • 案件の受け入れテスト待ちの時間自体が減る

6.タスクのバックログ化

タスクを優先順位付け、リスト化しました(=バックログ化)。 これにより、チームとしては、リストの上から順番に対応していけばいい、という状況になりました。

7.イテレーションの導入

集中して目の前にあるタスクに取り組めるようイテレーションを導入し、一週間でやることを明確化させました。また、週の終わりには前述の振り返りをおこないました。

8.デザイナーとの関わりを調整

従来の開発方法では、デザイナーが抱えている開発部以外のタスクが可視化されていない状態で、要件が決まったものの、そのUIを実現するデザイナーのリソース不足がネックでした。 そこで、前述のカンバンでタスクを可視化し、さらに早めに要件を共有し、イテレーションの計画に盛り込んでもらうことで、UIデザイン待ちとなる時間を減少させました。

満を持してスクラム導入

導入だけでなく、スクラムを浸透させるためにも、メンバー1人1人と1on1を行い、やり方や期待するものを説明しました。

で、何が変わった?

エッセンスを事前に取り入れまくったので、やっていることは、実はほとんど変わっていません。(^_^;)

問題は解決した?

これらの取り組みによって、以下の改善が見られました。

  • メンバー間のコミュニケーションが増え、助け合いが増えた
  • 1人で孤独に案件を進めることも、1人でいくつも抱えることもなくなった
  • リリース件数自体は変わらないが、重要な案件の歩留まりは減った

みんなHAPPY?

実はそうでもありませんでした。 確かに、「作ること」自体は改善しましたが、

  • 何を作るか
  • 作ったものが正しかったのか

という、当たり前のところにまだまだ問題を残し、本当にユーザーが欲しているものを正しく届けられているか、は不明なままだったのです・・・

しかし、優先順位を落としているものの、バックログに大量に積まれた要望を前に、抜本的な改革が中々図れず、ユーザーに正しく価値を届けるためにグロースチームが発足することになったのです。

この続きは、小西さんの「i-plugでのグロースハックって何やってんの?」をご覧ください!

itbl.hatenablog.com

堺 祐輔

3人の子どもの父親で、はっちゃけた成人式で有名な北九州出身で、ビールが好きで、家でも仕事でもチーム活動がスムーズになるようにふらふらしてる人。色んな技術領域を、広く浅く、ところによりちょっとだけ深くカバーしている人。前職でアジャイル・スクラム開発に出会った後、i-plugに入社、開発プロセスの改善に携わり、右往左往しているうちに今に至ります。