年末年始で自分とむきあう時間が取れて、休み明けは新たな気分で日常を迎えた。自分の戦略を立て直して日々に臨み直す。今まで力を入れていたところから、これからは変える。

　…と決意して、2週間ほどでも経ってみると、もうその誓いが遠い記憶であることに気づいた。気づけるならまだいい。その誓いのことを3ヶ月後、半年後に思い出すことだってあるだろう。この現象は何だろうか！考えてみると、仕事に必要な観点「詳細」と「俯瞰」にまつわる力学の存在に気がついた。

　詳細とは、仕事の最前線のことだ。そこでは具体的なタスクを行う。コードを書く、資料をつくる、ミーティングを運営する。一方俯瞰とは、仕事の全体像を眺める立ち位置のこと。詳細とは真逆で、一歩離れて観察し、分析する。

　そう捉えると、現場とは詳細が支配的な場所だ。何かを生み出したり、進めたり、解決するための場だから、詳細にむきあう時間が長くなる。現場は詳細を頂点としてプロセス、フォーメーション、意思決定を最適化していく。仕事のクオリティを出すためには現場では詳細に集中せねばならない。

　ゆえに、現場では「詳細の引力」が強く働くことになる。詳細を乗り切るために、結果を出すために徐々に、そしてますます時間と注意を投入していく。また、仕事は環境の影響を受けやすい。周囲が詳細のめり込みモードになっていくと、その方向へ引っ張られていく。全体が詳細へと移行する。これは悪いことではない。むしろ、強い現場だといえる。

　だからこそ現場では、詳細を見ようとしない、立ち入らない人が浮くわけだ。いわゆる、マネージャーとかコンサルタントとか呼ばれる役割だ。場合によって、蛇蝎のごとく嫌われる存在になる。

　だが、俯瞰する、俯瞰から抽象化して考えるという観点は、複雑で厄介な問題や仕事であればあるほど必要になる。詳細でひたすらこなし続けていれば、いつの間にかゴールにたどり着くというわけではない（だから、詳細から一旦離れて観る、ふりかえりに意義が出てくるわけだ）。

　詳細に偏るのも、俯瞰だけしているのも、いずれでも良い結果は出せない。必要なのは現場の一員でありながら、俯瞰し抽象化を適宜取り込みながら、詳細モードでは気づけ無い視点を引っ張り出せるような能力。これは、むちゃくちゃ値打ちがある。

　そして、これを同時に、一人の人間が担うのは相当難しいことでもある。「自分の意識の外側から自分の状態に気づく」ような仕組みが要る（こうした「気づくのマネジメント」は別の機会で言語化を試みたい）。

　もう一つ作戦がある。それは個人ではなくチームのフォーメーション(役割分担とその運用)で乗り越えようというものだ。

　そもそも、コンサルやマネージャー、コーチという存在は、俯瞰の立ち位置から芽生えた役割だ。この役割がチームから敬遠や疎外されてしまう場合は、その人達が俯瞰だけで詳細に立ち入らないケースだ。実際、詳細を全く見ずに下す判断が的外れになる場合が多い、という実害もある。それ以上に、いわゆる「チーム感が無い」というやつが両者に境界を生み出す。俯瞰からの言葉や働きかけがどれほど正しいことであっても、ただ投げかけるだけでは詳細モードにある現場には届かない。合理性だけで人は動かない。

　ちなみに、現場でコードを書いていて、経験年数を重ねたからということで、リーダーを任されるようになる、結果、レビューだけでコードをかけなくなり、モチベーションをガタ落ちさせるという話は、詳細を得意とする人が全体の最適化のために俯瞰の位置を託されるということだ。チームのフォーメーションやプロジェクトの達成のためには正しい判断だが、当事者の感情、思惑について読み違えているあたりが、まさに「俯瞰の的外れ」といえる。

　つまり、チームで詳細と俯瞰の取り扱うには現場の内と外という観点を抜くことができない。詳細と俯瞰という観点を、現場の内外という境界にあわせる必要があるのかは、むきなおってみた方が良い。この境界をなくすすべは、ミッションを一緒に背負うということだ。それは、例えばコンサルもチームと一緒にソフトウェアをつくる、ということではない。

　それぞれの役割の活動が統合できるように、それぞれが担っている詳細から一つ上でミッションをつくる。コードを書くのも、何かを分析するのも、プロジェクトやプロダクトのあるゴールを達成するためだ。そのことを言語化し、お互いのコミットの仕方を確認し合うことはできるはずだ。一つ上に視座を持っていってむきなおる、これも「越境」だ。