ISTJ

22 歳の春。同期 800 人が並ぶ入社式。 壇上の役員の話が長引くなか、ISTJ のあなたは配られた式次第の誤字をひとつ見つけて、こっそり赤ペンで直していた。 配属は、システム開発部の運用・保守チーム。会社の基幹システムを止めずに動かし続ける部署だ。 同期には「地味だね」と言われた。でも ISTJ は内心ちょっとうれしかった。「ここは、手順がある場所だ」。 ISTJ はすぐに頼られた。 誰も最後まで読まない分厚い運用マニュアルを隅から隅まで覚えていた。夜中にシステムが止まっても、慌てない。過去に同じ障害が起きたときの記録を引っぱり出し、手順通りに、淡々と直す。 正直、ISTJ が一日でいちばん落ち着くのは、障害対応チェックリストの一行目にチェックを入れる瞬間だ。本人は、大真面目だ。 ひとつだけ、どうしても飲み込めないものがあった。 それは、制度の面倒くささ——ではない。 Slack で 3 分で決まった話を、わざわざ紙に印刷して、課長、次長、部長とハンコを集めて回る。あれを ISTJ は「むしろ正しい」と思っていた。「記録が残るし、誰がいつ承認したか、後で必ず追えるから」。 飲み込めなかったのは、手順を飛ばす若手のほうだ。「とりあえず動かしてみました」と言われるたび、ISTJ は静かに胃が痛くなった。 25 歳。「サブリーダー、やってみないか」と打診が来た。同じ頃、「海外、行ってみる気はあるか」という話も来た。 ISTJ はどちらも丁寧に断った。 人をまとめることにも、目立つことにも、興味はなかった。自分が守るこのシステムをもっと深く知りたかった。 ——積み上げてきたものを置いて、知らない場所でゼロからやり直す。それが ISTJ には、いちばん落ち着かない生き方だった。

ISTJ の手順好きは、まわりから「頭が固い」と言われがちだ。でも、それはちょっと違う。 手順にこだわるのは、性格が細かいからじゃない。 「前に一度、同じ条件で止まった。だから次は、同じ条件で止めない。そのために手順がある」——理由は、いつもそれだけなんだ。 ただ、その理由を口に出さないから、まわりには「ただの細かい人」にしか見えない。 30 歳。会社は ISTJ にはっきりした分かれ道を示した。 管理職に進むか、専門職トラックに移るか。 管理職になれば、部下が増え、肩書きも上がる。でも、現場のシステムからは少し離れる。 ISTJ は迷わず専門職を選んだ。 「私は、人を動かす役じゃない。このシステムを、誰よりもわかっている人でいたい」。 それからの数年で、ISTJ は本物の専門家になった。 基幹システムのことなら、設計の理由から、十年前に「なぜこの仕様にしたのか」の経緯まで、全部頭に入っていた。 何か障害が起きれば、まず ISTJ に連絡が来る。「あの人に聞けば、必ず直る」。 派手な活躍じゃない。でも、ISTJ がいるだけで、みんなが「うちのシステムは大丈夫」と思えた。 誰も見返さない障害の履歴に原因と直し方を、一件ずつ書き足していく。それが ISTJ の静かな誇りだった。 このまま、定年まで、この場所を守る。 ISTJ は本気でそう思っていた。そして世界は、その「このまま」をあっさりとは許してくれなかった。

35 歳。 ある日、会議室に呼ばれた ISTJ は横文字だらけの資料を渡された。 「うちの基幹システム、来年ぜんぶクラウドに移します」。 若い役員が明るく言った。「もう、古いので」。 古い。 その一言が、ISTJ の頭から、ずっと離れなくなった。 ISTJ は落ち着いて、正しいことを言った。 「移行には、リスクがあります。今のシステムには、二十年分の例外処理が積み重なっている。それを全部洗い出さないと、必ずどこかで止まります」。 正論だった。たぶん、誰よりも。 でも、会議室の空気は「また始まった」という顔だった。 「そういう、できない理由から入るのが、いちばん良くないんですよね」。 ISTJ はそれ以上、何も言えなかった。 その夜から、ISTJ は眠れなくなった。 そして、ふだんは絶対にやらないことを、し始めた。深夜、誰もいないオフィスで、二十年分の運用記録を最初のページから順に、何度も読み返す。 何かを探していたわけじゃない。ただ、めくる手を止めると、もっと悪いことを考えてしまうからだった。 そして、記録ではもう止められない考えが、頭の中で増え始めた。 ふだんは絶対に考えないようにしている「最悪の未来」が、ひとりでに広がっていく。 「移行は、絶対に失敗する」。 「途中でデータが壊れて、お客さんの業務が止まる」。 「クレームが来て、契約を切られて、売上が落ちて、そこから会社全体が傾いていく」。 「二十年、私が守ってきたものは、ぜんぶ無駄だったことになる」。 ふだんなら、絶対に口にしない連想だった。 ひとつ倒れれば、次が倒れる。次が倒れれば、その次も。——まだ何ひとつ起きていないのに、頭の中では、もう会社が潰れていた。 ここが、ISTJ の崩れ方のいちばん深いところだ。 怒鳴ったりはしない。SNS に「もう無理」と書き込んだりも、絶対にしない。 ただ、誰にも何も言わずに一人で、自分の机のものをまっすぐに並べ直す。 キーボードの角度を直す。ペン立ての中身を本数まで揃える。意味がないのは、本人もわかっている。 でも、そこまで直しておかないと、次に何を確認すればいいのかさえ、わからなくなりそうだった。 ログの差分なら、追える。設定の戻し方も、書ける。手順も、記録も、ISTJ には直し方がわかる。 でも、「二十年が古い」と言われたことだけは——ISTJ がいちばん得意な過去の記録を、どれだけ探しても、直し方が書いていなかった。

40 歳。 あの移行プロジェクトは、結局、ISTJ なしでは一歩も進まなかった。 最初の月末。新しいシステムが、夜間バッチ——夜中にデータをまとめて処理する作業の途中で止まった。 担当の若手は画面の前で完全に固まっていた。エラーの意味も、どこを見ればいいかも、わからない。 昔の ISTJ なら、ここで言っていたかもしれない。「だから言ったでしょう」。 でも、その夜の ISTJ は、何も言わなかった。 黙って自分の席に戻り、二十年分の障害履歴を開いて、似た止まり方を探した。 「……これだ。二〇一二年の三月に一度だけ同じ止まり方をしてる」。 古いシステムでの直し方を新しいシステムのやり方に置き換えて、若手に手順を一行ずつ書いて渡した。 処理は、朝には最後まで終わっていた。 ISTJ はあの夜の破滅の妄想から、誰にも相談しないまま戻ってきていた。頼ったのは、いつもの手順だけだった。 やったことは地味だ。毎朝同じ時間に起きて、崩れたぶんを、また一つずつ、いつものやり方で並べ直す。それだけで、ISTJ はちゃんと「番人」に戻れた。 ひとつだけ、変わったことがある。 新しいシステムを頭ごなしに「危ない」と言わなくなった。 代わりに、こう考えるようになった。「想定外は、必ず起きる。なら、想定外が起きる前提で、手順を作っておけばいい」。 昔の ISTJ にとって、変化はぜんぶ"敵"だった。 今は、新しいやり方を自分の手順書に一行ずつ書き足していけるようになった。 今でも、新しい横文字を聞くと、ISTJ はちょっと身構える。 でも、そのたびにあの誰もいないオフィスで机を並べ直していた夜を思い出して、深呼吸をひとつ、する。