完成してから「そういう意味ではなかった」と分かると、変更したファイルと確認をやり直すことになります。
複数工程の仕事では、成果と承認地点を先に揃える方が手戻りを抑えられます。
このレッスンでは、架空の申込フォームに確認表示を加える仕事を題材に、短い計画の作り方を学びます。
作業を止めるためでなく、必要な判断を適切な時点へ置く方法です。
この記事で学ぶこと
- 完成を利用者の動作で書く
- 業務承認と実行権限を区別する
- 計画変更に合わせて検証も更新する
動作として完成を定義する
完成条件は、利用者に見える動作で書きます。
「フォームを改善する」ではなく、「送信前に入力内容を確認でき、修正してから送信できる」です。
どの画面で何ができるかが分かれば、設計案を比較できます。
見た目の改善と機能の追加を同じ言葉でまとめないようにします。
架空の例では、確認画面を新しく作る方法と、同じ画面に確認欄を出す方法が考えられます。
どちらも目的を満たす可能性がありますが、変更する範囲や確認項目が違います。
最初から実装方法を固定するより、既存の仕組みと必要な動作を調べ、最小限の案を出してもらいます。
完成の文には、維持する動作も含めます。
既存の入力チェック、送信先、送信後の案内などです。
新しい確認機能だけが動いても、送信できなくなれば目的を達成していません。
今回の追加と既存の約束を一組にすると、計画の検証範囲が具体的になります。
成果の記述には、対象とする利用者の操作順も加えられます。
入力して確認し、必要なら戻って修正する流れです。
これが明確なら、実装方法が変わっても同じ条件で評価できます。
コードの構造を先に決めるより、変えてはいけない利用体験を共有する方が、複数案の比較に役立ちます。
現状と変更案をつなげる
計画は、調査、変更、検証の流れでまとめます。
調査では現在のフォームの構造とルールを確認します。
変更では、どこに確認表示を置くかを決めます。
検証では、通常の送信と修正、入力不足などのケースを試します。
手順の名前だけでなく、各段階で何が分かれば次へ進めるかを置きます。
変更予定ファイルには役割を添えます。
画面、入力処理、確認用のテストなどです。
新しい仕組みを追加する場合は、既存の方法で対応できない理由を示します。
ライブラリを増やすことや構造を作り直すこと自体は成果ではありません。
依頼の動作へ必要な変更かどうかを判断します。
不確実な点は計画へ明記します。
例えば、確認画面へ移動した後に入力内容を保持する方法が未確認なら、最初の調査で確かめると書きます。
分からないことを隠した詳細計画より、不確実性と調べ方が分かる計画の方が実行できます。
調査の結果に応じて、変更案を更新する余地も残します。
計画の各工程には、作業を始める前提も書きます。
入力の保持方法を調べるには既存の画面が必要であり、送信確認には試験先が必要です。
前提がない工程を完了予定として並べないようにします。
必要な準備が見えると、実装途中で待ちが発生する原因を先に減らせます。
検証を承認前に準備する
承認する人が見るべきなのは、抽象的な計画だけではありません。
実装後に何を確かめ、どこまで確認できたかも必要です。
フォームなら、入力内容の表示、修正後の保持、二重送信の扱い、既存の入力チェックを検証候補にします。
どれを実施するかは、実際の変更が影響する範囲で選びます。
正常例だけでなく、空欄や長い入力なども用意します。
期待結果を先に決め、出てきた動作をそのまま正解にしないようにします。
例えば「戻って修正した値が確認表示にも反映される」と書きます。
判断が必要な動作が未定なら、実装を急ぐ前に提案と理由を整理します。
本番への実送信を含む検証は、試験用の宛先や環境を使えるか確認します。
見た目の確認と、外部へデータを送る確認は別の操作です。
実施できない部分は、その理由と残るリスクを記録します。
確認していない動作を「おそらく大丈夫」と成功扱いしないことが、承認の信頼性を保ちます。
承認前の検証資料は、見る順番も考えます。
利用者の動作、変更箇所、確認結果、未確認事項の順なら、コードを詳しく読めない担当者でも判断しやすくなります。
長いログの提出だけで説明を終えず、何が確かめられたかを短い文章へ整理します。
証拠へ戻れる場所も添えてください。
承認を権限と影響で置く
承認地点は、仕事の既存ルールと与えられた権限に基づいて決めます。
練習環境の編集、テスト、本番公開を一括にしないでください。
公開まで明確に許可された仕事と、変更案の作成だけを依頼された仕事では、進められる範囲が違います。
作業の依頼内容を境界として扱います。
Codexの実行環境にも、操作の制限や承認の仕組みがあります。
これは業務上の承認と同じではありません。
コマンドを実行できる設定でも、価格変更を決定する権限があるとは限りません。
逆に、依頼者が作業を依頼していても、環境上の制限で実行できない場合があります。
両者を分けて確認します。
承認を求める際は、対象、変更内容、検証結果、未確認事項を揃えます。
「進めてよいですか」だけでは判断できません。
公開前なら、公開先と実際の成果物を示します。
確認が必要な操作以外の作業は完了させ、担当者が具体的な結果を採用できる状態にしてから判断を求めます。
環境上の承認が必要になった場合は、要求された操作と仕事の目的を照合します。
確認表示を追加するために不要な権限まで広げないようにします。
別の許可済み手段で同じ検証ができるなら、その方法を選べます。
制限への対処も、成果に必要な操作を具体化してから判断します。
計画変更を完了報告へつなぐ
実装中に新しい条件が分かることがあります。
既存の入力チェックが確認表示と競合するなど、当初の案では対応できない場合です。
変更が必要なら、分かった事実、追加する範囲、検証への影響を短く整理します。
細かな方法を毎回承認に戻すのではなく、成果や権限へ影響する変化を扱います。
計画を変えたら、古い完了条件のまま検証しないようにします。
例えば同一画面から別画面へ方式を変えたなら、戻る操作や入力の保持も確認対象になります。
実装だけ更新して検証が古いままだと、重要な不具合を見逃します。
計画、変更、確認を同じ前提へ揃えます。
最終報告では、実現した動作、予定から変わった点、確認結果を対応させます。
未実施の確認が残るなら、利用開始へ影響するかを説明します。
次の担当者が、公開、追加検証、修正のどれを選ぶべきか判断できる状態が完成です。
計画は、その判断に戻るための基準として使います。
計画に残った未完了項目は、次の担当と解消条件を付けます。
試験先がないなら、担当者が用意した後に送信を確認するという形です。
単に残課題ありと書くより、再開できる状態へします。
納期までに解消できない場合は、公開判断へどう影響するかを分けて説明する必要があります。
実践課題
実践課題：三行の計画を具体化する
つくるものは、確認表示を追加する架空の計画です。
用意するのは、現在のフォームの動作を説明したメモです。
まず成果、変更、検証を各1行で書き、必要な承認を別に添えます。
具体的な実装コードは、この課題では不要です。
- 利用者ができる動作で成果を書く
- 現状確認と変更予定の役割を並べる
- 通常・修正・入力不足の期待結果を書く
- 公開前に示す情報と担当者の判断を決める
架空の完成例：「送信前に入力を確認し修正できる状態にする。既存処理を調べ、確認表示を追加する。入力不足、修正後の反映、試験用送信を確認する。本番公開は差分と検証記録を担当者が確認して判断する。」
自己確認
- 成果が画面の動作で判定できる
- 検証が追加機能と既存動作を含む
- 承認時の材料が揃っている
まとめ
計画では、利用者の動作、変更範囲、検証を対応させます。
承認は、権限と影響に合わせた地点へ置きます。
次の複数工程の依頼では、成果・変更・検証を先に書き、実行後も同じ基準で結果を確かめてください。
- 完成を利用者の動作で書く
- 業務承認と実行権限を区別する
- 計画変更に合わせて検証も更新する
