エンジニアとしての立ち振る舞い | プログラマのための IT 教科書

ここまでの章は「何を知っているか」の話でした。この章は「どう振る舞うか」の話です。

技術は調べれば分かります。しかし振る舞いは、誰も明文化してくれないまま「できて当然」とされがちです。そして評価の大部分は、実はこちらで決まります。

何で評価されるのか

新人のうちは「コードが書けること」で評価されると思いがちです。実際は違います。

チームがあなたに求めているのは、安心して仕事を任せられることです。

評価される人	評価されない人
状況が見えている（今どこまで進んだか分かる）	声をかけるまで状況が分からない
できないことを早く言う	締め切り直前に言う
同じ指摘を2回受けない	何度も同じ指摘を受ける
自分の失敗を隠さない	隠して後で発覚する
調べてから聞く	調べずに聞く / 調べすぎて止まる

技術力の差より、この差の方がずっと大きく効きます。 そして、ここに書いたことは今日から全部できます。

新人に期待されていること

先輩は、新人が最初から成果を出すとは思っていません。教えるコストを払う前提で受け入れています。

期待されているのは、同じことを2回教えなくて済むことと、 状況が見えることの2つです。

「できない」ことは問題になりません。「見えない」ことが問題になります。

信頼は小さな約束で作られる

信頼は、大きな成果ではなく小さな約束の積み重ねで作られます。

「明日までに調べます」と言ったら、明日中に報告する（できなくても報告する）
ミーティングに時間どおり出る
「後で見ます」と言った PR を、その日のうちに見る

逆に、これを崩すと一気に失われます。 大きな成果1つより、小さな約束10個の方が信頼になります。

見通しを共有する

悪い: 「やっています」
良い: 「API の実装が終わって、今テストを書いています。
       明日の午前中には PR を出せそうです」

聞かれる前に出すのが理想です。第6章の分報（times）はそのための道具です。

進捗が見えている人には、仕事を任せやすい。 ただそれだけのことです。

他人の時間を尊重する

チームで働くとは、他人の時間を使わせてもらうということです。

質問する時

第6章の質問テンプレート（やろうとしたこと・起きたこと・試したこと・聞きたいこと）は、 相手の時間を節約するための形式です。

調べてから聞く — ただし30分まで
パブリックチャンネルで聞く — 同じ疑問を持つ人の役に立つ
答えをもらったら、結果を報告する — 「解決しました」の一言があるだけで違います

「ちょっといいですか」で始めない

チャットで「ちょっといいですか？」だけ送って相手の返事を待つのは、 往復が1回増えるぶん、お互いの時間を無駄にします。

用件を最初に書いてください。相手は手が空いた時にまとめて答えられます。

❌ 「ちょっといいですか？」（→ 相手「はい」→ やっと本題）
✅ 「◯◯の件で相談です。〜という状況で、〜を試したのですが…」

レビューを依頼する時

小さく出す（第5章）
自分で一度読んでから出す — typo やデバッグコードの残りは自分で見つける
何を見てほしいか書く — 「特に◯◯の設計に自信がありません」

ミーティング

時間どおりに始められる状態で入る
目的が分からない会議は聞いてよい — 「何を決める会ですか？」は失礼ではありません
議事録を書く — 新人にできる最高の貢献の1つです。用語も覚えられます

AI との付き合い方

今の新人にとって最も重要な節です。ここを間違えると、成長が止まるか、事故を起こすかのどちらかになります。

大原則: 生成されたコードの責任は、あなたにあります

❌ 「AI が書いたので、そういう実装になっています」

これは通用しません。PR に自分の名前で出した時点で、それはあなたのコードです。 レビューでの説明責任も、本番で壊れた時の責任も、あなたが負います。

だから、理解できないコードを出してはいけません。

機密情報を入れない

これは事故になります。会社によっては懲戒の対象です。

入れてはいけないもの

社内のソースコード（許可されたツール以外）
顧客データ・個人情報
API キー、認証情報
未公開の仕様、設計資料

多くの会社が「このツールは使ってよい」というリストを持っています。 分からなければ、使う前に必ず確認してください。「たぶん大丈夫」で判断しないでください。

使ってよい場面・注意する場面

場面	使い方
知らない概念を理解する	◎ 分かりやすく説明してくれる。ただし裏を取る
エラーメッセージの意味を聞く	◎ 調査の入口として優秀
定型的なコードを書く	○ 理解した上でレビューして使う
設計を相談する	△ 選択肢は出るが、社内の事情は知らない
仕様が曖昧な実装を任せる	✕ 曖昧さは AI では解決しない。人に確認する

AI は自信たっぷりに間違えます

存在しない API、存在しないオプション、古いバージョンの書き方を、まったく同じ調子で提示してきます。

「そんなメソッドは存在しません」というエラーが出たら、
それは AI が間違えています。

必ず一次情報（公式ドキュメント）で裏を取ってください。これは第0章の「調べる順番」そのものです。

学習を止めない

一番怖いのは、分かった気になること

AI に聞けば答えが出るので、理解しないまま進めてしまいます。

半年後、AI が使えない場面（設計会議、障害対応、面接）で、自分が何も説明できないことに気づきます。

対策は簡単です。出てきたコードを、自分の言葉で説明してみてください。 説明できないなら、まだ理解していません。その場で調べてください。

AI は「調べる時間を短縮する道具」であって、「考えなくてよくする道具」ではありません。

障害対応での振る舞い

いつか必ず、あなたが関わったコードで本番が壊れます。全員が経験します。 その時どう振る舞うかで、評価が大きく変わります。

順番を守る

1. 復旧      ← 最優先。まず止血する
2. 影響範囲の把握
3. 原因究明   ← 復旧してから
4. 再発防止

原因が分からなくても、先に戻してよいのです。ロールバックは敗北ではなく、正しい手順です（第5章）。

障害中に一人で抱えない

「自分のミスだから自分で直す」と黙って作業するのが、最悪の行動です。

障害はチームの問題です。すぐに声を上げてください。

「本番でエラー率が上がっています。
 15時のデプロイが原因の可能性があります。ロールバックしてよいですか？」

判断を仰ぐこと自体が、正しい振る舞いです。

自分がやらかした時

やることは3つだけです。

すぐ報告する — 隠す時間がそのまま被害になります
事実を正確に伝える — 言い訳より、何をしたかの時系列
復旧に集中する — 落ち込むのは後で

「15:20 に deploy.sh を実行しました。
 設定ファイルの DB 接続先をステージングのままにしていたようです。
 現在エラー率が 30% です。ロールバックします。」

この報告ができる新人は、強く信頼されます。 逆に、隠した1時間は永久に取り返せません。

犯人探しをしない

他人のミスが原因だった時も、責めないでください。

障害の原因は、たいてい個人ではなく仕組みにあります。

❌ 「なんで確認しなかったんですか」
✅ 「設定ミスに気づける仕組みが無かったですね。CI でチェックできませんか」

ポストモーテム

障害後に、原因と再発防止をまとめる文書をポストモーテムと呼びます。

blameless（誰も責めない） が大原則です。責める文化があると、次から誰も障害を早く報告しなくなり、被害が拡大するようになります。

新人でも書けます。時系列を正確に書くだけで大きな価値があります。

やってはいけないこと

新人が「知らなかった」で踏みやすい地雷です。

やってはいけないこと	なぜ
本番の DB を直接触る	1文字のミスで全データが消えます。必ず許可と手順を確認
本番データをローカルに落とす	個人情報の持ち出しになります
勝手に大きな設計変更をする	「良かれと思って」でも、影響範囲が読めません
無断で外部サービスに社内情報を入れる	AI ツール、翻訳サイト、オンラインの整形ツールも含みます
`kubectl edit` で本番を直して放置	次のデプロイで消えます（第3章・第15章）
アラートを止める	鳴りやみますが、障害は続いています

迷ったら止まって聞く

この一覧に共通するのは、取り返しがつかないことです。

「これは戻せるか？」と自問してください。戻せない操作の前は、必ず誰かに確認する。それだけで大半の事故は防げます。

聞いて怒られることはありません。聞かずにやって事故になる方が、100倍問題です。

自分のデプロイが原因で本番のエラー率が急上昇しました。最初にすべきことは？

1on1 とフィードバック

多くの会社に、上司や先輩との定期的な1対1の時間（1on1）があります。

何を話せばいいか分からない時

新人が「特にありません」で終わらせがちな時間ですが、もったいないです。話すことが無いなら、この4つのどれかを持っていってください。

今困っていること（技術でも人間関係でも）
自分の理解が合っているかの確認（「このチームの優先順位は◯◯という理解で合っていますか」）
次に何を学ぶべきかの相談
やってみたいこと

1on1 はあなたのための時間です。 上司への報告会ではありません。

ネガティブなフィードバックを受けた時

落ち込みます。それは当然です。その上で、次を意識してください。

人格ではなく行動への指摘として受け取る
具体例を聞く — 「どういう場面でそう感じましたか？」
すぐ直せるものを1つ選ぶ — 全部直そうとすると何も変わりません

フィードバックをもらいに行く

待っていると、フィードバックは年に2回しか来ません。

「先週の PR、レビューしづらい点はありましたか？」
「もっとこうしてほしい、ということがあれば教えてください」

自分から聞きに行く人は、伸びるのが圧倒的に速いです。そして「改善したい意志がある人」として見られます。

学び方

変わらないものを優先する

技術の流行は数年で変わります。しかし変わらないものがあります。

変わりやすい	変わりにくい
フレームワーク（React, Next.js…）	HTTP、TCP、DNS
ライブラリ、ツール	データ構造、計算量
クラウドの個別サービス	設計原則、トランザクション
言語の流行	セキュリティの原理

この教科書が第3部（ネットワーク・Web・ブラウザ）に力を入れているのは、そこが10年後も使えるからです。

新しいフレームワークは、土台があれば数日で学べます。