チームがうまくいっていない時にとる泥臭いリーダーシップ
Tebiki株式会社でエンジニアをしている二瓶です。私は Tebiki株式会社の Web アプリケーションエンジニアとして入社し、製造業向けデジタル帳票サービス 「tebiki現場分析」 の開発を担当しています。また、チーム内では「チームリーダー」という役割を担っています。弊社のチームリーダーのミッションは要約すると「生産性とプロダクトの品質を最高の状態に保ち、プロダクトの価値を最大化できるような『チームの状態』をつくること」です。 私たちのチームはプロダクト立ち上げ当初からスクラムを導入し、私は2年前からスクラムマスターを務めています。しかし、昨年から開発者も兼任することにしました。この兼任の目的を一言で表すと「私自身がチームの状態をよく知り、生産性とプロダクトの品質を最高の状態に保ち続けることにコミットするため」です（本記事ではスクラムにおける役割についての説明は言及しません。スクラム
負債となっていたバッチ処理基盤を無停止で（ほぼ）ユーザ影響なく移行した話 - tebiki_techblog
※この記事は 2025年02月19日に Medium で公開されたものを、ブログ移行に伴い再掲載したものです。内容は当時のままですので、一部情報が古くなっている可能性があります。 Tebiki株式会社でtebiki現場教育サービスのプロダクトエンジニアを担当している清田です。 去年、tebiki現場教育で利用していたバッチ処理基盤を移行しました。 当記事では、その移行の内容を紹介します。 前提 tebiki現場教育サービスでは、主に以下の用途でバッチ処理基盤を利用していました。 ・業務イベントに応じたメール一括送信 ・ユーザ全体へのお知らせ通知 ・ユーザの学習状況の収集 バッチ処理基盤はAWSのElastic Beanstalk上でRuby on Rails製のアプリケーションとして起動しており、wheneverというgemを利用して所定のジョブを定期実行していました。 バッチ処理基盤のア
ユーザー行動を使い、ユーザー目線でのテストを洗練させる - tebiki_techblog
※この記事は 2023年06月05日に Medium で公開されたものを、ブログ移行に伴い再掲載したものです。内容は当時のままですので、一部情報が古くなっている可能性があります。 Tebiki社でQAエンジニアをしている中西です。 多くのテストエンジニアやQAエンジニアは、ユーザー目線でのテスト経験があるかと思います。プロダクトのユーザーとプロダクトの使われ方を想定して、テスト対象がユーザーのニーズにマッチしているかを確認しているのではないでしょうか。 Tebiki社では、「ユーザの行動が全て」というValueがあり、開発チームはプロダクトライフサイクルを通して、このバリューを体現することが求められています。つまり、ユーザー目線でテストすることに加えて、ユーザー行動に基づきテストすることが求められているのです。 本記事では、ユーザー目線でのテストとユーザー行動に基づくテストの違いを明らかに
始めるのをやめよう。終わらせることを始めよう。 - tebiki_techblog
※この記事は 2022年11月30日に Medium で公開されたものを、ブログ移行に伴い再掲載したものです。内容は当時のままですので、一部情報が古くなっている可能性があります。 あなたのチームがいくつも未着手の仕事を抱えているとき、どのようにそれらに着手し、そして完了させていったら良いでしょうか？ アジャイルには「始めるのをやめよう。終わらせることを始めよう。」という言葉があります。Tebiki株式会社では、この考え方を基本として、 デスクレスワーカーのための現場教育SaaS「tebiki」を開発しています。 この記事では、新しい仕事を「始める」ことを優先する場合と、仕掛り中の仕事を「終わらせる」ことを優先する場合の比較をしながら、かつては「始める」ことを優先していた Tebiki社が「終わらせる」ことを重視するように変わっていった事例を紹介したいと思います。 仕事が「終わる」とは まず
20%ルールでスクラムと技術的負債の解消を両立する - tebiki_techblog
※この記事は 2022年11月28日に Medium で公開されたものを、ブログ移行に伴い再掲載したものです。内容は当時のままですので、一部情報が古くなっている可能性があります。 Tebiki株式会社では「現場向け動画教育プラットフォーム tebiki 」を開発しています。そして、このプロダクトの価値を最速で大きくしていくために、スクラムを導入しています。 スクラムによりtebikiの開発チームはより速いプロダクトのフィードバックサイクルを回せるようになりました。その一方で「スクラムチームはどのように技術的負債の解消に取り組んでいけばいいのか？」という課題に直面しました。 この記事では「スクラムと技術的負債の解消の両立」という課題に対してTebiki社が導入した「20%ルール」についてご紹介します。 Tebiki社における20%ルールとは Tebiki社の20%ルールは エンジニアが開発に
コードより先にコミットメッセージを書く - tebiki_techblog
※この記事は 2021年12月13日に Medium で公開されたものを、ブログ移行に伴い再掲載したものです。内容は当時のままですので、一部情報が古くなっている可能性があります。 これは、フィヨルドブートキャンプ Advent Calendar 2021（Part 1） 13日目の記事です。 未経験からフィヨルドブートキャンプでプログラミングを勉強し、2021年3月から Tebiki 社でエンジニアとして働いている masuyama13 です。 入社当初、PR（プルリクエスト）を作成する際にコミットの整理に毎回かなり時間がかかるのが悩みでした。試行錯誤の結果、この悩みを解消することができたので紹介します。 それが、コードより先にコミットメッセージを書くという方法です。 コミットメッセージを先に書くやり方 まず、タスクを分解して TODO リストを作ります。 これから作業する内容がイメージで
自走するエンジニアが育つ組織の作り方 - tebiki_techblog
※この記事は 2021年07月07日に Medium で公開されたものを、ブログ移行に伴い再掲載したものです。内容は当時のままですので、一部情報が古くなっている可能性があります。 ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は、マネージャー向けに「もしメンバーに自走してほしいなら、個人のメンタリティに期待するのではなく、組織で相互にアドバイスし合うプロセスを構築したほうがいい」という話をしたいと思います。 エンジニアの求人サイトを検索してみると、求める人物像や歓迎するスキルに「自走力のある人」と書いている企業がたくさんヒットします。 これだけ書いてあるということは、自走する能力を備えていることがもはやエンジニアの必須条件のように思えてきます。 ですが、自走するかどうかはその人個人のメンタリティよりも外部要
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
