プログラマーのキャリアは「AI を使えるか」では分かれない

ai development career

AI もしくは AI Agent を業務の開発に使うのが当たり前と言ってよい時代になりました。私も日々の業務時間の8割を AI とのやり取りに費やしていると言っても過言ではありません。

余談ですが、Steps of AI Adoption として Claude Code の開発者として著名な Boris Cherny 氏が AI 活用のステップについてまとめていました。私はこのステップに当てはめると、Step 1 Assisted / Step 2: Parallel Orchestrator の中間程度のレベルのように思います。

一方で私自身 AI を使ってうまくいくこと・うまくいかないことを把握しつつ、周りの AI 活用をみていて感じることもあります。1年以上そういった働き方をしてきて私なりの考察や理解も進んできました。それらについて書いた記事が次の2つになります。

note.com

t2y.hatenablog.jp

この2つの記事における総論として、AI がいくら賢くなったとしても、それを扱う人間自身の理解や学びが速くなることはまったくありません。もちろん AI をうまく使うと効率よく学習できます。しかし、AI がいくらわかりやすく適切な回答を生成したとしても、ソフトウェアエンジニアリングの知識やスキルをそれを5分読んだだけで身につくということはありません。

AI 時代のキャリアにおいて最も大事になるのは「学びの本質とはなにか？」を理解して、自身に認知負荷をかけ、時間をかけて学んでいけることだと私は考えています。そのためには、自分が何を理解していて、なにを理解できていないかのメタ認知の能力がとても重要になります。メタ認知の能力が高い人は適切な問いを作れるからです。そして、適切な問いと AI 活用はとても相性がよいといえます。

ここから先は AI 時代のプログラマーのキャリアについて、私が ChatGPT と壁打ちした内容を Claude Code に読ませ、ブログ記事として整理した内容を、私がレビューしてまとめた成果物です。100% Claude Code が書いた文章です。

長文を読むのがしんどい方向けに要約です。

課題を AI エージェントに渡し、生成された成果物を提出するだけの働き方を、本稿では AI agent operator と呼びます。 対して、自分が設計と品質に責任を持ち、AI を補助に使う働き方が AI-assisted engineer です。 両者を分けるのは AI の利用量ではなく、判断の主体が誰かです。

経験の浅い開発者が operator の働き方を続けると、課題分解、設計判断、デバッグといった学習に必要な認知活動を AI が代替するため、開発チームに所属していても能力が育ちません。 従来は理解が不足していると手が止まり、それが学習の契機になっていましたが、生成 AI はそれらしい出力を返すため、この行き詰まりが消えました。 さらに、「理解した」の基準が「作業に着手できたこと」にすり替わり、周囲の補完も本人からは見えないため、本人は問題ないと感じたまま、自己評価と周囲の評価が離れていきます。

検証のコストを周囲に負担させるこの働き方は、組織が下流コストを可視化するほど成立しにくくなります。 キャリアの分岐点は、AI が間違っているときに止められるかであり、その土台には最低限、コードを読んで理解できるスキルが必要です。 AI を使う前に自分の仮説と設計を書き、出力のうち採用した部分、却下した部分、自分で確認できていない部分を区別することが、AI 時代の能力開発になります。

AI エージェントに任せる働き方は、開発者のキャリアになるか

コーディングエージェントの普及で、開発タスクの進め方は大きく変わりました。 課題をエージェントに渡し、生成された成果物を確認して提出する。 この働き方で日々の仕事は回るようになっています。 では、この働き方を数年続けたとき、開発者としての能力は育っているのでしょうか。

本稿では、AI を使う開発者を二つの働き方に分け、その違いが今後のキャリアにどう効いてくるかを考えます。

先に対象読者を断っておきます。 本稿が想定しているのは、AI がある時代にキャリアを始めた若い開発者、または経験の浅い開発者です。 AI がない時代に経験を積んできた開発者には、当てはまらない可能性が高いです。 そうした開発者は、設計、判断、検証の能力をすでに自分の手で形成し終えており、AI に作業を委譲しても失うものが少ないからです。 本稿で問題にするのは、その能力をこれから形成する時期に、形成の機会そのものを AI に委譲してしまうことです。

二つの働き方

まず用語を定義します。

  • AI agent operator：課題を AI エージェントに渡し、生成された成果物を受け取って提出する働き方
  • AI-assisted engineer：自分が設計と品質に責任を持ち、その作業の一部を AI に補助させる働き方

両者を分けるのは AI の利用量ではありません。 利用量で分けるなら、AI を多く使う経験豊富なエンジニアほど operator に近づくはずですが、実際にはそうならないからです。 分かれ目は、判断の主体が誰かにあります。

観点 AI agent operator AI-assisted engineer
課題理解 AI に整理させる 自分で構造化する
設計 AI の案を採用する 自分が設計し、AI を補助に使う
実装 指示して生成させる 意図を持って生成、修正する
検証 テストが通れば承認する 前提、境界、副作用まで確認する
問題発生時 AI に再質問する 自分で原因を切り分ける
品質責任 レビュー担当に委ねる 自分で負う
成長対象 指示の仕方、プロンプト 設計、判断、検証の能力
AI 停止時 作業の継続が難しい 生産性は落ちても継続できる

同じツールを使っていても、判断を自分で下しているかどうかで、日々経験している仕事の中身が変わります。 この違いは、数年単位で能力の差になって現れます。

開発チームにいれば育つのか

これまでの育成には、実務を経験させれば徐々に能力が上がる、という前提がありました。 この前提が成り立っていたのは、実務の認知的な負荷を本人が引き受けていたからです。 仕様を読み、わからない箇所を調べ、設計を考え、エラーの原因を調査する。 こうした活動そのものが学習でした。

AI agent operator の働き方では、この負荷の多くを AI に委譲できます。 委譲した部分については、学習に必要な認知活動が起きません。

課題分解を例にとります。 本来、開発者は曖昧な要件を読み、論点を分け、依存関係を整理します。 最初に課題を AI へ渡してしまうと、本人が見るのは分解された後の問題だけです。 分解する経験を積まないので、課題分解の能力は育ちません。

設計判断も同様です。 設計能力は、正しい設計を見るだけでは身につきません。 複数案を比較し、制約を特定し、何を捨てるか決め、失敗した設計を修正する。 そうした判断の経験が必要です。 AI が提示した設計案を「もっともらしいから」と採用している間、本人は設計判断をしていません。

デバッグでは、エラーを AI へ貼り付けて修正案を適用する進め方だと、仮説を立てて検証する経験が蓄積しません。 本人が上達するのは、原因の見つけ方ではなく、AI への追加質問の仕方です。

つまり、開発チームに所属していても、従来の若手と同じ学習経験をしているとは限りません。 所属している場所は同じでも、経験している仕事が違うのです。

行き詰まりの消失

この状態に本人が気づきにくいのには、理由があります。

従来は、問題を理解せずにコードを書こうとすると、途中で手が止まりました。 その停滞が、「理解しなければ書けない」と本人に気づかせる機会になっていました。

生成 AI は、問題を十分に理解していない入力に対しても、それらしい出力を返します。 このため、理解が不足したまま作業を進めても停滞が起きません。 学習の契機だった行き詰まりが、ツールによって消えたことになります。

その結果、次のループが成立します。

  1. 課題を十分に理解しないまま、AI に回答を作らせる
  2. 成果物を提出する
  3. レビューで指摘を受ける
  4. 指摘を AI へ渡し、修正版を提出する
  5. マージされて完了する

このループには、本人が課題を理解する工程がありません。 それでもコードは動き、PR はマージされ、機能はリリースされます。 本人は「自分は開発できている」と認識するでしょう。

自己評価と周囲の評価のギャップ

この認識は、周囲の評価と食い違っていきます。 周囲から見れば、課題の理解や設計の判断といった基本的なスキルが育っていないのに、本人はこの働き方で問題ないと感じている。 経験の浅い人がこのギャップに陥るのには、少なくとも三つの背景があります。

一つ目は、「理解した」の基準が本人の中でずれていくことです。 課題文を目で追い、キーワードを拾って AI に入力すると、それらしいコードが出てきます。 この流れが日常になると、本人にとっての「理解した」は、内容を自分の言葉で説明できることではなく、作業に着手できたことへとすり替わります。 コードが動いた、AI の説明を読んで納得した、という事実が理解の証拠として扱われます。 しかし、説明を読んで納得することと、自分で説明できることの間には距離があります。 自分で説明する場面がなければ、その距離は本人から見えません。

二つ目は、外部からの反応が思考を代替することです。 AI の回答、コンパイラのエラー、テストの失敗、レビューの指摘。 次の一手をこれらが教えてくれる環境では、自分で仮説を立てなくても作業は前に進みます。 むしろ、立ち止まって考えるより、とりあえず何かを出して反応をもらうほうが、タスクは早く終わります。 本人にとってこれは合理的な適応であり、考えることを怠けている自覚は生まれません。 しかし、この適応が続くと、外部から反応が返ってこない場面では手が止まるようになります。 考えていないのではなく、反応がないと考えられなくなるのです。

三つ目は、周囲の補完が本人から見えないことです。 実際には、AI が設計と実装を行い、CI が問題を検出し、レビュアーが要件とのずれや欠陥を見つけ、周囲が前提条件を補うことで、成果物は成立しています。 チームが品質保証のコストを負担して成立させた成功です。 しかし、本人の目に映るのは、マージされた PR とクローズされたチケットだけです。 自分の成果物がどれだけ補正されて成立しているかを、支援を受けている側から測ることはできません。

この三つが重なると、自己評価と周囲の評価は年々離れていきます。 本人の中では、完了したタスクと経験年数が積み上がっている。 周囲から見れば、課題の理解、設計の判断、原因の切り分けといった基本的な能力が、ほとんど変わっていない。 どちらかが嘘をついているわけではありません。 本人はタスクの完了数を見ており、周囲は判断の中身を見ているという、見ている対象の違いです。

そして、このギャップは放置される時間が長いほど埋めにくくなります。 「このやり方で何年も成果を出してきた」という実績が本人の中に積み上がり、周囲の指摘を退ける根拠として機能してしまうからです。

そのコストは誰が払っているか

生成する本人が便益を得て、検証のコストを周囲が負担する。 この構造を、個人の能力の問題としてではなく、便益とコストの帰属が分離した構造の問題として捉えた研究があります。 Reddit と Hacker News の投稿 1,154 件を質的に分析した論文1は、AI 利用者が生成速度という便益を得る一方で、レビュー、修正、保守といったコストをレビュアーやチーム全体へ外部化する構造を、共有地の悲劇として整理しています。

AI によって生成のコストが下がるほど、提出される成果物の量は増えます。 一方で、人間が検証する速度は変わりません。 このため、シニアエンジニアのレビュー資源は相対的に希少になっていきます。

組織はこれに対して防衛策をとり始めると考えられます。 論文でも、小さな PR の要求、提出前のセルフレビューの必須化、口頭でのコードウォークスルーといった対策が挙げられています。 「AI が生成したコードであっても、提出した時点で本人のコードである」という責任規範を、人事評価に反映している事例も紹介されています。

キャリアの観点から見ると、これは次のことを意味します。 AI agent operator の働き方は、周囲が下流コストを負担してくれる環境でしか成立しません。 組織がそのコストを可視化し、提出者に説明責任を求めるようになるほど、この働き方が成立する場所は狭くなっていきます。

キャリアはどう分かれるか

今後のプログラマーのキャリアは、「AI を使えるか」では分かれないでしょう。 使うこと自体は、誰にでもできるようになっていくからです。 分かれるのは、ここまで述べてきた二つの働き方のどちらを続けるかです。

AI-assisted engineer として働く人は、自分で問題を理解し、設計、実装、検証を行い、AI を増幅装置として使います。 一人で扱える範囲が広がるため、市場価値は高くなる可能性が高いです。

AI agent operator として働き続ける人は、短期的には一定の生産量を出せます。 しかし、判断を伴わない操作は手順として標準化しやすいため、同じ仕事はより安価な人材や、より高性能なエージェントに代替されやすくなります。

分岐点はどこにあるか

二つを分けるものを一言でいえば、自分が生成していない成果物について、責任ある判断ができるかです。

AI なしで全部書けるかどうかは、分岐点ではありません。 エージェントの性能が上がるほど、全部を手で書く場面自体が減っていくからです。 問われるのは、AI が間違っているときに止められるかです。

この能力の土台として、コードを読んで内容を理解できるスキルは最低限必要だと考えます。 AI がコードを書いてくれるなら、人間はもうコードを読めなくてもよい、という見方もあるかもしれません。 しかし、コードを読めなければ、AI が設計した内容の良し悪しを評価することも、内容を補正することも、誤りを指摘することもできません。 評価も補正もできない人に残るのは、AI の出力をそのまま受け入れることだけです。 書く作業は AI に任せられても、読んで判断する作業までは任せられません。 判断まで AI に任せてしまうと、その判断が正しいかを確かめる主体がいなくなるからです。

止めるためには、成果物を理解している必要があります。 ここでいう理解とは、コードが動いたことでも、AI の説明を読んだことでもありません。 少なくとも次ができる状態を指します。

  • 自分の言葉で説明できる
  • 前提条件を挙げられる
  • 別の選択肢と比較できる
  • 失敗する条件を挙げられる
  • 変更による影響を予測できる
  • AI の説明なしでも再構成できる

これができない成果物を提出しているなら、その品質は誰か別の人が保証しています。

自分の働き方を確かめる問い

自分がどちらの働き方をしているかは、日々の仕事の中で確かめられます。

  • AI に課題を渡す前に、自分の理解と仮説を書いているか
  • AI の提案を却下した経験があり、その理由を説明できるか
  • 提出した成果物について、各処理の意図を口頭で説明できるか
  • テストケースを自分で設計しているか
  • 障害が起きたとき、AI に聞く前に自分の仮説を立てているか

当てはまらない項目が多いなら、AI の利用で生産性が上がっているように見えても、経験しているのは operator の仕事です。

働き方を変えるために、AI の利用をやめる必要はありません。 変えるのは順序です。 AI を使う前に、自分の仮説、設計、判断を先に書きます。 そして AI の出力に対して、採用した部分、却下した部分、正しさを確認した方法、自分では確認できていない部分を区別します。 この最後の「自分では確認できていない部分」が、現時点で自分が品質責任を持てない範囲です。 その範囲を自覚し、少しずつ狭めていくことが、AI 時代の能力開発だと考えます。

おわりに

AI 時代に厳しくなるのは、コードを書けない人ではありません。 コードを書く作業自体は、エージェントが引き受けていくからです。 厳しくなるのは、コードを読めない人であり、自分が生成していない成果物について、責任ある判断ができない人です。

開発チームの役割も、コードを書く集団から、ソフトウェアについて判断し、品質と結果に責任を持つ集団へ変わっていくでしょう。 その中で開発者のキャリアを支えるのは、AI への指示の上手さよりも、AI が間違っているときに止められる能力です。

  1. "An Endless Stream of AI Slop": How Developers Discuss the Burden of AI-Assisted Software Development。開発現場の生産性を直接測定した研究ではなく、オンライン上の議論の質的分析であり、著者自身も頻度を一般化できないことを限界として挙げています。↩

直近1年の AI Agent を使ってシステム開発してきた所感

ai development issue

私が業務に AI Agent を活用できるようになったのは次の fukabori.fm のエピソードを聞いてからです。

iwashi さんと twada さんの話しを聞いて、ようやく ai を使った開発についての展望や方向性を自分の中で納得できた。これまで界隈の盛り上がりと周りの人の話しに対して、自分の懸念を解消できていなかった。時代の変化についていけないからプログラマーをやめようかとも考えていたのが、もう少しがんばってみようと思う fukabori.fm/episode/131

— t2y (@t2y.bsky.social) 2025-07-17T07:33:38.345Z
bsky.app

その後、業務において自分が把握していることを Claude Code を使って少しずつ委譲するようになりました。最初は依存関係の少ない新機能モジュールや、コードレビュー・テストコード生成のスキル化など、徐々に活用する場面を増やしていきました。そして2026年4月頃から、原則、私は手書きでコードを書かないという制約を自分に課し、90% 以上のコードを業務で Claude Code に書いてもらっています。plan ファイルと実装コードのレビューをすべて自分で行っているので初期実装の品質は高くなっていますが (品質を数値化できないので生産性に言及しにくい) 、開発の生産性は数10%程度上がっているかな？ぐらいの、経営陣からみたら AI Agent を使いこなせない方の開発者かもしれません。

その過程で感じた所感を、Claude とやり取りして本稿にまとめます。

まったくの余談ですが、少し前に Armin Ronacher 氏のループエンジニアリングについての記事を読みました。

lucumr.pocoo.org

いろんな読み方ができるとても素晴らしい記事だと思います。システム開発の未来はループやハーネスを人間が整備していく、プロダクトに対してメタ的な取り組みをしていくことに対して多くの人は疑っていないのではないかと思います。しかし、その過程で発生する障害やバグなどの責任は誰がどのように引き受けるのでしょうか？

AI Agent の生成物に対して AI は責任をもちません。AI 活用の成果物の責任は人間にあります。プログラミングに真摯な開発者ほど責任の所在に悩むと思います。これまでは自分が作った成果物で不具合を発生させた場合、その責任は自分にあることを疑う余地はありませんでしたし、そこに葛藤や逡巡を抱くことは少なかったように思います。

しかし、AI Agent のコード生成の分量は圧倒的であり、人間がレビューできない分量を生成させ、うまく活用できれば開発の生産性に寄与できるものの、レビューも任せて大きな失敗をもたらしたときの責任の所在はどこにいくのでしょうか？AI Agent がコミットしたコードを許可した開発者が負うのでしょうか？そのとき開発者はまさにそれは自分の責任だと認められるでしょうか？

冒頭で私は業務におけるコードの実装はすべて自分でレビューしていると書きました。実装のレビューをしなくてもコンテキストが正しければ90%以上は正しいコードであり、テストコードで振る舞いを検証する限り、すぐに問題を起こさないことは私自身も実践から理解しています。しかし、AI Agent が誤るかどうかとは別の視点で、私は開発者として品質に責任をもつ行為をプロとして行っているかどうかもとても気になっています。いくらでも AI Agent に委譲はできますが、その責任を無制限に取ることはできないようにも感じています。私はプログラミングにアイデンティティを感じており、プログラミングに真摯であるほど、この答えは重要な意思決定になります。その答えを私はまだもっていません。

ここからは、先の Claude との会話を Claude Code に読ませ、ブログ記事として書かせた内容を私がレビューしてまとめた成果物です。私の意図を伝えたり、よくわからない説明を訂正させたり、私が考えていないことを書いているところは削除したりしているものの、100% Claude Code が書いた文章です。

私が学ぶための教材のようなものです。私と同じ価値観や課題意識をもっている人には役に立つかもしれませんし、そうじゃない人向けにはただの AI slop コンテンツにみえるかもしれません。

長文を読むのがしんどい方向けに要約です。

Claude Code の登場は、20年プログラミングを続けてきた筆者のアイデンティティを揺るがした。だが plan を書いて AI に実装させる往復を続けるうち、それが昔ながらの設計のフィードバックループだと気づく。

plan をどれだけ作り込んでも、抜けや漏れは出る。専門知の大半は暗黙知であり、完全な仕様は原理的に書けない。だが人間は、生成できなくても、見せられれば誤りを認識できる。この非対称を使い、往復の中で暗黙知を引き出せばよい。特に漏れやすい非機能は、頭の中に答えがなく、動かして初めて発見されるものなので、plan を厚くするのではなく、検証の条件を書き、横断的な関心事を基盤側へ押し上げて対処する。実装からの重い手戻りも、実装前に戦略を文章化させる内側の安いループで減らせる。ただし設計とは問題を理解していく過程そのものであり、この往復は消せない。理解の構築まで AI に明け渡すと、本当の成果物である自分の理解が空洞化する。

シニアの価値は、手書きの速さから、アーキテクチャ判断、検証ハーネスの設計、開発プロセスを設計するメタ認知へと移る。ただし理解の空洞化への誘惑、経験が次世代で再生産されない懸念、価値の見えにくさという罠もある。コーディングの皮を剥ぐと、中にあった判断や理解という本体が残る。コンパイラ登場時と同じく、熟達の本体は無傷だった。そしてその本体を駆動し続けるのは、委譲できない好奇心だ。

手書きをやめても、やっていたのは設計だった

AIエージェント時代に、シニアエンジニアの価値はどこへ移るか

1年ほど前、Claude Code が登場したとき、私は自分のアイデンティティに小さくない衝撃を受けた。 プログラミングそのものが好きで楽しく、業務でもプライベートでも20年以上続けてきた。 その継続がスキルの熟達を生み、私をシニアエンジニアにしてくれた。 だからコードを書く行為が機械に委ねられていく光景は、職能の中心を抜かれるように感じられた。

ところがこの数ヶ月、自分では一行も手書きせず、先に plan（実装前に作る設計文書。以下 plan と呼ぶ）を書いて設計を固めてから Claude Code に実装させる進め方を続けてみて、感覚が変わってきた。 plan ファイルを手直しし、実装させてみては plan に戻り、また実装を直す。 その往復を繰り返すうちに、これは従来のシステム開発でやってきた設計の営みと、ほとんど同じだと気づいた。 コードを手書きしなくなったのに、昔やっていたことと大きくは違わない。

この記事は、その1年で感じたことの整理である。 手書きのプログラミングを手放した先に何が残るのか、シニアエンジニアの価値はどこへ移っていくのか。 現場で20年やってきた経験と、Claude Code を使い込んで得た実感の両方から書く。

設計のフィードバック

整理の出発点に、一枚の図を置きたい。 井上誠一郎氏が WEB+DB PRESS Vol.74 に書いた「良い設計の基礎知識」に出てくる、設計のフィードバックを描いた図である1。 図では、「ニーズ」「要望」「欲求」が上から「要求・要件（何を作るか）」に流れ込み、そこから「仕様・コード（どう作るか）」へ下る矢印に、設計とは考える工程だという注記がつく。 そして仕様やコードから要求や要件へ戻る大きな矢印が「コードのフィードバック」、仕様やコードのところで回る小さな矢印が「リファクタリング」だ。 この記事は、その設計のフィードバックという考え方を借りて始める。

plan と実装の往復は、昔ながらの設計だった

最初に腑に落ちたのは、plan と実装を行き来する構造が、その設計のフィードバックループそのものだということだった。 要求や要件があり、それを仕様とコードに落とし、コードを見て要求の理解を改める。 この矢印の往復は、引用した図が描く設計プロセスと完全に一致する。

Claude Code の動き方も、まさにこの構造で説明できる。 公式ドキュメントは、その中核を agentic loop と呼び、タスクを「コンテキスト収集、行動、検証」の3つの局面の反復として定義している2。 各ツールの実行結果が次の判断に戻り、人間もそのループの一部としていつでも割り込んで方向を直せる。 plan モードは読み取り専用のツールだけで計画を立て、承認を経てから実行に移る仕組みで、設計という考える工程を実装から物理的に切り離す装置になっている。

ここで言葉を1つ整理しておきたい。 ドキュメントは harness（ハーネス）を正式な用語として使い、Claude Code を「言語モデルを取り巻き、ツールとコンテキスト管理と実行環境を与えて、有能なコーディングエージェントに変える層」と定義している[^docs-loop]。 ただし、そのハーネスを設計し運用する工学に、名前のついた学問分野は今のところ存在しない。 harness という装置は公式の概念だが、それを体系として立ち上げる営みは、まだ命名されていない。 私が実務で手探りしているのは、後者のほうである。

この往復を、フィードバック制御の系として読むと見通しがよくなる。 仕様が目標値、コードベースとエージェントが制御対象、人間とハーネスが制御器、テスト結果や挙動が観測信号にあたる。 系がうまく収束するか、それとも修正がかえってぶれを広げて、いつまでも落ち着かない状態（発振）に陥るかは、仕様と実挙動の差を測れるか、介入が実際に効くか、ループが安定するかで決まる。 plan と実装の行き来は、制御系でいう過渡応答だ3。 ハーネスをうまく調整すれば過渡は短くなり、仕様が曖昧なら発振する。

そして決定的に変わったのは、ループの単価である。 設計を試すために実装してみるコストが激減した。 ここには落とし穴もあって、実装が安いと、考える工程を飛ばして総当たりでループに答えを探させたくなる。 だが私の経験はむしろ逆で、先に plan を作る規律は依然として効いた。 コストが下がっても、収束させるには設計がいる。

暗黙知は、言語化しきれない

plan を作り込む過程で、すぐに壁に突き当たった。 頭の中にある情報をすべて言語化して伝えようとしても、暗黙の前提や知識があり、どうしても抜けと漏れが出る。 生成された plan を読み直して、この制約が抜けている、この考慮が落ちていると気づく。 人間は、開発対象のすべてを言語化できるほど賢くない。

最初はこれを自分の能力不足だと感じていたが、それは誤診だった。 Michael Polanyi が「人は語れる以上のことを知っている」と言ったように、専門知の大半は暗黙的で、手続きや文脈と結びついていて、そもそも言語化になじまない4。 しかも、熟達するほど暗黙知の比率は上がる。 初心者はむしろ、習いたてのルールをそのまま使って動くから言語化しやすい。 私が抜け漏れを強く感じるのは、対象に深く詳しいからであって、能力が足りないからではない。

Peter Naur の「Programming as Theory Building」が、この感覚を正面から説明してくれる5。 彼は、プログラミングの本当の成果物はコードでもドキュメントでもなく、プログラマの頭の中にある理論、つまりプログラムが現実世界とどう対応するかのメンタルモデルだと論じた。 そしてこの理論は、いかなる文書にも完全には移せない。 plan ファイルは、頭の中の理論の、一部が欠け落ちた写しでしかない。 完全な plan を書くことは原理的に不可能で、もし書けたとしたらそれは実装と同じ情報量を持つので、もう実装そのものになっている。

このギャップはプロセスの欠陥ではなく、プロセスそのものだ、と捉え直すと景色が変わった。 私は自分の目標値を最初から完全には書けない。 自分の意図に完全にはアクセスできないからだ。 plan を読み直して「この制約が漏れている」と気づく瞬間こそ、暗黙知が形式知に変わる瞬間であり、ループはその意図を事後的に引き出すための手段になっている。

ここに、人間の強みを活かす非対称がある。 私は制約の完全なリストを生成することはできないが、plan を見せられれば欠落を認識することは瞬時にできる。 生成より認識のほうがはるかに易しい。 AI を使うワークフローは、この非対称を突いている。 候補を安く生成するのは機械にやらせ、間違いを認識する側に人間が回る。 「言語化できない」は、「だが見せられれば間違いに気づける」と必ずセットで捉えるべきだった。

だから私は、完全な plan を一度で書き切ろうとするのをやめた。 やめたというより、一度では書けないと認めたほうが近い。 これは努力すれば埋まる不足ではなく、人間の能力の限界として受け入れる種類のことだった。 plan は一度で仕上げる仕様書ではない。 生成されたものを読み直しては漏れに気づき、また直す。 その往復のなかで少しずつ形になっていく、途中経過の文書なのだと考えるようになった。

漏れるのは非機能だった

漏れる項目の正体を見ていくと、業務ルールやデータの不変条件といったドメイン制約よりも、性能、障害時の挙動、並行性といった非機能と運用の側に偏っていた。 そしてこの偏りには、はっきりした構造的な理由がある。

1つ目に、非機能は、機能で分ける軸とは別の軸に沿っている。 機能要件は一箇所に存在する。 チェックアウト処理が何をするか、という記述はその節に収まる。 だが並行性や性能や障害時の挙動は、複数のコンポーネントが組み合わさって初めて現れる性質で、plan のどの節にも属さない。 plan を機能分解の順に節ごとに書くと、機能の軸に沿わない関心事は節と節の隙間に落ちる。 書き方の構造がそうさせるので、注意しても防げない。

2つ目に、人は正常系しか頭の中でシミュレートできない。 設計を理解しているとは、正常系を再生できることとほぼ同義で、想像は放っておけばそこばかりをなぞる。 負荷の下での性能、トランザクション途中のコネクション断、並行時の競合は、頭の中のシミュレーションが自然には走らせない条件でしか現れない。

3つ目が決定的で、非機能の知識は、しばしばまだ誰の頭の中にも存在しない。 ドメイン制約は「頭にはあるが言語化できない」暗黙知だったので、引き出すことで対処できた。 だが p99 のレイテンシも、競合が起きる正確な条件も、実際に走らせて観測するまで誰も知らない。 非機能は思い出すものではなく、発見するものだ。 だから、いくら plan を厚くしても埋まらない。 引き出す対象が、そもそもまだ存在しないからである。

ここで戦略が反転する。 ドメイン制約への対処は、頭の中にすでにあるものを、いかに漏らさず書き出させるかだった。 いわば口述筆記の精度の問題だ。 非機能への対処はそうではない。 まだ誰も知らない性質が現れる条件を作って動かし、観測する。 実験の問題である。 制御工学では、モデルに載せきれない振る舞いを「より完璧なモデルを作る」ことでは決して潰さない。 不可能だからだ。 代わりに、フィードバックと、余裕を持たせた頑健な設計で対処する。 plan を厚くしても非機能が漏れ続けるのは、フィードバックで対処すべき問題を、モデルの精密化で解こうとしているからだった。

具体的にやることは、いくつかに整理できた。 正しい応答は予測できない（それが発見の対象だ）が、外から加える負荷や障害なら列挙できるので、仕様の語彙を挙動から条件へ移す。 依存先の障害モード（タイムアウト、部分障害、リトライ、遅延）はほぼ定型のカタログなので、「N 並行で走らせろ」「書き込み途中で接続を殺せ」「依存先に 500ms の遅延を入れろ」と書ける。 そのうえで、並行性、障害、資源、性能、可観測性を、独立した軸として一つずつ点検して回る。 非機能は機能分解の隙間に落ちるから、機能の節とは別に、専用のチェックリストを当てて軸ごとに総ざらいする。

ただし、最も効いたのは個別の対処ではなかった。 横断的な関心事を、アーキテクチャやフレームワークの層へ押し上げて、機能ごとの plan から消すことだ。 非機能が plan から漏れる根本の理由の1つは、本来横断的であるべき関心事を機能単位で扱っていることにある。 毎回の plan が並行性、障害、リトライを独立に正しく書かねばならないなら、毎回漏れる。 これらを基盤となる共通部品に集約すれば、機能単位の plan はそれらを書き起こす必要がなくなる。 基盤側が引き受けてくれるからだ。 こうした横断化は新しい発想ではなく、宣言的なトランザクション境界やリトライやタイムアウト、コネクションプールの設定として、多くのフレームワークがすでに提供してきたものだ。 plan の漏れる表面積を減らす最も確実な手は、漏れやすい関心事をコード側でも横断化して、一度だけ扱うことだった。

実装してみて初めて、仕様が完成する

plan を何度もやり取りして合意に達したあと、実装させてみて、その実装コードから設計を見直す。 この往復が、plan だけを作っているときよりもずっと多い。 これは冒頭の図が予言していた。 仕様やコードから要求や要件へ戻る「コードのフィードバック」は、あの図でいちばん大きな弧として描かれている。 実装を見て初めて抜けに気づくこともあれば、抽象的な機能の説明から適切な実装や戦略が選ばれていないこともある。 将来の拡張のために設計思想を足すこともある。

この往復が最も重くなるのは、効率が悪いからではなく、新規の設計では実装こそが仕様を完成させるという原理による。 Donald Schön は、設計を plan から実行への一方向ではなく、材料との対話として描いた6。 実践者が手を動かすと状況が応答し、その応答を受けて問題を立て直す。 私が実装を見て抜けに気づくのは、コードが応答している瞬間だ。 Horst Rittel の言う厄介な問題の言い方を借りれば、解いてみるまで問題は理解できない7。 往復が重いのは、設計が新規であることの当然の帰結なのだ。

ただ、この重い往復には、性質の違う2種類が混ざっている。

1つは、実装して動かしてみて初めてわかる性質だ。 事前には知り得ないので、ループを回して発見するしかない。 この往復は減らせない。

もう1つは、私が抽象的な「何を作るか」を書き、エージェントが「どう作るか」の戦略を勝手に選んだ結果、その戦略が的外れだというケースだ。 見れば即座に「その戦略ではない」とわかる。 新しい発見ではなく、plan から実装までの飛躍が大きすぎただけだ。

後者は、減らせる。 鍵は、気づくのが遅れるほど認識のコストが上がる点にある。 500行を書かせたあとで戦略の誤りに気づけば、その500行を読んで判断するはめになる。 だが同じ誤りも、実装の前に戦略を一段落の文章で書かせておけば、その一段落を読むだけで気づける。 先に述べた、生成より認識のほうが易しいという非対称を、コード全体ではなく戦略のレベルで先に使うわけだ。

そこで、修正のループを二重にする8。 外側は重くて遅い実装の往復、内側は速くて安い言葉の往復とし、訂正をできるだけ内側で済ませて、外側は実装しないと知り得ない発見だけに使う。 具体的には、plan と実装の間に戦略チェックポイントを挟む。 採る方針、主要な設計判断、トレードオフ、捨てた選択肢を、実装の前に文章で書き起こさせてレビューする。 plan モードで分析と計画を先に済ませる二段構えに、戦略の言語化という層をもう一枚足す格好だ。

戦略を事前に言語化できないときは、間違った実装を、使い捨ての探りとして意図的に使う。 安く実装させて応答を引き出し、捨てて plan を直す。 Claude Code はファイル編集をスナップショットしていて巻き戻せるので、探りのための実装を安全に捨てられる。 実装を成果物としてではなく、観測のための道具として扱う。

つまり、目指すのは往復の回数を減らすことではない。 一回の往復を安くすること、そして往復で得た発見を書き残して、次の機会に同じ発見をやり直さないことだ。 往復が多いのは言語化の失敗ではなく、新しいものを設計していることの証拠である。

最後に挙げた「将来の拡張のための設計思想」だけは、性質が違う。 暗黙知の引き出しでも未知の発見でもなく、まだ起きていない未来に賭ける判断だ。 過去の多くのプロジェクトで「この種のものはいずれ変わる」と繰り返し見てきた経験知が、目の前の硬直した実装を見て初めて立ち上がる。 ここは安易に委譲してはいけない部分だと考えている。 どの未来に備えるかの判断は YAGNI と常に緊張関係にあり、備えるべき未来を選ぶ目利きこそシニアの価値の核だからだ。 エージェントに拡張性の判断を生成させると、たいてい使われない抽象化に膨らむ。 ただし、ひとたび「ここは差し替えに備えて隔離すべきだ」と判断が固まったら、それはもう形式知なので、機能ごとに導き直さず、プロジェクトとして守る設計原則として書き残す。

設計とは、問題を理解していく過程

ここまでの層をさらに掘ると、本体が見えてくる。 要件や機能によって戦略はケースバイケースで選ばねばならないが、何が最適かの答えは事前にないことが多い。 設計を進める過程で、解くべき課題を私が深く理解していき、その理解が深まることで、適切な戦略としての実装を選べるようになる。 順序が逆なのだ。 気づきが少ない状態では、適切な設計や実装の指示をそもそも出せない。

これは、伝達の問題でも発見の問題でもない、認知の問題だった。 ループは仕様を伝える手段でも未知を発見する手段でもなく、私が問題を理解していくための媒体だった。 plan ファイルは、作業者に渡す仕様書ではなく、私自身の育ちつつある理解を外に置いた足場だった。

Rittel の厄介な問題の中心命題が、まさにこれである。 問題は、解を定式化したあとでしか理解できない。 よくわかっている問題なら理解してから解く順だが、新規の設計はそうならない。 Schön の言葉を借りれば、難所は適切な戦略の選択（問題を解くこと）ではなく、問題に名前と枠を与えること（問題を立てること）のほうにある[^schon]。 問題を正しく立てられれば、戦略はしばしば自明になる。 最適な戦略が事前にないのは当たり前で、それは問題の立て方が決めるものだからだ。

これは、ずっと引いてきた制御の比喩の到達点であり、限界点でもある。 古典的な制御は、固定された目標値を追いかける前提だった。 だがここで起きているのは、目標値そのものが、動かしてみながらだんだん定まっていく状況だ。 対象を思いどおりに動かすより前に、まず試しに動かして、対象の素性を知る必要がある。 この探りは、目先の効率を犠牲にしてでも打たないと、素性は見えてこない9。 私の重い往復は、非効率なのではなく、素性を知るための探りそのものだった。 最適にやってもこれは消えない。

ただ、この見方は使い方の前提を1つ反転させる。 ループが私の理解を構築する媒体なら、ループを AI に明け渡すと、理解を構築するのが AI になる。 Naur の理論、つまり本当の成果物が頭の中のメンタルモデルだったことを思い出すと、これは静かに深刻だ。 理解の構築を委譲した結果のコードは、動くが、理論の保持者がいない状態で生まれる。 plan を深く追わずに承認を重ねると、ループは効率的に見えて、実際の成果物である私の理解が空洞化する。 両取りのつもりが両損になる。

だから、往復を恐れる必要はないが、それはループが私の頭に理解を積み上げている限りにおいて、という条件がつく。 「コーディングを取り除く」を正確に言い直すと、「タイピングは委譲するが、理解を構築するループには自分が乗り続ける」になる。 委譲するのは手であって、関与ではない。 ここの線引きを雑にやると、価値を磨いているつもりで空洞化する。 私は委譲の境界を、コードの複雑さではなく、自分の理解が及んでいる境界線に引くようにしている。 理解が固まった部分は実装を任せ、まだ形成中の部分は AI に探りを入れさせて、ループは自分で回す。

シニアエンジニアの価値はどこへ移るか

20年やってきた経験は、この変化の中で一様には引き継がれない。 ここを正直に切り分けないと、見立てが甘くなる。

価値が下がるのは、手書きの実装速度、言語やライブラリの細部の習熟、局所最適化の小技だ。 かつて生産性の差を生んだ部分で、これは機械がやる。 巧いコードを速く書けることをアイデンティティにしてきたほど、その喪失は、自分が何者かという足場を揺らすほど痛い。 深いデバッグや、システムの病理を嗅ぎ当てる力は変わらず要るが、差別化にはなりにくくなる。 価値が増すのは、境界をどこに引くかのアーキテクチャ判断、検証ハーネスの設計、備える未来の選択、失敗モードの予見、そして開発プロセスそのものを設計するメタ認知だ。 価値が増す側が、私が大事にしてきたソフトウェア工学の視点、課題管理、チームビルディング、価値のデリバリーとほぼ一致するのは、偶然ではないと思う。

最大の変化は、てこの利く場所が、成果物そのものから、成果物を生み出す仕組みへ移ることだ。 手書きの時代、シニアの出力は自分のタイピング速度と、調整できるチームの規模に縛られていた。 Brooks の法則 10 も Conway の法則 11 も、煎じ詰めれば、人を増やすと調整コストが出力を食うという制約の話である。 エージェントとループの時代には、複数のループを並行に走らせる指揮者になる。 ボトルネックが「どれだけ速く作れるか」から「いくつのループを、互いに矛盾なく検証の通った状態に保てるか」へ移る。

もう1つ、何が長持ちする資産かも変わる。 生成されたコードはビルド成果物に近づき、本当の資産は、仕様とハーネスと、蓄積された文脈のほうへ移る。 冒頭の図でいちばん上にあった「要求・要件（何を作るか）」が、最も耐久性のある入力資産になる。 何を作るかという意図を課題として管理することがエンジニアリングの中核業務になり、コードレビューは、仕様のレビュー、ハーネスのレビュー、挙動のレビューへ組み替わっていく。

ここで20年の経験が効く。 並行する複数のループが前提のズレで発散し、統合で苦しみ、暗黙の仮定が食い違っていく失敗は、人間のチームで見てきた失敗そのものだ。 マイクロサービスのチームがなぜ分岐するかを知っている者は、並行するエージェントがなぜ少しずつずれていくかを知っている。 Conway の理解が、そのまま複数エージェントを編成し調整する設計の力に化ける。

ただ、「経験があるシニアが有利だ」を額面どおりに受け取ると足をすくわれる。 3つ、不都合な点を置いておきたい。

1つ目は、理解の空洞化が、今度は自分の生産性への誘惑と戦う形で来ることだ。 ループを任せれば、理解は浅いまま、出せる機能の量だけ増える状態に静かに移行でき、組織はその量を褒める。 承認スタンプを押す係に劣化したシニアは、自分を守っていたはずの優位そのものを失う。 優位は自動では続かず、自分の生産性への誘惑に抗う規律としてしか維持できない。

2つ目は、この優位が一世代限りで途切れるかもしれないことだ。 私の暗黙知は、20年ぶんの手書きとデバッグと悪いアーキテクチャの痛みが作った。 若手がもうコードを手で書かないなら、彼らはどうやってシニアになるのか。 これは個人のキャリアの話であると同時に、分野全体の構造問題で、私は楽観できていない。

3つ目は、価値の見えやすさが落ちることだ。 「5万行書いた」は誰の目にも見えた。 「致命的になる3つのアーキテクチャ判断を下し、作らなくていい4つを作らなかった」は、測りにくく、見せにくく、報酬に結びつけにくい。 組織は、防いだ問題を評価するのが下手だ。 価値はより本物になるが、より見えにくくなる。

これらを踏まえると、働き方としていちばん近い姿は、レンガは積まないが図面と判断が建物の成否を決める建築家であり、指揮者であり、編集者だ。 これまで一部のシニアが例外的に担っていた判断、アーキテクチャ、レビュー、育成、理論の保持が、稀な頂点ではなく標準のモードになる。 そこに、手書きの時代には名前のなかった専門性が1つ加わる。 開発のシステムそのものを設計する仕事、つまりハーネスとループの工学だ。

この工学の中身を1つだけ挙げるなら、検証の独立性である。 エージェントが自分の生成したコードを、自分の書いた甘いテストで検証すると、「テストは通るが間違っている」成果物が量産される。 ループは、自分に都合のよい基準で自分を強化してしまう。 だから、誰が仕様を書き、誰が検証を書くかの分離が、ハーネスの設計では効いてくる。 作った本人の確認だけで品質を保証しない、という古くからの知恵が、そのままエージェントの世界で新しい意味を持つ。

皮を剥ぐと、本体が残る

ここまで剥がしてきた層、つまり問題を立てること、暗黙知の言語化、走らせて初めての発見、理解構築の媒体としてのループは、どれも Claude Code が連れてきた新しい何かではなかった。 全部、20年やってきたことの名前だ。 変わったのは、束ね方である。 手書きの時代、これらの価値はコーディングという単一の活動の中に溶けて、不可分に見えていた。 だから私たちは、それらを「プログラミングができる」と一括りにし、「速く巧く書ける」を熟達の代理指標にしていた。 コード生成は、その束をほどいただけだ。 コーディングの皮を剥いだら、中に入っていた判断、理解、検証、理論の構築が、別々の名前を持って出てきた。 私が「あまり変わらない」と感じ始めたのは、慣れでも錯覚でもなく、この解体を内側から経験しているからだと思う。

これは歴史的に何度も起きたパターンの最新形でもある。 アセンブリを手で書いていた人にとって、コンパイラは、手書きの機械語に熟達したというアイデンティティを脅かすものだった。 だが振り返れば、その熟達の本体は機械語を覚えていることではなく、計算をどう構造化するかにあった。 コンパイラはコーディングの層を肩代わりし、本体を一段上の抽象へ押し上げただけだった。 私が1年前に受けた衝撃と、その後の「あまり変わらない」は、同じ移行の時系列なのだろう。 衝撃は代理指標を失ったことへの反応で、回復は本体が無傷だったことの発見だ。

ただ、楽観で滑らせてはいけない点が1つある。 代理指標だったと今わかるのは、それが剥がれたあとだからだ。 次に剥がれる層が、今私が「これは絶対に人間の本体だ」と思っている部分でない保証はない。 問題を立てることも検証の判断も、十分に良いモデルとハーネスの前で、どこまでが機械に置き換えられずに残るのか、まだ誰も知らない。 だから賭けるべきは、特定の価値にしがみつくことではなく、剥がれたら次の本体を改めて言葉にし直せる能力そのものだ。 それが、時代が変わっても持ち運べる、いちばん確かなスキルだと思う。

では、これは絶対に委譲できないと言えるものは何か。 あらかじめ用意していた答えはない。 やり取りの中でふいにそう問われて、まっ先に浮かんだのが好奇心だった。 反射的によぎったのは、アニメ『攻殻機動隊 STAND ALONE COMPLEX』のタチコマだ。 記憶を共有し、並列化された AI である彼らが、それでも個性（ゴースト）の兆しを見せていく。 そのきっかけを、あの作品は処理の速さや賢さではなく、好奇心に求めた。 確信があるわけではないが、自分の中から出てきたこの答えは、そう的を外していない気がしている。 ここまで剥がしてきたのは、どれも何かを達成するための手段だった。 手段は、より良い手段が現れれば置き換わる。 だが好奇心は手段ではない。 何を達成するかを決める前に、どの問いに向かうかを選ぶ衝動だ。 エージェントは、与えられた目的に対しては恐ろしく強い。 だが何を面白いと感じ、次にどこを掘るかを内から決める部分は、与えられた目的の外にある。

これは私の経歴の因果を正しく説明する。 私はスキルが熟達したからシニアになったのではない。 好きで楽しいから20年続けられ、続けたことが熟達を生み、熟達がシニアにした。 スキルは結果で、好奇心が原因だった。 だとすれば、手書きの熟達という代理指標が剥がれても、原因のほうは無傷で残る。 むしろ、剥がれたあとに何を再発見するかを駆動するのが、その同じ好奇心だ。

ただし、好奇心が本体だとしても万能ではない。 注意点が2つある。

1つ目は、好奇心が何で満たされるかに左右されて、すり減ることだ。 掘る対象が手書きのコーディングだけだった人は、それを失うと熱が冷めてしまうことがある。 だから、好奇心の向け先を1つに決め打ちしないほうがいい。

2つ目は、好奇心が委譲できないのは内から湧く動機だからで、あくまで自分の内側の話にすぎないことだ。 それを市場や組織が価値として認め、対価を払うかは、まったく別の問題で、ここでも価値が見えにくいという同じ罠が顔を出す。 好奇心はあくまで燃料であって、他人に伝わる価値に変えるには、それがもたらした発見を言葉にして共有する、ひと手間が要る。

シニアエンジニアのこれからは、手書きのプログラミングそのものに固執するのではなく、コーディングの部分をエージェントに委ね、委譲できない領域で新しい価値を磨くことになる。 価値が消えるのではなく、重心が、これまで副次的に扱われてきた層へ移る。 職人性が失われるのではなく、コードの職人性から、システムとプロセスの職人性へ、一段上がる。

私の場合、「プログラミングが好き」というのは本当だが、その底にはもう1つ、「わからなかったことがわかるようになるのが好き」がある。 後者は、対象を選ばない。 手書きのコーディングが消えても、設計でも、ループでも、まだ見ぬ何かでも、わからないことがわかる瞬間がある限り燃え続ける。 何を面白いと感じるかだけは、AI にも組織にも誰にも決められない。 それを手放さずにいられるかが、たぶん、いちばん確かな足場になる。

WEB+DB PRESS総集編［Vol.1～136］ (WEB+DB PRESS plusシリーズ)

WEB+DB PRESS総集編［Vol.1～136］ (WEB+DB PRESS plusシリーズ)

  • 技術評論社
Amazon

  1. 井上誠一郎「良い設計の基礎知識」WEB+DB PRESS Vol.74（技術評論社、2013年）。設計のフィードバックの図は同記事による。電子版は https://gihyo.jp/dp/ebook/2014/978-4-7741-6906-4 を参照。図そのものを誌面から転載する場合は、出典の明記に加えて権利者の許諾が必要になる点に注意。↩
  2. Claude Code の agentic loop と harness の定義は、公式ドキュメント How Claude Code works による。plan モードなどの権限モードは Permission modesに詳しい。↩
  3. 過渡応答とは、制御系に目標値や外乱の変化が加わってから、出力が新しい落ち着いた状態（定常状態）に到達するまでの、途中の振る舞いのこと。行き過ぎたり揺れ戻したりしながら収束していく過程を指す。ここでは、plan と実装を何度か往復しながら設計が落ち着いていく過程の比喩として使っている。↩
  4. Michael Polanyi, The Tacit Dimension (1966). 「We know more than we can tell（人は語れる以上のことを知っている）」は同書の主題を要約した有名な一節。↩
  5. Peter Naur, "Programming as Theory Building" (1985). プログラミングの成果物を、コードやドキュメントではなくプログラマの頭の中の理論（theory）と捉える論考。↩
  6. Donald A. Schön, The Reflective Practitioner (1983). 設計を材料との対話（conversation with the materials）とみなし、問題を立てること（problem-setting）と解くこと（problem-solving）を区別した。↩
  7. Horst W. J. Rittel and Melvin M. Webber, "Dilemmas in a General Theory of Planning" (1973). 厄介な問題（wicked problem）は、解こうとして初めて理解できると論じた。↩
  8. 制御工学では、速い内側のループと遅い外側のループを重ねるこの構成をカスケード制御と呼ぶ。外乱への訂正をできるだけ内側の速いループで済ませ、外側のループの負担を減らす。↩
  9. 制御工学では、実験によって対象の特性を突き止めることをシステム同定と呼ぶ。制御と同定を同時に進めなければならない状況では、目先の制御性能を犠牲にしてでも探りの入力を加える必要があることが知られている。↩
  10. Frederick P. Brooks Jr., The Mythical Man-Month (1975). 人員追加が遅れたプロジェクトをさらに遅らせるという「ブルックスの法則」で知られる。↩
  11. Melvin E. Conway, "How Do Committees Invent?" (1968). システムの構造が組織のコミュニケーション構造を映すという「コンウェイの法則」の出典。↩

(翻訳) GitLab 社で働くのはどのようなものだったか

gitlab development translate

本稿は Yorick Peterse 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。

yorickpeterse.com

また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Yorick Peterse 氏ではなく、本稿のコメント欄にお願いします。

ここから本文です。

GitLab 社で働くのはどのようなものだったか

私は2015年10月に GitLab 社に入社し、6年あまり働いて2021年12月に退社しました。

前に GitLab 社を辞めて Inko に取り組んでいることは書きましたが、2015年から2021年までの間、GitLab 社で働いていたことがどのようなものであったのかについては触れませんでした。理由は2つあります。

  1. 燃え尽き症候群に苦しんでいて、(当時は) 自分の人生の最後の6年間を見直す気力がありませんでした
  2. 私は24ヶ月間の NDA 下にあり、おそらく何の問題も起こさないだろうとはいえ、NDA に違反することなくどこまで議論できるか確信をもてませんでした

その NDA は昨年12月に失効し、私はまだ燃え尽き症候群の影響があると思われますが、GitLab 社での時間をふりかえるエネルギーは少しあります。

この記事は大きく2つの節で構成することにします。1つはまだ覚えていることに基づく GitLab 社での私が働いた概要と、もう1つは私の仕事と経験から学んだことです。

GitLab 社の入社前

GitLab 社に入社する前、私はアムステルダムを拠点とする小さなスタートアップで働いていました。ほとんどのスタートアップがそうであるように、私が退職するまでの数ヶ月間、会社は資金不足に陥り始め、費用を賄うためにオフィススペースの一部を貸し出すなど、絶望的な解決策に頼らざるを得ませんでした。同時に、技術的なレベルではやりたいこと、できることはやり尽くしたという思いもありました。

これと並行して、余暇には Rubinius の開発にも取り組んでいて、様々な場面で Rubinius の利用を検討し、すべてのコードが問題なく動くことを確認するまでに至りました。これは、Nokogiri に代わる XML/HTML 解析ライブラリ Oga の作成にもつながりました。

残念ながら、資金不足とさまざまな技術的問題が重なり、Rubinius の利用をそれ以上追求することはありませんでした。このようなことから、私は Rubinius を本番環境で使用できるほど安定させたいと思い、少なくとももう少し Rubinius の開発に時間を費やせる仕事を探し始めました。

その間、アムステルダムで開催されるさまざまな Ruby ミートアップに参加したり、Rails Girls のワークショップを手伝ったりしました。これらのワークショップのひとつで Sytse と彼の妻に出会い、後のワークショップかミートアップでまた出会いました (もうずいぶん前のことなのでよく覚えていません) 。その中で GitLab 社のことを知り、そこで働くことに興味を持ちました。

2015年の夏のある時、私は Sytse にメールを送り、GitLab 社で働きたい旨を伝え、週に1日 Rubinius で働くスポンサーになってもらえないかと頼みました。その後の会話と面接の結果、私は2015年10月に社員番号28番として GitLab 社に入社しました。私の仕事は GitLab のパフォーマンスを向上させることで、20%の時間を Rubinius に費やすことができました。

その間、私は様々なチームの一員となり、多くの自主性を持ち、数年間で10人の異なるマネージャーに報告し、会社をほぼ消滅させ、GitLab が今日まで使用している様々な重要なコンポーネントを構築し、会社が30人ほどの従業員から2000人ほどの従業員に成長するのを見届け、そして燃え尽き症候群で終わりました。オランダのことわざでは "Lekker gewerkt, pik!" です (がんばって翻訳して) 。

2015-2017

GitLab 社に入る前の会社での最終日は9月30日の水曜日で、その翌日から GitLab 社で働き始めました。つまり、私は週5日オフィスで働くことから、週5日リモートで働くことになったのです。それまでも自宅で仕事をしたことはありましたが、主に線路に積もったわずかな雪や落ち葉のために電車が動いていないときに仕事をしていました。

特に印象に残っているのは、日中に食料品の袋を家まで持ち帰ったことで、仕事から帰ってきて夕方ではなく、日中にそれをすることがいかに素晴らしいかをを実感しました。

もうひとつの思い出は、愛猫とソファで昼寝をしたことです。

https://yorickpeterse.com/images/what-it-was-like-working-for-gitlab/sofa_cat.jpg?hash=ef15409a921d80eea3e9e7f853b1dafb410a0c14a003a1b1947aa7226453b5e1

そう、それはホーマー・シンプソンのスリッパです。

当時私が借りていたアパートは広くなく、小さなキッチンスペースと小さなリビングルーム、そして同様に小さな屋根裏部屋しかありませんでした。そのため、私のリビングルームは、寝室、リビングルーム、オフィスとして機能していました。あまりいい環境とは言えなかったですが、当時の私にはそれしかありませんでした。おそらく高価なアーロンチェアが関係していたのでしょう。

フルリモートの会社であるにもかかわらず、GitLab 社は社交的な会社で、何年もの間、頻繁にミートアップやイベントが開催されていました。例えば、私が入社して数週間後にアムステルダムで会社の集まりがあり、日中は様々なアクティビティ、夜には夕食会がありました。

https://yorickpeterse.com/images/what-it-was-like-working-for-gitlab/amsterdam_dinner.jpg?hash=69193a4e4fe87cea08b63f3712f42e53199b7cd2c894637b060abf312480a8f6

当時はまだ、レストランの一角に会社全体をおさめることができました。

それから間もなく、GitLab 社は最初の成長期を迎え、100人ほどの従業員が新たに加わりました (と思うけれど、現時点では少し記憶があいまいです) 。2016年にオースティンで開催された次の会社の集まりでは、レストランの一角ではもはや十分ではありませんでした。

https://yorickpeterse.com/images/what-it-was-like-working-for-gitlab/austin_gathering.jpg?hash=5f2b4c1565a5b2ba96e1dbb174f96676b88a23d72d097a5eeef439eed79aed18

この間、ネガティブな経験もたくさんありました。GitLab はひどいパフォーマンス、頻繁な機能停止 (ほぼ毎週どこか)、不十分な管理、その他スタートアップが直面する多くの問題に苦しんでいました。その結果、"GitLabは遅い" というのがユーザーからの不満の声の第一位となりました。特に Hacker News では、元のトピック (例えば新機能の発表) が何であろうと、人々は文句を言うのが大好きでした。もちろん GitLab 社はこのことに気づいていましたし、実際 GitLab 社が私を雇った理由の一つはこの問題を解決するためでした。

特に、GitLab 社には適切なパフォーマンス・モニタリングのインフラがなかったからです。当時稼働していた唯一のサービスは New Relic のトライアルアカウントで、当時あった (と思う) 合計15～20台のサーバーのうち1台か2台しか監視できませんでした。このため、どのようなデータであっても正確な表現ではなく、パフォーマンスの測定と解決が困難でした。

これらの問題を解決するのをさらに難しくしたのは、GitLab の要件で、私たちが使うどんなツールであれ、セルフホスティングの顧客が利用できるものでなければならず、できればオープンソースでなければならなかったことです (あるいは、これは難しい要件だったのかもしれませんが、覚えていません) 。つまり、パフォーマンスを向上させるだけでなく、そもそもパフォーマンスを向上させるためのツールを構築しなければならなかったのでした。同時に、パフォーマントなコード (あるいは少なくとも恐ろしく遅くないコード) を書くことは、会社の他のメンバーにとって優先事項とはまったく考えられていませんでした。GitLab 社はまた、社内の苦情よりも Hacker News 上の苦情に耳を傾ける傾向がありました。そのため、社内では「何かを変えて欲しければ、然るべきルートで文句を言うよりも、匿名で Hacker News に文句を言った方がうまくいく」というジョークが飛び交っていました。

その後、数ヶ月間、私はパフォーマンスを改善し、そのために必要なツールを構築し、パフォーマンスに対する会社の文化や態度を変え、時間が経てば実際に改善されるように努め、GitLab がその改善に満足しないことに対処しました。少なくとも何度か、Sytse を怒鳴りつけそうになったビデオ通話があったことをはっきりと覚えています。

このような困難にもかかわらず、私は必要なツールを構築し、様々な部分でパフォーマンスを向上させることができました (重要なものもあれば、そうでないものもあった) 。このツールは "GitLab Performance Monitoring" として知られる GitLab の公式機能になりました。私が作ったもう一つのツールは "Sherlock" で、開発環境で使うためのヘビー級のプロファイラでした。

この間、GitLab は、特にパフォーマンスが会社の他の部分にとって優先事項でない場合、一人の人間を雇うだけではこの種の問題を解決できないことに気づき始めました。その結果、Sytse に直接報告する代わりに、新しい "Performance" チームの一員として専任のマネージャーに報告することになり、そのチームにはさらに人を雇うための予算がつくことになりました。その予算は正確には覚えていませんが、2人か3人だったと思います。会社の規模や、できるだけ多くの機能を生み出すことに主眼を置いていたことを考えると、これでは到底足りなかったが、スタートにはなりました。

2年目の大半は、このチームの一員として過ごしました。より多くのリソースを求めるキャンペーンを続け、新しいコードには優れたパフォーマンスを要件としましたが、結果はまちまちで、もちろん私やチーム全体としてパフォーマンスを改善し続けました。

この間、GitLab 社は最初のレイオフの波を経験し、主に GitLab 社が最初に間違った人を雇った結果、自分の意志で人が去っていきました。その結果、GitLab 社は30数人から130数人 (だったと思う) まで成長し、80数人まで縮小し、また数ヶ月後に成長し始めました。

Rubinius について。私たちは Rubinius で GitLab を動かそうとしましたが、成功しませんでした。Rubinius のメンテナがプロジェクトを別の方向に進めようとしたことと、このことが Ruby コミュニティ内で論争を引き起こしたことも相まって、私たちは最終的に Rubinius に見切りをつけることにし、私は Rubinius での作業を完全にやめました。Rubinius は長年にわたって多くのことを実現してきたのですが、最終的には、プロジェクトを成功させるために必要なこととは異なる方法で運営するメンテナーによって抑制されてしまったのです。

2017-2018

https://yorickpeterse.com/images/what-it-was-like-working-for-gitlab/sytse_giraffe.jpg?hash=06741c66e9a3d93163aa8ab8e653c9a89e85549f13d0e8150b947577f560d74a

最初の不安定な1年半の後、事態は好転し始めた。パフォーマンスは大幅に改善され、GitLab 社はより真剣に取り組み始めた。採用プロセスは大幅に改善され、チェスのゲームのように GitLab 社は適切な人材を適切な場所に配置し始めた。パフォーマンス・チームの範囲も変わりました。パフォーマンス全般に焦点を当てるのではなく、データベースのパフォーマンスに焦点を当てることになり、その一環として "データベース・チーム" というクリエイティブな名称に変更されました。この変更に伴い、人を雇うための予算も増え、新しいデータベースのセットアップなどを手伝ってくれるインフラ・エンジニアも配属されました。

この時期に私が作った決定的に重要な機能は、GitLab のデータベースロードバランサー です (ここで発表しました) 。この機能により、開発者は通常通りデータベースクエリを書き続けることができ、ロードバランサはこれらのクエリをレプリカやプライマリのどちらにも向けないようにします。書き込みを行った後、ロードバランサーは、書き込んだ変更がすべてのレプリカで利用可能になるまで、プライマリデータベースが使用されるようにする。ロードバランサーの導入はパフォーマンスに大きく良い影響を与えました。もしこのロードバランサーがなかったら、GitLab は大変なことになっていたと思います。私が最も誇りに思っているのは、このシステムを透過的に導入できたことです。これまでのところ、(Ruby on Rails はともかく) プロジェクトに追加するだけで使えるデータベースロードバランサーは見たことがありません。その代わり、既存のソリューションは、パズルのほんの一部分だけを提供するフレームワークのようなもので、自分ですべてをつなぎ合わせる必要があり、多くの場合、何のサポートもありません。スタンドアローン・ライブラリーにまで発展させることができなかったのは残念でした。

1月31日、夜遅くまで続く多くの問題に対処する長くストレスフルな一日の後、私は GitLab のパフォーマンス問題を解決しました 誤って GitLab の本番データベースを削除してしまいました 。その結果、システムが長い間機能していなかったため、バックアップがないことが判明しました。また、バックアップのエラーを通知するシステムも機能していませんでした。結局、その日に行っていた作業の一環として、6時間ほど前に本番データをステージング環境にコピーしていたため、復旧はできましたが、復旧には24時間ほどかかりました。約6時間のデータ損失はどう考えてもひどいものでしたが、もしバックアップを取っていなかったらどうなっていたかはわかりません。その日、私の心臓は数拍飛び、白髪が数本増えたことは間違いない。

この間、何度も苛立ちの種になったのは、データベースのロードバランサーを導入した後も、GitLab がデータベースをシャード化したがることでした。私や他のエンジニアや上司は、これが問題に対する間違った解決策だと考えていただけでなく、それを裏付けるデータも持っていました。例えば、シャーディングは書き込みが読み込みを大きく上回る場合に有効ですが、GitLab の場合は読み込みが書き込みを 10:1 の割合で上回っていました。さらに、私たちが保存していたデータ量は、シャーディングを導入する複雑さを正当化できるほどではありませんでした。私たちが雇ったコンサルタントが、"悪気はないのですが、私たちには数桁多い負荷とストレージを持つ顧客がおり、彼らにとってもシャーディングはやり過ぎです" というようなことを言っていたのをはっきりと覚えています。にもかかわらず、GitLab は何年もシャーディングを推し進め続け、経営陣がシャーディングを放置する決断をするまでになりました。

2019-2021

https://yorickpeterse.com/images/what-it-was-like-working-for-gitlab/new_orleans.jpg?hash=804a9dbb2eba8868a70c4a72029890487cfc847ee7e8bf9f234ec0155f885b71

2018年から2019年にかけてのある時期、私はこの4年間、パフォーマンスと信頼性に取り組むことに疲れてしまったため、データベースチームから新しく設立された「デリバリー」チームに移動しました。さらに、複数の人間がパフォーマンスと信頼性に取り組むようになったので、私にとっては新しいことに移る適切な時期だと感じました。この新しいチームの目標は、GitLab のリリースプロセスとツールの改善でした。

例えば、私たちはメインブランチにコミットしてから GitLab.com にデプロイするまでの時間を調べました。その結果、平均して数日かかるが、ひどい場合は3週間かかるというデータが出ました。ここでの主なボトルネックは、GitLab Community Edition と GitLab Enterprise Edition が別々の Git リポジトリとして存在し、定期的に手作業によるマージと競合解決が必要だったことです。そのため、 2つのプロジェクトを1つにマージする のに数ヶ月を要しました。私たちは作業をフロントエンドとバックエンドに分け、様々なチームがそれぞれの分担を分担して貢献するようにしましたが、結局私はバックエンド関連の変更のほとんどを実装し、別の同僚がフロントエンド作業のほとんどを担当しました。

チームの他のメンバーとともに、この期間にリリースプロセスを大幅に改善し、数時間で変更をデプロイできるまでになりました。これは本来あるべきスピードにはほど遠いものの、最悪の場合3週間かかっていたものが、最悪の場合1日程度で済むようになったのは大きな進歩でした。

これまでの期間と同様、この期間も混乱や変化がなかったわけではありません。

2018年は従業員に焦点を当てた GitLab サミットを開催した最後の年であり、2019年以降はより伝統的なカンファレンスのような形式で、より顧客向け、より従業員向けではないものになりました。2000人以上の集まりを開催するのはとてつもなくお金がかかるので、財政的な観点からすればこれは理解できることでした。社交的な観点からは、サミットがより企業的な設定になったことで、以前の形式ほど楽しくなくなったことは損失でした。コンテストで優勝したチームに対して Sytse がステージでダンスを披露したり 、Sytse がキリンの着ぐるみを着て Sytse 夫妻がフィットネス教室を開いたりしたのはいい思い出です。このようなおふざけイベントは、その後の数年間は起こらなくなりました。

ラップトップの管理の問題もありました。会社の Mac ラップトップを要求され、それをどう使うかは多かれ少なかれ自由でした。何年もかけて、GitLab 社の経営陣はラップトップをリモートで管理できるソフトウェアを使おうという議論を始めました。これらの議論で繰り返し問題になったのは、提案されたツールが侵略的で (例えば、ユーザーの行動を記録するために使われる可能性がある) 、悪用に対する保証がなく、主要な社員が経営陣に圧力をかけ始めるまで、社員からのフィードバック (たくさんあった) が無視されるということでした。そして計画は棚上げされ、数カ月後にまた議論がやり直されました。

最も際立っていたのは、提案された変更点ではなく、むしろ経営陣のフィードバックの扱い方であり、変更点全般が、その存在を正当化するために問題を解決しようとしているような雰囲気を醸し出していたことだった。この議論に参加したほとんどの人たち (私も含めて) は、(盗難対策など) 何らかの形でラップトップを管理する必要性を理解していましたが、提案された侵略的な解決策は行き過ぎだと感じていました。

GitLab 社は SentinelOne を使ったラップトップ管理ソリューションに落ち着きました。GitLab 社は、個人のハードウェアを含め、GitLab 社のリソースにアクセスするために使用するハードウェアにこのソフトウェアをインストールすることを従業員に義務付けていました (あるいは、少なくとも義務付けることを検討していました) が、私 (自分のデスクトップ・コンピューターを使っていました) はどういうわけかレーダーを潜り抜け、問題のソフトウェアのインストールを求められることはありませんでした。おそらく、会社支給のノートパソコンを使っていなかったために GitLab 社が私をチェックするのを忘れてしまったのでしょう。

このような文化的な変化と私生活の様々な変化が重なり、モチベーションや生産性が低下し、ストレスが増大し、労働時間が安定しなくなりました。チームのマネージャー (今までで最高のマネージャーだと思う) も別の役割に移り、今は新しく雇われたマネージャーがチームを率いています。私はこのマネージャーと折り合いが悪く、その結果、「業績改善計画」(PIP) が必要になる前に、物事を軌道に乗せるための手順である「業績向上計画」を立てることになりました。PIP は、従業員と仕事、そして雇用主との関係を改善するための最後の試みとして使われるものだ。

私は改善すべき点があることを認めましたが、問題の一端は新しいマネージャーの働き方にあると感じました。経営陣は、PEP は両者の状態を改善することを意味している、つまり私だけに焦点を当てるのではなく、マネージャーにも焦点を当てるのだと保証してくれました。それは実現せず、PEP は私が違うことをする必要があることだけに焦点を当てました。PEP はまた、どのような要件を満たさなければならないかについても少し曖昧でした。当初の計画では PEP は1カ月でしたが、最初の1カ月が終わるころ、上司は PEP をもう1カ月延長することを決めました。そして2ヵ月後、私は PEP を完了し、経営陣はその結果を満足のいくものだと判断した。

私の中の楽観主義者は、私が PEP を実施した最初の従業員であったため、経営陣が状況を把握しながら進めていったのだと信じたいです。私の中の悲観主義者は、この一連の出来事に対してはるかに否定的な意見を持っていますが、それは自分の胸にしまっておきます。

この経験の後、GitLab 社も私も違う方向に向かっていて、当時の状況に満足していなかったので、もしかしたら辞める時が来たのかもしれないと思いました。

そのチャンスは2021年の終わりに訪れました。GitLab 社が上場することになり、ストックオプションを行使できるようになるまでの期間を考慮すると、2021年12月に退職できることになりました。ストックオプションを行使すると、行使手数料と評価額との差額に対して、たとえ株式が流動的でなくても、所得税 (52％) を全額支払わなければならないからです。私の場合、税金が高すぎて払えなかったので、GitLab 社が上場するまで待つことを余儀なくされました。数ヶ月後、法律が変わり、税金を行使時に支払うか、株式が流動化した時に支払うかを選択できるようになりました。注意点は、株式が流動化するまで税金を先延ばしにした場合、ストック・オプションを行使した時点の価値ではなく、その時点の価値に基づいて税金を支払うということです。これは確かに理想的ではなく、財務上のリスクも大きいが、少なくとも選択肢はありました。

こうして株式を取得した私は、2021年12月に退職し、貯蓄を切り崩しながら Inko でフルタイムで働くことになりました。

学んだこと

歴史はさておき、私が GitLab 社で学んだことをいくつか見てみましょう。一つ心に留めておいてほしいのは、これらの知見は私の個人的な経験に基づくものであり、そのため、私が間違っている部分がある可能性は低くないということです。

スケーラビリティは企業文化とする必要がある

GitLab 社が犯した過ち、そして私が退職した後も犯し続けた過ちは、スケーラビリティを十分に気にしなかったことです。確かに、役員たちはスケーラビリティは重要だと言うでしょうし、改善もされてはきたけれど、他の目標ほど優先されることはありませんでした。この問題の核心は、GitLab 社のお金を稼ぐ方法にあります。GitLab 社は主に、GitLab.com ではなく、GitLab Enterprise Edition をセルフホストしている顧客からお金を得ています。 このため、当然ながらセルフホスティングの市場に焦点を当てることになり、GitLab.com で遭遇したパフォーマンスの問題の多くは、多くのセルフホスティングの顧客には当てはまりませんでした。

さらにイライラさせられたのは、多くの開発者が実際にはパフォーマンス向上を望んでいたにもかかわらず、そのための時間とリソースを与えられていなかったことです。

チームをよりデータ主導且つ、開発者主導にする

もう一つの要因は、GitLab のプロダクトマネージャー主導の性質です。主要な開発者の中には、プロダクトの決定に影響を与える能力を持っていた人もいたかもしれませんが (十分に叫んだり蹴ったりすれば)、何を実装すべきかを決めるのは主にプロダクトマネージャーやディレクターでした。これらの決定がとても理にかなったものであることもあれば、「Hacker News で読んだこれは良いアイデアだから作らなければならない」というだけのものであることもありました。

GitLab 社は、今日のような伝統的な多層階層ではなく、もっとシンプルな階層を早い段階から採用していれば、会社としてもっと良いパフォーマンスを発揮できたと思います。特に、プロダクトマネージャーという考え方はやめて、チームリーダーにもっと権限を与えて、ユーザーともっと交流させるべきだと思います。技術的なレベルで製品作りを支援するだけでなく、チームとユーザーとの連絡役としても機能します。

データがなければ、何が「最小限の実行可能」なのか判断できない

GitLab 社の基本原則の一つは、常に「実行可能な最小限の変更」から始めることです。これは、ユーザーに価値をもたらす可能な限り小さな作業単位を提供するという考え方です。机上では素晴らしいことに聞こえますが、実際には「最小」の定義は人によって一貫していません。その結果、あるチームではパフォーマンスや使い勝手の良さを実行可能な要件と考えるかもしれませんし、別のチームではそんなことはどうでもいいということになります。

誰も求めなかったサーバーレスプラットフォームは最終的に廃止され、Kubernetes クラスターを管理するためのサポートは誰にも気づかれることなく3週間も機能しなかったり、既存のソリューションを使う代わりに CI サービスの上に chatops ソリューションを構築しなければならなかったり (その結果、大幅なレイテンシが発生した)、データの作成と閲覧しかサポートしない要件管理機能 (更新や削除さえもサポートしなかった)、これらはここ数年のほんの一例です。

何が実現可能なのかを判断するには、ターゲットとするユーザーの要望を深く理解する必要があります。GitLab 社では四半期ごとにユーザー調査 を行っており、ユーザー・エンゲージメントに関するデータにアクセスできるチームもありますが、私が覚えている限り、また他の元同僚と話して学んだ限りでは、このデータは各チームのワークフローの中核部分ではなく、付随的に使われているようでした。

SaaS とセルフホスティングは相性が悪い

GitLab 社は、セルフホストインストールと SaaS (Software as a Service) の2種類の製品を提供しています。GitLab 社を含め、ほとんどの企業はこのようなセットアップを効果的に提供することはできないと思います。何が一番儲かるかという利害の対立が生じるだけでなく (前述の通り)、2種類のセットアップには異なる要件やアップデートの適用方法があります。

例えば、SaaS の場合、迅速にデプロイでき、一元化されたインフラ上で大量のデータとワークロードを処理する必要があります。ほとんどのセルフホストインスタンスは、SaaS の提供するものに比べて小さい傾向があるため、SaaS として遭遇する問題やそれに対応するソリューションの多くは、セルフホストインストレーションには適用されません。このため、プラットフォームの多くの部分で、SaaS 版とセルフホスト版の2つのコードパスが存在することになります。コードが物理的に同じであったとしても (つまり、セルフホスト型インストレーション用に使いやすいラッパーを提供する場合)、その違いについて考える必要があります。

対照的に、SaaS またはセルフホスティングのセットアップのどちらかに集中する場合、そのセットアップにとって最高のエクスペリエンスを提供することに全神経を集中させることができます。もちろん例外はありますが、それはまさに例外であり、例外はまれです。

人数が多ければ成果が上がるわけではない

GitLab 社は、それ以前の多くの企業と同様、何年にもわたって多くの人を雇用し、現在では2000人以上の従業員を抱えています。そのうちの何人が現在の開発者なのかは知りませんが、チーム・ページをざっと見た感じでは少なくとも数百人でしょう。

プロジェクトに人を増やしても、必ずしも生産性や成果が向上するわけではないことはよく知られています (「人月の神話」も参照) 。しかし、ベンチャーキャピタルを持つ欧米のスタートアップはほとんどすべてこのことを無視しているようで、製品にそれほど多くの開発者が必要でなくても、何百人もの開発者を雇っています。

これを裏付けるデータはありませんが、ほとんどの企業は20人以上の開発者を必要とせず、20人から50人、50人から100人の開発者を必要とする企業はほんの一握りではないでしょうか。開発者が100人を超えたら、さらに人を雇う前に、製品の範囲が手に負えなくなっていないかどうか考え始める必要があると思います。

なお、ここでは特にソフトウェア開発者について話しています。例えば、カスタムメイドのハードウェアを製造しているのであれば、製造工程を拡大するためにもっと多くの人が必要になるでしょう。営業とサポートは、一般的に人数が多い方が有利な2つの分野です。

Ruby on Rails の使用について葛藤している

GitLab は Ruby と Ruby on Rails を使って構築されており、これが今日の成功をもたらした大きな要因です。同時に、この組み合わせは、プロジェクトが大規模になり、経験レベルの異なる多くの貢献者が参加するようになると課題をもたらします。特に Rails では、うまく動作しないコードを導入するのが簡単過ぎます。

たとえば、プロジェクトメンバーの数を示すカウンタとともにプロジェクトのリストを表示したい場合、N+1 クエリの問題 を誤って導入するのはあまりにも簡単です。Rails (より具体的にはActiveRecord) はこの問題を解決する機能を提供していますが、これはオプトインの仕組みであるため、開発者がこの問題を忘れてしまうことは避けられません。私が GitLab 社にいた最初の数年間に解決したパフォーマンス問題の多くは、N+1 クエリの問題でした。

他のフレームワークは何年もかけてこの問題から学び、よりよい代替案を提供してきました。通常のアプローチは、関連するデータを任意にクエリできる代わりに、前もってデータを渡しておくというものです。この利点は、もしデータの受け渡しを忘れても、コードが行ごとにデータを照会してパフォーマンスの問題を引き起こすのではなく、何らかのエラーに遭遇することです。

また、Ruby 自体にも賛否両論があります。一方では、10年弱の間楽しく使ってきた素晴らしい言語です。一方では、メタプログラミングを多用するため、オプショナル型付けが導入されたとはいえ、大規模なプロジェクトで使うのは難しいです。私は数年前に Ruby の静的解析ツール を書いたときに、それを身をもって体験しました。

にもかかわらず、Ruby と Ruby on Rails の組み合わせの代わりに、どのような選択肢を勧められるかわかりません。Go、Rust、Node.js といった言語は Ruby よりも効率的かもしれませんが、Ruby on Rails ほど有能なフレームワークはない。Python や Django も選択肢に入るかもしれませんが、少なくともある程度は Ruby や Ruby on Rails と同じような問題にぶつかるのではないでしょうか。新しいウェブフレームワークが、ルーティングツリーをどう定義するかにこだわるのをやめて、代わりに全体としての生産性をもっと重視するようになれば、おそらく役に立つでしょう。

Inko でこの問題にどうアプローチするか、漠然としたアイデアはあるのですが、Inko でウェブ・フレームワークを書き始める前にやらなければならないことが他にもたくさんあります。

コードのデプロイにかかる時間は、組織の成功に欠かせない

これは GitLab 社に入社する前からわかっていたことで、前職では優れたデプロイとテストのパイプラインの構築にかなりの時間を費やしてきました。GitLab 社では、それに近づくまでに4年ほどかかりました。

(デプロイに何時間もかかることを考慮してコードをホットパッチする必要がない) より効率的にインシデントに対応できるといった明らかな利点のほかに、モチベーションを上げる利点もあります。変更に何週間も費やし、それがデプロイされるまでにさらに2週間かかることほど、やる気を失わせることはありません。

これがうまくいくためには、デプロイにかかる時間や、デプロイの一部としてテストスイートを実行する時間を、驚くほど積極的に削減する必要がある。アプリケーションの種類やテストするサービスの種類によっては、テストの実行にある程度の時間が必要な場合もあります。ここで重要なのは、「テストとデプロイにX分以上かかってはならない」ということではなく、(組織として) ビジネス要件が許す限り、デプロイを高速に行えるようにすることを優先することです。当たり前のことのように思えるかもしれないが、多くの組織はこの分野で、できる限り良い仕事をしていないのではないでしょうか。

場所ベースの給与は差別的だ

GitLab 社であなたが得る給料は様々な変数に影響されますが、その一つが勤務地です。勤務地の影響も取るに足らないものではありません。物理的なオフィスがある会社で、特定の地域で人を雇う必要がある場合、そうでなければ必要な地域で必要な人を雇うことができないかもしれないので、場所によって給与を調整することは理にかなっているかもしれません。しかし、物理的なオフィスを持たず、全世界に法人を持つフルリモートの会社にとって、同じ経験と責任を持つ2人の異なる人材に、純粋に住んでいる場所によって異なる給与を支払う正当な理由はありません。

例えるなら、私が GitLab 社を辞めた時の給料は税引き前で年間約12万ユーロ、月に約8500ユーロでした。オランダではこの給料は良い方で、これより良い給料でフルタイム在宅勤務ができる会社を見つけるのは難しいでしょう。しかし、もし私がベイエリアに住んでいたら、少なくともその2倍、場合によってはそれ以上の収入を得ていたでしょう。ベイエリアの方が仕事ができるからとか、そういう正当な理由ではなく、オランダではなくベイエリアに住んでいたからです。

どう言い繕ったところで、住んでいる場所によって賃金を決めるのは、どう考えても差別行為である。考えてみてください。肌の色や性別を理由に給与を低くしたら、会社は大問題になるでしょう。しかし、住んでいる場所によって賃金が低くなるのは問題ないのでしょうか？

これを解決する方法としては、企業にとっては簡単です。応募者の所在地ではなく、ポジションの要件に基づいて給与を支払えばいいのです。ベイエリアにいる人に年間10万ドル払おうが、フィリピンにいる人に払おうが、企業としてのコストは同じだからです。従業員に対する私の唯一のアドバイスは、より良い給与を交渉してみることですが、場所によって給与を支払う企業も頑固な傾向があるので、これは難しいかもしれません。いつか法律がこの慣習に追いつくことを願っています。

このやり方がうまくいっていると思われる会社に、0xide Computer Company があります。0xide は従業員に勤務地に応じて給与を支払う代わりに、同額を支払っています(詳しくは こちらの記事 を参照) 。

結論

振り返ってみると、GitLab 社で過ごした時間は信じられないほどポジティブな経験とネガティブな経験の両方が混在しています。私が所属していた様々なチームが成し遂げてきた成果や、一緒に働くことができた人たちを信じられないほど誇りに思っていますが、素晴らしい経験を台無しにしてしまったここ1年ほどのことを悲しくも思っています。GitLab 社で働いたことに後悔はありませんし、できることならもう一度やり直したいと思っています。欠点はあるにせよ、他の多くの会社よりもずっと良い会社だと思うからです。

(翻訳) ストーリーポイント再考

development scrum translate

本稿は Ron Jeffries 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。

ronjeffries.com

また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Ron Jeffries 氏ではなく、本稿のコメント欄にお願いします。

ここから本文です。

ストーリーポイント再考

私はストーリーポイントを発明したかもしれない。もしそうだったとしたら、いまは申し訳なかったと言いたい。ストーリーポイントに関する私の現在の考えを探ってみよう。少なくとも何人かは私の考えに興味をもっているでしょう。

もちろん、ストーリーは XP のアイディアであり、スクラムのアイディアではありません。どういうわけか、スクラムの実践者はこのアイディアを採用しています。公式のスクラムガイドではバックログアイテムに言及しているにもかかわらず、バックログアイテムをユーザーストーリーにすることは一般的なスクラムのプラクティスです。

少なくとも限られた範囲では正しいでしょう。ストーリーの一般的な使い方については別のところで書きました。ここでは「ストーリーポイント」について説明します。XP では、ストーリーはもともと時間で見積もられていました。そのストーリーを実行するのにかかる時間です。私たちはすぐに「理想的な日数 (Ideal Days)」と呼ぶことにしました。私たちは理想的な日数に「負荷係数」をかけて、実際の実装時間に換算しました。この負荷係数はだいたい3になる傾向がありました。つまり、理想的な日数分の仕事をこなすのに実質3日かかるということです。

私たちは、見積もりを日単位で話し、通常は「理想的な」という言葉を省略して使っていました。その結果、ステークホルダーは、1日の仕事を終わらせるのにどうして3日もかかるのか、あるいは逆の視点から目を向けて、なぜ3週間で50「日」の仕事ができなかったのか、と混乱することが多くなりました。そこで確か、私たちは「理想的な日数」を単に「ポイント」と呼ぶようにしました。つまり、1つのストーリーを3ポイントで見積もると、完了までに約9日かかるということです。ポイントというのは、あるイテレーションに要する作業量を決めるのに使うだけだったので、20ポイントくらいと言えば誰も反対はしませんでした。

私が名前を変える提案をしたかもしれません。もしそうだったとしたら、いまは申し訳なく思っています。この話題に関する私の現在の考えを、同僚の Simon に宛てたメールから紹介しましょう。

あなたは (ストーリーポイントを) 発明したことを本当に後悔していますか？それとも相対的なサイズを正しく理解していない場合に誤用されることを嘆いているだけですか？

私は次のように返答しました。

  • 確かにその誤用は嘆かわしい
  • 「いつ完了するか」を予測するために使うのは、せいぜい弱い考えだと思う
  • 実績が見積もりと比較してどうなのかを追跡するのは、せいぜい無駄だと思う
  • 見積もりやベロシティの質でチームを比較するのは有害だと思う

もう少し深く考えてみましょう。

「アジャイル」のアプローチの中には、計画を立てやすくするために、チーム間でストーリーポイントを正規化することを推奨しているものがあります。これは表面的には十分に理にかなっているように見えますが、チーム同士を比較するという罠にはまりやすく、実際に組織がそうしてしまうことがあまりにも多いです。

比較

まず第一に、たとえ「同じように見える」としても、それぞれのチームにはそれぞれのスキルがあり、それぞれの環境で仕事をしています。だから、同じように見える2つのストーリーを見て、一方のチームが2ポイントだと言い、もう一方のチームが6ポイントだと言ったとしても、それはあまり面白くないし、チームを比較するのに役立つ方法ではないことは確かなことです。

そのような状況を目の当たりにしたあなたや私は、好奇心を持ってその状況に臨むでしょう。まず比較できるほどその状況が似ているかどうかを確認し、次に高い見積もりを出したチームに、私たちが提供できる何らかの手助けが必要かどうかを探ります。それ自体はいいことです。暗に、あるいは明示的に「遅い」チームが劣っているとか、何かしくじっているとかを結論づけることは、非常に悪いことなのに、残念ながらよくあることです。

2つのチームが何かを生み出しているとき、多くのマネージャーにとって、それらを比較することは抗いがたい誘惑だと思います。これはストーリーポイントという概念を捨て去るほどの抗いがたい誘惑だと私は思います。そして、可能であればストーリーを見積もるという概念さえも捨て去るでしょう。より少ない見積もりで仕事をする方法については、また別の記事で触れる ことにしましょう。

追跡

多くのマネジャーにとって、見積りの存在は「実績」の存在を意味します。見積りと実績を比較し、見積りと実績が一致することを確認することを意味します。もし一致しない場合は、もっとうまく見積もることを学ぶべきだと意味します。

私にとって、リアルアジャイル (Real Agile) で重要なことは、次にやるべきことをいくつか選び、それを迅速に実行することです。重要な問題は、最も価値のあることを見つけ、それを素早く実行することです。それらを迅速に行うには、価値の高いものを小さく切り出し、迅速に反復 (イテレート) することに尽きます。ストーリーのコスト見積もりは、あまりその役には立ちません。

見積もりの存在によって経営陣が価値のボールから目を離し、代わりに見積もりを改善することに集中するようになると、真の価値を迅速に提供するという中心的な目的から注意がそれてしまいます。

このことから、ポイントであれ時間であれ、見積もりは避けるべきだと私は考えています。

プレッシャー

見積もりと実績の問題に関連するのは、「もっと」という経営陣の自然なプレッシャーです。チームがどんなに成果を上げていても、それだけでは十分ではありません。もっと、もっと、もっと。

価値を提供する最善の方法は、もっと、もっと、もっと、ではなく、小さな価値のあることを頻繁に行うことです。ストーリーを見積もるのではなく、「十分に小さいもの」に切り詰めれば、常に価値を提供しながら、スムーズな流れができます。

より多くのことに集中することは、価値を高める邪魔になります。チームはより速く進めようとして、コードの品質やテストに手を抜くことになります。やがて、より多くの不具合をリリースするようになり、不具合を修正するための再作業が増えるためにスピードが落ち、コード品質が急速に低下するためにさらにスピードが落ちます。事態はますます悪化し、プレッシャーは増大し、間をおかず惨事へと至ります。

見積もりは少なくとも不当なプレッシャーの適用に関与しているので、私は見積もりを避けたいのです。

さらに言いましょう。イテレーションやスプリントのプランニングは完全に止めた方がよいでしょう。次の数週間の予算を埋めるために仕事をするのではなく、次にすべきいくつかの最も重要なことのリストを持つために仕事をするのです。

完了の予測

必要不可欠な機能のリストを作り、それについてしばらく考え、次のリリースを決定するのは一般的なやり方です。次の質問は、もちろん、「いつまでにすべて完了するのか？」です。

答えは誰にもわからない、です。私たちは、わからないことを改善するために多くの仕事をできますし、入札を待っている大きな契約があるときなど、ある分野やある時期においては、それを行う価値はあります。しかし、社内外の顧客のためにソリューションを開発するビジネスをしている場合、私たちは頻繁に少量の価値を提供するのがベストであり、いつまでも未来に先送りするようなビッグバン的なリリースを待つべきではありません。

顧客に対する次のリリースの近い日を選び、そのリリースにできるだけ多くの良いものを詰め込む方がはるかに良いのです。ストーリーポイントであれ、グミベアであれ、あるいは時間であれ、見積もりは素早いリリースの邪魔をします。可能な限り、見積もりを避けるのがベストだと私は思います。

スライス

では、ストーリーの見積もりが嫌いなら、何が好きなのかという疑問が湧いてくるでしょう。私はストーリーのスライシングが好きです。これは、大きなストーリーを小さなストーリーにスライスすることであり、それぞれのストーリーは可能な限り高い価値を持ちますが、それを完成させるのに必要な時間はごくわずかです。理想的には1日以内、ほんの2、3時間です。

ここでは、スライスする際に何らかの見積もりが必要なのかどうかについて、あなたと屁理屈をこねるつもりはありません。もしあなたやあなたのチームが、頭の中で見積もりをして誰にも言わないのであれば、見積もりに関する問題は、それがストーリーポイントであれ時間であれ、発生しそうにはありません。そして「たぶん十分小さい」と「たぶん十分小さくない」の違いを知ることは、「3日」と「1日」の違いを知ることと同じではありません。

さらにコツがあります。私は 小さなストーリーを手に入れる と スライス、見積もり、トリミング でそのことを紹介しました。Neil Killick から学んだことです。「1回の受け入れテストが必要になるまでストーリーをスライスしてください。少し練習すれば、適切なサイズにできます。」

もちろん、見積もりに関する他の記事もあります。ページの一番上にあるリンクをクリックすれば、これまで知りたかったこと以上のことが書かれています。

未来の予測

しかし … 製品リリースにかかる時間を知る正当な必要性があり、そのために見積もりは必要ではないのでしょうか？そうかもしれませんが、ストーリーの見積もりは必要ないでしょう。おそらく、ストーリーレベルまで要件を落とし込むことはないでしょうし、もしあったとしても、それはあまりにも膨大でほとんどが無駄になってしまうでしょう。

もちろん、やらなければならないのであれば、やればいいです。私ならこうする、あるいはこうすべきだという私の理論は、単なるアイデアに過ぎません。最終的には、自分たちの状況で成功するために必要なことは何でもやるしかありません。しかし、私にはもっとよいと思うことがあります。

最初に、次のリリースのために重要な機能を1つ、あるいはいくつか考えます。それが解決する問題は何か、それを解決するのに役立ちそうなソフトウェアは何かについて話し合います。少しでも助けになりそうな最もシンプルな機能について話し合います。すべてを解決する必要はありません。多くの場合、ちょっとした手助けができれば、それでモノゴトが動き出すのに十分なのです。

2番目に、期限を決めましょう。それまでに良いものを作れそうだと思えるような期限を考えましょう。期限を決めて仕事に取りかかります。

3番目に、重要な機能をスライスして実装します。かなり簡単に1日以内にできるはずです。次の最も重要な部分だけに取り組みます。最初の機能を、ほんのわずかなフリルまで埋め尽くそうとしてはいけません。「このちょっとしたことを1つだけやれば、顧客であるジャックはこれを実際に使うことができる」と考えるような心境になるようにします。そして、そのちょっとしたことをやってジャックに試してもらいます。私たちは価値の継続的提供にできるだけ早く移行したいのです。

私たちがやっていることの価値を目に見えるものにし、プロダクトオーナーや他のステークホルダーが、それを世に出すのを待ちきれなくなるようにしたいのです。そうすれば … ストーリーの見積もりの有無にかかわらず、私たちは正しいことをしていることになります。

まとめ

まぁ、もし私がストーリーポイントを発明したのだとしたら、いまとなっては少し後悔しているでしょう。ストーリーポイントは頻繁に誤用され、ストーリー見積もりをまったく使わないことで多くの落とし穴を避けることができると私は考えています。もし、あなたのチームや会社に大きな価値をもたらしていないのであれば、無駄であるという理由でやめることをお勧めします。一方、どうしてもストーリーの見積もりが好きなら、そのまま続けてほしい！

リファレンス

本稿の翻訳ではなく、要約と紹介者の所感を述べた記事もあったので参考に紹介します。

note.com

過去に私が見積もりについて考えた記事です。

t2y.hatenablog.jp

ストーリーポイントの誤用について書かれた記事の翻訳です。

poohsunny.hatenablog.com

(翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎

scrum development translate

本稿は Gergely Orosz 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。

blog.pragmaticengineer.com

また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Gergely Orosz 氏ではなく、本稿のコメント欄にお願いします。

著者も機械翻訳を下地にしたやり方に関心をもたれたようです。

ここから本文です。

ビッグテックのプロジェクトマネジメントとスクラム不在の謎

プロジェクトマネジメントは、多くの人が強い意見を持っているテーマであり、私も例外ではありません。さまざまな企業がエンジニアリングプロジェクトをどのようにマネジメントしているのかという質問に答えるため、私は業界全体に協力を仰ぎました。本稿では次の内容を取り上げます。

  • 業界全体のプロジェクトマネジメントのアプローチ。 100社以上が参加した調査の概要と重要なポイント
  • ビッグテックにおけるプロジェクトマネジメント。 どのように行われているのか？ビッグテックの組織体制は、プロジェクトの遂行方法にどのような影響を与えているのか？
  • ビッグテックにおけるスクラムの欠如。 なぜこの有名なフレームワークがビッグテックのほとんどで行われていないのか？
  • あなたのチームではどのようにプロジェクトを進めるべきか？ 私の個人的な見解をお伝えしましょう

その前に、プロジェクトマネジメントのアプローチがいかに重要であるかを説明するのが難しい理由についての個人的な話をしましょう。

この記事は The Pragmatic Engineer Newsletter に掲載されたものです。このニュースレターは、とくに高成長スタートアップや大手テック企業のエンジニアリングマネージャーやシニア以上のエンジニアに関連するものです。このような記事を毎週お届けしますので 購読してください 。

Skype、スクラム、そして大切なことの再認識

私が Skype 社に入社した2012年、Skype 社はスクラムを全面的に取り組んでいました。すべてのエンジニアとプロダクト担当者は、アジャイルマニフェストの創始者の一人がファシリテートする最高クラスのスクラムトレーニングに参加させられました。Skype 社はスクラムを全面的に取り組み、数四半期をかけてすべてのチームをこの手法に移行させました。

そしてスクラムへの移行は Skype 社では成功とみなされました。Skype 社では、主要な Windows アプリの出荷がせいぜい四半期に1回だったのが、毎月出荷するようになりました。ほとんどのチームは 2～4 週間ごとになにかを納品していました。チームはスクラムマスターの役割を交代し、アジャイルコーチがチームへのフィードバックに訪れ、Skype 社を買収したばかりの Microsoft 社は、デリバリーの速度向上からインスピレーションを得ることに関心をもちました。

しかし、Skype 社がスクラムに移行する一方で、競合他社は冷酷に遂行していました。Whatsapp 社のことです。Whatsapp 社はずっと小さな組織でしたが、毎月のように市場シェアを削り、主要なコミュニケーションプラットフォームとなりました。

Skype 社とは異なり、Whatsapp 社はスクラムのようなフレームワークには手を出しませんでした。初期の従業員は、この言葉を口にしたことすらなく、重厚なプロセスを意図的に無視したことを話しています。Whatsapp 社は Skype 社を凌駕し、Skype 社よりも信頼性の高いメッセージング体験を構築し、最終的にメッセージングコミュニケーションアプリの戦いに勝利しました。

会社の成功とプロジェクトマネジメントのアプローチは必ずしも相関関係があるわけではなく、この話はそれを思い起こさせます。プロジェクトの進め方が重要ではないと言っているわけではありません。しかし、集中力、リーダーシップのアプローチ、プロセスがなくても人々がどのように働くかなど、成果にもっと大きな影響を与えるかもしれないものは他にもあります。

プロジェクトマネジメントは、複雑で変化し続けるパズルのピースです。しかし、プロジェクトマネジメントは最終目標ではなく、その目標に対してより早く到達する手段や要因に過ぎません。

業界におけるプロジェクトマネジメント手法

企業はどのようにプロジェクトを運営しているのか？私はアンケートを実施して100人以上の回答を得ました。結果は興味深いものでした。

企業がどのようにプロジェクトを管理しているかの結論は「場合による」というものでした。 これはあまり驚くべきことではありません。5人で設立されたばかりのスタートアップと、1,000 人でゆっくりと成長している非技術系の企業では、成功の見方は異なるのでしょう。非技術系の大企業のグループ内でも、斬新なアプローチを試すところもあれば、何年もうまくいっている同じやり方に固執するところもあります。

"標準" の方法論はあるか？ もっとも一般的なプロジェクトマネジメント方法論 (順番に) 通常エンジニアリングプロジェクトのリーダーは誰か？
ビッグテック & 公開会社のテック企業
- チームが働き方を選択できる (通常)
- 推奨された方法論はあるが、チームが選択できる (頻度は低い)		 1. プランニング → ビルド (イテレート) → リリース
2. "正式な" 方法論はない		 - テックリード
- そのチームのエンジニア
ベンチャー資金によるスケールアップ企業 (シリーズ B 以上)
- 推奨された方法論はあるが、チームが選択できる (通常)
- チームが特定の方法論に従うことが期待される (頻度は低い)		 1. プランニング → ビルド (イテレート) → リリース
2. "正式な" 方法論はない
3. カンバン
4. スクラム		 - テックリード
- そのチームのエンジニア
ベンチャー資金によるスタートアップ (シリーズ A まで)
- チームが特定の方法論に従うことが期待される (通常)
- 推奨された方法論はあるが、チームが選択できる (頻度は低い)		 1. プランニング → ビルド (イテレート) → リリース
2. スクラム
3. カンバン		 - テックリード
- 専任プロジェクトマネージャー
- そのチームのエンジニア
非ベンチャー資金調達型テック企業
- チームが特定の方法論に従うことが期待される (大半)
- 推奨された方法論はあるが、チームが選択できる (稀)		 1. スクラム
2. その他 (カンバン、SAFe、Scaled Agile)		 - テックリード
- 専任プロジェクトマネージャー
- そのチームのエンジニア
非技術系の大企業
- チームが特定の方法論に従うことが期待される (大半)
- 推奨された方法論はあるが、チームが選択できる (頻度は低い)		 1. スクラム
2. SAFe
3. その他 (プランニング → ビルド → リリース、カンバン)		 さまざまである。
- 専任プロジェクトマネージャー
スクラムマスター
プロダクトマネージャー／オーナー
テックリード
コンサルタント企業
- チームが特定の方法論に従うことが期待される (大半)
- 推奨された方法論はあるが、チームが選択できる (稀)		 1. スクラム
2. "正式な" 方法論はない		 - 専任プロジェクトマネージャー
企業はどのようにプロジェクトを管理しているのか？調査結果の概要

私はこれらのカテゴリーに基づいて企業を分別しました。

  • 公開会社のテック企業: テクノロジーを中核とする公開会社。これらの企業の多くは、以前はベンチャー資金を受けていた
  • ベンチャー資金によるスケールアップ企業: シリーズ B 以上の資金調達を受けたスタートアップ。これらの企業は通常、少なくとも3億ドルの評価を受けており、積極的に成長しており、数年後のIPOを視野に入れていることが多い
  • ベンチャー資金によるスタートアップ: プレシード、シード、シリーズ A の資金調達を行うスタートアップ。これらは一般的にビジネスモデルがあまり実証されていない成長企業である
  • 非ベンチャー資金調達型テック企業: ベンチャー資金を調達しておらず、株式公開もしていない老舗テック企業。これらの企業は、ベンチャー資金を得た企業よりも積極的な成長目標を持っていないことが多い
  • 非技術系の大企業: 技術を中核機能としない上場／非上場企業
  • コンサルタント会社: 開発サービスを提供する会社

今回の調査で各社が使用した 方法論 は次になります。

この調査では、いくつかの興味深い発見がありました。"1 (満足していない) から 5 (非常に満足している) の尺度で、現在のプロジェクトマネジメント手法にどの程度満足しているか／幸せか？"

考察に値する洞察 は次になります。この調査はサンプル数が non-representaitive (訳注: 十分な数ではない？) であるため、慎重に扱うようにしてほしい。とはいえ、これらは私が確認できる見解でもあります。

  • 専任のプロジェクトマネージャーがいるチーム は、一般的に公開会社やベンチャー企業では満足度が低い。しかし、ベンチャー以外の企業やコンサルタント会社では、プロジェクトマネジメントに非常に満足している回答者が何人もおり、その理由として専任のプロジェクトマネージャーの存在を挙げている
  • 自分たちの働き方を選択できるチーム は、公開会社のテック企業やベンチャー企業でより一般的でした。非技術系の大企業や、ベンチャー企業ではない中小企業では、社内の全チームに同じアプローチを義務付ける傾向が強い
  • チームの自主性と高い満足度は相関関係にあるようにみえる。 満足度を4または5と評価した人の多くが、自律性、自由度、柔軟性、チームレベルでの品質第一主義をポジティブな点として挙げている
  • 苦戦しているチームは、方法論とはあまり関係がないことが多い。 うまくいかなかった理由として、ビジョンの欠如、優秀なエンジニアの離職、透明性の欠如、ツールの不備などが挙げられている。このようなチームにとって方法論を変えても問題は解決しない
  • JIRAはネガティブなイメージで語られることが多い。 JIRA に関する 13 の言及 は、すべてこの設定でした。JIRA をあまり使わずにものごとを成し遂げられることは、ポジティブなこととして言及されました。さらに、最近 IPO した高成長のテック企業が JIRA に移行し、エンジニアの間で調査を実施しました。その結果、ネット・プロモーター・スコア (NPS) は -83 となりました。これは驚異的に低く、エンジニアの 83% が JIRA に対してアドバイスすることを意味します。対照的な意見として、安定した成長を遂げているある公開会社のテック企業のエンジニアリングリーダーは、彼らの組織が JIRA に大きく依存し、ナレッジエンジンとして使用していることを共有しました。彼らの場合、組織が JIRA を完全に採用した後、JIRA は大規模な調整にうまく機能しています。Linear は、私の Uber の元同僚が共同設立した課題管理システムであり、私が投資しているスタートアップ のほとんどが採用を決定し、高く評価しているツールです。なお、私は Linear とは何の関係もなく、これを書くためにお金をもらったわけでもありません。

1または2の評価を残した回答者によると うまく機能しないプロジェクトマネジメントのアプローチ にはいくつかの特徴があります。

  • チームがコミットした見積りにエンジニアが関与していないこと は、よくある、なかなか解決しない問題です。私の考えでは、これはエンジニアのやる気を失わせる最も簡単な方法の1つであり、何人かは退職してしまうほどです。
  • 専任のプロジェクトマネージャーがいても、要件が変わること はエンジニアにとっては不都合なことです。要件の変更が多いチームもあるが、そのようなチームでは通常、エンジニアがプロジェクトをマネジメントし要件変更に対処できます。しかし、専任のプロジェクトマネージャーがチームを要件の変更から守ることができない場合、回答者はこのアプローチを悪いと評価しました。
  • 失敗したプロジェクト管理手法を変更する自主性がないチームも、低い満足度を記録しました。 このような回答は、すべてのチームが同じ方法論に従うことを期待されている企業で顕著でした。これは指示的 (directive) リーダーシップの一例であり、このアプローチは、創造性がほとんど必要とされない職務ではうまくいくかもしれませんが、通常パフォーマンスの高いソフトウェアエンジニアリングチームを構築する方法としては不適切です。チームが一緒に反復 (イテレート) し、自分たちの言葉でプロセスを変えることができれば、満足度と生産性は向上します。

匿名化されたすべての回答はこちらにあります。

ビッグテックによるプロジェクトの進め方

ビックテックは、他の業界と比較して、技術プロジェクトを遂行するときの取り組み方が異なります。私は有名な公開会社のテック企業の人たちと話すことでデータを集めました。ここでは、彼らが一般的にどのようにものごとを進めているかを紹介します。

会社 "標準" の方法論はあるか？ もっとも一般的なプロジェクトマネジメント方法論 (順番に) 通常エンジニアリングプロジェクトのリーダーは誰か？
Amazon いいえ。チームが選択できる プランニング (6-pager) → ビルド (イテレート) → リリース テックリード
Apple いいえ。チームが選択できる プランニング → ビルド (イテレート) → リリース テックリード
Datadog いいえ。チームが選択できる プランニング (RFC) → ビルド (イテレート) → リリース テックリードまたはエンジニア
Facebook いいえ。チームが選択できる プランニング → ビルド (イテレート) → リリース テックリードまたはエンジニア
Google いいえ。チームが選択できる プランニング (Design Doc) → ビルド (イテレート) → リリース テックリードまたはエンジニア
Netflix いいえ。チームが選択できる プランニング → ビルド (イテレート) → リリース テックリードまたはエンジニア
Shopify いいえ。チームが選択できる GSD (Get Shift Done, 6-weeks cycles) → ビルド (イテレート) → リリース テックリードまたはエンジニア
Spotify いいえ。チームが選択できる プランニング (ERD) → ビルド (イテレート) → リリース テックリードまたはエンジニア
Uber いいえ。チームが選択できる プランニング → ビルド (イテレート) → リリース テックリードまたはエンジニア
ビッグテックのエンジニアリングプロジェクトの進め方。一般的に使用される方法論です。各チームが仕事の進め方を選択できるため、エンジニアリングチームごとに方法論は異なります。プロジェクト単位でも違います。

ビッグテックは、エンジニアがプロジェクトを遂行する方法において、いくつかの特徴を共有しています。

  • ほとんどのプロジェクトは エンジニアがリードしています 。テックリードか、チームのエンジニアがリーダーになります。ソフトウェアエンジニアがどのようにプロジェクトをリードしているか については、こちらをご覧ください
  • チームはプロジェクトマネジメント手法を自由に選択できます。 多くのチームは RFC のようなプランニングプロセスを採用し、ビルドを繰り返し、数週間以内にすべてをリリースします。他のチームは、よりカンバン方式に近いプロセスで、優先順位の高い項目から取り組みます
  • チームレベルのプロジェクトに 専任のプロジェクトマネージャーはいません。 ほとんどの企業では、複数のチームが関わる大規模プロジェクトや、組織をまたがるプロジェクトには、テクニカルプログラムマネージャー (TPM) が介入します。Uber では TPM とエンジニアの比率は 1:50 程度でした。TPMについてもっと読む
  • プロジェクトマネジメントの成果物やプロセス は、同じ組織内でもチームによって異なります。ほとんどのチームはプロジェクトバックログを持ち、チームが適切と考える間隔でスタンドアップを行い、時々レトロスペクティブを行います。
  • このようなところでは、 一流の開発者用ツールが与えられるのは当たり前 であり、短いイテレーションサイクルにおいて大きな役割を果たしています。多くのチームはメインブランチで作業し、CI/CD システムから素早いフィードバックを受け、作業中の機能をすぐに他のチームメンバーと共有できます。

ビッグテックで働いたことのある人にとっては、この多くはおなじみのことでしょう。しかし、これと同じアプローチを伝統的な企業で真似しようとしても、おそらく失敗するでしょう。というのも、ビッグテックの組織構造は、チームがどのように遂行できるのか、そして遂行するのかに大きな影響を与えるからです。

ニュースレター

私の 週刊ニュースレターを購読して 、ソフトウェア・エンジニアリング業界についての考察や深堀り記事を毎週読んでください。このニュースレターは Substack の No.1 技術ニュースレターであり、このような声が寄せられています 。

プロジェクトに影響を与えるビッグテックの組織構造

ビッグテックがどのようにプロジェクトを管理しているかを理解するために、一歩下がって、これらの企業の多くが活動している環境を見てみましょう。シリコンバレーがソフトウェアエンジニアについて、伝統的な企業にはない "理解" を得ていること という記事で詳しく解説しています。

  1. ソフトウェアエンジニアとチームの自律性。 伝統的な企業で開発者に期待されるのは、与えられた仕事をこなすことです。シリコンバレーのような企業では、ビジネスが抱える問題を解決することです。これは大きな違いです。このことはエンジニアの日々の生活に影響を与えます。

  2. 好奇心旺盛な問題解決者であり、頭を使わないリソースではない。 やる気のあるエンジニアは、言われたことしかやらない「工場労働者」の何倍もの影響力を簡単に生み出します。工場労働者のような態度の組織では、このアプローチは意図的に解釈の余地をほとんど残さない、より重厚なプロジェクト管理アプローチに偏るでしょう。

  3. 内部データ、コード、ドキュメントの透明性。 エンジニアに限らず、社員はしばしばリアルタイムのビジネス指標やデータソースにアクセスし、独自のクエリーを作成したり、カスタムレポートを作成したりできます。

  4. ビジネスやビジネス指標に触れる。 エンジニアは、ビジネスの他の部分と交流し、非エンジニアとの関係を構築することが奨励されます。対照的に、伝統的な企業では、開発者が他のビジネス部門と交流することを不可能にしていることが多いです。

  5. 三角形のコミュニケーションよりもエンジニア間のコミュニケーション。 伝統的な企業は、情報の流れを遅くし、意思決定を遅くする階層的なコミュニケーションを奨励します。

  6. フラストレーションの少ない開発者体験への投資。 エンジニアが迅速に問題を解決することを重視する企業は、様々なプラットフォームチームを立ち上げ、開発者の離職率を低下させます。

  7. 高いレバレッジによって正当化される高い給与。 エンジニアをうまく活用している企業は、市場のトップクラスに近い、あるいはそれ以上の給与を支払うことをいとわないです。

  8. 優秀な人材の採用。 このような企業は、上記のすべての組み合わせのおかげで、高い能力と高いモチベーションを持った人材を採用しています。これらの企業は、手厚い報酬体系と強力なキャリアアップの機会で知られているため、多くの人材から選ぶことができます。

エンパワーメントされた自律的なチーム は、これらすべての企業の構成要素です。またテック業界の多くの企業にとって、差別化の鍵となる要素でもあります。

ビッグテックのすべてのチームが完全にエンパワーメントされるわけではないが、これらの組織は、先進的な考えを持つスタートアップとともに、チームが可能な限りエンパワーメントされるようにする方法を実施することに最も近いです。

明確なオーナーシップをもつチーム は、ビッグテックのもう一つの構成要素です。5～15人で構成される各チームには、明確なビジョンとミッションがあり、それを実行するためのスキルと自律性があります。そのミッションとは、ホスピタリティ製品のプロダクトチームであれば「高齢者のためのワールドクラスの予約体験を構築する」であったり、プロダクトプラットフォームチーム であれば「労力をほとんどかけずに評価体験を統合できるようにチームを強化する」であったりします。

プロダクトに特化したチームは、通常、バックエンド、フロントエンド、モバイルエンジニアのようなクロスファンクショナルなチームメンバーで構成され、プロダクトマネージャー、データサイエンティスト、デザイナーもチームに加わることが多いです。プラットフォーム重視のチーム は、クロスファンクショナルでもなく、特定のドメインに縛られない傾向があります。

エンジニアが高度な専門性をもっていても、ビッグテックでは経験豊富なソフトウェアエンジニアの多くが幅広いエンジニアリング業務をこなせることを期待されており、面接プロセスにもこのジェネラリスト的アプローチが反映されていることに注意してください。

プロダクトマネージャーのはい／いいえ

ビッグテックとその他の企業とのもうひとつの不思議な違いは、プロダクトマネージャーの役割であり、チームに専任のプロジェクトマネージャーやプロダクトオーナーがいないことです。

これらの企業におけるプロダクトマネージャーの役割は、チームにおける戦略を定義すること、つまり「なぜ」です。そして、この戦略を実行するためのステップが「どのように」です。Facebook 社のプロダクトマネージャー Will Lawrence は このように表現しています 。

プロダクトマネジャーの役割は、どのようなゲームをどのようにプレーするか を考えることだ。戦略とは、我々がプレーするゲームを選択することである。投資する価値のある分野を見つけ、このゲームで成功するための説得力のあるビジョンを描くことだ。(...) 遂行とは、私たちがどのようにゲームをプレーするかということである。ミッションに向かって前進するための日々のプロセス、決断、行動である。

プロダクトマネージャーは、チームが正しいことに取り組み続けることを保証します。これは、ビジネス、データサイエンス、デザインと協力し、ロードマップを作り、計画を立て、仕事の優先順位をつけ、必要に応じてエスカレーションすることを意味します。大企業ではこれ自体がすでにフルタイムの仕事です。

多くの場合、大企業ではプロダクトマネージャーはプロジェクトマネジメントを担当しません。チームが遂行に責任を持ち、チームのリーダー (通常はエンジニアリングマネージャー) がこれを実現する責任を負います。

権限を与えられた自律的なチームでは、プロジェクトをトップダウンで管理することはほとんどありません。各チームによって異なりますが、私はエンジニア間でプロジェクトリーダーの役割を交代させることで、チーム全員がリーダーシップを発揮できるようになり、大きな成功を収めました。購読者は、🔒 プロジェクトリーダーの期待事項 にアクセスできます。

専任のプロジェクトマネージャーがいないことから、いくつかの疑問が生じます。エンジニアはプロジェクトマネジメントで手一杯なのか？プロジェクトを管理することは、エンジニアの時間を有効に使うことなのか？これらはすべて可能であり、私の見解は次になります。

  • チームレベルのプロジェクト では、専任のプロジェクトマネジャーがいない方が、結果的にプロセスを簡素化し、個人的な関係を強化できます。エンジニアのプロジェクトリーダーは、自分たちの利益のために、できる限りプロセスを増やしません。また、他のチームと協働する際にも、プロジェクトマネージャーを介さずに、プロジェクトを率いる他エンジニアや製品を所有するエンジニアとの関係を構築します。このようなエンジニア同士のコミュニケーションは、複数のプロジェクトマネージャーを介するよりも効率的です。

  • 異なるオフィスやタイムゾーンにまたがる複数のチームにまたがる複雑なプロジェクト では、そのようなプロジェクトのリーダーはエンジニアにとってフルタイムの仕事になります。ビッグテックでは、こうした複雑で、しばしば戦略的なプロジェクトを管理するために、テクニカルプログラムマネージャー (TPM) を導入し、エンジニアの負担を軽減しています。

  • 大手テック企業には、専任のプログラムマネジャー やプロジェクトマネジャーがまだ存在します。彼らは通常、対外的なコミットメントや顧客 (アップルとのパートナーシップのためのプログラムマネージャーなど) 、あるいはコンプライアンスプログラムのような長期的な構想と結びついている。TPM が単一のエンジニアリングチームに割り当てられないのと同様に、プログラムマネージャーやプロダクトマネージャーもエンジニアリングチームを持たず、多くのチームにまたがって仕事をします。

大手テック企業のプロジェクトマネジメント方法。シンプルなプロジェクトは一般的にエンジニアが主導する。複雑なプロジェクトはテクニカルプログラムマネージャーが担当する。また専任のプログラムマネージャーが長期的な構想を実行することもある

ビッグテックにおけるプロダクトマネージャーの役割が、多くの企業におけるプロジェクトマネージャーやプロダクトオーナーと、どのように異なるかを示す要約が、Facebook 社のプロダクト・マネージャー Ben Erez のツィートから伺えます。

Facebook の PM として1年以上働いているが、チケットやタスクを作成したことはない。スプリントもやりません。

ここの PM はビジョン、戦略、パートナーシップにフォーカスしている。プロジェクトマネジメントやタスクはあまりやらない。

エンジニアはプロジェクトマネジメントのほとんどの責任を担い、自分たちでタスクを作成する。

素晴らしいことだ。

プロダクト重視の環境とスクラムの廃止

私が Skype 社で働いていたとき、スクラムチームがスクラムを完全にやめてしまうのを目の当たりにしました。私が Skype for Web チームに参加したとき、当初は2週間のスプリントを行い、通常のスクラムプロセスに従っていました。またソフトウェアエンジニアと QA に特化したエンジニアに分かれ、Microsoft 社内では Software Development Engineer in Test (SDETs) と呼ばれていました。しかし、チームのリリースサイクルは2週間ごとでしたが、私たちはもっと頻繁にリリースしたいと考えていました。

最初にやったことは、QA をエンジニアリングの一部にしたことです。"古い世界" のやり方では、エンジニアは自分の仕事を終えてブランチにチェックインし、チケットを更新して QA にレビューの準備ができたことを伝えます。QA は1日か2日後にこのチケットを受け取り、レビューし、問題が見つかればチケットをリオープンします。これは長時間の遅延でした。

私たちは、非公式に静かな変更を行い、すべての SDETs が本番用ソフトウェアも構築し、すべてのソフトウェアエンジニアが自分のコードをテストする責任を持つようになりました。これでコードを本番環境へリリースする前にフィードバックを何日も待つ必要はなくなりました。しかし、隔週のスプリントと数々のスクラムのセレモニーが次の問題となりました。

スクラムが日々のリリースの邪魔になったのでした。 スクラムの全体的な考え方は、スプリントを中心に展開され、スプリントの最初にタスクにコミットし、スプリント中にそれらに取り組み、最後にやったことをデモするというものです。

このプロセスは不自然で、動きの速いウェブチームからは押し付けられたかのように感じられました。私たちはすぐにカンバンアプローチを取り入れました、より流動的な働き方に移行しました。私たちはスプリントを気にするのをやめ、スクラムにつきもののセレモニーもほとんどやめました。私たちは、今何に取り組んでいるのか、そして次に何をするのかを知ることだけに集中しました。

インフラと開発者ツールは、多くのスクラムのセレモニーを不要にしました。 プロダクトオーナーへのデモ、作業の承認、そしてリリースといったスクラムのセレモニーは、いくつかのことを前提としています。

  • プロダクトオーナーは、作業が仕様通りに行われたことを確実に検証できる人であること
  • プロダクトオーナーが仕様書を書いていること
  • 承認を行わずに成果物が本番環境にリリースされることありません

しかし、私たちの環境では、これらの前提にはしばしば欠点がありました。私たちが書いたコードはすべて単体テストでテストされ、必要に応じて統合テストやエンドツーエンドテストも行われました。私たちは、フィーチャーフラグで隠してコードをリリースし、チームへの新機能の導入から始めて、段階的な導入を経て検証しました。多くの "仕様" やチケットもエンジニアによって書かれ、エンジニアはそれが期待通りに動くかどうかを検証することができました。CI/CD、フィーチャーフラグ、実験ツールのおかげで、プロダクトオーナーに頼るよりも速いフィードバックサイクルが可能になりました。

ビッグテックの多くは、一流のインフラと開発者向けツールが、エンジニアリングチームの生産性に大きな違いをもたらすことを認識しています。これが、エンジニアリングの 30～40 ％がプラットフォームチームで働くことが多い理由であり、Uber がプラットフォームチームに多額の投資をした理由です 。ファーストクラスのインフラとプラットフォームがすぐに使える状態であれば、チームはインフラをどのようにセットアップするかとか、サービスをどのようにコンプライアンスに対応させるかといったことよりも、中核となる仕事の目標に集中できます。プラットフォームチームについて、私は次のように考えています。

プラットフォームチームは組織の効率を向上させます。(...) 規模を拡大し、素早くスケールアップするためには、プラットフォームチームは必須となります。(...) しかし、プラットフォームチームは直感的に導入できるものではありません。ビジネス視点の眼鏡でプラットフォームチームを見ると、ほとんど意味がありません。確かに、小規模な組織、あまり成長していない組織、うまく機能している構造を持つ組織では、プラットフォームチームは意味をなしません。

チームのメンバー全員が、私たちがなにを作っているのかを非常に明確に理解していました。 私たちの最終目標は Skype のウェブ機能をリリースすることでした。このアプローチはいくつかのサブプロジェクトから構成されていましたが、全体像はチームにとって明確でした。プロダクトマネジャーがハイレベルな戦略を設定し、私たちエンジニアがやるべきタスクをピックアップし、それを遂行しました。私たちは、スクラムの邪魔な部分を削ぎ落とすのに十分な権限を与えられていました。しばらくすると、残されたものはまったくスクラムではありませんでした。

スクラムの先へ

Facebook、Whatsapp、Google、Netflix や同様の組織のエンジニアと話すと、彼らのほとんどはスクラムを実践したことがありません。なぜか？それにはいくつかの理由があります。

  • 有能で自律的な人材は、信頼できる質の高いアウトプットを生み出すために、より少ない構造しか必要としません。 大手テック企業は、このような人材を惹きつけ、余裕をもたせ、雇用できます。

  • 有能なチームを活用するには、彼らに働き方を選択する自由を与えることが必要です。 これはほとんどの種類のエンジニアリングに当てはまることであり、官僚主義を減らして自律性を高めるという スカンクワークス のモデルが、優秀な人材を擁する多くの高業績チームが最終的に従うことになります。そこにはそれなりの理由があるのです。

エンジニアリング組織のスケーリングは、チームレベルのプロセスをはるかに超えるものです。 これらの組織に生産性に関する課題がないとは言わないが、これらの課題のほとんどは、重量級のプロセスで解決できるものではありません。これらの企業が取り組んでいる課題には次のようなものがあります。

  • 開発者の生産性。 エンジニアがインフラの問題に振り回されたり、依存関係の問題を回避したりする代わりに、チームの目標を達成するためのコードを書く時間を増やすにはどうすればいいのだろうか？プラットフォームチームはその一助となるアプローチだが、ここではさらに多くのことを解明する必要があります。これについては、今後のニュースレターで取り上げる予定です。

  • 技術とアーキテクチャの負債を返済する。 ビッグテックはどの会社も動きが速く、新しいチャンスに素早く対応します。そうすることで、企業はしばしば近道をし、技術やアーキテクチャの負債を抱えることになります。このような負債を「ビッグバン」と呼ばれる技術負債返済プロジェクトではなく、日常的なプロセスの一部として賢明な方法で返済するにはどうしたらよいだろうか？

  • 組織の目標にあったチーム構造。 会社や下部組織の目標は定期的に変化します。チームの結束を乱すことを最小限に抑えながら、どのようにチーム構造にその変化を反映させることができるだろうか？

  • イノベーションと予期せぬ仕事のための余剰時間。 イノベーションを期待されているチームにとって、それを実現するための余分な時間をどのように作るか？

  • エンジニアリングチームの成長にあわせてペースを維持する。 エンジニアの数が増えれば増えるほど、多くのエンジニアに影響を与える意思決定やコミュニケーションにかかるオーバーヘッドも増えます。組織の規模が2倍になった後も、同じ速さで前進し続けるにはどうすればいいのだろうか？組織の規模に関係なく、チームが軽快さを保ち、迅速に動くためのプロセスや構造の選択とは？

  • 耐久性のある卓越性。 どうすれば組織全体の処理能力を向上させながら、エンジニアも満足し、改善点が長期にわたって持続し、複合的に作用し続けることができるのか？「耐久性のある卓越性」という言葉は Will Larson による記事「Staying on the path to high performing teams」から引用しました。

スクラムの擁護

ビッグテックの多くがそうしているからと言って、企業はスクラムやその他の方法論を否定すべきなのだろうか？それは間違いです。

スクラムに切り替えることが完全に理にかなっており、生産性の向上につながるコンテキストはたくさんあります。 Skype 社は、この変更が会社の役に立った例であり、Whatsapp 社は Skype 社がどのような方法論を使ったかに関係なく、おそらくコンシューマー向け通話分野で勝利していたでしょう。

スクラムが良い選択肢となる状況をいくつか挙げてみましょう。

1. キッチンシンクチーム あらゆるものがこのチームに投げつけられます。一般的にスクラムのような重量級のプロセスでステークホルダーを管理することが勝利につながると気付きます。ステークホルダーは、進行中のスプリントを中断することはできないし、新しい機能要求には手入れが必要であることを理解するように教育されます。相反する優先順位を持つチームは、スプリント構造によってチームがこれらの中断を無視するスペースを与えられるおかげで、中断を少なくして遂行できるようになります。

"キッチンシンクチーム" は、非技術系の企業では典型的なもので、ビジネスがエンジニアリングの仕組みを理解していません。スクラムは、利害関係者をコントロールし、ソフトウェア開発プロセスについて教育するのに役立ちます。また初期段階のスタートアップ企業でもよく見られますが、そこでは1つのエンジニアリングチームがすべてを構築します。

"キッチンシンクチーム" は、プロダクトチームがあまりにも多くの責任を負わされる場合にビッグテックにおいてもたまに現れます。どのような場合でも、スクラムのようにチームに息抜きのスペースを与えるプロセスに移行することは、非常に理にかなっています。しかし、チームが自律し、権限を与えられるようになると、チーム憲章を更新する代わりに、チームが所有しない仕事にはチームメンバーがすぐにノーと言えるようになることが多くなります。

2. 新しいチームの「形成期」と「混乱期」の段階。 心理学者の Bruce Tuckman は、グループがどのように機能するかについての段階として「形成期、混乱期、統一期、機能期」という言葉を考え出しました。このモデルは、ほとんどのエンジニアリングチームがどのように進化していくのかにも適合します。

新しいチームが結成されたとき、そのチームはどのように仕事をするかを決める必要があります。スクラムのような既成のアプローチに手を出すことは、ほとんどの場合、お互いによく知らないメンバーがカスタムプロセスを考え出すよりも、あるいは全く考え出さないよりも、より良い選択です。スクラムのような文書化されたアプローチを採用することは、"正しい仕事の進め方" について相反する、または互換性のない意見をチームメンバーがもっている場合にも有効です。

スクラムの良いところは、レトロスペクティブがプロセスの一部であることです。これにより、チームは自分たちの仕事のやり方を振り返ることができます。時間の経過とともに、作業スタイルを変更する自主性を持つチームは、通常、必要のない重量級のスクラムルールをやめ、カスタムな作業スタイルを開発するようになります。

3. リリースを数週間に1回の頻度にスピードアップする。 この頻度がスプリントの長さを超えない限り、スクラムは週単位のスプリントとともに、チームがより頻繁なリリースに移行するのを助けます。デジタルファーストではない多くの組織にとってこのような加速は大きな勝利です。

リリースのスピードアップは、Skype 社が 2012 年にスクラムに移行した大きな理由の1つです。移行前は、チームは数ヶ月に1回リリースしていました。移行後、各チームは月に 1～2 回出荷するようになりました。これ以上の頻度でリリースすることになったチームは、スクラムをやめることを決めたチームです。

4. プロジェクトの進捗報告を統一することが必須と考えられている企業。 スクラムと JIRA は密接な関係にあり、JIRA ほど組織レベルのレポーティングに適したツールはありません。私は多くの組織がスクラムを導入し、リーダーシップチームがチームをより可視化し、支援が必要なチームを特定できるようになることを期待していることを見てきました。

統一されたレポーティングとチームレベルの優先事項への掘り下げは、Skype 社のリーダーシップもスクラムへの移行で見た利点の1つでした。当時 Skype 社でアジャイルコーチをしていた Chris Matts 氏は Strawberry-Jam-O-Meter と Wrong-Order-O-Meter をどのように実装したかを話してくれました。

Strawberry-Jam-O-Meter は、進行中のバックログ項目が最も多いチームを特定するために使われました。 Jerry Weinberg の "ストロベリージャムの法則" にヒントを得ました。Wrong-Order-O-Meter は、プロダクトオーナー組織が指定した組織全体のバックログに従って、間違った順序でアイテムに取り組んでいるチームを特定するために使われました。

私の個人的な見解では、権限委譲されたチームがいる組織では、目的および主要な結果 (OKR) 、主要業績評価指標 (KPI) 、目標は、報告のためにスクラムのような厳格な方法論を展開するよりも、チームを調整するためのはるかに優れたツールです。しかし、権限を与えられていない組織、チームや個人が自律的でない組織では、スクラムは代替案よりもうまく機能するかもしれません。

どのようにチームを運営すべきか？

さまざまな段階にある企業が、それぞれ異なるアプローチでプロジェクトを運営する傾向があること、また大企業はこのプロセスをうまく機能させるために多くの組織的サポートをもっているが、大企業が一般的に単一のアプローチを義務付けていないことを見てきました。

チームをどのように運営するかは、その企業の状況によって異なるはずです。関連する要素には、組織構造、一緒に働く人々、その人々の自主性とスキル、競合、「戦時」か「平時」かが含まれます。数え上げればきりがありません。

思考の糧として、次のアイデアを残しておきましょう。

  • 反復的な変化は「ビッグバン」的な変化よりも常に効果的である。 リリースが非常に遅いことに悩んでいたヨーロッパのテック企業が、新しいエンジニアリング担当副社長を雇いました。この人物は、就任後数ヶ月で組織全体を NoEstimates 方式に移行させることを決めました。彼らは大きなイベントを企画し、ロックバンドを雇い、新しい仕事のやり方を発表しました。その後の数週間、数ヶ月は大混乱となり、組織は以前のやり方に逆戻りしました。

  • 誰かに釣り方を教えるのは、その人のために魚を釣るよりも大変なことなのだ。 プロジェクトマネジメントに対する私のアプローチは、チームのメンバーを指導し、プロジェクトリーダーになるよう指導することでした。その結果、チームはより多くの成果を出し、人はより早く成長し、より早く昇進し、その人たちは同業者よりも早くエンジニアリングリーダーになりました。このアプローチは、権限を与えられた環境における私の最善の決断のひとつでした。購読者は、私の blueprint ドキュメント にもアクセスできます。

  • ディレクション、メンタリング、コーチングにはそれぞれ用途がある。 指示すること、つまり何かをする方法を正確に指示することは、彼らが自分でできるのにマイクロマネジメントになってしまいます。しかし、そうでない場合はサポートになります。指示するのか、指導するのか、コーチするのかによってアプローチを選び、人やチームの能力に応じてスペースを与えます。時間が経てば、指示することはほとんどなくなるはずです。しかし、最初はそうする必要があるかもしれません。

  • 意思決定に必要な人数が少なければ少ないほど、意思決定を迅速に行うことができる。 あるエンジニアが、あるエンジニアと話をするだけでよいのなら、そのエンジニアがプロジェクトマネジャーと話をし、そのプロジェクトマネジャーがまた別のプロジェクトマネジャーと話をし、そのプロジェクトマネジャーがまた別のエンジニアと話をし、そのエンジニアがまた別のプロジェクトマネジャーと話をし......といった具合に、エンジニアがプロジェクトマネジャーと話をする必要がある場合よりも、その決断は早くなるでしょう。

  • レポーティングを最適化することは、信頼性の低い環境を最適化すること。 幹部レベルでのレポーティングは重要です。しかし、レポーティングのために重たいプロセスを追加するようなプロジェクトマネジメント手法を導入すれば、プロセスが増え、信頼が低下し、どんなレポーティングを作成しようとも、人々がギャンブルをするようになります。

  • コンサルタントは、自分の価値を証明する最も簡単な方法であるため、測定しやすい結果を出すことに偏る。 測定しやすい結果がよい目標であれば、コンサルタントは良い投資となります。ただ、それが価値ある目標であり、方向性が正しいことを確認してください。

  • 直接の競合相手から学ぶことは過小評価されている。 動きの速い競合他社がやっていることを理解し、似たようなことを試してみるのは、非常に賢いやり方です。競合他社の同業者とコーヒーを飲むことは、プロとして、また人脈作りのための投資として素晴らしいものになります。

  • 優秀なエンジニアの中には、マイクロマネジメントされるくらいなら辞めたいと考える人もいる。 とくに雇用市場が熱く、転職が容易なときには。

私のアンケートへの回答から関連する言葉を引用します。

最近、Cレベルのエグゼクティブが、すべてのチームに対して仕事のやり方を強制し始めた (全員が同じ方法論に従う必要がある) 。その結果、多くのエンジニアが辞めていきました。

私は、他の人たちからインスピレーションを得て、実験し、反復し、人々がやる気になるような信頼性の高い環境に向かっていくことを勧めます。これは 私が行ったこと であり、チーム、会社、そして私自身という全員の利益のために、チーム内のすべての人が成長できるような体制を整えた方法です。

推奨記事

この記事のレビューに協力してくれた Adriaan, Alexandra, Alex, David と Steve 氏に感謝します。

本稿のオリジナルの記事は次になります。

blog.pragmaticengineer.com

見積もりをがんばらない

scrum

スクラムを開発方法論に採用しているチームで開発者をしています。最近たまたま見積もりについての話題がチームであがり、私の経験や考えを整理してみる機会にしようと考えました。お断りとして、本稿の考え方が正しいと主張する意図はありません。世の中にはさまざまなチームや開発スタイルがあります。私が経験していない業務においては他のやり方もうまくいくケースがあると考えています。

スクラムガイド には見積もりの実践について明確な指針を提供していません。一方でスプリントを設定し、スプリントプランニングを行う上で通常はその期間内にスプリントゴールの達成を図ることから、必然的になんらかの見積もりを行うことを前提としています。インターネットを検索すると、プランニングポーカーとストーリーポイントを用いた見積もりの記事も多くみつかります。私の立場として、ストーリーポイントという見積もり手法をやや懐疑的にみています。この手法は一定の制約の中でしか機能しないのではないかと私は考えています。その理由や背景も後述します。

また、チームのスプリントにバーンダウンチャートが導入されました。バーンダウンチャートの運用についてスクラムマスターと議論していて、私の見解とは大きく異なることに気付きました。スクラムのルールとバーンダウンチャートの目的が合致せず、不思議に思ったのでそれについても後述します。バーンダウンチャートもスクラムには含まれません。

TL/DR (要約)

  • (ストーリーポイントを用いない) 見積もりは担当者によって変わる
  • 見積もりの精度は見積もり対象に対する情報量や知識量に依存する
  • 見積もりはその見積もりを行った時点での予測に過ぎない

さらにまとめると言いたいことはこうです。

  • 見積もりは外れるので常に補正していく

スクラムと見積もり

アジャイル開発とスクラム 第2版 で木下氏が書かれた「2020スクラムガイド改訂とスクラムの3つの罠」というコラムで、デイリースクラムの目的を次のように述べています。

デイリースクラムの目的は状況に合わせた再計画であるため、形式的な報告だけではいけない。

私自身、このコラムを読むまで勘違いしていました。デイリースクラムとは昨日やったことや今日やることの報告をするものだと考えていました。本当の目的は、なにか障害があったときにスプリントの計画を柔軟に再プランニングすることです。スクラムガイドにも「デイリースクラム」の節に次のように説明されています。

開発者が計画を調整できるのは、デイリースクラムのときだけではない。スプリントの残りの作業を適応または再計画することについて、より詳細な議論をするために、開発者は⼀⽇を通じて頻繁に話し合う。

スプリントゴールが変わるような再プランニングをデイリースクラムで議論するのは構わないと思いますが、ゴールに含まれないタスクやスプリントバックログアイテムの再プランニング (次スプリントへの先送り) は開発者が能動的に行えばよいのではないかと私は考えていました。しかし、スクラムマスターからは次のようなコメントをいただき、私の考えるスクラムの運用や見積もりとスクラムマスターのそれとは大きく乖離していることに気付きました。

  • 基本的にはスプリントプランニングで立てた計画は変更しない
    • スプリントの中止だけ唯一 PO に権限が与えられている
  • スプリントの終了日にすべてやりきらなければならないということはない
  • 検査／適用／透明性を実現できることが重要である
  • バーンダウンチャートはスクラムには含まれない

スプリントとバーンダウンチャート

チームでは Backlog を用いて バーンダウンチャート を表示しています。

Backlog のバーンダウンチャート

Backlog のヘルプセンターの概要には、バーンダウンチャートの意味や目的については説明していないので、バーンダウンチャートとは？意味やメリット、作り方のポイントを解説 の記事を読み解きながらバーンダウンチャートの目的や役割を次にまとめます。

バーンダウンチャートとは、マイルストーン (スプリント) の期間における、仕事量と時間の関係を表したものである。当初の計画と現時点の進捗状況がどのぐらい乖離しているかを視覚的に表現してくれる。グラフの傾きが進捗のスピードを表し、グラフが横ばいになると進捗が停滞していることを表す。バーンダウンチャートのメリットとして、計画と実際の進捗との乖離が明確になるのと、残された期間に対する仕事量の関係を視覚的に確認できることがあげられる。マイルストーンの完了後に当初の計画と実際の進捗との管理を振り返ることにも使える。

たしかにこの説明からも、スプリントにおいて完了できないタスクをそのまま置いておき、そのスプリントの振り返りの材料とする使い方はできるように読めます。またバーンダウンチャートの注意点として、次の2点があげられている。

  • バーンダウンチャートは目安のひとつとして使う
    • バーンダウンチャートでは表現できないメトリクスがあるので、これだけでプロジェクト管理はできない
  • タスクをできるだけ正確に見積もれるようにする
    • タスクの見積もりに正確さを欠いてしまうと、理想線・計画線と実績線が大きく乖離してしまう
    • 「作業完了」の定義がメンバー間で異なると、仕事量の推定が不確かなものになり、適切なチャート運用を困難にしてしまう

バーンダウンチャートの適切な運用にはタスクの正確な見積もりが必要であると、この記事では説明されています。バーンダウンチャートを利用するのであれば、なるべく正確な見積もりとなるように努めるのは正しいでしょう。ここで、スプリントにおける、あるタスクの見積もりが外れたときに、そのタスクのマイルストーン (スプリント) を変更するかどうかでスクラムマスターと私では意見が分かれました。

スクラムマスターはタスクのマイルストーン (スプリント) はスプリント期間内では変更しないため、バーンダウンチャートはバーンダウンしなくてよいと主張します。一方で、私はバーンダウンチャートをみながら、マイルストーン (スプリント) に間に合いそうにないタスクはマイルストーン (スプリント) の変更を行い、スプリントが完了するときにはタスクがゼロになる、バーンダウンするのがよいのではないかと主張しました。

意見や考え方の相違そのものを私は気にしてはいません。しかし、スクラムマスターと私で見積もりに対する考え方が大きく異なることから、バーンダウンチャートの運用に食い違いが出ました。

本稿では、私の見積もりに対する考え方を説明した上でバーンダウンチャートの運用について述べます。

見積もりと不確実性コーン

そもそも正確な見積もりはとても難しいというのが私の経験則です。多くの人は共感してくれるのではないかと思います。大前提として、見積もりは誰がやっても外れる ものであり、一定のズレを織り込んだ上でプロジェクト管理を行うべきであると私は考えます。

私の経験では、見積もりと計画との乖離を過剰に責めるとメンバーが不正や誤魔化しを行い、結果的に品質が大幅に劣化して、後になってから (たいていは運用が始まってから) 大きな問題に発展することがありました。問題はわかった時点で対応する方がずっとコストが低くなります。品質管理の視点から見積もりのズレを誤魔化す必要は全くなく、そのズレを認識した時点で然るべき補正をしていくことが重要だと私は考えています。

見積もりの話題によく引用される図に 不確実性コーン があります。エンジニアリング組織論への招待 から引用します。

エンジニアリング組織論への招待から引用

プロジェクトの進行とともに見積もりのバラツキがどのように推移していくかを表したものです。プロジェクトの初期は最大4倍程度のズレが発生する可能性があり、終了前ではほとんどズレないということを表しています。調べてみると、この図は1981年に発表されたものでウォーターフォール型開発の時代の話しだそうです。現代の開発で同様にみなしてよいか、検討の余地はあるかもしれません。一方で私の経験則においてもこの図のバラツキは一定の理があるように受け取れます。

私は次の要因によってこのズレが起きるのではないかと考えます。

  • プロジェクトの初期は必要な情報が不足している
  • プロジェクトの初期はメンバーのスキルが未熟である
  • 情報もスキルもない状態では知識や知恵を得るのが難しい

そのため、プロジェクトが進むことで次のことが発生して見積もりのズレが補正されるのではないかと考えます。

  • プロジェクトの初期と比べて、相対的に情報が増える
  • メンバーが成長する (スキルや知識を身につける)

ストーリーポイントとプランニングポーカー

チームでも度々ストーリーポイントの話題が出るため、ストーリーポイントとプランニングポーカーという手法での見積もりについても考察します。

私はストーリーポイントもプランニングポーカーも実践したことはないため、この記事を読んだ程度の浅慮で書きます。そのため、本節の内容は誤っている可能性があり、参考程度に読んでください。

ストーリーポイントは、ストーリーポイントを実践できる状態のチームを先に作る必要があるのではないかと私は考えます。作業時間や工数をストーリーポイントに抽象化し、それをプランニングポーカーという手法で高い精度で見積もったとしても、そのストーリーポイントを誰でも同じぐらいの速度・品質でメンバーが対応できないと意味をなしません。というのは、どんな理屈を述べても最終的にストーリーポイントは作業時間や工数と対応付けられてしまうからです。現実の期限が10ストーリーポイント後になりますということはありません。

スクラムは属人性を排除して、メンバー全員がどんな作業でも同じぐらいの速度・品質でできることを目指すフレームワークであるというのは正しいと思います。しかし、現実の世界でその状態を維持するのはとても難しいのではないかと私は考えます。メンバーの知識やスキルセットには個人差があり、退職や移動などチームのメンバーは入れ替わります。そして、現実の業務にはドメイン知識や経験が必要とされ、その習得のために一定の学習コストを要します。1人でできる作業を複数のタスクに分割してメンバー全員が担当することによって属人化をなくすというのがスクラム的なやり方だというのは重々承知していますが、それを実践するには業務に対して過大なリソースを割り当てる必要があります。大雑把に言えば、1人でできるタスクを3つのタスクに分割して3人でやるような話しになるのではないでしょうか。大企業ではそういった働き方をしているかもしれません。

現実の世界では、特定の業務に対するドメイン知識やスキルは担当者個人に紐付いていることがよくあります。例えば、ある担当者 A が3年かけて身につけた知識やスキルを、3ヶ月ほどメンバー B や C に教えたからといって、B や C が A と同じことができるようにはならないことはあるでしょう。A, B, C でプランニングポーカーを行い、ストーリーポイントを見積もったとしても、A と B, C における実際の作業速度は大きく異なります。さらに本当は速度だけではなく、品質レベルも平準化しないといけません。しかし、品質は速度よりもさらに平準化が難しいです。

スクラム的な見積もり、ストーリーポイントとプランニングポーカーを実践するには、まずチームの知識やスキルセット、実践における品質レベルを先に平準化する必要があります。強いて言えば、過半数以上のメンバーの知識やスキルセットが高くない、深いドメイン知識を必要としない業務開発などに対してこの手法はうまくいくのではないかと思えます。私の知人からもそういう事例を聞いたこともあります。

ストーリーポイントのデメリット

【翻訳】ストーリーポイントを使うのをやめよう の記事では、ストーリーポイントの弊害についてまとめられています。2012年に書かれた記事でやや古く、いまの状況とあっていないこともあるかもしれません。この記事に出てくる成熟したチームで直感による見積もりを補正する程度でうまくいっている話しや著者の知人のベテランのアジャイル実践者のほぼ全員、何年もの間ストーリーポイントとベロシティ計算を利用していないと述べています。

これはストーリーポイントに限った話しではありませんが、測定される値に報酬が与えられるものはすべてが改ざんされるという キャンベルの法則 と呼ばれるものが、まさにこの記事で述べられている弊害のいくつかに当てはまるでしょう。さらにひどいことにストーリーポイントが誤解されてしまうと、その抽象化された概念の曖昧さゆえに誤解を正すために時間と労力を要するといったことも述べられています。

余談ですが、私の周りでストーリーポイントを実践していたり、その有用性を説く開発者はほとんどいません。

見積もりは担当者が決める

前節では、チームにおけるメンバーの知識やスキルセットが平準化されていない状態で、みんなで見積もることは役に立たないと私は述べました。本節では一旦、時間や工数といった従来のやり方で見積もるときの手法について考察します。

時間や工数を見積もる場合、見積もりは外れるという前提とともに、タスクの担当者が決めて補正していく やり方がもっともうまくいくのではないかと、私の経験則から考えています。X というタスクを、A は3日、B は5日で完了すると仮定します。前提として、X というタスクを A が担当するのか、B が担当するのかで見積もりは変わることを受け入れます。A が担当しても B が担当してもよいが、B が担当するときは3日ではなく、B の知識やスキルセットを考慮して5日という見積もりとします。

実際に B が X のタスクの作業をしていて5日では終わりそうにないことが、4日目にわかったとします。このとき、あと何日かかりそうかの再見積もりも他メンバーではなく、B が自分で見積もるようにします。見積もりが外れると同時に、B は再見積もりと一緒に振り返りの機会を得ます。認知心理学ではこのことを 活動中の振り返り (reflection in action) と呼んでいて、学習におけるメタ認知的活動の1つと分類しています。見積もりが外れたときの再見積もりには、それ自体を省察の機会とする狙いがあります。見積もりが外れることは構わないが、なぜ外れたかを振り返ることが重要であると私は考えます。

タスクの担当者に再見積もりを行わせる別の理由に、進捗中のタスクには情報の非対称性が生じやすいという背景があります。組織における情報の非対称性とは、マネージャーが知っていてメンバーが知らない情報が多いという状況を指すことが多いですが、現場の業務においてはその逆が生じます。B が担当者として作業しているタスクの状況を他メンバーがその実態を把握するのはとても難しいです。とくにソフトウェア開発はそうです。B が行った作業状況を最も理解しているのは B 自身であり、B が再見積もりする方が見積もりの精度が高くなる可能性が高いと言えます。

多くのケースで見積もりが外れるのは、想定していない状況や情報不足によることが多いです。そこで B は X というタスクを完了する上で必要な情報や気付きを得て学びにつながります。仮にその学びを他メンバーに共有したとしても、B の暗黙知を過不足なく他メンバーに共有することもまた難しいです。このような実務の1つ1つの作業がメンバーの知識やスキルセットの形成につながり、それをチームで平準化するためにやはり時間を要すると言えるでしょう。

見積もりは常に補正する

前節で見積もりは担当者が行うことを私は提案しました。さらに見積もりはプロジェクトやスプリントの開始時点で行うものと考えがちであるが、私はそのように考えていません。何度も申し上げているように 見積もりとは外れるもの という前提があるからです。

作業を進めていく過程でさまざまな情報を取得したり、たまたま担当者が体調が崩してパフォーマンスを落としたり、その時々の状況にあわせて担当者の状態が変化します。知識や情報量が増えることは見積もりを減らす方向に作用し、体調を崩すことは見積もりを増やす方向に作用します。担当者の状態が変化したときに再見積もりすることは、時間が経つと、より精度の高い見積もりになるという 不確実性コーン の理論とも合致します。

見積もりを自身の状態の変化にあわせて行うという考え方は、プロジェクトやスプリントの開始時点で見積もることとも矛盾しません。熟達者の見積もりの精度が高い理由は、見積もり対象のタスクの知識や情報を開始時点から他メンバーよりも多くもっているという点があげられます。

「エンジニアリング組織論への招待」の「プロフェッショナルの仕事」という節に次の図が紹介されています。

エンジニアリング組織論への招待から引用

熟達者であっても未知のタスクをこなすときの初期の見積もりは外れることが多いはずです。しかし、熟達者は不確実性の高いものから取り掛かるため、作業の早い段階で全体像をみえるようにしてしまい、後半は品質の作り込みを行うだけなので未知のタスクであっても早い段階で精度の高い見積もりに補正してきます。一方で、経験が少ない人はわかる範囲から作業を進め、後半になってから不確実性の高いものに取り掛かるため、作業の後半になっても見積もりのズレ幅が大きくなってしまう場合があります。

ここでは不確実性が高いものとは、その対象に対する知識や情報が不足していると言い換えられます。タスクにおいて不確実性が高いものは何かを把握することにも一定の経験やスキルを要するのです。前節で、時間とともに見積もりの精度が上がる背景を、必要な情報の取得とスキルや知識の習得と考えました。もし作業の後半になって行った再見積もりのズレも大きい場合、不確実性の高い作業を認識できていなかったと考えられるのではないでしょうか。

見積もりは外れるという前提とバーンダウンチャート

閑話休題。スクラムのバーンダウンチャートの運用に戻ります。

スクラムマスターは、スプリントプランニングで決めたタスクの見積もりに対してどのぐらい完了できたかみるためにバーンダウンチャートを用い、バーンダウンしなくてもよいと主張しました。おそらくバーンダウンチャートがバーンダウンしなかったことはスクラムイベントのふりかえりで見返すだけという運用を想定しているのでしょう。この背景はプランニングでは正確に見積もることと決めたことができなかったという事実を重視していると言えるでしょう。

一方で私は 見積もりは外れる という前提から、スプリント中に日々バーンダウンチャートをみながら実際のタスクの進捗と見積もりとの差異を確認し、見積もりのズレから気付きを得てタスクの見積もりやタスクのマイルストーンを補正しながら、スプリントの完了までにバーンダウンチャートをバーンダウンさせる運用を想定しています。冒頭でも説明したようにデイリースクラムの目的は再プランニングにあります。スプリントプランニングで決めたことを重視せず、日々の進捗にあわせて変えていこうという実践を重視しています。

スクラムの目的である検査／適用／透明性を実現するために、チームにとってどちらがうまくいくかという議論のたたき台として本稿を書きました。

余談ですが、見積もりと関連して短過ぎるスプリントの弊害もあるように感じています。私が参加しているスクラムチームはスプリントを1週間にしていますが、メンバーの業務に対する習熟度が低いと適切なタスク分割ができず、タスクが1つのスプリントで完了せず、複数のスプリントにまたがって同じタスクに取り組んでいるということも常態化しています。これが常態化すると、スプリントでタスクをやり切るというタイムボックスの効果が薄れます。さらにプランニングは前スプリントに完了しなかったタスクが優先となってしまい、新たに追加できるタスクが少なくなることから、プランニングの意義が減ってしまうようにも感じています。

まとめ

個人的には、見積もりやタスクの完了にバーンダウンチャートが役に立つとはあまり考えていません。

本当の意味で、マイルストーン (スプリント) でタスクが完了しないことを、そのタスクの担当者はある時点から気付いています。こういった見える化したいという意図は、プロジェクト管理をする立場の人から、タスクの進捗が担当者との情報の非対称性によって分からないから見える化したいというモチベーションに基づいていると私はみています。そして、バーンダウンチャートをみて、そのスプリントにて、プランニングで決めたタスクが完了しそうにないとわかったら、プロジェクト管理の立場の人がタスクのマイルストーンを変えていくのがよいのではないかと私は考えています。スクラムで言えば PO でしょうか？

一般論として、タスクの担当者は、タスクが完了しないことを認めたくない傾向があります。タスクが完了しないことは見積もりや実務能力の未熟さを露呈するものなので、自身が無能だと思われたくないという心理が働きます。これは容易に品質を犠牲にしてもタスクを完了させたいというインセンティブに変わります。とくにまだ十分に時間がある中で間に合わないという判断を下すのは担当者にとってはある種の屈辱感もあります。

したがって、私はマネージャーの立場と責任においてタスクの先送りをするのがよいと考えています。タスクが遅延したのは、担当者が無能だからではなく、マネージャーが無理なスケジュールにタスクを割り当てたという体裁にしてしまうのです。しかし、スクラムにはマネージャーに相当する役割がいないので、担当者以外にタスクが間に合わないという判断を誰が下すのでしょうか。スクラム的にはチームで話し合って決めるというのが教科書に書いてあると思います。しかし、私はそれでもチームって誰ですか？と聞いてしまいたくなります。

リファレンス

t2y.hatenablog.jp

note.com

アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

books scrum

www.shoeisha.co.jp

最近、開発方法論や組織論に関心をもっています。2020年改訂スクラムガイド を読んだり、実際に業務でもスクラムを実践している開発チームで働いています。しかし、まだスクラム開発者として働き始めて2ヶ月なので新人です。これまで私はスクラムを実践している開発チームで働いたことがなく、いま初めてスクラムチームで開発者として実践しています。とはいえ、チケット駆動開発 + イテレーション開発 は10年以上実践してきており、厳密な定義では正しくないかもしれませんが、広義ではアジャイル開発という枠組みで開発を実践してきたと私の中では捉えています。そして、私の周りでうまくまわっていないスクラム開発をみかける度にチケット駆動 + イテレーション開発でうまくいくのになぜスクラムのような効率の悪い開発をしているのか？とすら内心では思っていました。

本書を読み終えて、結論から言うと、これまでの私の考えは誤っていたことが分かりました。スクラム開発が悪いわけではなく、スクラムをうまく実践できていない開発チームの諸問題を、スクラムがよくないかのように私が誤解していたと補正できたことが、本書を読み終えて私が得た最も大きな収穫と言えます。

(2020年改訂版の) スクラムガイドでは意図的に抽象的な表現を用い、役割と会議体のルールを定めた軽量な開発方法論のフレームワークを提供しています。そもそもスクラムとは、それ単体でうまく機能するような方法論ではないと考えるのが正しいようです。組織の文化、顧客、開発対象・規模など、様々な状況において柔軟にカスタマイズできるようなフレームワークです。そのため、一口にスクラム開発というカテゴリに括ることはできても、それは組織や開発チームによって千差万別であると言えるでしょう。

したがって、開発方法論がスクラムであるかどうかはあまり重要ではなく、スクラムをベースにしてもしなくてもいいが、開発がうまくいくように創意工夫や改善をし続けることが重要であり、スクラムはそのための下地としてのフレームワークを提供するにすぎないということが本書を読み進めていくうちに理解できました。

このことは第3章で木下文彦氏が書かれた「2020スクラムガイド改訂とスクラムの3つの罠」というコラムからも伺えます。私がスクラム開発を誤解していたように、スクラムを適切に実践できていない開発チームの特徴を3つの罠として述べられています。これまで私はこの3つの罠に陥っているようなスクラムチームを傍からみていて違和感を抱いていたと言えるでしょう。

  1. スクラムが形式的、儀式的になってしまっている
  2. プロダクトオーナー vs 開発チームの構図に陥ってしまっている
  3. スクラムマスターがスクラム警察もしくは雑用係になってしまっている

3つの罠から1番目の例を取り上げると、デイリースクラムが形式的に情報を報告するだけになっているチームがあるとコラムの中では指摘されています。本来のデイリースクラムの目的は状況に合わせた再計画であり、形式的な報告はその副次的なものです。こういった目的を理解せずにただガイドに書いてあるからと状況報告するだけのチームも増えたのだろうと推測します。

余談: デイリースクラムのトレードオフ

私はデイリースクラムが現代の開発方法論において開発の生産性とトレードオフになっていると考えています。

まずデメリットから述べます。スクラムガイドではデイリースクラムを15分のイベントと定義しています。毎日15分会議してなぜ生産性が落ちるのか？と思う人もいるかもしれません。私が課題意識をもっているのは時間の長さではなく、チーム全員を毎日同じ時間に集めるという同期的イベントの発生そのものに懸念を抱いています。同期的イベントのデメリットとして次のようなことが考えられます。

  • 集中して作業をしていても強制的に中断させられる
  • 同期的イベントの前後30分ぐらいは集中力を要する作業がやりにくくなる
  • 様々な理由でチーム全員集まらないことがままある

まずデイリースクラムを何時に開催するか？という大きな課題があります。朝10時にしているところも多いのではないかと推測します。私は朝型なので平均して8時ぐらいから始業しています。そうすると、集中して作業をしていても必ず10時に作業の手を止めなくてはいけません。そして夜型の人にとっては10時に参加することが難しいメンバーもいます。そういう人は遅刻したり午前半休することが常態化してしまうこともありました。13時にすればよいのでないか？となると、急ぎの報告をしたいときに13時では遅いため、デイリースクラムの前に打ち合わせをしてしまい、デイリースクラムを必要としなくなってしまう状況も起こりがちになります。こういう指摘をすると、朝会と夕会をやろうと言い出すマネージャーが現れたりして、さらに会議を増やすのかと私のような開発者はうんざりするわけです。とくに実務をやらないマネージャーほど、会議を増やすことに抵抗がなく安易にそういった提案をする傾向があるように思います。

またデイリースクラムという1日1回しかないイベントでしか進捗を報告しないメンバーの問題もあげられます。チケット駆動開発に慣れた開発者からみると、これでは報告が遅過ぎるように感じるのです。問題や懸念が発生した時点でチケットにその状況を記載し、それをマネージャーやメンターがみていれば、その時すぐにアドバイスや対策を検討できます。しかし、デイリースクラムでしか進捗報告をしないメンバーがいると、1日1回しかアドバイスや対策を議論できなくなってしまう懸念があります。それはメンバーの問題でしょうと思う方もいるかもしれません。しかし、私は知人からもこういった話しをたまに聞くため、特殊なケースではないと考えています。とくにメンバーのスキルが未熟なために誤った考え方や作業方針で進めてしまっている場合、1日1回の進捗報告では訂正がやりにくい状況というのがあります。スキル不足が原因の場合、メンバーは誤っているという気付きがないために報告できないのです。チケット駆動開発であれば、発生時に状況を伺う内容がコメントとして記載されるため、マネージャーやメンターがより迅速に状況を把握して訂正していくことができるのです。

ここからはデイリースクラムのメリットを述べます。スクラムを支持している方も安心してください。当然デメリットがある一方でメリットもあります。繰り返しますが、本来のデイリースクラムの目的は状況にあわせた再計画にあります。

想定外の状況が発生したため、スプリントのタスクを見直したり、ゴールを変更したりすることを比較的早いタイミングでメンバー全員で確認・合意できるところにあります。また先ほど、私がチケット駆動開発ならば書き込まれたコメントから状況を把握できると言いましたが、これをすべてのメンバーができるとは限りません。自分がやっていることを文章として書き表せるというスキルは、私が思っていたよりも習熟を必要とするスキルであり、開発者であっても全員ができるというわけではないことが経験則から分かってきました。書くスキルに加え、自ら情報発信するのが苦手なメンバーもいます。そういったメンバーは書くよりも話すことで情報共有できるデイリースクラムという場が唯一の救いであり (一方で義務でもあり)、聞かない限り状況を伝えるのが苦手なメンバーでも協働しやすいプラクティスと言えます。

さらに本書を読み進めることで著者の野中氏がナレッジマネジメントの古典となっている考え方として SECI モデルを説明しています。そして、SECI モデルの 共同化 (Sociallizatoin) がプロジェクトの起点であり、個人の暗黙知を他人や組織の暗黙知に伝えていくことの意義や重要性を説いています。起点が暗黙知であるならば、それはチケット駆動開発のようなコメントや文章として書くことはできないのです。

f:id:t2y-1979:20211219135420p:plain
知識創造の SECI モデル

スクラムのイベントが多いのは個人の暗黙知を他人や組織の暗黙知に伝えていくための装置でもあるように私は受け取りました。そして、デイリースクラムもその暗黙知を伝えるための役割の一端を担っているはずです。だからこそ、儀式的に進捗を報告するだけのイベントには意味がなく、個人の暗黙知を伝える共同化という活動を促す必要があるのだと私は理解しました。

つまり、デイリースクラムは直接的には状況にあわせた再計画という目的をもちながら、中長期的には共同化という知識創造につながるプロセスも組み込まれているのです。単純に開発の生産性だけを理由にデイリースクラムは非効率だと断じるのは適切ではないと、本書を読み終えて私は考えています。

前置きが長くなりました。ここからは本書を読んで私が関心をもったところを抜き出して紹介します。

スクラムの起源と知識創造と組織

ソフトウェア開発方法論としてのスクラムはジェフ・サザーランド氏らによって定義され、スクラムガイドによってまとめられています。一方でそのオリジナルと言えるコンセプトは、野中氏と竹内氏が1986年にハーバード・ビジネス・レビューに掲載した The New New Product Development Game という論文になります。この論文はスクラムの直接の参考文献であり、スクラムの理論的基礎にもなっているそうです。

hbr.org

本書の「第10章 竹内・野中のスクラム論文再考」には野中氏と竹内氏のオリジナルの論文とソフトウェア開発方法論としてのスクラムの対比や考察が行われています。1986年という、日本の製造業が強かった時代に書かれた論文なので、いまとは全く時代背景が異なります。その時代背景も考慮しながら現代のスクラムとの共通点を見い出すことは、普遍的価値や概念を推し量る上でとても意義のあることだと私は思いました。さらに歴史を振り返ることでその是非を検証することもできるかもしれません。いま考えたことややっていることが正しいかどうか、本当の意味では、時間が経ってから歴史を振り返ることでしか検証できません。そして、オリジナルの論文とスクラムの間には多くの共通点があり、その意図している目的や概念を理解することでスクラムが意図する目的の理解もより進みます。

野中氏は2010年までこの論文のコンセプトがソフトウェア開発方法論として使われていることを知らなかったそうです。野中氏は組織や組織的知識創造理論の研究者であり、氏の理論が実際のソフトウェア開発の中でどのように発展してきたか、どのように要項が取り入れられているかなど、氏の研究にも意図せぬ相乗効果を生み出しているように私は読めました。そのため、スクラムの今後の発展形や拡張を推し量る上で野中氏の理論を学ぶことにも大きな意味があるように私は考えています。

また Scrum Inc. CEO であるジェフ・サザーランド氏のインタビューも本書の中で紹介されています。ジェフ氏はオリジナルの論文を1993年の終わりに作られた開発チームに取り入れたそうです。チームリーダーをスクラムマスターと呼び、機能横断チームを採用しましたが、最初はそれだけでは大きな変化をもたらさなかったように答えています。そして、第2スプリントでデイリースクラムを取り入れたらすごくうまくいき、第3スプリントでは生産性が最初の2回のスプリントと比べて400%にアップし、1ヶ月の仕事を1週間でやり終えたことが語られています。そして、そもそもジェフ氏がスクラムを体系化しようと考えた動機にも触れており、それは後半の実践知リーダーシップとはどういうものかにも係ってきます。

本書の前半では、ソフトウェア開発プロジェクトの背景や難しさ、スクラムの方法論やアジャイル開発における様々なプラクティス、大規模スクラムの話題などが書かれています。そして、中盤に事例紹介があり、後半は知識創造の背景や方法論について述べられています。とくに 実践知 という概念について説明されているところに私は関心をもちました。

実践知とは、アリストテレスが フロネシス と呼んだ概念であり、暗黙知と形式知との両方で構成されるものであると説明されています。そして、そこに身体性を伴っていないと実践知とは呼ばないというやり取りも野中氏のインタビューで話されています。「第12章 スクラムと実践知リーダー」を読んだだけでは曖昧だった実践知という概念が、その後のコラムやインタビューでのやり取りから、私はより理解できました。実践知は、考えることと行動することがセットになっており、自分の頭の中で考えているだけでは得られないものであることが明言されています。昔は 知行合一 と呼ばれていたものですが、90年代以降の日本は分析過多、計画過多、コンプライアンス過多になってしまい、そのことを忘れてしまっているという件には納得感がありました。

野中氏は日本的経営の強みとしてミドル層、中間管理職の存在をあげています。過去の日本においてはトップと現場に間の独特のポジションが政治力や知識の共有に影響力をもっていたと言います。そして、日本からイノベーションを起こしていくためにミドル層の役割が重要だとも話されています。しかし、この点だけは私は同意できませんでした。1980年代の日本においては中間管理職が大きな役割を担っていたかもしれませんが、私の経験からは中間管理職を不要とする組織を目指すべきではないかと考えています。中間管理職の大きな役割の1つにトップの考えや方針を現場に伝えることがあります。これは口頭で議論できる人数という物理的制約を伴うコミュニケーションパスの問題から組織階層が生まれたのではないかと思います。そして階層型の組織には情報の非対称性というとても厄介な問題があります。情報の非対称性は組織の理不尽を増大させてしまいます。だからこそ中間管理職が重要だという主張も理解はできますが、ICT 技術が発達した現代では別の解決策があるのではないかということを追求したいと私は考えます。その答えがティール組織やホラクラシーであるかどうかはまだわかりません。

合宿をしなさいという解決方法

「おわりに」という最後の結びに野中氏のこんなエピソードが紹介されています。2011年にジェフ氏とガブリエル氏がスクラムのトレーニングを日本で開催し、その際に平鍋氏と野中氏が飛び入りで参加したそうです。そして、参加者からの質問に対して野中氏が次のように回答したやり取りが紹介されています。

「プロジェクトには、営業部門、マーケティング部門、サポート部門など、いくつかの部門のステークホルダーがいるのです。そして、どの機能を優先すべきかについて意見が分かれているのです。意見を1つにまとめるには、どのようにしたらよいのでしょうか」

「合宿をしなさい」

「形式的な会議で決めることはできない。いろんな背景をもった人の集合において、形式知で語れること、理解し合えることはごく一部だ。合宿をし、一緒に飯を食い、泊まって徹底的に話しをする。そうすると、形式知は脱ぎ捨てられ、自分の主観で話すようになる。そこで、なぜこのプロジェクトに自分が参加しているのか、という根源的な問いにまでたどり着けるだろう。そこから初めて、1つの共通理解が生み出される。この過程をみんなで踏みなさい。」

この回答がどのような組織や状況においても正しいとは私には思えません。しかし、この回答は決して私が自分の言葉では語れない類のものであり、野中氏の唱える実践知リーダーシップがどういうものかを物語る一例として、私は衝撃を受けました。平鍋氏はこのことを伝えたいというのが本書を執筆した動機と書いており、その衝撃も理解できます。

一般論としてはなにかしら定量的な論理や多数決などで決めがちな難しい問題を、形式知では決められないと早々に認め、全く非論理的な解決方法を簡潔に提示しています。データサイエンティストが読んだらぶっ飛んでしまうのではないでしょうか。このような決め方に反発する人もいると思います。私もどちらかと言えばそちら側の方です。

おそらくこの手法の成否はリーダーとメンバーの関係性に依るのではないかと私は思います。最終的には論理ではなく、このリーダーに任せようという主観的な判断がメンバーに広がっていって結論を見いだせるように私は受け取りました。したがって、合宿そのものはその装置の1つであって、最終的には人間関係が決め手であり、チームまたはプロジェクトがよりよい関係を築くには実践知といった概念が不可欠になってくるのでしょう。

実践知の話題は心理的安全性や認知心理学の知見ともいくつか合致するところがあるように思います。合宿という手段を用いなくても、スクラムの中でそれに近い状態を再現できるようにしていくことが今後のスクラムを発展させていくということにもつながるのではないかと私は思いました。

アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

Amazon