1. はじめに：なぜ、この資料が必要か？
私たちは日々、「実装完了しました」「テストOKです」という報告を行います。
しかし、時として「サーバー側の実装が終わったが、疎通を試していない」「思った通りに動くだろう」といった 「暗黙の前提」（＝個人の経験則や感覚、すなわち「暗黙知」）によって、後工程で大きな手戻りが発生することがあります。
この「小さなズレ」が積み重なると、手戻りによるスケジュールの遅延、不具合による信用の低下、そして何よりチーム全体の疲弊につながってしまいます。
これは、個人の能力の問題ではなく、チームとしての「完了の定義」がズレているという「知識共有」の問題です。
この資料は、私たちが陥りがちな「暗黙の前提」をチーム全員で 「表出化（＝言葉にする）」し、それをチーム共通の「完了基準」（＝形式知）へと「連結化（＝体系化・ルール化）」 するための、対話型ワークショップ資料です。
このワークショップの目的は、完璧なルールを作ることではなく、まず 「自身とチームメンバーの『当たり前』の基準は、意外と違うかもしれない」 ということに気づき、その基準をすり合わせていく文化を作ることです。
また、例えば新米リーダーがメンバーの進捗を確認する際、基本に立ち返ることで、
メンバーが正しく進捗報告をできるように寄り添うためにも読んでみてください。
2. ワークショップ：「完了！」の解像度を上げる
以下の3つのテーマについて、私たちが普段「暗黙的に」判断している基準を、チームの言葉で整理し直してみましょう。
テーマ1：実装（コード）は本当に「完了」しているか？
「コードを書いた」＝「実装完了」ではありません。仕様書に書かれていない「当たり前」を実装できているか、そして「未来の自分や仲間」が読み解けるコードになっているかが重要です。
＜よくある「つもり」＞
仕様書（や箇条書きタスク）に書いてある機能は実装した。
正常系の動作は、自分のローカル環境で確認した。
「とりあえず動けばいい」という速度優先の意識。
使いたいと思う機能になっていない。
＜見落としがちなポイント＞
-
仕様の網羅性（「書かれていないこと」の考慮）：
- 箇条書きタスクに落とし込む際、元の仕様書の意図（特に細かい分岐やビジネス上の背景）が漏れていないか？
- 仕様書の文章を見ながら実装を確認してみよう。漏れてるかも？
- 例： 「ユーザー一覧表示」というタスクでも、「権限によって表示項目が変わる」「退会ユーザーは表示しない」といった暗黙の前提がないか？
-
エラーハンドリング（「うまくいかない」の考慮）：
- 正常系ができたからといって、それが全てではない
- データがnullやundefined、0件だった場合、処理が停止したり、画面がクラッシュしたりしないか？
- APIやライブラリがエラーを返した場合のtry-catch処理は？ ユーザーに「何が起きたか」を（最低限）通知できているか？
- 入力フォームの異常値（記号、絵文字、極端な長文、全角/半角の違い）は考慮されているか？
-
保守性・可読性（「未来」の考慮）：
- そのコードは、3ヶ月後の自分が読んでも理解できるか？
- 複雑なロジックに、なぜそう書いたのかという「意図」をコメントで残しているか？
- 似たような処理がコピペされていないか？（共通化できる部分はないか？）
- 必要以上に複雑な設計（オーバースペック）になっていないか？
【チームでの対話（Discussion Point）】
- 私たちのチームで、最も「エラーハンドリング」の考慮漏れが起きやすいのは、どの部分（どの機能、どのAPI）ですか？ なぜそこだと思いますか？
- 「仕様書に書いてないが考慮すべきこと」を、私たちは普段どのようにキャッチアップし、共有していますか？（例：コードレビューの観点、設計書のフォーマット、朝会での口頭確認など）
- 「レビューしやすい（＝意図が伝わる）」コードやPull Requestのために、私たちが工夫できることは何ですか？
テーマ2：テスト（動作）は本当に「完了」しているか？
「（自分の環境で）動いた」＝「テスト完了」ではありません。あらゆる利用シーンを想定し、意図的に「壊しにいく」視点（QA視点）が重要です。
＜よくある「つもり」＞
- 実装した機能が、自分のローカル環境で（1回は）動いた。
- テストコードを書くのは難しい / 時間がかかる。
- 「きっとQAチーム（や後工程）が拾ってくれるはず」という甘え。
＜見落としがちなポイント＞
- フロントエンド（画面系）：
- データ0件： 「データがありません」という通知は出ているか？ 0件になった後、1件目を登録したら正常に表示が切り替わるか？
- 2回目以降の動作： 新規登録→キャンセル→再度モーダルを開く、など「繰り返しの操作」は正常か？（古いデータが残っていないか？）
- ボタン連打： 処理中にボタンが無効化（disabled）されているか？（二重登録や複数回APIコールが起きないか？）
- 環境依存： 「Mac/SafariではOK。Windows/Chrome/FireFoxは？」「レスポンシブ確認した？」→ スマホとPC、画面解像度の違いはどうか？
- 状態の不整合： 画面Aでデータを更新した後、画面Bに戻ったとき、その更新が反映されているか？
- サーバーサイド（DB・API系）：
- バリデーション： required項目がnull、string項目にnullなど、DB制約違反になるリクエストを弾けているか？ 数値項目に文字列は？ 境界値（最大・最小）は？
- レスポンスの安定性：「不用意にnullを返さない」「パラメータをなくさない（アプリがクラッシュする）」→ これはAPI設計の「契約」の問題。
- 0件の扱い： nullを返すのか、空の配列[]を返すのか。チーム（またはフロントエンド）の期待値と合っているか？
- データ境界値： データが大量（例：1000件）の場合のレスポンス速度や、ページネーションは正常に機能しているか？
【チームでの対話（Discussion Point）】
- 「テストの手を抜く」と「結局三倍ぐらい時間かかっちゃう」。この経験に共感できる、過去の具体的な「ヒヤリハット」事例はありますか？
- 私たちが「テスト完了」と言うために、最低限クリアすべき項目（Definition of Done）を3つ挙げるとしたら何ですか？
- 「自分で自分のコードをテストする」ことの難しさはどこにあると思いますか？ それを補うために、チームとしてどんな工夫ができますか？（例：ペアレビュー、テスト観点リストの共有など）
テーマ3：私たち（チーム）は「健全」か？
どんなに良いコードも、どんなに完璧なテストも、それを行う「エンジニア（＝私たち）」が不健康では継続できません。「個」と「チーム」の健全性が、品質の土台です。
完全に蛇足かもしれないですが、人間にとって体は真の資本です。
侮れません。
＜よくある「思い込み」＞
- 気合で乗り切ればなんとかなる。（睡眠不足は気合でカバーできる）
- 実装で悩んだら、まず一人で（1時間以上）考え抜くべきだ。
- 雑談は仕事の妨げになる。技術的な会話だけしていれば良い。
＜健全性を保つポイント＞
- 睡眠（最大のデバッグ）：
- 「寝不足は自身のバグの原因」「寝るようになってわかる。びっくりするぐらいコードのバグが減る」
- 睡眠不足は、注意力不足や考慮漏れだけでなく、イライラを生み、チームのコミュニケーション品質を低下させます。
- 運動と食事（コンディション維持）：
- 「1日30分は散歩しよう」「ラジオ体操はとても有効」
- 同じ姿勢での作業は血流を低下させ、肩こりや頭痛を引き起こし、集中力を奪います。適度な運動と、腸内環境を整える食事がパフォーマンスを支えます。
- 対話（思考のデバッグ）：
- 「考えているだけでは、コードは動かない。声に出そう」
- 一人で悩んでいる状態は、思考がループしている（＝バグっている）状態かもしれません。
- 誰かに話す（＝アウトプット、表出化する）ことで、自分の思考が整理されます（ラバーダッキング）。
- 「雑談が、課題解決のヒントになることもある。」技術と関係ない会話が、チームの信頼関係（＝心理的安全性）を築き、本題の相談をしやすくさせます。
【チームでの対話（Discussion Point）】
- あなたが「実装に悩んだ時」、チームの誰に、どのタイミングで相談（＝アウトプット）したいですか？ また、どう相談されると（あるいは、どんな雰囲気だと）助けやすいですか？
- 私たちのチームの「健全性（＝パフォーマンス）」を（睡眠・運動・対話の面で）もっと高めるために、明日からできる小さな一歩は何ですか？
- チームの「心理的安全性」（＝「こんなこと聞いたら馬鹿にされるかも」と思わずに、安心して「わからない」「助けて」と言える状態）を高めるために、私たちができることは何ですか？
3. 次のステップ：知識の「内面化」へ
この資料は、一度読んで終わりではありません。
このワークショップで「表出化」され、「連結化」されたチームの新しい基準（形式知）を、今度は私たち個人の「暗黙知」レベルにまで落とし込み、 「内面化（＝無意識にできる当たり前のこと）」 していく必要があります。
この資料（の観点）を、いつ、どのように使っていきますか？
- 次回の「ふりかえり」で、テーマの1つとして対話してみる。
How: 毎回1テーマ（例：「今週、エラーハンドリングで見落としたことは？」）だけピックアップして、5分でも話す時間を作る。 - チームの「Definition of Done（完了の定義）」として明文化し、PBIやタスクの完了条件に設定する。
How: この資料をベースに、チームのルールとしてWikiなどに明記し、タスク完了の「客観的なモノサシ」として運用する。 - コードレビュー時の観点チェックリストとして活用する。
How: Pull Requestのテンプレートに、特に見落としがちなポイント（例：「データ0件の考慮は？」「ボタン連打対策は？」）をチェックボックスとして追加する。
やりすぎ注意：基準は「厳しいほど良い」わけではない
ここまで「完了の解像度を上げよう」と書いてきましたが、1つ注意点があります。
完了基準の網羅性を上げすぎると、今度は 「チェックを埋めること」自体が目的化 し、開発速度と「なぜこの項目が必要か」を考える対話が失われます。網羅性とスピードはトレードオフです。
判断軸は、事業フェーズによって基準の厳しさを変える ことです。
- 検証フェーズ（作っては壊す前提の段階）： 正常系＋致命的なエラーの考慮など、最低限まで軽くする。
- 本番運用フェーズ（ユーザーの信用がかかっている段階）： エラーハンドリングや環境依存まで含めて厳しくする。
また、形骸化のサイン にも気をつけてください。「チェックは全部つくのに手戻りが減らない」「レビューで同じ指摘が繰り返される」と感じたら、それは項目を増やすのではなく、ふりかえりで基準そのものを見直す（減らす・問い直す）タイミングです。
効果をどう感じ取るか
このワークショップの効果は、すぐに数値には表れません。観測するなら、次のような変化を「観点」として見てみてください。
- 手戻りの頻度： 「完了」報告のあとの差し戻しは減っているか？
- レビュー指摘の種類： 「データ0件の考慮漏れ」のような指摘から、設計や仕様の意図に関する議論へシフトしているか？
- 報告の言葉： 「動きました」が「〇〇のケースも確認しました」に変わってきているか？
これは、一度決めたら終わりの「ルール」ではなく、チームの成長とともに見直していく「生きた資料」となれば幸いです。
継続的に対話し、私たちの「完了の基準」をアップデートしていきましょう。