エンタープライズの開発における、プロダクトオーナーとしての組織（前編）。Developers Summit 2014 Summer

ソフトウェア開発において、プロダクトに責任を持って決断してくれる優秀なプロダクトオーナーがいることは望ましいことですが、一般に受託開発において、お客様側にしっかりとしたプロダクトオーナーとしての担当者がいることはめったにありません。

7月末に行われたDevelopers Summit 2014 Summerのセッション「創業122年の企業と顧客価値にコミットした 開発を実現する試みと成果について」では、東京商工リサーチのシステム開発を行ったグロースエクスパートナーズが、「プロダクトオーナーとしての組織」と題して受託開発における現実的なプロダクトオーナーの取り組みについて解説しています。

このセッションは開発側であるグロースエクスパートナーズだけでなく、発注側である東京商工リサーチの担当者も登壇し、両面から「プロダクトオーナーとしての組織」を実現するためにどのようなことを行ったのかを浮かび上がらせるユニークなものとなりました。

セッションの内容をダイジェストで紹介します。

創業122年の企業と顧客価値にコミットした 開発を実現する試みと成果について

グロースエクスパートナーズ 執行役員 鈴木雄介氏。

受託開発では、お客様は安くしてほしい一方で、開発側としてはできるだけ機能を作りたくないといったWin-Winの関係になりにくい。ただ、なりにくいだけでできないわけではありません。

そのためにはお客様と開発チームがきちんと意思疎通できていることが重要で、そのためにプロダクトオーナーという存在が必要となります。

プロダクトオーナーはスクラムによって重要になってきた言葉ですが、スクラムにかぎらずエンタープライズの開発ではプロダクトオーナーは重要だと思います。

プロダクトオーナーは2つの方向を見ていて、1つは組織内のステークホルダーやユーザーのニーズの優先順位について理解していること。もう1つの方向は、開発チームに何をどの順番で作るか、受け入れの条件は何かを伝えて、それを実行されるようにすること。

世界最高のプロダクトオーナーは誰かと言えば、スティーブ・ジョブズですね。

ということは、エンタープライズで開発をするときには、その会社のスティーブ・ジョブズがどこにいるかを考えないといけません。

今回はそれを私たちの開発でどのように見つけていったのか、という話をしたいと思います。

スティーブ・ジョブズを探して

お客様は東京商工リサーチという、企業の信用情報を提供している会社です。創業122年、明治維新の後に企業間取引が活発になって信用情報が必要になってできたと。

このお客様に対して、「tsr-van2」と呼ばれる、オンラインで企業情報や財務情報が検索できるサービスを再構築しました。例えば銀行さんが、ある会社に融資をしていいのかを確認したり、商社が取引するときなどの信用情報を提供します。

なぜこれを再構築したかと言えば、今後の事業のオンライン化を推進するための基盤とするためです。

今年の1月にリリースしましたが、だいたい300人月掛かりました。ウォーターフォールでがっちりと8割程度作ってから、テストと改善に関してはアジャイルっぽい改善プロセスを行いました。

現在はローンチを終えて持続的な改善プロセスに入っています。このとき、どこにスティーブ・ジョブズ、つまりプロダクトオーナーがいるのかを確認しなければいけません。

考えてみるとなかなか難しいのは、組織内のステークホルダーやユーザーのニーズの優先順位について深くしているのは誰か、ということです。営業はユーザーのニーズを理解していると思いますが、サービスの価格設定は役員の方が最終的に決めることになりますし、われわれの窓口はシステム本部ですが、業務上受け入れられるかどうかは業務部が決めるわけですね。

要するに、スティーブ・ジョブズみたいな（自分で全部決められる）スーパーマンはいないんですね。組織の中には個別にできる人はいるんですが、ひとりで全部できるわけではない、というのはどの組織でもあることだと思います。

個人でプロダクトオーナーはできないとしても、組織が意思決定を適切に回してくれれば、それがプロダクトオーナーになれます。つまり、お客様の組織がプロダクトオーナーとして機能してくれないといけない、ということが大きな気づきでした。

しかし組織のプロダクトオーナーというのは、意思決定もフィードバックもそんなに早くありません。ただ定期的に意思決定することはできると思います。そこで3つのサイクルを導入しようとしました。

1つは、「新機能」については企画して承認して設計をして承認してもらってと、必要な時間を書けて合意形成しなければいけないもので、ウォーターフォール的にやるものです。これが年1、2回。

2つ目の「定期改善」はポイントで、工数の枠だけ事前に承認いただいて、実質的な作業内容はバックログから優先順位によって選択することにしています。

「保守」はそれとは別に、障害対応や問い合わせ対応などです。

これを決めておくことで、いろいろいいことがあったなあと思っています。

こうした開発について、もう少し詳しく開発企業側からの視点と、お客様からの視点でお話をさせていただきます。

ソフトウェア開発企業からの視点

グロースエクスパートナーズ ITアーキテクト 和智右桂氏。

スクラムでは、ロールが3つ、プロダクトオーナー、スクラムマスター、開発チームと出てきました。私は開発チームの代表になればいいのか、あるいはスクラムマスターになればいいのかというと、スクラムをやろうとしてなかなかうまくいかないのが実態です。

というのも、スクラムがうまく回るためには、そもそもお客様との関係性というか、スクラムというフレームワークを成立させるための外側が重要なんですね。

そのために、プロジェクトマネージャ／プロジェクトリーダーとして顧客価値にコミットする、信頼関係を作っていくのが大切だと思います。

顧客価値へのコミットとは、1つはお客様の感覚を理解すること。抽象的なのでなんとなくふわっとしていますが、お客様のビジネスを理解してそれをモデルにしてソフトウェアを作りましょう、ということ。

それからビジョン。いまどこに向かおうとしているのか、成長戦略やマーケットは何か、そういったものも理解しましょうと。また、いまお客様が見ている景色を共有できるようになる。そこからさらに、それをどう感じるかまで分かるようになること。価値観というか肌感覚。

2つ目は、実行ですね。お客様が納得のいくように実行していくこと。

いわゆるアジャイルのプラクティスは導入していますが、大事なのは、ゴールへ向かって全力で走ってる状態でスクラムをやろうとしても、いきなりはできません。また、全力で走り続けられるわけでもないので、求められるものを少しずつ作りながらスピード感を揃えていく。

チームも、プログラマ集めました、テスター集めましたって作るものでもなくて、個々人が持っている力量や適性に応じてロールを配置して、そういう中で穴を埋めてくれるとか流れを整えてくれるとか、できあがるものであって。

≫後編に続きます。後編では、東京商工リサーチのシステム本部長が、顧客の側から見たプロダクトオーナーとしての組織について解説しています。