Webディレクター解体アドベントカレンダー3日目の記事です。今日はディレクターを取り巻く組織形態のバランスと、スキルマップを用いた横のつながりや知見の共有について書きます。
事業成長とディレクター育成の両立
Webサービスの開発を事業として行う会社の場合、組織形態として機能横断組織と機能別組織のどちらか、もしくはそれらを組み合わせたマトリックス型の組織になっていることが多いと思います。片方の軸がデザイナーやエンジニアなど複数の職種の人たちで構成された事業やプロダクトごとの組織（機能横断組織）、もう片方の軸が職種ごとの組織（機能別組織）になっているやつです。
機能横断型組織は複数の職種の多様なメンバーで構成されるため様々な知見が集まりやすく、新しいことに取り組んだり、サービスドメインの知識が深まることで事業を促進するスピードを出しやすいと言われています。一方機能別組織は特定の職種の専門家のみが集まるため、その分野の専門性を深めることに向いています。どちらにもメリットデメリットがあるため、多くの会社で両方の軸を取り入れたマトリックス型の組織になっていることが多いと思います。
縦軸と横軸のどちらが強いかは、会社や事業が直面しているステージによって変えていくのが良いとされています。立ち上げ時の不確定性の高いステージではスピードを優先して機能横断の方を強め、立ち上げから運用が安定してより効率的な運用が求められるようなステージでは知見の進化を優先して機能別の組織を強める。そのようにステージに応じて変化させやすいところにも、このマトリックス型組織のメリットがあります。
ただこのマトリックス型の組織、ディレクターの横断組織と相性が良くありません。エンジニアやデザイナーは事業の責任者とは異なる人が束ねることが多く、例えばCTOがエンジニアのトップだったり、チーフデザイナーがデザイン組織を束ねていたりします。一方、ディレクターやプロダクトマネージャーを束ねる機能別組織のトップはどういう人が務めているでしょうか。事業のトップが兼任していたり、そもそもいない場合もあります。
マトリックス型組織の場合、所属する組織が2つあって上長が2人いたりして、指揮系統が複雑になりやすいというデメリットがあります。ただ、エンジニアやデザイナーの横断組織の場合はそんなに混乱は起こりにくい。事業の責任者とは全く異なる視点で知見の共有や教育が行えるからです。だけどディレクターやプロダクトマネージャーの横断組織の場合、優れた人はすでに事業の責任者をやってるでしょうから、指揮系統が混乱しやすいんだと思います。そうなると、なかなか横のつながりや知見の共有が生まれにくい。だからと言って機能別組織にしたり、そっちの結びつきを強くすると事業を進めるスピードが落ちてしまう。困ったジレンマです。
スキルマップによるマッチング
ディレクター同士の横のつながりや知見の共有を、機能横断組織の中でどう進めていくのか。それにも、先日ご紹介したスキルツリーが一役買ってくれるのではないかと考えました。そして作ってみたのが、スキルツリーをスプレッドシートに移して、みんなで書き込んでいく形にしてみたスキルマップのテンプレートです。
https://docs.google.com/spreadsheets/d/166BXLSvl5lmhYRuy41GhMzy0ssO4Vuh0RDnNdh4NCD4/edit
紙に印刷しろとか言ってないで最初からこれを出せと怒られそうですが、ものには順番というものがあります。まず自分の担当領域を視覚的に把握してから、みんなとの相対化という順序で進むのがいいと思ったんです。許してください。
スキルマップに書き込んでいく習熟度には先日のスキルツリーと同じ4項目に、「⇑：習得希望、今後学びたいもの」と「--：担当範囲外のもの」を加え、以下の6つの選択肢から選んで項目ごとに記入していく形にしました。
- ◎：得意なもの、人に教えられるもの
- ◯：できるもの、普段からやっているもの
- △：苦手なもの、やったことはあるが不安なもの
- ×：できないもの、やったことがないもの
- ⇑：習得希望、今後学びたいもの
- --：担当範囲外のもの
スキルマップは一通り記入が終わると、作ったことで満足して「で？」ってなりがちです。作ったものがきちんとアップデートされ、管理され続けるにはそれ相応の存在価値が必要です。このスキルマップではまず、新しいスキルを身に付けたい人と自分の得意な特定のスキルを人に教えられる人とのマッチングを第一の用途に設計しました。
サービスの企画や分析を行なっているとき、ちょっとこのケース前に社内で他のチームがやってたなとか、このツールの使い方誰かにちょっと聞きたいなとか、そういうケースがないでしょうか。そんな時に機能別の組織があればその組織に対して質問をしたり、その組織の上長に相談しに行ったりすると思います。でもそんな組織がない場合、誰に相談に行ったら良いかわからない。そいういう時に役立てられればと考えました。
そういう「◯◯のやり方誰かにちょっと聞きたい」に対応するため、「◯◯」をより詳しく具体化するために、スキルツリーの末端に更に細かな小項目を設けました。例えば定量調査というスキルの中でも、Google Analyticsの使い方を誰かにちょっと聞きたいとか、特定業界のドメイン知識の中でもあの業界に詳しい人にちょっと話を聞いてみたいとか、より具体的にピンポイントで探せる方が便利だと思います。
この小項目は具体的であればあるほど良いです。テンプレートにある既存の項目に囚われず、自由に編集してください。スキルマップに記入してくれたメンバーにアンケートをとって、追加して欲しい項目を募っても良いと思います。スキルマップは上記のURLに雛形があるので、自分の手元にコピーして要望の多い項目を追加してみてください。そうして自分のチームや組織にあったスキルマップに育てていくと活用しやすいと思います。
注意すること
このスキルマップを機能別組織で使うときにはいくつか注意することがあります。1つ目は、記入するときの習熟度の基準です。
自らのスキル分布を把握して、今後伸ばしたいスキルがあるときに社内にいる詳しい人を把握できるようにすることを第一の目的にしています。だから習熟度の基準を厳正に揃える必要はなく、これについては人に教えられるなとか、これについては自信がないなとか、記入する人それぞれの主観に基づいて記入してもらうのが理想です。
だけど他のメンバーが横にずらっと並んでいると、この人に比べたら自分はできないから評価を下げようとか、このメンバーが並んでいるところに◎をつけるのはおこがましいとか、そういう遠慮が生まれてしまうことがあると思います。
そういう場合はグレードごとにシートを分けるか、みんなが横一列に並んだシートに記入してもらうのではなく、個人のスキルを記入するためのシートを別に作って、その入力値を参照する形に変えるのがいいと思います。これは個人用記入シートの例ですが、個人用だとこんな風に記入日の履歴を残して置けるのも成長の過程がわかって良いかと思います。
もう1つの注意点は、全ての項目をカバーすることを目的にしないことです。こうしてみんなのスキルが可視化されて並べられると、やっぱり全部の項目がきっちり埋まっている人がよく見えると思います。でも開発が高度になり、各スキルに専門性が求められる現代のWeb開発において、1人のディレクターが全てをカバーするのは無理があります。むしろ、専門性を深めることの阻害要因になりかねません。ジェネラリストもスペシャリストも共存できる組織が理想です。全てを埋めることが必ずしも良いわけではないということを記入するメンバーに周知徹底したり、これを評価のツールに使わないなど、運用前にルールを明確に定めておくと良いと思います。
