グロービスにJOINしてPOとして半年間で取り組んだ改善について
はじめに
※ GLOBIS Advent Calendar 2019 のコピーです。
はじめまして。グロービスのデジタル部門（グロービス・デジタル・プラットフォーム）でプロダクトオーナーをしています @talow1225 です。
こちらは グロービスアドベントカレンダー 3日目の記事です
私がグロービスにJOINしたのは2019年3月からなので、約9ヶ月ほど経ちました。今回は直近半年間のプロジェクトの中で解決していった課題について書こうと思います。
直近半年間で起こったこと
今回あえて半年間の話を書きます。何故ならば6月〜11月末までという期間は我々開発チームにとってはある種特別な激動の期間でした。
6月当初、私の所属している開発チームは2PO,2デザイナー,1FE,6BEという11人での開発体制に変更したばかりで、私はサブPOという肩書でした。しかし7月より急遽別の新規プロジェクトが発足し、チームメンバーが数人そちらへ移籍、メインPOも新規プロジェクトへのアサインとなりました。ですが私の所属している元々の開発チームは既存のプロジェクトを既にスタートしており、約半数のメンバーでデッドラインの変更ができないプロジェクトを進めることになりました。
課題山積み問題
私は晴天の霹靂のごとくPOを任されたわけですが、その時点で解決しなければならない課題が山のようにありました。細々としたものもありましたが、ざっくりと分類すると下記ような課題があったと思います。元々あった潜在的な課題と、プロジェクトの体制が変わったことで発生した課題です。
期日の課題
・開発メンバーは減ったがプロジェクトのデッドラインの変更ができない
・そもそもまだ具体的な見積もりが全然見えていない
品質の課題
・スケールとともにプロダクトが複雑になり軽微な障害が目立ち始めている
社内コミュニケーションの課題
・開発体制の変更により、関係者全体が不安な状態
・プロダクトの関係者が増え、部門を越えると顔も分からない状態
期日の課題
海を渡るにはコンパスが必要
我々はまずは何よりも、これから開発していくプロダクトが期日に間に合うのかを精緻に見積もる必要がありました。期日自体の調整も検討されましたが今回は10月頭というデッドラインを変更することは難しそうでした。
「期日に間に合うのかを精緻に見積もる必要がある」と書きましたが、まずは見積もるための情報が何もない状態からスタートしました。航海に例えると無事に辿り着くかどうかを判断するための情報が無い状態です。
我々はこのコンパスを手に入れるため、まずは現在詳細まで詰まっていること、何も決まっていないが決める必要があることを全て書き出して見積もりを行いました。何も情報がない箇所については、確認の必要があることを明確にしながらも情報の仮置をしざっくりとした見積もりを出しました。
これまで3ヶ月くらいの我々のベロシティから計算したところ、10月頭をターゲットに置いた場合ざっくり2倍くらいのポイント量がありました。正直この数字を目の当たりにした瞬間は少し笑ってしまいましたが、まずは現在どのような状況に置かれているか知ることが重要でした。
期日と見積もりの差分を埋める
ざっくりとした見積もりをした結果、約半分の開発工数に落とさなければデッドラインに間に合わない事が分かり、まずはその状況をチームに共有しました。
そこからは曖昧な箇所を減らす作業や、また実装する機能の目的を明確にし、ユーザーが目的を達成するために必要なミニマム機能での開発に要件を落とし込むことに集中しました。
しかし開発工数を削ったことで運用に負担をかけることは後々遺恨を残しかねないので、要件を縮小させる際のコミュニケーションに関してはオペレーション側にも丁寧な説明を行い、開発チームの状況を理解していただくことに細心の注意を払いました。
またそうこうしている間にも時間は過ぎていくので、我々はリリースバーンチャートを作り時間とポイント数の見積もりを日々精緻に比較することを行っていきました。「あと何スプリント残されているのか」「何が分かっていて何が分からないのか」「現在トータル何ポイントなのか（あ、無理かも）」みたいなことを日々会話していました。
開発を進めながらデッドライン内に収まるよう要件の調整を行った
品質の課題
プロダクトのフェーズと品質の重要性の変化
我々の開発するプロダクトは6月時点ではまだリリースして半年程度というフェーズでした。利用数なども限られていたことから、リリースまでのフローは比較的簡略化されており、開発のレビューなどもPOの経験則によるレビューのみでリリースしている状況でした。リリース当初はそれでも問題無かったのですが、徐々にプロダクトのユーザー数も増え、実装される機能も複雑になってきたことから軽微な障害が目立つようになり、その障害への対応が開発のスピードを鈍化させるとともに、顧客との直接の接点であるオペレーションチームの不安にもつながってしまっていました。
開発からリリースまでのフローの見直し
品質の課題については解決するために最優先で対策を行いました。いくつかの施策を実施しましたが、そのうちの1つがQAチームを強化してのリリース前テストの実施です。これまでの開発レビューでは属人的なテストしかできていなかったことから、どうしてもユーザーの行うアクションのエッジケースで障害が起こってしまうことがありました。QAチームに要件作成段階からレビューをもらい、またリリース前にも手厚いテストを行うことで、障害が起こる前にカバーできることが飛躍的に増えました。さらにリリース前の機能にstg環境でオペレーターの方にも一定期間触れていただくことで、気になる点を潰すことができたのも良い取り組みだったと思います。以前よりリリースまで時間はかかってしまうのですが、プロダクトが大きくなってきたことで品質の重要性が増したことや事前に何をリリースするのかを他部門の方に把握していただくために必要な取り組みだと考えています。
リリースまでのフロー
障害発生時のフローの見直し
障害は起こらないに越したことはないのですが、しかしあえて障害が起こることを前提で障害対応時のフローを明確化しておくのは非常に重要だと感じています。6月時点でも障害対応フローをドキュメント化したものは存在していましたが、やや形骸化しているところがあったため細部を改めました。障害レベル判断の抽象度が高かった箇所を明確にし、またレベルごとに具体的なアクションやコミュニケーションを取る相手、想定される時間軸まで明確にしました。障害対応時には情報が錯綜しがちなので、緊急のSlackチャンネルを作って情報を集約することや、情報をストックするためのドキュメントを一元化することも有効です。
実は私がPOに着任した直後に障害が起きてしまい、焦って上手く立ち回れなかったのですが、障害対応のフローが整備されてきてからは格段に対応品質が向上しました。
障害対応時早期にやっておくと良いこと
社内コミュニケーションの課題
開発部門とオペレーション部門の相互理解
これまでに書いてきたとおり、開発体制に変更があったりプロダクトの負債により開発・オペレーションチームともに不安な状況が続いていました。
またよく聞く話ですが、プロダクトが成長し、組織自体が大きくなってくると開発組織とオペレーション組織が同じ方向を向いて歩くことは時に困難です。原因はそれまでの文化であったり、見えている視野の違いであったりと様々だと思います。しかしこのズレを解決するには、結局前提条件を合わせることであったり、お互いのコンテクストを理解し合うことに尽きるのかなと感じています。
コミュニケーション頻度を増やす
解決のために行った取り組みとしては、オペレーターの方を顧客の伝道師だと思い業務を行う上での課題やオペレーション業務のことを徹底的にヒアリングし、自分の中の現場解像度を上げることを心がけました。自分の中の解像度が上がることで、自然と共通言語も増えお互いの業務について同じ目線で会話できるようになっていきます。また開発部門とオペレーション部門はフロアが違ったりと物理的な距離もあるのですが、チャット等のツールではなくあえて対面でヒアリングを行い距離感を縮め信頼感を持ってもらうような意識もしました。ヒアリングした内容は直ちにドキュメント化し、解像度の高い情報を開発チームへ共有することでオペレーションと開発の認識齟齬を減らし、開発の手戻りを削減させることにも寄与しました。
気軽にランチコミュニケーション
その他部門横断での取り組みとして、これまで中々行えなかった部門を越えてのランチ会を行いました。エンジニアの方とオペレーションの方が直接会話することはこれまで少なかったのですが、ランチ会の中で普段のオペレーション業務のことをエンジニアが聞いたり、今どんな開発を行っているのかをオペレーションの方が聞いたりとお互いの業務に興味を持てる良い機会になったのかなと感じました。以後自発的なランチ会なども開かれていますが、古い言葉ですが「同じ釜の飯を食う」というのは現代でもお互いを知る上で大切なことだなと感じます。あと予算にもよりますが、もし会社で懇親会費などが出る場合には夜の飲み会として使わず昼のランチでぷちリッチな食事に行くのも面白い取り組みだと思います。開発チームでミシュランを獲得した事のあるウナギ屋へランチへ行った際には謎の一体感が生まれました。
とても良いうなぎ
プロジェクトを終えて
今回のプロジェクトは多くの方々に支えていただきました。開発チームとしてもプロジェクト終了後に振り返りを行い、良かったこと良くなかったことを改めて振り返りました。
改めて振り返ると、自分の所属する開発チームの中の事というのは比較的問題解決しやすいのですが、チーム外の事象になると一気にコントロールする難易度が上がることを実感しました。しかし前述しましたが、お互いの前提条件を知ることや興味を持つことでどんどん良くしていける課題だと思います。自身のチームでの振り返り後、協業を行った開発チームとも連携時の振り返りを行い今後の改善に活かせるような取り組みにしました。
時系列での開発振り返り
最後に
これまでに書いてきたような方法で課題を乗り越え、多少のずれ込みはあったものの何とかプロジェクトを完了することができました。かなり厳しいと思われていたデッドラインを守り大きな事故もなく無事リリースできたのは、様々な課題に対して個人としてではなくワンチームとして全員で考え全員で取り組むことができたからだと思います。開発チームメンバーや、開発チームを取り巻く方々には感謝しかありません。
ここまで読んで頂きありがとうございました。
引き続きグロービスのアドベントカレンダーをお楽しみください！
https://qiita.com/advent-calendar/2019/globis
この記事が気に入ったらサポートをしてみませんか？