プロジェクトマネージャ (7/11) | IT業界職種研究 | IT転職 エージェント リーベル


IT転職 リーベル ホーム > IT業界職種研究 > プロジェクトマネージャ

プロジェクトマネージャ | IT業界職種研究

プロジェクトマネージャ project manager

竹政 昭利 株式会社オージス総研

大手外資系企業にてプロジェクトマネージャとして活躍中。製造、金融、物流等、数多くの大規模システム開発プロジェクトの経験を持つ。

第2章:プロジェクトマネージャに必要なスキル

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

リーダーシップ

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

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

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

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

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

本音で突っ込んだ議論をする
イメージ

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

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

顧客と仲良くなる

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

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

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

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

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

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

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

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

イメージ

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

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

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

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

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

コスト構造を把握する

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

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

コスト項目 コスト内容 対応する収入
(顧客企業と一括形式で開発契約を結んだ場合)
社内メンバー人件費 プロジェクトに参加する社内メンバーのコスト 一般的には、一括のプロジェクト費用に含まれます。
※ただし、本番移行時の現地調整費用など最初に読めない費用は、別途費用として扱うのが一般的です。
社外委任メンバー人件費 Third PartyへのT&M契約メンバーのコスト(社外コンサルタント費用などもこれに含む)
資材費用、経費 開発用のPC、開発用サーバの費用
プロジェクトに直接関わる物品運搬費、交通費、宿泊費
プロジェクトチームが借用する家屋の賃貸料
社外一括発注費用 Third Partyへの一括発注
製品購入コスト HW、ネットワーク機器、SW製品を購入し顧客企業に提供するコスト。 一括のプロジェクト費用に含めることもありますが、別立てで売値を提示する場合が多く、作業コストがあまりかからないこともあって利益を見込むことができます。
変更管理を実施する

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

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

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

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

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

特に注意する契約事項 留意点
守秘義務についての記載事項 プロジェクトを通じて知りえる企業秘密、データなどの取り扱いについて確認し、プロジェクトチーム内にも徹底しなければなりません。
納入物の定義 納入すべき成果物を確認し、プロジェクトチーム内に徹底していきます。
知的財産権の帰属についての記載事項 プロジェクトで使用される既存の著作物、特許物の取り扱いについて、あるいはプロジェクトの成果物の著作権についての取り決めを確認する必要があります。
納期遅延時の条件 遅延発生時の損害についての取り決めがある場合には、プロジェクト遂行中に途中の遅延の原因を記録して行く必要があります。勿論、遅延しそうな場合に顧客企業側と話し合いを持つことは必須です。
損害賠償事項 納入成果物の障害などによる損害の可能性について予想し、賠償限度額などを確認します。
例えば、人命に直接関わる障害の可能性がある場合には、免責事項等を取り決める必要があります。場合によってはプロジェクトを受注遂行できないこともありえます。
支払い条件 期間の長いプロジェクトでは、途中の分割支払いが無いと受注企業側は資金繰りできなくなります。

プロジェクトマネージャへの転職をお考えの方へ

IT業界出身のコンサルタントが、
あなたの転職活動をフルサポートいたします。

転職支援サービス
に申し込む無料

このページのトップへ