新卒エンジニアがスクラムマスタやってみた

こんにちは、19新卒として入社して今freee関西支社でエンジニアをしているりょう(@liaoziyang)です。この記事は freee Developers Advent Calendar 2019 の 18 日目の記事になります。

スクラムマスタになったきっかけ

組織が成長することによって、当時2,3名だった頃に決めたなんちゃってスクラムの回し方に課題感を感じており「じゃあ、スクラムマスタやってみよう」とジャーマネ (freeeでのマネージャーの呼び方)から言われたことをきっかけにチャレンジすることになりました。ただ、やってみたいと思ったものの、それまで今のチーム以外で働いた経験がなく、最初は結構不安でした。特にスクラムマスタは開発プロセスを守る役割で、しっかりとスクラムを理解しないといけません。その不安を解消するために「スクラム修行」ということで、1週間ぐらいかけて、社内の他のスクラムを上手く実行しているチームのミーティングに参加して、現役のスクラムマスタたちの話を聞いてくるなどしました。

なんちゃってスクラムを改善するため取り組んだこと

アジャイルワークショップ

チームの力を最大限を発揮するために、まずはチームメンバーが共通認識を持ってお互いを信頼する関係を築くことが大事です。作るものや開発プロセスについて共通認識を持つように、東京オフィスから開発プロセスについて詳しい方を招いて、二日間でアジャイルワークショップを開催しました。

内容はこんな感じです。非常に楽しい、学びになった二日間でした。

  • プロダクトバックログの価値と作り方
  • バックログを低リスクで早く実現する方法の体験(コイン渡し)
  • 開発のフローの見える化と無駄の排除(ValueStreamMapping)
  • チームと作るものの明確化(インセプションデッキ)
  • チームビルディング(ドラッカー風エクササイズ)
  • チームの働き方やルールを決めるWorking Agreementの作成

f:id:liaoziyang:20191217234707p:plain
アジャイルワークショップ

スプリントイベント

今までやってきたスクラムはスプリントを使っていたものの、スプリントのイベントとしてスプリントレビューと計画しかありませんでした。スプリントイベントを省略した分の時間は開発に回せましたが、レトロスペクティブが抜けているため、チームの問題点の意識や改善はできていない状態です。チームより良くするために、レトロスペクティブもスプリントイベントの重要な1つとして取り入れました。

チームとプロジェクト状態の可視化

スクラムは問題を見えるようにするもので、継続的に問題を可視化できる仕組みを保つことによって問題を早期発見し、直していくことができます。問題を発見するために、チームと「今進行しているプロジェクトの状態」を可視化して客観的に分析する必要があります。

平均ベロシティ

ベロシティとは、決められた期間の中で、あるチームが届けることができる要求の量のことです。 これは同じチームメンバーが固定の期間で繰り返している場合においては正しいものですが、チームメンバーの人数や期間が変われば、自動的にベロシティは変わります。特に毎スプリントの作業時間が不定であり、祝日やメンバーの休み、会社のイベントなどより変動します。なのでベロシティそのものはそこまで信頼できる値ではありません。

この図は実際の作業時間とベロシティの推移になりますが、作業時間が安定していないので、ベロシティーも常に変動しています。

f:id:liaoziyang:20191217234817p:plain
作業時間とベロシティ

一方で、時間の変動を排除すれば、単位時間のベロシティはある程度チームの平均生産性を表すことができます。平均ベロシティを計測して、高めて安定させることを目指して施策を打っています。

この図は実際にスプリントごとで算出した平均ベロシティですが、sprint1とsprint7以外は安定しているように見えます。安定していない週について、なぜこうなったのかをチームで深掘りして、次に活かします。

f:id:liaoziyang:20191217234859p:plain
平均ベロシティ

スプリントバーンダウンチャート

スプリントバーンダウンチャートは残作業の合計や目標日時を可視化することで、進捗が把握しやすくなります。デイリースクラムの前に、BOTがSlackチャンネルに投稿するので、これを元にタスクの調整や作戦を考えたりします。

f:id:liaoziyang:20191217235317p:plain
スプリントバーンダウンチャート

アジャイルQAの導入

今までは開発プロセスとQAプロセスを分離してやっていたのですが、膨大なテストケースにより、QAプロセスのバッチサイズが大きくなりすぎるところにデメリットがありました。QAであげた修正が間に合わないためにリリース予定がずれるリスクも大きくなります。 そこで、アジャイルQAを導入することにしました。 アジャイルQAは開発プロセスとQAプロセスを分離せず、QAプロセスをスプリント内で入れます。

↓こんなことをしました。

  • スプリントイベントにQAチームの担当者に参加してもらう
  • スプリントレビューのデモ範囲でQAテストを行う
  • 次回スプリント計画時に、前スプリントの開発内容のQAチケットを整理・優先度決め、優先度高い順で消化する計画を立てる

アジャイルQAを導入することで、バグが早期発見、解決できるようになってより高い品質保った状態で開発していくことができるので安心感が高いです。

Tryの管理

スプリントレトロスペクティブはKPT形式でやっていますが、せっかくあげてきたTryがそのまま放置されないように、KPTの最後に今までのTryを振り返ったりします。その中で完了したものは完了マークをつけて、継続して行うものは継続のマークをつけて管理しています。

こんな感じです。

f:id:liaoziyang:20191217235505p:plain
Tryの管理

ちなみに、とあるスプリントのTryに「スプリントが終わったらクラッカーを鳴らす」が書いてあったので、実際に次のスプリントからはクラッカーを鳴らすようになりました。予想以上にみんなテンション上がっていたので、良いカルチャーとして続けていきたいと思っています。

f:id:liaoziyang:20191217235545p:plain
クラッカーを鳴らす様子

最後に

スクラムマスタをやる前には、エンジニアとしてコード書く時間を増やせば多く成果出せるというマインドでしたが、スクラムマスタやってみて、コードを書く時間以外にも、振り返りや改善の時間を惜しまずに確保することも大事だなと思いました。引き続き頑張っていきたいと思います。

明日は、freee OSAKAについて熱く語ってくれる@yoshiさんです。お楽しみに!

デザインシステム運用の雑多な細かいはなし

freee Developers Advent Calendar 2019 の17日目です。 デザインシステムチームの @toofu__ です。夜はニートゥーチェストをしており、1988年生まれ4268人中3位です(12月16日現在)。腹筋が喜んでいます。

freee のデザインシステムの現状

freee にはデザインシステムチームが存在し、下記の運用を行っています。

  • UIコンポーネントライブラリ Vibes
  • デザインガイドライン Groove
  • アクセシビリティガイドライン

Groove と Vibes が生まれた経緯とかについてはチームメンバーの @ymrl が1日目に色々書いてくれているので、よろしければご覧ください。

developers.freee.co.jp

この記事では、Groove と Vibes に関するもうちょっと細かいブツの雑多な話を書きます。

Vibes の詳細

Vibes は UIコンポーネントライブラリで、デザイン向けには Sketch シンボルライブラリ、開発向けには React コンポーネントで提供されています。

ボタン等が並んでいるコンポーネントライブラリの様子
Vibes の Sketch ライブラリ

freee ではデザイン業務に Sketch を利用しています。ここしばらくは Figma と Sketch どちらを使うのか、という議論があったのですが、 Vibes コンポーネント管理の観点から、なるべく Sketch を利用することにしました(Sketch ファイルのアップデート管理にGitHubを使っており、Figma のヒストリー機能だけでは不足していた)。

freee は複数のプロダクトを運用していますが、それらを横断したコンポーネントを Vibes に含めるという運用をしています。プロダクト固有のUIについては各プロダクトで実装してもらっている感じです(もちろん、「これは Vibes に含められないか?」という社内からの相談があったときは入れたり入れなかったりの検討をメンテナ間で行っています)。

Groove の詳細

Groove は画面設計のルールを定めたデザイナー向けのドキュメントで、社内で利用している Gsuite 上の Google サイトで運用されています。目的としてUIの統一性を担保するとともに、デザイナー陣が「見た目」の細かい設計に時間を取られず思う存分ユーザー課題の解決にフォーカスできるようにするを挙げています。そのため、画面設計の作業に直接活かせるよう、 Material Design などよりもユースケースを絞ったガイドラインになっています。

デザインガイドライン Groove のキャプチャ画像。画面パターンカテゴリのページはログイン画面、ホーム画面、コレクション画面、シングル画面、インポート・エクスポート、レポート画面、会計帳簿画面、関連メニュー
Groove の Google サイト。左メニューに画面パターンを並べています。

左の方に映っているメニューを見てもらえればなんとなくわかるかもしれませんが、 Groove では freee のプロダクトにおける画面やUIを類型化し、その型ごとに設計ルールを記載しています。例えばコレクション画面で一括処理を行うときは「一括で行える操作は、コレクション画面上でその変化がわかるようにする / 「いま何件選択しているのか」を表示する」とか。

イメージとしては「Groove のルールに沿いながら、Vibes を並べることで画面設計を行っていく」という感じです

浸透具合

まだまだ freee のプロダクトすべてにデザインシステムが適用されているとは言えない状態ですが、現時点では

  • 新しく作られるプロダクト、サービスにはほぼ適用されている
  • プロダクトの既存部分にも適用され始めてきている

という浸透具合です。

使用してくれたエンジニアからは「フロント開発は Vibes が担保してくれるので、ドメインロジックの設計開発に頭のリソースを集中できてよい」というポジティブなフィードバックがもらえています。

課題とかツラさとかそれに対する解決策とか

デザインシステムを構築しているときも課題はありましたが、プロダクトへの導入が行われているときはまた違った課題感があります。

どれだけ浸透してるのかわかりづらい

デザインシステムチームが組織内で独立したため、「どれだけデザインシステムがプロダクトに浸透してきているか?」がチームの評価に大きく関わってくるのですが、まずそれを測ることが難しい。

理由としては

  • 組織が大きく、どこでどんな開発が行われているか全容を把握しづらい
  • 企画・設計から実装が完了するまで比較的長期にわたるプロジェクトも多く、単にリリースされた画面だけを測定対象にしていても成果が見えづらい

という2点が大きいように思います。

前者はデザインシステムチームのメンバーがあちこちに顔を出したり、Slack上で「Vibes」エゴサーチをしたりなど人力でカバーしています*1が、後者については指標自体の問題っぽいです。

そこで、以下の2段階で浸透度合を測ることにしました。*2

  • デザイナーによる設計にデザインシステムが浸透しているか
  • その設計を実装してリリースされた画面にデザインシステムが浸透しているか

まず前者についての計測の土台をつくるため、まずはツールと成果物の集約に着手しました。プロダクトも多くデザイナーの人数も10名を超えてきており個々人が作成したデザイン成果物がどこにあるのかわからない状態だったのですが、Sketch for Teams および Google Gallery へのツールの集約を行うことをチームに周知し、協力を依頼しました。

Sketch for Teams は Beta 版ではありますが、各デザイナーが作業しているデザインファイルにブラウザ上でアクセスできるので、Vibes / Groove に基づいた設計になっているかどうかがすぐチェックできます。ここからファイルごとに浸透度合を測っていくようにしました。 Sketch for Teams 利用サンプル

また、ファイルの属人性を排除するため、ファイルの命名規則等を作成し、作成者以外でも何がどこにあるのかを把握できるようにしました。freee ではプロダクトごとに Sketch Cloud 内で「プロジェクト」を区切り、ファイル名で「プロダクト内の担当領域」「プロジェクト名」「作成した時期」がわかるようなルールにしています。

後者もまだ完璧に計測できているわけではありませんが、freee ではリリース情報が社内各地から投稿されるチャンネルが存在するので、そこから現物を見に行って計測しようとしています。

Sketch ライブラリと React コンポーネントに差異がある

デザインシステムの構築をはじめた時期にわーっと作っていた都合もあり、一部 Sketch ライブラリと React コンポーネントに差異があるところがありました。

  • まずシンボル名とコンポーネント名が違う
  • 可変部分が Sketch と Reactコンポーネント で異なる

前者は「ちゃんとしようよ」という話ではあるのですが、 React では props でまとめられたりただの状態違いなものであっても Sketch では個々にシンボルとして定義する必要があり、必然的に Sketch ライブラリが肥大化していく傾向があるため、うまいことまとめていく必要があります。ただ「そもそもボタンの hover 時の表示とか Sketch ライブラリに含める必要あるか?」みたいな議論はしている最中です。

Lv2/04_Dialog/MessageDialog/single-button と Lv2/04_Dialog/MessageDialog/double-button という2つのSketchシンボル
Sketch ライブラリでは Lv2/04_Dialog/MessageDialog/single-button と Lv2/04_Dialog/MessageDialog/double-button というシンボル名になっているが、

Lv2/Dialog/MessageDialog と Lv2/Dialog/MessageDialogConfirm というふたつのReact コンポーネントのStorybook画像
React コンポーネントでは Lv2/Dialog/MessageDialog と Lv2/Dialog/MessageDialogConfirm という名前になっている

後者については仕組みで解決するのが結構難しく、コンポーネント上では string しか許容していない部分でもSketch上では改行を入れられてしまったり、コンポーネント上では input 要素の幅を small | medium | large から選ぶことになっていても Sketch 上ではその選択肢をつけるのが難しかったりします。

そこにズレが起きてしまうと「デザインシステムに沿った画面設計が行われているのに、結果実装できない」みたいなことが起きてしまうため、なるべくそこをなくすための活動も行っています。具体的には 実装と反する変更を入れてしまわないよう、Sketch シンボルを並べた時に目に入る場所にガイドを入れたり、デザイナー向けにStorybook の読み方の講習会を開いたりです。

幅の選択肢である「64px, 112px, 176px, 384px」が書かれたSketch ライブラリ
デザイナーがシンボルを並べたときに幅の選択肢がわかるよう、「64px(4rem), 112px(7rem), 176px(11rem), 384px(24rem)」と初期値が書かれた input フォームのSketch ライブラリ

デザイナーがつくったデザインに使われてるコンポーネントがどれなのか、エンジニアから見てよくわからない

地味に課題として根深いのがこの点です。どのコンポーネントを使っているのか、そもそもVibesコンポーネントではない独自のコンポーネントなのかをエンジニア側が調査する必要があるのが現状です。調査してもわからずメンテナに相談が来るのであればいいのですが、わからないので違うコンポーネントを使ってしまったり、独自実装をしてしまったりするとツラい。

デザイン成果物をエンジニアに共有する際に Gallery にアップロードすると Sketch のレイヤー名を見ることができますが、レイヤー名にコンポーネント名を入れるのもそれはそれでデザインファイルの見通しが悪くなってしまいます。

アップロードしたデザインでSketchのレイヤー名を確認することができる様子
レイヤー名は見えるが、ここはもうちょっと文脈に沿う名前を入れるように使いたい

これ、いい解決策が見当たらないです。現状ではエンジニアに対して「Vibes コンポーネントを使うときはLv2から探してください*3」と伝え、デザイナーには「Vibes コンポーネントではないUIを設計したときはきちんとエンジニアとコミュニケーションをとってください」と伝えています。

なんか良い方法があったら知りたい。

おわりに

developers.freee.co.jp

以前書いたようなデザインシステムに関する勉強会も増えてきており、各地のデザインシステムのやっていきかたを知れる機会が増えてきています。業務で運用する立場としては嬉しい限りです。そういった世の流れをもっと増やしていけるよう、なるべく具体的な手法や課題感を書くようにしてみました。気になることがあったら Twitter なりコメントなりいただけると嬉しいです。

明日は関西支社の新卒エンジニア、 liaoziyang さんです。

*1:といってもGroove / Vibes はメインメンテナ2名でやっているのでそれはそれで大変

*2:前提として、freeeにおいてデザイナーは基本的にコードをかかず、デザイン仕様の作成までを担当しています。エンジニアがバックエンド/フロントエンド問わず実装を行っています

*3:Vibes は当初 Atomic Design を踏襲したコンポーネント設計を目指していましたが、実態として色々不都合が出てきたため、現在は Lv1 / Lv2 という大雑把なグルーピングにしています

焼肉・イン・ザ・ダーク🔥🥓🔥

この記事はfreee Developers Advent Calendar 2019、およびアクセシビリティ Advent Calendar 2019の16日目です。

こんにちは、freeeでiOSアプリ開発を担当している @RyoAbe です。 今回は先日行った「焼肉・イン・ザ・ダーク」という企画について書きたいと思います。

複数人で焼肉をしているイラスト

焼肉・イン・ザ・ダークとは

「焼肉・イン・ザ・ダーク」とは、ダイアログ・イン・ザ・ダークをもじった企画で、弊社のアクセシビリティーおじさんことアクセシビリティーのガイドラインの作成やスクリーンリーダー対応のアドバイス等をされている全盲でエンジニアの中根さんと、freeeで開催されたアクセシビリティー関連のイベントにも何度かご登壇頂いた先天性の色弱(P型強度)で視覚情報デザインコンサルタントをされている伊賀さんお二人が果たして焼肉をすることはできるのかということをアクセシビリティーの観点で研究しようというもの。

企画を聞いたとき、普段視覚で肉の焼き具合を把握している晴眼者の我々からすると、聴覚で肉を焼くなんてことができるのか半信半疑で、とても興味深い面白そうな企画でワクワクしていました。

ダイアログ・イン・ザ・ダークを体験している方々の様子
ダイアログ・イン・ザ・ダークを体験している方々(出典: DIALOG IN THE DARK JAPAN

アクセシビリティーおじさんこと中根さん
アクセシビリティーおじさんこと全盲のエンジニア中根さん

P型色覚の視覚情報デザインコンサルタントをされている伊賀さん
P型色覚の視覚情報デザインコンサルタントをされている伊賀さん

企画当日

メンバーは中根さんと伊賀さんに加えて普段からfreeeでアクセシビリティーの活動に携わっている面々で、11月29日(いい肉の日)に開催されました。場所は牛角 五反田店

お店の前で案内されるのを待っている様子
お店の前で案内されるのを待っているところ

焼き始める

席に案内され注文を終えると、早々にお肉が来ました。すると伊賀さんが中根さんに、お肉が乗ったお皿の大きさ、網の形状やサイズを伝えていました。そして中根さんが網の上に置こうとする肉がどのあたりの位置なのか時計の位置関係で例えて伝えていました。(例: 手前だったら6時、左斜め奥だったら10時など)中根さんとご飯行った際はどういった料理が来たかや何をお皿によそったのかを伝えたりしますが、焼肉ではこのようなことを伝えると良いのかと、席に着いて早速学びがありました。

youtu.be

焼く、そして聞く

焼き始めると中根さんが解説をしてくれました。「焼き始めはこんな音」、「良い焼き具合になるとこんな音」、「油が多い肉はこんな音」、「薄い肉だとこんな音」などなど。自分も真似て目をつむり耳を澄まして聞いてみるも、初めはなかなか分かりませんでした。ですが、繰り返し解説なども交えて聞いていると徐々に分かってきたように思います。

耳を澄まして音から焼き具合を感じ取っている中根さん
耳を澄まして音から焼き具合を感じ取っている中根さん


さて、ここで問題です

実際、視覚障害や色覚障害を持っているといかに肉の焼き具合を識別するのが難しいか、お読みになっているあなたにも体験していただこうかと思います。iPhoneで撮影した動画で雑音も多く入っていますが、是非チャレンジして見ていただければと🔥

問題①(難易度: 低)

この写真は伊賀さんと同じ色覚の P型 をシミュレートした肉が焼かれている様子です。どれくらいの焼き具合でしょう?

伊賀さんと同じ色覚のP型をシミュレートした肉が焼かれている様子

  1. 焼き始め
  2. 少し焼けてきた。aとcの間
  3. 食べごろ
  4. 焦げてる




答え: a. 焼き始め
問題①答え(画像) (意外に分からなかったんじゃないですか?)

問題②(難易度: 中)

続いてはこちら。この動画は肉を焼いている際の音声を抜き出したものです。どれくらいの焼き具合でしょう? (問題①と同じ形式ですが、音で識別してみてください)

  1. 焼き始め
  2. 少し焼けてきた。aとcの間
  3. 食べごろ
  4. 焦げてる




答え: a. 焼き始め
問題②答え(動画) (音だけでは分からなくても、動画を見ると「あー」となりますよね笑)

問題③(難易度: 高)

ラム肉を焼いたときの音の変化で正しいのはどれでしょう?(これはほんと難しいと思います...w)

  1. 1.ジージー 2.パチパチ 3.バチバチ 4.プスプス
  2. 1.ジージー 2.パチパチ 3.プスプス 4.バチバチ
  3. 1.ジージー 2.プスプス 3.バチバチ 4.パチパチ
  4. 1.ジージー 2.バチバチ 3.パチパチ 4.プスプス




答え: b. 1.ジージー 2.パチパチ 3.プスプス 4.バチバチ
問題③答え(動画) (中根さんが後ろで解説されてるのが聞こえるかと思いますが、解説を聞くと納得感ありませんか?)

問題④(難易度: 最高)

これは何の肉を焼いている音でしょう?(音の特徴から分かるかも?)

  1. カルビ
  2. ハラミ
  3. ロース
  4. ホルモン




答え: d.ホルモン
問題③答え(動画) (こちらも後ろで中根さんの声が。なるほど確かに)

最後に

問題はいかがでしたか?難しかったですよねw この記事を通して面白そうだなと少しでも興味を持った方は、是非ご連絡ください。中根さん達と共に焼肉に行きましょう!何にしても生焼けだろうが焦げてようが、みんなで食べる焼肉って最高ですよね笑🔥🥓🔥

明日は、

です!お楽しみに!

サブスクリプションビジネスをする時に知っておきたいユースケース

こんにちは!freeeのエンジニアのmiyarappoです。

freeeには2019年5月に入社して、主に課金処理とサブスクリプション管理を集約したマイクロサービスを開発しています。 その中で得た知見を共有したいと思います。

この記事は freee Developers Advent Calendar 2019 の15日目です。

adventar.org

よろしくお願いします!


この記事の目的

「サブスクリプションビジネス未経験の人が、サブスクリプションビジネスをする時に考慮すべき最低限のユースケースを想定できるようになる」を目標とします。

誰かの落とし穴を塞げたら幸いです。

前提

この記事で取り上げるユースケースは、サブスクリプションビジネスにおける一般的なユースケースを想定しています。

freeeが辿った変遷を参考にしつつ私個人が想定したユースケースであり、現実のfreeeのユースケースと一致しないことをご理解ください。

前置きが長くなりました。はじめます。


ユースケース①: プラン変更が起こる

サブスクリプションビジネスでは、サービスそのものを売るのではなく、サービスを一定期間利用できる「権利」を売っています。 この権利は常にアップグレードやダウングレード、数量変更が可能です。

変更に耐えうるデータモデルを設計することが重要です。

具体的な例

やっていき株式会社は、経理をサポートするSassを開発しました。

サブスクリプションで販売しようと試みます。

初心者プランと上級者プランの2つのプランを用意しました。

初心者プランを購入したユーザーが、上級者プランに変更したいと言ってくれました。

初心者プランの分を返金して、上級者プランの料金を差額決済します。

按分計算が必要になります。

上級者プランから初心者プランへの変更の場合は、返金をする必要がありました。


ユースケース②: 売上は請求し回収する必要がある

当たり前ですが、売上分の金額をユーザーからいただく必要があります。 ユーザーの利便性を考慮し、支払い周期と支払い方法を増やすほど請求・回収業務が複雑になります。

スプレッドシートでの管理は、すぐに限界が訪れます。 請求業務や回収業務の自動化を進めないと、ユーザーの拡大にバックオフィスが耐えられなくなります。

具体的な例

経理をサポートするSassは順調にユーザーを獲得しました。

決済方法はクレジットカードのみ対応でしたが、新たにペイパル・銀行振込・PayPayを対応しました。

月額払だけでなく、年額払いにも対応しました。

UXは向上しましたが、「2つのプラン × 4の支払い方法 × 2つの支払い周期」のケースに対応する必要があります。

スプレッドシートも大きくなり、ユーザーの管理が大変になってきました。

登録されたクレジットカードの有効期限がきれて決済が完了出来なかったユーザーに対しては催促のメールを送る必要があります。

ある時、月額払いから年額払いに変更したユーザーに、月額の料金を請求してしまいました。

銀行振込が行われずユーザーに電話する必要がありました。

手形と楽天Payにも対応しようという話が挙がりましたが、管理コストが倍になるので取りやめざるを得なくなりました。


ユースケース③: オプションの販売が始まる

サブスクリプションビジネスでは、ユーザーのLTV(生涯価値)を最大化するべく、様々な施策を講じます。 その施策の1つが、オプションの販売です。

具体的な例

やっていき株式会社の経理作業サポートサービスは絶好調。

初心者プランに、年額1200円で電話サポートのオプションを販売することにしました。

経理が苦手なユーザーが喜んで購入してくれましたが、このユーザーは初心者プランを月払いで使っています。

初心者プランは月払いで、オプションは年払いとなり、ややこしいです。

「2つのプラン × 4の支払い方法 × 2つの支払い周期 × オプションありなし」のケースに対応する必要があります。

管理がまた複雑になりました。


ユースケース④: クーポンの発行が始まる

新規ユーザーの獲得は、とても重要です。 まずはユーザーにサービスを使ってもらい後ほど利益を出すという作戦は、サブスクリプションととても相性が良いです。 そのため、最初の採算は度外視でクーポンを発行するというケースがよくあります。

具体的な例

確定申告の時期になり、経理作業サポートサービスの問い合わせが急増しました。

やっていき株式会社は、新規ユーザーを増やすべくクーポンを発行しました。

初心者プランを1ヶ月無料で使えるクーポンを1000つ発行しました。

「2つのプラン × 4の支払い方法 × 2つの支払い周期 × オプションありなし × クーポンありなし」のケースに対応する必要があります。

新規ユーザーの獲得に成功するも、管理がまた複雑になりました。


ユースケース⑤: オフラインの販売が始まる

オンライン販売から始めたサービスも、拡大に伴いセールスが直接契約を結ぶケースが発生します。 多くの従業員を抱える会社の場合は、金額が大きくなるので、セールスが介在して請求書に直接ハンコを押して契約みたいなフローが一般的なようです。

セールスが売上分は、システムに反映する必要があります。 直接DBに書き込むわかにもいきませんから、セールス用の管理画面が必要になります。

オンライン、オフラインで同じフォーマットで管理しないとキャッシュフローを算出するのが難しくなります。

具体的な例

やっていき株式会社は、経理作業サポートサービスをセールスが直接販売するようになりました。

セールスは現場判断で、割引を行うことが出来ます。

「2つのプラン × 4の支払い方法 × 2つの支払い周期 × オプションありなし × クーポンありなし」のケースに加えて、「2つのプラン × 4の支払い方法 × 2つの支払い周期 × オプションありなし × クーポンありなし × Nパターンの割引」に対応する必要になります。

全体の売上を把握するだけでも一苦労です。


ユースケース⑥: 新プランがリリースされる

ユーザーの契約を永続的に管理することは、サブスクリプションビジネスをやる上で避けられません。 一方で、様々なパターンの契約を管理する必要があり、整理された状態でデータを保持するために一定の努力をする必要があります。

データが整理されていないと、ビジネスの意思決定(新プランのリリース等)にシステムがついていけなくなります。

データをコントロールできる状態に整理しておくことは、サブスクリプションビジネスでは特に重要です。

具体的な例

やっていき株式会社は、従来のプランを廃止し、松プラン、竹プラン、梅プランの3つに変更しようとしています。

初級者プランを梅プランに以降しようとしましたが、クーポンやオプションがついたプランのデータがうまく移行できませんでした。

その結果、新プランのリリース時は、一部のユーザーがサービスを使えなくなってしまいました。


まとめ

この半年間の業務で、サブスクリプションビジネスでは継続的に契約内容を管理する必要があり、データを整理し続けることが重要であることを学びました。 紹介したユースケースのように大変な部分もありますが、ユーザーがサービスをずっと使ってくれるのを見れるのは嬉しいです。

需要があれば、そのうち具体的なデータ構造とかシステム構成とか踏み込んだ説明をしようと思います。

そしてサブスクリプション管理の実装をしている方!是非 freee Tech Nightの懇親会 でお話しましょう!zuoraの辛みやデータモデル設計とか語りたいです。笑

freee-tech-night.connpass.com

一緒に開発している方もお待ちしております! 自分のチームでは、TypeScript / React / Redux / Rails6 / EKS で開発してます!

jobs.freee.co.jp

明日はモバイルエンジニアのあべちゃんです。

それでは!