WBSやガントチャートは合意形成の道具と考える【ユタカジン】
おつかれさまです。
本記事は「自分らしい時間的豊かさを追求する」をテーマにしたマガジン「ユタカジン」への投稿です。
僕の前回の記事はこちらです。
今回は「WBS」と「ガントチャート」について愚痴めいた説明と、私の捉え方についてお話します。
大人の組織では合意軽視がダイジ
大人の組織では「こういうモノを作ろう」「こういうコトをしよう」というプロジェクトを始めるとき、段階的に合意形成しながら進めていきます。
まずプロジェクトの目的や目標を、みんなで合意します。
どうせプロジェクトを進めて多忙になるとみんな忘れてしまいます。
そして「そもそも目的は…」と誰かが言い出すところまでがセットだったりします。
んが、とにかく必要です。
つぎに何をどこまでやるか（スコープ）を、みんなで合意します。
決めたところでスコープ外だからと拒否できる人ばかりではありません。
んが、とにかく決めます。
WBSとガントチャート
そして、WBSとガントチャートいう割とムダなものを作ります。
プロジェクトという大きな作業を段階的に小さな作業に分割したもの（WBS:Work Breakdown Structure）を作り、作業ごとに予想時間や順番を定義します。プロジェクトは長期間かけて多くの人が手分けして作業することになるからです。
そしてタスクを順番に実際の日付に割り当てながら、かつ担当を設定しながら「ガントチャート」を作ります。「Ａさんはこの時期この作業だから、同時期の別の作業はＢさんに変えよう」など考えることが増えます。あとすごく大きなディスプレイが欲しくなります。
ガントチャートができれば、あとはみんなが作業を進めながら進捗を反映していくだけです。これで「今週はここまでできたね（できなかったね）」が一目で分かり、みんなで共有できます。
ですが、私の狭い観測範囲では、このWBSとガントチャートはなかなかにムダ感が強いものでした。
WBSを作るのがタイヘン
例えばこの記事を書くという作業をWBSで考えてみます。
ネタを考える
書く
投稿する
から始まり
ネタを考える
ネタ帳からいくつかピックアップする
それぞれのネタについて精査して１つ選ぶ
書く
Scrapboxで下書きを書く
下書きを寝かせる
下書きを推敲して清書とする
投稿する
noteに転記する
タグを付けてマガジンに加えて投稿する
投稿内容で最終チェックする
のように段階的に作業を絞り出していきます。
会社組織でのプロジェクト、例えば「新しいSNSアプリを作る」みたいな規模でこれをやろうとするのは、結構無謀です。
ガントチャートを作るのがタイヘン
WBSの構造を反映して日付に割り当てた図が「ガントチャート」です。
ただ絵を書けば良いわけではなく、ひとつひとつの作業に「担当」や「見積日数」「作業開始日」「進捗状況」といった属性を付けていくため専用ソフトを使うことが多いです。というわけでだいたい４パターンに分かれます。
Microsoft Projectのような有料の専用ソフト（結構高い）
GanttProjectのような無料の専用ソフト（使いづらい）
Redmineなどチケット管理サービスの付属機能（単体では使いづらい）
Excel方眼紙（メンテ不能）
専用ソフトはクセがあるので、慣れないうちはどれを使っても使い勝手に軽くイライラします。あと「これWBSのタスク全部入れるの？」と遠い目になりますｗ もちろんインポート機能などはあるのですが、ずらっとタスク名だけがインポートされると心が折れます。
ガントチャートを維持するのがタイヘン
ガントチャートには「進捗状況」が入ります。
たいていは「着手したので10%」「気持ち半分できた」「あとは確認だけで90%」みたいな思い思いの進捗率が入ります。
もちろんキッチリしたルールで進捗率が決められている現場もありますが、パーセントが実際を反映していないことはままあります。
そんなわけで週次の進捗会議、できれば日時の進捗会議で進捗率を把握して「全体の進捗率」などを把握しておきたい・・・などと考えると、あなたの１日はこれのメンテだけになってしまう可能性が高まります。本当にこれだけで良いのならある意味ラクですが・・・。
ガントチャートが思い通りに進まない
物事は計画通りに進みません。
そんなことはみんな分かっています。
それ以上にWBS→ガントチャートにしたばかりに思い通りにならないものがいくつもあります。
そもそもやらないタスクが出てきて扱いに困る
例えば「下書きを寝かせる」タスク、結局やりませんでした。
そうなると上位の「書く」タスクはいつまでも完了しません。
「下書きを寝かせる」タスクは消すべきでしょうか？
でもこのタスクに見積１日を割り振っているため消してしまうと全体の数字がおかしくなります。
であれば日数0で100%完了とすべきでしょうか？（そうしがちです）
想定外のタスクをどこに入れるべきか悩む
例えば「Scrapboxで下書きを書く」をしようとしたらログインできなくて、パスワードをリセットしてログインしなおしたらメモが全部消えていて、アレ？と思ったらアカウントがそもそも違って・・・といった風に想定外のタスクが発生します。
当然これはガントチャートに反映すべきですが、別のタスクとして書くべきでしょうか？それとも元のタスクの日数が膨らんだだけにすべきでしょうか？別のタスクとするなら順番も反映しないといけなくなります（面倒）
終わらないタスクが大量に残って現実と乖離する
例えば「投稿内容で最終チェックする」タスクが、なかなか実施できなかったとします。アプリ開発だと「単機能を動作確認する」といったもので、これもなかなか実施できないことがあります。
するとこのタスクは90%で延々と残ることになります。ある日「進捗状況は？」と聞かれたときに、完了となっていないものの多さをナントカ取り繕う必要が出てきます（面倒）
このように気持ち的には終わっているのに終わっていない、というタスクが大量に残りがちです。
そんなこんなでガントチャートはメンテされなくなりがちです。
一度メンテされなくなったら最後、次は書き直しか、でっち上げになります。
ガントチャートですべて完了したのを見たことがない
あらゆる困難を乗り越えて、すべてのタスクが100%完了して、プロジェクト全体が完了した～なんてものを見たことがありません。
たいていプロジェクトの終盤はドタバタしていて、なぜかガントチャートとは別の（！）「課題管理表」といったものが作られてタスク管理されていくことがあります。
それも最終的には見捨てられて、何となく「リリースできていったん完了！明日からはメンテナンス！」と、当初のプロジェクト完了＝続きの始まり、といった感じになることが多いです。
それでも合意形成に必要ならWBSとガントチャートを作る
どうせこうなるのだから最初から作らないほうがラクなのですが、大規模になればなるほど人はWBSとガントチャートを欲しがります。
そうなったら私は「合意形成のための資料」と割り切って作ることが多いです。これ以外に納得させられるものがないからです。
とは言えアプリ開発の現場では「スクラム」という手法が浸透してきて、昔に比べるとだいぶ減ってきました。良い時代になってきました。
さいごに
「ユタカジン」では多様なバックグラウンドや考え方を持っているタスクシュート認定トレーナーのみなさんがそれぞれの「自分らしい時間的豊かさ」を追求していく記事が日々投稿されています。
みなさんにもピンとくるものがあると思うので、マガジンをフォローしていただけると嬉しいです。