エンジニアが仕様案を手戻りさせるアンチパターンはもう終わりにしよう - yigarashiのブログ
2024/1/4 加筆修正を行いました 初稿を書いた後に、さらなる経験、色々な方との対話、各種資料を通じて考え方が更新された部分があったので加筆修正を行いました。主要なポイントは以下です。 仕様案の手戻りが発生しないようにエンジニアに積極的に情報を開示していくのはPOの重要なプラクティスであると分かったので、その考え方に沿って整理しなおしました POになりたてのいわゆるパニックゾーンにいる時に書いた文章で、全体的にエンジニアに責任を転嫁するニュアンスになっていたので修正しました プロダクト開発のアンチパターン プロダクトオーナー（PO）が仕様案を持ってリファインメントや計画に臨み、エンジニアが実現可能性や曖昧さの観点からダメ出しをして手戻りが起こる……スクラムやデュアルトラックアジャイルを志向する組織においては、一度は目にする光景だろうと思います。しかしこれは、以下のふたつの理由からひどい
エンジニアリングマネージャーの最初の学び - このロールは何なのか - yigarashiのブログ
2023/6/16付の人事異動で正式にエンジニアリングマネージャー（以下EM）になりました。2021/8に「エンジニアリングマネージャーを目指す若者の戦略」という記事を書いて明確にEMを目指し始め、2022/12には「EMキャリアを切り拓く「最強の現場リーダー」という働き方」という記事でEMに近づく様子を書きました。さらにそこから半年余り、ついに会社からも正式にEMと呼ばれることになりました。実際には3ヶ月ほど前から強くEMを志向した動きにはなっていましたが、やはり正式な職位は特別なもので、キャリアにおける重要な実績をひとつ解除したと感じています。 これほどEMというロールを志向し色々とやってきたのですから、EMとしての振る舞いもさぞスムーズに立ち上がるかと思いきや、実際にEMとして動くのは非常に難しいことでした。書籍やブログ記事を読んで頭で理解したEMという働き方と、自分がチームでEMと
マイスキルマップでエンジニアとしての己を見つめ直す - yigarashiのブログ
最近テックリードのロールを手放し、働き方がEMに近づいた。折に触れてEMになりたいと言ってきたが、だからと言って最初からうまくできるわけもなく、ここ1ヶ月くらいは悶々としながら過ごしている。特に今回困ったのは、自分の現在地がぼんやりしていて漠然と据わりが悪い感触に苛まれている点だ。もう少し課題や方向性を精緻にして、自信を持って前進できる環境をつくりたい。その一環としてマイスキルマップを作ってみたので紹介する。 マイスキルマップへ至る思考 自分が大事にしている心構えのひとつに「練習していないことはできない」というのがある。十を知るには十を聞き、繰り返し実践することでしか一人前にはなれないという、ごくごく当たり前のことだ。この心構えでひとつひとつ丁寧にやっていくのが、ここ5、6年の自分の強みだと思っている。 しかしこの心構えを維持するのは簡単ではない。何かができるようになると、自分の能力のイメ
安定して成果を出せるエンジニアへの近道 - yigarashiのブログ
ソフトウェアエンジニアとして安定した成果を出したいと思っている人は多いでしょう。妥当な方針を危なげなく定め、素早く的確に実装し、滞りなく仕事を片付けていきたいものです。しかし、いつでもそのように成果を出せるようになるのは簡単ではありません。言語、ミドルウェア、クラウド、アーキテクチャと、身につけるべき知識が無限に並んでおり、それら全てに習熟する日は永遠に来ないとすら思えてきます。 にもかかわらず、この記事を読むみなさんの同僚には、安定して成果を出せるエンジニアが相当数いるだろうとも思います。これは一体どういうトリックなのでしょう。彼ら彼女らは全てを勉強しているのでしょうか。もちろんそれに近い研鑽を積んでいる人もいるでしょうが、多くの人はそこまでしていないと予想します。少なくとも僕はそこまでやっていませんが、技術面でもそこそこバリューを出して、テックリードを1年勤め上げました。この記事では、
エンジニアを増員するロジックについて考える - yigarashiのブログ
ソフトウェア開発で、より早くより多く価値を届けたいと考えた時、エンジニアの増員は有力な選択肢です。もちろん、人月の神話などで語られるように、人を増やしただけ線形に生産力が向上するというシンプルな世界ではありません。それでも多くの現場でエンジニアの増員が行われます。自分のチームでも、とりあえずエンジニアを増員すれば、いくつかの問題が解決してくれるような気もします。雑談ベースでメンターなどにこういう話を出してみるわけですが、改めて「なぜエンジニアを増員したいのか」と問われると、これが意外と広がりのある議論であることがわかってきました。本記事では、エンジニアを増員するロジックについて、自分が思考を広げられた範囲で書いてみます。 作り切りの場合は明快 まずエンジニア増員のロジックを素朴に立てられるのは作り切りの場合です。ある程度の規模のものを丸々作り切らないといけないケースです。締め切りがあること
エンジニアの異動は推奨すべきなのか？ - 組織の成長について考える - yigarashiのブログ
最近エンジニアの異動について軽く議論することがありました。自分はチームの安定性の側面からやや否定的な立場だったのですが、その議論で刺激を受けて周辺領域も含めて考え直したところ、組織の成長という軸で色々な知識がつながって面白かったのでまとめてみます。 議論の前提 異動も含めてエンジニア組織について考える時、まずは外せない前提がひとつあると思います。それは、安定したチームないしバリューストリームを維持することです。「チームトポロジー」の3章では以下の言葉を引用し、複雑なシステムの開発にはチームの効果的なパフォーマンスが欠かせないことを論じています。 ハイパフォーマンスなチームを解散するのは、単なる破壊行為では済まない。企業レベルのサイコパスと呼ぶべきものだ。 現代のソフトウェア開発の変化速度や複雑性に対処するには個人では限界があり、チームとしての活動が欠かせません。チームメンバー間で強い信頼関
エンジニアリングマネージャーを目指す若者の戦略 - yigarashiのブログ
企業でWebアプリケーションエンジニアとして働き始めて2年と4ヶ月ほど経ちました。様々な仕事を経て、自分が向いていることや楽しく感じることが徐々に明らかになり、数年後になりたい像がぼんやりと浮かび上がってきました。そして、その将来像が世間的には「エンジニアリングマネージャー」（以降EM）と呼ばれていることもわかってきました。この記事では、EMについて自分が周囲から受け取った知識を整理するとともに、そこに向けてどんな戦略を取ろうとしているかをまとめてみます。マネージャーというとネガティブなイメージも拭えませんが、EMは年を重ねて吸い込まれるものではなく、積極的に取りに行くに値する面白いポジションであると思います。この記事を読んでEMに魅力を感じる同世代の仲間が増えると嬉しく思います。 EMについての理解 エンジニアリングマネージャーという職務についてのオーバービューは、広木大地さんによるエン
KPTのKがいまいち膨らまないチームに贈るパワフルな質問 - yigarashiのブログ
ふりかえりでKPTのようなポジティブ/ネガティブな話題を出すような手法を使っていると、悪いところの掘り下げはサクサクできる一方で、良いところをうまく膨らませるのが意外と難しいように思います。書いた本人に話してもらって、ファシリテーターが「いいですね」とコメントして終わりとか、「コメントないですか」と聞いて誰も話さなくて終わりとか、そういった場面を見たことがある人は多いんじゃないかと思います。悪いところを解決するのは慣れていても、良いところを伸ばすための道具箱が空っぽという状態ですね。 そんなチームの最初の道具として次の質問を贈ります。 それがうまくいった要因は何かありますか？ これです。なんとかのひとつ覚えで良いので、ちょっとでも話が広がらないなと感じたら、まずはこれを聞いてみると良いです。この質問が優れているのは、出来事や本人の経験から単刀直入にプラクティスを抽出できることです。何か聞き
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
