エンジニアチームビルディングジャーニーEngineering Manager Meetup #4のLT用資料です。 https://engineering-manager-meetup.connpass.com/event/116235/ 元ネタ https://productmanager55.hatenablog.com/entry/2018/12/15/012008
Kaizen Platformで行っているOnboardingプロセス - Kaizen Platform 開発者ブログ
Kaizen PlatformでSRE Group Managerをしている前田 (@glidenote)です。4月ということで転職や部署異動など新しい環境で働いている人が多そうなので、今回はKaizen PlatformのEngineering GroupとSRE Groupが行っているOnboardingプロセスを紹介したいと思います。 TL;DR Kaizen Platformに入社してくれた人に最速でPerformanceを出してもらうためにOnboardingプロセスを策定し、運用、日々改善している 入社してくれた人が自身のOnboarding Planを自分で作成し、CTO、メンターとで定期的に期待値の調整、振り返りを実施し、齟齬が発生しないようにする ランチスケジュールを組み毎日別々の人と、別々の場所にランチに行き、一緒に働く人たちとオフィス周辺の情報を知ってもらう 入社した
第4章 プロジェクトの政治構造と社会構造
フリーソフトウェアについて人々がよくする最初の質問は、 "プロジェクトはどういう仕組みで動くの？ プロジェクトを維持しているものは何？ 誰に決定権があるの？" といったものです。 私は、実力主義や、協力の精神、読めば何をやっているかわかるコード、 などについて当たり障りなく答えて、 いつも釈然としない思いがします。 実のところ、こうした質問に答えるのは簡単ではありません。 実力主義、協力、そして動くコードは全て答えの一部ではありますが、 日々の単位でプロジェクトがどう動いているかについて殆ど説明していませんし、 プロジェクト内で起こる衝突をどうやって解決するのかについては何も触れていません。 この章では、成功しているオープンソースプロジェクトに共通している、 基本的な仕組みを説明します。 "成功している" というのは、ただ技術的に質が高いだけでなく、 プロジェクトが健全に運営されており、生
プロダクトマネージャーは攻守の要（ボランチ）だと思う - Quest PM
決勝戦はフランスの勝利。その裏にいた立役者 ４−２というスコア以上にポグバの活躍がフランスの強さを支えたと思う。ボールを持ったときのエムバペの怖さがクローズアップされがちだが、フィールドを縦横無尽に動き、相手の攻撃の目を潰し、攻めてはパスをつなぎ、時としてエムバペに長距離のパスを何度か成功させた。そして自らもゴールを決めている。 彼の活躍ぶりはプレー時間を示したヒートマップにも現れていた。これはポグバがボールに絡んだエリアを色の濃淡で示したもの。 （ソースはスポーツデータサイエンスで有名なOpta社のデータが出ていたサイト。） 今大会を見ていて、つくづくプロダクトマネージャーってのが攻守の要ボランチとスタイルが一緒だな〜と思わせることがたくさんあった。実はこのメタファーこそPMの理想的な動きを表す一つの格好の事例なのではないかとも思う。今日はそのことについて。 期待はずれどころか、悪い意味
1年半取り組んだWebプロジェクトマネジメントを振り返って、やって良かったこと、やっておけば良かったことをすべて書く - ねこのひたい
おはようございます。いしげ（@oturu333）です。 このブログは モチベーションクラウド Advent Calendar 2018 - Qiita 1日目の記事として書いています。 今回は過去私が1年半に及ぶWebプロジェクトのPMをした経験を語ろうと思っています。 この記事でお話することについて プロジェクトの概要は既存のWebシステムの全面リニューアルです（MCSではありません）。 ざっとやっていたこと サービスをすべて作り直す（リプレイス） PHPのメジャーバージョン2つくらい一気にあげた CakePHP -> Vue.js + Laravel の構成に変えた AWS構成をがっつり変えた 一部マイクロサービス化した 機能の見直し、UI全刷新 ドキュメントが全然なかったのでいろいろ作りつつ進める 当時の私の立場は、開発チームのマネージャーであり、今回お話するプロジェクトの企画者であ
「きちんと管理すれば企業は成長する」の迷信が企業を衰退させる〜ToMo指数の研究〜｜Yasuhiro Yoshizawa
事業が軌道に乗り、ここ２１ヶ月連続で、毎月売上記録を更新してきたベンチャーA社は、ついに念願の上場を迎えた。 ところがその直後、毎月の売上が急激に鈍化。役員たちは、上場初年度の売上予測の下方修正といった事態をなんとしても避けたいため、事業を担うマーケティング部長、営業部長たちに、こう檄を飛ばす。 「もっとしっかりと分析を行って、何を改善すべきかレポートにまとめてくれ。そして、速やかに改善計画を立て、実行してほしい」 今振り返れば、このときまでが、A社の繁栄のピーク。 この号令を境に、事業を担うメンバーたちは、「今月は、お客さんへのリーチを２０％回復させるためになんとかしなければ」「来訪したユーザが、うちのサイトで購入してくれる率を５％改善しよう」など、計画に基づいて打ち手を探るが、なぜか以前のようなインスピレーションも沸かなければ、ありきたりなアイデアばかりの繰り返しとなる。 一向に成長の
組織のなかで働く技術 - やしお
会社には専門分野の技術とは別に、組織の中で働くための一般的な技術がたくさんある。学校で体系的に教えてもらうものじゃないから会社に入って身に着けていく。僕自身もう会社に入って8年半になるからずいぶん知見が溜まってきた。後輩や新人がその習得に自分と同じ時間をかけるのはもったいない。一度全体を整理しておきたいと思っていた。 それで書いてみたら長くなって、3分の2に圧縮したけどまだ長いのであらすじだけ先に書いておく↓ 働く上でいろいろな制約が存在していて、その制約に対抗する手段としていろいろな技術がある。この制約-手段のつながりを見ず単に結果としての技術だけを覚えても応用がきかないし身につかない。この技術にはレベルがあって、このレベルがちぐはぐだと上手くいかない。 「能力と時間」、「ルール」、「他人の感情」、「自分の感情」、「人間の生理」という5つの制約について「制約→技術」を展開していく。最後に
会社でグループリーダーになるから準備する - やしお
職場のグループリーダー（GL）を交代し、年明けから自分がやるように、という内示を受けた。古い大手メーカーで、課の9割が自分より年上の中で、32歳で係長クラスを任せてもらえる、そう評価してもらえたらしいのはとてもありがたいことだと思った。15歳でガンダムのパイロットにはなれなかったけれど、35歳で係長の野原ひろしには間に合ったのかもしれない。 グループの運営をこんな感じで進めていこうと思うところを、事前にまとめておきたいと思って。 根本的な動機 そもそも「残業したくない」「有給休暇を100％取得したい」と思っている。それは10年前に入社した時そう誓っていて、今も変わらない。けれどそれは誰かを犠牲にすることで達成したいわけじゃない。誰かに仕事を押し付けて自分が早く帰れるのでは意味がない。そのためには仕事の総量を減らしつつ、他の人との負荷の差を均していく、ムリ・ムラ・ムダを減らすことが必要になる
組織変更したら部長がいなくなりました - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、最近愛媛から広島に移住した組織運営チームの水戸です。 2019年からサイボウズの開発本部から職能・地域毎に分かれた部署がなくなり、チーム主体の組織になりました。 組織変更をオープンに議論するというチャレンジングな試みの中で、新組織の理想はユーザー価値の最大化に定まり、個人やチームがより主体的に動ける組織構造に変わりました。 この記事では私がファシリテートを担当した組織変更をご紹介します。 開発本部の状況 開発本部の役割は製品を開発することです。 2018年までの開発本部はマトリクス組織を採用しており、プロダクト開発チームには様々な職能・地域毎に分かれた部署のメンバーが所属していました。 この組織構造は事業の中心がオンプレミスだった10年以上前から、事業の中心がクラウドに移った2018年に至るまで変わっていません。 一方、プロダクト開発チームに求められるものは大きく変わりました。
チームの症状と処方の考察｜Megumi Kaneko
はじめに自己紹介を少しさせてください。 私はクライアントワークで約30名規模の開発チームに1年間ほどジョインしていました。役割は5〜10名のエンジニアで構成されるチームのプロダクトオーナーとしてだったり、UIデザイナーとPMのチームのスクラムマスターとしてだったり、色んな形でチームに接してきました。 その中で経験したことが、広木大地さんの著書である「エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング」を読んで色々整理されたので、チームが陥りがちな問題について稚拙ながら考察を書きたいと思います。 チームの健康状態とはチームの状態を表す指標として心理的安全性はよく聞きますよね。 広木大地さんの著書である「エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング」には心理的安全性について下記のように書かれていました。 「問題点の指摘」や「自分の弱
エンジニアアルバイト氏受け入れテクニック - hitode909の日記
いま社員エンジニアが何人かに加えてエンジニアアルバイト2人、くらいのチームで働いていて、その中でアルバイト氏のメンターもやっている。 前のチームでも何年かアルバイトの面倒を見たり、何回かインターンのメンターをやったりしていた。 手癖でいろんなことをやってしまっていて、属人性が高まってしまっていると感じたので、どんなことをやっているか書いておく。 1日に何回か口頭で会話する 実装ができててから方針がまずかった、となると時間がもったいない 方針書いたくらいでレビュー依頼に出してね、とお願いしてもやってもらうの難しいので、こちらから聞きに行くほうがうまくいきやすい レビュー依頼になったらすぐに見る 社員は明日も要るけど、アルバイト氏は週に数回しか来ないので、その日帰るまでにレビュー完了して打ち返しもしてもらえるように動けると良い レビュー依頼になってなくてもPull Request見に行く 方針
スクラムイベントに出席しない優秀で不可欠な（？）エンジニアをどう扱うか
みなさんこんにちは。@ryuzeeです。 スクラムマスター用のロールプレイのお題をTwitterに書いたら、多くの方から「自分ならこうする」という案を頂いたので共有します。 今回のお題は、以下のものです。 あなたならどうするシリーズw 『あるメンバーはデイリースクラムの時間に出社せず、ほかのイベントでも内職したり別のミーティングでどこかに行ってしまうことがしばしばです。一方で技術的には非常に優秀で、現在の速度で開発する上では不可欠な存在です。スクラムマスターとしてどうしますか？』 — Ryutaro YOSHIBA (@ryuzee) January 1, 2019その他のお題はこちらにあるので、チームで自由に遊んでみてください。 あらかじめ言っておきますが、どの対応が正解というのはありません。 これは、あくまでロールプレイなので、色々なオプションを考えておいて、実際にそのような状況に遭遇
教えるという技術 | DevelopersIO
渡辺です。 自分は「教える」ことにやり甲斐を感じます。 大学時代を思い返すと、家庭教師やサポートセンターのバイトをやってました。 ボードゲームをする時は、ルール説明などを行っていました。 ゲームのインストの一環としてインストカードやサマリを作ることもあり、プレゼン資料作りも得意になりました。 IT業界に入ってからは、勉強会の講師や資料作成・ハンズオンのチューターなどを行うようになりました。 技術書の執筆やIT系専門学校講師も経験しています。 最近では趣味のスノーボードで、インストラクターの資格をとり、スノーボードスクールで教えています。 「教える」ことが好きなんでしょう。 これまで、様々な分野で技術を教えてきました。 畑はまったく違ったとしても、解りやすく「教える」ための技術は大きく変わりません。 今回はそんな「教える」技術をまとめてみました。 なお、本エントリーの対象は、その分野に初めて
チームビルディングの重要性と押さえるべきポイント【Google, Pixar, Airbnb 事例】 デザイン会社 ビートラックス: ブログ
企業にとっても最も重要なものは何か？多くの人がビジネスモデルと答える中で、サンフランシスコベイエリアの企業のその多くの回答は「カルチャー」。このことは、オフィスのデザインやワークスタイルにも色濃く反映されている。 成長企業に見るサンフランシスコ風企業カルチャーとは そんなカルチャー重視の風土のサンフランシスコ市内にあるbtraxも例に漏れず、毎週チームビルディングの時間を作っていたり、サービスとしてもチーム内のカルチャーづくりを促進することも視野に入れたワークショップを行ったりしている。 カルチャー作りの第一歩 – チームビルディング正しい企業風土を作り出す第一歩であるチームビルディングに関する活動は、今や会社のチームを組織する上で重要なイベントとされ、その意義の見直しやより多種多様なチームビルディングイベントの企画が見られるようになった。 その変化はここ数年でより大きくなっており、202
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
心理的安全性を 0から80ぐらいに上げた話
エンジニアメンター制度の効果的な運用を目指して/improve-mentor-system