サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
買ってよかったもの
techblog.tebiki.co.jp
Tebiki株式会社で「tebiki」のプロダクトエンジニアをしている日笠です。今回はtebikiで利用しているgemのニッチな使いづらさを解消したことについてお話しします。 tebikiは、製造業/物流業/食品業/小売業/飲食業などの現場でノウハウを可視化し効率的な教育を可能にするプロダクトです。tebikiはRuby on Railsで開発されており自動テストのデータ生成にFactoryBotを利用しています。 FactoryBotの機能の一つに、生成するデータそれぞれに連番を振ってくれる sequence というものがあります。sequence はデータを作る度に内部で持っているポインタをインクリメントすることで連番を生成します。 以下は toBサービスによくある会社に所属する従業員を扱うドメインのコードで、ここでは従業員番号を生成しています。 FactoryBot.define d
Tebiki株式会社でQAエンジニアをしている中西です。 2023年1月に一人目QAエンジニアとして入社して、1年半が経過しました。 今回は1年半をふりかえり、取り組んだ内容を簡単にまとめました。 これまでのQAエンジニアの活動を知っていただき、現在のプロダクト、チームの状況をお伝えしたいと思います。 一人目QAエンジニアとして奮闘している方、他社のQA活動に興味がある方に何か伝えられれば幸いです。 それでは、振り返っていきます。取り組み内容の詳細を知りたい方は、ぜひカジュアル面談でお話させてください。 知ってもらう入社して最初に取り組んだことは、社内外にTebikiのQAエンジニアについて認知してもらうことを目的にミッションを策定しました。 このミッションによって、ソフトウェアテストによる品質保証よりも開発プロセス全体でボトルネックになっている、もしくはなり得るプロセスを改善することに注
あなたが一生懸命手を動かしているその仕事、本当にいま皆から期待されていることですか…? 「職務記述書にそう書かれているんだから間違いない」 「上司が賛成しているんだからそうでしょう」 …本当に? わたしたちが職務設計について学んだことTebiki株式会社 エンジニアリングマネージャーの三宅と申します。私たち Tebiki社は、製造や物流などの現場での技能伝承を支援する動画マニュアルプラットフォーム「tebiki」を開発・運営しており、現場教育を行うことのできる人材の不足という社会問題に取り組んでいます。 Tebiki社の開発組織は「マネージャーが指示するよりも、役割を担う人が責任を果たすために創造的に活動するほうがうまくいく」という考え方のもと、「公式に定義された責任とそれを果たすための十分な権限」で職務設計をしています。 これに関して、最近、実践の中で学んだことがありました。具体的には、
はじめに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にはこんな事考えてるエンジニアが
これまで全く外部公開してきていませんでしたが、ここ1年くらいで Tebiki 社のエンジニアリング組織がかなり整ってきたということもあり、現時点でどういった状態かを軽くまとめてみたいと思います。 ( 渋谷 @shibukk ) 顧客の課題を解決できる技術スタックの選択Tebiki 社では tebiki 現場教育と tebiki 現場分析という2つのプロダクトを開発していますが、解決すべき顧客の課題は、プロダクトごと、機能ごとに異なります。 私たちは、その課題に合わせて最適な技術スタックを選択するよう心がけています。 詳しくはこちらの記事にてまとめています。 技術スタック概要スクラムチームがオーナーシップを発揮できる組織設計現在エンジニアだけでも20名以上いる組織になりましたが、その規模であっても、スクラムチームがアジャイルにフィードバックサイクルを回し続けられるような組織設計にしています。
はじめまして。約2ヶ月前に Tebiki に入社した村上です。 現在 Tebiki では、2プロダクト4チームで開発を進めております。Tebiki では週次の全社ミーティングがあり、そこで各チームがどんなものを作っているのかは知ることができます。一方、全社員対象なので技術的な深堀りは難しく、それぞれのチームであった技術的な挑戦や良い知見というものは、自分で他チームのドキュメントを見たり GitHub の Pull Request を見ないと得られない状態でした。 そこで、チーム外のエンジニア同士での情報交換を活性化するために、ホットトピックス共有会 & LT 大会を開催することにしました。(前職でうまくいってた仕組みをそのまま使いました) ホットトピックス共有会ホットトピックス共有会では、各チームから事前にホットなトピックを3つ程度挙げてもらい、それについて詳しい人が口頭で説明するという流
Tebiki社でQAエンジニアをしている中西です。 多くのテストエンジニアやQAエンジニアは、ユーザー目線でのテスト経験があるかと思います。プロダクトのユーザーとプロダクトの使われ方を想定して、テスト対象がユーザーのニーズにマッチしているかを確認しているのではないでしょうか。 Tebiki社では、「ユーザの行動が全て」というValueがあり、開発チームはプロダクトライフサイクルを通して、このバリューを体現することが求められています。つまり、ユーザー目線でテストすることに加えて、ユーザー行動に基づきテストすることが求められているのです。 本記事では、ユーザー目線でのテストとユーザー行動に基づくテストの違いを明らかにし、それらのテストを行うための取り組みを紹介します。この記事がユーザー行動にフォーカスしたテストプロセスの改善のきっかけになれば幸いです。 ユーザー目線でのテストとは本記事では、「
Tebiki社でQAエンジニアをしている中西です。 「開発エンジニア自身がプロダクトの品質保証をする。」このように開発エンジニアが自信をもって開発・テストできるようになってほしいと思いませんか? この記事では、「品質やテストのアドバイザーであり続けるQAチームへ」というタイトルで、Tebiki社での品質やテストのアドバイザーとしての関わり方とそのような関わり方をしている理由、今後の関わり方を紹介します。開発エンジニアを間接的に支える働き方をするQAチームに興味を持って頂ければ幸いです。 品質やテストのアドバイザーとは我々QAチームは、「プロダクト開発に関わる全ての人がより早く、自信を持って、継続的にユーザにとって正しい価値を提供し続けることを支援する。」というミッションのもと活動しています。現在は「自信を持って、継続的にユーザにとって正しい価値を提供し続ける」ことに注力したサポートを行って
Tebiki株式会社では「現場向け動画教育プラットフォーム tebiki 」を開発しています。そして、このプロダクトの価値を最速で大きくしていくために、スクラムを導入しています。 スクラムによりtebikiの開発チームはより速いプロダクトのフィードバックサイクルを回せるようになりました。その一方で「スクラムチームはどのように技術的負債の解消に取り組んでいけばいいのか?」という課題に直面しました。 この記事では「スクラムと技術的負債の解消の両立」という課題に対してTebiki社が導入した「20%ルール」についてご紹介します。 Tebiki社における20%ルールとはTebiki社の20%ルールは エンジニアが開発に充てられる時間の20%をスプリントゴール以外のことに使うこと。 というものです。 つまり、エンジニアのリソースは以下のように使われます。 スプリント … 80%スプリント以外の開発業
先日「プロダクトの価値を最速で最大化し続けるために取り組んでいる、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 の原典である『エリック・エヴァンスのドメイン駆動
Tebiki 社の CTO をしている渋谷です(会社名が変わりました)。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は「スタートアップでも AeyeScan を使えば、継続的に脆弱性を診断できるようになるよ」という話について書いてみたいと思います。 (※近年特に注目されている SaaS などの Web アプリケーションに対する脆弱性診断の話です) スタートアップでもセキュリティは最重要スタートアップではとにかくサービスの PMF を目指すことを優先すべきで多少の脆弱性は後でどうにかすればよい、という意見をたまに見かけます。BtoB 向けの SaaS スタートアップを3年間やってきた一人としては、それは全くの嘘で、やはりセキュリティが最も重要だと考えています。 なぜなら「情報漏えいは会社の倒産リスクに直結する」からです。 仮に脆弱性を突かれて情報が
ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は「プロダクト開発チームがプロダクトに集中できるように、専門性の高い技術課題を解決するチームを作りたい」という弊社の組織設計についてパブリックなところに公開してみたいと思います。 理想の組織とフルスタックの限界会社組織が大きくなっても、プロダクト開発チームはできる限り当事者のみで意思決定ができるように小さくしたいと考えています。 そうすることで開発スピードが上がり、その結果ユーザーへの価値提供がより高められるという信念からです。 ですが、プロダクト開発チームを小さく保つということは、各人のスタックを広げる必要があることを意味します。担当を分業するとその分専門性は高まりますが、同時に関係者が増えてしまいますよね。 そして専門性がないと乗り越えられない技術の壁も存在
ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は、「プロダクトの開発スピードを落とさずに、かつユーザーの芯を食ったソリューションを提供するためには、すべてのスコープをいかに小さくできるかが重要」だということについて書いてみたいと思います。 ちなみに弊社はこれを実践することで開発がものすごくスムーズになり、リリース頻度が体感で 50% くらい向上しました! スピードは失われていく前提として、プロダクトの開発スピードは意識的に改善し続けなければ、機能の追加とともに失われていきます。 提供する機能の増加に伴い、仕様の辻褄合わせだとか実装の順番だとかの複雑に関連するパラメータも同時に増えてしまうので、結果として人や時間といった必要なリソースが指数的に増えていくという話ですね。 (技術的な負債もこのパラメータに含まれ
ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回はスタートアップを経営してみて知った「もしソフトウェアエンジニアの自分が転職するならどんなスタートアップを選ぶとよさそうか」について書いてみたいと思います。(入れるかどうかはさておき) 成長率がすべて。これ絶対。スタートアップはストックオプションや提示ポジションといった外形的な要素に目が行きがちですが、企業の成長率が低いと PoC レベルのシステム開発や運用業務しか経験できず、エンジニアとしてのスキル獲得が難しい環境にあることがほとんどです。 一方で成長率の高いと要求される技術レベルが事業成長に伴い引き上げられるため、任せられる仕事によりスキルが向上したり、優秀な人材が集まってきて切磋琢磨できるようになるといったポジティブな環境が生まれやすいです。 そういった意
ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は「創業~シード期前後のスタートアップはチームにコミットするエンジニアだけをリファラルで採用しろ、それが無理なら副業一択だよ」という話についてです。 本記事は資金調達の合計金額が1億円未満の企業が対象となります。 それ以上の金額であれば PMF していると投資家から判断されているはずで、採用にアクセルを踏むフェーズとなるためスコープが異なります。 シード期のスタートアップが採用すべきエンジニアとは創業してまもなくは PMF するまでにピボットを繰り返す可能性が高いため、このチームでできるなら何でもいいぜ、というエンジニアのみを採用したほうがいいです。 事業に共感したとか採用技術やポジションに惹かれたとかそういうパターンではむしろ採用してはいけません。 例えばあな
このページを最初にブックマークしてみませんか?
『techblog.tebiki.co.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く