データアナリティクス事業本部＠札幌の佐藤です。 私は、自身のプロジェクトでプロジェクトメンバーが成長してほしいと願っています。 それがないと、プロジェクトを離任した際に自分が何のためにこれまでやってきたのかという疑問を持ったまま、次に案件にアサインされてしまいます。 折角、プロジェクトで働いているのであれば、何か不安に思っていることが1つでも解消して欲しいと思います。 そのため今回は、私のプロジェクトで実施している、「プロジェクトでの学び」について記載したいと思います。 当活用にあたっては株式会社コパイロツトの方に相談させていただいたうえで、プロジェクトの中で実践しているものとなります。 ご協力いただきありがとうございます。 また、当記事の別側面としてコパイロツト様から見た視点で、なぜプロジェクトでの学びが必要なのか、プロジェクトで学んでいくためのプロジェクトマネージャーの役割とは何かという観点で記載しております。 併せて見ていただくと、学びという取り組みについて、より深く知ることができるかと思います。
お話の前提
私の案件は小規模（メンバー10人未満）のプロジェクトが多いため、小規模案件での前提として記載します。 大規模案件の場合は必ずしも該当しない観点がある可能性がありますので、あらかじめご認識いただければと思います。
学びという取り組みの「なぜ」
ここでいう学びと何か
学び、つまり学習という意味となりますが、Wikipedia上では下記のように記載されています。 学びはある何かの事象を経験・それに対するアクションによって得られる何らかの「気づき」を蓄積することといえます。
学習（がくしゅう）とは、知識、行動、スキル（能力）、価値観、選考（好き嫌い）を、新しく獲得したり、修正したりすることである[1]。生理学や心理学においては、経験によって動物（人間を含め）の行動が変容することを指す。繰り返し行う学習を練習（れんしゅう）という。又は一度行った学習をもういちど学習することを、復習という。 https://ja.wikipedia.org/wiki/%E5%AD%A6%E7%BF%92
気づきは普段、意識しなければなんとなく自分に蓄積しているもので、その蓄積が気づくと自分のキャリア形成や、今後の道筋になっていたりします。 上でも記載した通り、何かの事象を経験・それに対するアクションとなるため、例えばAWSの資格を自分で勉強していく中で獲得したものも「気づき」です。 つまり、当然の話ですが自己学習も学びであるということです。 また、何かを意識的に気づくためには、何らかの目的（どうなっていたいのか）をもってその事象と対峙する必要があります。 AWSの資格の勉強であれば、資格を取るというのが目的となります。 ただし、必ずしも「気づき＝目的が明確」ではないと考えます。 なんとなくで経験したことで気づいたこと、それが面白かったなや、これは苦手かなというのも十分な気づきです。
なぜ「プロジェクト」で「学び」を設計するのか
気づきの獲得が自己学習だけで充足するものなのか、個人的にはそこに疑問を持っています。 自己学習の気づきだけで十分だという話だと、プロジェクトにアサインされてもそこに得られるものがないということになります。 それはあまりにも悲しく、普段１日の大半をプロジェクト内活動で占めているのであれば、少なからず何かを獲得して帰ってほしいというのは、プロジェクトマネージャとして思うことであります。 以前、プロジェクトマネジメントについて記載していますが、その際プロジェクトについて下記のように記載しました。
- 定義された期間中（有期性）で指定された精度のサービス・製品を提供（所産）するのをプロジェクトと呼び、その目標を達成するために力を合わせて活動するということが組織
- プロジェクトメンバーが複数人いる場合は、協力して目標を達成していく。それを資料などで明示的（あるいは非明示的に）に定義させたものをプロジェクト体制と呼ぶ
プロジェクトについて単純にに見た場合は上記言葉の通りです。
ただ、プロジェクトには様々なステークホルダーがおり、様々な出自・観点をもった人間が集合して成り立っています。 つまり、自己学習とプロジェクト活動での大きな違いは、「様々な出自・観点をもった人間が集合」であるという点です。
クライアントだけではなく、プロジェクトにアサインされたメンバーのプロジェクト満足度を考えていくという点も考えていくのも、プロジェクトマネジメントのひとつの要素であると考えてます。
アサイン者のスキルが単一ではないため、プロジェクトアサインメンバーの技術・ビジネススキルの把握、また、プロジェクトでのメンバーの成長を考えていく必要が出てきます。 この観点はネガティブにとらえられますし、ポジティブにもとらえられますが、ポジティブに受け止めるのがよいでしょう。
アサイン者のスキルが単一ではなくそれぞれが強みがあることで、プロジェクト活動する意味があるという考えをするのが適切です。 その様々な強みを持ったメンバーがいる中で、いかに相互に協力してプロジェクトを推進・メンバー育成し、育成されたメンバーがまた次のメンバーを育成するというフレームを作り出すことが重要だと考えます。
会社・プロジェクト・個人は階層として存在しますが、それぞれの階層にて新入社員からベテランまで様々なバックボーンを持っている人たちがいます。
今回はプロジェクトに閉じるものですが、個人から個人・個人からプロジェクト・個人から会社・プロジェクトから会社の2者間でアドバイスしあえる環境を構築することで、多方面の視野を取り込んだ学びを手に入れることが可能になります。
最終的に学びを通じてクライアントの満足感を向上する
プロジェクト満足度という考え方はクライアントに対してもありますが、アサインされているメンバーに対してもあります。
今回の学びという側面にフォーカスした場合は上記で記載した通り、周囲のフィードバックから自分の知らない観点を手に入れることができるというのが挙げられます。 プロジェクトを通した学びを得るサイクルを作り出すことで実験→フィードバック→実験のサイクルができるような状況を作り出し上げることができます。 それだけではなく、プロジェクトで成長をするということでプロジェクトにアサインされる価値が生まれます。
エンジニアとして、プロジェクトアサインは必ずしも自分の希望通りならず、利益のためにある意味で言うと空いている席に座ることになります。 その場合、ある瞬間に自分がなぜ頑張っているのかを見失う可能性があります。
学びとして、目先の目標を立て・不安も含めてメンバーに共有し相互で支えることで、プロジェクトという小さな円の中ではありますがロール・担当などが生まれ居場所というものができてくるのかなと思っています。
また、居場所という意味でも自身のパフォーマンスをあげていくためにも、プロジェクトを通して学びが得られたという充実感をいうのを意識したほうがよいかと思います。 上記のようにプロジェクトで良いフィードバックおよび学びが手に入ることにより、プロジェクトへの満足度が上がる可能性があります。 そうするといろいろなことをプロジェクトの中で実施したくなり、結果的にクライアントへの成果や満足感につながるのではと考えています。
なぜ「目標」ではなく「学び」なのか
ここまで何かの目的に対する気づきを「学び」と呼称してきました。 それはつまり目標という言葉でも表現可能で、通常この手の取り組みは「目標設定」という名目で取り組まれることが多いものとなります。 なぜ「目標」ではなく「学び」と銘打っていたのかというと、自発的な行動としての目標（学び）と管理目的としての目標の違いになります。 単純に「目標」とした場合、目標達成のための基準の明確に策定をする必要があります。（またはそのイメージを言葉から持ちます） 後述しますが、「学び」を考えたときに「ある期間をゴールと見定めた際の明確性」が高いと、目標設定のハードルがあると思います。 そのため、学びという考えにおいては、「自身の内省」と「相互の支援」というのを中心に考えています。
- この取り組みに対してのプロジェクト評価が存在しない。
- 絶対に目標を立てる必要はそもそもない（人の考え方による）
- プロジェクト・プロジェクトメンバーに上下関係はなく対等
上記からプロジェクトでの学びという取り組みとしては、自分がどんな学びをしたいかの共有からの、もうちょっと手前のレベルからスタートしたいと思っています。
この取り組みに対してのプロジェクト評価が存在しない
この取り組みに対してのプロジェクト評価が存在しないというのは、そもそも施策としてプロジェクト評価に関連するまでに至っていなかったというのは正直あります。
ですが、この取り組みを実施していく中で、逆に良かったと思える事象もありました。 それはプロジェクト評価が存在しないことにより、取り組みの成果を考える際に「安全に達成可能な目標」を立てる必要性がないというものです。
学びで立てた学びが仮に失敗しても何も自分にとっての評価的な被害はないため、その分自由に何を学びたいかを立てることができるようになります。
絶対に目標を立てる必要はそもそもない（人の考え方による）
よくプロジェクトアサイン時に目標を立てることもあるかと思います。
自身が目標を立てるのが苦手という側面もありますが、プロジェクトアサイン時に目標が必要なのかどうかというのは、人の考え方によります。
それを強制してもよいですが、デメリットについては上記にも記載した通り、目標というワードが目的が必要ととらえがちです。
ただ実際プロジェクトアサインされた際、特に初学者とは特にそうですが、必ずしも自身のキャリアパスが明確に設定されているわけではありません。 また、キャリアパスとプロジェクトでの要求事項が必ずしもイコールではありません。 最初から見えていたわけではない自身のキャリアパスが、作業を振られていく中で見えてくるということもあります。 ただがむしゃらに目の前を実施することであっても、そこに学びは存在しているはずです。 それが必ずしも具体的な自身の目標と紐づけられない可能性があるというだけだと思います。
目先のなんとなくのやりたいことという、抽象的なやっていきたいことを重視したいというのが、この取り組みの中心となります。
プロジェクト・プロジェクトメンバーに上下関係はなく対等
通常、「目標」を立てた場合、目標に対しての達成度を評価するプロセスが存在します。 つまり、何かの試みの評価をする際に、そこに評価者と被評価者が存在し、上下関係が存在します。
この取り組みは、自分の学びを共有することも目的のひとつとして存在しています。 そのうえで重要なのが「個対個ではなく個対他で進める」であることであると思います。 評価者と被評価者が存在するのではなく、全員がスーパーバイザーとして関係することによって、相互に協力して育成するのが望ましいと考えています。
また、プロジェクトに対してもフラットに自分のやりたいことと、プロジェクトが自分に期待していることの認識を併せることで、全体が協力していく形にするのが重要だと考えます。
上記にも書いていますが、学びの取り組みは下記であるべきだと考えます。
- 頑張りかたを様々な側面・角度から判断・評価するべき
- 目標は全員で認知・支えあったほうが効率的
プロジェクトを通して、自身やプロジェクトがどうなっていけばよいのか
「学び」をキーワードとして、個人やプロジェクトの中で成長し続けるループを作り出していければよいと考えています。 上記の円の関係性でもありますが、個人やプロジェクトの中でできること・改善事項を積み重ねていくことでよりよい状況が作りだせればよいです。
- 自分が何をプロジェクトを通して勉強してしていきたいのか
- 個人での内省だけではなく、みんなでアドバイスし合う関係性をつくること
- 次のステップを検討し、具体的なアクションを見出すことができている状態にしたい
どのように学びを見つめていくのか
学びを見つける
まずはこのプロジェクトで何を学びたいのかを記載してもらいます。
まずは初期アサイン時に記載してもらい、ある程度の折を見て小さく振り返るのが良いと思います。
ポイントとしては、最初の学びはPMとエンジニアで一緒に考えていくのがよいという点です。
1on1を行い、学びたいことの解像度を上げてもらうのが理由です。
1on1と1on1を行わないケースで検証してみましたが、それぞれで解像度が異なるというのを強く受けました。
やはりこのプロジェクトがある程度会社や部署に対しての価値や、何を期待されているのかを話し、不安事項は何かというのを聞いたうえで共に決めていくことで、まずはPMとエンジニア内での合意がとれるようになるのかなと思います。
また、記載内容はプロジェクトメンバー内で見ることができるものにするのも重要です。
個人の宣言だけでなく、プロジェクトや他者からの期待で、学ぶべきことを合意しあうというのがあるためです。
私のプロジェクトではGoogle スプレッドシートで、プロジェクトメンバーであればだれでも見ることができるようにしています。
また、後述する学びを蓄積するで記載する出来事も同じスプレッドシート上に記載しています。
例）
学びを蓄積する
見つけた学びについて、その週どのようなことが起きていたのかを記しておきます。
事象はポジティブ・ネガティブ問わず記載するのが重要です。（できればポジティブ多め）
後述する振り返りを実施する上での重要なインプットとなるのと、自身が少しでも成長しているという実感を振り返りの際に感じるためです。
学びの蓄積はプロジェクトメンバーが相互に見えるように記載し、記載する際には他プロジェクトメンバーの記載した学びにも目を通すように声掛けを行うのも必要です。
そうすることで、他の人が悩んでいることで自分が回答可能なのものが見えるようになるためです。
例）
学びを振り返る
学びを見つめるうえで、6つのポイントを用意するのがよいと考えています。 学びを考えていくうえで、「プロジェクトでありたい姿」と「そのための学び」という軸を用意しています。 「プロジェクトでありたい姿」として、プロジェクトの一員として自身がどう振舞えばよいのかを考え、それに対して学びを構築していくのが望ましいと考えているからです。 単なるワーカーとして停滞するのではなく、そこから少しずつ考えていくことで成長につながるだろうという考えからです。
- （他者起点）プロジェクトへの貢献・役割としてのありたい姿
- （自分起点）自分としてありたい姿
ただし、上記にも書いている通り、「プロジェクトでありたい姿」を全員がイメージして働いているわけではありません。 アサインされたばかりの人や、自身の強みが出せていない人などが該当します。 そのため、学びの補足として考えていくのが望ましいかもしれません。 また、なぜ実施するのかにも記載をしていますが、取り組みとして「自分の学び」「周囲の学びの認知」「周囲のサポート」を通じてプロジェクトで成長するとしています。 通常のKPTなどとは異なり、フォーカスするのはプロジェクトではなく、あくまで自身ということを忘れてはいけません。 「プロジェクトでXXXXを貢献するために、YYYYを学んでいきます。そのためプロジェクト（周り）がZZZZをサポートしてほしい」という、自分を中心として良いということです。（できること・できないことはありますが） ここからもわかるように、前提として、そのプロジェクトで相互に認知しあえる状況でなければ効果は薄いのではないかと思います。
上記を繰り返していくことで学びにサイクル性が生まれ、プロジェクトでの成長を通じ、プロジェクトでの存在意義というのが生まれるのではないかと考えています。 ここからはもう少し細かい観点でどのようなことをイメージすべきかを記載します。
①プロジェクトでありたかった姿の確認
プロジェクトを通じて当初、1年後自身がどうなりたかったのかを整理・思い返すものになります。 （プロジェクトが1年未満で終了する場合は、もし1年続いたと仮定して） 「プロジェクトでありたい姿」は必須としないほうが上手くいくという感覚を持っています。 理由については上記に記載のとおりです。 プロジェクトアサイン時や後述する「プロジェクトで何を学ぼうとしていたか確認」で、イメージ可否から認識をあわせておくが望ましいです。
②プロジェクトで何を学ぼうとしていたか確認
プロジェクトを通じて当初、1年後何を学びたかったのか、学びたかった内容を得ることができたのかを確認・思い返すものになります。 「学びを蓄積する」で蓄積した内容の思い出す作業を行います。 また、自身だけではなく他の人がどのような学びを得ようとしていたのかも確認します。
③過去のふりかえり
①と②で確認・思い返したものから下記4点の軸でそれぞれ何をやってきたのか・それがどのような結果であったのかを整理していきます。 ポイントとしては、失敗だけにフォーカスしない点と、プロジェクトの出来事ではなく自身にフォーカスすることです。
- 【トライしたこと】この学び、やってみた！（成功・失敗問わずチャレンジ）
- 【学べたこと】○○を理解できた！できるようになった！（学びで成功したこと）
- 【教えてもらった！】○○さんに△△のことを教えてもらって、助かった！勉強になった！（学びでサポートしてもらったこと）
- 【もっとこうしたかった！】もっと学びたかった！こうしたらよかった！（学びでうまくいかなかったこと）
例)
振り返りはポジティブに
失敗だけにフォーカスしがちですが、改善する余地があるかもしれません。 この場は思い描いていたことを周囲に共有するということも必要な観点です。 改善する余地があるものについては、今後の学びたいことと、周囲のサポートを依頼し、できるように近づいていくのがよいと考えます。 また、内省として自身を振り返るのも大切ですが、学びを得ていく中で周りにサポートしてもらったことがあれば、ポジティブなフィードバックとして伝えていくべきです。 周りも手を差し伸べて良かったのかということを悩んでいるケースがあるためです。
④このプロジェクトの1年後、どうありたいか？
ここから1年間プロジェクトが継続すると仮定して、自分はどうありたいのかを整理・再設計していきます。 過去の振り返りでも記載しましたが、「プロジェクトでありたい姿」は必須としないほうが上手くいくように思えます。 学びたいことが目先の事項なので、ありたい姿が想像できなくたってよいです。 ただ、自身のロールや、ロール以外での役割から自分の未来を想像し、他のメンバーと期待値として、自分がこうなりたいということを相互認識合わせる方がよりサポートが受けやすくなるのかなとは思います。
例)
⑤今後何を学びたいか？
ここから1年間プロジェクトが継続すると仮定して、何を学んでいきたいかを整理・再設計していきます。 学びたいことは変更してもよいですし、変更しなくてもよいと思います。 ここでの内容を元に、学んでいく中で起きた出来事や考えたことを蓄積していきます。 また、学びたいことを共有することで、周りからサポートが得られるようにするのも目的としています。
⑥成長のサポートができるか
個々の学びについて下記3つの観点で何をサポートしてほしいか・双方で同サポートしあえるのかを整理しています。 最終的にメンバーと合意を行い、次の振り返りに向かってサポートを行っていきます。
- プロジェクトでサポートしてほしいこと
- メンバー同士でサポートしてほしいこと
- 個人としてやっていくこと
各自が考えているプロジェクトでサポートしてほしいことは、ある程度グルーピングができる可能性があります。
そのため、整理についてはまずは各自が発散的に記載し、ある程度の塊でサポートできることを記載しておくのがよいです。
メンバー同士でサポートしあえる内容のうち、プロジェクトで実施していったほうがいいこと・プロジェクトでサポートする内容と同義である場合がありますので、その場合は討議の上方針を決めていくのがよいと考えます。
例）
学びの蓄積・振り返りを行う上のTips
振り返りにどのくらいかかるのか
振り返りの取り組みにどの程度かかるのかという観点で言うと、実績として10人未満で2.5h～3h程度はかかります。 時間がかかる理由としては、思い返す時間や今後の自分の学びを再構築するのには当然時間がかかるためです。 必要な工数が多いというのもありますが、連続して実施するよりも数回に分けたほうが効果的であるように思えます。 特に過去の振り返りと未来を考えことの間は少し開けたほうが良く、その期間内ですこし自分の頭で想像してきてもらうというのが良いと思います。
- 1回目（1h程度）：振り返り①～③
- 2回目（0.5～1h程度）：振り返り③～⑤
- 3回目（1h程度）：振り返り⑥
日々のメンバーのメンテナンスも必要
学びの蓄積開始後、放置していてよいのかという点についてはNOだと考えます。 個人という立場ではなく、PMという立場からプロジェクトの学びの構築を考えた場合、この取り組みはプロジェクトとプロジェクトメンバーの相互の解像度向上・良い関係性を作りあげる作業となります。 この取り組みは上記で記載している通り、プロジェクト満足度の向上が要素にあります。 そのため、学びを蓄積させている最中であっても、適宜1on1でヒアリングをしていくことが肝要です。
さいごに
まだまだブラッシュアップが必要な試みではありますが、現状で私のプロジェクトが実施している内容についてお話ししました。 プロジェクトのメンバーとして、また一人の個人としてプロジェクトを楽しく過ごしていければよいと思います。 この内容が誰かの参考になれば幸いです。