こんにちは。ホワイトプラスCTOの森谷です。
現在、ホワイトプラスのシステム開発チームは10名体制で、2020年度には倍の約20名規模のチームになることを目指し、絶賛採用を強化中です。（※人数は正社員のみ。業務委託は除く）
ただし今後、複数人で開発を始めるようになると、開発対象の理解度やスキルレベルの差によって開発効率が変わってしまうことが想定されます。
そこで、ホワイトプラスでは、チームで開発をなめらかに出来るようにするため、試行錯誤をしながらスキル・ナレッジトランスファーに取り組んでいます。
今回は、主にネット宅配クリーニング「リネット」に関わるエンジニアのスキル・ナレッジトランスファーをどのように取り組んでいるかについて紹介します。
そもそも、ホワイトプラスではどんなものを開発しているの？
リネットでは、クリーニングのお申し込み〜クリーニングされたお洋服のお届けまでの一連のフローを全て内製で開発しています。
一連のフローのなかで「認証・認可、決済、顧客管理、受注管理、在庫管理、商品管理」など一般的なECに求められる機能に加えて、「物流連携、提携工場の業務支援、会計連携」など、受注から納品、売上の計上まで一気通貫でサービスを支える機能開発を自社で行っています。
特に外部連携機能である、物流連携や会計連携、提携工場の業務支援機能は、必要とされる知識が多岐に渡り、且つ深いため、ナレッジトランスファーに苦労する部分でもあります。
スキル・ナレッジトランスファーの積極的な取り組みを始めた背景は？
2020年以降、リネット事業のさらなる成長に向けてエンジニア職の採用強化が進み、チームメンバーが確実に増えることが見えており、適切なトランスファーをするための指針や、トランスする／される側の相互で、何をトランスするのかを明示していく必要性が高くなりました。
これまでは、
・必要なドメイン知識を持っているエンジニアがアサインされる。
もしくは、
・プロジェクトに応じて必要なドメイン知識を適時移していく。
といった具合で、積極的にトランスファーを展開している状況ではありませんでした。
もちろん、トランスファーに対してチームがネガティブだったわけではなく、以前まではチームメンバーが急激に増えない採用計画だったため、積極的にトランスファーが行われる力学が発生しづらかったことが大きな理由かなと思います。
エンジニアのスキル・ナレッジトランスファーをなめらかにするための取組み
積極的なトランスファーを行っていく前に、解決すべき問題の整理をエンジニアチームのマネジャーと行い、以下の設定でスタートしました。
背景
1. 新しいチームメンバーが大きく増え計画的（目標設定に組み込めるとGood）なトランスファーの必要性が高まる
2. 現チームメンバー間でも、誰がどんなナレッジをどの程度保有しているのか不透明である（特に社歴が浅いチームメンバーほど分からない）
目的
新しいチームメンバーへトランスファーすべきスキル・ナレッジを整理する
ゴール
目標設定に組み込める粒度でトランスすべきスキル・ナレッジの列挙を行い、列挙されたスキル・ナレッジに対して現チームメンバーの理解度をプロットし、まず現メンバー間で目標設定に活かせる状態とする
こうして、DDDの文脈におけるドメイン単位でナレッジの整理を進め、網羅的にすべてのナレッジを明示したかったため、トランスファーの必要性が低い（改修可能性が極めて低い）ナレッジも取り入れていった結果、誕生したのが200行弱にも及ぶスキルマップです。
それぞれのスキル・ナレッジ定義には、マスター/リード/メンバー/ビギナーという呼称で、4段階の習熟度が設定されています。
そして現状では、評価期間中に担当予定のPJに紐づくスキル・ナレッジの獲得を目標設定にしていますが、将来的にはもう少しプロアクティブにしていく予定です。
例えば、
リード以上の習熟度のエンジニアが、メンバー以下のエンジニアにナレッジ・スキルトランスファーを行う。また、トランスファーを受ける側は獲得する。
という形で、相互に目標設定をして活用出来るようにしていきたいと考えています。
スキルマップを作成したことで、今までなんとなく思っていたスキル・ナレッジの境界線が明示化され、現チームメンバー間でも共通認識を持てる状態になったことは大きな一歩と感じています。
今後、チームの人数が増えたとしても、なめらかに開発し続けられるようにチーム皆で活用し、フィードバックを踏まえながら、このスキルマップを成長させていこうと思います。また、スキルマップを活用した結果、エンジニアにどのような変化が生まれたのかなどについても、もし機会があれば、どこかでご紹介できればと思います。
もっと踏み込んで話を聞いてみたい等あれば、ぜひ面談にお越しください。お会いできることを楽しみにしています。
