組織をプロダクトオーナーにする、ということ[修正あり]
2014年7月31日（木）に開催された「Developers Summit Summer 2014」（通称：夏サミ）にて、「創業122年の企業と顧客価値にコミットした開発を実現する試みと成果について」という講演をしてきました。資料と動画は以下から。
講演には弊社の顧客である（株）東京商工リサーチ（以下、TSR）の青木さん（システム本部 部長）にも参加いただきました。講演の最後に「GxPさんとは、まさに二人三脚のような関係を築けた」という言葉が非常にうれしかったです。
また、講演に向けて打ち合わせをする中で「我々は何をしてきたのか/何が出来たのか」というのをじっくり話せたのは良い経験でした。プロジェクトが完了したら顧客と一緒に講演する、みたいなことが毎回出来たらいいでしょうね。
速さよりもリズム
さて、今回の講演のキーワードでもある「組織としてプロダクトオーナーの役割を果たす」も、そういう事前打ち合わせの中で生まれた言葉です。
皆さんも承知の通り、エンタープライズ案件では顧客側の意志決定が一筋縄でいきません。プロジェクトで握っても業務部門で断られる、役員でひっくりかえされるというようなことですが、理由は簡単でシステム部門が業務や役員の関心事が理解できていないからです。エンドユーザーの興味や事業の優先事項は常に変わるので、これを常にシステム部門が把握しているのは無理でしょう。
とはいえ、「速くしたいからシステム部門が勝手に決めて、後から修正する」というわけにもいきません。たとえば商品の価格設定は「勝手に決めて後で変えればいい」ではダメで、事業計画も含めた関係各部門の確認が必須となります。
では、大企業では、どのような意志決定プロセスが「最適」なのでしょうか？我々は「速くする」ことではなく「適切なリズムを刻む」ことが重要と考えました。
3つの対象と3つのプロセス
今回のプロジェクトでは、我々が関わると決まる前からTSR青木さんが問題意識を持ってコアチーム作り/情報共有ツール整備などを推進されており、社内の意思疎通を強化していました。そこで、その流れに乗る形で意志決定プロセスの構築を進めました。
特にローンチ後は「新機能追加」「定期改善」「保守」という3つの枠で契約することを提案し、了承いただけました。
3つの枠は、それぞれ特定の開発対象と紐付いています。
・商品追加など事業戦略に関わることは都度（新機能追加）
・事業戦略までいかないが社内合意が必要な改善は3ヶ月ごと（定期改善）
・システム部だけで決められる改善は2週間ごと（保守）
・緊急事態は緊急対応（保守）
定期改善のタイミングは「組織として合意を得るような機能改善は3ヶ月定期ぐらいじゃないと無理」ということから決まりました。事前に年間計画としてリリース日と予算枠だけ役員承認をもらい、設計が進んで機能と工数を確定させた上で、再度、稟議をかけるという進め方です。やるべき機能は社内のバックログから優先順位で判断しています。特徴としては、
・定期的なリリースが実現できる（3ヶ月に1回）
・機能確定からリリースまでの時間が短い（2ヶ月程度）
・受託請負で契約できる（リソース制約が少ない）
ということになります。
なお、上記の3つの枠は全て非常駐（非委任契約）で実施しています。倉貫さんの「納品のない受託開発」でも同じですが、受託契約＋非常駐によって開発リソースの制約が少なくなることは開発側に様々なメリットをもたらします。
組織としてプロダクトオーナーの役割を果たす
3つの枠は「開発対象に応じてプロセスを変えている」だけなのですが、それは単に「ソフトウェア開発の都合」ということではなく「組織がITサービスをマネジメントする」という観点で考えられています。
アジャイル（俊敏）では速さが重要視されている気がしますが、[修正開始]「アジャイル」の訳語が「俊敏」とあるように、アジャイルはウォーターフォールと比較して「速い」ことが強調されているように思います。しかし、その本質は「速さ」ではなくて、[修正終了]僕は「ユーザーが主導すること」が最初にあって、そのために「適切なサイクルで活動を行うこと」が重要と考えています。[追記開始]ただ速さを求めるのではなく、自分にあったリズムはどのぐらいだろう？と考える事で無理のない適切な速さになるのです。[追記終了]そして、その「活動」というのがシステム部門と開発企業というプロジェクト内に閉じた話ではなく、顧客組織全体の活動になることが必要です。TSR様では都度/3ヶ月定期/2週間定期/という3つの枠を作ることで最適なサイクルに繋がりました。他の組織であれば、別のサイクルであっても問題ないでしょう。
この状況を説明するのに「組織としてプロダクトオーナーの役割を果たす」という言葉がフィットしました。誤解がないように書いておきますが、我々はスクラムを実践したかったわけではありません。でも、振り返ってみればスクラムが提唱する「プロダクトオーナー」という概念で説明ができた、というだけです。これは僕らにとっても面白い出来事でした。
まとめ
GxPは「社会的基盤を提供する事業会社と持続的な開発を実現する」ことを目指しています。その事例としてTSR様との取組みを紹介しました。もちろん、他の顧客とは、また異なるプロセスで仕事をしていますが基本的な考え方は同じです。現状では事業会社が外部のソフトウェア開発企業を受託で活用するは必要なことであり、そのためには我々が「ソフトウェア作る」だけの仕事ではなく「ITサービスを通じて顧客の成長を促す」仕事をしていかなくてはいけません。今後も機会があるたびに事例公表が出来ればと思います。
まだまだ道半ば。この案件だけではなく、様々な取組みの中でよりよい方法を模索していきたいと思います。一緒に歩いてみたい仲間はいつでも募集中ですよ！
