みなさまこんにちは。株式会社ソニー・ミュージックエンタテインメント（以下、SME）のやまと、ユタ、ゆまです。
前回の記事のおさらいになりますが、私たちが所属している業務アプリケーション開発・運用を行っている部門では、2024年度に既存業務の効率化・コスト削減の基本方針を掲げ、「要件定義」・「システムテスト」・「リリース計画」の3チームに分かれて開発工程の見直しを行いました（詳細は連載の第1回目をご確認ください）。
各チームの担当者がリレー形式でその取り組みを語る本連載、第3回目となる今回は「リリース計画・総括編」と題してリリース計画チームの活動と、最後にSMEとしての今後の計画についてご紹介します。
そもそもリリース計画とは？
みなさんは、リリース計画と聞いてどのような工程を思い浮かべますか。そもそも、「リリース計画」と「リリース」は何が違うのでしょうか。
「リリース」とは開発したシステムを公開しユーザーが利用できるようにすること、「リリース計画」とはリリース当日やリリース後に問題が起きないようにあらかじめ用意することです。つまり、「リリース計画＝リリースするときの実行計画、かつ、リリースしてからのシステム運用計画」ということになります。即ち「システムを開発・運用する」 のは「リリース前後を計画・実行していく」とほぼ同義ということです。
このことからもシステム開発・運用において「リリース」が重要な工程であることが分かっていただけると思います。では、具体的にシステムをリリースするにあたって何を計画する必要があるでしょうか。
リリース計画の中には、「移行」「運用保守」「効果測定」「マニュアル整備」「リリース」の５つの計画・実行と「リリース判定」が含まれています。前回までの記事で語っていた要件定義やテストは「移行」の計画にあたります。
実際にシステム開発をしたことのある人の中には、開発工程やテスト工程が終わった段階から、これらの要素を検討し出すという方も多いのではないでしょうか。しかし、より安全に、スケジュール通りにシステムをリリースするためには以下の図のように要件定義や設計の段階から計画を練る必要があります。
リリース計画チームの取り組み
先の段落で解説した前提を踏まえ、私たちのチームの取り組みとして、以下のゴールとそれに向けた活動計画を設定しました。
▶ゴール
SMEとして理想的なリリース計画の作成・実行を先導できるようになることをゴールとしました。
▶活動計画
1年間の活動計画を以下のように立てて活動を行いました。
その上で私たちは、チームをリリース前とリリース後に分割。リリース当日までのフェーズを「リリースチーム」、リリース後以降のフェーズを「運用チーム」として活動を行いました。
次のパートでは、2024年度に 「リリースチーム」と「運用チーム」の2チームで行った取り組みをご説明します。
1年間での取り組み（リリースチーム編）
- 一般的なリリースとSMEとしてのリリースの比較
システムのリリースにおいては、各個人の経験に頼っている部分があり、リリース手順書やリリースの判定基準も担当者によって差異があることがリリース当日やその後のトラブルの原因になっていました。そのため、まずはデジタル庁の標準ガイドラインから一般的な「リリースとは」について学びました。
次に、一般的なリリースと比較した結果として、現状のSMEに不足しているマイナスの部分とSMEとしてが独自に実施しているプラスの部分を洗い出し 一般的なリリースと比較した結果として、現状のSMEに不足しているマイナスの部分とSMEがとして独自に実施しているプラスの部分を洗い出し 、SMEの特性も含めたリリースの標準化を実施しました。
これにより、リリースについての品質が担保され、トラブル時の対応やリリース後の運用等での想定漏れがなくなることを期待しています。
（参考：デジタル社会推進標準ガイドライン｜デジタル庁） - リリース手順書・リリースチェックシート（リリース判定）整備
リリース手順書の標準フォーマットを作成し、1. で検討した項目に沿ってフォーマットを作成することに加え、リリース計画に必要な運用保守/効果測定/マニュアル整備 といった事前に確認が必要な要素についても項目として追加しました（リリース判定については、過去に作成されたものの運用されてなかったリリースチェックシートが存在していたため、現在のシステム構成に沿った形で見直しを実施）。
また、今回作成されたドキュメントがきちんと運用されるように、ドキュメントの更新ルールや運用ルールの検討を行いました。
これにより、経験の差によるトラブルを防ぎ、外部ベンダーにスムーズにSME のリリース標準を展開できるようになることを期待しています。また、実運用まではできませんでしたが、今回整備した運用ルールをもとにドキュメントが運用されるフローが構築されることを期待しています。 - ドキュメント運用方法整備（社内Wikiに記載）
社内Wikiにリリース計画やリリース判定に関する考え方や今回の活動で作成したドキュメント、運用時の利用方法やルールを記載し、まとめました。これにより、リリースについての認識の共通化を図り、リリース当日やリリース後のトラブルを未然に防げるようになることを期待しています。
この1年のリリースチームでの活動の中で、当たり前だと思っていたことが意外とSME独自の考え方やルールであることに気づきました。独自のルールを再認識するとこで、外部のベンダーとの認識差異もなくなるのではないかと思いました。
また、昔同じような活動を社内で行っていた痕跡があったのですが、今回の活動前はそのこと自体を知らなかったので、ルールを決めることよりもそれをどう運用にのせていくかが大切だなと思いました。
1年間での取り組み（運用チーム編）
- 「リリースに伴う運用」を整理
リリース時に「開発」から「運用」へ引き継ぐための「運用設計」として、運用ドキュメントを整備する必要があると判断しました。 社内で運用ドキュメントについての標準化がされていなかったので、デジタル庁の標準ガイドラインとその別紙に用意されていた「運用計画書」「運用実施要領」というドキュメントから運用ドキュメントのあるべき姿を学びました。
-
「運用計画書/運用実施要領」の記載項目と現状の運用ドキュメントの比較
既に運用しているアプリケーションの運用ドキュメントが十分かどうか、そして、①で学んだ「運用計画書」「運用実施要領」にSMEのアプリケーションを運用するにあたっての必要な情報が揃っているのかという2つを確認するために、以下の観点で比較を行いました。
・ 「運用計画書」「運用実施要領」の項目にあって、SMEではドキュメント化していない項目
・ SMEの運用上では必要な内容だが、「運用計画書」「運用実施要領」にはない項目
比較を行っていく中で、年次の浅いメンバーからすると、運用ドキュメントが「存在していない」のか「見つけられていない」のか、見つけたとしても、そのドキュメントが「最新の情報なのか」が分からないという現状を知り、「運用設計」のドキュメント標準化を進める前に、今ある運用ドキュメントの管理について取り組むべきだと考えました。 - ドキュメントが「あるのか」「どこなのか」「正しいのか」が分かる状態を目指して検討
運用ドキュメントのあるべき姿として、新任の担当でもすぐに正しい情報にたどり着けて、楽に担当間の引継ぎが行える状態を目指して検討を行い、施策として、以下を実施しました。- 社内Wikiで「運用計画書」「運用実施要領」を基にした アプリ共通のテンプレートを用意
②で比較した結果のSMEで必要だと判断した項目を目次とし、ページにはドキュメントの内容を直接記載するか、ドキュメントのリンクを置くことを想定したテンプレートを作成しました。 - アプリケーションの一覧を整備し、俯瞰して見るべき情報のみに絞った項目への変更を検討
運用ドキュメントの適切な管理場所を整備していく中で、上記のページで個別のドキュメントとして管理すべき内容がアプリケーションの一覧の中で管理されていたので、俯瞰して各アプリケーションを横断して見るべき情報のみを一覧として管理するように検討しました。
- 社内Wikiで「運用計画書」「運用実施要領」を基にした アプリ共通のテンプレートを用意
各アプリケーションの運用ドキュメントを調査した際に感じたのは、アプリケーションによってフォルダの構成もファイル名も異なるため、とても探しづらいということです。
アプリケーションライフサイクルの大部分を占める、運用についてのドキュメント管理がルール化されていないために、担当引継ぎの際などに無駄な時間を要していたのです。これはトラブルの原因にもなり得るので、ルールを整備し、それに基づく管理を継続的に行っていく必要があります。
今回の取り組みでそうした現状を知り、後回しになってしまいがちなドキュメントの管理を積極的に行っていくことが重要だと気付けたことも成果の1つだと考えています。
リリース計画チームのまとめ
私たちリリース計画チームは、SMEの現状の実態に沿って細かく段階を設定し着々と消化しながら、「リリース」「運用」の2つのチームで「結果を出す」ことを強く意識して今回の活動を進めてきました。
結果、具体的かつ実用的なドキュメントと現状に沿ったルール整理ができたのではないかと感じています。ただ、2024年度の活動では実運用に載せるところまでは実現できませんでした。
今後、取り組みの成果を実運用に載せていくために、まずは作成したドキュメントが廃れないためのルールの作成・体制の構築が必要だと考えています。また、作成したドキュメントの使用方法などのルールの周知も必要だと考えているため、2025年度も引き続き活動していきたいと思います。
連載の総括とこれからの展望
2024年度は、社内業務アプリケーションの開発・運用における効率化とコスト削減を目指し、要件定義、システムテスト、リリース計画の3つのチームに分かれて取り組みを実施しました。この1年間の活動を通じて、以下のような経験と成果を得ることができました。
＜得られた経験及び成果＞
- プロセスの標準化
これまで個人の裁量でプロジェクトを進行していたため、プロジェクトごとに成果物やテスト内容・リリース計画として定める内容が不揃いでしたが、各々が感じていた課題を明確化し、そちらをドキュメントやプロセスを社内Wikiにまとめることで、情報の共有と標準化をすることができました。 - 開発プロセスの理解
要件定義～リリースするまでの工程について、1から学びなおすことで理解不足な部分を補い、そちらを社内Wikiにまとめることで、今後新規に当部門に参画するメンバー含めてSMEとして各開発プロセスにどう関わるべきかを学べるようにしました。
上記のような経験・成果を得る途中で、困難な場面もありました。今回のチーム編成自体、年代や担当範囲もバラバラだったため、そもそも抱えている課題自体も三者三様です。そのため、それぞれの課題に対して共通理解を持ったうえで解決策を練る必要があり、想定より時間がかかることもありました。また、解決策を練って今回対応したものの、数年後には使われなくなってしまうという懸念もあったため、形骸化しないように将来を見据えて今回作成したドキュメントや社内Wikiの運用ルールも検討する必要がありました。
2025年度は、2024年度に各チームが作成したものを統合して不整合がないかをチェックしつつ、積み残した課題の整理・対応を実施し、2026年度から実際の業務で利活用できるように整備を進めています。2025年10月からは実際にいくつかのプロジェクトでパイロット的に利用してもらい、完成度をあげていく予定です。
今回の取り組みを通じて得た知見やドキュメントが活かされつつ、育っていき、今後のソニーミュージックグループの成長にシステム部門として寄与していくことを期待しています。
最後に
システム開発においては、当人の技術や経験とは別に、参画したチームやプロジェクトごとに異なるローカルルールの把握も重要です。SMEでは今回の連載でご紹介した、業務アプリケーション開発におけるSMEとしての関わり方をWiki化するなど、新規メンバー向けのコンテンツも整備・充実させることで、混乱なく開発に参加していただけるよう工夫しています。
経験が豊富な方はもちろん、そうでない方でも活躍していただける職場ですので、ソニーミュージックグループのビジネスをIT分野から支えることに興味がある方、お待ちしております！ 一緒に働ける日が来るのを楽しみにしてます!! それではまた！
