計画（タスク分解）レビューの勧め

エンジニアリングは抽象的な課題やタスクを具体的にしていく。チームや個人のエンジニアリングのスキルが高ければ高いほど、抽象的な状態から具体的にすることができるだろう。

っということは「依頼の内容」と「チームや個人のスキル」次第で何かをお願いした結果、想定外の内容が返ってくることになるだろう。

エンジニアリングではそれを予防するためにレビューというものがあるが、実は結果をレビューすることが多い。設計レビュー、実装レビュー、テスト設計レビュー、テスト仕様書レビュー。

例えば、設計の誤りは設計書完成後のレビューで見つかる。プロジェクト全体でみるとリリース前に見つかっているので予防になっているが、工程という単位では誤りが設計工程の最後に分かる仕組みになっている。

これをどうにかしたいと悩んでた。特に大きな認識齟齬。タスクの終わりではなくもっと前で。そこで思いついたのがタスク着手後に時間を確保して、計画を立て（タスク分解）、その計画をレビューする。その後、タスクを消化する。

結果を出す過程（プロセス）の認識合わせをすることで結果の認識齟齬を減らそうと。それも認識齟齬をゼロにする！という完璧主義ではなく、認識齟齬が減ったらいいなぐらいの感覚で。

事前に認識齟齬を減らせる以外に、過程を複数人でチェックすることで不安を分散したり、想定外のことが起きた場合に相談がしやすかったりと心理面でも楽になることもある。漠然と仕事をどう進めればいいか分からないという不安を持っているOJTにも使える。

計画（タスク分解）レビューを是非、お勧めしたい。

※後々、スクラムを勉強して分かったことは、スクラムではスプリントレビューで計画やタスク分解のレビューをしており、同じ仕組みである