CNDT2020シリーズ：プロジェクトからプロダクトへ。強いチームを作るコツをVMwareのアーキテクトが語る

CloudNative Days Tokyo 2020のセッションの中から、クラウドネイティブなシステムに欠かせない持続するチーム作りのコツ、そしてプロジェクトベースの発想からプロダクトを作る発想に転換するためのコツを語ったVMwareのアーキテクト草間一人氏のセッションを紹介する。タイトルは「世界に誇れるPlatform Teamを作る」というもので、コンテンツ作りにおいてサイバーエージェントの青山真也氏、LINEの西脇雄基氏へのインタビューを行ったという。

参考リンク：世界に誇れるプラットフォームチームをつくる

VMwareのアーキテクト草間一人氏

冒頭は失敗したプロジェクトとして、「プラットフォームエンジニアが、上司の指示に従って社内で使えるKubernetesを使ったクラウドネイティブなプラットフォームを開発する」の例を紹介した。このプラットフォームは、アプリケーション開発の生産性向上を目指して開発されたものだが、思うようにいかずに失敗するという内容だった。

社内のプラットフォームをクラウドネイティブにしようとしたが……

この例では、KubernetesだけではなくCI/CD、トレーシングなどの多くのコンポーネントを用意して開発に望んだものの、現場は必要としていなかった、外注化されている開発、Kubernetesの高い学習コストなどに加えて、エンジニアの離脱や兼任による生産性の低下などもあったという。その結果、「Kubernetesは使えない」という認識だけが残るという悲惨な最期を迎えたという例え話だった。いかにもどこかのプロジェクトで聞いたことのある内容となった。

新しいソフトウェアを使ったプロジェクトの失敗例

草間氏は、このような結果を防ぐために一番大事なのは担当者を専任にすることや上司の理解を得ることなど以上に「プロジェクトではなく『プロダクト』として開発するプロダクトマインドセット」が必要だと強調した。

プラットフォームをプロダクトとして開発する

そしてここからProduct Teamの解説、Lean Product Management、User Centered Design、Extreme Programming、Site Reliability Engineering、Balanced Teamなどのキーワードを使って解説を行った。

英語キーワードのオンパレード

最初に解説したのは、Platform Teamを作るという部分だ。これは前段の失敗例で「兼任のエンジニア」が多かったという部分への改善ポイントだろう。専任のプロダクトマネージャー、専任のエンジニアを置くことが必須であること、そしてそのチームを支援してくれるProduct Championを任命することが必要と説く。この中でプロダクトマネージャーは「何をすべきか」を定義する人として紹介され、Dreamer、Alchemist、Influencerなどのタイプが例として挙げられている。これらのタイプが英単語で表現されているのは、この辺りの役職／役割が日本では馴染みがないことの表れだろう。

プロダクトマネージャーとは

そしていかなる時でも兼任はNGであると強調し、プロダクトマネージャーと開発を行うエンジニアは専任を置くことが必要であると解説した。また「人の稼働は算数できません」という一文からも人月という発想ではダメらしいということが窺い知れる。

兼任はNG、必ず専任の人を用意すべき

またPlatform Championについては「CxOレベルの人、社内起業や組織変革の実績がある人、プラットフォームの価値を理解し、明確にし、社内に伝えられる人」と定義し、チームを牽引する人、組織の人事を決定できる人を味方に付ける必要があると説明した。

Platform Championとは

またプロダクトマネージャーがいないのはどこの組織でも同じなので、プロダクトマインドセットを持ったエンジニアがやることも有り得ると解説した。

そしてチームとしてビジョンを定め、やること（Goal）とやらないこと（Anti-Goal）を決めることが重要だとして、評価のためにOKR（Objectives and Key Results）を導入することも選択肢として検討すべきと説明した。

チームにおける大事なことはやることとやらないことを決めること

そしてユーザーを理解するためにはインタビューを行ったり、ユーザーストーリーやペルソナを作ってチームとして共有したりすることが重要だと解説した。

何が欲しいかではなく何に困っているかをインタビューするべき

他にもValue Stream MappingやMVP（Minimum Viable Product）を作って少しずつユーザーに使ってもらうアプローチを紹介した。ここで興味深いのは、クラウドネイティブなシステムにおいては常に新しいプロダクトが登場してくるが、欲張ってすべてを入れようとせずに必要最低限のソフトウェアから始めるべきという点だ。冒頭で紹介した、欲張ってさまざまなコンポーネントを使って開発を行ったプロジェクトの失敗を振り返る記述がある点も興味深い。

MVPで使えるモノをユーザーに提供するやり方

そしてExtreme Programming（XP）の手法を、ソフトウェア開発だけではなくプロダクトチームの活動にも取り入れて実施するべきと解説した。ここでもXPの価値がSimplicity/Communication/Feedback/Respect/Courageという英単語で表記されており、未だに日本語での分かりやすい解説がなされないのはXP自体がまだ日本では十分に馴染んでいないことの表れと言えるだろう。

XPの概要

最後にソフトウェア開発期間だけではなく持続する製品作りという観点から「次世代○○プロジェクト」などの抽象的な名称は止め、プラットフォームであってもプロダクトとしての命名を行うべきと語った。

プロダクトを命名することの意義を強調

また開発から利用を拡げていくためには、開発チームだけではなくそれを拡大するための仕組み、ここではEnablementが必要であるとして、ドキュメント作り、ワークショップ開催、ヘルプデスクなどの周辺業務についても言及し、プロダクトとして利用してもらうための組織作りが重要だと解説した。

Enablementのための努力も必要

同時にEnablementを考えるとチーム自体が拡大していくことを想定し、チームの人数を2枚のピザが分け合えるような人数、具体的には5名～9名程度に抑えることが重要と解説し、チームを責任ごとに分解していくことを提案した。

チームはピザ2枚を分け合える人数がベスト

ここからはチームの構成に関して「Team Topologies」というサイトのコンテンツを使って解説した。

参考：Team Topologies

Team Topologiesを使ってチーム構成を解説

ここではPlatform Team、Stream-aligned Team、Enabling Team、Complicated Subsystem Teamという4つに分け、それぞれが責任範囲を明確にして協力／分担してプロダクト開発に望むやり方を解説した。

Team Topologiesの分担の一例

草間氏は、プラットフォームをプロジェクトとしてではなくプロダクトと捉えて開発すべきということを強調してセッションを終えた。プロジェクトではなくプロダクトとして開発すること、専任を置くこと、名前を決めることなど、具体的な内容が示された点は視聴者にとっても価値のあるものだったと言える。

一方で、後半のTeam Topologies辺りではまだ英語での解説となってしまう点は、海外のセオリーをそのまま持ってきた感があり残念に感じた。例えばProduct Champion、Enabling Team、Stream-aligned Teamといったキーワードを具体的に日本での組織に照らし合わせて用語にできれば、自社の組織との対照で理解が進んだのではないだろうか。

組織変革が必要なイノベーションに関わる部分は、コンセプト優先で実態との乖離が目立つことが多い。これはDevOpsなどでも同様だ。組織に関わる変革を語る際には、ぜひ日本語で解説をお願いしたいところだ。