207で1年間磨き続けた1on1のフォーマットを公開します｜207株式会社
いつでもどこでもモノがトドク、世界的な物流ネットワークを創りたい、207株式会社のイナバです。 207の1on1、めっちゃ良いんです！！ 先日の忘年会で業務委託の方に「207に所属していて良いところは何か？」とお聞きして「1on1、めっちゃ科学されていて良いですよね」という話題に上がるくらいには良いです！ 私自身、業務委託で色んな会社を見ているのですが、たしかに207の1on1は凝っていると思います。 という事で、本記事では「どんな質問を」「どんな意図で」しているのかを代表にインタビューしてきたのでまとめていきます。 1on1をやる目的 そもそも1on1を実施してよかった点ですが、たくさんのメリットの中でも特に、 - 認識のズレをなくす - 信頼関係を構築する - アラートの早期検出 みたいな効果を享受できています。それぞれ、どういう意味かをご説明していきます。 認識のズレをなくす 業務上
コーチングから学ぶ、1on1の「聴く」技術
コーチングから学ぶ、1on1の「聴く」技術：あなたの1on1、独演会になってない？（1/4 ページ） 菌類、コーチングの研修を受ける おひさしぶりです。元プログラマーにして採用担当、最近はエンジニアリングマネジャーでもある「きのこる先生」、一人称は菌類です。 季節は秋から冬になろうとしている今日このごろ、皆さまいかがお過ごしでしょうか。菌類は緊急事態宣言の解除に伴い、飲み会や出張が解禁されて忙しくしています。この原稿も出張帰りの新幹線で書いていますし、飲み会続きで2キロほど太ってしまいました。なるほど食欲の秋、恐ろしいワナです。 本業では、日々マネジメントの仕事をしています。ゴタゴタした雑務に追われてメンバー個々と向き合う時間が不足しているな、と思うことが増えてきたので、1on1の時間を増やすことにしました。 メンバー全員と2週間に1回1on1を実施する、と決めたのですが、これがまた結構大
ミーティング・ファシリテーション入門 / Introduction To Meeting And Facilitation
Stockmark ( https://stockmark.co.jp ) 社内勉強会の資料公開です。
文化的負債解消における“プロセスで解決する”視点の重要性 「周りを変える前に、自分自身が変わることが大切だ」
文化的負債Case9：エンゲージメントが低い 高橋裕之氏（以下、高橋）：次は高橋から、Case9。「エンゲージメントが低い」です。“ここで”というのは、所属している組織や会社とかです。エンゲージメントは「ここで働き続ける理由」と言われています。今まで会社の従業員満足度調査やモチベーション、ロイヤルティなどが昔よくあったと思います。だけど、今はエンゲージメントを測ることがすごく効果的と言われています。 実は2年ちょっと前に、とある部門を私が部門長として引き受けることになった時、そこはすでにエンゲージメントを測っていましたが、64というそこそこ低い状でした。これはどうにかしないとならないということで、いろいろやりました。 正直、64という数字がどういう状態なのかさっぱりわからなかったため、みんなを知るためにリーダーズ・アクライメーションというワークをやったり、あとは弊社の言い方でGMGという、
再現性と質を高める「意思決定のフロー化」 ―― 開発畑のプロダクトマネージャーの失敗から学べ
はじめに こんにちは、ゆずたそ（@yuzutas0）です。この連載では、ソフトウェア開発者からプロダクトマネージャーに転向した筆者が、多くの失敗を経て重要性を痛感した「プロダクトマネージャーのマインドセット」を解説します。 主な対象読者としては、同じようにソフトウェア開発を出自とした方で、「同じような失敗経験のある方」「これから失敗を経験するであろう方」を想定しています。連載の前提条件の詳細、免責事項などについては、第1回の冒頭を併せて参照ください。 トレードオフが生じる場面 今回は意思決定について扱います。たとえステークホルダーの協力を引き出し、どれだけ試行錯誤しても、どこかでトレードオフが生じることになります。関係者全員が問題と向き合い、議論を整理した上で、それでも一つの結論にならないという場面が訪れます。そこではプロダクトマネージャーとして意思決定を求められます。 画面に表示するテキ
技術部門にOKRを導入したら3ヶ月で部の雰囲気がめちゃくちゃ良くなった話 - Qiita
こんにちは、食べログシステム本部本部長代理の京和と言います。今年の7月から食べログにジョインし、10月に技術部という部署を新設しました。技術部はSREチーム、QAチーム、マイクロサービスチーム、DX(Developer Experience)チームの4チームで構成されています。 本エントリでは技術部におけるOKRの導入事例について紹介します。 目的と背景 一定規模以上のサービスではよくあることですが、食べログではプロダクトや組織の成長に伴い日々の運用業務の負荷が高くなった結果、既存システムの抜本的な改善のための時間を取ることができず、システムのレガシー化や技術的負債が徐々に蓄積していく課題がありました。 少し抽象化すると、組織の構造的な課題によって技術負債が生まれており、技術負債を解消していくためには、まず組織課題を解消することが必要でした。これらの課題に対して、横串でシステムを見ることの
データ組織のトポロジー｜Jun Ernesto Okumura
この記事について最近発売された『チームトポロジー』（以後、本書）を読んだのですが、チーム体制やコミュニケーションの設計について汎用的にまとめられていてとても良い読書体験でした。私自身、データ組織をどのように設計していくか日頃考えており、本書を読み進めながら、考えが構造化され、課題の解像度が高まった気がします。 現在、私は株式会社エウレカで、BIチーム（分析チーム）、AIチーム、Data Managementチーム（データ基盤チーム）、の3チームのマネジメントをしています。日々生まれるデータを価値に転換し、同時にプライバシーやセキュリティなどのガバナンスを徹底するために、全社的なデータ戦略を推進していく立場です。大雑把に「データ活用」と括ってしまいましたが、意思決定をサポートするのための活動（BI）、ユーザー向けの機能開発を伴う活動（AI）、それらの活動を効率よく進めるための活動（Data
技術的負債は開発者体験を悪化させる - mtx2s’s blog
ソフトウェアエンジニアにとって、技術的負債が増え続けるソフトウェアプロダクト開発現場に身を置くことがどれほど苦痛なことであるか。エンジニアリング組織のマネジメントを長年担ってきて、それは強く感じるところだ。 中途採用の選考プロセスに面接官として参加し、これまで数多くの退職理由を見聞きしてきた。その中で、レガシーシステムをリファクタリング・リアーキテクティング・リライトできないことへの不満を理由として挙げるエンジニアは多かったように思う。裏を返せば、自社のソフトウェアプロダクトが技術的負債にまみれたまま放置されているなら、優秀な人材が他社に流出するリスクがあると認識すべきだ。 本稿では、技術的負債と開発者体験の関係について紐解くとともに、それに対してソフトウェアエンジニアリング組織を預かるマネージャーが取るべき行動について考えてみたい。 ※これは、Engineering Manager Ad
SRE チームで Engineering Manager になって二ヶ月経っての心境など - ツナワタリマイライフ
この記事は前任 EM の yuya-takeyama の記事へのアンサーソングであり、 blog.yuyat.jp Engineering Manager Advent Calendar 2021 その2 2日目の記事として寄稿します。 qiita.com 背景 僕は引用記事の SRE チームの Software Enginner でした。ひょんなことから前任が別のミッションを担うことになり、このチームの後任としてどうか、となり 2021年10月より同チームの Engineering Manager をやっています。 以下、引用したりしなかったりしてこの2ヶ月の心境などを語っていきます。 Engineering Manager として置かれている状況 先ほど言った経緯に引き続き、情報的な話でいうと 自分含め7人のチーム もともと中途採用をしていた会社でもあり、自走可能なメンバーで構成されて
自走する組織に必要なのはルールではなくガイドライン
ということをいつも心がけている、という話です。 僕が組織のマネジメント職を20年ほどやらせてもらっている上で、いつも意識しているのは権限移譲とセルフマネジメントです。この辺の話は過去のブログにも書きました。管理職のためのエンジニア組織構築マニュアル管理職のための役職引退マニュアル現場に口を出さないマネージャーの作り方つまり「権限と裁量を同時に移譲し、責任感を持ってプロアクティブに仕事をしてもらいながらも、メンバーの良いところを更に引き出して高いパフォーマンスを出してもらう」ことこそが、マネジメント職のやるべきことだと思っています。 そのために僕がいつも権限移譲の際に伝えるのは、ルールではなくガイドラインです。ルールは規則や規定といった決まりごとなので「やること」「やってはいけないこと」が書かれたものです。ガイドラインは大まかな指針なので「方向性」「やったほうがいいこと」「やらないほうがいい
ラクスにおける「システムを腐敗させない組織だった技術刷新」を行う取り組み - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは。 株式会社ラクスで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（@moomooya）です。 ラクスの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「技術推進プロジェクト」というプロジェクトがあります。 以前、社外の方にこの取り組みについて紹介した際に好意的な反応を得られたので、この場でも紹介してみようと思います。 取り組みの発端 これまでの軌跡 継続のための試行錯誤 割り込み作業対策 認知度向上 取り組みのサイクル 大まかな進め方 おわりに ――この取組のつらみ 成果が出るまで時間がかかる 知見がいくらあっても足りない 取り組みの発端 ことの発端――と言っても何か目立った事件が起きたわけではないのですが、今から4年前
エンジニアリングマネージャーとしての開発力向上の取り組みついて - Qiita
スクワッド体制における留意点として、「Spotifyは "Spotifyモデル "を使っていない [3]」で以下のように述べられているように、単に方法論を真似るのではく、自分の組織と向き合い、学習して、進化し続けることが大切であると思います。READYFORにおいても日々、組織体制について議論し、改善を進めています。 ビジネスユニット、部門、チーム、マネージャーは、Spotifyの失敗した方法論に固執してはいけません。彼らはSptifyのモノマネよりも効果的に組織構造の役割と責任を伝えることができるのです。 あなたがSpotify Modelを見つけたのは、自分のチームをどのように構成するかをいつも考えていたからでしょう。でもここで止まってはいけません。学習を続けてください。 1-2. READYFORのスクワッド体制 READYFORの場合、どのようなスクワッド体制を敷いているか？ ひと
Data Management Guide - 事業成長を支えるデータ基盤のDev&Ops #TechMar / 20211210
---------------------------------------------------------------------------------------- 【PR】一緒に働きましょう！ https://kazaneya.com/kdec ---------------------------------------------------------------------------------------- 「Tech × Marketing Conference 2021 #データマネジメント」基調講演の登壇資料です。 https://techxmarketing.connpass.com/event/229173/ データ活用やDXが注目されている一方で、実際にプロジェクトを進めようとすると「必要なデータが入力されていない」「用途を実現できるほどデータ品質が高
1on1の効果を高める3つの技法 - NTT Communications Engineers' Blog
この記事は NTTコミュニケーションズ Advent Calendar 2021 の11日目の記事です。 はじめに ヒューマンリソース部の岩瀬(@iwashi86)です。普段は、全社の人材開発・組織開発を推進しており、業務の1つとして、"1on1" の全社展開をしております。 本記事では、その"1on1"の効果を高める具体的な技法を紹介いたします。アドベントカレンダーということで、ゆるめに書いてみます。*1 NTT Com における1on1の目的とは？ 技法を説明する前に、1on1の目的について説明します。技法はあくまで目的達成に向けたHowでしかないためです。 1on1の目的とは何でしょうか？1on1それ自体には、複数の目的が挙げられます。代表的なところで言えば次のようなものでしょうか。 信頼関係の構築 離職率の低下 メンバー育成 目標達成へ向けた支援 etc... どれが正解というもの
システム開発で曖昧な要望を形にしていく方法 - arclamp
このブログはグロースエクスパートナーズ Advent Calendar 2021の10日目です。 社内メンバーから要望があったので、僕自身がどのようにシステム開発の初期段階において、どのように要望を整理し、形にしていっているのかについて書きたいと思います。 なお内容は弊グループの案件を前提にしているので、システム開発は以下のような状況が一般的です。 クライアントは直接契約（プライム） 要望を出すのはクライアント企業内で事業運営側の人で、システム開発にかかわった経験がないことがある 対象システムはSoE/mode2で、一般消費者や取引先などの外部ユーザーと、社内で業務を回す内部ユーザーがいる 相手の話を整理するフレーム まず、相手から得られる情報を4つの階層にわけて整理する必要があります。 目的：達成すべきこと 戦略：目的を確実・効率的に達成するためのシナリオ 戦術：戦略を実行するための具体
評価の満足度を劇的にあげた秘訣。Continuous Feedbackのすすめ | メルカリエンジニアリング
誰向けの記事？ EM（Engineering Manager）の方に向けた記事です。 ただ、一般的な評価者全般にあてはまる内容を書いているので、評価を行う方なら誰でも参考にできると思います。 評価をする側ではないけど、どんな気持ちで自分のマネージャーが評価しているのか知りたい！といったエンジニアの方にも楽しんでいただけるかもしれません。 要約 メルカリエンジニア組織で、評価の負荷を削減しつつ、品質をあげるために、「Continuous Feedback」という仕組みを導入しました。 Continuous Feedbackは、通常よりも高い頻度でフィードバックを行うことで、負荷分散や、フィードバックサイクルの高速化などをはかる手法です。 導入した結果、評価に対する満足度や、評価を自身の成長に使えてると感じるようになったメンバーがとても増えました。現在では多くのEMの方が、評価に利用してくれて
エンジニアのための「ミーティング・メモ」入門 - クラウドサービスとVSCodeを添えて - Lean Baseball
10月からコンサルタントに出戻りしたエンジニアです. 入社前に想定していた以上に毎日が楽しいです*1. それはさておき, つい先日に前職の同僚であるエンジニアリングマネージャーの@jazzsasoriさんとサシ飲みしたのですが, 「エンジニアリングマネージャーとかテックリードとかになると, 議事録（的なメモ）」を取る力無いと辛いよね, 案外言及されてないけど という話題になりました, 酔っ払ってあんまり覚えてないけど🍻*2 で, どれぐらいの方がこの話題に興味あるのかな?と気になり, 昨夜、久々に前職エンジニアリングマネージャー氏と飲んでて、何かの拍子に「エンジニアがビジネスな力をつける訓練の一つとして議事録書くのがいいんだよね」的な話をしたのですが 「エンジニアのための議事録書き入門」とかいうブログ記事って需要あると思いますか皆さん🤔— Shinichi Nakagawa / 中川
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発組織の持続可能性について
「界隈がざわつくほど超進化したPMBOK第7版」に私たちはどう取り組むか
EMことはじめ / How to start EM
