第１２回　大規模プロジェクトの体験を通して（その７：７カ条の教訓）

ＩＴ部門におけるプロジェクト・マネジメントも今回で最後になりました。今回は、筆者のプロジェクト・マネジメントの体験から得た、プロジェクト・マネジメントにおける教訓を７カ条に纏めましたので、ご紹介します。

筆者が興味深く思ったのはリーダーのタイプ分類の部分です。以下にその概略を示します。

１．真の利用者（ユーザ）を常に考えよ。

様々な場面で利用者（ユーザ）が登場します。システムの企画部門、システムの開発部門、システムの運用部門、システムの利用部門、企業の経営部門などがシステムの開発・運用・利用に関わっています。ユーザ仕様の決定の時に、一般的にはシステム開発部門が顧客の代表として利用者（ユーザ）になっています。しかし、システム開発部門だけとユーザ要求仕様の検討・調整作業をしていると、企画部、利用部門、運用部門、経営部門などからの指摘や要望で、要求仕様を大幅に変更することがあります。仕様問題が発生すると、実際は顧客企業の調整不足等にも拘わらず、システム開発受注企業からの「提案が無い」、「問題の指摘が無い」とか非難されることもあります。顧客企業の問題であれ受注企業の問題であれ、作業のやり直しが発生すれば、コストが増大し、納期やコストを圧迫します。これを防止するには、開発者自身が「システム利用者の立場になって、この要求仕様で良いのか？」と繰り返し自問自答し、少しでも疑問があったら納得するまで確認することが重要です。開発者が受注企業の場合、特に「システム利用者の立場」になって、積極的に確認することが必要なのです。そして、顧客企業の様々な部門の人々の要求を整理して、利用者（ユーザ）の真の要求を自分なりに把握・納得したうえで、システム開発に臨むことが重要なのです。

２．全員合意の意思決定の仕組みを追求せよ。

システム開発には、様々な意思決定の場面が出てきますが、限られた時間内での意思決定が必要です。技術的な問題で意見が分かれた場合、技術的な論議を十分に尽くさずに、多数決、声の大きい人への意見採用、発注者側の押付けなどの不合理な意思決定手段を使うと、後々に問題を残します。特に技術論が不十分なままに発注企業が横暴を押し通した場合、問題が感情問題に発展して修復が困難な状態になり、システム開発が延期や中止になった事例が多くあります。関係者全員の合意を得るのは、時間がかかり大変な苦労が伴いますが、結果的には早道です。不合理な意思決定は、プロジェクト失敗の原因になります。特に受注企業の立場の場合は、技術論では絶対に妥協すべきではありません。逆に発注企業の立場の場合は、発注企業が想像している以上に受注企業は反論できないことを察して、「発注者の横暴」にならないように細心の注意をすべきです。この問題の予防措置として、本音のコミュニケーションの仕組みや全員合意の仕組みを構築することが必要でしょう。「急がば回れ」です。

３．常に先行試行を心がけよ。

どんな理論や手法を持ち込んでも、未来に発生する問題を完璧に見通して、プロジェクトを遂行することは不可能です。同じ事を２回繰り返すことが出来れば、２回目には学習効果が働いて、プロジェクトを失敗から救うことができます。これを実プロジェクトで実現させる方法は、公式スケジュールに対してプロジェクト（あるいはプロジェクトの重要部分）を先行試行して問題点を洗い出しながら、プロジェクトを遂行することです。この先行試行を上手（メンバの緊張感や真剣さに気の緩みが出ないように工夫して）に組み込んでプロジェクトを遂行していくのがコツでしょう。筆者の経験では、少数の主要メンバだけが知っていて、他のメンバに内緒でこの先行試行手法を使うことが出来れば、成功の確率をより高めることができるでしょう。

４．ミスや誤解を前提に手順や仕組みを構築せよ。

システム環境構築作業や運用作業の手順や仕組みを考える場合、プログラミング作業よりも軽く作業ミスや誤解を想定して計画する事が多いのですが、実際にはシステム環境構築作業や運用作業においては、テスト期間やレビュー期間が少ないためにプログラミング以上に予想外のトラブルが発生します。プログラム・バグ以外のトラブルにより、計画が遅れることが非常に多いのです。特にシステム運用開始後の緊急作業の場合は、緊張感の高いぶっつけ本番の作業になりますので、運用者のミスや誤解発生時の対処を十分に考慮した手順や仕組みの構築が必要です。出来れば作業の完全自動化を実現して、運用者に判断や操作をさせないような配慮をして頂きたいと思います。開発者が運用のことを楽観視して、「異常が発生した時はシステム運用者判断」という発想でシステムを開発することは、絶対に止めて下さい。

５．最新技術よりも運用後の成果を重視せよ。

技術者は新しい技術に憧れがあるのか、最新技術を使うことに価値観を感じて、利用者に対する効果や利便性を正当に評価しないことが良くあります。過去にブームとなったような新技術の初期段階には、過大宣伝に惑わされて成果や利便性が伴わないことが多くありました。筆者は、新技術を使ったために多大なコストと時間を費やした結果、殆ど成果を得らないプロジェクトを経験したことがありました。そのシステムは、システム利用者のメリットがないために使用されず、技術者の自己満足に過ぎないことが明確になり、結局はお蔵入りになりました。技術的価値に対して異常に興味のある方がシステムの責任者の場合は、厄介なことになります。個人的な技術的趣味の実現が、プロジェクト目標になった場合は最悪です。プロジェクトの早い時点で、現実的な目標設定に誘導することが重要です。客観的に技術のトレンドと効果の関係を判断して下さい。

６．スキルアップの前に心の鍛錬を。

技術進展に伴って、開発技術者は新技術スキルアップのために教育訓練をますます重視しています。様々な技術の資格が登場し、様々な教育プログラムが整備されてきています。一方では、SEには欝病の人が増えています。人との関わり合いの多いシステム構築作業において、人間関係に対する心や精神力の鍛錬が不足したために生じた現象だと思います。技術のスキルアップと同等以上に、様々な人達と共同作業を円滑に実施していくための心や精神の鍛錬が重要です。しかし、心の鍛錬をする有効な教育プログラムが無いのが現状です。この問題に対して筆者は、日常のプロジェクトの実践現場でも、各人が心や精神力の鍛錬をする努力が必要だと感じています。各人が自ら心の鍛錬の重要性をもっと理解すべきです。筆者が経験した有効な鍛錬は、様々な人（特に嫌な人）と接触し、話を丹念に聞き、心情を深く理解し、できれば共感を得るまでの努力をすることです。性格や遺伝の問題として諦めないで、日頃の努力で解決すべき問題だと思います。

７．プロジェクトの利益を優先せよ。

平穏時、自分の利益よりもチームの利益を優先して行動することは比較的容易ですが、問題発生時にチーム利益を優先する行動をすることは難しいことです。自分だけが不利益を蒙る場合、チームの利益を優先することはなかなか出来ません。特に大規模プロジェクトの場合、たった一人が犠牲を払っても効果が無いと考える人が多いでしょう。しかし、プロジェクトが利益を得ない限り、自己の利益、自社の利益は得られないはずです。各人がプロジェクトの利益を無視して、自己の利益や自社の利益だけに走ったら、プロジェクトは崩壊します。問題発生時に、「プロジェクトの利益優先」を自ら示すのがリーダー・シップです。真にリーダー・シップのある人は、どんな場面でもプロジェクトの利益を優先して、最大限の努力するのです。このリーダー・シップを心意気に感じて、プロジェクト・メンバは団結していくのです。

この７カ条は、あまりに理想的過ぎると考える人が多いと思いますが、目標を高く置いて努力しなければ、極めて低いレベルで努力しなくなるでしょう。この７ヶ条はそんなに簡単に出来ることではないからです。分かっていても実行が難しい、奥深いテーマなのです。自らの戒めとして活用して頂いても結構です。