どうもこたにんです。
ポケットモンスター、縮めてポケモン。
1996年に、ゲームボーイで、ポケモン赤緑が発売されて20年以上が経ちました。
子ども当時、ゲームボーイでポケモンをたくさん遊んでいた世代。
その世代って今、ちょうど中堅くらいの年代になっている気がしています。
ことエンジニア界隈においては、マネージャー的な立ち回りをする方々はその世代。
ふと、ポケモンを思い返したときに思った。
もしかして、ポケモンからエンジニアリングについて学びを得られるかもしれない。
ポケモンじゃなくても良いんだけどね、何かを例に学ぶことはインプットの促進になるので。
ということで今回は、エンジニア・システム開発におけるチームの種類
- コンポーネントチーム
- フィーチャーチーム
の役割やあり方について、ポケモンを例にとって学びを得るための記事です。
ここからはポケモンを知っている遊んだことがある前提で話は進みます。
さらに言うと、初代赤緑くらいの頃を想起しながら書いていきます。
はい、目次どんっ！
今回学ぶチームのパターン
コンポーネントチーム
コンポーネントチームは、ある特定のサブシステム・モジュールの責任を負うチームである。
例えば、WEBアプリケーションのフロントエンドのような特定の技術領域。
そこでは、JS系のフレームワークや一部WEBアプリケーション向けの言語・ライブラリを扱う。
コンポーネントで組織することで、共通ロジックの集約、テストの共通化などで、保守性や品質の向上が見込める。
チーム全体として共通の技術・認識・領域を持つため、リファクタリングや新たなライブラリ導入など、技術的挑戦も容易に可能とする。
ただしコンポーネントチームは、領域外には干渉しないため、他のチームとの協業が発生するケースでは往々にしてコミュニケーションコストが発生することになる。
フィーチャーチーム
フィーチャーチームは、コンポーネントチームとは対照的に、機能単位で組織されるチームである。
ユーザーストーリーを満たす機能を十全に実装する責務を持つ。
機能を完成・改良させることを目的としたチームなので、扱う技術領域は特化されず、コンポーネントを跨ぐ。
ユーザーストーリーに対してアウトプットの責任を負うため、アジャイル開発で採用されやすい組織。
コミュニケーションコストの面ではかなり低く、開発に専念しやすい。
複数の技術領域を抱えるため、チームとしてのアウトプットという意識を持てないと、作業の専任化が促進されてしまう場合がある。
これら2種類のチーム構成を、ポケモンに照らして学んでいきましょう。
ジムリーダーを倒すためにはコンポーネントチーム
コンポーネントチームをポケモンであてはめると、ジムリーダーを倒すために組織されたタイプ別チーム。
ジムリーダーはひとつのタイプに特化しているため、チームも自ずとある領域に特化する必要があります。
ではちょっくら、グレンジムのカツラさんを倒そうと思います。
カツラさんのパーティー構成はこちら。
炎タイプで固めています、ウィンディをモフモフしたい。
これに立ち向かうためには、水タイプのコンポーネントチームを作る必要がありますね。
ということでこのようなメンバー構成のチームを作ってみました。
純粋に水タイプとして職務を全うしているメンバーもいれば、付け焼き刃で水タイプの技を仕込まれただけのメンバーもいます。
コンポーネントチームとは、ある責務を全うするために組織されるチームです。
その中で必要なことがいくつかあります。
- スキルセットの平準化が可能であること
- コンポーネントを統べる役割が存在すること
- 学びの手段があること
スキルセットの平準化が可能であること
このチームは全員、なみのりが使えます。
なみのりというスキルが平準化されており、代替可能というわけです。
同じスキルが必要なときに代えが利くことは、コンポーネントチームとして大事。
さらに言うと、スキルが明確であるため、新規メンバーの参入障壁が低くなります。
「なみのりが覚えられること」って明確だし、覚えさせる手段もあるし。
コンポーネントを統べる役割が存在すること
コンポーネントチームでは、ロジックの共通化や実装の判断を求められます。
ある技術の責務を担うので、技術選定やアーキテクチャ設計などもチームに閉じることが多い。
そのためには、チーム内で決定をすることができる強いメンバーが必要。
そのため、万が一の頼みの綱、カメックスのような強い役割のメンバーが大事。
学びの手段があること
炎タイプを倒すために組織した水タイプ技のチームですが、実はそれだけでないのがこのチーム。
サイドンは地面タイプです、炎を倒すには地面でもいいのです。
このように、新たなライブラリ・スキルを用いてコンポーネントを高めていく学びが必要。
コンポーネントチームのデメリットとしては、ひとつの領域に閉じている点から発生します。
他システムとのコミュニケーションコストの増加が一番多いデメリットです。
カツラさんを倒すチーム、ナツメさんを倒すチーム、エリカさんを倒すチーム。
それぞれのチームの取組やスキル、倒し方の共有はなかなか簡単ではなさそうです。
しかもチーム間の移動も簡単ではなさそうですね。
四天王を倒すためにはフィーチャーチーム
フィーチャーチームをポケモンにあてはめると、四天王を倒すためのチーム。
四天王を倒してチャンピオンになるというゴールの達成のためのチーム。
（四天王の後にはチャンピオンもいるけど、今回は割愛します）
そのためには、タイプの異なる相手を1つのチームで倒し続ける必要があります。
四天王のポケモンたちを見てみましょう。
ひゃー壮観、そして懐かしみのすごい構成。
そしてタイプ構成が様々なので、全てに十分に太刀打ちするチーム構成が必要。
メンバーの個性だけではなくスキルまで考えてこういう構成のチームを作りました。
どの相手でも対処できるような構成です。
四天王までにハクリューをカイリューまで育てるの間に合わないのあるある。
フィーチャーチームで求められるのはストーリーの達成、ここでいうと四天王の撃破。
チャンピオンになるために、氷・格闘・ゴースト・ドラゴンの4タイプを倒さなければいけない。
ジムリーダーを倒すための1タイプに特化したチームでは太刀打ちできません。
それぞれのタイプを補助しながら倒す、そんなチーム構成である必要があります。
フィーチャーチームに必要なことを3つ挙げるとしたらこれです。
- ストーリー達成における課題の潰しが利くこと
- コミュニケーションコストが低いこと
- スキルマップが明示化され自走すること
ストーリー達成における課題の潰しが利くこと
チャンピオンになるには、複数のタイプを同じチームで倒す必要があります。
カンナさんには、サンダースとハクリューをぶつける。
シバさんには、フリーザー・ダグドリオ・カメックスで落ち着いて対処。
キクコさんには、ラッキーで止めつつダグトリオ・カメックスで押し込む。
ワタルさんには、フリーザーの4倍とハクリューで倒し抜く。
このように、それぞれの得意領域を持ち、相互で潰しが利くこと。
これがフィーチャーチームが能力を最大限に発揮するための要素です。
コミュニケーションコストが低いこと
コンポーネントチームとは違い、チーム内で完結させるのがフィーチャーチーム。
そのため、チーム内でのコミュニケーションコストは低くある必要があります。
イワークはカメックスで倒しておいて、サワムラー出てきたらフリーザーで倒すみたいな。
スキルマップが明示化され自走すること
コンポーネントチームでも大事になるのだけど、フィーチャーチームで重要なのがこれ。
ゴールが明確なこともあり、チーム内で自走する力が問われます。
幅広いスキルマップを明示化し、不足を補えるフローや体制を作っていく必要があります。
実はこのチームにはエスパータイプの技を持っていないから、持ってたほうが良いかもねとか。
スキルマップを明示化すると、このフィーチャーチームを複数作ることも容易になります。
同じようなスキルマップを持つチームを複数作ることがフィーチャーチーム最大の効果をもたらしますからね。
デメリットとしては、スキルマップに偏りが強くなってきて専任化すること。
なかなかフリーザーの代わりが務まるメンバーは難しいですね。
ジュゴンをひたすら育て上げるか、プテラかギャラドスにするか、とか。
それもまずはスキルマップを完成させる必要があります。
このスキルマップづくりがフィーチャーチームを作る上でとても大事だったりする。
まとめ
ポケモンというひとつのゲームから、今回はチームのかたちを学びました。
コンポーネントチームとフィーチャーチーム、それぞれの役割がわかりましたかね。
実際のチームとなったときは、現実的に扱っている技術やシステムだけでなく、社内の人間関係や経験値なども加味した上で、これらのチームが組織されます。
もっと言うと、全社的に組織的にどのようなかたちだと、会社のバリューに貢献できるのか、によっても取りうるチーム体系は変わってくるものです。
何か少しでも、学んでもらえればなによりです！
個人的に書いててとても楽しかったので、これシリーズ化します！
リーダーシップ、フルスタックエンジニア、メンタリング、リクルーティング
あたりをネタにできそうだ。
