エンジニアが仕様案を手戻りさせるアンチパターンはもう終わりにしよう - yigarashiのブログ
プロダクト開発のアンチパターン プロダクトオーナー（PO）が仕様案を持ってリファインメントや計画に臨み、エンジニアが実現可能性や曖昧さの観点からダメ出しをして手戻りが起こる……スクラムやデュアルトラックアジャイルを志向する組織においては、一度は目にする光景だろうと思います。しかしこれは、以下のふたつの理由からひどいアンチパターンであると言えます。 ひとつには、仕様案を持って臨むPO側の精神的な負担があまりにも大きいやり方だからです。ちゃんとした仕事をしているPOならば、そもそも仕様案なんていう細かいところにたどり着くまでに、とてつもない量の不確実性を捌いてボロボロになっているのです。プロダクトのミッション、戦略、プロダクトゴール、ユーザーの課題、仮説検証の設計、MVPの特定、そういった大上段からのヘビーな分解を繰り返して、ようやくたどり着くのが具体的な仕様案なわけで、それを実装が難しいとか
パスキーが快適すぎる - yigarashiのブログ
パスワードレスな認証方式である「パスキー」が急速に普及しています。OS、ブラウザ、パスワード管理ツール、サービス提供者のどれもが整いつつあり、ついに本当にパスワードが必要ない世界がやってきたことを感じます。この記事では、本腰を入れてパスキーを使い始めて快適になるまでの様子をまとめます。技術的な厳密さ・網羅性には踏み込まず、いちユーザーとしての入門記事という位置付けです。 パスキーとは パスキー - Wikipedia 認証、セキュリティに関しては門外漢なので、Wikipediaのリンクを置いておきます。私よりはWikipediaのほうが信用に足るでしょう。 そこから辿れるホワイトペーパー：マルチデバイス対応FIDO認証資格情報を読むと、多少ストーリーもわかります。FIDO2というデバイスに格納された秘密鍵に依存したパスワードレス認証の仕様に、暗号鍵（と訳されていますが秘密鍵のことで良い……
エンジニアを増員するロジックについて考える - yigarashiのブログ
ソフトウェア開発で、より早くより多く価値を届けたいと考えた時、エンジニアの増員は有力な選択肢です。もちろん、人月の神話などで語られるように、人を増やしただけ線形に生産力が向上するというシンプルな世界ではありません。それでも多くの現場でエンジニアの増員が行われます。自分のチームでも、とりあえずエンジニアを増員すれば、いくつかの問題が解決してくれるような気もします。雑談ベースでメンターなどにこういう話を出してみるわけですが、改めて「なぜエンジニアを増員したいのか」と問われると、これが意外と広がりのある議論であることがわかってきました。本記事では、エンジニアを増員するロジックについて、自分が思考を広げられた範囲で書いてみます。 作り切りの場合は明快 まずエンジニア増員のロジックを素朴に立てられるのは作り切りの場合です。ある程度の規模のものを丸々作り切らないといけないケースです。締め切りがあること
EMキャリアを切り拓く「最強の現場リーダー」という働き方 - yigarashiのブログ
このエントリはEngineering Manager Advent Calendar 202213日目の記事です。 まえがき このエントリは、以下のPodcastで話した内容を掘り下げて整理したものです。Podcastの方では本エントリで触れていないチームの具体的な様子等についても話しているので、ぜひ合わせてお楽しみください！ はじめに 以前、エンジニアリングマネージャーを目指す若者の戦略というエントリを書きました。その時点でのエンジニアリングマネージャー（以下EM）というロールへの理解や、実際にEMを目指していくための戦略を整理したものです。 素晴らしいことに、このエントリの投稿からおよそ1年3ヶ月たった今も戦略は機能しており、ロールへの理解を深めつつキャリアを前進させることが出来ています。本エントリでは、EMというロールへの理解の変化や、EMを志向する過程で目指している「最強の現場リー
段取りとマイクロマネジメントとスクラム - yigarashiのブログ
仕事ができるエンジニアはだいたい段取りがうまい。達成したいゴールがあるときに、AとBとCをやる必要があって、Bはわからないことが多いから先にやろうとか、AとCは並行してできるからCを誰かにお願いしようとか、とにかく目標を達成するための道のりをうまく計画できる人が多い。こういう作業をそつなくこなせるかが、ジュニアと一人前を区別する重要な指標のひとつと言える。そしてこの段取りをうまくできない人に対して、細かい計画を立ててあげて指示をするのがマイクロマネジメントだと思う。 スクラムにおけるスプリントプランニングは、この段取りをチームでやると思うとよく腹落ちする。達成したいゴールとしていくつかのプロダクトバックログアイテムを置いて、その達成に必要な作業を半日から1日で終わるサイズのタスクにみんなで分解して、不明点を一緒に洗い出して、どういう順番でやっていくか計画を立てる。まさに段取りだ。これがスク
User Agent文字列を使ったブラウザ判定の事例 2022年版 - yigarashiのブログ
やむを得ず、User Agent文字列を使って特定のブラウザ向けにJavaScriptの処理を分岐する必要が生まれてしまったので、調査・検討のログを記事にまとめます。 基本的にはバッドプラクティスである ユーザーエージェント文字列を用いたブラウザーの判定 - HTTP | MDN まずはMDNがドキュメントを公開しているので読みましょう。要点は以下です。 基本的にUser Agent文字列に基づいて処理を出し分けるのはバッドプラクティス 多くのケースではUser Agent文字列を使うよりも良い手段がある 例えば特定の機能の実装状況に基づく分岐を行いたければそれを直接検出する それでもやむを得ない場合、User Agent文字列からブラウザ名、レンダリングエンジン、バージョン、OS、端末といった情報を取得することができる ただし各ブラウザのUser Agent文字列は嘘をついていることもあ
「職能横断チーム」の実践におけるアンチパターンと対策 - yigarashiのブログ
近年のアジャイルムーブメントにおいて「職能横断チーム」は当たり前の概念になっています。ユーザーに価値を届けるのに必要なあらゆる機能をチームが備え自律的にコントロールすることで、リードタイムを短縮するとともに、イノベーションが起こりやすい環境を作ることができます。しかしながら、7〜8人を超える大きめの集団になってくると、開発の効率を著しく下げるアンチパターンを踏んでしまうことがあります。 「職能横断チーム」の実践におけるアンチパターン そのアンチパターンとは「いつも全員一緒」です。バックエンドエンジニアだろうとアプリエンジニアだろうと、デザイナーだろうとプランナーだろうと関係なくとにかく全員です。サイロ化のカウンターとしての「職能横断チーム」に囚われ過ぎてしまって、チーム内に部分集合を作ることを極端に避けてしまっている状態です。その結果、10人もいる会を開いて細かい相談で時間が伸びたり、そも
チームのベロシティを上げる vs. 安定させる - yigarashiのブログ
タイトルの議論はよく見られるもので、スクラムコーチの間ですら（一見すると）意見が分かれることがあるようです。自分は「安定させる」派だったのですが、CSPO研修を受講したチームのPOが「上げる」派のコーチングを受けてきて、改めてチームとしてどういうスタンスを取るか考える機会を得ました。結論から言ってしまうと、そもそもこれは二項対立ではなく、「上げる」派の人も「（安定させた上で）上げる」と言っているだけで、単に目指している高さが違うだけだろうと解釈しました。その上で、チームの現状に合わせて適切な目標設定をすれば良いと考えました。以下でもう少し掘り下げてみます。 大前提 まずソフトウェア開発の大前提として、開発チームには常にベロシティを下げる方向に様々な力がかかっています。これは「変化」と呼ばれて恐れられ、プロダクトや開発チームに次々と襲い掛かります。例えば以下のようなものです。 市場が求めるも
がんばりすぎないふりかえりのススメ - yigarashiのブログ
がんばりすぎてふりかえりを嫌いになった 自分たちのやりかたを検査して改善するふりかえり。巷には様々な思想やフレークワークが出回っています。チームからうまく情報を引き出したり、教訓に昇華したり、SMARTなアクションを設定することも大事です。そういう情報がどんどん襲ってきて、しっかり会を設計してバリューの高いふりかえりをやらなければという気になってきます。 それで工夫して上手くいくなら良いですが、自分にとってはあまり良い道標として機能しませんでした。会を頑張って設計しても、そもそも参加者が喋ってくれなかったり、ファシリテーターと1対1の会話が起こるだけになったりして、手応えを得られないことが多くありました。それでもちゃんとバリューを出さなければと焦って、なんとかアクションをまとめたり、無理やり教訓ということにしてチームのドキュメントに追記したりしていました。そういうぎこちない会を回すのはとに
エンジニアの異動は推奨すべきなのか？ - 組織の成長について考える - yigarashiのブログ
最近エンジニアの異動について軽く議論することがありました。自分はチームの安定性の側面からやや否定的な立場だったのですが、その議論で刺激を受けて周辺領域も含めて考え直したところ、組織の成長という軸で色々な知識がつながって面白かったのでまとめてみます。 議論の前提 異動も含めてエンジニア組織について考える時、まずは外せない前提がひとつあると思います。それは、安定したチームないしバリューストリームを維持することです。「チームトポロジー」の3章では以下の言葉を引用し、複雑なシステムの開発にはチームの効果的なパフォーマンスが欠かせないことを論じています。 ハイパフォーマンスなチームを解散するのは、単なる破壊行為では済まない。企業レベルのサイコパスと呼ぶべきものだ。 現代のソフトウェア開発の変化速度や複雑性に対処するには個人では限界があり、チームとしての活動が欠かせません。チームメンバー間で強い信頼関
KPTのKがいまいち膨らまないチームに贈るパワフルな質問 - yigarashiのブログ
ふりかえりでKPTのようなポジティブ/ネガティブな話題を出すような手法を使っていると、悪いところの掘り下げはサクサクできる一方で、良いところをうまく膨らませるのが意外と難しいように思います。書いた本人に話してもらって、ファシリテーターが「いいですね」とコメントして終わりとか、「コメントないですか」と聞いて誰も話さなくて終わりとか、そういった場面を見たことがある人は多いんじゃないかと思います。悪いところを解決するのは慣れていても、良いところを伸ばすための道具箱が空っぽという状態ですね。 そんなチームの最初の道具として次の質問を贈ります。 それがうまくいった要因は何かありますか？ これです。なんとかのひとつ覚えで良いので、ちょっとでも話が広がらないなと感じたら、まずはこれを聞いてみると良いです。この質問が優れているのは、出来事や本人の経験から単刀直入にプラクティスを抽出できることです。何か聞き
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
