モバイル装置の開発手法の基本① 〜開発工程編〜
NFV(クラウド技術)の導入やモバイル内の信号のREST化によって、モバイル装置の開発とWeb系の開発の境界が段々薄くなってきているように感じる。ETSI NFVやO-RANでもCloud-Native (ETSI GS NFV EVE 019) やCICD (ETSI GR NFV TST 006)という話が出てきたり、OpenStackやKubernetes、Free5GC、O-RAN SCというOpen Sourceを(部分的でも)利用したり、リファレンス実装として仕様調整として参考にされたりしており、従来のような専用装置を開発する開発スタイルから変わりつつある。
一方で、モバイルサービスの特徴そのものは変わっていないので、開発で求められる要件は変わっていない。今回は、変わりつつあるテレコムの開発スタイルを横目で見つつ、モバイル開発の基本とその特徴について書いてみたい。
モバイル装置を開発する上での基本的要件
モバイルネットワークの保守運用の基礎にも記載している通り、モバイル装置は各国で法規制がありつつ、目標SLA 99.999％(年間停止許容時間5分程度)を目指した様々な運用条件や保守要件がある。Web系システムの場合は目標SLAを99.9％(年間停止許容時間9時間弱)と設定していることが多いので、この目標SLAの違いがそのままシステム設計の基本原則や運用条件の違いとして染み出してくる。
また、モバイルサービスは、2G、3G、4Gがそれぞれ10年近くサービスを提供し続けている通り、同一サービスを長期間提供し続ける必要がある。モバイルサービスは、多くの場合途中でのサービス追加などを求められることはなく、安定した通信を値上がりすることなく継続利用できることが求められる。
この、目標SLA99.999％を実現することと、10年単位でのサービス継続のために、各モバイルオペレータやベンダは様々な開発ノウハウを保有しており、それらに基づいてこれまで開発してきた。また、日本の場合は総務省が「電気通信事故検証会議」として毎年その年の通信事故の検証結果を報告書としてまとめており、その中に再発防止策や教訓が記載されている。最新の取り組みは電気通信事故検証会議の報告を参照するとして、各モバイルオペレータが取り組むべき品質改善策の全体像については、少し古いが総務省の「多様化・複雑化する電気通信事故の防止の在り方に関する検討会」の中の第4回参考資料2がまとまっている。
モバイルオペレータは、3GPPが提案している標準仕様をベースに、上図のような大きく3つの要件や条件を考慮して開発していることになる。
- 日本の法律：重大事故の基準をベースとした、モバイル装置として対応が必要な様々な設計や試験のガイドライン
- 運用条件や保守条件：日本の法律を遵守するための、各モバイルオペレータが積み重ねた再発防止策やメンテナンス条件
- 開発ノウハウ：ソフトウェアバグや工事ミスを最小化するための、各モバイルオペレータが装置ベンダの設計や試験の品質管理指標値や観点表
これらはWeb系の開発手法を取り入れたとしても、現時点では変えることができないモバイル装置開発の要件となる。これらをベースに、モバイル装置を提供するためには3つの側面に分けて設計試験を行うことになる
- モバイルサービス(呼処理)を提供するための装置
- その装置を運用するための保守装置
- モバイル装置を実現するためのネットワークやハードウェアなどのインフラ装置
モバイル装置開発の全体像
一般的にソフトウェアを開発する場合、解決すべき課題を明確にした上で、その課題をソフトウェアで解決するためのシステム(What)と、それを作るための開発工程(How)を明確にして、チームで開発していくことになる。どのような対象のシステム開発でも、どのような開発工程を採用したとしても、各設計段階のアウトプットや工程間の比重が異なるが、外部設計→内部設計→詳細設計→製造→単体試験→結合試験→総合試験という作業は必要となる。
特にモバイル装置は1つのモバイルサービスを追加・変更するだけでも関連する装置の種類も数も多く、更に新旧装置が混在した環境でサービスを継続提供できるように開発する必要があるため、モバイル装置の開発は大規模なチーム開発になる傾向が強い。そのため、サービスレベルの外部設計は当然重要となるが、同様に装置間の機能分担やIF条件も重要となり、多くの場合開発工程にウォーターフォール型を採用する傾向が強かった。特にモバイル装置の外部設計においては、呼処理は他事業者のネットワークとも接続(ローミング)する必要もあることから、複数のオペレータやベンダで外部設計をした方が効率が良いこともある。そこで、外部設計やIF条件は3GPPなどの標準仕様を利用することも多い。
モバイル装置開発における外部設計
モバイル装置の外部設計においても基本的には解決すべき課題の明確化が非常に重要であり、それを様々な方法で設計している。特にモバイルサービスは10年という単位で利用することから、長期スパンを見越した課題の明確化が重要となり、そのための定型手法はなかなか存在しない。そのため、最近のモバイル装置の外部設計は、標準化団体を利用してモバイルオペレータやモバイル装置ベンダが共同で設計を行うようになってきており、各企業が様々な手法や研究を通して見つけた課題をUsecaseという形で提起しつつ必要機能を精査したり(Stage1)、長期安定的に利用できるようにアーキテクチャを定め必要な装置の機能要件を決めたり(Stage2)、各装置の接続のためのIF条件を検討したり(Stage3)するようになってきている。標準化団体においてこのような標準仕様を作ることで、モバイルオペレータやモバイル装置ベンダは外部設計における“課題“の明確化や“インタフェース“規定というコアな部分に対して、標準仕様を利用することができるようになる。
その上で、モバイルオペレータはそのオペレータ独自の“課題“を追加で解消したり、各国の法規制やSLAなどの“条件“に従って冗長性や障害耐性を追加で設計したりする。こちらもなかなか定型手法は存在せず、一般的なビジネスツールで課題を発見したり、商用での運用経験からバリューチェーン分析で解決すべき課題を明確化するなど、様々な検討が必要となるだろう。
このように定められた解決すべき課題をもとに作るべきシステムを設計するが、ここでも既存装置に追加・変更する(差分開発/派生開発)か、新規装置を導入するか(スクラッチ開発)という大きな判断と設計が必要となる。
差分開発であれば、条件や開発ポリシーは基本的に既存踏襲となり、解決すべき課題の明確化とそのために変更が必要なインタフェース条件の設計がメインな外部設計となる。しかし、新規装置の場合は10年という長期間装置を維持できるように“開発ポリシー“を検討することで、性能や品質を守りつつ拡張性を維持できるようにする必要があり、途端に開発難易度が大幅に上昇する。
このように、モバイル装置は解決すべき課題をベースにインタフェース、各種条件、開発ポリシーを外部設計として設計することで、何のシステムを作るか(What)を明確化しつつ、外部設計やIF条件を重要視した開発工程(How)によって開発を進めることになる。これらの外部設計によって呼処理を提供するモバイル装置を設計しつつ、そのモバイル装置を商用で利用するための保守装置やインフラ装置も同じように外部設計を行なっていくことになる
(参考)モバイル装置におけるアジャイル型開発の可能性
従来のモバイル装置の開発においては、ウォーターフォール型の開発手法がとられてきたが、最近はアジャイル型の開発手法が叫ばれ始めている。モバイル装置におけるこれらの開発手法は大きく分けて2つに分類できるだろう。
- ウォーターフォール型： 大きな課題を解決するために、全ての工程を順番に実施していく
- 品質の向上手法の違いとして、プロトタイプ型開発(事前にプロトタイプを作成することで開発上の課題を事前にチェックする)、スパイラル開発(ウォーターフォールを何ラウンドか実施することで大枠から設計をして詳細を後から設計することで全体の品質を上げる)などがある。
- 大きな課題を大量のチームで一気に開発することは向いているが、開発中に課題が変化したとしても対応できない。そのため、保守装置のような課題が変化しやすい場合には課題が解決しきれないことがある。
- アジャイル型： 課題をサブ課題として分割することで、それぞれのサブ課題単位で小さく短期間の開発を行う
- サブ課題の分割手法やそれぞれの小さな開発の実現方法で、アジャイル(開発体制を固定し開発可能なボリューム単位にサブ課題を分割)、DevOps(サブ課題を運用しながら発見)、CICD(サブ課題の解決のためのフレームワークを開発環境と商用導入まで自動化する)、MVC(プロダクトの変化のタイミングが異なる部分で分割)などがある。
- サブ課題化と各小さなチーム毎のアウトプットを正規化できれば課題の変化に柔軟に対応できるが、サブ課題が膨大に増えると各コンポーネント間の整合性をとるところに大きな時間がかかり逆に品質低下や開発の長期化が起きる。
現状の開発手法や開発環境を踏まえると、モバイル装置は複数の装置を並列で開発し、最後それらを繋いで対向試験や総合試験をする必要があるので、基本的には複数の装置間で開発のタイミングを合わせやすいウォーターフォールが引き続き採用されるケースが多いだろう。
コメント
コメントを投稿