開発マネージャ必見！ 基幹システム"講談社流"ハイブリッド開発、成功の秘訣とは

基幹システム開発の課題とハイブリッド開発のアプローチ

　小山氏の所属する講談社は、主力事業である紙・電子の出版ビジネスとライツ（著作権の二次利用）をはじめ、メディア事業（広告収益）、さらには出版関連以外の新規事業など、多岐にわたる事業を展開している。出版業界がデジタル化やグローバル化への急速な変革期を迎える中、ユーザーニーズに迅速に応えるための新たな基幹システム開発が同社でも求められ、開発マネージャとして抜擢されたのが小山氏だった。

　当時について小山氏は、「出版業界が急速な変革期に突入する中、7年ほど稼働していた現行システムが業務の変化に対応しきれず、近い将来ビジネスの足かせになるという懸念があった。また働き方改革、つまり生産性の向上という課題も浮上していた。そのためにも現行システムを刷新し、ユーザーニーズに対応できる体制を迅速に整える必要があったが、一般的に基幹システム開発でアジャイルの導入は難しいとされていた」と振り返る。

　アジャイルが基幹システム開発に向かない理由として、小山氏は「複雑なロジックや他システムとの連携があり、品質の確保が難しい」「予算・納期の管理が難しい」「アジャイル開発ではドキュメント作成が最低限に抑えられるため、保守への引継ぎが難しい」という3つを挙げる。一方で、従来のウォーターフォール開発にも、「ユーザーニーズを十分に汲み取りきれない。また、仕様変更による手戻りが発生することで、プロジェクトの長期化を招く恐れがある」というリスクがあったと話す。

　そこで小山氏が思いついたのが、企画や要件定義の工程ではウォーターフォール、開発部分ではアジャイルを適用し、結合・総合テストや導入の工程では再びウォーターフォールの手法を用いるという「ハイブリッド開発」だった。アジャイル、ウォーターフォールそれぞれの課題を打ち消し、メリットを掛け合わせることで、ユーザーニーズを的確に反映しつつ、迅速な開発サイクルの実現を可能にするわけだ。

　プロジェクトの体制は以下の通りだ。まず業務部門には、業務マネージャとしてプロダクトオーナー（PO）を設置。このPOは、開発部門のマネージャー（PM）である小山氏の補佐を受けながら、プロダクトバックログの最終決定などを行う。

　一方で開発部門には、小山氏を支えるスクラムマスター（SM）が1名と、SM補佐が2名に加え、テックリードと開発メンバーがアサインされた。この体制は「ほぼ内製化に近い形」であり、同社のニーズに合わせた柔軟な対応を可能にしたという。

　小山氏がPMとしてまず取り組んだのは、プロジェクトの企画書／計画書づくりだった。混同されがちな両者だが、「それぞれの役割や作成時期は大きく異なる」と小山氏は話す。

　まず企画書は、プロジェクト開始前に作成されるものであり、プロジェクトの背景や目的、必要性を経営層にも理解できるレベルで記載したものだ。このタスクでPMが意識すべきは、「プロジェクトの背景と主要業務課題を明記する」「プロジェクトの目的とゴールを正確に記載する」の2点である。

　企画書に関して小山氏は、「背景と課題を明確にすることで、プロジェクトの意義が共有され、後に問題が生じた際にも的確な対応が可能となる。また、目的とゴールは定量的に書くことが重要だ。例えば『システム導入により生産性を20％向上させる』といった具体的な目標を設定しておけば、仮に問題が発生した場合にも、別の手段をすばやく模索できる」と説明する。

　一方の計画書は、プロジェクト開始後に作成され、具体的な進め方を定義するドキュメントだ。主に実務者が参照するため、基本方針や進行方法、スケジュール管理、スコープ管理、コスト管理などが含まれることが望ましい。

　小山氏によると、このタスクで重要なのは、「プロジェクトの基本方針を明確にする」「アジャイルとウォーターフォールの境界線を定義する」の2点だという。基本方針を書いておくことで、要件定義の工程などでユーザー部門とコンフリクトが起こっても、良い落としどころが見つけられる。また、ハイブリット開発ではアジャイルとウォーターフォールの境界が曖昧になりやすいため、ドキュメントで明確に区切ることで、メンバー間の混乱を防げることが可能だ。