はじめに
松戸 一真です。
普段は 株式会社edandit を経営しており、プロジェクトマネージャーや技術顧問/CTOに関する業務を請けております。
株式会社COMPASSには2021年参画し、システム全体の設計や見直しに伴う負債解消、および年単位で進行するプロジェクトのテックリードとして期待される業務を遂行致しました。
プロジェクトの一区切りとともに一度契約終了とさせていただきましたが、そのときの御縁もあり新しいプロダクトの開発相談をいただき、今回再参画致しました。
さて、株式会社COMPASSに提供した松戸の成果物の一つに、「プロジェクト進行ガイドライン」という資料がございます。
このドキュメントは、開発におけるV字モデルをベースに株式会社COMPASSの組織体制を考慮してアレンジしたものです。
メンバの役割の定義から始まり、企画/設計/開発/運用の4フェーズからブレイクダウンした業務と期待される成果物をまとめています。
過去と全く同じ成果物を納品するプロジェクトというのはほとんど存在しません。
そのため、あるプロジェクトでうまくいったやり方を別のプロジェクトでそのまま行っても通用するとは限りません。
ただ、プロジェクトの進行中に成功/失敗した理由を掘り下げて抽象化することで、今後取り組むプロジェクトで成功する確率を上げることは可能です。
本稿では、直近で開発した社内向けシステム「COMPASS Bridge」という事例を基に、松戸がプロジェクトマネージャーとして心がけていることを紹介致します。
対象読者
タイトルについて
プロジェクト・マネジャーが知るべき97のこと という書籍が株式会社オライリー・ジャパンから出版されています。
松戸はこの本を愛読しており、畏れ多くも敬意を表して本稿のタイトルに使用しております。
今回開発したプロダクト
COMPASS Bridge (以下、CB) は Digital Adoption Platform (以下、DAP) です。
DAP とは、ユーザーがシステムを使いこなせるようにすることを支援するためのプラットフォームです。
株式会社COMPASSでは、「キュビナ」と呼ばれる児童・生徒向けのアダプティブラーニング教材、およびその学習データをリアルタイムに収集・分析する専用システムを開発しています(詳細は キュビナについて をご確認ください)。
システムは日々アップデートを積み重ねておりますが、実際に新機能を利活用いただくためには、機能を認知いただくことはもちろんのこと、使い方を理解したり使用するハードル(心理的抵抗感)を下げる必要があります。
これらの課題の解消を目指したものが DAP であり、この度株式会社COMPASSの CX推進部 とタッグを組み、 CB を開発致しました(CX推進部について、詳しくは 子どもたちのよりよい学習体験を目指して、顧客の声を製品開発に届けるCX推進の仕事【メンバーインタビュー#27】 をご確認ください)。
CB では主に「アプリ内告知」と「ガイド」の2つの機能があります。
それぞれシステムを静的・動的に紹介する機能です。
各システムのトンマナを損なうことなく、かつシステム開発に携わるデザイナー・エンジニアが追加開発を必要としないシステムを実現致しました。
アプリ内告知の設定画面
生徒向けアプリのガイドの設定画面
先生向けアプリのガイドの設定画面
プロジェクト・マネジャーが知るべき3のこと
1. エピローグを作ろう
物語を想像してみてください。
ジャンルは映画や小説、漫画でも構いません。
これらの作品はなんらかの形で終幕しますが、登場人物の人生はこれからも続きます。
プロジェクトも同様で、いつか解散するタイミングを必ず迎えます。
ただ、携わったメンバーの業務はそのタイミングで終わらない事も多いと思います。
むしろここからがスタートとして、業務の規模が拡大していく事もあると思います。
CB は、「ユーザーに新機能を認知していただきたい」「ユーザーの新機能を利用するハードルを下げたい」という課題から生まれたプロダクトです。
CX推進部へのプロダクトの納品はプロジェクトの目的の1つとなりますが、CX推進部の活動はプロジェクトが終了した後も続きます。
そのため、プロジェクトが立ち上がったあと、最初に下記内容の整理を行いました。
- CB 納品後の業務フロー
- CB のメンテナンス
プロジェクトの目的は「課題を解決すること」です。
プロジェクトの前後で、関係者の行動がどのように変わるのかを解像度高く描くことはとても大切なことです。
2. 仕様検討は業務フローの整理から
プロジェクトの目的は「課題を解決すること」です。
では、具体的に何を達成すれば課題を解決したとみなすことができるでしょうか。
理想状態を考えるためには、あわせて現状を正しく把握することが大切です。
ギャップが大きければ大きいほど、達成できた時のインパクトも大きくなります。
これは改善の余地があることを示すだけではなく、検討した運用が現実的かどうかを見直すポイントともなります。
CB では、現状の業務フローを把握するために、以下を整理しました。
- 携わっているメンバーは、普段どのように業務を行っているか
- メンバーが使用しているシステムにどのようなものがあるか
- メンバー および メンバーが使用しているシステムは、どのような リポジトリ/データベース/ストレージ を活用しているか
これを踏まえて、「ユーザーに新機能を認知していただきたい」「ユーザーの新機能を利用するハードルを下げたい」という理想状態を達成するために、 CB 導入後の業務フローとして下記を整理しました。
- CB を操作するメンバーをどのタイミングで追加/変更/削除するか
- いつ、誰が、どこで CB を操作するか
- CB で設定した「アプリ内告知」「ガイド」をどのようにブラッシュアップしていくか
プロジェクトは大抵、多くの関係者、ならびに多額の費用の上で成り立つ活動です。
それを「絵に描いた餅」としてしまうことは避けなければなりません。
3. 「ドキュメント」はコミュニケーションのインターフェース
プロジェクトには大抵、多くの人が関わります。
関係者のプロジェクトへの関わり方は様々で、マネージャーが直接コミュニケーションを取ることができない場面もあると思います。
これを解消するのがドキュメントです。
設計やプロジェクトのスケジュールを口頭で伝えることには限界があるため、言語化した資料を蓄積していく必要があります。
とはいえ、ドキュメントはただ記せば良いというわけではなく、下記のような課題もしばしば発生します。
- 文章に誤謬や矛盾があり(古くなった情報を含む)、正確な意図が伝わらない
- 受け手がテキストベースでのコミュニケーションに慣れておらず、理解が頭打ちになる
これらの課題に取り組むために、 CB では会議や slack 上のコミュニケーションを以下のように定義して進行致しました。
- 会議は「作成した資料を読み上げること」と「資料へのフィードバック」の2つで進行する
- 資料へのフィードバックは原則その場で資料を直接修正する
- Slack で質問を受けた場合、回答の概要と併せてドキュメントの場所を提示する
- 回答の概要はSDS法のS, ドキュメントはSDS法のDに相当
プロジェクトを正確に理解できないことで最も困るのは、プロジェクトを理解したいと考えている人本人です。
プロジェクトが解散してからも色褪せない文章を残すことは、プロジェクトマネージャーの責務であると考えています。
終わりに
プロジェクトマネジメントはとても面白い仕事です。
限られたリソース、差し迫るスケジュール、そして湧き上がる無数の要求を前にして、どうすれば全員が幸せになれるかを考え抜くことはとても創造的な活動です。
松戸がプロジェクトマネジメントを行う上で常に意識していることの1つに「再現性」があります。
成功/失敗体験を1つ1つ昇華することが、最大公約数を大きくするために必要なことだと考えています。
そんな現代のアートの1つとも呼べるこの創作活動を、これからも楽しんでいけたらと思います。
Appendix
COMPASS Bridge のシステム構成
成果物
- 管理画面
- COMPASS Bridge が表示するアプリ内告知やガイドを設定するためのシステム
- Web ブラウザからのアクセスを想定
- ライブラリ
- COMPASS Bridge を使用する各プロダクトで、管理画面で設定したアプリ内告知やガイドを表示するためのライブラリ
- 各プロダクトのフロントエンドに npm パッケージとして組み込むことを想定
採用技術
COMPASSの技術スタック紹介 に記載されていない技術は採用理由も添えています。
フロントエンド/バックエンド共通
- プログラミング言語
- TypeScript
- Node.js ランタイム
- deno
- GraphQL のフロントエンド/バックエンド間の型共有
- GraphQL-Codegen
GraphQL 採用の理由
- 新しいエンドポイント/フィールドを構築した際の総実装量が、 REST API と比較して小さく抑えられると見込んだため
deno 採用の理由
- TypeScript のまま実行でき、かつ linter や formatter, test などのエコシステムが充実しているため、ほぼ追加の設定がなく環境構築ができると見込んだため
- npm package を publish するビルドツールが deno 公式から提供されているため(dnt)
フロントエンド
- メタフレームワーク
- astro
- CSS フレームワーク
- tailwindcss
- リッチテキストエディタ
- tiptap
astro 採用の理由
- 特定の UI フレームワーク(React, Vue など)への依存をなくすことで、将来 React 以外のプロダクトで CB を利用したいとなった際の改修工数を抑えたいため
- Next.js 以外の可能性の探究
バックエンド
- API サーバフレームワーク
- hono
インフラ
- PaaS
- GCP
- Firebase
- IaC
- terraform
Firebase 採用の理由
- Firestore Data Bundles を採用することで、要件定義中に上がった下記2点の課題をクリアできると見込んだため
- 特に生徒向けのサービスで大量配信が想定されるため、アプリ内告知・ガイドの配信は静的ファイルに出力し CDN でできる限りキャッシュを効かせたかった
- サービス側で柔軟なデータ操作を行いたかった
参考文献
プロジェクトマネージャー
DAP
COMPASS より
最後に、、、
株式会社COMPASSでは一緒に教育をより良くしていく仲間を募集しています。
少しでも興味を持っていただけた方は、以下よりお気軽にご応募ください。
とりあえず話をきいてみたい！という方はぜひカジュアル面談に来ていただけると幸いです。
Discussion