プロジェクトマネージャーはどこまで専門技術を理解しておくべきか？（設計編）

こんにちは。今回は、専門職を集めたチームをまとめるプロジェクトマネージャーは、どこまで専門知識や技術の理解が必要かについて。

専門知識や技術を理解してるとより管理がしやすいのは絶対です。別業界の複数案件を抱えたりして専門知識をつけれない場合に、どの程度知っておけばいいの？という疑問に、現時点での私の答えをお話しします。

PMの前提条件

話を始める前に、前提として、２つの定義をおさらいしていきます。

ひとつめは「プロジェクト」の定義。
PMBOKでは「独自のプロダクト、サービス、所産を創造するために実施される有期的な業務である。」と言われいるけれど、理解がムズカシイ.…

ざっくりいうと「プロジェクトは２つの要素があれば成り立つ」ってこと。
1. 独自性がある ＝ 何か新しいもの or プロセスを作る
2. 有期である ＝ はじまりとおわりがある

そして、この２つを管理するのが、プロジェクトマネージャー（以降、PMと言います）なんですね。

ふたつめは「プロジェクトマネージャー」の定義。

一般的には、「プロジェクト全体に対する責任を持ち、総合的に管理を行う」と言われますが、これもどこか雲を掴むような…。何かを言ってるようで、何も言ってないような気がしてました。

そこで私が辿り着いたのが、PMは「誰かの想像した世界を、形にするプロセスを作り、完成まで導く人」なのでは？ということ。

つまり、誰かの想像した世界（＝独自性）を、形にするプロセスを作り、完成まで（期限内）まで導く人と定義ができるなって思ってます。

この前提を理解した上で、PMがどこまで専門技術や知識が必要かについて。前編としてプロジェクトを立てつけるときの話です。

独自性を担保する

まず、PMがやらないといけないのは、プロジェクトたらしめてる「誰かの想像した世界（＝独自性）」をブラさないこと。

立ち上げる時に「なぜ作るのか？」「 何を作るのか？」を、チーム全体で同じものを思い描けるまでに、言語化に努めます。
同じビジュアルを想像できるように、参考ビジュアルを作ったり、コラージュしてイメージを固めてもいいかもしれないです。

一般的にプロジェクト目的と言われるものなので馴染みがあると思います。

理想としては、これらの質問にチーム全員が同じ答えになること。
・解決したい課題は何か？
・なぜこの課題を解決したいのか？
・どんな状態にしたいのか？

これから作り上げていく世界なので、すべてが言語化されてる必要はなくて、「作り上げたい背景」を明確にするのが大切。

いろんなビジネス本でも絶対に書いてある、ほんと大前提の考えですが、
ぶっちゃけ、これは専門技術も知識は必要ないです。

プロセスを担保する

次にプロジェクトたらしめてる「形にするプロセスを作り」を設計していくところ。２つに分けて説明していきます。

おおまかな工程

PMが把握しておかないといけないのは、大まかな工程です。
スケジュール作成に使うので、あたりまえっちゃあたりまえ（笑）。

ここでやりがちなのは、専門職の作業レベルで把握しようと試みること。

例えば、実装フェーズの中で、機能設計・詳細設計・スタブ開発、、、、みたいなやつ。
呪文のようでちんぷんかんぷん。だけどPMは全体工程を把握せねば！と全てを理解しようとするのは違います。そこ重要じゃないです。

細かいプロセスやタスクの洗い出しは専門職におまかせ。
粒度は、「主担当が変わる」「使用ツールが変わる」レベル感でOKです。

やっていることは把握して理解できるのに越したことはありませんが、無理は禁物です。

インプットとアウトプット

これは技術や知識をしっかりつけておくと、抜きにでる部分。

・インプットは、作業に使う情報
・アウトプットは、作業後に出てくる情報（＝成果物）

上の図のように、前工程のアウトプットが次工程のインプットになります。

この情報の管理をしていくのがPMの仕事。作業開始日までに、アウトプットされたものを、インプット情報として、担当者に届けます。

やりがちな情報管理としては、画面項目書・サンプルデータ・テスト設計書・スケッチのように、ファイル名や単語レベルのざっくり内容で把握してること。

これだと、設計担当者の作業は終わったけれど、実装者が作業できる情報が揃っていないため遅延する、、、なんてことになりかねません。

なんとなーくはわかるレベルなら、作業担当者から、具体的な粒度や内容を細かくヒアリングします。プロセス管理はこのインプット/アウトプット粒度の精度が肝。

たとえば、この程度までブレイクダウンしていきます。
・設計書：定義項目や内容
　例：項目名、文字数指定、アクション指定、表示形式、可変/固定、条件分岐
・デザイン：粒度や目的
　特にラフやスケッチは人によってイメージが千差万別。
　デザイン粒度は他社参考を共有、何を合意したくて作るかを明確に。

最初は全部聞いていたとしても、このステップを踏めば、どんどん知識がついていきます。

ヒアリング
↓
実際のアウトプットの中身を確認
↓
言葉と内容を合致させる
↓
次に活かす

もちろん、作業開始前にすべてのインプット情報が揃わないことはザラにあります。その対応策は、別記事でお伝えしますね。

ということで

PMはプロジェクトを俯瞰して、最初から最後まで情報を流していくので、思ったよりも専門技術や知識が必要な箇所は少なかったのでは？と思います。

最後に、、、
周りをみていてもったいなーと思うのが「PMだからとすべてひとりで考える・管理する」と思っている人。全然抱え込む必要はないです！

私は、ひとりで完結させずに、設計段階から専門職の意見を聞くようにしています。だって、プロジェクト実行者に合わない計画を立てても、ハプニングやトラブルのもと。最初からみんなで進め方を合意していくようにしてます。

いかがでしたでしょうか？

今度、プロジェクト進行編を書きたいと思います。実はこちらのほうが技術を知っておくと便利なことが多いです。

参考になればと。それでは、また。