こんにちは。
当社（アカウンティング・サース・ジャパン株式会社）は、会計事務所向けのクラウド税務・会計・給与システム「A-SaaS（エーサース）」を開発しているベンチャーです。
100%内製で、JavaやScalaで業務システムを開発しています。
今日は、私が担当する様々なプロジェクトで導入している「リーンカンバン」についてご紹介します。
リーンカンバンとは
リーンカンバンとは、書籍『リーン開発の現場 カンバンによる大規模プロジェクトの運営』（Henrik Kniberg著）で紹介されているカンバンです。
上記の本と、もう1冊、『カンバン ソフトウェア開発の変革』（David J. Anderson著）に書かれていることをミックスしてカンバンを運用しています。
リーンカンバン導入の背景と目的
当社でリーンカンバンを使い始めたのは、巨大なシステムを開発する際のリスクを可能な限り軽減したいと考えたからです。
これまでは、開発・テストの工程を外部委託するケースが多かったため、ウォーターフォール型の開発プロセスを採用していました。社内で企画者が仕様を書き、社外の開発者に開発・テストしてもらって、システムが完成したらリリースするという流れです。
しかし、外部委託を中心にした開発を数年間続けてきたところ、システムに多くの技術的負債が存在するようになってきました。最近では、システムの保守性や拡張性の低さが深刻な問題となってきました。不具合が見つかっても、どこを修正すれば良いのか、また修正によってどういった影響が出るのかわからないため、修正できないというケースも出てきました。
さらに、外部委託での開発はどうしてもコストが高くなりがちでした。
そこで、昨年からシステムの開発を100%内製に切り替え、これまでに開発したシステムの一部を、新たに作り直すことにしました。
同時に技術も刷新し、Scala+Ext JSという、これまで取り組んだことがない言語、フレームワークを採用することにしました。
既存システムの作り直しのため、仕様面でのリスクは低い一方、技術的なリスクは高くなります。最も怖いのは、開発の終盤になってアーキテクチャ的な問題が明らかになり、大きな手戻りが発生することです。そうならないように、なるべく小さな失敗から学びながら、スピーディに開発を進められる開発プロセスを探しました。
そんななか出会ったのが「リーンカンバン」です。
タスクを細かく分割し、全体の状況を見える化しながら、リリースを重ねつつ技術的な課題をチームで解決していくプロセスは、私たちにとって最適であるように思えました。
リーンカンバンの導入
リーンカンバンを社内に導入するにあたり、以下のような進め方をしました。
- 専門家への相談
- パイロットプロジェクトへの導入
- 他プロジェクトへの展開
専門家への相談
リーンカンバンの導入前から導入後3ヶ月ほどの間、月に1回ほどのペースで専門家に相談をしていました。
そもそも、リーンカンバンの存在もこの方から教えて頂いたものです。リーンカンバンのメリット、導入方法、運用のコツなど、様々なことを教えて頂きました。
初めてのリーンカンバンということもあり、何を重視して運用すべきなのか、わからないケースも多々ありました。専門家への相談から得られた知見は大変有用でした。
パイロットプロジェクトへの導入
リーンカンバンの導入決定後、PoC(Proof of Concept)という形で、ある1つのパイロットプロジェクトにリーンカンバンを導入しました。
プロセスの変更にはリスクが伴います。スタッフの心理的な抵抗もあります。リーンカンバンをいきなり全社展開することは難しいため、まずは失敗しても大きなダメージを受けない技術検証プロジェクトで試してみることにしました。
リーンカンバンを導入したプロジェクトでは、なぜリーンカンバンを導入するのかしっかりと説明しました。どうしても従来の開発プロセスに戻りたがるメンバーが出るだろうと予想していましたが、新しいものへの好奇心もあってか、大きな反発もなくスムーズにリーンカンバンの運用を始めることができました。最初はたどたどしい運用でしたが、日々熱心に改善を繰り返し、楽しみながらリーンカンバンを試しました。
このプロジェクトでリーンカンバンの有効性が確認されたため、他のプロジェクトにもリーンカンバンを導入することになりました。
他プロジェクトへの展開
自分が担当していたプロジェクトが4つあったため、それぞれのプロジェクトに順次リーンカンバンを導入していきました。
すでに成功事例があり、（楽しそうな）開発の雰囲気が社内に伝わっていましたので、他プロジェクトへの展開にあたりほとんど抵抗はありませんでした。
リーンカンバンを導入してよかったこと
リーンカンバンを導入してよかったことは以下の3点です。
- タスクが高速に消化されるようになった
- コミュニケーションが活発になった
- チームワークが強固になった
タスクが高速に消化されるようになった
タスクは、遅くとも2日以内で終わる粒度まで細かく分割し、付箋に書いてホワイトボードに貼ります。
そのうえで、カンバン上に2日以上滞留している付箋を見つけたら、救急車のマグネットを貼ってチーム全員で問題解決に乗り出します。
大抵の場合、スキルの高いリーダーやメンバーが手伝うことで、そのタスクはその日のうちにDoneになり、付箋が右に（Doneの列に）移動します。
このようにして、タスクの滞留時間をなるべく短くし、左から右にどんどん付箋を動かすように心がけることで、タスクが高速に消化されるようになりました。
カンバンを使うことで、個人の実行スピードに頼るのではなく、組織力で実行スピードを上げられるようになったと思います。
コミュニケーションが活発になった
私たちの場合、毎朝、カンバン前でスタンドアップミーティングをしています。
まず、1人のメンバーが、最近あった「良かったこと」「新しいこと」を発表します。Good & Newと呼んでいます。これはアイスブレイクのようなものですが、単に場を温めるだけでなく、そのメンバーのプライベートな一面を知ることも目的の一つとなっています。
その後、全メンバーが1人ずつ、「昨日やったこと」「今日やること」「困っていること」を話していきます。ここで大切なことは、話の内容ではなくて、全員が何か一言でも話すことです。どうやら、人は一度でも自分が話すと、相手の話もよく聞けるようになり、また、プロジェクトへの参加意識が高まるようです。
毎朝、メンバーについてプライベートな一面を知り、また全員が一言ずつ何かを話すことで、チーム全体の毎日のコミュニケーションがとても活発になりました。
プロジェクト失敗の最大の原因は「コミュニケーション不足」とよく言われます。コミュニケーションの活性化にリーンカンバンは大きく寄与していると思います。
チームワークが強固になった
ウォーターフォール型で開発していたときは、企画、開発、QAというように職能がはっきり分かれていて、職能間の壁は高いものがありました。
ときには、職能間で敵対的な雰囲気になることもあります。「企画が仕様を明確にしないから開発できない」「開発が納期を守らないからQAにしわ寄せが来ている」こんな言葉を聞くこともありました。
ウォーターフォールからリーンカンバンに移行して、座席の配置も変え、「全員が企画者であり開発者でありQAである」ことを確認してからは、そうした職能間の壁は徐々に低くなっていきました。
もちろん、一気に壁がなくなったりはしませんでしたが、そこはプロジェクトマネージャーとプロジェクトリーダーが協力し、メンバーの心理的な抵抗感を徐々に潰していくことができたと思います。
リーンカンバンの運用上の課題
実際にリーンカンバンを運用してみて見えてきた課題もあります。
- 進捗が見えづらい
- タスク間の依存関係がわかりづらい
- 運用に手間がかかる
進捗が見えづらい
開発計画に対し、進んでいるのか遅れているのかわかりづらい点が一番の課題です。
別途、スケジュール表や、ガントチャート、バーンダウンチャートを用いて全体の進捗管理をしています。
タスク間の依存関係がわかりづらい
タスク間に依存関係がある場合、ひと目でそれがわかりづらい点も課題です。
運用に手間がかかる
ホワイトボードを作ったり、直したり、意外と運用に手間がかかります。
ホワイトボードが足りない
いろいろなプロジェクトでリーンカンバンを導入していったら、ホワイトボードが足りなくなりました。
それだけ社内にリーンカンバンが定着し、コミュニケーションが活性化して、チームワークも強固になってきたということで、喜ばしく思います。
リーンカンバンを運用するうえで、やってはいけないなと思うのは、アナログなカンバン（ホワイトボード）を捨てる（使わない）ことです。
カンバンの真価は、コミュニケーションの活性化とチームワークの強化にあります。デジタルなカンバンでは、その点が大きく弱まり、進捗管理のためだけのツールに成り下がってしまう危険性があります。
リモート拠点で開発しているメンバーがいる場合でも、アナログなカンバンをメインに運用し、リモートのメンバーにはホワイトボードの写真を毎日撮影して共有するような運用が有効だと思います。手間はかかりますが、それだけ、アナログなカンバンにこだわる価値があると思います。
今後もリーンカンバンの運用を磨き続け、より生産性高く、楽しく開発できる環境を作っていこうと思います。