CEDEC2017「優れたエンジニアが集まり継続的に成長する会社にする方法 ~組織を急拡大させる採用育成評価ガイド~」講演資料です。
CEDEC2017「優れたエンジニアが集まり継続的に成長する会社にする方法 ~組織を急拡大させる採用育成評価ガイド~」講演資料です。
By OnInnovation オンライン決済サービス「PayPal」の母体を作り、世界で最も成功しているEVメーカー「テスラ」の創設、民間宇宙開発のトップをひた走る「スペースX」を立ち上げた経歴を持つイーロン・マスク氏の成功はこれらにとどまらず、超高速交通網を開発する「ハイパーループ」、都市の地下にトンネル網を張り巡らせる「Boring Company」などの構想をうち立てるなど、そのアイデア力と経営手腕は非常に高いものがあります。そんなマスク氏が数年前にテスラの従業員宛に送ったというメールには、組織としての強靱な体力を実現するために必要な社内コミュニケーションの在り方が雄弁に語られています。 This Email From Elon Musk to Tesla Employees Describes What Great Communication Looks Like | Inc.c
2017年7月21日(金)DevLOVE関西「心理的安全性」のことに思いを馳せてみるにて。
2017 - 01 - 20 良いチームとは「何でないか」 プロダクト-プロダクトマネージャー 「良いチームとは何か?」 という質問を投げかけると、答えが多様にわたり、同じチームに所属していたとしても認識が全く揃わないことはザラである。 アメフトチームをコーチしていた時。この組織の目的は驚くほど明確で「全ての試合に勝つこと」以外に存在しない。と、僕は思っていたが、チーム全員(100名超)との1on1を行うと 「職場での評価が上がる」 「仲間との関係」 「〜に憧れている」 などの、「勝利」と直結しない所属動機が浮き彫りになった。また仕事におけるチームでも、同様の質問を投げかけると 「会社に来るのが楽しいこと」 「コミュニケーションがスムーズ」 「お互いが尊重し合える」 など、必ずしもチームが達成を目指す成果に結びついていない回答が殆どであったりする。このことから、 良いチームを定義するのは簡
はじめに 今更ながらTeam Geekを読んでみたら良かったので、個人的に学びが多いと思った箇所をアンチパターンの形でまとめてみました。自分でやってしまった失敗に関係する内容がメインですが、メンバーとして嫌だなと思っていた部分もあります。 いくばくかのリーダー経験を経て(大半は失敗)、チームで結果を出す難しさと大切さを知った時期に、このような良書に出会えたことを感謝しつつ書きました。現在進行形でリーダーとしての働き方に悩まれている方や、これからリーダーになる方の一助となれば、そしてTeamGeekを手に取るきっかけとなれば幸いです。 内容について 冒頭にも書きましたが、以下すべて "アンチ" パターンです。(真似しちゃダメってやつですね) アンチパターンをやってしまうときのリーダーの頭の中を再現して書いてみました。(構成は自分の経験によって再編成しているのでTeamGeekのそれとは少し異
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
コンテンツブロックが有効であることを検知しました。 このサイトを利用するには、コンテンツブロック機能(広告ブロック機能を持つ拡張機能等)を無効にしてページを再読み込みしてください。 ✕
この記事は、はてなディレクターアドベントカレンダー2016の17日目のエントリです。(昨日は id:daiksy の『嫌われない勇気』でした。) id:motemen です。過去には立ち上げ期の Mackerel チームのディレクターをしていましたが、当時のことは 過去の記事 にあるとおりで、あまりディレクターとしてほかに書けることもないので違う話を。 今年のはじめごろに エンジニアの専門性を伸ばすためにディレクターに気をつけてほしい3つのこと - Hatena Developer Blog という記事が書かれましたが、これはディレクターからエンジニアに向けた話だったのでこれの逆バージョンを書いてみようと思います。 先に書いておくと、ぼくは新卒ではてなに入社し、ディレクターの id:nmy さん(アドベントカレンダー最終日)や id:chris4403 さん(アドベントカレンダーのエントリ
はじめに 十名~数十名ぐらいのプロジェクトで開発することの多いドリコムだが, プロジェクトの中に「プロジェクトリード職」という役割を置いている。 プロジェクトの実現性と健全性を担保するのが仕事だ。 ディレクター,プロダクトデザイン,プランナー,アート,エンジニアリーダーという風に 職種別のリード職を設けていて,エンジニアリーダーの場合はアーキテクチャや安定稼働, (技術的な) ユーザビリティ等への専門性を持って責任を負うのと,エンジニアチームの チーム作りもミッションに加えている。 最近は開発ライン数が増えてきたこともあり,新卒 2,3 年目のリード職が増えてきた。 リード職になった人に「一メンバーだった頃と何が違う?」と聞くと, よく「視野が広くなった」と返ってくる。 視野が広くなるとは具体的にどういうことなのか,掘り下げてみようと思う。 主に 2 年目エンジニア向けのエントリです。 仕
この記事はProduct Manager Advent Calendar 2016の7日目の記事として書かれました。6日目の記事はgackyさんのおじさん Product Manager サバイバルガイドでした。 はじめまして。GMOペパボ株式会社でディレクターとして働いています。@jitsuzon です。弊社ペパボには「プロダクトマネージャー」という名称の職位や役職は存在しないため、自称プロダクトマネージャーとして、サービスのあれやこれやに関わっています。自称に至った経緯はこちらのスライドをご参考ください。 いきなりですが、みなさんのチームは「良いチーム」でしょうか?どこが良いのでしょう?どのくらい良いのでしょう? この記事では、それをアンケートを用いて定量的に確認する方法について実践を元にお伝えしていきます。最近話題にのぼってくることも多い「心理的安全性」なんかも登場します。 背景 私
こんにちは、新米ディレクターのid:yashigani_wです。 この記事ははてなディレクターアドベントカレンダー2日目の記事です。昨日はid:moretのそろそろ5年生なので右も左もわからない新卒のころの自分にアドバイスする - el cineでした。 私は8月にアプリケーションエンジニアからディレクターになりました。 はてなではディレクター職には担当するサービスの成長に責任を持つプロダクトオーナーとしての役割と、担当するチームの成果を最大化するマネージャーとしての役割が求められます。 マネージャーというと、多くのエンジニアはあまりなりたがらないとおもいますが、それはマネージャーに求められる責任を具体的にイメージできないことや未知の仕事に対する不安からではないでしょうか? この記事は私の経験から、これからマネージャーになるエンジニアに向けてマネージャーがまず意識すべきことと、最初に陥るで
この記事は、Pepabo Managers Advent Calendar 2016の3日目の記事です。2日目は、弊社チーフエンジニアhsbtさんの「マネージャが仕事の仕組みを作る」でした。 僕自身は、エンジニア専門職の主席研究員兼シニア・プリンシパルエンジニアではありますが、特にペパボ福岡のエンジニア組織を現場でまとめる人間として、エンジニア組織を成長させる中で個々のエンジニアの成長をサポートしているという意味では、マネージメントに関する活動も兼ねております。 しばしば、インターネットサービスの高度化と複雑化の速度が早過ぎるため、グランドデザインができない、人が多過ぎても成立しない、少な過ぎても難しい、とういうような類のサービスを作り上げないといけない状況があります。その際に、厳密過ぎない役割を持たせ、それぞれが横断的にそれぞれのスタイルで、まるで、攻殻機動隊の世界におけるスタンドプレー
2016年10月15日、「AbemaTV」を支えるUIデザイナーやエンジニアの技術的な知見が共有される「AbemaTV Developer Conference2016」が行われました。同サービスのような新規開発プロジェクトには優秀な人材は必要不可欠。そこで課題となるのが「属人化」です。AbemaTVでは、属人化という課題をどのようにクリアしたのでしょうか。本パートでは、立ち上げから運用までの開発スタイルについて、同社エンジニアである大﨑浩崇氏が語りました。 AbemaTVとFRESH!の開発スタイル 司会者:ではAbemaTVの開発スタイルについて、大﨑さんからお話いただきます。よろしくお願いします。 (会場拍手) 大﨑浩崇氏(以下、大﨑):それではAbemaTVの開発スタイルについて、僕から発表させていただきたいと思います。 まず、自己紹介からいきますね。大﨑と言います。 2015年4
by sid 「昼から夕方の6時間労働がクリエイティブな仕事には重要」など、仕事において人がアイデアを出し、イノベーションを起こすために必要なものについては色んな説があります。一方で、「仕事」ではなく「仕事場」において重要なのは個人の資質ではなく、「心理的安全性」であると説いているのが世界で最も影響力のあるビジネス思想家に選ばれている世界的な経営学者Amy Edmondson教授。Edmondson教授はスピーチフォーラムのTEDで、心理的安全性がないとどのような事態を招くのか、そして職場が心理的安全性を得るにはどうすればいいのかを語っています。 Building a psychologically safe workplace: Amy Edmondson at TEDxHGSE - YouTube Edmondson教授が語ったのは、まず以下の3つのエピソード。 「ある都会のせわしない
code_review_basics.md コードレビューの基本 一番大事な事 ソースコードはプロジェクトの共同所有物である 誰かだけが触れるコードを無くす 自分だけが持っているコードを無くす 自分だけが触っている時間を短くする コードレビューで大事な事 コードレビューは... 相互学習型のプロセスである メンバが成長することが大事 相互学習とは レビュアーとレビュイーが、お互い学び合うこと 考え方を共有すること 質問することで学ぼう 一番できる誰かだけが教えるのではない 知識や経験の少ない人が何に躓いているのか学ぼう メンバの成長 同じミスをチーム内で繰り返さないことが成長 ミスを繰り返さないために 本人の問題にしない 明日はわが身 仕事の正しい手順を覚えよう 道具の正しい使い方を覚えよう コードレビューの心構え 伝えることが大事 改善するまでがレビュー レビューにコストをかけ過ぎない
最近は、ソフトウェアの新しい技術や、考え方の日本に対する導入の遅れをどうやったら無くすことができるか?ということを考えている。今回はインターナショナルチームに参加して感じたマネジメントスタイルの違いについて書いてみたい。 海外企業のリーダーシップスタイルの変化 ソフトウェアの世界では、2001年にアジャイル開発が登場以来、それ以降のパラダイムでは、「サーバントリーダーシップ」と呼ばれるタイプのマネジメントスタイルが主流になっている。 従来型のスタイルは「コマンドアンドコントロール」というスタイルで、リーダーが部下に指示をし、リーダーは部下の状況を把握、確認し、管理していく。一方、サーバントリーダーシップの場合、リーダーは、ビジョンとKPIを示すが、実際にどのようにするかは、チームが自ら考えて意思決定していく。 この考え方は、既に1969年に発表されているらしいというのを下記の本で知った。
チームワークというのは、全体が力を合わせることで、個々の持つ以上の力を発揮することです。6人が個別に働いたほうが、6人で一緒に働くよりも生産性が高いのであれば、チームである必要はありません。 しかし、実際に複数人で長い時間働いたことがある人と話すと、必ずしもそのような相互作用が起こるわけではないことは、すぐにわかります。内輪もめや手抜き、内部のポジション争いなどが起こります。1つの船に船頭は2人要りません。 このような、チームの生産性を落としかねないよくある問題が、起こらないようにするにはどうすればいいのでしょうか? 最近「Quartz」で、『Committed Teams: Three Steps to Inspiring Passion and Performance』の3人の共著者がこの質問に対して、チームがうまく機能するための効果的な対処法を問題別に答えていました。その回答をそれぞ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く