テックリードを再生産可能にする - テックリード養成講座をやっている話 - 貳佰伍拾陸夜日記
この記事はEngineering Management Advent Calendar 2022の7日目です. 今はエンジニアリングマネージャ(EM)としてエンジニアリングマネジメントの4領域(プロダクト・プロジェクト・テクノロジ・ピープル)すべてを見ていますが, それ以前は長い間テックリードをやっていました. その経験を活かして, 最近は後進を育ててテックリードあるいは「弱いEM」*1をできる人材を増やそうとしています(これ自体がピープルマネジメントの一環ですね). テックリードを育てるためにやっていることの全容を詳細に書くと本が1冊書けるくらいになってしまうと思うので, その中でも再利用可能そうな(と言うより再利用可能にしたいと目論んでいる)「テックリード養成講座」について紹介したいと思います. Memeplex.appで生成した, テックなリードが養成されるイメージ 経緯 僕自身は,
【資料公開】アジャイルについてマネージャーが知るべき97のこと
みなさんこんにちは。@ryuzeeです。 昨年12月に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 アジャイルコーチや技術顧問の仕事は多岐にわたりますが、その1つに社内での講演やセミナーがあります。 今回、技術顧問先のイベントで登壇しましたので、その際の資料を公開します。 アジャイルとは直接関係ないものも多々含まれていますが、ネタということでご了承ください。 アジャイル全般QCDSを同時にすべて固定することはできない要件の決まったものを早く・安く作る方法ではない開発だけをアジャイルにしても意味がないアジャイルで請負契約は無理だと心得ようすべてがアジャイルに適しているわけではない大規模アジャイルは小さなアジャイルの成功後アジャイル導入を支援しようアジャイル推進での組織的な課題に取り組もう無駄な社内プロセスを廃止するよう働きかけよう効率ではなく成果に着目した組織設計をし
社内PlatformチームのProduct Management
現職においてPlatform チーム（社内基盤チーム）として働き始めて2年近くがたった．このチームにおいて自分はTech Leadをメインに努めてきたが，同時にPlatformの「どのような機能を」「どのような優先度で」作るか? を決めるProduct Manager的な役割も果たしてきた（ちなみにTech Leadに関してはメルカリのテックリードが学んだ、HowよりWhyを重視することが大切なわけ で少し話した）．これは何度も失敗しながら悪戦苦闘しつつやってきたが自分たちなりのフレームワークをつくり実際に回すことができている． 未だに試行錯誤しているのでここで書いていることが正解だとは思っていないが，今後同じようにPlatformチーム的なことを始めるひとに向けて現状自分たちがどのようにやっているのかについて簡単にまとめておく（他の会社がどのようにやってるのかも聞きたいのでもし同じような
LayerX CTO就任によせて｜Matsumoto Yuki
2021年3月1日よりLayerX 代表取締役CTOに就任しました。急な発表で驚かれた方もいらっしゃるかもしれませんが、今回の意思決定に至った経緯、なぜLayerXなのかについて、多少エモーショナルな部分も含めnoteにて書かせていただければと思います。 DMM改革の2年半2018年10月よりDMM.comのCTOに就任し、テックカンパニー化をミッションに改革を推進してきました。その過程で取り組んできたことは様々発信してきましたので詳細はそちらを見ていただけると幸いです。 この二年半、DMMという組織を広い範囲に渡って変化させてきました。非常に少しずつ、少しずつの変化の連続ですが結果として今はDMM Tech Visionを骨子に据え、Agility, Scientifi, Attractive, Motivativeという4つのバリューに基づいて一人ひとりが考え意思決定できる組織となって
A year of DMM reformation
EOF2019にて 2018年10月からの1年間のDMMにおける改革の話です。
CTOの頭の中：技術を財務で表現する｜Shin Takeuchi｜note
会社の体制が大きく変わり、カオスの中に少しの静寂（暇）ができました。特に日々執行に勤しんでいる方々は皆そうだと思いますが、色んなこと考えているのにそのプロセスをアウトプットする機会があまりなく、結果や結論、最終的な決断のみが共有されるため、サクセッションプランに対する有効な情報を残すことも出来ていないことと思います。僕もその一人。 この時間を有効に活用するため、頭の中にあるイメージと考え方をここに、時間の許す限り吐き出していこうと思います。時折、言葉が足りないところも前提条件やバイアスの記述が足りないところもあるかと思いますが、混沌とした頭の中を曝け出すプロセスにはつきものですので、大目に見ながら読んでいただけると幸いです。 財務諸表と同じように見える化する会社は財務諸表によって経営されるものなので、経営者たるもの財務諸表を見ながら戦略を立てるべきであると僕は考えています。数字以外信じない
無能な同僚と働くということ。 - WETな備忘録
君へ、 つい最近まで、南米で3ヶ月ほどデータエンジニアとして仕事していた。Tシャツで帰ってきて震えた。寒くて。 僕にとって2019年は、あんまりいろんなことが無かったくせに、いや糞ヒマだったからこそ、いろいろ考えることが多い1年だったと思う。最後の3ヶ月以外は、基本的にヒマだった。 過去に僕はベルリンで1年ほど働いていたこと*1があり、まあ結論からいうと音を上げて、日本に逃げ帰ってきた。何がそんなにしんどかったかというと、ベルリンは十分英語で生活できるとはいえ、ドイツ語関連のトラブルシューティングに付き合ってくれるドイツ人の友人を作ることができなかったというのが大きいが、そういう人間関係を構築することが出来なかったことも含めて、当時所属していた会社の上司および同僚と上手くいかなかったのが致命的だった。 とくに、エンジニアの同僚氏、つまり君は、まったく許せなかった。 あれからもう3年も経ち、
２つのDXと技術的負債-YAPC Tokyo 2019
「エンジニアリング組織論への招待」はビジネス書としても技術書としても評価された。これら二つは別のことなのだろうか。それをも同じものなのだろうか。 この講演では技術者体験DXと企業のデジタル化のDXの２つを橋渡ししていく。 「エンジニアリング組織論への招待」の骨子である、不確実性を恐れる人間の本能を乗り越えて、それらに向き合える組織を作ることによって生産的なチームができる。 そして、ソフトウェアを作るとは、「認識に齟齬がないほど明晰な言語に書き下すこと」であれば、これは情報の非対称性を減らすというコミュニケーションそのものだろう。 このコミュニケーションのコスト構造をそのまま、システムの構造に当て込んでしまうというのを「コンウェイの法則」と呼ばれている。 組織構造の問題が、システムへと転移して、コントローラビリティを喪失すること。これが技術的負債の真実であるなら、これはありふれた経済現象であ
AWS re:Invent 2018 に参加してプレイングマネージャーを下りる決断をした | はったりエンジニアの備忘録
この記事は 裏 freee developers Advent Calendar 2018 の 2 日目です。 タイトルにもあるとおり、11/26 - 11/30 までラスベガスで開催された AWS re:Invent 2018 に参加してきました。この記事はまさに帰国途中の空港から書いています。 re:Invent は初めて参加しましたが、とても充実した時間を過ごせました！ また re:Invent に参加して自分の中で大きな変化がありました。当初は Advent Calendar に参加レポートを書くつもりだったのですが、今回はその変化について書いてみようと思います。 AWS との出会い 自分が初めて AWS を触ったときは、まだ東京リージョンもなく、サービスの数も両手で数えられました。はっきり覚えていませんが、アカウントを作ったのは 2010 年の後半だったと思います。その後、JAW
エンジニアリングマネジメントについて - HsbtDiary(2018-12-01)
■ エンジニアリングマネジメントについて Pepabo Managers Advent Calendar 2018 1日目の記事です。 @hsbt が勤務先であるペパボで最近やっているマネジメントについて紹介します。昨年は執行役員CPO兼業務プロセス革新室室長として、主に社内の情報システムやワークフローのアップデートについて携わってきましたが、今年度は技術部長としてペパボの技術者組織を率いる=エンジニアリングマネジメントを担当しています。 エンジニアリングマネジメントと、ただのマネジメントではなくわざわざ「エンジニアリング」と頭につけているからには、それ特有の何かしらの特徴があると考えています。一つにはエンジニアは専門職であるということがあると思います。その専門職集団をマネジメントすることで成果を出すためにペパボでは以下のような事項を @hsbt は執行しています。 ペパボのエンジニアの評
良いテックリード、悪いテックリード - 小さなごちそう
本記事は、下記の記事の翻訳です。著者の許可を得て翻訳しました。 この記事はフォースクエアの技術的リーダーシップを簡潔に説明したガイドだ。 ベン・ホロウィッツの「良いプロダクトマージャー、悪いプロダクトマージャー」からインスピレーションを得ている。 チームワーク / Teamwork 良いテックリードはチームの一員として振る舞い、自分の成功とはチームが成功することだと考える。面倒で退屈な仕事の一部を担って障害物を取り除き、チームが100%のパフォーマンスで稼働できるようにする。チームの技術的能力を拡大し、システムの重要な知識が属人化しないように務める。 悪いテックリードは注目の集まる仕事で自分の成果を示すことを好む。その成果は部分最適に留まり、開発チームのアウトプットを増やすにはエンジニアの人数を増やすしかない、という状況から脱することができない。 技術的ビジョン / Technical v
エンジニア組織を成功に導く「VP of Engineering」とは？ CTOとの違いも徹底解説！ | SELECK [セレック]
「VP of Engineering」という役職を知っていますか？ 海外、特に欧米のエンジニア組織では以前から欠かせない存在とされていますが、日本での認知度はまだまだ低いかと思います。 今年の1月には、Uberが元GoogleのエンジニアをVP of Engineeringとして採用したことが、トップニュースになりました。 また国内でも、4月に株式会社メルカリが、CTOとVP of Engineeringの2頭体制への移行を発表しています。 テクノロジー系のトップVCのひとつであるUnion Square VenturesのFred Wilson氏は、その存在意義について、2011年にこう語っています。 When a company has a strong CTO and a strong VP Engineering that trust, respect, and like each
![エンジニア組織を成功に導く「VP of Engineering」とは？ CTOとの違いも徹底解説！ | SELECK [セレック]](https://cdn-ak-scissors.b.st-hatena.com/image/square/89279c52f1e7c8fb19f0340403ff4763f7348cc9/height=288;version=1;width=512/https%3A%2F%2Fdpd29bjwmgbr8.cloudfront.net%2Fwp-content%2Fuploads%2F2018%2F06%2F06072140%2F993e0a25-eeba-4ea4-921f-d96ffa5e3169.png)
エンジニア組織のマネージメントってほんと奥が深いですね ～VP of Engineering meetup by CA #3～ | CyberAgent Developers Blog
エンジニア組織のマネージメントってほんと奥が深いですね ～VP of Engineering meetup by CA #3～ こんにちは、サイバーエージェント 事業推進室の伊藤 淳貴(@wildtiger0713)です。 全エンジニア組織に共通する「エンジニア組織のマネージメント」というテーマについて皆で語り合う場として開催している「VP of Engineering meetup by CA」の第3回を4/2(月)に開催しました。 VP of Engineering Meetup by CA #3 https://cyberagent.connpass.com/event/82410/ 今回もサイバーエージェントグループの各事業部、子会社においてVP of Engineering = エンジニア組織のマネージメント の役割を担うキーマン3名が登壇し、それぞれの組織における取り組みや知見
筋トレを続ける技術〜意志力をマネジメントしよう - リハビリmemo
なぜ筋トレが続かないのでしょうか？ この問いに進化生物学者のDaniell Liebermanはひとつの答えを提示しています。 「そもそもヒトは筋トレをするようにデザインされていない」 200万年という長い石器時代に、ヒトは獲物を狩るために長い距離を走り、正確にものを投げれるように身体を進化させ、獣から身を守るために恐怖や不安といったネガティブな感情もつように適応させてきました（楽観的では獣に襲われる）。現在の身体や感情があるのには、生き延びるために進化の過程で選択された合理的な理由があるのです。 そして、筋トレを続けられずに、テレビの前でゴロゴロしてしまうことにも進化論的合理性があるとLiebermanはいいます。 食べ物が少ない時代では、限られたエネルギーを狩猟や性交、獣からの逃避に費やすことが優先されてきました。余暇の時間に筋トレをしてエネルギーを無駄遣いしていては、狩猟などの機会を
「エンジニアリング組織論への招待」はいろんな立場の人に読んで欲しい - $shibayu36->blog;
最近メンタリング制度のことや、技術組織のことについて興味がある。最近「エンジニアリング組織論への招待」という本が出版されて話題になっていたので読んでみた。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 作者:広木 大地技術評論社Amazon この本は、エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」ということと述べている。その考え方に従って、思考方法、メンタリング、チーム運営、組織運営といったプログラミング以外でのやるべきことについて、様々な背景も含めて教えてくれる。 全部読んでみたところ本当に良い本であった。メンタリングや組織運営といった、なかなか汎用化や言語化がしにくい分野を、納得のできる形で言語化されていて本当にすごい。僕は最近はメンタリング制度について考えているので、特にChapter2のメンタリングの技術の章が一番
2016年のエンジニアリング振り返り - ゆううきブログ
はてなに入社して3年経った。 入社3年成功 https://t.co/GnQ3gEdLs4— ゆううき (@y_uuk1) 2016年12月1日 3年というのは節目と言われる。働き方や考え方の軸が多少変わってきたように思う。 技術観点では、仕事が少しつまらなくなっていた時期があった。 技術的におもしろいことより、つまらないことのほうが優先度が高くなってしまうというよくあるやつだと思う。 もしくは、おもしろいところまで到達できずに、仕事としては十分な成果になってしまうということもあった。 去年の振り返りに、来年はコードを書くと書いていて、多少はできたものの実感としてはあまりできていない。これからのオペレーションエンジニア/SREは、ソフトウェアエンジニアリングによる問題解決ができないと時代に取り残されてしまうという危機感がある。 技術的挑戦を続けていくためには、自分だけでなく、周囲の環境も変
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
株式会社フィネット