報告と指導

ソフトウェア開発組織におけるコミュニケーションは、非常に重要な要素です。毎朝のスクラムミーティングで状況の確認や指導、あるいは、毎週の週報会での活動報告を受けての状況の確認や問題点への対応の指示などを行う場であったりします。

しかし、リーダのソフトウェア開発経験や人材育成に関する考え方次第では、単なる「報告会」になってしまうのか、「報告と指導の場」になるのかという大きな違いが発生します。単なる報告会になっていると、チームで集まって報告を聞くことが無駄だと感じてしまい、全員を集めるミーティングは無駄という発想になってしまいます。

指導の場も兼ねるという発想だと、報告内容を深掘りする質問をしたり、他のメンバーにも分かるように説明を求めたり、あるいは、本来どうすべきかの指導をしたりします。そして、重要なことは、それらすべてを参加メンバーと共有することで報告者だけでなく全員への指導となる訳です。

コードレビューでたとえると、一行一行処理が正しいかとか読みやすいかとかのきちんとしたレビューをしないで、表面的に「何となくいいのでは」というレビューをしていくと、レビューを通して指導する場ではなくなり、無駄な時間と考えられてしまいます。なぜなら、レビューをしてもコードの品質は上がらないし、レビューを受ける側のレベルが上がるような指導を受けないからです。

別の例で言えば、現場の担当者がビルドを手作業で行っているとしたら、リーダはそのような報告の場で、自動化するように指導したり、自動化のために他の作業との優先順位の調整をしたりすることが必要です。しかし、技術的指導も含めて指導しない人がリーダの場合には、手作業で行うのが問題であるという認識がなかったりして、指導するという場面がなく、単なる報告会になってしまったりします。そして、全員が集まるのが無駄という感覚がメンバー全員に浸透してしまいます。

一対一の指導は、非効率です。同じ知識を全員に伝達するには多くの時間を要しますし、あるいは全員に伝える機会も時間もないかもしれません。そして、単なる報告会しか行わないミーティングばかりだと、基本的なことさえ開発組織全体に浸透しなかったりするかもしれません。