プロジェクトチームの職務定義書を作ろう

プロジェクトが進むにつれて、特定のメンバーに負荷が集中したり、
その結果としてアウトプットの品質が下って困った経験はありませんか？

それ、もしかして役割分担に無理があったかも？

プロジェクトの職務の定義、してますか？
職務定義をしないと何が起きる？なぜ細かく職務定義をするのか
＜職務定義の目的１＞仕事の穴を無くし、メンバーの負荷を平準化する
＜職務定義の目的２＞プロジェクトメンバーに能動的に動いてもらう

プロジェクトの職務の定義、してますか？

「プロジェクトの職務定義」とは、あまり聞き慣れない言葉だと思います。
まずはどんなものか見てみましょう。

https://drive.google.com/u/4/uc?id=1rb4yokpS-L9s3zIFOiux5iDPyo1y2EaH&export=download

※エクセル形式などでダウンロードして、ご自由にお使いください

早い話が、プロジェクトを通じて、チーム内の「誰が何をするか」が書かれているものになります。

なんだそんなことか、と思われるかもしれませんが、
このステップをしっかり踏むことで、プロジェクト進行中に発生するいくつかの不幸を防ぐことができるようになります。

次の章で見ていきましょう。

職務定義をしないと何が起きる？なぜ細かく職務定義をするのか

実は、「職務定義を全くしていません」というプロジェクトは、基本的にありません。
プロジェクトマネージャーの皆さんは、大なり小なり同様のことをされているはずです。

例えば以下のような具合です。
「Aさんは今回のプロジェクトではPLをお願いね。BさんはSEね。CさんはPGをお願い。」

小規模なプロジェクトなら、この粒度でも問題ないかもしれません。

しかし、プロジェクトの規模が大きくなって、タスクの数や作業量が大きくなってくると、
下記のようなまずいことが起き始めます。

プロジェクトの途中で要員不足が分かり、メンバーの負荷が増える
メンバー各自の作業範囲が明示されていないため、仕事の抜け漏れがが発生する
上記２つの理由から、プロジェクトに対する意欲と責任感が低下する

プロジェクトがある程度進行した状態で上記を是正するには、
ある程度の時間と、メンバー間の摩擦や紛争を覚悟する必要があります。

例えば、

・人が足りないから、新たにDさんに参画してもらおう
⇒Dさんの教育コストかかり、結果的にそれほど楽にならない。あるいはさらに負担が増える。

・この仕事が漏れていたから、Bさんお願いね
⇒「聞いてません。他のタスクがあるから受けられません。」と、断られる。

こんなことではプロジェクトの成功も怪しくなります。

そんなわけで、職務定義の目的とやり方をもう少し深掘りしていきましょう。

＜職務定義の目的１＞仕事の穴を無くし、メンバーの負荷を平準化する

ゴールを簡単に書くと、「大雑把に仕事を書き出して、役割分担を決めてしまう」ということです。

プロジェクトの開始前にこれをやっておけば、「この仕事の存在を忘れてたね」というエラーを防げるとともに、
効率の良い、無理のない要員配置が可能となります。

特に、「文書作成の要員」をきちんと確保しておくことが大切です。

これはどういうことでしょうか。

例えば、プロジェクトマネージャーが兼任することの多い、要件定義の業務について考えてみましょう。
ある機能の要件定義の作業を分解すると、主に以下の８ステップに分けられます。

順番	作業内容	作業の種類	かかる時間
１	対象の機能の仕様案を考える	思考	２時間
２	１で考えた内容を仕様書に書き出す	仕様書の作成	２時間
３	設計者と仕様書をレビューし、修正する	会議＋仕様書の作成	0.5時間＋0.5時間
４	クライアントと仕様書をレビューし、修正する	会議＋仕様書の作成	１時間＋１時間
５	４で修正した仕様書を再度設計者とレビューし、修正する	会議＋仕様書の作成	0.5時間＋0.5時間
６	再度クライアントと仕様書をレビューし、合意する	会議	１時間
７	合意した内容で仕様書を更新する	仕様書の作成	１時間
８	確定した仕様を、設計者・開発者に説明する	会議	0.5時間

	（作業時間の内訳）
	仕様を考える時間＋コミュニケーションの時間		5.5時間
	仕様書を書いている時間		5時間

作業内容やかかる時間はあくまで一例ですが、
「仕様を考えてそれを調整する時間」と「資料を作成する時間」は、大体１：１の比率にあることが分かります。

そう、文書の作成って時間がかかるんですよ。

プロジェクト全体で見ると、複数の機能の要件定義が並走するうえ、
仕様変更に伴って、影響する過去の仕様書も修正する必要が出てくるため、
プロジェクトが進むにつれて、仕様書の更新に必要な時間は雪だるま式に膨らみます。

これは「誰かとコミュニケーションを取り、何かを決めて、それをまた別の誰かに伝える」という種類の仕事で発生することが多く、
プロジェクトマネージャー、要件定義担当者、設計者などの役割が、特にそれに該当します。

ごく小規模なプロジェクトでもない限り、
「思考」と「コミュニケーション」と「文書作成」を１人のメンバーにアサインすることは避けると良いでしょう。

特に、設計者がプログラマーも兼任するようなアサインはもってのほかです。
（大抵の場合、設計書の更新が追い付かなくなる）

＜職務定義の目的２＞プロジェクトメンバーに能動的に動いてもらう

ここでやりたいことを、プロジェクトマネージャーとメンバーのやり取りで書くとこうなります。

プロジェクトマネージャー：この仕事、任せてええか？お前が適任やと思うねん。

メンバー：ええで。

プロジェクトマネージャー：ほな、ある程度好きにしてええから、責任持ってやってな。あと、困ったらいつでも相談してな。

メンバー：おっけー。

ここで押さえるべきポイントは下記になります。

仕事の内容と、そのメンバーに依頼する理由と期待値（目標）、求める品質などを説明する（動機づけ）
引き受けてもらえる場合、それに伴う責任を理解してもらう（必達事項の説明）
あくまでメンバー本人の意思を尊重し、無理に頼まない（合意形成）
困ったときの相談先があることと、やってみてダメなら途中棄権ができることを説明する（救済措置の説明）

こうすることで、双方に下記のメリットが生まれ、Win-Winの関係になります。

プロジェクトマネージャー側のメリット

プロジェクトマネージャーは、その仕事を細かく管理をするタスクから解放されます。

むしろ任せた以上、細かく管理をしてはいけません。そのメンバーに「任せた」のですから。
仕事の進捗が心配なら、報告のルールも合わせて相談しましょう。（仕事を依頼するタイミングで一緒に伝えることが重要）

メンバー側のメリット

仕事を任されたメンバーは、ある程度安全に、未経験の仕事に挑戦する機会を得られます。

だってほら、やってみてダメなら途中で降りても良いって、プロジェクトマネージャーが言ってるんですから。
「その仕事から降りる」という判断も、そのメンバーが持つ権限に含まれます。

全ての仕事の割振りが終わったら、
プロジェクトメンバー全員で集まって、メンバー全員の仕事の割り当てに無理がないかを確認し、合意します。

ね、難しくないでしょう？
単純に仕事を任せる相談をして、了解を取っているだけです。

ただし、プロジェクトマネージャーは下記の点に注意してください。

仕事を任せるときに相談した目標（ゴール）を一方的に動かしてはいけません。
それは不誠実です。やむを得ない理由がある場合は、しっかり相談すること。
「相談を受ける」や、「交代の場合の要員調整」という約束は守ってください。
リカバリの体制を予め関係者と相談しておくと良いです。
未経験の職務にチャレンジするメンバーがあれば、潰れないよう、常に観察を怠らないでください。
自分の口から「無理です」と言い出せないメンバーもいます。真面目な人は特に抱えやすいです。
人心掌握術を極端に利用した無理な動機づけや、二枚舌はNGです。誠意をもってメンバーと接してください。
全体に通じますが、これが一番大事です。不誠実な態度は、後でほころびを生みます。