プロダクトチーム vs プロジェクトチーム
この記事は、以下サイトの機械翻訳です。
この記事は、2年前に「プロダクトチームとプロジェクトチーム」を発表した直後に書くべきでした。
その時は、プロダクトチームとプロジェクトチームの違いを強調した記事に続くべきだと考えていましたが、実際には希望的観測の犠牲になってしまいました。
私は、プロジェクトチームが悪いという主張を続ける必要はもうないと信じたかったのです。 それはちょうど、明らかな詐欺師に投票する人はいないと信じたかったように、健康に関しては人々が科学に従うと信じたかったように、あるいはFacebookが正しいことをすると信じたかったように。
残念ながら、希望的観測では現実は変わりません。
SVPGのパートナーであり、EMPOWEREDの共著者でもあるクリス・ジョーンズは、最近もプロジェクトチームに遭遇することがあると私に話してくれましたが、私はそれがまだそんなに流行っているとは信じたくありませんでした。
プロジェクトチームの問題点について書いたことがないわけではありませんが、それらの記事の多くは10年以上前のものであり、私はもう過去のものだと信じたかったのです。
この話題はもちろん、プロダクトチームとフィーチャーチームの違いに関連しています。プロダクトチームとフィーチャーチームの違いは、基本的にエンパワーメントにあります。 チームに解決すべき問題を与えるのと、構築すべき機能を与えるのとの違いです。
一方、プロダクトチームとプロジェクトチームの違いは、基本的にオーナーシップの違いです。 チームが結果に責任を持つのか、プロジェクト（アウトプット）を提供するだけで他のことに移るのかの違いです。
リーンスタートアップの用語では、プロダクトチームは耐久性があります。 長く存続します（通常、最低でも1～2年）。
対して、プロジェクトチームは、プロジェクトそのものの期間中、存在します。 これが、プロジェクトチームが "プールモデル "と呼ばれる理由です。 エンジニアはプールから選ばれ、1週間から1ヶ月、2ヶ月とプロジェクトに従事し、プロジェクトが終了するとプールに戻って他のエリアに再配属されるのです。
プロジェクトチームにまつわる最大の神話は、すべてのエンジニアがその時点で最も重要なプロジェクトに「フル活用」されるため、この方が効率的だというものです。
例えば、パンフレットのWebサイトを作るような些細なことに取り組んでいるのであれば、確かにそうでしょう。 しかし、私は、つまらないものを作っている会社と一緒に仕事をしたことがありません。
技術系プロダクトの会社が作るものは、決して些細なものではありません。 実際、エンジニアが重要な役割を果たすために、実現可能な技術、基礎となるアーキテクチャ、関連するコードベース、そしてドメインを十分に学ぶためには、数ヶ月を要するのが普通です。 また、デザイナーやプロダクトマネージャーも同じように学習します。
エンジニアやデザイナー、プロダクトマネージャーが、簡単かつ瞬時に主要な分野を切り替えてイノベーションを期待されるという概念は、現実を無視しており、希望的観測をはるかに超えています。
また、これは単にベロシティの話です。 顧客のために革新を起こすことは言うに及ばず、実際に何か真の価値を生み出すことについて語ろうとすると、事態はさらに悪化します。 プロジェクトチームのメンバーは、コードベースをほとんど知らないだけでなく、自分のチームメイトのこともほとんど知らないため、真のコラボレーションや問題解決に必要な信頼関係はほとんどありません。 そして、実際の顧客についてはさらに知らないのです。 このようなモデルで働いてくれる宣教師を探すのは大変です。
より一般的に言えば、私たちが何年も前に学んだことの一つは、成功はプロジェクトから生まれるのではなく、必要な結果が得られるまで、ある分野で継続的に作業し、繰り返し行うことから生まれるということです。
プロジェクトチームの兆候は一目瞭然です。傭兵チーム、遅いベロシティ、ほとんどないイノベーション、膨れ上がった技術的負債、結果のオーナーシップがない、孤児となったプロジェクト、あらゆるところに向けられた非難。
将来的にはこのプロジェクトに戻れるかもしれませんが、それは確実ではありません。また、後続のプロジェクトが承認されたとしても、同じ人がアサインされるかどうかは誰にもわかりません。
これらの欠陥は、長い間、周知の事実でした。 では、なぜ多くの企業がいまだにプロジェクトチームを使っているのだろうか？
その最大の理由は、プロジェクトチームがIT文化の一部であるからだ。 ITの特徴は、テクノロジーをコストセンターとして扱うことである。
そして、IT組織が資金を調達する古典的な方法は、プロジェクトによるものです。 昔から、プロジェクトのためのビジネスケースを提供し、プロジェクトのための資金を調達し、プロジェクトにスタッフを配置し、プロジェクトを出荷し、実際の結果をビジネスケースと比較して誰もチェックしないことを願い、繰り返してきました。
通常、このような組織では、問題の根源はCFOとCIOにあると言われています。 両者は表裏一体の関係にあります。 CFOは、自分が財政的に責任を果たしていると信じたがっている（そうではない）。 CIOは、自分がステークホルダーに貢献することでビジネスに貢献していると信じたがっている（そうではない）。
彼らは意図的に会社を傷つけようとしているわけではありませんが、それにもかかわらず、これは膨大な量の無駄をもたらし、さらに重要なことには、会社がディスラプション（破壊）の機運に包まれていることになります。
これは、プロジェクトチーム（またはフィーチャーチーム）から権限を与えられたプロダクトチームへの変革が、プロダクトやテクノロジーを超えて行われることを理解することが非常に重要である理由でもあります。 このノートだけでも、ビジネスオーナー/ステークホルダーだけでなく、財務にも影響を与えることがわかります。
この問題を抱えているのは、古いITスタイルの大企業だけではないということを指摘しておきたいと思います。 優れたプロダクトスキルを持つスタートアップ企業が急成長したものの、初期の頃のようにチームに権限を与えて仕事をさせることで規模を拡大するのではなく（権限を与えられたプロダクトチームの中でも最も純粋な形です）、リーダーは代わりにプロジェクトチームや機能チームに人員を配置して指揮することで規模を拡大しようとし、初期の頃の最も重要な要素を失っていることに気づかない、という状況を見たことがあります。
このような基本的なテーマについて観察し、書いているのは私だけではありません。 先に述べたように、これらの問題は確立されており、よく知られています。 数年前にThoughtworks社が素晴らしい要約を書いています。
LINEで「海外プロダクトマネジメント情報を機械翻訳」の新着投稿を受け取れます📬
Discussion