チームにズレを感じたら、スタート位置に戻ろう

上手くいっていないプロジェクトチームのメンバは不満を言いながらも下を向いたり、他所を向いたりしている。不満を言わないからと言って、どこを向いているかと言えば、明後日の方を見ていたり、目の前のタスクだけを見て周りは気にかけない。

そんなプロジェクトチームでも一人ひとりに『なんのためにコードを書いているか』と尋ねれば、『システムを完成させるため』とか『プロジェクトを成功させるため』と返ってくるだろう。振る舞いはそうは見えないのに答えだけはもっともらしいことを言う。

あなたのチームは、botのようなチームになっていないだろうか。

ウォーターフォールの開発手法を取っているプロジェクトであるからと言って、プロジェクトマネージャが全てのWBSを作成して、メンバに作業指示を出し、一つひとつタスクの進捗をトレースすることはしていないはずだ。

必ず、メンバにデレゲートする部分が出てくる。そのくらい作業は多く複雑でプロジェクトマネージャ一人では目が届かない。

システム開発は、工場で決まったものを決まった日に決まっただけ作るような作業ではない。

エンジニアリングとアーティスティックの組み合わせこそ、システム開発を表す表現なのはそのためである。

組み合わせるためにチームはその組み合わせを機能させなればならない。チームメンバ自身で考え、チームのメンバと連携しなければ実現できない。

チームを客観的に見ることができる位置にいるのがプロジェクトマネージャである。不満が出ている、他所を見ている、フォーカスし過ぎていると気づけるのはプロジェクトマネージャで、プロジェクトマネージャこそ一番近い場所にいるのである。

観察をしよう。

昨日との違いを見つけよう。

なぜメンバの仕事は遅延しているのか。

なぜ、コードの品質が悪いのか。

チームにズレを感じたら、スタート位置に戻ろう。

なんのためのプロジェクトか。

なぜコードを書いているのか。

チームの存在意義はスタート地点にある。それを確かめよう。

チームのビジョンに立ち返ろう。

チームメンバ全員が同じ方向に顔を向けよう。

そのビジョンを実現できる行動をしているか、メンバに問いかけよう。メンバ同士で連携しよう。

その集成がシステムなのだから。

そのシステムが完成しなければ、ユーザに届かないのだから。

 

チーム (実業之日本社文庫)

チーム (実業之日本社文庫)