社会インフラを支えるようなシステムは、システムアシュアランス等で求められる高信頼性を確保・維持するために開発時には膨大な数の検証で発見した不具合を徹底的に潰し、保守時には莫大なコストをかけたメンテナンスがなされていることが多い。
しかし、近年のシステムの大規模化・複雑化に伴い、考慮すべき劣化や故障のパターンが増えてくると、有限のリソース範囲内で優先順位をつけて効率的に開発・保守することが必要になってきた。
今回はこのような開発・保守の考え方の変遷を紹介しつつ、特にソフトウェアの開発・保守への適用可能性・課題を考えてみたい。
リスク把握先んずれば信頼性を制す
近年の信頼性確保の考え方が旧来と何が一番違うのかというと、それはリスクを事前に把握しその影響度や頻度を勘案した対応を行い、かけるリソースの最適配置を行うようになった点である。
かつての開発・保守は、劣化や故障に対して事後的な実証主義を取っていたと言える。例えば開発局面では、膨大なテストケースをすべて消化することを基本とし、欠陥の影響度に関わらず等しく徹底的に対策することが是とされていた。また保守局面では、システムの状態は関係なく一定時間経過後オーバーホールを行ったり、また壊れてからの交換や修理を基本とする対応が行われていた。
転機が訪れたのは、1980年代後半から取り組まれるようになった航空機のメンテナンス戦略を劣化・故障リスクを踏まえ決定する、信頼性中心保全（Reliability-Centered Maintenance, RCM）という考え方が現れた時である。RCMは他の産業にも多大な影響を与え、以後起こりうるリスクを事前に評価し、保守のみならず開発のリソース配分に活かしていく試みが行われるようになった。
背景には劣化故障対応ノウハウの蓄積とセンシング情報の進化
事前把握したリスク度合いを設計保守に活かすという考え方は多大な影響を与えたものの、RCMが広く様々な産業で実践的に使われるようになったのは、比較的近年のことである。その背景には、劣化や故障に関するノウハウの蓄積が進んだことと、システムの状態をリアルタイムかつ精緻に把握できるセンシング技術の発達があった。
例えば、石油プラントにおけるリスクベースのメンテナンス指針は、2000年代にアメリカ石油協会（American Petroleum Institute, API）によってAPI RP580/581としてまとめられたことで多くの企業が本指針を採用し、近年では指針の運用を支援するツール（DNV社Orbit, TWI社RiskWISE等）も多く提案されるようになった。
JAXAでは、高信頼性開発プロセス構築の取り組みとして、リスクベースの開発手法を実践している。開発の初期から全フェーズを通して定量的リスク評価・解析を行い、リスクの高い故障モードに重点化した開発リソース配分を実現することで、高信頼性なエンジンを短期間・ 低コストで開発可能となった。これまで蓄積した劣化や故障のノウハウを格納したデータベースと、それを使った故障モード解析ツールを支援環境として用意したことが、この高信頼性開発プロセス構築の成功要因とされている。
センシング技術をメンテナンスに活かす事例としては、航空機分野に先進的なものが多い。例えば、機体に光ファイバーを埋め込み、機体の僅かなひずみをブリルアン散乱光として計測する技術の研究が三菱重工業主導で行われている。人の目だけでは捉えられない微妙な機体の劣化を把握しメンテナンス対応に活かすことで、保守コスト低減や機体の信頼性維持の面で高い効果があると期待されている。
また、既存運行中のシステムにセンサを取り付けるため技術として、損傷記憶スマートパッチといった汎用性が高く低コストな技術も提案されている。就航中の船体の長寿命化がコスト戦略上重要となる船舶分野などでの活用が期待される。
ソフトウェア開発・保守にみる「先」の課題
以上のような信頼性確保のための事前リスク把握のあり方は、宮本武蔵の五輪書で言うところの「3つの先」になぞらえると、以下のような形式があると見ることが出来る。
- 先の先・・・劣化故障リスクを事前に評価し、開発リソースの最適配置をすること（JAXA 高信頼性開発プロセス等の事例）
- 先々の先・・・劣化故障リスクを事前に評価し、保守リソースの最適配置をを行うこと（API RB580/581等の事例）
- 後の先・・・起こった小さな劣化故障を見逃さず対応をとり、影響拡大を防ぎ全体としての信頼性を維持すること（リアルタイムセンシング等の事例）
リスクベースの開発・保守最適化は、保守ノウハウの蓄積量があったこと・リスクの把握が比較的行いやすいことから、建造物や機体といった物理的な構造体を扱う分野で発展している。一方で、ソフトウェア開発・保守においては、「3つの先」のいずれもまだ発展途上と言えるだろう。
ソフトウェアの故障・劣化は、物理的な寿命から来るものではなく、ソフトウェアへの要求の変化や将来加えられる改修による当初設計との乖離といった、予想がしにくい要素から発生することが多い。物理的な構造体を扱う分野とは、事前リスク把握のあり方がこの点で大きく異なる。
先ずは踏み出してみなければ始まらない
とは言え、ソフトウェアにおいても、リスク把握が全く出来ないわけではない。障害情報やプロダクト指標、プロセス指標を蓄積し分析していけば、自身の組織でどのプログラムやサービス、開発経緯に注意しなければならないかが見えてくる。必ず障害がここに起こると予測することは難しくとも、開発や保守の優先順位をつけるための情報は十分得られることが多い。まだ情報を蓄積していない場合でも、GoogleのBug Predictionなど、障害リスク把握のノウハウをツール化した事例等を上手く活用すれば、素早くリスク把握を行うことも可能だ。
組織的に「3つの先」を行うには、機先をとるためのリスク把握の仕組みを整えることに加え、把握したリスク情報をふまえて「先」をとる意識改革が必要となる。大規模開発や旧来システムの改修では、すでにリスクを把握できる情報がありながらも、開発・保守リソースの旧習に縛られ適切にリソース配分されないケースが多い。また、開発自体に手一杯で、システム不調時に人の手による代替策に気が回らないといったケースもありがちである。
仕組みの整備や意識改革は、マネジメント層や開発チーム、運用保守チームが連動して始めなければ意味がない。今後のソフトウェア開発・保守はQCDの要求が一層高まっていくと予想され、DevOpsで叫ばれるように開発と運用保守の連携も必須となってくる。ソフトウェアの開発・保守はつい日々の業務に追われがちになるが、機を見てリソース制約に対抗する「先」を考えてみてはいかがだろう。