ソフトウェア・シンポジウム2017 in 宮崎

パッケージ製品におけるソフトウェア保守情報の活用事例
加藤 英之
東芝ソリューション株式会社

増井 和也
ソフトウェア・メインテナンス研究会ージョンが 1999 年にリリースされてから，ライセンス契
テムは，単一法人向けとして人事・給与機能のみの初期バ

要旨

約数を拡大しつつ 18 年余りになろうとしている（図 1-1）。

開発が済んだソフトウェアは，システム上で稼働を開始

すると，ある種のソフトウェア保守 1)対応が必要となる。

稼働中ソフトウェアへのこの保守対応（含む利用者サポート）は，利用者にとって無償か有償かに関係なく，稼働がして 30 年以上となる事例もある 2) 。保守対応の間で得ら終了するまで何らかの形で継続する。その継続期間が時とれる情報は，処理機能の操作等の Q&A，クレーム，要望，障害情報(事象，原因，回避策，再発防止策等)，修正版リリース情報，保守作業のための運用停止情報，修正に伴う仕様・設計 ・プロ グラム・テス ト仕様・作業エビデン
ゆる 5W1H 情報を含み，多岐にわたる。ソフトウェアの開ス・承認過程など，1 件の保守対応にもさまざまで，いわ図 1-1

発完了時の完成文書が完成時点の状況を示す比較的均一

本体製品のメジャーバージョンは現在 V6 である。初版

で静的な情報であるのに比べ，保守対応情報は時間軸を持より現在まで，グループ企業を統括する複数法人対応の強った動的でかつ多様な情報の集まりといえる。

化，基盤技術や動作可能環境の最新化など，大幅な内部設契約顧客数の推移(1999-2016)

これらの情報には，システム，ソフトウェア，人間系の計更新は複数回行っている。また，企業等の人的資源管理問題や障害といった瑕疵情報を含み，その量や種類の多さの周辺業務をサポートするオプションサブシステムの製品レパートリの拡張も継続して行っている（図 1-2）。現は一般的にシステムの信頼性のあるべき姿から誇らしいことではないとの認識３)がある。そのため，保守対応情報

在のオプションライセンスサブシステムは，従業員の教育は社外への開示はもちろんのこと，社内の他部門への開示も統計処理した一部データを除き，生の個別保守情報（特ラーニング，人材育成など計 9 のオプション機能を持つまに恥かしい事例と印象付けられるようなもの）が積極的にでに進化している。

管理，能力・目標管理，タレントマネージメント管理，e-開示されることは少ない。
本論文は，パッケージ製品の顧客別アドオンソフトウェ
ア保守専任チームが管理する保守情報を，外部への開示は制限しているものの，厳重なセキュリティ権限管理や顧客との機密保持契約遵守の下，可能な範囲で部門間共有を積極的に行い，さまざまな効果が出ている事例を総括的に報告するものである。

1. 対象ソフトウェアシステムの概要
本論文の対象システムは大規模企業グループ向け Web

ベースの人財管理パッケージシステム 5) である。対象シス

図 1-2 対象システムのサブシステム拡張（進化）

67

SEA

ソフトウェア・シンポジウム2017 in 宮崎

なお，多様な業種に広がる顧客企業等の業態や勤務形態している。

4. 対象システムのソフトウェア保守体制にきめ細かく対応するため，顧客の求めに応じ，個別アドオン機能のライセンス提供の提案と契約締結により顧客別アドオン開発・導入を行う場合がある。アドオンソフト

製品本体及び各オプション製品単位に保守担当チーム
ウェア契約自体は，個別顧客の導入効果や利用満足度の向ムが別にある（図 4-1 参照）。以下，アドオン保守統括チがあり，また顧客別のアドオンを束ねて保守する担当チー
上及び本製品提供側の売上増となり，双方にとってメリットがある。

ームが保守情報をどう活用しているかを中心に報告する。
しかし，製品及びアドオンのそれぞれのソフトウェアを併せた場合は，製品のみの導入に比べ，保守対応の困難性ンアップ，PC（端末）の OS やブラウザなどのアップグレが増す。たとえば，対象システム製品のメジャーバージョードなど，周辺環境の変化に個別保守対応が必要となった場合が発生する。アドオンソフトウェアの保守対応を円滑に提供していくには，製品・アドオンの各機能ソフトウェア間の関連を確実に制御できる高度なソフトウェアの保守対応やソフトウェア構成管理技術が必要となってくる。
本論文は，対象システム製品の保守情報管理を通じて保（注）HW:ハードウェア，OS:オペレーティングシステム，MW:守対応の活用事例および課題とその対策について述べる。
また，このアドオンソフトウェアの保守対応も対象に含

図 4-1

ミドルウェア，PKG:パッケージ製品めて述べることにする。

対象システムの保守体制のイメージ図

5. 保守情報管理システムの概要

2. 対象システムの規模と顧客保守契約

現在，本管理システムには対象システムの全製品，アドドオン部分，本製品特化した保守作業ツール等を併せ， 1現状の対象システムの規模は，製品本体部分，顧客別アオン機能に関するインシデント対応情報やそれに問い合る。これまでの登録件数の推移を図 5-1 に示す。

わせに回答するための情報が約７万件超が登録されてい千万行を超える。なお，この行数はコメント行も含めて数えている。
顧客が本製品を導入する場合，本体ライセンス費及び，必要とするオプションライセンス費，アドオン機能提供費を支払う。また，その後の保守費として導入した部分に対応する年間保守費が発生する。しかし，製品戦略上，主要パッケージ製品 6) の保守サービス費よりも抑えられた保守契約になる傾向がある。さらに既存顧客が今後の IT 予算計画立案を行う際には，当該顧客から保守費減額交渉要
図 5-1

求が発生することが珍しくない。

3. 対象ソフトウェアの保守発生状況

保守情報管理システムの登録件数推移

シデント情報の検索画面，検索で絞り込んだ情報の CSV

本管理システムの主な機能は，登録画面，登録済みイン出力機能などがある（図 5-2 参照）。

対象システムで発生する保守事案（以下，インシデントと呼ぶ）の情報は，保守情報管理システム（以下，単に本JIS X0161 で定義された保守プロセスで入出力されるデー管理システムと呼ぶ）に登録する。登録保守情報の範囲は，タや情報だけでなく，製品の仕様・動作環境・顧客情報・一部営業情報，アドオンの機能，操作，制限，注意点，事例，追加・改良見積もりなどの問合せ情報に関するものなども含む。本管理システムは，インシデント情報の登録自体が最終目的ではなく，問合せに対する回答を行う場合に，
図 5-2

本管理システムの過去の問合せを検索することで，ワンストップで回答や対応の情報にたどり着けることを目的と

68

保守情報管理システムの画面イメージ

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 6-1

務用 PC で行う。利用上の制限は，ログイン画面の表示が出力した情報の加工は，CSV ダウンロードした側の業

保守情報管理システムで管理する主な項目一覧

ロックアウト機能をもつパスワード管理され，登録 ID か許可されたドメインに限定されている。また，ログインはつ適正なパスワード以外は利用ができないか，権限によって検索範囲が制限される。また，誰がどんな操作をしたかのログも取られている。

6. 保守情報管理システムで管理する項目
本システムで管理する主な項目を表 6-1 に示す。特に，で，各種派生資料（含む CSV 出力後の加工資料）の更新
顧客が現在利用している製品リリースバージョンは重要にも注意を払っている。顧客別製品構成管理情報が別にあると，インシデント情報以外の資料も相互に閲覧が必要になり，必要な確認作業が増加する。

7. 本管理システムの情報管理者と入力者
本システムへの登録（初期入力）は，ヘルプデスク，顧ものが 90%以上である。その他全国にいる営業担当者，受客から直接入ってきた情報を登録する保守担当者による注前提案 IT 技術者等が登録する場合がある。また，回答や再質問のような追加情報入力は，それぞれの回答担当者や回答を受けた側が行う。
なお，回答や対応のやり取りは，きめ細かく迅速に行う
が，クローズは特に急がない（早期クローズを最大目標とするようなことはしない）。インシデントのクローズ（完了）の目的は「終わったことにしよう」と安心や達成感を与えるものではなく，必要なインシデント対応記録を漏れなく記録できたことを十分確認できたことを証明するためのものと考えている。そのため，いったん追加入力は収まったが，何年かして，不再現の現象が再発して，追加現象発生情報の入力がなされることも珍しくない。クローズされていると（もう済んだインデントだから余計なことを（表 7-1 参照）。

しないという）情報入力の漏れの発生リスクが高くなる

また，たとえクローズ状態でも，クローズ案件を除外しなければ，検索対象から外れることはない。また，クローズ状態から非クローズ状態に戻すことや，クローズ後の入力も特に制限なく可能としている。滞留残件（非クローズインシデント）数の増減のみで一喜一憂するようなソフトウェアの保守作業品質の管理発想は，結果的に必要な保守記録をすべて記録しようとする努力を阻害することになり，保守対応プロセスとしての成熟度は高くないと考えている。

69SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 7-1

インシデントの早期クローズのデメリット8. 保守情報の活用事例(課題と活用効果)（課題２）保守対応の終わりが不明確。やって当たり前の（課題１）緊急事態に常に対応できる専任体制は保守コス
世界で業務アピール度が低いト増大のリスクがある。
（対策２）重大インシデントが発生すると営業部門や品質（対策１）顧客から保守サービスの費用対効果の向上（コ保証部門が客先窓口になって対応する必要が発生するこスト低減とサービス向上の両方を進める）を求められる。
とも珍しくない。この場合，保守対応チームは社内においコストの多くは緊急障害に備えた体制維持に多くが取らても，フォローを受けるチームの中心となる。また，障害れる。緊急障害の発生予測精度を高めるため，過去インシ解消に向け目覚ましい活躍をしても，その評価はやって当
デント情報（情報精度が高いことが前提）を分析し，事前たり前というものが多い。特に大きな部門として，開発組に対応準備をしておく。レビジョンアップ後のデグレード
織と一緒の場合，顧客，営業部門，品質保証部門から見た（機能低下），顧客担当者の異動に伴う不慣れ，顧客端末とき，そのような障害を発生させた責任追及がメインとなＰＣ環境の変化，季節的な利用機能の変動など，過去に発り，努力不足または対応能力が低い要員が対応した場合に生した構成の変更・変化後のインシデントの発生傾向をは復旧不可能であった障害を，素早く復旧させた保守対応分析し，緊急インシデントの防止対策（事前に判明した障能力（技能）に対しての評価を受けることが少ない。
害や利用制限のアナウンス，障害発生時の利用者対処方法，保守担当者が開発の一員（障害を起こした犯人）と見ら障害を防止する運用方法や設定変更のアナウンス，初心者れ，そのような不当な評価を受けることがないよう，過去が間違いやすい操作の事例紹介，対応の事前準備。）を検Mean Time To Repair の短縮，予防保守による障害発生数のの障害対応の平均工数，復旧までの期間の短縮（MTTR:トを抑えるようにする(図 8-1)。

討し準備することで発生コストの計画を行い，予定外コス削減（MTBF: Mean Time Between Failure の伸長）の傾向のデータを本管理システムから採取・分析した。そして，従来の同様の障害に対して，どれだけ少ない工数，短い時間で解消できたか，予防保守で同種障害を過年度に比べどれだけ少なくできたかをアピールすることを心掛けた。
さらに，この他に月単位，半期単位，経年で総インシデントの集計，分析を行い，インシデントの状況とオプショ
図 8-1

ン製品の保守契約開始の関係等，営業部門への情報提供を
保守情報の活用例１：今後発生するインシデント行い，既存顧客の営業活動重点分野を決める参考にしてもの予測精度向上
らう。また，インシデントの時系列分析（顧客別，全顧客）結果と，インシデント対応残件状況報告の定例会開催を顧客に提案する。この時，営業や提案ＳＥも同行を調整し，70SEA

ソフトウェア・シンポジウム2017 in 宮崎

顧客部門から次期予算の提案計画などを構想段階から話の作業が発生。モチベーション向上が困難

ちに最適な提案を提供できる可能性が高くなる(図 8-2)。ま（対策４）緊急事態の発生は，本来計画的に作業をするこ

た，製品に対する顧客の評価や製品やサービスの課題もタては，教科書にもポジティブに書かれることもなく，悲惨イムリに話を聞くことができ，製品やサービス改善を顧客で計画的でない作業に感じることが多い。特に，緊急対応志向で進めることができるようになった。の経験が浅いソフトウェア技術者にとっては，障害対応優題として聞くことができ，準備を行い正式決定されたら直とが是として教育されてきたソフトウェア技術者にとっ先という大きなプレッシャーを感じながらの作業をつらく感じることもある。
一方，中堅クラス以上の技術者の場合は，早期の障害解消対応を求められるだけでなく，障害の原因や再発防止策の報告書の原稿作成対応を迫られる。また，自身が原因でない場合でも，利用者，顧客，営業部門，品質保証部門から厳しい叱責を受けなければならない立場となる場合がある。
このような場合も，本システムに蓄積されている障害対
図 8-2

保守情報の活用例 2：保守作業の価値アピールに応記録から最適と考えられる対応プロセスを関係者で選択，共有，対応することで，対応の進捗の同一認識と対応

活用作成物の本システムへの登録で，報告資料の定型部分の流用（文章部分のコピペはご法度）ができ，進捗可視化が可能となる。結果として，次にすべことや対応に苦慮する場（課題３）保守作業の作業環境改善という名目での予算合の相談先が明確になり，対応ミスが減る。以前の類似障化・調達には困難が伴う害対応に要した期間や工数に比べ早く・安く・確実に対（対策３）製品の競争力を高めるための機能強化調達予算応できたことを実感できるようになり，障害対応作業にお化は承認されやすいが，一般的に保守対応コストの削減，いても達成感やチームワーク感を得られるようになり，メンバの士気が向上した(図 8-4)。

保守サービスのタイムリさ向上，保守担当者の作業負荷低減の体制強化など，保守作業整備を達成するための調達予算をあらかじめ入れておくことが難しい場合がある。特に企業業績が思わしくないときはなおさらである。
そこで，本管理システムから，インシデント対応工数やコストデータを分析し，インシデント対応で費用対効果が一番高い調達先や内製対応した時との比較，現行の体制で達が必要な根拠を示すことができるようになった(図 8-3)。のバックログの増加状況をデータで示すことによって，調たとえ，今期予算がなく，新たな調達が難しい場合でも，図 8-4

これらのデータから来期の予算確保の裏付けデータとして活用ができるようになった。

保守情報の活用事例４：保守要員のモチベーション向上に活用

9. 管理システム運営上の課題と対策
9.1. 担当者の初期入力と情報更新の負担感
本管理システムは，インシデント対応や各種問合せ対応の記録が必要十分に行われてこそ意味がある。たとえ，10
図 8-3

万件近い保守対応記録があったとしても，それらの入力内保守情報の活用例３：保守作業改善の予算化に活容にばらつきや重要な記録項目の入力に漏れがあると利用用価値が小さくなる。

（課題４）障害が発生すると緊急の原因調査・報告・謝罪

そのためには，重い緊急障害対応（入力する時間がない）

71

SEA

ソフトウェア・シンポジウム2017 in 宮崎(図 9-2)。

や逆に取るに足らないと感じたインシデント対応（こんなアピールし，コストの問題を削減していこうとしている

些細なことはいちいち入力する必要を感じない）の場合，入力自体を強制されるとソフトウェア技術者にとっては大きな負担感を感じることが多い。
それを解消するため，入力を個人の作業義務として位置付けるのではなく，定例保守打ち合わせ時に，各担当から必要事項を報告し，互いの状況を共有する。突然参加したメンバには無駄や退屈と感じることが多いが，それは保守る(図 9-1)。

チームの一体感がないことから発生すると動機づけをす
図 9-2

保守技術者の仕事は担当割り当てを受けて，誰ともコミコスト問題への対応

ュニケーションをせず，ひたすら対応する個人プレーの仕

9.3. 製品統括責任者の役割事ではない（過去対応事例を効率的に活用した保守プロセスの理解）という認識を持ってもらうようリーダが指導する。入力を誰かに任せ（振）れば，もっと短い会議時間に本対象システムの製品の収益を統括する責任者は，新規なると考えるのは，結局保守情報が共有されず，情報内容
導入顧客の増加によるライセンス収入，既存顧客の保守料の不正確さ，陳腐化，活用の形骸化の要因となりやすい。
収入が主な収入となる。保守料収入は安定的な収入と考えられるが，新規導入顧客のライセンス収入はどうしても変動が避けられない。そのため，期初には保守コストを抑えて，本来保守費として計画している以上の利益を出し，変動が避けられない新規ライセンス収入が下振れしても利益予算達成が可能になるようにすることになる。保守コストを抑えた計画を立てることにより，期初に発生したインシデント対応への臨時調達も含めた手厚い対応が手薄になる可能性がある。ソフトウェア保守部門が独立していれば，そんなことはできないはずであるが，現状はソフトウ
ェアに関する部門は販売・開発・保守も一緒になっているケースが少なくない。
図 9-1

このような場合も，本管理システムを活用している営業
インシデント棚卸ミーティングのイメージ担当者の活動状況の把握や実際の状況を知るための連絡を取り合い，プロスペクト（受注見込み案件）の受注可能9.2. コスト障壁性のリアルな状況を入手する。また，営業活動にも顧客から顔を知られている保守チームのメンバが積極的に協力

予定外コストの多くはクレームや緊急作業依頼の対応し受注活動支援も行い，結果として製品統括責任者の防衛により発生する。クレームや緊急作業依頼は，客先からだ的対応を防いでいる。

けでなく，社内の営業部門，提案ＳＥのほか，品質保証部

10. 結論門，セキュリティ統括部門，知的財産部門，その他監査部門などのスタッフ部門からも来る。
これらの対応記録も本システムに登録し，過去どのようソフトウェア保守作業やその作業から発生する記録情な対応をして，どういった対応課題が発生し，どうすれば報は多くの場合，隠される傾向にある。しかし，そういっ効率よく対応できるかのノウハウを蓄積するようにする。
た保守情報は顧客満足度，顧客サービスレベル，製品品質
そして，営業担当者や別システム提案者が顧客訪問する前状況，弱点対策分野絞り込み，周辺分野の製品開発参考デに，当該顧客のインシデント情報，最近インシデント対応ータなどに有効で貴重なデータである。本論文では対象と状況を閲覧することを関係部門と調整することで，保守チなるパッケージシステムで管理している保守情報の内容ームの存在価値を高め，営業や提案ＳＥにファンや理解者とその活用方法・課題等について説明した。ソフトウェアを増やし，保守チームへの体制強化や作業改善の提案の味
保守チームがこの情報を管理し，営業部門，提案部門，品方になってもらうよう働きかける。
質保証部門，開発チーム，パッケージ保守チーム，ヘルプ
さらに，顧客が設定する運用系パラメータや開発経験のデスクチームなどと共有することにより，次のビジネス拡ない他の製品のアドオンソフトウェアの保守も第三者と大に的確につながる糧の一つとなることは間違いない。
して保守担当を引き受けることを行い，コストメリットを72

SEA

ソフトウェア・シンポジウム2017 in 宮崎

そのためには，保守情報をネガティブにとらえず，入力，開示をためらう発想を捨てる。開示された側も問題を起こしたことに対し，責める側の立場に回ることで，自分に責任がないことを強調するような未成熟な対応に終始しない。
その前提で，保守対応に関連するチームや組織全体がよ関係部門間や顧客との連携が強まり win-win の関係を築きり組織能力向上に向けた保守情報の活用を考えることで，上げることができる可能性をソフトウェア保守情報は秘めていることが，本論文から分かった。

参考文献
1) JIS X160:2012 ソフトウェアライフサイクルプロ
セス (ISO/IEC/IEEE/EIA 12207;2008 の一致規格)
2) ユーザ企業ソフトウェアメトリックス調査 2014
第 7 章 保守調査 日本情報システムユーザ協会
3) ソフトウェア開発データ白書 2016-2017 9 章「信頼性の分析」 IPA
4) ソフトウェア開発プロジェクトの生産性評価に関する事例 佐藤浩明 Unisys Technology Review
第 129 号 2017 年 9 月
5) http://www.toshiba.co.jp/cl/sol/gene/6) http://www.oracle.com/jp/corporate/pricing/e-pl101005-101005a-n-176288-ja.pdf
7) ソフトウェア開発データ白書 2016-2017 3 章「分析について」 IPA73

SEA