生産性が上がらないチームは、この問いを忘れている

はじめに

四半期の目標設定の会議室にいた。

マネージャーが「今期は何をやるか」と聞いた。メンバーが手を挙げた。認証基盤の設計改善、API（システム間の接続口）の応答速度の改善、新規機能の試作。ホワイトボードがタスクで埋まり、マネージャーが上から3つに線を引いた。「この3つに集中しよう」。

3ヶ月後、達成したのは1つだった。残り2つは「状況が変わった」で消えた。ホワイトボードになかった仕事──突発的な障害対応や他チームからの問い合わせ──に半分の時間を取られてしまったのだ。

ホワイトボードの前にいた全員が「何をやるか」を話していた。しかし、誰も問わなかった問いがある。このチームは何のために存在するのか。誰のどんな問題を解決するために、私たちはここにいるのか。この問いの存在にすら、たぶん気づいていなかった。

チームの朝会は何に「雇われて」いるか

ここで「ジョブ」という言葉を使います。クレイトン・クリステンセンの「ジョブ理論」から借りた言葉です（詳しくは巻末の参考資料を）。

ジョブとは、人が片付けたいと思っている用事のことです。この理論の見方では、人は商品やサービスそのものを欲しがっているのではありません。自分の用事を片付けるために、それを「雇って」いる。もっとうまく片付けてくれるものが現れれば、古いほうを「クビにして」乗り換える。

この「雇う／雇われる」という見方を、商品だけではなく、チームの中の仕組みに当てはめてみます。私たちが日々やっている仕組みはすべて、何かのジョブに「雇われて」います。たとえば朝会。毎朝15分、各メンバーが「昨日やったこと」「今日やること」「困っていること」を共有します。

では、朝会のジョブは何でしょうか？　多くのチームは「情報共有」だと答えるでしょう。しかし、朝会が実際に満たしているものは、少なくとも3つの層にわたっていると思います。

情報を受け渡す層──タスクの重複を防ぐ。作業の障害（ブロッカー）を早期発見する。「昨日やったこと」「今日やること」「困っていること」を確認する。ここだけを見れば、朝会は情報の受け渡しの場です。

不安を軽くする層──朝、チームメンバーの顔を見て、全員がいることを確認する。一人で抱えている問題を声に出して、不安が少し軽くなる。「大丈夫、自分だけが困っているわけではない」と感じられる場です。

一員であることを確認する層──「困っています」と言ったときに、誰かが「手伝うよ」と応じる。その関係性を日々確認する。「自分はこのチームの一員だ」という感覚は、日々の小さなやり取りの積み重ねで作られます。

もし朝会を「情報の受け渡し」の層だけで見ているなら、「Slackで書けば済むのでは」となります。しかし、朝会を廃止したチームで「なんとなくチームの一体感がなくなった」と感じた経験はないでしょうか。下の2層──不安を軽くする層と、一員であることを確認する層──が一緒に消えているのです。

ジョブを取り違えたまま仕組みを変えると、意図しないものが壊れます。

人は機能ではなくジョブを「雇う」

数年前、社内の開発者向けにあるプラットフォームを作ったとき、さまざまな機能リクエストが寄せられました。「ビルドをもっと速くしてほしい」「ログ検索を強化してほしい」「ダッシュボードにメトリクスを追加してほしい」。

私たちは素直に実装しました。リクエストに応えたから、開発者のプラットフォームの利用回数も増えるだろうと思っていた。しかし、ほとんど増えませんでした。

そこで、特定の開発者に張り付いて、彼らが実際にこのプラットフォームをどう使っているかを観察しました。すると、最も頻繁に開かれていたのは、いちばんリクエストの多かったメトリクス画面ではなく、過去のビルドログ（コードを動く形に組み立てたときの記録）を前回と見比べる画面でした。

要望に応えて作った画面ではなく、誰も強く求めていなかった画面が、一番使われていた。これがまず予想外でした。

しかも、見るタイミングが不可解でした。この種の記録は普通、何かが壊れた後に「なぜ壊れたか」を調べるために開きます。ところが彼らは、まだ何も壊れていない段階、新しいコードを送り出す直前に開いていた。事故の記録を、事故の後ではなく、車を出す前に読むようなものです。

意味が分からず、本人に聞きました。返ってきた答えはこうでした。「同じ失敗をしていないか、先にチェックしておきたい。運用チームに『またこれか』と言われたくないので」。

つまり、開発者の多くがメトリクス画面を求めたのは、メトリクス画面が見たいからではなかった。このプラットフォームが「雇われていた」のは、「運用チームに叱られない自分を守る」というジョブでした。機能は同じなのに、ジョブは違った。

ここから学んだことは、はっきりしています。私たちがやるべきだったのは、相手が本当に片付けたい用事であるジョブを先に知ることでした。

全員が困っているのに誰のタスクにもない仕事

ここまでは「すでに存在する仕組み（朝会や機能）がどんなジョブに雇われているか？」を見てきました。

しかし、視点の使い方にはもう1つあります。まだ仕組みは存在しないが、たしかに必要とされている事柄を見つけて、チームのジョブとして定義することです。

仕事の現場には、困っているのに、解決する手段がないまま諦められている領域があります。「そういうものだ」と受け入れてしまって、不便を不便と認識すらしていない。

たとえばある部署で、毎朝誰かが手作業でCSVを集計していました。本人は「これは自分の仕事だから」と諦めて受け入れていた。同僚も「大変そうだけど、自分の仕事ではない」と通り過ぎていた。

そして、誰かがふと自動化スクリプトやAIアシスタントを差し出した瞬間、「ずっとこれが欲しかった」と、はじめて不便は不便として認識されます。

誰もやっていないが、全員が必要としている仕事を見つけて、自分たちのジョブとして定義する。ここに手をつけるチームは、組織にとって不可欠な存在になります。

「手作業のCSV集計を改善する」という仕事は、四半期のホワイトボードには載りませんが、チームの生産性に直接影響しています。

チームの「予期」で見える景色が変わる

ここで、あなたのチームに「ジョブの定義」が必要かどうかを見分けるヒントを3つ紹介します。

既存の仕事をより良くやるチーム──同じプロダクトの機能を改善します。同じプロセスを安定して回します。堅実で欠かせない存在ですが、代替可能性が高い。見分けるヒントは、「このチームがなくなっても、別のチームがやればいい」と言われたとき、即座に反論できるかどうかです。

※誤解のないように書き添えると、この型を貶めるつもりはありません。特殊ドメインを磨き抜く専門性で代替されないチームもあります。ここで話しているのは、磨き抜きが利かない領域で既存タスクだけをこなしている場合です。

既存の仕事を少ない人数でやるチーム──自動化を進めます。工数を削減します。短期的にはコスト削減に貢献しますが、長期的にはチーム自体の存在意義を削る方向に動きます。見分けるヒントは、「自動化が進むほど、自分たちの存在理由が薄くなっていく」と感じるかどうかです。成功するほど「このチームはもう要らないのでは」と言われる皮肉な構造です。

まだ誰もやっていない仕事を見つけるチーム──組織の中で困っているのに手段がないまま諦められている領域を見つけ、自分たちの存在意義を自分で作っていきます。見分けるヒントは、「このチームにしかできない仕事が、自分たちの言葉で語れるかどうか」です。

この3つの振る舞いを分けているものが何なのか、私は長いこと分かっていませんでした。振り返ってやっと気づいたのは、チームが自分たちを何だと思っているか──自分たちは何をするチームだと「予期」しているかが、この違いを生んでいたということです。

ここで「予想」でも「認識」でもなく「予期」と書いたのには理由があります。

予想は自分の外で起きることを当てにいく言葉、認識はいま目の前にあるものをそのまま捉える言葉で、どちらも見る対象がすでにそこにあることを前提にしています。

しかし予期は違う。予期とは「自分たちはこういうチームだ」とあらかじめ構えることであり、その構えが、何を見るかより前に、何が目に入るかを選んでしまう。見てから予期するのではなく、予期しているものしか見えない。だからここでは、あえて予期と書いています。

私たちが「うちは既存のAPIを改善するチームだ」と予期していた頃、目に映る仕事はそのカテゴリに合うものだけでした。新しい仕事が目の前にあっても「それはうちの仕事ではない」と反射的に分類して棚に上げていた。

つまり、チーム自身への予期の差が、見える景色を作るのです。

そして予期は自己強化します。「うちはこれをやるチームだ」と予期していると、それ以外の仕事に手を出さなくなる。出さないから経験が積まれない。経験がないから自信も持てない。新しい仕事を探す目が曇り、予期が補強される。気づかないうちに、選択肢そのものが減っていきました。

しかし、チームの定義を「開発者の困りごとを片付けるチーム」に書き直してからは、同じ目の前の現実から全く違うものが拾えるようになりました。新しい仕事が増えたのではありません。前から見えていたのに「見えていなかった」仕事が、急に見えるようになったのです。

見える景色が、予期によって選別されていた。その瞬間に、過去数ヶ月のチームの選択が「選ばれた」のではなく「選ぶ以前に消されていた」ことに気づいて、少し背筋が寒くなりました。

自分で仕事を定義するチームは代替されない

チームが何を見るかは「チームが自分たちを何だと予期しているか」の関数です。だから自分たちの仕事のジョブを再定義することは、仕事の再配分である以前に、自分たちへの予期の書き換えです。

そしてそれは、一度やれば済むものではありません。放っておけば、チームは自分の予期を強化する方向に戻ります。毎月意識的に手を入れ続けないと、気づかないうちに元の予期に戻っていく。

この戻り癖のせいで、ほとんどのチームは「既存を維持する」か「既存を効率化する」にとどまっています。上から降ってくる仕事をこなすか、既存の仕事を効率化するか。

しかし、最も価値を生み、最も代替されにくいのは、新しい仕事を自分で見つけるチームです。なぜなら、仕事を自分で定義しているからです。定義した本人たちが最もその仕事の意味を理解しています。

ただし、反論も聞こえます。「それは、誰にも依頼されていない仕事を勝手に始めるチームではないか」と。正当な指摘です。このタイプのチームが成立するには、決裁権を持つ人に承認を取りつける政治力が要ります。発見するだけでは不十分で、その仕事の価値を、予算と人員を動かせる立場の人に説明する能力が必要です。

チームの強みは「何ができるか」ではなく、「自分たちの仕事が、組織の中で誰の何を前に進めているか」で決まります。

以前、自前で運用していた監視基盤を外部サービス（SaaS）に移行したことがありました。「作れる」は内部資源の話です。「作るべきか」は外界との対比の話です。新しい仕事を見つけるチームは、外界の変化を見て「何を持ち続け、何を手放すか」を判断できるチームです。

AIがこの問いをさらに鋭くしているように感じます。AIがコードを書き、ドキュメントを作り、分析を出せるようになると、「何ができるか」は急速に安くなっていきます。能力は誰でも手に入る汎用品（コモディティ）になります。

そのとき残る問いは「何に賭けるか」です。

AIは出力を無限に修正・撤回できますが、チームの決断は簡単には撤回できません。失敗しても「ここで頑張る」と腹をくくる覚悟は、AIには持てない。たぶん。新しい仕事を自分で見つけるチームの本質は、能力の高さではなく、賭けの深さにあります。

「あの人さえいなければ」という誤診に、いま答えを出す

ここで、第1回の連載の冒頭に戻ります。「あの人さえいなければ」──この誤診から、連載は始まりました。5回の旅を経て、この誤診にどう答えを出せるのか。いま書いておかないと、連載全体の結論がぼやけます。

第1回で例に出した「困った人」を、順に棚卸しします。会議を脱線させるAさん。決まったことを後から覆すBさん。何をやっているかわからないCさん。当時の私は、この3人の「個性」に問題の原因を帰属させていました。いまなら、全員違う景色が見えます。

Aさんが会議で脱線したのは、Aさんの個性ではありません。あの会議が、Aさんにとっての「チームの一員であることを確認する」ジョブを満たす唯一の場だったからです。冒頭で、朝会の役割が「チームの一員であることを確認する層」も一緒に満たしていたという話を書きました。Aさんの職場では、あの種の層が他のどこにも提供されていなかった。

だからAさんは、会議という「情報の場」に、承認という別のジョブを持ち込まざるを得なかった。脱線は、ジョブの不足分を埋めようとする合理的な行動でした。Aさんが「脱線する人」だったのではない。チームの制度が、Aさんを脱線させる人にしていたのです。

Bさんが決定を覆したのも、Bさんの個性ではありません。意思決定のプロセスに、Bさんの声を拾う導線がなかったからです。第4回の連載で見た「悪い情報が自然に上流へ流れる経路」が、あのチームには設計されていませんでした。会議中は発言順が固まっていて、Bさんの「気になっていること」の行き場がなかった。残る場所は、決定の後だけだった。Bさんが「覆す人」だったのではない。制度が、Bさんに覆すことを強いていたのです。

Cさんについては、正直に書きます。Cさんは第1回の連載以降、私の記事にほぼ登場しません。書きながらずっと気づかないふりをしていました。「何をやっているかわからないCさん」──この言い方自体が、第1回の連載で触れた「代理指標の罠」と第2回の連載で触れた「グレシャムの法則」の合わせ技の再生産でした。

見えやすい仕事だけを「やっている仕事」として数え、Cさんの見えにくい仕事を「やっていない」と見なしていた。Cさんは障害を未然に防いでいたのかもしれない。新人の質問を黙って拾っていたのかもしれない。連載を始めた当時の私には、見えないものが「やっていない」と等号で結ばれていた。それだけは事実です。Cさんが「何をやっているかわからない人」だったのではない。私の眼鏡が、Cさんを見えなくしていたのです。

つまり、「あの人さえいなければ」という誤診の正体は、3つの盲点の重ね合わせでした。

第1回で見た「人の評価や見え方は構造によって変わる」こと。第2回で見た「測りやすいものが測りにくいものを駆逐する」こと。第5回で見た「ジョブの不足分を別の場で埋めざるを得ない人がいる」こと。この3つは独立に見えて、実は1つの構造の別の断面です。

チームが自分たちのジョブを明確に定義していないとき、個人はそれぞれのやり方でジョブの不足を埋めようとし、その埋め方の違いが「個性」や「問題」として現れる。だから、「あの人」を排除しても何も変わらないのです。

覚悟は制度として設計できる

では、どう答えを出すか？　「あの人を変えよう」でも「あの人を受け入れよう」でもありません。どちらも個人に原因を戻す発想です。答えは1つです。

チームのジョブを明確にし、そのジョブが満たすべき複数の層──情報、不安、承認、意思決定への参加──を制度として設計する。

層が設計されれば、Aさんは会議で脱線する必要がなくなる。Bさんは決定の後に異議を唱える必要がなくなる。Cさんの見えにくい仕事は、ジョブに貢献する仕事として再定義される。人は変わりません。構造が変わることで、同じ人が違う行動を取ります。

ここで、第1回で自分に対して立てた問いにも答えを出しておきます。「構造を変える覚悟」が自分にあるのか、と書いた問いです。

5回書いてわかったのは、覚悟の有無は二択ではないということでした。覚悟は制度として設計できる。

個人の決意に頼るから二択になる。月次の振り返り、ジョブの再定義、疑いを強制する場──これらが制度として回り始めれば、覚悟は個人の中ではなく、仕組みの中に移せます。「構造を変える覚悟」を個人に求め続ける限り、誰もその覚悟を持てません。覚悟は個人の性質ではなく、制度が引き出すものだった。

これが、第1回の問いへの、いまの私の答えです。

「あの人」は変えられないからこそ、構造で迂回経路を作る

ここまで読んで、「甘い」と感じた方がいるかもしれません。構造論はキラキラした環境でしか通用しない理想論ではないか、と。

この指摘は、半分正しい。残り半分は私が書き足りなかった部分なので、書き足します。

まず認めます。明らかに特定の「人」が組織の生産性を削っている。全員が気づいている。それでも動かせない。役員に直通の関係があった。労務上のリスクが高すぎた。私自身、「あの人さえいなければ」と言いたくなる現実に何度も直面してきました。

では、構造論は無意味か？　むしろ逆です。「あの人」は変えられないからこそ、構造で迂回経路を作るしかない。困った人を簡単に外せる組織なら、構造論は要りません。構造論が実用的になるのは、外せない人がいる現場です。

具体的にやったことを書きます。10年分のドキュメント化されていない知識を一人で握っていた人がいました。そこで、新人がその人に質問した内容を、全員が見えるチャンネルに自動転記する仕組みを作りました。本人は嫌がりました。しかし「新人のため」を盾にすれば、表立っては断りにくい。

半年で、その人しか知らなかったことの半分が、組織全体の知識になりました。残り半分はまだその人しか知りません。それでも、質問しないと業務が止まる構造は崩れました。

「あの人」を変えようとするのではなく、力の源泉である情報独占を先に崩す戦術です。相手が握っている資源の希少性を下げる。人を動かせないときに動かせるのは、人の周りの資源の分配だけです。

もう一人、「解決しない方が都合のいい人」もいました。第1回で書いた、根本設計の改修提案を静かに退けた人です。問題を管理する立場にいる限り、その人の存在意義はその問題と一緒にあります。問題が解決されれば、存在意義も消える。あの人の抵抗は、論理ではなく存在への防衛でした。

後から振り返って、やるべきだったのは、その人の新しいジョブを先に用意することでした。現行システムの設計者ではなく、次のシステムへの移行を監督する立場として振る舞ってもらう。敬意の対象を、過去の設計から未来の移行へずらす。存在意義を別の場所に移設する。

この下準備を怠ったまま構造論を振りかざしても、相手にとっては自分の過去を否定されるだけです。抵抗は必然でした。第5回の言葉で言い直せば、「解決しない方が都合のいい人」には、別のジョブを先に設計しなければ、構造は動かない。ジョブ論は、外せない人を外さずに構造を動かすための、具体的な迂回路です。

もちろん、この戦術も万能ではありません。相手が新しいジョブを受け入れない場合があります。敬意を払われても権力そのものを手放す気がない人もいます。それでも、個人を名指しで攻撃するより、構造で迂回する方が勝率が高い。これが失敗の積み重ねから学んだことです。

構造論は理想ではなく、「あの人」は変えられない現実で、それでも何かを動かそうとする側の技術です。

この連載で書いてきたことは、キラキラした解決策ではなく、ほとんどは敗北の記録と、敗北の中で見つけた小さな迂回路の記録です。迂回路は万能ではありません。通れない場所もあります。それでも、正面突破で何度も砕けるより、迂回路を地図に書き残す方が、次の人の役に立つはずです。

すべての問題の根は「ジョブの不在」だった

ここで、連載全体を振り返ります。5回かけて見てきたものが、自分の中で何と繋がったのか、正直に整理しておきたいのです。

ジョブが明確なら、「消すべき仕事」と「測るべき指標」の両方が見えます。 第1回で「この仕事は証拠づくりだ」と判断できたのも、第2回で「何のために測るか」を問えたのも、背後にジョブへの貢献という基準があったからです。

ジョブが不明確なとき、あらゆる仕事が「必要なのでは」と映り、あらゆる指標が「測るべきでは」と映ります。判断できないから消せないし、指標は増える一方になります。

そして、ジョブを定義した後に「このジョブ定義は本当に正しいか」と問い直す習慣が、第3回の連載で見た「疑える構造」そのものです。「自分の仮説を検証するモード」を、チームの存在意義に向けて使うこと。

ジョブを問い直すとは、チーム自身を仮説として扱い、現実の証拠で更新し続けることです。「私たちはこういうチームだ」という信念を守るのではなく、「私たちのジョブは本当にこれで正しいか」を自分たちに問う。このモードに入れるかどうかが、代替されるチームと代替されないチームを分けます。

つまり、すべての問題の根には「ジョブの不在」があったのです。忙しいのに進まない。測っているのに改善しない。賢いのに判断できない。善意があるのに機能しない。すべて、「このチームは何のために存在するか」という問いの不在から来ていました。

しかも、ジョブの不在はチームの判断を狂わせるだけでなく、メンバー個人の動機そのものを枯らしていきます。人が内側から動けるためには、3つの条件が要ると感じています。なぜやるのかが分かること。自分が上達している実感があること。自分で決められる範囲があること。

ジョブが不明確なチームでは、3つとも成立しません。なぜやるのかが分からないから、動機の土台がない。何を上達させればいいかが見えないから、努力の方向が定まらない。判断基準がないから、自分で決める余地がない。ジョブの不在は、メンバーの動機そのものを構造的に殺しています。

ジョブの不在は原因ではなく、症状だ。そう言いたくなる自分もいます。ジョブが不明確になるのは、組織が急拡大したから、事業の方向性が揺れたから、マネジメントが機能していないから。根本原因はもっと上流にあるのではないか。

しかし、「上流を直せ」は正論であっても処方箋にはなりません。チームが今日できることは、自分たちのジョブを自分たちの言葉で定義することです。上流が壊れていても、その一歩は踏めます。

具体的に何ができるか。私が試したのは、3つの問いを繰り返すことでした。

• 今月、チームの時間の3割以上を使ったが、ジョブに貢献していない仕事は何か？
• それをやめたとき、誰が本当に困るか？
• 困る人がいるなら、別の形で満たせないか？

完璧ではありません。しかし、問い自体が構造を動かし始めます。

おわりに

四半期の目標設定に戻ります。

マネージャーが「今期は何をやるか」と聞いた。今度は、私が先に問いました。「その前に、私たちは誰のどんなジョブを片付けるために存在しているのか、話しませんか？」。

少し沈黙があった。それから、ゆっくりと対話が始まった。「うちのチームのユーザーって、社内の開発者だよね」「開発者が困っているのは、環境構築の手間とチーム間の仕様の曖昧さじゃないか」「つまりうちのジョブは『開発者が開発に集中できる基盤を作ること』では」。

ホワイトボードに書かれるタスクが減りました。5つが2つになった。しかし、1つひとつが重い。重いが、意味がある。

3ヶ月後、2つとも達成しました。突発的な仕事は相変わらず降ってきました。しかし、ジョブが明確だったから、「これはジョブに貢献するか」で判断できました。貢献しないものは断りました。断れなかったものもあります。経営層からの依頼（VP案件）は、ジョブと無関係でも断れません。それでも、断る基準があるだけで、チームの時間の使い方は変わりました。

構造が忙しさを生み、計測がその構造を歪め、賢さがバイアスを増幅し、善意が制度なしには機能しない。5回かけて見てきたのは、つまるところ「チームは何のために存在するのか？」という一つの問いへの準備でした。

AIがコードを書き、ドキュメントを作り、分析を出せるようになった以上、もとの「生産性」に戻る場所はもうありません。取り戻すのはアウトプットの量ではない。

自分たちの仕事の意味を、自分たちで定義する力。それが取り戻すべきものだった。

構造に名前をつけ、数字の外にある価値を認め、「本当にそうか」と立ち止まれる場を作り、善意を制度に変換し、そして「このチームは何のために存在するか」を自分たちの言葉で語る。

生産性とは、結局、「何に賭けるか」という問いへの答え方です。意味のある仕事は、忙しくても消耗しません。消耗するのは、意味のわからない忙しさです。意味はジョブの中にあります。ただし、「ジョブを問い直せ」と言っている自分が、半年後にまたジョブを見失っている可能性は高い。ジョブも一度定義して終わりではなく、問い続ける姿勢そのものが生産性の土台です。

おい、構造を見ろ。見ても、また人を責めるだろう。それでも、見ろ。

参考資料

↓連載第4回の記事はこちら

2026年6月 9日1on1、雑談タイム──これらが失敗に終わるのはなぜか

↓連載第3回の記事はこちら

2026年5月19日全員が正しいのに何も決まらない会議の正体

↓連載第2回の記事はこちら

2026年4月23日数字は「嘘をつける」──KPIがチームの協力を破壊する構造的な理由

↓連載第1回の記事はこちら

2026年4月16日「あの人さえいなければ」──この誤診が、チームの生産性を下げる