こんにちは LINE Delivery Management Team の Tanigawa です。
今回は、LINEの様々な開発拠点で活躍・奮闘するプロジェクトマネジメントのプロフェッショナルを集めて福岡で開催した、Global Technical Project Manager Workshop (Global TPM workshop) の内容をかいつまんで紹介します。

LINEのプロジェクトマネジメント

最近の日本におけるLINEの新展開といえば、LINE Pay や LINEトラベル、LINEほけん など新しいサービスが続々と誕生していますね。

これらのサービスの裏では、もちろんさまざまなプロジェクトが発足したりプロダクトが生み出されている訳ですが、この数多くのプロジェクトやプロダクトをLINEはどのように管理し運営しサービスの品質を維持しているのか気になりませんか？

LINEではソフトウェア開発のプロセス管理(プロジェクト,プロダクト問わず)のナレッジを統合し、開発を促進するプロジェクトマネジメント手法の良いプラクティスを浸透させるために、2017年から部門横断的にプロジェクト管理を担当・補助するプロフェッショナルな組織を新設しています。

その組織が私の所属する Delivery Management Team で、LINE は韓国,台湾,タイ,インドネシア,中国,ベトナムでも様々なサービスを開発し提供しているため、海外拠点にも同じようなサービスを提供する組織です。

今回ご紹介する Global TPM workshop ではそのような役割を担うメンバーが一同に会して、プロジェクトマネジメントやScrumの成功例や苦労していること、また統一されたプラクティスの紹介などを共有し、お互いの知識と団結をより一層深めることができたので、その一部分ですが私なりに印象が大きかったトピックをシェアさせてください。

Workshopの注目トピック

Icebreaking

初めて顔を合わすメンバーも多い中でより効率的にディスカッションが進むように、ワークショップの冒頭で "Market of Skills" というエクササイズで参加者の自己紹介を兼ねてコミュニケーション活性化を図りました。自己紹介の観点を絞り、かつ他者とのコラボレーションを促す手法ですね。方法を簡単にまとめたので、ぜひみなさんも試してみてください。

• 各個人が下記3つの内容について自分を説明したポスターを作り、順番で自己紹介をする
  • Project Management に関して自分が備えているスキルや知識や経験
  • Project Management に関係ないが、自分が備えているスキルや知識や経験（例えばスキューバダイビングなども可）
  • 今回のworkshopを通じて、身に付けたいスキルや知識や能力
• 自己紹介後にポスターを会場に貼りつけて、自分以外の参加者のポスターに "興味あり！" とか "その課題、僕なら解決できます！" とか自由に付箋を貼っていく
• 上記の二段階で自然とコミュニケーションが活性化されていく

詳しい説明は下記を参照してくださいね。

• 書籍 : "Coaching Agile Teams"
• https://medium.com/practicalscrum/market-of-skills-634a6ebf3363
• https://blog.crisp.se/2012/11/06/anderslaestadius/team-liftoff-with-market-of-skills-and-competence-matrix

Portfolio for JIRA

LINEではタスク管理ツールとしてAtlassian社のJIRAをメインで使っています。
そのJIRAのアドオン的に使える Portfolio というサービスの紹介と実際のプロジェクトでの使用例を Vinicio@Japan にレクチャーしてもらいました。
　Portfolio for JIRA : https://ja.atlassian.com/software/jira/portfolio

組織が大きくなってくるとJIRAのプロジェクトがあちこちに生成されますよね。（JIRAに限らずどのグループウェアでも同じだと思います）
このセッションでは、JIRAのプロジェクトは分かれているがそれぞれのプロジェクト全体を俯瞰してロードマップ計画や工数調整をする事例とツールの使い方を紹介しました。
JIRAの細かい話になりますが、Initiative という Epic の親にあたるイシュータイプが管理できるため、プロジェクト横断的なタスクも管理しやすいそうです。

実際に LINE のプロジェクトで使っている例を紹介してもらいながらのレクチャーでした。

Lean/Agile 基礎研修の共有、Scrum 事例の紹介

Lean Product Development TF という、 LeanやAgileの原則を活かしながら現場の改善を支援するチームの Yokomichi@Japan から Lean/Agile 基礎研修の内容共有がありました。

アジャイル、モダンアジャイル、リーンソフトウェア開発 などの原理・原則や基礎を学ぶ座学を行った後、リーンソフトウェア開発における「ムダ」をテーマにした ”カリグラフィーゲーム” とよばれるエクササイズを全員で体験しました。

私は前職で Scrum 研修を受けたことがあったのですが、その時は基本的な原理・原則を座学で学んだ後、折り紙を使って Scrum を疑似体験したのがとても印象的で、そのおかげで今でもその研修の内容を鮮明に覚えています。こういった形で、学習にエクササイズが交えられると、知識が定着されてよいですね。

また同じく Lean Product Development TF の Nakamura @Japan から、Agile / Scrum のチームでの実践事例も共有されました。
特定の手法にはこだわらず「よりアジャイルになること」を目指しさまざまな改善を積み重ねた結果、開発リードタイムの短縮や、ソフトウェア品質の向上、東京-福岡で離れて働いているステークホルダー間のコミュニケーション向上、信頼の構築、チームメンバーの従業員満足度の調査結果の高さなどが実現されたチームの事例でした。
このチームの事例は 2019/1/9〜11 で開催される Regional Scrum Gathering(R) TOKYO 2019 にて発表されることが決まっていますので、ぜひ皆さんの耳でお確かめください。

また、チームビルディングのために ”リモート飲み会” を開催していることなども紹介された際には、参加者全員が興味津々でした。これは是非ともチームビルディングの一環として真似したい手法のひとつですね！

Scrum case share

LINEスタンプのオートサジェスト機能を開発しているチームのScrum実施例を、開発リーダーでありスクラムマスターであった、Jonathan氏＠Japan にシェアしてもらいました。

LINEは全社的な開発プロセス規定によってQA(Quality Assurance)工程をきちんと定義し、QA専任の人材も用意しています。
(どの現場でも大抵そうだとは思いますが) 開発者とQAとの間の仕様確認やスケジュール調整、バグ修正の緊急度の認識の違いなどでコミュニケーションが必要になり、デリバリスピードが最大化されない場合があります。
このチームのScrum実施例で特徴的だったことは、QAメンバーをScrumチームの中に入れたことです。

QAメンバーにScrumイベントはもちろんのことプロダクトバックログのブレークダウンのフェーズから密接に開発者と関わってもらうことで、コミュニケーションコストを減らし、2週間のスプリントで毎回QA品質をクリアしたものをリリースできる(ステークホルダーがレビューできる)状態にできていたそうです。
QAがScrumメンバーとして参加していると、QAが発見したバグに対してもプロダクトオーナーがしっかり優先順位をつけるというプロセスが自然と出来上がると思うので、何を修正し何を修正しなくていいのかが分かりやすくなるというメリットもありますね。

Scrumを成功に導くための条件のひとつとして、全メンバーが同じ場所に集まって仕事をしていることが挙げられると思います。
このチームのもう一つの特徴は、スクラムマスターと開発者とQAメンバーが福岡、プロダクトオーナーが東京という分離された環境でScrumを実施したことです。

プロダクトオーナーは、半分の時間はお客様やステークホルダーと一緒に過ごし、もう半分の時間は開発者と一緒に過ごすのが良いと言われることがあります。
リモート会議ができるファシリティが整っているということが大前提になってしまいますが、LINEでは特にマルチロケーションで開発プロジェクトが組まれることがよくあるので、このチームのプラクティスはマルチロケーションでも健全なScrumが実行できたという点でWorkshopメンバーの注目を集めました。

Healthcheck

今自分のプロジェクトが上手くいっているのかを普段から意識していますか？
たとえ自分のプロジェクトが客観的に見て上手くいっていなかったとしても、開発メンバーもリーダーもそれをあまり認めたくない心理になっちゃいますよね。

そんな時にメンバー全員で一歩引いた目線に立ってプロジェクトの健康度を自己診断するために、プロジェクトのヘルスチェックアンケートを作ったよという事例を Yinseok@Korea に紹介してもらいました。

プロジェクトの立ち上げ方や立ち上げ後の管理状態が良くないと、目標意識が統一できていなかったりプロセスがうまく回らないままメンバーが不満を持ち続け、不健康なプロジェクトになってしまいがちです。
人間の身体に定期検診が必要であるように、プロジェクトも定期的に様々な観点から検診をすることで、潜在している問題に対して早く改善策が打てるようになるということです。
自分のプロジェクトは大丈夫だと思っていても"定期的"にヘルスチェックをすることが重要です。(自分だけはガンにかからないと思っている人って結構いたりしませんか？)

下記にプレゼンテーションのスライドを共有します。
(左) に記載されている各観点についてのいくつかの問診票をあるプロジェクトのメンバーに回答してもらい、(右) のようなメリットを生み出せた事例が紹介されました。

せっかくなので、問診票の例を紹介しておきます。

• 目標の達成度を測定できる定量的な指標が設定されているか？
• メンバーはみなお互いに尊重し合っているか？
• 定期的にプロジェクトの進捗を見直し、改善策を施しているか？

Retrospective

上述のヘルスチェックの中に"定期的な見直しを行っているか？"という項目がありましたが、プロジェクトをより良い方向に向ける活動のひとつとして、レトロスペクティブ(振り返りイベント)があります。

アジャイル開発手法について韓国で本を出版したこともある Jongbeom@Korea から、レトロスペクティブにおけるより良いプラクティスを共有してもらいました。 

より良いレトロスペクティブはチームやプロセスをさらに成長させ、潜在リスクを回避できるきっかけになります。(さっきのヘルスチェックと言ってること一緒ですね..)

レトロスペクティブのハウツー本やウェブ記事はたくさんありますので、ここでは印象的だったことを一部紹介します。

ひとつ目ですが、レトロスペクティブのファシリテータは誰がやるのかということがかなり重要のようです。
例えば、チームメンバーがファシリテータを担当することはやめた方がいいようで、チームのことを客観的に見れて、開発者側,企画側などどのポジションの観点にも立って考えることのできる、いわば他人のような人が適任だそうです。
実際に外部からファシリテータを呼んだ方が充実したレトロスペクティブができたとさえ言っていましたね...
外部ってことは、隣のチームの全然関係無い同僚を引っ張って来てお願いしてもいいんです。これならお金をかけずに誰でもすぐに実践できそうですよね？

ふたつ目は、議論を盛り上げる特徴的な質問について。
また1つの質問だけでレトロスペクティブが活発になり、有意義な議論のきっかけになる面白い質問集の紹介もありました。
二つ目の質問は下記スライドの "Miracle Question" という名前で紹介されていますね。

• 「10年後、私たちの会社が倒産してしまった。何が起こったと思う？」

これは小さなスタートアップ企業での実例らしいのですが、将来何が起こったら怖いか、何が起き得るかについて想像を膨らませて意見を出しあうのに役立ったそうです。
　　　この質問をするだけでチームメンバーから、実は大きな問題だと思っているリスクや、プロジェクトの最悪のケースについて事前に対策を打てる案が次々と出てきたそうです。

• 「もし、奇跡が起こって全ての問題が解消し期限内にサービスリリースできるとすれば、何が起こったのだろう？」

　　　この質問も'もしも'の仮定で質問を投げかけることで、チームメンバーが胸の内に秘めている"たられば"を引き出し、そのたらればを実現するにはどう改善したらいいかの議論を引き起こすことができます。

終わりに

今回がLINEのプロジェクトマネジメント部隊として初めての Global TPM workshop だった訳ですが、
各国お互いに持ち寄ったプロジェクトマネジメントに関するノウハウはそれぞれ完成されたものではないものの（いや、たぶんプロジェクトマネジメントに完成はないですね..）、カジュアルに苦労や成功例を共有することで、お互いの国で抱える問題に共感したり知恵を出して助け合ったりできたため、非常に有意義なWorkshopになりました。

韓国、タイ、台湾とロケーションが違ってLINEのサービスカタログも異なれども、プロジェクトマネジメントで悩んでいることは基本的に同じで、各拠点で共通のナレッジを体系化していけば、これからまだまだスケールアップするLINE developerたちのマルチロケーション開発をうまくまとめていける未来が見えました。

あとこれは個人的な話で余談ですが、月例のリモート会議で英語でぎこちない会話しかできていなかったグローバルメンバーと今回実際に会ってみて、よりコラボレーションが生み出されやすい状態になったと言えます。（英語力が乏しいなら、実際に会って身振り手振りとホワイトボードを使ったりなどしてコミュニケーションしないとダメですね..）
福岡の美味しいご飯が助けてくれたのもありますね。