作業分担と作業の階層化

チームメンバーのアサインに関する考え方は前項で説明しましたが、作業切分けについても工夫が必要である。ソフト開発で作業の階層化を行う場合、私はこのように工程により作業を区切っている。テストには大いに学ぶところがある。まずは、ユーザーとして参画し、詳細なロジックよりも機能仕様の観点から入り、自分の目指す方向性をおぼろげながらでも確立することが出来る。これは、新人だけではなく、他チームから移籍してきたメンバーに対しても同様に有効である。これを行うことにより、設計時に視野の広い設計が可能となる。下流工程設計では、先輩の行った上流工程の設計書もしくはテスト検仕をみて、参考にもし反面教師にもして今後自分が設計するときの肥やしにす。これは、OJT の一環と考えている。この方式では、入社２，３年目までは上流工程の設計が出来ないことになる。ましてや新人はテスト担当となり、設計すら出来ないことになる。だがこれでよいのではないか？テストや下流工程の設計をしっかり行えなければ、上流工程の設計は行えない。下流工程の経験は蒸留工程には必須である。もし、早く上流工程を設計したいと文句の言う元気のある若者がいたとしたら、それはそれまでの作業をいち早く習得することを薦める。そこで腐るようであればそこまでである。上記の階層化では、各工程担当者間のコミュニケーション増加が問題点として挙げられるだろう。設計フェーズでは、出来るだけコミュニケーションを減らしたほうがよい設計が出来る。極端に言えば、一人で全工程行ったほうが精度の高い設計が出来ることは確かだが、それは狭義の中での話である。これまで述べてきたように、プロフェッショナル思考はチーム力向上の妨げになる。上記のように設計工程で担当が分かれる場合、インターフェースは設計書が主になるが、それらを媒介する事によっておのずと設計書の精度も上がるし、各担当者間のコミュニケーションの勉強にもなる。上流工程設計になると、他チームとの調整も必要になる。その時の為の勉強の一環にもなる。このように、チーム運営とゆう大きなくくりで言えば特に問題とはならず、チーム運営の一環として捉えることが出来る。

このように、チームでは一人では出来ない作業の分担と知識の継承、OJT が可能となる。また、工程の階層化を行うことにより、工程のパイプライン化を可能とし、スケジューリングの幅を持たせることが出来る。このことだけでも、チームの有用性があると言えるでしょう。

vol.15

比較的大きなチームでなければこのようなことは出来ないし、プロジェクトマネジメントの良い面もでてこない。上記のことはチームだけではなく組織にも言えることだと思う。行き当たりばったりの人員配置しかしていないと、まともな教育が出来なくなり、かなり偏ったスキルになってしまう。それは組織にも不幸だが、なによりもその人自身が一番不幸な結果となっちゃいます。組織は人を育てるもの。今だけを見ないで先をみて育てたいものです。