プログラマの思索

Redmineによるチケット駆動開発、タスクボードやバーンダウンチャートによる運用事例を見つけたのでメモ。
僕は、以下の事例のように、実際の現場で試行錯誤しながら自分たちの運用を見つけていくボトムアップのやり方が好きだ。
パターン言語の発想に通じるものがある。

【元ネタ】
ASE アドヴァンスト・ソフト・エンジニアリング｜タスクボード、バーンダウンチャートの運用（実際にやってみて）（第一回）

ASE アドヴァンスト・ソフト・エンジニアリング｜タスクボード、バーンダウンチャートの運用（実際にやってみて）（第二回）

ASE アドヴァンスト・ソフト・エンジニアリング｜タスクボード、バーンダウンチャートの運用（実際にやってみて）（第三回）

ASE アドヴァンスト・ソフト・エンジニアリング｜タスクボード、バーンダウンチャートの運用（実際にやってみて）（第四回）

ASE アドヴァンスト・ソフト・エンジニアリング｜タスクボード、バーンダウンチャートの運用（実際にやってみて）（第五回）

ASE アドヴァンスト・ソフト・エンジニアリング｜タスクボード、バーンダウンチャートの運用（実際にやってみて）（第六回：最終回）

【1】以下の記述から経験談が始まる。
詳細なお話は上記のリンクを読んで欲しい。

(引用開始)
余談ですが、当時はワクワクと胸を躍らせながら始めていた気がします。
なお、チーム内では既に「チケット駆動開発」を取り入れており、そのツールとして「Redmine」を利用しておりました。また、アジャイルの手法には、Scrumを採用しています。ただし、残念ながらお客様との契約形態は「請負」であり、その中で開発フェーズをアジャイル開発で実施していました。以下の内容はそれを利用している前提で記述しています。
(引用終了)

(以下抜粋)
胸をワクワクしながら始めたタスクボードやバーンダウンチャートですが、残念ながら多くのアジャイルを始めた同士達と同じ様に「ハマリ」ました。そんなハマった事象をご紹介したいと思います。
この時に発生した事象としては、以下のようなものがありました。

・このタスクなにするんだっけ？
・このタスクのボリュームは？
・ぱっとみで分からない
・収束しないタスク
・0にならないバーンダウンチャート
・タスク持ち越し
・優先度が分からない
・関連がわからない
・粘着率が悪い
・朝ミ・夕ミなげーよ
・今する話じゃないだろう
・打ち合わせ眠くなる。。。
・それ俺には関係ない話だな
・それ俺には出来ない話だな
・とったけど出来ませんでした
・テストって残るよね

以下、掴み取った転機の一覧です。
・色分けだー
・バーンダウンの種別わけだー
・TRYの貼りだしだー
・優先度に応じたチケット移動だー
・タスクの粒度はこれだー
・皆で何するか決めるんだー
・ちゃっちゃと終わらせちゃれ
・タスク無いならこれやって
・必要だからこれ先にやって
・気合よりも仕組みを！
・間に合わない。だったら客と死ぬ気で交渉

以下、課題の一覧です。
・それでも残るタスク
・増やさない努力はいつから行うべきか
・誰にとっての優先度
・誰でもできるもの、彼らにしかできないもの
・作業時間、見積もり時間
・誰がネックになるのか、特定の人だけなのか
・ちゃっちゃと終わらせちゃれ
(抜粋終了)

【2】読んでいて興味を引いた点はいくつかある。
一つ目は、綺麗なバーンダウンチャートを運用するのは難しいこと。
バーンダウンチャートを表示するには、イテレーション開始時に総予定工数を見積りし、イテレーション終了まで残工数を常に入力し、計測する運用が前提条件だ。
その前提条件を満たしながら運用するのは、僕自身も経験があるが、至難の業だ。

実際の現場では、イテレーションの途中に割り込みで作業が増えざるを得ない状況が発生しやすい。
すると、最初の総予定工数そのものが狂ってしまう。
また、残工数をメンバーに逐一入力させるのは結構面倒だ。その作業だけで退社間際に1時間以上の労力をかけてしまいがち。
しかも、その結果を集計し、バーンダウンチャートへ毎日プロットしていく作業をリーダーが残業してやるのだから、溜まったものではない。

だから僕のチームではRedmineのロードマップを毎日の朝会で確認しながら、直近のバージョンをまず100％完了するまでに持って行く事を最優先とした。
綺麗なバーンダウンチャートを運用するよりも、納期までに確実にリリースするのを最優先したからだ。

上記の記事では、バーンダウンチャートがイテレーション終了時に0にならない時がほとんどだったという。
その理由は詳しく書かれていないが、推測するに、タスクを完全に完了するには顧客へ仕様を再確認する場合があったり、リリースはできたものの新たなリスクが発生したため暫定対応となり完全に障害が解決できていない場合があるのだろうと思う。
そのような状況は、チケット駆動開発であってもよくある事例だと思う。

その場合は、残タスクやリスク、課題をタスクから切り離して、次のイテレーションないしバックログ、アイスボックスへ回す運用でカバーするしかないだろうと思う。
ソフトウェア開発は1回だけの本番リリースで、物事が全て解決する状況は殆ど無い。
例えば「マイクロソフトの製品はバージョン3になって初めて使える」と揶揄された時があったけれど、その言葉が意味することは、ソフトウェアは複数回のリリースを経てやっとまともに使えるようになるということだ。
だから、最初から完璧なソフトウェアを目指すよりも、自分たちの可能な範囲で少しずつ改良していく戦略を取る方がいい。
そのためには、残タスク、残課題、将来へのリスクを忘れずに検知しておき、しかるべきタイミングで1つずつ潰していくしかないのだと思う。

【3】2つ目は、「気合よりも仕組みを！」という言葉。
KPTによるふりかえりをやった経験がある人は分かるが、Tryには次回のイテレーションにチャレンジする内容を書く。
その時に、具体的な対策を挙げるときもあるが、「～したいな」という希望だけで終わる時もあるし、以前からずっと同じTryがあがる時がある。
すると、単なる希望的観測だけでTryが終わってしまい、本来の運用改善につながっていない時がある。

KPTの本来の意図を平鍋さんに質問した時があったけれど、ふりかえりではあくまでもメンバーから意見を引き出し、メンバーへ気づきをフィードバックするのを重視するため、希望的観測であれ、意見が出るのはいい。
「自分たちは～のようにありたい」という意見をまず出さなければ、どの方向へ改善するか分からないから。

しかし、この問題は正直難しい。
チームの成熟度が低ければ、ふりかえりは単なる反省会に過ぎない。
つまり、メンバー自身が自らの課題を認識し、それに対して対策を立てて実施し、実施した結果の評価を行うだけでなく、実施した対策そのものの評価と課題を見つける作業を訓練した経験がなければ、そう簡単には改善できないだろう。
つまり、改善していく仕組みを作らなければ、自己満足で終わってしまう。

そして、いずれにしても、現場の状況(コンテキスト)は各チーム、各プロジェクトで異なるため、他のチームの運用が全て効果的になるように当てはまるとは限らないことだ。

だから、正直、この問題にはこれと言った解決策はない。
でも、チケット駆動開発の利点の一つは、プロセスを定量化する手段を付与してくれる点なので、改善の糸口を見つけやすいことがある。
例えば、残作業が溜まり過ぎるならば、チケットの優先度や重要度を工夫したり、スコープ管理を意識して思い切ってチケットを削ったりする。
あるいは、課題や障害のうち、重要度が高いものは予防対策を立てたり、重要度が低いものは都度対応で無視する運用にしたりする。
あるいは、コードレビューや障害検証をペアで作業するように工夫して、品質を互いにチェックするだけでなく、メンバーのプログラミング技術や業務知識を共有できるように運用したりする。
他にも色々あるだろう。
自分たちが生み出した対策の評価を必ずまとめて、ノウハウを地道に貯めていくしかないのだろうと思う。

【4】逆に、自分たちの現場で編み出した運用ルールは、実践した経験に基づくため、とても価値あるものになる。
何故なら、自分たちのチームだけとはいえ、チームで実証された効果的な運用ルールだから。
その運用ルールが抽象化され、他のチームで運用して効果が出れば、パターン言語になる。

「チケット駆動開発」という言葉が広く知られるようになり、あちこちで実践されている状況を聞くと、それら現場で効果があると知られた経験をプラクティスという名のパターン言語で、再利用可能な形式知としてまとめたくなってくる。
ツールに依存しないチケット駆動のプラクティスを収集するために、他にも事例を集めてみる。