エンジニアリングマネージャーの最初の学び - このロールは何なのか - yigarashiのブログ
2023/6/16付の人事異動で正式にエンジニアリングマネージャー（以下EM）になりました。2021/8に「エンジニアリングマネージャーを目指す若者の戦略」という記事を書いて明確にEMを目指し始め、2022/12には「EMキャリアを切り拓く「最強の現場リーダー」という働き方」という記事でEMに近づく様子を書きました。さらにそこから半年余り、ついに会社からも正式にEMと呼ばれることになりました。実際には3ヶ月ほど前から強くEMを志向した動きにはなっていましたが、やはり正式な職位は特別なもので、キャリアにおける重要な実績をひとつ解除したと感じています。 これほどEMというロールを志向し色々とやってきたのですから、EMとしての振る舞いもさぞスムーズに立ち上がるかと思いきや、実際にEMとして動くのは非常に難しいことでした。書籍やブログ記事を読んで頭で理解したEMという働き方と、自分がチームでEMと
スクラムチームを3年リードして得た学びと目線 - yigarashiのブログ
この記事ははてなエンジニア Advent Calendar 20227日目の記事です。 昨日は id:utgwkk さんでした。 さて、今日はスクラムの話です。スクラムの導入とリードは自分のキャリアにおける重要な仕事のひとつで、気づけば3年ほどスクラムと取っ組み合ってきました。ここ1年くらいで、ようやく安定してテンポ良く開発が回るようになって、大仕事に一区切りついたような気持ちでいます。そうして少し肩の力が抜けた結果、最近はスクラムというフレームワークから一歩引いた位置に自分の目線が移動しつつある気がしています。自分の考えのスナップショットを取るには絶好のタイミングと思われるので、スクラムについての学びや、自分のスクラムに対する目線をまとめてみようと思います。 スクラム導入のキモ まずは、自分が経験したり見聞きした様子から、スクラム導入のキモだと思う点を2つほど書いてみます。どちらも越えが
段取りとマイクロマネジメントとスクラム - yigarashiのブログ
仕事ができるエンジニアはだいたい段取りがうまい。達成したいゴールがあるときに、AとBとCをやる必要があって、Bはわからないことが多いから先にやろうとか、AとCは並行してできるからCを誰かにお願いしようとか、とにかく目標を達成するための道のりをうまく計画できる人が多い。こういう作業をそつなくこなせるかが、ジュニアと一人前を区別する重要な指標のひとつと言える。そしてこの段取りをうまくできない人に対して、細かい計画を立ててあげて指示をするのがマイクロマネジメントだと思う。 スクラムにおけるスプリントプランニングは、この段取りをチームでやると思うとよく腹落ちする。達成したいゴールとしていくつかのプロダクトバックログアイテムを置いて、その達成に必要な作業を半日から1日で終わるサイズのタスクにみんなで分解して、不明点を一緒に洗い出して、どういう順番でやっていくか計画を立てる。まさに段取りだ。これがスク
Four Keysがなぜ重要なのか - 開発チームのパフォーマンスを改善する方法について - yigarashiのブログ
ソフトウェアエンジニアとして働き始めて以来、ずっとソフトウェアデリバリーのパフォーマンスに興味を持って、さまざまな改善活動をしてきた。当初はスクラムを中心としたプロセスの改善に注力したが、最近はチームの成熟に伴って技術的なプラクティスに興味が移りつつある。より広い視点からデリバリーについて考えるのは非常に楽しい仕事だ。 デリバリーのパフォーマンスを改善していくには、定量指標として確立されたFour Keysを計測し改善するのが業界標準となりつつある。恥ずかしながら、私はこれまでこのFour Keysが腹落ちせず、積極的に計測してこなかった。しかし、多方面に興味が向いて知識や経験が蓄積するにつれて、猛烈にFour Keysの重要性が腹落ちしてきた。この記事では、現時点における自分のFour Keysに関する理解と解釈を整理してみようと思う。 Four Keysとは Four Keysの妥当性
スキルマップに採用する予定の技術も書いてみている - yigarashiのブログ
スキルマップとは スキルマップは、チームで使っている技術を各メンバーがどのくらい習得しているかを集計したものです。スプレッドシートで表を書いてメンテナンスしているチームが多いのではないかと思います。このアクティビティのメリットは以下のようなものがあります。 チームで属人化している領域を可視化できる チームが使っている技術を一覧する機会になる 各メンバーの能力開発の資料になる スキルマップはいまつかっている技術を一覧するのが一般的ですが、今回はそこに未来の話も混ぜてみているという話です。 問題意識 こうした発想に至る問題意識は大きく分けてふたつあります。 ひとつは、いま使っている技術だけを見ていると、メンバーのスキルビルドの道筋が難しいことが挙げられます。特に長く運用されているサービスでは、どうしても技術の新陳代謝のスピードに限界があり、スキルマップに一世代前の技術が並んでしまうことが多いと
高すぎる認知負荷が生むサービスの袋小路とエンジニアリングマネージャーの役割 - yigarashiのブログ
最近流行りの「チームトポロジー」では、フローが改善するようにチームの認知負荷をコントロールすることが述べられています。そのためには組織とアーキテクチャをうまく変化させていく必要があり、いくつか主要な考え方やパターンが紹介されています。詳しく知りたい方は以下の資料を読むと良いです。 【資料公開】30分で分かった気になるチームトポロジー | Ryuzee.com この資料は2022年3月16日の「チームトポロジーを成功させる実践方法の探求」というイベントの発表資料です。このイベントでは、上記の解説に加えて、イベント共催企業で実際にチームトポロジーを適用した様子も紹介されました。それが以下です。 チームトポロジーを成功させる実践方法の探求 - Team Topologies Study、登壇資料 課題の言語化が上手く、しかも実際に素早く変化しており、「とても敵わないな」というのが率直な感想でした
テックリードとしてシステムの未来を示して品質の期待を合わせる - yigarashiのブログ
最近チームのテックリードを拝命して、テクノロジーマネジメント領域もリードすることになりました。興味の中心は開発プロセスやデリバリーで、エンジニアリングはまだまだひよっこなので苦労の日々が続いています。この記事では新米テックリードとしての取り組みをひとつ紹介します。 私のチームでは10個近いコンポーネントのオーナーシップを持っています。それらの品質の期待度は大きく異なり、変更頻度、採用技術、システムに占める重要度といったパラメータから決定されます。この期待を見誤ると、変更頻度が極めて低いコンポーネントを頑張ってリファクタリングしたり、モダンな技術が採用され寿命の長いシステムを雑に拡張したりと、成果の小さいアクションを取ってしまいます。逆にこの期待を適切に捉えられると、チームのリソースがコスパが高いアクションに向かっていくことが期待できます。変更頻度の高いコンポーネントのCI/CDを改善し、重
計画は総量を増やす！ - プロジェクト進行と計画の量のイメージ - yigarashiのブログ
※本記事では継続開発をしているスクラムチームがまとまった機能をリリースする状況を想像してください。関係者は多くとも10人程度で、期間は3ヶ月程度のシンプルなものです。 プロジェクトのフェーズごとに適切な計画の量をイメージして共有できると上手くいく手応えがあり、それをチームに展開した時の様子を書こうと思います。自分が陥った失敗ケースも示すので参考にしてください。おそらくスクラム初心者が陥りがちな罠だと思います。 ウォーターフォール まずは手慣らしです。古典的なウォーターフォールだと計画の量はこんなイメージです。 開発開始時に一気に計画を行い、開発がスタートすると再計画はほとんど行われません。リリースが近くなると、結合したりQAが走ったりして色々な問題が明らかになるので対処するための計画が発生します。この図のように後ろの山が小さく収まることは珍しく、実際は開発期間中にたまりにたまった問題が溢れ
エンジニアの異動は推奨すべきなのか？ - 組織の成長について考える - yigarashiのブログ
最近エンジニアの異動について軽く議論することがありました。自分はチームの安定性の側面からやや否定的な立場だったのですが、その議論で刺激を受けて周辺領域も含めて考え直したところ、組織の成長という軸で色々な知識がつながって面白かったのでまとめてみます。 議論の前提 異動も含めてエンジニア組織について考える時、まずは外せない前提がひとつあると思います。それは、安定したチームないしバリューストリームを維持することです。「チームトポロジー」の3章では以下の言葉を引用し、複雑なシステムの開発にはチームの効果的なパフォーマンスが欠かせないことを論じています。 ハイパフォーマンスなチームを解散するのは、単なる破壊行為では済まない。企業レベルのサイコパスと呼ぶべきものだ。 現代のソフトウェア開発の変化速度や複雑性に対処するには個人では限界があり、チームとしての活動が欠かせません。チームメンバー間で強い信頼関
漸進的型付けの未来を考える - yigarashiのブログ
この記事はCAMPHOR- Advent Calendar 2017 11日目の記事です． アブストラクト 漸進的型付けは，ひとつの言語の中で静的型付けと動的型付けをスムーズに組み合わせるための技術です． よく知られた特徴は any 型を使った静的型付けで， TypeScript や Python といったプログラミング言語には既に実装されています． しかし，理論と実際のプログラミング言語の間には大きなギャップが存在します． 特に，漸進的型付けの理論で提案されているキャストを用いた動的型検査が実装されていないために， 静的型付けの恩恵を十分に得られていないという問題があります． この記事では，まず漸進的型付けの理論をコード例を用いて紹介し， 現状の漸進的型付き言語が抱える問題を解説します． そのあとで，漸進的型付き言語が目指すべき目標を理論的視点から論じます． それらの目標は，静的型付けを
エンジニアリングマネージャーを目指す若者の戦略 - yigarashiのブログ
企業でWebアプリケーションエンジニアとして働き始めて2年と4ヶ月ほど経ちました。様々な仕事を経て、自分が向いていることや楽しく感じることが徐々に明らかになり、数年後になりたい像がぼんやりと浮かび上がってきました。そして、その将来像が世間的には「エンジニアリングマネージャー」（以降EM）と呼ばれていることもわかってきました。この記事では、EMについて自分が周囲から受け取った知識を整理するとともに、そこに向けてどんな戦略を取ろうとしているかをまとめてみます。マネージャーというとネガティブなイメージも拭えませんが、EMは年を重ねて吸い込まれるものではなく、積極的に取りに行くに値する面白いポジションであると思います。この記事を読んでEMに魅力を感じる同世代の仲間が増えると嬉しく思います。 EMについての理解 エンジニアリングマネージャーという職務についてのオーバービューは、広木大地さんによるエン
アジャイルなチームとアジャイルなデリバリーの仕組み - yigarashiのブログ
最近少しずつアジャイル開発の解像度を上げようとしていて、それが少し整理されてきたのでざっくり考えていることをまとめてみようと思います。 アジャイル開発をやりたいと言った時、取り組むべき領域は大きく2つに分けられると思います。それはデリバリーの仕組みとチームの2つです。そしてそれぞれに段階や考えるべきことがあると思います。 アジャイルなデリバリーの仕組み アジャイル開発の大筋は、作ったものに対していち早くフィードバックを集め学習しプロダクトに反映することです。そのために、スクラムをはじめとしたイテレーティブな開発プロセスによって軌道修正の機会を増やしたり、CI/CDの整備のようなエクストリームプログラミングのプラクティスによってイテレーティブな開発にかかるコストを小さくしたりといった、仕組みの整備が広く語られています。アジャイル開発というとまずこういった話題を思い浮かべる人が多いでしょうし、
エンジニア8人チームで"効果的に"タスクをアサインするために検討した8つの軸 - yigarashiのブログ
最近、締め切りのある大きめなプロジェクトでWebアプリケーションエンジニア兼プロジェクトマネージャーとして仕事をしました。一年目なので当然プロジェクト管理の経験はなく、本を読んで知識を得たり、チームメンバーに助けられたりと、だいぶ手探りでの挑戦となりました。その中でもっとも難しかった仕事の一つとして、タスクの効果的なアサインがあります。 エンジニアは最大8人おり、その技術力、ドメイン知識、勤務地などは多岐に渡ります。ウォーターフォール的な開発だったため、タスクは事前に洗い出されており、タスク管理ツール上に無数に登録されていました。適当に人とタスクを辞書順でソートしてアサインするだけなら簡単ですが、現実はそうもいきません。締め切りは厳しく、チームの生産性を少しでも高く維持しなければいけません。メンバーのモチベーションが下がったり、依存の多いタスクが遅れたりといったことはなんとしても避けたいも
Apollo ClientのInMemoryCacheとMutationに関する調査・考察 - yigarashiのEMブログ
本記事は はてなエンジニアAdvent Calendar 2019 3日目のエントリーです。 はじめに Apollo Client （執筆時 v2.6.4）は、Apollo プラットフォームが提供する JavaScript で実装された GraphQL クライアントです。Apollo Client には InMemoryCache （執筆時 v1.6.3）という強力なキャッシュ機構が用意されており、クエリの結果をキャッシュすることができます。このキャッシュ機構は、多くの場面で API サーバーとの通信回数を削減しパフォーマンスの向上に貢献します。しかし、Mutation によるオブジェクトの作成・更新・削除を行う際には、Apollo Client を使う側がその変更をキャッシュに反映するよう意識する必要があります。例えば、オブジェクトAを含むリストがキャッシュされていたとして、オブジェクト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
