作法はプロジェクトチーム全員で作ろう

それでは欲しい結果が得られない
プロジェクトチームに開発プロセスの具体的な手続き、たとえば設計からリリースまでの作業ステップは一般的にプロジェクトマネージャやプロジェクトのリーダのエンジニアが考えるものだ。ウォータフォールなら標準化した作業ステップをリーダから落とすし、アジャイルのスクラムならリーダからチームに共有する。プロジェクトマネージャやリーダのエンジニアがチームのエンジニア一人ひとりが同じように理解できるために子細までどうやって欲しいか説明する義務がある。なぜ義務があるかと言えば、それをして欲しいのだからして欲しい側の方から説明しないと相手にはわからないからだ。ところが、プロジェクトチームを見ていると、子細まで作業ステップや作業の状態を話すことは稀だ。だから、実際に作業をするときにチームのエンジニアは夫々各自の判断で作業をはじめ、リリースする段階で初めてリーダが要求していた作業ステップや作業品質との差異を具体的に認識することになる。これでは、チームは、自ら無駄な時間を浪費するだけで、やり直さないと本来欲しい結果が得られない。

チームの作法はチームで作る
開発方法論に問わず、プロジェクトを進める上でチームの作業ステップや作業品質について同じレベルでの共通理解が必要なことは、あえて書き記すまではないだろう。共通理解が最低限の品質を確保する下限値であり、プロジェクトのdeliverablesはその下限値が要求されるプロジェクトの品質を具体化する。人は各々の頭の中で思考を持ち、外から来る情報を理解して、考え、行動する。人は一人ひとり違うから、リーダが考えたことを子細且つ具体的なイメージを持って伝えないと実現してほしいことの半分も伝わらないものだ。まして、その伝え方が成り行き任せなら10%も伝わりしない。伝わらないということは、不経済な作業をチーム自ら作り出し、時間を消費し、後になってその結果を再び作業することを容認しているほかにならない。チームは、そのような無駄な作業に時間を費やすなら、チームとしての作法を共通認識の下でピタリと合わせるということを時間をかけてでもやるべきだ。それこそ、チームとして届けたいdeliverablesを得るために、要求された品質を適切な作業時間で確保するということになる。