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

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

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 リストを作ります。これから作業する内容がイメージできたら、コミットメッセージを一つ考えます。エディタなどにコミットメッセージを入力します。コミットメッセージが書けたら、それを常に意識しながらコーディングを進めます。作業中にコミットメッ

Tebiki 社の CTO をしている渋谷です（会社名が変わりました）。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は「スタートアップでも AeyeScan を使えば、継続的に脆弱性を診断できるようになるよ」という話について書いてみたいと思います。 （※近年特に注目されている SaaS などの Web アプリケーションに対する脆弱性診断の話です） スタートアップでもセキュリティは最重要スタートアップではとにかくサービスの PMF を目指すことを優先すべきで多少の脆弱性は後でどうにかすればよい、という意見をたまに見かけます。BtoB 向けの SaaS スタートアップを3年間やってきた一人としては、それは全くの嘘で、やはりセキュリティが最も重要だと考えています。 なぜなら「情報漏えいは会社の倒産リスクに直結する」からです。 仮に脆弱性を突かれて情報が

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

ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は、マネージャー向けに「もしメンバーに自走してほしいなら、個人のメンタリティに期待するのではなく、組織で相互にアドバイスし合うプロセスを構築したほうがいい」という話をしたいと思います。 エンジニアの求人サイトを検索してみると、求める人物像や歓迎するスキルに「自走力のある人」と書いている企業がたくさんヒットします。 これだけ書いてあるということは、自走する能力を備えていることがもはやエンジニアの必須条件のように思えてきます。 ですが、自走するかどうかはその人個人のメンタリティよりも外部要因のほうが遥かに大きいと私は考えています。どんなに自走できる人でも、ほとんどの場合で権限移譲された範囲までしか自走はできないからです。上司の知らないうちに「新サービスリリースしてお

ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は、「プロダクトの開発スピードを落とさずに、かつユーザーの芯を食ったソリューションを提供するためには、すべてのスコープをいかに小さくできるかが重要」だということについて書いてみたいと思います。 ちなみに弊社はこれを実践することで開発がものすごくスムーズになり、リリース頻度が体感で 50% くらい向上しました！ スピードは失われていく前提として、プロダクトの開発スピードは意識的に改善し続けなければ、機能の追加とともに失われていきます。 提供する機能の増加に伴い、仕様の辻褄合わせだとか実装の順番だとかの複雑に関連するパラメータも同時に増えてしまうので、結果として人や時間といった必要なリソースが指数的に増えていくという話ですね。 （技術的な負債もこのパラメータに含まれ