ソフトウェア保守 隠蔽の構造～なぜ，保守作業は隠されてきたのか？～

ソフトウェア技術者協会

SS2017

事例報告

ソフトウェア・メインテナンス研究会
増井和也(C) 2017 Masui, Kazuya . All rights reserved.

発表

要旨の組織を別したソフトウェア現場【現状】「開発」と「保守」の区分が不明
確で両者同一組織のソフトウェア現場
外からはカッコ良く見える「開発」部門。部門名に当然「保守」なんか入っていない。
ただ，実態は作業の多くが保守（既存ソフトウェアの調査・修正・機能などの改修関連作業）。
開発中心の部門イメージ維持のため，保守作業の一部または全部が恒常的に隠蔽される。
隠蔽理由：開発善／保守悪の古典的パラダイム，保守多い⇒開発能力低いと評価，etc
隠蔽の結果：開発担当の保守作業掛持ち（実態は保守が多）や保守担当の塩漬け（含むパートナ）。人員削減（開発予算に比べ要員が多すぎ）の話が出るたびに不安を感じつつ，黙々と保守作業対応。
隠蔽の弊害：全作業量に比べ少ない技術者配置となり，恒常的な高負荷状態となる。

【今後】 「開発」と「保守」

報告者の解決策↓
開発と保守の組織完全分離↓
・作り手は「作り」に特化
・直し手は「直し」に特化

官・学も開発指向で保守隠蔽に加担に？
(C) 2017 Masui, Kazuya . All rights reserved.

開発専任担当組織（開発プロセス担当）
要件・仕様が明確になったソフト
ウェア機能の作成を担当
利点：開発の成否が引継ぎで明確になる
保守要なら保守専任組織に引継ぐ

保守専任担当組織（保守プロセス担当）
既存ソフトウェアへの修正要求の調査・影響分析，修正設計，修正，適正修正かの確認テストを担当
利点：保守作業の存在明確化で保守の体系的改善が進む発表の順序
1. ソフトウェア保守の定義とスコープ
2. ソフトウェア保守の対応者数
3. ソフトウェア保守隠蔽の事例
3.1 今の研究・教育は保守を隠している？
3.2 今のIT振興施策行政は保守を隠している？
3.3 今の企業のIT施策は保守を隠している？
4. ソフトウェア保守隠蔽に走る構造
5. ソフトウェア保守隠蔽の弊害
6. では，どうすればよいのか?
6.1 開発と保守の組織を分離する効果
6.2 開発時の保守組織の役割
7. まとめ(C) 2017 Masui, Kazuya . All rights reserved.

１．ソフトウェア保守の定義とスコープ☆ソフトウェア保守を明確に定義した文献例
・ソフトウェア保守の国際規格
ISO/IEC 14764 Standard for Information Technology Software Life Cycle Processes – Maintenance（注）IEEEも上記規格を採用，日本でのJIS化済み(JIS X0161)☆本国際規格でのソフトウェア保守のスコープとタイプ分類
次ページ参照☆本国際規格によるソフトウェア保守プロセスの内容
次々ページ参照（注）この規格はどの保守タイプ（4種）でも同一保守プロセスをガイド(C) 2017 Masui, Kazuya . All rights reserved.

ソフトウェア保守の国際規格ISO/IEC/IEEE14764（JISX0161）における保守タイプ分類
既存のソフト
業務系，業種系，組込系， ウェアを意識
ソフトウェア保守パッケージ系等を問わず， することなくSoftware
すべて同じ保守タイプ分
ソフトウェア類を適用
Maintenanceの作業ができる場合は現状少ない。
訂正
改良
Correction
Enhancement↓
今のソフト
ウェア作業の完全化保守
適応保守
是正保守
予防保守
大半が，このPerfective
Adaptive
Corrective
Preventive
保守定義のどMaintenance
Maintenance
Maintenance
Maintenance
れかに入って将来に向けた保より価値を高め
発生後のバグ修正内部発見等のバしまう？

既存ソフトウェアへの対応は，対象や修正の規模の大小，瑕疵の有無等を問わず，すべてソフトウェア保守に含まれる（含む緊急保守）

グを先行修正るための改修等(C) 2017 Masui, Kazuya . All rights reserved.

守性向上改修等

ソフトウェア保守プロセス（JIS X0161）
プロセス実装 ①

この中で「影響分析」等を行う

修正結果が不適問題分析及び修正分析 ②

し支援プロセス
文書化，構成管理，品質管理，妥当性確認，監査，問題解決管理，共同レビュー

保守レビュー及び受入れ④

この中で「リグレッションテスト」等を行う

調整・承認が重要
修正の実施
廃棄

⑥③

修正作業部分（☆）

移行⑤

ソフトウェア実装（構築）プロセス☆ 修正作業は，ISO/IEC12207（JIS X0160）のソフトウェア実装（構築）プロセス（旧称：開発プロセス）の一部または全部を実行(C) 2017 Masui, Kazuya . All rights reserved.

プロセスの要点：
保守プロセスが上流で，構築(開発)プロセスが下流のプロセス↓
開発善／保守悪のレガシーパラダイムを堅持している人は，この考えは許せるか？

２．ソフトウェア保守の対応者数• 情報処理推進機構(IPA)の「エンタプライズ系ソフトウェア技術者 個人の実態調査 2008」：調査時点でソフトウェア技術者が新規開発プロジェク
トに参画していたのは36%のみ ⇒実態はさらに少なかった可能性も？
• 日本情報システム・ユーザ協会(JUAS)の「2014年ソフトウェア・メトリ
クス調査」: 保守専任者一人が担当できるステップ数の平均値は36.5万行⇒日本の既存ソフトウェア量から，保守専任者が何人必要なのか？
• JIS X0161(ISO/IEC 14764一致規格)には「保守はソフトウェアライフサイクルの財政的資源のほとんどを消費」とある。⇒世界中の既存ソフトウェアの量から，いったい何人が稼働中ソフトウェアの保守に従事している？
• 報告者の現場経験(現40年超)：JIS X0161定義の保守経験大半。ただ，新規開発も経験(15%程度) ⇒「開発」と「保守」の対応技術の明確な相違を知る(C) 2017 Masui, Kazuya . All rights reserved.

３．ソフトウェア保守隠蔽の事例

わが社はアプリケーション保守費の大幅削減に成功！！

本当？
単に人が減らされているだけでは？

(C) 2017 Masui, Kazuya . All rights reserved.

3.1 今の研究・教育は保守を隠している？
• ソフトウェアの「保守」について書いた書籍・資料・論文は，「開発」のそれに比べ僅か（次ページ）• 保守の解説を含むソフトウェア全般ガイド本も，保守の記述量は全体の極一部（例：SWEBOK）で，教育機関のIT教育シラバスでもソフトウェア保守のテーマは僅か• ソフトウェア関連学会の発表キーワードに「ソフトウェア保守が必須作業であり，高度な技術的作業であると前向きにとらえたもの」は少ない⇒海外にソフトウェア保守専門と呼べる学会(IEEE/CS内)はある。ただ，日本ではそこでの発表紹介や現場適用事例は聞くことが少ない。日本では保守は研究対象外？
• ソフトウェアの保守は，次のように扱われている（日本だけ？）
開発をちゃんと教えれば保守なんかできるはず。保守が多い原因は元の設計・作りの悪さのため。優秀な技術者が保守作業如きに取られるのは悪。保守を削減・消滅させる新開発方法論の研究と教育が中心 ⇒「保守作業は確実に減少」と世間を勘違いさせてまっている(C) 2017 Masui, Kazuya . All rights reserved.

和書のブック通販サイト検索結果例「ソフトウェア開発」でのヒット数「ソフトウェア保守」でのヒット数

開発／
保守

アマゾン

11,26530375.5倍

楽天ブックス（中古含む）

2,101

13215.9倍

紀伊国屋ウェブストア（和書）1,4022166.8倍

セブンネットショッピング
（本）

3,640

277

13.1倍

ヨドバシ書籍通販

4,713

226

20.9倍

TSUTAYA(販売本)

4222211.0倍

国会図書館検索（本のみ）

1,500

4037.5倍

検索対象サイト名

2017年5月時点

この差は以前から不変。今も「ソフトウェア開発」が増加傾向？
⇒「ソフトウェア保守」は書名として非常に不人気な言葉？
(C) 2017 Masui, Kazuya . All rights reserved.

3.2 今のIT振興施策行政は保守を隠している？
• IPAの「i コンピテンシ ディクショナリ」に「ソフトウェア保守」のキーワードはあるが概要のみ。また，ソフトウェアの保守は運用の付け足しの位置づけに見える• 情報処理技術者試験のシラバスには，2016年５月改定で「ソフトウェア保守」が追記された部分もあるが，記述量は他に比べ圧倒的に少なく，超概要程度の内容• 国のIT振興施策予算は，ソフトウェアの新規開発や先端技術による研究に向ける方針から脱皮できていない？
• ソフトウェアに関する各種調査報告や提言の多くは新規開発テーマから記述されている。既存ソフトウェアの対応が多い組織にとっては保守が最初のはず？

• 現在，ソフトウェア開発から現場に入るのではなく，最初から保守作業現場に入る若手もいる。開発中心の施策方針と現場のギャップに戸惑いは隠せない？
ソフトウェア振興施策対象は開発中心。保守は将来必要性が低下，現作業量も統計から少ないはず ⇒保守は積極的振興施策対象になるほどのものではないと世間に印象付(C) 2017 Masui, Kazuya . All rights reserved.

3.3 今の企業のIT施策は保守を隠している？
• IT企業新人向けIT教育はずっとソフトウェア開発が中心？ ⇒保守教育を積極的実施と公表すると，保守作業が大半のIT企業イメージに思われるから？
• IT関連部門の部門名は，保守作業の存在を隠蔽した名前ばかり？
• ソフトウェアに関する技術標準は，実態は少ない新規開発中心の標準。
保守作業はそんな開発標準の無理な適用で辻褄合わせ？

• ソフトウェア技術標準に保守の標準が仮にあったとしても，それに守るためのリソース（工数）が保守では与えられない？
• 現場技術者も保守は「あるべき作業でない」とオープンにしない• IT部門が抱えるソフトウェアの規模とそれに見合う保守担当技術者数等については，営業秘密を盾に公表しない?
(C) 2017 Masui, Kazuya . All rights reserved.

４．ソフトウェア保守隠蔽に走る構造整理• 新規開発は加速度的に増大中という思い込みで保守の存在を認めない• ソフトウェア技術は常に革新的に進化し，旧世代技術のソフトウェアは自然淘汰され，その保守作業も急速に減少しているはず• 古い技術で開発されたソフトウェアの保守作業は誇れるものではないから，たとえあっても表に出さないし，ポジティブに語らない• 早く／安く／品質良く「開発」するから「後はよろしく」という無責任体質を責めない（安易に産んで，養育責任を放棄した親の氾濫）• 「これで保守コストは劇的に削減できます」と何度も騙す大手～中小のシステム構築ベンダ• だまされたことを隠し続けようと保守を隠す導入IT部門責任者（導入失敗責任追及逃れ）• ソフトウェアの保守予算をバッサリと削減し，経営基盤強化達成を強調する経営トップ• いつまでも続く現場無視の「開発善／保守悪」発想刷り込み

実態がどうあれ，「ソフトウェア保守」みんなで隠せば怖くない？
(C) 2017 Masui, Kazuya . All rights reserved.

５．ソフトウェア保守隠蔽の弊害
行政，研究，教育，企業経営などの皆が保守を隠すとどうなる？
• 隠された保守作業が重く現場ソフトウェア技術者にのしかかる（技術者）• 華やかなソフトウェア開発のイメージと現場に入り感じるイメージが大きく異なり，若手の定着率が下がる（不人気業種へまっしぐら）（業界）• ソフトウェア技術者の世代交代が進まず，現場中堅技術者の保守作業塩漬けが発生（技術者，技術移転）• 削られる保守予算の中で，現場中堅技術者は他の開発にも駆り出され，キャリアアップも自己啓発もできない極端な高負荷状態に置かれる（技術者）• 少ない人数での無理な保守対応で作業ミスが多発。IT部門の評価が下がり，お荷物（リストラ対象）部門になり，現場技術者への報酬も能力や働きに応じたものにならなくなる（産業）⇒ITは海外にお任せ（産業の大空洞化）

現場ソフトウェア技術者の使い捨てが横行(C) 2017 Masui, Kazuya . All rights reserved.

６．では，どうすればよいのかソフトウェア保守作業の存在と必要性を認め，開発善／保守悪のレガシーパラダイムを捨てる。そして，まずは行政として，① ソフトウェア保守業態の追加を行い，企業等のIT部門にソフトウェア保守専任部門（開発とは別部門）設立（効果：次ページ）を指導② ソフトウェアの少産少死時代における現場作業の実態に則した保守中心の教育充実・人材育成を，学校法人や企業等に指導③ 適切に保守対応できる既存ソフトウェアの引継ぎ研究を行い，第三者保守事業を推進④ 保守の適正な作業量を冷静に研究・分析させ，新システム導入営業での不当な保守コスト削減誇大広告を規制⑤
ソフトウェアの保守でシステムを人質に取り，利益確保に走る悪質なIT企業を
ただ，行政を動かすには，ソフトウェアに関わる（産・学などの）ステークホルダーが上排除
記の青字の考えを持ち，協力して主張していく必要がある(C) 2017 Masui, Kazuya . All rights reserved.

6.1 開発と保守の組織を分離する効果• 開発組織は開発技術に特化，保守組織は保守技術に特化• 開発の成否が開発組織から別の保守組織への引継ぎで明確になる• 開発と保守の掛け持ち要員が無くなる• 開発組織と保守組織の要員交代は双方の責任者の合意で実施• 保守作業や必要な保守技術が，開発とは別に確立される• 保守の生産性や品質の改善は，保守のスコープの中で計られる• 保守技術の向上が個人のレベルから組織のレベルに成熟独自組織となるため，開発標準とは別の保守独自の作業標準を作成し，繰返し保守対応することでプロセス改善が速やかに進む(C) 2017 Masui, Kazuya . All rights reserved.

6.2 開発時の保守組織の役割• 開発の初期段階から保守組織の要員が開発に参画する• 開発要件の内容を初期の段階から開発組織と共有する(適切な保守計画が目的)• システム構成設計の段階から，開発完了稼働後の障害発生時の調査時間短縮のための仕組み（含む仕組みのテスト項目）について助言• ソフトウェア基本設計時に設計規約の中に「保守性」確保について，具体的対応項目（含むテスト項目）の助言し，ポイントとなる設計レビューに参画する• ソフトウェア詳細設計では，モジュール分割やモジュール間インタフェースの設計（含むテスト項目）について，保守性の観点から助言，レビューする• コーディング規約について，保守のし易さ，修正記録のコメントのしやすさについて助言，コードレビュー実施• 設計，仕様などの変更が開発途中で発生した場合の変更手続きについて，適切な記録がされているか確認する(C) 2017 Masui, Kazuya . All rights reserved.

７． まとめ•••••••••

イメージが悪いモノは見せたくないのが世の常
モノのイメージは，周辺の権威者の発言やヒトの都合で良否が作られる（現実とは必ずしも合致せずに）「ソフトウェア保守⇒イメージが悪い⇒隠蔽」しても保守作業は減らない（保守が必要な既存ソフトウェア量が増えれば逆に保守は増加）
増加する保守を無理に隠すと，隠した費用の帳尻合わせが必要となる
その帳尻合わせが，技術者の使い捨てや疲弊多発によるソフトウェア技術者の不人気を加速させている
保守を悪モノとして，存在を否定する（無くす，減らす）研究をこのまま続けると，それが新たな保守隠蔽の悪循環をさらに進めてしまう
ソフトウェアの少産少死時代となっている現在の根本対策は，「開発善／保守悪」のレガシーパラダイムを捨てることである
保守の必要性（価値）や課題を正確に分析し，逃げずに議論していく
保守技術や保守専任者の客観的な優劣評価，適正コストの研究を進める(C) 2017 Masui, Kazuya . All rights reserved.

ご清聴ありがとうございました(C) 2017 Masui, Kazuya . All rights reserved.