DACI とは、意思決定プロセスにおいて主要な利害関係者の役割と責任をチームに明確にすることで、意思決定プロセスを簡素化するための略語です。DACI の頭字語の説明は、以下のとおりです。 D = Driver (推進役): 利害関係者を集め、必要な情報をすべて収集し、意思決定の範囲を定義し、合意された日までに意思決定が下されるようにする責任を持つ人です。 A = Approver (承認者): 意思決定を行う 1 人の担当者です。これにより、承認者の役割は、受動的に「ゴム印を押す」ことから、非常に積極的に「意思決定を行う」ことに変わります。 C = Contributors (貢献者): 主題分野の知識があり、提案できる人です。発言権はありますが、投票権はありません。 I = Informed (報告先): 決定によって仕事に影響が出る可能性があり、意思決定が下された後に知らせるべき人です

Masato Morishima / チューリング株式会社CFO @MasatoMorishima イーロン・マスクさんが複数社経営しつつ、なぜこんなに生産性が高いのかに関する面白い話。 実は彼は予想に反してほとんどの業務は権限委譲していて、彼がやるのは毎週1つだけ。 「今この会社で最も重要なボトルネック・課題は何か？」を見つけ、その解決のためだけに週のほとんどの時間を費やすらしい。 しかもその際には、現場の製造ラインのオペレーターやソフトウェアエンジニアなど実際にそのタスクに関わっている人たちのレベルまで下りていき、現場の人たちと一緒に課題に取り組み解決するまでやりきる。 そうすることで、年に52個のその会社にとって最も重要な問題を解決し、それにより会社を大きく前進させるらしい。 起業家レベル99。これはチューリングでもやっていきたい。 How Elon Musk Gets So Muc

はじめに こんにちは。食べログ開発本部 ウェブ開発1部の大橋と中村です。 私たちは食べログのサーバーサイドの開発を担当しており、今回食べログで利用している決済システムの機能拡張に伴うリプレイスを行いました。 今回のプロジェクトを進めていて特に感じたのが「ステークホルダーが多いプロジェクトほどスピードと品質が手を動かす前の段取りの良さによって決まる」ということです。 本記事では実際に行った決済システムのリプレイスを事例に段取りがプロジェクトの品質および開発スピードにいかに寄与するのかを紹介します。 段取りの重要性 この章からは段取りの内容についてお話しします。 段取りができているとは下記3つの状態だと考えています。 業務や要件、実際の利用シーンが決まっている アサインするチーム・ステークホルダーが決まっている チームの間でシステムやデータの責務が明確になっている 段取りは序章でお話しした通り

こんにちは、リーナーの id:yusuke-k です。 リーナーは4年前に一人目のエンジニアを採用してから、2024年10月時点で20名弱のメンバーがいます。 この4年間でのエンジニアの退職者はゼロです。 エンジニアに長く働いてもらうために意識してることを、ここで一度まとめてみました。 前提 個人としてもチームとしても、一定のネガティブケイパビリティが必要（たとえば、自分の内に秘めるモヤモヤに向き合えない人には合わない） リーナーではマネージャーと呼ばれる役割は存在しないが、キャプテンと呼ばれるメンバーがチームビルディングやピープルマネジメントを行っている リーナーにおけるエンジニアはWebアプリケーションとその基盤の開発を前提にしている 「個の尊重」と「チームの成果」の両立 最初に結論を簡単にまとめると、長く働けるためには「個の尊重」と「チームの成果」を両立させることが大事だと考えていま

こんにちは。BIGLOBE Style編集部の吉田です。 BIGLOBEでは、4月1日に新入社員が入社しました。今回は、その新入社員が取り組んだ研修の中から、人事部主催「良いチームをつくるワークショップ」についてレポートします♪（4月末実施） 「作業指示に従うvs自主的に動く」どう違うか体験してみる 自己組織化とは何か 作業指示は、思考停止を招く 自己組織化された良いチームをつくる「紙飛行機ワークショップ」 ふりかえりのテーマは「良いチームになるには」 参加者の気づき 経験を反復し、沢山ふりかえる 本ワークショップは、「自己組織化の体験」、「紙飛行機ワークショップ」、「ふりかえり」の流れに沿って進められました。 「作業指示に従うvs自主的に動く」どう違うか体験してみる 「今日は沢山動くワークショップだよ」と説明を受けるみなさん。 入社から1カ月ほど経ち、みなさんわきあいあいとした様子。 講

カケハシで Musubi Insight のバックエンドエンジニアをしている末松です。今回はプロダクトのモニタリングをどう進めていくべきかについて、4つの大事な段階とそのベストプラクティスを紹介したいと思います。 この記事は秋の技術特集 2024の 10 記事目です。 想定読者 モニタリングの悩みあるある モニタリングを始めるためには モニタリングにおいて大事な4つの段階 1. 【可視化】プロダクトの状況がさまざまな断面で可視化されている 【可視化】 のベストプラクティス 2. 【共有】プロダクトの状況が定期的にチームに共有・認識されている 【共有】 のベストプラクティス 3. 【検知】プロダクトが異常な状態であることにチームが気付くことができる 【検知】 のベストプラクティス 4. 【集中】チームが優先すべき指標が定まっている 【集中】 のベストプラクティス まとめ 想定読者 プロダクト

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