エンジニアならバグ票を書き慣れているので『事実と意見』を分けて話せる - 室長のひとりごち
仕事をしていて、状況をヒヤリングしていると、事実と話し手の意見の混同というか、話し手が質問を理解できなくて自分の思い、いや、感想を話し出すことはしょっちゅうある。 一方的に話し手の思いがダダ漏れしているというよりは、コミュニケーション自体、質問する側からの投げ掛けがキッカケなのだから、受け側の話し手のリアクションが期待するものでなければ、問いかけ側の質問が悪い。 例えば、次のエントリの中に出てくる会話はよくある上司と部下の日常的な風景に思えるかもしれないが、であれば部下へ聞きたいことを効率的に聞こうと思ったら、部下の返答の癖（事実と意見を区別できないこと）を知っているわけだから、上司の聞き方は上手とは言えない。 blog.tinect.jp そういうときの質問の仕方も曖昧だったりする。聞き手が最短で聞きたいことを質問するなら枕詞として、 「先に事実だけ教えて。そのあとに意見を教えて」 と誘
新しいチームに加わるエンジニアのための "被" オンボーディングガイド v0.1.0 - rocky-manobi's blog
この記事はLAPRAS Advent Calendar 2019の13日目の記事です 自分も最近体験したということもあり、LAPRASのWebAppチームのオンボーディングについて紹介しようと思いましたが、最近自社推しが過ぎる気もしたので視点をオンボーディングを受ける側に移し、「こんな風に立ち回ろう！」というスタンスで書くことにしました。 v0.1.0 ということで走り書きの勢いでそのままお届け致します。 オンボーディングとは オンボーディングとは、新たにサービスを導入した人や新たに組織に参加した人などに対して早く慣れることができるようにサポートすることです。 この記事の文脈は後者。 注意することやTIPSを書いていきたい。自分にも多少刺さる点もあるが、過去よりも改善はされていると思っているので勇気を持って書くことにする。 いきなり目立った成果を出そうとして消耗しない まずは危険性を認識す
デザインをいつみせるか、どう伝えるか - Speaker Deck
2018/11/24 開催の FRONTEND CONFERENCE 2018 にて登壇させていただきました。 以前デザインの勉強会にてお話させていただいた「デザインを３割で投げ出す技術」の続きのお話になります。 ======================================== デザインをいつみせるか、どう伝えるか 制作フローの中にある、「相談」について考えてみました 「デザインに悩みすぎて進捗が出せない」 デザイナーになって間もない頃に抱えていた私の悩みは、 人に「相談」することで解決できるようになりました。 しかし、「相談」するものの、思うように伝わらなかったり、 ずれた答えが返ってきたり… デザイン制作の場面で重要な、「なぜ相談するのか」や 「どう相談するか」といったコミュニケーションの工夫をお話します。
エンジニア(野獣(ケダモノ))を飼いならすチーム作り
http://attitude4webperson.doorkeeper.jp/events/16227 10/30 at コワーキングスペース茅場町 Co-Edo
書けないプログラマとの向き合い方があったら教えて欲しい - まなめはうす
私はピラミッド構造の真ん中で「どんな人でも一定の品質を確保するためにどうするか」を日々考えているような立場なのですが、正直なところ、自分でレビューする以外の受け入れをできていないのが現状だったりする。なにせ「どんな人でも」といってもある程度のスキルを保有していることを条件に人材を集めてはいるものの、若い人でも定年近い人でも、他のメンバーの残業時間を増やすだけの人が存在する。そんな人の対処法（銀の弾丸）があるようなら、教えて欲しいものである。 www.megamouth.info はてさて今話題のこのエントリ。私の所属するＰＪにもいろんな人が出入りするが、書けない人は何人か見てきた。特に中途半端な時期に人が必要になって集めると、たいてい書けない人が回ってくる。優秀な人を手放すＰＪは無いので解散でもない限りそういった人が入ってくることはない。また集める人もスキルだけで判断するのでいろんな経験の
自分の本音と向き合う期待値マネジメント
期待値を言語化する、期待値を伝える、期待値をすり合わせる。 チームをマネジメントしたりサポートしたりすると、こういった期待値の調整をする場面はよくありますよね。 今回は期待される側ではなく期待する側に注目して、「何を期待しているか」「どのように期待を伝えているか」について考えてみようと思います。私がチームマネジメントやスクラムマスターをしていてよく陥る失敗を思い返しながら、自分への注意喚起を兼ねて整理してみます。 何に期待するか 私は期待の種類を4つのレイヤに分類して捉えています。 状態への期待 ひとつひとつの出来事・仕事・タスクについてではなく、それらを繰り返しどういう状態を維持してほしいと思っているかを指します。「案件の優先順位に沿ってうまく計画立てて進行している状態を維持してほしい(ときには失敗することもあるだろうが、その改善も含めて停滞せず前進し続けていればよい)」といったものです
当事者意識は「意識」だけでは生まれない｜石倉秀明
こんばんは。オンラインで働く人を増やしたい石倉です。 つい先日緊急事態宣言でて大変だ！！となっていたのに、あっという間に4月が終わってしまいびっくりしています。 一応、スタートアップの経営者をしてますので、このタイミングで悩むこと、考えることは非常に多いですし、経営者人生の中でもなかなかハードな局面を迎えています。 毎日家で仕事をしていて、保育園も休園なので4歳になる娘もずっと家にいるんですが、娘がすごく前向きで明るく過ごしていることが本当に精神面でも支えになっているなと。（もちろん子供が家にいる中での仕事はなかなか難しいものがあり、一旦午後まで働いて夜に再開するなどしている状況ですが...） そんな中で最近感じている「当事者意識」について書いていきたいと思います。 スタートアップで働く皆さんの多くはもちろん、そうじゃない方も仕事で「当事者意識を持ちなさい」と言われた経験がある方は多いので
人月の神話を読んでみた | フューチャー技術ブログ
TIGの伊藤真彦です この記事は秋のブログ週間の2記事目です。 この前新宿で複数の用事を済ませていた際、隙間時間が暇になったため人月の神話を買ってみました。紀伊国屋新宿本店の技術書コーナーはほぼ全ての技術書が置いてあるのではと感じるほどの物量があるのでおススメです。 名著として名高い事は知っており、タイトルに惹かれて読んでみましたがとても良いものでした、読書の秋におススメの一冊として紹介します。 人月の神話とは 皆さんは「人月の神話」という書籍をご存じでしょうか。 ITの世界には名著と呼ばれる書籍がいくつかあります。人月の神話はそのうちの一冊です。フレデリック・ブルックスによるソフトウェア工学、およびプロジェクトマネジメントに関する書籍です。 最初の刊行はなんと1975年、実に40年以上の時を経て未だに読まれている書籍です。進歩が速く、常に新しい知識が求められるイメージのIT業界において、
「ヤフーの1on1」を読んだらスラムダンク山王戦の謎が20年越しで解けた話 - Speee DEVELOPER BLOG
お疲れ様です。スラムダンクで最も好きなセリフは「大好きです。今度は嘘じゃないっす」。稼働率のディフェンスに定評がある開発基盤グループのEM @k.bigwheel (= 西田和史) です。 今日はヤフーの1on1という本を読んでいたら20年謎だった安西先生の行動がやっと理解できた話をします。 スラムダンクについて みなさんスラムダンクという漫画はご存知ですか？ SLAM DUNK 新装再編版 | 集英社コミック公式 S-MANGA スラムダンクは90~96年にかけて週刊少年ジャンプで連載された漫画で、シリーズ累計発行部数が1億2000万部の大ヒット漫画です。90年代のバスケットブームを牽引しました。 僕はスラムダンクがとても好きでもう何回読み返したか覚えていません。特に山王戦が好きで未だに年に一度は必ず読んでいます。今日はその山王戦の話をします。 一部ネタバレも含みますので気になる方はご注
エンジニアってどう評価すればよいのかをプレイングマネージャー視点でまとめてみた - Qiita
エンジニアの評価って難しくないですか？ これは、エンジニアをメンバーに持つマネージャーや、 営業畑で出世していった、事業部の課長や部長クラスの人向けの記事です。 私自身、エンジニアの評価を聞かれる機会が多くなる中で、 色んな人から「エンジニアってどう評価したら良いんだろう」という相談をされます。 これ、凄く分かる話で、エンジニアをどう評価したらよいかというのはかなり難しい仕事だと思います。 営業サイドは目標も結果も定量的に判断出来る為、判断し易いが、 エンジニアはどうしても定性的になってしまい、評価するのが難しいです。 また、後に詳しく書きますが、「前回からの成長」等のポイントもどう評価するかというのも難しいポイントの1つです。 軽く例題 例えば、以下のような3人のエンジニアがいた場合、あなたならどう評価しますか？ Aさん 与えられた仕事はしっかりとこなし、毎回自分で設定した工数通りに納品
音楽仲間の人間関係が悪くなっていく理由 - ギタリスト専用ブログ
最初は仲良かったのに ロスの音楽高校時代 相談されました。 「ライブ計画する度にバンド内の人間関係が悪くなるんですけどぉ」 分かります。大人の音楽家でも、音楽仲間とある時期を境にギクシャクし始めるってありますよね。思い返せば学生の時も1学期は仲良くしてたのに2学期あたりからギクシャクし始めましたよね。どうしてこんなこと起こるんでしょうか？ トータル・ギター・メソッドお客様の声 心配無用です。 この記事を読んだら、音楽仲間の人間関係が悪くなっていく理由が分かりますよ。 目次 最初は仲良かったのに 結論 解釈レベル理論とは 例 さらに 対処法 まとめ 結論 解釈レベル理論によるもの トータル・ギター・メソッドの口コミ 解釈レベル理論とは 解釈レベル理論とは時間的に遠いことに高次解釈をして、近いことに低次解釈をするってことです・・・わかりにくいですね。 例 バンドを作って1年後のワンマンライブを
🔦「お気持ち会」で暗闇を払う - 弥生開発者ブログ
こんにちは、@mugi_uno です。気付いたら弥生社員になってました！！ プロジェクトの立ち上げはむずかしい Misocaチームで何かしらの課題に取り組む場合、基本的にはプロジェクト化して進めていきます。 その際、まずはインセプションデッキを作成して「目的やゴールは何か」「何をして、何をしないか」といったことを明文化し、メンバーで認識を揃える作業をします。 ですが、現実的にはそれ自体が難しいケースが存在します。 何から手を付ければいいのかわかりません！ たとえば 多種多様な立場の人が参加するプロジェクトを始めるが、メンバー個々人が何を重要視しているかを互いに知らない ○○について効率化したいけど、具体的に何が課題で次に何をすべきかが誰もハッキリとは見えていない 膨大なタスクが存在していて、どういった判断軸で優先順位をつけていけばいいのかがわからない みたいな経験はないでしょうか。 このよ
課題を考えるチームより理想を考えるチームが成果に近い。 - どこぞのエンジニアなマネージャーのブログ。
序章 チームで活動していると、振り返りとか課題提起とかよくやると思うのだけれど、 ｢○○を改善しよう。｣とか｢xxがよくなかった。｣とか｢じゃあ次回△△しよう。｣とか、 そういったコミュニケーションとってますよね。 ※KPTなんかもよく使われてたり。 それが如何によくないか、という話をしたい。 それって本当によくないことなの? ｢問題を出し合おう。｣ と言って出てきた考えに対応を苦慮したことはないだろうか? それは今やるべきことなのか? 優先順はあっている? 最悪なことに本当は必要なことだったりしないか? 実は勝手にそう思っているだけではないか? そういう課題ではなく別の課題の話をしたい。 とかいう話。 そこで事前にやっておくべきは ｢チームとしてどうありたいのか。最適な状態は?｣ とちゃんと理想を考えておく必要がある。 ｢どうありたいか｣に対して無駄なことであれば課題であるわけだけれど、
「組織の目標をどうやってエンジニアリング目標に落とし込むかOKRで考えてみる」に参加してきた - 天の月
distributed-agile-team.connpass.com 今日はこちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。 いくおさんがこの会のために書いてくれたnote 会の概要 会で印象的だったこと 変化するObjectiveの難しさ エンジニアだからこそ気が付く目標の解像度の粗さ 先行指標 いきいき 全体を通した感想 いくおさんがこの会のために書いてくれたnote note.com 会の概要 いきいきいくおさんこと小田中さんの以下のつぶやきをきっかけに、エンジニアリングやOKRについて話してみようという会です。 「売上○○円」「ユーザー数○○人」「平均DAU○○」といった目標をどうやってエンジニアリングの目標に落とし込むか。 OKRの場合、ツリーが連なってく中で親KR (定量)→子O(定性)の変換を行うため、ここの変換の仕方がキモになる。 こういう「エ
『自分でやった方が早い病』を読んだ - ravelll の日記
タイトルと "孤独な成功者" というキーワードに思い当たるところがあり読んだ。 自分でやった方が早い病 (星海社新書) 作者:小倉 広発売日: 2012/05/25メディア: 新書 僕は相手に頼み事をするのが苦手（年々改善されてはいるが）で、これは思いやりではなくエゴだよなーと思っているのだけど、本の中でも「要求を遠慮するのは信頼関係が無いから」ということが書かれていて、そうだよな、となった。 僕はこの問題を「今解決しようとしている問題は同僚にとっても解決すべき問題なはずなので僕の頼み事を渋ることがあればその人は仕事をする気がないと言えるのでは」のような責任転嫁によって改善しているフシがあり、根本的な解決に向かっていないので意識を改めようと思いました… また「仕事を任せることと仕事をふることは違う」の話は思い当たる具体的な失敗経験があり少し頭が痛くなった。半年前くらいに仕事でプロジェクトの
Googleマネジメントの元ネタでもあるインテル経営の本を読んだ - 勘と経験と読経
ちょっと前に目に付いた「1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から」というブログ記事で紹介されていた「インテル経営の秘密―世界最強企業を創ったマネジメント哲学」を読んだメモ。かなり以前から気になっていたのだけれども、現在は絶版で古書がプレミア価格になっている。さすがに買えないので公立図書館で借りて読んだもの。普通の管理職、マネジャーとして非常に勉強になる良い本だった。 経営陣 or 上司が 1 on 1 の価値を分かってくれない インテル経営の秘密―世界最強企業を創ったマネジメント哲学 をプレゼントしよう 1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア - higepon blog インテル経営の秘密―世界最強企業を創ったマネジメント哲学 作者:アンドリュー・S. グロ
組織のベースラインを引く - sugimoriの日記
元エンジニアリングマネージャで、今は人事をやっています。 この記事は、Engineering Manager vol.2 Advent Calendar 2018 の19日目です。 もはや関係ないのに未だにエンジニアの1on1を何人かの人とやっているのですが、そこで、同じことを何人かの人に説明することが続いたので、きっと同じようなことで詰まってるんだろうなと思い、久しぶりに書いてみることにしました。*1 前提 僕が1on1をやっている人は、チームのリーダーもしくはリーダー的な動きを期待されている人 それぞれのチームは古い人もいれば、新しい人も入ってきて、割とカオス。 それぞれのリーダーは、なんとかチームを良くしたいと思ってがんばっている。 1on1での話 とあるAさんの1on1から チームのみんなが技術的に向上したいって思ってくれない という悩み。聞いてみるとチームとしては業務はそれなりに
“雰囲気でOKRをやっている” と感じたら読んでもらいたいnote｜Shohei Iwata
OKRに関するnoteをいくつか書いてたら相談をもらうことが増えてきた。 相談の多くは「導入してみたけど何だかうまくいかない…」というもの。多くの書籍でも書かれているようにOKRは何度か壁にぶつかって組織にフィットしていくものなので当然なのかもしれない。 そのため、“雰囲気でOKRをやっている” という状態が続きやすいものだと思っている。ただ、OKRそのものの考え方を改めてインストールしてみると案外うまくいくことが多かったので、そのポイントを書き出してみる。 OKRとは何か公式的にはこんな感じだろうか OKRとは？Objective and Key Result（目標と主な結果）の略称。目標と目標達成度を測る指標をリンクさせ、企業やチーム、個人が向かうべき方向とやるべきことを明確にする目標管理手法。1970年代にインテル社が採用し、グーグルやジンガなど、数多くのグローバル企業が採用している
マネージメントに必要なことは全てゲームから学んだ
この投稿は毎年恒例、pyspa Advent Calendar 2020の1日目の投稿になります。 どうもご無沙汰しております、akisuteです。すっかり年に1回アドベントカレンダーのときにだけ顔を見せる人になっておりますが、おかげさまで無事平穏に過ごしております。 さて突然ですが私はプログラマーを引退しました。 なぜなら今年で36歳だからです。プログラマーは35歳になったら定年ですね。 実際のところ、このぐらいの年になると、よほど何らかの意志が働かない限り、技術に対する情熱みたいなものが失われてくると思います。もちろん本当に技術とプログラミングが好きな人は間違いなく35歳なんかで情熱を失ったりはしないと断言しますが、残念ながら私はそうではなく、もはやiPhoneには大した興味が湧いておりませんし、最近はJavaだのGoだのTypescriptだのVue.jsだのといったものを必要に応じ
なぜSpotifyはOKRをやめた？アジャイル組織に最適な目標管理「Spotify Rhythm」とは｜加藤 章太朗
なぜSpotifyはOKRをやめた？アジャイル組織に最適な目標管理「Spotify Rhythm」とは こんにちは、加藤章太朗（@katoshow）です。 前回のnoteでは、自律分散型の組織の1形態である「アジャイル組織」について説明しました。 今回は、アジャイル組織の代表Spotifyが採用する目標管理のフレームワーク（戦略フレームワーク）についてお伝えします。 Spotifyでは、2014年まではOKRを採用していました。Googleなどで大きな成果を上げたOKRは、日本でも昨今導入が進んでいます。しかし、SpotifyはOKRをやめ、Spotify Rhythm（スポティファイリズム）という独自の目標管理フレームワーク（戦略フレームワーク）に移行しました。 SpotifyがなぜOKRをやめたのか？そしてSpotify Rhythmとはどのようなものか？について説明していきます。 ※
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
