_・)Keep Smiling

モソモソと日々の雑感を書き溜めるというか書き殴るというか書き捨てるというか

_・)チームの中で必要そうな役割を想像してみる遊戯

こちらはPlatform Engineering Advent Calendar 2024の1日目の記事です。

2024年は、Platform Engineering Kaigiも実施され、日本においてもPlatform Engineeringが大きな盛り上がりを見せた1年となりました。 Platform Engineering Meetupも通常開催に加え、OnlineのMeetupも3回開催され、色々なテーマでのセッションが開かれたなぁと個人的にも感じます。

Backstage特集や、小規模な組織から始めるPlatform Engineering、JTCでの取り組みなど、いろんな話があったなぁと思う中で、やはり個人的にはマニュエル・パイス氏のトレーニングを受けたこともあって「Team Topologies(ちーとぽ)」が特に印象に残っています。

ちーとぽの話も色々な文脈で語られてきましたが、ここではPFEM #9での北村 慎太郎氏によるチームトポロジーに見るKubernetes × Platform Engineeringの目指す姿にちょっと注目したいと思います。

北村さんでの資料では、ちーとぽがどんなものであるかを解説しつつ、組織が成熟してくるとどのようにチームが変化していくのかを説明しています。さらに、最後のページではプラットフォームチームがスケールしていった結果、プラットフォームチームの中に「ストリームアラインドチーム」や「イネイブリングチーム」など、ちーとぽに出てくる各チームが入れ子構造として存在することになるだろうという点にまで言及しています。

speakerdeck.com

私もこの意見には大きく賛成で、チーム自体をスケールしていく中で、他のメンバーを補助していく役割の人材や、そのメンバーに対しての対話方法(インタラクションモード)なども整理しながら成熟させていく必要があるだろうなーって感じます。

さて、ここからが本題なのですが、この話は果たして、チームがスケールして大きくなっていく時だけの話でしょうか?

私は、逆にチームがまだできたてで少人数のときでも、同じようなことが言えるのではないかなぁと感じました。
まぁ、少人数の時は信頼関係も築きやすいですし、少人数ゆえに手間(負荷)も小さいのであまり気にならないのかもしれないですが、それでも役割としては重要なのではないかと思うので、ここでちょっと整理してみます。

ここでは、プラットフォームチームだけにこだわらず、汎用的なチームの形として妄想を繰り広げてみます。 少人数なチームってことを前提とするのでチーム単位では無くRole単位として考えてみます。

とりあえず、営業チームを例に考えてみましょう。

  • ストリームアラインドRole

    そのチームが本来実行すべき職務を一貫して一通り実行する役割。
    営業チームだったら、顧客発掘から、実際に注文をとって売り上げを稼いで、社内売り上げ処理を行って、実際に納品するチームに引き継ぐまで・・・とかですかね? 実際のちーとぽでのストリームアラインドチームでは、開発しているアプリ/サービスを引き継がないで全ての責任を持って業務を進めていくのですが、今回は営業チームで考えているので、ちょっと改変です。

  • イネイブリングRole

    ストリームアラインドRoleの人材が100%の能力を発揮してお仕事を進められるように、サポートする役割。
    OJTトレーナーなんかがこの役割に近いですかね?一般的な営業のお仕事の進め方を教えるだけではなく、後述するプラットフォームRoleの人が用意した営業ツール群の使い方とかも教えたりするでしょう。

  • コンプリケイテッドサブシステムRole

    一般メンバーでは捌くのが難しい状況を取り扱う役割。
    複雑な社内規定や法規制、その他、難しい判断を伴うような重大なトラブルを扱う・・・上司?リーダー?なんかが当てはまりそうです。
    頼れる上司や先輩って感じですかね。もしくは、会計処理や事務手続きなどのプロフェッショナルな人がこのRoleかも知れません。

  • プラットフォームRole

    そのチームが扱うべきツール群を整え提供する役割。
    営業チームの場合は、コミュニケーションツール(Slackとか)や、顧客管理システム、売上管理システムとかでしょうか。
    そういうツールが、どんな人にも使い易くなるように整備していくようなRoleかなーと思いますが、これは実際の組織だと営業チームとは別のチームになりそうですね。

と、基本の4チーム(4 Role)について妄想してみましたが、どうでしょうか、それぞれの役割はやはり効率の良く結果を生み出すチームにとっては必要なんじゃないかなと感じます。

大切なのは、それぞれのRoleが本当に必要なのであれば、今のチームにこれらの役割が不足していないか(たとえば、上司が責任とらないとか!)、また誰かが辞めたときにRoleがいきなり不在にならないか等を考えていくことは意味のあるようなことのような気もします。

特に小規模なチームの場合、これらの役割は特定の人材に集中(重複)してしまうことが多くなるかもしれませんが、バックアップも含め、複数のメンバーにうまいことRoleを分散させていくことも大切になるのではないでしょうか。

ゆくゆくは組織は大きくなっていきます。その時に慌ててチームをバタバタと立ち上げなくても良いように、どのようなチーム/役割が将来必要になるのかを見据えながら成長の歩みを進めるのが良いように思います。

と・・・ここまで書いといて何ですが、これはPlatform Engineeringの記事なんでしょうか・・・。
まぁ、こまけぇことはいいんだよ。

明日は2日目です。こんな緩い記事のあとなら、きっと書きやすいでしょう・・・フフフ・・・。カレンダー見ると誰もアサイン無いけども・・・。