開発組織のOKRの作り方 / OKR in a develoment division
OKRと「測りすぎ」 〜なりたい姿を、「測りすぎ」ないようにしながらどう追いかけるか〜/OKR and the tyranny of metrics
チームトポロジーを読んだ感想
はじめに 最近、チームってどんな構成にするのがいいんだろうか？と考えたことがあって、参考になる情報がほしかったのでこの本を読んでみた。この本は組織設計について書かれた本で、次のようなことが書かれてる。 どうチームを構成するか？ チーム間のコミュニケーション（インタラクション）をどう設計するか？ 定義したチーム構成やコミュニケーションの設計をどう変化させていくべきか？ チームファースト、コンウェイの法則などの考え方をベースにこういった問いに答えており、具体的な事例も紹介されつつ説明されていたので、わかりやすかった。 個人的に特に知りたかったことが、１つのチーム内で複数のプロダクトを扱うときのアプローチ方法だった。この本はコンウェイの法則推しなので、境界線をみつけてチームを分けた方が良さそうだと思いつつ、よく読んでみると組織のサイズやソフトウェアの規模が小さい場合は、必ずしもこの法則に従わなく
AWS Well-Architected フレームワーク DevOps ガイダンスが発表されたのでサマってみた
AWS Well-Architected フレームワーク DevOps ガイダンスが発表されました。 ガイダンスは6つの柱とは違い、特定のユースケースやテクノロジーにフォーカスしたドキュメントです。DevOps を継続的かつ効果的に導入・実践することを支援してくれます。 ベストプラクティス〜アンチパターン〜メトリクスという段落構成になっており、ありがちな理想論を語るドキュメントではなく本当に実践的です。 それでは DevOps ガイダンスをサマってみます。本エントリは機械翻訳でサマっています。ご了承ください。 本家のドキュメントはこちらです。ぜひお読みになってください。 DevOps Guidance 要約と紹介 最初の章です。このガイダンスを作成するに至った経緯や言葉の定義が書かれています。 面白い一文があったので引用します。 There is no one-size-fits-all
「名前のない仕事」ができる人は強い
ℹ この記事は推敲中のため、今後大幅な変更が加えられる可能性があります。 ここのところ至るところで話している気がするので、この機会にブログにまとめておくことにする。 最近人にポジティブなフィードバックをするときや、ある人の仕事ぶりをポジティブに伝えるときに「名前のない仕事」という言葉で表現することが非常に多くなった。 この表現自体は以前から必要に応じて使っていたものの、感染症の影響下にあった世界の雪解けにつれて、こう表現できるシチュエーションが増えたように感じる。 「名前のある仕事をそつなくこなすことは誰でもできる、ただ名前のない仕事は、その意識と実行力が伴った人間が行って初めてできる」という言葉の理由を改めて伝えたい。 直接話す人達にはその文脈に即したその人の活躍を交えて伝えられるが、誰に対してもその機会があるわけではないので。そのため抽象的な話にはなるが、この記事を通じて企業組織に所属
なぜソフトウェア開発者はテストのスキルを身に付ける必要があるのか
急速に変化するソフトウェア開発のライフサイクルに対応するため、多くの組織において、テストは欠かせない存在になった。ソフトウェア開発者にはテストを容易にするアプリケーションを構築するスキルだけでなく、パイプラインを通じてテスト結果を追跡するようなテストスイートを作成するスキルも求められる。 だが、効果的なテストスイートを作成するのは、適切なテスト戦略や、経験、トレーニングがない開発者にとっては容易ではない。正しいテスト習慣を身に付けることができなければ、見逃したバグを絶えず追いかけるリスクが伴う。
“高効率で”強いプロジェクトマネージャーを目指すために ステータス表でわかる2つのことと、活用してできる2つのこと
複数事業に携わるPM組織のスキル成長と評価について、コングロマリットな経済圏を持つDMMのPMから聞く「複数事業を跨ぐPM！なんでもやるDMMに聞く、PM組織の成長と評価の話【開発PM勉強会vol.21】」。ここで合同会社DMM.comの金築氏が登壇。PjM能力の可視化について話します。 金築氏の自己紹介 金築英雄氏：では私から始めます。今回私からは「可視化から始まるPjM育成」といった話をします。まず自己紹介させてください。名前は金築英雄と申します。経歴としてはアプリエンジニア、チームリーダー、諸々の経験を経て、現在プロジェクトマネージャー（PjM）として仕事をしています。 2023年にPMP（Project Management Professional）を取得して、さらにプロジェクト推進とかPjM採用、PjM育成に熱を上げています。今回は可視化がテーマなので、私のステータスなんかも書
アジャイル、とりわけスクラム開発をやるときに立ち向かわなければならない壁の話 - freee Developers Hub
この記事は freee Developers Advent Calendar 2022 の3日目です。 このドキュメントはなにかの答えをあたえるというより、アジャイルやスクラムを有効化させる上での障害はこれであるということを検討するためのドキュメントです。壁はすべての環境で発生するわけではないですが、そういう壁があるということを認識することで、転ばぬ先の杖となるような文章になることを目指しています。そして、その解決方法は示さず「意図的に不完全」にしています。これを読んで「なぜ意図的に不完全にしているのか」を味わっていただければと思います。（あるいは、私自身のエクスキューズかは読んでる皆様にその判断を委ねます） 前提: アジャイル開発とは アジャイルソフトウェア開発（以後、アジャイル開発）はアジャイルソフトウェア開発宣言で示されている価値の実現を目的とした開発手法です。宣言では4つの項目でそ
アジャイル開発時代は、“人間工学”の時代 アジャイルマニフェストはどのように定められたのか
アジャイル時代は「人間の工学」の時代 川口恭伸氏（以下、川口）：ここから2001年です。アジャイルに入ります。 1990年代からスクラムとかでXPはやられていますが、2001年に初めてアジャイルマニフェストというものが作られました。アジャイルマニフェストが何だったのか、その後の影響の話をしていきます。 これは「アジャイル開発の時代」という別のスライドから抜粋してお送りします。 まず、私の知り合いというか、先生にデビッド・バーンスタインという人がいて、『レガシーコードからの脱却』という本を書かれています。この人が言っていたのが、「ソフトウェアの品質って何ですか？」と。 30年前の品質は今と違うよね。30年前だったら動いているものが正解みたいな、「動いているものはいじるなよ」みたいなことを言われていましたが、今はきれいに整理されていて、メンテナンスしやすい、つまり変化に対応できることが必要だと
これからの時代に求められるアジャイルな組織づくりとリーダーシップ - Mitsuyuki.Shiiba
アジャイルリーダーシップ を翻訳者の一人であるヒロオカさんにいただいて読みました。ありがとうございます！今の自分にグサッとくる内容でとてもとても良かった。今後の自分の行動も変わりそうです。今日から数日後の11月22日に発売されます www.kyoritsu-pub.co.jp 読みやすかった 著者は SCRUMMASTER THE BOOK を書かれたズージーさん ズージーさんの本自体が読みやすいのと、あと、ユーザベースさんの翻訳が読みやすいのとで、とても読みやすかった。英語の言い回しって日本語にすると分かりにくかったりするけど、そういうのがなくて、自然に読むことができた アジャイルリーダーシップ？ 「アジャイルリーダーシップ」ってタイトルを見たときは、アジャイルなチームのリーダーの話なのかな？スクラムマスターはこうあるべきだよとかって話？と思ったのだけど、読み始めてみるとそうじゃなくて、
「成果を出せば評価される」という考えが不幸の始まり 人事評価制度に不満の声が出る、必然の理由
人気シリーズ『図解 人材マネジメント入門』や『図解 組織開発入門』の著者であり、企業の人材マネジメントを支援する株式会社壺中天の坪谷邦生氏が、MBO（目標管理）をテーマとした新刊の発行にあたり、各界のエキスパートと対談を行います。第3回の後編は『最高の結果を出すKPIマネジメント』の著者である中尾隆一郎氏と、人事評価制度に不満が出やすい理由や、ハイパフォーマーを育てるマネジメント手法について語りました。 「成果を出せば評価される」という考えが不幸の始まり 坪谷邦生氏（以下、坪谷）：私はもともと人事制度のコンサルタントなので、KPIマネジメントと評価・報酬との紐づけが気になるんです。メールで「密結合ではなく、疎結合にしたほうがうまくいく」と教えていただいたのですが、もう少し詳しく聞かせていただけますか？ 中尾隆一郎氏（以下、中尾）：普通の人は、成果を出したら評価をされて、給料が上がって、昇進
統一教会と自民は“一心同体”。安倍元首相が破壊した「政教分離の原則」 - まぐまぐニュース！
安倍元首相銃撃事件以降、次々と明らかになる自民党と旧統一教会との浅からぬ関係。その繋がりは、もはや「一心同体」と言っても過言ではないもののようです。今回の『 きっこのメルマガ きっこのメルマガ 』では人気ブロガーのきっこさんが、旧統一教会がどのような団体であるかを解説するとともに、彼らと安倍政権がお互いの利益のために行ってきた「活動」を詳細に紹介。その上で、安倍元首相は日本における政教分離の原則をも破壊したと断言しています。 この記事の著者・きっこさんのメルマガ 初月無料で読む 安倍晋三と統一教会の蜜月関係 参院選の最中に発生した安倍晋三元首相の殺害事件で、またスポットを浴びることになった韓国のカルト教団「統一教会」ですが、安倍政権下の2015年に名称を「世界平和統一家庭連合」に変更し、安倍政権が終わった2020年には「天の父母様教団」に変更しています。しかし、これらの名称は長いし紛らわし
「61億Ｋ必要」“Ｋ”＝献金集めるよう指示する内部文書入手 謎の“Ｍ作戦”も “統一教会”元信者が語る【第4弾】富山 | TBS NEWS DIG
安倍元総理が銃撃され死亡した事件で、逮捕された男の母親が旧統一教会に献金した金額は1億円に上るということです。なぜ家庭が崩壊するまで献金に走るのでしょうか。そこには精神をコントロールする巧妙な手段が…
プロダクトマネジメントを学ぶための推しの書籍
プロダクトマネジメントを学びたい人、プロダクトマネージャーにおすすめの書籍です。 以下、記載した書籍のリストです ## Product Management ### プロダクトマネジメントを広く理解する 「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」オライリージャパン (2020/10/26) https://www.amazon.co.jp/dp/4873119251/ 「プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで」翔泳社 (2021/3/3) https://www.amazon.co.jp/dp/4798166391/ 「INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント」日本能率協会マネジメントセンター (2019/11/1) https://www.amazon.co.jp/dp/4
「みんながCTO・PdM・テックリードをやる組織が理想」 エンジニアリング思考を活用したマネジメント道
「Day One - CTO/VPoE Conference 2022 Spring -」は、日本CTO協会が主催するイベントです。パネルディスカッションでは、政財界、テクノロジー分野の第一人者をパネリストにお迎えし、日本CTO協会理事のモデレートにより、“Day One”をテーマにご講演いただきます。ここで登壇したのは、株式会社Lighthouse Studio CTOの海老原昂輔氏。これまでの経験から導き出した、“ソフトウェアエンジニア的思考をマネジメントに活用するアプローチ”について発表しました。全2回。後半は、3つ目の転機と海老原流マネジメント道について。前半はこちらから。 転機その3 「ストレングスファインダー」の活用 海老原昂輔氏：おぼろげながら、自分と他者との違いがわかりかけてきた私に訪れた、第3の転機が、このストレングスファインダーです。（スライドを示して）これはさまざまな
Google 、SalesforceのPMは、どう開発の難題に立ち向かう？ 強いプロダクト組織の考え方 | キャリアハック（CAREER HACK）
Google にてGroup Product Managerを務める徳生裕人氏、日本CPO協会・代表理事を務めるKen Wakamatsu氏が登壇。それぞれ複数の組織を見てきた観点から考える「強いプロダクト組織」の作り方とはーー。及川卓也氏によるモデレーションで行われたセミナーをレポートする。 ※2022年4月に開催されたクライス＆カンパニー主催「クライス汐留アカデミー」より『「強いプロダクト組織の作り方」～プロダクト組織作りの要諦となる採用と育成～』セミナーのレポート記事をお届けします。PM＝プロダクトマネージャーとして記載しています。 前半パートはこちら 後半パートはこちら Moderator クライス＆カンパニー 顧問 及川 卓也 MicrosoftにてWindowsおよびその関連製品の開発を担当した後、Googleに転職し、ウェブ検索やGoogleニュースのプロダクトマネジメントや
伸ばすのが難しい能力: 柴田 芳樹 (Yoshiki Shibata)
2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。 ソフトウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない API仕様については、このブログでも何度か書いています（「API仕様を書く」）。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
仕事の進め方がグダグダの会社はどうすればいいのか、「プロジェクトマネジメントの基本が全部わかる本」の著者に聞いてみた
より多く書き、より少なく話す：ドキュメンテーションとインナーソースで組織のレジリエンスを高める
ChatGPT で自分の仕事がどう楽しくなるのかを考えるネタ集 -2023年10月バージョン-
OKRはツリーではない
