チームでプロダクト開発するための取り組み/cookpadtechconf2017作りすぎない技術 - API時代の開発努力の在り方について考える / Thinking about the state of development efforts in the API era
効果的な 1 on 1 ミーティングのためにマネージャができること
2016 年に逝去した、元 Intel CEO の Andy Grove による High Output Management の日本語訳が復刊され、さらに Hard Things の Ben Horowitz の序文がついたことで、改めてスタートアップ界隈でも 1 on 1 (ワンオンワン) ミーティングの効果が注目され、各社や各人の 1 on 1 のノウハウが共有されるのではないかと期待しています。 Y Combinator の Sam Altman はスタートアップ初期でのコミュニケーションの重要性を何度も説いています。特にスタートアップは業務が複雑になりがちで、かつ状況の変化も早いため、コミュニケーションがボトルネックになりがちです。 コミュニケーションの遅れは意思決定の遅れにつながります。そして意思決定の遅れは事業の進捗を遅らせたり、トラブルの兆候を見逃してトラブル発生の原因にな
エンジニアの技術力評価は難しい? - 5年間運用してきた技術力評価制度の改善の歴史 ‒ / Regional SCRUM GATHERING Tokyo 2017
Jan 12, 2017 @ Regional SCRUM GATHERING Tokyo 2017
TeamGeek から学ぶマネジメント・アンチパターン13選 - Qiita
はじめに 今更ながらTeam Geekを読んでみたら良かったので、個人的に学びが多いと思った箇所をアンチパターンの形でまとめてみました。自分でやってしまった失敗に関係する内容がメインですが、メンバーとして嫌だなと思っていた部分もあります。 いくばくかのリーダー経験を経て(大半は失敗)、チームで結果を出す難しさと大切さを知った時期に、このような良書に出会えたことを感謝しつつ書きました。現在進行形でリーダーとしての働き方に悩まれている方や、これからリーダーになる方の一助となれば、そしてTeamGeekを手に取るきっかけとなれば幸いです。 内容について 冒頭にも書きましたが、以下すべて "アンチ" パターンです。(真似しちゃダメってやつですね) アンチパターンをやってしまうときのリーダーの頭の中を再現して書いてみました。(構成は自分の経験によって再編成しているのでTeamGeekのそれとは少し異
早くチームにマッチするために気をつけてる事 - そーだいなるらくがき帳
新入社員として1週間が過ぎた。 ブルックスの法則的に考えても私はまだチームにとって生産性をマイナスさせる存在でしかない。 ブルックスの法則 - Wikipedia だからいち早くチームにとって必要な存在になる必要があるし、そのために気をつけてる事をメモする。 これを見て「もっとコレした方がいいよ」ってアドバイス、逆に「それは不要だよ」ってアドバイスを期待してる。 チームやプロダクトを好きになる これはとても大切なことだ。 嫌いな人とは仲良くできないし、嫌いなプロダクトは育てれない。 もし、コレを読んでる人が職場のチームもプロダクトも嫌いなら転職した方がいい。 ただ好きの反対は無関心なので無関心の場合は条件付きでやっていけると思う。 この辺の話は主旨が変わるのでまた別の機会があれば話したい。 コミュニケーションについて 新しいチームに合流してまず一番大事なのはコミュニケーションコスト。 自分
これからマネージャーになるエンジニアのあなたへ - yashiganiの英傑になるまで死ねない日記
こんにちは、新米ディレクターのid:yashigani_wです。 この記事ははてなディレクターアドベントカレンダー2日目の記事です。昨日はid:moretのそろそろ5年生なので右も左もわからない新卒のころの自分にアドバイスする - el cineでした。 私は8月にアプリケーションエンジニアからディレクターになりました。 はてなではディレクター職には担当するサービスの成長に責任を持つプロダクトオーナーとしての役割と、担当するチームの成果を最大化するマネージャーとしての役割が求められます。 マネージャーというと、多くのエンジニアはあまりなりたがらないとおもいますが、それはマネージャーに求められる責任を具体的にイメージできないことや未知の仕事に対する不安からではないでしょうか？ この記事は私の経験から、これからマネージャーになるエンジニアに向けてマネージャーがまず意識すべきことと、最初に陥るで
人間を16タイプに分けよう。欧米で伝統的に使われる「MBTI」とは？ - まぐまぐニュース！
欧米で古い歴史を持つ性格診断テスト、「Myers–Briggs Type Indicator（通称MBTI）」は、個人はもちろんビジネスの現場においてもたびたび使用されています。しかし最近では、そのテストの信憑性を問う意見も出ているようです。あなたはこの性格診断テスト結果に賛成？ それとも反対？ 欧米で伝統的に使われている「MBTI」とは？ 「あなたの血液型は何ですか？」。 日本では性格の話をするときに血液型を持ち出すことが多いですね。 でもこれを海外の人に聞くと、「え、なんで？」と疑問に思われることがほとんど。 そもそも自分の血液型がわからない人もいますし、「なぜ、この人は初対面でそんなプライベートなことを聞いてくるのだろう」と、マナー違反と捉えられてしまうことさえあります。 そう、血液型を聞くことは、日本特有の習慣なのです。 欧米で血液型の代わりに多く使われている指針。 それは「Mye
【読書メモ】この1冊ですべてわかる コーチングの基本 | Yunicode
些細なことでもアウトプットしていこう〜とか言ってたのにだいぶ間が空いてしまいましたが久しぶりに読書メモ。新しいスキルとしてマネジメントを勉強中。 この1冊ですべてわかる コーチングの基本 感想本当に基礎の基礎から丁寧に書いてある本で、一年生の人は入門書として必読。 マネジメントというふわっとした形のわかりづらいものに対してなぜコーチングをするのか、どのようにするのか、というところから丁寧に解説がある。「相手にする質問でより効果の出そうな質問例はどんなものがあるか」など一通りの流れなど、具体的なアクションまで書かれているのですぐ実践に活かせそう。取り掛かりとしてはとてもよい本だったと思います。紹介していただけてよかった。 それにしてもマネジメント（コーチング）を実践するのって本で読むと、そりゃそうだろうな〜ってことも多いのだけど、実際にやろうとすると相手も自分も人間なのでそう簡単にはいかない
チームの良さを確認するためにやったこと - Web錯誤
この記事はProduct Manager Advent Calendar 2016の7日目の記事として書かれました。6日目の記事はgackyさんのおじさん Product Manager サバイバルガイドでした。 はじめまして。GMOペパボ株式会社でディレクターとして働いています。@jitsuzon です。弊社ペパボには「プロダクトマネージャー」という名称の職位や役職は存在しないため、自称プロダクトマネージャーとして、サービスのあれやこれやに関わっています。自称に至った経緯はこちらのスライドをご参考ください。 いきなりですが、みなさんのチームは「良いチーム」でしょうか？どこが良いのでしょう？どのくらい良いのでしょう？ この記事では、それをアンケートを用いて定量的に確認する方法について実践を元にお伝えしていきます。最近話題にのぼってくることも多い「心理的安全性」なんかも登場します。 背景 私
リーダーであるための視野・視座・視点 - Tech Inside Drecom
はじめに 十名～数十名ぐらいのプロジェクトで開発することの多いドリコムだが， プロジェクトの中に「プロジェクトリード職」という役割を置いている。 プロジェクトの実現性と健全性を担保するのが仕事だ。 ディレクター，プロダクトデザイン，プランナー，アート，エンジニアリーダーという風に 職種別のリード職を設けていて，エンジニアリーダーの場合はアーキテクチャや安定稼働， (技術的な) ユーザビリティ等への専門性を持って責任を負うのと，エンジニアチームの チーム作りもミッションに加えている。 最近は開発ライン数が増えてきたこともあり，新卒 2，3 年目のリード職が増えてきた。 リード職になった人に「一メンバーだった頃と何が違う？」と聞くと， よく「視野が広くなった」と返ってくる。 視野が広くなるとは具体的にどういうことなのか，掘り下げてみようと思う。 主に 2 年目エンジニア向けのエントリです。 仕
コードレビューをする話を新卒研修で話しました。 - パルカワ2
今いる会社には、新卒研修で座学と呼ばれるものがあって、先輩エンジニアがある程度好き勝手に話したいことを1時間ほど話す時間があります。 そんな最高の学習環境である座学で、コードレビューについて話してきました。 テーマは、 https://github.com/kenchan/keynote-theme を使いました。 内容についての補足 iOSとか出来ないので、そのあたりの説明が出来ない 最近コードレビュー全くしてない 相手によってはLGTM画像が嫌いな場合がある TPOがあるよね コンテキストが違う人にいきなりはキビシイ 海外の人にアニメ画像は使わないほうがよさそう 英語だと横向きの顔文字とかよく見る ;P 美女LGTM画像は会社で使ったことない スライド作る時に気をつけたこと 6個のステップ、3つの目的とか個数を言うようにした。 新卒氏たちに今やるべき事を認識してもらう 新卒氏たちにも出
どのようにしてマネージャーとしてのスキルを得てきたか - Qiita
この記事は、Pepabo Managers Advent Calendar 2016 の12日目の記事です。 11日目は、kwgcさんの「スニーカーについて」でした。 以下のような項目についてお話ができればと思います。 現在の立場について どのような経歴からマネージャー職になったか 足りないと思ったスキル 会計 面接 コーチング ファシリテーション プロダクト開発 それをどのような手段で身につけてきたか 本を読む 計画 実践 問題の発見 改善 (PDCA) 先輩マネージャーを見る 問題だったプロセスや気付き とにかく行うMTG 共通認識・理解 どのように解決したか、改善したか MTG 目的を決め、意思決定者を決める 共通認識・理解 徹底的に話す 新たに見つかった足りないスキル 最近考えていること 最後に 現在の立場について プロダクトに関わるマネージャーです。現在担当しているプロダクトは写
ひどい会議は上司のせい
会議がイマイチ盛り上がらない。若い部下が発言しない。いつまでもダラダラと時間がかかる─。会議に対する不満は、どの企業でも共通している。 「やれやれ。ウチの会議は全然良くならないよ」と思っている管理職の方たちも多いことだろう。そんな人にこそ、声を大にして言いたい。 「そのグダグダ会議、あなたのせいですよ!」 管理職ではなくても、部下や仲間を抱えるリーダーも同じだ。会議の出席者で1番立場が上の人が「会議の雰囲気を作る」のである。 普段の会議を思い出してほしい。重鎮のような人が仕切る会議は暗く、重くないだろうか。話好きで活発な人が仕切る会議は盛り上がるかもしれないが、総じて議論が発散しがちではないか。 良くも悪くも、影響力のある人、特に上司の振る舞い方一つで会議の質は決まってしまうのである。 もう一度、言おう。あなたのチームの会議の雰囲気は間違いなく、上司であるあなたが作っている。つまり、上司が
あなたのスキルは職人気質型？バランス型？コミュ型？
前回、現在の企業活動に必要な三つの要素として、パッション（情熱）、スキル、スモールチームを挙げた。社会的な課題を解決する情熱を持ち、実現に必要なスキルを身に付け、密接に働く小さなチームを組んでサービスを提供していく。これは、スタートアップ企業だけでなく、大企業でも製品やサービスの単位で当てはまる。 スモールチームを中心とした働き方がこれからのスタンダードになっていくだろう。こう考えたとき、個人としての行動をどう変えていったらよいのか。自分の意見を押し殺してでもチームに貢献すべきなのか。 それは違うだろう。チームの能力はあくまで個々のメンバーのスキルの上に成り立つものだ。パッションとスキルを持つ強いリーダーによって統率されるチームは、リーダーに依存する弱さも併せ持つ。しかし、短期決戦では強いとしても、中長期では継続性に難点がある。強いリーダー1人よりも、個々のメンバーが自らのパッションとスキ
技術採択のときにやるべきこと - まるまるこふこふ
初めに 新規プロジェクト／既存プロジェクトで、新しく使う ライブラリだったり、フレームワークだったり、ミドルウェアを選定してきた経験を通して、 採択する段階でこれはしておいた方がいいなという知見が溜まったので、 メモ書き程度に記述します。 前提として、技術採択についてある程度メンバーに裁量が任せられている風土があり、 かつミッションクリティカルでないシステムに導入する、また自社で事業を行っており、 顧客＝ユーザーであるというのがあります。 (この辺の前提条件が違う場合、採択に当たってまた別の観点が必要になってくると思います) システム要件を満たしているかどうか なんだかフワっとした言い方になりましたが、例えば Web システムに JavaScript のライブラリを 導入する場合に、Web システムが IE8 に対応するという要件ならば、 そのライブラリが、IE8 でも動くか調査するという
開発速度と品質のトレードオフの判断基準の合意 - Hatena Developer Blog
Webサービスの開発は、ユーザ/顧客へ価値を早く届けるため、競合より早くリリースするため、人的リソースを無駄使いしないためなど、とにかく素早く進めたいものですね。一方で、開発を急ぐあまり品質を犠牲にすればかえって価値が失われたり、技術的負債が溜まって長期的なコストが大幅に増大する可能性もあります。開発速度とプロダクト品質は基本的にはトレードオフの関係にあるのでしょう。 開発速度と品質のどちらを優先するかはプロダクトの性質や、チームもしくは会社の状況によって異なるとおもいます。この状況の認識がチームメンバー間でずれていると、チームのパフォーマンスを最大限に発揮できないばかりか、チーム内の関係悪化も招きかねません。エンジニアたちとプロダクトオーナーの間の対立のようなありがちな問題の原因の一つかもしれません。 そこで、開発速度と品質のトレードオフをどう判断すべきかの基準を明確にして、原則それに従
少人数のチームなので全員同じKPI担当にしたらサービスも組織も成長した話 | yusukehiruta.com
この記事は、Pepabo Managers Advent Calendar 2016の14日目の記事です。 13日目は、取締役兼EC事業部部長兼インターネット汁というポッドキャストで一緒にMCをしているホシハヤトさんの「山田くんと一緒に考える「組織の成長段階における最適なマネジメントとは？」〜 2016 年に購入してよかったものを添えて〜」でした！ はじめましての方からインターネット幼馴染まで、皆さんこんにちは、蛭田悠介（37歳）会社ではヒルティという可愛い呼び名で殺し屋のような顔面とのギャップ萌えだけで何とかここまでやっきた少し毒のある蠍座の男です。 ということで最近の私は何をしているかというとグーペというサービスのマネージャーをしています。 2016年のグーペ まずグーペを簡単に説明しますと、月額1,000円から誰でも簡単にホームページが作成できるウェブサービスです。 リリースは200
自律的なチームを作るために —組織心理学・臨床心理学の応用—
Japan Product Manager Conference 2016 の アンカンファレンスで発表させて頂いた内容です。 http://pmconf.jp/Read less
Japan Product Manager Conference 2016 に行ってきました - Tech Blog
はじめまして。Timersでプロダクトマネージャーしてます わた と申します。メガネとウイスキーとコーヒーを愛するメガネです。近々発売のニッカの60周年限定のブラックニッカ ブレンダーズスピリットが楽しみでなりません。 さて、突然ではありますが日本初のプロダクトマネージャーが一堂に集結するカンファレンスなるに参加してきましたので、報告ポストです。 pmconf.jp ちなみに、このカンファレンス、第一回の開催ながら、なんと400名を超える参加者が集まるという偉業っぷり。しかも、有償ですよ、このカンファレンス。すごいな。では、以下、レポートにはなっておりませんが「PMって何者？」的な観点で感想をまとめています。ご一読いただけると幸いです！ プロダクトマネージャーって、意外にたくさんいた 一言で云うと「日本にプロダクトマネージャーって、こんなにたくさんいるんだ！」ってことでした。フタを開けてみ
君のチームに「構造」はあるか？ 伊藤直也が語る、学びが蓄積されるマネジメント
2016年8月30日、これまで2社のCTOと5社の技術顧問を経験してきた一休の伊藤直也氏による「1人CTO Night」が開催されました。主催は転職サイト「DODA」を運営する、株式会社インテリジェンス。開発知識に加え、マネジメントスキルも求められるプロダクトマネージャーが最速・最高のアウトプットを生み出すにはどうすればいいのでしょうか。本パートでは、伊藤氏が過去の実例から「学習結果が蓄積されるマネジメント」について語りました。 「CTO」と「VP of Engineering」 伊藤直也氏（以下、伊藤）：「1人CTO Night」というちょっとキャッチーな名前のイベントですが（笑）、さっそく始めさせていただきます。一休の伊藤です。 今日は「一休の伊藤」というかたちで出ていますが、あまり自社の宣伝をしてもしょうがないので、過去に技術顧問をやってきた時の経験などを含めて「いろいろな会社でこう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
