今日は、自分が新しいタスクにどう向き合っているかを書いてみる。
特別なベストプラクティスとかじゃない。ただ数年働いて、いろいろやらかして、直して、少しずつ「長期的に一番疲れにくい」やり方に落ち着いてきた感じ。
同じようなこと考えてる人、たぶんどこのチームにもいると思う。
devでも、testerでも、BAでも、comtorでも、誰でも気軽に読んでもらえれば。
新しい依頼が来たら、まずチケットを作る
クライアントやPMから新しい依頼が来たとき、自分がまず考えるのはいつもこれ。
チケットを作る。
プロセスのためじゃない。チケットがないタスクって、実質存在してないのと同じだから。
口頭で話して終わり、次の日には誰も覚えてない。一週間後には「そんな話あったっけ？」になる。
チケットはコンテキストの保管場所。
あとで何か起きても、見返せば「なぜこうしたのか」がわかる。
チケットがなければ、それはただの会話であって仕事じゃない。
要件は「文章」じゃなく「意図」を読む
チケットができたら、まず要件をかなり丁寧に読む。
書かれている内容だけじゃなく、その裏にある意図を理解するようにしている。
推測できるところは自分で推測する。
でも曖昧すぎるところはちゃんと聞く。
そのときはだいたいこう聞く。
「Aという意味ですか？それともBですか？」
この聞き方だとPMやクライアントも答えやすいし、自分もすぐ方向が定まる。
たまにChatGPTを使って要件を整理することもある。
ただ、AIにちゃんと理解させるには、コンテキストをかなり明確に書かないといけない。
でもその「書く作業」自体が思考整理になる。問題をきちんと言語化できた時点で、半分くらい解決してることも多い。
ただ、自分一人が理解しても意味がない。
チーム内で解釈がバラバラなら普通に崩壊する。
他メンバーに影響がありそうなタスクは、できるだけ早めに共有する。
全員が詳細まで把握する必要はないけど、「何かがある」ことは知っておいた方がいい。
最初に議論できることは最初に議論しておく。
理解に時間を使う方が、後から直すよりずっとマシ。
クリアじゃなければコードは書かない
これは自分の中でかなり徹底している。
はっきりしてないなら、コードを書かない。
過去に、自分も含めて周りで何度も見てきた。
一日かけてきれいに機能を作ったのに、PMが「それ今いらない」と言うやつ。あれは精神的にくる。
だから最初に時間がかかってもいい。
方向を間違えるくらいなら、遅い方がいい。
要件がある程度見えたら、タスクを小さく分割する。
見た目のためじゃなく、見積もりしやすくするため。
要件変更があっても影響範囲だけ直せばいいし、PMやクライアントもスケジュールを把握しやすい。
実装前には、できるだけ設計を整理する。
フロー、DB、必要ならUI。
図でも文章でもいいから一度外に出して、チームに見せる。
BAやcomtorがそこまで技術的じゃなくても、全体像が見えればクライアントと話しやすくなる。
うちのチームはエッジケースの議論も結構長い。
standupが1時間近く伸びて、ひたすら議論する日もある。
でも方針が決まれば、あとはほぼ実装だけ。
1時間の議論で済むなら、3日作り直すより全然いい。
曖昧なまま進むより、最初に全部クリアにしてから一気にやる方が、結局一番疲れない。
曖昧なままコードを書くと、間違った方向に速く進むだけ。
本当に消耗するのはコードじゃない
実装に入ってからよく思う。
タスクで一番エネルギーを使うのって、実はコードじゃない。
難しいコードでも解ける。
本当に消耗するのは、同じことを何度も考え直すこと。
一見シンプルなタスクでも、途中で何度も中断されることがある。
別の作業に呼ばれて、数日後に戻ってくると、前に何を考えていたか思い出せない。
なぜこの設計にしたのか。
なぜ別案を採用しなかったのか。
毎回そこから読み直し。
この「コンテキスト再読み込み」が一番しんどい。
複雑なロジックやバグよりも。
だから最近は、できるだけタスクのコンテキストを連続させることを意識している。
途中で止まっても、すぐ再開できる状態にしておく。
命名、コード構造、実装中の小さな前提。
その場で明確にしておかないと、数日後には他人のコードみたいに見える。
長い目で見ると、タスクって「終わらせる」だけじゃない。
自分や他の誰かが、もう一度考え直さなくても続けられる状態を残すこと。
「最初から考え直す」回数が少ないほど、疲れない。
一番疲れるのは難しいコードじゃなく、何度も理解し直すこと。
詰まったとき
現実のチームはレスポンスが常に早いわけじゃない。
PMが忙しいこともあるし、QAが数日返してこないこともある。
だからまず自分で最大限考える。
それでも複数の選択肢があるなら、早めに共有して方向合わせする。
チャットで解決できるならチャット。
難しければ次のstandupで話す。
ずっと黙って詰まるのは良くない。
でも、自分で考えずにすぐ聞くのも違う。
まず自分でできるだけ進める。でも長く黙りすぎない。
本番のhotfixは別物
hotfixは一番雑にやりやすい瞬間。
だからこそ一番規律が必要。
本番環境は実験場じゃない。
うちのチームはだいたいこの流れ：
依頼受領 → 原因調査 → 原因報告 → 修正案提示 → 合意 → ローカル修正 → staging/dev反映 → 内部テスト → リリース日確認 → クライアント承認 → リリース
バグの大小に関係なく、できるだけこの流れを守る。
クライアントも安心するし、チームも混乱しにくい。
急いでいるときほど、ちゃんとやる。本番は試す場所じゃない。
最後に
自分のタスクの進め方は、特別すごいものじゃない。
最初にクリアにして、整理して、やり直しを減らす。それだけ。
でもほぼどのチームでも共通してると思う。
最初が曖昧なほど、後で代償が大きい。
早くクリアにするほど、長期的に楽になる。
…というわけで、またコードに戻る。