LINE NEWSにおける改善事例
横道稔氏：では、ここからは実際の事例をお話しします。「LINE NEWS」というニュースサービスの中での事例になります。
このLINE NEWSは、私たちが支援に入ったタイミングではこのようなイメージになっていました。
全体で100名ほどの組織です。これはイメージ図で、細かな構造や人数は実際と大きく異なっていますので、そこはご留意ください。
画面の左側がビジネスやプロダクト企画を担当する事業部で、シニアマネージャーから、マネージャー、メンバーという階層構造で仕事が行われていました。右側がプロダクトを開発する組織です。いわゆる職能別の組織で、フロントエンド・サーバサイド・QAというチームがあり、それぞれにマネージャーやリーダーがいて、各メンバーに仕事を都度アサインしていくスタイルをとっていました。
こういった中で主要な問題は何だったかというと、プロダクトのデリバリーのプロセス全体のリードタイムを見たときに、徐々に下がってきていることでした。昔はスタートアップのようにやっていましたが、そのリードタイムが徐々に下がってきているという課題感がありました。
もう1つは、組織の人数が増えていく中で、マネージャーやリーダーがボトルネックになりやすく、メンバーがそこに依存してしまう構造になりつつありました。大きな組織になると抱えやすい問題かと思います。
自己組織化された小さなチームの集合で組織を作る
この問題解決に対してどういったところを目標に置いていくかです。
1つ目は、課題にマッピングされますが、プロダクトや組織におけるリードタイムですね。『リーンソフトウエア開発』の中で出てくる言葉ですが、なにかコンセプトが生まれてからそれがキャッシュになるまでのリードタイムを短くするということです。
2つ目が、先ほどのマネージャー依存が強くなってしまう件ですが、できるだけ組織のスケールアップに耐え、変化に対応できるような構造を作ろうと考えました。
では、これに対して私たちはどんな実験をしているか？ 現在進行系なんですが、それをシンプルに要約すると、「組織を機能横断的なチームの集合にして、そのチームに権限を移譲していく」という非常にシンプルな考え方を採用しました。いわゆるself-organizedされた、自己組織化された小さなチームの集合で組織を成り立たせるというものですね。
これによって意思決定も早くなりますしコミュニケーションのギャップも少なくなるので、リードタイムを短くできる。そして、マネージャーやリーダーに対する依存も減ってくるのではと考えて、この実験を行いました。
開発のリードタイムを短くするためにやったこと
ここからはこれまでの道のりこれからについて、最初に流れを説明します。
まず最初にやった実験は、図の右下です。
まずは開発側に機能横断型の小さなチームをつくりました。フロントエンド・サーバサイド・QAからそれぞれメンバーが来て、ビジネス・企画プロダクトオーナーをアサインし、もともとあるチームのマネージャーだった方がスクラムマスターのような振る舞いをするという1つのチームをつくりました。
幸いにこれが非常に成功裏に終わったので、次はそれをスケールアウトさせることにしました。
このタイミングでマネージャーがアサインするという従来の構造はなくなって、マネージャーはどちらかというとサーヴァントリーダーのように振る舞い、チームの成長を促している状態になりました。
次がまさしく今の状態なのですが、今度は開発側ではなくビジネス企画側の組織に関しても同様に、小さなチームを作ってそこに権限移譲して回すというチームを、いくつかのチームをつくって始めています。
そちらもうまくいく兆しがあるので、おそらく次の段階としてはそれがビジネス、企画、もっと言うとバックオフィス、採用とかそういった人事系の仕事も、すべて小さなチームにして権限移譲をして進めていく構造になることが見込まれています。
さらにそのあとというのはまだわかりません。私が決めることでもありません。ただ、今までの流れでいくと、次は事業側・開発側がより近くなってくるのではないかと思います。
マネージャー層やリーダー層に対してトレーニングを実施
ではここからは、今までお伝えしたステップの中で私たちがどんなことを全社組織として支援したかをご説明していきます。
まず最初の段階では、関係者・キーマンを中心にいろいろヒアリングをして、先ほど申し上げた課題設定を行いました。
そして、マネージャーやリーダー層に対して「リーンやアジャイルを知るためのトレーニングを受けてみませんか？」という提案をしました。
その中では、アジャイルのメソドロジーの話は一切しませんでした。リーンやアジャイルの持っている価値基準や原則の話をして、それと照らし合わせて自分たちの組織はどうだろうかというディスカッションするようなトレーニングワークショップのようなかたちでやりました。
左下にあるのは、先ほどお見せした3つのカテゴリの仕事のイメージ図です。全社を対象にしたモデルとしてご紹介しましたたが、特定の事業部やプロダクト・組織に対しても当てはまる話なので、そこを踏まえてお話します。まずは一部の現場に対して底上げを行うというアプローチです。
このトレーニングは非常に満足度が高かったです。
私たちはトレーニングの結果をNet Promoter Scoreという手法を使ってフィードバックを得ているので、簡単に説明したいと思います。「そのトレーニングをほかの人におすすめする可能性はどれぐらいですか？」ということを0〜10段階で評価してもらうんですね。
結果としては、4分の3の方が9か10をつけ、残りの人も7〜8というようなスコアでした。わかりやすく10点満点に換算すると、平均で9.1点というような結果でした。
これが非常に功を奏して、「アジャイル・リーンの価値基準や原則をすべてのメンバーに知ってもらいたい」ということになり、すべてのロールの人が同じ時間に同じ場所に集まって同じトレーニングを受けました。
さらに、それと同時期にマネージャーやリーダー向けにリーダーシップ、とくにサーヴァントリーダーシップをテーマにした研修を実施しました。なので、左下のモデルでいうと、組織全体に対して底上げをしたというアプローチになります。
これが当日の風景ですね。かなりの人数を1つの場所に集めてワークショップをやりました。マネージャーやリーダーに対してゲームも交えながらいろいろ学んでいただきました。
こちらに関してもかなり満足度が高い結果になって、10点換算で8.2点・8.8点という結果になりました。
支援先のみなさんが同じ考え方を持って、こういったことを信じながら進めていけそうだとなりましたので、その次の1つ目のスモールチームをつくるというアプローチにつながりました。
改善ミーティングのファシリテーションやカンバン方式の採用
このなかで私たちが何をしていたかというと、スクラムにだいぶ近しいプロセスを踏んでいるので、スクラムから学べることがないか考えてみようというトレーニングをしました。もちろんアジャイルコーチとしていろいろなミーティングに出て、どうすればよいかというアドバイスや、振る舞いに対してフィードバックを粘り強く続けていきました。
もちろん従来型の組織に対してもなにもしていなかったわけではなく、そういった組織も今よりも良くしていくことが大切なので、定期的な改善ミーティングを立ち上げて、それをファシリテーションしました。自分たちの振る舞いやプロセスなど、すべてのものを改善していく習慣づくりをこの中で行いました。
さらに並行して、ビジネス側の組織に対してはカンバン方式の適用を支援しました。今やっていることをしっかり見える化して、それに応じてみんなで自律的に動こうということで、カンバン方式を採用しました。
これがイメージです。
左側は開発組織全員で集まってディスカッションをしているところですね。右側は実際に自分たちのプロセスを洗い出してカンバンを作っているような風景になります。
そういったことを粘り強く続けていくことでそこが成功裏に終わったので、次はスモールチームをスケールしたフェーズになります。
スモールチームだけでなく継続的な改善も成功してきたタイミングなので、それを組織の中に広めていくことをお手伝いしていました。事業部内の勉強会の開催などを少しお手伝いしていました。
もちろん新しくできたチームに対しての支援も必要です。ただ、一方ですべてのチームに入っていくのは難しくなるので、各チームのスクラムマスターのようなロールの方に個別のセッションの時間をとって、課題解決の支援をしていました。
そして、現在が事業部側に新しいチームをつくるところなのですが、ここに関しては同様に新しいチームの立ち上げなので、1つ目のチームのように、実際にチームの中のミーティングやイベントに出てフィードバックをするということを繰り返しています。
今は外部のトレーニングを受けることも検討していて、内部でやってきた改善や、やっていることがどうなのかという外の視点を入れてやっていくことも検討しています。
やり方を指示するのではなく、情報提供をして相手に選択してもらう
ここまでさらっと説明しましたが、この過程では数々の障害や障壁があり、いろいろと問題点もありました。ただ、彼らは非常に率直に忌憚のない意見をぶつけあって、時にはピリッとした空気になることもありましたが、そういったことを臆せずにしっかりと話していく。そこで新しい次の実験を考えていくことを繰り返してきました。そして、もちろん今も繰り返しています。
この先はどうなっていくかわからないという話をしましたが、本当にそのとおりです。ただ私たちにできる唯一のことは、今言ったように、議論をして新しい実験をしてそこから学んでいくことだと考えています。
左のモデルで言うと、1ついい事例ができたことを次は全社的にそれを広げていくことは、間違いなく彼らと私たちのミッションになると考えています。
これからどうなっていくかはまだわかりませんが、ここまで多くの人数を巻き込んで実験を重ねてこられた理由は、最初のトレーニングでもあったように、こういった考え方を人に薦めたいぐらい良いものだと思ったというところが1つ大きなポイントになったと思っています。
ここは私たちもかなり意識しているところです。先ほど申し上げた、なにかしらを強制するのではなく、サポートして彼らの潜在能力を引き出すような働きをするということが功を奏したのではないかと思います。
私たちは彼らがやってきたこと・やることを完全にリスペクトしています。私たちは、可能なかぎり彼らからの声を聞いて、専門性を持つ人間として話すことを心懸けています。
繰り返しになりますが、私たちが「こういうふうにやったほうがいい」「こうやるべきだ」ということは一切なく、私たちから最大限の情報を提供して、彼ら自身に選んでもらうことを非常に意識しています。
なにか物事を広めるにあたって、それを好きになってもらえるかどうかは非常に大事だと思っています。1人で突っ走って、共感してもらえずにコケることは誰しも経験したことがあるのではないかと思いますが、そういったことを非常に留意しながら進めています。
さまざまなトレーニング機会を提供
これで大きな事例は終わりなんですが、ここからは大小さまざまな、先ほどの3つの仕事のカテゴリの中から駆け足で紹介させていただきます。
その前に、ここまでお話ししてきたことのグローバル視点でのお話なのですが、これまでお話ししてきたEffective Team and Delivery室は日本に存在している組織で、それと目的観を同じにした組織や集団が各国にも存在しています。それを束ねてハブになるような組織をつくって、これらのチーム・組織の相互作用を促しています。
Project Management Roundtable Task Forceと呼んでいる、情報を同期して、ここのハブの中心になるような組織であったり。あとはProject Management Evangelistというグローバルのコミュニティであったり。あとは、Global PJM Training Working Groupという、グローバルでトレーニングを作って提供している組織もあります。これらは決してヒエラルキー的な構造ではなく、ハブのような存在になっているところがポイントです。
この3つのカテゴリの仕事ですが、先ほどから申し上げている、プロジェクトマネジメントやアジャイルに関するトレーニングイベントを定期的に全社でやっています。
コンテンツとしては、プロジェクトマネジメントの基礎やリーン・アジャイルの基礎、あとはプロジェクトのビジュアライゼーション、プロジェクト／プロダクトのヘルスチェック。あとはリスクマネジメントやレトロスペクティブ、スクラムのトレーニングといったコンテンツを持っています。
実際のプロジェクトやチームの課題に応じたトレーニングもやっています。
これまではリーダーシップのトレーニングやスクラムから学ぶトレーニング、スクラムを実践している中でさらに学びましょうというトレーニングや、アウトソーシングの会社と一緒に仕事をするときにどうすればうまくいくかなど、さまざまなトレーニングを提供しています。
問題解決の支援としてやっていること
問題解決の支援においては、最も多いのはチームビルディングのサポートです。
とくに入社した直後はお互いのことを知ったり心理的安全性を高めたり、お互いの価値観を深める、理解を深めるようなアクティビティをやっています。こちらの写真も、ある開発センターで全員で集まってやったものですね。
もう1つが、これもエッセンシャルなものなんですが、やはり自分たちの問題解決を自分たちでしていく、そういった場を継続的につくることが非常に大切です。ですので、オープンスペーステクノロジーと呼ばれるディスカッションイベントのファシリテーションをやったり、実際のプロジェクトのレトロスペクティブをお手伝いしたり、定期的な改善ミーティングの習慣化をお手伝いをしたりしています。
そして、実際のプロダクトチーム・プロジェクトチームのアラインメント、方向づけを支援することも多いです。
左側の例ですと、トップダウンでロードマップを作るのではなく、メンバーも含めてみんなでどういう姿がよいのかを議論をしながらプロダクトのロードマップを作ったり、インセプションデッキと呼ばれる、「このプロダクトは何のために必要なのだろうか？」ということを全員で議論する場を提供してファシリテーションするようなサポートもしています。
また、アジャイルのプラクティスの適用を支援することもあります。左側はカンバンを適用していたり、右側は台湾の事例になりますが、LeSSの適用を支援することもあります。プラクティスの適用を目的にするのではなく、価値基準や問題解決をベースにした上でこういった選択をしています。
最近ではマネジメントレイヤーのサポートも積極的に行っています。
左側は、改めてシニアマネージャーとマネージャーがどういったことをお互い考えているのか、腹を割って話すような会議です。右側は、シニアマネージャーが少し仕事を抱え過ぎている瞬間があったので、それを開示してみなさんでどうやっていけばよりよいだろうかと考えるワークショップをやったりしています。
今お話ししたものに関しては「お仕事解体ワークショップ」という名前でやったんですけれども、LINE HR Blogにも詳細を載せているので、もしご興味があればぜひご覧ください。
そしてコミュニティの部分なのですが、こちらに関しては各拠点をつないでランチを食べながらみなさんの課題をディスカッションしたり、誰かが事例を共有したり、そういった場をカジュアルなかたちで提供しています。
あとは、社内でカンバンをやっているチームをお互いに見に行くツアーをやったりすることがあります。
また、写真には載せていませんが、Slack上にアジャイルやプロジェクトマネジメントに関わるチャンネルがあり、250名ほど参加していて、そこで情報交換をしたり一緒に議論をしたりということが行われています。
Effective Team and Delivery室の働き方
ここまでは私たちが全社組織としてどのように仕事をしているか、どのような仕事を提供しているかという話をしてきましたが、ここから私たちの全社組織自体がどのように仕事を進めているかをご紹介します。
まずは、支援と同じく自分たちのビジョン・ミッション・ストラテジーが何かしっかりと意識を合わせることが重要なので、四半期に1回全員で顔を突き合わせて、全員で改めてビジョン・ミッションを見直して、なにか変更をしたりrefineしたりする余地がないかを考えます。
あとは、この半年でどんなインパクトのあることをやっていくのかを全員で考えて、このようにロードマップのようなかたちにして計画を立てています。
こちらは韓国での事例になるのですが、「TPM Manifesto」という、「Agile Manifesto」をもじったような、自分たちがどういった価値基準の下で行動すべきか、どういった価値提供をするのかという信念をみんなで出しあって、それを1つのステートメントにして自分たちの仕事の信念として持っている、というようなことを作っています。ここも方向づけですね。
こちらも、私たちが支援するチームに対して行うことと同じように、やはりチームとしてお互いのことを深く知っているかも非常にキーになるので、Self-Assessmentのツールを使ったりして、それを自分で自覚し、それを相手に自己開示して、それに対してディスカッションするというようなことをやりながらチームワークを高めています。
効率よくインプットをするための工夫
あとはLean & Agileチームの取り組みですが、このチームは自分たちの仕事もスクラムで進めています。アジャイルのこと、スクラムのことを説明しながら自分たちの仕事はそうでないというわけにいかないので、バックログを作り、それをセルフサインアップでペア作業したりモブワークしたり、そういったことをチームの中でも行っています。
そして、私たちは知識とか経験、これまでの事例を社内に広く伝えていく役割を持っているので、いろいろなことを学ぶインプットも大事になってきます。
なので、業務時間を使いながら、自分たちが学ぶべきことをLearning Backlogというかたちでバックログ化して、それをLearning Sessionという時間にみんなで学ぶということをやっています。外のイベントに行ってきてそれに対してフィードバックやディスカッションをしたり、読書会をやったりすることもあります。
これによって、外から得た知識を中に伝えていく、中に合うようにカスタマイズをして解釈していくということが行われています。Learning Sessionに関しては、弊社のEngineering Blogでも紹介されていますので、こちらもご興味あればご覧ください。
リモートチームでもコミュニケーションを円滑にするためにやっていること
そして、これはコミュニケーション上のTipsになりますが、私たちは実は複数の拠点にチームメンバーがいまして、私たち自身がリモートチームになっています。ですので、ふだんから簡単に隣の席に声をかけるように雑談するのがなかなか難しい環境にもなっているので、定期的にリモートビデオをつなぎながら、「業務、仕事の話をするのは禁止」というルールを作ってリモートランチをしたりしています。
あとは、もちろんマネージャーとメンバーでの1on1をやっているんですけれども、それ以外にもメンバー同士の1on1、お互いの仕事を知り、お互いにフィードバックをし、お互いに学ぶために「Peer 1on1」もやっていたり、1on1ではなく3人組になる「Buddy」という仕組みを用いて、3人で仕事を共有しお互い学び合うということもやっています。
ごく一部ではありますが、社内での事例を少し駆け足で紹介させていただきました。今日に関しては概要レベルでの共有になりましたので、このあとAsk the Speakerで、ぜひ気になる事例などがありましたら具体的に聞いていただければと思います。
それでは、本日はこのセッションにご来場いただき、ありがとうございます。今日のセッションで紹介したTechnical Project Managerやアジャイルコーチという職種に関しては募集を行っていますので、もしご興味があればぜひ検索してご覧いただければと思います。
それでは、引き続きLINE DEV DAYをお楽しみください。ありがとうございました。
（会場拍手）
