第２回　リーダシップとマネジメントスキル

• #プロジェクトマネージャー

リーダーシップ

よく「リーダシップを発揮する」などといいますが、リーダシップという言葉ほど解釈が多様な言葉も無いでしょう。実際、リーダシップを発揮しようと思えば思うほど、結果的には発揮できないものかも知れません

チームメンバーとコミュニケーションをはかる

PMは、チームメンバーとのコミュニケーション、及びチームメンバー同士のコミュニケーションに気を配る必要があります。チームメンバーから上がってくる報告を見ることにより、メンバーの誤解や理解不足が判明したり、重大なリスクの兆しが見えたり、チーム間の摩擦や改善すべき問題点を知ることができます。

時にはメンバーが失敗したりミスをしたりすることもありますが、頭ごなしに怒鳴っても改善されるものではありません。むしろ、原因を把握してニ度と発生しないような対策を講じるなど、プラス方向のリカバリーを考えるほうが有意義です。

PMがこのような態度を取れば、チームメンバーは自主的、積極的に仕事に取り組んでくれるでしょうし、一時的な言い訳や取り繕いに逃げることなく、いつも本音を話してくれるようになるでしょう。

本音で突っ込んだ議論をする

日本では正式な会議の場で議論を避け、形式や格好を重んじて事を荒立てないように重大な問題を先送りすることがよくあります。プロジェクトの状況を顧客企業に報告する場合でも、格好を重んじて懸案事項、問題点を明らかにしない傾向にあります。

しかしながら、本当に重要なことは正式な会議の場で物議を醸してでも議論したほうが、一時的に格好悪くはなりますが、同時に多くの重要なステークホルダの認識を得ることができるので、結果的にプロジェクトが進めやすくなる場合がよくあります。

顧客と仲良くなる

既に述べたようにITシステムは「使ってもらってナンボのもの」ですので、ITを使っていただく顧客とは馴れ合いにならない程度に仲良くなるべきです。顧客の中にもスポンサ、ユーザ、さらに情報システム部の業務系、運用系、基盤系など、いろいろな立場の人たちがいて、エンドユーザ部門、スポンサ、上位マネージャの間で板ばさみになって苦し紛れに発注先に怒りをぶつけてくる人もいます。しかし、少なくともプロジェクトが走っている最中は、できるだけそういう人たちの立場を理解しなければなりません。いろんな人たちがいたとしても共通の目的は「プロジェクトが成功し、成果物が期待通りに使えるようになること」です。

プレゼンテーションを実施する

PMは、下記のような時期にプロジェクトキックオフミーティングを開催し、進むべき方向を示しチームメンバーを動機付けなければなりません。

1. プロジェクト開始時期で、ある程度のチームの体制ができた時点。
2. 基本設計、詳細設計などの設計フェーズが終了し、製造に開始する直前
3. システムテストを開始する直前
4. 本番移行を開始する直前

プレゼンテーションの基本的な注意点は下記のようになります。

1. マテリアルの注意点
   • 主題は単に名詞だけで終わらず、動詞、形容詞を含み、主張がわかるようにする。
   • 箇条書きかつシンプルで正確に記載する。
2. しゃべるときの注意点
   • 最初に、挨拶、自己紹介、主題紹介、プレゼンテーションの理由（内容、時期、聞き手に対する期待）を簡単に伝える。
   • 「簡単な前置き→内容説明→まとめ」を繰り返す。
   • しゃべる時には必ず聞き手を見る。一つのことをしゃべるときに、聞き手の一人を選択して話し掛けるようにするとよい。

マネジメントスキル

バランスを重視する

そもそもプロジェクトは、品質、コスト、納期、成果物の性能、機能、プロジェクトチーム、プロジェクトチームの所属組織、顧客企業など、相反する要素が複雑に絡み合っていて、その間のバランスを取ることが、非常に重要となります。PMは顧客とチームと会社の三又を掛けるバランスが要求されますし、チーム間の進捗、会社間の進捗もバランスが重要です。

世の中にアンバランスの例は、たくさんあります。周りにほとんど人家も無いのに突然立派な公会堂が建っていたり、周りの道路は細くて曲がりくねっているのに限られた一箇所だけ道路が整備されて立派なショッピングビルが建っていたり。また、ある小島では一つのホテルだけが非常に豪華ですが、島内には、バスもタクシーも無く、海水浴場などのめぼしい施設がほとんど無かったりします。

しかし、このようなアンバランス（もしくは一点豪華主義）は、豪華さを維持するコストが増大し、周りに掛かる負荷も増大し、いつか破綻します。

プロジェクトでもバランス感覚は大切です。

例えば、一つのサブチームだけが他のチームを省みずに進みすぎることが、プロジェクト全体にとって有害となり得ますし、複数の企業が参画するプロジェクトの場合において一つの企業だけが進みすぎるのも有害となり得ます。

以前、あるプロジェクトで、アプリケーションの開発標準の策定前にも関わらず、プロトタイプの開発だけが異常に進んでおり、顧客側もそのチームに過剰な期待を抱いていました。プロトタイプチームは、重要なアプリケーション要件を選んでプロトタイプ開発していましたが、アプリケーション開発標準の策定前であったため、エラー処理すらやっていませんでした。さらに、あるミドルウェアの機能を使って複数のユーザに情報を同報していましたが、あるユーザに情報が届かない障害が発生しても、それを検知する手段がありませんでした。さらに、そのミドルウェアを本来の使いやすい形式で使用していませんでした。

もはや、そのままプロトタイプ開発を進めても意味がありませんでした。プロトタイプチームの各メンバーはやる気満々でしたが、私は顧客に、これからはプロトタイプではなく本物を作るために開発標準を策定し、それに則った本物を設計すべきだと説明しました。また、情報欠落の障害が分からないようなミドルウェアの機能は使わずに、同様の機能を手作りせざるを得ないこと、なども説明しました。その日のうちにプロトタイプチームは解散しました。やる気をそがれたプロトタイプチームメンバーは、解散させられた理由がよく分からなかったようですが、プロジェクトが進むにつれて次第に納得してくれました。

コスト構造を把握する

プロジェクトのコスト構造は、一般的に以下の表のようにまとめることができます。PMはプロジェクトの収支を把握するとともに予想する必要があります。

なお、この表ではプロジェクトを一括で契約した場合を想定しています。

変更管理を実施する

プロジェクトには変更がつき物で、具体的には下記のような変更が発生します。

1. 業務ニーズの変更による成果物の変更
2. 様々なマイルストーンのスケジュール変更
3. 基本設計後、詳細設計後、または製造後の成果物の仕様変更

従ってプロジェクトでは、必ず変更管理を実施して顧客企業やプロジェクトチーム内部からの変更要求や検討結果を記録し、変更に伴うコストを見積らねばなりません。コストの見積りは顧客企業からお金がもらえるかどうかに関わらず必要です。また、変更結果も記録していきます。PMは変更管理がきちんと行われているかチェックする必要があります。

開発契約書の内容を確認する

開発契約書の内容については特に下記のような点を把握しておく必要があります。営業部門や専門の部署が契約管理を行う場合がほとんどですがPMは遂行責任者ですので、問題等あれば契約内容の変更を要請しなければなりません。