むかしむかしあるところに
※おおむね嘘です
めでたくリリース！までは幸せだった
ボス🧔♂️ < 今日から新規プロジェクトを立ち上げる！
ボス🧔♂️ < まず、君には基幹システムからのデータ連携システムの構築を任せる。
ボス🧔♂️ < 連携元システムの担当者はxxxさんだ。詳細は彼と詰めてくれたまえ。
私👨🏻💻 < ラジャ！
...
私👨🏻💻 < でけたっす！
ボス🧔♂️ < よくやってくれた。では次のタスクを～...。
...
ボス🧔♂️ < 無事リリースだ！お疲れ様！
ボス🧔♂️ < 早速次のプロジェクトに移ってもらう。運用保守はやってもらうが、優先度は低くていい。
私👨🏻💻 < ラジャ！
そして起こる悲劇
CS👧 < すみません、お客様が「商品を購入したのにログインできない」っておっしゃってます！カンカンです！至急確認をお願いします！
私👨🏻💻 < わかりました！すぐ確認します！
...
私👨🏻💻 < 権限有無の判定は...えーっと...。
私👨🏻💻 < 元データは基幹システムからの連携バッチで持ってきてるのがわかったぞ。
私👨🏻💻 < 連携バッチゴチャゴチャしてるなー...今回のユーザーのIDはxxxだから、えーーっと...。
私👨🏻💻 < わかった！この注文情報がデータ連携時に弾かれてるのが原因だ！
私👨🏻💻 < 仕様通りに動いてるから、「この人はログインできないのが正しいです」ってCSに伝えれば...
私👨🏻💻 < でも、ログインできないって怒ってるんだよな。もしかしてバグ...？
私👨🏻💻 < チケット掘って確認したら、仕様通りの実装だ。バグじゃない。
私👨🏻💻 < ってことは、仕様が間違ってる？
私👨🏻💻 < くそ！どういう仕様なのか？はわかるけど、なんでこの仕様なのか？がわからない！
私👨🏻💻 < こうなったら、必殺のSlack/Notion/GoogleDrive鬼grepするしか...
...
私👨🏻💻 < 仕様は合ってる！基幹システム側で商品情報の登録時に設定ミスってるんだ！
私👨🏻💻 < すみません原因わかりました！管理システムにて商品xxxの上方修正をおねg
CS👧 < 返金対応なう
懺悔
横着してチケット切らずに作業してごめんなさい
連携バッチは初期実装 → バグ修正 → 仕様変更 → ...と、コミットが積みあがっていました。
git blameを元にPRを掘ってみるも、「連携条件をxxxからxxxに変更」のように、何をしたのか？しか書いておらず。
「瞬殺で終わるからチケット切るまでもないか...」でチケット切らずに修正 → PR出す → あざマージ。
当然のごとく、PRの中にもたいしたこと書いてない。
未来の誰かが情報を探す時に使うかもしれないのだから、許される横着ではありませんでした。ごめんなさい。
チケットのタイトルを短くしようとしてごめんなさい
ちゃんとチケット切って書いて作業したPRもありました。
しかし、「連携バッチのバグ修正」のようにチケットを切っていました。
朝会でチケットを整理する際、チケット名がゴチャゴチャしてて鬱陶しかったためです。
タイトルだけでわかるくらいのチケットは内容書かかずに切ることもあるし、よくわかります。
しかし、「タイトル見ればわかるだろ～」で切ったチケットを後から見返すと、なんのこっちゃわからないことが往々にしてあります。
❌ 連携バッチのバグ修正
⭕ 連携バッチでエラーが起きた時に通知できていない
これだったら、後から読み返した時にサクッと「このgit blameは追わなくていいな」できたことでしょう。そうしておけばよかったです。ごめんなさい。
チケットに「なんでこうしたのか？」書くのサボってごめんなさい
ちゃんとチケット切って/内容書いて作業したPRもありました。
でも、チケットには「連携条件をxxxからxxxに変更する」レベルの情報しか以下略。
ものを作るときには「どうなっていればいいのか？どうなるべきなのか？」が分かっていればいいです。その裏にある「なんでそうなっているべきなのか？なんでそう決めたのか？」まで書き出すのは手間ですし、情報過多に思えます。
...が、ものを作った後は「なんでそうなっているべきなのか？なんでそう決めたのか？」が重要です。
「どうなっているのか？」はコード読めば/アプリケーションを動かせばわかるので、あまり重要ではありません。
「ぜったいxxxな方が良い気がするけど、なんか理由あってこうなってんだろうなぁ。こわいから触るのやめとこ。。」となったことは経験あるのではないでしょうか。
git blame → PR → チケットと辿っていけば情報を得られるのはとても重要です。サボってごめんなさい。
Discussion