手戻りといえば、一度転職してから元の会社に戻ること…いや、それは違う。これは「出戻り」だ。
よく手戻りと出戻りを混同している人がいるが、毎回気になるところではある。
まあそれは置いておいて。
手戻りというのは、いろんな工程を踏んでやったのに、またやり直しになることを指す。
手戻りとは、作業工程の途中で問題が発生し、 前の段階に戻ってやり直すことを指します。
https://aippearnet.com/column/glossary/temodori/
手戻りという捉え方の問題
しかし、これって結構難しい概念だと思う。
手戻りという言葉を使ってしまうと、全部却下されてやり直しになるような印象、プロセスの逆流のようなイメージを受ける。
でも、そうやって捉えてしまわない方がいい場面も結構あるんじゃないかと思う。
例えば
- ドラフトやアイデアを作る
- レビューする
- 実装する
- テストとかレビューとかする
- 「じゃあこれでやっていきましょう」とリリースする
その途中、リリースのプロセスだったり、実装し始めてからのプロセスで何かフィードバックをもらって、そのポイントの調整・やり直しが必要になる。これを「手戻り」として受け取ってしまうとする。
フィードバックサイクルとの区別
でも、よくよく考えると、実はこれってフィードバックサイクルの一環なんじゃないだろうか。
これを仮に手戻りと呼んでしまうのであれば、イテレーション開発とかアジャイルとかスクラムとか呼ばれるものは、全て「手戻り開発」であると言えてしまう。 実はこの手戻りをただ素早くやっているだけなのである（我々は、手戻り開発をやっていたのだ！）
だから、手戻りという言葉はあまり使わない方がいいんじゃないかと最近思う。
どうしてかそう思うかというと、そこまで重くないことのやり直しで手戻りと感じるというのは、多分、各プロセスを重く置きすぎだからなのかもしれない。それはウォーターフォールがやってきたことだ。
フィードバックサイクルと真の手戻り
僕は最近、本当に全く同じ作業をやり直すという、まさに「手戻り」というのを経験した。
おそらくこの、「問題が見つかって、本当に全く同じ作業をもう一回ゼロからやる」ということこそが手戻りなんだと思う。
だから、それと、フィードバックループやPDCAサイクルというのは混同しない方がいい、ごちゃ混ぜにしない方がいいと思う。
フィードバックを引き出すプロセスづくりが大事
いや、もちろん上長だったりリーダーだったり、ビジネスメンバーだったり申し訳なさみたいなのあると思う。
「こう出来ないですか？」と言うのはやり直しや調整のお願いではあるので。
でも、この「申し訳なさ」を感じさせてしまっていると、いいフィードバックなんかもらえないじゃないですか。言ってくれなくなるのでね
一度立ち止まって考えてみてもいいかもしれない
結局、手戻りというのは、起こったフィードバックだったり、この変化の適用というのをネガティブに捉えてしまう言葉かもしれない。それは勿体ない。
「手戻りなんてないさ」と言いつつ、本当の手戻りというのは真の意味で存在する。でも、ほとんどの場合は手戻りと捉えてしまっているだけで、本当はただのフィードバックサイクルなのかもしれない。
プロセスの逆流がなるべく発生しないようにするのは、進め方として気をつけたほうが良いですけどね。
まとめ
ということで簡単にまとめます。
- 手戻りというのは、行った作業を全く同じようにもう一回やり直すということ、その工程が繰り返されること
- 一方で、手戻りとして捉えてしまうけども、実はそれはフィードバックサイクルの一環と考えた方が良いものもあるかもしれない
- 手戻りという言葉をそろそろ再定義しても良いかもしれない
- そのフィードバックサイクルがうまく循環せずに、単なる工程の繰り返しになってしまっているということは、プロセスの進め方自体に問題があるのかもしれない
- 「手戻り」という風に受け取ってしまうと、純粋なフィードバックをビジネス側・顧客側から得ることができなくなるので、建設的ではなくなってしまうかもしれない
- フィードバックサイクルをうまく回す。そしてフィードバックをうまく受け取る。そして業務プロセスを繰り返さないように済むような形で、インクリメンタルに開発するとか取り組んでいくというのが一番いいんじゃないだろうか
変化を受け入れたいし、変化を受け入れやすいプロセスや協力関係を上手くつくりたいと常々思いますね（自戒）
