チームや組織で、ある一定期間以上持続に、一つのミッションに向かって動いていく仕事。例えば、プロジェクトとかプロダクト作り、事業運営など。こうした高度なレベルの協働が求められる仕事は、あらゆる観点で難易度が高い。

　まずもって、漫然と取り組んでも上手くいかない。ゆえに、「どのように進めるか？」という算段を立て、なおかつ共通理解にすることが前提になる。ところが、この算段・企て・目論見といった観点が弱い、場合によっては無いこともままある。この傾向は組織観点でも現場観点でも、この10年で強まっているのではないかというのが、私の所感だ。

　まず仕事の取り組みを、「作戦（算段、企て、目論見..）」と「運用」で切り分けて捉える必要がある。作戦と運用は異なる。後者は、日々の営みそのものにあたる。本来は作戦に基づいて実行される。そうでなければ、集団で行う仕事は相互の連動を失い、いきあたりばったりに終始することになる。それは都合よく試行錯誤とは呼ばない。

　前もって強調しておきたのは、この「作戦」というのは仮説であるということだ。その時点の情報と知識でもって捉えうる、最善とおぼしき策。それは、どれだけ言葉を尽くしたところで仮説であり、「運用」結果によって正されていく。「作戦」だけでも、「運用」だけでも、成り立たない。両者が揃ってこそ、意味をなす。

　ところで、この「作戦」を立てるにはどうしたらいいのだろう？　勘と経験、合議（つまり参加者の勘と経験）あたりがごく普通に取られるだろう。私達の仕事と取り巻く環境はますますもって高度になっているが、算段・企て・目論見といった観点では、時が止まっているかのようだ。

　データはどうだろう？　データは仮説の立案や意思決定のために利用する。ここで言う「作戦」とは、何をどう進めていくか、つまりどこでデータを活用して仮説を立てるか、あるいは意思決定するのか、その組み立てにあたる。組み立て自体はまだ自分たちで行わなければならない。

　作戦を立てる上でのリファレンス（参考するもの、基準、規範など）として「型」があるのが望ましい。「型」は知識の結集だ。繰り返し、繰り返し営まれる「運営」の結果から鍛え上げられた、学習の産物と言える。「型」が用意されているか、練られているかは、組織やチームの強さの一面を表すことになる。
　もちろん型にはめる、型どおりがネガに使われるように、型の適用は丁寧に行う必要がある。鮮度も継続的に保たなければならない。

　「型」「作戦」「運用」、これを具体例で捉えてみよう。

　伝統的なソフトウェア開発の場合、型は各社長年鍛えられてきた標準規程類がまず挙げられる。個別の作戦に落とし込む際の表現手段として、大日程、中日程などを用いる。日々の運用はタスク管理で。
　この組み合わせを頭からネガに捉える必要はない。取り組むことに型のフィット感が高く、堅実にすすめていくことで成果にたどり着けるならばそのとおりにするのが何よりだ。あくまで型や固めのマネジメントが機能するならば、ね。

　スクラムを適用するとはどういうことだろう。型はスクラムガイドで言語化されたスクラム・フレームワークになる。運用は、スクラムの営みそのもので、1週間か2週間などチームで決めたスプリントを活動単位とし、具体的なスクラムイベントなどがあたる。
　おや作戦は？　そう、作戦については個々で考える必要がある。インセプションデッキで補完するチームもあれば、作戦のみ伝統から道具を拝借して、スケジュールを引いてしまう組織もあるだろう。運用をうっかり台無しにしないよう注意しよう。

　観点を変えて、プロダクトマネジメントではどうだろう。プロダクトマネジメントの型は百花繚乱の状況だ。作戦の表現手段も曖昧で、ロードマップで描こうとする組織もあれば、やはりスケジュールが用いられている場合もある。まさか作戦がないってことはないだろうね。運用は伝統的なタスク管理かスクラムの営みといった具合だ。
　何が選択されるかは、プロダクト作りに挑む組織の歴史的なマネジメントスタイル、チームメンバーの経験に依るところが大きい。

　どの組み合わせがベストなのか、といった話ではない。取り組みとして、型、作戦、運用というディメンションを意識してみる。すると、チームや組織として何が必要かが見えてくる。
　型が全くないのは極端であるし、作戦がないまま進めていくと混乱、迷走する度合いが高まる。運用が足元の動きだ、かなめなのは言うまでもない。どれ一つ欠けても上手くない。何が不足しているか、みんなで考えるようにしてみよう。