開発生産性の現在地点～エンジニアリングが及ぼす多角的視点 / Current status of development productivity2024/2/15 Developers Summit 2024 登壇資料 https://event.shoeisha.jp/devsumi/20240215
エンジニアリングマネージャーのやるべきこと！ - estie inside blog
【プロフィール】田村 祐樹（たむら ゆうき） 1979年生まれ。ネバーランドカンパニーにてゲーム開発に従事。gumiにて技術担当執行役員CTOに就任し、ソーシャルゲーム開発を牽引する。 その後、ディライトワークスにてFGOをはじめとしたスマートフォンゲーム開発を担当。直近ではSmartNewsにてEMを務め、その後、不動産テックのCTOに着任。 2023年9月よりestieに参画。2024年2月に事業部CTOに就任。 エンジニアリングマネージャーの仕事といえば一言で言えば何でしょうか？ マネジメント？ 1on1？ ミーティングにでること？ 違いますね。 そう、マネージャーの仕事は「マネージャーのアウトプット＝チームのアウトプット+影響を与えた他のチームのアウトプット」ですからこのアウトプットを最大化することです。 （かの有名なアンディ・グローブの定義を持ってきました） このアウトプットの影
「影響範囲の考慮漏れ」によるソフトウェアトラブルの多発はビジネス継続性に対する危険信号｜mtx2s
リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。 このようなトラブルが頻発すれば、関係者らは不満を感じます。エンジニアたちの能力に不信感を抱くかもしれません。 しかし、不満の矛先をエンジニアに向けたところで問題が解決することはありません。そもそも原因を見誤っているからです。根本的な原因は、もっと奥深くにあります。 影響範囲の考慮漏れの多発は、ソフトウェアシステムが大きな問題を抱えていることを知らせるサインです。このサインを見逃して表面的な対策ばかりを続けていると、症状が良くなるどころか、かえって悪化し続けることになるでしょう。 問題/原因の3層
経営とソフトウェアエンジニアリングの接続 - WEB SALAD
はじめに 2020年の1月から執行役員CTOに就任し、そこから数年間「CTOの役割は何か」を自問自答してきました。 就任当初から「CTOの役割とは、経営とソフトウェアエンジニアリングを接続することである」という考えはありましたが、上手く言語化できずにいました。 最近になってようやく他者へ説明できるレベルまで言語化できるようになったので、現時点での考えを残しておきたいと思い、4年ぶり（！）にブログを更新する1ことにしました。 本ブログポストの要旨 筆者の考えるCTOの役割は、「ソフトウェアエンジニアリング組織の日々の活動が企業価値の向上に繋がっている状態を作ること」です。 企業価値の向上のためにソフトウェアエンジニアリング組織が行うべき取り組みは、コーポレートファイナンスの視点を導入することで論理的に導けます。 そして、ソフトウェアエンジニアリング組織の日々の活動がこれらの取り組みに自然と向
人事制度ハンドブック - kaneda blog
2022年5月6日 人事制度 人事制度ハンドブック 22年1月から開始したブログ。 人事制度の設計・運用に関する記事のまとめです。 今後、人事制度を設計する際のハンドブックとして、随時更新していきます。 ■書籍：スタートアップのための人事制度の作り方 ■ブログ本体：https://kaneda3.com/ Pickup スタートアップにおける組織づくりの鉄則 今年、何パーセント昇給しましたか？(昇給率の話) 「売上が上がらないことよりも、人が辞める方がつらい」という本音 人事制度を使って、入社時に「期待」を伝える方法 等級の中に「サブグレード」をつくってはいけない 等級制度と評価制度の違い 降格・降給は、「カルチャー」である 【スライド公開】スタートアップにおける等級別の報酬レンジ 報酬水準に関する公開資料_ver5.0 昇格に、メリットはあるのか？ 急成長できるスタートアップの組織文化と
アウトカムの最大化へ。開発組織の変遷と向き合い方 - Gaudiy Tech Blog
こんにちは。ファンと共に時代を進める、Web3スタートアップのGaudiyでプロダクトマネージャーをしている@kaa_a_zuです。 開発組織は、ITサービスを提供している企業にとって「エンジン的な存在」であり、プロジェクトや各メンバーの生産性に大きな影響を及ぼします。そんなエンジンは、事業の成長に伴って柔軟に変化させていく必要があると考えています。 Gaudiyでも、これまでに数度、開発組織のアップデートを重ねてきました。今のエンジンは、「仕様策定から開発、リリース、効果測定までをひとつのチームが行い、そのチームメンバー全員が責任を持ってアウトカムの最大化を図ることができる」ものになっています。 そこで今回は、2022年7月に行われた開発組織の体制移行を中心に、これまでの開発組織の変遷から今回の体制に至った背景、体制移行にあたって考慮した点などについて書こうと思います。 事業や人員拡大に
スタートアップ1人目EMが1年でやってきたこと｜Yoshiki Iida
こんにちは、ログラスでエンジニアリングマネージャー（以下EM）をしております飯田です。 昨年12月にEMをはじめましたという記事を書いてから早くも3Qの月日が流れ現在4Q目を過ごしています。 私自身は前職でも現職でもエンジニア→EMというキャリアとなっており、現職ログラスでも1人目EMとして立ち上げを行ってきました。 当時EM取り組むにあたり、掲げていたことがいくつかあります。ざっくりまとめると、 エンジニア ⇄ EMで必要であれば柔軟に行き来できるようなフレキシブルな組織を作りたい スタートアップの初期フェーズから盤石なマネジメント基盤を作りたい 長期でパフォームし続けられる組織を作りたい です。 この記事ではこの3Qの中で取り組んできたことと、それによって上記のやりたかったことに近づいたのか？をご紹介できればと思います。 スタートアップのマネジメントのスケールに悩んでいる人（EMに関わ
A framework for Engineering Managers
(click on position name for more details) Axes The chart shown above has the following 5 axes: Technology: knowledge of the tech stack and tools System: level of ownership of the system(s) People: relationship with the team(s) Process: level of engagement with the development process Influence: scope of influence of the position The influence axis can be seen as a different dimension since it is o
エンジニアリングマネージャーとしての開発力向上の取り組みついて - Qiita
スクワッド体制における留意点として、「Spotifyは "Spotifyモデル "を使っていない [3]」で以下のように述べられているように、単に方法論を真似るのではく、自分の組織と向き合い、学習して、進化し続けることが大切であると思います。READYFORにおいても日々、組織体制について議論し、改善を進めています。 ビジネスユニット、部門、チーム、マネージャーは、Spotifyの失敗した方法論に固執してはいけません。彼らはSptifyのモノマネよりも効果的に組織構造の役割と責任を伝えることができるのです。 あなたがSpotify Modelを見つけたのは、自分のチームをどのように構成するかをいつも考えていたからでしょう。でもここで止まってはいけません。学習を続けてください。 1-2. READYFORのスクワッド体制 READYFORの場合、どのようなスクワッド体制を敷いているか？ ひと
自走するエンジニアが育つ組織の作り方
ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は、マネージャー向けに「もしメンバーに自走してほしいなら、個人のメンタリティに期待するのではなく、組織で相互にアドバイスし合うプロセスを構築したほうがいい」という話をしたいと思います。 エンジニアの求人サイトを検索してみると、求める人物像や歓迎するスキルに「自走力のある人」と書いている企業がたくさんヒットします。 これだけ書いてあるということは、自走する能力を備えていることがもはやエンジニアの必須条件のように思えてきます。 ですが、自走するかどうかはその人個人のメンタリティよりも外部要因のほうが遥かに大きいと私は考えています。どんなに自走できる人でも、ほとんどの場合で権限移譲された範囲までしか自走はできないからです。上司の知らないうちに「新サービスリリースしてお
Tech Lead（TL/テックリード）の役割 - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
Tech Lead（TL/テックリード）の役割。聞きなれない名前かもしれない。リードプログラマやテクニカルリードと呼ばれることも。過去にいくつものチーム（最大で10人以上）の Tech Lead をやってきた自分の経験を踏まえて書いてみる。 Tech Lead の主な役割 Tech Lead はエンジニア班長と言いかえるとイメージがわきやすいかもしれない 顧客に提供したい価値（プロダクトゴール）を正しく理解する エンジニアチームの生産性を可能な限り最大化。プロダクトマネージャ・デザイナと顧客に価値を提供する Product の Launch に責任を持つ Product の Launch 後のメンテナンスに責任を持つ エンジニアを過負荷から守る ときにはマネージャ、プロダクトマネージャのアイデア、スケジュールに NO を言う。代替案を提示する チーム内のテクニカルデザイン、採用技術などに責
開発爆速化を支える経営会議や週次定例の方法論 〜LayerXの透明性への取り組みについて〜 - LayerX エンジニアブログ
こんにちは。松本(@y_matsuwitter)です。GWはカレーを沢山作っていました。スパイスから作るカレー、思ったよりも手間が掛からないですね。インド料理にハマる波が数年置きにやってきます。 本日は、最近いくつかのイベントでの議論を通じて感じた、開発組織づくりにおいて見られる共通のパターンについて触れつつ、LayerXが意識している取り組みを書いてみようと思います。 最近toBなスタートアップ各社と会った中で、組織の指向性に色々と共通の傾向が見られる気がする。 ・透明性への狂気的な取り組み、公開だけでなく情報整理とチャネル整備 ・採用は技術力そのものよりもカルチャーフィットと学習意欲（もちろん両立が理想だけども） ・開発では速度を最も意識— 松本 勇気 | LayerXはSaaSとFintechの会社です (@y_matsuwitter) 2021年4月22日 各社で見られる最近の組織
マネージャーはエンジニアに戻れるのか？元執行役員が今現場に戻る理由｜Yoshiki Iida
こんにちは、ログラスでエンジニアをやっている飯田 / @ysk_118と申します。2020年10月にjoinし現在2ヶ月ほど経ったところです。 優秀なメンバーに囲まれて毎日焦りを感じながら開発をしています。 私はこの2年ほど開発組織のマネジメント業に専念しており、現場でコードを書くのはかなり久しぶりでした。 このエントリではそんな元マネージャーがなぜ社員数人のどスタートアップに行こうと思ったのか？マネジメントから現場に戻ると何がどうなるのか？について書きたいと思います。 Generalistなマネージャー歴前職は株式会社クラウドワークスで5年勤務していました。クラウドワークスには第二新卒的な若手枠で転職し、現場の一エンジニアから始まり、スクラムマスターやプロダクトオーナーなど様々なロールを経て2018年から開発組織のマネジメントに関わるようになりました。最終的には執行役員という形で開発組織
CTOの頭の中：技術投資を最適化する｜Shin Takeuchi
ざっくり年収1,000万円のエンジニアが10名いる会社では、年間1億円の技術投資がなされているわけですが（地代家賃、ライセンスフィー、PC代など含めるともっと）、年間1億円を正しく詳細に把握して、投資をコントロールできている会社は少ないと思います。会社が創業期であれば、最低限作らなければならない機能などは分かりやすく見えていたりするのでまだしも、そのプロダクトでしっかりとした収益が成り立ち、上場企業となるようなレベル感のプロダクトに対する技術投資となると、一部の大きなプロジェクトは把握していても、細かな投資ポートフォリオを常に把握することは難しいのではないでしょうか？今回はこの部分に一石を投じてみたいと思います。 技術投資量を見える化する 投資の最適化とは言いますが、最適化というのは「To Be」の話ですので、まずは「As Is」を知らなければ話になりません。その、まず「As Is」を知る
Engineering Manager になってから身に沁みた12のアイデアと言葉 part2 - これはただの日記
2019/12 にこんな記事を書きました。 kths.hatenablog.com あれから一年たち、日々積み上げた新しいアイデアをみなさんとも共有したいと思います。 システム操作性スコア 私が勤めるスタディストでは、一部のサービスがマイクロサービスとして稼働しています。また、それ以外にも稼働している別プロダクトがあったりと、徐々に組織の管理対象となるサービスの数が増えつつあります。また、今後もその数は増加していくことが予想できます。 2020/12/26に発売されたばかりの書籍『モノリスからマイクロサービスへ』では、マイクロサービスが引き起こす可能性のある痛みの一例として、孤児サービスという言葉が登場します。これは文字通り、所有権や責任を負う人がいなくなってしまったサービスのことで、孤児サービスに対するトラブルシューティングは困難になることが予想されます。単に一部機能の停止で済めばマシで
VPoE handbook | エンジニア組織のマネジメントに悩んでいた三年前に戻れるなら渡したい。VPoE handbookを書き終えました (目次&サマリ付)｜Takayuki Shimizu
（この記事はVPoE handbookの目次＆サマリパートです） 以下で書き始めを宣言してから進捗が悪思わしくなかったhandbookですが、ようやく書き終わりました。 数えるといつの間にか合計30,000字ほどになり、意外とボリュームが増えてしまったので、少しずつ読みやすいように章ごとに記事にしています。 目次はこの記事の目次部分、もしくはこちらのマガジンの一覧からご覧ください。 この記事自体ではその目次と簡単な解説をつけ、ざっくりと全体像を知り、詳しく読みたい気になる記事を見つけやすくするような構成で書いていきたいと思います。 （この7月からは開発マネジメントのキャリアとはまた違った方向に進みだしたので、賞味期限切れギリギリ?!になりましたがなんとか整理も終わりました。） VPoE handbookを書こうと思った理由まずはなぜ書こうと思った？の問題意識から。 この記事にあるように、三
エンジニアだけが優遇されるのではない組織をつくりたい - Unknown Error
※ 2つの意味で解釈できるようなタイトルだった*1ため、より伝えたいことが明確になるタイトルに訂正しました。ご指摘いただいた皆様ありがとうございました。お詫び申し上げます この記事はEngineering Manager Advent Calendar 2019の17日目の記事です。 手前味噌だが、所属している会社のエンジニア組織はだいぶ良い感じになってきているという自負がある。最近書いた自社のブログのエントリも多くの方に共感いただいた。 hackerslab.aktsk.jp 一つ一つの組織活動に対してこれって本当にあるべき姿なんだっけというのを問い続けながら地道な改善を続け、組織としての練度が大分高まってきた。 結果として、自社のあらゆる組織の中で、エンジニア組織は一番改善が進んでいる。*2 一方で、そこはかとなく、「このままで良いんだろうか」というモヤモヤがある。 会社はエンジニアの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Effective Remote Working
Engineering Ladder | メルカリエンジニアリング
心理的安全性とソフトウェア化する社会/ Psychological Safety and Software-based Society
