EOF2019と登壇の経緯
こんにちは、Delivery Management Team の Tanigawa です。
2019年10月31日、渋谷がハロウィンムードに包まれている中、私は浅草橋にて EOF2019 というカンファレンスでLINEにおける組織/チームマネジメントに関する取り組みを紹介してきました。
本カンファレンスは今回 EOF2019実行委員会によって初めて開催され、様々な企業で日々奮闘するエンジニアリングマネージャーやプロジェクトマネージャーが自身の経験やチャレンジ、失敗などをオープンに共有しあうという目的で開催されました。詳しくはイベントページを参照してみてください。
LINEは11月に開催した LINE Developer Day 2019 の宣伝も兼ねて、ゴールドスポンサーとしてこのイベントに協賛させていただきました。
このカンファレンスで私から共有したのは、LINEのある開発チームのコミュニケーションやプロセスの課題をどうやって改善してきたかについてです。
以降でその内容について簡単に紹介させていただきます。タイムテーブル&セッション内容
発表内容
発表資料
Effective Team and Delivery室の仕事
LINEには組織横断的にプロダクト開発プロセスの改善や組織自体の課題の解決に、開発チームと一緒になって取り組む Effective Team and Delivery室という組織があります。
その中に、AgileやLeanの考え方に基づいて組織/チームづくりや人の課題を中心にサポートをする Lean & Agile Team と、プロジェクトマネジメントの知識を基にプロジェクトの進行や課題解決をサポートする Delivery Management Team があります。
具体的な仕事といえば、組織の課題に対するコンサルティングや継続的なコーチング、プロジェクトマネジメントやスクラムのトレーニングの提供、社内コミュニティの運営、実際のプロジェクトマネージャーやスクラムマスターの役割としてプロジェクトに参画することです。
私は Project Management のプロフェッショナルとして Delivery Management Team に所属して、LINEのインフラを支える開発部隊、Verda室をサポートすることになりました。
Verda室の悩みと関わりの背景
Verda室 は、LINE 開発者専用のプライベートクラウド "Verda" を開発する組織です。
Verda 上には現在、仮想サーバーでは37000台、物理サーバーでは5000台ものインフラリソースが稼働していて、Full managed kubernetes や Object storage など一般的なパブリッククラウドが提供するサービスなども備えています。
2016年に10人前後で開発組織が構成されてから、今では東京,京都,福岡,韓国のメンバー総計で約60人の大きさの組織になります。
Verda室の当初の悩みは、組織が大きくなる中でさまざまなプロジェクトが立ち上がるのですが、そのプロジェクト一つ一つに対する、進捗やリスクの可視化とそれに基づいたタイムリーな対策や意思決定ができていなかったことでした。
当時は日本語/韓国語どちらも話せる室長が一人で、ヒアリングベースで6~7個のプロジェクトの状況を確認していましたが、それぞれのプロジェクトの会議全てに参加できるわけではなく、プロジェクト状況の詳細な把握に限界がありました。
そこで私はプロジェクト可視化を最初の仕事として取り組み始めました。
プロジェクト可視化と見えてきたプロジェクトの根本課題
プロジェクトを失敗させないためにやった方がいいことはPMBOKに知識体系として色々と整理されていますが、私が特にプロジェクト可視化に関して必要だと思う最低限のことは下記の3つだと思っています。
- 明確化されたゴールと最新のスケジュール
- 次のマイルストーンに対する状況
- リスクと問題に対する分析とアクションプラン
これらを可視化することは、スポンサーや上長、ステークホルダーがプロジェクトの状態が分かるだけではなく、リスク回避の対策が取れるという点でプロジェクトメンバーにもメリットがあります。
この3つの観点で、プロジェクトの定例会やSlackのチャット履歴から情報を吸い上げ、 社内wikiページに可視化していきました。(実際のアウトプットはプロジェクト情報を含むので掲載のスライドからは削除しています)
いくつかのプロジェクトの可視化は達成されたのですが、新たな課題が見えてきました。
- 結局すべてのプロジェクトを可視化しようにも人手が足りない
- プロジェクト進行が難しくなる共通の根本原因がある
a.リリース済みプロダクトのメンテナンスタスクの割り込み
b.Frontend(FE)開発者とBackend(BE)開発者の足並みが揃わない(スケジュール, 仕様調整)
2-b の課題に関しては、Verda室の組織構造を知っておいてもらわなければなりません。
Verdaのサービスはそれぞれ OpenStack や Kubernetes,Storage,Network などの専門性が明確に分かれていて、BEチームはそれぞれの専門性に特化したメンバーの集まりによって構成されていました。プロダクトの企画はBEチームが主導して行い、FEやSRE、QAなどのすべてのサービスに共通で必要な役割はプロダクト横断的な共通のチームとして構成されていました。
この組織構成から、FE開発者はプロダクトのUI企画について受動的になってしまい、BE開発者とスケジュールや仕様の調整面で足並みが揃わない問題が起きていました。
これらの課題を解決し、なりたい組織像を描き、さらなる課題解決に取り組んでいくことになりました。
スクラム導入で試みた課題の解決
"メンテナンスイシューの扱い" と "FE/BE開発者の協働" の課題解決策の一つとして、スクラムの導入を提案してみました。
"スクラムを銀の弾丸だと思うな" という言葉をよく耳にしますが、そのことは承知のうえでも、この時はあわよくば上記2つの課題をスクラムのフレームワークに則ることで改善することができるのではないかと考えていました。
提案後、残念ながら全てのチーム、特にBEチームとFEチームが一緒になってスクラムを実施しようとはなりませんでしたが、いくつかのチームで「スクラムの原理について同意できるので、できるところからやってみよう」ということになりました。
Verdaで最初にスクラムを実践することになったチームは、スクラムのルールすべてに則る方がより効果が高いだろうと考えつつも、導入期の負荷を下げたい思いもあり、スクラムのルールを部分的に適用することを試してみることになりました。
そこで実施したのが、スクラムのプラクティスの意味や効果を考えるワークショップです。
ワークショップ内容
- スクラムのイベントや成果物やロールの意味やそれぞれの特徴に対する理解を共有する
- 自分たちのチームで実践すると効果がありそうなアクティビティを選び、カスタマイズする
このワークショップを通じて、メンバー間のスクラムに対する理解の認識合わせと自分たちでチームのプロセスを作るという2つのことをやってもらい、部分的にスクラムの要素を取り入れた独自のスプリントワークを始めることになりました。
決まったプロセスの主なルール
- 2週間のスプリントでチームのプロセスやプロダクトの問題点を定期的に振り返る
- デイリーミーティングでメンテナンスイシューの緊急度や割り込み可否を判断する
- 重要度の高いメンテナンスイシューを2,3つ先のスプリント計画に入れる
この他にいくつか定着に失敗したルールなどもありましたが、メンテナンスタスクの優先度管理とチームの継続的な改善が促される文化になってきました。
さらに、当初想定していなかった効果だったのですが、一つのチームでこの独自スプリントワークのメリットが少しずつ見えてくると、他のチームもとりあえずやってみるかという形で、スプリントワークが始まり、それぞれのチーム独自の改善策やプロセス/ルールが生まれていきました。今では4つのチームでスプリントが実施されています。
大プロジェクトでの失敗から学んだ振り返りと期待値調整の重要性
4つのチームがスプリントを通じて定期的に計画と振り返りをすることで、アジャイルなカルチャーが徐々に浸透してきつつある中で、あるプロジェクトでそれらのプラクティスを適用していなかったことによる失敗も経験しました。
プロジェクトの詳細は割愛しますが、とにかくVerdaのほとんど全てのチームが関わる1年がかりの大きなプロジェクトで、それぞれのコンポーネントでの開発を一通り終えてからインテグレーションを最後に実施するというウォータフォール型開発のようなスタイルになりました。
このプロジェクトでの失敗は、振り返りをプロジェクトの途中で実施しなかったことです。4度ものリスケジュールの末、1年経ってようやくリリースできたときに初めてレトロスペクティブ(振り返り会)を開催しました。
レトロスペクティブの結果たどり着いた結論は、①自分たちには"プロダクト全体を俯瞰して開発をリードする人"がいなかった、ということと、②役割を持った相手に期待する振る舞いやアウトプットの認識を合わせべきだったということでした。実際には "Planner" という役割をアサインされた人でさえ、自分が開発者に対してどうコミュニケーションをとってどういうアウトプットを出すべきかという認識にも不安がありました。
この類の問題であれば、プロジェクトの途中で気付いて修正されるべきですが、ほとんどのメンバーが兼務をしていたということと振り返りのきっかけがなかったことで、問題として認識されないままプロジェクトが進行していました。
先ほどはチームという単位で定期振り返りの習慣が浸透してきたという事例を紹介しましたが、それがチーム横断的なプロジェクトでできていなかったのです。
ウォータフォール型開発といえども、プロジェクト途中で振り返りをすることの重要性を強く認識した経験になりました。
"レトロスペクティブ"と言うとつい、「それはスクラムのプラクティスであってウォーターフォールのプロセスには不要」と感じてしまいがちですが、レトロスペクティプはアジャイルなマインドセットに根ざした一つのプラクティスと考えれば、ウォーターフォールのプロジェクトに適用することもできるということです。
登壇後、私の予想に反して Twitter でのリアクションが多かったレトロスペクティプの手法もここで共有しておきます。(#eof2019 #hall)
プロジェクトヘルスチェックアンケート
- ゴールは明確で共有されていたか、潜在リスクとそれに対するアクションプランが管理されていたか、などプロジェクトマネジメントの健康度要素に対する16の質問に対するメンバーの回答を点数化。
- 問題があった箇所を明確にできる。
なりきりレトロスペクティブ
- 事前に仮想プロジェクトに対する成功と失敗の価値観を共有してもらう。
- 全員でプロジェクトに対して「成功した!」という気持ちになりきって成功したことを書き出してもらい、その後で「失敗したなあ..」という気持ちになりきって失敗したことを書き出す。
- ネガティブなことをアウトプットしにくい心情が解除される。
タイムライン&エモーショナルライン
- プロジェクト開始からやってきたことやハプニングなどのイベントを書き出し、その時系列に沿ってメンバー全員の心情の変化を線で表す。心情の変化のきっかけになったことも書く。
- 辛さのきっかけになった問題の中で改善したいことを投票で選ぶ。
- 選ばれた問題に対してグループに分かれて改善案を議論し、発表しあう。
期待値を調整しながら組織の課題解決を探る
チームやプロジェクトで働く上で、ある役割を持った相手に対して何を期待しているのかと、その役割を持った人は自分が何を期待されているかの認識ギャップを埋めることが大切だということに気づかされ、この考え方を組織の課題解決に適用した取り組みを紹介します。
まだアプローチできてなかった理想像
- 全プロジェクトが自主的に可視化される
- FE/BE開発者一丸となって開発速度、プロダクト品質を上げる
プロジェクト可視化についての取り組み
室長が一人もしくはProject Manager が一人で10前後のプロジェクトを可視化するというのは無理があったので、それぞれのチームやプロジェクトのリーダーに最低限やってほしいプロジェクトアクティビティを考えて共有しました。しかし、これは浸透しませんでした。
プロジェクトを可視化して欲しいという室長と、それをしなければいけないリーダー達には立場の違いがあり、なぜプロジェクトの可視化が必要なのかについて認識のギャップもあります。
このギャップのすり合わせに、デリゲーションポーカーの考え方を適用しました。
デリゲーションポーカーは、一つの仕事に対して権限を移譲する人とされる人のそれぞれの移譲レベル認識を "いっせーのーで" で突き合わせることで、認識ギャップの解消を促します。
ここで大事なのは、決して権限移譲や仕事を依頼する側(普通は上司に当たる)から先に期待を言わないということです。上司から先に期待値を言うと、部下の想像力は停止され、期待値ギャップが存在したまま仕事の委任が始まります。
Verda室では、室長が考えるプロジェクト運用に必要なプロセスについて、各リーダーたちが先に "なぜそのプロセスが必要なのか/必要だと思われているのか" をアウトプットした後で、室長から足りない部分やそこまでしなくていいという認識のズレを調整するワークショップを開催しました。
その結果、各プロセスの再定義とともにリーダー達の納得感を確認し、リーダー達による自主的なプロジェクト可視化の取り組みを始めることになりました。
FE/BE開発の統合についての取り組み
Verdaは組織構成の都合上、プロダクトの特徴に分かれたバックエンドチームがプロダクト企画を主導し、フロントエンドやSRE、QAチームはその企画とスケジュールに合わせて計画を立てるという業務形態になっていました。そもそもFE, SRE, QAチームのメンバー数が少ないという理由もありましたが、この組織構成ではプロダクトのリリース計画をする上でFE, SRE, QAチームがボトルネックになったり、ボトルネック解消のために労働時間が長くなってしまったり、余計なコミュニケーションコストが発生するという課題がありました。
この課題について室長自身は、最終的にはFE, SRE, QAチームもBEチームと一緒になって1つのプロダクトチームとして企画/開発をイテレーティブに実施できるようにしたい、という理想を持っていましたが。しかし、ここでもあえて各チームのリーダーに今の状態の課題認識とその課題をどうやって解決したいかを議論してもらい、BEチームとFE, SRE, QAチームの思いのギャップを埋めるようなワークショップを設けました。
日韓の2グループに分けて議論した結果、どちらのグループも長期的にはクロスファンクショナルなプロダクトチームになりたいという考え方で一致し、その背景にあるお互いのチームの辛さや展望も共有することができました。
まとめ と Effective Team and Delivery室の取り組み
今回はLINEの中での、Verdaというプロダクトを開発する組織に対して、最初はプロジェクトマネジメントの切り口で関わり初めてから、組織の課題解決にチャレンジしている事例を紹介しました。
エンジニアリングは人によって営まれるものなので、組織を構成する個人個人との対話や共感によってチームを継続的に改善していくことが、プロジェクトマネジメントの難しさの根本に潜む問題を少しづつ解決していくアプローチにつながると信じています。
そのためにはどんな開発手法をとっていようとも(もはやソフトウェア開発に限定せず)定期的に自分たちチームの状態を振り返り、理想像について共感し、そこに存在するギャップを埋めるアクションを起こしていくというアジャイルなマインドセットが大事だということに私自身が気付かされました。
LINEでは、さまざまな開発組織のさまざまな課題に対して一緒に考え、組織の足りない役割の一部になったり、トレーニングやコンサルティングを通じて課題解決に取り組む組織として Effective Team and Delivery室という組織を設置しています。さらに日本だけでなくグローバル拠点でも同じような組織があり、定期的なコミュニケーションを通じてお互いの拠点の悩みや課題解決のナレッジを共有しています。(Technical Project Management Workshop)
興味がある方がいればぜひ一緒に働きましょう!