良いチームとは「何でないか」 - Yamotty Blog
2017 - 01 - 20 良いチームとは「何でないか」 プロダクト-プロダクトマネージャー 「良いチームとは何か？」 という質問を投げかけると、答えが多様にわたり、同じチームに所属していたとしても認識が全く揃わないことはザラである。 アメフトチームをコーチしていた時。この組織の目的は驚くほど明確で「全ての試合に勝つこと」以外に存在しない。と、僕は思っていたが、チーム全員（100名超）との1on1を行うと 「職場での評価が上がる」 「仲間との関係」 「〜に憧れている」 などの、「勝利」と直結しない所属動機が浮き彫りになった。また仕事におけるチームでも、同様の質問を投げかけると 「会社に来るのが楽しいこと」 「コミュニケーションがスムーズ」 「お互いが尊重し合える」 など、必ずしもチームが達成を目指す成果に結びついていない回答が殆どであったりする。このことから、 良いチームを定義するのは簡
効果的な 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のそれとは少し異
「優先すべきはスピードと柔軟さ」LINE開発チームが今も配属を固定しない理由を、上級執行役の池邉智洋氏に聞く - エンジニアtype | 転職type
転職・求人情報サイトのtype エンジニアtype 転職 「優先すべきはスピードと柔軟さ」LINE開発チームが今も配属を固定しない理由を、上級執行役の池邉智洋氏に聞く 2017.01.11 転職 組織には規模に合った適正な運営方法というものがある。サービスが拡大し、それを支えるエンジニアの人数が増えれば、最適な開発の進め方や体制も変わるというのが一般的な考え方ではないだろうか。 しかし、そうした”常識”が当てはまらないケースもあるというのが、今回の記事のテーマだ。 月に世界2億人超が使っているメッセンジャーアプリ『LINE』の他にも、ゲームやeコマース、漫画など多種多様なアプリサービスを提供するLINEの開発チームが、明確な業務分担をせずに事業開発にあたっているというのは、2014年に本誌でもお伝えした通り（以下リンク）。 >> LINE開発の“新2トップ”に直撃～世界展開に向けた体制強化
早くチームにマッチするために気をつけてる事 - そーだいなるらくがき帳
新入社員として1週間が過ぎた。 ブルックスの法則的に考えても私はまだチームにとって生産性をマイナスさせる存在でしかない。 ブルックスの法則 - Wikipedia だからいち早くチームにとって必要な存在になる必要があるし、そのために気をつけてる事をメモする。 これを見て「もっとコレした方がいいよ」ってアドバイス、逆に「それは不要だよ」ってアドバイスを期待してる。 チームやプロダクトを好きになる これはとても大切なことだ。 嫌いな人とは仲良くできないし、嫌いなプロダクトは育てれない。 もし、コレを読んでる人が職場のチームもプロダクトも嫌いなら転職した方がいい。 ただ好きの反対は無関心なので無関心の場合は条件付きでやっていけると思う。 この辺の話は主旨が変わるのでまた別の機会があれば話したい。 コミュニケーションについて 新しいチームに合流してまず一番大事なのはコミュニケーションコスト。 自分
オープンソースプロジェクトとの距離のとりかた
オープンソースプロジェクトに参加したいな、と思った時、まず最初に問題だと感じるのは英語だと思う。構成員が日本人だけで、日本人に向けてのみ出しているそソフトウェアでない限り、プロジェクトの共通語はふつう英語だ。植山さんの記事には英語で物事を進めることの利点が体験談とともに書かれている。他の記事にも、オープンソースプロジェクトで上手いことやっていくためのひとつとして英語の話が出てくる。一方、英語のせいで参加したくても二の足を踏んでしまう、というのもよく聞く話だ。結論から言ってしまうと、やっぱり読み書きだけでも習得しないと話に入っていくのは難しい。ソフトウェア開発者の多くは多様性に対して寛容なので、英語が不得意という理由で拒絶されることはないだろう。ただ、特別な配慮もしてくれない。 しかし英語の前に、プロジェクトとの距離のとりかたを学ぶべきだと思う。いままでわたしが見てきたり、自分自身がやって良
これからマネージャーになるエンジニアのあなたへ - yashiganiの英傑になるまで死ねない日記
こんにちは、新米ディレクターのid:yashigani_wです。 この記事ははてなディレクターアドベントカレンダー2日目の記事です。昨日はid:moretのそろそろ5年生なので右も左もわからない新卒のころの自分にアドバイスする - el cineでした。 私は8月にアプリケーションエンジニアからディレクターになりました。 はてなではディレクター職には担当するサービスの成長に責任を持つプロダクトオーナーとしての役割と、担当するチームの成果を最大化するマネージャーとしての役割が求められます。 マネージャーというと、多くのエンジニアはあまりなりたがらないとおもいますが、それはマネージャーに求められる責任を具体的にイメージできないことや未知の仕事に対する不安からではないでしょうか？ この記事は私の経験から、これからマネージャーになるエンジニアに向けてマネージャーがまず意識すべきことと、最初に陥るで
人間を16タイプに分けよう。欧米で伝統的に使われる「MBTI」とは？ - まぐまぐニュース！
欧米で古い歴史を持つ性格診断テスト、「Myers–Briggs Type Indicator（通称MBTI）」は、個人はもちろんビジネスの現場においてもたびたび使用されています。しかし最近では、そのテストの信憑性を問う意見も出ているようです。あなたはこの性格診断テスト結果に賛成？ それとも反対？ 欧米で伝統的に使われている「MBTI」とは？ 「あなたの血液型は何ですか？」。 日本では性格の話をするときに血液型を持ち出すことが多いですね。 でもこれを海外の人に聞くと、「え、なんで？」と疑問に思われることがほとんど。 そもそも自分の血液型がわからない人もいますし、「なぜ、この人は初対面でそんなプライベートなことを聞いてくるのだろう」と、マナー違反と捉えられてしまうことさえあります。 そう、血液型を聞くことは、日本特有の習慣なのです。 欧米で血液型の代わりに多く使われている指針。 それは「Mye
チームの良さを確認するためにやったこと - Web錯誤
この記事はProduct Manager Advent Calendar 2016の7日目の記事として書かれました。6日目の記事はgackyさんのおじさん Product Manager サバイバルガイドでした。 はじめまして。GMOペパボ株式会社でディレクターとして働いています。@jitsuzon です。弊社ペパボには「プロダクトマネージャー」という名称の職位や役職は存在しないため、自称プロダクトマネージャーとして、サービスのあれやこれやに関わっています。自称に至った経緯はこちらのスライドをご参考ください。 いきなりですが、みなさんのチームは「良いチーム」でしょうか？どこが良いのでしょう？どのくらい良いのでしょう？ この記事では、それをアンケートを用いて定量的に確認する方法について実践を元にお伝えしていきます。最近話題にのぼってくることも多い「心理的安全性」なんかも登場します。 背景 私
リーダーであるための視野・視座・視点 - Tech Inside Drecom
はじめに 十名～数十名ぐらいのプロジェクトで開発することの多いドリコムだが， プロジェクトの中に「プロジェクトリード職」という役割を置いている。 プロジェクトの実現性と健全性を担保するのが仕事だ。 ディレクター，プロダクトデザイン，プランナー，アート，エンジニアリーダーという風に 職種別のリード職を設けていて，エンジニアリーダーの場合はアーキテクチャや安定稼働， (技術的な) ユーザビリティ等への専門性を持って責任を負うのと，エンジニアチームの チーム作りもミッションに加えている。 最近は開発ライン数が増えてきたこともあり，新卒 2，3 年目のリード職が増えてきた。 リード職になった人に「一メンバーだった頃と何が違う？」と聞くと， よく「視野が広くなった」と返ってくる。 視野が広くなるとは具体的にどういうことなのか，掘り下げてみようと思う。 主に 2 年目エンジニア向けのエントリです。 仕
社員の育成・スキル向上と真剣に向き合う
はじめに みなさん、こんにちは。この連載は、日本のIT産業を支えるSIerが本来の魅力あふれる仕事をして、ユーザーに感謝され、諸外国のようにITエンジニアが憧れの職業と思われる、そんな復活を果たすための応援メッセージです。耳に痛いようなことも提言しますが、私自身もIT業界の一員として試行錯誤しながら経営しているので、一緒に考えて改革していければと思っています。 「会社の改革のためのその4」―社員の育成・スキル向上と真剣に向き合う ここで、これまでに「会社の改革のために」提言してきたことをおさらいしましょう。 その1 「KPI管理を導入する」 その2 「社員の定着率をアップする」 その3 「合理化・効率化のために先行投資をする」 社員の育成やスキル向上を口先だけにしない。そのためにKPIを設定して、定着率を監視し、必要な先行投資をする、ということを前ふりとして論じてきたわけです。 今回は、本
コードレビューをする話を新卒研修で話しました。 - パルカワ2
今いる会社には、新卒研修で座学と呼ばれるものがあって、先輩エンジニアがある程度好き勝手に話したいことを1時間ほど話す時間があります。 そんな最高の学習環境である座学で、コードレビューについて話してきました。 テーマは、 https://github.com/kenchan/keynote-theme を使いました。 内容についての補足 iOSとか出来ないので、そのあたりの説明が出来ない 最近コードレビュー全くしてない 相手によってはLGTM画像が嫌いな場合がある TPOがあるよね コンテキストが違う人にいきなりはキビシイ 海外の人にアニメ画像は使わないほうがよさそう 英語だと横向きの顔文字とかよく見る ;P 美女LGTM画像は会社で使ったことない スライド作る時に気をつけたこと 6個のステップ、3つの目的とか個数を言うようにした。 新卒氏たちに今やるべき事を認識してもらう 新卒氏たちにも出
MTG力を上げよう
弊社の新卒向けに発表した勉強会のスライド。 かく言うわたくしもまだ新卒二年目でございまする。。Read less
どのようにしてマネージャーとしてのスキルを得てきたか - Qiita
この記事は、Pepabo Managers Advent Calendar 2016 の12日目の記事です。 11日目は、kwgcさんの「スニーカーについて」でした。 以下のような項目についてお話ができればと思います。 現在の立場について どのような経歴からマネージャー職になったか 足りないと思ったスキル 会計 面接 コーチング ファシリテーション プロダクト開発 それをどのような手段で身につけてきたか 本を読む 計画 実践 問題の発見 改善 (PDCA) 先輩マネージャーを見る 問題だったプロセスや気付き とにかく行うMTG 共通認識・理解 どのように解決したか、改善したか MTG 目的を決め、意思決定者を決める 共通認識・理解 徹底的に話す 新たに見つかった足りないスキル 最近考えていること 最後に 現在の立場について プロダクトに関わるマネージャーです。現在担当しているプロダクトは写
ひどい会議は上司のせい
会議がイマイチ盛り上がらない。若い部下が発言しない。いつまでもダラダラと時間がかかる─。会議に対する不満は、どの企業でも共通している。 「やれやれ。ウチの会議は全然良くならないよ」と思っている管理職の方たちも多いことだろう。そんな人にこそ、声を大にして言いたい。 「そのグダグダ会議、あなたのせいですよ!」 管理職ではなくても、部下や仲間を抱えるリーダーも同じだ。会議の出席者で1番立場が上の人が「会議の雰囲気を作る」のである。 普段の会議を思い出してほしい。重鎮のような人が仕切る会議は暗く、重くないだろうか。話好きで活発な人が仕切る会議は盛り上がるかもしれないが、総じて議論が発散しがちではないか。 良くも悪くも、影響力のある人、特に上司の振る舞い方一つで会議の質は決まってしまうのである。 もう一度、言おう。あなたのチームの会議の雰囲気は間違いなく、上司であるあなたが作っている。つまり、上司が
あなたのスキルは職人気質型？バランス型？コミュ型？
前回、現在の企業活動に必要な三つの要素として、パッション（情熱）、スキル、スモールチームを挙げた。社会的な課題を解決する情熱を持ち、実現に必要なスキルを身に付け、密接に働く小さなチームを組んでサービスを提供していく。これは、スタートアップ企業だけでなく、大企業でも製品やサービスの単位で当てはまる。 スモールチームを中心とした働き方がこれからのスタンダードになっていくだろう。こう考えたとき、個人としての行動をどう変えていったらよいのか。自分の意見を押し殺してでもチームに貢献すべきなのか。 それは違うだろう。チームの能力はあくまで個々のメンバーのスキルの上に成り立つものだ。パッションとスキルを持つ強いリーダーによって統率されるチームは、リーダーに依存する弱さも併せ持つ。しかし、短期決戦では強いとしても、中長期では継続性に難点がある。強いリーダー1人よりも、個々のメンバーが自らのパッションとスキ
エンジニア立ち居振舞い: ルーズボールを拾う - @kyanny's blog
お題「エンジニア立ち居振舞い」 チャットや課題管理システムを使って非同期コミュニケーションをしていると、誰かに向けて発せられたけど誰も応答していない、ルーズボールのようなメッセージができてしまう。こういうのを見かけたら、できるだけ拾うようにしている。 Quipper の Slack には #development という公開チャンネルがある。開発者が開発にまつわる話をする場で、開発者向けの #general チャンネルといった位置づけだ（なお、開発者向けの #random に相当する #slackoverflow というチャンネルもある） #development は公開チャンネルなので、開発者だけでなく、営業・マーケティング・カスタマーサポートなどの部門で働く人たちも参加している。時折、彼らがシステムのことで何か困っていて、開発者の手助けが必要なことがある。そういうとき、誰でも構わないか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チームとプロダクトをぶっ壊した話
チームでプロダクト開発するための取り組み/cookpadtechconf2017
