なぜレビューが嫌がられるのか

あまりレビューを好き好んで受けたり行ったりする人はいないと思いますが、 なぜレビューが嫌がられるのか、どうすれば多少マシになりそうか、ということを考察しました。

以下の記事の続きです。 yuichi-ikeda.hatenablog.com

レビューイがレビューを避けたくなる心理

進みが遅い

全体の2割の作業が8割の時間を消費する、という8:2の法則(パレートの法則)があります。 レビューフェーズはこの残り2割の作業に当たるので、 レビューまでの一人で成果物を作成していたフェーズに比べて、 大幅に作業のスピードが落ちる感覚が生まれます。 この感覚が 「もうほとんどできてるのに!」「早く終わらせて次のタスクに移りたい!」 という感情に繋がると考えられます。

ダメ出しされる

レビュアーのダメ出しで自分の仕事にケチを付けられてるように思うことがあるかもしれません。 時間をかけて頭をひねって生み出した成果をボロクソに言われたら誰だって傷つきます。 感情的に傷つきたくないからできることなら避けたい、後回しにしたい、という心理はあると思います。

レビューの指摘が欲しいものと違う

  • 大枠の方針をレビューして欲しいのに誤字脱字の指摘が来る
  • 逆に顧客送付する前のダブルチェックをお願いしているのにそもそも的なちゃぶ台返しをされる

あるあるですよね。

レビュアーがレビューを避けたくなる心理

自分の成果に繋がらない

自分がレビューに加わった結果、成果物が良いものになったとしても、 自分の成果によるとはアピールしにくいし周りにも認識してもらえないと思います。 同じ時間を使うなら自分が主体している活動の方に割きたくなります。

面倒臭い、退屈な作業

間違いがないか、抜けがないか、わかりやすいか、 など評価する視点で成果物を読む作業は面倒で退屈と感じる人が多いと思います。 特に同じような指摘を何度も繰り返していると感じると辛くなります。

問題点のまとめ

レビューイ、レビュアーそれぞれの視点での心理分析から問題点をまとめます。

  • レビューの目的を理解していない・認識が一致していない
  • レビュー対象の現時点での品質について認識が一致していない
  • レビューに必要な時間を見積もっていない・計画に入れていない

問題が見えてくれば解決策は自ずと明らかになります。

レビュイーの心がけ

  • レビュアーに感謝する
  • 見てもらいたいポイント、期限、優先度などをなるべく明確にする
  • 可能ならタスク作成までやってあげる
  • 的外れな指摘が来たらそれは自分のコミュニケーションの問題であると自覚する
  • レビューが終わった時のアクションを忘れない(主体的に動くべきなのはレビューイである)
  • レビューフェーズをスケジュールの見積に加える

レビュアーの心がけ

  • 早くボールを返す
  • 表現をやわらかくする
  • あくまで補佐的役割なのであまり細かい所にこだわり過ぎない
  • レビュー等自分が主体で動く活動以外の時間をあらかじめ用意しておく

なぜレビューするのか

レビューとは

レビューは頭脳労働においては必ず発生するもので、 成果物(ドキュメントやソースコード)に対して作成者以外が意見を述べ、 成果物を修正・改善していくプロセスのことです。 レビューの対象となる成果物を作成した人をレビューイと呼び、 成果物に対して意見を述べる人をレビュアーと呼びます。

なぜレビューするのか

レビューの目的は、

  • 成果物の方向性を合わせること
  • 成果物の品質を上げること
  • 成果物を通してチームメンバーの認識・理解を合わせること

などがあります。

レビューの必要性は成果物の重要性や用途によって変わりますが、 レビューをしないことによって起こる主な問題としては

  • 品質の低い成果物を顧客に提供してしまう
  • 理解の間違った情報を外部に伝えてしまう
  • 成果物にコストを割いた後に、大きな軌道修正による手戻りが発生する

などがあります。

レビューのタイミング

レビューのタイミングは早すぎても遅すぎても問題はありますが、 一般論としては早めにやった方がいいと思います。

早すぎるレビューの問題

  • 完成度が低すぎてレビュアーの視点が本質的な問題に行かない
  • まだ決まっていないことをレビューしても二度手間になる

遅すぎるレビューの問題

  • 大きな手戻りが発生する可能性がある
  • 物事が進んでからこんなはずじゃなかったというような不毛な議論が発生する
  • 成果物の期限がある場合、レビュー結果を十分に反映する時間が取れない

レビューの難しさ、レビュアー/レビューイの心がけ

これについて本当は書こうと思ってたのですが、 前段の整理で長くなってきたので続きはそのうち。。

とにかくハードを増やしたくない

私が普段使ってるデバイスMacBookiPhoneだけです。 これはできる限り増やしたくないと思っています。

うちにはテレビもゲーム機もありません。 iPadはあって家族が動画を見るのに使われていますが、 自分一人だったら要らないと思います。 MacBookも外部モニタやキーボード、マウス等は一切なしです。

Android機もiPhone7がSuica対応したタイミングで処分しました。 Windowsは多少重くても面倒臭くてもVMでやりくりしています。

あと減らしたいハードは財布と家の鍵です。

ハードを増やさないと何がいいか。

  • 物を忘れる確率が減る
  • カバンが軽くなる
  • すぐ移動できる
  • すぐ仕事できる
  • 場所を取らない

ただ、特定の趣味やこだわりがある人は、 そうは言っても用途特化したハードが欲しいものだと思います。

  • ゲーム機
  • オーディオ
  • カメラ
  • 時計

特にゲームはソフトが欲しい時は困りますね。 面白そうなゲームが出ると時々ゲーム機を買おうか迷うんですが、 結局お金以上のデメリットが上回って買わないという結論になります。

タスクのリードタイムを最小化せよ

リードタイムとは?

リードタイムとは、発注から納品までにかかるトータルの時間のことを指します。 より具体的には「顧客からの要求を認識した日時」から「顧客に価値を提供した日時」までの所要時間のことです。 一般的なタスク管理の文脈としては、顧客は必ずしもいないので、 「タスクの依頼があった日時、または自分自身がタスクを認識した日時」から「タスクを完了した日時」 までの所要時間として、リードタイムという言葉を使います。

リードタイムが長いと何が起きるか

ビジネスとしてのリードタイムが長いということは、顧客に価値を提供するのに時間がかかるということですので、 以下のような問題が発生します。

  • 顧客がしびれを切らすことにより、信頼を損なう、場合によっては依頼がキャンセルされる
  • 時間が経つほど顧客の要求は変わり、当初の要求を満たすことの価値が下がる
  • 提供する価値の対価を受け取るまでの時間が伸び、資金面での問題となる

ではタスク管理としてのリードタイムが長いと何が起こるでしょうか?

  • 依頼者がしびれを切らすことにより、信頼を損なう、場合によっては依頼がキャンセルされる
  • 時間が経つほど依頼者の要求は変わり、当初の要求を満たすことの価値が下がる

ビジネスではないので最後の対価の受け取り問題ははっきりとは出てきませんが、大体同じ問題は起こります。 これは依頼者がいない自分自身のタスクの場合でも同じことです。

  • なかなか終わらないタスクを前に、自信が持てなくなる、場合によってはタスクを諦める
  • 時間が経つほど自分自身の要求は変わり、当初の要求を満たすことの価値が下がる

リードタイムを最小化することのメリット

逆にタスクのリードタイムを最小化することができれば、 実行力もつく、自信もつく、価値が生まれる、いいことずくめなわけです。

さらにリードタイムを最小化をしようとすると、ひとつひとつのタスクに集中せざるを得ないため、 生産性が上がり、同じ時間で消化できるタスク数を増やすことに繋がります。

リードタイムの最小化を妨げる要因

リードタイム最小化が良いということは、すんなり理解できる話だと思いますが、 ではそれを現実に適用できるかというと難しいところもあります。

リードタイム最小化を妨げる要因としては例えば以下のようなものがあります。

  • 集中力が続かない
  • 気分よって安易にタスクに着手し、着手中タスクが増え続ける
  • タスクが他人のアクション待ちのまま進まない
  • タスクをある程度進めたところで満足してしまう

このような問題はタスク管理のツールや方法論でなんとかしようという試みがあります。

以上、私が思うタスク管理上の最重要メトリクス「リードタイム」、 最重要原則「リードタイムを最小化せよ」についての紹介でした。

やった方がいいこととの向き合い方

当たり前ですが、仕事でもプライベートでもやった方がいいことはいくらでもあります。 やらなければいけないこととは違って、 やった方がいいことはタスク管理を続けていると日々溜まり続ける一方です。 やった方がいいことに圧倒されてタスク管理が嫌になってしまい、 タスク管理を放棄したくなることがあるかもしれません。 この問題についてまとめてみました。

やった方がいいこととは?

いつかやるタスクとも言いますが、以下のようなタスクです。

  • 期限は指定されてないしやる義務もないけど、他人から要望されたタスク
  • 日々の中でふと思いついた、いつかやりたいタスク
  • GTDではSomedayやMaybeに分類されるタスク
  • ソフトウェア開発プロジェクトの場合はバックログ(積み残しタスク)

やった方がいいことの管理コスト

GTDの場合はとにかく頭に上がったタスクはすべて書き出し、 定期的なレビュープロセスによってタスクを分類するということが推奨されています。 やった方がいいことは、来週やる、再来週やる、来月やる、と延ばし延ばしにされ、 結局やらないままタスク一覧に残り続けることになりがちです。

何度も何度もレビュープロセスを通過し、もしかしたら1年後にやらないという判定を下し、タスクを削除するかもしれません。 この場合、レビューの度にこのタスクに意識を向けたコストは無駄になっているということです。 レビューの時以外は一切タスクを見ない人ならまだましですが、 常時タスク一覧を眺める人にとってはコストは更に大きいものとなります。

なるべくタスク管理対象にしない

そこで、とにかく思いついたらタスクにするのではなく、 タスク管理対象にしたら今後ずっとタスク管理コストを払い続けるのだ、ということを意識するようにします。 どうせ多分やらないタスクは、タスク追加する誘惑を抑え、捨てます。 本当にやるべきタスクなのだとしたら今捨てたとしても、後でまた湧いて出てきます。

以上、私が最近意識している、 「やった方がいいタスクは吟味・厳選し、安易にタスク管理対象にしない」 という向き合い方でした。