私の永遠の敵「調査タスク」

◆「調査」がタスクをせき止める

私はタスク管理にExcelベースのマクロアプリで「TaskChute2」を利用しています。このツールの使い方としてユニークだと思うのが、「タスクを定型化する」という考え方です。そして、その定型化ができるまではひたすら「実行タスクを記録する」ことが推奨されています。

これは「二度あることは三度ある」的な発想で、一度行った行動をテンプレート化することになるので、タスクを記録して適切なレビューを実施すれば効率化が加速するというわけです。しかし、実際にこれを業務で実践しようとすると、なかなかうまくいかない部分もでてきます。

特に「調査しないと前に進めない」というタスクが多いと、タスクの管理と実行が鈍くなりやすい傾向があるように思います。たとえば何かを便利にする仕組みを開発しようとすると、その仕組みの機能要素が実際に実現可能なのかどうかを確認する必要があります。

【参考例1】Aの機能が実現できるかどうかを調べてみた
　(1)　Aの機能を実現させることは可能
　　(2)　ただし、Aの機能を使うためにはBとCの環境準備が必要

【参考例2】Aの機能が実現できた場合に必要となるタスクを事前検討した
　(3)　Aの機能が実現したときに事前に考慮しておくことのリストを作っておく
　　(4)　Aの機能を実現するための仕組みの中で選択肢が定義済みだった

この参考例だけでもタスク見積もりの難しさがいくつか見えてきます。


◆タスクが現れたり消滅したり

(1)先ほどの参考例のひとつめの壁は、Aの機能を実現させる方法のバリエーションを調べるコストです。特に前例があまりないような仕組みを作ろうとした場合、調査しようとしてもネタそのものの母数が著しく少ない可能性があります。ネタが著しく少ない場合、それを探し当てるだけでも予測時間を越えてしまうでしょう。

この「実際に調べてみるまで分からない」という不確定要素がタスクの根本にある場合、全体のスケジュールを大きく揺るがすことになります。

(2)運良くいくつかのネタが見つかった場合でも、そこから細かく派生する調査タスクが生まれることがあります。先ほどの場合では、Aの機能を実現させるためにBとCという前提条件を調査する必要が発生しています。場合によってはこれ以上出ることもありますし、Aの選択肢が複数ある場合はさらに広がる可能性があります。

こういう「開けてみたらすごいことになっていた」というケースもよく遭遇します。この派生タスクには費用調査もセットでつくことがあります。

(3)実際にどのような仕組みを使ってAの機能を実現するか分かっていない状態の中でも、それなりに思いつける内容はあって、プランニングの時点でできるだけ「リストアップ」なり「洗い出し」なりをしたくなるわけですが、経験が少ない領域であればあるほどフリーハンドで絵を描くが如くリストがふくれあがることもあります。

たいていの場合、要件定義を細かくすればするほど、現実と理想がかけ離れていた時の時間的コストがふくれあがってきます。

(4)そして残念なことに「具体的な選択肢」を見つけた時点で、せっかく(3)でいろいろ考えたリストアップが無駄になってしまうこともあります。基本的にプランニング時点で道筋をクリアにできることが好ましいのですが、こういうことはよく発生しがちだと思います。

もちろん最初から(4)の事実が分かっていれば無駄なリストアップのタスクは不要だったわけですが、まぁ、覆水は盆に返ってきません。

私は基本的に「プランニングでなんとかしたい派」なのですが、こういうことがあると「実際に走ってみないと何も始まらないよね派」に同意せざるを得なくなってしまいます。

しかし、ここで愚痴を言っていても仕方がありません。私なりにこの問題の解決方法を考えてみました。もちろん他にもいいノウハウがあるかもしれませんが、まずは私が考えた方法をまとめておきたいと思います。実はまだ検証していないアイデアもあるので「机上の空論」なのですが、私は記憶力に不安があります。

霞のように消えてしまう前にここに書き残しておこうと思います。実際に試してみてどうだったこうだった……というノウハウをお持ちの方、コメントをお待ちしております。


◆小刻みな記録と確認

「Taskchute2」でタスク管理を行う場合、本質的に「はじめての案件」は「タスク記録」が大前提になります。私はこういう場合、記録するタスク名として「Aの機能の調査(120分)」と大雑把に書いてしまいがちです。そして最悪なことに、他の割込みタスクに身体と頭を持って行かれた後に、しれっと「Aの機能の調査(120分)」というタスク名を追加してしまうことがあります。

でもこの方法だと後からレビューしたときに何の役にも立たないことに愕然とします。結果として「Aの調査のタスクには480分かかったんだなあ」という事実を知ることはできますが、一体、どういう経緯でそのようになってしまったのか……というトラッキング(追跡調査)ができないのです。

そして新しい調査案件が発生するたびに、同じように不幸な「使途不明タスク」や「見積もり不能タスク」が生まれてしまいます。大雑把なタスク記録は「ああ、調査って大変なんだな」とか「ああ、調査タスクって見積もりできないんだな」という悲しい後ろ向きの経験知に直面します。

そこで試してみたいのが、「細分化記録」です。これ、「Taskchute2」の紹介記事などでスマートに「プランニングして、あとはタスクを淡々と実行！」とか「『思考』と『実行』を分けるとこんなに快適！」というハッピーストーリーを知っていると、すんごくストレスがかかります。

具体的には「Aの機能の調査」というタスク名を複製していって、タスク名に情報追加をしていくんです。「Aの機能の調査→前提環境(30分)」とか「Aの機能の調査→プラグイン調査→費用(15分)」とか。ただ、海外の技術の場合、たまに「どこの国だよ？」というサイトに行き着いて途方に暮れることもあります。

ただ、きっちりと記録することができれば、自分の調査の「パターン」というか「クセ」が分かるかもしれません。全体的に「どーでもいい領域の調査」に時間をかけているかもしれません。なので記録をしっかり残して、かつ、きっちりと「レビュー」という名の反省会をやっておけば、パターン解析によって調査行動の無駄が減るかも知れません。


◆小さめのマイルストーン設定

先ほどの方法、実は本当にやろうと試みたことはあるのですが、納期が迫っていたり他のタスクとの兼ね合いで、結局「仕方ない、どんぶり勘定でタスク名を付けておくか」となってしまい、最後までできた試しがありません。ひとつ疑問が湧くたびに調査タスクを追加することは想像以上にストレスフルです。タスク管理ができていない自分に対するストレスなんでしょうけれど。

特に派生した調査アイテムリストが10項目を越えてしまうと、一気にモチベーションが下がります。たいてい、そういう時はリストを全部出し切ったわけではなく、リストが増加傾向の過程にあることも珍しくありません。そこで二つ目の方法です。あんまりスッキリしないといえばそうなのですが、こちらはやや現実的です。

それは、タスクの目標を「小さなマイルストーン」に区切っていくというやり方です。たいていのタスクには「相談する」というフェーズがあります。企業組織で働いている場合は上司がいますし、独立起業している場合は仕事のパートナーがいます。それが場合によってはお客様であることもあります。

「ここで○○を調査しようとすると、スケジュールがこれくらい押しそうです」という相談ができるのなら、そういう小さいマイルストーンごとに確認していくのがいいのかも知れません。もちろん、ここにも落とし穴があって、「いつまでたってもズルズルと先に進めない」とか「調査の深みにはまっていく」とか、挙げ句の果てには「見当違い」だったりするリスクもあります。

また、「あんたらはプロなんだから、わたしらに相談するんじゃなくて、自分で解決してください！」と言われることもあるでしょう。このあたり、どちらの選択肢にもツライ局面があるといえばあります。上司の場合でもそうですね。「ったく、なんだよ、いちいちいちいち、そんなこと自分で考えろよな……」という表情に遭遇するかもしれません。

ま、でも、ひとりでいろんな判断を抱え込みすぎて、スケジュール的に致命的で取り返しのつかない事態に直面するよりは、小刻みにアラートを出していく方がプロジェクトの安定性は上がると思います。自分の評価が下がりそうだという不安はあるかもしれませんが、まあ、そこは実際に甘受するしかないのかもしれません。自分の未熟を恥じるしかありません。


◆「やるか」「やらないか」を時間で切る

自分自身の裁量でプロジェクトを進行させている場合、最初に「閾値(しきいち：物事を判断するための指標)」を決めておくというのも重要なポイントかもしれません。たとえば「○○の実現方法をリストアップする1(30分)」、「○○の実現方法をリストアップする2(30分)」、「○○の実現方法をリストアップする3(30分)」というタスクを先に「Taskchute2」に放り込んでおいて、その決めておいたスロット以上は使わないと決めておくんです。

最良の場合、90分以内に3つの具体案が3つのスロットに収まっているはずです。この場合、ひとつのスロットにかけていい時間は30分だけです。30分を越えそうになった時には、「Taskchute2」のコメント欄に参照先URLを貼って「次いってみよう！」と、強制的に進んでしまうわけです。実際にやってみるとおそらくスッキリしないに決まっているのだけど、利用できる時間が決まっている場合、こうするしかないのかなと思います。

今回の参考例の場合、「Aの機能を実現するために……」しか書いていませんが、実際に仕組みを作ろうとした場合、きっとそれ以外の要件定義が複数あるはずです。細かいところを「未解決」にしたまま進むのは気持ちが悪いし、そもそも達成感が満たされないかもしれませんが、すくなくとも「それぞれの要件定義」にかかる「調査コスト」がざっくりと分かるはずです。そして、まずは「調査コストが分かる」ということが正しいのかも知れません。

すると、「調査コスト」と「機能の重要性」のバランスを踏まえた上で「本当にこの機能は時間とリスクをかけてまで必要なものなのだろうか？」という本質的な判断ができるかも知れません。たまに見かけるのは「見かけ上だけのどうでもいい機能」が「もうちょっとでできそうだから」という理由で「作業時間がズルズルと伸びていく」という現象です。これはどうにも悲劇ですが、開発現場で冷静さを失うと陥りがちなトラップです。開発の最前線にいないマネージャの立場はとても大切です。

ちなみに、全部の「調査コスト」がまんべんなく高コストだとしたならば、そもそもその仕組みを開発するスキルや技術が「致命的にない」ということかもしれません。そういう場合は悔しいことですが、勇気を持ってその企画から撤退する選択を迫られるかもしれません。予算が潤沢にあれば足踏みをしていてもかまわないのですが、そうでない場合、じりじりとクライシスに向かって行進している可能性が高いからです。


◆「結局何もやっていない」というリスクも

時間で実行判断をするというのは一見したところ効率的です。しかし、この方法にもリスクがあって「早めの損切りができる」代わりに「結果的にすぐにあきらめて何もやれていない」という結果に陥るリスクもあります。しかし、「リミットとする時間設定」が適切であればそこそこ正しい結果を導けそうな気がしています。ただ、この「リミットとする時間設定」を長くしすぎてしまうと、ダラダラしてしまうリスクもあって難しいところです。

さて、あらためて今回の【参考例】の最適解を妄想してみると、

「Aの機能を実現する方法をリストアップする1(30)」
「Aの機能を実現する方法をリストアップする2(30)」
「Aの機能を実現する方法をリストアップする3(30)」
「Aの機能を実現性と重要性について検討する(30)」
「Aの機能を使うための基礎研究(30)」

というタスクスロットを作る方法がいいのかも知れません。でも、これまた所詮「机上の空論」なので、実際には「Aの機能を使うための基礎研究」タスクがうだうだと増殖してしまう可能性もあります。このあたり、腕のいいプロジェクトマネージャが「リスクのある未知の技術」に挑む場合はどのようにプランニング保全をしているのでしょうか？……とても気になります。

まぁ、もっとも、「未知の技術」という時点で「開発」というよりも「研究」というカテゴリで考えるべきなのかも知れません。「iPS細胞」を使った新しい治療方法も「○○までに実現させます」ではなく「○○までに実用化を目指す」的な感じですから。

ちなみに、今回の【参考例】を「仕組み開発」にしちゃったので、たとえが適切ではなかったような気がしますが、私が書きたいことはあくまでも一般的なタスク管理のことです。

「技術力が低いヤツが自分のスキルを越えたことをやろうとしていること自体が間違っている」とかというお話をいただいても、ちょっとアレなんですが、私のタスク管理に対する葛藤とそれに対する解決策がちょっとでも伝わって、しかもそれが誰かにとって有益な情報になってくれたら嬉しいです。