翻訳：あなたが働いている場所がフィーチャーファクトリーである12の兆候

概要

この記事は"12 Signs You’re Working in a Feature Factory"の日本語訳です。

本文

（注：これは 2016 年に書かれたものです。最近、つまり 2019 年後半に、それ以降に学んだことについて投稿を書きました。）

過去2年間、いくつかのカンファレンスでの講演で「フィーチャーファクトリー」という言葉を使ってきました。この言葉を使い始めたのは、ソフトウェア開発者の友人が「工場に座って、ひたすら機能を作って、それをラインに送り込んでいるだけだ」と愚痴っていたのがきっかけです。

もしあなたがエンジニア自分がフィーチャーファクトリーで作業しているかどうかはどうやってわかるのでしょうか?

1.測定がない。

チームは仕事の影響を測定していません。
あるいは、測定があったとしても、製品管理チームによって個別に行われ、選択的に共有されています。
自分の仕事がうまくいったかどうか、全く分かりません。

2.チームとプロジェクトの急速なシャッフル（いわゆるチームテトリス）

チームは、魅力的なミッションやイニシアチブではなく、機能やプロジェクトの割り当てに取り組んでいます。
それによって慢性的なマルチタスクと過剰なリソース投入が発生します。

翻訳者解説：
機能やプロジェクトをある期日までに開発するために必要な人員はどれだけか？
フロントとサーバサイド、API設計の知識が必要で……。最低でも知見のあるAさんは必要だな。
じゃあAさんとBさん、サポートでCさんを割り当てよう。
そのような理由で人員が割り当てられます。
期日までに機能やプロジェクトが完成するか？それがチームテトリスの最大の目的であり、そのために恒常的に急速なシャッフルが行われます。

3.「出荷」に関する成功劇

リリースの影響についてほとんど議論されずに成功したと言う物語が展開されます。
組織が何を称賛しているかで、その組織について多くのことがわかります。

翻訳者解説：
リリースによってどうなったかという測定結果は共有されません。
かわりに「xx月xx日、プロジェクトや機能のリリースによってxxが多大なる成果をもたらした！」という大本営発表がもたらされます。
大本営発表で称賛される内容が組織が重視している事柄です。

4.頻度の低い（認知された）失敗と廃棄作業

削除された機能はありません。
成功の主な尺度は、提供された機能であり、提供された成果ではありません。
データと学習に基づいて作業が破棄されることはめったにありません。
チームには、失敗を認めるという前提となる安全性が欠けていることがよくあります。

5.コア指標との関連性がない

顧客やビジネスの望ましい成果に関する議論が不足しています。
チームは業務を主要なビジネス指標や顧客満足度指標と結び付けることができません。
反復作業を「最も重要なこと」と結び付けることができません。

6.PMの振り返りがない

プロダクトマネージャーは、製品に関する意思決定の質について定期的に振り返りを実施しておらず、期待されるメリットと実際のメリットを比較していません。
開発者には「合格テスト(passing tests)」がありますが、プロダクトマネージャーにはそれがありません。
プロダクトマネージャーは、ベロシティとアウトプットを主要業績評価指標としています。

翻訳者解説：
「合格テスト」は受入テストなどの機能的には動くがRejectされる類のテストか。ベロシティとアウトプットはいずれも量の指標でしかない。

7.優先順位付けへの執着

優先順位付けの厳密さ（何に取り組むかを決めること）と検証の厳密さ（実際に取り組むべき正しいことかどうかを判断すること）の間に不一致があります。
優先順位付けの厳密さは、社内のアジェンダを緩和し、人々が「自信を持てるように」することのみを目的としています。
どのアイデアに取り組むかを決めるのに多くの労力が費やされ、データに基づく調整や即興の余地はほとんど残されていません。
ロードマップには機能のリストが示されており、重点分野や成果は示されていません。

翻訳者解説：
機能やプロジェクトの優先順位は厳密に定められています。
そのため「本当にこの機能は必要か？」「このやり方には再検討の余地はないのか？」そのような議論は発生しません。何しろそうつくられているからです。
そんな優先順位を決めるために多くの労力が費やされています。
多くの労力を費やして決められた優先順位に、調整や即興の余地はほとんど残されていません。
またロードマップに示されるのは機能のリストだけです。なに(What)を開発するのか、が示され開発チームはどのように(How)実現するかを考えることに注力します。
しかしなぜ(Why)は示されず、そのことが計画の変更をより困難にします。

8.微調整は不要

作業が「完了」すると、チームはすぐに次の「プロジェクト」に移ります。
定性・定量データに基づいて反復する時間はありません。

9.引き継ぎの文化

「エンジニアリングの準備が整う」よう、「作業を先取りする」ための前倒しプロセスを導入しています。
チームは、調査、問題探索、実験、検証に直接関与しません。
作業が出荷されると、チームはサポート、カスタマーサクセス、営業とほとんど連絡を取りません。

10.大規模なバッチ

実験の義務がないため、機能は段階的に提供されるのではなく、単一の大規模なバッチで提供されます。
スプリントで作業することはできますが（やった、私たちは「アジャイル」です）、各スプリントの終了時には新しいものは顧客に届きません。
※訳者注：作業は短いスプリントで区切られているが、リリースは大きなバッチサイズで行われる。そのためスプリント単位でリリースを振り返り、それを開発プロセスに反映させることができないと言う話か

11.先行収益の追求

機能は新規取引を成立させるために実装されます。
本質的に間違っているわけではありませんが、経済的な正当化は往々にして（せいぜい）薄弱で、製品の複雑さの非線形的な増加（四半期の利益は得られても、後になって何倍にもなって支払うことになる）を考慮に入れていません。
繰り返しますが、これは機能が価値測定の単位であるという考えを強固なものにしています。
製品に関する意思決定には、健全な経済的根拠が欠けています。

12.派手なオブジェクト

リファクタリング作業と負債削減の可視性が低いです。
また全体的な価値提供能力の可視性が低いです。
前述のように、成功の尺度は新機能の成果である。派手な新しいオブジェクトとは対照的に、製品全体の健全性に対する評価が低いです。新機能が既存製品のユーザビリティ（および保守性と拡張性）に与える影響に対する認識が低いです。
この投稿の翻訳は、韓国語をご覧ください。

この問題の対処法については、以前に記事を書きました。以下の記事をご覧ください。
（こちらに関しては原記事をごらんください）