はじめに

日付：2026年6月23日（火）/ 12日目

午前は次の指示があるまでの自習、午後はチームで役割分担して
手順書の修正作業を実施した。初めての残業も経験した一日。

午前：自習・業務フローの説明を受ける

次の指示があるまでの間、移行手順書に関連する
チケット文書・SQL・手順を自習した。

① 指摘表
手順書の中で理解できない点やミスがあった場合、
リーダーがこの表に記載し、作成者が下部に回答を追記していく形式。

② QA表
作業中に発生した質問を表に記入し、
Slackの専用スレッドに「〇〇にQAを記載しました。確認をお願いします」
と投稿して確認を依頼する形式。

表の種類	用途	流れ
指摘表	手順書の指摘・回答管理	リーダーが記載 → 作成者が回答
QA表	質問・回答管理	Excelに記入 → Slackで通知

12時30分からの会議は、先に参加しているメンバーは会議室で、
6月参加の4名は各自席でイヤホンをつけて参加する形式で実施した。

会議で出た指摘内容をもとに、チームで役割分担して作業を進めた。

自分はVSCodeを使用してチケット文書の手順書を
Markdown形式に修正する担当を担った。

テキストを見やすく整形するための軽量マークアップ言語。
## で見出し、|で表、`でコードを表現できる。

実はこのQiitaの記事もMarkdown形式で書かれている。
業務で先に学んだことで、Qiitaでの記事作成がより理解しやすくなった。

メンバー	完了数
自分	8件完了
チームメンバー	11件完了（合計19件）

夕方の会議では午後の作業進捗を共有した。

インフラ手順書の整理
複雑な内容をExcelでわかりやすく要約・整理する作業を
4名で分担して進めている。量が多いため全員で対応中。

ログ収集について
Pythonを活用してログのスクリーンショットを撮影し、
ログを収集して文言を提出する作業が発生している。

台風時の出勤ルール
モノレールが運行している場合は出勤、
運行停止の場合はリモートワーク。
運行する場合は2時間後を目安に出勤。
情報はグループチャットで共有される。

前日の残作業があったため、19時45分まで残業した。

今日初めて「Markdown」という言葉を知った。
業務の手順書修正で実際に使ってみて、
その後Qiitaで記事を書く際に「あ、これが同じMarkdownだ！」
とすぐに結びついた。

何事も一度使ってみると次に使う時の理解度が全然違うと実感した。
知識は使ってこそ身につくものだと改めて感じた。

チームで役割分担が生まれ、お互い声をかけながら
一緒に頑張れている雰囲気がとても好きだ。

そして初めての残業。
「残業＝大変」というイメージがあったが、
初めてということもあってか、不思議と気持ちよく取り組めた。
まだしばらくはこの気持ちで残業も前向きにこなせそうな気がする。