1on1の間は鏡になる メンティーの言うことを否定しない、肯定しない ただ受け入れる 理解と共感に努める 理解はMust 共感はNice to have 理解に努めると自然と話が広がり、深くなる ex. 「たとえばそれってどういうこと？」 ex. 「他にはどういう選択肢があった？」 理解したうえで共感までいけたらラッキー 無理に共感しなくても問題ない Why（意見）ではなく、What、When（事実）を聞く Whyはメンティーの意見・解釈を主観として尋ねる質問 自分の主観を他人に話すのは心理的ハードルが高い What, When, Whereは事実を言うだけなのでメンティーも客観的に思考しながら話せる ex. 「何がきっかけでこうなったんだろう？」 ex. 「そう思ったきっかけはどこから来てるんだろう？」 傾聴のためにメモを取る メモを取ることでちゃんと聴いてることをメンティーにアピール

現場で自ら考え、動いた経験は、たとえ失敗しても成長につながる。一律をやめ、一人ひとりがやりがいを持って働けるように、議論は熱を帯びていく。 ■考慮されにくい「ムリ」 ■数字は異常を知らせるもの ■孤立する若手 ■できないことの証明ほど、消耗して、虚しくなることはない ■組合からの提案 ■自動車産業の魅力を高めるために ■当たり前も疑い、思い切って変えていくとき 第2回の労使協議会（労使協）が2月28日、愛知県豊田市の本社で開催された。 第1回で挙がった主な課題は、次の通り。「生産性や能率など一律の目標、開発日程などに縛られた働き方となっていること」、「双方向でのコミュニケーション不足となっていること」その結果として「安全をベースとした優先順位の順守、人材育成に影響を及ぼしていること」だ。 労働組合の鬼頭圭介委員長は第2回の冒頭、これらについて「トヨタの根幹を揺るがしかねない課題」とし、現場

スクラムフェス福岡2024での講演資料です。 --- 皆さん、職場でFour Keysを導入していますか？ Yesと答えた皆さん、『LeanとDevOpsの科学』は読みましたか？ あくまで僕の周囲のみの観測で語るのですが、Four Keysを職場で導入しているという人はとても多いのですが、そのうち、出典である『LeanとDevOpsの科学』をきちんと読んだ人はかなり少ないようです。 そして、ここで敢えて強めの主張をするのですが 『LeanとDevOpsの科学』を読まずにFour Keysをきちんと利用することはほぼ不可能です。 Forsgrenらは徹底した研究の結果として4つのメトリクス（指標）を見出すのですが、その裏には彼女らの沢山の思いが詰まっています。その思いや彼女らの思考を理解し、彼女らの考えをきちんとトレースして始めて、Four Keysは意味を持ちます。 そして『LeanとDe

現状のLeanerがこういう価値観で組織づくりしているというだけで、今後も絶対これらのポジションをつくらないと思ってるわけではないです Leanerについて Leaner Technologiesは「調達のスタンダードを刷新し続ける」会社です。企業の購買や調達に関する業務を支援するBtoB SaaSスタートアップです。トヨタ自動車様 や 大手コンビニエンス企業様 など主にエンタープライズ領域に導入いただいて急成長してます。 「Leaner見積」 「Leaner購買」 の二つのプロダクトを開発・提供しています。 エンジニアメンバーは約15名ほどです。 なぜポジションがないのか そもそもなぜポジションがあるのかについて明確な理由が自分たちの中でありません。特定のポジションがあるとそのポジションを目指すことが社内で正当化されます。 Leanerは「調達のスタンダードを刷新し続ける」という大きなコ

Regional Scrum Gathering Tokyo 2024での講演資料です。 --- 2023年、ソフトウェア工学分野の論文誌であるTOSEM[1]、およびトップカンファレンスであるICSE 2023[2]に、スクラムに関する1本の論文が同時に採択されました。 僕は50ページを超えるその論文を読んで衝撃を受けました。こういう学会に投稿されるスクラム・アジャイルの論文は、アジャイル実践者の目線からするとあまりピンとこないものもあるのですが、この論文はまず、そういった点で一分のスキもありませんでした。 ただの研究者ではない、明らかにスクラム実践者が書いた論文でした。 一体誰が書いたのか、と思って調べてみると、2人の著者 Christiann Verwijs と Daniel Russo のうち、Christiaan Verwijsはあの『ゾンビスクラムサバイバルガイド』の著者の1人

弊社の伝説の開発のひとつ、スクラムの源流でもある、初代プリウスについて、当時の開発者たちが語る熱く、時には洩れる本音のトークを紹介します。また日本を代表するアジャイルコーチの皆さんと、温故知新の心構えでこれらを分析しました。開発者たちのトークに、いくつかの共通ワードが存在し、それがスクラムの源流と繋がっている所まで整理できたので解説します。更に、変化の時代、環境変化に対し、ハードウェア開発をどう進めるべきか？ いまどきの取り組みを現場の開発者たちの声と共にお届けいたします。本内容は、スクフェス三河「初代プリウスにみるアジャイル開発の要素と現代の環境での進め方について」の続編という位置付けになります。 / We will introduce passionate and occasionally candid discussions by the developers of our lege

依頼、調整、合意、承認、etc. こういったコミュニケーションがチーム境界を越えて頻発すると、ソフトウェアプロダクト開発のフローは遅々として進まなくなります。いずれも、機能追加や機能改善を進める上でのクリティカルパスを引き伸ばす要因を生み出すからです。 機能追加や機能改善といったひとつひとつの開発は、アイデアを生み出し、それを価値に変えるまでのフローです。フローが進む過程で、組織内の様々な人の手で、様々なタスクが実行されます。その全てを1つのチームで完結することは、プロダクトの規模が大きくなるほど困難になり、より多くの人々が関わるようになります。そこに、チーム境界を越えた「依頼、調整、合意、承認」といったコミュニケーションが発生するのです。 開発フローのクリティカルパスを悪化させるこのようなコミュニケーションの頻度をどれだけ減らせるか。組織設計、チーム設計で最も注視すべき観点の1つは、そこ

Have you been in any of these situations? Managers make decisions that’s out of their leagues and everyone else in the team ends up paying for it. Knowledgeable people passively observe without bothering to contribute. Sometimes they are denied access to the room. Developers act like code monkeys, throwing the code over a metaphorical wall for the QA to test and “DevOps” to run. In “you build it,

某社の人とカジュアル面談してて思ったのは、組織のトップに必要な才能は正解の意思決定ができることではなくて、決定したことのアカウンタビリティ（説明責任）を果たすこと。もっと大事なのは説明責任果たしてるなぁ、と周りに感じてもらえること。 — こくぼ (@yusuke_kokubo) September 13, 2022 別にトップじゃなくても、中間管理職でもチームのリーダーでも誰でも影響力を持っている立場なら同じことが言えると思います。 意思決定の是非は関係ない何に決めたかは（比較すると）そんな大事ではないです。重要なのは意思決定のプロセスです。決定に至るまでにどんな情報を取り入れたのか、ただの雰囲気や勘で決めたのか、些細なことでもオープンであること自体が重要です。 会社として重要な決定であればあるほど丁寧な説明が必要でしょう。 自分が意見・主張を持っている決定であればそのプロセスに少なからず

皆さん、こんにちは、こんばんは。エムスリーで執行役員VPoE兼PdM兼QA責任者兼デザイングループ担当役員をしている山崎です。エムスリーデジカルなど事業部門の責任者もやっています。 本日は、@iwashi86さんにお声がけ頂き、2/25（金）に収録して翌週3/2（水）に公開頂きましたfukabori.fmの「第68. エンジニアリング組織に溶け込むHRBP w/ yamamuteking」について補足記事を書きたいと思います。 fukabori.fm ちなみに、Podcastはこちら、Spotifyはこちらです^^。また、過去出演した第59回と第60回も人気とのことなのでリンクしておきます。 はじめに 昨今、戦略人事の文脈で新しい人事、人事組織のあり方が議論されています。Amazonで検索しても戦略人事関連の本は多数発刊されており、ハーバード・ビジネス・レビューでも人事、組織関連の特集は多

株式会社アンドパッドのアカウント基盤チームで認証基盤に関するエンジニアリングをしているid:shiba_yu36です。最近はチームのテックリードロールも担っています。 現在アンドパッドではFindy Teamsを導入し*1、生産性の可視化を行っています。自分は生産性向上のためのチーム改善に興味が強いため、2021/10に入社してからアカウント基盤チームのFindy Teams指標を観察し、チームのボトルネックを見極め、チームの生産性改善をしてきました。結果として、Findy Teamsの平均プルリク クローズ時間の指標が、チームに入った2021/10当時は120時間だったのが、現在は23時間ほどまで改善しました。今回はその様子について書きたいと思います。チーム改善の流れの一例として、参考にしてもらえればと思います。 チーム改善の全体的な流れ Findy Teamsで定量的にチームの生産性を

・・・ ・不確実性パフォーマンス・ドメインについて加筆しました ・テーラリングについて加筆しました ・適応課題について補足を追加しました。 はじめにPMBOKといえば、PMIが世界中のプロマネの実務家から意見を集めてプロジェクトマネジメントについて知識体系化している分厚い本、というイメージです。 いや、でした。。。以前の第6版までは（7版からはすごく薄い）。 2021年8月に第7版が発表されると（ただし、日本語版はもっと先）公式からアナウンスがありましたが、本家サイトに行ってみると英語版は既に購入できる状態でしたので早速電子版を購入し読みましたので解説したいと思います。 一応前置きしておきますと、僕はPMPホルダーではありません。外資系にいるときにPMBOKをベースとしたプロジェクトマネジメントを実施したり、国内企業ではCMMI レベル5（最高レベル）を運用したりバージョンアップ対応を経験

社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて

こんにちは、こくぼです。Leaner Technologiesという会社に入って2ヶ月経ちました。そろそろ桜の季節ですね、早いものです。 今日は入社してからの初仕事として取り組んだエンジニア組織のミッションとポリシーを言語化した話です。 この記事で伝えたいこと・ スタートアップを組織として成長させるには暗黙知を言語化しよう ・ 会社として大事な文化や価値観をエンジニア視点で見直すと発見がある ・暗黙知を言語化することで、各自がその会社で働く意味が見出せる 何をやったか ・ エンジニア組織のミッションとポリシーを言語化した ・ そのための調査と対話をした なぜやったかLeanerは2019年2月に創業したスタートアップです。創業からちょうど2年が経過して、創業期から成長期に入りはじめたフェーズです。 資金調達をして、事業のコアとなる仮説にも手応えを感じはじめ、これからプロダクト開発を本格化す

Leanerという会社がやってることは↑をみていただけると嬉しいです。 今日の本題: スタートアップの仮説検証 スタートアップではMVPをつくって仮説検証をするのが鉄則とされています。どの本にもMVPやプロトタイプをつくって仮説検証しましょう、と書かれています。 有名なエピソードだと、Zapposが靴の通販を始めた当初、アプリの表面だけつくって、注文を実際に受けてから人力で靴を仕入れて出荷していたことがよく言われていますし、Amazonも当初は注文を受けた本を人力で取次に注文して、ペゾスや創業メンバーが梱包して出荷していた話も有名です。 ユーザーからはWebなどのシステム上で全てが動いているように見えるのに、実際は裏側で人間が頑張ってる仕組みは「オズの魔法使い型MVP」として知られています。 プロダクトをつくる前に、その仮説が正しいのかちゃんと検証しましょう、という話です。 言うは易く行う

こんにちは。id:shiba_yu36です。MackerelチームでWebアプリケーションエンジニアをしています。最近の開発合宿で、id:syou6162やid:polamjagと一緒に、社内の全チームの開発パフォーマンスを表す指標をGitHubのPull Requestから可視化し、開発チームの改善に活かせるようにしました。今回はその紹介をします。 説明するサンプルコードは、次のレポジトリで公開しているので参考にしてください。ここではGitHubのhatenaオーガニゼーションで集計していますが、forkして少し手直しすれば、別のオーガニゼーションの集計も可能になっています。 hatena/pull-request-analysis-sample 開発チームの改善におけるいくつかの課題感 開発チームのパフォーマンス指標に何を使うか 4つの指標のうち何からまず集計するか 変更のリードタイム

[2020.12.8 追記] ブコメでEMが何かわからないと書かれていたので補足。EM = Engineering Managerです。EM菌ではありません！！！ [追記ここまで] 今の会社でお世話になったEMの人たちのマネジメントがとてもよかったので育休で全てを忘れる前にメモを残す。EMの話題はよく見かけるけれど、マネジメントされる側の視点で語られることがあまりなかった気がするのでいい記録になるかもしれない。 前提 自分: メンバー（マネジメントされる側）。Androidエンジニア。ある程度放置されても自走できる。 EM: 一人ではなく複数。（歴代という意味。同時に複数人のEMにマネジメントされたという意味ではない。）彼らはみなAndroidエンジニアではないがモバイルもしくはフロントエンドのエンジニア。なので技術の相談はしないが、開発業務そのものについてはとても詳しい。 組織: エンジ

スクラムガイド2020からは、IT以外の分野にも適用してもらいたいみたいなので、ソフトウェアに特化したものはできるだけ排除する（とはいえ、なかなか難しいね） スクラムガイドでは「我々は1990年代初頭にスクラムを開発した」とあるので、まずは当時の状況を把握しておくとよさそう。おおざっぱに言うと、ソフトウェア業界的にウォーターフォールじゃダメだという雰囲気になっていて、何かいい方法がないものか……とみんなが模索していた時代。 そこで、過去の文献を遡り、当時でも使える概念が発掘された。それが、以下の竹内・野中論文である。Jeff Sutherlandはここから「スクラム」という名前を拝借しており、両名は「スクラムの祖父」と称される。 Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard

まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを