私は10月からマーケティング自動化の部署に異動しました。新しいチームでは以前のチームと比較して、カンバンをきれいに利用できていることが印象的でした。

この記事では、私がカンバン方式について調べた内容と、現在のチームの開発手法を比較・分析する内容です。

背景・前提

LIFULLでは、MAMという有料集客の自動化のための社内システムを運用しています。LIFULLでは広告宣伝費に年間100億近く使っており、その効率化のための自社ツールを内製しています。

やや乱暴に説明していまうと、以下のようなシステム群です。

各広告媒体からレポートデータを収集してBigQueryに入れる
BigQueryに入ったデータを組み合わせ、各種計算（各媒体の予算の最適化など）を行う
- 余談ですが、最適化手法に興味のある方は、以前LIFULL Creators Blogに投稿された「広告宣伝費最適化に向けた最適化問題の活用」という記事を読んでください
各媒体のAPI経由して2.の結果を反映させる

そのため、次のような特性があります。

大半が「バッチ処理」と「レポーティング画面」なので、個々の機能の開発難易度は高くない
大量のバッチ処理があるので、データフローやデータ内容の把握が難しい
仕様を決定する人は、マーケッターの業務フローも把握している必要がある

チームの運営状況とカンバン方式の比較

エンジニアチームでどのようにタスク管理されているかを述べ、それがどうカンバン方式と対応しているかを比較します。

どのようにエンジニアチームが運営されているのか？

「マーケッターサイドの仕様策定」→「エンジニアサイドの実装」→「マーケッターサイドの効果測定」という工程で分業しています。本来はマーケッターの仕様策定のプロセスも含めるべきだと思いますが、実装部分にだけ発行すると、チケットは以下のような策定・完了されていきます。

マーケッターの要望を経て発行される。
毎朝のデイリーミーティングでカンバンボードを見て、チケットの状況を確認する。もうすぐ手の空く人がいたら、手を挙げてアサインされる
テストやレビューなどの工程を経て、リリースされるとチケットが完了される

カンバンボードには、全社標準で使われているjiraが利用されていました。

「え？普通じゃん」と思われるかもしれませんが、スプリントやタイムボックスがほとんど無い状態で、いわゆるアジャイルやスクラムのベストプラクティスには沿っていませんでした。

少しだけ先に考察を話すと、「エンジニアが高負荷にならないにはどうすればいいか？」と当時のメンバーが考えて工夫した結果、適切な形で運用されたんだと私は推測しています。それをこれから解説します。

カンバン方式とは？

ご存じの方も多いでしょうが、まず「カンバン方式」について軽く解説します。カンバン方式は、元々はトヨタの開発現場で使われた改善活動が、「リーン生産方式」として海外に輸出され、ソフトウェア開発にも導入されたものだそうです。

カンバン方式では、具体的には、以下のようなプロセスで開発します。

タスクをチケットとして管理する
前工程（例: 仕様策定）のタスクが完了すると、後工程（例: 開発）の人がそのチケットを引き取り、作業に取り掛かる（後工程引取り）
自分のチケットのタスクが終わったら、次のチケットを取りに行く

これがあると以下のようなメリットがある。

後工程の人が無理のない範囲でタスクを引き取るので、その人のペースを保て、負荷が平準化される
全体のタスクの流量がボトルネックで処理しきれる量に制限される（WIP制限）
- 「開発部分がボトルネックだから工夫しようか」って改善ポイントが見つけやすいってことなんだと思う
スキルが平準化され、多能工を生み出しやすい
- 上記の一部で、例えば「仕様策定までに時間かかるから他の人もできるようになろうか」って議論しやすいんだと思う

元々のトヨタの生産現場では「作りすぎ（コストが二重にかかる）の抑止」として始まったようですが、ソフトウェア開発では「開発者の負荷軽減」「リリースまでの待ち時間の削減」などが主目的になってる印象があります。また、生産現場ではデリバリーリズムやタイムボックスの概念は無かったようです。また、「開発工程内の製品の数（チケットの数）を制限する」という目的は共通しています。

我々の開発現場では、「タイムボックスの無いカンバン方式」というような状況で、ある意味先祖返りした状態で運用されていました。カンバン自体については、「デイリーミーティングで手の空く人がいたら、手を挙げてアサインされる」というルールのおかげで、その人の能力に応じて適切なチケット数を消化できるように、後工程引取りの役割が徹底できていたようです。

なぜカンバン方式がハマっていたのか？

私が見る限り、以下のような状態でした。逆に考えるとこの部分は属人化してしまっていました。

在籍の長く、既存データの知識の豊富なエンジニアが上手く通訳していた。そのため、仕様策定がしっかりしていて、タイムボックスを区切って漸近的に開発しなくても問題なかった
朝会をマーケッター側のファシリテーションで行なっており、各チケットやメンバーの状態を把握できている
逆に、広告媒体や本体サイトの事情で突発的な作業が多く、計画が立てづらい部分も多い

部署再編の都合で大きく開発メンバーが抜けてしまったことがあり、業務委託が多い状態で開発していました。開発管理のノウハウもないためにエンジニアの負荷が高く、残念ながらあまり人が定着しなかった時期も続いたそうです。

「エンジニアが高負荷にならないにはどうすればいいか？」と当時のメンバーが考えて工夫した結果、後工程引取りが徹底される本来のカンバンの良さが発揮できる運用に収束していったんじゃないかと考察しています。

カンバンだけでは解消できていなかった課題

もちろんチーム内の課題はいろいろ残っていました。これによって「カンバンだけでは解消できない課題」の効果が考察できそうです。

仕様策定や運用業務が属人化していた

仕様策定部分では、マーケッターとのコミュニケーションや、既存データの把握など、エンジニアリング部分以外の能力が必要とされ、特定のメンバーに偏っていました。また、バッチ処理の再実行などの運用業務もその方に依存していました。その方がいなかったら破綻してしまっていたと思います。

また、エンジニアの正社員がほとんどおらず、レビューやリリース作業などはエンジニアリーダーに集中してしまっていました。

現在はチームで分担して、ドキュメンテーションや、PdMの立場を導入するなど工夫を始めています。ただ、運用改善やドキュメンテーションはうまくいきそうですが、PdMはまだいろいろ試行錯誤が必要な印象があります。

振り返りが改善活動に繋げられていなかった

それぞれが感じている課題を、うまく拾い切って改善活動まで繋げきれていなかった印象がありました。ミーティングを明確に「振り返り会」というタイトルで再定義して、うまく意見が出るようになった状態です。最近私がファシリテーションを担当するようになりました。

ただ、実際はカンバンのおかげで「タスク（チケット）がたまりがちな工程をどうすればいいか」って視点で話し合って改善活動しやすい状況だったので、おそらくエンジニアチームリーダーがいろいろ担当してしまっていて手が回らなかっただけだったんじゃないかと思っています。

不確実性に対処できない

追加改修（「広告媒体の追加」など）の突発的な作業などの不確実性の低い開発は、スループットも安定した状態で進められていたと思います。

しかし、それに比較して、やや不確実性の高いシステム改善、新規開発はうまく進んでいません。うまく計画プロセスを入れて少しずつ進められるようにするか、より細かく計画修正が必要ならタイムボックスやスプリントの概念を導入し、いわゆるスクラム開発のスプリントプランニング、スプリントレビューみたいなものを行なうべきかもしれません。

不確実性の高い機能に対しては、タイムボックスを区切ったほうが計画の振り返りを行いやすい
不確実性が低い場合に対しては、（カンバンソフトウェア開発の変革を信じるなら）タイムボックスが無いほうがスループットを上げやすい

もしタイムボックスを導入し、スプリントプランニング、スプリントレビューを行なうと、本当にオーソドックスな形のスクラム開発にかなり近くなります。レトロスペクティブ（振り返り会）はすでに実施し始めているので。

まとめ

最後にもう一度まとめると、この記事は次のような内容でした。

新しいチームでは「タイムボックスの無いカンバン方式」というような開発管理が行われていた
カンバンを適切に運用し、WIP制限を行なうと開発者の負荷が減る
カンバンだけでは「不確実性の高いタスク」などの問題には対処しづらいかもしれない

「タイムボックスの無いカンバン方式」に対する考察