コニカミノルタとしてのオフィス向け複合機の製品開発は2004年の統合第1世代機より始まり、2022年現在は第6世代機の製品開発および機能のバージョンアップを進めている。本稿では、その製品開発の中でも開発規模の大きく複雑化したコントローラー制御部のソフトウェア開発における、品質向上に向けた様々な取り組みの歩みと成果を紹介する。

　オフィス向け複合機は、コピーを中心とした様々な画像処理や用紙印刷を同時に実行する製品の総称であるが、製品化を重ねる過程の中で、複合機として求められる役割や機能は大きく進化した。

　大きな変化点は、製品として取り扱う画像処理がアナログからデジタルへ技術革新したことである。それまで紙の原稿を用紙へ複写（コピー）する単機能しか実現できなかったアナログ世代から、電子化された画像を扱えるデジタル世代へ移行したことにより、Fig.1のように、オフィス内のPCからのデータを受信印刷するPCプリント、電話回線経由でのファクス送受信、電子メールなどで電子画像を送信するネットワーク送信、製品内部のストレージに画像データを保存するボックス保存、保存した電子画像を各種形式へ変換する電子ファイル変換、といった様々な機能が実現可能となった。それらを１台で複数の機能実行を可能とするオフィスにおける複合機として、製品としての多機能化が加速的に進んだ。

　これに伴い、製品を操作するユーザビリティーも進化を遂げた。初期製品は小サイズなモノクロ表示の操作画面だったが、搭載機能の増加により操作画面のカラー表示や機能選択のビジュアル化を行い、さらにフリック操作やポップアップ表示、機能階層構造の並列化などを施した直感的な操作画面の提供を行った。現在の統合第6世代機では、多機能化によって複雑化した操作性より脱却するため、フラットデザインによるシンプル化・アイコン化や、ユーザー毎に好みな操作ボタン配置のカスタマイズを行えるパーソナライズ対応について取り組んでいる。

　また、製品として外部へ接続するためのネットワーク技術への対応も加速した。ネットワーク送受信・PCプリントに必要な通信プロトコル群、IEEE802.11/Bluetooth/NFCなどの各種インターフェース、モバイル連携規格対応、3rdベンダーを含む外部ネットワークサービスとの連携を図るアプリケーション・インターフェース提供などが対象であり、常に最新のネットワーク技術を取り込みながら、複合機と外部ソリューションサービス商材とのハイブリッドな価値を提供している。同時に、利用ユーザーを識別するためのユーザー認証技術、外部ネットワークからの悪意ある攻撃を防ぐネットワークセキュリティー技術、これら最新技術を取り込むためのコントローラー制御OSの汎用Linux化、世界各国で要請される省電力規格へ対応するための製品起動・省電力制御技術など、多くの新規技術や機能を搭載した製品となっている。

　前章にて説明した経緯より、オフィス向け複合機におけるコントローラー制御部のソフトウェアは、その開発規模を拡大し続けており、現在の統合第6世代機における対象ソフトウェアのコード行数は2000万行を超えている。このような類を見ない大規模なソフトウェア開発を続ける中で、その品質の確保と維持は大きな課題となるため、我々は製品開発工程におけるソフトウェア品質向上のための様々な取り組みを行った。以下に５つの事例を紹介する。

（１）ソフトウェアを１つのプラットフォーム資産とした共通化開発 複数の機種開発を進める中で、開発環境を多重化せず規模抑制するために、１つのソフトウェアプラットフォームをベースに開発を進め、過去ソフトウェア資産をベースに機能を追加・修正する開発を実施した。弊害として、ソフトウェア資産全体の複雑度が増したため、潜在するソフトウェア不具合の密度は増加傾向となってしまった。

（２）ソースコードの複雑度を定期的に測定したリファイン活動 前項によるソフトウェア資産の複雑度の増加を抑止するために、対策基準を指標化して、ソフトウェア構造の見直し（リファイン）を定期実施した。主に、構成モジュールの依存関係を適正化するアンチパターンの緩和、巨大なファイルやクラスの分割、可読性向上を目的としたコンパイルスイッチの削減を進めたことで、モジュール独立性向上やケアレスミスの抑止につながった。

（３）製品開発とソフト追加機能開発の分離とアジャイル開発要素の取り入れ ソフトウェアとしての追加機能開発は、ウォーターフォール形式の製品開発とは分離して、定常的なアジャイル形式にて完成させた成果物をその時点の製品開発へ適用することで、追加機能開発の品質コントロールを図った。これにより製品開発日程への影響は軽減された。

（４）コーディングにおける静的解析ツールの導入と徹底 ソフトウェア設計における基準ルールをカテゴライズ・明文化し、静的解析ツールによるコーディングルール違反 箇所の検出を自動化、およびその修正の徹底を進め、ツールによる品質特性別の診断スコア化を試みた。

（５）製品化プロセスに同期した不具合修正のフロントローディングの徹底 ソフトウェア不具合は修正の難易度が高いものほど開発期間後半での修正に偏りがちとなり、修正によるシステム制御全体への副作用確認が不十分なまま製品化を迎えてしまうことがあるため、製品化プロセスとソフトウェア開発プロセスを同期させて、システム検証を開始するまでに主要な検出不具合を前倒しして修正（フロントローディング）することを徹底した。

　これらの取り組みにて、ソフトウェア開発の効率化、機能品質の向上、製品開発・評価日程の遵守には効果を得たが、ソフトウェア品質を可視化した品質指標からは継続的な改善傾向は見られなかった。

　ソフトウェア品質を示す指標のひとつとして、１件の不具合を検出するまでに要した評価時間を表すs-mtbc (software mean time between claim)を定義しており、コニカミノルタでは同値が30h以上を製品出荷可能レベルとしている。Fig.2の製品世代別の製品およびバージョンアップにおける品質指標値s-mtbcの推移が示すとおり、プラットフォーム変更を行った新しい世代のローンチ機種では、大規模なソフトウェア変更による品質指標値s-mtbcの低下が生じ、以降の機能バージョンアップにて品質向上を図る形を繰り返している。

　また、ソフトウェアの開発コード行数に対する不具合件数の密度を表す「バグ密度 (件/KLOC)」においても、Fig.3のように同様の傾向を示している。これは、プラットフォーム共通化によって１つのソフトウェア資産をベースにコード追加・修正を続けることで、ソフトウェア資産の複雑度が増して、潜在する不具合も徐々に増加していったためである。

　以上のことから、大規模なソフトウェア開発において、開発工程期間における品質向上の取り組みによる効果には限界があると考えた我々は、それより下流となる市場へ出荷されたあとの製品品質へ着目した。市場利用における製品品質の低下要因を的確に把握すること、それらに対して適切かつ迅速に対処を行うこと、が市場にて利用いただいている製品ユーザーの目線に即したもうひとつのソフトウェア品質向上に繋がるのでは、と仮説を立てて、統合第4世代機開発より新たな取り組みとして検討を開始した。

　最初に、市場へ出荷された製品を利用いただく際に、その稼働を停めてしまうことを品質低下要因として捉え、その分類を行い、Fig.4に示すように要因を4種に分類した。

　製品を直接停止させない「仕様と異なる動作」と、用紙JAMのような「復帰可能な異常で停止」の2種については、明確な識別が可能な要因であり、これまでの製品開発工程において製品仕様書と対比した機能評価を徹底することや、3章にて紹介した既存の品質向上の取り組みにて品質維持は可能であると判断した。

　致命的なトラブルによる「復帰不可能な異常で停止」と、ソフトウェア自体が停止したことによる「操作パネルロック」の2種については、発生要因が不定ゆえに機能評価での網羅的な検出による品質確保は困難であり、市場製品の品質低下を招く要因として対処が必要と判断した。しかしながら、これら2種要因の市場製品における発生状況を我々が正確に把握できていない実態も同時に認識し、市場製品の状態を定量的に把握して事実に基づいた対処を進める科学的なアプローチが早急に必要と考え、それらを実現する手段を検討した。

　１つめの「復帰不可能な異常で停止」については、市場製品の状況を把握するために、出荷された複合機の保守や管理を遠隔で行うコニカミノルタのシステムCustomer Support Remote Care (CSRC)の活用を進めた。

　Fig.5のようにCSRCではシステムに接続された複合機の各種カウンター情報の取得・蓄積、複合機からの異常状態の通知受信、複合機の設定情報の確認・変更をリアルタイムに行っている。その中の復帰不可能な異常を示す「トラブル」の検出カウンター・履歴などから、「１万枚用紙出力する間に検出するソフトウェア要因トラブルの回数」を品質指標として、その推移を可視化した。これにより市場製品の品質をリアルタイムに監視し、多発傾向なトラブルの定量的な可視化が実現できたが、２つの課題に直面したため新たな対策を行った。

（１）ソフトウェア要因トラブルの１要因1コード化

　定義されたソフトウェア要因トラブルの中にはその検出要因が複数存在するものがあったので、その検出要因を

一意に特定するために、すべてのトラブルの検出要因を固有のコードに定義して、CSRCより取得可能とした。

（２）原因箇所推定を容易にする原因解析情報のコード化

　トラブルの原因特定は、トラブルを検出した際のソフトウェア内部の制御遷移を示す解析ログの取得に依存しており、その取得には時間を要していたため、解析ログが示す原因に至るまでの制御遷移を数値化（コード化）し、CSRCより取得可能とした。

　これら新たなコード情報の収集によって、検出されたトラブルの要因の特定、その原因解析情報の同時入手、が可能となり、トラブルの要因ごとの分類と優先要因の修正を進めることで、対策したファームウェアの市場への早期投入を達成した。Fig.6が示すとおり、製品稼働を停めてしまうトラブルの検出率は、各製品世代におけるファームウェアバージョンが進むことで大きく低減した。

　２つめの「操作パネルロック」については、何らかの要因でソフトウェア自体が停止してしまい、製品としては操作パネルがキー操作を受け付けない状態（ロック状態）に至るので、遭遇した場合は製品の電源をOFF/ONいただくことになる。その状態の性質上、遭遇したかどうかがソフトウェア上では識別できない課題があったため、2つの対策を行った。

（１）停止した状態の検知

　ソフトウェア自体が停止してしまうと、製品として異常の検知と通知を行えないため、別の状態監視手段を組み込み、ソフトウェアの停止状態を検知したらソフトウェア復旧後にその検知結果を伝達する仕組みを搭載した。

また、検知結果はコードとして記録し、前述のCSRCによるコード収集対象とした。

（２）自動リブート処理の導入

　ソフトウェア停止を状態監視手段が検知したら、システム全体のリセット（リブート）を自動実行して、製品を継続稼働する仕組みを搭載した。なお、前述のソフトウェア要因トラブルの検出時も対象とした。

　これらにより、観測できなかったパネルロック検出のコードによる可視化と、自動復旧による製品の継続稼働を達成するファームウェアを市場投入した。

　こうして品質向上を図ったファームウェアの市場投入は進められたが、提供したファームウェアの市場製品の適用作業は、基本的に市場サポート要員が製品を直接操作して実施しているため、提供ファームウェアを市場製品へ速やかに適用できない課題に直面した。そこで、市場製品へリモートによる各種サービス提供するグローバルクラウドサービス基盤であるコニカミノルタのWW Remote Service Plat-Form (WWRSPF)にて、遠隔で任意にファームウェア適用するプロセスを構築し、統合第5世代機より運用を開始した。

　対策適用して品質向上したファームウェアの市場製品への早期投入を実現し定常化したことで、Fig.7の世代製品毎の出荷からのソフトウェア要因トラブル検出率の推移が示すとおり、現在の統合第6世代機では大きく改善しており、出荷初期より安定した品質維持を達成した。

　以上より、市場製品の状態を定量的に把握して事実に基づいた対処を進める科学的なアプローチは、市場製品からのデータより市場品質をリアルタイムで監視・定量的に可視化、多発要因の早期特定、対策適用ファームウェアの速やかな市場適用、を実現・定常運用したことによって、ソフトウェア品質向上に対して大きな効果を得た。

　このアプローチは、複合機のハードウェア領域においても成果を上げている。事例として、複合機におけるコントローラー基板の交換率改善を紹介する。

　複合機におけるシステム制御系部品の中で、コントローラー基板の市場交換率は全体の半数を占めていたが、後日調査した交換基板のハードウェア不良率は20%程度であることが分かり、80%は不要な部品交換を行っていたことが分かった。その原因は、ハードウェア異常の疑いが起きた際に異常個所の特定できないので、主要部品であるコントローラー基板を交換してしまう一時措置が定着してしまっていたためである。そこで、ハードウェア異常に対しても原因箇所を一意に特定・記録・通知する仕組みを徹底し、その異常部品を自動的に判定・通知する診断機能を搭載して市場製品へ投入したことで、統合第5世代機にて、市場ハードウェア品質の可視化と共に、不要な部品交換を約86%削減した。また、このような市場製品データの活用は、各製品の利用状況に応じた最適な部品交換タイミングを自動判断するPredictive Maintenance（予兆保全）にも展開されている。

　今後も市場製品より得られるデータの活用領域の幅を広げていくことで、製品の提供機能や性能を大きくトランスフォームさせることによる新たな価値提供の実現へつなげていく。