私は30年以上システム開発に関わってきましたが、若い頃は「できる人なら何でもできる」と考えていた時期がありました。ところが、大規模な案件ほど、一人の能力よりも、誰に何を任せるかで進み方が大きく変わります。

アニメ『Dr.STONE』第1話では、科学知識を持つ千空と、圧倒的な体力を持つ大樹が、それぞれにできることを持ち寄って行動します。その姿を見て思い出したのが、10名規模の基幹システム刷新で経験した役割分担でした。

この記事では、担当を決めるときに見たこと、責任の境界をどう考えたか、状況が変わったときに何を組み替えたかを振り返ります。

役割分担は得意分野から決める

千空は科学の知識に優れていますが、木を切ったり重いものを運んだりする作業は得意ではありません。一方の大樹は、千空のような知識は持っていなくても、体力と粘り強さがあります。

どちらが上という話ではなく、二人の能力が違うからこそ組み合わせる意味があります。これは、ITの現場でも同じです。

チームを組むとき、全員に同じ能力を求める必要はありません。それよりも、誰がどの作業なら力を発揮しやすいのかを見るほうが、実際の成果につながります。

設計・実装・調整を分けた10人の現場

特に印象に残っているのが、
10名規模で基幹システムを刷新したプロジェクトです。

この現場では、設計が得意な担当者が仕様を整理し、実装が速いメンバーが設計内容を形にしていきました。私は、各機能のつながりや進捗、リスクを確認する役割を担当しています。

設計担当には、利用部門の要望をそのまま並べるのではなく、処理の流れやデータの持ち方まで考えてもらいました。実装担当には、細かな設計判断まで抱え込ませず、決まった内容を正確に作ることへ集中してもらいます。

そして私は、機能単体では問題がなくても、システム全体を通したときに矛盾が起きないかを見ていました。

この分担がうまく機能したことで、
限られた期間でも作業を進め、納期に間に合わせることができました。

役割分担を決めるときは、肩書ではなく、
実際にその人が得意としている仕事を見ることが大切です。

「設計担当だから設計を任せる」というより、曖昧な要望を整理するのが得意なのか、細部まで仕様を詰めるのが得意なのかを見る。その違いまで考えないと、同じ役割名でも結果は変わります。

苦手を埋めるより強みを組み合わせる

以前の私は、苦手なことを克服して何でもできるようになるのが成長だと思っていました。もちろん、最低限できることを増やすのは必要です。

でもチーム開発では、全員を同じような人材にするより、違う強みを組み合わせるほうがうまくいく場合があります。

設計が得意な人に無理に大量の実装を任せても、その人の良さが薄れます。反対に、実装が速い人へ曖昧な要件整理まで任せると、作業途中で迷いが増えることもあります。

本人が苦手な仕事ばかりを任されると、時間がかかるだけでなく自信まで失ってしまいますよね。

千空と大樹の関係が分かりやすいのは、お互いの不足を責めず、できることを持ち寄っている点です。チームでも、「全員が同じようにできる状態」を目指すより、「誰かの弱い部分を、別の誰かの強みで補える状態」を作るほうが現実的でした。

担当だけでなく責任の境界を決める

役割分担というと、「誰がどの作業をするか」だけを決めればよいように見えます。

ところが、実際の開発では、作業名だけ決めても十分ではありません。どこまで自分で判断してよいのか、問題が出たら誰へ相談するのか、最終的に誰が確認するのか。ここが曖昧だと、チーム内で認識がずれていきます。

私も担当を割り振っただけで安心し、後から調整に追われたことがあります。

認識のずれは手戻りにつながる

設計担当が「ここから先は実装側で決める」と考え、実装担当は「設計で決まっているはず」と考えている。こうした小さな認識のずれは、現場では珍しくありません。

どちらも仕事を放棄しているわけではないのに、境界が曖昧なため、判断されない部分が残ります。

そのまま実装が進むと、テスト段階で「想定と違う」と分かり、作り直しになることがあります。後から見ると単純な確認漏れですが、複数人で動いている最中は意外と見えません。

そのため、私は役割を決めるとき、次の点まで確認するようになりました。

• その担当者が自分で決めてよい範囲
• 判断に迷ったときの相談相手
• 完了とみなす条件
• 次の担当者へ渡す情報

これを細かく決めすぎると動きにくくなりますが、最低限の境界は必要です。

役割分担の目的は、仕事を細かく切り刻むことではありません。誰が次の判断をするのかを、チーム内で分かる状態にすることだと思います。

リーダーが全体を見る意味

10名規模のプロジェクトでは、
それぞれの担当者が自分の作業に集中するほど、全体のずれが見えにくくなります。

設計担当は仕様の正しさを見ています。実装担当はコードを完成させることへ意識が向きます。テスト担当は不具合を見つけることに集中します。

どの視点も必要ですが、それだけではシステム全体がつながりません。

私が担ったのは、個々の作業の間に抜けや矛盾がないかを見る役割でした。進捗が遅れていないかだけではなく、ある機能の変更が別の機能に影響しないか、後工程へ必要な情報が渡っているかも確認します。

リーダーが何でも自分で判断し、細かな作業まで抱え込むと、今度はリーダー自身が詰まります。だからこそ、作業は任せつつ、つながりを見る。任せることと放置することは違います。

千空も、大樹の作業を一から代わりに行うのではなく、何を目指しているのかを示しています。現場のリーダーにも、同じような役割が必要なのかもしれませんね。

状況が変われば役割も組み替える

役割分担は、一度決めたら最後まで変えないものではありません。

開発が進むと、想定していなかった問題が見つかります。ある作業だけが遅れたり、特定の担当者へ負担が集中したりすることもあります。

最初の分担を守ることより、今の状況に合わせて組み替えるほうが大切な場面もあります。

納期逼迫時にタスクを再分配した経験

以前、納期が迫る中で深夜残業が続いたプロジェクトがありました。

当初の分担では、一部の担当者へ重要な作業が集中していました。その人しか分からない部分が増え、本人が遅くまで残らなければ全体が進まない状態になっていたのです。

このままでは、作業が終わってもチームが疲弊します。家族との時間を削り続けてまで守るべき分担なのか、私自身も考えました。そこで、作業を細かく分け直し、他のメンバーでも対応できる部分を移しました。

担当者本人にしかできない判断は残し、それ以外の確認や資料整理、テスト準備を分散させています。すべてがきれいに解決したわけではありませんが、特定の人だけが残り続ける状況は軽減できました。

役割分担は公平に仕事を配るためではなく、チーム全体が無理なく前へ進むために調整するものです。

同じ量を配っても、難易度や得意分野が違えば負担は同じになりません。誰かの作業が遅れているときも、能力不足と決めつける前に、仕事の集中や前提条件を確認する必要があります。

任せた後も進み方を確認する

仕事を任せた後、「あとはよろしく」と完全に手を離すのは簡単です。

ただ、担当者が困っていても、本人からすぐ相談が上がるとは限りません。質問すると評価が下がるのではないか、忙しそうだから話しかけにくい、と考えて抱え込む人もいます。

私も若い頃は、分からないと言い出せず、必要以上に時間をかけたことがありました。だから今は、問題が出てから確認するのではなく、途中の進み方を見るようにしています。

見るのは、細かな作業方法ではありません。

• 判断に迷っている箇所はないか
• 他の担当者から情報を待っていないか
• 当初の見積もりより難しくなっていないか
• 一人で抱える必要のない作業がないか

こうした点を確認します。

何度も進捗を聞きすぎると、監視されているように感じます。その一方で、何も聞かなければ、問題が大きくなるまで分かりません。

この加減は今でも難しいところです。
相手によっても違いますし、同じ人でも案件によって変わります。

それでも、役割を任せた後に会話を続けることは必要です。分担は、決めた瞬間に完成するのではなく、作業を進めながら整えていくものだと思います。

小さな成果の積み上げがチームを強くする

『Dr.STONE』では、失われた文明を一気に取り戻すことはできません。使える材料を探し、試し、うまくいかなければやり直しながら、一つずつ前へ進みます。

システム開発も、完成した姿だけを見ると大きな仕事に見えますが、実際には小さな判断と作業の積み重ねです。

設計書を一つ仕上げる。機能を一つ実装する。見つかった不具合を一つ直す。その積み上げが、最後にシステム全体になります。

私は52歳になった今も、新しい技術を試す機会があります。金融機関向けの業務システムでは、生成AIを使った自動照合ツールのPoCを担当しました。

従来は手作業で一日かかっていた請求データの突合を効率化するため、約1か月でプロトタイプを作り、作業時間を約40％短縮できる見通しを示しました。

もちろん、一人だけで実現したものではありません。業務を知る人、データを確認する人、技術を試す人が役割を持ち、それぞれの結果をつないだから形になりました。

若いメンバーから声をかけてもらったときは、52歳でも現場で役に立てたことが素直にうれしかったです。ただそれ以上に感じたのは、長く続けてきた経験も、新しい知識も、チームの中で使われて初めて成果になるということでした。

一人で多くの知識を持っていても、共有されなければチームの力にはなりません。反対に、小さな知識でも、必要な人へ渡れば大きな作業を支えます。

役割分担によって一人ひとりの強みを生かし、その成果を次の担当者へ渡していく。この繰り返しが、チームを少しずつ強くしていくのだと思います。

まとめ

チーム開発の役割分担は、単に人数分へ仕事を割り振ることではありません。

まず、それぞれが得意とする仕事を見ます。そのうえで、自分で判断できる範囲、相談相手、完了条件を決めます。作業が始まった後も、負担の偏りや認識のずれを確認し、必要なら分担を変えます。

10名規模の基幹システム刷新を経験して分かったのは、一人の優秀な人へ頼るより、設計、実装、調整の強みを組み合わせたほうが、安定して前へ進めるということでした。

千空と大樹も、同じ能力を持っているから協力できたわけではありません。違う能力を認め、必要な役割を引き受けたからこそ、何もない世界で最初の一歩を踏み出せました。

チームがうまく進まないときは、メンバーの能力だけを疑う前に、役割の決め方を見直してみるとよいかもしれませんね。誰が悪いかではなく、誰の強みをどこで使うか。その見方に変えるだけで、動き出す仕事もあると思います。

毎回ではありません。大半の日は正常に終わるのに、ある条件が重なったときだけ処理が途中で止まります。ログを見ても、最初は原因らしいものが見つかりませんでした。

原因不明の不具合を調べていると、技術的な難しさ以上に「本当に前へ進んでいるのか分からないこと」が苦しくなります。私も30年以上システム開発に関わるなかで、何度もその感覚を味わってきました。

『Dr.STONE』第2話で繰り返される試行錯誤を見たとき、夜中までログを追い、古い仕様書をめくっていた頃を思い出しました。この記事では、5年前の仕様まで調べて原因にたどり着いた経験から、調査が進まないときに何を確認し、どう作業を続けたのかを書いていきます。

月に数回だけ止まる夜間バッチ

調査したのは、金融系システムの夜間バッチでした。

通常は問題なく終了します。
でも不思議なことに、月に数回だけ、処理が途中で止まることがありました。

毎回発生する不具合なら、同じ操作を繰り返しながら原因を追えます。でも今回のように発生頻度が低いと、再現させるだけでも時間がかかります。

最初は、実行時刻やサーバーの負荷、データ件数などを疑いました。

ログを追加し、条件を変えて実行し、結果を確認する。違えば、また別の可能性を考える。その繰り返しです。

数回試して原因が分からないと、
「見ている場所が違うのではないか」と不安になります。いや、実際に違っていることもあります。

ただ、そこで思いつくままに調査範囲を広げると、今度は何を確認したのか分からなくなります。

原因が見つからないときほど、
調査範囲を広げる前に、分かったことと分からないことを分ける必要があります。

5年前の仕様書まで戻った理由

調査を続けるうちに、
特定の入力データが含まれるときだけ停止する可能性が見えてきました。

ただし、そのデータが入っていれば必ず止まるわけではありません。正常に終わるケースもありました。

「同じように見えるデータの何が違うのか」

そこから、正常終了したデータと停止したデータを並べ、項目ごとに違いを確認しました。

文字数、空欄、日付、コード値。
最初はどれも決定的な違いには見えません。

何度見ても分からず、日付が変わってからもログとデータを行き来していました。正直、途中から画面の文字が頭に入ってこなくなります。

それでも、過去の改修履歴を調べていると、
対象の項目が5年ほど前に追加されていたことが分かりました。

現在の仕様書だけを見ると、その項目は必須に見えます。しかし、追加当時の資料まで戻ると、移行期間中だけ空欄を許す設計になっていました。

古いデータの一部には、その当時の条件が残っていたのです。

最終的な原因は、特定の入力パターンでNULLチェックをすり抜ける条件分岐でした。

コードだけを見れば、一行の問題です。

ただ、その一行がなぜ必要だったのかは、現在の資料だけでは分かりませんでした。5年前の仕様変更と古いデータの扱いを確認して、ようやく処理が止まる流れがつながったのです。

原因より先に再現条件を探した

不具合が起きると、すぐに
「どのコードが悪いのか」を探したくなります。

私も最初は、停止した周辺の処理ばかり見ていました。しかし、コードを読み続けても原因候補が増えるだけで、なかなか絞れません。

調査が動き始めたのは、
原因を当てようとするのをやめて、「どんなときに起きるのか」を整理してからでした。

実際には、次のような違いを記録しました。

• 停止したときの入力データ
• 正常終了したときの入力データ
• 実行した日時と環境
• 処理が止まる直前のログ
• 同じ条件で再実行した結果

ここで大切だったのは、
異常なケースだけでなく、正常だったケースも残したことです。

たとえば、特定の項目が空欄でも正常に終わるケースがあれば、「空欄だけが原因ではない」と分かります。原因にはたどり着いていなくても、可能性を一つ消せています。

不具合調査では、原因を見つけた回数ではなく、
原因ではない条件をどれだけ確認できたかも前進です。

『Dr.STONE』第2話の試行錯誤も、一度で正解を当てるものではありませんでした。失敗を重ねながら、何が足りないのかを少しずつ探っていきます。

デバッグも似ています。
外れた仮説は無駄ではなく、次に調べなくてよい範囲を教えてくれます。

深夜の調査で事実だけを書き出した

夜中まで調査が続くと、考えがだんだん雑になります。

同じログを何度も開いたり、
さっき確認した条件をもう一度試したりすることもあります。

「何か見落としている気がする」

そう思うほど、調査範囲を広げたくなります。
しかし、疲れている状態で思いつきの確認を増やしても、結果が整理できません。

そこで私は、いったん原因の予想を書くのをやめ、確認できた事実だけを残すことにしました。

たとえば、次のような短い記録です。

きれいな報告書を作る必要はありません。

私の場合は、箇条書きや表に短く残す程度でした。
それでも、「どこまで確認したか」が見えるだけで、同じ調査を繰り返しにくくなります。

また、翌日に別のメンバーが見ても、
調査を最初からやり直さずに済みました。

気持ちが折れそうなときにも、この記録は役に立ちます。

原因が見つからないと、何時間作業しても何も進んでいないように思えます。しかし、「この条件は除外できた」「ここまでは正常だった」と書かれていれば、少なくとも昨日と同じ場所にはいません。

一人で抱えるほど調査が遅くなった

以前の私は、不具合調査を最初から最後まで一人で進めようとすることがありました。

ログを読む。コードを調べる。再現手順を作る。修正案を考える。テストする。

一人で把握したほうが早いと思っていたのです。でも原因不明の不具合では、この進め方がかえって遅くなることがあります。

ログを調べている間はテストが止まり、
コードを読んでいる間は再現条件の確認が止まります。すべての作業が順番待ちになるためです。

ある調査では、途中から役割を分けました。

私は再現条件の整理に集中し、改修担当には該当コードの確認を依頼しました。テスト担当には、私がまとめた条件をもとに、別の入力パターンを試してもらいました。

• 私は、どの条件で発生するかを絞る
• 改修担当は、該当する条件分岐を確認する
• テスト担当は、見落としそうな組み合わせを試す

この形に変えると、調査と検証を同時に進められるようになりました。

ただし、単に人数を増やせばよいわけではありません。

「原因不明なので見てください」と渡しても、相手もどこから始めればよいか分かりません。私が共有したのは、調査途中の長い説明ではなく、発生条件と未確認事項をまとめた短いメモでした。

何が分かっていて、何を調べてほしいのか。
そこまで整理して初めて、分業が機能します。

『Dr.STONE』第2話の千空と大樹も、同じ作業を二人で繰り返しているわけではありません。それぞれが得意なことを担当するから、長い試行錯誤を続けられます。

不具合調査でも、自分が全部解決することより、
次の人が動ける形にして渡すほうが早い場合があります。

調査が止まったときに確認すること

原因が分からない状態が続くと、つい新しい仮説ばかり考えたくなります。

ただ、仮説を増やす前に、私は次の点を確認するようにしています。

再現条件を言葉にできるか

「たまに止まる」だけでは、まだ調査の入口です。

どのデータ、どの時刻、どの環境で起きたのか。
完全に再現できなくても、共通点を言葉にできれば調査範囲を狭められます。

正常なケースと比べたか

異常なデータだけを見続けると、
そのデータのすべてが怪しく見えてきます。

正常に動いたケースと並べることで、本当に違う部分が見えやすくなります。

同じ確認を繰り返していないか

長時間の調査では、
自分でも気づかないうちに同じことを試します。

記録があれば、「これはすでに確認済み」と判断でき、その時間を別の調査に使えます。

古い仕様や改修履歴を見たか

現在のコードが理解できても、
なぜその処理になったのかまでは分からない場合があります。

古いデータや例外処理が関係していそうなら、現在の仕様だけでなく、導入当時の資料や改修履歴まで戻る必要があります。

一人で抱えすぎていないか

長く調べている人ほど、
無意識に前提を固定してしまいます。

別の人に状況を説明すると、
「なぜそこを原因だと思ったのか」と聞かれ、自分の思い込みに気づくことがあります。

まとめ

原因不明の不具合調査では、原因が見つからない時間が長く続きます。

私が担当した夜間バッチも、最終的な原因は一行の条件分岐でした。しかし、そこへたどり着くには、正常ケースとの比較、何度もの仮説検証、5年前の仕様書の確認が必要でした。

大きなひらめきで解決したわけではありません。

分かったことを記録し、原因ではない可能性を一つずつ消し、必要なところで役割を分けた結果です。

調査が進んでいないように見える日でも、再現条件が一つ分かったなら前進しています。関係のない処理を一つ外せたなら、それも前進です。

原因を早く当てようとするより、次に調べる範囲を少し狭くする。私は今でも原因不明の不具合に出会うと、まずそこから始めています。

提案に問題があるなら、採用しない判断も必要です。ただ、理由を聞かずに退ければ、消えるのは一つの案だけではありません。その若手が次に意見を言う気持ちまで失わせることがあります。

この記事では、なぜ私は会議中に声を上げられなかったのか、提案を採用できない場合でも何を確認すべきだったのか、同じ場面に戻れるならどんな言葉を挟むかを振り返ります。会議で若手の提案が潰されそうなとき、第三者としてできる対応の参考になれば幸いです。

若手の表情が変わった会議の一言

私が40代の頃、ある会議で若手エンジニアが新しい開発言語の導入を提案しました。

少し声を上ずらせながらも、その若手は自分なりに考えた利点、従来より開発しやすくなること、今後の保守にも役立つことなどしっかり説明していました。少なくとも、思いつきだけで話しているようには見えませんでした。

ところが、話し始めて間もなく、会議室の空気が変わります。

ベテランの何人かは黙ったまま資料へ目を落とし、わずかなため息も聞こえました。誰も質問しないため、若手だけが前のめりになって説明している状態です。

そこで上司が、低い声で言いました。

「今さら変える必要はない。前例がないものを導入して、失敗したら誰が責任を取るんだ」

その瞬間、「え？．．．」という感じで、若手の表情が変わりました。

先ほどまで明るかった顔が固まり、視線が泳ぎ肩を落とします。「検討してみます」といった言葉すらありませんでした。提案はその場、その一言で終わったのです。

私はその様子を見ながら、何も言えませんでした。

上司の言うことにも一理はあります。新しい開発言語を入れれば、習得の時間や保守体制、既存システムとの相性を確認しなければなりません。失敗した場合の影響も小さくないでしょう。

ただ、それらは提案を聞いたうえで検討する話です。

「前例がない」「誰が責任を取る」という言葉だけで終わらせると、提案の問題点も、改善できる余地も分かりません。

若手に残るのは、「新しいことを言うと責められる」という記憶だけです。

なぜ私はその場で何も言えなかったのか

会議が終わったあと、私は強く後悔しました。上司に反論できなかったことだけではありません。せめて若手へ質問を一つ投げかけることはできたはずです。

「導入する範囲はどこまで考えているのか」
「既存言語と比べたメリットをもう少し聞かせてほしい」

その程度なら、上司を正面から否定せず、提案を検討の場へ戻せたかもしれません。

それでも、私は黙っていました。

理由の一つは、会議の空気を壊したくなかったからです。上司が結論を出したあとに話を戻せば、「もう終わった話だ」と思われるかもしれません。

もう一つは、自分にも新しい開発言語の知識が足りなかったこと。十分に理解していないのに若手をかばえば、無責任に見えるのではないかと考えました。

そして正直に言えば、次に矛先が自分へ向くのが怖かったのだと思います。

「では、お前が責任を持つのか」

そう言われたときに答えられない。
そこまで想像して、口を閉じました。

会議では否定した本人だけでなく、周囲の沈黙も大きな意味を持ちますよね。誰も言葉を挟まなければ、若手からは「この場にいる全員が自分の提案を否定した」と見えるかもしれません。

私は上司と同じ言葉を言ったわけではありません。でも、何も言わなかったことで、結果としてその場の結論を支えてしまいました。

提案を採用できなくても確認すべきこと

若手の提案を尊重することと、無条件に採用することは違います。

新しい技術にはリスクがあります。学習にかかる時間、対応できる技術者の人数、既存環境との相性、将来の保守まで確認しなければなりません。

だからこそ、提案を退ける前に、最低限の内容を聞く必要があります。

例えば、新しい開発言語の提案なら、私は今なら次の点を確認します。

• どの問題を解決するための提案なのか
• 現在の方法と比べて何が良くなるのか
• 全面導入ではなく、一部で試せないか
• 習得や保守にどの程度の負担がかかるか
• うまくいかなかった場合に元へ戻せるか

この質問に答えられないなら、提案はまだ検討不足かもしれません。

しかし、それでも「考えが浅い」で終わらせる必要はありません。足りない部分を伝え、次に何を調べればよいかを示せます。

反対に、若手が具体的な比較や小さな検証案まで用意しているなら、少なくとも話を聞く価値はあります。

採用しない場合でも、「何が足りなかったか」が分かれば、提案は次の学びにつながります。

一番避けたいのは、内容ではなく、年齢や前例だけで結論を出すことです。

「若手だから分かっていない」
「これまでやっていないから危険だ」

そう決めつけると、提案の中身を検討する機会そのものがなくなります。そして若手も、次からは考えていても口にしなくなるでしょう。

同じ場面で今ならこう言葉を挟む

あの会議と同じ場面に戻れるなら、
私は上司の言葉を直接否定するのではなく、検討を続けるための言葉を挟みます。

例えば、こう言います。

「確かに全面導入はリスクがあります。まず、どの範囲なら小さく試せるのかだけ聞いてみませんか」

これなら、上司が心配しているリスクを無視していません。同時に、若手の提案もその場で終わらせずに済みます。

あるいは、

「責任の問題は整理が必要ですね。その前に、今の方法の何を変えたい提案なのか確認させてください」

と聞く方法もあります。

大切なのは、若手を全面的に擁護することではありません。提案を感情的な対立から切り離し、検討できる形へ戻すことです。会議の中で結論を出せないなら、宿題にしてもよいと思います。

「既存方式との比較を一枚にまとめて、次回もう一度説明してほしい」

「小規模な検証に必要な日数を出してほしい」

そう終われば、少なくとも若手には次の行動があります。

一方、「前例がないから却下」で終われば、次に何を改善すればよいのか分かりません。

会議後の声かけも必要です。当時の私は、その若手へ十分な言葉をかけられませんでした。気まずさもあり、何と話せばよいのか迷っているうちに機会を逃したのだと思います。

今なら、短くてもこう伝えます。

「提案したこと自体は悪くなかった。今回はリスクの説明が足りなかったから、次は比較と試し方まで用意しよう」

提案が通らなかった事実を無理に慰めるのではなく、良かった点と足りなかった点を分けて伝えます。これなら、「何を言っても無駄だった」という記憶だけを残さずに済むかもしれません。

若手の提案を守るとは、必ず採用することではなく、次も意見を言える終わらせ方をすることです。

私はあの会議で、それができませんでした。だからこそ今は、誰かの提案が強い言葉で終わりそうなとき、「検討に必要な質問が残っていないか」を考えるようにしています。

まとめ

若手の提案に問題があれば、採用しない判断も必要です。

ただ前例や責任という言葉だけで終わらせると、若手は何を直せばよいのか分かりません。その場にいる人も、質問を一つ挟むことで、提案を冷静な検討へ戻せる場合があります。

私はあの会議で何も言えませんでした。今なら、全面導入か却下かを急がず、小さく試せる範囲や不足している情報を確認します。

提案が通らなくても、次に何を準備すればよいかが分かる。そんな終わらせ方が、若手の次の発言を守ることにつながると思います。

納期まで残り数日。周囲から聞こえるのはキーボードをたたく音と、たまに漏れるため息だけです。「このまま進めて本当に大丈夫か」と考えているのに、焦るほど頭が回らなくなっていきました。

『Dr.STONE』第4話を見たとき、司に見つかる危険を承知で決断する千空たちの姿から、あの夜の空気を思い出しました。もちろん、作品のように命を懸ける場面ではありません。それでも、納期に追われた開発現場では、一つの判断がチーム全体を大きく左右することがあります。

この記事では、20年以上システム開発に関わってきた私の経験から、焦っているときに判断を誤りやすい理由と、実際に何を確認してきたのかを書きます。納期直前で「もう決めるしかない」と追い詰められている方にとって、いったん考え直すきっかけになればと思います。

焦っているときほど大きな決断をしたくなる

『Dr.STONE』第4話では、仲間を探すために狼煙を上げる場面があります。

狼煙を上げれば、仲間に気づいてもらえるかもしれません。その一方で、敵である司にも居場所を知られる危険があります。

安全だけを考えれば、何もしないほうがいい。でも何もしなければ状況は変わらない。千空たちは危険を理解したうえで、先へ進むための決断をします。

この場面を見ながら、納期直前の開発現場でも似たようなことが起きると思いました。

追い詰められると、人は思い切った判断をしたくなります。

「この機能は削ろう」
「確認は後回しでいい」
「とりあえず動けば先へ進める」

時間がないため、どれも現実的な選択に見えます。ただ焦っているときほど、目の前の作業を減らすことだけに意識が向き、その判断が後工程へ与える影響を見落としやすくなります。

納期直前に必要なのは、
思い切りのよさよりも、何を失う判断なのかを確認することです。

機能を削る提案に反対した理由

以前、大手金融機関向けの基幹システム刷新に関わったときのこと。

開発が予定より遅れ、上層部から「一部の機能を今回は見送ろう」という話が出ました。目の前の納期だけを考えれば、もっともな判断に見えます。

しかし、私はその機能を外すと、
後工程で大きな手戻りが発生する可能性が高いと考えました。

連携するほかの機能との関係が深く、単純に切り離せるものではなかったからです。そこで、過去の類似案件で発生した不具合や修正工数を調べ、機能を削った場合に起きそうな問題を整理しました。

当時は、上層部の方針に反対することにかなり迷いました。

「余計なことを言わず、決まった通りに進めたほうが楽なのではないか」

正直、そんな気持ちもありました。
ただ、危険だと思いながら黙って進めれば、問題が起きたときに後悔する気がしたのです。

会議では、感覚的に「危ない」と言うのではなく、次の点を伝えました。

• 機能を外した場合に影響する範囲
• 過去に似た判断で発生した手戻り
• 今進めた場合と、後から戻した場合の工数差

結果として、機能を残したまま進める方針になりました。作業は厳しかったものの、大きな手戻りを起こさず納期にも間に合い、すごくホッとしたのを鮮明に覚えています。

この経験で分かったのは、
リスクを取ることと、勢いで決めることは違うということ。

千空の判断も、ただ無謀だったわけではありません。危険と得られる可能性を比べたうえで、それでも進む道を選んでいました。

開発現場でも同じであり、何かを決める前に、
少なくとも「失うもの」「残るもの」「後から戻せるか」は確認したほうがいいと思います。

夜中のオフィスで手が震えた

今でも忘れられないのは、納期まで数日しかなかった夜のこと。

蛍光灯の白い光がついたままのオフィスで、コーヒーの空きカップが机に並んでいました。普段なら雑談するメンバーも、その夜はほとんど話しません。

キーボードの音だけが続き、たまに誰かのため息が聞こえます。外はとっくに真っ暗なのに、時間の感覚がだんだんなくなっていました。

私は画面を見ながら、修正した処理をそのまま反映してよいか迷っていました。

「たぶん大丈夫だろう」
「いや、でも見落としがあるかもしれない」
「ここで止めたら、さらに遅れる」

同じ考えが頭の中を何度も回ります。

気づくと、マウスを持つ手が少し震えていました。喉が乾き、背中に汗が流れているのも分かります。失敗すれば、自分だけでなくチーム全体に迷惑がかかる。その考えが離れませんでした。

あのとき一番危なかったのは、
技術力が足りなかったことではありません。

焦っている自分を、まだ正しく判断できる状態だと思い込んでいたことです。

画面から離れて初めて気づいたこと

そのまま作業を続けても、
同じ箇所を何度も読み直すだけでした。

そこで一度、席を立ちました。
格好よく冷静になれたわけではありません。
もう画面を見続けるのが苦しくなっただけです。

給湯室まで歩き、水を飲みました。
数分だけ画面から離れて戻ってみると、さっきまで見えていなかった違和感に気づきました。

修正した処理そのものではなく、
その前後にあるデータ更新の順番が危なかったのです。

もし焦ったまま反映していたら、
別の不具合を起こしていた可能性があります。

この経験から、私は納期直前ほど次のことを確認するようになりました。

• 同じ箇所を何度も見ていないか
• 「たぶん大丈夫」で進めようとしていないか
• 誰かに説明できる状態になっているか

すぐに答えが出ないときは、数分でも画面から離れます。

深呼吸をすればすべて解決する、という話ではありません。現場によっては、席を立つ余裕すらないこともあります。

ただ、焦った状態のまま決定ボタンを押すよりは、短い時間でも視線を外したほうが、見落としに気づけることがあります。

判断に迷ったら声の大きさではなく根拠を見る

若い頃の私は、危険だと思っても、うまく説明できないことがよくありました。

あるプロジェクトで仕様について意見が分かれたときも、「この設計は危ない気がする」としか言えませんでした。相手から理由を聞かれても、考えを整理できず、結局は会議の空気に流されました。

その仕様は採用され、後になって大きな問題が起きました。

問題が起きたとき、「やはり危なかった」と思った一方で、反対意見を伝えきれなかった自分にも悔しさが残りました。

それからは、違和感があるときほど、理由を分けて考えるようにしています。

• どの条件で問題が起きるのか
• 影響する利用者や機能はどこか
• 今直す場合と後で直す場合で何が違うか

全部を完璧に説明できなくても構いません。ただ「怖い」「危ない」という感覚を、そのままにしないことが大切です。

主張を通す力は声の大きさではなく、
危険を具体的に説明できる準備から生まれます。

『Dr.STONE』の千空も、力だけで周囲を動かす人物ではありません。状況を見て、何が必要かを考え、限られた材料から次の手を選んでいます。

納期に追われた現場でも、最後に頼りになるのは、
勢いや根性より、いま分かっていることを整理する力なのだと思います。

チームに必要なのは判断する人だけではない

第4話では、杠が加わったことで、
千空と大樹だけだったチームの雰囲気が変わります。

千空は論理的に考え、大樹は迷わず行動する。
そこに、細かな作業や周囲への配慮ができる杠が加わります。

開発現場でも、判断が速い人や実装が得意な人だけでチームがうまく回るとは限りません。

以前のプロジェクトでは、設計と実装が得意なメンバーはそろっていました。しかし、仕様書の更新や関係者との調整を後回しにしがちで、認識のずれが何度も起きていました。

そこで、私は仕様変更を一覧にし、週次会議で確認する形に変えました。

地味な作業です。正直、最初は「そこまで細かく管理しなくてもいいのでは」と言われました。

それでも続けていると、
「聞いていない」「その認識ではなかった」というやり取りが減り、会議時間も短くなりました。

極限状態では、強く決断できる人が目立ちます。
しかし、本当にチームを支えるのは、確認する人、記録する人、違和感を伝える人でもあります。

自分が決断役でなくても、チームの判断を正確にすることはできます。

まとめ

納期に追われると、早く決めることが正解に見えてきます。

しかし、夜中のオフィスで手が震えた経験から、私は焦っているときほど、自分の判断を疑う必要があると学びました。

画面から数分離れる。誰かに説明するつもりで考える。判断によって失うものを確認する。

どれも派手な方法ではありません。それでも、取り返しのつかない判断を避ける助けにはなります。

今でも納期が迫ると焦りますし、冷静でいられないこともあります。ただ、「早く終わらせたい」という気持ちが強くなったときほど、そのまま進めて大丈夫かを一度確認するようになりました。

焦りをなくすことはできなくても、焦ったまま決めないことはできます。

長く勤めた会社を離れると、役職も担当案件も、社内で頼られていた立場も一度になくなります。自由になったはずなのに、「会社の外でも、自分はエンジニアとして通用するのだろうか」と不安になりました。

それでも、新しい技術を調べて実際に動かすことだけはやめませんでした。52歳になった今も、週末には生成AIをはじめ、気になった技術を少しずつ試しています。

この記事では、40代で会社を辞めた私が、その後も技術を学び続けている理由をお伝えできればと思い、年齢を重ねてからの学び方や、若いエンジニアと同じ競争をせずに経験を生かす考え方もまとめました。

「今から新しい技術を学んでも遅いのでは」と迷っている方が、次に何を試すか考える材料になればと思います。

会社を辞めると自分の価値が分からなくなった

会社員だった頃の私は、担当している仕事や社内での立場によって、自分の価値を確かめていたのだと思います。

チームのメンバーから相談を受け、会議では判断を求められます。納期が近づけば忙しくなり、問題が起きれば対応に追われる。大変ではありましたが、「自分にはやることがある」という感覚はありました。

ところが、会社を辞めると、その状況が一変します。

朝になっても出社する必要はありません。確認を求める連絡も、急ぎの会議もない。最初は気が楽でしたが、しばらくすると別の不安が出てきました。

「会社の名前がなくても仕事を任せてもらえるのか」

「これまでの経験は、外でも役に立つのか」

「自分の技術は、もう古いのではないか」

正直、会社を辞めた後に一番こたえたのは、仕事の量が減ったことではありません。自分の価値を判断する基準がなくなったことでした。

会社にいると、肩書きや評価、担当案件が、自分の現在地をある程度教えてくれます。しかし、その看板が外れると、最後に残るのは自分が何を知っていて、何ができるのかです。

そこで私は、以前から気になっていた技術をもう一度触り始めました。立派な目標があったわけではありません。まずは「まだ自分は手を動かせる」と確かめたかったのだと思います。

会社を離れた後の技術学習は、仕事を得る準備であると同時に、自分の感覚を取り戻す時間でもありました。

若手を見て「もう勝てない」と思った

若手の提案で気づいた自分の役割

会社を辞める前、
大規模なWebシステムの刷新に関わったことがあります。

会議では、30代前半のメンバーが新しい開発環境やクラウド技術を使った提案を次々に出していました。説明を聞けば内容は理解できます。ただ、技術の選択肢が自然に出てくる速さは、当時の私とは違って見えました。

「もう次の時代が始まっているな」

そう思ったのを覚えています。

少し前の私なら、負けてはいけないと考え、すべて自分で勉強して先頭に立とうとしたかもしれません。けれど40代後半になり、それは現実的ではないと気づき始めていました。

新しい技術の情報量も、変化の速さも増えています。すべてを同じ深さで覚えようとすれば、いくら時間があっても足りません。その一方で、私は長年の開発経験から、設計上の危険や運用時の問題には気づけます。

新しい仕組みを使う若手に対して、

「この条件だと障害が起きたときに復旧が難しくないか」

「実際に運用する担当者が困るのは、どの部分だろう」

「以前、似た構成でここが問題になった」

といった話はできました。

そこで考え方を変えました。

新しい技術を覚える速さで若手と競うのではなく、自分が経験してきた失敗や判断基準と、新しい技術を組み合わせればよいのではないか。

手順ではなく判断基準を引き継いだ

そう考えてから、すべてを自分で担当するのではなく、若いメンバーへ仕事を引き継ぐ準備も始めました。

引き継いだのは、操作方法や手順だけではありません。

• なぜその設計を選んだのか
• どの条件なら判断を変えるのか
• 過去にどの部分で失敗したのか
• 問題が起きたときに何を先に確認するのか

こうした、資料に残りにくい部分も言葉にしました。

自分が長く担当した仕事を誰かに渡すのは、思った以上に寂しいものです。「まだ私の方が分かっている」と思う場面もありました。

いや、実際に口を出しすぎたこともあります。

それでも任せてみると、自分にはなかった改善案が出てきます。そこでようやく、役割を譲ることと、エンジニアをやめることは別だと分かりました。

技術を学ぶのは若手に勝つためではない

会社を辞めた後も技術を学んでいると言うと、「仕事を取るためですか」と聞かれることがあります。

もちろん、それも理由の一つです。

フリーランスとして仕事を続けるなら、新しい技術やサービスをまったく知らないままでは難しいでしょう。過去の経験だけで対応できる仕事にも限りがあります。

ただ、それだけなら、必要な範囲だけ勉強すれば済むはずです。

それでも休日にPCを開き、直接仕事とは関係のない技術まで試してしまうのは、単純に「どう動くのだろう」と気になるからです。

誰にも評価されなくても面白かった

30代前半の頃、
データをグラフで見せる技術に夢中になった時期がありました。

当時は周囲から、それほど重要な技術だと思われていなかった記憶があります。それでも論文や技術資料を読み、プログラムを書き、グラフの形を何度も調整していました。

夜になり、オフィスの照明がほとんど消えても作業を続けたことがあります。

何度試しても思ったように動かなかったグラフが、ある瞬間、予想した形に変わりました。

「ほら、やっぱりそうなるよな」

思わず声が出ました。周りには誰もいません。

売上が増えたわけでも、上司に評価されたわけでもありません。それでも、分からなかったものが少し分かった。その瞬間がうれしかったのです。

52歳でも「なぜだ」と試してしまう

52歳になった今も、この感覚はあまり変わっていません。

最近は、生成AIを使った業務の自動化を試しました。最初は思ったような回答が返らず、処理の途中で止まる。修正したら別の場所がおかしくなる。久しぶりにPCへ向かって「なぜだ」と独り言を言いました。

まあ、こういう時間も嫌いではありません。

何度か見直すうちに、月次レポート作成の一部を効率化できそうな形になりました。完成と呼べる段階ではありませんでしたが、「これなら仕事に使えるかもしれない」と見えた瞬間は面白かったです。

私が技術を学び続ける一番の理由は、若手に負けないためではなく、分からないことを試す面白さをまだ失っていないからです。

40代以降は経験と新しい技術をつなげる

覚える速さより判断できることが強み

年齢を重ねると、
新しい技術を覚えるのが遅くなったと思うことがあります。

以前なら一度読めば理解できた説明を、何度も読み返す。設定項目の名前が頭に入らず、さっき見た画面をもう一度探す。

そんなことも増えました。

若い頃と同じように学べない自分へ、
焦りを覚える人もいるかもしれません。私にもあります。

ただ、長く仕事をしてきたからこそ分かることもあります。

新しい技術を見たときに、使い方だけでなく、

• 導入後の運用で誰が困るか
• 障害が起きたときにどう切り戻すか
• 説明や教育にどれくらい時間がかかるか
• 本当に既存の仕組みを置き換える価値があるか

といった点まで考えられるようになりました。

技術の新しさだけに引っ張られず、
仕事の中で本当に使えるかを考えられるのは、過去の失敗や調整経験があるからです。

過去の経験は捨てなくていい

私も以前は、「古い知識を捨て、新しい技術を一から覚えなければならない」と考えていました。しかし、すべてを捨てる必要はありませんでした。

たとえば、生成AIの仕組み自体は新しくても、入力データの品質、権限管理、利用者への説明、障害時の対応といった問題は、これまでのシステム開発と共通しています。

新しい技術へ、過去の経験をどう持ち込むか。
そこに40代以降のエンジニアが学び続ける意味があると思います。

若手と同じ速さで覚えることより、これまでの経験を使って新しい技術の価値と危険を判断することが大切です。

学び続けるために大きな目標を立てない

大きな目標ほど始めにくくなる

技術を学び続けるといっても、
毎日何時間も勉強しているわけではありません。

疲れてPCを開く気になれない日もあります。少し資料を読んだだけで、結局何も作らずに終わる週末もあります。

若い頃のように、深夜まで毎日作業することは難しくなりました。体力の問題もありますし、仕事以外に使いたい時間もあります。

そのため、今は最初から大きな目標を立てないようにしています。

「この技術を完全に習得する」

「3か月で資格を取る」

「新しい分野へ転職できるレベルになる」

このように考えると、始める前から負担が大きくなります。

まず1時間だけ触って判断する

私が実際に行っているのは、もっと小さなことです。

• 気になった技術を一つ選ぶ
• まず1時間だけ触る
• 小さな機能を一つ動かす
• 分からない点をメモする
• 面白ければ翌週も続ける

一度触ってみて、自分の仕事には必要ないと分かることもあります。それも無駄ではありません。

技術名だけを知っている状態と、
実際に少し触って難しさを知っている状態では、その後の判断が変わります。

以前、話題になっていたツールを試したところ、簡単に使えると思っていた部分で設定にかなり手間がかかりました。仕事へ導入する前に試していなければ、納期や費用を甘く見積もっていたはずです。

学ぶことは、必ずしも専門家になることではありません。自分の目で確かめ、どこまで使えそうか判断できれば、それだけでも仕事に生かせます。

一人で学び続けないようにする

会社を辞めると、技術について気軽に話せる相手が減ります。

会社員時代なら、隣の席にいる人へ「この方法、どう思う」と聞けました。雑談の中で、知らなかったサービスや失敗事例を知ることもあります。

フリーランスになると、そうした偶然の会話は少なくなりました。

一人で調べていると、自分の理解が正しいのか分からなくなることがあります。間違った方向へ何時間も進んでしまうことも珍しくありません。

そこで私は、以前の同僚や仕事仲間とのつながりを意識して残すようになりました。

以前、元同僚と二人でシステム改修を担当したときのことです。私が作った予定を見て、彼から「この部分は現実的ではない」と指摘されました。

私は経験もあるし、何とかなるだろうと思っていました。

しかし作業を細かく分けて確認すると、確かに無理があります。自分の得意な作業だったため、必要な時間を少なく見積もっていたのです。

長く仕事をしていると、経験が助けになる一方で、「これくらいならできる」という思い込みも強くなります。

学習も同じです。

一人で試す時間は必要ですが、
誰かへ説明したり意見を聞いたりすると、自分が理解できていない部分に気づきます。

技術のコミュニティへ参加する方法もありますが、無理に大勢の輪へ入らなくてもよいと思います。気軽に話せる相手が一人いるだけでも違います。

私の場合は、以前の同僚と近況を話したり、仕事で使った技術について情報を交換したりすることが、学びを続ける助けになっています。

まとめ

48歳で会社を辞めた直後、
私は自分がエンジニアとしてどこまで通用するのか分からなくなりました。

それでも技術を学ぶことをやめなかったのは、仕事を得るためだけではありません。分からない仕組みを調べ、実際に動かし、「なるほど、こうなるのか」と分かる瞬間が、今でも面白いからです。

40代以降は、若いエンジニアと同じ速さで新しい技術を覚える必要はないと思います。これまでの失敗や判断経験と新しい知識をつなげれば、自分なりの価値を出せます。

毎日長時間勉強しなくても構いません。まずは気になる技術を一つ選び、1時間だけ触ってみる。その程度でも、学びを完全に止めないことには意味があります。

会社や肩書きが変わっても、「これはどう動くのだろう」と考える自分は残りました。

たぶん私は、これから働き方がまた変わっても、PCを開いて何かを試すのでしょう。それが、今もエンジニアを続けている一番の理由です。

ところが、最後まで踏ん張ろうとして心身をすり減らした経験から、考え方が少しずつ変わりました。戦って状況を変えるより、早めに距離を取るほうが自分と仕事を守れることもあります。

アニメ『とんでもスキルで異世界放浪メシ』の第1話で、主人公のムコーダは召喚された王宮の空気に違和感を覚え、勇者になる道から早々に降ります。その姿を見て思い出したのが、私がIT業界で身につけてきた「戦わずに生き残るための判断」でした。

危険な現場の見分け方、技術との付き合い方、既存ツールを使う判断について、失敗も含めて振り返ります。

危険な現場では、戦う前に距離を考える

ムコーダは、王宮のきらびやかな雰囲気に流されず、その裏にある胡散臭さを察して勇者を辞退します。いきなり大きな役割を与えられた状況で断るのは、現実に置き換えると簡単なことではありません。

会社でいえば、平社員が突然社長の前に呼ばれ、「重要なプロジェクトを任せる」と言われた直後に辞退するようなものです。普通なら期待に応えようとしますし、断った後の立場も気になりますよね。

それでも、危険だと思った段階で離れる。ムコーダの判断には、単なる臆病さではなく、状況を見る冷静さがありました。

損切りできずに心身を消耗した経験

私自身、以前はプロジェクトの空気がおかしくても、なかなか離れられませんでした。会議を重ねても方針が決まらず、責任の押し付け合いが増え、残業だけが積み上がっていく。それでも「最後までやり遂げるのがプロだ」と自分に言い聞かせていました。

今思えば、かなり無理をしています。
それでも当時は、途中で降りることを逃げだと思っていました。

結果として、過労で心身を摩耗しました。仕事を続けるために踏ん張っていたはずなのに、仕事そのものができなくなりかねない状態まで自分を追い込んでしまったのです。

生き残るためには、最後まで耐えることより、危険な状態を早めに認めることのほうが大切な場合があります。

もちろん、気に入らないことがあればすぐ辞めればよい、という話ではありません。ただ、次のような状態が続くなら、我慢だけで解決しようとしないほうがよいと思います。

• 方針が何度も変わるのに、責任者が判断しない
• 問題を報告した人が責められる
• 残業や休日対応が一時的ではなく常態化している
• 心身に異変が出ても、相談先が機能していない

当時の私は、こうした兆候を見ながら「もう少し頑張れば終わる」と考えていました。でも、終わらない現場は本当に終わりません。泥舟から降りる決断が遅れるほど、失うものは大きくなります。

即レスと関わる範囲で自分を守る

その経験以降、私はすべての問題に正面からぶつからないようになりました。役割として必要な仕事はしますが、感情まで巻き込まれないよう、関わる範囲を意識しています。

たとえば、業務上の連絡にはなるべく早く、要点だけを返します。即レスというと、何でもすぐ引き受ける印象があるかもしれません。私の場合は反対で、「確認しました」「この内容で進めます」「対応期限は何日です」と短く返し、やり取りを曖昧にしないために使っています。

返事を先延ばしにすると、相手との間に余計な解釈や感情が入りやすくなります。一方で、用件を明確に返しておけば、必要以上に距離を詰められにくくなりました。

不毛だと思う飲み会を断ることもありますし、「この人とは深く関わらないほうがよい」と思ったときは、必要なやり取りだけにとどめます。正直、若い頃はそこまで割り切れませんでした。

組織の中では、すべての人と分かり合えるわけではありません。それでも仕事は進められます。相手を変えようとして消耗するより、自分が関わる範囲を決めるほうが現実的でした。

特定の技術だけに頼らない

ムコーダが持つ固有スキルは、剣術や魔法ではなく「ネットスーパー」です。異世界で現代の商品を購入できる、一見すると地味な能力でした。

でも彼はその能力で食料や調味料を調達し、自分の生活を成り立たせていきます。戦闘力がなくても、使える道具を理解して活用すれば生きていける。その発想は、IT業界にもかなり近いものがあります。

得意な技術が古くなる怖さ

エンジニアとして働いていると、特定の言語やフレームワークを深く学ぶ時期があります。私にも「この技術があれば、しばらく仕事には困らない」と思っていた時期がありました。

ところが現場で求められる技術は変わります。以前は多くの案件で使われていたものが、数年後には別の技術へ置き換わり、募集自体が少なくなることもあります。

自分が時間をかけて覚えた技術が、急に過去のものとして扱われる。あの感覚は今でも忘れられません。積み上げてきたものが無駄になったようで、かなり焦りました。

ただ、後になって分かったのは、学んだ内容がすべて無駄になるわけではないということ。設計の考え方、エラーの追い方、仕様を読み解く力は、道具が変わっても残ります。

問題になるのは、特定の製品名や技術名だけを自分の強みにしてしまうことでした。

AIや新しい道具を試し続ける

現在は、私もAIを実務で試しています。複雑なコードの原因を整理するときや、テスト項目のたたき台を作るとき、要件を言葉にし直すときなど、以前は一人で長時間考えていた作業をAIと一緒に進めるようになりました。

最初からうまく使えたわけではありませんし、曖昧な指示を出して、まったく役に立たない回答が返ってきたこともあります。

「これなら自分でやったほうが早い」と思ったことも一度ではありません。

それでも、依頼内容を細かく分けたり、前提条件を伝えたりするうちに、使える場面が見えてきました。以前なら数時間かけていた構造整理が、短い時間で進むこともあります。

ここで大事なのは、AIという特定の道具を信じ切ることではありません。新しい道具が出たときに、触らず否定するのでも、何でも任せるのでもなく、自分の仕事に使える範囲を確かめることです。

ムコーダも、ネットスーパーがあるだけで生き残ったわけではありません。何を買うか、どう料理するか、誰とどう関わるかを考えたからこそ、能力を生かせています。

私たちも同じで、道具そのものより、
使いどころを判断できる状態を保つことが大切なのだと思います。

自前開発へのこだわりを手放す

ムコーダの料理では、異世界の食材に現代の調味料を組み合わせます。生姜焼きのたれやコンソメなど、すでに完成されているものを利用して、おいしい料理に仕上げていきます。

これを見ていると、開発現場におけるライブラリや外部サービスの活用を思い出します。何でも一から作らなくても、既存のものをうまく組み合わせれば価値は生み出せます。

ゼロから作って遅延させた失敗

若い頃の私は、「全部自分で作ること」にエンジニアらしさを感じていました。既存ライブラリを使うより、仕組みから理解して自前で実装するほうが技術力の証明になると思っていたのです。

あるとき、社内システムで使うUIコンポーネントを、標準的なライブラリに頼らず、自前のCSSとJavaScriptで作りました。最初は自由に調整できて、良い選択に思えました。

ところが、ブラウザごとの表示差や細かな操作の違いが次々に出てきます。ひとつ直すと別の場所が崩れ、確認作業ばかりが増えました。

結局、本来進めるべき機能開発が遅れ、保守しづらいコードも残りました。柔軟性を求めたつもりが、自分で複雑さを増やしていたわけです。

あのときは、既存ツールを使うことを「手抜き」のように考えていました。でも実際には、使えるものを選び、問題なく組み込むことにも知識と判断が必要です。

既存ツールを使うときの判断

もちろん、既存ライブラリや外部サービスを何でも使えばよいわけではありません。更新が止まることもあれば、セキュリティ上の問題が見つかることもあります。

私が今確認するのは、主に次の点です。

• 現在も更新や保守が続いているか
• 利用者が多く、情報を探しやすいか
• 不具合が起きたときに置き換えられるか
• 導入によって、本当に作業や保守が楽になるか

既存ツールを採用する場合でも、仕組みをまったく理解しなくてよいとは思いません。最低限の動作や制約を理解しないまま使うと、問題が起きたときに手が止まります。

それでも、すでに解決されている課題を毎回ゼロから作り直す必要はありません。限られた時間を、利用者が本当に必要としている機能に使う。そのほうが、仕事としては価値が高いことも多いです。

自分で作れることと、自分で作るべきことは別です。

この違いに気づくまで、私はずいぶん遠回りしました。

戦わない選択は逃げではない

IT業界では、新しい技術を覚え続けることや、難しい案件を乗り越えることが評価されやすい傾向があります。そのため、つらい状況から離れたり、既存ツールに頼ったりすると、「自分は逃げているのではないか」と不安になる人もいるかもしれませんね。

私も以前はそうでした。

しかし、無理をして体調を崩せば、長く働くことはできません。特定の技術に執着して環境の変化を拒めば、選べる仕事は減っていきます。すべてを自前で作ろうとすれば、本当に必要な仕事へ時間を使えなくなります。

52歳になった今は、何に挑むかと同じくらい、何から離れるかも重要だと思うようになりました。戦う価値のない問題まで背負わず、自分の力を使う場所を選ぶ。それは逃げではなく、経験を重ねたからこそできる判断です。

もちろん、離れることには怖さがあります。
慣れた職場、得意な技術、自分なりの仕事の進め方を手放すのは簡単ではありません。

それでも、「今の状態を続けるほうが安全なのか」は、一度立ち止まって考えたほうがよいでしょう。慣れていることと、安全であることは同じではありません。

ムコーダは、用意された勇者の道を降り、自分の能力を使える場所へ移動しました。彼のように大きな決断をすぐ下す必要はありませんが、危険な場所で無理に戦い続けないという考え方は、現実の仕事でも役立ちます。

まとめ

IT業界で生き残るために必要なのは、何にでも正面から立ち向かう強さだけではありません。

危険なプロジェクトや人間関係から距離を取り、特定の技術だけに依存せず、すでにある道具を賢く使う。こうした判断も、長く働くための力になります。

私自身、損切りできずに心身を消耗し、自前開発にこだわって仕事を遅らせ、技術の変化に焦った経験がありました。その失敗があったからこそ、今は「戦うべき問題か」「離れたほうがよい問題か」を考えるようになっています。

何かに正面からぶつかるべきか迷ったときは、戦わない選択も忘れないでください。自分を守りながら力を発揮できる場所へ移ることも、IT業界で生き残るための立派な判断だと思います。

教室へ通う一方で、当時大好きだった映画『バック・トゥ・ザ・フューチャー』のシナリオを片手に、同じ場面を何度も見返しました。聞き取れないセリフを確認し、もう一度再生する。効率のよい勉強法だったかは分かりませんが、不思議と苦にはなりませんでした。

その英語が、やがて海外の友人とのメール交流につながり、私の世界を大きく広げてくれました。

この記事では、英語を学ぶことで人生が急に華やかになった、という話ではありません。好きな映画から始めた学びが、人とのつながりや考え方をどう変えていったのか、実体験をもとにお話しできればと思います。

社会人になってから英語を学び始めた

若いころの私は、海外へ漠然とした憧れを持っていました。

ただ、英語が得意だったわけではありません。学校で勉強した文法や単語は知っていても、実際に会話するとなると言葉が出てこない。相手の英語を聞き取ることも簡単ではありませんでした。

それでも、社会人になってから英会話教室へ通い始めました。

仕事が終わったあとに教室へ向かうのは、正直、面倒に思う日もあります。疲れている日は、日本語でさえあまり話したくありません。それでも続けられたのは、勉強というより、知らない世界へ少し近づく時間だと思えたからでしょう。

教室では、間違えるのが恥ずかしくて、簡単な言葉しか出せないこともありました。頭の中ではもう少し複雑なことを考えているのに、口から出るのは短い表現だけです。

「自分はこんなことしか言えないのか」

そう落ち込むこともありました。
ただ、通じない経験を何度かすると、完璧な文を作ってから話そうとする癖が少しずつ減りました。

知っている単語を並べる。身振りを使う。言い直す。

英語を学び始めて最初に変わったのは、語彙力よりも、間違ったままでも伝えようとする姿勢だったのかもしれません。

好きな映画を繰り返し見た

英会話教室だけでは、英語へ触れる時間が足りないと感じました。

そこで使ったのが、映画『バック・トゥ・ザ・フューチャー』のシナリオでした。

私は何度見ても飽きないほど、この映画が大好きでした。好きな作品なら、同じ場面を繰り返しても苦にならない。そう考えたのです。

聞き取れないセリフを何度も確認した

最初は、字幕を見れば分かるセリフでも、英語だけではほとんど聞き取れませんでした。知っている単語なのに、音になると別の言葉に聞こえる。話す速さについていけず、文の途中で置いていかれます。

そこで、本屋さんでシナリオを見つけ、それを見ながら同じ場面を何度も再生しました。

一文だけ確認するつもりが、気づけば前後の場面まで見てしまうこともあります。まあ、勉強というより普通に映画を楽しんでいただけかもしれません。

それでも、繰り返すうちに少しずつ音が言葉として聞こえるようになりました。一度聞き取れるようになると、そのセリフだけは妙にはっきり耳に入ります。

昨日までノイズのように聞こえてた音が、急に意味を持つ。あの感覚はうれしいものでした。

教材より感情のある言葉が残った

映画の英語は、教科書の例文とは違います。
驚いたときの声、言い争うときの速さ、相手へためらいながら話す間。その場面の感情と一緒に言葉が入ってきます。

だからでしょうか。机で覚えた表現より、映画で聞いた言い回しのほうが後まで残ることがありました。もちろん、映画を見るだけで会話ができるようになったわけではありません。

聞いた表現を自分で使おうとして、不自然な言い方になったこともあります。相手に聞き返されて、「映画では通じていたのに」と困ったこともありました。

それでも、好きな作品を通じて英語へ触れる方法は、学習を続けるうえで私には合っていました。

社会人の学びでは、効率だけでなく、
何度でも戻りたくなる題材を選ぶことも大切だと思います。

覚えた英語を海外交流で使ってみた

英語を学んでいても、使う相手がいなければ、自分がどこまで伝えられるのか分かりません。そこで当時の私は、ネットを通じて海外の人とメールを交わすようになりました。

思えば30年ほどの前になるでしょうか。今のように翻訳機能やAIが簡単に使える時代ではありません。短いメールを書くにも、辞書を引きながらかなり時間をかけていました。

送信ボタンを押す前には、何度も文章を読み返します。失礼な表現になっていないか。意味が逆になっていないか。冗談のつもりが、相手を困らせないか。

最初のころは、数行のメールでも緊張しました。それでも、返事が届くとうれしいものです。

自分の書いた英語が遠く離れた相手へ届き、相手の日常や考えが返ってくる。それまで英語は勉強する対象でしたが、このとき初めて、人とつながるための道具になりました。

英語力より知りたい気持ちが会話を続けた

海外の友人とのやり取りでは、
語彙が足りず、うまく説明できないことが何度もありました。

日本の習慣をどう説明すればよいのか分からない。相手の国の制度や文化について、前提知識がなくて質問の意味を取り違える。

ただ、分からないからこそ、もう一度聞きます。

「それはどういう意味ですか」
「あなたの国では普通なのですか」
「日本ではこうですが、そちらではどうですか」

英語が上手だったから交流が続いたのではありません。相手のことをもっと知りたいという気持ちがあったから、辞書を引き、言葉を探し、やり取りを続けられたのだと思います。

言葉が不完全でも、質問し合えば少しずつ分かります。逆に、英語が正しくても、相手への関心がなければ会話は続きません。

この経験から、外国語は能力を見せるためのものではなく、相手を理解するために使うものだと思うようになりました。

違う日常に触れて自分の常識が揺れた

海外の友人と話していると、
自分が当たり前だと思っていたことが、相手には当たり前ではないと分かります。

仕事への考え方、家族との距離、休日の過ごし方。似ている部分もあれば、驚くほど違う部分もありました。

最初は、どちらが正しいのかを考えてしまいます。でもやり取りを続けるうちに、正解が一つではないことを実感しました。

同じ出来事でも、育った環境や文化が違えば受け止め方も変わります。これは、その後の仕事でも役立ちました。

自分と異なる意見を聞いたとき、すぐに「分かっていない」と決めつけず、相手には別の前提があるのではないかと考えるようになったからです。

英語を通じて広がったのは、交流相手の数だけではありません。物事を見る角度そのものが増えました。

英語が仕事と人生の選択肢を広げた

英語を学び始めたとき、私は将来を細かく計画していたわけではありません。海外の友人と交流することも、仕事で英語を使うことも、最初から決めていたわけではありませんでした。

それでも、学び続けていると、
英語を使えることが次の機会につながりました。

海外の人とのやり取りへ抵抗が少なくなり、仕事でも国外のメンバーと話す場面に入りやすくなりました。

もちろん、ネイティブのように話せたわけではありません。聞き取れないこともありますし、会議で言いたい表現が出てこないこともありました。それでも、分からないまま黙るのではなく、確認しながら話すことはできました。

若いころに映画のセリフを何度も聞き返した経験も、海外の友人へ辞書を引きながらメールを書いた経験も、そこで生きてきます。そして、そうした交流の積み重ねの先に、今の私の生活へつながる大切な縁も生まれました。

英語を学べば、誰にでも同じ出来事が起きるわけではありません。英語そのものが人生を変えてくれるわけでもないでしょう。ただ、英語がなければ出会えなかった人や、知ることのなかった考え方が、私には確かにありました。

英語は人生の答えではなく、それまで見えなかった選択肢へ手を伸ばすための道具でした。

英語学習だけで人生が変わるわけではない

「英語を学べば人生が変わる」と言うと、少し大げさに聞こえるかもしれません。

実際、単語帳を覚えたり、資格を取ったりするだけで、暮らしが急に変わるわけではありません。私の場合も、英会話教室へ通っただけでは大きな変化は起きませんでした。

映画で聞いた言葉を楽しみ、メールで実際に使い、海外の人と関係を続けた。その行動が重なって、結果として人生の範囲が広がりました。学んだものを外で使うことが大切だったのです。

これは英語に限りません。

新しい技術や道具を身につけても、それを持っているだけでは何も起きないことがあります。『とんでもスキルで異世界放浪メシ』のムコーダも、ネットスーパーという能力を持っているだけでは、フェルとの関係は生まれません。

食材を選び、自分で調理し、相手へ差し出したからこそ、その能力が価値に変わりました。英語も同じだったように思います。

知っている単語の数より、それを使って誰と話したか。どんなことを知ろうとしたか。そのほうが、私の人生には大きく影響しました。

英語学習を始めるなら、最初から立派な目的がなくても構いません。

好きな映画を字幕なしで少し聞いてみたい。海外の人へ短いメッセージを書いてみたい。そんな小さな目的でも十分です。

学んだ言葉を外へ出してみると、思っていなかった反応が返ってきます。そのやり取りの中に、次の学びや出会いが生まれるのだと思います。

まとめ｜英語は人とつながる選択肢を増やしてくれた

私にとって英語学習の一番大きな成果は、難しい表現を覚えたことでも、流ちょうに話せるようになったことでもありませんでした。

それまで接点のなかった人と、直接やり取りできるようになったことです。

英語が完璧でなくても、知りたいことを尋ね、自分の考えを伝えようとすれば、交流は始められます。そこから何が生まれるかは分かりません。仕事につながることもあれば、考え方を揺さぶられることもあります。

私のように、その後の暮らしへつながる大切な縁が生まれる場合もあるでしょう。ただし、英語が自動的に人生を変えるわけではありません。

覚えた言葉を使い、相手へ関心を持ち、関係を続けようとしたとき、初めて新しい扉が開きます。

英語を学ぶ意味に迷っているなら、遠い将来の成果だけを考えなくてもよいと思います。好きな映画の一言を聞き取る。短い英文を誰かへ送ってみる。その小さな行動が、今いる場所の外側へつながるきっかけになるかもしれません。

顧客の要望を受ければ現場が苦しくなり、断れば関係が悪くなるかもしれません。実際、夜遅くまで調整メールを書き直しながら、返事を決められないこともありました。

今回は、板挟みの中で、現場を守るために見直した対応を紹介します。

要求をそのまま開発へ流さない

納品先の担当者から追加の修正を頼まれると、以前の私は、そのまま開発メンバーへ伝えていました。

「顧客が必要だと言っているのだから、仕方がない」

そう考えていたのです。
早く返事をすることが、顧客への誠実な対応だと思っていた部分もありました。

でも、顧客から見れば小さな変更でも、開発側では話が違います。

例えば、画面上の項目を一つ追加するだけに見えても、実際には入力チェック、データベース、帳票、テスト項目まで確認が必要になり、一か所の変更だとしても、裏側では複数の担当者が動かなければなりません。

あるとき、納期が迫った段階で追加修正を受け、そのまま朝の打ち合わせでメンバーへ伝えたことがありました。私が説明を始めると、何人かが目を伏せ、会議室の空気が重くなりました。強く反対する人はいませんでしたが、「また増えるのか」という気持ちは伝わってきます。

要求を右から左へ流すだけでは、調整役とは言えないのではないか。

そう思い、それからは顧客から要望を受けても、その場で「対応します」と約束しないようになりました。当然費用もその分増えることになりますしね。

まず開発側へ持ち帰り、次の点を確認します。

• どの機能に影響するのか
• 作業とテストに何日必要か
• 現在の納期を守れるのか
• 先に予定していた作業と入れ替えられるのか
• 一部対応や別の方法で代替できないか

実際に開発メンバーへ確認すると、「修正自体は半日でも、関連テストに二日かかる」とか「影響範囲が広く1週間から2週間かかる」と分かる場合もあります。

顧客との会話だけでは見えなかった大きな負担です。

顧客の要求を受け取ることと、その場で実施を約束することは全く別。今なら、「影響範囲を確認し、明日までに回答します」と伝えます。

返事を保留するのは逃げではありません。曖昧なまま引き受け、後から納期や品質の問題を出すほうが、顧客にも迷惑をかけるものです。

現場の限界を具体的に伝える

顧客へ事情を説明するとき、
私はメールだけで済ませず、できるだけ対面で話すようにしていました。

以前は、相手を怒らせないように言葉を選び、夜遅くまでメールを書き直すことがありました。

「現状では難しいと思われます」
「可能であれば次回にお願いできないでしょうか」

柔らかく書こうとするほど、何が問題なのか分かりにくくなります。顧客から「結局、できるのですか」と聞き返されたこともありました。

そこで、単に「忙しい」「人が足りない」と訴えるのではなく、追加要求によって何が起きるのかを具体的に伝えるようにしました。

例えば、次のように説明します。

• 「今回の修正を追加すると、予定していた総合テストを1週間短縮する必要があります」
• 「納期を変えない場合、別の機能を次回へ回す判断が必要です」
• 「この部分だけなら対応できますが、全面的な変更には追加日数が必要です」

顧客が知りたいのは、開発側が大変かどうかだけではありません。追加要求を入れると何が変わるのか。予定どおり進めたいなら、何を諦める必要があるのか。その判断材料です。

ある追加依頼では、担当者は「画面を少し直すだけ」と考えていました。しかし関連する確認作業まで説明すると、「そこまで影響するなら今回は見送る」と判断してくれました。こちらが拒否したのではなく、影響を理解したうえで、顧客自身が優先順位を選んだ形です。

現場を守るには、苦しさを訴えるより、相手が選べる材料を示す必要があります。

こちらの都合だけを説明しても交渉は進まないため、その要求がなぜ必要なのかの確認も重要です。

• 「今回の運用開始時点で必須なのでしょうか」
• 「どの利用者から強く求められているのでしょうか」
• 「機能そのものではなく、別の方法でも目的を満たせますか」

詳しく聞くと、実際には機能追加そのものが目的ではなく、顧客担当者が上司へ改善状況を示したいだけだったこともあります。

目的が分かれば、簡単な暫定対応や資料の追加で解決できる場合がありますし、最初の要求どおりに作る必要がないこともあるのです。

断るのではなく対応を分ける

無理な要求を受けたとき、「全部やる」か「全部断る」かで考えると、どちらかに負担が偏ります。そこで私は、要求を細かく分けるようにしました。

例えば、複数の修正を一度に求められた場合は、次のように整理します。

• 運用開始に必要な部分は今回対応する
• 見た目の改善は次回へ回す
• 大きな作り直しは別見積もりにする
• 手作業で代替できる部分は暫定運用にする

ある案件では、顧客から複数の画面変更をまとめて求められました。

すべてを対応すると納期に間に合いません。そこで開発メンバーと確認し、利用頻度が高い画面だけを先に直し、それ以外は次回の更新候補に分けました。

顧客には、今回対応する項目と後回しにする項目を一覧で示し、さらに後回しにした場合でも業務が止まらないよう、当面の操作方法も説明しました。

「今回はできません」だけでは、担当者も社内で説明しにくいでしょう。

一方で、

• 今回できること
• 今回できないこと
• できない理由
• 次に対応できる時期
• それまでの代替手段

が整理されていれば、相手も持ち帰って話しやすくなります。

顧客の顔を立てるとは、言われたことをすべて引き受けることではありません。担当者が社内で説明し、判断できる材料を用意することだと、私は考えるようになりました。

もちろん、毎回きれいにまとまったわけではありません。

顧客から「何とか今回入れてほしい」と押され、開発側からは「また受けるつもりですか」と言われたこともあります。

どちらにも理解されていないように思い、「調整役なんて割に合わないな」と感じた夜もありました。板挟みになると、どちらか一方の味方をしたほうが楽に思えることもありますよね。

それでも、要求を一度止め、影響を確認し、誰か一人へ負担を寄せない形を探しました。やがて開発メンバーからも、追加要求が来たときに「まず確認してから返してくれる」と思ってもらえるようにもなりました。

すべての不満をなくせなくても、
要求がそのまま降ってこないだけで、現場の受け止め方は変わります。

板挟みで結論に迷ったとき、私は次の二つを確認していました。

• 誰か一人に負担を押しつけていないか
• 顧客と開発の両方へ理由を説明できるか

全員が満足する答えがなくても、この二つに答えられる判断なら、少なくとも無責任な丸投げにはなりません。

まとめ

顧客と開発の板挟みになったとき、要求をそのまま現場へ流すと、開発メンバーの負担が積み重なります。反対に、現場の事情だけを理由に断れば、顧客との関係が悪くなるかもしれません。

私が意識したのは、まず要求の影響を確認し、納期や品質に何が起きるのかを具体的に伝えることでした。そのうえで、今回対応する部分、次回へ回す部分、別の方法で代替する部分に分けます。

すべてを受ける必要はありませんが、ただ断るだけでも話は進みません。相手が判断できる材料を示し、現場にも無理をさせない着地点を探すことが大切です。

板挟みになると、どちらにも不満を持たれているように思うことがありますよね。それでも、要求を一度止めて整理し、誰か一人に負担を押しつけない判断を続けることが、現場を守ることにつながると思います。

私は技術や現場の近くで働くことが好きで、昇進すれば、自分らしい仕事から離れてしまうように思えたのが理由ですが、周囲からは「せっかくの機会なのだから受けるべきだ」と何度も言われました。

この記事では、私がなぜ昇進を断り続けたのか、受ける前に何を確認したのか、上司のどの言葉で決断したのかを振り返ります。昇進を受けるか迷ったときに、肩書きや周囲の期待だけで決めず、自分に合う選択を考えるための判断材料になればうれしいです。

室長への昇進を数年間断った理由

メーカーに勤めていた頃、上司から「早く上に行け」と何度も言われました。

打診されたのは「室長」という役職です。会社によって違いはありますが、当時の職場では、その受け持つ範囲から、課長と部長の中間に近い立場でした。

周囲から見れば、断る理由はあまりなかったのかもしれません。仕事ぶりを認められ、より大きな役割を任せたいと言われているのですから、本来なら喜ぶ場面でしょう。

でも、当時の私は強く拒みました。

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

そんな気持ちが強かったからです。

私はシステムの不具合を調べたり、設計についてメンバーと話したり、実際の仕事が動いている場所にいることが好きでしたし、役職が上がれば、会議や調整、人の評価が増え、技術に直接触れる時間が減っていくように思えました。

正直に言えば、人をまとめる役割が自分に務まるのかという不安もったんですね。

技術的な問題なら調べて答えを出せます。でも人の感情や評価、組織の事情が絡む問題には、必ず正解があるわけではありません。そこへ自分から飛び込むことに、なかなか気持ちが向きませんでした。

周囲へ相談すると、返ってくるのは「チャンスなのだから受けたほうがいい」という意見がほとんど。確かに、昇進の機会はいつでも来るとは限りませんし、断れば、次は声がかからない可能性もあります。

それでも私は、「周囲が受けろと言うから」という理由だけでは決められませんでした。

昇進をためらうと、「責任から逃げたいだけなのでは」という思いもありました。でも今振り返ると、あの迷いを無理に押し込めなくてよかったと思います。

昇進によって得られるものだけでなく、自分が失いたくないものを考える時間になったからです。

昇進を受ける前に確認した判断基準

数年間迷う中で、「昇進したいか、したくないか」だけでは決められないと考えるようになりました。

感情だけで拒めば、後から後悔するかもしれません。反対に、肩書きや周囲の期待だけで受けても、役割が自分に合わなければ苦しくなります。

そこで私は、主に次の点を確認しました。

• 現場や技術からどの程度離れるのか
• 増える責任に見合う裁量があるのか
• 自分の経験を何に使う役割なのか
• 数年後も今の働き方を続けたいのか

最も気になっていたのは、
役職に就いたあとも技術判断に関われるかどうかでした。

私は当初、管理職になれば現場の仕事をほぼ手放し、人員や数字の管理だけをすることになると思い込んでいました。でもそれは私が勝手に作っていた管理職像かもしれません。そこで、曖昧な不安のまま断り続けるのではなく、実際に何を求められているのかを上司へ確認することにしました。

また、責任だけでなく、どこまで自分で決められるのかも重要でした。

役職に就けば、トラブル時の説明やメンバーの評価など、重い責任が増えます。その一方で、人員配置や仕事の優先順位を変える権限がほとんどないなら、現場を良くしたくても動けません。

昇進を考えるときは、肩書きではなく、責任・裁量・実際の仕事内容を具体的に確認する必要があります。

「管理職になる」という言葉だけで判断せず、何を任され、何を決められ、何を手放すのか。その中身を見ることで、自分が迷っている理由も少しずつ整理できました。

上司の回答で昇進を決めた

昇進を受ける直前、私は上司に一つ確認しました。

「室長になったら、現場や技術判断からは離れることになるのでしょうか」

私が一番恐れていたのは、肩書きが変わることではなく、これまで積み上げてきた技術経験を使わなくなりったり、会議と管理だけの毎日になることでした。

その質問に対して、上司から返ってきたのは、おおよそ次のような答えでした。

「現場から離れてほしいわけではない」
「これまでの技術経験を、個別の案件だけでなく、もっと広い範囲の判断に使ってほしい」

その言葉を聞いて、私の中で管理職の見え方が変わりました。

自分でコードを書いたり、すべての不具合を直接調べたりする時間は減るでしょう。でも、どの案件に人を配置するか、どのリスクを先に潰すか、どの技術へ投資するかを決める場面で、これまでの経験を使えます。

技術を捨てるのではなく、使う場所が変わる。

そう考えられたことが、
最後に昇進を受け入れた大きな理由でした。

もう一つ、上司の言葉から感じたのは、会社が求めていたのは「管理職らしい人間になること」ではなく、私が現場で身につけた判断を組織へ広げることだった、という点です。それなら、自分らしさをすべて変える必要はないかもしれません。

昇進を受け入れたのは、不安が消えたからではなく、自分の経験を何に使う役割なのかが分かったからです。

数年間迷った時間も無駄ではありませんでした。すぐに受けていたら、肩書きに自分を合わせようとして、必要以上に無理をしていたかもしれません。

何を失いたくないのかを考え、その点を上司へ直接確認した。だからこそ、納得して役職を引き受けられました。

役職に就いても守ったこと

役職に就いたあと、技術に直接触れる時間は以前より減りました。それでも、現場で何が起きているのか分からない管理職にはなりたくないと思っていました。

そのため、重大な技術判断や、過去のトラブルと似た危険がある案件については、資料や報告だけで済ませず、担当者の話を直接聞くようにしました。

ただし、自分が細かな作業まで引き取るのではありません。私が守ろうとしたのは、「自分で手を動かし続けること」ではなく、現場の難しさを理解したうえで判断することでした。

管理職になってから気づいたのは、技術経験は、コードを書く以外にも使えるということです。

・無理な納期を見抜くこと、
・危険な設計を早めに止めること、
・現場の説明を上層部へ伝わる形に直すこと。

そうした場面でも、技術者としての経験は役立ちました。

現場を離れることが不安な人は、「今までと同じ仕事を続けられるか」だけでなく、「その経験を別の形で使えるか」を確認してみてもよいと思います。

まとめ

昇進を断ることは、必ずしも逃げだとは限りません。大切なのは、何が不安なのかを曖昧にしないことだと思います。

責任が増えることなのか、現場を離れることなのか、裁量がないまま仕事だけ増えることなのか。理由によって、確認すべき内容は変わります。

私の場合は、上司へ「役職後も技術判断に関われるのか」を確認し、技術を捨てるのではなく、より広い範囲で使う役割だと分かったことで決断できました。

昇進を受けるか断るかだけでなく、その立場で何を任され、自分の経験を何に使えるのか。そこまで確かめることが、後悔を減らす判断につながると思います。

会議室でそう告げられたとき、すぐには意味を理解できませんでした。

何度も海外へ出張し、現地のメンバーと仕様を詰め、これから数年かけて育てていく仕事だと思っていたからです。自分のキャリアの中心になるかもしれない。そんな期待もありました。

それが、現場とは別の判断で突然なくなりました。

悔しいというより、最初は何も考えられませんでした。でも一方で、過酷な日程から解放された安堵もあり、その気持ちが余計に自分を戸惑わせました。

この記事では、数年続くと思っていた海外共同プロジェクトが突然中止になった経験から、仕事が消えた後にどう受け止め、何を次へ持っていけばよいのかをお話しします。

数年続くと思っていた仕事が突然消えた

そのプロジェクトは、
海外のメンバーと共同で進める大規模な案件でした。

仕様の認識を合わせるだけでも簡単ではありません。言葉の違いだけでなく、仕事の進め方や判断の基準も異なります。

メールだけでは伝わらないため、何度も現地へ出向きました。

会議では、一つの表現をめぐって長く議論することもあります。こちらでは当然だと思っている前提が、相手には共有されていない。逆に、相手の説明を聞いて初めて、自分たちの考え方が国内だけの常識だったと気づくこともありました。

大変でしたが、面白さもありました。

少しずつ相手との呼吸が合い、以前なら何時間もかかった確認が短時間で終わる。別々の組織だったメンバーが、一つのチームになっていく感覚がありました。私は、この仕事が数年続くと思っていました。

ところが、ある日突然、上層部から中止が伝えられました。

詳しい理由は現場まで十分には共有されませんでしたが、おそらく経営上の判断や、事業環境の変化があったのでしょう。それまでに費やした時間や、現地で積み重ねた議論とは関係なく、仕事は終わりました。

現場がどれだけ努力しても、
プロジェクトは現場以外の理由でなくなることがあります。

頭では分かっていたつもりでしたが、
自分の仕事として実際に起きると、簡単には受け止められませんでした。

中止を知らされた直後は何も考えられなかった

会議室を出た後、周囲の誰もあまり話しませんでした。

怒っている人もいたと思います。理由を知りたがっている人もいたでしょう。ただ、その場では皆、言葉にするところまで気持ちが追いついていませんでした。

私も同じでした。

「今までやってきたことは何だったのか」
「もう少し続けていれば形になったのではないか」
「現場の説明を聞く機会はなかったのか」

いろいろな考えが浮かびます。
ただ、強い怒りだけではありませんでした。

これで海外出張や厳しい日程から解放される。少し休める。そう思った自分もいました。

悔しいのに、ほっとしている。

その二つが同時にあることが、自分でも嫌でした。あれだけ力を注いだ仕事なのだから、もっと純粋に悔しがるべきではないかと思ったのです。

今なら、どちらも自然な反応だったと思えます。仕事が終わった喪失感と、負担から解放された安堵は、同時にあってもおかしくありません。

無理に前向きになろうとせず、
「今は力が抜けている」と認めたことで、少しずつ状況を整理できるようになりました。

「努力が無駄になった」と考えるほど苦しくなった

プロジェクトが中止になると、最初に浮かぶのは「全部無駄になった」という思いでした。完成しなければ、製品にもサービスにもなりません。利用者へ届くこともありません。

成果物だけを見れば、確かに残らないものは多くあります。ただ、その考え方だけでは、費やした時間まで否定することになります。

何度も海外へ行ったこと。文化や前提の違う相手と議論したこと。曖昧な仕様を言葉にし、互いに理解できる形へ直したこと。

それらもすべて消えたのかと考えると、そうではありませんでした。

完成しなかった仕事にも残るものがあった

別の案件を担当したとき、
海外メンバーとのやり取りで身につけた説明の仕方が役立ちました。

専門用語をそのまま使わず、前提から説明する。相手がどこまで理解しているか確認する。決まったことだけでなく、決まっていないことも明確にする。

当時は、そのプロジェクトを進めるために必要だから行っていました。でも、中止後もその力は残りました。

仕様を細かく整理した経験も、後のレビューで役に立ちました。相手と意見が合わないとき、正しさをぶつけるのではなく、判断の前提を確認する癖もつきました。

完成した成果物は残らなくても、
仕事の進め方は自分の中に残っていたことに気が付きました。

結果と経験を分けて考えた

結果が出なかったことまで、無理に成功だと言い換える必要はありません。

プロジェクトは中止になりました。それは事実です。悔しさもありましたし、もっと説明がほしかったという思いも残りました。

ただ、結果が出なかったことと、その過程で何も得なかったことは別です。この二つを分けて考えられるようになってから、少し気持ちが楽になりました。

仕事の成果が消えても、
その中で身につけた判断や技術まで消えるわけではありません。

「無駄ではなかった」と無理に納得するのではなく、何が失われ、何が残ったのかを分けて見る。そのほうが、次へ進みやすかったです。

立ち直るために行ったのは振り返りだった

プロジェクトが終わった直後は、早く忘れたい気持ちもありました。

関係する資料を見ると、途中で終わった仕事を思い出します。現地メンバーとのやり取りを読み返すと、「続いていれば」と考えてしまいます。

それでも、落ち着いてから一度だけ振り返りました。感情を整理するためというより、次の仕事で同じ時間を無駄にしないためです。

自分で変えられたことを確認した

最初に考えたのは、中止そのものではありません。経営判断を現場の私が変えられた可能性は、ほとんどありませんでした。そこを何度考えても答えは出ません。

一方で、自分の仕事の進め方には振り返れる部分がありました。

• 重要な判断を記録できていたか
• 特定の人しか分からない状態になっていなかったか
• 途中でも転用できる資料を残していたか
• 得た知識を他のメンバーへ共有していたか

プロジェクトが最後まで続く前提で、
作業を抱え込みすぎていた部分もありました。

中止になる可能性まで考えて仕事をするのは難しいです。ただ、途中で終わっても他の案件へ引き継げる形を意識しておけば、残せるものは増えます。

次へ持っていくものを言葉にした

もう一つ行ったのは、
その仕事で得たものを具体的に書き出すことでした。

「海外案件を経験した」という曖昧な言葉では、次に使えません。そこで、もう少し細かく考えました。

異なる前提を持つ相手との仕様調整、会議後の認識違いを防ぐ記録、言葉だけに頼らない図解、決定事項と保留事項の分離。

こうして言葉にすると、次の仕事で何を活かせるかが見えてきます。

プロジェクトそのものへ戻ることはできません。でも、そこで得た方法を次の現場へ持っていけば、完全に切り離された過去ではなくなります。

次の仕事にすぐ情熱を持てなくてもよかった

プロジェクトが終わった後、
すぐに新しい仕事へ夢中になれたわけではありません。

新しい案件を説明されても、どこか冷めた気持ちがありました。「この仕事も、また突然なくなるかもしれない」そう思うと、以前と同じ熱量で入り込むのが怖くなります。

期待しなければ、失ったときの痛みも小さくなる。そんな考えもありました。ただ、仕事へ距離を置きすぎると、自分自身が面白くありません。

そこで、最初から長期的な意味を求めるのではなく、目の前の一つの課題へ集中することにしました。

この資料を分かりやすくする。
この仕様の曖昧さをなくす。
この会議で判断できる状態を作る。

小さな部分で役に立つことを積み重ねるうちに、少しずつ仕事へ気持ちが戻ってきました。

次の仕事が前の仕事の代わりになるわけではありません。なくなったプロジェクトの悔しさも、そのまま残っています。それでも、新しい現場で過去の経験が役立った瞬間に、「あの時間はここにつながっていたのかもしれない」と思えました。

立ち直るとは、すべてを忘れることではないのでしょう。失った経験を抱えたまま、別の場所でまた仕事ができるようになることだと思います。

プロジェクト中止後に確認したいこと

プロジェクトが突然終わると、気持ちの整理だけで精いっぱいになります。そのため、直後に無理をして教訓を探す必要はありません。

少し落ち着いてから、次の点を確認すると、経験を残しやすくなります。

• 途中まで作った資料を転用できるか
• 身につけた技術や進め方は何か
• 次の担当者へ共有すべき知識があるか
• 自分では変えられなかったことは何か
• 次回は早めに残しておきたい記録は何か

特に自分で変えられなかったことと、自分で改善できることを分けるのは大切です。

経営判断まで自分の責任として抱え込むと、必要以上に自分を責めてしまいます。一方で、「上が決めたことだから」とすべてを切り離すと、次へ活かせる経験まで手放すことになります。

自分の責任ではない部分は手放し、自分が持っていける部分は拾う。言葉にすると簡単ですが、実際には時間がかかりました。

まとめ｜消えた仕事から何を持っていくか

プロジェクトが中止になったとき、すぐに前向きな意味を見つける必要はないと思います。悔しいなら悔しいままでよいですし、力が抜けたなら、いったん立ち止まってもよいでしょう。

ただ、少し落ち着いた後で、完成しなかった仕事と、自分に残った経験を分けて考えることはできます。

中止という結果は変えられません。それでも、そこで身につけた説明の仕方、判断の記録、相手との調整、失敗を減らす工夫は、次の仕事へ持っていけます。

私にとって立ち直るきっかけになったのは、「無駄ではなかった」と自分へ言い聞かせることではありませんでした。何が消え、何が残ったのかを一つずつ確かめたことです。

仕事そのものが終わっても、自分までそこで終わるわけではありません。次の現場へ何を持っていくかを決められたとき、ようやく少しだけ前を向けた気がします。