プロジェクトマネージャーとして気をつけていること①準備,契約,見積もり編

概要

現役のプロジェクトマネージャーが業務で気をつけていることを示します。

筆者の経験に基づく偏見ですが、参考にしてもらえたりご意見いただけると嬉しいです。

筆者について

業界経験10年のフリーランスのWebアプリケーションエンジニアです。
案件によってはプロジェクトマネージャーロールとして働いています。

プロジェクトマネージャーとして参画した案件は5件以上10件未満です。

想定読者

• 駆け出しプロジェクトマネージャー
• プロジェクトマネージャーを志している方
• プロジェクトマネージャーの周辺ロールの方

プロジェクトマネジメントを一切知らない方や熟練の方は対象外です。🙅‍♂️

プロジェクトマネージャーとは

プロジェクトマネージャーが行う業務は会社やプロジェクトによって異なりますが、この記事では以下のように定義します。

• システム開発プロジェクトにおける責任者である
• 予算, スケジュール, 人員, タスク, ドキュメント, 品質などを調達・管理し、それらに対して責任を持つ

これをプロジェクトマネジメントと呼びます。

抽象化すると、意思決定して責任を取ることが仕事です。

関わる関係者が多く、異なる立場のステークホルダーと交渉することも多いので、交渉力やコミュニケーション能力が求められます。

プロジェクトマネジメントの目標

この記事では以下のように定義します。

• あらかじめ合意した予算内で納期を守り、人員に過度な負担をかけず、求められた品質や仕様を満たしたシステムをリリースする。それを継続的に行える環境を維持する。

これは目標なので、実際はプロジェクトを進める中で柔軟に対応します。
これに近い状態であるほど優れたマネジメントであると言えます。

プロジェクトマネジメントにおいて重要な要素

1. 予算
2. 納期
3. 人員

この3要素を不足なく確保することがプロジェクトを円滑に運営するために最も重要です。
これらのいずれかが欠けているとスケジュールや品質などの基準を満たすことが困難となります。

次いで、下記の3つの視点も持ち合わせていると付加価値となり他者との差別化を図れます。

4. 事業KGI
5. 会社の方向性
6. メンバーのキャリアパス

事業KGI

事業によって何を成果とするかは異なりますが、成果（売上, 成約数など）の数値目標が定められているはずです。
プロジェクトマネージャーとして、システム開発を成功させるのは大切ですが、そのシステムが担う事業活動を成功させることも考えれると、クライアントからの信頼が揺るぎないものになります。

会社の方向性

自社のプロジェクトなのか、クライアント企業のプロジェクトなのかにもよりますが、自分の所属する会社が今後どうしていきたいか？という点も踏まえて意思決定できると、プロジェクトのみならず会社にとって利益を生む人物であると印象づけることができます。

会社にとってそのプロジェクトは伸ばしていきたいのか？頃合いを見て撤退したいのか？他の事業へ経験や資産として残せるものがあるか？など様々な判断材料があり、それらが技術選定や人員の配置などの個別の意思決定の質を高める。より大局的な視点で判断できるようになります。

メンバーのキャリアパス

マネージャーとしてメンバーに指示を出す以上、少なからずメンバーの将来に影響を及ぼしています。
メンバーそれぞれに個別の人生があり、実現したい目標があるはずなので、可能な限りそれに近づく意思決定ができると理想的です。
マネジメントに興味があるメンバーにはまずはプレイングマネージャーをお願いしたり、関心のある技術を担当してもらうなど、場合によりますが、大きなコストを払わなくてもできることはたくさんあります。

メンバーのモチベーションが高い方が生産性が高まり、離職率も下がると期待しています。（効果を測定しづらいので数値で示せないですが）

コミュニケーション

常にポジティブで明るく話しかけやすいキャラクターでいる

忙しい雰囲気は出さず、相手問わず褒める癖をつけておくと情報が集まってきてプロジェクトが円滑に進みます。

大人は『あえて口にするまでもないこと』を口にしない人が多いので、思ったことを感情表現するだけでも差別化になります。
アウトプットやプロセスを褒めたり、ポジティブな出来事に『やったー！！！！🙌』とリアクションしたり、クライアントやメンバーに『事業を伸ばしたい！！🔥』『爆速で良いもの作るぞ！！💪』といった言葉を口にして鼓舞するなど、滑稽でもいいのでそういったことをしているとチームの雰囲気がいい状態が保てます。

大きな問題が起こったとしても、怒ったり悲しんだりせずに淡々と過ごしましょう。

エンジニアやデザイナーのようなクリエイティブ系の仕事はメンタルヘルスが仕事のパフォーマンスに大きく影響を及ぼすので、特に注意しています。

忖度しない

お互いで妥協点を探すようなときに、『きっと相手は受け入れづらいだろう』という要求を相手に伝えずに忖度してしまうことは避けたいです。
こういったシーンでは、お互いの要求をすべて出し切って、そこからどちらがどこを譲歩するか折り合いをつけていくという方法で進めるべきです。
勝手に忖度してしまうと、自分にとっては譲歩したつもりでも、相手にとっては譲ってもらった感覚はありません。
交渉ごとは常にギブアンドテイクのバランスが大切なので、譲歩するところは明確に譲歩である旨を伝えて、他のところで譲ってもらえるように布石を打っておきましょう。

要求することも譲歩することも明確に伝えて、相手の要求も譲歩も明確に引き出すことができればスムーズです。

Why, Why notを伝える

メンバーに対して指示や結果を伝えるだけではなく、何故そうなったかという背景を併せて伝えると、メンバーが指示された以上に考えて提案してくれたり、指示に対して納得感があり不満を抱きづらくなります。
なぜ他の選択肢ではないのかも同じ理由で併せて伝えたいです。

クライアントに対しても同様で、業務の進め方や決めた仕様などの根拠を伝えます。

プロジェクトマネージャーは答えのない問いに答えなければいけないことが多いです。そんなときに価値があるのは答えそのものではなく、どのような論理で答えを導き出したかという根拠です。

メンバーがやりたいことをやってもらう

可能な限りメンバーがやりたいことをやってもらうようにしてモチベーションをコントロールしています。
逆に、『やりたくないことをやらせない』ようにしようとすると、それが叶わないときに本人がストレスに感じたり、叶えるために組織として折り合いをつけるのが難しいことが何度かあったのでこちらは積極的にはコントロールしないようにしています。悪手だと考えています。

エビデンスを取る

• ミーティングは録画し、共有フォルダに格納する
• 可能な限り通話や口頭ではなくチャットで議論する
• チャットで決まったことは先週か翌週のミーティングの議事録に記載し、議事録は共有フォルダに格納する
• チャットや議事録で用いる文言は後から検索しやすい表現を使う

特に仕様に関しては後から検索可能な形式で残っていないと認識齟齬が発生してしまいトラブルの原因になるので注意が必要です。

契約

プロジェクトが炎上するのは、プロジェクトが始まる前の契約時に決まることが多いです。
契約締結時点で予算, 納期, 人員を確保できていないと負け戦が確定していますし、要件を固めれていないと後出しで要件が膨らみ、納期を過ぎたり人手が足りなくなることがあります。

契約時に確実に予算, 納期, 人員を確保できることを確約させて、要件も可能な限り詳細度高く合意しておくと安全です。

契約書の内容は一文字漏らさず確認して、リスクがある箇所は削除・修正を提案することが必須です。
一般的に契約書を用意した側に有利に書かれていることが多いので、可能であれば取引先が用意した契約書ではなく自社が用意した契約書で契約することが望ましいです。

自社のプロジェクトの場合は契約しないですが、プロジェクト発足時に様々な事柄について合意形成するはずなので他社相手に契約する場合と同じです。

見積もり

見積もり時点で以下のような情報が必要です。

• 使うSaaSなど外部サービス
• インフラ構成
• 対応端末（スマートフォン対応、タブレット非対応、パソコン対応など）
• 対応OS・ブラウザ
• システム内のページ数
• データベースのテーブル数
• APIの数

決まっていないことも多いので、決める必要があります。
言い換えると、見積もりはほぼ設計なのでそれなりに時間がかかります。

受注未確定の案件に工数を多く取られてしまうリスクがあるので、予算規模に応じて見積もりにかけていい時間を事前に決めて、その時間に収まるように見積もりをします。

実際に着手すると想定が甘かったり想定が変更となったりするので、着手前に100%確定させるのは無理ですが、詳細な見積もりを作成すると仕様変更の際に他の仕様を削って、仕様を追加するなどの話がしやすいです。
詳細度の低い見積もりで合意してしまうと、後から仕様が追加される場合に追加なのかどうかも判断しづらく、想定よりも機能が増えてしまう恐れがあります。

不確実性の高い箇所に関しては特に具体的に想定している状況を明記して、それと実態が逸脱する場合は都度追加で見積もるなどの対応となります。

新規にシステムを開発する場合は見積もりは簡単ですが、既存システムに手を加える場合は不確実性が格段に上がるので、見積もり不可能なケースもあります。
その場合、見積もりのために準委任契約（時給）で稼働するか、あるいはシステム開発自体を準委任契約（時給）で契約するといった選択肢があります。

おわりに

プロジェクトマネージャーのすべてを書こうとすると、とても長くなってしまうのでこの記事は導入編という位置づけで準備から契約, 見積もりまでで気をつけていることを書きました。

もしニーズがあれば、要件定義, タスク管理, スケジュール管理などそれ以降のフェーズに関しても続編として書こうかと考えています。
（腰が重いですが、Likeやコメントを多数いただければがんばって早めに書きます。）

最後までお読みいただきありがとうございました🥳

おまけ

エンジニアリングやマネジメント、マネージャー教育などのお仕事のご相談があればX(旧Twitter)にてご連絡ください。
この記事を見た旨メッセージに記載いただければ返信漏れしづらいです。🙏
お断りすることが多いですが、状況次第でお受けできたり、合いそうな知り合いを紹介できるかもしれません。