LINEを支えるプロジェクトマネジメント＆アジャイルの専門家組織「Effective Team and Delivery室」の取り組みと戦略

LINEの全社横断組織の仕事

横道稔氏：みなさんこんにちは。ご来場いただきありがとうございます。それでは、私から「Project Management & Agile全社横断組織の戦略と事例」というタイトルにて発表させていただきます。よろしくお願いします。

では、最初に私の自己紹介をさせてください。

はじめまして、横道と申します。よろしくお願いします。Effective Team and Delivery室という部門で室長をしております。

私のバックグラウンドも紹介させていただきたいのですが、私はエンジニアからキャリアをスタートして、エンジニアリングマネージャーやプロダクトマネージャー、プロジェクトマネージャー、スクラムマスター、アジャイルコーチなど、さまざまなロールを経験してきました。

そして、社外活動の一環として、「プロダクトマネージャーカンファレンス」や「Regional Scrum Gathering Tokyo」「Agile Leadership Summit」や「Scrum Masters Night!」といった、アジャイル系を中心とした社外でのカンファレンスのオーガナイザーもやっております。

こういったバックグラウンドを持っているなかで、現在は全社的にプロジェクトマネジメントとアジャイルコーチングを提供する全社組織の部門のリードを行っています。

さて、本題なんですけれども、今日はこういったアジェンダでお話をさせていただければと思います。

まず最初に、どんな目的や戦略で全社組織を運営しているのか。2つ目が、その戦略の中での実際の事例についてお話しします。最後に、その全社組織を実際どのように運営しているのかという話もできればと思います。

CTO室直下の2つのチーム

最初に目的とストラテジーの話をさせていただきます。まずは組織図を見ていただきたいのですが、このようになっています。

先ほど申し上げたEffective Team and Delivery室はCTOの直下にあります。その下に2つのチームがぶら下がっているようなかたちとなっています。

それぞれ説明をしていくのですが、まずこのEffective Team and Delivery室はなかなか覚えにくい名前だと思います。こう名づけた思いとしては、デリバリープロセスやチームをより効果的にしていくことをミッションにする意味でつけた名前になっています。

ここにぶら下がる組織なのですが、1つはDelivery Management Teamというチームがあります。こちらはTechnical Project Managerで構成されています。全社的なプロジェクトマネージャーの組織というと、みなさまはPMOのような存在を想像されるんじゃないかなと思います。

私たちはDelivery Management TeamをDMTと呼んでいるのですが、そこに所属しているTechnical Project Managerはどういう考え方なのかをご紹介しようと思います。

ちなみにTechnical Project Managerの「Technical」は「テクニカルなバックグラウンドを持つ」というような意味合いなので、このセッションでは単純にプロジェクトマネージャーと捉えて聞いていただいても問題ありません。TPMと略したりすることがあります。

まず1つ目に、すごく極端に言うと、私たちはプロジェクトマネージャーはいらないんじゃないかと考えています。ただ一方で、プロダクトをしっかりデリバリーするためには「プロジェクトマネジメント」という行為自体は非常に大事だと考えています。

ですので、私たちTPMは、チームやプロジェクトに対してプロジェクトマネジメントという行為をインストールするという役割を担っていると考えています。

プロジェクトにおける3つの要素

わかりにくかったかもしれないので少し補足をしていくと、例えば仮にプロダクト開発における主要なコンポーネントにこの3つに置いたとします。

マーケットを調査したり、機会を発見してプロダクトを定義して、UXデザインなどをしてプロダクトを定義する「プロダクトマネジメント」。スコープやスケジュール、リスク、コミュニケーションをマネジメントする「プロジェクトマネジメント」。そして、実際のソフトウェアを作って品質を保証しながら、ちゃんとデリバリーする「開発」という部分があると置いたとします。

単純に考えると、それぞれのこの3つの要素についてそれぞれ専用のロールを作って遂行していくという考え方があると思います。

つまり、プロダクトマネジメントという行為をプロダクトマネージャーが行って、プロジェクトマネジメントという行為をプロジェクトマネージャーが行って、ディベロップメントとをエンジニアやQAが行うということですね。

場合によっては、プロダクトマネージャーがプロジェクトマネジメントの要素も担っているケースも有るのではないかと思います。例えばスコープの管理などをやっているケースもあるのではないでしょうか。

もちろん、プロジェクトの中にプロジェクトマネージャーが存在していなくて、それをプロダクトマネージャーがすべて担っているケースもあると思います。

逆に開発の担当エンジニアやQAが、プロジェクトマネジメントの要素を担保することも一般的にあるケースだと思います。

さらには、プロダクトマネージャー・プロジェクトマネージャー・エンジニア・QAに関係なく、プロジェクトをちゃんと成功裏にデリバリーするための仕事をチームのメンバー全員でやっているようなケースもあると思います。

なので、今示したように、それぞれ必要な仕事の要素があるものを、必ずしも誰か専任の人を置いてやっていく必要はないと考えています。とくに、自己組織化といいますが、自律的に動くチームであれば、プロジェクトマネジメントの要素はよりチームの中に溶けているような状態になります。なので、私たちは可能なかぎりこのような状態を目指せるように動いています。

現場に入って問題発見・解決をサポートする

ただ、もちろんこういった考え方は、言うのはすごく簡単ですが、プロジェクトマネジメントやアジャイルの知識が不足していれば、単純にプロジェクトマネジメントという行為が行われない、カオスな状態になると思います。

ですので、そのためにも私たちTPMは、実際に現場に入って問題発見・問題解決から一緒にやっています。なので、私たちはプロジェクトマネジメント、アジャイルの専門家として、そこをサポートするような働き方がメインになっています。

もちろん、複雑で大きなプロジェクトやプロダクトの場合では、短期的にTPMが直接的にプロジェクトマネジメントを担うケースもあります。デリバリーを成功裏に終わらせるために必要であれば、そういったこともしています。ただ、そういった場合でも、ずっとプロジェクトマネージャーに依存されてしまう関係性ではなく、プロジェクトマネージャー自分自身が自分自身を必要としなくなるように働きかけをやっています。

プロジェクトマネージャーがプロジェクトマネージャーの仕事をなくすということは、一見自己矛盾のように感じるかもしれませんが、リーンな考え方、無駄がないような考え方をすると、プロジェクトマネージャーは直接的にはプロダクトに価値を提供しているわけではない役割だと思っています。

ですので、より価値を付与できる仕事に集中できることが重要だと思っています。会社の多くの人間がプロジェクトマネージャーになっていくよりは、それがいろいろな人で補完されていく状態を目指しています。

ちょっと余談になりますが、より先ほどの図を広げていくと、それぞれのロールが自分たちの責任を果たしながらも、プロジェクトマネジメント以外のそれ以上のところにも踏み出していくことはすごくいいことだと思っています。こういったところにも働きかけられるように振る舞っています。

アジャイルを押し付けるのではなく、現状をより良くするために活用

次はもう1つのLean & Agile Teamを紹介します。

このチームはスクラムマスターやアジャイルコーチが所属している組織になります。

LINEにおけるアジャイルコーチなんですが、こちらもどんな考え方かというと、私たちはアジャイルの方法論にこだわるようなことは決してしません。一方で、アジャイルの価値観や原則を非常に大事にしています。

この中で「アジャイルソフトウェア開発宣言（Agile Manifesto）」を読んだことのある方もいらっしゃるかもしれませんが、個人との対話や動くソフトウェア、コラボレーション、変化への対応などを価値基準としています。

なので、私たちは支援したチームに対して「アジャイルでやりましょう」とか「スクラムをやりましょう」と言ったり、「いや、そんなのはアジャイルじゃないのでダメです」とか、そう言うことは絶対にありません。あくまでも現状の問題を解決するため、現状をより良くするためにアジャイルの考え方やプラクティスを活用するようにしています。

2つのチームの共通点と違うところ

ここまで簡単に2つのチームを説明してきましたが、これら2つのチームに違いがあるように感じられたでしょうか？　この2つのチームが共通に持つ信念は「より良いプロダクトをデリバリーするために、チームとデリバリープロセスの面で問題を解決することをサポートする」ということです。

逆にこの2つのチームの違いは、単純に所属しているメンバーの専門性の違いでしかないとしています。プロジェクトマネジメントに専門性・バックグラウンドを持つか、アジャイルに専門性・バックグラウンドを持つかというところですね。もちろんこのチーム2つはコラボレーティブに働いています。

全社組織として私たちがやらないこと・やることを説明すると、やらないことはなにかしらプロセスを良い悪いと判断して、権威的な判子を押すような承認機構は一切やりません。また、プロセスや文書を標準化してそれを使うことを強いるようなこともしていません。

正直に言うと、こういった標準化は従業員のクリエイティビティ、創造力を減らして改善マインドを減らしていくようなものだと思っています。さらには、なにか上の人だけが喜ぶような、つまらないレポートを作るような仕事もしてません。

では、逆に何をしているかというと、これは先ほどお伝えしたとおり、実際にプロジェクトやチームが問題解決するところを専門家として助けています。

2つ目は、トレーニングやツールキット、ガイドを提供して、「こういったいいものがあるので、もし自分のコンテキストに合うようであれば使ってください」とか「まずこれから使って始めてみましょう」みたいなことをやるのが2つ目です。

そして3つ目が、社内にお互いに学び合うようなコミュニティを作って、それを促進していくということをやっています。

アジャイルをやるのではなく、アジャイルであることを意識する

ここまでのキーポイントをまとめると、プロジェクトマネージャーではなくてプロジェクトマネジメントに着目していることと、アジャイルに関しても、アジャイルをやるのではなくてアジャイルになる、アジャイルであることを意識しています。そして、なにかしら強制して無理やりやらせるよりは、サポートして彼らをenablingする。もともと持つ能力を引き上げるということをやっています。

先ほどやると言ったことは、全社組織の中の仕事のカテゴリとして3つの主要なカテゴリとして定義しています。

これらをもう少し詳しく説明しますと、1つ目はトレーニングやガイド、ツールキットを提供しています。やはり全社組織ですので、広くアジャイルやプロジェクトマネジメントに関するスキルのベースラインを引き上げるためにやっています。

定期的に全社を対象にしたトレーニングイベントを開催したり、プロジェクトやチームの課題に応じて内容をカスタマイズして、今必要なものを提供するトレーニングをやっています。これに関しては、なにかしらプロジェクトマネジメントに関わっている人のためではなく、チーム全員、プロジェクトメンバー全員を対象に提供しています。

そして、2つ目が問題解決のサポートです。こちらに関しては、先ほどから申し上げているとおり、現場に入って一緒に問題解決のためのサポートをします。

これを繰り返していくことによって、さまざまなコンテキストの中で「こういうことをやったらうまくいった」「こういうことはうまくいかなかった」という事例が集まってきます。なので、そういったものを組織に蓄積していくことにもつながっています。

では、一般的にどういったフローでやっているかというと、リクエストを現場からいただき、まずはキーマンであるマネージャーやメンバーとの対話からはじめます。このタイミングでサーベイを取ることもあります。それによって問題を見える化していき、それに対するアクションを実験的にやる。それを繰り返しています。

ここに関しても、「私たちが入ったらこんな標準的なものを提供します」「こういったソリューションを適用します」ということをやっているわけではなく、私たちのチームに所属するメンバーの強みやバックグラウンド・経験を勘案しながら、最も価値を提供できるソリューションをニーズとかけあわせて提供しています。

3つ目にお互いに学び合うコミュニティを構築するところですが、これに関しては、先ほどのチームでできた事例を社内で横に広げていくために必要不可欠になっています。我々がすべてのチームに入って問題解決を支援するわけにはいきませんので、相互作用で問題が解決されていくというかたちを目指しています。

今の話をイメージにするとこうなります。