本記事は
【PM/ディレクターウィーク】
5日目の記事です。
🍦
4日目
▶▶ 本記事 💻
はじめまして。安島です。
最近子供たちが折り紙にはまっており、上の子（5歳）はひとりで鶴が折れるようになりました。
何度挑戦しても折り方を覚えられない、そんな2児のパパSEです。
本日は、プロジェクトマネージャー（以下、PM）のお仕事についてご紹介したいと思います。
PMと聞くと、プロジェクトの管理に責任を持ち運営していくであったり、
お客様への進捗報告や要件の調整、場合によっては計画変更だったりといわゆるプロジェクトをマネジメントする業務を行っているイメージを持つ方が多いのではないでしょうか。
概ね、思い描いていただいたイメージはあっています。
ただし、当然ながらプロジェクトの規模や特性やNRIネットコム以外の企業によってもPMが行う業務や考え方は変わってくるため、このブログでは私がこれまで働いてきた中で経験したPMというお仕事や考え方をご紹介したいと思います。
はじめに
プロジェクトとは？
そもそもプロジェクトとはなんでしょうか。
一般的にはある目的を達成するために、期限を切って行動することを指します。
例えば、お客様が新規サービスを立ち上げるために集客用のスマホアプリを作りたいと我々に依頼をするとします。
その際に、お客様からの依頼に基づきサービスの開始時期などに合わせてスマホアプリを開発する
「○○サービス向けスマホアプリ構築プロジェクト」が立ち上がるわけです。
私がこれまで担当したプロジェクトの種類には、Webサイトをデザインリニューアルする、新しいサービス（Webシステム）を構築するといったお客様が目に触れるものから、業務システムを構築する、システムを支える基盤を再構築するといったお客様には見えない内部システムやインフラといった様々なものがあります。
期間も様々で１～2ヵ月と短い期間のものから1年以上対応するプロジェクトもあり、規模も数人月（MM）から数十、数百人月のものもあります。
プロジェクトマネージャーとは？
PMとは上述のプロジェクトをマネジメントする役割となります。
主な業務は以下の通りです。
プロジェクト立ち上げ・計画時
- プロジェクトの目的整理
- 要件の取りまとめ
- プロジェクトリスクの洗い出しと対策方針の検討
- 対応方針の策定
- 工程（要件定義～リリース）定義
- 概算費用見積もり（収支計画なども含む）
- 要員計画の策定、体制検討
- スケジュール立案
- 社内稟議 など
これらは主にプロジェクトを立ち上げる前に検討する項目となり、実際に案件化するまでのタスクになります。
このタスクはPMだけがやるわけではなく、上司や関係者、時には顧客とも連携しながら検討します。
次にプロジェクトが立ち上がり、活動が始まった後の役割は以下の通りです。
プロジェクト活動中
- 顧客および社内関係者との各種調整
- 各種レビュー、品質評価
- 各チーム（アプリ・基盤・デザインなど）の進捗確認
- 課題確認、課題解消
- 打ち合わせ準備（進捗報告・課題整理・仕様調整など）
- 計画見直し、是正対応
- 状況報告 など
PMは開発やテストをしたりするわけではなく、あくまでプロジェクトを円滑に進めるための活動を行います。
また、アプリケーションエンジニア出身だったり、インフラエンジニア、ディレクター、時にはデザイナーが担当することもあります。
さらに、一つのプロジェクトの全体を俯瞰してみる必要があるため、得意分野だけではなく幅広いスキルが求められます。
顧客側の業務も理解しておく必要があり、新規に構築するアプリがなぜ必要なのか、お客様の業務にどう関わっていくのか、
そこを理解したうえで仕様の調整や、お客様と対話していくことがプロジェクトの成功につながります。
実際のプロジェクト事例
私がPMとしてお仕事をするようになってから約5年ほどたちます。
これまで経験した実際のプロジェクトではどうなのか、事例を交えてPMの業務や楽しさや大変さをご紹介します。
事例：社内システムリニューアルプロジェクト
社内システムとは何かというと、利用者は企業の従業員で、会社からのお知らせや経営メッセージ、各部署で取り組んでいる活動を紹介するのがメインコンテンツのシステムとなります。
このプロジェクトは要件定義工程は別の方が担当し、それ以降の工程を私が担当しました。
難しかったポイントは下記の通りです。
－ 海外にあるシステムとの統合を見据えた顧客の現場担当者との調整 －
この会社は海外にも多くの拠点やグループ企業があり、社内システムも国内と海外用でそれぞれ存在していました。
そんな状況の中、お客様の経営層およびプロジェクト担当者はグローバル企業における国内外の一体感を課題に感じており、
まずは社内システムを統合することでグローバル企業としての一体感を実現していくということで本プロジェクトが始動しました。
一方で、国内の社内システムはこれまで自分たちが運用してきたシステムが安定して稼働しているということもあり、デザイン面や運用面を含めて大きな変更は望んでいないといった意見もありました。そのため、これらの意見をいかに収束させるかが本プロジェクトの成功のカギだなと感じました。
そんな中、PMとして工夫したこととしては次の通りです。
まずは対話を
まず行ったのは、打ち合わせの場になるべくプロジェクト担当者やその他の関係者全員に出てきてもらって会話するよう働きかけたことです。
打ち合わせ内容が伝言ゲームになりこちらの真意が伝わらないことも多々あったため、まずは対話することで担当者間で認識相違がなくなることを心がけました。
現場業務への配慮を
システムを統合もしくはリニューアルした後は絶対に運用が発生します。
プロジェクト担当者が運用すればいいのですが、現行システムを運用されている社員が行うことも多いです。
当然、今のやり方から大きく変わると負荷も高まりますし、なるべく現行業務から変えないような仕組みを提案しました。
そのためにも私自らがお客様の業務を理解し、運用の大変さを認識したうえでプロジェクト担当者とも調整を行いました。
みんなが納得できる形でのプロジェクト進行を
妥協点と聞くとあまりよくは聞こえないかもしれませんが、現場の業務ばかりに気を取られてあまり抜本的な改革をしないと、大きな変化が現れず、せっかく投資したのに無駄になってしまう可能性もあります。
一方で大きな変化は現行の業務にも影響をおよぼす可能性もあり現場社員への負荷増加のリスクも高まります。
そのため、ユーザが集まる仕組みや現行システムの課題を解決しつつ、なるべく現場への負担が増えることがないような仕組みを検討することでみんなが納得した形でプロジェクトを進行できるよう心がけました。
結果的には技術的なハードルや言語、現地担当者との調整難航という課題もあり、海外との統合はなくなり、国内の社内システムのリニューアルのみとなりましたが、もう少しPMとしてうまく調整ができれば、理想のゴールに向かって案件が進めたのかなと力不足を感じたプロジェクトだと思います。
プロジェクトを進めるうえでもステークホルダーは多岐にわたり、調整の仕方も人ごとに変えていく必要があるため、全員が同じ方向を向いてプロジェクトを進めるためにもPMの役割の重要性を痛感したプロジェクトでした。
ただ、プロジェクトの成果として、社内システムのリニューアルのみを行い社内システムへの訪問者はリニューアル前と比べて増やすことができ、お客様からもお褒めのお言葉をいただきました。
当初のプロジェクト目的からするとお客様の理想には届かなかったかもしれませんが、最終的に結果を残すことができたのはお客様と積極的にコミュニケーションをとることで、関係者全員の意見をとりながら全力でプロジェクトを推進できたからかもしれません。
さいごに
いかがだったでしょうか。
このブログを読んでみて、PMという業務が楽しそう・やりがいがありそう！と思った人や逆に難しそうと思った人がいるかと思います。
私がこれまでPMという立場で仕事をしてきてよかったなと感じたことは、お客様のビジネスやシステムの最前線に立てるということと、顧客の関係者や他の部署の人たちと広く関わりが持てるということです。
もちろんいいことばかりではなく、プロジェクトがうまく進まず大変な時や、お客さんとプロジェクトメンバーとの板挟みになり苦労する立場にあるのも事実です。
PMは、お客様のビジネスやシステムの変革を主導する役割だと考えています。
プロジェクトを運営していく役割。というだけではなく、お客様のビジネスやシステムを変えていく役割であると考えるとやりがいのある業務なので、みなさまもトライしてみてはいかがでしょうか。
