プロジェクトからプロダクトへの移行に伴う課題

Nationwide Insuranceの元DevOpsテクノロジディレクタであるCarmen DeArdo氏と、Tasktop製品管理担当副社長のNicole Bryan氏が、先日のDevOps Enterprise Summit Londonで、プロジェクトベースからプロダクトベースの組織に移行することの重要性について講演した(スライドのPDF)。プロジェクトをベースとした計画と投資は、ITとビジネスビジョンの乖離へとつながる(ITがコストセンタないしブラックボックス扱いされる)、成果よりも活動が重視される、硬直化したプロジェクト予算が今日の戦略や方向性の変化速度に適応できない、といった問題を孕んでいる。

プロダクト志向(Product Orientation)には予算や計画、チーム、優先度、可視性、リスクなどの管理において、全面的に新しいアプローチを必要とする困難さがある。DeArdo氏に、これらの課題について詳しく聞いた。

InfoQ: プロジェクトからプロダクトへの移行を推奨するのはなぜでしょう？“間違ったプロジェクト”の具体的な例をあげて頂けますか？

Carmen DeArdo: 講演では、冒頭に５つの課題を取り上げました。それらの多くはITを、プロフィットを生み出す重要な機能ではなく、“コストセンタ”と見ることから来ています。その理由のひとつは、ITがビジネスビジョンや戦略から切り離されているように見える点にあります。企業はビジネスとITの目標の関係を(絶えず)マップしていますが、どちらの立場にいる者にとっても、そのようなつながりは実感できないものである場合が多いのです。ビジネスとITの両方から構成されたプロダクトチームを立ち上げて、直接作業することで、ビジネス機能に加えて、リスクや障害、負債の観点からの優先度付けが必要な項目に対するビジネス的な洞察力を備えることで、ビジネスとITの直接的な連携が可能になります。

プロジェクトに問題があるがために、ビジネスに重大な影響を及ぼす可能性のある、リスク管理のような重要な項目が顧みられなかったり、後回しにされたりすることが多くなっているのではないでしょうか。開発と運用の乖離が問題を起こすように、ビジネスと開発の分断も問題を起こします。プロジェクト構造には、作業の種類や優先度の違いによって、これと同じような分断を引き起こす傾向があるため、全体的に対処する必要があります。

InfoQ: それはつまり、仕事を計画する上でプロジェクトを使用するべきではない、ということでしょうか？

DeArdo: そうではありません。私は、Jon Smart氏が講演で語った“PMOは死んだ、PMOよ永遠なれ”、という言葉は名言だと思っています。私がベル研究所にいた頃、新しい製品の開発にはプロジェクトを使用していました。ですから、プロジェクトが不要だというつもりはないのですが、製品の改善やサポートに必要な作業は、プロダクト構造の方がうまくいきます。

InfoQ: ご自身の経験から、作業管理のアプローチをそのように変更する上で、おもな障害を３つあげて頂けますか？

DeArdo: 講演では、プロジェクトからプロダクトへ移行する際に取り組むべき７つの分野を取り上げました。トップ3は、その企業における現在の状況や文化によって違うと思います。私としてのトップ3は、予算、(コスト削減の必要なコストセンタとしてITを見た場合の)成功、チームへのアプローチ(プロジェクトチームを編成するのではなく、チームに作業を提供する) です。ただし、当面の課題は、ビジネスの視点からプロダクトを定義して、それをサポートするチームを立ち上げることでしょう。

InfoQ: プロダクト志向による具体的なアプローチやメリットを、予算の観点からあげることはできますか？

DeArdo: 年間予算が必要不可欠だという組織もあるかも知れませんが、何百という活動に対して - 場合によっては18ヶ月前に - 資金を提供する代わりに、プロダクトへの投資に資金を供出して、プロダクトマネージャが開発の優先順位を決定する、という方法もあります。ベル研究所では、プロダクトへの投資を変更する必要性を判断するために、3ヶ月毎に再検討が行われていました。

Jon Smart氏は、ポートフォリオ管理にアジャイルアプローチを適用することを提唱しています。バリューストリームのごく一部であっても実際にアジャイルでない部分があるならば、アジャルであるとは言えません。真にアジャイルであるためには、予算とポートフォリオ管理プロセスに手を付ける必要があります。

InfoQ: プロダクトをどのように定義しますか？

DeArdo: ビジネスプロダクトとITプロダクトの両方があります。プロダクトとは単純に、価値を提供するカスタマベースを持つものです。私たちはこれまで、ITプロダクト(例えばデプロイメントパイプライン)をビジネスプロダクトと同じ方法で扱わなかったために、問題を起こしてきたのだと思います。

InfoQ: 講演では、プロジェクトを行うチームを引っ張り出す“リソースプール”として人々を捉えることの問題点について話していましたが、では、どうすればよいのでしょう？ それに対してプロダクト志向は、どのように役立つのでしょうか？

DeArdo: プロダクトのどの部分に投資するかを決定すれば、そのプロダクトをサポートするチームに対する資金提供が可能になります。ただし、講演でも話したように、製品に関するすべての業務をひとつの少人数チーム(two-pizza team)で行うというのは、“お伽話”に過ぎません。製品に関する複数のスキルを備えた人材が必要なのです。そして資金が変化したとき、私たちが真にアジャイルならば、それに応じて人を動かすことができます。これが言うほど簡単ではないことは分かっていますが、目標にする必要はあります。

30日、60日、90日といった“需要”見通しの必要なプロセスや、長期的なSLAを伴った遂行プロセスは、いかなる意味においてもアジャイルではありませんし、ビジネスニーズへの迅速な対応というニーズの高まりをサポートするものではありません。

InfoQ: バリューストリームをどのように定義しますか、また、作業やチームをそれに合わせることが重要なのはなぜでしょう？

DeArdo: バリューストリームは、特定のユーザに対する“価値”の提供に集中した、アクティビティと時間の集合体です。バリューストリームはユーザに始まり、ユーザに終わります。

バリューストリームが重要なのは、あらゆるビジネスの焦点がユーザへの価値提供であるからです。これを達成するためのメカニズムがバリューストリームなのです。

InfoQ: バリューストリームとビジネス領域の間には、どのような関係性が成り立つのでしょう？

DeArdo: これまで述べたように、ビジネスプロダクトをプロダクトチームに連携させることは重要です。今日ではこれが不明確であるがために局所的な最適化が実行され、結果としてユーザへの価値の流れを改善できていない、というのが、多くの組織が直面している複雑性の原因です。

InfoQ: リスクを効果的に管理し、緩和する上で、プロダクト志向はどのように役立つのですか？特定のプロジェクトに割り当てられなければ、リスクについて“忘れる”というリスクが増すのではないのでしょうか？

DeArdo: プロダクトにリスクは付きものです。例えばファミリーカーでは、オイル交換などのメンテナンスを忘れていれば、故障の発生するリスクがあります。それぞれの自動車のリスクは車種や製造時期によって違います。従ってこれらをすべてひとつの“Transportation(輸送)”プロジェクトとしてまとめるのは、リスク(リコールなど)やメンテナンス(負債)作業などのアクティビティセットや、Sirius MXなどの“機能”を独自に持ったTransportationのプロダクトとするよりも、複雑なものになることは明らかです。

プロダクトにとって何が最良かを考える“システム思考”の担い手としては、プロダクトオーナが最適です。さまざまなタイプの作業を全体的に見通して、継続的な優先度付けと追跡を行うことができる立場だからです。

最後に、プロジェクトマネージャには多くの場合、最初コストでビジネス機能を提供することに対して十分な見返りがあります。リリース単位で変更されるシステムのセキュリティ修正に出資することは、その目標に沿ったものではありません。プロダクション志向を採用することで、プロダクトオーナは、インセンティブが矛盾する心配なく管理を行うことができるのです。