# 仕様／指摘内容の理解

## ルールの内容

- チケットに期待値と予定工数を入力する:
エンジニアは、チケットに対して自身の期待値と予定工数（Pull Request（PR）依頼までの工数とPR完了までの工数）を明確に入力します。
期待値は、エンジニアがそのチケットを実装する際に目指す仕様や結果を示すものです。
予定工数はそのチケットの実装にかかる見積り工数です。

- チケットの期待値の確認:
チケットを受け取った他の関係者（プロジェクトマネージャーなど）は、エンジニアが入力した期待値と自身の理解とを照らし合わせ、一致しない点や疑問点がある場合は迅速に議論します。
認識違いがある場合は、議論の結果導かれた仕様に基づいてチケットを修正します。

- チケットの予定工数の確認: 
チケットの予定工数も同様に確認されます。
他の関係者はエンジニアの見積りと自身の理解とを比較し、予定工数について疑問がある場合は議論を行います。
必要に応じて、適切な修正や再見積もりが行われます。

## ルールの目的

このルールは、開発プロセスにおける仕様／指摘内容の認識違いを早期に発見し、それによる問題を最小限に抑えることを目的としています。
認識違いがあるまま実装が進むと、後になって仕様に合わないことが明らかになり、修正や再作業が必要となります。
これにより、プロジェクトのコストが増加し、スケジュールの圧迫を招きかねません。
また、正確な仕様に基づいて作業を行うことで、最終的な成果物の品質が向上します。
早期に仕様の認識違いを特定することは、プロジェクトの効率性と品質を向上させる重要な要素です。

- チケットに期待値と予定工数を入力することの目的:
チケットの目的や要件を明確にすることで、開発者が自分自身の開発方針を整理することができます。
この段階で仕様において不明瞭な部分や不足している情報を明らかにすることで、修正や再作業を最小限に抑えることができます。
また、予定工数の入力により、開発者は担当するタスクのスケジュール管理を正確に行い、遅延や不足を予防します。

- チケットの期待値の確認をする目的:
もし開発者の開発方針に誤りがある場合は、関係者がチケットの期待値を確認することで明らかにすることができます。
これにより、作業がある程度進んだ後に認識違いが発覚することにより発生する修正や再作業を防ぐことができます。
正しい仕様認識の元で進められた作業の成果物の品質は向上するため、指摘量も削減されることで関係者がレビューに必要とする工数も削減できます。

- チケットの予定工数の確認をする目的:
前項の開発方針が正しい場合は、入力されている予定工数にも基本的には大きなずれがないものとみなすことができます。
これによりプロジェクトマネージャーなどは、より正確なタスクのスケジュール管理ができます。
スケジュールを圧迫する可能性のある、未把握の大きなリスクをなくすことでコストの削減や品質の向上につながります。

## ルールの重要性

- 問題の早期発見: 
仕様の認識違いを早期に発見することで、実装の進行中に修正や再作業を行う必要性を減らすことができます。
これにより、プロジェクトの進行に対するリスクを軽減することができます。

- コストとスケジュールの削減: 
認識違いによる修正や再作業は、追加の時間と労力を必要とします。
これにより、開発のコストが増加し、スケジュールが圧迫される可能性があります。
認識違いを早期に特定し、正しい仕様に基づいて作業を進めることで、コストの削減とスケジュールの遵守を実現できます。

- モチベーションの維持: 
認識違いによる修正や再作業は、同一のエンジニアが担当する場合、そのエンジニアのモチベーションを下げてしまうリスクがあります。
予期せぬ時間と労力を費やすことになり、自らの目標や次の作業のために費やせた時間を無駄にしてしまったと感じるためです。
自己評価の低下にもつながるリスクがあります。

- コミュニケーションの改善: 
チケットの期待値と予定工数を明確にすることで、関係者間のコミュニケーションが改善されます。
仕様についての認識や見積りの違いが明確になるため、意見の食い違いや勘違いを未然に防ぐことができます。

- 品質の向上: 
正確な仕様に基づいて作業を行うことで、最終的な成果物の品質が向上します。
認識違いによる問題や不正確な実装を未然に防ぐことができるため、顧客満足度の向上にもつながります。