デーブ・クイック私は、数百ものソフトウェアプロジェクトで働いたことがあります。どのプロジェクトも問題点を抱えており、結果的にはそれらが予想以上に大きなトラブルを引き起こしました。チーム内のごく少数のメンバーは早い段階から問題点があることに気付いていたのです。大多数はそれに気付いていなかったり、気付いていても深刻だと思わずに無視してしまっていたので、気がついたときには手遅れになっていたのです。プロジェクトには、次のような力が作用しています。最初はごく小さな問題に見えたことが、いつの間にかとてつもなく重大なものになっており、その頃にはもう手遅れになっていることがあります。ゆで蛙はおとぎ話に過ぎないかもしれませんが、多くのプロジェクトで起きていることの説明としては役に立ちます。自分以外の多くのメンバーと経験や知識を共有していない場合には、彼らから抵抗を受けることがよくあります。このような抵抗を制圧するには、並々ならぬ勇気、自信と説得力が必要です。そのために高給を支払ってベテランのコンサルタントを入れても、この問題はまず避けられません。ほとんどのソフトウェア・デベロッパーは楽観主義者です。私たちはみな、痛い経験をして、その性格をなんとかしなければならないことを学んでいるはずですが、特別な経験がなければ、楽観主義の方に走りがちです。性格的に悲観主義的な人は、たとえ一貫して正しいことを言っていても、開発チームの中では支持されないことが多いのです。した根拠でもない限り、チーム内での孤立を恐れずに多数派に反対するような人は滅多にいません。説明できない」という感覚を経験したことがありますが、その感覚を共有しても、議論に勝つことはまずありません。何が大切で何がそうでもないかということについての考えが、全員異なります。メンバーの関心は、プロジェクトの目標よりも、個人的な責任に傾きがちです。私たちは誰もが盲点や欠点を持っていて、自分では容易に認識したり受け入れたりできません。いった力を乗り越えるためには、次のような工夫をするとよいでしょう。リスク管理のために組織的な取り組みをします。シンプルな方法ですが、バグの追跡と同じようにリスクを追跡するのも効果的です。誰が見つけたリスクでも、それがリスクでなくなるまで、追跡を続けるのです。リスクには優先順位を付け、リスクの状態に変化が見られたときや新しい情報が得られたときには、その優先順位を見直します。すると、議論が感情的にならず、定期的にリスクを再評価することを忘れにくくなります。多数派に反対するときには、彼らの理解を助ける方法を探します。意見の相違があることに価値を見出すよう、チームを誘導し、感情的にならずに議論できる方法を探します。「いやなにおい」をかぎつけるのは大切なことです。問題のある事実が現れていなくても、事実を引き出せるもっとも単純なテスト方法を模索しましょう。チームや顧客についての自分の理解を絶えずテストしましょう。顧客が話した優先項目リストなどのツールがあれば役に立ちますが、何よりも大切なのは、聞かれた心で顧客と定期的にコミュニケーションを取ることです。盲点は、その定義からしても、認識しにくいものです。信頼できる人で、必要なときに苦い現実を言ってくれるような人は、とても貴重な存在になります。ソフトウェアアーキテクトが知るべき97のこと当サイトはオライリー・ジャパンによる公式なサイトではありません。個々のエッセイは「CC-by-3.0-US」によってライセンスされています。2プロジェクト・マネジャーが知るべき97のこと。