8．手続きによる壁を作る
開発チームが追い詰められていると感じる場合、それに対する自然な反応の1つは、物事のスピードを落とすために、多くの手続きを作ることだ。わたしはどんな簡単な変更でも変更申請書（もちろん紙で）を3通作成して稟議にかけ、関係するマネージャーのサインを集める必要があり、その上で作業が終わるまでに最短で45日間かかるという職場で働いたことがある。言うまでもないが、この組織はビジネスでは「パートナー」や「仕事をするために重要な相手」と見られることはなく、コストセンターであると見なされ、そのように扱われた。手続きによる壁は、手続きの中にあるより根が深い問題や、企業文化の問題に対処するための対症療法であり、壁を作ることはそういった問題そのものを解決するよりも簡単だが（一部の企業では、問題が解決不可能な場合もある）、手続きによる壁を作ることは非生産的であり、敵意に満ちた環境につながる。
9．「すぐに本格的な作業を始められる」という神話
プロジェクトに人を増やす時には、すぐに本格的な活動を開始できると仮定しがちだ。ソフトウェア開発の世界にはすぐに本格的な作業を始められるということはあり得ないし、そういう発言をする人は間違っている。すべてのプロジェクトには順応期間があり、プロジェクトが大きくなるほど順応期間も長くなる。これは、あらかじめ理解し、掌握しなければならないコードの量が多くなるからだ。これを計算に入れるのを忘れると、大きなトラブルになる。プロジェクトの初期にはこれに数日から数週間しかかからないかもしれないが、プロジェクトが始まって長い時間経ってから参加した開発者が生産性を完全に発揮するには、何カ月もかかる可能性がある。
10．マルチタスク
これも、多くの人が自分が持っていると考えているが、本当には持っていない「スキル」の1つだ（「すぐに本格的な活動を始める」スキルと同じように）。マルチタスクを要求すればするほど、仕事の質は落ち、時間もかかるようになる。これは、数分単位のマルチタスク（電子メール、電話、実際の仕事などを切り替える）にも、数時間から数日単位のマルチタスク（複数のプロジェクトを処理する）にも当てはまる。人材に対して多くを要求するほど、歯車の狂いは大きくなる。さらに悪いことに、マルチタスクは仕事をダメにしがちなだけでなく、人間を押しつぶし、最終的にその人は他の仕事を探し始めることになる。その結果、プロジェクトの最中に新しい人材を迎え入れざるをえなくなり、さらに問題は大きくなってしまう。
この記事は海外CBS Interactive発の記事を朝日インタラクティブが日本向けに編集したものです。
