これは何か
開発・レビュー標準は、たくさんの開発者が同じシステムを作るときに、「プログラムをどう書くか」「変更を誰がどう確かめるか」「何がそろえば作業が終わりと言えるか」をそろえるための決まりをまとめた成果物です。
会社も経験も違う人が集まると、名前の付け方やエラーのときの動きがばらばらになり、読む人が毎回意味を確かめることになります。レビューにも保守にも時間がかかります。この標準は、そうした「人ごとの違い」を減らすためのものです。
レビューで何を見るかの考え方は 09-02 コードレビューは何を見るのか、大人数で同時に変更するときの問題は 09-01 同時に100人がコードを変更したらどうなるか で学びます。
なぜ作るか
- 誰が書いても、同じ読み方ができるプログラムにする
- レビューの進め方（誰が、何人で、どこまで見るか）を人によって変えない
- 「終わった」の意味をそろえ、作業の引き渡しでもめないようにする
- 自動でチェックできる決まりは道具に任せ、人のレビューを大事な点に集中させる
誰が使うか・いつ作るか
- 作る人：開発の取りまとめ役と、システムアーキテクト。各社の開発リーダーも加わる
- 使う人：すべての開発者、レビューする人、テストの担当、新しく加わる人
- 一般的には、開発が本格的に始まる前に作り、実際のレビューの指摘を反映して更新します
- マルチベンダーの案件では、全社共通の決まりと、各社が追加してよい決まりを分けて書くのが一般的です
- アステリア案件の開発・レビューの決まり（書き方・レビューの人数・終わりの条件）は、正本に記載がありません。未確定
CASE FACTFROZEN正本に記載されたアステリア案件の事実
開発に関係する記載
- 約120人規模のプロジェクト、マルチベンダー
- システムに SYS-09 開発・CI/CD基盤、SYS-10 AI開発エージェントがある
- P-008 黒田 健 — システムアーキテクト
- AIは意思決定責任者ではなく、人間が管理する作業実行・支援手段とする。設計承認は、AIへ最終委任しない事項の1つ
アステリア案件で、誰がこの標準を作り、承認し、各社がどこまで独自の決まりを持つかは、正本に記載がありません。未確定 上の人物が標準を承認するという記載もありません。未確定
主な項目
一般的には、次の項目で構成します。
- 適用範囲：どのシステム・どの会社の開発に使うか。共通の決まりと、各社の追加の決まりの区別
- 書き方の決まり：名前の付け方、書式、エラーのときの動き、記録（ログ）の残し方、個人情報の扱い
- 自動チェック：書式や禁止された書き方を、道具で自動的に確かめる範囲（09-04）
- レビューの進め方：変更の種類ごとに、誰が、何人でレビューし、特に何を確かめるか（観点の考え方は 09-02）。返事の期限、指摘の記録。1回の変更は1つの目的にする
- 完了の決まり：作業を「終わり」と言うために、そろっていなければならないもの
- AIを使って書いたプログラムの扱い：人が書いたものと同じ標準で確かめる（AIの使い方の方針は AI-001 AI開発利用方針）
- 例外と見直し：標準に従えないときの了解と記録。よく出る指摘を、いつ標準に反映するか
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 変更の種類ごとのレビューと完了の決まり
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
次の表は、標準の書き方を学ぶための例です。内容はすべて教材上の架空の例で、アステリア案件の記録ではありません。
| 変更の種類（教材上の例） | レビューする人 | 必ず見る点 | 返事の期限 |
|---|---|---|---|
| 画面の文言・表示の並び | 同じチームの開発者1人 | 業務の用語の表記が用語集と合っているか | 翌営業日 |
| 業務の計算（金額・日数など） | 同じチームの開発者1人と、業務の仕様が分かる人1人 | 端数の扱い、条件の境目、計算の元になる要件 | 2営業日 |
| 権限・個人情報に関わる処理 | 開発者1人と、セキュリティの担当 | 誰が何を見られるようになるか、記録が残るか | 2営業日 |
| 連携で受け渡す項目 | 開発者1人と、連携の相手の担当 | 項目の意味と形が、連携の仕様と合っているか | 相手と決めた期限 |
| 完了の決まり（教材上の例） | 確かめ方 |
|---|---|
| 自動チェック（書式・禁止された書き方）に通っている | 道具の結果 |
| 変更に合わせたテストを追加し、合格している | テストの結果と、追加したテストの一覧 |
| 決めた人数のレビューで承認されている | レビューの記録 |
| レビューの指摘がすべて対応済み、または対応しない理由が書かれている | 指摘の記録 |
| 設計書・手順書など、影響する文書を直している | 文書の変更の記録 |
読み方
- 変更の種類によって、レビューする人と必ず見る点が変わっているか（全部同じ扱いになっていないか）
- 業務や安全に関わる変更で、開発者以外の人が加わっているか
- 完了の決まりが、確かめられる形（記録・結果）で書かれているか
- 自動チェックに任せる部分と、人が見る部分が分かれているか
書き方
- 道具で自動的に確かめられる決まりを先に決め、道具に設定する
- 変更の種類ごとに、レビューする人・必ず見る点・期限を決める
- 完了の決まりを、確かめ方と一緒に書く
- 各社の開発リーダーと読み合わせ、最初の数週間の指摘を見て直す
何を書いてはいけないか
- 「読みやすく書く」「十分にレビューする」のような、人によって意味が変わる決まり
- 守られているかを確かめる方法のない決まり
- 実際には守れない厳しさの決まり（守られない決まりが、ほかの決まりまで軽く見せる）
どこを見るか
- 変更の種類ごとのレビューの決まり
- 業務・安全に関わる変更に加わる人
- 完了の決まりと、その確かめ方
- 自動チェックの範囲
- 例外の扱いと見直しの予定
赤信号
- レビューの記録を見ると、承認までの時間が極端に短い変更が多い（読まずに承認している可能性）
- 会社ごとに書き方が大きく違い、共通の決まりが守られていない
- 標準が開発の初めに作られたまま、一度も更新されていない
よくある失敗
- 書式の細かい指摘がレビューの大半を占め、業務や安全に関わる点が見落とされる（書式は自動チェックに任せる）
- 「終わった」の意味が人によって違い、作業を引き渡すたびに確かめ直しが起きる
関係するUnit・成果物・危機演習
- Unit：09-02 コードレビューは何を見るのか、09-01 同時に100人がコードを変更したらどうなるか、09-04 自動テストと自動配布
- 成果物：DEV-004 環境・リリース対応表、AI-001 AI開発利用方針、TST-001 テスト戦略書
- 危機演習：この成果物を直接の題材にする危機演習はありません
AI WORKFLOW
AIは、レビューの指摘の記録から、標準に足すべき決まりの候補を探す下書きに役立ちます。
「このレビューの指摘の記録を、指摘の内容ごとにまとめ、件数の多い順に並べてください。それぞれについて、現在の開発・レビュー標準に対応する決まりがあるかを示してください。新しい決まりを作ったり、決まりの良し悪しを判断したりしないでください。」
REVIEW
- AIのまとめ方が、元の指摘の意味を変えていないか
- 指摘の記録を AI に渡してよいか（プログラムや情報の扱い）を、事前に確かめたか
- 件数が少なくても重大な指摘（安全に関わるものなど）を、人が見落としていないか
人間が判断すること
- 変更の種類ごとに、誰が何人でレビューするか
- 完了の決まりに何を含めるか
- 標準に従えない例外を認めるか
いつ使うか
この教材では STAGE 09｜120人で安全に開発する の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
この標準を初めて読んだ開発者は、「どう書き、誰にどうレビューしてもらい、何がそろえば自分の作業を終わりと言えるか」を説明できますか？