はじめに

さくらインターネットでは数多くのサービスを開発し提供しています。それらを開発する中でどのようなマネジメントを行っているか、およびそれらの経験から得られた知見を共有する会を社内イベントとして実施しました。本記事では、この知見共有会の模様を2本に分けてレポートします。当日は4人のエンジニアが発表しましたので、それぞれの発表について紹介します。

さくらのIoTにおけるプロジェクト管理術

1人目の発表者は小田島太郎さんです。小田島さんが所属するIoTプラットフォーム事業部は、「さくらのセキュアモバイルコネクト」「さくらのモノプラットフォーム」といったIoT関連サービスを開発・提供しています。小田島さんからは、同事業部で試行錯誤中のプロジェクト管理手法が披露されました。

プロダクトとプロジェクトとタスクの関係

はじめに、この発表で重要な3つの用語の説明がありました。

プロダクト：「さくらのセキュアモバイルコネクト」などの製品・サービスのこと。それを提供している限り、終わりはない。
プロジェクト：プロダクト内で達成すべき個々の目標。例えば、機能追加、広告出稿など。終わりがある。
タスク：プロジェクトを完了させるのに必要な作業項目。例えば、実装、デプロイ、告知など。終わりがある。

作業報告の問題点

次に、プロジェクトの進捗管理に欠かせない作業報告に関する問題点を指摘しました。作業報告の目的はプロジェクトが予定通り進んでいるかをチームメンバーに把握してもらうことですが、一般にプロジェクトは複数が同時進行しているので、単に「○○をやりました」だけでは、それが全体のどの部分にあたるのかを把握できません。

プロジェクトの4W1H

ではどうすればよいかですが、まずプロジェクトに必要な要素として4W1H (Who/Why/When/What/How)を定めます。Whatはどんなプロジェクトかで、Whoとしてプロジェクトの責任者を1名(2名以上でなく1名)決めます。責任者はプロジェクト完遂に必要なタスク(How)を洗い出し、それらに担当者(Who)と期限(When)を設定します。それから、そのプロジェクトやタスクはなぜ実施する必要があるのか(Why)を考えることも重要です。そして、洗い出したタスクをすべて実施し、これ以上何もすることがなくなったらプロジェクトは完了となります。

Trelloを使った管理方法

これを管理するために、小田島さんのチームではタスク管理ツール・Trelloの有償版を使用しています。Trelloのリストとしては「要対応」「対応中」「今回作業した」「完了」「先方待ち」「却下」があります。各リストの中にはカードが並びますが、このカードがプロジェクトです。

プロジェクトを登録する際はテンプレートを使用します。テンプレートには、そのプロジェクトの4W1Hに加えて完了状態を記載することになっていて、完了状態を定義できるものだけをTrelloに登録しています。プロジェクトの中にはタスクが並び、各タスクの担当者や期限が設定されます。

それから、プロジェクトにはアクティビティログを記入する欄があります。進捗があったときだけでなく、予定通りに進んでいないときや相談事があるときなど、とりあえず何かあったらここに書きます。そして、アクティビティログが更新されると、Trelloのオートメーション機能により、そのカードが自動的に「今回作業した」リストに移動します。定期的に実施している作業報告会では、この「今回作業した」リストを確認します。

作業報告会の進め方

作業報告会については、まずルールとして、内職禁止・マイクON(しゃべらないことに慣れてしまわないように)・カメラON(リモートワークでは表情は大事な情報だから)を設けています。

報告会の冒頭に作業時間があり、ここでチームメンバーはアクティビティログの更新を行います。

次に「今回作業した」リストに入ったカードを順番に見ながら、更新した人が報告します。よくあるチームミーティングでは人ベースで報告が行われますが、ここでは人ベースではなくプロジェクトベースで報告が行われるので、プロジェクトの状況がわかりやすいです。

報告を終えたプロジェクトは、このあとどうするかに応じて適切なリストに移動します。これを「今回作業した」リストが空になるまで行います。最後に、報告がなかったプロジェクトを見ていき、責任者に状況を確認します。

まとめと感想

IoT事業部におけるプロジェクト管理の手法をお伝えしました。プロダクトとプロジェクトの関係や、プロジェクトの管理方法など、説明もわかりやすく、自分たちが携わっているプロダクトにも取り入れやすい方法だと思いました。

ユーザー価値とプロダクト

2人目の発表者は、さくらインターネット研究所の野田宗一郎さんです。野田さんはかつて当社が提供していたWebアプリケーションプラットフォーム「Hacobune」の開発に携わっていました。そのときの経験から現在の研究活動で得た知見を共有しました。

プロダクト≠サービス、ユーザー≠顧客

こちらも発表で使う用語の説明がありました。

プロダクト：ユーザに価値を届けるもの。期限はなく育てていくもの。
サービス：プロダクトをコアとしてユーザに届ける価値や体験の総称。サービスがプロダクトやサポートなどを内包している。

さくらのレンタルサーバを例にすると、「さくらのレンタルサーバ」がプロダクトで、申し込み、決済、運用、サポートなどがサービスとなります。

ユーザー：サービスを使う人
顧客：サービスに金を払う人

ユーザーと顧客は異なる場合もあります。例えばエンジニアが有償サービスを利用したいのでマネージャーに購入をお願いすることがありますが、これはユーザーがエンジニアでマネージャーが顧客となります。

プロダクトマネジメントとの出会い

Hacobuneはエンジニア3人で開発していましたが、「作ってはみたものの誰が使ってくれるんだろう」「この機能は必要なのか？」「売りたいけどどうすればいいのかわからない」「技術的な観点だけで話し合ってしまう」などの悩みを抱えていました。このまま開発を続けても単にリリースすることだけが目的になってしまい、ユーザも開発者も不幸になるのではないかと考えていたところで出会ったのが「プロダクトマネジメント」です。

プロダクトマネジメントとは

プロダクトマネジメントとは、プロダクトを成功に導くためのマネジメント手法です。プロダクトの成功とは、作り出したい世界観を達成し、ユーザーのニーズを読み取り、ユーザーが欲しかった価値を提供し、収益を達成できている状態を指します。

プロダクトマネジメントを知ることで、プロダクト作りを体系的に学ぶことができます。さらに、UXデザイン、事業戦略、マーケティングなど、さまざまな領域の知識も得られます。野田さんはプロダクトマネジメントを知ることで以下のような変化がありました。

エンジニアの時にあった技術中心の思考ではなく、ユーザーへの価値や体験を重視する思考になった
ユーザーインタビューやフィードバックから課題を見つけてプロダクト開発を進めるようになった
フィードバックをもとに振り返りを行うことで、機能の取捨選択やUIの改善を素早く判断できるようになった

プロダクト開発で重要なこと

野田さんは、プロダクトマネジメントの考え方をもとに、プロダクト開発において重要なことをいくつか挙げました。

まずはMVV(ミッション・ビジョン・バリュー)です。ミッションは「プロダクトを通して社会のためにやりたいこと」、ビジョンは「ミッションを実現するために目指すあるべき姿」、バリューは「プロダクトを作る人の行動指針」です。これらを明文化しておくことでさまざまな判断の基準とします。

次はユーザー価値です。ユーザーの課題を整理し、ユーザーが本当に欲しかったもの(ユーザー価値)を見つけ出すことが重要です。

もう1つは時代の変化への対応です。現代は類似のプロダクトがあふれ、機能による差別化が困難になっています。そんな時代だからこそ、ユーザー価値を見つけながらプロダクトを作っていくことが重要になっています。

プロダクトマネジメントのフレームワーク

プロダクトマネジメントを実践するためのフレームワークは数多く存在します。よくわからないまま使うと混乱するので、役割や使う場面を整理し、適材適所で使っていきます。野田さんは下図のように整理しています。

フレームワークを使う上での注意点として、フレームワークは有効な道具ですが、答えを出してくれるものではありません。答えはあくまでも自分たちで見つけ出すものです。

プロダクトマネージャーと組織

プロダクトマネージャー(PdM)とは、プロダクトマネジメントを行う人です。「マネージャー」という言葉から人を管理する役職を連想しがちですが、そうではなくプロダクトの管理をします。役割としては、プロダクト全体の方向性を示すだけでなく、テクノロジー、ビジネス、UXも守備範囲となるので、幅広い知識が必要です。ただしPdMがすべてやるわけではなく、各分野に専門家がいれば分担するという感じです。PdMを置いたときの組織図を下に示します。

そして、プロダクトマネジメントは、プロダクト全体を知るには良い手法ですが、各分野を深く追究するわけではないので、プロダクトマネジメントだけやれば良いプロダクトができるわけではありません。各分野のプロフェッショナルを集めた上でプロダクトマネジメントの手法を活用し、プロダクトの方向性を示すことが良いプロダクト作りにつながります。