最近、毎日のようにEMのいくおさん（ @dora_e_m ）とTwitterXでわちゃわちゃしてる。彼のポストを見ていると、ガンプラをつくるかビールを飲むかしかしていないように見えるが、それで合っている。 という冗談はおいといて真面目な話をすると、エンジニアとしての僕は彼と仕事ができている今の時間のことを本当に貴重な時間だと思っている。とにかく仕事がしやすいし、いろいろな気づきを与えてくれるおかげで、自分自身の成長も感じている。 エンジニアリングマネージャとしての知識が豊富でスキルが高いというのはもちろん、人との接し方や日常的なふるまいもとても尊敬できるものなのだ。 そこで今日は、僕が彼とこの3ヶ月間仕事をしていて、やりやすい・尊敬していると感じていることの中から10個だけ簡単に紹介しようと思う。僕からいくおさんへの日頃の感謝の気持ちをあらためて書いておこうと思っただけとも言う（ふだんから

Staff Engineer: Leadership beyond the management track (English Edition) www.amazon.co.jp Staff Engineer, Leadership beyond the management trackというタイトルの本を呼んだ 何が書かれているのかGAFAに代表される米国Tech companyではSoftware Engineerの職位として、Stuff Engineerというタイトル・ポジション・グレードがある。会社によって違いはあるものの、概ねSeniorよりも更に上のグレードのエンジニアを指す。 例えばGoogleでは下記のようなグレードがある。Google Senior Fellowが最上位となる。 Senior Software Engineer Staff Software Enginee

1. はじめに こんにちは。QAエンジニアとして働いている市川です。 今回は、私が所属しているカミナシ設備保全サービスチーム（以下サービスチーム）で「チーム全体で品質を考える文化づくり」を進めるために行った取り組みについて紹介します。 チーム構成は、エンジニア2名、デザイナー1名、PdM1名の体制で、私は昨年末からチームにスポットで参画して取り組みを進めてきました。 私が取り組んだことは大きく分けて以下の3つです。 QAやテストの考え方を伝える座学セッション 品質を考えるワークショップ 設計ワークへの参加によるコラボレーションの強化 これらの活動の背景には、「プロダクトの品質はQAだけで担保できるものではなく、チーム全員が品質に対して主体的に取り組む文化が重要」という考え方があります。 まだすべてが解決できたわけではありませんが、まずは1チームでトライしてみたプロセスを共有したいと思います

2024.12.11 エンジニア組織のリアルな失敗経験から学ぶ！ 生産性向上＆チーム強化Tips

Tebiki株式会社 取締役CTO 渋谷 和暁 神戸大学法学部卒業後、SIerを経てWebシステムの開発会社に入社。ECなどの受託開発やゲームアプリ開発のリードとして従事した後、コーチ・ユナイテッドに転職。クックパッドによる吸収合併のタイミングでCEO貴山氏とともにTebiki社を起業し、取締役CTOを務める。 GitHub Medium アジャイルなプロダクト開発において、コード品質・学習効率・チームワークの向上に効果があるとされる「ペアプロ」。1人でプログラミングすること（＝ソロプログラミング、以下ソロプロ）が主流の中で、ペアプロをどうやって組織に浸透させるべきか、困っている組織は少なくないのではないでしょうか。 かつてのTebiki社も、同じ悩みを抱えていた組織の一つでした。2018年3月に創業し、小売、製造、サービス、物流などの現場マニュアルのDXを目的としたSaaSを開発する同社

はじめに こんにちは。PharmaXでエンジニアリングマネージャーをしている古家(@enzerubank)です。 弊社では開発生産性の改善のためにFindy Team+を活用しているのですが、先日チームサーベイ機能という新機能がリリースされました。 チームサーベイ機能をリリースしました！ このチームサーベイ機能はMicrosoftやGitHub等によるリサーチで提唱されたSPACEフレームワークに沿って、チームの開発者体験を可視化し、生産性向上に向けた取り組みを推進できる機能です。 開発生産性の指標としてはFour Keysが有名ですが、これはあくまでDevOpsの指標であり、リリース速度や障害の発生状況を把握することしかできません。 生産性をより広く捉え、働いている人がモチベーション高く働けているかどうかを測る方法が欲しかったので、今回のチームサーベイ機能のリリースはとても嬉しいものでし

ソフトウェア開発に携わるエンジニアがキャリアを積むとマネージャーへの転身を余儀なくされた時代もありましたが、今ではIC（Individual Contributor）やスタッフエンジニアという働き方も周知となり、開発組織そのものをマネジメント対象とするEM（エンジニアリングマネージャー）を置く企業も増えてきました。 そんな状況を反映してか、株式会社カケハシの椎葉光行（@bufferings）さん、小田中育生（@dora_e_m）さん、荻野淳也（@ogijun）さんの3人は、それぞれチームをリードできるシニアなエンジニアでありながら、現在は同じチームのメンバーとしてともに開発に取り組んでいます。 新たに採用するハイキャリアなエンジニアを既存の開発組織にどうフィットさせるかに課題感を持つ企業もありますが、このように複数のシニアを集めたスーパーチームで開発にあたることにどういった意義があるのでし

はじめに ログラスさんで取り組もうとしているFaST agileを下記の資料で知り、調べてみました。 はじめに FAST概要 用語 コレクティブ バリューサイクル ロール ツール バリューサイクル内の開発の流れ 1. プロダクトマネージャーの指針表明 2. 自己組織化し、活動の周りにチームを形成 価値・原則・柱 考えたこと フレームワークの狙いは何か できそう? 参考文献 FAST概要 "Fluid Scaling Technology (for Agile)"を標榜した、自己組織化を重視した軽量なフレームワークです。 日本語ガイドも公開されています。 FaSTガイド.pdf - Google ドライブ FASTガイドより引用した概要図 (Per Beiningによる) ※ 以下「スクラムでいうXX」といった表現を避け、FASTガイドの文言をできるだけそのまま受け取ってみます 用語 コレク

この記事はEngineering Management Advent Calendar 2022の7日目です. 今はエンジニアリングマネージャ(EM)としてエンジニアリングマネジメントの4領域(プロダクト・プロジェクト・テクノロジ・ピープル)すべてを見ていますが, それ以前は長い間テックリードをやっていました. その経験を活かして, 最近は後進を育ててテックリードあるいは「弱いEM」*1をできる人材を増やそうとしています(これ自体がピープルマネジメントの一環ですね). テックリードを育てるためにやっていることの全容を詳細に書くと本が1冊書けるくらいになってしまうと思うので, その中でも再利用可能そうな(と言うより再利用可能にしたいと目論んでいる)「テックリード養成講座」について紹介したいと思います. Memeplex.appで生成した, テックなリードが養成されるイメージ 経緯 僕自身は,

QAの山下です。 QAグループという名前で横断組織として手動&自動テストやツール開発、プロセス改善など仕組みづくりに取り組んでいます。 今回は LIFULL HOME'S の開発で実行されているE2Eテスト（リグレッションテスト）をシフトレフトし、実行時間を80％短縮した話を紹介します。 ざっくり何をやったのか 大規模なリポジトリでのdevelopマージ後のE2Eテストの9割をPR上で実行可能にした コードのpushからE2Eテスト完了まで5～8分で完了できる 運用上の課題も頑張って解消した 目次 ざっくり何をやったのか 目次 結論 前提情報 E2Eテストとは リグレッションテストとは LIFULL HOMESでのE2Eテストの位置付け シフトレフトとは EEとは 対象のプロダクトの規模 起こっていた課題 テストの削除とリファクタを行い、テストケースを3割削減した デプロイ後のアプリケーシ

こんにちは。スクラムマスターの@sakebookです。 今回は「象・死んだ魚・嘔吐」をチームでやってみたのでその振り返りをします。 「象・死んだ魚・嘔吐」とは 振り返り手法の一つです。Airbnb Story 大胆なアイデアを生み、困難を乗り越え、超人気サービスをつくる方法（原題: The Airbnb Story）の中で紹介されていたようです。 翻訳されてなかなかキャッチーなネーミングになっています。 それぞれ次のようなことを意味します。 象 凄く大きい、見えているけど、みんな見ないふりをしている課題・問題。表層化しているけど大きすぎてみようとしていない。これが何かをみんなで話していく。 死んだ魚 放っておくと腐っていく。そういう問題。放置しておくとまずいことになる問題ってなんだろう？ということを話し合う。 嘔吐 自分の胸の中に隠していて、吐き出せなかったこと。これをこの場で嘔吐する。

果たしなく続くビジネスパーソンの「取捨選択」「朝食に何を食べるか」にはじまり「どのメールに最初に返信すべきか」「チームミーティングで誰がメモを取るべきか」「チームが次に優先すべきプロジェクトは何か」「チームの新しいメンバーとして誰を採用すべきか」「どのルートで帰宅するか」などなど、チームのリーダーやメンバーが選択すべき事柄は無数にある。ある推定によれば、些細な事柄から重大な事柄に至るまで、ビジネスパーソンが日々取捨選択している事柄の数はおよそ3万5,000にも及ぶという（参考文書 (英語)）。 このような大量の選択肢の中から、何かを選び続けていると、精神的な疲労とエネルギーの消耗が激しくなり、苛立ちを覚えることもある。ゆえに夕食のメニューを考えるころには「もう何も考えたくない！食べれるモノなら何でもいい」という気分になる。 こうした選択による精神的な疲労、あるいは消耗が「決断疲れ」と呼ばれ

ふりかえり手法にはKPT、Fun Done Learnなど様々な手法が知られています。 今回はその中でもチームの課題と向き合う手法「象、死んだ魚、嘔吐」について説明します。 また自分達が実際に実践するにあたって行った工夫を紹介します。 ふりかえり手法「象、死んだ魚、嘔吐」とは？ 2024.1.17追記 「象死んだ魚嘔吐のうた」を制作し、Reginal Scrum Gathering Tokyo 2024にて発表しました。 ↑使用したオリジナルの背景画像です。お好きなツールの背景としてどうぞ。 「象、死んだ魚、嘔吐」とは、Airbnbの共同創業者ジョー・ゲビアが提唱した手法です。 カリスマ性があり完璧主義のジョー・ゲビアが率いるチームでは、雰囲気が重苦しく、メンバーはゲビアを恐れ、自分の考えていることを発言できなくなっており、チームは崩壊寸前でした。 そのような状態で考案されたふりかえり手法

過去にshimobayashi.hatenablog.comで色々書いてたけど、長い。 個人的には、以下のようにまとめられそう。 最速で最高の決定を目指す そのために、自分自身を含めた誰に水を向けるか考える 答えを出せそうな人 答えを出すために必要な情報を持ってそうな人 答えを出すために必要な考え方を持ってそうな人 決定ごとに合意を取る 色んな人の意見を聞いた方が良いと思いがちだけど、意見を聞いても答えが変わらないなら聞く時間が無駄なので意識的にやめる なので、異議が無いかだけ確認する あとでちゃぶ台をひっくり返されたくないときは、決定権を持つ人に意識的に確認する こういう動きをするためには、参加者の特性や力関係などを把握しておく必要がある なので、これは司会ではなくファシリテーション もちろん「若手に考える訓練をさせたい」とか色んな理由で違うやり方をやることもあるだろうけど、基本的にはこ

自分としては、チームが成果を出すためには心理的安全性が重要、心理的安全性を高めるにはHRTが重要、反HRT的なふるまいをする人がブリリアントジャークと呼ばれている、という理解 心理的安全性: Google re:Work - ガイド: 「効果的なチームとは何か」を知る 仲が良いとかじゃなくて、言うべきことを言える関係性を築けているか、という理解 HRT: チームで働くための知識体系としての「心理的安全性」 | DevelopersIO ブリリアントジャーク: No Brilliant Jerks - Netflixの「頭はいいけど嫌な奴、お断り」について調べた - Qiita 心理的安全性とブリリアントジャークがあまり紐付けられてるところを見てない気がするので、割と自分独自の解釈なんじゃないかとは思っている なぜチームが成果を出すためには心理的安全性が重要なのかというと、我々が知識労働者だ

こんにちは。こんばんは。おはようございます。アンドパッドで現在はバックエンドの方のエンジニアをやっている北村です。 アンドパッドには2021年4月にJOINしまして、現在までANDPADボード(以下ボード)の開発に携わっています。ANDPAD施工管理が比較的長期間の工事をターゲットにしているのに対してANDPADボードは1日〜数日の間に短期間の工事や施工を行う際のスケジュール管理を行えるサービスです。 lp.andpad.jp 半年ほど前に同チームのバックエンドエンジニアの原田さんに技術的負債を粉砕する記事を投稿してもらいました。今回はその続きの話をしようと思います。 前回記事は塵積もった技術的負債に対する技術的なアプローチがメインでしたが、今回はプロセスやチームビルディングの参考になりそうな話をバックエンドエンジニア目線で書いたものになります。 ANDPADボードの開発チーム紹介 話をイ

Page Scrolling Vertical Scrolling Horizontal Scrolling Wrapped Scrolling

株式会社はてなでWebアプリケーションエンジニアをやっているid:stefafafanです。はてなマンガチームの魅力を書く流れ*1になっているみたいなので自分も書いてみます。日記ばかり書いてましたが唐突に会社の【PR】的なエントリ失礼します。 はてなの関わっているマンガサービスについて 多くの人は「はてな」と聞くと、「はてなブログ」とか「はてなブックマーク」、エンジニアだと「Mackerel」などを連想するかもしれませんが、マンガ関連のサービスにも力を入れています。 プレスリリース一覧で「マンガ」で検索すると、2014年の「少年ジャンプルーキー」、2017年の「少年ジャンプ＋」や「マガジンポケット」、2018年は「コミックDAYS」などなど様々なサイトや出版社のマンガビューワを手掛けていることがわかります。 新しめなチャレンジとしては、新マンガ投稿サービスのマンガノなども今年リリースしてい

最近、SlackのHuddleっていう、チャンネルから離れずに通話できる機能を使っていて、ミーティングないときはとりあえずジョインするようにしている。 同じく予定のない間はジョインしているメンバーがいるので、いろいろと声をかけながら調査したり、その場で確認をとりながら作業を進めたりできている。 今日話したことは以下のような話題。以下のいずれの話題についても、今日話す予定になかったけど、その場でちょこちょこと直せたり、調査が進んだりした。 週末いいことありましたか、みたいな雑談 同僚が使ってるイヤホンの音量ボタンをリズムよく連打するとクラッシュする、という良い情報を教えてもらえた 今日発生した不具合の原因が、以前からのキャッシュの出し分けロジックに関連していそうという話 キャッシュの出し分け方針をディレクターに確認しよう、といってissueを入れて方針決めを進めた データベースのパーティショ

LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog LINEの開発組織のそれぞれの部門やプロジェクトについて、その役割や体制、技術スタック、今後の課題やロードマップなどを具体的に紹介していく「Team & Project」シリーズ。 今回は、フロントエンド開発組織の中で、ユーザ向けサービスのWebフロントエンドを担当しているチームについて紹介します。フロントエンド開発センターの清水大輔、縣亮太、折原レオナルド賢に話を聞きました。 ユーザ向けサービスのWebフロントエンドを担当しているチームのzoom会議の様子 ―― まず、自己紹介をお願いします。 清水：システム開発会社で図書館システムや金融・物流の開発などを担当した後、2009年5月にネイバージャパン（現LINE）にフロントエ