開発チームにカンバンを導入した理由とその変遷

お疲れ様です。株式会社Timers（タイマーズ）でプロダクトマネージャーをしているsuzukenです。

こちらの投稿アカウントは、弊社CTOの椎名アマドのものとなりますが、今回Agile Japan「ぼくたちのひみつきち紹介」に参加するため、アカウントを貸りて投稿しております。

弊社は、「Famm（ファム）」という家族向け写真/動画共有アプリを運営しております。
そしてプロダクトはアジャイル開発を採用しております。

本ブログでは、ある恵比寿のITベンチャー企業がどのようにアジャイル開発を採用し、導入し、現在どうなっているのかの歴史をお伝えしてみます。

アジャイル開発導入の理由

弊社Timersは2012年5月に創業し、社内の古い記録をたどってみると、「アジャイル開発を採用するぞ！」と社内に宣言されたのは2015年5月くらいのことでした。つまりTimersは、2019年5月現在でアジャイル開発歴5年目に突入しています。

私はTimersに2017年に入社したため、アジャイル開発採用の経緯は知りません。そこで弊社内に残されたドキュメントと、CTOのアマドにヒアリングを行って歴史を紐解いてみましょう。

社内ドキュメントによると
まず2015年5月に書かれた「1_アジャイルの目的・前提」という資料には、以下の記述がありました。

目的
なぜアジャイル開発を行なうのか？
前提：どんなプロジェクトでも仕様や納期は、（どれだけ頑張っても）進めていく中で変わってしまうことはある
その前提があった上で、柔軟に変化に対応できるためにアジャイル開発を採用しています。

ふむふむ。
その後、Timersはスクラム開発を始めていきます。

そして興味深いのが、2015年9月に「0_背景」という資料が追加されます。
その資料には以下のような記述がありました。

今回アジャイル・スクラムのやり方を、以前のやり方から少々変えるに至った背景について。
「アジャイル」という意識
アジャイル開発というのは別にミーティングやタスク管理のフォーマットではなく、思想＆意識です。「なんでアジャイルでやってるの」という根底の意識が欠けた状態でフォーマットだけなぞってても半端な成果しか出ない（むしろ効率が落ちる事もある）ので、きちんと意識を全員に浸透させる必要がある。

今までの問題点
今までのプロジェクトのやり方が、まさに上記で言う「なぜアジャイルでやってるのか」という意識が欠けた状態があったので、それを解消したい。
 * 完璧なプランニングが無いとプロジェクトを開始できない
     * 我々が「ストーリー」と呼んでるものはもはや「具体的な開発項目」なので、「ストーリーを出し切る」という行為は「具体的な開発項目をすべて出し切る」という事になってた。
    * 完璧で網羅的な事前計画→開発項目の洗い出し→開発　という流れはアジャイルではなくむしろウォーターフォールに近い。今までは「開発」のステップをアジャイル的に刻んでるだけ
 * 決まってない仕様・変わる仕様に弱い
     * 上記で「完璧であること」を要求していてそれベースでプロジェクトが動くので、決まって無いところ（抜け漏れ）が「良くない事である」という捉え方になってしまう。
     * 仕様が変わる事に対しても、対応することは出来ているが、同じく「良くない事」とされている雰囲気。
 * 中途半端なプロダクトでスプリントが終わる
     * ストーリーが「開発項目」になってるせいで、ユーザーから見たら動かなかったりバグってる状態でも、「このストーリーまで終わった」という理由でスプリントが完了してしまう。その結果：
         * 「結局ユーザーへの価値提供としてどれぐらい進んだの？」という視点での進捗が見にくい。
        * リリース時期の変化などに対して、「結局今のものにどれぐらい手を加えればリリース可能なものが出るのか」という判断がしにくい

→開始時点で細かいところまで仕様が完璧に決まってなくても、重要なこと（実現したい機能）についての共通認識が取れていれば動けるようにしたい→スプリント完了時に常に完璧な「成立してるプロダクト」が出せているようにしたい

なぜアジャイル開発に移行したんですか？

上の社内資料だけだと、今まではどんな開発手法で、そこにどんな問題があって、アジャイル開発手法のスクラムに至ったのかがわかりませんでした。

というわけでその経緯を知る1人である、弊社CTOの椎名アマド（本ブログオーナー）に直接聞いてみました。

suzuken「アジャイル開発導入以前はどんな開発手法だったんですか？」

アマド「ウォーターフォール型だったねー。開発前に仕様やデザインは事前にカッチリ揃えておいて、全機能完成したらまとめてデバッグする的な。」

suzuken「ちなみにアジャイル開発に移行したいと決意した理由は何でしょう？」

アマド「まー、よくある話ですがデバッグが巨大になるし、テストフェーズのバグ対応や仕様修正で疲弊が大きかったというのがあるね。開発の終わりが見えづらくなるので、メンバーの気疲れが大きいのをなくしたかったんですよ。」

suzuken「なるほどー。ちなみにスクラム開発導入宣言の後に、2015年9月に「背景」という資料が追加されてましたが、それは何があったのでしょう？」

アマド「数ヶ月試してみて見えたことが、結局やっていることがウォーターフォール的に固めた仕様をスプリント期間に分けて開発していただけなっていた、というのがあったんですよ。」

アマド「この時スクラムを導入して改善したこととしては、開発途中でチームの振り返りができるようになったのはありますが、プロダクトの増分がスプリントが経過しても全然確認出来なかったので、資料を書いて改めて説明した、という背景ですね。」

資料だけではわからない、なんとも泥臭い歴史が垣間見えました...！

アジャイル開発採用の変遷

そして2015年にスクラムを導入したTimersですが、私が入社した2017年にはスクラム開発は行われておりませんでした！

開発共有資料にはSprintやポイント見積りなど、スクラム開発が行われていた形跡は残っていましたが、Sprint期間は特に無く、見積りもエンジニア個人個人の肌感覚による期間見積りが行われているという形でした。

私が入社直後の開発手法を表現すると、スパイラル型開発風にプロジェクトが進められていた印象を感じていました。

このあたりもCTOに理由を聞いてみました。

アマド「2015年にアジャイルを始めてからしばらくは、iOSとAndroidの2開発チームで開発を進めてましたが、PMメンバーの入社が増えてきて、開発チームがプロジェクト単位に分割されるようになったんだよね。」

アマド「社内の開発方針はスクラムを推奨してたんだけど、プロジェクトチーム型はあまりスクラムとの相性がよくなかったんですよ。短いプロジェクトだとチームに知見が溜まらないし、スプリント期間/イベントの設計の手間も多そうに感じてスクラム以外の手法をとるチームが多くなってしまったと思う。」

カンバン導入期

その後私が入社してから数ヶ月はスパイラル型開発風のまま進めていましたが、私が担当したチーム内で以下の課題が発生したため、私が前職で経験のあったカンバン開発をチームに導入してみました。

 * チーム課題
     * リリース期限が設けられているが、工程の残り状態が見えない
 *  メンバーがある機能の開発を長期間続けているが、計画通りなのか問題があるのかがわからない
 * 解決できたこと
     * タスクをカード化し、状態ごとにレーンで表現したことで進捗を可視化した
     * 特定レーンに滞在し続けるカードを可視化し、チームで相談できる体制を作った

スクラム開発復興期

上記カンバンを実行していたのは私のチームのみでしたが、私が2017年後半で非開発の別プロジェクトに移動したため、カンバンが全社に普及するほどには至りませんでした。

そして2017年10月頃に、別チームでスクラム知識に長けたスクラムおじさんメンバーの活躍により、長期プロジェクトでスクラムを採用し、スクラム開発って結構いいじゃん！という雰囲気が社内に広まってきました。

そして以下の開発課題を解決するため、2018年から開発全チームでスクラム開発が導入されました。

 * チーム課題
     * ビッグバンリリースになりがちで、反動として発生しがちな障害対応への疲弊
     * プロジェクトごとにチーム変更すると、チームとしての知見が溜まっていかない
 * 解決できたこと
    * スプリント期間を1週間に区切り、細かくリリースと検証が行えるように
    * 開発チームメンバーを固定化し、チームの知見を溜められるようにした
    * 開発やイベントのペースが作れてきて無理がなくなった

1チーム化&カンバン移行期

しかし銀の弾丸は見つからないもの。
スクラム開発自体はある程度順調に回り始めましたが、約1年経ったくらいで新たな課題が出始めました。

 * チーム課題
    * 複数開発チームで似た機能を開発し、競合や調整が発生する
    * チームに縛られ、人やスキルセットに合わせた最適なリソース配分ができない

そして2019年2月より、私たちは2チームだった開発チームを1つに統合し、開発手法をスクラム→カンバンに移行しました。

 * 解決したいこと
    * メンバーの実力をフルに発揮し、良いものを安定的に出荷する

アジャイル開発を続けて得られたこと

そんなこんなでTimersのアジャイル開発（そうでなかった期間もありましたが）の歴史を簡単に紹介させていただきました。
そしてTimersでアジャイル開発を続け、得られたことがあります。

それは、
「可視化が進んで混乱の量が減り、チーム開発サイクルが着実に早まってきたこと」
です。

昔はチーム自体が経験が浅くカオスと立ち向かう日々でしたが、長期的に取り組めるチームで日々試し、振り返り、透明性を高めることで、チーム開発品質とスピードは年々早まってきています。

チームが固定化されることで、同じ仲間で課題に立ち向かう体制となり、継続的に取り組む必要のある課題を改善する動機が生まれ、品質がよくなり負債と向き合う時間が減り、本質的な価値と向き合う時間が増えてきたと感じます。
（実際2年前から現在だと、残業・障害・問合せの数がかなり削減され、集中して開発に取り組める体制が整ってきました）

市場・メンバー・開発手法などは変わっていき、これからも変わっていくことでしょう。
しかしアジャイル開発を目指すという思想は、これからも変わらず続けていくと考えています。

いやー、歴史って面白いですね！
あなたの会社やあなた自身でもぜひキリのよいところで振り返ってみて、アジャイル開発を通じて得られたものを探してみてください！