Timee Product Team Blog

タイミー開発者ブログ

t_wada さんに「質とスピード」について講演していただきました

はじめに

こんにちは、フロントエンドエンジニアの樫福 @cashfooooou です。

先日、 和田卓人氏(以下、 t_wada さん)に「質とスピード」というテーマで講演をしていただきました。 この講演にはエンジニア以外の方々も参加してくれました。

僕は学生時代に t_wada さんのテスト駆動開発についての講演を聞いたことがあり、それ以来テスト駆動開発を取り入れるようになりました。

今回の講演でも、なにか気づきが得られるとうれしいなあとワクワクしながら参加しました。

  • はじめに
  • こんな講演でした
    • 冒頭で投げられた問い
    • 犠牲にされがちな「品質」とはなにか
    • 内部品質を犠牲にしたときのスピードの損益分岐点はどこか
  • 講演会の振り返り
    • エンジニアの振り返り
    • エンジニア以外の参加者の感想
  • おわりに
続きを読む

CSとエンジニアを滑らかにつなぐ、タイミーでの「割り込みタスク」の運用フロー

  • 不定期な割り込みタスクは見落としやすく、振り返りづらい
  • Slack + Notionで、割り込みタスクを管理する
    • CSメンバーはNotionに起票後、Slackで報告
    • エンジニアメンバーは、Daily Standupで優先度をつけ着手
  • 職種をまたいだ依頼フローをもっと整えたい

※このブログは Cocoda さんに寄稿したものです。

タイミーでバックエンドエンジニアをしているedyです。 スキマ時間にバイトができるアプリTimeeを運営しています。

timee.co.jp

続きを読む

役割を超えたインタビューから『組織として』顧客を理解する

こんにちは、タイミーでプロダクトマネージャを務めている高石 ( @tktktks10 ) です。

戦略やロードマップの策定から、プロダクトの成果を最大化するための課題発見や優先順位付けを日々の業務としていますが、今回はその中でも顧客と直接顔を合わせる「ユーザーインタビュー」を起点とした取り組みの話をしようと思います。

ユーザーインタビューの積み重ねから組織のアライメントを生み出す

タイミーでは最近新たに入社頂いたPMMの影響もあり、ユーザーインタビューの頻度を大幅に増やしています。きっかけは単に顧客解像度を上げようという至ってシンプルなものでしたが、横断的に継続する中で次第に部署や役職を超えた共通の顧客像*1(セグメント)が出来上がり、最近では全社戦略やプロダクトロードマップ、個別の施策にも引用されるまでになってきました。

一言で言えば、「横断的なユーザーインタビューの積み重ねから組織として顧客像を定義し、戦略や施策に活用している話」となります。

役割にかかわらず、同じ顧客像を向くことで価値提供の前提が揃います

組織全体で共通理解のある顧客像は、全社戦略からチームレベルの施策全てにおける主語となり、自ずと各所の取り組みが同じ方向を向く、所謂アライメントが取れている状態を生み出します。アライメントが取れている状態ではあらゆる場面でコミュニケーションコストが削減される他、マーケティング、プロダクト開発、カスタマーサクセスまでなど、一気通貫した課題解決に繋がります。

ユーザーインタビューやペルソナ、個別具体に関する記事は多いものの、実際に構築から運用までを紹介した実例を見かける機会は少ないように思い、今回はタイミーにおける実際のプラクティスをまとめました。


*1 厳密には顧客とユーザーの双方が存在しますが、ここではまとめ上げられたもの呼称として"顧客像"(セグメント)に統一することとします

続きを読む

バッチ処理の改善 〜冪等性の設計導入〜

前編(トランザクション範囲の最小化)へ

はじめに

こんにちは。タイミーのバックエンドエンジニア中野です。

前編では締めのバッチ処理におけるトランザクションの範囲を最小化した技術的改善をご紹介しました。トランザクションの範囲をバッチ処理全体から最小限の範囲に変更したことにより、バッチ処理が失敗した場合に請求レコードの処理が途中まで完了している状態が発生するようになりました。後編では、処理対象の請求レコードに対し状態を持たせることでバッチ処理全体での冪等性を担保し、バッチ処理が途中で失敗した場合でも安全に処理を再開できるようにした取り組みをご紹介します。

  • はじめに
  • 締めのバッチ処理とは
  • 現状の課題認識
  • 実施した施策
    • 冪等性とは
    • 冪等性を実現する方法
    • バッチ処理への適用
  • 達成できたこと
  • 今後の課題
  • まとめ
続きを読む

バッチ処理の改善〜トランザクション範囲の最小化〜

後編(冪等性の設計導入)へ

はじめに

こんにちは。タイミーのバックエンドエンジニアの中野です。よくGopherくんに似てると言われます。

本記事では月次で実行している「締め」のバッチ処理に関する一連の技術的改善について掲載します。弊社のプロダクト「タイミー」は著しい事業成長に伴いデータ量が急増してきています。そこで今回はデータ量の急増を背景とした中長期的なバッチ処理の設計改善にどのように取り組んできたのかをご紹介したいと思います。バッチ処理に関する技術的改善の記事は前編・後編の2部構成をとっています。前編はバッチ処理におけるトランザクションの改善をテーマに、後編ではバッチ処理に冪等性の設計を導入したことをご紹介したいと思います。
今回は前編のトランザクションの改善をテーマにご紹介します。すでに本番稼働しているアプリケーションにおいてトランザクションの範囲が大きい場合にどのような問題が発生したのか、そしてどう解決していったのかを中心に取り上げます。

読み手としては、今後データ量の急激な増加が見込まれるプロダクト開発の中長期的な設計・運用を模索している方を想定しています。また読み手に該当しない場合でも、現在タイミーがどのような事業を推進しているのか興味を持ってもらえるように記載しましたので是非最後までお付き合いください。

続きを読む

ユーザーインタビュー参加コストを極小化する仕組み

この記事はタイミーのPMM(Product Marketing Manager)のishinabeが担当します。

PMM??と思った方もいるかもしれないので軽くどんなミッションを持っているのかを説明しておくと、デプス調査や定量分析などなどを絡めて顧客課題やジョブの発見から、その深さ・ボリュームの推定、リリースする機能のマーケットイン(機能に価値を感じてもらえる顧客に機能を認知してもらい使ってもらうこと)あたりを主な任務としてIssue度が高いものから解決しようと動いています。

また、今回の記事のテーマのように、デプス含めた顧客理解を組織にインストールすることも重要なミッションとして捉えています。

※前提、世の中的にもまだ役割がかっちりと定まっている訳ではないので、私も関連チームと会話しつつ模索しながら動いている段階です(この記事の話はどちらかというと世に言うUXリサーチャーっぽい動きかも知れない)。

さて、本題の「ユーザーインタビュー参加コストを極小化する仕組み」お話しです。
なお、以降「ユーザー」→「ワーカー」と表記します。タイミーのサービスのユーザーは、お仕事内容を掲載して働く人を募集する「クライアント」と、お仕事に申し込んで働く「ワーカー」に大別されるためです。

  • 何をやったか
    • やりたいという意思表示をしたらあとは当日参加するだけ
    • 裏側で処理されていること
    • インタビュー参加のサポート
  • なぜやったか
  • 取り組みへのフィードバックなど
    • 今後の展望
  • 最後に自己紹介とおさそい
続きを読む

Notion API を使った機能開発 〜最小の実装で作る要望回収システム〜

はじめに

こんにちは、フロントエンドエンジニアの樫福 @cashfooooou です。 タイミーでは toB 向け管理画面を作成しています。

半年ほど前、タイミーでは顧客からのサービスへの要望を集め、管理するシステム(以下、要望回収システム)を作りました。 顧客の課題から新しい機能について考え、顧客により価値のあるものを届けるための施策です。

システムの実装には Notion という SaaS を活用しました。 最小限の実装で良い機能・良い運用が作れたと思っています。

この記事では、要望回収システムの実装に取り組んだ経緯から、実際の運用の例まで紹介します。 同じように顧客の要望回収を行いたい方はもちろん、SaaS を使ったミニマルな機能開発の参考になれば幸いです。

  • はじめに
  • Notion
  • 従来の回収システム
    • 課題
  • 解決したい課題
  • Notion API を用いた課題解決
    • 制約
  • データベースの構成
  • 回収システムの Notion の構築
  • 運用
  • まとめ
続きを読む