「深夜2時の君は、これで寝直せるか？」ベテランSEが若手に授ける『運用のアンテナ』の立て方

※この記事は個人の体験と知見に基づいています。
医療的な助言ではないこと、また成果を保証するものではありません。　　　　　　　　　　　　
免責事項の全文はこちらをご参照ください。

SE（システムエンジニア）として長年現場に立っていると、メンバーとの間に「どうしても埋まらない溝」を感じる瞬間がある。 その最たるものが、「運用のアンテナ」の感度差だ。

私たちは、設計書の一行を見ただけで、その先に待ち受ける運用保守の苦労、深夜の呼び出し、顧客への謝罪行脚といった「未来の修羅場」が脳裏をよぎる。しかし、目の前の若手エンジニアは、晴れやかな顔でこう言うのだ。 「機能は要件通りです。テストも正常に終わりました」

この温度差はどこから来るのか。なぜ彼らの設計には、あれほどまでに「運用」の視点が抜け落ちてしまうのか。

彼らに想像力がないわけではない。ただ、彼らの脳内には「運用という名のリアルな戦場」のデータが蓄積されていないだけなのだ。 では、経験のない彼らに、どうやってそのアンテナを植え付ければいいのか？

今回は、私が長年の試行錯誤の末にたどり着いた、若手の「自分事化スイッチ」を強制的に入れるための「たった一つの問いかけ」についてお話ししたい。

１．はじめに：なぜ彼らの設計には「運用」が抜けているのか

「機能は要件通りに動きます。テストも通っています」 自信満々にそう報告してくる若手エンジニアの設計書を開き、私は心の中で静かにため息をつく。

そこには、ユーザーがハッピーに使い続けている「正常系」のシナリオは完璧に描かれている。しかし、ひとたび本番環境という荒波に放り出された後に起きる「泥臭い現実」への備えが、驚くほど抜け落ちているのだ。

ベテランSEから見て、彼らの設計に共通して足りないのは、以下の４点に集約される。

• 「死に際」の美学がない
  • エラーが起きた時、システムがどう美しく（あるいは安全に）停止し、後続に何を伝えるべきかという視点。
  • 【過去の苦い経験】
    • エラーが発生した際、ファイルが無駄に消してしまったり、データの状態がよくわからないくなるといった停止の仕方をする機能があった。後続がどうするのかを考えた設計にしないといけない。
• 「証拠」を残す執念がない
  • 障害が起きた際、ブラックボックス化した中身をこじ開けなくても、ログ一行で原因が特定できるような「親切さ」の欠如。
  • 【過去の苦い経験】
    • 必要なログがまったく出ていないサブシステムがあった。この時、ここにログが１行出ているだけで復旧できる障害が、順を追って処理を追いかけ、データを解析し、やっと原因にたどり着くということがあった。
• 「明日へのバトン」がない
  • リリースして終わりではない。数年後の運用担当者が、そのコードを読んで意図を理解できるかという時間軸の欠如。
    • 【過去の苦い経験】
      • ある機能では設計書にかかれていいないコードが散見され、さも迷路を作っているようなコードがあった。このようなコードを読んで運用担当者に何をさせたかったのかわからない。作成者の趣味なのか、後で困らせてやろうという悪意なのかわからないが、迷惑であることには変わりがない。
• 「立ち直り」の速さがない
  • 障害で止まったバッチを「単純に再実行（リラン）」できるか？という視点だ。若手の設計は、中途半端にデータが更新された状態で止まると、手動でデータを修正しない限り再開できない「片肺飛行」の状態になりがちだ。運用担当者が深夜にマニュアルを読み込まなくても、ボタン一つで最初からやり直せる（何度動かしても結果が同じになる）設計は、運用への最大の優しさである。
    • 【過去の苦い経験】
      • 私が若手であるとき、この設計ができておらず、それをレビューしてもらうこともできなかったため、実際に障害が起きた際、関連するテーブルのいくつかのデータを処理実行前に戻してリランする必要があった。かなり緊急性が高いリカバリだったため、冷や汗をかきながら必死にリカバリした経験がある。このことがあってから、リカバリについては詳細に検討し、障害が発生した際は可能限り手数の少なくなるように心がけている。

彼らに悪意があるわけではない。ただ、彼らの脳内には「運用フェーズで起きる修羅場」というデータセットがまだ存在しないのだ。経験がないから、想像力が働かない。これは責めるべきことではなく、私たちが「教えるべき」ことなのだ。

２．魔法の問いかけ：「深夜2時の自分」を想像させる

彼らに「運用の大切さ」を説くとき、概念的な言葉を並べても響かない。「顧客のために」や「品質向上のために」という言葉は、彼らの脳内では、どこか他人事の綺麗なスローガンとして処理されてしまうからだ。

そこで私は、設計レビューの際、彼らに極めて個人的かつ具体的な「呪文」を投げかけることにしている。

「このシステムが深夜2時に止まって、君が電話で叩き起こされた時、5分以内に原因を特定して寝直せるログが出ているか？」

この問いを投げた瞬間、若手の顔色が変わる。それまで画面上のコードしか見ていなかった彼らの視線が、初めて「自分の未来の睡眠」へと向くのだ。

想像力が「自分事」を変える

「深夜2時の呼び出し」という設定は、単なる脅しではない。

• 寝ぼけた頭でも理解できるほどログが明快か？
  • 私の経験上、夜２時に起こされた時、頭が覚醒するまでに少し時間がかかる。この時に電話で言われるのはエラーメッセージの内容のみである。それがすぐに理解できないものであった場合、寝ぼけた頭では処理することができず、掛けてきた人へ何度も聞くことになり、それだけで対応が送れてしまう。
• マニュアルを探さずとも、次に何をすべきかエラーメッセージが教えてくれるか？
  • 当然マニュアルを直ぐに出せる状態にしておくことは重要である。ただ、エラーメッセージを聞いて直ぐに対処できるのであれば、それに越したことはない。障害対応は時間との勝負であるからだ。
• そして、最悪の事態でも「リラン」一つで被害を最小限に抑えられるか？
  • ジョブから出力されているエラーメッセージから、どこで異常終了が発生したのか、そのエラーが発生した際の処理の流れを理解していれば、単純リランで対応できる。という処理にしておくことが大事であり、ジョブが大きくなってこれが難しいのあれば、ジョブを細かい単位に分けて置くことも検討し、ジョブ単位で単純リランできるような作りにしておくことが大事である。

これらを「自分の睡眠を守るための防衛策」として再定義させることで、彼らの脳内に初めて「運用のアンテナ」が立ち始めるのだ。

３．「アンテナ」が立った後の変化――コードに宿る「優しさ」

問いかけを継続していくと、メンバーが書く設計書やコードに明らかな変化が現れ始める。 それは一言で言えば、運用者（未来の自分）への「優しさ」だ。

「なぜ」を語るログへの進化

以前は「エラーが発生しました」という無機質なログだったものが、「〇〇処理のDB更新時にタイムアウト。再試行を推奨」といった、次のアクションを促すログに変わる。これは、彼らが「深夜2時の自分」を救うための言葉をコードに託し始めた証拠だ。

以前はログなんてとりあえず出てて、なんのエラーかわかればいいでしょ？と言っていた若手も、深夜２時の状況を聞いて、可能な限り一目で見てわかるメッセージを意識するようになった。

万が一、自分が呼び出された時を意識するようになった結果だと思っている。

ただ、１点気をつけなければならなくなったのが、深夜２時を意識するあまり、不用意にメッセージに追加する情報量が増えてしまったメンバーがいたことだ。

これも入れた方が・・・、これがあればわかることが・・・、といろいろ考えることは望ましい方向だ。

ｓしかし、メッセージの量が多くなり、オペレータのコンソールを圧迫してしまったり、メッセージ内容をメールで送ったりする際に読みにくくなってしまうという弊害が発生することがあった。この点は事前に基準を決めることで解消できるため、意識が上がった以上のデメリットはないと思っている。

「事後処理」までを見越した設計

ただ機能を作るだけでなく、「もしここで止まったら、このテーブルのフラグをどう戻すべきか？」というリカバリ手順まで、設計段階で考慮されるようになる。問いかけによって「リリース後の世界」が彼らの視界に入ったのだ。

設計書のレビュー依頼が来た時、同じような指摘をしないといけないと思っていたのが、すでにわかりやすい処理の流れ、リカバリを考えた添付資料などが添えられていた。

それだけではなく、事前に運用ではこの処理をどうするべきかを聞いてきてくれるようになった。このことで機能に対する相互理解が進むとともに、運用フェーズになった場合の設計ができるようになった。

レビューする側も、実際に運用する際に見る資料としても、精度が格段に上がっていて嬉しかったのを覚えている。

チームに広がる「安心感」という資産

一人のアンテナが立つと、それはチーム全体に伝播する。レビューの基準が「動くかどうか」から「守れるかどうか」へシフトし、PMである私の脳内の「不信感のビット」も、少しずつ下がっていくのを感じる。

彼らが運用のアンテナを持ってくれることは、私にとって単に仕事が減る以上の意味がある。私の脳内の『あいつの設計、本当に大丈夫か？』という監視プログラムを停止させ、その空いたメモリを『プロジェクトの未来の戦略』に回せるようになるからだ。

４．まとめ――「視点」を授けるのがベテランの真の教育

若手に「運用のアンテナ」を持たせることは、単にプロジェクトの障害を減らすこと以上の意味がある。それは、彼らの視座を一段引き上げ、「機能を作る人」から「システムを守るプロ」へと成長させることに他ならない。

想像力が、若者を絶望から救う

「深夜2時に起こされる怖さ」を説くのは、一見すると厳しいことのように思えるかもしれない。しかし、本当の恐怖は、何も知らずにリリースを迎え、取り返しのつかない大事故を起こして、若者が立ち直れないほどの挫折を味わってしまうことだ。

実際、協力会社の方で、運用作業に異常な恐怖心を持っている人がいた。どうも運用での大きな失敗で恐怖心が付いてしまい、その作業をしなければならないのであれば抜けたいといい、実際のその作業が必須であった私のプロジェクトからは抜けることとなった。

この恐怖心があるがために仕事の範囲を狭めてしまうということはあると思う。そう思うと、失敗したとしても正しいリカバリができる設計になっていることや、単純リランでリカバリできることがわかれば、そういう恐怖から解き放されることもあるかもしれない。

そんな致命的な失敗をする前に、言葉の力で「疑似体験」をさせ、彼らを将来の絶望から守ってあげること。これこそが、30年のキャリアの中で数々の修羅場をくぐり抜けてきた、ベテランPMが渡せる最高に「優しい」バトンなのだ。

最後に：新しい景色に向かって

振り返れば、私自身もかつては「動けばいい」と考えていた若手の一人だった。多くの失敗をし、冷や汗をかきながらリカバリをしたあの夜があったからこそ、今の私がある。

今回、この記事を書きながら、自分の中にある「不信感のビット」の正体を見つめ直すことができた。メンバーを信じ、彼らに「視点」を授けることで、私自身の脳にも新しい余白が生まれるはずだ。

新年の仕事始め、私は少しだけ晴れやかな気持ちでデスクに向かえる気がしている。 私の隣で設計書を広げる若手に、明日もまた、あの問いかけを投げようと思う。 「深夜2時の君は、これで安心して寝直せるか？」と。