タスクには二種類ある。フロー型とビルド型だ。この二つは、仕事を前に進める力がどこから生まれるかで分けられる。
フロー型は、締め切りの圧力によって進む仕事である
フロー型は、締め切りや他者との約束によって、取り組む必要が生まれる仕事である。会議の日までに資料を用意する。公開日までにウェブページを仕上げる。月末までに必要な集計を済ませる。こうした仕事は、いつまでに何を済ませるかが、周囲の予定や後続の工程と結びついている。
締め切りが近づけば、残り時間は短くなり、相手から進み具合を聞かれることもある。後回しにすれば、誰かが待つことになったり、次の工程が遅れたりする。そのため、自分で毎回その仕事の重要さを思い出さなくても、取り組まざるを得ない状況が生まれる。フロー型がある意味で勝手に進むのは、この圧力が着手や再開を促すからだ。
実際の作業には判断も労力も要るが、何もしないまま放置しにくい。公開前の確認が遅れれば、修正に使える時間が減る。そこで公開までに直す箇所を絞り、担当者と相談して進める。締め切りが仕事を意識に戻し、間に合わせるための判断を促す。フロー型では、こうした圧力を受けながら、必要な仕事を期限までに完了させていく。
ビルド型は、自分の意志で積み重ねて進める仕事である
ビルド型は、今後の方向を左右する重要なイシューに、自分の意志で継続して取り組む仕事である。どの事業に力を注ぐか、組織にどんな専門性を持たせるか、製品のどの課題を解くべきか。答えによって、これから取り組む仕事や資源の配分が変わる。こうした戦略的な仕事は重要でも、今日手をつけなかったことによる支障がすぐに現れるとは限らない。
そのため、必要だと思っているだけでは進まない。目の前の依頼に応えているうちに、一週間前と同じ問いを抱えたままになることもある。自分で取り組む時間を取り、調べ、考え、確かめることを繰り返して、少しずつ判断できる状態に近づけていく。この積み重ねを始めるにも、途中で止まった検討を再開するにも、取り組む人の意志が必要になる。
ビルド型で積み重ねるのは、問いに答えるための知識や検証結果、判断である。事例を一つ調べて仮説を立て、別の事例で確かめ、合わない部分を修正する。一度で結論に至らなくても、前回分かったことを次の検討に使えれば、問いへの答えは具体的になっていく。コツコツ進めるとは、重要な問いを持ち続け、その答えに近づく仕事を重ねることだ。
重要なイシューから仕事を組み立てる
ビルド型の出発点は、答えによって今後の仕事が変わる問いである。たとえば、限られたデザイナーを複数の事業に配置するなら、「新しい事業の仮説を確かめる段階と、成果が出始めた事業を伸ばす段階のうち、どの段階にどんな専門性を振り向けるべきか」と問える。答えが変われば、優先して支援する事業、各チームが持つ役割、次の採用で求める専門性も変わりうる。答えが後の複数の判断に影響するから、時間をかけて取り組む価値がある。
「来期の体制を考える」という題だけでは、何を調べるかを選びにくい。「各事業に専任で置く役割と、複数事業で共有する役割をどう分けるか」まで絞ると、判断に必要な情報を選べる。継続して製品を改善するために、日頃から事業の事情を知っておく必要がある仕事は何か。短期間だけ専門性が必要になり、複数事業で同じ人が支援できる仕事は何か。こうして大きな問いを、現場の事例を使って答えられる問いに分ける。イシューの見極めで扱うのも、調べ始める前に何を解くべきかを定めることである。
一つの仮説として、製品を継続して改善する担当は各事業に置き、立ち上げ期に短く必要になる専門家は共通部門から出すと考える。過去の支援を振り返り、専門家が短期間だけ入って成果を出せた場面と、事情を把握するまでに時間がかかった場面を比べる。後者が多い仕事では、短期派遣を想定していた範囲を見直す。最初の仮説を立てると、どの事例を比べるか、何が分かったら案を修正するかまで決められる。
配分の方針は、実際の依頼に照らして具体化できる。複数の事業から同じ時期に要請が来たら、どの段階のどんな相談を優先し、誰がその判断をするのか。この場面で使える答えまで用意すると、戦略を具体的な行動に移すところまで考えられる。
問いの重要度は、仕事の規模とも分けて考えられる。たとえば学習アプリの初回体験で、「登録した人は、最初の問題を選べずに離れるのか、それとも選んだ後で難しさを感じて離れるのか」と問う。前者なら問題を選ぶ画面、後者なら最初に出す問題や解き方の案内が改善の候補になる。対象は一つの画面や数分の体験でも、答えが次の開発方針を左右するなら、先に取り組む価値がある。
同じ会議に向けて、二つの仕事が進む
来期の方針を話し合う会議を開くとする。当日までに前提となる数字をそろえ、読める形にした資料を参加者に共有するのはフロー型である。どの事業に人を振り向けるべきかを考え、案を比べて根拠を用意するのはビルド型である。一枚の資料に集計結果と配分案が並ぶこともある。資料を共有できたかと、配置方針を決めるだけの根拠がそろったかは、別々に確かめられる。
会議の日までに調べきれなかったときは、分かったこと、暫定案、判断に必要な追加情報を分けて持ち込める。たとえば支援を急ぐ事業は見えているが、担当者が実際に動ける時期が分からないなら、会議では優先する事業を相談し、配置は稼働を確認した後に判断する。会議でどこまで決められるかは、出席者が持つ情報や判断できる範囲にもよる。期限までに議論を始められたことと、方針が決まったことを区別すると、会議後の作業も具体的になる。
問いに答えが出ると、その判断を受けて新しいフロー型の仕事が生まれる。支援先と担当が決まれば、開始日までに現場と話す機会を設け、引き継ぎに必要な資料をそろえることになる。反対に、引き継ぎを重ねるうちに、複数の事業で同じ専門性が不足していると分かれば、配置や育成の方針を見直すイシューが生まれる。仕事を明らかにする段階と進める段階は、一つのプロジェクトの中で何度も現れる。
進捗を記録する単位
フロー型は、期限と次の行動を一緒に書くと管理しやすい。たとえば「木曜のレビューまでに、小さい画面で申込ページを開いてリンクを確認する」と書けば、いつ着手するかを判断できる。複数人で進めるなら、確認結果を誰に知らせるかまで分かると、修正に移れる。作業が済んだ後は、相手が受け取ったか、次の作業に進めるかを確かめる。
ビルド型では、次の行動に加えて、その行動がどの問いに答えるためかを残しておく。「支援事例を三件読む」とだけ記録すると、読み終えた時点で何を判断できるようになったかが分かりにくい。「共通部門から短期間だけ人を出して成果が出た条件を、三件の支援事例から調べる」と書けば、共通点と例外を次の検討に持ち越せる。読み始めて比較できる事例が足りないと分かれば、当時の担当者に聞く仕事を加えられる。イシューを単位にした仕事の管理では、向き合う問いと、それに答えるための行動を区別して扱っている。
ビルド型では、会議や提出日がまだ決まっていない段階でも、次に取り組む日を自分で決める。まとまった答えが出るまでには、事例を読み、話を聞き、仮説を見直す時間が要る。一回の検討を終えるたびに、分かったことと次に確かめることを書いておく。急ぎの仕事で中断しても、何を考えていたかを一から思い出す時間が減り、続きから始められる。
週の終わりには、完了した作業に加え、どの判断が前に進んだかを確認できる。たとえば、共通部門からの支援で進められる仕事と、事業の事情に通じた担当者が必要な仕事を分けられたなら、その区別は次週にも使える。残る問いが「同時に支援を求められたとき、誰が優先順位を決めるか」まで絞れていれば、次は配置を決める権限と、その判断に必要な情報を調べる段階である。