マネジメントを4年くらいやっている間に、何人かにEngineering managerや採用のリードなどの役割をお願いして担ってもらってきた。何か新しい役割をお願いする時に整理して伝えている項目を雑にまとめておきたい。 以下のようなGoogle docsを作って共有し、30分のミーティングで直接伝えて考えてもらうようにしている。タイトルは「◯◯さんにxxをお願いしたい」みたいな感じ。項目や内容は相手によって適宜変えてる。 これは何 「◯◯さんにxxをお願いして一緒にやっていきたいと考えています」みたいな感じでストレートにお願いしたい役割を書く 「命令ではなく、なぜお願いしたいか、何をお願いしたいかなど◯◯さんに意思決定する材料を渡すためのdocsです」のようにまだあくまで提案ですよということも書く なぜ今お願いしたいか プロダクトや組織の状況も踏まえて、"今"お願いしたい理由を書く その役
中田:‖ @paddy_joy 今日のマネジメント研修はめちゃくちゃ良かった。Twitterではボロクソに言われてる人が講師だったのでむしろネタにしてやろうくらいの気持ちで受けたんだけれども説得力がTwitterとは段違いだった。発信する場によってこれくらい印象が変わること自体が一つのケーススタディーになりそう。 中田:‖ @paddy_joy 「"心理的安全性"は部下の立場でしか語られないのが大きな問題。「指摘したら部下が落ち込むんじゃないか」「指導をしたらパワハラ扱いじゃないか」などと心配するのは上司の側の心理的安全性が脅かされている。ダメなものはダメだと上司が躊躇なく言えなければその組織も強くならない」 中田:‖ @paddy_joy ↑この前段に、「部下が上司に指摘できない組織は死ぬ」というデータがいくつも出てきて、例えば ・副操縦士が機長に指摘できない飛行機は落ちやすい ・リーダ
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
委託したシステム開発が頓挫したとして、野村ホールディングス（HD）と野村証券が日本IBMを相手取って計約36億円の損害賠償を求めた裁判。プロジェクト失敗はベンダー側に非があるとした2019年3月の一審判決から一転、2021年4月の控訴審判決はユーザー企業側に責任があるとした。工数削減提案に十分に応じなかったり、プロジェクト途中で追加要件を多発したりした野村側の姿勢を東京高裁は問題視し、逆転敗訴の判決を下した。 関連記事 野村HDが日本IBMに逆転敗訴の深層、裁判所が問題視した「X氏」の横暴な変更要求 野村HDが日本IBMに逆転敗訴のワケ、「工数削減に応じず変更要求を多発」と指摘 東京高裁が特に問題視したのが、システムの仕様を策定するうえで重要な役割を担っていた野村証券のユーザー部門「X氏」の振る舞いだ。 当時、投資顧問事業部（判決文では「投資顧問部」）の次長だったX氏は、パッケージソフトに
ゲーム開発 プロジェクトマネジメント講座 ２０１１年１０月８日 株式会社スクウェア・エニックス CTO 橋本 善久 1 ©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか？ 2 ©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3 ©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ（コンテンツの範囲）の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース（人員・環境）の問題 • ビジネスの問題 4 ©SQUARE
この記事は Engineering Manager vol.2 Advent Calendar 2019 の 4 日目の記事（代打）です。 はじめまして。メルペイでBackendのEngineering Manager（以下EM）をやっている@keigowです。 MeEM目線でもエンジニア組織を振り返ってみようと思います。 はじめに 振り返り VPoEの入社（2018年4月〜） PM/EM/TL体制の導入（2018年7月〜） リリースに向けた開発（2018年10月〜） メルペイ1stリリース（2019年1月〜） 大型キャンペーンと組織体制の変更（2019年4月〜） 技術負債の返済と採用（2019年7月〜） 成長とクオリティの追求（2019年10月〜） おわ
新しい便利なサービスを世の中に広めるためには、(1)サービスを思いつく (2)プロトタイプを作って感触を確かめる (3)周囲を巻き込んで利用してもらう (4)高品質な実装を行なって公開する (5)ユーザの声を聞きながら継続的に改善を続ける という長いステップが必要である。Nota Inc.で展開中のGyazo, Scrapbox, Helpfeelはいずれも10年以上にわたって(1)〜(5)を継続している。講演者はもっぱら(1)〜(3)を担当しているが、(4)〜(5)のプロダクトマネジメントまでの連続的な流れについて、Notaでの実例を紹介する。
久津（@Nunerm）です。 「日本のPMといえば？」という問いに高確率で名前が出てくるであろう人といえば。 及川卓也さんですね。 この度その及川さんから「プロダクトマネジメントの極意」を伝授いただける機会に恵まれました。NewsPickアカデミアのゼミです。 newspicks.com 決して安くない受講料のゼミの30人の枠に対して60人の応募があったそうで、日本でもプロダクトマネジメントを学ぶ必要性に迫られている人が増えてきているんですね。 というわけで、この記事では初日の講義での学びである 「PMは技術力やドメイン知識をどこまで持つべきなのか」 の考察を書きます。 PMは技術力やドメインに詳しくあるべき？ PMの役割には色々な定義がありますが、メルペイの丹野さんの言葉を借りると以下のようになります。 このうち①を実現するためには、PMがその事業が属するドメイン（領域）を理解する必要が
デブサミ2017でパネルディスカッション形式で登壇させていただいた。 event.shoeisha.jp エンジニアからプロダクトマネージャーへのキャリアがテーマで、私自身どうやってなったのか振り返るキッカケになった。また別の機会でもエンジニアのキャリアについて考えることが多く、改めてエンジニアからプロダクトマネージャーへのキャリアについてまとめてみた。 プロダクトマネージャーの仕事と必要なスキル まず、プロダクトマネージャーの仕事とスキルについて言語化を試みた。プロダクトマネージャーの教科書であるINSPIREDにもあるように、プロダクトマネージャーの任務は2つ、「製品の市場性を評価する」ことと「製品を定義する」こと。少しわかりにくいので、下記の3つのプロセスを定義した。 市場の分析 STP（セグメンテーション/ターゲティング/ポジショニング・コンセプト） 製品要求の定義 Webの製品開
Japan Product Manager Conference 2016におけるナイアンティック河合敬一さんと、インクリメンツ及川卓也さんの対談をレポート。会場から飛んできた鋭い質問に2人はどう回答した？ ▼前編はこちらより 『ポケモンGO』のナイアンティック社・河合敬一が語った、プロダクトマネージャー論 「変化の仕掛け」をつくる ※2016年10月に開催された「Japan Product Manager Conference 2016」よりレポート記事をお届けします。 この日会場に集まったのは、自身がPMであったり、とても近しい領域を担う人たち。『ポケモンGO』のPMである河合敬一さん、そしてMicrosoftやGoogleでヒットプロダクトの開発に関わってきた及川卓也さんを前に、多くの質問が飛び交った。 その一部を河合さんと及川さんの回答とともに紹介する。 Q：組織やプロダクトの規模
『ポケモンGO』のヒットが記憶に新しいナイアンティック社。同社にてプロダクトマネジメントを統括しているのが河合敬一さんだ。河合さんが語った「プロダクトマネージャー（PM）論」とは？ 日本におけるプロダクトマネジメント全体の底上げを ※2016年10月に開催された「Japan Product Manager Conference 2016」よりレポート記事をお届けします。 ヒットするプロダクトを作るには、技術力の高いエンジニアやデザイナーはもちろん、優秀なプロダクトマネージャー（以下、PM）が必要だ。 しかし、日本において特にWebにおけるPMの重要性が語られるようになったのはここ最近。教育の場も、正しい評価制度も、きちんと整備されているとはいえないだろう。 そんな現状を打破し、日本のPM業界全体の底上げをはかるため開催されたのが「Japan Product Manager Conferen
「入門 組織開発」を読みました 入門 組織開発 活き活きと働ける職場をつくる (光文社新書) 4月から組織活性を担当する部門に異動になりました。 「よーし、組織活性するぞ～！」と盛り上がっているのはいいですが、「そもそも組織活性とは？」がわかっていない僕。 新しい上司が「読んでおくといいですよ」とこの本をおすすめしてくれました。 南山大学の中村和彦教授の著書で、タイトルどおり組織開発に関する入門書になっています。 組織開発の定義や、どんな手法や取り組み事例があるか、また現在の組織開発における課題について、非常にわかりやすく説明をしてくれています。 一部アカデミック（学術的）な内容もありますが、それも初心者がわかるように易しく書かれています。 まさに導入としてはうってつけで、僕と同じようにこれから組織開発に携わる人にとっては必読の一冊だと思います。 特に勉強になった点の要約本書を読んでこんな
MicrosoftやGoogleでヒットプロダクトの開発に関わってきた及川卓也さん。現在、プロダクトマネージャーが育つ土壌づくりを推し進める。なぜ、業界全体での底上げに取り組むのか？及川さんのインタビューを通じて見えてきたのは、日本のITをより強くしたいという及川さんの思いだった。 PMが育てば、日本のITは欧米に負けないくらい強くなる｜及川卓也 プログラマー向けの情報共有サービス「Qiita」。提供元であるInPM）を務めているのが及川卓也さんだ。 及川さんはMicrosoftやGoogleといった企業で、さまざまなヒットプロダクトの開発に関わってきた、まさに日本のPMの第一人者といえる存在。 PMは海外だと多くの優秀な人材がこぞって志願し、“ミニ本における認知度はまだ低
(Qiita:Teamで社内にて共有していた記事を公開) GoogleやZyngaで使われているOKRという仕組みが、「会社として何が大事なのか」「そのためにチームや自分は何に集中すべきか」を明確にするフレームワークとしてよさそうなので調べてまとめてみた。 OKR(Objectives and Key Results)とは OKRは会社やチーム及び個々のメンバーの目標(Objectives、達成すべき戦略目標)と主要な結果(Key Results、その目標の達成度を示す客観的指標)から成り立つ。 OKRを導入することのメリット Objectives and Key Results ( OKR )より 思考が統制される 大きな目標が明らかになる 日々のオペレーションにかかりっきりだと「実際のところ何が重要なのか」は見失いがち メンバーと正しいコミュニケーションをとることができる 各々が何を重
知らないのは日本人だけ？―なぜトヨタは世界で売れ続けるのか。 それは「トヨタ生産方式」が利益を生み出しているのではなく、秘密は「主査制度」にあった。アメリカ企業が徹底研究して、次々とイノベーションを起こす源流は日本にあったのだ！ 「ダメじゃないですか」 リストラについての相談を受けているとき、酒井崇男は思わずそう口にした。人事・組織関係のコンサルティング「グローバル・ピープル・ソリューションズ」の代表取締役を務める彼は、リーマンショック前後からリストラの相談を受けることが増えた。大半はメーカーなどの研究職。一流企業の有能な技術系エリートばかりだ。ところが、面談中、酒井が研究について聞くと、しばしばこんな答えが返ってくるのだ。「研究の用途？ それはわかりませんよ」―信じがたいことに、彼らには売れるものをつくるという目的がスッポリと抜け落ちているのだ。 自身も東大大学院で工学系を修了し、大手企
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
