新鮮

頑張らないために頑張る

【ダイエット】バーンダウンで痩せてみる【マネジメント】

f:id:hiizumix:20180226191028j:plain

さて「バーンダウンチャート」である。

先日はダイエット・マネジメントに情報システム開発手法「バーンダウンチャート」を適用してみようと考えだしたが、結局はガントチャートの不平不満をまき散らしただけのエントリで終わってしまった。

f:id:hiizumix:20180301201051j:plain

ほんとクズだよね

すまん。

バーンダウンチャートとは

バーンダウンチャートは実際のモノを出した方が早いだろう。

f:id:hiizumix:20180301201920j:plain

縦軸を残作業量、横軸を時間として、予定の残作業量と実績の残作業量をプロットしたシンプルなチャートだ。実績線が一番下まで到達したらプロジェクト完了である。

バーンダウンチャートはタスクリストを元データとする。ここで「作業量」とは各タスクに重みづけして合算した数字である。

今回のダイエットでは、筋トレを 2 回さぼっても糖質制限を 1 回追加すれば遅れは挽回できると想定し、次の重みづけをしている。

  • タスク「標準食事メニュー」、重み = 2
  • タスク「筋トレ」、重み = 1

さて、バーンダウンチャートの特徴を利点と欠点で述べよう。

バーンダウンチャートの利点

わかりやすい

まず作業進捗がすぐにわかる。

実績線が予定線より上にあれば遅れているし下にあれば進んでいる。もっと頑張るべきか多少緩くしてもいいかがパッと見た瞬間にわかる。これはモチベーションを維持していくために意外と重要なことである。

f:id:hiizumix:20180301202347j:plain

いきなり遅れているけど?

・・・そだねー。

メンテナンスが簡単

ガントチャートをメンテナンスするのは大変だ。僕はやりたくない。もちろん補助するツールはたくさんあるのだが、仕様変更のたび、リスク顕在化のたび、必死に後続工程を含めた見直しをする必要がある。

大体のケースにおいて、タスク管理に「ガントチャートをメンテナンスすること」と書かれたままメンテされず放置されるか、ガントチャートをメンテするだけの人員を確保することになるのではないだろうか。要は、管理のための管理のための管理のた・・になる。

一方、バーンダウンチャートでは仕様変更が発生したらタスクを追加するだけだ。予定タスクが増えると予定線が上に伸びる形になる。現実のプロジェクトでは決して見たくないチャートだがこんな感じである。

f:id:hiizumix:20180301202721j:plain

ダイエットに使うケースでは、

「思ったより体重が減らないので、ランニングを追加しないとダメか」

といった仕様変更が考えらえるだろう。

パーキンソンの法則が働きにくい?

僕の感覚だが、ガントチャートで管理したときは「予定通りに進めたいな」と感じるが、バーンダウンチャートで管理したときは「早く終わらせたいな」と感じる。

どうもロジカルに話せないので、モチベーションが上がるかも、とだけ。

バーンダウンチャートの欠点

クリティカルパスが分らない

クリティカルパス、すなわちプロジェクトを最短で終わらせるためのルートが分らないという欠点がある。一般にタスクとタスクには前後関係があるため、前後関係を繋ぎ合わせた最短ルートを管理するのがプロジェクトマネジメントである。

僕は何を言っているんだろうか?

具体的に見てみよう。

あなたが鍋をつくって食べたいとき、

  • 野菜を買う → 鍋を作る → 食べる

という流れをとる。当然、野菜が無ければ鍋が作れないので、タスク「野菜を買う」から実行しないとご飯が食べられない。これがいわゆる前後関係である。

では、次はどちらが早くご飯を食べられるだろうか。

  • 野菜を買う → お肉を買う → 鍋を作る → 食べる
  • お肉を買う → 野菜を買う → 鍋を作る → 食べる

仮にお肉屋さんより八百屋さんが自宅から遠かったとしたら、まず八百屋さんに行ってからお肉屋さんに向かうと早くご飯が食べられる。このどちらのルートを選ぶと早く終わるかを判断するのがマネジメントのキモのひとつである。

そこで実際の開発プロジェクトでは他のツール(PERT, CCPM など)と併用したりするのだが、さすがにダイエット管理にそこまではやらない。

まとめ

  • CMMI に倣い「目標→標準化→効果測定→継続的改善」で考える
  • 「効果測定」にはバーンダウンチャートを使う
  • バーンダウンとは予定作業量と実績作業量のチャートである

「継続的改善」は別エントリで考えよう。

おわり