First Career Note

APIの入口を自前のサーバーで受けるか、マネージドな窓口に任せるか。Amazon API Gatewayを「ビルの受付窓口」のたとえと図解で解説し、REST・HTTP・WebSocketの違い、ELBやCloudFrontとの使い分け、現場での選び方と料金までまとめました。

指示書に書いたのに守られない。原因は書き方ではなく「思い出す前提」で設計していることでした。ルール文書に書いたときは数字が動かず、作業手順に検査を組み込んだら動いた実例をもとに、指示書の絞り方と、人やチームへの応用まで整理します。

サービスをまたぐ処理は、ログを1台ずつ追っても遅い原因にたどり着けません。1回のリクエストの経路と区間ごとの時間を1本につないで見るのが分散トレーシングです。標準になったOpenTelemetryの考え方と、入社1〜3年目がまず手をつける3つを整理します。

取り出しても消えず、削除するまで残る。Amazon SQSの動きは最初つまずきます。整理券の待ち行列というたとえで、可視性タイムアウトとデッドレターキュー、SNSとの使い分け、監視でまず見る指標、リクエスト単位の料金の数え方までまとめました。

「できません」の言い換えを、社内・社外・顧客の場面別に7パターン紹介します。「できかねます」は失礼なのか、よくある3つの間違い、そのまま使える断りメールの例文つき。角が立たない断り方の型がわかります。

Design Docとは、実装前に不確実性を洗い出す設計文書です。優秀なエンジニアが必ず書く代替案・懸念点・未決定事項の3点と、A4一枚から始める書き方を新社会人エンジニア向けにやさしく解説します。

Amazon SNSは交流サイトのSNSではなく、AWSの通知サービスです。「登録者全員への一斉放送」というしくみ、トピックとサブスクライバーの関係、SQSとの使い分け、料金と無料枠に加え、監視通知が多すぎて誰も見なくなる問題まで解説します。

自己評価シートで手が止まる新人・若手向けに、評価する側・される側を10年以上経験した筆者が書き方を解説。「成果・姿勢・能力」の3要素で材料を整理し、「事実+具体例・数字+次にどうするか」の型に流し込むだけ。そのまま使える例文とNG例つき。

議事録の書き方を5つの型とテンプレートで解説します。決定事項・ToDo・論点と結論・保留・次回の順に並べるだけで、会議終了から30分で出せる議事録になります。新人がやりがちな失敗3つも紹介。

CloudWatchは「システムの健康診断モニター」です。メトリクス・ログ・アラームの関係、EC2やLambdaとのつながり、料金と無料枠を整理したうえで、監視設計を10年やってきた筆者が障害時にまず確認する3つの指標を紹介します。