"掴まず、抗わず、流れとともに" 第192話
前回、第191話では、「感情労働で壊れる人 カスタマーサポート編」を扱いました。
丁寧にやるほど削られ、雑にやると罪悪感で削られる。
その出口のなさの中で、人は自分の人格を仕事へ持ち出し続けてしまう。
だから必要なのは、優しさを捨てることではなく、丁寧さを必要十分へ戻し、人格の持ち出し量を下げることでした。
今回扱うのは、別の形で同じことが起きる現場です。
カスタマーサポートでは感情が徴用されていました。
プロダクト開発では、責任感と知性と主体性が徴用されます。
この現場では、よくこう言われます。
オーナーシップを持とう。
自分ごととして考えよう。
課題を拾おう。
改善提案をしよう。
巻き取ろう。
推進しよう。
どれも一見もっともです。
実際、こうした姿勢がプロダクトを前へ進めることはある。
しかし、この言葉群には一つ大きな罠があります。
責任感が強い人ほど、仕事の成否がそのまま自分の人格評価に直結しやすいことです。
そこで今回の主題はこれです。
オーナーシップが人を燃やす。
プロダクト開発編。
結論を先に言います。
プロダクト開発の現場で人を燃やすのは、仕事量そのものだけではありません。
参加型経営と意欲強制が混ざり、従業員でありながら「新米経営者」として振る舞うことを内面化してしまうことです。
つまり、プロダクトの勝敗を役割の範囲で受け止めるのではなく、自分の人生や価値の勝敗として引き受けてしまう。
この事例で必要なのは、主体性を捨てることではありません。
オーナーシップを「人格」ではなく「役割」の範囲に戻すことです。
そのために中心となる適用順は、
プロトコル1
仕事の侵食マップを作る
プロトコル8
意欲の強制から降りる参加の仕方
プロトコル9
緊急の偽装を見抜く運用
プロトコル3
境界線の言語化テンプレ
プロトコル6
成果と人格の切り離し
プロトコル16
仕事ができない日を前提化する
この順になります。
なぜこの順か。
この職種では、まず私生活のどこまで仕事が侵食しているかを見なければならず、その次に参加の単位を変え、緊急っぽさを削り、責任境界を言語化し、最後に成果と自己価値の切り離しを制度化しないと、また全部を自分の人格で埋め始めるからです。
責任感が強い人ほど、仕事が人生を飲み込む
プロダクト開発の現場には独特の魅力があります。
ただ言われたものを作るだけではない。
どうあるべきかを考える。
何を優先するかを決める。
より良い体験を設計する。
チームで議論し、仮説を立て、改善を重ねる。
ここには知性も創造性も責任感も要る。
だからこの仕事に引かれる人は、多くの場合かなり真面目です。
良くしたい。
前に進めたい。
ユーザーのためにしたい。
プロダクトを育てたい。
そう思って入ってくる。
問題は、その良さがどこで燃料から拘束へ変わるかです。
責任感が強い人ほど、少しずつ次のように感じ始めます。
この課題に気づいた以上、自分が動くべきだ。
改善案がある以上、自分が推進すべきだ。
いま巻き取らなければプロダクトが悪くなる。
つまり、役割として参加していたはずのものが、人格として引き受ける義務へ変わっていく。
ここで、仕事はもう単なる仕事ではなくなります。
プロダクトの成否が、自分という人間の成否のように感じられ始める。
これがこの職種の深い苦しさです。
この現場で何が改造されるのか
プロダクト開発で改造されるのは、まず責任の境界です。
本来、自分が担うべき責任には範囲がある。
しかし、改善提案をする。
課題を発見する。
論点整理をする。
そうしたことが続くと、どこまでが自分の責任で、どこからがチームや組織や制度の責任なのかが曖昧になっていく。
気づいた人がやる。
言い出した人が持つ。
そうした暗黙ルールがある職場ほど、この侵食は速い。
次に改造されるのは、時間の意味です。
勤務時間が終わっても、バックログが頭から離れない。
ユーザーストーリーが回る。
優先順位が気になる。
会議で言い返せなかった一言が残る。
つまり仕事は、時間の中で終わらず、頭の中で続く。
ここで生活はかなり侵食されています。
最後に改造されるのは、成果の読み方です。
施策が外れた。
数字が伸びない。
優先順位がずれた。
すると、それが単なる仕事上の結果として処理されず、
自分は見る目がない。
自分は推進力がない。
自分は価値を生めていない。
という人格判決へ滑っていく。
つまり、成果と人格が非常に結びつきやすい。
これがこの職種で人を燃やす構造です。
改造サインはどこに出るか
この事例では、特に三つの改造サインが重要です。
第一に、休日もバックログが頭から離れないことです。
休んでいても、未完了感が消えない。
思いついた課題を書き留めたくなる。
他チームの動きが気になる。
来週の議論を先回りして考えてしまう。
これは思考侵食の典型です。
仕事がもう勤務時間の中に収まっていません。
第二に、失敗が「自分の価値の失敗」になることです。
施策が刺さらなかった。
すると、単に仮説が外れたのではなく、自分の洞察が浅い、自分は役に立てない、という読み方になる。
この時点で、成果と人格はかなり混ざっています。
第三に、仕事以外の時間までインプット化することです。
読書は知見の補充になる。
映画は体験設計のヒントになる。
会話はユーザー理解の材料になる。
散歩ですら、思考整理の時間になる。
つまり生活がまるごとプロダクトの補助線へ回収され始める。
ここまで来ると、仕事の外側が薄くなっています。
どこから介入するか
この事例で最初に必要なのは、プロトコル1、侵食マップです。
なぜか。
この職種の苦しさは、仕事時間の長さだけでは見えにくいからです。
むしろ、どこから私生活が仕事化しているかを特定しないと、全部が「自分が気にしすぎるせい」に見えてしまう。
見るべきは四領域です。
時間侵食。
夜や休日にどこまで仕事がはみ出しているか。
思考侵食。
頭の中でプロダクト会議がどこまで続いているか。
感情侵食。
失敗や評価が生活全体の気分を支配していないか。
評価侵食。
プロダクトの勝敗がそのまま自分の価値へ変換されていないか。
この四つを見えるようにすることが、最初の診断になります。
たとえば、
休日にずっと仕事しているわけではない。
しかし朝起きて最初に課題管理ツールを思い出す。
あるいは、
勤務中は平静だが、帰宅後に失敗した施策のことばかり考える。
このように入口は人によって違う。
まずそこを見ないと、介入点が定まりません。
次に必要なのは、参加の仕方を変えること
侵食が見えたら、次に当てるのはプロトコル8です。
この職種で最も危険なのは、提案、関与、責任が一体化していることだからです。
気づいた。
だから自分がやる。
提案した。
だから最後まで持つ。
問題を理解している。
だから自分が巻き取る。
この流れがある限り、プロダクトは少しずつ人格の全投資になっていきます。
ここで必要なのは、参加の単位を変えることです。
提案は出す。
しかし、その瞬間に所有権までは抱えない。
論点整理はする。
しかし、実装責任まで一緒に持たない。
懸念は言う。
しかし、言った以上自分が全部やらねば、という契約には入らない。
この区別をはっきりさせる必要があります。
現場で使える形にするなら、
「改善余地があります。必要なら論点整理まではやります」
「これは気になります。ただ、担当と優先順位は別で決めたいです」
「提案は出せますが、運用責任まで持つ前提ではありません」
こうした言い方が有効です。
提案を出すことと、人生ごと賭けることは違う。
この線を言葉にすることが、燃焼を止める中心になります。
プロダクト開発では「緊急っぽさ」も非常に危険である
次に必要なのが、プロトコル9です。
プロダクト開発は、一見するとカスタマーサポートほど緊急が多くないように見えるかもしれません。
しかし実際には別の形で、緊急っぽさが膨張しやすい。
今日中に決めないと遅れる。
今ここで巻き取らないと体験が悪くなる。
この議論を今やらないとあとで大きな損失になる。
そうした空気が頻繁に生まれます。
しかも、プロダクトは未確定情報が多い。
だから
もしかすると大きいかもしれない
が緊急として扱われやすい。
ここで必要なのは、定義です。
本当に今日中に決める必要があるのか。
いま必要なのは一次判断か、恒久判断か。
今日動かないと何が壊れるのか。
そこを分ける。
でないと、すべての不安が即時対応案件になります。
すると、神経がずっと仕事の方へ引かれる。
この職種では特に、
未確定
と
緊急
を同義にしないことが重要です。
まだわからないことは多い。
しかし、わからないからすべて今やる、ではなく、
わからないなら確認手順へ乗せる。
そこへ戻せるかどうかで、かなり違います。
境界線は「怠慢」に見えない形で言語化する必要がある
ここでプロトコル3が必要になります。
プロダクト開発の現場では、境界線がしばしば
主体性がない
と誤解されやすい。
だからただ断るだけでは、自己否定も摩擦も増えやすい。
必要なのは、境界線を運用として言語化することです。
たとえば、
「追加で持つなら、今の優先順位の入れ替えが必要です」
「今日は論点整理までにします。実装判断は明日に回したいです」
「即答はしません。確認して○時までに返します」
「今週はこの範囲までは持てますが、それ以上は別担当が必要です」
こうした言い方です。
大事なのは、
やりたくない
ではなく、
この形なら成立する
を示すことです。
そうすると、境界線が単なる拒否ではなく、運用上の調整に見える。
この職種では、この差が大きい。
なぜなら、主体性が重視される現場ほど、拒否は人格評価に結びつきやすいからです。
成果と人格の切り離しが最後の要になる
ここまで来て、ようやくプロトコル6が本格的に効いてきます。
プロダクト開発で最も深い苦しみは、やはりここにあるからです。
プロダクトの勝敗と自己価値が直結していること。
これを切らない限り、どれだけ運用を整えても、最後はまた内側で自分を燃やします。
ここで必要なのは、施策や判断を三層で読むことです。
事実。
何が起きたか。
影響。
何にどんな影響が出たか。
次の一手。
何を変えるか。
ここで止める。
そこから先の
だから自分はプロダクトを預かる資格がない
だから自分は価値を作れない
という人格判決へ行かない。
また、この職種では自己評価の固定点も重要です。
仮説が外れても、誤りをごまかさない。
議論がずれても、論点は明確にする。
できない日は短縮運転へ切り替える。
そうした運用上の誠実さを固定点にする。
すると、施策が外れた日にも、自分全体が崩れにくくなります。
そして最後に、「できない日」を制度へ入れる
この事例では最後に、プロトコル16が必要になります。
なぜなら、プロダクト開発の現場では
常に深く考え、常に前に進め、常に良い判断を出せる
ことが暗黙の前提になりやすいからです。
しかし現実には、そんな日は続きません。
集中できない日。
判断が浅い日。
人と話すだけで消耗する日。
そういう日は必ず来る。
にもかかわらず、その日を例外や事故として扱うと、
今日は全然だめだ
がそのまま
自分はこの仕事に向いていない
へ滑りやすい。
だから、できない日を制度へ入れる必要がある。
たとえば、
重い判断は一日にいくつまでにするか。
議論が荒れそうな日は、品質の下限をどこに置くか。
今日は論点整理までで十分、という短縮運転をどこで発動するか。
そうしたものを先に持つ。
すると、プロダクト開発の現場で最も痛い
思考の鈍り
が、人格の終わりではなく運用条件になります。
これが最後の重要な転換です。
この事例でやってはいけない失敗
まず一つ目は、主体性を下げることを、手を抜くことだと誤解することです。
責任感の強い人ほど、ここで苦しみます。
巻き取らない。
全部を持たない。
そのこと自体に罪悪感が出る。
しかし、ここで下げたいのは責任感ではありません。
人格投資です。
役割としての参加は残してよい。
全部を人生として引き受けない。
その違いを失わないことが大切です。
二つ目は、緊急の定義を持たず、結局いつでも呼び出し可のままでいることです。
プロダクト開発では、
この件だけ
いまだけ
今日だけ
が非常に多い。
しかし、それを全部飲むと、常時オンの神経が出来上がります。
そして、その神経は休日も離してくれない。
だから、優先順位や即時性の線引きを曖昧にしたまま善意で耐えるのは危険です。
この事例の着地点
この事例の着地点は明確です。
オーナーシップを「人格」ではなく「役割」の範囲に戻すこと。
これです。
プロダクトに関わる。
しかし、プロダクトの成否すべてを自分の人格評価にしない。
改善提案をする。
しかし、提案した瞬間に人生ごと賭けない。
関与する。
しかし、責任上限を持つ。
失敗することもある。
しかし、それをそのまま存在価値の失敗に変えない。
この位置に戻ると、プロダクト開発は
全部を背負って燃える仕事
から
役割として深く関わりながらも壊れない仕事
へ少しずつ変わっていきます。
そしてもう一つの着地点があります。
プロダクトの勝敗と自己価値が分離されることです。
これは簡単ではありません。
しかし、ここが分かれ始めると、判断の質そのものも上がりやすい。
なぜなら、施策や議論を
自分の存在防衛
としてではなく
仕事上の判断
として扱えるようになるからです。
これは非常に大きい。
この事例が示していること
プロダクト開発の現場は、現代の知的労働の縮図です。
感情労働ほど露骨ではない。
しかしその代わり、責任感、知性、主体性、創造性が徴用される。
しかも、その徴用はしばしば
成長
や
やりがい
や
オーナーシップ
というポジティブな言葉の中に隠れています。
だから見えにくい。
しかし見えにくい分、深く入りやすい。
この事例を読む時に大事なのは、
自分はPMや開発職ではない
で終わらないことです。
自分の仕事の中にも、気づいた人が全部背負う構造はないか。
主体性がいつの間にか人格契約になっていないか。
改善提案が自己価値証明になっていないか。
そこを見ることです。
その問いは、多くの職種に通じます。
このシリーズの立場
ここでも、主題は同じです。
掴まず。
オーナーシップや改善責任に、自分の人生全体を預けすぎない。
抗わず。
また巻き取りすぎた自分を、理想の主体的人間へ鍛え直そうとしない。
流れとともに。
侵食を見えるようにする。
参加の上限を持つ。
緊急を定義する。
境界線を言葉にする。
成果と人格を切り離す。
できない日を制度へ入れる。
そうやって、プロダクトとの距離を少しずつ取り戻していく。
第192話。
オーナーシップが人を燃やす プロダクト開発編。
この事例が教えているのは、主体性を捨てることではありません。
主体性を、人格の全投資から役割の運用へ戻すことです。
そこからしか、この仕事は長く持ちません。
