夜はニートゥーチェストをしており、1988年生まれ4268人中3位です(12月16日現在)。デザインシステムチームが存在し、下記の運用を行っています。1日目に色々書いてくれているので、よろしければご覧ください。関するもうちょっと細かいブツの雑多な話を書きます。コンポーネントで提供されています。ヒストリー機能だけでは不足していた)。含めるという運用をしています。含められないか?」という社内からの相談があったときは入れたり入れなかったりの検討をメンテナ間で行っています)。サイトで運用されています。目的としてUIの統一性を担保するとともに、デザイナー陣が「見た目」の細かい設計に時間を取られず思う存分ユーザー課題の解決にフォーカスできるようにするを挙げています。ユースケースを絞ったガイドラインになっています。左メニューに画面パターンを並べています。プロダクトにおける画面やUIを類型化し、その型ごとに設計ルールを記載しています。「いま何件選択しているのか」を表示する」とか。プロダクトすべてにデザインシステムが適用されているとは言えない状態ですが、現時点では新しく作られるプロダクト、サービスにはほぼ適用されているプロダクトの既存部分にも適用され始めてきているという浸透具合です。担保してくれるので、ドメインロジックの設計開発に頭のリソースを集中できてよい」というポジティブなフィードバックがもらえています。課題とかツラさとかそれに対する解決策とかデザインシステムを構築しているときも課題はありましたが、プロダクトへの導入が行われているときはまた違った課題感があります。どれだけ浸透してるのかわかりづらいデザインシステムチームが組織内で独立したため、「どれだけデザインシステムがプロダクトに浸透してきているか?」がチームの評価に大きく関わってくるのですが、まずそれを測ることが難しい。理由としては組織が大きく、どこでどんな開発が行われているか全容を把握しづらい企画・設計から実装が完了するまで比較的長期にわたるプロジェクトも多く、単にリリースされた画面だけを測定対象にしていても成果が見えづらいという2点が大きいように思います。前者はデザインシステムチームのメンバーがあちこちに顔を出したり、Slack上で「Vibes」エゴサーチをしたりなど人力でカバーしています*1が、後者については指標自体の問題っぽいです。そこで、以下の2段階で浸透度合を測ることにしました。*2デザイナーによる設計にデザインシステムが浸透しているかその設計を実装してリリースされた画面にデザインシステムが浸透しているかまず前者についての計測の土台をつくるため、まずはツールと成果物の集約に着手しました。ツールの集約を行うことをチームに周知し、協力を依頼しました。基づいた設計になっているかどうかがすぐチェックできます。ここからファイルごとに浸透度合を測っていくようにしました。ファイルの属人性を排除するため、ファイルの命名規則等を作成し、作成者以外でも何がどこにあるのかを把握できるようにしました。内で「プロジェクト」を区切り、ファイル名で「プロダクト内の担当領域」「プロジェクト名」「作成した時期」がわかるようなルールにしています。リリース情報が社内各地から投稿されるチャンネルが存在するので、そこから現物を見に行って計測しようとしています。コンポーネントに差異があるところがありました。ライブラリが肥大化していく傾向があるため、うまいことまとめていく必要があります。ライブラリに含める必要あるか?」みたいな議論はしている最中です。上ではその選択肢をつけるのが難しかったりします。そこにズレが起きてしまうと「デザインシステムに沿った画面設計が行われているのに、結果実装できない」みたいなことが起きてしまうため、なるべくそこをなくすための活動も行っています。読み方の講習会を開いたりです。ライブラリデザイナーがつくったデザインに使われてるコンポーネントがどれなのか、エンジニアから見てよくわからない地味に課題として根深いのがこの点です。どのコンポーネントを使っているのか、そもそもVibesコンポーネントではない独自のコンポーネントなのかをエンジニア側が調査する必要があるのが現状です。調査してもわからずメンテナに相談が来るのであればいいのですが、わからないので違うコンポーネントを使ってしまったり、独自実装をしてしまったりするとツラい。レイヤー名を見ることができますが、レイヤー名にコンポーネント名を入れるのもそれはそれでデザインファイルの見通しが悪くなってしまいます。レイヤー名は見えるが、ここはもうちょっと文脈に沿う名前を入れるように使いたいこれ、いい解決策が見当たらないです。コンポーネントではないUIを設計したときはきちんとエンジニアとコミュニケーションをとってください」と伝えています。なんか良い方法があったら知りたい。おわりにdevelopers.freee.co.jp以前書いたようなデザインシステムに関する勉強会も増えてきており、各地のデザインシステムのやっていきかたを知れる機会が増えてきています。業務で運用する立場としては嬉しい限りです。いった世の流れをもっと増やしていけるよう、なるべく具体的な手法や課題感を書くようにしてみました。なりコメントなりいただけると嬉しいです。メインメンテナ2名でやっているのでそれはそれで大変*2:前提として、freeeにおいてデザイナーは基本的にコードをかかず、デザイン仕様の作成までを担当しています。2019の16日目です。今回は先日行った「焼肉・イン・ザ・ダーク」という企画について書きたいと思います。焼肉・イン・ザ・ダークとは「焼肉・イン・ザ・ダーク」とは、ダイアログ・イン・ザ・ダークをもじった企画で、弊社のアクセシビリティーおじさんことアクセシビリティーのガイドラインの作成やスクリーンリーダー対応のアドバイス等をされている全盲でエンジニアの中根さんと、freeeで開催されたアクセシビリティー関連のイベントにも何度かご登壇頂いた先天性の色弱(P型強度)で視覚情報デザインコンサルタントをされている伊賀さん、お二人が果たして焼肉をすることはできるのかということをアクセシビリティーの観点で研究しようというもの。企画を聞いたとき、普段視覚で肉の焼き具合を把握している晴眼者の我々からすると、聴覚で肉を焼くなんてことができるのか半信半疑で、とても興味深い面白そうな企画でワクワクしていました。JAPAN)アクセシビリティーおじさんこと全盲のエンジニア中根さんP型色覚の視覚情報デザインコンサルタントをされている伊賀さん企画当日メンバーは中根さんと伊賀さんに加えて普段からfreeeでアクセシビリティーの活動に携わっている面々で、11月29日(いい肉の日)に開催されました。お店の前で案内されるのを待っているところ焼き始める席に案内され注文を終えると、早々にお肉が来ました。すると伊賀さんが中根さんに、お肉が乗ったお皿の大きさ、網の形状やサイズを伝えていました。中根さんが網の上に置こうとする肉がどのあたりの位置なのか時計の位置関係で例えて伝えていました。手前だったら6時、左斜め奥だったら10時など)中根さんとご飯行った際はどういった料理が来たかや何をお皿によそったのかを伝えたりしますが、焼肉ではこのようなことを伝えると良いのかと、席に着いて早速学びがありました。youtu.be焼く、そして聞く焼き始めると中根さんが解説をしてくれました。「焼き始めはこんな音」、「良い焼き具合になるとこんな音」、「油が多い肉はこんな音」、「薄い肉だとこんな音」などなど。自分も真似て目をつむり耳を澄まして聞いてみるも、初めはなかなか分かりませんでした。繰り返し解説なども交えて聞いていると徐々に分かってきたように思います。耳を澄まして音から焼き具合を感じ取っている中根さんさて、ここで問題です実際、視覚障害や色覚障害を持っているといかに肉の焼き具合を識別するのが難しいか、お読みになっているあなたにも体験していただこうかと思います。シミュレートした肉が焼かれている様子です。どれくらいの焼き具合でしょう?焼き始め少し焼けてきた。この動画は肉を焼いている際の音声を抜き出したものです。(問題1と同じ形式ですが、音で識別してみてください)焼き始め少し焼けてきた。(こちらも後ろで中根さんの声が。この記事を通して面白そうだなと少しでも興味を持った方は、是非ご連絡ください。2019こんにちは!freeeのエンジニアのmiyarappoです。freeeには2019年5月に入社して、主に課金処理とサブスクリプション管理を集約したマイクロサービスを開発しています。その中で得た知見を共有したいと思います。「サブスクリプションビジネス未経験の人が、サブスクリプションビジネスをする時に考慮すべき最低限のユースケースを想定できるようになる」を目標とします。誰かの落とし穴を塞げたら幸いです。前提この記事で取り上げるユースケースは、サブスクリプションビジネスにおける一般的なユースケースを想定しています。freeeが辿った変遷を参考にしつつ私個人が想定したユースケースであり、現実のfreeeのユースケースと一致しないことをご理解ください。前置きが長くなりました。プラン変更が起こるサブスクリプションビジネスでは、サービスそのものを売るのではなく、サービスを一定期間利用できる「権利」を売っています。この権利は常にアップグレードやダウングレード、数量変更が可能です。変更に耐えうるデータモデルを設計することが重要です。具体的な例やっていき株式会社は、経理をサポートするSassを開発しました。サブスクリプションで販売しようと試みます。初心者プランと上級者プランの2つのプランを用意しました。初心者プランを購入したユーザーが、上級者プランに変更したいと言ってくれました。初心者プランの分を返金して、上級者プランの料金を差額決済します。按分計算が必要になります。上級者プランから初心者プランへの変更の場合は、返金をする必要がありました。売上は請求し回収する必要がある当たり前ですが、売上分の金額をユーザーからいただく必要があります。ユーザーの利便性を考慮し、支払い周期と支払い方法を増やすほど請求・回収業務が複雑になります。スプレッドシートでの管理は、すぐに限界が訪れます。請求業務や回収業務の自動化を進めないと、ユーザーの拡大にバックオフィスが耐えられなくなります。経理をサポートするSassは順調にユーザーを獲得しました。決済方法はクレジットカードのみ対応でしたが、新たにペイパル・銀行振込・PayPayを対応しました。月額払だけでなく、年額払いにも対応しました。2つの支払い周期」のケースに対応する必要があります。スプレッドシートも大きくなり、ユーザーの管理が大変になってきました。登録されたクレジットカードの有効期限がきれて決済が完了出来なかったユーザーに対しては催促のメールを送る必要があります。ある時、月額払いから年額払いに変更したユーザーに、月額の料金を請求してしまいました。銀行振込が行われずユーザーに電話する必要がありました。手形と楽天Payにも対応しようという話が挙がりましたが、管理コストが倍になるので取りやめざるを得なくなりました。オプションの販売が始まるサブスクリプションビジネスでは、ユーザーのLTV(生涯価値)を最大化するべく、様々な施策を講じます。その施策の1つが、オプションの販売です。具体的な例やっていき株式会社の経理作業サポートサービスは絶好調。初心者プランに、年額1200円で電話サポートのオプションを販売することにしました。経理が苦手なユーザーが喜んで購入してくれましたが、このユーザーは初心者プランを月払いで使っています。初心者プランは月払いで、オプションは年払いとなり、ややこしいです。オプションありなし」のケースに対応する必要があります。管理がまた複雑になりました。クーポンの発行が始まる新規ユーザーの獲得は、とても重要です。ユーザーにサービスを使ってもらい後ほど利益を出すという作戦は、サブスクリプションととても相性が良いです。そのため、最初の採算は度外視でクーポンを発行するというケースがよくあります。確定申告の時期になり、経理作業サポートサービスの問い合わせが急増しました。やっていき株式会社は、新規ユーザーを増やすべくクーポンを発行しました。初心者プランを1ヶ月無料で使えるクーポンを1000つ発行しました。クーポンありなし」のケースに対応する必要があります。新規ユーザーの獲得に成功するも、管理がまた複雑になりました。オフラインの販売が始まるオンライン販売から始めたサービスも、拡大に伴いセールスが直接契約を結ぶケースが発生します。多くの従業員を抱える会社の場合は、金額が大きくなるので、セールスが介在して請求書に直接ハンコを押して契約みたいなフローが一般的なようです。セールスが売上分は、システムに反映する必要があります。DBに書き込むわかにもいきませんから、セールス用の管理画面が必要になります。オンライン、オフラインで同じフォーマットで管理しないとキャッシュフローを算出するのが難しくなります。具体的な例やっていき株式会社は、経理作業サポートサービスをセールスが直接販売するようになりました。セールスは現場判断で、割引を行うことが出来ます。Nパターンの割引」に対応する必要になります。全体の売上を把握するだけでも一苦労です。新プランがリリースされるユーザーの契約を永続的に管理することは、サブスクリプションビジネスをやる上で避けられません。一方で、様々なパターンの契約を管理する必要があり、整理された状態でデータを保持するために一定の努力をする必要があります。データが整理されていないと、ビジネスの意思決定(新プランのリリース等)にシステムがついていけなくなります。データをコントロールできる状態に整理しておくことは、サブスクリプションビジネスでは特に重要です。具体的な例やっていき株式会社は、従来のプランを廃止し、松プラン、竹プラン、梅プランの3つに変更しようとしています。初級者プランを梅プランに以降しようとしましたが、クーポンやオプションがついたプランのデータがうまく移行できませんでした。その結果、新プランのリリース時は、一部のユーザーがサービスを使えなくなってしまいました。まとめこの半年間の業務で、サブスクリプションビジネスでは継続的に契約内容を管理する必要があり、データを整理し続けることが重要であることを学びました。紹介したユースケースのように大変な部分もありますが、ユーザーがサービスをずっと使ってくれるのを見れるのは嬉しいです。需要があれば、そのうち具体的なデータ構造とかシステム構成とか踏み込んだ説明をしようと思います。お話しましょう!zuoraの辛みやデータモデル設計とか語りたいです。開発してます!jobs.freee.co.jp明日はモバイルエンジニアのあべちゃんです。参加しましたプロダクトカンパニーの技術戦略2019年、freeeのアクセシビリティを振り返るCEOが開発合宿で6年半ぶりにコードを書いてみたfreeeの脆弱性診断と管理のこれから月別アーカイブ検索スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。