仕事自体を設計する。

　仕事がどうにも上手く進まない、終わらない。いつも想定より遅れていたり、結果も今ひとつで期待に応えられていなかったりする。そんなことを感じたことはあるだろうか。
　様々な理由があるだろうが、そうした状況には共通するある課題がある気がした。それは「仕事の設計図」が描けていないということだ。

　設計図と言っても、手の込んだややこしいことを言うつもりはない。要は、仕事の段取りをつけるということだ。何からはじめて、どこに着地させるのか。
　着地に至るまでにはいくつかの過程が存在する。仕事に取り掛かる前に、どういうルートを辿っていけば目的地に至るのか自分の中で見立てをする。その見立てを簡単に図にしてまとめる。A4一枚程度だ。
　むしろそれ以上にすると詳細すぎる。詳細に出来るほうが怪しいと思ったほうが良い。想像に想像を重ねすぎているのではないか、と。

　図の書き方とか、図で用いるオブジェクトとか、そういったところは本質ではない。凝っても構わないが、この話においてはそこが大事なのではない。左上から、右下に円を連ねていくだけで良い。仕事に取り組むあなたと、関係者が理解できるに足る内容であればそれで結構だ。

　仕事の設計が可視化されていると、他者からフィードバックを集めることができる。どのように段取りを踏んでいくのか。チームや関係者の経験を取り込めるタイミングを作ることができる。ともすると置いている目的地をそもそも捉え違いしていることもある。だから、どうするつもりなのかを可視化するのは極めて有効なのだ。

　この時描くルートは「仮説」も含む。目的地に至るまでの道筋が分かりやすく、明確になっていることは少ない。あくまでこのルートを辿ることで目的地に辿り着けそうだ、という感覚で見立てる。ゆえに、実際に取り組み進める中で、ルート変更を大いにかける。少し進めては設計図を書き換える。
　さながら、未開の地を探索するように少しずつ進める。正解ルートが誰にも分からない状況であったとしても、自分の中で見立てがあるかどうかは大きな差になる。見立てがなければあまりにも手ぶらで、やたらめったら前に進んでみるしかない。我々の仕事で、そこまでゼロベースなのも珍しい。仕事を始められる段階なのかを見直したほうがよい。

　仮説を手に、探索するように仕事を進める。多くの場合、ともに取り組むチームメンバや関係者がいる。そうした人たちに今からどういう見立てで進むのか、そのイメージを合わせておく必要がある。
　だから、あえて「作戦」と称して、今から取り組むこと内容を代表する言葉で言語化し、合わせる。「作戦」のイメージとは、もとより状況によって機敏に方針や内容を変えていくものだ。変更を許容しない固定的なプランではなく、むしろ変更可能性をその言葉から意図として伝える。

　こうした仕事の「設計図」はイニシエのソフトウェア開発では「工程表」と呼んでいた。今は現場で見かけることは少ないだろう。組織内で標準として定められた「規程」に基づき組み立てられる。
　標準があてはまる時代は、ルートも固定的だった。一つのルートで、だいたい収まりがつく。しかし、目的も手段も多様になった現代においては、ルートは固定できない。ルートは標準から開放され、自分たちで組み立てなければならなくなった。自分たちで仕事を組み立てる「自由」を得たということだ（この「自由」がなかった頃は実にツラミも深かった）。

　だからこそ、「仕事自体を設計する」というスキルが極めて重要になるのだが、そうした経験を磨く場面や機会はかえって減っているのかもしれない。意図的に「仕事を組み立てる」という局面が減り、悪くいうと、適当にはじめて、適当な結果に辿り着く。これをただ繰り返していても、仕事の結果は遠いままだ。