【EM必読】エンジニアリングマネジメントトライアングルの考察：序 - STEAM PLACE
エンジニアリングマネジメントトライアングル エンジニアリングの話をする前に、プロダクトマネジメントトライアングルという言葉と聞いたことはありますか？ それは、プロダクトマネジメントという言葉の定義、責任をまとめたグラフィックモデルのことです。これはプロダクトマネジメントを探求するために作られました。 かたやエンジニアリングマネジメントも組織やフェーズによって役割が違う、責任もさまざまということから、プロダクトマネジメントトライアングルと同じように思考を整理できるのではないかと考えました。*1 では、このトライアングルをエンジニアリングマネジメントで作るとどうなるのか。Engineering Manager Meetup の有志が作ったので紹介します。 エンジニアリングマネジメントトライアングル 中心にエンジニアリングを置いて、テクノロジー、プロダクト、チームでトライアングルを構成しています
ブルックスの法則を可視化できるのか（あるいは、人と月は等価交換できるのか） - STEAM PLACE
書籍:組織パターンにて興味深い数式が紹介されています。 その数式とは、ベテランが新人を鍛えたときのチーム全体の生産性表すものです。 本の中では”託児所”というパターンで紹介されています。 なぜ興味深いのか 人月の神話、ブルックスの法則にある通り、開発者の人数と生産性が比例しないことは自明の理ですが、わたしはそれを論理的に説明することができませんでした。 ブルックスの法則 ブルックスの法則はフレデリック・ブルックスによって提唱された、「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」という、ソフトウェア開発のプロジェクトマネジメントに関する法則である。 数式を使ってシュミレートまでできると、開発者の人数と生産性の関係性の説明でき、さらに最適な人数がわかってくるのではないかと考えました。 問題に思うこと さて、プロジェクトを進めていると「開発者をもっと
エンジニアリング組織の文化ができるまでの3年間の軌跡 - STEAM PLACE
メリークリスマスイヴ！ この記事は Engineering Manager Advent Calendar 2018 の24日目の記事です。 私 (@dskst9) が3年前、アスクルという会社のエンジニアリングチームにJoinしてから、エンジニアリング組織の文化がどのように作られていったのかというお話です。 これは、私自身のアクションと、エンジニアリングチームの一人ひとりがアクションしたことを織り交ぜて書いています。誰かがアクションし続けることで、会社は変わり続けることができるということを感じてもらえると幸いです。 この記事が伝えたいこと どんな会社でも変えることができる 組織を変えたいなら自分自身でアクションする 組織がアクションを続けると習慣となりそれが文化になる この記事が伝えたいこと そもそもどんな会社 むかし いま ふりかえる Forming（形成期） やったこと Stormi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
