こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと - Mitsuyuki.Shiiba
最近、毎日のようにEMのいくおさん（ @dora_e_m ）とTwitterXでわちゃわちゃしてる。彼のポストを見ていると、ガンプラをつくるかビールを飲むかしかしていないように見えるが、それで合っている。 という冗談はおいといて真面目な話をすると、エンジニアとしての僕は彼と仕事ができている今の時間のことを本当に貴重な時間だと思っている。とにかく仕事がしやすいし、いろいろな気づきを与えてくれるおかげで、自分自身の成長も感じている。 エンジニアリングマネージャとしての知識が豊富でスキルが高いというのはもちろん、人との接し方や日常的なふるまいもとても尊敬できるものなのだ。 そこで今日は、僕が彼とこの3ヶ月間仕事をしていて、やりやすい・尊敬していると感じていることの中から10個だけ簡単に紹介しようと思う。僕からいくおさんへの日頃の感謝の気持ちをあらためて書いておこうと思っただけとも言う（ふだんから
ブルシットプロダクトからチームを守れ! ｢顧客が本当に必要だったもの｣をいかに追求しつづけるか /bullshit product rsgt2022
ユーザーから見て、ただひどいだけでなく、開発したり販売する人たち自身がプロダクトに価値がないと感じており、また買ってもらうことに罪悪感を感じるようなプロダクトやサービスをブルシットプロダクトと呼びましょう。 ブルシットプロダクトとは何か、どのようにして生まれるのか、なにをすれば解消されるのか、顧客が「顧客が本当に必要だったもの」を実現しつづけるプロダクト組織に向けて、組織システムの成長の観点からお話しします。 Regional Scrum Gathering Tokyo 2022 概要 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/16109 発表者 https://twitter.com/_N_A_ https://note.com/mryy/n/n6f01561a6253
チームで成果を出すためには心理的安全性が必要で、そのためには礼節とHRTが不可欠だ、という話をしました | DevelopersIO
事業開発部の塩谷 (@kwappa) です。 クラスメソッドの関連会社であるアノテーション株式会社の研修として依頼を受け、チームと心理的安全性、それに礼節というテーマで話をしてきました。 スライド 概要 ここしばらく重点的に書いたり喋ったりしている、心理的安全性とその土台となる礼節がテーマです。昨年のDevelopers.IO Tokyo 2019でのセッション『3つの「Re」〜ソフトウェアの信頼性を高めるためにぼくたちができること〜』 をベースに、発表時間が少し長くなったので各要素の解説を丁寧にしつつ、全体の流れを整理しています。 また、エンジニアに特化した部分をはがすことも意識しています。チームで仕事をするのはエンジニアに限ったことではないですし、昨年末からOpsチームのスクラムマスターをやっていることも影響しています。ともすると「仕事 = コードを書く」という意識に傾きがちな自分への
正論だけ言ってればいいと思っているようじゃ、POISON｜りょかち
「君は、物怖じせずに意見を言えるところが素晴らしいよね」 インターンしていた職場で言われたことがある。当時にしてはTwitterのフォロワーが多く、取材もしてもらったりしていた学生の私は、だれかに対して意見を述べることに人よりも慣れていた。 それからも、フラットで自由な会社に入り、1年目から自分の意見を求められる環境に身を置いていた。「ただの『決めてください』というレポートはナンセンス。自分は沢山調べてこういう選択肢があると発見し、その中でコレが良いと思いますがどうですか？と聞いてほしい」という上司の発言をどこかの記事で見かけたことがある。若いからという理由だけで誰かに黙らされた記憶も勿論ない。 "若いうちから、発言を許される"こと自体が羨ましがられるどこか奇妙な世の中で、「自分の意見がないと、仕事は進まない」と学べる会社にいることは私の幸運だと今も思う。 ただ最近思うのが「"はっきり意見
無能な同僚と働くということ。 - WETな備忘録
君へ、 つい最近まで、南米で3ヶ月ほどデータエンジニアとして仕事していた。Tシャツで帰ってきて震えた。寒くて。 僕にとって2019年は、あんまりいろんなことが無かったくせに、いや糞ヒマだったからこそ、いろいろ考えることが多い1年だったと思う。最後の3ヶ月以外は、基本的にヒマだった。 過去に僕はベルリンで1年ほど働いていたこと*1があり、まあ結論からいうと音を上げて、日本に逃げ帰ってきた。何がそんなにしんどかったかというと、ベルリンは十分英語で生活できるとはいえ、ドイツ語関連のトラブルシューティングに付き合ってくれるドイツ人の友人を作ることができなかったというのが大きいが、そういう人間関係を構築することが出来なかったことも含めて、当時所属していた会社の上司および同僚と上手くいかなかったのが致命的だった。 とくに、エンジニアの同僚氏、つまり君は、まったく許せなかった。 あれからもう3年も経ち、
グーグルが出した「最終解」 理想のリーダーとチーム | NIKKEIリスキリング
米グーグルがまとめた「最高のマネジャーになるための8つの習慣」は「よいコミュニケーターであれ。そしてチームの声を聞け」と説く。 写真はイメージ=PIXTA 人事関連の人たちや人材業界では大きな注目を集めたグーグルのプロジェクトが2つあります。最高のマネジャーになるための8つの習慣を明らかにした「プロジェクトOxygen」と、チームを成功へと導く5つの鍵を明らかにした「プロジェクトAristotle（アリストテレス）」。今回は、この2つについて見てみることで、ミドルシニアの皆さんの転職力をアップさせるポイントに迫ってみたいと思います。 まずはグーグルが2009年に実施した社員対象の大規模調査「プロジェクトOxygen」の結果から見てみましょう。このプロジェクトでは「優秀なマネジャーはどういう人か？」を、グーグルの従業員を対象にリサーチしました。 人事考課、フィードバックサーベイ、表彰、その他
組織のなかで働く技術 - やしお
会社には専門分野の技術とは別に、組織の中で働くための一般的な技術がたくさんある。学校で体系的に教えてもらうものじゃないから会社に入って身に着けていく。僕自身もう会社に入って8年半になるからずいぶん知見が溜まってきた。後輩や新人がその習得に自分と同じ時間をかけるのはもったいない。一度全体を整理しておきたいと思っていた。 それで書いてみたら長くなって、3分の2に圧縮したけどまだ長いのであらすじだけ先に書いておく↓ 働く上でいろいろな制約が存在していて、その制約に対抗する手段としていろいろな技術がある。この制約-手段のつながりを見ず単に結果としての技術だけを覚えても応用がきかないし身につかない。この技術にはレベルがあって、このレベルがちぐはぐだと上手くいかない。 「能力と時間」、「ルール」、「他人の感情」、「自分の感情」、「人間の生理」という5つの制約について「制約→技術」を展開していく。最後に
退職エントリーを書かれる前に実践したい、エンジニアが辞めないチームの作り方
マネジャーにできること 「辞めたい」と相談された場合はラッキーですが、そうでなくても常日頃からエンジニアの「辞めたい気持ち」が蓄積しないようケアをすることがマネジャーには求められます。 蓄積させないために、蓄積したものを取り除くために、マネジャーができることを考えてみましょう。 マネジャーのミッションはメンバーの給料を上げること 仕事上の不満や理不尽は現場によってまちまちですから、一般的な答えはありません。しかし、マネジャーとして最も重要なこと、すなわち「メンバーの給料を上げる」ことをミッションとして肝に銘じてさえいれば、行動指針はおのずと見えてくるのではないでしょうか。 関連記事 エンジニアに「退職の自由」はあるのか？ 主要エンジニアが退職したからゲームのリリース日が大幅に遅れた。訴えてやる！――IT訴訟事例を例にとり、システム開発にまつわるトラブルの予防と対策法を解説する人気連載。今回
他チームの人とうまくやりとりするための心がけ
個人的に大切にしていることを書いていきます。少しSREの話が出てきますが、私がSREチームだから出しているだけで、基本的にSREに関係の無い分野でも使えるはずです。 前提となる心がけまず前提となる心がけについて書きます。 エンジニアは恐いと思われている人は自分と関わりの少ない人のことを恐いと思いがちです。 システムはほとんどの人にとってブラックボックスです。そしてシステムを担当しているエンジニアのことも、ほとんどの人にとって未知の存在です。関わりが少ないからこそ、ほとんどの人にとってエンジニアは恐い存在です。 ビジネスをやっていく上で、エンジニアとのやりとりは非常に重要です。そのエンジニアと他の社員のやりとりがしにくい状況だとお互いにストレスが溜まり、不健全な組織となっていきます。 これを解消する一つの手として、例えばチャンネル名が z- から始まるチャンネルは雑談していいというようなルー
ゲーム開発における失敗するに決まってるプロジェクト問題 島国大和のド畜生
俺は開発中プロジェクトの進行具合を見ればその後の成功失敗をわりと当てることができる。（偉そうに出たが、開発者の何割かは息を吸うようにこれをやる） 数日一緒に仕事をすれば確度はもっと高くなる。 美味しんぼにおける、「天ぷらを揚げる前に、上手い天ぷらをあげる職人が分かるか？」という奴だ。これのチーム版。 なぜそれが解る人と解らない人が居るかを説明する。 犬は嗅覚の世界で生きていて、鳥は視覚の世界で生きている。お互いの世界は理解することができない。 ゲームの開発現場には、犬、鳥、トカゲ、深海魚、ナマケモノと各種種族が入り混じっているので、ある属性の人には別の属性の人の重要な事象がまるで見えていない事がある。犬の世界は鳥には分からないのだから。 例えば日本人は、昔、青色と緑色は同じと扱っていた。どうでもよかったのだろう。 砂漠の民はラクダを表す言葉が年齢性別によって細かく区別されているという。重要
会議/ミーティングについて本気出して考えて見た結果 - Qiita
はじめに 「会議だけで一日終わっちゃったよ・・・」と言うワードを聞く頻度が増えました。 前々から、会議なんとかしたいなぁと思いつつも、どうやればいいのかな？ってのをいまいち理解できていなかった＆良い機会なので、ちょっと力入れて調べ/考えてみました。 結論 まず結論を述べておきます。たった2点です。 1.「適切な振り返り」を行うこと 適切な振り返りとは、「基準を明確にし、測定し、データに基づいた振り返りを行うこと」。 そして、この「適切な振り返り」は、会議だけに留まらせず、基本的な仕事のスタンスにさせていくこと。 2.日頃からチーム力を上げておくこと 人間心理として、会議に対する心理的負荷は大きい。心理的負荷を下げ、効果的な会議を行うには、日頃からチーム力を上げておくことが効果的である。 チーム力を上げるには、「心理的安全性（チームのメンバー一人ひとりがそのチームに対して、気兼ねなく発言でき
チームリーダーをやるときに気をつけてた「4つの混ぜない」 - Mitsuyuki.Shiiba
開発チームのチームリーダーやってたときってどんなこと考えながらやってた？って相談があって、僕がチームリーダーやってたときはこういうことに気をつけてたよ。って話をした。今は僕はリーダーは後輩にまかせて、自分はシニアエンジニア的な立場でコードを書いたりウロウロしたりして楽しく過ごしてるんだけども。 4つの混ぜない やってるときは特に考えてなかったけど、今になって考えるとこういうこと気にしてたなーってのね。数は、単に4つ思い出した。ってだけ。 帽子を混ぜない エンジニア出身のチームリーダーって、こんな帽子をかぶってることが多いかな: 組織マネージャの帽子で 後輩の育成や組織としての成長を考えたり 開発リードの帽子で クオリティの最後の砦みたいな役割や、チームの外との調整をやったり プロジェクトマネージャの帽子で プロジェクトをどうやってうまく回していくかを考えたり なので「今の自分の気持ちはどの
自己組織化の実験
Caroline Kirkhope氏によれば、自己組織化するチームは効率的でより幸せだ。全ての人が自己組織化するチームに馴染む訳ではない。言われたことをやり、自分で働くことに慣れている。自己組織化するチームを実現するには意図を元にしたリーダーシップ、ソシオクラシー、ホロクラシーのようなモダンなリーダーシップのアプローチが必要だ。 Caroline Kirkhope氏はソフトウェア開発者でありテックリードだ。氏はLean Agile Scotland 2017で自己組織化について話した。InfoQはこのカンファレンスをインタビューや記事で取り上げている。 InfoQは氏にインタビューし、自己組織化についての実験から学んだことについて話を聞いた。 InfoQ: 自己組織化はなぜ重要なのでしょうか。 Caroline Kirkhope: 知識労働者は自分たちの仕事に発言権があればより健康的でより
開発運用チームを立て直した話 - 下町柚子黄昏記 by @yuzutas0
SPI Japan 2017というカンファレンスで発表をしました。 グロースフェーズの痛みの中で、いかに開発・運用チームを立て直したかという内容になります。 発表スライド 「Rebuild Team - 急成長プロダクトのDev&Opsで生じる悪循環とその解決策」 ここ最近の発表の集大成です。 急成長フェーズを体験した人は多くないはずなので、有用な知見ではないかと自負しています。 参加した感想 運営が非常に丁寧でした。選考通過時にはレビュアーから「こういう点が素晴らしい」とコメントいただき、また当日には司会者からフォローをいただき、非常に話しやすい場作りがなされていました。 一方で内容面については全体的に違和感を覚えました。もやもやです。 内容 思ったこと 補足事項 「改善施策が現場に受け入れられない」という意見が多かった 改善施策は現場の人が現場のために生み出すものではないか。 現場にメ
敵は社内にあり！ 抵抗勢力との向き合い方 「チーム編成の極意」
どんなチームにどんな人を加えるか？ まずは「チームの構成」について。どんなメンバーでプロジェクトチームを構成するのがいいのだろうか？ 1. 抵抗勢力候補など、自分と違うタイプを集める 変革を成し遂げるまでには、いろいろなことが起きる。関係者にもいろいろな人がいる。だからコアメンバーのスタイルが一本やりだと、難所を突破できなくなる。 真にチームワークにすぐれた組織では 同じ穴のムジナではなく、自分にないモノを持った人を集める 他のメンバーの色に応じて、自分が演じる役割を微調整する（バランス感覚） という力学が必ず働いている。例えば、 リーダーがアクセル役で、サブリーダーがブレーキ／ハンドル役 リーダーが強行突破型で、サブリーダーが根回し調整型 リーダーがアイデアマンタイプで、それを支えるプロジェクトオーナーが現実的に考え抜くタイプ 要するにバランスが重要なのだ。 変革の方向性によっては、反対
組織の強みは唯一、知を発見できるかで決まる ——チームラボ代表・猪子寿之 | 組織文化/組織開発｜DIAMOND ハーバード・ビジネス・レビュー
世の中を驚かせるアートを生み出し続ける“ウルトラテクロノジスト集団”チームラボは、その創作活動の基本に「集団的創造」を掲げている。なぜ彼らは、チームでの作品づくりにこだわり続けるのか。そこには、現代の知のあり方に対する深い洞察が隠されていた。猪子寿之氏へのインタビュー後編。（構成／加藤年男、写真／鈴木愛子） 編集部（以下色文字）：前回、手を動かす中で知を発見する重要性についてお話されましたが、同じプロセスで同じようにモノをつくっていても、知を発見できる人とできない人がいるのではありませんか？ 猪子寿之（いのこ・としゆき） チームラボ代表 1977年、徳島県生まれ。2001年、東京大学計数工学科卒業時にチームラボ設立。チームラボは、さまざまな分野のスペシャリストから構成されているウルトラテクノロジスト集団。アート、サイエンス、テクノロジー、クリエイティビティの境界を超えて、集団的創造をコンセ
リーダー(管理者)ではなくエンジニア(実務者)でありたいと願う人々へ - おうさまのみみはロバのみみ
「お前は向いていないんじゃない、やってないだけだ」 この一文を読んでほんの少しでもなにかを感じた人は是非とも↓の本を今すぐに読むべきだ。 エラスティックリーダーシップ ―自己組織化チームの育て方 作者: Roy Osherove,島田浩二出版社/メーカー: オライリージャパン発売日: 2017/05/13メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 本著はみんなが考え、感じているリーダーシップという曖昧模糊な概念に対して具体性をもたらせてくれる。 それは「チームリーダーの役割は優れた人材が育つのを助けること」と定義付けていることだ。 このシンプルである意味で本質をついている定義付けが本著を名書たらしめているとぼくは思う。 この本の構成は1部〜4部(おおよそ本書の半分ほどを占めている)までが著者によるリーダーシップとはなにか？3つのフェーズの分類とそのときに期待さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スクラムガイド - Scrum Guide 2020 年 11 月
心理的安全性を 0から80ぐらいに上げた話
リーダーになるすべての人に知ってほしい チームビルディングの極意
