関心事の違いによる問題
SIのように作りたい機能の方針が決まっているときには良いのですが、Web系のシステムで、その機能を作るべきかどうかがより揺らぎやすい時、何人ものアイデアが集まってきてしまう時にカンバンに全てをのせてしまうと制御できなくなってしまいました。
ビジネスとシステムのやりたいことの粒度が違い、カンバン上のチケットが中途半端になって、状況把握が難しくなってしまったので、この方法を試そうとしているところです。
システムサイド、エンジニアの関心事
システム側としては仕様の複雑さの整理やアーキテクチャ選定、検証作業などスケジュールが読みづらいリスクの高い作業があります。また、これはビジネス側から見ればほとんど進捗が見えません。
また、作業中の開発タスクの粒度も違います。実装の他にも沢山の作業があるのです。
進めること以外に、機能ではない非機能な部分がたくさんあります。中長期的な観点や協調作業のための時間も必要です。
技術的負債の解消やリファクタリング、設計やドキュメント、レビューなどです。
レビューが止まってしまえば短期的なスピードは上がっても中長期的なクオリティが保てないのは当然です。
そしてレビュー時間を正しく掌握出来なければ、他の作業の進捗が押してしまうのは当然です。
エンジニアとしてはチケットをできるだけ細かくして、やることを明確にすることで実装などのシステム化に集中することが出来ます。
ビジネスサイドの関心事
ビジネス側の興味関心は「スケジュール」と「提供させる機能」がどこまでのことが実現できるかということです。
ビジネス側はやりたいことは沢山出てきます。プロダクトバックログに追加されます。
スプリントバックログに落とし込まれます。
方針が決定された上で落とし込まれたものであれば良いのですが、仕様の粒度が大抵の場合は大きいです。
なぜなら、必要な機能の幾つかが揃ってから初めて価値を生むからです。
では、ビジネスサイドはプロダクトバックログとスプリントバックログのストーリーだけ見ればよいのでしょうか？
それはカンバンを全体に表示している意味はあるのでしょうか？
じゃあ、カンバン全体を見れば良いのでしょうか？ カラム追加を確認するのにビジネスサイドの人間の時間を使って良いのでしょうか？
現状で挑戦しようとしていること
この項目については、まだ自分の中でも答えを見つけれていません。
今チャレンジしようとしているのが、ビジネス側と意識を合わせるためのカンバンと開発チームが使うカンバンを分けて、全く違う粒度と違うコミュニケーションをするためのチケットの作り方を定義して回すようにしました。
ビジネス側がビジネスのカンバンにストーリーを書き、優先順を決めるのは変わりません。
システム側はそのカンバンにはビジネスに共有したい内容と大きな負債対応などの作業などの要望を書いたりします。
このときにはビジネスサイドに伝わる言葉で書くということです。
alter tableやzabbix設定とかは書いたらダメです。
あえて書くなら、データベース構造の変更とシステム監視設定の追加です。
システムサイドはビジネスサイドのカンバンを受けて、各一人がメインにつけれるくらいのストーリーなどに落とし込んだり、システムカンバンでは親子関係が生まれくらいチケットを細かく定義し直します。
要件や機能のリスク、アーキテクチャ方針などをできるだけ落とし込むことが出来ることで、ビジネスとシステムのやりたいことの粒度が中途半端になって、状況把握が難しくなってしまったルールを変えました。
管理コストが上がってしまうことと、ビジネスサイドもしっかりと運用してもらうための意識付けが必要なため、難易度が高いかもしれませんが、良い結果が出せれば、また違う場所で報告ができればと思います。