トラブルは自分のせい？私が「人」ではなく「事象」を見るようにしている話

世の中的には、仕事は自責で考えた方がいいという人もいっぱいいますよね。

トラブルがあったらそれは自分の責任だと捉える。だから別に悪い考えではないかなという気はするんです。

ただ、それに苛まれて身動きが取れなくなるとか、本当に頭が痛くなるとかっていうのは、ちょっとやりすぎかなと思っています。

この手の話で私がすごく好きな例え話があって、90年代のガンダムWという作品の中に、責任感が強すぎる登場人物が出てくるんですね。

その人を仲間が揶揄して、「あいつは、宇宙に空気がないのは僕の努力が足りないせいだって言い出すぞ」というセリフがあるんです。

何でもかんでも自分の責任だと言い出すと、宇宙に空気がないことまで自分のせいにしてしまう。あいつは考えすぎだよな、という話なんですけど、自責が行きすぎるとこれに近くなるなと思うんですよ。

トラブルや遅延があったとき、確かにどうしておけば回避できたか、という方法はなきにしもあらずだと思います。

でも全部を自分が悪いと言うのではなくて、ちゃんと原因が何なのかを考えなきゃいけないんじゃないかなと思うんです。

結果的に自分が単に悪いというわけではなくて、ここにも原因があった、これは自分で回避できたのかできなかったのか。そういうことをちゃんと切り分けておかないと、ただ全部自分が責任を負えばいいのだ、という方に行ってしまう。

それはそれで、あんまり良くはないかなという気がします。

大事なのは原因が何なのかということで、それに対して改善策を生み出せるか。もっと言えば、言語化して次の自分が見返せる状態にしておけるか、なんじゃないかと思うんですよね。

何でも悪いんだ、で終わったり、悪かったから次は頑張ろう、で終わっていると、結局何も改善しないままになってしまいますから。

この手の話でいうと、私がうまいこと言うなと思っている言葉があって、「勝ちに不思議の勝ちあり、負けに不思議の負けなし」というものです。

これは野球監督の野村克也さんが座右の銘にしていたことで知られるようになったらしいんですけど、勝ちにはラッキーもあるけれど、負けた時には必ず原因があるんだ、という意味なんですね。

トラブルや遅延が起きた時も同じで、なんでそうなったんだろうということは、罪の意識とは別で、ちゃんと解きほぐしていった方がいいんじゃないかなと思います。

たとえばドキュメントの書き方が悪かったとか、指示が読みづらかったとか。確定した日付が言えていなくて、なんとなく月末ぐらい、で収まっちゃっていたとか。

なんとなく曖昧な思考だったのか、デジタルのように1か0かでちゃんとわかる内容で言えていたのか。そういうところを見ていくといいと思うんです。

ここで気をつけてほしいのは、別に誰かを悪者にしたいわけではない、ということです。

ただ、起こった事象自体は、ディレクターとしては次には起こらないようにしておかないといけないわけですよ。その積み重ねが、修練だったり老獪なスキルになってきたりするので。

なので、なんでそれが起こったのかという事象そのものにはフォーカスした方がいいと思っています。

ドキュメントを書いたけど見てなかった、伝えたけど忘れてた。そういうことは実際に起こります。人だからこそのミスもあるわけです。

それが起こってもなんとか運用が回るところに持っていくのが、私たちディレクターの仕事だと思っているんですね。

ただ難しいのは、トラブルの原因って、ほとんどが人に紐づくことなんです。だから「これが遅れた理由は何ですか」という話が、「なぜあなたは遅れたんですか」と一対になりがちなんですよね。

そこだけは気をつけないと、人をすごく追い込んでしまうことになる。だから私は、「なんで遅れたのかな、何が原因でした？」と、できるだけ事象にフォーカスするようにしているという感じです。

もう一通、サーバーサイドエンジニアの方から「保守や調整が中心で、成長している実感がない」というお便りもいただいていて、これも近い話だなと思いました。

言わんとすることはわかります。クリエイターなら新しいことをしたいし、ずっとルーティーンばかりだと成長してない気がしてしまいますよね。

ここで私が思うのは、成長には2つあるということです。今までできなかったことができるようになること。それと、今までやってきたことの練度が上がって、ミスなく早くできるようになること。この2つですね。

昇給は練度が上がってもできると思いますが、昇進を目指すなら、今までできなかったことができるようにならないと難しいと思います。

ただ、練度だけだと給料の上がり幅にはどこかでアッパーが来るので、新しいスキルを身につけないと、最終的な大きな評価は得づらいなと私はずっと思って仕事をしてきました。

じゃあ保守で毎年同じことをやっているなら、その「同じことをやる」こと自体を、生成AIなどを使ってツール化していけばいいと思うんですよ。

実際、私はこの2〜3か月で20個ぐらいアプリを作ったんですけど、あれは生成AIをどう使うかの練習のためにやっていたところがちゃんとあったんです。

最初はちょっとめんどくさい手間が便利になるみたいな小さいものから始めて、だんだんWebサイトを作ったり、最後はフルスクラッチでアプリを作るところまでいきました。

だから既存システムの保守や調整も、今の技術を使ってよりベターにならないか、コストが安くならないか、人のミスが減らせないか、という視点で見直せると思うんです。

ただ、これは評価する人へのプレゼンを間違えると、「自分のノウハウで手を抜いてる」と誤解されかねないので、何のためにやっているのかは伝え方をパラダイムシフトしておかないとまずいかもしれません。

それでも理解してくれない人が上にいるなら、さっさと転職したらいいと思いますし、だからなおさら、保守という題材を使って自分のスキルアップの仕組みを作っていくのがいいんじゃないかなと私は思っています。

まとめ

トラブルや遅延が起きたとき、自分を責めきってしまう気持ちはよくわかります。でも今の私は、責めるのは人でも自分でもなく「事象」だと考えていて、そこにフォーカスした方が結果的に前に進めると思っています。保守や運用の日々も、見方を変えれば十分に成長の題材になりますからね。

• 自責で考えるのは悪くないが、身動きが取れなくなるのはやりすぎ
• 大事なのは原因を切り分けて、言語化し、次に見返せる状態にすること
• 責めるべきは人ではなく事象。原因が人に紐づきやすいからこそ気をつける
• 成長には「新しくできること」と「練度が上がること」の2つがあり、保守も自動化の題材にできる