Tebiki株式会社でQAエンジニアを担当している中西です。最近CREの活動も兼務しています。 QAエンジニアである私は、プロダクト開発のプロセス改善の一つとしてTebiki株式会社でCREの職種の導入を提案し、2024年1月から活動を開始しました。 今回の記事では、Tebiki社でCREの職種を立ち上げた経緯と、業務内容、そして今後取り組みたいことを紹介します。この記事を読んで、我々のCREに興味を持っていただければ幸いです。 CRE 立ち上げの背景CRE（Customer Reliability Engineering / Engineer）とはご存知の方も多いかと思いますが、CRE（Customer Reliability Engineering）という職種は、2016年にGoogleがGoogle Cloud Platform（パブリッククラウド）事業で発表した新しい専門職です。（

はじめまして、2023年の12月にWebアプリケーションエンジニアとして入社した鈴木です。 主な仕事は tebiki現場分析 のアプリケーション開発で、 Product Engineer として幅広い業務に携わっています。 早いもので、自分が入社してから半年が過ぎました。 SaaS企業でエンジニアとして働くことが初めてである自分にとって、この半年は多くの学びがあり、とても充実したものであったと感じています。 当記事では、そんな学びの中から一つを「エンジニアにとってのカスタマーサクセス」というテーマで紹介させていただきます。 ※ 当記事では、カスタマーサクセス(以下、CS)を「顧客が成功する（成果を出す）ことを能動的にサポートすること」とします。 職業としてCSをされている方のことはCS担当者と表記します。 エンジニアにとってのCSとは現時点での自分は、以下のように考えています。 自身の影響

はじめに2024年1月に入社した村上です。前職では小説投稿サイトの開発・運営を行っていました。 入社して数ヶ月が経ちましたので、入社前に持っていた思いと実際に入社して感じたことについてお話しします。 入社したいと思ったきっかけ端的に言えば、「これから伸びる市場で、ユーザーに喜ばれるプロダクトを作れそう」と感じたからです。 具体的には以下の二点が大きな理由です。 1. 挑戦的な事業領域以前ECサイトを運営している会社に所属しており、自社工場の見学や日常業務を通じて製造現場を垣間見てきました。 それまでは「製造現場ではパッケージのソフトウェアががっつり導入していたり、ロボットなどで高度に自動化されていそうなので、Webエンジニアにできることはない領域」という印象を持っていました。 ただ、(ここには書けませんが…)実際にはWebエンジニアの技術で解決できる課題が多く存在しており、未開拓だと感じま

2023年11月にリリースされた『LEADING QUALITY』という書籍は、QAエンジニアだけでなく、CTOやEMといったマネジメント層からも大きな注目を集めました。 私はQAエンジニアとして、この本から得られる知識の共有と影響力をより発揮するため、『LEADING QUALITY』の講演会／読書会を企画、実施しました。この記事では、その背景と本書籍を活用した今後の改善活動についてお話しします。品質改善活動の進め方に困っているQAエンジニアの方々の活動の一助になれば幸いです。 Tebikiの品質課題約1年間開発チームを支援し、QAエンジニアである私は現在、以下の課題を持っています。 ・スクラムチームは、中長期的な品質課題に関心が向きにくい スクラムチームは、事業を加速させる価値をユーザーに提供することを目的として活動しており、その活動を阻害する品質課題には対処します。重大な不具合の修正

2024年3月に『LEADING QUALITY』の訳者でもあり、QAブレインとして様々な場で講演されている@mkwrdさんを社内にお招きし、社内講演会を実施しました。 講演会当日はCTO、PO、SM、テックリード、CREのメンバーが参加し、ソフトウェア品質とビジネス価値の関係性や品質文化を学びました。また、参加者にとって有意義な時間にするために、講演会前までに『LEADING QUALITY』第2章、第8章を参加者に一読してもらいました。今回は事前学習や講演会の様子をご紹介いたします。事前学習と講演会により、参加者それぞれの品質に対する考え方が明らかになりました。 演会前の事前学習参加者が『LEADING QUALITY』の第2章、第8章を読んで気になった点です。Tebikiの開発チームがアンテナを張っている点が明らかになりました。 第2章 3つの品質ナラティブ

私達のチームが開発してきた「tebiki現場分析」を2024年1月下旬に正式にリリースしました。 tebiki現場分析は、製造現場の帳票をデジタル化することでデータの可視化と分析を可能にするプロダクトです。Tebiki社としては、tebiki現場教育 に続く2つ目のプロダクトになります。 tebiki 現場分析チーム立ち上げ時から携わってきた私にとって人一倍思い入れの強いプロダクトです。「このプロダクトを成功させるためなら何でもやるぞ！そのためにお客様をもっと理解したい」というモチベーションからtebiki現場分析 として初の展示会出展になる「第8回 スマート工場 EXPO SFE 2024」に展示スタッフとして1日お手伝いさせていただきました。本記事ではその感想と学びをご紹介します。 「Tebiki が新しいプロダクト作ったんだ」という宣伝や「Tebikiにはこんな事考えてるエンジニアが

はじめまして。約2ヶ月前に Tebiki に入社した村上です。 現在 Tebiki では、2プロダクト4チームで開発を進めております。Tebiki では週次の全社ミーティングがあり、そこで各チームがどんなものを作っているのかは知ることができます。一方、全社員対象なので技術的な深堀りは難しく、それぞれのチームであった技術的な挑戦や良い知見というものは、自分で他チームのドキュメントを見たり GitHub の Pull Request を見ないと得られない状態でした。 そこで、チーム外のエンジニア同士での情報交換を活性化するために、ホットトピックス共有会 & LT 大会を開催することにしました。(前職でうまくいってた仕組みをそのまま使いました) ホットトピックス共有会ホットトピックス共有会では、各チームから事前にホットなトピックを3つ程度挙げてもらい、それについて詳しい人が口頭で説明するという流

Tebiki社でQAエンジニアをしている中西です。 多くのテストエンジニアやQAエンジニアは、ユーザー目線でのテスト経験があるかと思います。プロダクトのユーザーとプロダクトの使われ方を想定して、テスト対象がユーザーのニーズにマッチしているかを確認しているのではないでしょうか。 Tebiki社では、「ユーザの行動が全て」というValueがあり、開発チームはプロダクトライフサイクルを通して、このバリューを体現することが求められています。つまり、ユーザー目線でテストすることに加えて、ユーザー行動に基づきテストすることが求められているのです。 本記事では、ユーザー目線でのテストとユーザー行動に基づくテストの違いを明らかにし、それらのテストを行うための取り組みを紹介します。この記事がユーザー行動にフォーカスしたテストプロセスの改善のきっかけになれば幸いです。 ユーザー目線でのテストとは本記事では、「

Tebiki社でQAエンジニアをしている中西です。 「開発エンジニア自身がプロダクトの品質保証をする。」このように開発エンジニアが自信をもって開発・テストできるようになってほしいと思いませんか？ この記事では、「品質やテストのアドバイザーであり続けるQAチームへ」というタイトルで、Tebiki社での品質やテストのアドバイザーとしての関わり方とそのような関わり方をしている理由、今後の関わり方を紹介します。開発エンジニアを間接的に支える働き方をするQAチームに興味を持って頂ければ幸いです。 品質やテストのアドバイザーとは我々QAチームは、「プロダクト開発に関わる全ての人がより早く、自信を持って、継続的にユーザにとって正しい価値を提供し続けることを支援する。」というミッションのもと活動しています。現在は「自信を持って、継続的にユーザにとって正しい価値を提供し続ける」ことに注力したサポートを行って

あなたのチームがいくつも未着手の仕事を抱えているとき、どのようにそれらに着手し、そして完了させていったら良いでしょうか？ アジャイルには「始めるのをやめよう。終わらせることを始めよう。」という言葉があります。Tebiki株式会社では、この考え方を基本として、 デスクレスワーカーのための現場教育SaaS「tebiki」を開発しています。 この記事では、新しい仕事を「始める」ことを優先する場合と、仕掛り中の仕事を「終わらせる」ことを優先する場合の比較をしながら、かつては「始める」ことを優先していた Tebiki社が「終わらせる」ことを重視するように変わっていった事例を紹介したいと思います。 仕事が「終わる」とはまず前提として、仕事が「終わる」とは、どういうことでしょうか？たいていの仕事では、まず必要な作業を計画し、それを実行することでその仕事を進めるはずです。 それでは、計画していた作業をひと

Tebiki株式会社では「現場向け動画教育プラットフォーム tebiki 」を開発しています。そして、このプロダクトの価値を最速で大きくしていくために、スクラムを導入しています。 スクラムによりtebikiの開発チームはより速いプロダクトのフィードバックサイクルを回せるようになりました。その一方で「スクラムチームはどのように技術的負債の解消に取り組んでいけばいいのか？」という課題に直面しました。 この記事では「スクラムと技術的負債の解消の両立」という課題に対してTebiki社が導入した「20%ルール」についてご紹介します。 Tebiki社における20%ルールとはTebiki社の20%ルールは エンジニアが開発に充てられる時間の20%をスプリントゴール以外のことに使うこと。 というものです。 つまり、エンジニアのリソースは以下のように使われます。 スプリント … 80%スプリント以外の開発業

あなたがやった仕事、不良在庫になっていませんか？ Tebiki株式会社では「知的在庫をできるだけ持たない」という考えのもとに、現場DX の SaaS「tebiki」を開発しています。この記事では、Tebiki社の考える知的在庫とは何か、そしてそれを持たなくて済むようにするためにどのような取り組みをしているかをご紹介します。 在庫とは在庫と聞くと何を想像するでしょうか？ 靴屋の在庫一掃セール？ 倉庫での棚卸し作業？ 経営者の方にとっては、キャッシュフローの悩みのタネかもしれません。 この記事では、在庫を「将来利益へと変換されるビジネスのネタ」と定義します。 どのようなビジネスでも、資金によって在庫を獲得し、それを使って利益を生み出すからです。 在庫商品を売って利益を得るソフトウェア開発における在庫靴屋などの小売店が商品である靴を在庫として抱えるように、ソフトウェア開発でも在庫は存在します。

先日「プロダクトの価値を最速で最大化し続けるために取り組んでいる、SaaSスタートアップのモニタリングLT」というイベントを YouTube Live にて開催いたしました。当日ご視聴いただいた皆様、一緒にご登壇くださった dinii 唐澤さま、スマートラウンド 小山さま、Spir 篠原さま、エンペイ 小口さま、誠にありがとうございました。 今回はこのイベント配信を通して、具体的にどんな作業が必要だったか（こうしておけばよかった含む）をまるっとまとめてみました。 意外とやることがいっぱいあったので、今後技術イベントを配信したいと思っている方の参考になれば幸いです。 （渋谷 @shibukk） 登壇者の募集までにやることオーガナイザーを決めるまずはじめにやること、それはイベントオーガナイザー（＝取りまとめ役）を1人決めることです。 複数人で話がスタートしたとしてもこれはマストで、誰が推進力を

Tebiki社のWebアプリケーションエンジニアの中山と申します。前職では、SIerでAIアプリの開発を3年弱経験し、現職のTebiki社では、to B向けSaaSの機能開発を行なっています。好きな言語は、C++, Python, Ruby です！ この記事では、GitHub Discussionsの運用による知識のストック化と、新人オンボーディング時の負担軽減についてご紹介します！ Tebiki社のDiscussionsとは？Tebiki社では、エンジニアチーム内の知識を共有するツールとして、GitHubのDiscussions機能を活用しており、これまでチーム内で議論した内容や暗黙知であった内容をQ&A形式で記録しています。 TebikiのDiscussionsDiscussionsの運用ルールDiscussionsを運用するにあたって、以下のようなルールを作っています。 Discus

これは、フィヨルドブートキャンプ Advent Calendar 2021（Part 1） 13日目の記事です。 未経験からフィヨルドブートキャンプでプログラミングを勉強し、2021年3月から Tebiki 社でエンジニアとして働いている masuyama13 です。 入社当初、PR（プルリクエスト）を作成する際にコミットの整理に毎回かなり時間がかかるのが悩みでした。試行錯誤の結果、この悩みを解消することができたので紹介します。 それが、コードより先にコミットメッセージを書くという方法です。 コミットメッセージを先に書くやり方まず、タスクを分解して TODO リストを作ります。これから作業する内容がイメージできたら、コミットメッセージを一つ考えます。エディタなどにコミットメッセージを入力します。コミットメッセージが書けたら、それを常に意識しながらコーディングを進めます。作業中にコミットメッ

この記事は AWS Startup Community Advent Calendar 2021 の2日目の記事です。 弊社が提供する「現場向け動画教育プラットフォーム tebiki」は法人向けクラウドサービスで、一般的には BtoB SaaS と分類されます。 今回はこういった「BtoB のプロダクトを作る上でドメインエキスパートという存在はどれくらい重要か、ドメインエキスパートに活躍してもらうにはどうすればよいか」について書いてみたいと思います。 （渋谷 @shibukk） ドメインエキスパートとは何か皆さんは「ドメインエキスパート」という言葉を知っていますでしょうか？エンジニアの方だと聞いたことがある人のほうが多いかもですね。 私がこの言葉を一番最初に聞いたのはドメイン駆動設計（DDD）の文脈でした。 2003 年に刊行された DDD の原典である『エリック・エヴァンスのドメイン駆動

ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は「プロダクト開発チームがプロダクトに集中できるように、専門性の高い技術課題を解決するチームを作りたい」という弊社の組織設計についてパブリックなところに公開してみたいと思います。 理想の組織とフルスタックの限界会社組織が大きくなっても、プロダクト開発チームはできる限り当事者のみで意思決定ができるように小さくしたいと考えています。 そうすることで開発スピードが上がり、その結果ユーザーへの価値提供がより高められるという信念からです。 ですが、プロダクト開発チームを小さく保つということは、各人のスタックを広げる必要があることを意味します。担当を分業するとその分専門性は高まりますが、同時に関係者が増えてしまいますよね。 そして専門性がないと乗り越えられない技術の壁も存在