タグ

ブックマーク / techblog.tebiki.co.jp (5)

  • ユーザー行動を使い、ユーザー目線でのテストを洗練させる

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

    ユーザー行動を使い、ユーザー目線でのテストを洗練させる
    honeybe
    honeybe 2023/06/05
  • 始めるのをやめよう。終わらせることを始めよう。

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

    始めるのをやめよう。終わらせることを始めよう。
    honeybe
    honeybe 2022/11/30
  • 20%ルールでスクラムと技術的負債の解消を両立する

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

    20%ルールでスクラムと技術的負債の解消を両立する
    honeybe
    honeybe 2022/11/29
  • コードより先にコミットメッセージを書く

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

    コードより先にコミットメッセージを書く
    honeybe
    honeybe 2021/12/14
  • 自走するエンジニアが育つ組織の作り方

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

    自走するエンジニアが育つ組織の作り方
    honeybe
    honeybe 2021/07/07
  • 1