プログラマの思索

Agile開発のイテレーションの考え方は、業務の締め処理と同じではないか、というアイデアについてメモ。

【元ネタ】
Twitter / @akipii: Redmineでイテレーションの概念が分からない人は、締という業務が分かっていない。締がないから、仕掛かり在庫(未完了チケット)がどんどん溜まるだけ。TPS(リーンソフトウェア開発)の発想に通じる。

【1】Redmineを各チームに運用してもらうと、使い方が分かっているなというチームと、Redmineは使いづらくてExcelに戻ってしまうチームの2種類に分かれる。

Redmineが使いづらいと不満を言うチームは、開発業務をRedmineへマッピングできてない。

チケットの粒度が大きすぎて、2週間もかかるタスクを1個のチケットで平気でアサインする。
チケットを登録する運用はできているが、リーダーやメンバーが定期的に精査する運用がないため、乱発されて放置されて、すぐにゴミ箱になる。
Redmineのバージョンの使い方がわかってないので、チケット一覧でスクロールできないくらいのたくさんのチケットを一生懸命クリックしては、チェックしている。

あるいは、工程とRedmineバージョンを紐づけているため、いつまで経ってもRedmineバージョンをCloseできない。
手戻り作業があるたびに、前工程の作業をやり直すからだ。

あるいは、ガントチャートを綺麗に表示させるために、チケットの期限や作業状態を保守するのは良いが、本番リリースを意識していないので、リリース間際になってドタバタしている。
だから、ガントチャートを使うチームは、イナズマ線が欲しいと言う。

【2】Redmineの運用で最も大事な事は、イテレーションを意識することだと思う。
イテレーションとは、Redmineの対象バージョンであり、本番リリース日であり、システム開発のマイルストーンであり、システムの納期である。

リリースするシステムこそが価値を生む源泉であるから、Redmineでは本番リリースする日がとても重要だ。
本番リリースで初めて自分たちが作ったシステムが、顧客にとって本当に価値があったのか、評価される。
本番リリース日が、Redmineの対象バージョンに相当する。

本番リリース間際になってもタスクがチケットとしてたくさん残っている状況は、仕掛品が多いことを意味していて、それは、無駄が多い事実を示している。
TPS(トヨタ生産方式)に影響を受けたリーンソフトウェア開発で言う、7つの無駄のどれかが含まれているだろう。

つまり、会社の業務に例えれば、毎月の月末締めに相当する。
このアイデアについては、既に下記で具体例を書いた。

TiDD初心者が陥りやすい罠～バージョンをCloseしないRedmineはVelocityが分からない: プログラマの思索

例えば、普通の会社では、月末に営業活動を一旦締めて、売上と仕入、在庫の資産を確定する。
締めが行われるから、月次の売上と費用、利益が確定される。
だから、社員に前月の労働に対する対価として給料も支払われる。
1年続ければ、決算処理で損益計算書と貸借対照表が作られる。

締め処理では、今どれだけのキャッシュ(現金)があるのか、売上見込(売掛金)や負債(買掛金)があるのか、を精査する。
そうしなければ、黒字なのにキャッシュが足りなくて黒字倒産してしまう。

Redmineでチケット管理を始めると、チケットがタスクであり、それらタスクの成果物が集まって初めて一つのシステムがリリースされる。
本番リリースとは、価値あるソフトウェアを顧客に届けて、顧客の受入を行うことに相当する。
つまり、本番リリースから逆算した作業がチケットに登録されるべき。

チケットの粒度が分からないという人達は、おそらく本番リリースに向けてどんな作業が必要なのか、が多分見えてないのだろうと思う。
本番リリースで失敗は許されないのだから、必要な作業はWBSとして階層化して登録しておき、イテレーション実施中に、チケットを更新したり却下したり、漏れていたタスクを登録したりして、精度を上げていけばいい。
最初から計画が完璧でなくていいが、その計画の精度はイテレーションを実施しながら上げていくべき。
Redmineによるチケット駆動開発の利点は、作業を見える化することで漏れなく作業しやすくなることだから、作業の整合性を考えればいい。

【3】締め処理で特に重要なのは、倉庫にある在庫の資産を棚卸し評価することだ。
倉庫にある商品又は製品は、売りたい商品なのにキャッシュに変わっていないのだから、在庫が膨れ上がるほどキャッシュの状況は悪いことになる。
製造業の工場で製造中の仕掛品ならば、製品にすらなっていないわけだから、仕掛品が多いほど無駄が多いことになる。

つまり、締め処理では、実棚という実地棚卸し作業で、帳簿上の在庫資産と実際の倉庫にある在庫資産を一致させる作業を行う。
実際の業務では、理論在庫と実際在庫は食い違う時が多いので、実地棚卸で誤差をなくす。

Redmineによるチケット管理でも、バージョンをCloseさせるタイミングで、チケットの棚卸しを行う。
チケットの棚卸しでは、残ったチケットは今すぐやるべきなのか、次のバージョンへ延期して良いのか、それともそのチケットをそもそもやる事なく却下して捨ててもいいのか、を判断する。
つまり、チケットの棚卸作業で、チケットの終了基準、バージョンの終了基準をクリアしているのかを精査している。

定期的な棚卸しを運用できれば、Redmineチケットがトランプのカードのように思えて、まるでゲームをやっている感覚になる。
多分その感覚を、XPは計画ゲームと呼んだのだろうと推測する。

【4】更にチケットの棚卸作業によって、Scrumの言う重要な概念Velocityが計測される。
Velocityは開発チームの生産能力であり、チケットの粒度が一定ならば、1イテレーションの平均完了チケット数(実際は平均作業量)になる。

ScrumやXPが教える所によれば、Velocityは増やすものではなく、安定すべき値である。
つまり、適切なペースで一定のペースで開発のリズムを生むべきもの。

Velocityの概念は、開発チームの生産能力には限界があることを示唆していると思う。
製造業の工場ならば、資金があるなら設備投資して、工場の生産能力をどんどん拡張できる。
しかし、ソフトウェア開発では、いくら資金があったところで、設備投資してもサーバーやPCが増やせるぐらい。
人をたくさん投入するほど、生産能力が落ちることは、人月の神話以来、既に知られている。

つまり、ソフトウェア開発の生産能力はとても貴重な有限な資源であることを意味している。
開発チームにたくさんの人員を投入したとしても、開発チームは混乱して、納期になってもバグだらけのシステムしかリリースできないだけだ。

【5】ITSのマイルストーンとは、Agile開発のイテレーションであり、システムのリリース予定バージョンであり、本番リリース日であり、SCMブランチ(trunk, リリースブランチ)であり、リリースされる製品と同一視できる。

RedmineやTracなどのITS(課題管理システム)の一機能であるマイルストーンは、たくさんの意味を持っていると思う。