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

先日のRSGT2023で以下の発表がありました。「自分がそれほどプロダクト開発に興味がないことに気づく」は自分自身にも心当たりがありますし、プロダクト開発チームのリアルを言語化した発表だと思いました。この発表では、そうした言語化を受けてどうするのかについては深く触れられておらず、回答は聴衆に委ねられていることから、さらに議論を広げてみようと思います。

実際問題、真に興味を持つのは大変

現代のプロダクトマネジメントは、ひとつの深遠な専門領域になっていると思います。「本が1冊書ける」なんてレベルではありません。何百冊、何千冊と書ける世界です。そうした専門知識を組み合わせ、市場とユーザーとプロダクトを徹底的に分析し、データに基づいて仮説検証を繰り返し、それを自分のプロダクトに接続する方法を捻り出して、ようやく少し尤もらしい方向に近づきます。とても過酷な領域です。

ここにエンジニアが越境して興味を持つのは大変なことだと思います。もちろん程度の差はあって、特にtoCのサービスなんかであれば、ドッグフーディングをして「こうした方が良いんじゃないか」と意見を持ったり、実際に工夫をして貢献できる人はたくさんいると思います。しかし、ユーザーインタビューの結果を分析して示唆を抽出したり、データ基盤を叩きまくって有力な仮説を捻り出したり、そういうプロダクトマネジメント的なやり方にまで興味を持ち、咀嚼し手を動かすとなると話は別です。エンジニアとしてキャリアを始めて、そういった部分にも「興味がある」と自認できる人はそう多くはないでしょう。多くのエンジニア組織がデリバリーマネジメントやピープルマネジメントを担う人材に困るのと同様のことがプロダクトマネジメントにも当てはまると思います。

興味がないものを興味を持てと言ったって仕方がないので、これは組織が認めなければいけない前提だろうと思います。プロダクト開発チームには基本的に分断する方向に力が加わっていて、自己組織化の文脈でチームにプロダクトマネジメント能力を実装するのも困難で、「じゃあどうする？」というのが議論の出発点ということです。

専門性は違うけど力を合わせる

件の発表においても、イシューからはじめよを引用して、解く問題の価値（ディスカバリー）と解き方の質（デリバリー）の両方が必要と論じています。プロダクト開発においてディスカバリーとデリバリーという大きなふたつの専門性があるのもまた真です。それをどのくらい重ね合わせられるかという問題に帰着すると、議論が整理されるように思います。

2つの専門性を全く重ね合わせないのが、まさに「分断」された状態です。デュアルトラックアジャイルを志向するチームが一度は通るアンチパターンではないかと思います。ウォーターフォール型の社内受託のような形になり、ディスカバリーからデリバリーへの接続が不快な行事になります。エンジニアは内心魅力的だと思っていないものを渋々受け取ったり、そもそも実現不可能な仕様で何度も突き返されたりと、イヤなことがたくさん起こります。質は上がらないし、リードタイムもどんどん伸びていくし、非常につらい状態だと言えます。

反対に2つの専門性を完全に重ね合わせたのが究極の世界です。全員がコードも書いてプロダクトマネジメントもする状態です。もちろん実現すればすごいことですが、先に述べた議論からスキルビルドや採用の問題に阻まれて上手くいかないでしょう。これができるなら誰も苦労しないのです。

「要はバランス」という話になってしまうわけですが、良いものを良いやり方で届けることを共通の目標として、チームメンバーの興味や能力が許す範囲で2領域を重ね合わせることで、「専門性は違うけど力を合わせる」という空気を醸成していくのが現実的な落とし所になっていくと考えます。分業や分断という言葉で捉えてしまうとネガティブな印象になってしまいますが、そもそもプロダクト開発は均質な人材でカバーできるほど簡単な世界ではないようにも思います。専門性を分担して掘り下げて力を合わせるという考え方をして、お互いに越境を称え合えると良いですね。

具体的な取り組み

「専門性は違うけど力を合わせる」という観点で、自分のチームで実施されている取り組みを紹介します。

まず、エンジニアが施策立案の早い段階に参加する仕組みがいくつかあります。ひとつは、PdM - リードデザイナー - テックリードによる30分x2/週の定例です。ここでおおまかな実現可能性を壁打ちすることで、Value/Effort比の見積もり精度を上げたり、筋よく実現できる方向に軌道修正したりします。

もうひとつは、スプリントの作業として相談時間を積んでしまうものです。特に不確実性が高い施策で採用されやすく、エンジニアの誰かが早い段階で専任で議論に入り一緒に磨いていきます。フットワークを軽めに維持しつつ、設計や着手までスムーズに接続しやすく、最近チーム内ではアツいやり方です。

また、リファインメントのなかで多職種で議論する時間を「スーパークリエイティブコラボレーションパート」と呼ぶようにしました。バカみたいだと思うかもしれませんが、これによって議論の雰囲気はかなり変わった感触があります。リファインメントはPdMが持ってきたアイディアを品定めする時間ではなく、全員がアイディアを出し合って価値を最大化する時間であるということを表現できたと思います。全く詳細が決まっていない施策の卵も議論の俎上に上がるようになり、プロダクトマネジメントを多少は加速できているはずです。

他にも、デザインスプリントや、プロダクトゴールの念入りな周知、リファインメントの時間の拡充、スプリントレビューのインタラクションの改善など、さまざまな施策が打たれています。チームが一体となってプロダクトを作っている感触が増し、提供する価値の手応えも少しずつですが良くなっています。

まとめ

RSGT2023の発表を受けて、プロダクトマネジメントをチームでやっていく難しさをさらに掘り下げることで、「専門性は違うけど力を合わせる」という現実的な目線を提示しました。その上で、自分のチームでやっている具体的な改善の取り組みを紹介しました。発表で提起されているプロダクトの成長に伴うPdMのボトルネック化に対してはイマイチ答えられておらず、まだまだな思考ですが、まずは自分なりに議論を広げてみました。

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

ソフトウェア開発で、より早くより多く価値を届けたいと考えた時、エンジニアの増員は有力な選択肢です。もちろん、人月の神話などで語られるように、人を増やしただけ線形に生産力が向上するというシンプルな世界ではありません。それでも多くの現場でエンジニアの増員が行われます。自分のチームでも、とりあえずエンジニアを増員すれば、いくつかの問題が解決してくれるような気もします。雑談ベースでメンターなどにこういう話を出してみるわけですが、改めて「なぜエンジニアを増員したいのか」と問われると、これが意外と広がりのある議論であることがわかってきました。本記事では、エンジニアを増員するロジックについて、自分が思考を広げられた範囲で書いてみます。

作り切りの場合は明快

まずエンジニア増員のロジックを素朴に立てられるのは作り切りの場合です。ある程度の規模のものを丸々作り切らないといけないケースです。締め切りがあることも多いでしょう。そうした要求に対して、現状のベロシティでは期待する期日に完成しないとなれば、何か手を打たなければいけません。スコープと期日から動かすのが定石ではありますが、それでもダメだとなれば、ベロシティがどれほど伸びるかわからないにしても、人海戦術に頼っていく必要があるでしょう。

この場合のロジックは非常に明快です。今のペースでは間に合わない、他のパラメータも全て切り詰めた、それでも無理なので増員してください、ということです。この場合はスポットの増員になることが多いでしょう。このパターンは伝統的な危険なやり方で、スポットで入ったひとの割合が多すぎると、作り切った後に残されたメンバーがひどい目に遭うかもしれません。チームに仕事が流れ込む形を維持できるのが理想ですが、苛烈なサバイバルプロジェクトにおいて、こうした綺麗事を言っている余裕はないかもしれません。

利益に着目すると難しい

継続開発の場合はもっと話が難しくなるように思います。まず初めに考えつくのはお金の話です。素朴には、増員による人件費の増加より、売上の増加が大きい期待があれば、その増員は投資として成立することになります。利益が増える期待があるなら投資したら良い、当たり前だと思います。

しかし、どれほどのサービスがこのロジックを立てられるでしょうか。継続開発ということは、サービスのコア機能は十分に揃っていて、機能の追加、改善、整理などを通してサービスを伸ばしていくフェーズにあるということです。この状況において、開発のスピードが上がるほど利益が増加すると主張できるのは珍しいケースだと思います。ベロシティ、施策のサイズとインパクト、ユーザー行動のKPI、売上といった一連のパラメータが密に接続され、予測可能でなければ説明できないからです。これは途方もないことです。

また、利益に着目するならエンジニアの増員は手段のひとつに過ぎません。システムとして売り上げが立つスキームが完成しているなら、エンジニアの人件費に投資するより、広告や営業に投資した方が売上の増加が期待できる場合も多いでしょう。「"利益を増やしたいから"エンジニアを増員する」は必然性がなく、もしかしたら背後に別の課題があるのを取り違えているのかもしれません。

システムの変化するスピードに着目すると……？

少し視点を変えて、システムの変化するスピードに着目してみましょう。ソフトウェアには常に壊れたり陳腐化する方向に向かっています。ミドルウェアは古くなり、かつて栄えた言語は気づけば落ち目になります。エンジニアはそれよりも速いスピードでシステムを進化させ続ける必要があります。さもなくば、競争力で負け、ユーザーが減り、優秀なエンジニアが減り、サービスは緩やかに死んでいきます。

そうならないように十分な投資をしたいと考えると、エンジニアの増員は有力な選択肢になります。スコープを動かすのが難しく、EOLやセキュリティパッチが迫ってくることを考えると期日もあり、システムを変化させられるのはエンジニアだけとなると、利益に着目した場合よりはだいぶロジックは強固に見えます。

この場合に難しいのは、品質のターゲットをどこに置くかということです。素朴に考えると、品質のターゲットを可能な限り下げて人件費を圧縮し、利益率を上げるのが短期・中期的には最適な戦略に見えます。その結果EOLがやってきたものから助け上げるようなメンテナンス体制になってしまいます。これが多くの現場の現実ではないかと思います。

この状況から脱するひとつの方法として、CTOなどが外から働きかけることが考えられます。素朴に考えると最低ラインに収束する品質ターゲットを、採用や技術ブランディング、グローバルなテクノロジーマネジメントの観点を入れて引き上げるということです。たとえば「全てのミドルウェアは最新のLTS以上のバージョンを利用する」といったことです。システムの品質、利益率、外部要請の3つでうまく綱引きさせることで、システムを積極的に変化させる道が開けないものかと考えています。

こうした取り組みを受け入れエンジニアを増員するには、当然そのサービスが余剰人員を張れる状態になければいけません。これ以上エンジニアを増やすと赤字になるという状況で、ミドルウェアのバージョンを上げるために人は増やせないわけです。それ自体が事業の健全性を測るものさしとなり、利益率の低い事業を潰していくことにつながるのかもしれません。世知辛いですね。

このあたりについては、現実には各チームで余剰人員を張るのは大変なので、コストセンター的にプラットフォームチームを組成するパターンも教えてもらいました。確かに、典型的なシステムの進化であれば、ドメインと直交する形で進められる可能性はあるなと思います。一方で、本当にやりたいのはドメインにベッタリくっついた難しいところなんだよな〜という思いもあり、まだまだどうしたら良いかわかりません。少人数で大儲けできてたら一番良いのですが……そんなにうまくはいきませんね……。

残りの議論とまとめ

以上のようなことを考えたわけですが、「増員」で思い浮かぶような急成長している企業がこういう細かい勘定をしている印象があまりなく（そういう会社にいたことがないので完全に憶測ですが）、もっと大胆に異常な増員をしているように感じるので、そこにどういうロジックがあるのかは純粋に気になりました。「作り切り」のロジックで急拡大させて、そのまま継続開発チームとして配置していく感じになるのでしょうか……？

何はともあれ、これまでよりは強固なロジックでエンジニアの増員について主張できるようになったと思います。ビジネスモデルや経営に絡む話のはずで、そういった方面に興味を持つきっかけにもなりそうです。引き続き考えていこうと思います。

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

このエントリはEngineering Manager Advent Calendar 202213日目の記事です。

まえがき

このエントリは、以下のPodcastで話した内容を掘り下げて整理したものです。Podcastの方では本エントリで触れていないチームの具体的な様子等についても話しているので、ぜひ合わせてお楽しみください！

はじめに

以前、エンジニアリングマネージャーを目指す若者の戦略というエントリを書きました。その時点でのエンジニアリングマネージャー（以下EM）というロールへの理解や、実際にEMを目指していくための戦略を整理したものです。

素晴らしいことに、このエントリの投稿からおよそ1年3ヶ月たった今も戦略は機能しており、ロールへの理解を深めつつキャリアを前進させることが出来ています。本エントリでは、EMというロールへの理解の変化や、EMを志向する過程で目指している「最強の現場リーダー」という働き方について書いていきます。

EMについての理解

まず、ソフトウェア開発において以下の4つのマネジメント領域があるという捉え方は、前回のエントリから変わっていません。

• テクノロジーマネジメント
• デリバリーマネジメント
• ピープルマネジメント
• プロダクトマネジメント

EMとは、チームや組織にこれらのマネジメント能力を実装し、組織やプロダクトが生み出す価値を大きくし、メンバーの幸福度を高めるロールであると理解しています。達成の方法は任意で、自らが手を動かして牽引しても良いし、他者に委譲しても良いし、自己組織化を通じてチームがカバーするように仕向けても良いです。マネージャーではあるので、人への働きかけによって間接的に大きなインパクトを与えられる方が望ましくはあるでしょう。また、4領域のどこまでをカバー範囲とするかも、当人の能力や各組織のEMに対する期待によって変わってくるはずです。私がこのモデルを知った広木大地さんの記事でも、そのカバー範囲によって「強めのEM定義」と「弱めのEM定義」が提示されています。

最近のアップデートとしては、エンジニアリングマネージャーのしごとの登場で、人をマネジメントする典型的なマネージャーとしての像が少し際立った印象を持っています。もちろんそこに書かれているテクニックや考え方は優れたものですし、それらが主務になっていくのはロールの性質から考えて自然なことだと思います。EMのトレンド？もしくはその兆し (2022年)でも、人や組織に向き合う専任のマネージャーロールが増えつつあるのではという仮説が提示されており、肌感としては納得できます。

一方で、Engineering Managerをエンジニアのマネージャーとするのはやめませんか？ - Unknown Errorでも語られているように、評価や1on1、採用はあくまでEMの責任を果たすためのツールであるという見方もあります。EMにどういった成果を期待するのか、EMとしてどういう働き方をしたいのかといった点は、依然として考え続けなければいけないだろうと思います。

EMキャリアの進捗 - 最強の現場リーダーという働き方

前回のエントリでは、まずは弱めのEM定義を志向して、以下のような優先度で取り組む戦略を提示しました。

• テクノロジーマネジメント = デリバリーマネジメント
• > ピープルマネジメント
• > プロダクトマネジメント

現状はおおよそこの通りにキャリアを前進させられています。

• テクノロジーマネジメント
  • 2022/2にチームのテックリードを拝命しました。非機能開発の計画を立てたり、大きな施策の設計を行ったり、壁打ちやレビューを通してシステムの品質の維持・向上に努めたりと、一般的なテックリード業を地道に遂行しています。最近は、一部の定常業務や単発の設計業から他メンバーに委譲し、負荷を軽減しつつ成長機会を狙って配ろうとしています
• デリバリーマネジメント
  • チームのスクラムマスター的なロールを務めています。こちらの発表で紹介した形でスクラムを軌道に乗せることに成功しました。現在はチーム全体の改善を引っ張るロールを別のメンバーに委譲し、そのメンバーの壁打ち相手となることで間接的な働きかけに挑戦しています
• ピープルマネジメント
  • チーム内外で合わせて5名のエンジニアのメンターを務め、隔週の1on1や日々のコミュニケーションを通じたメンタリングをしつつ、人事評価プロセスの一部を担っています

このように、方法不確実性への対処を担うテクノロジー、デリバリー、ピープルの3領域を中心に、プレイヤーとマネージャーの振る舞いを使い分けながら飛び回っています。自分が関わることでチームのあらゆる仕事がうまくいく、自分と関わった人が楽しく成果を挙げて成長していく、そういう「最強の現場リーダー」を目指して日々仕事をしています。

この働き方の最大の魅力は、各領域を接続して自由にコントロールできることです。たとえば、メンバーとの1on1で得意分野や気になっている課題・技術について聞いたら、それを素早く非機能開発のバックログに反映することができます（ピープル - テクノロジーの接続）。重要な基盤刷新のプロジェクトがあれば、スプリントごとのベロシティの内訳を詳しく集計するように変え、一定の割合で工数が投入されるようにコントロールしたりできます（テクノロジー - デリバリーの接続）。このように開発全体を自分ごとにしてしまうことで、仕事をうまく進めるための手札がどんどん増え、日々たくさんの学びを得られています。

一方で、この働き方には良くない点があります。それはとてもハードなことです。毎日全速力で走って、たまにちょっと余分に走って、ようやく納得できるクオリティの仕事ができています。3領域のバランスを自分の中で取って、メンバーの思いとチームとしてやりたいことを擦り合わせて、尖ったイノベーションが起こるようなダイナミックな采配もできるように……とさまざま考えていると心労が絶えません。仕事が好きで、家庭を持たず、心身が健康な、いまの自分だからこそ成立する働き方であると思います。領域ごとに違うメンバーへの委譲を目指したり、僕の背中を見てプレッシャーを感じるメンバーに説明をしたりと、この働き方が禍根を残さないように気を配っています。（一応ですが、全て望んで拝命したロールで、調子が悪い時は自分のメンターにいつでもエスカレーションして負荷軽減する体制は整っています）

EMキャリアの次の戦略

複数のマネジメント領域に目を配り、ときどきマネージャー仕草を交えてチームを引っ張る「最強の現場リーダー」という働き方は、EMへのステップとしてかなり良くできていると思います。この働き方を以ってEMであると考える人もいるかもしれません。実際、前回のエントリで「EMになりたい」と言って思い描いた働き方はだいぶ実現しつつあります。大きな方向はおそらくこのままでよく、各領域のスキルを磨きつつ、視座を上げて影響範囲を広げていくことで、多くの組織のEMポジションに手が届くだろうと見ています。

テクノロジーマネジメントでは、枯れた解法を組み合わせた無難な采配だけでなく、先頭集団に追いついたり、率先して技術を切り拓いたりと、もっとエンジニアリングを楽しむ仕事を増やしたい思いがあります。自分の中で最も思いと行動が乖離している部分ではあるのですが、思いだけはあります。そのためには、当たり前品質を素早く繰り出せるようにし、知識をバランスよく増やし、有力な技術の素振りをし、とにかく筋肉をつけていくしかありません。これは一朝一夕では成し得ません。自分が納得するスキルを獲得するための作戦を練っていきたいと考えています（何度も考えては頓挫しているのですが……）。

ピープルマネジメントでは、現状5名のメンタリングを行っていますが、その範囲でもまだまだ伸び代を感じます。モチベーションを削ぐような言い方をしてしまったとか、自分の思い込みで話してしまったとか、その日を振り返ってグッと唇を噛みたくなるような失敗が絶えません。またEngineering LaddersのPeople軸を見ると、mentorsの先にcoordinates、managesという段階があり、メンバー間のコミュニケーションに働きかけたり、各メンバーにより深くコミットするような振る舞いがあることがわかります。またチームメンバーとのコミュニケーションだけでなく、採用やリソースマネジメントといった方向への広がりもあるでしょう。メンティーに誠実に向き合いマネージャーとしての地力を底上げしつつ、スキルが広がる機会には積極的に手を上げていこうと思います。

デリバリーマネジメントは、3年ほど最高優先度で取り組んできたこともあり、経験と知識が一番豊富です。チームの状況もひと段落していることから、緊急度の高い領域ではなくなっています。今後はチームの中で大きな仕事をするというよりは、影響範囲を広げる方向に伸び代があります。あまり焦らずに、情報収集や社内でのコーチング、外部登壇で少しずつスキルを伸ばしていこうと思います。

また、「最強の現場リーダー」として飛び回っていると、良くも悪くもチームに対して非常に大きな影響力を持つことになります。素早く力強いリードが可能な反面、一歩間違えば、自分の価値観や能力でチームのバリューを制限してしまうこともあります。自分が知らないことや理解し難いことも成果に接続できるのが理想です。これを上手くやるには指揮統制型のリーダーからサーバントリーダーへと変化していく必要があるでしょう。各領域のスキルだけでなく、それらと直交する自分の振る舞いにも磨きをかけ、ひとの力を引き出せるリーダーを目指します。

まとめ

本記事では、現状のEMというロールへの理解と、キャリアのステップとして志向している「最強の現場リーダー」という働き方、それらを踏まえた次のキャリア戦略についてまとめました。

大方針では依然としてEMを狙っているわけですが、「最強の現場リーダー」という働き方も理想に近い状態なので、あえて急いでマネージャー方向に全振りしなくても良いかもしれません。(翻訳) エンジニアとマネージャの振り子 - ふしみのブログで述べられているように、このキャリアの分岐は不可逆なものではないでしょう。それどころか、意図して何度も行き来することがキャリアを切り拓くかもしれません。チームで飛び回る働き方も、ひとに働きかける仕事も好きなので、そのあたりは巡り合わせに任せて、地道に自分のレベル上げをやっていこうと思います。

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

この記事ははてなエンジニア Advent Calendar 20227日目の記事です。

昨日は id:utgwkk さんでした。

さて、今日はスクラムの話です。スクラムの導入とリードは自分のキャリアにおける重要な仕事のひとつで、気づけば3年ほどスクラムと取っ組み合ってきました。ここ1年くらいで、ようやく安定してテンポ良く開発が回るようになって、大仕事に一区切りついたような気持ちでいます。そうして少し肩の力が抜けた結果、最近はスクラムというフレームワークから一歩引いた位置に自分の目線が移動しつつある気がしています。自分の考えのスナップショットを取るには絶好のタイミングと思われるので、スクラムについての学びや、自分のスクラムに対する目線をまとめてみようと思います。

スクラム導入のキモ

まずは、自分が経験したり見聞きした様子から、スクラム導入のキモだと思う点を2つほど書いてみます。どちらも越えがたい難所ですが、スクラムを機能させるために避けては通れない部分だと思います。

言うとおりに全部やってみる

スクラムガイド2020では次のように述べられています。

スクラムの核となるデザインやアイデアを変更したり、要素を省略したり、スクラムのルールに従わなかったりすると、問題が隠蔽され、スクラムの利点が制限される。 場合によっては、スクラムが役に立たなくなることさえある

スクラムの実践では「言うとおりに全部やってみる」ことが推奨されています。自分のチームでも、人員配置等の都合から意図的にガイドから外している部分が課題に上がることが多く、後付けパッチのような泥臭い対策を何度もしているので、経験的にもよく理解できます。しかし一方でこの部分は軽視されがちな印象を持っています。どちらかというと以下のような部分のニュアンスを感じることが多いです。

スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている

似た例としては以下です。

スクラムフレームワークの中で、さまざまなプロセス、技法、⼿法を使⽤できる。スクラムは既存のプラクティスを包み込む

こうした「自由度が高い」というニュアンスがひとり歩きして、スクラムのコアについても、はじめから部分的な導入に留めたり容易に変形しがちな印象を持っています。

しかしそうした進め方は、スクラムガイドが言うとおり成功しづらい道であると感じます。というのも、スクラムの構成要素は単体で著しい効果を発揮することは少なく、相互に作用することで真価を発揮するからです。例えば、スプリントゴールがあるからこそ、それを達成するために検査して適応するデイリースクラムが機能します。スプリントレビューがあるからこそインクリメントを確認する場ができ、完了の定義が重要な役割を果たします。こういった具合に、スクラムの構成要素にはシナジー効果が多くあるので、なにかひとつを導入して良くなるというよりは、カバレッジが一定ラインを超えた時に急激にチームが良くなるイメージを持っています。一部だけを導入しようとしても、他の構成要素との繋がりをチームに実装できないので、導入する理由を説明しづらく得られる効果も小さいため、スクラム導入は茨の道となります。手応えがないままチームに変化を起こし続けるのは大変なものです。

とはいえ、スクラム導入のような大きな変化が一晩で起こるはずもなく、結局少しずつやっていくしかありません。この現実がスクラムの性質とコンフリクトしていると感じます。ひとつひとつは小さな変化としつつも、スクラムの大部分を実装し切ることを狙って素早く動くのが望ましいということになってきます。これは非常に難しいことです。かくいう私も、始めは素朴にスクラムを少しずつ導入しようとし、手応えのない日々を過ごしました。その袋小路を脱出しチームを大きく改善するに至った経緯は、以下の発表で詳しく紹介しているので、興味のある方はご覧ください。

仕事をチームのものにする

スクラムはチームとしてゴールを達成することに重きを置いたフレームワークです。まとまった仕事を人に向けてアサインするのではなく、フィードバックを得られる単位のインクリメントを、チームで協力・分担して素早く作り上げます。そっちのメソッドは私が、あっちのコンポーネントは私が、ここは並行に進められる？ちょっと待った方が良い？、こういった具合です。リソース効率よりもフロー効率を重視しているという言い方もできそうですね。

このように仕事をチームのものにするやり方は、チーム内の知識格差を是正し、設計やレビューの手戻りを減らし、ユーザーに素早く価値を届けることに繋がります。スクラムを機能させるための重要な要件と言って良いでしょう。こうした考え方に移行しないまま、ひとり1プロジェクトのような世界観でスクラムを回そうとしても、スプリントの切れ目が進捗確認ポイントになるだけで、スクラムとしての恩恵を得るのは難しいと思います。

しかし、こうしたやり方はエンジニアごとに好みが分かれるところだと思います。自分もエンジニアなので、大規模な難しい実装をひとりで作り上げたい思いも理解できます。また、段取りとマイクロマネジメントとスクラム - yigarashiのブログでも述べたように、チームに仕事を展開しようと思うと、だいぶ細かいところまでチームで計画を話し合うことになります。ジュニアメンバーにとってはメリットが多いですが、シニアメンバーから見ると冗長で退屈に思えてしまうかもしれません。この部分をチームで合意してやっていくには、スクラム推進者の情熱やメンバー構成の運も必要になってくると思います。そういった点から、この「仕事をチームのものにするという」変化はスクラムの難所であると考えています。

逆に、この難所を越えようとした時に、自分たちがスクラムを必要としていないことに気づくケースも少なくないようです。シニアメンバーが集まっているなら、マイクロマネジメントなやり方にコストをかけてもリターンが少ないでしょう。フロー効率を追求する要請が特になければ、リソース効率を重視した別のやり方を選択するのも建設的だと思います。スクラムはあくまで道具のひとつであるということです。

スクラムの好きなところ

ここまでスクラムのハードな部分の学びを紹介しましたが、もう少しライトに、素朴に好きな部分について書いてみようと思います。

スプリントゴールに関する確約

スクラムの価値基準のひとつに確約（コミットメント）があります。これは、チームで協力してゴールを達成することを確約するもので、スクラムでは確約の対象となるゴールがいくつか明示されています。そのひとつがスプリントの目標であるスプリントゴールです。スプリントごとに設定された目標を達成するために協力し全力を尽くすということが、フレームワークに最初から織り込まれているのです。

スプリントゴールをうまく運用することで、チームは2週間程度の短いスパンで具体的な目標を持つことになります。よく例えとして言われる「次の電柱」が常に存在するので、走っていてもチームが迷子になりづらいです。また「スプリントゴールを安定して達成するにはどうするか？」という問いから、良いプレーがたくさん生まれます。定期的に成功体験を得る機会にもなり、ある種のゲーミフィケーションのような効果も期待できます。スプリントゴールがある生活は「退屈しないな」という印象で、とても好きな仕組みです。

バリューストリームを広く包括するプロセス

スクラムでは、主にプロダクトバックログのメンテナンスを通じて、何を作るか、つまりプロダクトマネジメントのプロセスにも踏み込んでいきます。スクラムガイド2020では「プロダクトゴール」というプロダクトの中期的な目標もスクラムの成果物として含まれるようになり、その色はさらに強くなっているように思います。こうした仕組みのおかげで、ある目標やアイディアが生まれてから、それがユーザーに届き、成果をふりかえるまでの一連のプロセスをスクラムの上で考えやすくなっています。プロダクトバックログをインターフェースとすることで、ディスカバリートラックとデリバリートラックを分けた、デュアルトラックアジャイルのような形式にもスムーズに対応できます。最終的にはプロダクトとしての成果を挙げたいわけですから、そうした全体像を形式的に議論できるスクラムは、思考に補助輪をつけてくれる仕組みとして気に入っています。

知の高速道路としてのスクラム

スクラムはアジャイル開発における最大手のフレームワークと言って良いでしょう。シンプルながらソフトウェア開発のバリューストリームを広くカバーしており、アジャイルにやりたい多くのチームで採用されています。SCRUM BOOTCAMP THE BOOKのような詳細まで補完した入門書も充実しています。これらと原典であるスクラムガイドを併読し、目の前のチームと課題にしっかりと向き合えば、多くの組織が合格点の開発プロセスを実装することができます。定石が多く変化のスピードを上げやすいのも嬉しいポイントです。また、スクラムはコミュニティが大きく活発です。スクラムというキーワードに多くのコンテンツが集まっています。それらを参照することで、ひとりではないという勇気を得ると共に、書籍等でカバーしきれない泥臭い課題の突破口すら見つけることができます。デリバリーマネジメント領域でこうした手札が1枚あるのは大変心強いことだと思います。

スクラムへの目線

こうした学びを得つつ3年ほどスクラムをやってきたわけですが、現在のスクラムへの目線はかなりフラットになってきました。もちろんうまくやれれば強力ですが、越えなければいけない難所もあり、誰にとっても楽しいわけではないかもしれません。チームやプロダクトの性質によって合う、合わないもあります。スクラムが銀の弾丸ではないということを、少し実感を伴って理解できるようになった気がします。

一方で、ではスクラムを選択しなかった時にどうするか、というのは自分の中でまだ回答の手札が少ない問いです。こればっかりは違う環境に身を置いてみないと分からないので、キャリアの今後の楽しみとしておこうと思います。

なんだかスクラム卒業のような雰囲気で書いてしまっていますが、実務経験3年なんてまだまだペーペーでしょうし、スクラムチームをリードする仕事も続きます。今はスクラムでの開発を楽しめており、条件が合う限りは今後もスクラムをやっていくと思います。また2年、3年と経過して、今とはまた違う面白い学びが得られることを期待して頑張っていこうと思います。

この記事ははてなエンジニア Advent Calendar 20227日目の記事でした。

明日は id:cockscomb さんです。

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

仕事ができるエンジニアはだいたい段取りがうまい。達成したいゴールがあるときに、AとBとCをやる必要があって、Bはわからないことが多いから先にやろうとか、AとCは並行してできるからCを誰かにお願いしようとか、とにかく目標を達成するための道のりをうまく計画できる人が多い。こういう作業をそつなくこなせるかが、ジュニアと一人前を区別する重要な指標のひとつと言える。そしてこの段取りをうまくできない人に対して、細かい計画を立ててあげて指示をするのがマイクロマネジメントだと思う。

スクラムにおけるスプリントプランニングは、この段取りをチームでやると思うとよく腹落ちする。達成したいゴールとしていくつかのプロダクトバックログアイテムを置いて、その達成に必要な作業を半日から1日で終わるサイズのタスクにみんなで分解して、不明点を一緒に洗い出して、どういう順番でやっていくか計画を立てる。まさに段取りだ。これがスクラムがマイクロマネジメント手法だと言われがちな由縁だろう。自分で段取りができてしまうエンジニアからすると、わざわざチームで集まって細切れにしなくても、大きい単位で渡してくれたらいい感じにしまっせ、という気持ちになるのも理解できる。そうした方がリソース効率は上げやすいし自由な感じがする。

こうした方法を取るメリットは大きく2つあると思う。ひとつはマイクロマネジメントを形式的にできることだ。シニアメンバーも含めて一緒に詳細な計画を立てて回ることで、チームの総合的な段取り力を大きく、かつ確実に底上げできる。ジュニアメンバーが多いほど有効に機能するだろう。もうひとつのメリットはフロー効率の最適化をしやすいことだ。ある目的を達成するための作業を、一度バラしてチームのものとして一覧することで、多少コストがかさんでも最速で価値を届けるための方法を見つけやすくなる。

こういう特徴を考えると、急成長しているSaaSの開発なんかとスクラムは非常に相性が良さそうに見える。組織の拡大が早いのでシステムに詳しくないメンバーの割合が高いし、仮説検証による製品発見が重要になるのでフロー効率を上げる必要がある。反対に、一定のスコープを目指して作り切るような仕事をしているチームでは、スクラムによる恩恵は感じにくいかもしれない。インクリメンタルな結果を求められなければ、フロー効率を高める意味もイテレーティブにやる意味も主張しづらい（本来は不確実性を下げたりチームの学習を促すためにやるべきだとは思うが）。シニアメンバーだけでチームが構成されている場合も、スプリントプランニングを簡素化するといったチューニングは検討しても良いだろう。POが期待する成果が出ていれば、細かいやり方に口出しされる筋合いはない。

以上。エンジニアなら誰もがやる段取りという仕草とスクラムを結びつけて、スクラムの性質や向き不向きを議論してみた。