yigarashiのブログ

学んだことや考えていることを書きます

スプリントをやめてゴールに熱中したっていい

最近、自分のチームがやっていて良いなーと思う開発プロセスを紹介します。そのチームにはスクラムで言うところのスプリントがありません。ふりかえりや定点観測のために定例イベントはありますが、そこに向けて何かを計画したり約束することはありません。…

EM of EMsになった - 現在の働き方とそこに至るキャリア戦略

EMキャリアの近況報告シリーズです。2024/4にEM of EMsになったので、現在の働き方やそこに至るキャリア戦略について書きます。これまでの様子は以下です。 エンジニアリングマネージャーを目指す若者の戦略 EMキャリアを切り拓く「最強の現場リーダー」とい…

「真摯な質問」のコツを知って誘導質問しない信頼できるマネージャーになる

「真摯な質問」は対話の基礎を成す重要な要素です。「組織を変える5つの対話(p.41)」では、真摯な質問の特徴を次のように挙げています。 本当に答えを知りたい。 答えを聞いて驚くことがあってもそれは当然である。 答えに応じて自分の考えや行動を変える…

経験学習のために「ブログ記事のネタ30個出す」が予想以上に良かった

経験学習サイクルとは、人の学習のモデルのひとつで、「経験」「内省」「概念化」「実践」の4ステップを繰り返して学ぶというものです。本記事では、「ブログ記事のネタを30個出す」というアクティビティが予想以上に経験学習に有用で面白い体験につながった…

EMがユーザーインタビューをやって生まれたバリュー

わたしは現在、新規事業チームのEMをやっています。その仕事の中でユーザーインタビューが自分の得意技になりつつあり、思わぬ形でEMとしてのバリューを高めることができています。「XXもやるYY」というのはエンジニア界隈で良くある売り文句ですが、「ユー…

事業を深く理解しOODAループを回しまくる最近の自分のEM像に至るまで

はじめに これまで自分のEMとしてのキャリアや考え方の変化について書き留めてきました。 エンジニアリングマネージャーを目指す若者の戦略 EMキャリアを切り拓く「最強の現場リーダー」という働き方 エンジニアリングマネージャーの最初の学び - このロール…

エンジニアが仕様案を手戻りさせるアンチパターンはもう終わりにしよう

2024/1/4 加筆修正を行いました 初稿を書いた後に、さらなる経験、色々な方との対話、各種資料を通じて考え方が更新された部分があったので加筆修正を行いました。主要なポイントは以下です。 仕様案の手戻りが発生しないようにエンジニアに積極的に情報を開…

OpenTelemetryをざっくり学んだ

OpenTelemetryについての情報を見聞きする頻度がどんどん上がっており、各種サーバー監視サービスやクラウドでも対応が進んでいることから、そろそろ自分の引き出しに入れたいと感じました。概要を自分で説明できるくらいを目指してざっくり学んだログを自分…

パスキーが快適すぎる

パスワードレスな認証方式である「パスキー」が急速に普及しています。OS、ブラウザ、パスワード管理ツール、サービス提供者のどれもが整いつつあり、ついに本当にパスワードが必要ない世界がやってきたことを感じます。この記事では、本腰を入れてパスキー…

「 ITエンジニア採用入門」を読んで採用活動の全体像を学ぶ

最近エンジニア採用に関わる機会が増えました。エンジニアリングマネージャーとして、採用プロセス全体を機能させチームを組成する能力を獲得したいと考えており、その足掛かりとして面接官の役割を積極的にアサインしてもらっています。それなりの件数をこ…

エンジニアリングマネージャーの最初の学び - このロールは何なのか

2023/6/16付の人事異動で正式にエンジニアリングマネージャー(以下EM)になりました。2021/8に「エンジニアリングマネージャーを目指す若者の戦略」という記事を書いて明確にEMを目指し始め、2022/12には「EMキャリアを切り拓く「最強の現場リーダー」とい…

開発手法「カンバン」について学んだ 〜スクラム実践者の考察を添えて〜

自分のチームでスクラムからカンバンへ移行する機運が高まっており、本格的な取り組みに向けてザッと勉強したのでまとめる。 カンバンとは カンバンとはトヨタ生産方式に由来するソフトウェア開発手法(ないし、より広く適用可能なプロジェクト管理手法)の…

マイスキルマップでエンジニアとしての己を見つめ直す

最近テックリードのロールを手放し、働き方がEMに近づいた。折に触れてEMになりたいと言ってきたが、だからと言って最初からうまくできるわけもなく、ここ1ヶ月くらいは悶々としながら過ごしている。特に今回困ったのは、自分の現在地がぼんやりしていて漠然…

安定して成果を出せるエンジニアへの近道

ソフトウェアエンジニアとして安定した成果を出したいと思っている人は多いでしょう。妥当な方針を危なげなく定め、素早く的確に実装し、滞りなく仕事を片付けていきたいものです。しかし、いつでもそのように成果を出せるようになるのは簡単ではありません…

プロダクト開発チームの分断に立ち向かう

先日のRSGT2023で以下の発表がありました。「自分がそれほどプロダクト開発に興味がないことに気づく」は自分自身にも心当たりがありますし、プロダクト開発チームのリアルを言語化した発表だと思いました。この発表では、そうした言語化を受けてどうするの…

エンジニアを増員するロジックについて考える

ソフトウェア開発で、より早くより多く価値を届けたいと考えた時、エンジニアの増員は有力な選択肢です。もちろん、人月の神話などで語られるように、人を増やしただけ線形に生産力が向上するというシンプルな世界ではありません。それでも多くの現場でエン…

EMキャリアを切り拓く「最強の現場リーダー」という働き方

このエントリはEngineering Manager Advent Calendar 202213日目の記事です。 まえがき このエントリは、以下のPodcastで話した内容を掘り下げて整理したものです。Podcastの方では本エントリで触れていないチームの具体的な様子等についても話しているので…

スクラムチームを3年リードして得た学びと目線

この記事ははてなエンジニア Advent Calendar 20227日目の記事です。 昨日は id:utgwkk さんでした。 さて、今日はスクラムの話です。スクラムの導入とリードは自分のキャリアにおける重要な仕事のひとつで、気づけば3年ほどスクラムと取っ組み合ってきまし…

段取りとマイクロマネジメントとスクラム

仕事ができるエンジニアはだいたい段取りがうまい。達成したいゴールがあるときに、AとBとCをやる必要があって、Bはわからないことが多いから先にやろうとか、AとCは並行してできるからCを誰かにお願いしようとか、とにかく目標を達成するための道のりをうま…

プロダクトの非機能的な改善の工数をどう確保するか

プロダクトの非機能的な改善をビジネスの中でどのように進めるかは、多くのチームが頭を悩ませる課題であると思います。本記事では私が最近考えていることをまとめてみようと思います。主に自社プロダクトの継続開発を想定した議論をします。 前提 まず非機…

User Agent文字列を使ったブラウザ判定の事例 2022年版

やむを得ず、User Agent文字列を使って特定のブラウザ向けにJavaScriptの処理を分岐する必要が生まれてしまったので、調査・検討のログを記事にまとめます。 基本的にはバッドプラクティスである ユーザーエージェント文字列を用いたブラウザーの判定 - HTTP…

Four Keysがなぜ重要なのか - 開発チームのパフォーマンスを改善する方法について

ソフトウェアエンジニアとして働き始めて以来、ずっとソフトウェアデリバリーのパフォーマンスに興味を持って、さまざまな改善活動をしてきた。当初はスクラムを中心としたプロセスの改善に注力したが、最近はチームの成熟に伴って技術的なプラクティスに興…

スキルマップに採用する予定の技術も書いてみている

スキルマップとは スキルマップは、チームで使っている技術を各メンバーがどのくらい習得しているかを集計したものです。スプレッドシートで表を書いてメンテナンスしているチームが多いのではないかと思います。このアクティビティのメリットは以下のような…

「職能横断チーム」の実践におけるアンチパターンと対策

近年のアジャイルムーブメントにおいて「職能横断チーム」は当たり前の概念になっています。ユーザーに価値を届けるのに必要なあらゆる機能をチームが備え自律的にコントロールすることで、リードタイムを短縮するとともに、イノベーションが起こりやすい環…

チームのベロシティを上げる vs. 安定させる

タイトルの議論はよく見られるもので、スクラムコーチの間ですら(一見すると)意見が分かれることがあるようです。自分は「安定させる」派だったのですが、CSPO研修を受講したチームのPOが「上げる」派のコーチングを受けてきて、改めてチームとしてどうい…

チームが重要な目標にリソースを使えているか可視化する

リソースを集中させるのは難しい プロダクト作りにおいては、一番効果が高いところにリソースを集中しリードタイムを縮めるのが良いとされています。スクラムをやっているなら、ただひとつのプロダクトゴールが掲げられていて、そのためのプロダクトバックロ…

がんばりすぎないふりかえりのススメ

がんばりすぎてふりかえりを嫌いになった 自分たちのやりかたを検査して改善するふりかえり。巷には様々な思想やフレークワークが出回っています。チームからうまく情報を引き出したり、教訓に昇華したり、SMARTなアクションを設定することも大事です。そう…

高すぎる認知負荷が生むサービスの袋小路とエンジニアリングマネージャーの役割

最近流行りの「チームトポロジー」では、フローが改善するようにチームの認知負荷をコントロールすることが述べられています。そのためには組織とアーキテクチャをうまく変化させていく必要があり、いくつか主要な考え方やパターンが紹介されています。詳し…

「エラスティックリーダーシップ」でソフトウェア開発をうまくリードする方法を考える

僕にはリーダーシップがわからない。しかし無策で取り組むべきでないことだけはわかる。 ということで、自分の周囲で共通言語としてよく参照されている「エラスティックリーダーシップ」を読むことにした。自分は新米リーダーとして困りをたくさん抱えている…

テックリードとしてシステムの未来を示して品質の期待を合わせる

最近チームのテックリードを拝命して、テクノロジーマネジメント領域もリードすることになりました。興味の中心は開発プロセスやデリバリーで、エンジニアリングはまだまだひよっこなので苦労の日々が続いています。この記事では新米テックリードとしての取…