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