DXの設計書⑫ – タスクと進捗を見える化せよ

①タスクを洗い出しました。
②工数を見積もりました。
③次はスケジュールです。

あーやだやだ。
①も②も不確実です。そこにのっかるスケジュール。
最早、絵に描いた餅以外の何物でもありません。
さて、今回は餅の絵を描くお話です。

絵に描いた餅とは、実際には何の役にも立たないことのたとえ。
また、実現する見込みがないことのたとえ。

故事ことわざ辞典 – 絵に描いた餅

冗談です。スケジュールは絶対に必要です。
その通りにならないというだけ、全く役に立たない訳ではないのです。
難しいですね。投げやりになってはいけません。

では、スケジュールについてです。


スケジュールが何故合わないのか?
実際、作業工数の見積もりは合ってると思います。
僕の個人的な意見ですが、トラブルが見積もれないのではないかと考えています。

ブラックスワンの考え方ですね。

第一に、異常であること。
つまり、過去に照らせば、そんなことが起こるかもしれないとはっきり示すものは何もなく、
普通に考えられる範囲の外側にあること。
第二に、とても大きな衝撃があること。
そして、第三に、異常であるにも関わらず、私たち人間は、生まれついての性質で、
それが起こってから適当な説明をでっち上げて筋道をつけたり、予測が可能だったことにしてしまったりすること。

「ブラックスワン – 不確実性とリスクの本質」より抜粋

前回の記事の好き放題言われる内容も第三に当てはめれば納得がいきます。

備えることはできても、起きなければゼロで起きれば大量工数の消費です。
そんなものばらつくに決まっています。
ブラックスワンを予見できるのであれば僕は株で大金持ちですね。はは。。。


さて、スケジュールには3つの役割があります。

まず第一の目的は、いつものごとが完了するかを表すという最も有名なものです。
・・・
スケジュールの第二の目的は、プロジェクトに貢献するすべてのメンバーに対して、
チーム全体における個人の成果物の位置づけを理解させ、各メンバーの協調を促進させるというものです。
・・・
スケジュールの第三の目的は、進捗を管理し、作業を管理可能な塊に分割するツールをチームに与えるというものです。

[アート・オブ・プロジェクトマネジメント]より引用

1つ目はお尻を決めるということですね。2つ目は各メンバーと同期をとる。3つ目は進捗を測定する役割です。

これがないとプロジェクトの体を成しません。
プロジェクトマネジメント初心者はプロジェクトがスケジュールから逸脱したらスケジュールを確認しなくなります。
プロジェクトは勝手に進み始めコントロール不能に。
ちゃんと、終わってくれ・・・と祈るしかなくなります。

スケジュールなんて目隠しして遠くの的を射抜くようなものです。
ハズレて当然。くらいの気構えでいきましょう。

とはいえ、スケジュール通りにいってないとわかると上司は説明を求めます。
で、説明してもこれです。

上司「大丈夫なのか?」→僕「無理です」→上司「何とかしろ」

退職願を書きました – プログラマーやめました

まぁ、中小企業だとこんなもんです。
スケジュールの遅れはそのまま利益の減少もしくは損失につながります。
なので、必死ですね。


僕はGitHubのIssueボードを見て、カンバンボードの便利さに気付きました。
Amazon Primeでシリコンバレー(Wikipedia)などのドラマを見ていてもちょくちょく出てきます。

英語ですが、わかりやすかったので貼っておきます。

ツールを使うのも良いですが、ホワイトボードと付箋が一番直観的ですね。
遅れてても進捗しているように見えれば上司も満足です。

説明の手間が省けて助かります。


ガントチャートは他の作業との紐づきなど上司への説明としては余計な情報が多いです。
後、横長・縦長になってしまって説明するときに難儀します。

意外と便利なカンバンボード。
英語でもKANBANというのが良いですね。
一度使ってみてはいかがでしょう。

タスクと進捗を見える化せよ

おわり

PR

コメント

“DXの設計書⑫ – タスクと進捗を見える化せよ” への2件のフィードバック

  1. のアバター
    匿名

    さっそくカンバンボード検討してみます

    いつもさ更新楽しみにしてます

    1. ¥552(税込)のアバター

      わざわざコメントありがとうございます。
      何もないところですがお役に立てれば幸いです。

¥552(税込) へ返信する コメントをキャンセル

メールアドレスが公開されることはありません。 が付いている欄は必須項目です