Shoeisha Technology Media

CodeZine(コードジン)

記事種別から探す

「誰もが幸せになる」プロダクト開発を、リリースプランニングの見える化で可能に【デブサミ2017】

【17-C-4】 正しくプロダクトを作り、リリースプランニングするためのプロダクトオーナーの役割とは

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2017/03/30 14:00

 ビジネスにおけるITソリューションの役割と影響は年々大きくなっており、そこに求められるソフトウェアも複雑で高度になってきている。開発プロジェクトの不確実性はますます高まり、変化の激しい市場のニーズに応える製品やサービスを、いかに的確に提供するかは開発者にとって最重要課題の一つだ。株式会社エウレカ 経営管理本部 情報システム部 梶原成親氏は、これまで数多くのプロジェクトを通じて、アトラシアンの開発管理ツールを活用してきた。そして、より良い開発プランニングの方法を探ってきた。Atlassian User Group Tokyoでも活躍する同氏が、「ユーザー、デベロッパー、そして誰もが幸せになる」プロダクトオーナーの役割について語る。

目次
株式会社エウレカ / eureka, Inc. 経営管理本部 情報システム部 梶原成親氏
株式会社エウレカ / eureka, Inc. 経営管理本部 情報システム部 梶原成親氏

見積もりはプロジェクトの進捗によって変わる

 梶原氏はプロダクトオーナーを「プロダクトバックログの管理に責任を持つ一人の人間」と定義する。プロダクトバックログとは、その製品がユーザーに提供する価値と、その実現のために必要なタスクをリスト化したものだ。これをもとに開発チームが行うべき作業の価値を最適化し、プロダクトのROIを最大化する上で必要なタスクの優先順位を考えながら、リリースのための計画策定を行うのがプロダクトオーナーの責務である。

 開発プロジェクトの基本となるのが、見積もりだ。一般的に見積もりは、プロジェクトの完了までを正確に見通すものでなくてはならないと考えられている。しかし梶原氏は「見積もりとは、現時点での情報に基づく予測にすぎない。それを確定のものとして扱えば、無理なスケジュールや余計な作業が発生するなど、むしろ弊害が大きい」と警告する。

 プロジェクトが大規模なものであればあるほど、たとえ大きく全体を見積もったとしても、作業の進捗にしたがって、当初の見通しと実績との差は確実に大きくなっていく。下図は各フェイズ時点での見積もりと実績の差を示しているが、左端のプロジェクト開始時から、作業の進捗に比例して、ブレ幅が小さくなっていくのがわかる。最初は「ここまでやりたい」という要件がいくつもあるが、具体的な作業が進むにつれて要件が絞られてくるため、見積もりの精度もどんどん向上していくのだ。

プロジェクトの進捗にしたがって見積もりの精度は上がっていく
プロジェクトの進捗にしたがって見積もりの精度は上がっていく

「まず納期ありき」は、かえって品質に悪影響も

 梶原氏は「大事なのは、見積もりはコミットメントではないということだ。ビジネスサイドの人と話していると、スケジュールと予算を見積もって、あとはその通りに進めることだけを求めがちだが、そんなコミュニケーションをしている限り、誰も幸せになれない」と語る。

 見積もりを「コミットメント=確約」と、とらえてしまう弊害は大きく2つある。1つは「納期最優先」になってしまうことだ。とにかく予定に間に合わせようといろいろな小細工をして、かえって進捗を遅らせてしまう。よくある失敗が追加人員の投入だ。人月数が減ることで数字上は間に合うように見えるが、中途で加わった開発者がプロジェクトの目的や自分の役割を理解するには一定の時間が必要で、スピードアップするよりもむしろチーム内のコミュニケーションコストを増大させるリスクのほうが大きい。

 2つ目は、逆に過剰なバッファを取り、余裕のあり過ぎるスケジュールを引くケースだ。こちらもユーザー上の価値提供よりも納期に目が行ってしまうため、結局締め切りいっぱいまで時間を使ってしまい、開発スケジュールやコストが余計にかかるだけで終わってしまう。

 「いたずらに納期に間に合わせようとすればデスマーチ化は必至で、開発者はつらく、肝心の顧客も品質の良いプロダクトが期待できない。反対に余裕がありすぎても、余裕はあればあるだけ使ってしまうので、時間をかける割にプロダクト品質は向上しない。いずれにしても『まず納期ありき』は、良いプロダクト開発の上でむしろ障害だと言える」

定期的な計画見直しが開発関係者の団結を促す

 では、良いプロダクト開発計画とは何か。梶原氏は、ステークホルダーが信頼できる計画だと示唆する。

 「大事なのは、常に正しい見通しを共有し、定期的に計画を更新し続けることができる体制だ。そう言うと『いったん決めたスケジュールを守らないのか』といった声も聞こえてくるだろうが、先ほど述べた通り、そこだけに固執するとかえってマイナスになる」

 むしろ重要なのは、この先の見通しに対して常にトレードオフを提示し続けることだ。「この先を順調に進めるには、当初の見積もりに対してこの変更案が有効だ」といった指針を全員に示し、より的確な意思決定を支援できる力量が、プロダクトオーナーには求められている。

 ここで有効なのは、定期的な計画の見直しである。絶えず「計画=見通し」は変化していくので、最新の状況に応じたアップデートを、プロジェクト途中に定期的に行うのが良い。そうすることで、見積もりとのブレが広がらない早い段階でトレードオフの話をできるからだ。ウォーターフォール開発だとリリース直前に間に合わなくなってしまい、土壇場で調整するはめになるケースが少なくない。見積もりの変更を恐れずに、早い時点で手を打つからこそ調整の余地も多くあるのだ。

 また、ここでのプロダクトオーナーの役割は、スタッフが「スケジュールを守らない開発チーム」という視線にさらされないように、周囲の理解を得るよう配慮することにある。

 「見直しを定期的なイベントに組み込むことで、『問題vs私たち』という立ち位置が実現する。スケジュールの見直しが悪いことのように思っていると、ユーザーや営業担当者が開発チームを一方的に非難する図式に陥りがちだ。そうではなく、プロダクトオーナーが率先して関係者全員に問題解決を呼びかけ、話し合うことで、前向きにプロジェクトを進められるようになる」


  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

バックナンバー

連載:【デブサミ2017】セッションレポート

もっと読む

All contents copyright © 2006-2017 Shoeisha Co., Ltd. All rights reserved. ver.1.5