プロダクトマネジメントを最近は生業としていますが、プロジェクトマネジメントについても必要となることが多くあります。
最近、周囲でもプロジェクトマネジメントが必要な機会を見聞きすることがあり、需要はあるのではないかと思い、私が学んできた知識や経験を書き記してみます。
- 仕事の終わらせ方は2つしかない
- プロダクトマネジメントとの違い
- プロジェクトマネジメントの３種の神器
- プロジェクトマネージャーの仕事は不確実性を潰していくこと
- チームマネジメントについて
- 「運用でカバー」は最終手段
- まとめ
仕事の終わらせ方は2つしかない
新人研修で、仕事の終わらせ方は2つしかないという話を教えてもらいました。その2つは「成果で終わらせるか」、「期限で終わらせるか」です。 （こちらの企業の研修だったと思います http://www.onevision.jp）
言い換えると、あらかじめ定めた成果物が完成した時、あるいはあらかじめ定めた期限がきて時間切れになってしまう時に仕事の終わりが来るということです。 夏休みの宿題で例えると、プロジェクトの終わりは宿題が完了した時か8月31日を迎えた時です。当然、宿題が完了せずに8月31日を迎えてプロジェクトが終わることもありえますが、やはり成果物を完成させて仕事を終わらせることが理想です。
また、実際の仕事では成果物が定義されていないことがほとんどです。成果物が定義されていないとどこに向かっていいかわからず、プロジェクトメンバーは右往左往することになります。故にプロジェクトマネージャーの最初の仕事は「成果物を定義すること」になります。
また、期限から時間内に適切な成果物を定義することも重要です。期限内に到底終わらない成果物を定義してしまってもいけませんし、逆に期限と比べて成果物が少なければ、期限を短くすることか成果物の質を上げることを検討すべきです。
この時間と成果のバランスがうまく取れた成果物を定義することが重要なプロジェクトマネージャーの仕事になります。普段の仕事でも、何をしていいかわからない、となったら成果物を定義することを心がけると進捗が生まれやすくなります。
プロダクトマネジメントとの違い
プロジェクトマネジメントとプロダクトマネジメントの違いについて何か、ということはよくある質問なのですが、プロジェクトマネジメントは成果物を定義してそれを期限通りに完了させることが目的で、明確な終わりのある仕事です。一方でプロダクトマネジメントは、プロダクトビジョン達成のためにあらゆる手段を尽くす仕事で、明確な終わりがない仕事です。
完全に被る部分がない仕事というわけではなく、プロダクトマネジメントの方が少し概念が広く、プロジェクトマネジメントを内包しているとも言えるでしょう。
プロジェクトマネジメントの３種の神器
具体的にプロジェクトマネジメントを行うときに用意するものを紹介します。さまざまツールはあるのですが、私は「全体スケジュール」、「WBS」、「課題管理表」を３種の神器と呼んでおり、これが基本としてあれば多くの場合は対応できます。
全体スケジュールは月次レベルでの進捗目標、マイルストンを現した大まかな全体スケジュールです。これがあることで目標から遅れているのか進んでいるのか、全体像レベルで確認できます。
WBSはワーク・ブレイクダウン・ストラクチャーの略称で、スケジュールから具体的なタスクに分解していったものです。例えば「新しい販売管理システムを開発する」というプロジェクトであれば、「業務フロー整理」、「要件定義」、「設計」、「開発」、「テスト」という大きなタスクに分けられます。「業務フロー整理」だけでは大雑把すぎるので、「現行の業務フロー整理」、「あるべきの業務フロー定義」とわけ、さらに「現行の業務フロー整理」でも販売管理のどのプロセス（売上実績管理なのか、販売計画管理なのか）などによって細分化できます。そうして「具体的に何をすべきか」が明確になるまで分解していくことでメンバー着手可能な粒度になり、かつ工数の見積もりもしやすくなります。
「課題管理表」は、プロジェクト推進において決めなければいけないことや問題として出てきたことを整理するために使います。クライアントが存在するプロジェクトであれば、この表を共有してクライアントと一緒に意思決定をして解決していきます。
経験的に、プロジェクトを走らせるときはこの3つがあれば基本的なことはカバーできることが多いと考えています。（なお、全体スケジュールは不要な場合は省略したり、アジャイル開発においてはWBSは厳密に作りすぎない等、実際の現場に合わせて少しずつ変えることもあります）
プロジェクトマネージャーの仕事は不確実性を潰していくこと
プロジェクトマネージャーの仕事によくある誤解は「工程管理を行う人」という誤解です。あくまでプロジェクトマネージャーのミッションは期日通りに期待される成果を出すことです。不確実性はQCD(Quality-品質, Cost-コスト, Delivery-納期)の種類があります。
Qualityの不確実性については出来上がる品質に懸念があること。技術的に実現が難しい仕様で進めてしまうことや、ニーズが不確かなまま進めて結果的に不要なものを作ってしまうことなどが原因の例としてあげられます。プロジェクトマネージャーとしては、問題が顕在化するために品質を上げるための施策を打つ対策が求められます。
Costの不確実性は、費用が想定より多くかかりプロジェクトの許容範囲を超えてしまうことです。プロジェクトの成果物定義が広いことや、必要以上に人員を雇ってしまうことなどが原因の例としてあげられます。プロジェクトマネージャーとしては、コストと期限のバランスがみあっているか、適宜トラックしていくことが必要でしょう。
Deliveryについては、納期が予想以上にかかってしまうことです。こちらについては見積もりの甘さが結果として出てくるケースや、後続タスクを進めるためのブロッカー（クリティカルパス）となる事象の存在が原因の例としてあげられます。プロジェクトマネージャーとしては、見積もりが難しいタスクを先行調査することやクリティカルパスを早期に発見して解消することが求められます。
このような不確実性を潰していくことがプロジェクトマネージャーの仕事です。不確実性の高いタスクから着手していくのが良いでしょう。不確実性については「エンジニアリング組織論への招待」でも触れられています。
チームマネジメントについて
プロジェクトというからにはチーム組成があります。チームメンバーにどのタスクを依頼するかは個々のメンバーの特性を見て依頼するべきです。バックエンドが得意なエンジニアにフロントエンドの仕事を依頼するのはチームパフォーマンス最大化という観点で機会損失が大きくあります。
進捗管理の仕方について、「なれる！SE」というシステムエンジニアを題材にしたライトノベルがあるのですが、4巻でプロジェクトマネジメントが題材として取り上げられてました。（軽度なネタバレがあるので嫌な方はこの項目だけ飛ばしてください）本書では人の種類を
- 大きく役職を任せられ、細かい管理を好まないタイプ
- 具体的な手順まで細かく知らされたく、細かく管理されたいタイプ
- 自身の専門領域に特化したことをやりたく、専門外のことは極端に嫌がるスペシャリスト
として大別して管理する方法論が挙げられます。究極、個々人のスキルや性格に向き合うことが重要なのは間違いないのですが、一つのフレームワークとして意識するとタスクの割り振りを考えやすいかと思います。色々なプロジェクトマネジメントの本も読んだのですが、ストーリー形式でわかりやすいので４巻だけでもおすすめです。
「運用でカバー」は最終手段
ソフトウェア開発において、間に合わない場合や難しい場合「運用でカバー」という手段を提案することがあります。ソフトウェアで吸収しきれないことを業務上の運用で対応してもらうことですが、基本的に最終手段だと考えています。
なぜなら、「手動運用」という新たな不確実性を内包するからです。経験上、少数精鋭のチームか、非常にオペレーションが統一化された組織でしか決められた運用通りの業務はできません。
どうしてもQCDの観点で達成できない場合に「運用でカバー」を提案することはありますが、非常に狭い範囲で行うべきです。特に、大企業など多くの人数が関わる組織では「運用でカバー」を浸透させることが難しいケースがあります。
まとめ
プロジェクトマネジメントの仕事では成果物と期限のバランスをコントロールし、プロジェクト推進のために不確実性を潰していくことが求められます。プロジェクトマネジメントの考え方はとても重要で普段の仕事の進め方にも役立ちます。また、必要以上に難解で高いスキルが求められる仕事と思われがちですが、実際のところ考え方はシンプルで標準化しやすい領域であるとも思います。
プロジェクトマネジメント業務をコンサル会社など外部に発注する会社もままあるのですが、内製化が求められる時代だからこそ、社内で知見をためて骨太なプロジェクトマネージャーを育てるということが大事になると考えています。
