「誰も悪くない」の構造

二人のエンジニアが、同じレガシーコードを見ていました。

「ひどいな」と一人が言いました。「誰が書いたんだ、これ」

もう一人は静かにGitログを遡っていました。やがて言いました。
「4年前だ。チームが2人しかいなくて、3ヶ月で全部作り直した頃のコードだよ」

「だとしても、ひどいものはひどい」

「そうかもね。でも、4年後の誰かも、きっと僕らのコードを見て同じことを言うよ」

二人は黙りました。

画面には同じコードが映っていました。
でも、二人に見えていたものは、違っていました。

---

これは寓話です。

二人のエンジニアは実在しないかもしれませんし、どこにでもいるかもしれません。大事なのは、彼らが誰かということではありません。大事なのは、同じものを見ているのに、見えているものが違う、ということです。

これからお話しすることは、特別な知恵でも、新しい発見でもありません。

ただ、お願いがあるのです。

日々の仕事の中で、「なんでこうなっているんだ」と思う瞬間があったら、この二人のことを少しだけ思い出してほしいのです。

はじめに

形骸化した承認フロー。誰も読まないドキュメント。終わらない会議。放置される技術的負債。

目の前の「不合理」を見るたびに、私たちはつい考えます。「誰がこんな仕組みを作ったんだ」と。「なぜ変えようとしないのか」と。

でも、多くの場合「誰も悪くない」のです。

そしてそのことを理解することこそが、実は変化への第一歩だったりします。

これから、冒頭の二人のエンジニアと一緒に、いくつかの場面を見ていきましょう。

会議室にて

二人のエンジニアが、会議室にいました。

「また会議か」と一人が言いました。「今日だけで4つ目だ」

もう一人はカレンダーを見ていました。
「この会議、最初は月イチだったんだ。去年の4月から始まった」

「月イチ？ 今は毎日あるじゃないか」

「うん。5月に誰かが言ったんだ。『月イチだと情報が古くなる。隔週にしよう』って」

「それで？」

「6月に別の誰かが言った。『隔週でも足りない。週イチにしよう』」

「なるほど」

「7月にはこうなった。『週イチだと金曜の情報が月曜には古くなる。毎日やろう』」

一人が言いました。「誰がそんなことを決めたんだ」

もう一人は首を振りました。
「誰も『決めて』なんかいないよ。みんな、その時々で合理的なことを言っただけだ。情報は新しい方がいい。共有は多い方がいい。誰も間違ったことは言っていない」

「でも、結果として僕らは毎日1時間、会議室に座っている」

「そう。誰も望んでいなかったのにね」

二人は会議の開始を待ちながら、同じホワイトボードを見ていました。

前回の会議で書かれたまま消されていない文字がありました。「情報共有の効率化について」と書いてありました。

見積もりの話

二人のエンジニアが、スプレッドシートを見ていました。

「この機能、最初の見積もりは2週間だったのに、なんで2ヶ月になってるんだ」

もう一人がセルを指差しました。
「ここ、見てごらん。田中さんの見積もりが2週間。でも『バッファ込みで3週間』になってる」

「まあ、バッファは必要だろう」

「うん。で、チームリーダーがそれを見て、『念のため4週間で出しておこう』と」

「それも分かる」

「で、マネージャーがそれを見て、『他のタスクとの兼ね合いもあるから6週間で』と」

「ふむ」

「で、部長がそれを見て、『経営への報告だから余裕を持って8週間で』と」

一人が言いました。「つまり、誰も悪くないってことか」

「そう。田中さんは、以前見積もりを外して詰められたことがある。バッファを積むのは当然だ。チームリーダーは、チーム全体の遅延リスクを考えている。マネージャーは、複数チームの調整をしている。部長は、経営陣への説明責任がある」

「全員、自分の立場では正しいことをしている」

「うん。でも、結果として見積もりは4倍になった」

一人が言いました。「で、2ヶ月後に部長が言うわけだ。『なんでこんなに時間がかかるんだ？』って」

もう一人は黙ってうなずきました。

---

ここで少し立ち止まって、お願いがあります。

あなたの職場でも、似たようなことが起きていないでしょうか。

見積もりが膨らんでいく。会議が増えていく。承認フローが複雑になっていく。

そのとき、「誰がこんなことを決めたんだ」と思うかもしれません。

でも、多くの場合、誰も「決めて」などいないのです。

各人が、自分の立場で、自分なりに合理的な判断をした。その積み重ねが、誰も望んでいなかった結果を生んでいる。

これを「創発」と呼ぶ人もいます。部分の総和が、全体とは異なるものになる現象です。

でも、名前などどうでもいいのです。大事なのは、この構造を見ることです。

ドキュメントを探して

二人のエンジニアが、Confluenceを検索していました。

「このAPIの仕様書、どこにあるんだ」

「たぶん、ない」

「ないって、3年前からあるAPIだぞ」

「うん。だから、ない」

一人が言いました。「誰も書かなかったのか」

もう一人は検索結果をスクロールしながら答えました。
「最初は書いてあったんだ。でも、APIが変わるたびに更新されなくなった」

「なぜ？」

「考えてみてよ。ドキュメントを更新しても、評価には反映されない。でも、新機能を作れば反映される。締め切りに追われているとき、どっちを優先する？」

「新機能だろうな」

「そう。みんなそう思った。だから、誰もドキュメントを更新しなかった」

一人が言いました。「つまり、チームの意識が低いってことか」

もう一人は首を振りました。
「意識の問題じゃないと思う。構造の問題だ。ドキュメントを書くインセンティブがない。書かないインセンティブはある。この構造の中で、書かないのは合理的な判断だ」

「でも、結果として僕らは今、仕様を知るために元の開発者を探し回っている」

「そう。元の開発者は、もう会社にいないけどね」

二人は空の検索結果を見つめていました。

技術的負債の山

二人のエンジニアが、コードベースを眺めていました。

「このモジュール、誰も触りたがらないよな」

「触ったら最後、何が起きるかわからないからね」

一人が言いました。「なんでリファクタリングしないんだ」

もう一人はJIRAのバックログを開きました。
「ここに『リファクタリング』ってチケットがあるだろ。2年前からある」

「2年？」

「うん。で、毎四半期、優先度が下がっていく。なぜだかわかる？」

「機能開発が優先されるから？」

「そう。四半期ごとに機能リリースの目標がある。目標を達成しないと評価に響く。リファクタリングは『余裕があれば』になる」

「でも、リファクタリングしないと、開発速度がどんどん落ちていく」

「そう。でも、それは来四半期の問題だ。今四半期の問題じゃない」

一人が言いました。「経営陣は目先のことしか見ていないってことか」

もう一人は首を振りました。
「経営陣だって、技術的負債の問題は知っている。でも、彼らも四半期ごとの目標で評価されている。株主への説明責任がある。『今四半期は機能を出しませんでしたが、コードをきれいにしました』とは言いにくい」

「じゃあ、誰が悪いんだ」

「誰も悪くないんだ。みんな、自分の立場では正しいことをしている。でも、結果として負債は積み上がっていく」

二人は、2年間動いていないチケットを見つめていました。

仕様変更の連鎖

二人のエンジニアが、チャットのログを遡っていました。

「この機能、最初の仕様と全然違うな」

「数えてみたら、リリースまでに14回変わってる」

一人が言いました。「なんでこんなに変わるんだ」

もう一人はログを指差しました。
「最初の仕様をクライアントに見せた。『ここ、こうした方がいいかも』と言われた」

「まあ、フィードバックは大事だろう」

「うん。で、営業がそれを持ち帰って、『お客様の声です』と伝えた」

「それで？」

「PMが『顧客の声は大事だ』と言って、仕様を変えた。でも、デザイナーは別の方向で作り込んでいた。整合性を取るために、また変更が入った」

「なるほど」

「開発が始まってから、法務が『この表現はリスクがある』と言った。また変更。QAが触り始めたら『この動線だとユーザーが迷う』と言った。また変更」

一人が言いました。「誰も悪意があったわけじゃないんだな」

「そう。クライアントは良かれと思って言った。営業は顧客の声を届けようとした。PMは顧客を大事にしようとした。法務はリスクを防ごうとした。QAはユーザーのことを考えた。全員、自分の立場では正しいことをしていた」

「でも、結果として僕らは14回書き直している」

「そう。そして誰かが言うんだ。『なんでこんなにスケジュールが遅れるんだ？』って」

二人は、最初の仕様書と最終の仕様書を並べて見ていました。同じ機能とは思えないほど、違うものになっていました。

別の眼鏡

二人のエンジニアが、オフィスを歩いていました。

「鈴木さん、レビューが細かいって言われてるだろ」

「ああ。重箱の隅をつつくような指摘ばかりだ」

「鈴木さん、3年前に本番障害を出したことがある。レビューで見落とした箇所がバグの原因だった。あれ以来、細かくチェックするようになった」

「そうだったのか」

「山田さん、なかなかレビューしてくれないって言われてるだろ」

「ああ。いつも後回しにされる」

「山田さん、自分のタスクが遅れると詰められる。他人のレビューを優先しても評価されない。となると、まず自分のタスクを終わらせるのが合理的だ」

一人が言いました。「つまり、みんな自分の立場では正しいことをしている」

「そう。誰も悪くない。でも、全体としてはうまくいっていない」

---

ここで、もうひとつお願いがあります。

明日、職場で誰かの行動に「なんであの人は...」と思うことがあったら、少しだけ立ち止まってみてほしいのです。

その人の立場に立ってみる。その人が見ている景色を想像してみる。その人が過去に経験したことを考えてみる。

すると、その行動が「合理的」に見えてくることがあります。

これは、その行動を正当化することではありません。良い・悪いの判断とは別の話です。

ただ、「なぜそうするのか」が見えると、「どうすれば変わるのか」も見えてくることがあるのです。

正論の限界

二人のエンジニアが、会議室から出てきました。

「さっきの、言いすぎたかな」

「何を言ったんだ」

「このままだとスケジュールが破綻するって。見積もりにバッファを積みすぎだって。もっと現実的な数字を出すべきだって」

「で、どうなった」

「マネージャーが黙った。その後、『リスク管理の観点から現状の方針を維持する』って言われた」

もう一人は黙っていました。

「間違ったこと言ったかな」

「間違ってはいないと思う。でも、正しいことを言っても、変わらないことがある」

「なんでだ」

「マネージャーの立場で考えてみてよ。見積もりを減らして、もし遅延したら、責任を取るのは誰だ」

「マネージャーだろうな」

「そう。君の正論は、マネージャーにとっては『リスクを取れ』という要求に聞こえたんだ。しかも、みんなの前で」

一人は黙りました。

「正論って、相手を追い詰めることがあるんだ。特に、その人が変えられない構造の中にいるときや、変えたくても変え方がわからないときは」

「じゃあ、黙ってろってことか」

「そうじゃない。言い方と、言う場所と、言うタイミングがあるってこと。あと、相手が何を恐れているのかを理解してから言うこと」

一人が言いました。「難しいな」

「うん。僕も何度も失敗した。正しいことを言っているのに、なぜか関係が悪くなる。そういう経験、何度もある」

二人は廊下を歩きながら、さっきの会議のことを考えていました。

同じ人間

二人のエンジニアが、会社の廊下を歩いていました。

「子供の頃さ」と一人が言いました。「大人って、自分とは全然違う生き物だと思ってた」

「わかる」

「完成された存在というか。迷わないし、間違えないし、何でも知ってると思ってた。宿題を忘れたりしないし、朝寝坊もしないし、泣いたりもしないと思ってた」

「僕もそうだった」

「いつからだろう。大人も自分と同じだって気づいたのは」

もう一人は少し考えてから言いました。
「社会人になっても、しばらくは同じだった。部長とか役員とか、自分とは違う完璧な存在だと思ってた。迷わず決断できて、全体が見えていて、正解を知っている人たちだと」

「今は？」

「今は、同じ人間だってわかる」

一人が言いました。「どういうこと？」

「上の人も迷うんだ。間違える。知らないことだらけだ。夜中に不安で眠れないこともあるし、自分の判断が正しかったのか何年も気にしていることもある。部下に厳しいことを言った後、家に帰って後悔していることもある」

「そうか」

「僕らと同じなんだ。ただ、立場が違うだけで。見えている景色が違うだけで。抱えている責任が違うだけで。でも、中身は同じ。不完全で、迷っていて、自分なりに必死にやっている人間だ」

一人は黙って歩いていました。

やがて言いました。
「そう思うと、ちょっと楽になるな」

「うん。僕は長いこと、自分にできないことを他人に求めていたんだと思う。完璧であることを。全部わかっていることを。間違えないことを。でも、それは自分にもできないことだ」

「自分にできないことを、他人に求めてはいけない」

「そう。上の人も、隣の人も、過去にこのコードを書いた人も、みんな自分と同じ不完全な人間なんだ。それぞれの立場で、それぞれの制約の中で、それぞれなりに必死にやっていた。それだけのことなんだ」

二人は廊下の窓から、夕暮れのオフィス街を見ていました。

どのビルにも、同じように不完全な人間たちがいて、同じように必死にやっているのだと思うと、少しだけ景色が違って見えました。

誰が悪いのか

二人のエンジニアが、屋上でコーヒーを飲んでいました。

「結局、誰が悪いんだ」

「誰も悪くないんだと思う」

「それは無責任じゃないか？ 誰かが責任を取らないと」

もう一人はコーヒーを一口飲みました。
「責任を取るって、どういうこと？」

「犯人を見つけて、罰するってことだろ」

「それで何か変わる？」

一人は黙りました。

もう一人が続けました。
「犯人を見つけて、罰したとする。その人がいなくなっても、構造は残る。同じ構造の中で、別の誰かが同じことをする。また犯人を見つけて、罰する。何度でも繰り返す」

「じゃあ、どうすればいいんだ」

「構造を見るんだ。なぜその行動が合理的になっているのか。何がその行動を促しているのか。そこを変えないと、何も変わらない」

一人が言いました。「でも、構造を変えるのは難しいだろ」

「うん。難しい。時間もかかる。だから、まずは別のことを考えてみてほしい」

「何を？」

「この構造の中で、自分に何ができるか」

前提という視点

二人のエンジニアが、例のレガシーコードに戻ってきました。

「結局、このコードはどうするんだ」

「リファクタリングするよ。少しずつ」

「でも、四半期目標があるだろ。評価されないだろ」

「うん。されない」

「なのにやるのか」

もう一人は画面を見つめたまま言いました。
「評価制度は、僕には変えられない。四半期目標も、僕には変えられない。チームの人数も、過去の経緯も、このコードが存在する事実も、僕には変えられない」

「じゃあ、諦めるのか」

「諦めるんじゃない。前提として受け入れるんだ」

一人は黙りました。

もう一人が続けました。
「変えられないものに怒っていても、何も変わらない。エネルギーを消耗するだけだ。でも、変えられないものを前提として受け入れると、別のことが見えてくる」

「何が？」

「この前提の中で、自分に何ができるか」

一人が言いました。「それは、現状を諦めて受け入れろってことか」

「違う。変えたいなら、変える努力をすればいい。でも、変わるまでの間も、僕らは仕事をしなければならない。その間、不満を抱えて消耗するか、前提として受け入れて前に進むか。選ぶのは自分だ」

---

ここで、最後のお願いがあります。

これは「我慢しろ」という話ではありません。「文句を言うな」という話でもありません。

ただ、変えられるものと変えられないものを区別することは、とても大事なことだと思うのです。

変えられないものに怒り続けることは、自分を消耗させるだけです。

変えられるものに集中することは、実際に何かを変える可能性を開きます。

そして、変えられるものの中で最も確実なのは、自分自身です。

4つの問い

二人のエンジニアが、帰り道を歩いていました。

「今日話したこと、どうやって覚えておけばいいかな」

もう一人は少し考えてから言いました。
「4つの問いがあるんだ。僕はいつも、この4つを自分に問いかけている」

「教えてくれよ」

---

「最初の問いは、『この行動を合理的にしているのは、何か？』」

「誰かの行動に『なんでそんなことを』と思ったとき、その人の立場、見えている情報、評価される基準、過去の経験を考えてみる。すると、その行動が合理的に見えてくることがある」

---

「2つ目の問いは、『この構造が続くと、最終的にどうなるか？』」

「目の前の不合理を『仕方ない』で済ませない。このまま続くとどうなるか、想像してみる。会議が増え続けたら？ バッファが積み上がり続けたら？ 未来を想像することで、今何かを変えなければという気持ちが生まれる」

---

「3つ目の問いは、『これは前提か、変えられるものか？』」

「目の前の不合理は、自分に変えられるものか。変えられないなら、前提として受け入れる。変えられるなら、変えるために動く。この区別ができるだけで、無駄な消耗が減る」

---

「4つ目の問いは、『この前提の中で、自分に何ができるか？』」

「前提を受け入れた上で、自分の行動に目を向ける。構造は変えられなくても、自分の行動は選べる。その小さな選択の積み重ねが、やがて周囲にも影響を与えていく」

---

一人が言いました。「覚えておくよ」

もう一人はうなずきました。
「僕も、いつも忘れそうになる。だから、何度でも思い出すんだ」

二人はしばらく黙って歩いていました。

「今日話してくれたこと」と一人が言いました。「いつからそう考えるようになったんだ」

もう一人は少し間を置いてから答えました。
「いつだろう。気づいたら、かな。でも、もっと早く気づきたかった」

「どういうこと？」

「昔の僕は、ずっと怒ってたんだ。なんでこの人は。なんでこの会社は。なんでこのコードは。毎日そればかり考えて、毎日消耗してた」

「今は違う？」

「今も怒ることはあるよ。でも、構造が見えるようになって、少し楽になった。あの頃の自分がこのことを知っていたら、あんなに消耗しなくて済んだのにって、今でも思う」

一人が言いました。「過去の自分に教えてやりたかった？」

「うん。だから、君に話したのかもしれない」

終わりに

冒頭の二人のエンジニアを、覚えているでしょうか。

二人は、同じレガシーコードを見ていました。

「ひどいな」と一人が言いました。「誰が書いたんだ、これ」

もう一人は、コードの向こうに別のものを見ていました。4年前の、2人だけのチーム。3ヶ月という締め切り。その中で必死に書かれたコード。そして、4年後の自分たちも、きっと同じように言われるという未来。

二人が見ていたのは、同じコードでした。
でも、見えていたものは、違っていました。

---

明日、職場で「なんでこんなことを...」と思う瞬間が来るでしょう。

そのとき、少しだけ立ち止まってみてほしいのです。

同じものを見ていても、見えているものは違うのかもしれません。

誰も悪くないのに、悪い結果が生まれているのかもしれません。

そして、その構造の中で、自分に何ができるかを考えてみてください。

変えられるのは、自分だけです。

この世界で何を見るか、それは自分で選べるのです。