【資料公開】エンジニアリングマネージャーのしごと
みなさんこんにちは。@ryuzeeです。 2022年9月6日に行われたオンラインイベント「エンジニアリングマネージャーのしごと - Forkwell Library #5」の登壇資料を公開します。 内容は、新刊書籍『エンジニアリングマネージャーのしごと』に関するものなのですが、本書は18章、350ページからなる本であり全部を網羅的に紹介するのは無理筋なので、今回は根底にある考え方にフォーカスを当てています。この発表のあとにQ&Aコーナーがあったのですが、その内容については、aki.mさんのブログ記事にまとまっていますので参考にしてください。 内容に関するご意見やフィードバックは、Twitter: @ryuzee までお知らせください。 スライドを見て興味を持たれた方は、ぜひ書籍『エンジニアリングマネージャーのしごと』を読んでいただければと思います。 それでは。 エンジニアリングマネージャー
プロダクトマネージャーの転職活動記 - もくもくプロダクトマネジメント( @Nunerm )
はじめに 前提：経歴 前提：転職活動を始めた経緯 準備：企業選びの軸を言語化する 準備：自分のスキルや成果を言語化する 実施：転職サービスを選ぶ 躓き：面接が通らない…！ 問題：Why/WhatとHowに一貫性がない 問題：プロセスのアピールになりがち 再開：内定３社 おまけ：よく聞かれた質問 はじめに 2020年6月に株式会社CAMPIFREを退職し、株式会社グロービスに転職しました。 今回が3回目の転職なのですが、組織によって役割が異なるプロダクトマネージャーとしての転職には独特な難しさがありました。 そんな中、こちらの記事が非常に参考になりました。 note.com というわけで、自分の経験も誰かの役に立てばいいなと思い、転職活動記を残します。 前提：経歴 自分の過去の経歴はざっくりこんな感じです。 Javaエンジニア（4年） インフラエンジニア（3年） プロジェクトマネージャー（4
不安とストレスから解放される見積りとスケジュール方法 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを
The Cathedral and the Bazaar: Japanese
Eric S. Raymond 著 山形浩生 YAMAGATA Hiroo 訳 リンク、コピーは黙ってどうぞ。くわしくはこちらを見よ。 プロジェクト杉田玄白 正式参加作品。詳細は http://www.genpaku.org/ を参照のこと。 1999/07/30版、1999/08/16訳更新, 2000年5月2日更新 原文の最新版はhttp://www.catb.org/~esr/writings/cathedral-bazaar/にて各種フォーマットで入手可能。 翻訳の pdf 版はhttps://cruel.org/freeware/cathedral.pdfにある。 翻訳の PostScript 版 (tar+gzip圧縮）はhttps://cruel.org//freeware/cathedral.tgzにある。 第 2 部 「ノウアスフィアの開墾」 (Homesteadi
【エンジニアリング組織論への招待】を10~15分で読めるように1万文字程度でまとめてみた - Qiita
■ はじめに エンジニアリング組織論への招待という本を読みました。 ジョブ理論 に続く名著でした。 理想に向けて、事業を最速かつ生産性高く成長させるには、「未来」と「他人」という2つの不確実性をマネジメントすることで、成し遂げられる ソフトウェア開発における不確実性のマネジメントには、不確実性に立ち向かえるチーム開発が何よりも重要である（ex. メンタリング、権限移譲、信頼関係、透明性） の2点を中心に、事業成長×組織の幸せに必要なフレームワークを提供してもらえるものでした。 ソフトウェア関連の事業やプロダクトに関わっている人（特にマネジメントしている人）は職種限らず読むと、みんな幸せになれそうなので、1人でも多くの人がこの概念に触れられるように、私なりの視点で雑多にまとめました。 （ちなみに著者の 広木さん - hiroki_daichi には個別にご連絡し、要約した本記事の公開許可は(
Infrastructure as Codeと組織構造
2. 吉羽龍太郎 / Ryuzee.com ✤ アジャイル開発/DevOps/クラウドに関する従量課 金型コンサルティングサービスを提供 ✤ http://www.ryuzee.com @ryuzee 3. コンテキスト設定 複雑な領域 探索 理解 反応 カオスな領域 行動 理解 反応 込み入った領域 無秩序 な領域 理解 分析 反応 明白な領域 理解 分類 反応 ✤ 1チーム〜数10チームくらいの規模を想定 ✤ とてもお硬い領域というよりは変化の大き い領域の話 4. Infrastructure as Code (1) ✤ なんらかのアプリケーションを動かすためのインフラをコードで記述すること ✤ コードで書くことで再現性を高められる (はず) ✤ コードで書くことによって、ソフトウェア開発のプラクティスがインフラにも適用可能 になる
Developers Festa Sapporo 2016にCTOの伊藤が登壇しました！ | 株式会社一休
こんにちは。松崎です。 今日はDevelopers Festa Sapporo 2016でCTOの伊藤が登壇した内容について記事にしました！ 対象システムを Record (記録) が目的なのか、Engagement (エンゲージメント) が目的なのかで捉えてマネジメントするCTO の伊藤です。 先週金曜日は 11/11 に北海道札幌で開催された Developers Festa Sapporo 2016 で講演しました。 資料は Speaker Deck に公開していますので、興味のある方はご参照ください。 タイトルは「System of Record と System of Engagment」です。 システム、とひとことにいってもその目的が、例えば業務システムにおける個人情報の保存や確かな請求処理のように「Record (記録)」を主目的にしているのか、「使い易いユーザーインタフェー
「指示待ち人間」はなぜ生まれるのか？
『なぜ、あなたの仕事が終わらないのか』の担当編集より連絡があって、彼が担当した新しい本『自分の頭で考えて動く部下の育て方』（文響社）の関連記事を私のブログに掲載してもらえないか、という話でした。 原稿を読んでみるととても興味深かったので、そのまま掲載します。書き手は、『自分の頭で考えて動く部下の育て方』の著者であり、国立研究開発法人「農業・食品産業技術総合研究機構」上級研究員の篠原信さん。 ◇ ◇ ◇ ■ずぼら人間の周りに優秀な部下が集まる？ 「指示待ち人間ばかり、自分の頭で考えて動かない」という嘆きの声をよく聞く。不思議なことに私の研究室には指示待ち人間は一人もいない。パートの女性3名も他の研究室がうらやむほど優秀。9年連続で私のところに来た学生もことごとく自分の頭で考えて行動する。指示待ち、なんのこと？ という感じ。たぶん私がテキパキ指示を出せない人間なので、そのうち周囲があきれて、自
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発組織マネジメントのコツ - Speaker Deck