通信制御ソフトウェアのアジャイルを活用した開発

ネットワークイノベーションセンタ ネットワーク制御ソフトウェアプロジェクトでは、ネットワーク制御システムの基盤技術の研究やオープンソース開発を行っています。近年は同プロジェクトのメンバーも参画しているオープンソースソフトウェア OpenStack Tacker⁽¹⁾を活用した通信システムの仮想化（NFV^*1）における仮想化制御機能部（MANO^*2機能）のソフトウェア開発に取り組んでいます。
MANO機能のような通信制御ソフトウェアの開発は規模が大きくなりやすく、ウォーターフォール⁽²⁾が比較的適しているのですが、今回のMANO機能開発においては、後述する理由からウォーターフォールとアジャイルとを組み合わせた開発手法であるウォーター・スクラム・フォールを採用しました。
本記事では、ウォーターフォールとアジャイルの違い、現在取り組んでいるウォーター・スクラム・フォールとその開発状況についてご紹介します。

ソフトウェア開発手法は一般的にウォーターフォール、アジャイル、プロトタイピング、スパイラル...等複数存在します。これらのソフトウェア開発手法は完全に独立しているわけではなく、部分的に採用したハイブリッド手法をとることもできます。ウォーター・スクラム・フォールはウォーターフォールとアジャイルを部分的に組み合わせたハイブリッド手法となっています。

ここからはウォーター・スクラム・フォールの基となっているウォーターフォール、アジャイルの概要を紹介し、その後ウォーター・スクラム・フォールを説明していきます。

従来から利用されているウォーターフォールは要件定義や設計を先に明確化し、その後製造、試験と順番に進める開発手法です。早期に開発対象を明確化でき、その後の製造・試験工程では開発状況を評価しやすい利点がある一方、要件定義より後の工程で要件変更する場合、変更を決定した時点の工程より前の工程すべての見直しが必要となるため、手戻りの負荷が大きくなる傾向があり、柔軟性に乏しいという欠点があります。

アジャイルはウォーターフォールの欠点である柔軟な対応に応える開発手法を指しています。ただし、柔軟な要件の変更に伴い継続的な開発を行うために、開発完了時期や成果物のゴールも変動する点がウォーターフォールと異なります。
アジャイルは以下の４つの価値観⁽³⁾に基づいており、これらを実現するために複数の開発手法が編み出されており、それらから選択及び組み合わせ（もしくは新たな手法を考案して）開発します。

代表的なアジャイル開発を実現する手法に、スクラム、エクストリーム・プログラミング、カンバン、リーン、クリスタル等があります。

ここでは、アジャイル開発で多く採用されており、かつ、ウォーター・スクラム・フォールに関係するスクラムについて、簡単にご紹介します。
スクラムは開発期間を短く区切って進める開発手法です。区切った開発期間をスプリントと呼び、通常のスプリント期間は１～４週間単位です。ウォーターフォールとは異なり、開発対象の全ての要件を決めるのではなく、開発するソフトウェアのうち優先する機能を見定め、開発を進めます。具体的にスプリントは以下のように進みます。

1. 開始時に優先して開発する機能の要件定義・設計・製造・試験の計画を立て開発を進め、スプリント完了時点の成果物をリリースする。

2. 完了時に開発進捗確認や改善点を振り返ることで、全体の開発に要する見積期間の調整や問題の早期発見につなげる。

3. 開発完了となるまで1,2を繰り返す

要件変更への柔軟な対応のために、スプリント総数は固定ではなく、変更する場合がありますし、開発期間が定められている場合には予定していた機能のうち優先した機能のみのリリースで開発完了とするケースもありえます。

ウォーター・スクラム・フォールについて説明する前に、MANO機能の開発前の状況から、なぜMANO機能の開発ではウォーターフォールおよびアジャイルがそれぞれ採用しづらかったのかを紹介します。
開発着手前の時点で、MANO機能は大規模な通信制御ソフトウェアとなる見込みであり、お客様へのサービス提供時期がある程度決まっていました。更にMANO機能はETSI^*3 NFV/O-RAN^*4 Allianceの標準化に準拠した機能を目指しており、開発着手後の標準化動向等によって要件が変動する可能性がありました。したがって、お客様にサービス提供できる機能・品質でのリリース時期が定まっているため、要件の変動に対して継続的に開発とリリースしてソフトウェアをアップデートしていくアジャイルが採用しづらい一方で、要件変動がありうる標準化に準拠した機能を目指す点でウォーターフォールも採用しづらい状況でした。
このような状況から、MANO機能の開発では早期に開発着手し、開発期間中の変動する可能性のある要件を許容しながらも品質の高いソフトウェアのリリースを目指して、変動要件に対応するためにアジャイルを、品質を確保するためにウォーターフォールを、開発工程に応じて変えるウォーター・スクラム・フォールを採用しました。
また、アジャイルを一部採用することで、オープンソースソフトウェア(OSS) OpenStack Tackerの開発期間中のバージョンアップに対して柔軟に対応できるという利点もありました。

ウォーター・スクラム・フォールとは、開発工程の序盤・終盤をウォーターフォール、中盤をスクラムで進める開発手法です。工程の区切り方に定まった決まりはなく、MANO機能開発では、ウォーターとして要件定義・基本設計を、アジャイルとして要件変動時の要件定義と基本設計の修正・詳細設計・製造・単体/結合試験を、最後にフォールとして総合検証を実施しています。

スクラム期間中の標準化に関連する要件の変動は許容するので、ウォーター期間中はベースとなる要件のみを要件定義・基本設計でユーザ側と認識合わせできれば問題ないとして、早期にスクラム期間を開始でき、ベースとなる要件を開発するためのスプリント回数を多く確保することや品質改善のための期間を設けることができます。また総合試験することで最終リリース前にソフトウェア品質を担保できます。

現在もMANO機能の開発は継続しています。開発する中で、通信制御ソフトウェアのウォーター・スクラム・フォールにおいての課題がいくつかありました。現在もそれら課題に対処し、品質・開発進捗の低下が発生しないよう取り組んでいます。ここでは、ウォーター・スクラム・フォールを適用したMANO機能の開発で発生した課題についていくつか紹介します。

MANO機能はシステム全体が大規模であるため、ウォーター期間の基本設計で見積もった規模から、MANO機能を複数のサブシステムに分割しサブシステム単位の開発チームを編成しました。
当初定めた開発チームのまま開発が完了できればよかったのですが、スクラム期間中に変動要件に伴うサブシステムの規模拡大があり、ソフトウェアリリース時期が決まっていることから、該当サブシステムの開発メンバーを増やし、その開発チームをさらに分割することにしました。分割する際、基本設計でサブシステムの仕様が決まっていたため、既に設計書があり製造を進めている中で、該当のチームをサブシステムのどの機能部ごとで分けるべきかを改めて議論する必要がありました。
通常のスクラム開発の場合、各スプリント期間で個々の機能部を設計していくため要件変動に伴う規模拡大の判明以降のスプリントで追加開発メンバーや担当する機能部を検討・編成でき、既にある設計書で決まったチームをどう再編成するかの議論は起こりづらいです。また、通常のウォーターフォールでは変動要件は0として進み、規模の見積りは大きく変動しないので改めてチームをどの機能部で分割するかの議論は製造工程以降では発生しないと考えられます。
なお、現在はチーム再編成の議論を経て、比較的規模が大きいサブシステムをさらに分割し2チーム化して開発を進めています。

アジャイルの4つの価値観にある通り、アジャイルではドキュメントよりも動くソフトウェアを優先しますが、通信制御ソフトウェアとしてMANO機能をサービス提供するためには、高品質なドキュメントが最終リリース時点で必要になります。MANO機能の開発ではシステム開発チームとは別にドキュメント専任チームを編成し、ドキュメント作成を開発と並行で試行錯誤しながら進めています。
ドキュメントには二種類あり、一つ目は製造・試験前に作成する要件定義書と基本設計書で、二つ目は製造・試験後に作成するマニュアルと手順書です。製造・試験後に作成を進めるマニュアルと手順書については開発チームから試験で実施した手順等をそのままドキュメントチームへ情報共有するために情報の漏れが起こりづらいですが、製造・試験前に作成している要件定義書と設計書に製造・試験工程を通して修正が発生する場合、開発チームから要件定義書や設計書の修正箇所や内容を明示的にドキュメントチームに伝える必要があるため漏れが発生しやすいと考えています。
また、要件定義書と設計書はドキュメントチームの修正にかかる負荷が高いことから、品質向上に時間を要すると考えています。時間がかかる要因は、要件定義書と設計書はウォーター期間に作成しているドキュメントであるため、スクラム期間中の要件変動に応じて修正範囲が大きくなることと、要件定義書と設計書の修正は手順と異なり実機で試した確認をドキュメントチームができないことの2つがあると考えています。
現在も情報共有チェックルールの制定等で改善を続け、ドキュメント品質の向上に努めています。

MANO機能のウォーター・スクラム・フォールにおいて、総合試験は終盤での実施であり、スクラム期間ではサブシステム単位での製造、単体試験、結合試験の実施であるため、それぞれのサブシステムの観点で製造や試験を実施していました。そのため、開発当初は総合試験するために必要なそれぞれのサブシステムの機能の開発進捗や詳細設計がずれていて、試験実施の計画からの遅れや詳細設計への手戻りが発生したり、システム全体での確認が必要な性能試験や障害発生時のシステム切替においてサブシステム間の認識齟齬が発生したりしました。現在は、総合試験を見据えて、横通しで認識を合わせるためのドキュメントを用意し、各サブシステム担当者からの意見を集約し整理して進めています。

この記事では、ウォーターフォールとアジャイルの違い、ウォーターフォールとアジャイルのハイブリッド手法を適用した通信制御ソフトウェアの開発について紹介しました。今後もMANO機能の開発を継続し、お客様の通信環境を支える機能のリリースに向けてプロジェクトのみんなで頑張っていきます。また、開発対象のMANO機能の詳細な技術に興味がある方は、是非技術ジャーナルの記事をご覧ください。⁽⁴⁾

^*1 NFV（Network Function Virtualization）: ネットワーク機器を汎用サーバ上でソフトウェアとして実装する技術

^*2 MANO（Management and Orchestration）: NFVにおいて、ネットワークサービスやリソースを統合的に管理・制御、最適化する機能

^*3 ETSI（European Telecommunications Standards Institute）: ヨーロッパにおける情報通信技術の標準化組織

^*4 O-RAN（Open Radio Access Network）: オープンな無線アクセスネットワークの標準アーキテクチャ規定

(1) OpenStack Tackerによるネットワーク仮想化基盤システムの研究開発 | NIC Tech Talks

(2) 開発手法と品質管理について | NIC Tech Talks

(3) アジャイルソフトウェア開発宣言

(4) 無線アクセスネットワーク（RAN）運用管理のインテリジェント化を実現するコグニティブ・ファウンデーション（CF）連携基盤技術