老兵は死なず、ただQiitaを書くのみ ～ かつてシステムエンジニアだった私へ贈る10の言葉
こんにちは。今年50歳になった元システムエンジニアです。システムエンジニアというのは、IT関連のシステム設計・構築に携わる職業で、最近ではITエンジニアという名称が使われています。
"元"と書いてある通り、いまはシステムエンジニアではありません（今はアドバイザリー的な仕事が多いです）。
とはいえ、相変わらずIT業界には所属しており、ITやセキュリティに携わる仕事をしています。
この業界に長くいると、いろいろ知識や経験が増えてきます。若いころああしておけばよかったなとか、こんなことを知っていたらもっと仕事が楽だったかもな、ということもいろいろありました。
今回は、そんな過去の自分に伝えたいあれこれをまとめてみました。過去の自分へのメッセージですが、今の人たちにも何か役に立つかもしれません。
追伸：IT業界で働いていたので、それ系のネタが多くなりますが、それ以外の業界の人にも参考になることがあるかもしれません。
追伸の追伸：あ、ちなみにフィクションですので、そのつもりで読んでください（勘のいいガキは嫌いだよ）。
贈る言葉① ログを見よう
なにかあったら、ログを見よう。何が何でもログを見よう。何かが起動しない、ログインできない、動きが想定と異なる、etc…
IT（システム）で起こるあれこれは、基本的に（原則）ログに記録されているぞ。そしてそこにはあらゆることが記録されているぞ（多分）。
アクセスログ、エラーログ、システムログ、操作ログ、監査ログ、特権ログ、etc
ん？ログファイル名がわからない？ログがどこにあるか、そもそもわからない？
よし、まずログがどこにあるか、マニュアルを見よう。OS、ミドルウェア、データベース、アプリケーション、すべてのログのありかを！話はそれからだ！
あ、そのログ気を付けて。自動ローテーションで消えるから…（ログファイルのバックアップも忘れずに）
贈る言葉② 操作ログを取ろう
人間は忘れやすいもの、自分の操作のログを取ろう。検証か何かで操作して、うまくいっても、うまくいかなくても、上司や先輩に報告するよね？ その際、操作のエビデンス（証拠）が必要になる。それが操作ログだ。
操作ログがないと、後で手順書も作れないぞ。
過去自分は若いから、自分がやってことは忘れない自信があるかもしれないけど、すぐに忘れるから気をつけろ。自分を過信するな！
あと、単純に勘違いもある。自分ではこうやったつもりでも、実際はそんなことやってなかったり、別のことをやっていたり。そういったときに客観的な記録として使える、それが操作ログだ。
過去自分が扱うシステムは、Unix系/Linux系が多かったね。なので、システムの接続時に、Tera Termよく使ってたね。「自動的にログ採取を開始する」設定があるぞ、必ず設定しとけ！システムにつなぐと自動的に全部の操作をログに取ってくれる、便利な機能だ！
あ、echoコマンドでコメントを残しておくと便利だぞ。
え、Windows系のシステムはどうするかって？ スクリーンショットを取りまくるんだ、WinShotいれとけよ！
贈る言葉③ リリースノートを読もう
何かをインストールする前に、リリースノートを読もう。どんな機能が追加されたのかも大事だけど、もっと大事なことがある。前提や制約だ。
新バージョンになったら前提条件が変わっているっていうのは、よくあることだ。今までサポートしていたOS（のバージョン）がサポートされなくなったり、使えていたミドルウェアやデータベースが対象外になっていたり。
あと、特定パッケージの特定バージョンが必要なケースもある。間違えて最新バージョンインストールするなよ、動かなくなるぞ。
新しいバージョンがサポートされたからって、お客様に勧めちゃだめだぞ。実績の無いものは、どれだけトラブルが起こるかわからないぞ。事前検証して、バグを見つけておけ。
新バージョンの検証を怠って、インストール失敗してテープ環境から切り戻したやつがいるらしいけど、ココだけの秘密だ。
制約も注意だ。新機能が追加されて喜んでいるかもしれないが、代わりに使えない機能があったり、特定条件下では使えない場合があるぞ。事前検証して、使えるか確認しておけ。
マニュアルに何が書いてあったとしても、動かなければお客様には提供できないよ。
なに、リリースノートが英語で読めない？
おまえ つまんないウソつくね
贈る言葉④ リストアしよう
システム構築すると、必ず運用要件としてバックアップが出てくる。バックアップ設計して、バックアップする仕組みを構築して、バックアップファイルを取って終わり、じゃないぞ。必ずリストアしてみろ。必ず何か問題が見つかるから。
バックアップするファイルが足りてなかったり、バックアップするときの条件が間違っていたり、あとバグだったり。リストア手順も間違えがちだぞ。
必ず何か見つかるから、忘れずにリストアテストを実施するんだ。
え、何も問題が見つからなかった？
それはラッキー、手順書に落とし込もう。そして手順書通りにバックアップ/リストアしてみるんだ。そこで問題が無ければ、ようやく手順書の完成だ。
あ、バックアップ後にパッチあてた？
悪いことは言わない、もう一度バックアップとリストアをやり直すんだ。
そして手順書を修正しておけ。
3か月後の自分はほぼ忘れていると思え！
1年後の自分は、もはや他人だぞ！！
あと、バックアップファイルはどこかにきちんと退避するように。
バックアップファイルの最初の置き場所、1か月後に自動削除されるぞ！
贈る言葉⑤ 議事録を取ろう
議事録、必ず取ろう。できれば自分で取ろう。
議事録を書くと、自分がどれだけちゃんと話を聞いていないか（理解していないか）わかるから。
わからない用語は、調べよう。
それでもわからなければ、先輩や上司に聞くんだ。
自分以外の誰かが議事録を書く場合、必ず中身を確認しよう。
自分が言っていないことが書かれていたり、自分の言ったことが書かれていなかったりするから。
すぐ訂正依頼を出すんだ。
そうしないと、間違った情報が公式にコミットされちゃうから。
あと、議事録はあとで見返せるようにしておこう。
数か月後の会議で、真逆のことを言い出す人が現れるから。
議事録を差し出して、そっと当時のことを思い出させるんだ。
え、知らぬ存ぜぬだと？
そんなことを言った覚えがないだと？
しかたない、このプロジェクトが終わったら、静かにそのお客様から離れよう。
永遠の別れでさみしいかもしれないが、別れがあれば出会いもあるさ。
贈る言葉⑥ やることをメモしよう
やることをメモしよう。メモしておかないと、何をやるか忘れるから。
いや、君は若いから、記憶力には自信があるだろう。
落語の寿限無だって、何も見ずにスラスラ言えるだろう。
でも、忘れるんだ、人というやつは。
やることが日々増えていくから。
やることが日々変わっていくから。
だから、メモしよう。
やることと、期限と、ゴールと、アウトプット（成果物）と、優先順位ぐらいはメモしておこう。
アウトプットは粒度も大事だ。
参考になるものがないか、確認しよう。
あと、何で作るか。
Wordなのか、Excelなのか、PowerPointなのか、確認しておこう。
もしかしたらフォーマット/テンプレートがあるかも。流用しよう。
この辺りを明確にしておかないと、何から始めればいいのか、わかんなくなるぞ。
できれば、ドラフトの段階でレビューしてもらおう。
方向性が間違っていたら、早めの軌道修正が大事だからね。
あ、優先順位と期限はコロコロ変わるから、注意してね。
定期的に上司/先輩に進捗報告した方がいいよ。
あとまれに、仕事ふっておいて忘れられることもあるけど、いちいち腹を立てないように。
向こうに悪気はない。ただ、忘れているだけなんだ…
（歳を取ると、色々忘れるんだ…）
贈る言葉⑦ 周りを巻き込もう
周りを巻き込もう、全部自分でやろうとしちゃ駄目だよ。
いや、わかるよ。全部自分でやりたいんだよね。
調べて知識が増えるとうれしいし、検証して動くと楽しいよね。
あと、先輩/上司って、忙しいから聞きにくいよね。
相談しても「ググれ」って言われそうだし…
でも、巻き込むんだ。
トラブルは急にやってくる。
システムトラブルもそうだし、顧客トラブルもある。
あと単純に自分のトラブルもある（風邪/インフルエンザにかかったり、転んでけがしたり）。
自分しか知らない状況は、とても優越感があるかもしれないけど、
実は危険な状態なんだ。
インフルエンザで40℃の熱が出て意識が朦朧としているのに、君しか知らないことがあったらどうなる？
出社するかい？
ゆっくり寝てたいだろう？
何かあった場合に自分一人でできるようにしておくことは大事だ。
でも、自分だけしかできない状況は避けた方がいい。
きちんと周りを巻き込んでおこう。
きっと何かあったとき、周りが助けてくれるから。
（周りに頼れないと、すぐに限界が来るぞ）
贈る言葉⑧ 言葉を定義しよう
言葉を定義しよう。普段何気なく使っている言葉は特に。
深夜客先作業で、先輩に「サーバ止めて」って言われたよね？
で、某Unixにログインして、shutdownコマンドたたいたよね？
で、サーバの電源が落ちた（これ自体は正常な動き）。
で、先輩に報告したら、ものすごく驚いた顔してたよね？
そう、先輩の言う「サーバ」とは、「アプリケーションサーバ」のことだったんだよね…
いやあ、驚いたね…
物理サーバの電源ボタンがどこにあるかわからなくて、お客様に聞いたよね…
いやあ、冷や汗かいたね…
（良い子はマネしちゃだめだよ）
いや、報連相が足りなかっただけなんだよ？
「shutdownコマンドでサーバ止めればいいですか？」って聞けば、ね。
いや、そもそも作業手順書を準備していれば、ね。
まあ、防ぐ方法はいくらでもあったはずなんだ。
でもまあ、まず、言葉を定義しておこう。
話はそれからだ。
贈る言葉⑨ 何の話か伝えよう
それ、なんの話だっけ？ って言われること無い？
理由は簡単。何の話か伝わっていないんだ。
上司や先輩に話しかけるときは、何の話かきちんと言おう。
当時の君はよく知らないかもしれないが、上司や先輩はえぐい数の仕事をこなしているんだ（こなしきれているかは別問題）。
A社のプロジェクト（設計中）、
B社のプロジェクト（構築中）、
C社のプロジェクト（テスト中）、
A社の別プロジェクト（別の設計中、製品検証中、クレーム対応中）
D社のプロジェクト（提案中）、
E社のプロジェクト（アフターフォロー）、
自社のXX戦略会議、人材育成会議、来年度の採用計画、技術者交流会の企画、対外セミナーの準備、昇格候補の要員選定、etc
正直、君に何の仕事を振ったのかなんて、覚えていない（けど頭の中のどこかにはある）…
だから最初に話すんだ。
A社のXXプロジェクトのYY製品の検証の件で、「相談」があります（「報告」があります）！！！
その一言で上司/先輩は君に何を頼んでいたか、必死に思い出すから。
（え、思い出さない？ じゃあそのまま寝かせとけ）
贈る言葉⑩ 事実と感想を意識しよう
上司や先輩に報告するとき、事実と感想を意識して話そう。
トラブルや障害報告の場合は特に気を付けて話そう。
どこまでが事実なのか。
どこからが（自分の）感想なのか。
例えば、構築中のシステムで動作確認してたとしよう。
想定通りに動かない。
さて、何がおかしいのか？
自分が確認したことは、事実だ。
例えば、XXシステムにTeraTermを使ってID：xxx、パスワード：xxxでログインし、
xxxディレクトリに移動して、xxxコマンドを実行した。
これは事実だ。
その結果、メッセージが出力された。
これも事実だ。
本当ならばこのメッセージは出力されないのに…
これは、事実か？ それとも感想か？
仕様書を確認して、このケースではこのメッセージが出力されないことを確認したのであれば、事実だ。
でも、以前こういうケースでは違うメッセージが出力された、気がする、であれば感想だ。
事実の報告の場で、事実っぽい感想を混ぜると危険だ。
判断を誤る可能性がある。
判断を誤ると、トラブルのリカバリが遅れ、最悪、復旧不能になる。
事実と感想を適切に報告しよう。
みんなで幸せになろうよ。
おわりに
書いたものを改めて読み返すと、システムエンジニアだけに通じる内容というよりは、若手社会人が読んでも大丈夫な内容になっている気がします。結局ベーススキルとして求められるものは、こういったものだったりするっていうオチ、なのかもしれません。
98. 更新履歴
- 2025.09.18 初版