LayerX エンジニアブログ

LayerX の エンジニアブログです。

SaaS.tech #3 で登壇しAmazon Cognitoでシュッと認証基盤を作る話をしました

こんにちは、眠れる銭をActivateしたい武市@tacke_jpです。

先日のSaaS.tech #3で、三井物産デジタル・アセットマネジメント(※)で認証基盤としてCognitoを導入した経緯やその実装についてお話させて頂きました。

※LayerXが出資しており複数メンバーが出向しているJVです。

www.youtube.com

speakerdeck.com

当日はLive配信で100人ほどの方にご覧頂きました。ありがとうございました。

登壇内容

少しだけ登壇内容を紹介します。

三井物産デジタル・アセットマネジメントでは社内向けのWebアプリケーションが複数存在しており、それぞれの認証情報を統一して管理したいという要望がありました。各Webアプリごとにpasswordを払い出して保存する方式だと、社内から「パスワード忘れたので再発行してください!」という依頼に毎回対応するのが面倒くさいですよね... これは避けたい。

三井物産デジタル・アセットマネジメントではMicrosoftのAzure ADを従業員のID基盤として採用しているので、外部のSaaSを契約する際はできるだけAzure ADへのSSOを設定してアカウント管理コストを下げています。であれば自前開発のWebアプリでも同様にしたい...!

また現状社内で使っているWebアプリケーションを将来的にパートナー企業にも開放し、メールでのコミュニケーションを代替したいという要望もありました。

というわけで、Amazon CognitoをID基盤として据えて弊社のAzure ADやパートナー企業のID基盤と連携することで、アカウント管理の手間を省けてかつ利用ユーザーの体験もよい仕組みを作りました。

このように既存のサービスのアカウント連携によりpassword管理フリーなWebアプリの認証をシュッと実現したいシチュエーションは結構ありそうかなと思うので、良ければ参考にしてみてください。

最後に

三井物産デジタル・アセットマネジメントでは不動産アセットマネジメント業務のDXを強力に推し進めているのと、個人向けに証券を販売すべく今急ピッチでプロダクトの開発・立ち上げを行っております。ご興味がありましたら、是非以下のFintech事業部のポジションにご応募ください!

open.talentio.com

社内業務も(バク)ラクに ーZoom背景作成をバクラクにしたハナシー

この記事は、【2022 春 LayerX Advent Calendar(概念) 】30日目の記事です。前回はインサイドセールスチームのMJさんの記事でした。

note.com

こんにちは、SaaS事業部でデザインを担当しています森です。

SaaS事業部では経理業務をバクラクにするサービスを提供していますが、今回は社内業務を少しラクにしたお話です。

bakuraku.jp

みなさん様々なツールや仕組みで業務を効率化されていると思いますが、画像作成などのデザイン作業はなかなか人の手から離れていないのではないでしょうか?

当社でも、名前入りのZoomの背景の作成などが、社員が急増しているなかで地味に手間になってきています。

制作はFigmaを使っていて、名前を入れて画像を書き出すだけですが、地味に手間なのとデザイナー以外がその作業をする場合、そのためのライセンスが余分に必要だったりと、問題があるので自動化することにしました。

f:id:hiroakimori:20220411143451p:plain
温かみのあるFigmaでの作業

仕組みを作る上で考えていたことは以下の4つです。

  • コードを書きたくない
  • サーバーを建てたくない
  • インターフェースを作りたくない
  • メンテナンスは誰でもできる

コードを書きたくない

書きたくないです。

画像に任意のテキストを合成して生成することは難しくはないのですが、書かないですませたい。なぜって、

  • どこで動かす?
  • 何で書く?
  • リポジトリは?
  • デプロイは?
  • 誰が管理?

考えたくないですね…

当社mosa_siruの言葉を借りると「作ったものは必ず負債になる」ので、より負債の軽いものにしたかったです。

www.slideshare.net

サーバーを建てたくない

建てたくないです。

  • どこで…(以下略)

考えたくないですね…

インターフェースを作りたくない

作りたくないです。

  • どこで…(以下略)

インターフェースは極力ない方がいいと思う派です。
特定の場所(URLとか)を用意して、使い方を覚えてもらう。それも、毎日使わない機能に… 全然、行動のコストとして見合ってないように思います。

メンテナンスは誰でもできる

コードを書いたり、サーバーを用意したりすれば、それを理解できる人しか管理できなくなります。
開発メンバーが使うツールならいいかもしれませんが、開発以外のメンバーには敷居が高いですよね。

ではどうやって画像を生成するか?

コードを書かないで画像生成する方法を探します。

上記のように制作にはFigmaを使っていたのでFigmaAPIを考えましたが、読み出し系のものしかないので早々に却下。

https://www.figma.com/developers/api

検索をさまよっているうちに、APITemplate.io というサービスを見つけます。

apitemplate.io

レイアウトのテンプレートに、画像とテキストを流し込んで広告画像を量産する、ような用途向けのサービスでしたが、GUIを使ってレイアウトのテンプレートを作成でき、日本語を含むGoogle Fontが使えたりもして機能的に十分でした。

f:id:hiroakimori:20220411143720p:plain
テキストや画像にキーが設定されるので、API経由で差し替えて画像やPDFを生成できます。

インターフェースは?

バグ報告や機能要望の発言にスタンプを付けるとAirtableに起票されたり、情報の取り出し口など、日頃からSlackを使った自動化を行っていることもあり、ほぼSlackだろうと考えていました。

f:id:hiroakimori:20220411145657p:plain
情報の取り出し口

Slackをつかうメリットは、

  • 日常的に使っている
  • 誰かが使っている様子が見えるのでマネできる
  • トラブルや間違った使い方を見かけたら助言しやすい

などがあげられます。

当社プロダクトの「バクラク申請」でも、Slackで申請を承認できる機能は、承認が爆速で進むと評価をいただいており、日頃から使いなれたツールをインターフェースとする事の良さがあらわれています。

prtimes.jp

Slack + APITemplate + Google Drive + zapier

機能の目処はつきました。
Slackを起点として、APITemplateで画像生成、それをGoogle Driveに保存。それらをzapierで繋ぐことにします。

f:id:hiroakimori:20220411143902p:plain
zapierのレシピ

  • Slackの特定チャンネルに、コマンド、氏名、ふりがなの3行で投稿される
  • 氏名、ふりがなをAPITemplateに渡して画像を生成
  • 生成した画像のファイル名に、氏名や日付をつけて、Google Driveに保存
  • 保存された画像のダウンロードURLをSlackで通知
  • APITemplateから生成した画像を消去

使うとこんな感じに画像URLが返信されてきます

f:id:hiroakimori:20220411145003p:plain

生成された画像

f:id:hiroakimori:20220411145932p:plain

これで、手間だった作業がラクになりました。

余談

実は公開してから、コマンドを受け付けるチャンネルを変更していて、旧チャンネルでコマンドが呼ばれた場合、変更の案内を返信するようにしています。これはSlackならではな感じがしますね。

f:id:hiroakimori:20220411145025p:plain

余談2

予想はしていましたがハックする人がでてきました。これはこれで楽しい。

f:id:hiroakimori:20220411145044p:plain

もっとバクラクに

今回は社内業務をラクにするお話しでした。

冒頭でもご紹介したように、当社SaaS事業部では経理業務をラクに、バクラクにするサービスを提供しています。 世の中の業務をもっとバクラクにするために、仲間を絶賛募集中です。是非ご連絡ください!

LayerX 採用情報

LayerX Company Deck

open.talentio.com

Go Conference Online 2022 Spring に Silver プランにて協賛します

LayerX は Go Conference Online 2022 Spring を Sliver プランにて応援させていただきます!

開催概要

Go Conference は半年に 1 回行われるプログラミング言語 Go に関するカンファレンスです。

  • 日程:2022/04/23(土) 10:00 〜 20:00
  • 会場:オンライン
  • 参加費:無料
  • イベント公式サイト:https://gocon.jp/2022spring/ja/
  • 主催:Gophers Japan

参加申込

以下のイベント申込ページよりお申込みください。

gocon.connpass.com

登壇情報

LayerX からはバクラク請求書でリードエンジニアをしているSaaS事業部の @yyoshiki41(中川佳希)が登壇します。

gocon.jp

また中川の Meety は以下です。ご興味ある方は是非お申し込みください! meety.net

スポンサードの背景

LayerX では、社内のプロジェクトの多くで Go を利用しています。

Go のテックコミュニティの裾野を拡げていくことの一助を担えればと思い、今回は Silver プランでの協賛という形で応援させていただくことにしました。

今回のようなスポンサードだけではなく、私たち自身が 会計 freee API のクライアントライブラリ freee-go をはじめとした OSS の公開もおこなっています。

他にも既存の OSS に対して適切な Issue、Pull Request の作成や SaaS.tech などテックコミュニティの運営などできる範囲でのコントリビューションを実施しています。

今後も LayerX の行動指針である「Bet Technology」と「徳」の観点から、テックコミュニティへの貢献を継続していきたいと考えています。

LayerX エンジニアブログには Go に関する記事が下記にまとまっております!こちらも是非ご覧ください! tech.layerx.co.jp

SaaS.tech #1を開催しました

こんにちは、CTOの松本です。最近はモノレポ構成にハマってます、アーキテクチャ設計が柔らかくなる感覚が好きです。

さて、今回は2022年3月15日にSaaS.techの第一回を開催させていただいたのでそのご報告をさせていただこうかと思います。

saas-tech.connpass.com

ちなみにアーカイブ動画はこちらに。

www.youtube.com

SaaS.techとは?

そもそもSaaS.techとはという話なのですが、本イベントはLayerXのイベントというよりも、SaaSに関わるすべてのエンジニアに向けたコミュニティイベントを目指して企画した勉強会となります。

ですので、レギュレーションとして会社紹介や採用宣伝は抑えるように設定しつつ、純粋に技術の話でワイワイできる場づくりを目指しました。個人的に、一企業で会社紹介たっぷりの構成でオンライン勉強会を開くフォーマットについてちょっと聞き手としても話し手としても疲れてしまった感覚があり、技術でワイワイできる場をSaaSカテゴリでもやりたくなった次第でした。

SaaSモデルのtoBサービスは、広く様々な会社がソフトウェアを活用しようとする上で、適切なコストでメリットを受け入れやすくするものであり、SaaSが広く普及することですべての経済活動をデジタル化することにつながると考えています。

そのうえで、SaaSモデルのプロダクト開発を進める上では、関わったことのある人ならわかる「ならでは」の課題が多々存在しています。例えばマルチテナント設計や認証認可、API連携、要件の複雑な機能へのチーム開発、品質保証、セキュリティなどなど。

この課題とそれに対する取り組みを共有し合うことで国内のSaaS全体がより成長し、メリットを享受できるユーザーが増えていくことにつながればと思いSaaSにカテゴリを絞った勉強会の開催に至りました。

知見の共有によってソフトウェア技術での躓きが減り、より成長しやすいSaaSの市場環境が生まれれば幸いです。長期で市場全体が国内、ひいては国外まで含め価値を届けられるよう、LayerXの行動指針である「徳」に紐付けて技術にフォーカスした勉強会、今後継続的に開催していきたいと考えています。

第一回はアーキテクチャ編

さて、その第一回が先日開催されたわけですが、第一回にしてはいきなり応募900名超えという巨大イベントになりました。企画した自分含め一同驚いています。当日も350名を超える方にリアルタイムに視聴していただきました。

第一回のトピックはアーキテクチャ、特にマイクロサービスか、モノリスか、という意思決定について取り扱っています。なかなか答えのない課題であり、各社の葛藤を知ることができるよい回になったように思います。

おそらく、各コンテンツについては登壇された皆様がブログを書くのではと思いますので、こちらではタイトルだけさせていただきます。 当日の資料はこちらに。

saas-tech.connpass.com

・「アプリケーションが大きくてツラい…ってこと!?」 すがわら まさのり / 株式会社 SmartHR

・「絡み合うSaaSプロダクトのマイクロサービスアーキテクチャ」 mosa / 株式会社 LayerX

・「デモつき!動かしてわかる はじめてのPact」 Satoshi Toyama / フリーランスエンジニア

・「Scalebaseがモノリスでもなくマイクロサービスでもなくモジュラモノリスを採用した理由!」 竹尾正馬 / アルプ株式会社

・「カオナビにおけるマイクロサービスの取組と今後の展開」 @hanhan1978 / 株式会社カオナビ

どのコンテンツも、これが答えだ!というものではなく銀の弾丸が無い中で何に悩み何を追い求めたのか、その悩みの過程を知ることができる良い発表の数々で、私自身としても学びとなりました。

第二回以降の運営をお手伝いいただける企業・個人の方を募集しています

今後も安定して継続開催していく上で、どのようなコンテンツで開催するか議論したり、実際にスピーカーを出していただいたり、また配信準備や懇親会運営に向けて、運営をお手伝いいただける企業・個人の方々を募集しています。

ご興味ある方、私(@y_matsuwitter)か、@serima までDMをいただければ幸いです。

最後に

SaaS事業は、広く、また適切なコストでデジタル化を届ける意味でどんどん盛り上がっていくべきものだと考えています。SaaS.techを通じて、少しでも多くのSaaS事業が拡大していくサポートとなれれば幸いです。

MySQL 外部キー制約とインデックスに必要な知識

バクラク請求書 でリードエンジニアをしているSaaS事業部の @yyoshiki41(中川佳希)です! バクラクシリーズでは、経理向けSaaSに始まりコーポレートDXをサポートする複数プロダクトを提供しています。

サービスローンチから1年経過したこともあり、2021年12月から2022年1月は短い間に事業部として怒涛のリリースの日々でした。

サービス全体で変化はありましたが今後も変わらずプロダクト開発を通して、経理・コーポレートチームの仕事がバクラクになるようサポートしていきます!

今回の記事は、MySQL の外部キー制約とインデックスについてです。

Foreign Keys

多くの人が馴染みあると思いますが改めて整理すると、2つの役割を担っていると言えます。

  1. 複数のテーブル間でインデックスとしてデータの参照を効率的に行う(外部キー)
  2. 複数のテーブル間でデータの一貫性を保つ(外部キー制約)

上記をサンプルのテーブルを使って具体的にみていきます。

外部キーの作成とインデックス

親テーブルとその外部キーをもつ子テーブルを以下のSQLで作成してみます。

CREATE TABLE `parents` (
  `id` int NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;
CREATE TABLE `children` (
  `id` int NOT NULL,
  `parent_id` int NOT NULL,
  FOREIGN KEY (`parent_id`) REFERENCES `parents` (`id`)
) ENGINE=InnoDB;

作成されたテーブル定義の結果は以下です。 比較してみると上の children テーブルのCREATE文は簡略化して書いたもので、MySQLが自動でインデックスキー(KEY parent_id)を作成してくれている事がわかります。

mysql> SHOW CREATE TABLE children\G;
*************************** 1. row ***************************
       Table: children
Create Table: CREATE TABLE `children` (
  `id` int(11) NOT NULL,
  `parent_id` int(11) NOT NULL,
  KEY `parent_id` (`parent_id`),
  CONSTRAINT `children_ibfk_1` FOREIGN KEY (`parent_id`) REFERENCES `parents` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

上では簡略化した書き方をしましたが、外部キー作成の構文は以下で表現されます。

[CONSTRAINT [symbol]] FOREIGN KEY
    [index_name] (index_col_name, ...)
    REFERENCES tbl_name (index_col_name,...)
    [ON DELETE reference_option]
    [ON UPDATE reference_option]

reference_option:
    RESTRICT | CASCADE | SET NULL | NO ACTION

マルチカラムインデックスの場合は?

では、マルチカラムインデックスを持つテーブルでの挙動もみてみます。

CREATE TABLE `children` (
  `id` int NOT NULL,
  `parent_id` int NOT NULL,
  `revision` int NOT NULL,  
  KEY (`parent_id`, `revision`),
  FOREIGN KEY (`parent_id`) REFERENCES `parents` (`id`)
) ENGINE=InnoDB;

先に Composite Key として使用するインデックスカラムとして、外部キーとなるカラムを使用しておけば、特に自動でのインデックス作成は行われません

mysql> SHOW CREATE TABLE children\G;
*************************** 1. row ***************************
       Table: children
Create Table: CREATE TABLE `children` (
  `id` int(11) NOT NULL,
  `parent_id` int(11) NOT NULL,
  `revision` int(11) NOT NULL,
  KEY `parent_id` (`parent_id`,`revision`),
  CONSTRAINT `children_ibfk_1` FOREIGN KEY (`parent_id`) REFERENCES `parents` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

逆に、先に外部キー以外のカラムを指定していると、外部キーの単独のインデックスが自動で作成されます。

CREATE TABLE `children` (
  `id` int NOT NULL,
  `parent_id` int NOT NULL,
  `revision` int NOT NULL,  
  KEY (`revision`, `parent_id`),
  FOREIGN KEY (`parent_id`) REFERENCES `parents` (`id`)
) ENGINE=InnoDB;
CREATE TABLE `children` (
  `id` int(11) NOT NULL,
  `parent_id` int(11) NOT NULL,
  `revision` int(11) NOT NULL,
  KEY `revision` (`revision`,`parent_id`),
  KEY `parent_id` (`parent_id`),
  CONSTRAINT `children_ibfk_1` FOREIGN KEY (`parent_id`) REFERENCES `parents` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

今回の外部キーの話とは逸れますが、マルチカラムインデックスは内部でカラム値を定義順に連結して作成した値を持っていることが分かります。(効率的なキーの設計をしておけば、追加でのインデックス作成が不要になる。)

外部キー制約

MySQLでは ON DELETE, ON UPDATE の後ろにオプション(RESTRICT | CASCADE | SET NULL | NO ACTION)をつけて表現でき、参照元の親テーブルが削除された場合にどのようにデータの一貫性を保つかを指定できます。 デフォルトでは制約違反のデータ操作は拒否されます。

Cannot add or update a child row: a foreign key constraint fails

例えば ON DELETE CASCADE を指定すれば、親テーブルのレコードが削除された場合に、子テーブルで参照元としているレコードも自動で削除されます。(各オプションの挙動については、他の記事に譲ります。)

外部キー制約とインデックスまとめ

最初に書きましたが、外部キーの重要な役割にデータの一貫性を保つことがあります。
親テーブルのレコードが削除された場合などに、子テーブルのデータをチェックして制約を満たすかを確認する必要があります。その参照を高速に処理するためにインデックスが用いられます。ユーザーがインデックス作成を明示的に定義しない場合には、MySQL側で自動で作成が行われます。
ユーザーにとっても、複数テーブルにまたがるデータを参照する際に効率的なクエリのために、このインデックスを効率的に使うことを意識しておく必要はあります。
今回は普段あまり意識されない内部的な動きを整理してみる記事となりました。

LayerX ではエンジニア採用をオープンしています。カジュアルに話をする機会などもありますのでお待ちしております!

open.talentio.com

open.talentio.com

open.talentio.com

「バクラク」ロゴの制作過程で生まれた言葉

※こちらは「LayerX Advent Calendar」58日目の記事です。

こんにちは、SaaS事業部でデザインを担当しています森です。
先日お知らせした通り、弊社SaaSプロダクトシリーズの名前を「バクラク」にリニューアルいたしました。

bakuraku.jp

リブランディングの経緯は、SaaS事業部のビジネスサイドの責任者@makiのエントリーを読んでいただくとして、今日はそれに伴うロゴ制作についてのお話しです。

note.com

バクラク

コーポレートミッションの策定をお手伝いいただいた、PARK 田村さんに提案いただいたリニューアル案の中から「バクラク(この時点では表記方法は未定)」に決まりました。

チームでの軽いネタだしから、シリーズ表記をカタカナ、プロダクト表記を漢字(請求書、申請、電子帳簿保存)でいくことになります。

漢字(爆楽)だと、字面の複雑さ重そうな雰囲気、他社さんとの被りが気になり、アルファベット(Bakuraku)だと語感の持つ面白みを感じにくい。また、プロダクト名はわかりやすさを重視して、漢字にすることは概ね決まっていたので、組み合わせ的にもカタカナを選びました。

ロゴの制作の場合、何かしらとっかかりになる物を探すのですが、「バクラク」に感じていた特徴は

  • 濁点はじまり
  • 韻を踏むような「ク」が生むリズム感

の二つ。最初にイメージしたのは、楽譜の上で等間隔に並ぶ音符や、ステップシーケンサーのマス目のように等間隔に並ぶ直線でした。

f:id:hiroakimori:20211221091146p:plain

この方向で試作していきます。

f:id:hiroakimori:20211221085545p:plain

少し単調ですね。濁点の扱いに悩みつつ、可読性や文字の特徴を強めていきます。

f:id:hiroakimori:20211221085554p:plain

おおよその着地が見えてきました。社内のフィードバックをもらいながら、ボリュームや可読性を調整していきます。

f:id:hiroakimori:20211221085602p:plain

フィードバックから生まれた言葉

直線を軸に作っていたので、いくつか可読性についてのフィードバックをもらい、調整を繰り返していました。その中で、「ハタラクに見える」というフィードバックをもらいます。

「バクラク」というカナ表記は、濁点と一画の違いだけで、私たちが向かい合う「ハタラク(働く)」という事と似通っていたのです。
その瞬間、可読性の問題が一転します。

f:id:hiroakimori:20211221085612p:plain

ハタラクをバクラクに

「圧倒的に使いやすいプロダクトを届け、ワクワクする働き方を。」  

企業活動を支えるコーポレート業務は、ミスができない難しい業務。 そんな業務に「楽しい!」と言ってもらえるくらいの体験を届ける。 UXへの圧倒的こだわりと、深い顧客理解で業務プロセスを滑らかにし、toCサービスの体験をtoBにも これらの体験を組織的なオペレーションであらゆる企業に届ける。 LayerXの提供する体験が、toBの世界で当たり前と言われる水準になるように。

note.com

弊社SaaS事業部には、事業部ミッションがあります。「バクラク」という名前を選んだのは「難しい業務を楽にしたい」という姿勢の現れです。 そして、ロゴへのフィードバックをきっかけに、それを濃縮したような言葉を見つけることができました。

f:id:hiroakimori:20211221085525p:plain

この言葉に行きついたのは運が良かったと思います。
そもそも、この視点が抜け落ちていた中、フィードバックによって気づくことができました。 そのフィードバックも、可読性の問題とだけ捉えていたら、濁点の位置を変更するなどして「ハタラク」と結びつけることはできなかったと思います。

そして、その過程は弊社っぽいと思っています。

弊社のプロダクト開発の特徴として、まず動く物を作り、フィードバックを通してより良くしていくというものがあります。フィードバックも社内だけではなく、お客様や有識者の方々にご協力いただいています。

セールス、CS、開発、コーポレートを問わず、より近いところで意見を聞き、それをプロダクトに生かしていく。そんな社風から生まれた言葉だったように思います。

「ハタラクをバクラクに」

この言葉を体現する道のりは、まだまだこれからです。
もっと沢山の人に、より良い価値を提供していくには、まだまだ仲間が足りません!
開発、ビジネス全方位で絶賛募集中ですので、下記よりご連絡ください!!

LayerX 採用情報

LayerX Company Deck

open.talentio.com

プロダクトマーケットマッピングを用いた開発ロードマップ作り~地図とコンパスを作ろう~

※ こちらは「LayerX Advent Calendar 」49日目の記事です。

こんにちは。SaaS事業部PdMエンジニアの花村(@naomasabit)です。先日TECH PLAYさんのPdMイベントで登壇させていただきました。そこで話したLayerXインボイスのプロダクトマネジメントで行っている方法論をご紹介しようと思います。

techplay.jp

イベントで使用したスライドはこちらです。ダイジェストの説明をこの後の章でしていきますが、詳細が気になる方は眺めながら読んでみてください。

speakerdeck.com

地図とコンパスを作ろう

プロダクトマネジメントではスコープがなく、ビジョンを実現するためにやるべきことを付加してやっていく、という動きになります。そのため、何をどの順番で作るべきかを定めるのがPdMの重要な役割です。

役割を果たすために「『地図』と『コンパス』を作ろう」と述べました。目的地と自分達のプロダクトの居場所を見つけるための地図と、行き先の指針となるコンパスが必要としています。

f:id:naomasabit:20211208125408p:plain

地図の作り方

地図の作り方の手順は以下のように定義しました。

f:id:naomasabit:20211208125352p:plain

1. ユーザーの要望を集める

1ではセールス・CS・ユーザー行動ログから要望を抽出しています。それぞれ、新規ユーザーからの要望、既存ユーザーからの要望、ユーザーの本音の行動としての特性を持っているため、満遍なく情報を取りまとめています。

f:id:naomasabit:20211208130002p:plain

2. 集めた要望から機能要件を抽出し、3. 抽出した機能要件を求めている企業の属性を抽出する

2,3 では、抽出した要望を機能にし、求めている企業の属性をラベリングしていきます。例えば規模と業界の2軸で要望をまとめていきます。

f:id:naomasabit:20211208131546p:plain

f:id:naomasabit:20211208131650p:plain

4. 機能と企業の属性(市場)をマッピングする

3までのステップで機能と要望企業のラベリングができたので、こちらを図にまとめると以下スライドのようになります。そうすると、要望の全体像が見えてきます。図にまとめると今要望を多く実現できているセグメント、まだ要望を実現していく前のセグメントが見えてきます。

これにより、自分達のプロダクトがどの立ち位置にいて、要望を求めている企業たちがどこにいるのかをみえてくる「地図」がみえてきます。この手法を私は「プロダクトマーケットマッピング」と命名しています。

f:id:naomasabit:20211208134104p:plain

コンパスの作り方

地図があると、どの順序で要望を実現すべきかの道筋を定めやすくなります。

f:id:naomasabit:20211208134747p:plain

これにより方向性は見えますが、具体的な計画に落とし込むときの要素として

  • 時間軸の概念
  • 取り組むべきテーマ
  • 取り組みによるアウトカム

の3つを付与していきます。

時間軸の概念は、具体的にどのクォーターでどの機能要望を実現するか。

取り組むべきテーマは、セグメントの要望を実現するために腰を据えて取り組む内容。

取り組みによるアウトカムは、機能要望を実現したらユーザーの価値として何を提供できるか。(B2BSaaSにおいてのアウトカムは業務インパクト)

です。これらを図に落とすと以下スライドのようになります。

f:id:naomasabit:20211208134829p:plain

さらにブレイクダウンし、アウトカムに紐づく機能要望を何年何月に実現していくかの計画とするのが、以下スライドの右画像のようにロードマップとなります。

地図として作ったプロダクトマーケットマッピングから、計画としてテーマとアウトカムを練り上げてブレイクダウンすることで開発ロードマップを作成するようにしています。早く価値を届けるために、寄り道をしないこと、計画で失敗しないことを気をつけています。

f:id:naomasabit:20211208135413p:plain

最後に

エアプは悪

最後に、要望を集める際にセールス、CSから抽出すると書きました。が、どうしても又聞きで二次情報になってしまうので、直接ユーザーヒアリングをする機会を意識的に作っています。それによって要望の背景を深堀したり、リリースした機能の使い心地のフィードバックを受けたりと、より新鮮な情報を得られてプロダクト計画に落とし込めます。

又聞き情報だけで知ったかぶりになってしまうことを、「エアプ」(エアプレイ)と自分への戒めのために呼んでいます。私がコードを書いて開発もしている以上、ユーザーと向き合う時間を意識的に作らなければ「エアプ」となってしまい、細部へのこだわりが減ってしまうという危機感から「エアプは悪」とイベントでは述べていました。

全職種募集中

機能にこだわりを持って推進できるプロダクトマネージャー、プロダクトマーケティングマネージャーをはじめ、全職種で採用募集しています。

layerx.page.link

各メンバーでmeetyもしておりますので、ぜひお気軽にお申し込みください。

meety.net

参考書籍

地図とコンパスは走りながら作った方法論ですが、書籍などの体系的理解がベースになっています。B2BSaaSのプロダクトマネジメントで参考にした書籍を紹介します。

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける Melissa Perri 。言わずと知れた名著で、ユーザー価値である「アウトカム」へのフォーカスの重要さが学べます。 プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける | Melissa Perri, 吉羽 龍太郎 |本 | 通販 | Amazon

プロダクトマネジメントのすべて。基礎にして非常に良書です。 プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで | 及川 卓也, 小城 久美子, 曽根原 春樹 | コンピュータ・IT | Kindleストア | Amazon

ALL for SaaS. 「freeeプロジェクト管理」を立ち上げる中の知見が非常に体型的にまとまっています。B2BSaaSへの解像度が非常に上がります。 ALL for SaaS SaaS立ち上げのすべて | 宮田 善孝 |本 | 通販 | Amazon