OKRと「測りすぎ」 〜なりたい姿を、「測りすぎ」ないようにしながらどう追いかけるか〜/OKR and the tyranny of metrics
OKRと「測りすぎ」 〜なりたい姿を、「測りすぎ」ないようにしながらどう追いかけるか〜/OKR and the tyranny of metrics
OKRと「測りすぎ」 〜なりたい姿を、「測りすぎ」ないようにしながらどう追いかけるか〜/OKR and the tyranny of metrics
エンジニアリングマネージャーの4領域はEM以外のメンバーでも濃淡はあれど意識する必要がある - stefafafan の fa は3つです
株式会社はてなでテックリードとして仕事をしている id:stefafafan です。今回は自分が個人的に考えてきたことを記事としてまとめてみます。 エンジニアリングマネージャーの4領域とは EMでなくとも4領域を意識する必要がある テックリードの場合 スクラムマスターの場合 Individual Contributor (IC) の場合 ロールを持たないソフトウェアエンジニアの場合 結局エンジニアリングマネージャーの役割とは 終わりに エンジニアリングマネージャーの4領域とは ここで私がEMの4領域と呼んでいるのは以下の4つの領域のことです。 テクノロジーマネジメント アーキテクチャやテストなど プロジェクトマネジメント 見積もりやアジャイル開発など プロダクトマネジメント ビジョンや仮説検証など ピープルマネジメント メンバーの成長やメンタリングなど これらの4つの領域は @hiroki
「ドラッカー風エクササイズ」で期待をすりあわせて安全なチームに - Pepabo Tech Portal
EC事業部チーフテクニカルリードのけんちゃんくんさんです。 GMOペパボでは、新しいプロジェクトが始まるときや何かの節目に、チームビルディングの手法としてドラッカー風エクササイズや、それをカスタマイズしたワークショップを実施しています。今回は、そのワークショップの中身と、ファシリテーターとして気をつけていることをお伝えします。 ドラッカー風エクササイズとは ドラッカー風エクササイズは、アジャイルサムライの著者であるJonathan Rasmusson氏が書籍やブログで紹介しているチームビルディングの手法です。4つの質問に全員が答えることで、相互理解の促進と期待のすりあわせという効果があり、特にプロジェクトの開始時や新メンバーを迎えるときに効果的であると言われています。 4つの質問 「4つの質問に答えるだけ」と書きましたが、質問の内容はなかなかハードです。 自分は何が得意なのか？ どういうふ
プロダクトマネジメントの優先順位付けフレームワークの究極ガイド
この記事は、以下サイトの機械翻訳です。 何を作るか（あるいは次に何を作るか）を決めることは、プロダクトマネージャーの仕事の中で最も重要な部分の一つです。インパクトを与えるチャンスは何度もありません。だからこそ、賢く選択して、チャンスを最大限に生かすことが重要なのです。 プロダクトの優先順位を決めるには、さまざまな要素を考慮する必要があります。しかし、何よりもまず、お客様の真の問題を解決することを優先しなければなりません。多くの企業では、このプロダクト開発の基本方針が守られていません。おそらく、価値よりも革新性を優先しているからでしょう。私たちは皆、自分たちが最先端の先駆者であると他人に思われたいと思っていますが、市場が求めているのは必ずしもそうではありません。 市場が求めているのは、すでに機能しているものを適度に改良することだったりします。究極のゲームチェンジャーを追い求めるのではなく、フ
なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
人間、チーム、プロダクトあたりのマネジメントに一切触れてこなかった人間が手始めに読むのによい文書 - ruby-jp
人間、チーム、プロダクトあたりのマネジメントに一切触れてこなかった人間が手始めに読むのによい文書ってなんかないですかね
一人前のプロマネってどんな人？ プロジェクトマネジメントのスキルセットとは - 誰も教えてくれないプロマネのコツ
今やあらゆる場面で必要とされるプロジェクトのノウハウを、300件以上成功させてきたプロフェッショナルがこっそりお伝えします。 先日、仕事で関わっている方から、「結局、プロマネって何ができないといけないんですかね？」という質問をされたので、その場でざっくり洗い出してみました。 世の中には PMBOK や ITSS, PRINCE2 などのスキル標準を定めたものはありますが、これらは大規模システム開発を志向しており、概念として抽象度が高いためベースの知識として利用できる環境は残念ながら非常に少ないという現実があります（もしこれらを利用できる環境にいるならとても幸せなことです）。 少なくとも日本で実施される一般的なプロジェクトは PMBOK や ITSS を元に共通認識を整備するどころか、「限られた予算で1年でクライアントのシステムを刷新する必要がある」とか、「社長の思いつきで何も決まっていない
締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
自分は何をマネージメントしているのか - そーだいなるらくがき帳
かっちゃん（id:katzchang） の記事を読んで思ったことをつらつらと書く。 medium.com 前提 今はオミカレという婚活パーティーのポータルサイトのWebサービスをメインにしている会社でCTOをしている。 CTOといっても会社の人数は15人未満でエンジニアは自分を入れても8名しかいない。 だから厳密なマネージャ職はおらず、CTOと名が付いているけども自分がCode書くなどのプレイヤーの仕事をしながらエンジニアやプロジェクトのマネージメントを兼任してる。 オミカレ party-calendar.net 婚活パーティーやお見合いパーティー、街コン、趣味コンといったイベントのポータルサイト。 自社でイベントなどは行わずに、主催されている方々からの情報提供を受けてサイトに掲載している。 そもそもプレイングマネージャーはアンチパターンでは？ これは常日頃から思う。 何をマネージメントす
父親に聞いた管理職として「ダメなチームをデキるチームにする必勝パターン」 - komagataのブログ
もう定年してますが、郵便局の管理職歴うん十年の父親に社会人の大後輩として、 「管理職としてダメなチームをデキるチームにする必勝パターンみたいなのってあるの？」 と聞いたら 「あるよ」 とあっさり。その話が面白かったので紹介します。 背景父親は郵便局員で公務員だった。郵政民営化する前の話。公務員は一般企業と違い犯罪でも犯さない限り首にならない。（管理の難易度が高い）郵便局の仕事は大きく「郵便」「貯金」「保険」の３つに分かれている。父親は「保険」のセールスマンの管理職を長年やっていた。郵便局の管理職は３年（？）毎に別の局（調布市郵便局とか）に移動する。 1. 新しい職場（チーム）に赴任したらそこの中心人物の協力を取り付ける中心人物：顔役的な人で大抵が年長者やリーダー気質の人。どこの組織にも必ずいて、誰にでもすぐに分かるそうです。（役職的には自分より下の人です。） 父「誰に聞いても山田（仮）さん
チームを育てるのに7つのレベルのデリゲーションを考えてみる - Mitsuyuki.Shiiba
この数年は色んな開発チームのサポートをしてるんだけど、最近、その中のひとつのチームに対するサポートの方法を切り替えた。「外からアドバイスをする」から「中に入って実際にやり方を見せる」に。 たまに「どうしてそこまでやる必要があるのか？それで成長できるのか？自分で考えて決断をしていくことで成長するべきではないか？」みたいに考える人もいるかもしれないけど、僕は単にそうした方がそのチームにとって良いなと思っただけ。 「このチームはダメだなー」とかは全く思ってなくて、むしろそのチームのことが好きなので「どうやるのが一番ストレスなく成長できるかなー？」というのを考えた結果の切り替え。 ただ、感覚で動いてしまってるので、自分の頭の中の整理のためと、そのチームも含めて周りの人に説明できるようにするために理由を考えてみたいと思う。たぶん、Management 3.0の7つのレベルのデリゲーション（権限委譲）
チームリーダーをやるときに気をつけてた「4つの混ぜない」 - Mitsuyuki.Shiiba
開発チームのチームリーダーやってたときってどんなこと考えながらやってた？って相談があって、僕がチームリーダーやってたときはこういうことに気をつけてたよ。って話をした。今は僕はリーダーは後輩にまかせて、自分はシニアエンジニア的な立場でコードを書いたりウロウロしたりして楽しく過ごしてるんだけども。 4つの混ぜない やってるときは特に考えてなかったけど、今になって考えるとこういうこと気にしてたなーってのね。数は、単に4つ思い出した。ってだけ。 帽子を混ぜない エンジニア出身のチームリーダーって、こんな帽子をかぶってることが多いかな: 組織マネージャの帽子で 後輩の育成や組織としての成長を考えたり 開発リードの帽子で クオリティの最後の砦みたいな役割や、チームの外との調整をやったり プロジェクトマネージャの帽子で プロジェクトをどうやってうまく回していくかを考えたり なので「今の自分の気持ちはどの
タスク管理アプリ「Todoist」の開発会社から学ぶ、「リモートワーク」の運用を成功させるために必要な2つの要素 | ライフハッカー・ジャパン
初めまして、世界を旅しながら働く"リモートワーカー"の早瀧正治（はやたき・まさはる）です。フリーランスの翻訳家兼マーケターとして、日本に進出したい海外の企業や、海外の広告代理店にオンラインマーケティングや翻訳サービスを提供しています。 世界中に1000万人以上、日本でも10万人以上のユーザーがいるタスク管理アプリ「Todoist」の開発会社Doistは、リモートワークの従業員が世界中に50人以上います。 ほとんどの従業員が互いに面識がなく、日本市場の担当者である私も、仕事で同僚と会ったことは一度もありません。 経営層も含め、ほぼ全員が別々の国でリモートワークをしており、私自身も海外旅行をしながらリモートで働いています。 Doistは、決して従業員の幸せを考えてリモートワークを導入しているのではありません。 企業としての合理的な経営のためにとった手段が完全リモートチームだったのです。 この記
「伸びる」仕事の頼み方 /how-to-request-work-to-grow
pmjpオフ会#8 での発表資料です。
権限を委譲したい/してほしいときに便利なデリゲーションポーカー - Qiita
デリゲーションポーカーの出典はこのあたりです。 仕事は、あらゆる場面で、様々な決定をしながら進める必要があります。 ですが、何を誰が決めるかでモメることはありませんか？ チームメンバーは「私はどこまで決めていいのか」と思うときがあるでしょう。 また、偉い人も「私はどれほど決定していいのか、又は委ねていいのか」と思う時があるでしょう。 そんな時に便利なのが「デリゲーションポーカー」です。 権限委譲は「する/しない」といった2値の問題ではなく、7段階のステップに分かれています。 7段階のステップは以下です ※私=偉い人、彼ら＝チームメンバー 命令する(私が彼らに決定を伝える) 説得する(私が彼らに売り込む) 相談する(彼らに相談し私が決める) 同意する(私と彼らが合意して決める) 助言する(私は助言するが彼らが決める) 尋ねる(彼らが決めた後で私が尋ねる) 委任する(私は彼らに完全に委ねる)
どのようにエンジニアの目標設定を行うか - $shibayu36->blog;
以前 ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。 しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。 僕がメンティーと目標設定を行うときは、以下のフローを辿っている。 なんでも良いのでゴールのイメージを明確にする 現在の自分とゴールのイメージのギャップを考える ギャップを埋める目標を考え、アクションを定める ちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。 なんでも良いのでゴールのイメージを明確にする
それでも人を変えることはできない。変わってもらう方法は「ある」｜長沢智治のブログ
人を変えることはできない 10年以上前からの講演などで触れるようにしていることがあります。それは、人を変えることはできないという事実です。 よく質問で、「たくさんの人がいると必ずしも前向きな人ばかりではない、彼らをどう変えていけるのか」とか、「マネージャの意識を変えてもらわないと推進できないが」などいただきます。そういうときにお話しをさせていただく内容を書きたいなと思います。 ここで書いていることは私の実体験にもとづくものがベースですが、心理学者の講演会や、TV番組で得た知見も含まれます。 なぜ人を変えることはできないのか 人には防衛本能があります。自分を守る本能ですね。なので、自分が培ってきた経歴、経験、スキル、嗜好に抵触する変化を好まないわけです。 そもそも人には「根拠のある自信」と「根拠のない自信」が必要です。この二つの「自信」がないと生きてゆけません。 「根拠のある自信」は、自らの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発組織のOKRの作り方 / OKR in a development division
心理的安全性を 0から80ぐらいに上げた話
エンジニアのチーム開発入門 - 心技体を磨いて自身とチームをより良くしよう / Being geek in the team
