イテレーション的プロジェクト運用
タスク管理におけるプロジェクトは、いわゆるブレイクダウンによって生じる。つまり、何かしら為すべきことがあり、しかしそれは単一の行動(アクション)では達成できないので、為すべきことを為すための行動を具体化しましょうというわけだ。
たとえば、目指すべき状態がAだとして、それをブレイクダウンすると以下のようになるとする。
A
task 1
task 2
task 3
定義から言って、task 1~ 3までを遂行すれば、Aが為されることになる(そのようなものとして、それぞれのtaskを設定したのだからそうなる)。
無論、ブレイクダウンは無謬ではない人間が行うのだから、もれやらぬけやらは起きるので、ブレイクダウン後に新しいタスクが見出されることはあるが、逆に言えば、完璧な存在がもしAをブレイクダウンを行ったとしたら、そこに並ぶタスクをすべて実行すれば、Aは達成されることになる。
このようなプロジェクト(と呼ばないほうが混乱が少なくなるかもしれないが)運用を、「単純なプロジェクト運用」と呼ぶことにする。
問題は、この世のすべてが「単純なプロジェクト運用」で賄えるわけではない、ということだ。たとえば、「企画書を提出する」が為すべきことだとして、
企画書を提出する
過去の資料を確認する
新しいアイデアを出す
アイデアに基づいて企画書の草案を書く
草案を清書してメールを送信する
というブレイクダウンが行われたとして、「新しいアイデアを出す」が厄介なのである。これをタスクにして、10時25分くらいに着手し始めたとして、それが達成できるかはわからない。
そもそも、これ自身がタスク性のある記述になっていないのが一番の問題であるとするならば、「アイデア出しを10分行う」という実際に取れる具体的な行動に置き換えることもできる。しかし、そうしたところで、そのような行動を取ったからといって、アイデアが出るとは限らない。このように、具体的な行動に置き換えてすら、達成が確約されない「為すべきこと」がある。
もちろん、「企画書を提出する」が為すべきことなので、「どんな陳腐なものであっても、それらしいことが書いてあったらいい」と基準を切り下げれば、この行為は達成できるだろう。しかし、達成を主目的にして、より大きな目的がロストされている点はどうしても看破できない。そういう「目的のすり替え」で何かを為した気になるのは、仕事において極めて危険な兆候である。
*なぜなら、仕事の評価は基本的に他者が行うからである。
では、そのような正当化による回避を行わない場合、私たちは「新しいアイデアを出す」をどのように達成するだろうか。それは、完全性ブレイクダウンの網羅的達成ではなく、ある種の繰り返しによるアプローチであろう。つまり、以下のようなアルゴリズムを仮想的に設定する。
「アイデア出しを10分行う」→アイデアは出た?
Yes
→「草案を書く」に移動する
No
→もう一度「アイデア出しを10分行う」を行う
この場合、ある状態に至るまで、何かしらの行為が繰り返されることになる。もちろん、「アイデア出しを10分行う」がずっと繰り返されるわけではなく、別の行為になる場合もあるが、それでも一般的に想像されるブレイクダウンされたタスクリストを上から順にこなしていけば達成となる、というのとは別のアプローチがここにあると言えるだろう。
そして、デスクワーカーであっても、知識労働者の仕事はこうしたアルゴリズム的なアプローチを必要とするものが多い。ある意味で、モダンな(現代的な)アプローチと言えるだろう。
玄武.icon『イテレーション的プロジェクト運用』を読む
「アイデア出し」だけを取り出すと、一見するとタスクのように見えますが、その内実は複雑そうです。
私の場合、大きいGTDと小さいGTDに分けて運用しています。
大きいGTDというのは
企画書を提出する
過去の資料を確認する
新しいアイデアを出す
アイデアに基づいて企画書の草案を書く
草案を清書してメールを送信する
小さいGTDというのがネクストアクション(次にとるべき行動)を選択して、望んでいる結果を得られなかったときにも「これはなにか?」を問いかける繰り返しのGTDをやります。
「アイデア出しを10分行う」を選択して、望んでいる結果を得られたのかどうか。そうして次にとるべき行動を考えます。
上記の小さいGTDは 原典にはありませんが、基本(原典)にこだわりすぎるより、GTDには応用で考えられることが多いです。
rashita.iconそういう運用が、わりと現実的だと思うのですが、あまり言及されていない気がします。それぞれの人が提示された方法を現実にうまく調和させているのでしょうが、そういう話があまり表に出てこないというか。
玄武.iconなるほど、GTDはいかなるものか、どういうものかというのは見かけますが、たしかにそういった話は少なそうです。
takahrt.icon 『イテレーション的プロジェクト運用』を読みました
倉下さんがお書きになったんですよね?
rashita.iconですです。
ブレイクダウンと、事例「企画書を提出する」があげられてますが、そこには記されていない期限や期日などの制約が実務には加わってくるのではないかと
記事では「基準を切り下げる」と書かれていましたが、期限から逆算して「多少陳腐にも思えるアイデアだが、今日のところはこれを採用して先に進もう」として、アイデア出しタスクの反復から抜け出す事はあると思いますが、記事では望まれていないのでしょうか
ぶっちゃけ、納期や退社時間などの制約の前では、繰り返しに費やす時間・回数を、現実的なところに収めることになると思います
これは思考実験だから、それを持ち出すのは違うのかも知れませんが
rashita.icon
「アイデア出しタスクの反復から抜け出す事」は、上で書いたアルゴリズムの発展だと言えると思います。逆に言うと、あのアルゴリズムは極めてシンプルな(モデル的な)例です。
「基準を切り下げる」というのは、「不出来でもよしとする」というのではなく、「良し悪しについては一切考慮せず、単に10分のアイデア出して出てきたものを、何であれ採用する」という非判断的(非アルゴリズム的)な極端なやり方を想定しています。
「本当はもう少しブラッシュアップしたいけど、時間がないし、これで良しとしておこう」と「なんでもいいから、思いついたことを出そう」には、私にはかなりの違いがあると思います。
そのような人が実際にいるという話ではなく、タスクをいわゆるブレイクダウンして、「アイデア出しを10分行う」というタスクを設定して、それを「単純なプロジェクト運用」と同じように処理しようとすると、上のような極端なやり方をせざるを得ないが、そういうことをしている人はいないよね、ということです。
つまり、一つの目標があり、その下にいくつかの行動がぶら下がっている場合でも、単純な遂行と、アルゴリズム的判断が入ってくる遂行があり、それらを区別した方が良いだろう、という話です。
アイデア出しなどの領域では、タスク管理の技術でフォローすることではなく、アイデアメーカーである作業者の基礎体力的な部分、教養であるとか情報収集・整理などを高めていくのが成功への方向なのかなと、極めて個人的に考えてます。
rashita.icon私もそう考えているので、上のように「単純なプロジェクト運用」だけですべてがうまくいくとは想定しないほうが良い、と改めて文章にしてみました。