最近、デスマの話を聞いても驚かなくなった。仕事は選べなくなったとよく聞く。
その会話の中でよく耳にするのは、「無茶振りプロジェクト」や「無茶振りタスク」の話題だ。
こんなシーンが想像できる。
とある顧客：この不具合さー、明日まで対応できる？
とあるエンジニア：え、明日ですか、、、（明日といっても後数時間じゃん）
とある顧客：明日までに対応しますって、お客さんと約束したので、対応してもらわないと困ります。
とあるエンジニア：（困るっていわれても、、、）あ、分かりました。対応します（無茶振りだなー。できるかなー）
その後、必死になって不具合原因を調査する。コードが超スパゲッティで原因調査に時間が掛かりそうだということがわかった。でも、今更断れないということで、徹夜して頑張ることに。。
そして翌日。
とある顧客：昨日の不具合の改修完了しました？
とあるエンジニア：いやー、ちょっと終わっていません。。いろいろ難しくて。。
とある顧客：ありえないでしょう。やるっていったでしょう。。
まぁ、無茶振りなのは分かるｗ
だが、これは”とあるエンジニア”に問題がある（と考えたほうが価値的だ）。その理由は当然 受発注で顧客スタンスを尊重すべきだという話もあるが、相手をいくら批判しても相手に変わってもらわないといけない。つまり自分のコントロール下でない外部要因となる。それなら、まず自分のコントロール下である自分の行動を最適化したほうがいい。
まず考えられるのは、最初に無条件にタスクを安請け合いしている点。
次は、作業開始後に、作業が完了できないリスクが発生しているのに、顧客に警告を出さずに納期当日を迎えている点だ。
タスクを実現するためのIF文を考える
最初にタスクが無茶振りで問題だと思いながらも、顧客に何も伝えずにタスクを受けている。これは問題。
「このタスクは明日までに作業を完了させることはできません。」とはっきりいうことだ。
これだけだと、単なる あなたの感想でしかない。全くロジックになっていない。
「このタスクは明日までに作業を完了させることはできません。なぜならば○○○だからです。」とはっきりいう。
たとえば、このケースの場合は、「このタスクは納期どおりに作業することはできません。なぜならばソースを解析するためのリソースが2名足りないだからです。」などが考えられる。*1
このロジックポリシーを採用している場合の難点があるとしたら、「こいつはいつも否定的なことばかりいいやがって」という感情論に対するサポートができていないということだ。
そこに目を向けるなら、対偶命題を使おう。「AならばBである」に対する対偶命題は「BでないならAでない」だ。
「（もし）ソースを解析するためのリソースが2名追加してもらえば、明日までに作業を完了させることができます」という具合だ。
ここで間違ってほしくないのだが、この対偶命題で「いや、それでもできないよ」となる場合は、そもそもの最初の命題がおかしいと考えなければならない。納期通りに作業を完了できない根拠がまだほかにあるということだ。要は○○○の部分の根拠が考慮漏れで、MECEではなかったのだ。それで対偶命題を作っても論理破綻するのは当然だ。
いずれにしても、「ソースを解析するためのリソースが2名追加してもらえば」の部分は、タスクを完了させるための前提条件。プログラムでいうならば、IF文に相当する部分だ。この条件だけは、足りない場合はIF文を複数考えるか、AND条件を考えればよい。どんな無茶なタスクでも前提のIF文があるはずだ。IF文が成り立つなら絶対実行できるだろうし、成り立たないなら絶対に実行できない。どうしても無茶振りタスクを実行させたいなら、顧客にそのIF文をクリアするようにしてもらえばよいのだ。これは契約条件のようなものだ。
屏風の虎退治ができるようになろう
一休さんの屏風の虎退治という説話を思い出してほしい。「”屏風の虎”を退治せよ」という無茶振りタスクに対して、「”屏風の虎”を屏風から出してもらえば、虎を退治する」という命題で挑んだわけだ。*2これは、無茶振りタスクの証明には十分でわかりやすい。私の考えでは、無茶振りタスクには、それを実現するためのIF文を作って顧客に説明するのが一番納得感が得られてわかりやすいと思っている。そんなの屁理屈といってしまうのは簡単だろうだが、業務においては「わかりやすい」つまりシンプルにするということは何事にも代え難い。問題をシンプルにすることで仕事が早くなればよいのだ。無用に感情論に走るよりは何倍も価値的だ。目的と手段を履き違えてはならいと思う。
現場では、事前調査の時間が全くなく、タスクの実行を余儀なくされる場合も多い。その場合は次のリスクに対するスタンスが大事なる。
リスクの報告と契約変更を忘れない
２点目。まぁ、これは前のエントリでも書いたが「仮説思考」で考えて、リスクが発生したら早期に修正することだ。その際には顧客などの利害関係者にも報告しなければならない。報告については日々の作業の状況を伝えていたほうがいい。報告までのインターバルが長いと、現状を無視した会話になりがちだ。顧客にこちらの状況を理解してもらいたければ、できるだけ日々の作業状況を伝えることだ。アジャイルでもこのスタンスは重要視されているはずだ。まぁ、言うのは簡単だが、意外に難しい。日々流れているタスクが多いと、意識しておかないと、重大なリスクも自分勝手に判断して見逃してしまう可能性があるから注意が必要だ。
それと、リスクが発生した場合の対処だが、リスクが発生した事でタスクの前提条件が崩れたので、顧客などの利害関係者を含めて、タスクの見直しや再定義が必要になる。これを怠ると、認識の相違がでてトラブルの元となるので気をつけたい。つまるところ、タスクの依頼主と担当者の間には、”契約”が成立していると考えたほうがいい。法的にいっても口頭で約束しても契約は成り立つ。リスクが発生して契約が守れなくなったらすぐにアラートを上げて、契約の変更を申請しよう。
上記の例では、とある顧客と、とあるエンジニアとしたが、タスクの依頼主と担当者に置き換えて表すことができるので、社外だけではなく社内にも目を向けてみると成り立つところが多い。上記に書いたことは、顧客と向き合うPMやリーダだけでなく、プログラマが実践しても十分に効果を出すことができる。
このご時世、無茶振りタスクがいつ降ってくるかわからない、ぜひ心掛けたいところだ。
