マイクロマネジメントに陥ったチケット駆動開発の罠と再生戦略 #redminet

現代ではチケット駆動開発は当たり前になった。
しかし今、その運用はマイクロマネジメント化し、タスク管理のはずが管理強化の道具となり、現場の自律性を奪うケースが増えている。
加えて大規模運用の壁も顕在化している。
現場視点で課題と打ち手を具体的に考えてみる。

【参考】
Redmineによるタスクマネジメント実践技法 : 小川 明彦, 阪井 誠: 本

チケット駆動開発 : 小川 明彦, 阪井 誠: 本

逆引きでわかる！ Redmineハンドブック バージョン5.0対応 | 川端 光義 |本 | 通販 | Amazon

Redmine実践ガイド 理論と実践、事例で学ぶ新しいプロジェクトマネジメント | 株式会社アジャイルウェア |本 | 通販 | Amazon

入門Redmine第6版

【1】僕が2008年に「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ 」をKOFで発表してからもう15年以上経った。
現在地点では、チケット駆動開発をベースとしたソフトウェア開発は、アジャイル開発であれ、WF型開発であれ、たぶん当たり前になっているだろう。

redmine-presentation-846109from akipii Oga

では、現在地点におけるチケット駆動開発の課題は何があるのだろうか？
チケット駆動開発のどこに問題が起きているのだろうか？

【2】僕個人の考えでは、2つの問題があると思う。

1つ目は、チケット駆動開発がマイクロマネジメントのツールに化してしまっていること。もう1つは、大規模チームでチケット駆動開発を運用するノウハウがまだ蓄積できていないこと。

前者の問題点は、伊藤直也さんがツイートされている。

Xユーザーのnaoyaさん: 「タスクを細かく洗い出してチケット切って開発みたいなの、自分は基本的に信用してない マイクロマネジメントで作業者から自分で物事を考えて進める思考や責任を奪ってる」 / X

Xユーザーのnaoyaさん: 「チームでざっくり直近の目標を決めて、それぞれの担当領域を決めたらその領域内でどうつくるかは各々に任せる そのうえで作ってるものの過程は成果物をマネジメントするべきで、プロセスをマネジメントしない」 / X

Xユーザーのnaoyaさん: 「2週間とかの期間がある中で、どこで本気出すかは各々の自由だしそれはコントロールできるものでもない マイクロマネジメントはその裁量を奪うだけだ」 / X

Xユーザーのnaoyaさん: 「良いプロダクトは、洗い出したタスクを全部こなしたらできあがるわけではなく、良いプロダクトになるよう仕上げることで出来上がるもの プロセスをマネジメントしすぎると、結果タスクをこなすことにマインドが向かう 良いプロダクトに仕上げることにマインドが向くようマネジメントするべき」 / X

Xユーザーのnaoyaさん: 「良いプロダクトにしようと思ったら、作りながら発見した事実をもとに、臨機応変にやることを変えていく必要がある タスク志向になると、この自分で臨機応変に状況にあわせてやることを変える、という力を奪うことになる」 / X

本来のチケット駆動開発は、タスク管理をプロマネから開発者へ権限委譲し、開発者自身がアジャイル開発をベースにタスクを消化していくことで、ソフトウェアを開発するスタイルだった。開発者の自主性を引き出す効果があった。

しかし、チケットをWBSとみなせばWF型開発にも適用できるので、プロマネが計画時点でPJ計画書に基づいてWBSをチケット化して開発者に押し付ける運用も多く見かける。
つまり、開発者がタスクを考える必要もなく、プロマネがチケットを担当する開発者をマイクロマネジメントするための道具になってしまった。
すなわち、開発者がシステム開発するためにタスクを詳細化していく思考を奪ってしまい、単純労働者の地位に押し付けられている。
こうなってしまうと、チケット駆動開発はアジャイルさを失い、ガチガチのマイクロマネジメントの道具になってしまっている。

【3】では、そんな状態から脱出し、本来のチケット駆動開発の良さを引き出すには何が必要なのか？

そもそも、マイクロマネジメントしたい状況は、特に製造業の工程管理や、ソフトウェア開発の大規模案件でよく見かける。
たとえば、製造業の工程管理では、受注、設計、購買、製造、出荷物流のような工程があらかじめ決まっている。
各工程では、メカ・エレキ・ソフト・品質管理担当などがどんな役割でどんな作業をするのか、ISOの規定に沿ってあらかじめ決まっている。
それらのタスクは、受注した時点であらかじめ確定する。
後は、納期に合わせてスケジュールを作り、担当者の負荷計画を立てるだけだ。
つまり、WF型開発みたいにガチガチの作業管理になるのは必然だ。

しかし、実際の製造業の現場を見ると、設計者も生産管理担当者も3つ4つの製品を担当していて、複数案件をまたがって作業しているのが一般的だ。
つまり、製造業の組織が機能別組織であっても、実際の作業者は複数案件を掛け持ちして兼務しているので、自然にマトリクス型組織になる。
2ボス体制なので、レポートラインが2つ以上あるため、作業者は非常にやりづらい。
製造業の担当者はいつも複数製品の作業で手一杯で、いつも忙しそうにしている。
毎日自転車操業しているようなものだ。

よって、ガチガチのガントチャート管理をしてもすぐに進捗遅延が発生する。
納期間近になってドタバタするのが当たり前だ。

だからこそ、本来のチケット駆動開発の良さを引き出すには、突破的な作業はチケット管理で忘れないように起票して毎日の朝会で優先順位付けすることが大事だと思う。
一方で、製造業では工程管理も重要なので、突発的な作業管理以外にも、工程管理するためのチケット管理も必要になると思う。

つまり、製造業のタスク管理では、突発的な作業管理と工程管理の2種類のチケット管理が必要になるだろう。
マイクロマネジメントになる雰囲気があっても、やるべき作業は見える化し、チームとして対応していく雰囲気づくりは必要だと考える。

【4】後者の問題は、大規模なチケット駆動開発により、管理の複雑性が増していることに起因しているのだと思う。

元々、チケット駆動開発は数人レベルの小規模なチームによる開発経験から生まれた。
だから、少人数で俊敏に開発するアジャイル開発と親和性が高い。
そこから、アジャイル開発のプラクティスを取り入れると開発が上手くいくことが分かり、チケット駆動開発のプラクティスやアンチパターンも色々分かってきた。

また、チケット駆動開発は元々柔軟なワークフロー管理機能を持つので、ITILによるソフトウェア保守、情シスのタスク管理、システム監査、カスタマーサポートなどにも適用できる。
つまり、色んなプロセスをチケット駆動開発で実現できる。そこが、チケット駆動開発の面白さの一つだと思う。

しかし、チケット駆動開発の適用範囲が広がり、ユーザ数やチケット数が膨大に増えていくと、複雑性が増して、単純な運用ルールだけではじきに手が負えなくなる。
大規模なチケット駆動開発では、複雑性を制御するために、何らかの標準プロセスの実装が必要になってくるのだと思う。

では、大規模なチケット駆動開発による複雑性は、どのように解決すればいいのか？

Redmineコミュニティで今までに語られたアイデアの一つとしては、Redmine警察やRedmine職人のような役割を設けたり、定期的な棚卸し会を運用するなど、組織として運用する仕組みを作ること。

他には、大規模アジャイル開発のフレームワークであるLeSS、SAFeなどのアイデアを参考にして、チームやプロセスを階層化して管理する手法もあるだろう。

つまり、チームやプロセスを階層化することで、会議体を整理し、必要な情報がレイヤに関係なく共有できる仕組みづくりが必要だろうと考えsる。

【5】2つのテーマに関するこの辺りの問題点、解決法を整理してみたいと思う。