課題管理のお話第二弾(まだ続くのか?^^;。
イントロ
課題管理──というか、問題を解決していくのが苦手な人はけっこういると思うのですが、中には「人はできることしかできない」ということがわかっていないんじゃないかなと思える人をよく見かけます。
「一階にいる人が二階に物を届ける」
という課題があったとします。
この課題って一見簡単そうに見えますがその建物にエレベーターも階段もなかったとしたらどうでしょう?
人は空を飛べません。どうあがいたってその状況では二階に行くことなんてできるわけないのです。
なのに、お届け物を二階に投げて受け取ってもらおうとしたり、大声で二階にいる人を呼んで飛び降りてもらおうとしたりする人が現実にいます。
遠回りに見えるかもしれませんがこの課題を解決する一番の近道はたぶん「二階に向かう階段を作る」なのです。
困難な課題はやることを分割せよ
たとえば、Aということをしたいのにコンピュータのプログラムが変な動きをしてできないとします。
そもそもそのソフトウェアのバグなのかもしれません。そのプログラムを作った本人でない人が、いくらプログラムと睨めっこしても問題を解決できる可能性はとても低いです。
ですので、課題表に「このプログラムの変な動きを解消する」なんて書いた日にはその課題は永遠に残っていくことになります。
なぜなら、その課題は「自分にできないことを、さもできるように書いた課題」ですから。
では、どうやったら解決できるのか?
こういったやっかいな課題を抱えた時は問題を自分ができること(アクション)にバラしてそれぞれをミニ課題にし、その「アクションが完了」=「そのミニ課題の完了」という風に管理していくと良いです。
具体的にはこんな感じ。
ミニ課題1:作った人(=開発元)にメールで問い合わせる
このアクションは誰だってできますよね。メールを書いて送信ボタンをクリックすればミニ課題解決(完了)です。
課題の完了が容易になるだけじゃなくて、メールを送れば自分の手を離れるので他のことができるようになります。(但しフォローは必要ですけど)
ミニ課題2:メールの返信を元に原因を分析する⇒それでも答えがでなければ、分かりそうな人を招集して会議を設定する
これも難しくありません。
とりあえず、返信の内容を読んでわかれば良し、わからなければ会議開催通知を発信すればミニ課題2は完了です。
会議の結果がとうなるかというのはこのミニ課題とは別のお話と区別をつけることが大切です。
ミニ課題3:会議の結果、お金を投入すれば改造して解決できそうとなれば、スポンサーと相談する
これもできます。事情を整理してスポンサーと会話をすれば結論が出る課題です。
ミニ課題4:予算が下りなかったり投資してもやっぱり原因がわからなければ、迂回路を探す。納品を待っているお客様も巻き込む
そのソフトを諦めて別の方法で思っていることが実現できないか模索します。
完全に実現できなくてもかなり近いことができるのなら妥協点を探るのも1つの手です。
大事なのはお客様を含め関係者全員で情報を共有しちゃうことです。
ミニ課題4のコツは×月×日に検討結果を報告と具体的な日程を最初に決めちゃうことです。
そうすればミニ課題完了は難しくありません。×月×日が来れば自動的に完了します(もちろん、お客様が納得する妥協案をまとめないといけませんが)。
困難の分割 ーまとめー
重要なのは手が届きもしない課題を設定して停滞し続けないこと。
たいして進んでいないように見えても確実に一歩すすめるアクションにまで課題をミニ課題に分割することです。
アームストロング船長の名言ではありませんが、その一歩は小さな一歩でも、その一歩を次の一歩につないでいけばいつかは二階に間違いなくたどり着くことができます。
とまれ、こんな風に自分の手におえない課題は誰それにメールするとか、誰それと協議すると言った風に誰でもできるようなことに分割してアプローチするのが得策です。
一見遠回りをしているように見えてもそもそもの目的が「このプログラムの不具合をなんとかする」ではなくて「Aということをしたい」ということを忘れずにいれば必ずたどり着けます。
これを困難の分割と言うのですが、問題解決が苦手な人を見ているとやっぱり一階から二階を呆然と見上げている気がするんですよね。