「成長するプロジェクト計画」は、本当にメンバが成長するやり方だと思った。
こんにちは。
発案者の熱い行動に感化されて、会社のAdvent Calendarに参加することになり、初めて記事を書きます。よろしくお願いします。
記事ネタですが、私は人が「できるようになった！」と成長を感じる瞬間に立ち会うのが好きで、育成について色々と考えたり、試したりしていますので、そこで得られた経験について書いてみます。
チームについて
内容に入る前に、チーム説明をします。
私のチームは、社内外の様々なプロジェクトを支援しています。様々なタイプの支援がありますが、一番多いのは新規事業の立ち上げです。
メンバーは、みなもともとエンジニアなのですが、支援プロジェクト中で横断的な役割を求められることがあり、流行り（？）の越境にチャレンジしています。越境には、「デザイン」と「ビジネス」の２つの方向があるのですが、「エンジニア＋デザイン」案件の支援が多く、越境も必然的に「エンジニア」→「デザイン」方向が主流になっています。
これまでの育成のやり方
越境といっても、簡単にできるものではありません（そんなこと言ったら、その道のプロフェッショナルにボコられます）。エンジニアが長年かけて育つように、エンジニアがデザイン領域で伸びていくためにも、長い期間と経験が必要になります。
育成の基本的な考え方としては、「勉強する」「実践する」「振り返る」というサイクルを回すということですが、特に「実践する」「振り返る」という点で、様々なやり方を取り入れてきました。
例えば、クラスメソッドさんの「タスクバラシ」。
「セルフマネジメントの必須スキル」というタイトルですが、私は「スキルトランスファーの方法」とも認識しています。
エントリーレベルの人は、ある仕事を任されても、どう進めればいいのかがわからないことが多い。そこで、その道のリードが一緒にタスクバラシしてあげることで、再利用可能な単位にタスクを分解する。これにより、チームでタスク用語を共通化できるし、その中身も教えやすく（教わりやすく）なる。といった効果があります。
また「月次／週次の目標設定MTG」という仕組みも導入しています。
関わっているプロジェクトで、今月や今週の成長目標（どんな経験が詰めそうか？どんなスキルを得たいか？）を考え、1か月後や1週間後の振り返りで達成度合いを振り返る。という仕組みです。
※開発フェーズの支援時には、Scrumのレトロスペクティブなども行いますが、振り返りの単位がチームになります。個人レベルでの育成を「明示的」に行うための取り組みという位置づけで行っています。
コンセントさんの「プロジェクト学習計画」
～出会い、そして実践～
ただ、毎回、日や週や月の学びをうまく収穫できたのか？というと、実際はそうでもありませんでした。そもそも予定されていた行動をしなくなったり、目標に対して、得られた経験が少なかったり。もう少しいいやり方はないだろうか？と考えていたところに出会ったのがコンセントさんの記事でした。
批判を恐れずにざっくりまとめると（詳細は記事を読んでください！）
プロジェクトにおいて、リード、サブ、エントリとレベル分けをして、何を学んでいくか明示する仕組み（何を教えるかが可視化され、スキルトランスファーが進む）
実際のプロジェクト計画（やる作業内容）に応じて、学ぶことを可視化する（なので実効性が高い）
上から教わるだけでなく、それぞれが自分の成長目標を立てることで新しいことにもチャレンジできる。（新しい知が生み出されやすい）
ということなのではないかと思っています。
読んでみて、考え方等にとても共感したので、チームで試してみたところ、これが非常に効果的でした。これまでのやり方の中でご紹介した「週次定例」との比較でいうと、次のようなメリットがあると感じました。
各メンバが「教えること」「学ぶこと」を意識づけされるため、「言語化」が促進され、暗黙的なノウハウも共有される
プロジェクトのTODOに紐づいた成長目標を掲げるため、実施しなかった。ということがほぼない
また、実際にやってみたメンバーからも
・他のレベルとの目標の差分を知ったり、やることに合わせた目標を立てたりすることで、今までより取り組みたいこと、学びたいことの解像度を上げて取り組めた
・目標を実施しやすいので、地に足ついた目標を立てやすかった
・リーダーやサブのやりたいことが見えて関わりやすくなった
・実行性の高さがウリですね。エントリーがいるときは特におすすめ。
といった高評価のコメントもありました。これからも継続して使っていきたいと思います。
～取り入れるときのコツ・気を付けること～
ただ、我々の初回トライアルではうまくいきましたが、見えないところにうまくいった要因があったと思います。もし「やってみようかな？」と思われる方がいれば参考になるかと思いましたので、ここで3つほどご紹介します。
1．リードの動機づけが必要
1つ目が「リードの動機づけ」です。
リードといっても様々な人がいます。特に、サブやエントリーを育てることに対して、意味を感じる人、逆に感じない人。この特性を理解したうえで導入を決めないと、失敗する可能性が高くなると思いました。
今回のリードUXデザイナーは「意味を感じる人」だったので、動機づけは不要でしたが、人によっては「なぜ育てるのか」といったことを、しっかりと意味づける必要があると思います。（どう意味づけるかを書くと、長くなるので割愛）
2．教える・教わるの関係性の構築が必要
2つ目が「教える・教わるの関係性の構築」です。
実は、今回のメンバは他のプロジェクトで、一度組んだことがあるメンバでした。その時の関係性、信頼関係が今回の学習をスムーズにさせていたと思います。
始めて参加するメンバ間では、チームビルディングなどをしっかりとやったほうがいいと思いました。
3．計画を立てすぎない
3つ目は、「計画を立てすぎない」です。
実際のプロジェクトの現場では「アウトプット」が優先され、逆に「学習・成長」の優先度は低くなりがちです。この事実に基づくと、この仕組みの運用自体に過大な時間はかけられません。
当たり前のことですが、そこで大切なのが、「計画を立てすぎない」だと思います。なぜならば、当初の計画通りに進むプロジェクトはほぼなく、先の計画を立てすぎても結局修正することになるからです。
具体的には、プロジェクトスタート直前には「全体像をざっくりと」、そしてプロジェクトの期間中には「2週間先までをじっくりと」くらいがちょうどよいと思います。
全体像を想定することで最終的に得られる学びを想像し、作業計画が大きく変わることのない2週間という単位で、学びの詳細な設計を行う。という考え方に基づいています。
最後に
今回、私のチームに「学習するプロジェクト計画」を適用したお話を書きましたが、いろいろな職種の人に使える方法だと思います。ぜひ、一度チャレンジされてみてください。
長い文章を書き慣れていないこともあり、読みにくいところもあるかもしれません。ただ、本文章中にリンクを張った記事は、どれも面白いですので、もしよければ読んでみてください。皆様のお役に立つと思います。
あ、あと、いつも私の育成の新たな方法論に付き合ってくれるメンバに、ここで改めて感謝です。
では、みなさま、ごきげんよう！良いお年を！
この記事が気に入ったらサポートをしてみませんか？