[#TiDD] チケットのエクセル連携は工事進行基準と相性が悪い(更新)
工事進行基準
工事進行基準というのは、最終納品時に売り上げを計上するのではなく、開発の進捗に合わせて売り上げを計上できる会計の方法です。毎月売り上げが上がるので、納品が1日遅れるだけで売り上げが次の期なるということがありません。
工事進行基準を採用するには、一定の規模以上で、きちんと計画が立てられていて(ある程度詳細なWBSがあり)、その実施が可能と考えられる場合です(売り上げを単純に期間で立てられる会社もあるようですので、もう少しゆるい場合もあるかもしれません。
私の勤める会社の場合、顧客と合意した工数でWBSを作成し、そのWBS上の
(完了工数/総工数)×受注金額
で売り上げを決めます(完了工数にもステータスで進捗率を決めるなどのルールがありますがここでは省略します)。チケット駆動開発のプロジェクトではWBS 相当の情報をチケットにしますので、当然のようにチケットの内容をTSVで出力して、エクセルで整形しようと考えました。
そこには壁が
担当プロジェクトは客先常駐作業でした。お客様は情報漏えいを気にされていましたので、条件がつきました。「技術要件が外に出ないように」とのこと。そこで、文字列の入れ替えもしくは番号での表記、あまりにも細かいタスクは連携せずに上位タスクを連携する、といったことをEXCELシートでやりました。
その結果、それなりのWBSができました。しかし、1ヶ月以上の結合テストのタスクができて「詳細化が不足している」との指摘を受けたほか、自分でもどれがどのタスクであるかわかりにくいものになってしまいました。
タスクが増やせない
それだけであれば適当に調整すれば何とかなるのですが、開発を進めるうちに別の問題が発生しました。工事進行基準は総工数に対する完了済み工数の比率で生産額を決めます。しかし、なにかタスクを追加するだけで総工数が変わってしまい、売上げの予定が変わってしまいました。たった1時間か2時間のタスクを追加するだけで、売上げに影響しました。こんな恐ろしいことはありません。
そんな風に勝手に総工数が変わらないように、リーダーなりマネージャが新規タスクを管理すればよいのですが、細々としたチケットまで管理できません。また、細かなタスクも管理できる、個人の作業を自己管理できる、というチケット駆動開発の良さが失われてしまいます。
実は工事進行基準の場合、生産計画の工数と実際の配員工数は一致しなくてもかまいません。お客様と合意した機能に、合意した工数を割り当てたものが生産計画で、余裕を残して少なく配員しても良いし、予想外の問題などで過配員になってもかまいません(利益が減るので問題ですが、、、)。ポイントは計画した時期に、計画した機能が実現されていれば良いのです。もちろん、実現できない時は生産計画を見直します。
問題なのは、生産計画のWBSと配員は異なっても良いのに、両方に共通のチケットにしてしまったことです。チケット駆動開発では作業をチケットにしますので、チケットは配員を表しています。 2日で計画したことを2.5日かかりそうであれば、そのように計画を変更し、他のタスクと調整します。残業を増やして解決できるならそれでも良いですし、余裕のある仲間にチケットを担当してもらってもかまいません。いずれにしろ、計画した機能が経過した時期にできればよいのです。工事進行基準は1か月単位で売り上げを得委譲しますので、極言するならその月の間に計画通りの機能ができればよいのです(もちろん、間に合わなければ再計画が必要です)。
結局、チケットは生産計画ではないということで、チケットからエクセルに進捗を連携することをやめて、生産計画とその進捗はエクセルで管理しました。
じゃあ、エクセルの職場は?
考えてみると、そもそも別物を一つのデータで扱うことが無謀だったのです。生産計画と配員は違うのですから、当初の生産計画に対する進捗と、さらに細かな作業が明確になった現状での進捗は異なって当然だったのです。
では、チケット駆動開発ではない場合はどうしているのか、私は経験が無いので理論だけで考えてみました。生産計画と配員の二つがあるのですから、
- 2重帳簿方式で管理している
- 「生産計画=配員」として一元管理している
このどちらかだと思います。一般には、「生産計画=配員」のことが多いので、2が多いと思うのですが、どうでしょうか?
もし、そうだとすると、エクセルで管理されているなら、細かなタスクが新たに見つかった場合、こんなことが行われるのでしょうね。
- 見える化されない:タスクが追加されず、他の人にも知られず、協力もされない
- 多大な管理工数をかける:WBSを修正、生産計画を修正、売上げ予定を調整する
いずれかの対応が、組織の文化によってなされるのでしょうね。
このように考えると、エクセルだけで管理するよりも、やはりチケット駆動開発で、新しいタスクを追加し、見える化し、協力し合うプロジェクトが良いと思いました。
« [#TiDD] チケット駆動開発のはじまり #devsumi | トップページ | 意外にいける赤ワイン BANROCK STATION CABERNET SAUVIGNON / SHIRAZ(更新) »
「チケット駆動開発」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- [#TiDD] ポケモンGOにチケット駆動開発のポイントを学ぶ(2018.05.01)
- [#TiDD] プロジェクトを成功させるチケット管理(2017.07.02)
この記事へのコメントは終了しました。
« [#TiDD] チケット駆動開発のはじまり #devsumi | トップページ | 意外にいける赤ワイン BANROCK STATION CABERNET SAUVIGNON / SHIRAZ(更新) »
コメント