みなさまこんにちは、ヤマト と かげろうです。
私たちが所属している部門では、ソニーミュージックグループに所属しているメンバーが、社内業務を『効率よく』処理するために必要な業務アプリケーションの開発・運用を行っているのですが、2024年度より、外注する範囲を再度検討し、開発・運用プロセスの改善をすることになりました。
この連載では、具体的にどのような取り組みを行ったかをご紹介できればと思います。全3回を予定していますので、ぜひ最後までご覧ください！
取り組み全体の概要
そもそもの背景
私たちはソニーミュージックグループの基幹となるシステムの多くを開発しているのですが、ソニーミュージックグループ特有の業務の複雑さがあり、システムにも独自の仕様が求められるため、開発はスクラッチ方式で行っています。
2023年度までは、最初の要求分析や最後の受入テストは社内で行うものの、その間の要件定義～システムテストは外部ベンダーに依頼することが多くなりがちでした。このやり方にはリソースの節約やスピード感を持った開発が可能になるなどのメリットがあるものの、外注する範囲が広いため外部依存度が高く、さらにコストがかさむといったデメリットも存在します。昨今、IT人材の単価が上昇していることを考慮すると、なるべく外注する範囲を抑えたいというのが実情です。
そんな事情もあり、2024年度は部門方針・指針として、以下の2点が掲げられました。
▶基本方針
- 既存業務の効率化、コスト削減
▶活動指針
- 外部依存脱却、自力を鍛える
目的設定とチーム構成
前段で述べた部門の方針・指針に則り、課題を解決するための活動の一環として、V字モデル（下図）において当社が担う範囲を1層目から2層目まで広げること、そして業務効率化・品質向上の観点も考慮して、リリース計画や運用面も含めて見直すことにしました。
まずは部門内のメンバー21名が要件定義チーム、システムテストチーム、リリース計画チームの3チームにわかれ、各チームで現状の課題を整理し、解決策を検討しました。その上で、進捗報告や相談事項を月に一度の全体ミーティングで共有し、他チームの意見を吸い上げながら活路を見出していくということを約1年かけて行いました。
連載の第1回となる今回は、「要件定義チーム」の取り組みに関してご紹介したいと思います。
要件定義チームの方針設定
方針とゴールを定義
これまで外部ベンダーに依頼することが多かった要件定義フェーズを社内で将来実施していきたい、という部署の方針に対し、最初に私たちのチームが立てた問いは「要件定義を自ら進めるにはどのような方針と手段が必要か？」でした。
幾度かのミーティングを行い、以下のように方針とゴールをまとめました。
▶方針
- 社員が要件定義を適切に行えるようガイドやプロセスをドキュメント化する
- 担当者の経験による品質のばらつきを是正する
- 一般的な要件定義をベースとしつつ、当社のルールに合わせた観点で取捨選択する
- スクラッチ開発を主なターゲットとする
▶ゴール
- 要件定義のマニュアル作成およびプロセス定義を行い、社内Wikiにまとめる
- 外部ベンダーが設計作業以降手戻りなくスムーズに着手できる、高品質な要件定義資料を作成するための評価シートを作る
活動計画を立案
方針とゴールを踏まえ、2024年度末までに成果を挙げられるよう必要なタスクと実施期間を考え、1年間の活動計画を以下のように立てました。
次のパートでは、この1年間で要件定義チームが行った取り組みをご説明します。
要件定義チームの昨年度1年間の取り組み
①基礎知識の学び直し
「進め方・課題検討」のフェーズでは、まず今までシステム開発のプロジェクトマネジメントを行っていた中で生じた課題について、チーム内で整理しました。
その結果、そもそも要件定義について何を実施するかが明確でなく、担当者の知識や理解に依存していたため、精度にばらつきが生じ、開発中の追加要件や稼働後のトラブルが度々発生していることがわかりました。そこで私たちは、一度基本に立ち返り、書籍やインターネット、社外研修を元に一般的な要件定義について学び直して資料化しました。
これにより、個々のメンバーが体系化した要件定義の知識を習得できました。
②協力会社との作業分担を明確化
開発全体における要件定義の位置づけを理解するため、開発の全工程を説明した資料を作成しました。合わせてRACIチャートについても、プロジェクトの基本的な責任範囲をシステム部署、利用部署、外部ベンダー、運用会社に分け記載しました。
さらに、専門用語や社内用語など、システムを開発する上で業務の理解に必要な用語をまとめ、異なる領域の人との話を円滑にしたり、プロジェクトに素早く参画したりできるようにしました。
③開発の各プロセスで必要な資料の明確化
過去のシステム開発において各外部ベンダーからどういった資料が納品されたかをリスト化しました。外部ベンダーによって納品資料には微妙に違いがあり、当社としてどの資料の作成が必要かを明確化すべきだということがわかったためです。
そして、これを受けて要件定義の各プロセスにおいてどの資料の作成が必要かを明記したリストを作成しました。これにより、要件定義資料の作成漏れによる遅延を減らすことが期待できます。
④要件定義資料のサンプルを用意
要件定義の資料作成の助けとなるサンプルイメージの選定を、過去に外部ベンダーから納品された要件定義資料から行いました。これにより、要件定義の経験がない、もしくは浅い担当者であってもできるだけ自力で要件定義資料を作成できるようにしました。
⑤評価シートの作成
外部ベンダーや（将来的には）自社が作成する要件定義の各資料（要件定義書、業務フロー図、概念データモデル…）の妥当性を、社内で一定の基準以上で評価できるようにするための評価シートを作成しました。
【評価シートの例（要件定義書の場合）】
- 評価シートの説明
- 評価項目（確認ポイント）
今後は、この評価シートが実際に要件定義資料の作成に活用できるか検証する予定です。
⑥自社システムの運用環境を外部ベンダーに共有
システム開発を行うにあたって要件定義を自社で行ったとしても、その後の設計以降の工程を担うのは外部ベンダーです。そこで、外部ベンダーがスムーズに業務に取り組めるよう、自社システムの運用環境を改めてまとめました。
具体的には、自社システムの運用環境を改めて社内Wikiで一覧化し、外部ベンダーに共有しました。
主な記載事項は以下の通りです。
・AWS環境
・ワークフロー
・データ連携周り
・帳票関連
・ジョブ管理(JP1)
・セキュリティポリシー
これにより、ベンダーに自社システム環境の情報共有を開発初期に漏れなく伝えることができ、開発途中の確認や手戻りを減らすことができると考えています。
おわりに
1年間要件定義の社内推進に取り組んでみて大変だったのは、限られた時間の中でゴールを定め、要件定義について学び、外部ベンダーの意見を取り入れつつ、社内に受け入れられるレベルで各種ドキュメントを作成することでした。その実現に向け、要件定義チームでは週次で定例を開くなどして個人のタスクを細かく調整し、1年間でしっかりとした成果を出すことができました。とは言え、こうして作りあげた各種ドキュメントが、実際に使えるものになっているかの評価はこれからです。
また、いきなり全ての開発の要件定義を自社で実施するのは人員や時間の制約から、負担が非常に大きいです。そのため、以下の3つにパターン分けを実施し、プロジェクトごとに当社側が担う範囲を明確化しながら、段階的に移行していく予定です。
- 要件定義は外部ベンダーが行い、確認は自社で行う（今まで通り）
- 業務要件定義を自社で行い、システム要件定義を外部ベンダーが行う（最終的なチェックは自社で行う）
- 全ての要件定義を自社で行う
作成した成果資料を改めて読むと、要件定義をきちんと進めるためには数々の伝達事項や評価項目があることがわかります。今回のような取り組みなく、過去の経験や断片的な資料の共有のみで滞りなく要件定義を実施するのは大変なことだと実感しました。今後は、本資料のテスト運用を行って資料を改善し、社内での要件定義実施という目標に引き続き取り組んでいきます。
次回はシステムテストチームの取り組みを紹介します。リリース計画チームの取り組みと要件定義チームのこれから（2025年度）の話は、第3回で取り扱いますので、今しばらくお待ちいただければと思います。
ここまで読んでいただき、ありがとうございました！
