エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita
本記事は、Engineering Manager Advent Calenderの１日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ
新しくプロダクト開発に入ったときにやっていること | wapa5pow blog
年度が代わり新しい環境に行く人も多いですね。新しい環境・プロダクトだといろいろ戸惑うことがあります。自分は数年ごとに転職し、副業も複数のところでしているので初めての環境に関わることが結構あります。そのなかで素早くチームになじんでプロダクトに貢献できるようにやっていることがあるのでそれを紹介したいと思います。 自分がウェブやアプリのエンジニアなのでその文脈で話します。 「プロダクトのあるべき姿と現状を把握する」と「短期的・長期的に貢献できることを探す」ことを意識してやっています。 プロダクトのあるべき姿と現状を把握する 関わるプロダクトがユーザの何を解決しているのか理解することは開発する上で非常に大切です。機能を開発する上でもただ開発するだけでなくその機能自体が必要なのかどうか、必要ならどのような機能にすればユーザが問題を解決しやすいかという何を開発するかに密接にかかわっています。 1. ア
「挑戦させすぎ？」マネジメント勉強会で分かった組織課題とその解決策 - ZOZO TECH BLOG
こんにちは、ZOZOテクノロジーズSREチームリーダー兼組織開発チーム所属の指原(@sashihara_jp)です。 この記事では2019年12月から全11回開催してきた「マネジメント勉強会」を通じて分かってきたZOZOテクノロジーズの組織課題と、これから取り組もうとしているその解決方法を紹介します。 ZOZOテクノロジーズの社員構成 マネジメント勉強会とは 立ち上げまでの道のり 運営メンバーの勧誘 経営層への企画提案 勉強会の命名 1年間で実施したテーマ 第1回 各チームで実施しているチームビルディング施策の共有 第2回 書籍「1on1マネジメント」を読んだ上で内容について議論 第9回 採用面接で質問している内容について意図と効果共有 マネジメント勉強会を通じて分かってきたZOZOテクノロジーズの現状 1.組織の急拡大による弊害 2.現場のコンフリクト 3.マネジメントと人材育成 組織開
プロダクトマネジメント入門: 失敗しないプロダクトの作り方を学ぼう
Founder Customer Fitこのセクションについて解決したい課題を見つけよう顧客を決めようリーンキャンバスを書こうミッションを決めようCustomer Problem Fitこのセクションについてペルソナを立てよう共感マップをつくろうカスタマージャーニーマップをつくろう課題仮説を整理しようプロブレムインタビューをしようProblem Solution FitこのセクションについてPEST分析をしようフックモデルを定義しようプロトタイプをつくろう解決策仮説を整理しようソリューションインタビューをしようSolution Product Fitこのセクションについて名前をつけようユーザーストーリーマップをつくろうMVPを構築しようMVP仮説を整理しようMVPインタビューをしようProduct Market Fitこのセクションについてグロースサイクルを定義しよう利用規約をつくろうプロ
Google re:Work - マネージャー
イノベーション イノベーションを起こすためのスキルを習得し、業務に活かす方法を学びます。
Rubyの父、まつもとゆきひろもマネジメントで大失敗！？そこから学んだ“苦手をあえて克服しない”戦略 - エンジニアtype | 転職type
本連載では、「世の中で活躍するエンジニアの過去の失敗」にフォーカス。どのような失敗をし、どう対処し、そこから何を学んだのか。仕事で失敗してしまった時の対処法や心構えを先輩エンジニアから学ぼう！ 本連載、第２回目となるゲストは、オブジェクト指向スクリプト言語「Ruby」の生みの親として知られる、まつもとゆきひろさん。世界中のプログラマーから尊敬を集めるまつもとさんは、過去の「失敗」や「挫折」から何を学び、どうやって優れた仕事に昇華してきたのだろうか。これまでの開発者人生を振り返ってもらいながら紐解いていく。 まつもとゆきひろ さん (@yukihiro_matz) 1965年生まれ。筑波大学第三学群情報学類卒業。プログラミング言語Rubyの生みの親。株式会社ネットワーク応用通信研究所フェロー、一般財団法人Rubyアソシエーション理事長、Speeeをはじめとした複数社の技術顧問、Herokuチ
エンジニアリングマネージャを退いた話 - Qiita
この記事は、Engineering Manager Advent Calendar 2018の06日目のエントリーです。 Engineering Manager Advent Calendar 2018 2016年某月からリーダー相当となり、さらに2018年04月から半年間、開発チームのマネージャとしてやってきた。しかしやり続けても成果を出す自信も、そもそもこれがやりたいことなのかという疑問もあったことと、なによりちょうどよくそれを託すに値する人がリファラル採用によって獲得できそうということが偶然にも重なり、マネジメントをやめたいと経営者に伝えたのが2018年10月。 そしていま現在、件の人にマネジメントしていただいており、これが機能していて、これがマネジメントなのかということを感じている。振り返るに自分には何が足りなかったか、マネジメントとは具体的になにをすることだったのか、ということを
マネージャーが負うべき責任と役割とは？ 3人のリーダーが“強いエンジニアリング組織”の作り方を語る
各分野で活躍するプロフェッショナルを講師として招く、クライス＆カンパニー主催のセミナー＆交流会「汐留アカデミー」。今回は、Googleでエンジニアリングマネージャを担当した後、Incrementsにて「Qiita」などのプロダクトマネージメントを担当してきた及川卓也氏をモデレータに、情報共有ツール「Kibela」の開発をしながら複数企業の技術顧問も兼務する株式会社ビットジャーニーの井原正博氏、CTO、テックリード、プロダクトマネージャとして一人三役を兼ねる株式会社ニューズピックスの杉浦正明氏をゲストに迎えます。「強いエンジニアリング組織をつくる」というテーマで、エンジニアの組織作りやマネジメントについて考察します。 エンジニアのマネジメントと組織づくり 及川卓也氏（以下、及川）：今日のファシリテーターを務めさせていただきます、及川です。よろしくお願いいたします。 （会場拍手） 今日はこの「
広告プラットフォーム立ち上げ百鬼夜行
JJUG CCC 2015 Spring の発表資料。 --------------------------------------------------------------------------------- 私は2014年にITベンチャーにエンジニアとして入社しました。 理系の大学院出身でしたが、学生時代はとにかくプログラミングから逃げるように過ごしてきました。 入社後の研修ではJavaでif文やfor文の書き方を学んでいたという見事な初心者っぷり。 そんなJava初心者の私が、2ヶ月でwebサービスを開発し、公開するというプロジェクトにチャレンジしました。 数々の困難を乗り越え、何とか「ニクリーチ2016」というwebサービスを公開。 当セッションでは 入社後どのような研修を受けたのか ニクリーチ2016ではどのような技術を使ったのか 一人開発プロジェクトを通して感じたこと
優れたエンジニアが集まり継続的に成長する会社にする方法 ～組織を急拡大させる採用育成評価ガイド～/Concise Guide to Finding the Best Technical Talent
CEDEC2017「優れたエンジニアが集まり継続的に成長する会社にする方法 ～組織を急拡大させる採用育成評価ガイド～」講演資料です。
プロジェクトリーダーとプロジェクトマネージャーの違い、あるいは会社にとって死活的に大事なのはどちらか？：プロジェクトマジック：オルタナティブ・ブログ
プロジェクトリーダーとプロジェクトマネージャーの違い、あるいは会社にとって死活的に大事なのはどちらか？ 2015年12月に「会社のITはエンジニアに任せるな」という本を出した。 「経営にとって、ITとは？」がテーマの本なので、「ITを担わせる人材をどう育てるべきか？」という章をもうけたのだが、意外だったのは、「プロジェクトリーダーとプロジェクトマネージャーの違い」という短いコラムへの反応が多かったことだ。 実は用語の混乱を避けるために書いただけなのだが、結構本質的な問いかけも混ざっている。この記事で、少し掘り下げてみたい。 ※以下、プロジェクトマネージャー⇒PM、プロジェクトリーダー⇒PLと表記する ★何が混乱の元なのか？ 大きめのプロジェクトだと、たいてい体制図が作られ、色んなカタカナの役職の人が登場する。ただ、この手の役職名は会社ごとに定義がマチマチなので、毎回関係者間で「これって結局
どのようにエンジニアの目標設定を行うか - $shibayu36->blog;
以前 ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。 しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。 僕がメンティーと目標設定を行うときは、以下のフローを辿っている。 なんでも良いのでゴールのイメージを明確にする 現在の自分とゴールのイメージのギャップを考える ギャップを埋める目標を考え、アクションを定める ちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。 なんでも良いのでゴールのイメージを明確にする
Rebuild: 123: The Grail Dialogue (Naoya Ito)
Naoya Ito さんをゲストに迎えて、Rails 5, 聖杯問答、サーヴァントリーダー、マネジメント、キャリアパス、自由などについて話しました。 Show Notes Rebuild: 121: Ruby Is Not Dying, Not Yet (Laurent Sansonetti) Rebuild: 122: The Metal Is Dead (tenderlove) Rebuild Supporter Program Rails 5.0.0.beta1 rails-api/active_model_serializers Fate/Zero Servant leadership Rebuild: Aftershow 71: Green Grass On GitHub (Naoya Ito) サーバントリーダーシップ 自由をつくる 自在に生きる: 森博嗣 Fate/Zero
計画する技術 - kakakakakku blog
今日は社内勉強会で「計画する技術」というタイトルで発表をした． 前から少し「計画」のところに課題感があって，そのあたりの知識を組織に広めて欲しいというオーダーもあったため，僕が日々考えていることを言語化して，発表することにした．僕は今までに様々な「計画」の経験があり，実際に今の組織でも難易度の高いプロジェクトを何度も計画し，遂行してきたため，「計画」に対する信頼残高は増えているのではないかと思う． 発表資料 意識したこと 今回，発表資料を作るときに意識したことが2個あった．他にも話したいことはたくさんあったけど，組織マネジメントの話はまた別でしようと思って，あくまで「計画」に特化した話にした． 明日からすぐに使える話をする 開発プロセスに依存しない話をする 1. 明日からすぐに使える話をする 原理原則すぎる話や，難しい法則の話は控えるようにした．そういう話をしてしまうと，その場では「おー，
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プロダクトマネジメントとは[新卒研修] - Speaker Deck![プロダクトマネジメントとは[新卒研修] - Speaker Deck](https://cdn-ak-scissors.b.st-hatena.com/image/square/d7f1eac2c9f48e259d61ec8bfd9699a61d2d7044/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F244088756e884ccf9ef250c495915682%2Fslide_0.jpg%3F10000184)
Google：マネージャはやはり重要な存在である