すべてのタスクは緊急で重要です
こんにちは、クラウド型バージョン管理サービス tracpath(トラックパス)を利用して頂いている企業とBtoB向けのシステム開発に協力させて頂くことがあります。多くは企業向けのシステム開発であったり、ウェブサイト、ECサイトの開発をサポートしています。また、開発プラットフォーム構築や開発インフラに特化したサポートもさせて頂いています。
深くプロジェクト内部に入って知れば知るほど企業によってプロジェクトの運営方針や考え方が大きく異なっている点を見つけることが出来ます。
プロジェクトの方針や工程毎の進め方は、プロジェクトの条件や環境、その時の状況によって大きく変わってきます。今回は、できるだけ一般的と思える（独断です）点をピックアップしています。ソフトウェア開発プロジェクトのリーダーに見られる危険な兆候を考えてみたいと思います。
危険な兆候とは
プロジェクトのリーダーはだれもプロジェクトを成功させたい、顧客のために最大限努力してよいものを作りたい、と考えています。この考えはすばらしいことです。でもプロジェクトでこのようなやりとりを見たことはありませんか？
「顧客から新しい要望が挙がってきたので何とか対応したい、今の開発に含めるためのスケジュールを調整したい」「仕様が変わったので来週までに絶対に対応しなければいけないし、対応しなければ他の作業が意味なくなってしまう、そのためにチームのスケジュールを調整したい」「指摘された点はほんとうに重要な問題、他のタスクを止めてでも今日中に対応したい。止めたタスクもオンスケで。」「ドキュメントの修正が緊急で依頼されたので来週までに対応して欲しい」
プロジェクトは予測できないことが頻繁に起こります。計画を立てるがその通りに進むことの方が少ないくらいです。
顧客からの仕様変更、要望追加やバグ対応、急な変更依頼などプロジェクト計画を送らせる要因はたくさんあります。プロジェクトチームをこのような判断の連続や外部からの圧力によって作業に影響が出ないよう防波堤の役割をしているのがチームリーダーの仕事の一つでもあります。
その防波堤の役割がなかったら…リーダーが顧客に言われたことはそのまま実現しなければいけない(=顧客の要望に応えたい)と考えていることは危険な兆候の一つです。
このようなリーダーの場合、すべてのタスクの緊急度が高く、綿密な計画を立てるよりも目の前の緊急性のタスクを処理する方が良いと思っています。 目の前の緊急性の高いタスクのためにスケジュールは頻繁に更新され、期限と作業範囲が何度も変わってしまいます。
プロジェクトリーダーの問題より、企業文化？
これはプロジェクトのリーダーだけに問題があるわけではなく、企業文化によって作られる部分があるかもしれません。 いつでも全力で走ることが良いと考えていたり、いつでも緊急性のタスクを処理している切迫感が重要と考えていたり、毎日終電まで仕事したり、週末を当たり前のように仕事のスケジュールに入れて使ったり、それががんばっているチームと評価されたりするなどです。
このようなチームのプロジェクトはすべて失敗するわけではなく、うまくいったり、何年も続く(外から見ると)安定して運営されているプロジェクトに見えるときがあります。でもいつまでも全力疾走し続けることはできないと思います。
いつも急ぎのタスク、緊急性の高いタスクばかりではないし、プロジェクトチーム全員がリスケジュールされた緊急性の高いタスクに関わるわけでもないです。
チームリーダーは、急ぎの仕事、依頼された仕事の優先度と重要度を考えてスケジュールし、顧客と交渉することがチームを守り、顧客のためになると説得するよう努力すべきです。自分たちで気づき変えていくしか解決方法は存在しないかもしれません。
この「すべてのタスクが緊急で重要」という呪縛から逃れる方法は何だと思いますか？
参考