プロジェクトの役割をメンバーに伝えるためには？運用している方法を公開してみた

データアナリティクス事業本部＠札幌の佐藤です。

今回は私のプロジェクトで実際に活用している、プロジェクト体制・役割をどうプロジェクトメンバーに伝えるといいのかについて記載したいと思います。
当活用にあたっては株式会社コパイロツトの方に相談させていただいたうえで、ルールとして運用しているものとなります。
ご協力いただきありがとうございます。

お話の前提

私の案件は小規模（メンバー10人未満）のプロジェクトが多いため、小規模案件での前提として記載します。
大規模案件の場合は必ずしも該当しない観点がある可能性がありますので、あらかじめご認識いただければと思います。

プロジェクト体制は何のために存在しているのか

そもそもプロジェクト体制とはなぜ必要なのでしょうか。

プロジェクトはWikipediaに下記のように記載されています。

プロジェクト（英: project）は、何らかの目標を達成するための計画を指す。基本的に集団で大がかりに実行するものを指す。

プロジェクトマネジメント協会が制定しているPMBOK（第5版）の定義では、「プロジェクトとは、独自のプロダクト、サービス、所産を創造するために実施する有期性のある業務」とされている。
プロジェクト

また、体制を組織という観点で見た場合、Wikipediaに下記のように記載されています。

社会科学における組織（そしき、（英: organization）は、共通の目標を有し、目標達成のために協働を行う、何らかの手段で統制された複数の人々の行為やコミュニケーションによって構成されるシステムのことである。
組織 (社会科学)

定義された期間中（有期性）で指定された精度のサービス・製品を提供（所産）するのをプロジェクトと呼び、その目標を達成するために力を合わせて活動するということが組織になります。

プロジェクトメンバーが複数人いる場合は、協力して目標を達成していく。
それを資料などで明示的（あるいは非明示的に）に定義させたものをプロジェクト体制と呼ぶのだと思います。

プロジェクト体制は何が表現されるべきなのか（クライアント向け）

プロジェクト体制をどのような形で定義すべきなのかを考えた際に、思い浮かべるのはプロジェクト体制図（組織図）になると思います。 プロジェクト体制図には、一般的にこの3つが最低限記載されているのではないかと思います。
私も新規プロジェクトを進めていくにあたりクライアントにはまずこの観点で提示を行います。

• プロジェクトアサイン者
• プロジェクトにはアサインされないが関係者
• 各メンバーのロール（役割）

つまり、自分の会社のステークホルダーとして、このプロジェクトの影響範囲にいる関係者（利害関係者）を提示しているということになります。

上記観点に記載している通りに体制図を記載しますが、それに加えて関係性も明確になるようにツリー状に記載を行います。
PMとエンジニアが傘連判のようにフラットになっているのは、誰が上の人間が分からないのでぱっと見で分かりにくいです。

これでクライアントに誰が自社のステークホルダーなのかを情報提供できる状態となりました。

ここでひとつ考えたほうがいいのは、プロジェクト影響範囲は対クライアント向きだけでいいのかという点です。
（ここから主題になります）

ステークホルダープロジェクト内にも存在している

今まではクライアントに対してという視線でプロジェクト体制を考えました。
ただ、ステークホルダーはプロジェクト内の人間も当然該当します。

人数が多くなればメンバーの中でリーダや、領域などで分割していくことになります。
それをプロジェクト内のメンバーにも共有しなければいけません。

以下は、プロジェクトの利害関係者の例である。

• プロジェクトリーダー
• 上級管理職
• プロジェクトチームメンバー
• プロジェクトの顧客
• リソースマネージャー
• ラインマネージャー
• 製品ユーザーグループ
• プロジェクトテスター
• プロジェクトの進行中にプロジェクトの影響を受けるグループ
• プロジェクトの完了時にプロジェクトの影響を受けるグループ
• プロジェクトの下請け業者
• プロジェクトのコンサルタント
  ステークホルダー (プロジェクト管理)

単純に伝えようと思えばクライアントに提示したプロジェクト体制図で問題ありません。
しかし、本当に同じ体制図を見せることで100％理解できたといえるのでしょうか。

内部のメンバーはプロジェクト期間中、その体制図を見て、作業で体制感を感じながら作業を行っています。
私はクライアントに提示した体制図のレベルとは少し違う切り口で語るべきだと考えています。

プロジェクト体制は何が表現されるべきなのか（プロジェクトメンバー向け）

プロジェクト体制は何が表現されるべきなのかと考えたときに、自分がプロジェクトに何を求められているのかある程度明確になっているものを提示すべきです。

体制図・責任分担表でPM（プロジェクト）がメンバーに要求する役割を、ロールセッションがPM以外のメンバーがメンバーに求める役割を定義することになります。

ロールセッションは最悪なくてもよいですが、より平等なプロジェクト推進を目指したいということであれば実施したほうがよいかと考えます。

ロールセッションについては別途、ブログにまとめておりますのでそちらをご参照ください。

プロジェクト体制はいつ作るべきか

開発と保守運用でそれぞれタイミングは異なるかと思いますが、もしプロジェクト体制について明確化していないという場合は、それに気づいた瞬間である点はともに変わりません。

また、一度決めた体制（役割）を変更してはいけないというルールは原則ありません（クライアント説明がいる場合除く）。
そのため、うまくいかなければまた建て直せばよいのです。

開発フェイズ

プロジェクトの立ち上がり時に第1版として提示を行い、プロジェクト中の状況の変化に対して都度変えていくという形になると思います。

• 内部キックオフ時
• アサイン人数増減時
• プロジェクト内での定期的な振り返り
• プロジェクトスコープの変更

保守運用フェイズ

開発フェイズでは、契約の切り替えなどある一定のタイミングで作り直すことになる場合が多いです。
開発とは違いある程度落ち着いている状態になっていますので、定期的な振り返りをしない限りは役割の違和感をキャッチできないため、適切なヒアリングは必要になると思います。

• ある一定のタイミング
• アサイン人数増減時
• プロジェクト内での定期的な振り返り

体制図で表現すべきこと

プロジェクト内に向けて体制図を書くにあたってのベースは、クライアント向けの体制図です。
そもそもクライアントに提示している体制と、内部の体制が乖離していることは少ないと思います。
そのため、私は既存の体制図に下記観点を追加して、内部キックオフ時に提示しています。

• 各ロールがどの様な作業を行うのか作業概要を記載
• レビューを誰が行うのかを明確化
• アドバイザリーなどの特殊な立ち位置の人間を明確化

例：

各ロールがどの様な作業を行うのか作業概要を記載

自分がどこまでの責任範囲を負っているのかを明確にしています。
単純にロールを書くと、インフラはAWSを構築するのように当たり前のことしか書けません。
その情報に加えて、自分がビジネススキル上何を求められているのかを明確にしています。

レビューを誰が行うのかを明確化

上記の中で一番重要なのに定義されない観点としてはレビュー体制になります。
品質にかかわる重要な観点ではありますが、意外に定義されていることが少ない印象です。
「（誰かが）レビューする」となっており、いざレビューをする際にまず内部でそこを決定する、という経験も少なくありません。

私の案件は最初に書いてある通り、人数も少ないことから調達時点でその観点を入れているため、意識して書くようにしています。

アドバイザリーなどの特殊な立ち位置の人間を明確化

これは半分周知の要素が含んでいる記載です。
様々な要因で特殊な立ち位置のメンバーが入る場合があり、該当アサイン者に何をしてほしいのかを提示しています。

責任分担表で表現すべきこと

責任分担表はプロジェクト体制図をブレイクダウンするというイメージで書いています。
基本的にはWikipediaに書いてある観点に準じて作成していくことになります。

責任分担表（英: Responsibility assignment matrix、RAM）とは、リソースと活動を結びつけ、ある目的の達成に必要な仕事が全て個人やチームに割り当てられていることを保証するもの。責任分担マトリクス、役割分担表とも。
1つの形態としてRACI図に基づく形式がある。この場合に割り当てられる役割は、Responsible（実行責任者）、Accountable（説明責任者）、Consulted（協業先）、Informed（報告先）である。表の縦に活動（仕事）を並べ、横に資源（個人やチーム）を並べる。
責任分担表

ただ、私の担当案件ではConsulted（協業先）が出てこないため省いている点、上記の通りレビュー者を明確にする目的でVerifies（検証者）を明示しています。

例

※R：作業者、A：最終承認者、I：報告先、S：フォロー、V：レビュー者

責任分担表を作成する際に意識すること

基本的にはプロジェクト体制を想像しながら埋めていくことで対応可能かと思います。
ただ１点、各作業の最終承認者はクライアントという点は忘れずに記載をしたほうがよいでしょう。
クライアントがOKしなければそのフェーズ・作業は、完了とみなすことはできないはずです。

体制の違和感に迅速に気づくには

プロジェクト体制をメンバーで合意して、いざスタートしてうまくいかないケースもあります。
うまくいっていないというのは、作業平準化や、プロジェクト中の会話で表面化する場合が多いと考えます。

例えば

• ある特定の人ばかり発言している場合
• 作業進捗が悪い場合
• レビューなど事前の割振りが筋書き通りにいかない場合
• 与えられた工数と作業内容・量に乖離が見られる場合

その場合は状況をヒアリングし、調整できる範囲・メンバーが違和感がないよう変更を進めていく必要があります。
急に作業を変更すると逆に進捗が悪くなるケースも考えられるのは、素直にメンバーに聞きながら微調整をするのがよいと思います。

振り返るべきタイミング

体制が現実に対して適切なのかという判断において、振り返りを行うのは効果的です。
振り返りにて自分の役割を再度確認をし、違和感があるものは改めて討議をすることでブラッシュアップしていくことになります。
振り返りのタイミングは細かければ細かいほど良いとは思いますが、月1度自分の役割を数分でもよいから見る時間を設けることが重要だと考えます。

最後に

エンジニアとしては何も考えていない要素でありましたが、実際にPMとして向き合ったときに重要性というのを改めて理解したように思えます。
まだまだ考えるべき点もあるかと思いますが、現状はこのやり方でうまくいっているように思えます。
もしこの記事が報告や相談のよりよいやり方としてお役に立てれば幸いです。