本格的リニューアル構想中のため、一部表示に不具合があります m(_ _)m

世界で一番シンプルな To-Do リスト(3)分割統治法を用いて最小管理タスクを定義する

プロジェクトマネジメント(基礎編) プロジェクトマネジメント(基礎)
この記事は約8分で読めます。

世界で一番シンプルなTo-Do リストの最小管理単位とは

世界で一番シンプルなTo-Do リストは、同時に優先順位を表す項番(No.)とタスク内容を表す件名の2つの要素だけで構成されるミニマリストにも受け入れやすいものです。そのシンプルさは、タスクの切り方にも取り入れられていて、最小管理単位は字句の通り、最小管理タスクの大きさになります。

コンピュータのプログラムは、あらかじめ、処理(プロセス)が定義されていて、その処理にインプットを与えると、事前に定義した処理コードに記述された計算式の通りに、アウトプットが吐き出されるように作られています。

この一連の「Input→Process→Output」の流れで完結する仕事の単位を、そのまま頭文字をとって、「IPO」と呼ぶことがあります。

ひとつのIPOから出たアウトプットが他のIPOへのインプットになって、バケツリレーのように次々とインプットとアウトプットが連鎖していき、最終的にはアウトプットを渡してあげるIPOがどこにもいなくなった時に、その処理は終わるようになっています。

このIPOを人間が行う仕事・タスクに当てはめて、一つのインプットが一つのアウトプットを吐き出す単位を管理すべきタスクの最小単位としてあげることで、貴方の作成する「To-Do リスト」は、変更耐性が強く、実行可能性も上がるようになります。

世界で一番シンプルなTo-Do リスト で最小管理タスクを定義する

このままだと、「AはAだからAなのだ」の以上でも以下でもない説明に陥りそうなので、具体例を示して説明します。

下記に、前回お示しした「To-Do リスト」を再掲します。

1田中さんに来週の会議のアジェンダをメールする(チーム)
2夕飯の材料である牛肉細切れ500gを買って帰る(P)
3【購買PJ】仕入先マスタのクレンジング機能の要件定義書のドラフト作成
3.5 来期の定例会議フォーマットの改善案を作成する<業務改善PJ> (12/18)
4【購買PJ】総合テスト計画書の草案提出を木下さんにリマインドする(12/20)
5 デスク周りの整理整頓をする

この中で、一つのインプット情報を使って、一つ以上のアウトプットが出てきそうなものはあるでしょうか? 

例えば、「2.夕飯の材料である牛肉細切れ500gを買って帰る(P) 」ですが、奥さんから、ピーマンと牛肉のオイスターソース炒めを作るから牛肉買ってきて、という言付けをもらったことが、このタスクの起動条件となり、その言付けがこの「2.」というタスク(処理、プロセス)のインプットとなります。

アウトプットは、言われた通り、 牛肉細切れ500g を買って帰るか、忘れたまま帰宅して奥さんに怒られるか、間違えて豚肉細切れ500gを買って帰るかの三択が考えられるかもしれません。

しかし、それは可能性として3つのケースが考えられるというだけで、「牛肉細切れ500gを用意する」という期待されるアウトプットに対するタスクは一つだけに限られます。残り2つはそのタスクを結果としてしくじるだけであって、3つの帰結するアウトプットが並列に存在するわけではありません。必ずどれか一つしか実現しないはずです。

ですから、望むべき唯一の結果をもたらすであろうタスク(ミッションと言い換えてもいいかもしれない)は、アウトプットと1対1の関係になるまで、仕事を細分化していき、期待されるアウトプットと必ずペアになる具体的なアクションがイメージされるまで、自分の仕事をブレークダウンしたものになります。

自分の仕事が、「インプット→プロセス→アウトプット」の3点セットが一つの具体的な仕事のイメージになるところまで想像する。そのひと固まりが「IPO」となり、管理すべき最小単位のタスクということになります。

最小管理タスクの絞り出し方 – 分割統治法を用いる

よくある勘違いを先に説明しておきます。下表をご覧ください。

No.タスクアウトプット
2牛肉細切れ500gを買って帰る①牛肉細切れ500gを買って帰る
②牛肉細切れ500gを買って帰らない(忘れた!)
③条件を満たしていない中途半端をした
 (1kg買ってしまった、牛ミンチを買ってしまった、豚肉を買って
  しまった、買いはしたが電車の中に置き忘れてしまった)
3 【購買PJ】仕入先マスタのクレンジング
機能の要件定義書のドラフト作成
①必要な機能をユーザからヒアリングする
②ヒアリング結果を精査する
③要件定義書としてアイデアをドキュメントとして記述する

前章で説明したことの実例が「2.」のアウトプット欄に書いてあります。①から③までの事象(さらに、③の中にはどういう風にしくじるかのバリエーションが無数に存在します)は、”OK”, “NG”, “微妙”という3つの結果をもたらします。しかし、行われるべきアクションは、「牛肉を買って帰る」という一つだけであり、その結果もたらされる帰結は1つだけです。

次に、「3.」の例を見てみましょう。多くの方は、むしろ、「2.」よりこの「3.」のケースのような実例でお困りになるほうが多いのではないかと推察します。

「要件定義書のドラフトを作成する」というアクションには、作業の手順があって、それが3つの実際に行われるアクションに細分化されることを上表では示してあります。

①ユーザヒアリング → ②ヒアリング内容の精査 → ③ドラフトを実際に文書化する

物的証拠は必ずないといけないとは言いませんが、ユーザヒアリングをすれば、「ヒアリング調書(議事録)」が作成され、ヒアリング内容の精査をすれば、「プロコン表(メリット-デメリット一覧表)」が作成され、ドラフトを実際に文書化すれば、「ドキュメント(要件定義書ドラフト版)」が作成されることになります。

つまり、これこそ、一つのアクションに対して複数のアウトプットが存在することになるので、一つ手前の「To-Do リスト」作成の手順に戻って、そもそも「 3.【購買PJ】仕入先マスタのクレンジング機能の要件定義書のドラフト作成 」というタスクの定義が大雑把すぎたと考え直すのです。

これを、「分割統治法( divide-and-conquer method )」と呼びます。そのままでは解決できない大きな問題を小さな問題に分割し、その全てを解決することで、最終的に最初の問題全体を解決する、という問題解決の手法のひとつです。

以下は、脱線した説明文です。承知している人は次の章まで読み飛ばしてください。

よく、「実際に必ずユーザヒアリングを文書化しなければ、タスクにできませんか?」と聞かれます。チームで共有するか自分の中だけで活用するかの違いはあるかもしれませんが、世界で一番シンプルな「To-Do リスト」は、件名を読んだだけで、その帰結やアウトプットがすぐに頭に浮かぶまで具体性が確保されていればそれで充分です。

具体性を持ってアウトプットがイメージできるレベルにまでタスクを細分化できていることが目指すべき状態で、すべてのアウトプットが文書化されていることが最終目的ではないのです。文書化や、ドキュメントというのは、目に見え、後まで証拠として残るので、その分だけ具体的なイメージを喚起しやすいと考えています。そのため、「できるだけドキュメント化したほうがいいですよ」と、ひとつのタスク定義の目安として、文書化をアドバイスしているだけです。

世界で一番シンプルなTo-Do リスト で作業手続きをどう表現するか

「3. クレンジング機能の要件定義書ドラフト作成」という疑似タスクを「IPO」が明確になるまで、丁寧にブレークダウンしたのが次の表になります。

1田中さんに来週の会議のアジェンダをメールする(チーム)
2夕飯の材料である牛肉細切れ500gを買って帰る(P)
3.1【購買PJ】仕入先マスタのクレンジング機能のためのユーザヒアリングの実施
3.2【購買PJ】仕入先マスタのクレンジング機能のためのユーザヒアリング結果の精査
3.3【購買PJ】仕入先マスタのクレンジング機能のための要件定義書のドラフト記述
3.5 来期の定例会議フォーマットの改善案を作成する<業務改善PJ> (12/18)
4【購買PJ】総合テスト計画書の草案提出を木下さんにリマインドする(12/20)
5 デスク周りの整理整頓をする

世界で一番シンプルな「To-Do リスト」の項番には優先順位の意味を含ませているので、作業手順的な順序は、この項番を上から順番に時系列で並べるだけで、大抵の場合は問題ないと思われます。

もっとこだわりを持っている方は、例えば、米を炊くという一連の動作を「To-Do リスト」に書き起こす際、

  1. 米を用意する
  2. 米研ぎ用の容器を準備する
  3. 米を研ぐ
  4. 炊飯器をセットする

というタスクまで分解した場合、「1. 米を用意する」「2. 米研ぎ用の容器を準備する」のどちらを上(先)に記載したらよいか迷われるかもしれません。そこまでこだわりがある場合は、もはや「To-Do リスト」の範疇を超えて、WBS(Work break-down structure)の作成が必要かと存じます。

WBSについては、下記の記事(三部作)を参考にしてみてください。

コメント