購読している「えのさんのeの素」というメルマガより。

　●「直す」ではなく「やり直す」

事業の再構築を考えるときには、一度頭の中で会社を解散し、全て白紙にしてみよう。そこから新会社を設立し、解散した会社から儲かる顧客と儲かる商品だけを持ってくる。その取引に必要なだけの仕入れ先を選別し、設備を戻し、人材を再雇用する。そうすると、最も利益の出る布陣と、それ以外の設備・人材・取引先とに分けることができる。ベストな布陣が明確になったら、余った設備や人材の活用方法を探し、布陣に加えていく。

この手順で考えていくと、儲かっていない部分だけを直そうとしていた時には思いつかなかった新しい仕事や人事が生まれることが多い。

私はこの「出直しの法則」を企業再建の際によく用いるが、本来は好調な時に考えるとより大きな効果を生む。事業の再構築は、危機に陥ってからではなく、定期的に行うものである。

例えば、電化製品が壊れたからといってすぐに

　「じゃぁ、買い換えるか」

といった性急で腰の軽い判断はせず、

　「ちょっといじったら直るのではないか？」

という、どちらかといえば楽観的でどっしりと構えた態度を、私たちはとるものです。

この背景には、「やり直す」よりも「直す」方が手間と時間が少なくて済むことが多い、という経験則が息づいていると考えられます。それゆえ、ゼロから見直すことの手間を過大評価してしまいがちなのではないか、と思うのです。

もちろん、明らかに「やり直す」コストが過大であるという場合もあるでしょうから、常に「ゼロから見直す」のが正解とはいえませんが、持つべき指針として、現状を変えずに短い時間と少ない手間で何とかしようとしている自分に気づいたら、改めて時間をとって、ゼロベースで組み立て直すという選択肢についても検討してみる、ということが挙げられます。

つまり、自分で「正しい」と考えてやろうとしていることであったとしても、それが「正しさ」を盾にして、その場しのぎ的な対応で済ませようとする態度──多くの場合、後でより大きな問題として再燃することになる──に自ら警鐘を鳴らし、踏みとどまる、もっといえば、別の角度からの検討結果も加味したうえで、改めて目の前の意志決定に向かうようにするわけです。

そういえば、私のとっておきのプログラミングスタイル（Life is beautiful）では、プログラミングを題材にしながら、「直す」と「やり直す」の違いについて、同様の考察がされていました。

変更した箇所が思った通りに動かない時も同じ。デバッグしてすぐに問題点が見つかるのであれば直せば良いが、なかなかデバッグしてもうまく動かないときは、思い切って変更を切り捨てて、最後にチェックインしたところにまで戻る。特にこれが必要なのが、新しい機能を追加した時に、今まで動いていたものが動かなくなってしまった場合。「なぜ動かなくなったか」を解析している時間と、ゼロからもう一度書き直す時間とどちらが大切なのかを考えると、ゼロから書き直した方が早い場合が多い。これは私の経験だが、動くはずのプログラムが思った通りに動かないときの一番の原因はつまらないケアレスミス。セミコロンの入れそこないだとか、x と y が逆になっていたりとかだ。そんなケアレスミスがなかなか見つからずに煮詰まってしまうことは良くある。そんなときは、躊躇せずに変更を全部捨て、最後にチェックインしたところまで戻って、ゼロから書き直す。