私は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エンジニアとして30年以上、小規模開発案件をリードする立場で何度も納期危機を経験してきました。徹夜や根性論で乗り切った時代もありましたが、今ではそれだけでは限界があると痛感しています。

そんなとき、転スラ第3話で描かれるカイジンの納期危機とリムルの対応が非常にリアルに感じました。

この記事では、52歳現役エンジニアの現場経験をもとに、無理な納期を切り抜けるためのリソース確保術と職人・ベテランとの信頼構築方法を具体的にまとめます。明日から試せるヒントになれば幸いです。

関連：
指示待ち集団を変えるには何が必要？現場経験から考える組織再生のヒント

無理な納期にどう立ち向かうか？ リソース確保の現場術

ドワーフ王国の名工「カイジン」は、到底間に合わない「魔鉱石の剣20本」という納期を突きつけられ、窮地に立たされていました。こうした無理なスケジュール、現場でも聞くことがありそうです。

私が会社員だった頃は、正直に言えば「徹夜してでもやり遂げる」という、今ではあまり考えられないような力技で切り抜けたことが多々ありました。

当時担当していたのは小規模な開発案件で、納期が近づくと社内の空気が一気に張り詰めます。夜になると、多くの社員が黙々と叩くキーボードの音だけが響くような状況で作業していたこともありました。

でもやはり根性論だけでは限界があります。

特に経費削減が叫ばれ、仕事量は増えるのに人は増えない。そんな状況に陥ったとき、私は他部門のリーダーに相談しました。

外から見ていても、その方が部門をうまく切り盛りしているのが伝わってきていたからです。会社帰りに食事でもしながら話がしたいというと、何かを察したのか快諾してくれました。

仕事量が増えているのは、当時どの部門も同じ。でもなぜかその部門は人も増えてます。

その秘密を知りたくて実際に話を聞いてみると、「人が足りなくて大変なんです」みたいな感情で訴えるのではなく、「具体的にこれだけの仕事量があり、納期を達成するには、何人必要」と言った具合に論理で訴え続ける、という姿勢を取っていました。

なぜその人数が必要なのか、現状のリソースでどれだけの仕事量があるのかを数値化し、上司にぶつけ続ける。その結果、増員を勝ち取った経験は、私にとって「リソース確保の原体験」となりました。

頑固なベテランと信頼を築く方法

ドワーフ王国を訪れたリムルは、腕はいいが頑固なカイジンたちの懐にうまく飛び込みました。現場の職人や、一癖あるベテランエンジニアとどう付き合うか。これは本当に難しいテーマです。

かつて私の周りにも、癖が強く周囲から敬遠されているけれど、驚くほど頭の良い先輩がいました。最初はどう接していいか悩みましたが、導き出した答えは「まず、自分の意見を横に置いて、徹底的に話を聞く」ことでした。

例えばその先輩は、基幹システムの更新プロジェクトで過去に大きな障害を起こした経験があり、周囲が「また何か言ってくる」と警戒していました。私は週に1回、定時後に30分だけ時間を設け、最初はほとんど聞き役に徹していました。具体的に「そのとき、どんなタイミングで障害が起きたのか」「その前にどんな兆候があったのか」を中心に聞くようにしていました。

すると3ヶ月後くらいから、先輩の方から「実はあの案件ではこうすればよかった」と自ら過去の失敗談や技術的な判断基準を話してくれるようになりました。最初から自分の意見をぶつけてバトルをしてしまえば、相手は心を閉ざします。でも「まずは相手の言い分を聞く」というワンクッションを置くだけで、信頼関係が築け、貴重な実務ノウハウを引き出せるようになるものです。

52歳になった今でも、この「徹底的に聞く」姿勢を意識しています。特に最近のプロジェクトでは、ベテラン技術者に「これまでの失敗経験で一番大きかったものは何ですか？」と質問するようにしています。すると相手が心を開き、貴重なノウハウを教えてくれるようになりました。

職人へのリスペクトとは、その人の積み上げてきた経験に耳を傾けることから始まるのでしょう。

プロジェクトの土台となる3つの確認事項

リムルがなぜドワーフ王国に行ったかと言えば、村に必要なものだらけの中で、まず「技術者（ヒト）」の確保が必要だと思ったからです。

今ではAIも頼れる技術者の一人になると思いますが、私が小規模な開発案件を回していた頃も、似た感覚を持っていました。

それにはまず「全体の仕事量の把握」と「正確なスケジュール感」が重要だと痛感していました。そこでプロジェクトを回す際、私は必ず以下の3つを数値ベースで整理するようにしています。

この3つが見えてくると、初めて「何がどれだけ足りないのか」が分かりますし、逆に言えば、これが見えていない状態では、どれだけ人手を増やしても問題は解決しないことも多いのです。

相手の困りごとを先回りする「余計な口」が信頼を生む

この話の中では、リムルはカイジンの窮地を救うことで、強力なパートナーシップを手に入れました。窮地を救うというほどでもないですが、相手の不足を補ったりすることは、お互いの信頼関係を作る上でとても重要になることがあります。

以前、納品先の会社から提示された共通仕様書があまりに出来が悪かったことがありました。

例えば、ログイン後の初期画面で「10項目以上の必須入力欄」が最初から表示される仕様で、ユーザーが「まずは概要だけ見たい」という要望に対して、手順が長すぎる設計になっていました。

このまま実装すると、入力ミスが頻発し、後工程で仕様変更による手戻りが確実に出る内容でした。

他の会社はその仕様のまま作っていましたが、私はどうしても納得できず、会議で具体的に「この5項目は概要確認後に表示するように変更しませんか」と提案しました。

最初は「余計なことを言うな」という空気になりましたが、3回の会議で粘り強く根拠（想定ユーザー行動とエラー予測）を説明した結果、結局その提案の8割が採用されました。

それ以降、相手の担当者から「君の視点は参考になる」と言われるようになり、関係性が明らかに良くなったのを覚えています。

相手の困りごとを先回りして補うことは、信頼関係を築く上で非常に効果的だと実感した事例です。

今回のまとめ

今回のエピソードから感じた、現場で役立つポイントを整理すると次の3つになると思います。

• 無理な納期には「根性」ではなくリソースの整理で向き合う
• 職人やベテランには、まず話を聞くところから信頼が生まれる
• 困りごとを先回りして補うと、パートナー関係は一気に強くなる

アニメの一場面ですが、仕事の現場を思い出す人も多いのではないでしょうか。

次回は、村に戻ったリムルの前に現れる「運命の人」。新しい出会いと、それによって引き継がれる「想い」について、52歳の人生観を交えて語ってみたいと思います。

私は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話。そこには技術への好奇心と、人との向き合い方のエッセンスが詰まっていました。

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