ブログ
ryuzeeによるブログ記事。不定期更新

【資料公開】「自分の仕事はここまで」はどこから来るのか

みなさんこんにちは。@ryuzeeです。

2026年10月22日に、あるお客様の社内イベントで「『自分の仕事はここまで』はどこから来るのか」というテーマで講演したので、資料を公開します(講演依頼はお気軽にどうぞ!)。

仕事柄いろいろな組織を見ていますが、「担当外のことには手を出さない」「チケットに書いてあるとおりにやりました」「言われていないので」といった声はどこでもよく聞きます。そして決まって「あの人は主体性がない」「当事者意識が足りない」と、本人の問題として片づけられます。対策も「越境しよう」という呼びかけや研修、目標管理シートへの「主体性」の記入など、本人に向けたものばかりです。でも、呼びかけで変わるくらいなら、とっくに変わっています。本人のやる気や性格のせいにするのは、たいてい見当違いです(他人の行動の原因を状況より性格や意欲に求めすぎるのは、社会心理学で「根本的な帰属の誤り」と呼ばれる典型的な思い込みです)。

「自分の仕事はここまで」は本人の意識の問題ではなく、目標設定や評価制度、意思決定の仕組みといった構造が生み出している症状です。 線を引いている人は、その環境に正しく適応しているだけです。

今回の資料では、線を引かせている構造を心理学や組織論の知見をもとに整理し、それを踏まえてメンバーとリーダー・マネージャーがそれぞれ明日から何をすればよいかを解説しています。

参考になれば幸いです。


忙しい人向けのサマリー

「自分の仕事はここまで」は原因ではなく症状

  • 「越境しよう」「当事者意識を持とう」と呼びかけても、たいてい変わらない
  • 本人の意識の問題として扱うと、症状のモグラ叩きになる
  • 行動は人と環境の両方で決まる(レヴィンの式)。他人の行動の原因を性格や意欲に求めすぎる傾向(根本的な帰属の誤り)にも注意する

自律は放任ではない

  • アジャイルソフトウェア開発宣言の背後にある原則もスクラムガイドも、自分の仕事に線を引かない自律的なチームを前提にしている
  • 自律とは、目指す方向や守るべき制約を共有したうえで、その枠の中で自分たちで判断して行動すること
  • 枠がわからないと、人は安全な範囲にこもりやすくなる
  • 目的が見えている、決めてよい範囲がはっきりしている、必要な情報が届く、自分の行動が結果を変えると感じられる、越境して失敗しても責められない。どれかが欠けると、人は線の内側にこもる

線の内側にこもると何が起きるか

  • 指示待ち、進捗率での報告、誰も決めない合議制、チケットの投げ合い、組織の沈黙、縦割りがそのままシステムの形になる(コンウェイの法則)
  • 「指示待ちをやめよう」とルールを作っても、別の形の症状が出るだけ。原因のほうを見る

線を引かせている3つの要因

  • 目標設定と評価制度:目標を担当範囲まで分解すると、目標に書いていないことはする理由がなくなる。担当外の貢献は評価されにくく、全体がうまくいかなかったときは責められる。この条件なら線の内側にいるのが合理的な選択になる
  • 学習性無力感:2016年の見直しで、学習しているのは「無力さ」ではなく「自分の行動で状況をコントロールできる」ということのほうだとわかった。「主体的になれ」と言うより、自分の行動で何かが変わった経験を作る
  • 意思決定者の曖昧さ:誰が決めるのかわからないと、意見を出すことが「他人の領分を侵す」行為になる。承認者が複数いると責任が薄まり(責任の拡散)、決定が後から覆されると決めることそのものに意味を感じなくなる

影響力を実感できる関わり方

  • 自分の意見や行動が結果に影響しないと感じると、関心を持ち続けるのは難しい
  • 関心を求める前に、影響力を実感できるようにする。採用されなくてもよいので、検討されて、採否の理由が返ってくることが大切
  • DACIで決める人(Approver)を1人に決め、意見を出す人(Contributor)を明確にすれば、意見を出すのは越境ではなく役割になる

線は引いてはいけないのか

  • 引いてよい。チームの認知負荷には限界があるので境界は必要(『チームトポロジー』)。問題は境界があることではなく、またぎ方が決まっていないこと
  • 線を引くだけで「内と外」が生まれるので、線をまたいで共有する上位の目標をセットで持つ。プロダクトゴールがこの上位目標になる
  • 線を引くのは説明責任と権限まで。関心まで線を引かない

明日から試すこと

  • メンバーとして
    • 自分のチームのゴールを1文で説明できるか確かめる
    • 自分の仕事に関わるステークホルダーを3人書き出す
    • 他チームのスプリントレビューに1回出てみる
    • 担当外で気になったことを1つ口に出す
    • 小さく越境して、結果が返ってきた経験を記録しておく
  • リーダー・マネージャーとして
    • 越境して失敗した人を責めない。悪い知らせを持ってきた人に感謝する
    • 提案には必ず結果を返す。通らなかったなら理由も返す
    • 決める人を明確にし、承認者は1人にする
    • 個人の目標とチームの成果をつなげ、担当外の貢献を見える場に出す
    • チームに任せる範囲を言語化する

それでは。

前の記事 ← 【資料公開】AIで組織を加速させる勘所

プロダクト開発で、こんな課題を感じていませんか?

  • 何を作るべきか、順位の決め方が定まらない
  • プロダクトの方向性をチームで共有できていない
  • 開発組織の体制や役割がうまく機能していない
  • 開発プロセスが形骸化し、目的を見失っている
  • アジャイルを導入したが、組織に定着しない

プロダクトマネジメント、組織構造、開発プロセスの課題について、組織全体の視点から支援します。

お問い合わせ(初回相談無料)

契約を前提にした相談でなくて構いません。相談に際して事前の整理や準備は不要です。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方
ダイナミックリチーミング 第2版
Tidy First?
脳に収まるコードの書き方
プロダクトマネージャーのしごと 第2版
エンジニアリングマネージャーのしごと
チームトポロジー
スクラム実践者が知るべき97のこと
プロダクトマネジメント
SCRUM BOOT CAMP THE BOOK
みんなでアジャイル
レガシーコードからの脱却
Effective DevOps
変革の軌跡
ジョイ・インク
アジャイルコーチの道具箱
カンバン仕事術
Software in 30 Days
How to Change the World