私は52歳の現役ITエンジニアとして長年現場で働いてきましたが、会議での一言が若手のやる気を一瞬で消してしまう場面を何度も見てきました。『Dr.STONE』第3話での司と千空の対立は、アニメの話にとどまらず、実際の職場で起きるリーダーのあり方の違いにも重なって見えます。

この記事では、私自身の後悔経験も交えながら、若手の光を消さない組織にするために大切なことを具体的にまとめます。チームリーダーや若手の育成に悩んでいる方のヒントになればうれしいです。

関連：
原因不明の不具合調査を進める3つの考え方｜開発現場とDr.STONE第2話の試行錯誤から

会社組織に潜む「司が憎んだ大人たち」

司は「石化した大人たち」を次々と破壊しながら「純粋な若者だけの世界」を目指します。彼が憎んだのは、「自分は動かず」「勉強もせず」「ただポジションという既得権益にしがみつく大人たち」。

実際のところ、会社組織という場所に長く身を置いていると、司が抱いたような憎しみを抱く若者の気持ちはよく分かります。

失敗したら誰が責任を取るんだ

私が40代の頃、若手エンジニアが目を輝かせ、声を少し上ずらせながら新しい開発言語を提案した場面を今でも鮮明に覚えています。会議室の空気は一瞬で張りつめ、ベテランたちの視線が冷たく集中し、微かなため息が聞こえるほどの重い沈黙が落ちました。

上司が低く抑えた声で「今さら変える必要はない。前例がないものを導入して、もし失敗したら誰が責任を取るんだ」と一蹴した瞬間、部屋全体の温度が明らかに下がり、重苦しい空気が一気に広がりました。

提案した若手の表情が、明るく弾んでいたものが一瞬で凍りつき、瞳から光が消え、肩ががっくり落ち、唇を強く噛んでうつむく姿……。その場にいた私は背中に冷や汗が伝うのを感じ、喉が乾くのを自覚しながら席に座ったまま何も言えませんでした。

あのような上司にはなりたくない

「前例がないから」という淀んだ空気が、誰も異を唱えられない壁となって全員を飲み込む。あの無力感と、会議が終わった後に込み上げてきた深い後悔は、今でも胸の奥に重く沈んで離れません。

この「論理 vs 空気」の構造こそが、組織の病理の根深い部分だと今でも強く思います。

司が憎んだ「動かない大人たち」の姿は、まさにこうした組織の延長線上にあり、現実の職場でも痛いほど見えてしまいます。

「私はあのような上司にはなりたくない」。

これまでそう思いながら働いてきた私にとって、司の過激な行動は、社会の不条理に対する一つの極端な回答のようにも映りました。

「元の世界」を信じ切れる千空の強さ

一方で千空は「全人類を救う」と断言し、石化前の文明を完全に復元しようとします。科学への絶対的な信頼があるからこそ、過去を否定せずに「元の世界」を取り戻そうとするのです。

対して司は、元の世界では「どうにもならない」と諦めたからこそ、世界そのものを変えようとしました。

古いシステムに良くある選択

エンジニアの世界でも、古いシステムを「延命させる」か「一から作り直す」かという選択は常にあります。

私が実際に経験したのは、約11年前に担当した大手製造業向けの生産管理システムの移行プロジェクトです。当時、周囲の多くは「このスパゲティコードはもう限界。一からJavaで作り直した方が早い」と主張していました。

しかし私は「このコードの中には、先人たちが30年以上かけて積み上げてきた業務ルールが詰まっている」と信じ、泥臭くコードを解析し、ドキュメント化を進めました。結果、既存資産の約70%を活かした形で移行を完了。

完全新規構築案に比べて初期コストを抑えられただけでなく、移行後の運用安定性も高く、現場から「このまま使えて助かった」という声が多数上がりました。

既存資産をどう使うかが鍵

この経験から、千空の「元の世界を信じ切る強さ」は、エンジニアとして「既存資産を活かしながら丁寧に積み上げる姿勢」と重なる部分が大きいと感じます。

過去の資産を否定せず、長期的な価値を見据える視点こそが、本当の強さなのだと思います。

「論理」は、感情よりも気楽である

司のようなカリスマ的なパワープレイのリーダーと、千空のような徹底した論理性を持つリーダー。私がどちらと一緒にいて「気楽」かと問われれば、迷わず千空を選びます。

例えば、私が30代の頃に関わった大手流通企業向けの在庫管理システム更新プロジェクトでは、感情的な叱責が多い上司の下で作業した時期がありました。

疲労感のある現場

ある日、急な仕様変更が発生したのですが、上司は「とにかく早く直せ」と理由も共有せずに怒鳴り、チームは理由が分からないまま夜遅くまで修正に追われました。現場は常にピリピリした空気で、メンバーのモチベーションが明らかに低下していました。

その後、論理的にタスクを分解して説明するタイプのリーダーのプロジェクトに移ったとき、同じ忙しさでも精神的な疲労がまったく違うと感じました。

疲労感がない現場

違いを振り返ると、前者は「なぜ変えるのか」が見えず、後者は「何を、いつまでに、どの順番でやるのか」が先に示されていました。忙しさそのものより、先が読めるかどうかで疲労感は大きく変わります。

私はこの経験から、現場が安心して動けるかどうかは、優しさよりもまず説明の筋道で決まると、52歳になった今でも強く思っています。論理的なリーダーの下では、若手も意見を出しやすくなり、結果としてチーム全体の生産性も上がるのです。

もし「不要な大人」と言われたら

もし司の目の前で「君のような大人は新世界にはいらない」と言われたらどうするか。

笑って隠居を選択する理由

私が言われたとしたら「確かにそうかもね」と笑って、大人たちだけの小さなコミュニティで、のんびり隠居することを選択するでしょう。

実際、数年前に若手エンジニアが中心になって「Kubernetesを活用したコンテナ環境」への全面移行プロジェクトが始まったとき、私は「このツールは分からないから任せるよ」と一歩引きました。若いメンバーの方が圧倒的に詳しかったからです。

ただ、全部を任せて終わりにしたわけではありません。

過去に私が経験した同じような環境移行で起きた「ネットワーク構成のミスによる2日間のサービス停止」や「データ移行時の不整合」などの失敗パターンを事前に共有し、若手が進めやすいように周辺の調整役に回りました。

世代によって変わる役割

結果としてプロジェクトは無事成功し、若手からは「先輩のアドバイスがなければ詰まっていたと思います」と言われました。

「世代によって役割は変わるのだな」と、その時に妙に納得した記憶があります。

新しい技術を先頭で触る役と、失敗しやすい場所を先回りして潰す役は別でいいのだと、その時に腹落ちしました。若者は若者で、理想の新世界をガンガン作っていけばいい。

それは余裕というよりも、その場の状況を客観的に見て「どう動くのが最も平穏か」を考える、エンジニア的な最適解の選択です。

まとめ｜若手を活かす組織は、空気ではなく論理で動く

若手を活かす組織と、潰してしまう組織の違いは、結局のところ「空気で決まるか、論理で決まるか」なのかもしれません。

技術の話でも仕事の進め方でも、提案がきちんと論理的に議論される場所では人は自然と成長していきます。逆に、前例や立場、空気だけで決まる職場では、新しい挑戦は生まれにくく、若手の芽が静かに摘まれ続けます。

私自身、あの会議室で若手の提案が一蹴された瞬間の無力感と、後悔を今でも鮮明に覚えています。

千空のように論理と手順で人を動かすリーダーの下で働く方が、現場はずっと気楽に動けると、私はこの回を見ながら改めて感じました。

私は今でもあのときの後悔を糧に、「空気」に流されず、少しでも論理を大切にできる大人であり続けたいと思っています。

『異世界放浪メシ』第4話では、主人公ムコーダがまさにそんな状況に直面します。風の女神ニンリルという「絶対的な存在」から、半ば強引にお供え物を要求されるのです。

この記事では、かつて納品先と自社メンバーの板挟みで頭を悩ませていた私の経験を交えながら、理不尽な要求にどう落とし所を見つけるべきか、当時の立ち回りを振り返ってみたいと思います。

無理な要求に振り回されそうな場面で、どう立ち回ればいいのかの参考になれば嬉しいです。

関連：組織で「過ぎた力」をどう扱うか｜スキルを持つほど牙を隠す理由（異世界放浪メシ第3話）

「絶対的な存在」との対等な着地点を探す

ムコーダに「お供え物」（現代のお菓子）を執拗に要求する女神ニンリル。逆らえない相手からの理不尽な要求は、会社員時代における「納品先の担当者」の言葉を彷彿とさせます。

私がいた現場では、納品先の担当者がそれに近い影響力を持つことがありました。「これ、追加して」「ここを修正して」という一言で、現場の苦労は一瞬で跳ね上がります。

私はかつて、その「神」のような担当者と自社の開発メンバーの板挟みになり、毎晩遅くまで調整のメールを書き直すような日々を送っていました。ここで私がただ「はい」と引き受めてしまえば、翌朝のメンバーたちの引きつった顔を見るのが目に見えていたのです。

正直に話し、相手の顔も立てる

そこで私が心がけていたのは、相手の意見を否定せずに一度すべて受け止めること。その上で、電話ではなくあえて対面で「実は今のリソースだとメンバーがパンクしてしまうんです」と、こちらの台所事情を正直に打ち明けながらメリット・デメリットを話し合うことでした。

「今回は無理でも、次にはこうした形で期待に応えたい」 など、相手の顔を立てつつ、自社にとっても有利な着地点を見つける。決して相手をないがしろにせず、誠実に、かつ戦略的に「納得感」を醸成する。

ムコーダがお菓子を差し出して女神の機嫌を取りつつ、ちゃっかり「神の加護」を引き出したように、交渉では、こういう“落とし所探し”が効く場面が多いと思います。

「神の加護」に代わる、大人の可愛げという後ろ盾

ムコーダが手に入れた「神の加護」は、異世界で生きる上でとても心強いパートナーでしょう。

私自身、勿論神からの加護など持っていませんが、振り返れば、これまで「年上の方々からの厚意」という大きな後ろ盾に助けられてきたことも多かったと思います。

どうやら私は、どこか抜けていたり、世間知らずな一面があったりして、年上の方から見ると「面白いやつ」と映ることが多いようです。

例えば、専門用語を派手に勘違いして話し続け、飲み会の席で「意味が全然違ってたけど、なんとなく分かったから黙ってたよ」など、先輩方を大いに笑わせたことも一度や二度ではありません。

「あいつなら仕方ないな」と笑って許してもらえること。一見、スキルの低さに見えるかもしれませんが、私自身はそれを、当時の職場で助けられた一種の“立ち回り”だったと思っています。

完璧すぎる人間よりも少し隙がある人間の方が、いざという時に手を差し伸べてもらえる。そんな「可愛げ」という名の加護が、私を多くのピンチから救ってくれたのだと思います。

未知への恐怖を「感動」で塗り替える。AI時代の歩き方

フェルの背に乗って未知の領域を爆走するムコーダ。そのスピード感に驚き、翻弄されるその姿は、現代の「AIの進化」に直面している私の感覚に重なります。

私の中にも、正直なところ「このままAIに取り残されるのではないか」という不安はあります。世の中が具体的にどこへ向かっているのかが見えにくい時期は、どうしても足元がふわつく感覚を覚えます。

私の場合でいえば、そうした不安を薄めるのは、結局小さく手を動かすことでした。

好奇心を持ち使い倒す

実際にAIを使ってみると、ブログのプラグイン開発で何時間も悩んだ複雑なコードの不具合をわずか数秒で特定して修正してくれたりと、驚きを通り越して「感動」すら覚えます。

例えば、ブログのちょっとしたレイアウトの修正。これらもAIに相談してみると、自分では思いつかなかったスマートなCSSの書き方を提示してくれて驚くことがあります。

日常の小さな作業でも、まずは試してみる。
そうすることで、手戻りの時間も大きく減るようになりました。

不安を解消するために、

• とにかく使い倒して実感として身につける。
• AIの進化に遅れを取らないよう、好奇心を持って並走し続ける。

今のところ、それがバランスを保つ一つの方法だと私は考えています。

「ワクワク」と「恐怖」は、常にセット。52歳の今、ムコーダのように新しい世界のスピードを楽しみながら、AIという最強のパートナーと共に、まだ見ぬ景色を見に行きたいと思っています。

まとめ

神という巨大な存在を相手に、ムコーダは「お菓子」という身近なツールで、最強のバックアップを手に入れました。理不尽に見える状況も、見方を変えれば大きなチャンスになり得ます。

実際、会社員時代を振り返ってみても、最初は無理だと思えた要求が、交渉や工夫を重ねることで結果的にプロジェクトを前進させた場面が何度もありました。

理不尽な要求に直面したとき、ただ従うか拒否するかの二択ではなく、相手の立場も考えながら「どこに着地点を作るか」を探すこと。

そうした視点を忘れずに、厳しい状況でも楽しみながら、私はこれからも自分の仕事を前に進めていきたいと思っています。

『異世界放浪メシ』第3話で描かれるのは、まさにそんな「過ぎた力」の扱い方。

伝説の魔獣フェルを従え、国境を越えようとするムコーダ。しかし、その圧倒的な存在感は、平穏を望む彼にとってトラブルの種でもあります。

この記事では、このエピソードをきっかけに、組織での「実力の見せ方」や大人の立ち回りについて考えてみます。

かつて会社員時代に「早く上に行け」と言われながらも役職を拒み、あえて一歩引いた場所で自分を抑えていた私の経験も、少し振り返ってみたいと思います。

関連：規格外の力についてはこちら
規格外の力とどう向き合うか｜異世界放浪メシ第2話に見る「ツールが変える人生」

おだてられて木に登らないための「理性」というブレーキ

ムコーダはフェルに対し、「威圧感を抑えろ」と厳命します。これは、自分の持つ力が周囲にどう映るかを客観視できているからこその判断です。

翻って自分自身のことを考えてみます。実を言うと私は「おだてられたら木に登る」という言葉がぴったりの性格です。人からスキルや実績を褒められると、つい嬉しくなって調子に乗ってしまう… そんな青臭い一面が今、この歳になってもどこかにあります。

おだてられると調子に乗る悪い癖

例えば、システムの複雑なバグや仕様の不具合を鮮やかに解決して「さすがですね！」と褒められると、つい嬉しくなってしまいます。

聞かれてもないのに、そのコードがいかに合理的で美しいかをホワイトボードに書き殴りながら熱弁してしまい、後になって「少し出過ぎたかな」「自慢話に聞こえたかな」と反省することも何度もありました。

周りからは「また始まったよ」など思われていたかもしれませんね。

その「高揚感」のままに振る舞えば、周囲からは自慢げに見え、不要な反発や嫉妬を招くことになりかねません。だからこそ、年齢を重ねるごとに私は「口を開く前に一度考える」という習慣を意識的に身につけてきたという訳です。

プロとして中立を保つためにとった行動

特に会社という組織においては、感情に流されず、客観的なデータや仕様の整合性といった「正論」をベースに話すよう意識してきました。

例えば、会議でメンバーが「この機能は絶対にウケます！」と熱く盛り上がっているときほど、私はあえて一歩引き、「開発コストと納期への影響は検証したか」と冷静な数字を突きつけるような役割を引き受けていたのです。

その結果、周囲からは「冷静すぎる」「少し冷たい」といった印象を持たれることもあったようですが、それは勿論、冷淡さゆえではありません。

自分の「おだてに乗りやすい性質」にブレーキをかけ、プロとして中立を保つための、私なりの防衛策だったのです。

昇進という「キャパシティオーバー」の資源に抗う

ムコーダはフェルが狩ってきた山のような高級獲物を見て、喜ぶどころか「自分には扱いきれないリスクだ」と困惑します。これと同じような、想定外の「大きな資源（権限）」に対する戸惑いを、私は自分の昇進の時に経験しました。

昇進を拒んでいたあの頃

メーカーに勤めていた頃、「室長」という役職への打診がありました。一般的な会社で言えば、課長と部長の中間くらいのポジションです。上司は「早く上に行け」と背中を押してくれましたが、当時の私は猛烈にそれを拒みました。

「自分はそんなガラではないし、もっと現場の近くで技術に触れていたい」

そうした思いが強すぎて、数年間にわたって昇進を辞退し続けました。

周囲に相談しても「チャンスなのだから早く受けるべきだ」というアドバイスが大半でしたが、私には、その新しい権限が「自分の本質を損なう、手に余るもの」のように思えてならなかったのです。

飛びつかなかったからこそ得られたもの

結局は多くの人の話を聞くうちに「それも一つの道か」と受け入れることになりました。

しかし、あの時の「自分に扱いきれるか？」という冷静な自問自答は、今でも間違っていなかったと感じています。

手放しで飛びつかなかったからこそ、役職に就いた後も「自分の本分は技術と現場にある」という軸がブレず、過度なプレッシャーに潰されずに役割を全うできたのだと思うからです。

大きな力やチャンスが舞い込んだ時、手放しで喜ぶのではなく、まず自分の器と照らし合わせる。それは、エンジニアとして「システムにどこまで負荷をかけても安定して動き続けるかを見極める」感覚に似ているのかもしれません。

専門家（ギルド）への信頼と「依存しない」距離感

自分では効率の悪い魔物の解体を、ムコーダはギルドの専門家に任せます。これは「限られた時間」と「リソース」を最大化するための、正しいアウトソーシングの形です。

仕事において、相手が信頼に足るプロかどうかを見極めるのは非常に難しいもの。結局のところ、返ってくる「アウトプット」で判断するしかありません。

でも、私が真のプロだと感じる人たちには共通点があります。

それは、自分の役割に誇りを持ち、「その役割を全うするのが当たり前だ」という姿勢で仕事に向き合っていること。

プロは限界まで負荷を背負い合う

幸いにも、これまでのキャリアで何人かのそうしたプロフェッショナルに出会うことができました。彼らと良好な関係を築くために、私が最も大切にしているのは「依存しないこと」です。

プロ同士の仕事では、どちらかが甘える関係になると歪みが出やすいと感じています。

例えば開発の現場でいえば、UIやデザインのプロが「ユーザーの使いやすさのために、この複雑な画面表示をどうしても実現したい」と1ミリも妥協せずに要求してくる。

それに対して、バックエンドを担う私が「それなら、どれだけデータが重くなろうが数秒で処理できる、絶対に落ちない堅牢な土台を組んでやろう」と意地とロジックで応える。

お互いに相手の「最高の仕事」を引き出すために、自分の領域で限界まで負荷を背負い合う。

この協力の枠組みの中で、お互いに一切の妥協を許さないプロ同士の攻防があるからこそ、一人では絶対に作れない最高のシステムが生まれるし、健全な緊張感と深い充実感が宿るのです。

あえて「一歩引く」ことが、平穏を守る知恵になる

伝説の魔獣フェルであっても、街に入る時はその威圧感を消さなければなりません。私たちも、どんなに高いスキルや経験を持っていたとしても、それを振りかざすのではなく、環境に合わせてあえて「一歩引く」謙虚さが必要な場面があります。

それは決して自分を偽ることではなく、周囲との調和を図りながら、結果として自分のやりたい仕事をスムーズに進めるための、大人の「立ち回り」なのだと思います。

実際、私も会社員時代、設計の打ち合わせなどで若手メンバーが「新しいこの手法を試したい」と熱弁しているとき、自分の経験から見ればリスクがあると分かっていても、頭ごなしに「それはダメだ」と実績を振りかざすようなことはしませんでした。

一歩引くことで生まれる信頼関係

まずは「その視点は面白いね、一度やってみよう」と相手の意見を立てて、一歩引く。

そうして相手に花を持たせ、信頼関係を築いておくからこそ、後になって「ただし、システムの根幹に関わるこの部分だけは、過去のトラブル事例を踏まえて私のやり方で固めさせてほしい」と切り出しても、「あの人がそこまで言うなら」と、本当に譲れない部分の提案をすんなり受け入れてもらえたのです。

組織の中で長く仕事を続けていると、こうして「自分の力をどう抑えて見せるか」が、結果的に仕事の進み方そのものを左右する場面を何度も経験します。

ムコーダがフェルという巨大な力に振り回されながらも、なんとか自分らしい旅を続けようとする姿。そこには、組織や人脈という「自分より大きなもの」の中で生きる私たちが学ぶべき、しなやかな強さが隠されている気がしてなりません。

まとめ

力があること自体は悪いことではありませんが、組織の中では、その見せ方や使い方まで含めて問われるのだと思います。

• 自分の限界を知ること。
• 必要な場面では人に任せること。
• そして、力を振りかざすのではなく、周囲との調和の中で使うこと。

ムコーダの振る舞いを見ていると、そうした大人の立ち回り方を深く考えさせられます。

組織の中で力を持つほど、あえて「一歩引く」姿勢を持つことが、自分と周囲の平穏を守る知恵になるのかもしれません。

私はITエンジニアとして、外注スタッフ中心の小さな運用チームを任されたことがあります。「指示を出さないと動かない」「問題が起きても誰も判断しない」、そんな完全に停滞した現場でした。

その重苦しい空気を思い出したのが、
『転生したらスライムだった件』第2話のゴブリン村の場面です。

この記事では、私が実際にそのチームを変えていった経験をもとに、指示待ち集団を動かすための3つの実践的なヒントをまとめます。チームをまとめる立場の方や、現場の空気を変えたいと思っている方の参考になれば幸いです。

関連）
会社合併で気づいた「組織OS」の違い｜エンジニアが転スラ第1話から学んだAI時代の働き方

指示待ち集団に「思考の種」を蒔く戦略

私も以前、外注スタッフが中心の「弱小チーム」のリーダーを任されたことがあります。当時はIT関連の小規模な運用案件で、進行管理と調整を担当していました。

当時のチームメンバーは「指示を待つだけ」で、自発的に動くことはありませんでした。また何か問題が起きても「何をすればいいか分かりません」という、まさにゴブリン村のような停滞した状態だったと思います。

そうした状況を変えようと、まず私が着手したのは、彼らが自分の考えを言葉にする機会を作ることでした。具体的には毎日1時間のミーティングを設け、徹底的に問いかけを繰り返しました。

• 「この状況をどう思うか？」
• 「この作業で一番時間がかかっているのはどこだと思う？」
• 「もし自分が責任者なら、どこを直す？」

そんな問いを投げても、最初の数日はほとんど沈黙でした。会議室の空気も重く、

「どうせ自分の意見なんて．．．」
「余計なことを言うと怒られるのでは．．．」

など、自信のなさというか、指示待ち感、警戒感が伝わってきたのを覚えています。

それでも続けるうちに、ある日ひとりがぽつりと「ここ、実は二重作業になってます」と言いました。そこからだと思います、少しずつ、メンバーの発言が増えていったを感じました。

この時の「やった！遂に意見を言ってくれた」といった感動は、今でも昨日のように覚えています。とにかく、何でも良いので「自分で考える」きっかけを作ることが最初の一歩だったんですね。

リムルがゴブリンたちに「戦う意思」を確認し自立を促したように、私も技術的な指示の前に「当事者意識」を育てることを最優先にしていました。

「役割のネーミング」で人が動き出す

また第一話でもありましたが、
第2話でも「名づけ」というのが大きなキーワードになってます。

リムルが名もなきゴブリンたちに「名前」を授けると、なんと彼らは劇的な進化（ランクアップ）を遂げます。でもこれ、よく考えればファンタジーの世界だけの話ではありません。

「地位が人を作る」という言葉があります。
経験上、役割を言葉にしたことで動きやすくなる場面というのがあるものです。

ITの現場でも、単に「メンバーの一人」として扱うのではなく、「この領域のスペシャリスト」や「品質の最終防衛ライン」といった立ち位置を明確に定義することがあります。

実際にそうした役割を言葉にしたとき、それまで遠慮がちだったメンバーが「ここは自分が確認します」と自然に動き始めたことがあります。

例えば、私はあるメンバーに「品質最終確認スペシャリスト」という役割を明確に与えました。それまでは「誰かがやるでしょ」という空気だったチェック作業を、彼が自ら主体的に進めるようになったのです。結果、チーム全体のミス率が目に見えて減りました。

名前や肩書きを付けることは、周囲に対する「この人はこういう役割である」という宣言であり、本人に対する「期待の表明」でもあります。

実際にこうしたネーミングを意識するようになってから、チームの自発的な動きが明らかに増えたと実感しています。役割を明確にすることは、組織を設計する上での重要な「設計図」だと、私は現場で学んできました。

対立を「巻き込み」に変えるマネジメント術

主人公のリムルは、村を襲撃した牙狼族（がろうぞく）のボスを倒した後、生き残った群れを排除せず、仲間として受け入れました。この「敵を味方に変える」姿勢は、実社会、特に納品先との関係構築においても意識することが多いと思います。

例えば、納品先の担当者が特定の画面仕様に強く固執し、プロジェクトが停滞する局面がありました。

そこで「やってください」「できません」と対立するのではなく、まず「なぜその仕様にこだわるのか」を丁寧に聞きました。すると、その担当者の上司から「絶対にセキュリティを強化せよ」という強いプレッシャーがあることがわかりました。

私は「できない」と突っぱねるのではなく、代替案として「この部分だけセキュリティを強化し、他の部分は簡略化する」案を資料にまとめ、担当者が上司を説得するための理論武装を一緒に作成しました。

結果、その案が採用され、プロジェクトは停滞から脱却。担当者からも「助かった」と感謝され、以後、難しい案件でも相談される関係になりました。

異なる文化のメンバーを「まず混ぜる」組織統合術

第2話では、異なる種族を1つにまとめ上げる話が描かれます。リムルは新しく仲間になった牙狼族をゴブリンとペアにさせ、一つの村として機能させました。これは、私が以前経験した「会社の合併」に伴う組織統合のプロセスと重なります。

合併後、片方の会社は「まず動いてみる」現場主導型、もう一方は「承認が下りるまで動かない」管理重視型という文化がぶつかり、大きな摩擦が生じました。

例えば、ある機能改修作業では、現場主導型のメンバーは「とにかく早く作ってみよう」と動き、管理重視型のメンバーは「承認が下りていない」と止まる、という対立が頻発していました。

そこで私が実践したのは「まず混ぜてみる」こと。

両社のメンバーを意図的に3〜4名ずつの混合小チームに分け、1週間単位の共同タスクを課しました。最初は衝突が激しかったですが、2週間後には「相手のやり方にはこういう利点がある」と互いの強みを認め合うようになりました。

結果として、統合後のチームの作業スピードが以前より約30％向上し、異なる文化を活かした提案も増えました。

今回のまとめ

弱いチームが動き出すとき、最初から劇的な変化が起きるわけではありません。

私の経験から、特に効果的だったのは次の3つです。

• 意見を言える空気を作ること
• 役割を言葉にして渡すこと
• 対立をそのままにせず、共通の目的に巻き込むこと

実際に私が指示待ちの外注チームを担当したときも、この3つを地道に繰り返した結果、3ヶ月後にはメンバーから自発的な改善提案が出るようになり、チームの生産性が明らかに向上しました。

転スラ第2話を見ていると、組織を動かすのは強さそのものではなく、「人が動ける状態をどう作るか」にあるのだと改めて思います。

あなたの現場でも、まずは「問いかける」「名前を付ける」「混ぜてみる」ことから始めてみてはいかがでしょうか。

転スラ第4話では、リムルが大きな功績を上げたはずなのに罠にはめられ、追放される展開が描かれます。

私もITエンジニアとして30年以上、組織の中で理不尽な評価や突然のプロジェクト中止を何度も経験してきています。

この記事では、そんな理不尽な状況で「何が残り、次のチャンスにつなげるか」を、私の現場経験をもとに具体的にまとめます。組織の壁にぶつかっている方のヒントになれば幸いです。

関連：
納期トラブルをどう切り抜ける？現場経験から学んだ「リソース確保と職人との信頼構築」｜転スラ第3話から考える

上司から「意味がない」と言われた新人時代の理不尽

新人時代の話ですが、私は市場動向を踏まえた分析を、グラフと説明で丁寧にまとめ、上司に提出したことがあります。重要なポイントは赤字で強調し、「この市場ニーズは今後3年で拡大が見込まれ、製品化すれば大きな差別化になります」と説明しました。

その資料をわずか10秒ほど見た上司から返ってきたのは、「その図は意味がない」という一言だけでした。理由の説明は一切なく、その図に興味を持った別の人に対しても、上司は「それは意味がないから」と追い打ちをかけるように繰り返しました。

今振り返れば、当時の私に足りなかったのは上司の意図を汲み取る力だったのかもしれません。

でもなぜ「意味がない」のかという論理的な説明がないまま下される評価は、ただ若手の芽を摘むだけの「理不尽」のように思えます。

この経験は、私のマネジメントスタイルに大きな影響を与えました。52歳になった今でも、部下の資料を見る際は必ず「なぜこの結論に至ったのか」を論理的に説明するよう心がけています。

「意味がない」で終わらせず、必ず理由を伝える。
これが、私が反面教師として得た最も大きな教訓です。

理不尽な評価の中でも「見てくれている人」は必ずいる

そんな理不尽な評価に晒される一方で、救いとなる「眼力」を持った人物との出会いもありました。それは会社に入る前の学生時代、所属クラブでの話です。

お調子者で軽く見られがちだった私に対し、クラブのリーダーは皆の前で「こいつなら、どんな会社に行っても絶対やっていける」と、1度だけでなく2度、はっきり断言してくれました。

当時、私はクラブのイベント告知チラシを担当していましたが、他のメンバーが「派手で目立つデザイン」にしようとする中、私は「ターゲット学生が本当に欲しい情報（開催日時・持ち物・得られるメリット）を一目でわかるように整理する」ことを重視していました。

リーダーはそのチラシの設計思想や、私が細かいところまでこだわる姿勢をじっくり観察してくれていたようです。

その言葉のおかげで、私は就職活動で「自分は物事を整理して伝えるのが得意」と自信を持ってアピールできるようになり、結果として第一志望のIT企業から内定を獲得できました。

リムルの器を見抜いたドワーフ王ガゼルのように、本質を見抜く力を持つ人は、リーダーとして最高の資質の一つだと思いますし、そうした一言は人を自然と動かす力を持っていると、私は52歳になった今でも強く実感しています。

プロジェクト中止（追放）から得た人間関係の資産

リムルはドワーフの国を追放されましたが、それを機に名工カイジンたちを自分の村へと連れ帰ります。私もかつて、心血を注いだ新規プロジェクトが採算性の問題で急遽中止になるという、ある種の「追放」を経験しました。

それはある金融機関向けの基幹システム刷新プロジェクトで、要件定義から設計まで約8ヶ月間、週6日ほぼ毎日夜遅くまでチームで取り組んでいました。中止が決まったときは非常にショックでしたが、そこで終わったわけではありませんでした。

発注先の担当者とは、プロジェクト期間中に何度も深夜まで仕様調整をした関係から、業界の裏話や他社の失敗事例を語り合う信頼関係が築けていました。中止決定後も、その担当者から「また一緒に仕事がしたい」と言われ、その後2件の別プロジェクトで再び一緒に仕事をする機会に恵まれました。

また、共に戦った部下たちからも「このプロジェクトで課長の判断力と粘り強さを見て、今まで以上に信頼できるようになりました」と、少し照れながらも言われるようになりました。

プロジェクトという「箱」は壊れても、そこで培われた「人間関係」という資産は、次のステージへ確実に持ち越すことができるのです。

理想と現実の狭間で選ぶ「優先順位」

この第4話では、カイジンは王への忠誠とリムルへの義理の狭間で、自らの道を選びました。しかし、現実の組織ではそう簡単にはいきません。

私が50歳のとき、大規模金融システムの刷新プロジェクトで、上層部が決めた「6ヶ月納期」に強く反対したことがあります。チームの負担が大きすぎると判断し、部長にデータ（想定工数と過去類似案件の失敗率）を示して直談判しましたが、最終的には「組織決定に従う」ことを選ばざるを得ませんでした。

そのとき優先したのは「家族の生活を守る安定」と「チーム崩壊を防ぐこと」。結果、プロジェクトは遅延しましたが、私は「できる限りの抵抗はした」という納得感を得ることができました。

仲間への義理を通したい、自分の信じる道を行きたいと願っても、生活基盤がある中で組織のルールを優先せざるを得ない瞬間はあります。それは「負け」ではなく、人生を成立させるための切実な選択です。

52歳の今、私はそうした局面で「ここだけは譲れない一線」を事前に明確にしておくことを心がけています。

理不尽を乗り越えて最高のチームを組んだとき

リムルがカイジン三兄弟という最強の技術者を揃えたように、私も初めて大規模プロジェクトのリーダーを任された際、約100名規模のチームをまとめることになりました。

「これは大変なことになりそうだ」と感じた私は、まずチームを6つのサブチームに分けました。そして最初に注力したのは「信頼できるサブリーダーの選定」でした。

これまでの仕事で特に印象に残っていた、納期が逼迫した状況でも冷静に優先順位をつけ、メンバー間の調整を上手くこなす3名のエンジニアには直接声をかけました。一方、残りの3名は「特定の技術領域に強いメンバー」をバランスよく選ぶようにしました。結果として、技術力と調整力のバランスが取れた布陣ができました。

全員が快諾してくれた瞬間、「これなら絶対にやりきれる」と確信しました。しかし実際には、要件定義の段階で上層部から突然の仕様変更が3回続き、予算も途中削減されるなど、想定外の困難が連続しました。

それでもサブリーダーたちがそれぞれの持ち場で優先順位を再調整し、チーム内で情報を透明に共有してくれたおかげで、最後までプロジェクトを完遂することができました。

理不尽な壁を、最強の仲間と共に一つずつ壊していく。その高揚感こそが、この仕事の最大の醍醐味だと、私は52歳になった今でも思っています。

今回のまとめ

ここまで、転スラ第4話から私が感じた「理不尽な評価を乗り越えるヒント」を、52歳現役エンジニアの視点でまとめると次の4つになります。

理不尽な評価や組織の壁にぶつかったときでも、「見てくれている人」が必ずどこかにいて、人間関係という資産は消えない。そして何より、信頼できる仲間と共に困難を乗り越える高揚感が、仕事の醍醐味だと改めて思いました。

あなたの現場でも、理不尽を感じたときに「次に何が残るか」を意識するきっかけになれば幸いです。

私はITエンジニアとして、会社合併によって組織文化が激変する経験をしました。そのときに感じた強い違和感と学びを鮮明に思い出させたのが、『転生したらスライムだった件』第1話です。

リムルがスライムとして異世界に適応していく姿は、AI時代に組織が変わったときの働き方や適応の仕方に重なります。

この記事では、会社合併を実際に経験した52歳エンジニアの視点から、「AI活用」「組織適応」「交渉力」の3つの実践的なヒントを整理します。環境が変わったときにどう動くべきか、具体的な対応策として参考にしていただければ幸いです。

関連：
理不尽な評価はどう乗り越える？実体験から考える「組織の壁」と信頼できる布陣づくり

現代に現れた「大賢者」という名のAI

スライムに転生した主人公、後に「リムル」の名で活躍しますが、その彼を影から支え、あらゆる問いに答えてくれるのがユニークスキル「大賢者」。

異世界のファンタジーだと思って見ていたこの存在が、今や私たちの現実にも現れています。そう、GeminiやChatGPTといった生成AIです。

私たちは今、全人類が「大賢者」をインストールできる時代に突入しています。分からないことを瞬時に解析し、プログラミングのコードを書き、新しい視点を提供してくれる。これほど羨ましいスキルが、指先一つで使えるようになったのです。

ただし、この強力なスキルも、使わなければ宝の持ち腐れ。

大賢者のアドバイスを使いこなすリムルと、ただのスライムのまま終わる者。少なくとも私の周囲では、「AIを使うかどうか」で体感の差として表れてきているように感じます。

私はこの「現実世界の大賢者」と対話を続け、自分の思考を広げる道具として使いながら、その進化に遅れを取らないようにしたいと考えています。

私自身、最近はAIを次の3つの用途で使うことが増えました。

• 新しい技術の概要を短時間で整理する
• 文章や資料の構成を考える
• 議論の別視点を出してもらう

特に52歳になってからは、コードレビュー時に「この設計の潜在的なリスクは何か」をAIに聞く使い方を増やしています。自分の経験だけでは見落としがちな視点をもらえるので、重宝しています。

「大賢者」のように万能ではありませんが、発想を広げる相談相手として使うと非常に頼りになります。

合併という名の「組織OS」の載せ替え

でも、どれほど強力なスキルを持っていても、環境（システム）が変われば苦労は絶えません。

リムルが「人間」から「スライム」へとOSを強制的に載せ替えられたように、私も会社同士の合併によって、働く環境が激変する経験をしました。

それまでの私の会社は、今から思えば非常に自由な「OS」で動いていました。誰もが自由に発言でき、仕事のスタイルも個人に任される裁量が大きかったと思います。

でも合併相手の会社は、まさに「管理された組織」。上からの指示を待ち、降りてきたタスクを完璧にこなそうと動きます。

例えば、合併後の最初のプロジェクト会議で、それまでの会社では当たり前だった「自由なアイデア出し」をしたところ、会議室が一瞬静まり返ったことがあります。

後から分かったのですが、その会社では「決定された方針に対して意見を出すのは上司の役割」という文化が強かったのです。この小さな違和感が、「組織OSの違い」を実感した最初の瞬間でした。

それ以来、私は新しい組織に入ったときは、まず「誰が意見を出す文化なのか」を観察するようにしています。組織のOSを理解するだけで、動き方の失敗はかなり減ると思います。

ただこの「文化（OS）」の違いは、想像以上に深刻でした。

どちらが良い悪いではなく、根本的な「動き方」が違うため、実際にお互いのやり方を理解するまでにはかなり長い時間がかかった記憶があります。

異世界に転生して体の動かし方を一から覚えるリムルのように、私自身、環境が変わったときには、それまでの成功体験を一度見直す必要があると感じた場面がありました。

交渉の場で「空気を読む」技術

そうした新しい環境（OS）の中で生き抜くために、私が頼りにしてきたのが、リムルが持つ「魔力感知」に近い感覚です。

視覚を失ったリムルは、周囲の魔力の流れを読む「魔力感知」によって世界を把握します。エンジニアとしてコードを追うのも大切ですが、キャリアを重ねて交渉の場が増えるにつれ、私も一種の「感知能力」を磨いてきたように思います。

会議室のテーブルに座り、相手と対峙する。交わされる言葉の端々、視線の動き、沈黙の長さ。それらを総合的に捉えることで、「このあたりが落としどころになりそうだ」というポイントが、理屈ではなく感覚として浮かび上がってくることがあります。

私の場合、交渉の場では次の3つを見るようにしています。

この3つを意識すると、「本当に守りたい条件」がどこにあるのかが少し見えてきます。

これは1行ずつのコード（論理）を追う作業ではなく、システム全体のアーキテクチャを俯瞰するように、プロジェクトの空気感を読む作業に近いものだと思います。

エンジニアとして長く仕事をしていると、コードレビューだけでなく、「このプロジェクトはどこで詰まりそうか」という感覚が自然と育っていくものです。

スライムという弱小な存在でありながら最強の龍と対等に話せたリムルのように、「相手の意図」を意識することで、状況が少し読みやすくなったと感じる場面も出てきますね。

最強の相手とも対等に話せる「開き直り」の力

最後に、”なぜ最弱のスライムが世界の破壊神とも言われる「暴風竜ヴェルドラ」と友達になれたのか”について。

第一話を見終わった後に考えてみましたが、そこには、究極の「開き直り」があったのでは？と思います。

転生前は、後輩から頼れるサラリーマンだった主人公。でも気づけば目も見えない一匹のスライムとなってました。この極端すぎる環境の変化が、「失うものなど何もない」という境地を主人公に与えたのでしょう。

仕事の現場でも、相手を「雲の上の存在」と神格化しすぎると、対等な対話はできません。でも転スラを思い出し、もし気後れしてしまったら心の中で「自分はスライムだ」と開き直ってみる。

肩の力を抜いたときに、相手との距離が少し縮まったと感じた経験は、私自身にもあります。

例えば以前、大きなプロジェクトの打ち合わせで、相手企業の役員クラスと直接話す機会がありました。

最初は「自分が話していいのだろうか」と構えていましたが、途中でふと「どうせ自分の言葉など大した影響にもならないだろう」と開き直って思っていたことを質問してみたところ、相手も笑いながら本音を話してくれました。

その瞬間に、会議の空気が少し柔らいだのを覚えています。

まとめ

こうして振り返ると、転スラ第1話には仕事にも通じるヒントがいくつも隠れていることに気づきます。

特に印象に残ったのは次の3つです。

最弱のスライムが、大賢者という知恵と、ヴェルドラという強力な存在に出会った第1話。そこには技術への好奇心と、人との向き合い方のエッセンスが詰まっていました。

次回は、スライムの体が持つ「捕食」という機能について。何でも取り込み、自分のものにしていくその姿から、私なりの「学び直し」の考え方を書いてみようと思います。