一つ上のチームメンバーのそだてかた

自分が先輩社員となり、チームを持ち、すぐに直面する問題といえば「エンジニアの育成」問題です。

私は7年間システムエンジニアとして働いてきた中で早い段階で多くのメンバーを育てる機会に恵まれました。メンバーの中には文系出身の新人や技術に尖った新人、数年間くすぶっていた中堅若手と様々な境遇の人がいました。

性質がそれぞれ違うなかでどのように"プロ"として育て上げたかを紹介したいと思います。

育成のきほん

まずは下記の図を見てください。これは「1分間リーダーシップ」(Paul Hersey, Kenneth H Blanchard/1985年) で取り上げられているSL理論 (Situational Leadership)というメンバーの能力とモチベーションに応じて発揮すべきリーダーシップを表した図です。

S1の状態から順に2,3,4とリーダーシップを変更させていくことが望ましいとされています。

単に発揮すべきリーダーシップの型として語られていますが、メンバーの成熟度を上げる方法については語られることが少ないです。そこで今回はITの現場でリーダーシップを発揮しながらメンバーの育成を行う方法論について深めていきます。

重要な点は、メンバーの成熟度によって(リーダーシップとともに)教え方を使い分けなければいけないということです。教える側が真っ先に行うべきことは、育て上げるメンバーがいまどのレベルにいるかを見極めるということです。

レベルを見極める

ITの現場ではしばしば「アーキテクトの実務経験○年」や「業務で○○言語を使用したことがある」など表面上のチカラで語られがちです。しかし真の意味でレベルを見極めるにはメンバーのアウトプットを見て判断する必要があります。

観点とやりかた

• 技術面
  • 技術を体系的に学習をしてきたか？
  • 仕様をソースコードに落とすことが出来るか？
• 業務面
  • 適切なタイミングや粒度で質問ができているか？
  • 現実的な見積もりや計画が出せるか？
  • 業務では仕様の本質を追い求めてきたか？

これらの能力を見るためには(たとえば3時間など)具体的に時間を区切って仕事を**「委任」**してみるのが早いです。

評価する

委任した仕事に対して実際にアウトプットがなされたら、チームメンバー全員で1行1行に至るまでに「なぜそうしたのか?」(Why)をぶつけてみます。そして上記の観点がどのレベルにあるのかを見極めます。このとき嫌な先輩たちだな、と思われるくらい質問することが求められます。
評価される側のメンバーは誠心誠意答えます。今までググってでてきた内容をコピペして乗り切ってきた中堅メンバーはここで死滅します。

そして、アウトプットもさることながらここに到達するまでのプロセス(計画、質問のレベルetc.)も評価の観点として含めるべきです。アウトプット作成中のやりとりを事前に新メンバー以外のチームメンバーにヒアリングし判断します。

ここでやっとどうやって育てていくかのスタート地点に立てます。

レベルごとのそだてかた

ではメンバーの成熟度ごとの方針をみてみましょう。

S1: 指示型

メンバーの成熟度が低い場合に用います。

どのような状態か?

• 体系的な知識を有していない
  • 新人は言わずもがなですが案外、中堅メンバーにも多いので注意して見る必要がある
• 作るものの全体像や流れのイメージを持たない状態
  • ITの現場では具体的な完成像を目の前で共有できないことが多いため (町工場の職人の師弟とは違い、師の作品が形として共有されないため)

効果的な学習スタイル

ここを脱却するためには、体系的に学び作るもののイメージを持つことが求められます。
アウトプットよりも仕事のプロセスを大切にする育成が必要です。

• タスクの細分化
  • タスクに入る前にこのタスクの"成果物と完了条件"を一緒に定義する
    • タスクでどこまで実装すべきかをすり合わせる
    • タスクの中に定義を明記する
      • チームメンバー間の認識齟齬をなくす
  • 30分ほどの作業粒度になるまでTODOを一緒に積み上げる
    • 「機能」がどのような部品の集合やデータの流れで出来ているのかを知る
    • タスクの中に定義を明記し、チェックリスト化する
    • 実装の観点/考慮点を盗ませる
• ペアプログラミング (教育的側面)
  • 徹底的に"why"を叩き込む
    • 教えられるメンバーは1行1行に「なぜそうするのか?」を質問することが求められる
    • 自身の成果物に責任と自信をつけて、圧倒的当事者意識を植え付ける
  • 紙やホワイトボードでデータの流れや関係するコンポーネントを書き出して議論を行う
  • タスクが終わったら一緒にTODOにチェックを入れて達成感を共有する
  • 教える側の仕事の進め方を肌で感じられる
    • コードの書き初めには何をすべきかなどを知れる
    • ググり方を学ぶ
    • Editorショートカットキーなどを教わる

とても手間はかかりますが、ものづくりの楽しさを教えるための絶好の方法です。この時期は過保護にするくらいがちょうどいい状態といってよいでしょう。

S2: コーチ型

メンバーの能力は発展途上であるが、成長に向かって進む意欲のあるメンバーに用います。

どのような状態か?

• 全体像が表面上で説明できる
  • 経験が浅く、細部の理解には乏しい
• 自主的な作業を調べながら少しずつ進められる
  • 自ら提案し、相手を納得させながら進む力がない

話のコンテキストはズレていないが、説明する力や知識に乏しい状態と言えます。

効果的な学習スタイル

ここを脱却するためには、表面上の知識だけではなく1つ下の層の知識をつけて根拠をもたせることが求められます。アウトプットに対するフィードバックを常に行い、自身のアウトプットを確実に説明できる状態を目指す教育が必要です。

• フィードバック
  • タスクのTODOリストへのレビュー
    • 考慮漏れがある場合は勝手に修正せずに、指摘を行う
  • ソースコードのレビュー
    • レビューが共有出来る仕組みの導入 (Gitlabなど)
    • 可能な限り多くのメンバーがレビューに参加する
  • ソースコード修正の影響
    • CIを導入する (Jenkinsなど)
    • テストが落ちることで自身の修正がどこに影響を与えるのかを即時得られる
• 業界における定石の基礎学習
  • 技術書による基礎知識の獲得
    • チーム内読書会を提案し、実施してみる (技術書の中で比較的読みやすい「リーダブルコード」など)
  • 技術のアウトプットとフィードバック
    • チーム内LT大会だと議論しやすい
    • お題は最近書いたコードなどLightな内容で良い

メンバーの少し遠い位置からのフィードバックを行い、方向性をすり合わせながら進むと良いでしょう。
また、インプットした知識を常にアウトプットする癖をつけることでセルフフィードバックの良いループが回るようになります。この状態までくれば、他の人への質問や説明のレベルは格段に上がってきます。

S3: 援助型

メンバーの能力はある程度高いが、意思決定への不安を覚えるメンバーに用います。

どのような状態か?

• 全体像が正しく説明できる
  • 一部の分野に関しては専門性が見られる
  • 具体的な根拠や自分なりの解決策をもって議論に臨めている
• 仕様を満たす実装の選択肢を複数持っている
  • 選択肢の中から最適な解を導くことに不安を持っている
  • 適切な相談を行い意見交換を行えば進むことが出来る

おおよその問題は意見交換や知識の整理を手伝うことで解決できる状態と言えます。
ほぼ手のかからないメンバーと言っていいでしょう。

効果的な学習スタイル

ここを脱却するためには、1つ下の層の知識を把握した上で人的・時間的リソースの観点から適切な選択ができることが求められます。自分の行っているアウトプットと世界の技術動向をリンクさせる教育が必要です。

• 業界における定石の応用学習
  • 技術書による応用知識の獲得
    • Deepな内容や新しい技術を取り上げて定期的に実施する
  • 技術のアウトプットとフィードバック
    • お題は最新技術とその実用例の内容など、尖った内容であることが望ましい
• 使用している言語やフレームワークへの理解
  • コードリーディング
    • フレームワークの振る舞いやコンポーネント設計を学ぶ
    • フレームワークの細部の挙動を踏まえ、書いているコードが正しいかを説く

最新技術の動向を議論して、少ない情報から深い世界へひとりで潜ることのできる練習を積み重ねます。
ここまでくればメンバーの中では一目置かれる存在になっていきます。

S4: 委任型

どのような状態か?

• 技術に関するアンテナを巡らして主体的に知識を獲得している
• 適宜、自身の成果を説明・発信している

この人に任せておけば安心という状態と言えるでしょう。

効果的な学習スタイル

これより上のステップに上がるためには、顧客やサービスの要件に考慮をめぐらしてより良い仕様として昇華することが求められます。この状態まで来ると、ほぼほぼ教育という面では語る点がなくなってきます。強いて言えば

• 業界全体の事例やソリューションの発信
  • 社内外の事例の獲得
    • 事例についての問題点を議論し列挙する
    • 問題点について再設計する場合の議論をする
  • 自身の成果を国内外に向けて発信
    • 規模の大きいコミュニティーでの登壇を勧める
    • OSSソリューションの開発
    • 書籍の執筆

会社や組織内の後続メンバーの育成を牽引したり、より専門性の高いステージへ挑戦をしたり、業界全体のフィードバックを回したり...と進んでいくことでしょう。

まとめ

• 自分が育てる立場になったときは発揮するリーダシップとともに育成方法もセットで考えるべき
• 育て上げるメンバーのレベルをチーム全員でただしく見極める
• ただしい育成方法を選択する
  • 仕事の内容がメンバーを育てると決めつけない
  • 仕事を委任し、責任を与えれば勝手に成長するものだと捉えない

いま一度チームメンバーのそだてかたについて考え、気持ちよく仕事ができる環境づくりをしてみましょう！