SaaSのNRRは役に立たない？見るべきは契約後12ヶ月の月次推移。グローバル、日本、自社の数値で解説。 一般に定義されている「NRR (売上継続率)」の算式は、SaaS企業の稼ぐ力を総合判断するには役立ちますが、そのまま数字を見ても直近のカスタマーサクセス戦術評価には役立たないよ、という分析を自社データを交えて解説します。 なお、平均顧客単価とNRRは正比例の関係にあり、例えば月額5,000円のSaaSのNRRは低く、月額15万円のNRRは高くなります。ビジネスモデルの違いから来るもので両者を比較する意味はありません。本記事では高単価SaaSを念頭において書いています。 貴山敬 (@tkiyama) 「NRR (Net Revenue Retention)」とは日本語では「売上継続率」。既存顧客が伸びているのか／減っているのか、という指標で、SaaS企業の力をあらわす重要指標の一つです。

Tebiki株式会社でデザインマネージャーをしている鮫島です。 私たちが提供しているデスクレスワーカーのための現場向けSaaS「tebiki現場教育」と「tebiki現場分析」は、作成、分析、共有といった異なるプロセスを一元化するために多機能化していきました。しかし、提供する高度な機能がユーザーにとって使いこなしにくいものでは意味がありません。ユーザーに求められるのは、これらの複雑な機能を直感的で「かんたん」に操作できることです。 「かんたん」であることは多くのデジタルプロダクトにとって重要な価値ですが、その感覚は主観的であり、プロダクトを提供する側が無策でユーザーにとっての「かんたん」を定義することは困難です。 この記事では、「かんたん」の本質を探り、ユーザーが直感的に操作できるプロダクトをどのように実現するかを弊社の事例と合わせてご紹介します。 「かんたん」の源泉「かんたん」と感じる（

一旦雑に書く。 半年くらいかけてやっと、チームがメテオフォールからスクラムを実践できつつある。。。 自分もアジャイルが何たるか、スクラムが何たるか、、、、あんま分かってないけど、大事にしていた心構えというかマインドセットがある それは、「アジャイルをする」んじゃなくて「アジャイルという生き方を選ぶ」（ちょっと大袈裟だな）ということだ。 自分たちの独りよがりなモノ作りをするのではない。一方通行的にいつまでにこれを作れというモノ作りをするのではない。 「我々はなぜここにるのか」「我々が届ける価値とは何なのか」 ここだけはブラさずにやってきたと思う。 価値に、アウトカムに集中する 集中すべき以外のものは捨てるorやらないという選択をする（これが一番しんどい） 少しずつご近所さんを探し、対話し、巻き込み気付けば執行役員や事業部長たちと一緒にプロダクトの未来を話せるようになってきた。 モノ作りのHo

Tebiki株式会社で「tebiki現場教育」のプロダクトエンジニアを担当している清田です。 「tebiki現場教育」の開発チームではスクラムを導入しており、1週間のsprintごとにレトロスペクティブでふりかえりを行っています。 一方で、規模が大きい機能のリリース等をきっかけとして、sprintごとの短期間のふりかえりではなく、普段とは違う長期間のふりかえりをやる機会もあるかと思います。 我々のチームでも長期間のふりかえりを実施する機会があったのですが、そこで難しさを感じたと同時に学びを得たので、今回はその内容についてお話ししたいと思います。 事例1「スキルマップ開発全体のふりかえり」実施の背景「tebiki現場教育」にて新規機能であるスキルマップ機能が2024年春頃にリリースされました。 スキルマップ機能開発はこれまでの機能開発と比べて開発規模や不確実性が大きく、多くの課題を抱えながら

Tebiki株式会社でQAエンジニアとCREを担当している中西です。CREを導入し、半年以上が経過しました。 CREとして活動している私は、ユーザーからの問い合わせの早期解決という点で、開発チームやカスタマーサクセスチームに貢献できている感覚を持っています。私の感覚にギャップがあるかどうか、CREをもっと良くするために必要なことは何かを知るために、CREと協力することが多い職種の方々にインタビューを実施しました。 インタビューに協力して頂いた方々はこちらの方々です。 日笠 陽仁／テックリード テックリードとして、設計や実装の品質を支援。現在は、技術的負債の解消に先陣をきって取り組み中。調査の難易度が高い、もしくは緊急性が高い問い合わせ発生時には、CREと一緒に調査も行う。 中村 翔平／チームリーダー スクラムチームに足りない能力を見極めて補完できるようにプロダクトオーナー、プロダクトデザイ

SaaSの「コンパウンドスタートアップ」「コンパウンド戦略」という言葉は今年に入ってすっかり定着して、上場企業の決算説明資料でもちょいちょい目にするようになりました。 いろんなところで見聞きしてると、人によって「コンパウンド」が指している内容がけっこう違うように思うので、整理メモとしてまとめてみました。結論を先に書くと、「SaaSのマルチプロダクト展開は必須だけど、アーリーフェーズのコンパウンド戦略はマジでむずいよ」。 貴山敬 (@tkiyama) コンパウンド戦略とはマネーフォワード社の決算説明資料では、コンパウンド戦略を「単⼀のプロダクトやセグメントに限定せず、共通基盤やデータを中⼼に複数のプロダクトを複数のセグメント向けに同時に提供する」と定義しています。 「共通基盤やデータを中心」に、「複数のプロダクト」を、「同時に提供」という3つが大事なポイントです。後述の『マルチプロダクト』が

チームのパフォーマンスを高めるために、日々試行錯誤している方も多いと思います。私自身も、プロセス改善にこだわり続け、うまくいった部分もあれば、失敗を経験した部分もあります。今回は私のチームリーダーとしての失敗談と学びを共有したいと思います。 チームリーダーとしての責任Tebiki株式会社 エンジニアの二瓶と申します。私は Tebiki株式会社の Web アプリケーションエンジニアとして入社し、現在は tebiki現場分析 の開発を担当しています。また、チーム内では「チームリーダー」という役割 を担っています。弊社のチームリーダーのミッションはざっくりいうと「生産性とプロダクトの品質を最高の状態に保ち、プロダクトの価値を最大化できるような『チームの状態』をつくること」です。ここでいうチームとはプロダクトマネージャー、デザイナー、エンジニアを含む開発チームことです。これまで一人の開発者として手

はじめに 凄腕エンジニアさんから学んだ例外の話、たくさん読んでいただけているみたいでありがとうございます。 はてなブックマークのコメントなども読ませていただき、勉強させていただいています。 コメントを読んでみて、自分の記事がちょっと誤解を与えてしまっている部分もあるのかもしれない。。。と感じましたので、今回補足記事としてこの記事を書きます。 【例外が起こった時の挙動を決めるのはプレゼンテーション層】について この表現によって、例外は常にプレゼンテーション層でtry-catchをするものなんだと誤解を与えてしまったかもしれません。 この表現で伝えたかったこととしては、例外の挙動を決めるのは上位レイヤーであるため、下位レイヤーである業務ロジックの部分でtry-catchして例外が起こった時の挙動を決めるのはあまり良くないということでした。 システム例外と業務例外と区分したとして、Webアプリで

こんにちは！ with で iOS エンジニアをしている中村です。 iOS エンジニアを名乗っているものの、 iOS 開発経験はまだ半年足らずで、それまでは with の Android エンジニアをしていました。 2022/10 に iOS チームに異動させてもらったものの、ほぼゼロからのスタートだったので成長を目に見える形に残したく TIL を続けていました。 TIL とは、 Today I Learned の頭文字を取ったもので、その日学んだことを Github などに記録していくことらしいです。 今回は職場の Slack の iOS チームのチャンネルで、 TIL を放流していくことにしました。 以下のような形で [TIL] のタグを付け、些細なことでも良いので基本毎日その日学んだことを投稿していました。 チームのチャンネルでやるとチャンネルが汚れてしまうかな、とも思いましたが、私

はじめに 今携わっているプロジェクトで凄腕エンジニアさんと一緒に開発をさせていただいているのですが、その凄腕エンジニアさんから教えていただいた例外の話がとても勉強になり、 さらにこの例外の話を他のプロジェクトのエンジニアさんに伝えたところ、反応が良く、とても勉強になりました！という声をいただけたので、アウトプットしていきたいと思います。 （この記事の中で凄腕エンジニアさんのことはTさんと呼ぶことにします。） ※【凄腕エンジニアさんから学んだ例外の話】の補足 というQiita記事を書きました。 この記事を読み終わった後に疑問が残った人などは補足資料として読んでいただけると嬉しいです。 例外の考え方の源 Tさんの例外の考え方は http://diveintopython3-ja.rdy.jp/your-first-python-program.html#exceptions ↑こちらのPyth

インターネットでのレスバを見るのが好きだ。 特に、過激派同士がトンデモ理論で殴り合っていると人類の創造性を感じずにはいられない。 そういう争いをもっと見るため、争いが起きる場があれば両陣営に扮して対立煽りをしてきたし、なんならまとめサイトも作った。 そんな俺にとってAIイラストは絶好の狩り場だ。 メインの層が10代〜20代、クリエイターを盲信している若年層。 年齢高めの層もまともな教育を受けておらず、精神年齢は子供並み。 インターネットに慣れていないキッズは釣りやすくて助かる。かわいいね〜 あまりにもチョロすぎて手応えがなかったから、対立煽りの手法を公開する。 ・レッテル貼りをするAI推進派には「盗賊」「ケガレ」「犯罪者」 反AIには「馬鹿」「ラッダイト」「因習村」 などの言葉を投げつけてやろう。 もちろん呼称はもっと沢山ある。クリエイターなだけあって言葉遣いも創造的ですねw 最近は誹謗中

はじめに 最近コードを書いていてふと、今の自分は以前とは全く違う思考でコードを書くようになってるな。。。と気づいたので、少しまとめたいと思います。 以前 「本でこういうコードの書き方が良いって書いてあったな〜」 「本でこういうコードの書き方だめって書いてあったな〜」 「凝集度あげるためにデータとメソッドは一箇所にまとめた方がいいな〜」 「単一責務の原則に反しているからなおさないとな〜」 ↓ 実際に改善 ↓ 「よし綺麗になった」 最近 「使いやすい形のインタフェースになっているかな？」 「メンテのためにも共通化しておいたほうが良いな。。。」 「どういうデータ構造で持っておくのが嬉しいだろうか？」 「直感的に理解できるようになっているだろうか？意図などは伝わるかな？」 ↓ 実際に改善 ↓ 結果的に綺麗になっている 以前と最近との違いは？ 以前と最近の主な違いは、思考の過程で具体的に自分のコード

Twitter 形式でメモが残せる Obsidian Memos で「考えるな、書け」を体現できるくらい筆が進むようになった 2023-06-16 Obsidian-Memos という Obsidian のプラグインを Twittier で見かけて1ためしてみたら、Obsidian が更に便利になったので紹介。 https://github.com/Quorafind/Obsidian-Memos 以下、こんな感じで daily journal に list or task 形式で書き出されていく Memos の画面 Daily Note にはこんな感じで書き込まれる。 これらの内容は以下のような形式で Daily Note にリスト or タスク形式で書き込まれていく。 - 01:25 Memos を入れてみた、しばらく試してみる - 01:25 書きなぐるようにメモれるのは楽かも、ti

はじめに 最近ドキュメントを Notion で管理する人たちも多い今日この頃 弊社でもドキュメント管理はNotionを使っているところが多いのですが、 意外と何も考えず使ってるーみたいな感じでした。 今回、管理しているNotionのドキュメントを整理する機会があって 「どうせ整理するなら、本気で向き合ってみよう！」 ということでNotionについて色々試行錯誤したのでそれのアウトプット。 その1: いろんな人のnotionをたくさん調べる まずは他のNotionユーザーさんがどんな使い方をしているのか調べてみました。 そして意外とそういう記事？あんまりなく記事探しから悪戦苦闘..... そこである記事に「日本国外のユーザーの使い方がめっちゃオシャレ！Pinterestで画像検索すると良いよ！」というのを見つけて早速検索。 私は「https://www.pinterest.jp/search

はじめに 普段自分がよく使用しているMacのツールをまとめました。 今回はあくまでも「デスクトップアプリ」が用意されているものに対してのまとめになるため、Webサービスだけのものは含めていません。 また、特定の開発領域に必要になるツール類もここでは紹介していません。あくまで汎用的なものに限定しています。 注目！Mustで入れておきたい Raycast ざっくり ランチャーアプリ。 Alfredなどが対抗としてありますが、Raycastは無料です。 クリップボード履歴・アプリ起動・クイックリンク・簡単な計算・簡易的なスニペット・画面分割などなどがすぐに操作できる。キーボードでMacを操作する範囲を広げるためにはマストでほしいです。 後述で書くKarabinerのHyper Keyという概念と組み合わせることによってショートカットキーが衝突問題から解放されます。 こんな悩みが解決します アプリ

こうしてふりかえりは終わってしまった / A Demise of a retrospective ふりかえりカンファレンスで一番面白かった発表資料です。 資料をざっくり要約すると ふりかえりは最初は順調に機能するがある段階で停滞し、次第に「効果が出ていないもの」と判断されて廃止されてしまう、という話です。 理由として最初は低コスト高リターンの課題を倒していけるが、それらをすべて解決すると残るのは「リターンはあるが、コストが高すぎて解決できない課題」と「コストは低いがリターンもほぼない課題」だけになります。 開発チームは前者を「コストが高すぎて解決できない」と忌避し、後者だけに打ち込んだ結果、リターンが出ずに振り返り事態を無価値を判断してしまうからです。 ふりかえりを廃止することでチームの成長は停止してしまうでしょう。 これを防ぐために「コストが高すぎて解決できない」課題を解決する方向に頑張

Laravel Advent Calendar 2020 - Qiita の 19日目 の記事です。 今回は個人的な興味本位も有り、Laravelの2011年のリリースからの歴史をネットから調べてまとめてみようと思います。 参考、引用した記事やページは最後にまとめてあります。 Laravelが生まれた背景 2011年当時、CodeigniterがPHPで使用される人気のフレームワークだったそうです。 ASP.netを業務で書いていたTaylor Otwellは、副業でPHPを触っており、Codeigniterを使っていました。 フレームワークの内部コードを操作せずに、必要なすべての機能を追加することが出来ないことを不便に思い、 よりシンプルで、より柔軟なものをという欲求からLaravelを自身で作り始めました。 Codeigniterを補完する気持ちがLaravelを生み出したようです。

【徹底解説】これからのエンジニアの必携スキル、プロンプトエンジニアリングの手引「Prompt Engineering Guide」を読んでまとめてみた こんにちは。CX 事業本部 Delivery 部のきんじょーです。 ここのところChatGPT と戯れてアプリを作ったり、様々なプロンプトの検証をしていましたが、言語モデルの性能を最大限に引き出すために、体系的にプロンプトエンジニアリングを学びたいと考えていました。 GitHub に「Prompt Engineering Guide」という素晴らしいリポジトリがあったので、読んで検証した内容をブログにまとめていきます。 本記事は、執筆時点の上記リポジトリの内容を元にしていますが、意訳や独自に検証した日本語のプロンプトを含みます。 上記リポジトリも絶賛開発中の段階のため、最新情報や原文が気になる方はリポジトリを直接参照してください。 目次 プ

プロダクト、サービス、アプリやソフトウェアなどのランディングページ用のHTMLテンプレートを無料でダウンロードできるHTMLrevを紹介します。 ランディングページ用のHTMLテンプレートはすべて無料で、商用プロジェクトでも帰属なしで利用できます。 HTMLrev HTMLrevは先日ローンチされたばかりのサイトで、ランディングページ用のHTMLテンプレートが無料でダウンロードできます。 HTMLテンプレートはMITライセンスで、商用プロジェクトでも無料で利用できます。詳しくはLicenseをご覧ください。

ドキュメンタリアンとは、役職に関係なく、ソフトウェア業界でドキュメントとコミュニケーションに関心を持つ人のことです。 www.writethedocs.org はじめに これは主に『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』の書評です。私はSreakeにてSREという役職についています。SREはサービス概要、アーキテクチャの解説や図、各種構成図、各種手順書、ポストモーテム、ポリシー、SLA(SLO) … その他の様々な場面でドキュメントを書く必要があります。しかし、ドキュメントは価値が見えにくく時間と労力がかかり品質担保の面で重要度がとても高いのにその場での価値が見えにくいので浸透しにくいです。そのため、エンジニアとしてモチベーションが保ちづらいです。2021年 State of DevOps 2021 にもドキュメントに関する言及があり今後、