「コスト伝えるちゃん」から学ぶプロダクトマネジメントについて #ProductManagement #コスト管理
こんにちは。 Data Platform & Cloud Solution Team 所属の渡辺です。タイトルに「コスト伝えるちゃん」とありますが、何のことかと思われた方いると思います。「コスト伝えるちゃん」とは2022年頃に弊社社内で抱えていた課題を解決するために作ったツールです。
本ブログはこのツールを例にダイジェストでプロダクトの開発の流れ、プロダクトマネジメント、を見ていきたいと思います。今回のブログはこれから product を準備する方たちの「気づき」となってもらえると幸いです。
コンテンツは次の通りです。
- What is a product ? - プロダクト (product) とは何か?
- The Ideation - コスト管理者が抱えていた課題
- Go-to-market ? - 外のマーケットは開拓するのか？
- Product development - 問題解決のために整えた仕組み
- Product lifecycle - ライフサイクルの開始
- Value proposition - 一体何を解決したのか？
- 最後に
TL ; TR ;
What is a product ? - プロダクト (product) とは何か?
私は日ごろからお客様と product 開発を進める上で「問題や課題の解決を行えるモノ」という点をとても重視しますが、ここでは少し客観的な視点から考えたいと思います。
product という言葉自体の意味は様々なサイトで説明されています。 what is a product ? と検索すれば多数出てきます。その中でも 個人的には Scrum.org は 直観的で分かりやすいと思いました。
A product is a vehicle for delivering value, meaning valuable outcomes, to customers.
product という言葉の定義は前述の定義で個人的にはしっくりきますが、では「その存在意義を模索し、先導する立場の人」である Product Manager の役割から見た product を見てみましょう。 ※ Product Leadership は別です、という意見もありますがここでは厳密には分けません。
Product Management 界隈での influencer である Martin Eriksson のブログでは、Martin Caygan氏の言葉を引用し次のように述べています。
to discover a product that is valuable, usable and feasible
ご本人は product management (プロダクト管理) を次のように定義をしています。
Similarly, I’ve always defined product management as the intersection between the functions business, technology and user experience
私はこれらの文章を読んだとき、「人」の視点から見た product とは valuable （価値ある）とは別に、usable （使える）そして feasible （実現可能）であるという特性を合わせ持つ「モノ」であるという点の大切さにとても共感しました。
The Ideation - コスト管理者が抱えていた課題
さて本題に入りたいと思います。
弊社の主な事業は サプライチェーン において「IT サービス」で社会に貢献するお客様をサポートしている立場です。従って、様々なお客様とお相手させていただくことから、お客様を支えるための技術といったところは多岐に渡ります。そのような事業モデルの中で、社内で組織は目的別に分かれ、検証に利用するパブリッククラウドのコストやリソースの管理を行う担当者が各部門毎に存在していました。
以下はイメージになります。
パブリッククラウドを利用されたことがある経験をお持ちの方は分かると思いますが、当然、各事業者ごとにサービスの ユーザー体験やユーザインタフェース は異なります。当時、管理者の役割を担っていたのは、各部門の「リーダー」であり、「クラウドのリソース利用費用を見るのに事業者毎に異なる画面をブラウズしなければならない」、という点に煩わしさを感じていたのが解決をしたい点でした。
以下の図は実際に product の開発を前に行った Ideation (アイディア化の作業) の一環になります。ここでの作業でとても重要になるのが、primitive な問いをすることでした。例えば、次のような問いです。これらの問いの答えが、創造するべき「価値 value」につながります。
※ 個人情報はマスキングしています。
問題提起をしたチケット
具体的に product に必要な value proposition を考えたチケット
利用者となるリーダーの方たちと会話を続け、問題を解決するべく、我々は、「複数のクラウドの利用費用を一元的に見れる場所」を解決策として選びました。同時にこの「仕組み」をコスト伝えるちゃん と命名しました。
Go-to-market ? - 外のマーケットは開拓するのか？
まずは、「社内のお客様」を対象に立ち上がったわけですが、当然、多くの事業者の方がそうであるように、「外のお客様」も同じ問題を抱えていないか、という視点も持ちました。こちらの話は本ブログのスコープ外なので詳細は触れませんが、ビジネスモデルの草案まで考えた点をご紹介しておきます。
実際に考えたビジネスモデルのドラフト
Product development - 問題解決のために整えた仕組み
さあ、解決しようかと言っても、昨今、様々な技術が存在し、多くの人がそうであるようにどこから手をつけるのかという状態でした。私含め、パートタイムのメンバーが3人程度のチームで始めたのであまりコストはかけられませんでした。そこで我々はディレクショニングを行い、次の点に留意して進めました。
- Model driven (モデルドリブン）
- Flexible architecture （柔軟性を期待したアーキテクチャ）
- Fast development（迅速な開発）
モデルドリブン
ご存じの方はいらっしゃるかもしれませんが、Eric Evans の Domain Driven Design でも紹介されている通り、 Model は 「地図」です。そして、自分たちが初めに必要としたものですね。
Maps are models, and every model represents some aspect of reality or an idea that is of interest
Domain Driven Design , P2 より引用
まずは、「お金の流れ」の整理から始めました。すると浮かび上がった全体像は、複数のステークホルダー（経理とリーダー）がクラウド利用費用に関わっていて、各々の目的で「数字」を利用しているという点です。重要なのは product を作る上で「整合性」が取れた状態で slack 通知をする必要がある点が分かりました。
整理したドメイン図のスケッチ
柔軟性を期待したアーキテクチャ
前述の model から シンプルに ETL （Extract Transform Load）のアーキテクチャを選定。技術スタックを選定する際には、メンテナンスのコスト及び信頼性等の Quality attributes (ISO25010) を総合的に考慮しました。また、AWS のフルマネージドのサービスを活用しつつ、以下の要件を踏まえたアーキテクチャです。
- 定期的に slack に通知。各クラウド事業者の請求の更新時期に従う。
- 過去に遡りデータにアクセスするデータアクセス要件が無い
- カスタマイズしたメッセージを slack に通知したい
- 利用者が求める請求情報が増える見込みは一旦は無い。
概念図
迅速な開発
実際には Python を用いましたが、コーディングは私一人でした。そのため、継続的インテグレーション/デプロイメントを整え、unit test や static code scan といった自動化できるものは機械に任せました。これにより、プロダクトの glitch （破損）を早期に検出できる仕組みを確保しました 。
Product lifecycle - ライフサイクルの開始
無事開発を終え、リリースすることができました。ここでライフサイクルという点を一つメンションしておきたいと思います。
- 再現性
- 利用者からのフィードバック
もし、この product が外販となると話が変わります。競合他社と顧客獲得の競争となるため以下のようなライフサイクルを考慮した上で、ライフサイクル毎のプロダクト管理が求められます。本ブログでは具体的な話は省略します。
GMO 社のページより引用
再現性
今回は社内向けの product であったため、いわゆるプロダクトライフサイクルという意味では、開始と終了はとても重要視しました。つまり、効率的に product を 活動状態に戻せるし、終了状態に戻せる、といった点です。技術的には、IaC (terraform, wikipedia) でクラウド環境を再現し、コード含む構成情報は Git で管理しておき（GitOps のエッセンス, Alex Richarson のインタビュー）、「人」が product のライフサイクルを制御できる仕組みを整備しました。
利用者からのフィードバック
プロダクトを成長させるという意味では利用者からのフィードバックはとても重要になります。限定された社内の利用者を考えていたこともありましたので、フィードバックの仕組みはツール等は使わず、定例会での定期的なインタビューに留めていました。フィードバックがあり次第、すぐに product へのフィードバックを行いました。
Value proposition - 一体何を解決したのか？
果たしてどのような value を提供できたのか。利用者からの口頭でいただいたフィードバックをもとに wrap up したいと思います。
各部門のリーダー達からはフィードバックとして、普段使い慣れているチャット画面で求めているチャット画面で請求情報に辿りつけるようになった点を評価いただけました。
機微情報をマスキングした実際の slack 画面
今回は North star metric といった指標値は用意しませんでしたが、具体的な利用者のフィードバックといった定性的な形で評価を終えました。
今では、利用者は増え、その他の部門（e.g. 情報システム部門）の人たちも情報にアクセスできるようになりました。ただし、アクセス権限には十分に注意した上での公開としています。
最後に
いかがでしたでしょうか？ 昨今、様々な問題や課題の解決のために、product を準備する企業の方たちは増えていると思います。もちろん、 「プロダクトの管理」というのは、組織、環境、政治といった様々な条件でその方法が変わってきます。
社会に貢献しようという方達の気づきに少しでもなれれば幸いです。
