GAS×BackLog×Slackで一人PMOしてる話

自己紹介

初めまして!
現在、株式会社エアークローゼットにて「PMO」をやらせていただいております、Horizohと申します。
エアークローゼットアドベントカレンダー2021の21日目の記事として、「PMO業務を自動化しちゃった」お話をさせていただきます!

株式会社エアークローゼットでは、各プロジェクトリーダーが日夜お客様のUXを高めるようなワクワクするプロジェクト(以下、PJ)を企画・立案し、デザイナやエンジニアの手によって数々の機能や体験価値を生み出していますが、その中で私は、

  • 全体的なエンジニアのリソース管理

  • 各PJを俯瞰したQCDの管理

  • PJ間の情報の橋渡し

などを役割とするPMO(一人)として、日々業務にあたっています。

今回は「エアークローゼットにおけるプロジェクトマネジメントを仕組み化/自動化して、一人PMOを実現できている」現状について、そこに至るまでの経緯や課題感、ターニングポイントなどをつらつらとご紹介できればと思います。

なお、同じチームとしてPJの仕様設計や検証に対してのアプローチを行っているRiberyさんも弊社の「設計プロセス」についての記事を書いてくれています!こちらもぜひご一読ください!

Joinした当初のプロマネ

私がJoinした2020年度の4月時点では、会社として管理媒体であるPMOの役割自体がそもそも存在しませんでした。

さまざまなステークホルダーが関わるPJ管理の標準フローもなく、「プロジェクトマネジメントそのものが存在しないこと」が会社としての大きな課題でした。

(当時、社内のすべての稼働中PJを一覧化したスプレッドシート1枚だけが引継ぎ資料でした。)

そこでまず始めたのは「理想とするPJフローの定義」でした。

現状稼働中のPJを参考にしながら、進行フローを約90プロセスに細分化し、大まかな進捗を確認できるタイミングにマイルストーンを設定して、あるべきPJフローの構築を進めていきました。

いままでなんとなく言語化されていたノウハウや、各ステークホルダーが個別で持っていたイメージをヒアリングしながら、丁寧に、理想とするフローの流れを定義していきました。

また、既に社内で用いられていたタスク管理ツールである「BackLog」を用いて各プロセスをチケット化し、担当者と期限の管理をすることで「どのステークホルダーから見てもPJ進捗が明確である体制」を整え、見える化を徹底していきました。

結果、管理コストがボトルネックに…

PJフローも定まり、BackLogによる各プロセスにおける完了状態の見える化の土台も整い、いざその通りに実際にフローを進められるように管理しようとしますが、当初は全く機能していませんでした。

一番の課題は「各ステークホルダーのチケットの更新漏れ」で、突然細分化された各プロセスの担当者が運用についていけず、BackLogのチケット更新を忘れたり、更新のタイミングがわからなかったために、BackLogを見てもPJの状況がわからない問題が頻発しました。

ひとまず、各プロセスごとの担当者に直接声を掛けたり、社内の連絡ツールとして利用しているSlackを用いてヒアリングするパワープレイが続きますが、

  • リモート環境だったため、そもそも同期的な連絡がしづらい

  • 正となるプロセスへの理解が浅く、状況確認時にインプットも並行して実施することになる

など、せっかく細分化したプロセスによって、結果的に管理側の首を苦しめる形が続いてしまいました。

当時、管理コストを完全に人的リソースに頼り切っていたので、
「今後のリソースの増大に比例して、管理工数をいたずらに増やす余裕はないし、このままの流れであるべきを追うままでは破綻してしまう…」というイメージが現実的になってきたタイミングで「PJ管理の自動化」を検討し始め、
ちょうどその折にRyanさん(弊社のサムライCTO)に当時簡単な社内の仕組み化で用いていた「GAS」(GoogleAppScript)をご教授いただいたのがターニングポイントでした。

GASを用いたPJ管理の自動化

GASとは、Javascriptによって自動化の仕組みを構築できるプラットフォームで、

  • 各Googleリソースを操作する

  • APIのGETやPOST処理をする

  • 決められた時間に自動実行する

  • などの機能を、Googleのアカウントがあれば完全無料で利用できる

という、ざっくりいうと「タダで使えるサーバー」です。

GASを利用することで、BackLogが提供するAPIなどの外部APIを利用した仕組み化が完全無料で構築できるため、

  • あらかじめ定義したPJのフロー定義をもとに、想定通りのチケットの情報更新ができているか?

  • 定義されたマイルストーンに間に合っていないチケットが存在しないか?

などの、運用に照らし合わせた各種チェックだけでなく、SlackAPIと組み合わせることで異常値に対する自動通知も実装できるイメージが膨らみました。

私自身、前職でのエンジニアの経験があったので、言語としての学習ハードルが低いJavascriptを扱えたことも功を奏し、早速フロー定義に沿ったBackLogのチケット監視ロジックを設計し、実装していきました。

大枠の構成は以下の通りで、構成としては非常にシンプルです。

  1. BackLogからチケット情報を取得し、

  2. フロー定義に照らし合わせて、「マイルストーンまでに未完了の状態のチケットがないか?」をチェック

  3. 未完了チケットがあればチケットの担当者に通知し、現フェーズの完了条件を満たしていれば、チケットの状態更新をしながら次フェーズの担当者に開始通知を出す

  4. GASの自動実行機能により、1~3を定期実行する

という流れで「1時間に一度、稼働中PJに関わる全てのチケットについての監視をする」形にしました。

システム構成の概要図

前提として用いていたBackLogのカスタマイズの自由度が高かったこともGASとの相性が良いポイントであり、

  • チケットどうしに親子の関係性を持たせられることから、1PJ=1親チケットという区切りとし、各PJごとに発生する細かなプロセスを子チケットとして紐づける構成にできた。

 ⇒PJ単位での検証を実装しやすかった。

  • チケットの種別や状態を好きなように追加できた。

  • 「カスタム項目」という形でチケットに対する入力項目を増やせた。

 ⇒フロー定義に合わせた細かな・流動的な検証ロジックに耐えられた。

点が非常に大きなメリットで、「管理運用そのものに対するトライ&エラーが回しやすい」状態を作ることができました。

PJ単位で作られるBackLogチケットの例
各プロセスを細分化して、親子で紐づけて管理しています。


チケットの中では、カスタム項目というもので自由に入力項目を作れます。
↑はほとんどすべて独自に作ったカスタム項目です。

「タスク未完了の担当者への通知Bot」として、「1度通知がされたが最後、きっちりとタスクを完了させたり、正当な理由をもって期限調整しなければ、鬼の形相で追い詰める」ブランディングを浸透させるため、「HoriOniBot」と名付けました。

(最終的にはSlackにて通知が届くため、SlackBotとしての立て付けにはなりますが、根本的にはGAS駆動で成り立つ仕組みではあります。)

開発当初のHoriOniBotからのSlack通知
「アイコンが怖すぎる」というフィードバックを受けて、現在は泣く泣くシンプルなアイコンにしています。

一人PMOの土台が完成

「HoriOniBot」が稼働してからは、

  • 各ステークホルダーに対して、いちいち完了確認しに行く手間が削減した。

  • トップダウン型の確認→ボトムアップ型の報告 という変化を促し、運用の理解度が高まった。

という管理側の課題感の解決につながっただけでなく、

  • 直接の連絡を待たずとも、次フェーズの作業メンバーは受け身で構えておける。

  • どこで言われたか、いつ言われたかをボールを受け渡す双方がほとんど意識しなくてもよくなった。

のような、各ステークホルダー目線でのメリットも大きく感じることができました。

わざわざそれぞれの稼働メンバーに直接ヒアリングをしなくても稼働中のPJすべてを定期的にチェックしてくれるので、実際に一人PMOを達成することができました。

構想から実装、全体向けの共有を経た運用の開始ののち、実際の反応に合わせた仕様の調整を実施しきるまでを約2週間ほどでやりきることができ、大きく環境の変化を起こすことができたのは、会社/組織として「変化を恐れない」風土が整っていたことも非常に大きかったように思います。

また別軸の施策により、PJのボリュームそのものを定量評価できるような単位も組み合わせることでBackLogチケットに対する「生産性」の情報も付与することができ、エンジニアの稼働ボリュームを定量的な集計や分析も可能になるなど、自由度の高いBackLogとGASを組み合わせたことで非常に柔軟な仕組み化の土台を形成することができました。

さらなる改善を目指して

現在はこのGASのノウハウを活かして、PJ管理をより効率的に、確実に、迅速に行うための改善を継続的に行っています。

直近だと、

  • PJの企画書をスプレッドシートで作成し、ボタン一つでその内容を反映したBackLogのPJ用のチケットを作成し、各PJ用に紐づく専用のSlackチャンネルの自動生成を行う仕組み化

  • BackLogチケットの期限日をGoogleカレンダーに反映させて、カレンダー上でガントチャートが確認できる仕組み化

等々の仕組み化もリリースしています。

何よりもうれしいのは、現状のチームメンバーが皆エンジニア経験があることで「GASの多人数開発」を実現できている点です。

各メンバーそれぞれで課題の起票→設計→実装→レビュー→リリースをサイクルとして回すことができており、本当の意味で組織としての「PMO(Project Management Office)」が作れていると実感しています。

チームメンバー全員で課題感を共有しながら、日々目に見える改善を回すことができている環境は非常に刺激的です。

今後もGASの力を借りながら様々な課題に立ち向かっていき、チームとしてさらなる高みを目指していきます!