プロジェクトアサイン者との期待値を揃えてみよう！ロールセッションについて徹底解説してみた

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

今回は私のプロジェクトで実際に活用している、各メンバーとの役割や期待値のすり合わせ方法について記載します。
当活用にあたっては株式会社コパイロツトの方にナレッジの共有や、推進方法など相談させていただいたうえで、ルールとして今整備、運用しているものとなります。
※コパイロツト様に事前に掲載のご了承をいただいているものとなります。 ご協力いただきありがとうございます。

お話の前提

私の案件は小規模（メンバー10人未満）のプロジェクトが多いため、小規模案件での前提として記載します。
また、期間においても3ヶ月程度の短期間の開発プロジェクトを前提としております。

大規模案件・長期間案件・保守案件の場合は必ずしも該当しない観点がある可能性がありますので、あらかじめご認識いただければと思います。

プロジェクトでよくある問題

プロジェクトを実施していく中で様々な問題が発生します。

例えば、開発時のレビュアーが誰なのか、他のチームとのコミュニケーションは誰がとるのか、プロジェクトにアサインしたての人のサポートは誰がやるのかなど、責任分担表にないポイントでの抜け漏れ・作業が偏ることの不公平感。

また、責任分担表には記載があるが、担当者にとってそれが自分のスキルとはずれている場合での担当者の不安、リーダーとの認識のずれ。

問題の多くはこのような見えないタスクや、期待感の乖離によって発生します。
プロジェクトを無事に終了するためにはまず、各メンバー間での気持ちを揃えることから始めるのがよいと考えています。

その一つの方法として、「ロールセッション」を実施しています。

ロールセッションを実施する理由

ロールセッションを実施する理由は上に書いている通りですが、もう少し細かく書くと以下になります。

• 自分を伝える（自己紹介・このプロジェクトでの自分の役割）
• 自分がこのプロジェクトでできること・できないことを正しく伝える
• 相手にこのプロジェクトで期待することを正しく伝える
• 役割分担表に存在していない見えない役割の合意

プロジェクトアサイン者が全員どの領域も完璧となるケースは基本的にはないと考えています。
皆ある程度の偏りがあり得意不得意があり、その中には右も左も分からない新入社員もいるかもしれません。
ただ通常、その偏りを互いに明確にすること自体を行わないと思います。

私はロールセッションで、あえて自分が能力に偏りがあることを周知することで、無用な期待を抱かせない。
その人に与えられている期待値を全員で正しく認識するというのを意識して実施しています。

そうすることで作業の不公平感を減らすことが可能であると考えているためです。

また、役割分担やWBSに表現できない、見えない役割というものを全員で合意するためにも用いています。

例えば、「とある技術のサポートをメンバーにしてもらう」はWBSに用意できませんが、プロジェクトを進める上では非常に重要であると考えております。
それを明示的に依頼されていて、全員で合意されているということであれば、安心してその人に確認することができます。

私はロールセッションをプロジェクトの一番初めに実施しているため、自己紹介も兼ねて実施しています。

いつロールセッションをするのがよいのか

これを読んでやってみようかなと思った瞬間がやるべき瞬間です。
ロールセッションは特別、ここでやるべきというものではありません。いつでも実施することができます。

ただし、効果的なタイミングはいつかどいう点でいうと、新規開発時において効果的なのはプロジェクト初期になると思います。
各メンバーが与えらえている不安値・不公平感が早い段階で下がるためです。

まず何が必要なのか

ロールセッションをやりましょうとなって、ただ闇雲にロールセッションをすればよいというものではありません。
まずは、プロジェクトゴールなど、アサイン者間で共通のテーマを定義することが必要です。

ゴールがない状態で個々人ができる/できないを書くと、そもそも討議がおかしい方向に進みます。
（家事ができませんと書かれていても困るため）

そのため何はなくとも、プロジェクトでのゴール（今のプロジェクトについて）と、各自の与えている役割を話す必要があります。
ここが明確であればあるほど、そのゴールや役割に対して、自分ができる/できないなどの自己認識や、他人への期待が明確になると思います。

逆に言うと基本的にプロジェクトが始まった時点で、そのゴールはある程度定まっているものですので、特別ロールセッションのために何かを準備する必要はないといえます。

保守運用についても開発終了というものはありませんが、運用保守をやっていくということがひとつのゴールですので、保守運用をやっていくうえで、自分ができる/できない、他人への期待を書くことは可能です。

どのように実施するのか

ここからは具体的にどのように実施すべきかという点について記載していきます。

主に自己紹介に関連する

• 自分を伝える（自己紹介・このプロジェクトでの自分の役割）

と、このプロジェクトにおけるロール

• 自分がこのプロジェクトでできること・できないことを正しく伝える
• 相手にこのプロジェクトで期待することを正しく伝える
• 役割分担表に存在していない見えない役割の合意

この２つで構成されています。

下記はあくまで私が今実施しているものになります。自己紹介をもっと多めにする等いろいろ調整してみると、期待値がもっと揃えられるかもしれません。

記載のポイントとしてはあまり長く書きすぎないというのもポイントだと思います。

また、素直に書いてもらうこと、ここで変なことを書いても評価や待遇が変わらないことは必ず話しておいたほうがよいと思います。
期待値を揃えたいのにそのフィルターによって、自分の気持ちを改変されてしまうと、この取り組み自体も意味を成しません。

主な記載観点（自己紹介フェーズ）

主に自分のこと、自分がこのプロジェクトに与えらえているミッションについて答えていくものになります。

1. 好きな仕事
2. 趣味
3. 今興味のある仕事・伸ばしたい仕事
4. このプロジェクトにおける役割
5. このプロジェクトへの意気込み

好きな仕事

エンジニアとしてやっていて楽しい仕事について記載します。
ロールに縛られなくても問題ありません。
（私はロールとしてはPMですが、もともとSQLを書く機会が多かったため、この内容を書いています）

例：

趣味

自分の趣味を記載します。

例：

今興味のある仕事・伸ばしたい仕事

今のロールで作業していて興味がある、伸ばしたいことについて記載します。
必ずしもこのプロジェクトと適合している必要はありません。
ここを共有することで、もしその作業があった場合に作業を振ってもらいやすくなる、情報を得やすくなるというのを目的にしています。
（ここに適合しているタスク場合は、振ってあげると作業に対する興味もありますので、成果が出やすいかもしれません）

例：

このプロジェクトにおける役割

このプロジェクトにおける自分が認識している役割を記載します。
役割分担表に記載されている内容を記載してもかまいませんが、それは明記されていますのでそこから自分が感じ取った自分の役割を記載するのがよいと思います。

例：

このプロジェクトへの意気込み

このプロジェクトに臨む意気込みを記載してもらっています。
具体的にこうしますというアクションを書くというものではなく、単純な今の気持ちを書いてもらうというレベルのものです。

例：

主な記載観点（作業ロールフェーズ）

主に自分がこのプロジェクトでできること、できないこと、他の人に期待していることを答えていくものになります。

1. 必要な役割（自分ができること）
2. サポートしてほしいこと（自分ができないこと、お願いしたいこと）
3. 他の人への期待
4. このプロジェクトでの目標

必要な役割（自分ができること）

このプロジェクトにおいて自分ができることを書いていきます。
具体的であればあるほど良いですが、書けない人もいるため強制はしない方がよいと思います。

例：

サポートしてほしいこと（自分ができないこと、お願いしたいこと）

このプロジェクトにおいて自分が苦手なことを書いていきます。
どんな些末なものでもいいので、まずは記載するのが良いと思います。

ここは特に自分を開示するものになりますので抵抗がある人がいると思いますが、その抵抗に対しての否定、書いた内容についての否定は絶対に避けてください。
知らない人たちがいる中で自分が認識している劣っていることを書くことは、本来非常にハードルが高い行為であるためです。

例：

他の人への期待

自分が他の人に期待していることを、担当者単位で書いていきます。
記載されている内容が同じであるものが多い＝自分がほかの人に期待されていることになります。

どんな些末なものでもいいので、まずは記載するのが良いと思います。
以前議事録を書くかかないという、一見些末な話見えるような話をロールセッションで認識合わせしました。
不公平感・不安を排除するのが主目的であるため、このような些細なレベルもこの場では討議するべきです。

例：

このプロジェクトでの目標

「このプロジェクトへの意気込み」に似ている観点ではありますが、若干意味合いが異なっています。
ここではこのプロジェクトで具体的にどのようなことを達成したいのかを記載してほしいという意図で用意しています。
あくまで個人の話となりますので、作業遅延が発生しないようにするというのも目標です。

ただの作業者として終わるのではなく、どのようなことでもよいので何かひとつ目標を立て、プロジェクトの中で試行錯誤してほしいという願いから、当設問を用意しています。

例：

主な記載観点（このプロジェクトの役割（確定））

「主な記載観点（作業ロールフェーズ）」で記載された内容から、通常の役割表以外にどのような役割を担っていただくのかを記載します。
ここについては、各参加メンバーと話しながら全員が納得するように記載を行っていきます。

最終的に通常の役割表と同じ内容となっても構いません。全員がそれで納得したということが重要です。

例：

どの程度時間がかかるのか・進め方

アサイン者の人数によりますが、最低30分程度見るのがよいと思います。
私の案件では、時間の短縮化のため事前に記載をお願いしていることが多いです。

作業	作業時間	補足
①自己紹介フェーズに各自記載・共有	個人ワーク 2分→共有 1分/人（議論しない）
②作業ロールフェーズの「他の人への期待」以外を各自記載・共有	個人ワーク 2分→共有 1分/人（議論しない）
③作業ロールフェーズの「他の人への期待」を各自記載・共有	個人ワーク 2分→共有 1分/人（議論しない）	・アサイン対象がいない・わからない場合も記述可能にする
④このプロジェクトの役割を精査・承認し、議論して深める	自分の記載事項の共有 1分と質疑・議論 1分 → 合計 2分 /人	・必要であれば未アサイン期待値を振り分ける ・発表・質疑・議論後に必要であれば自分でリライトする

実施フォーマットが必要なのか

ロールセッションを実施するにあたって、エクセルで実施するべきなのか、それとも別のツールを使うべきなのか、という観点があります。
これについて回答するならば、実施フォーマットは特別に指定する必要がなく、使い慣れているもの・後で見返せるものであるのが適切であると考えます。

できればMiroやGoogle Jamboardなど、ホワイトボードツールを利用するのがとっつきやすいかもしれません。
とはいえ、どの様なツールでも実施することができますので、普段プロジェクトで使っているものを利用するのがよいと思います。

ただし、SlackやTeamsなどタイムラインがあるものは避けるべきだと思います。
理由は振り返りたいときに埋もれてしまい、振り返りが難しくなる点や、コメントした人間しかUpdateができなくなるためです。

ロールセッションは全員で書くというのが重要ですので、適宜修正できるようなツールを利用するのが良いと思います。

私の案件での例1（Google Spreadsheet）：

私の案件での例2（Google Slide）：

一度ロールセッション実施したら終わりなのか

ロールセッションは自分の役割を明確にするために利用しますが、役割は確定しないというのが重要だと考えています。
特にプロジェクト初期の役割は、実施にあたって変わっていく可能性が大いにあり得ます。

そのため、継続的にロールセッションを行うのが望ましいです。
ですが、何度もロールセッションを行うのは時間的に厳しいと思います。
そのときは、ロールセッションを振り返るということを定期的に実施することをお勧めします。

ロールセッションを振り返る理由は、主に役割の認識と再検討にあります。

• 振り返って自分の役割を再認識する
• 振り返って自分の役割が適切であるのかを再度判断する

上で振り返るという話をしましたが、振り返った結果当時の役割ができなそう・加えて別の役割もできそうなど変更点があります。
できなそうという、マイナスの要素も含め再検討する必要があれば、改めて全員で役割を再度合意していくことで、不安なく作業を推進できると考えています。

おわりに

プロジェクト全員が同じく高いスキルセット統一されているのがベストではありますが、現実的にあり得ないです。
その中で全員が納得して不安なく作業を進められるの良いと思います。

この記事がプロジェクトマネージャの皆さんにとって何か参考になれば幸いに思います。