【このテーマの目的・ねらい】
目的:
ソフトウェア保守業務に関心を持っていただく。
ソフトウェア保守業務の現状を知っていただく。
ソフトウェア保守業務は大幅に改善可能であることを知っていただく。
ソフトウェア保守業務改善・改革の対策を概括していただく。
上野が苦労しているのだな、ということを知っていただく。
ねらい
日経コンピュータ誌を読んでいただく。
ソフトウェア保守業務を改善しようかと思っていただく。
「この対策」を実施してみようかと思っていただく。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
日経コンピュータ誌2013年1月10日号に
上野則男寄稿の
保守コスト半減の勘所
目的・ねらいの明確化が必須
ツール活用で作業を自動化
が掲載されます。
私の所属する会社のグループは、
ソフトウェア保守業務の経営戦略的な重要性を
事あるごとに訴えてきました。
その主張を一言で言えば、
「ソフトウェア保守業務の経営貢献を高めましょう!!」
です。
今や新規開発は一部の業種を除いて、行われません。
開発の一部であるシステム再構築も、
その難易度・コスト制約の点から、行われることは稀です。
ところがビジネスは生きていて変化・成長しますから、
システムに対する要求もずい分あるはずです。
それを受けるのは、
ソフトウェア保守でなければならないのです。
ところが、現在の保守の体制あるいは資産が、
その要求に応えられるようになっていません。
そこを改善すべきなのです。
改善はこうすればよい!!と訴え続けてきました。
しかし、
まだまだ本格的に改善に取り組もうという企業は少数派です。
今回の日経コンピュータ誌の寄稿は、そのさわりです。
この寄稿の主な内容をご紹介します。
1.ソフトウェア保守業務の現状
・ソフトウェア保守業務は、
全国平均で開発業務の3~4倍、
金額にして年間合計7兆円の大きさです。
・それにも拘らず、
これまでほとんど実施方法の改善が行われずに、
昔ながらの人海戦術で業務が実施されています。
・その結果、ほんのわずかの改修に大きな時間と費用がかかり、
改修作業の不備でたびたび障害を起こしています。
・そのため、改善者に取っては「宝の山」状態です。
2、改善した場合の期待効果
・そこで、以下の対策を講じると、
3年で現在の業務は半減、5年で3分の1にできます。
・その浮いた工数で、 現在は先送りになっている
ビジネスを支援する機能拡張・改良等を実施することができます。
2.1短期的効果(3年以内に実現)
・目的・ねらいの明確化 15%
・障害削減対策の実施 10%
・作業の自動化 20%
・保守インフラの整備 10%
2.2中長期的効果(3年以上で実現)
・保守インフラの整備 10%
・システム部門の保守機能強化 (測定不能)
3.対策の内容
(1)まず第1は、「目的・ねらいの明確化」です。
・これは当社のオハコテーマです。
・保守の依頼者はあまり深く考えずに
「こういうことができたらいいかな」という程度で
依頼している案件もかなりあるのです。
・JUASの調査でも、
「ユーザビリティ変化」
「担当者要望」
「業務方法変化」
という理由の案件が全体の半分近くを占めています。
・これらの案件は、「どういうことなのですか」と探求することによって
当初の要望が変更になる可能性があります。
・それでも、多くの企業では、
一つ一つの案件はたいして大きくないこともあり、
担当者の要望がそのまま通ってしまいます。
・そこで、すべて案件について
「これは何のために変更するのですか?」と探求すると
費用対効果の観点から別の方法で対応した方がよいと分かったり、
内容を変更するということになったりします。
・これを徹底しましょう、という対策が1番めです。
あるシステム部長は、このことによって2割のコストカットが可能だ、
と言っておられます。
(2)障害削減対策の徹底実施
・障害対策はほぼ完全に実施済み(それでも障害は発生する)という企業と
まだまだ対策強化の余地が大きい企業と、ばらつきがあります。
・JUASの調査では、保守工数の25%が障害対応であるとなっています。
・障害が半分になれば、保守工数の10%以上が浮く計算になります。
・障害が起きなくなるようにする対策は、非常に多くあります。
この一つずつを地道に実施していかないと障害の撲滅はできません。
・寄稿文では、各保守プロセスでの障害対策の優先度等を示しています。
・これらの対策と並んで有効な基本対策として、障害発生状況の見える化
(どのグループのどのような障害が多いのか)を勧めています。
・これを行うと、各組織が自律的に障害削減対策を実施し、
「目に見える効果」が各社で実現しています。
(3)ツール活用による作業の自動化
・現状の保守業務では、ツールの利用率は極めて低い状況で、
竹やりでゲリラと戦っているようなものです。
・保守プロセスで大きな工数がかかっているのは、
影響範囲調査(この変更・修正はどこに影響するかを見極めること)と
テスト(間違いなく変更・修正が行われていて
余計なことをしていないことの確認)です。
・そこでこのプロセスにツールを導入して、作業の自動化を行います。
有効なツールが存在することをご紹介しています。
・特に、影響調査ツールは、影響調査が省力化されるだけでなく、
影響調査の精度が高くなりますので、
後のプロセスすべてに好影響を与え、
保守の全体工数が半分になったという事例も報告されています。
(4)保守インフラの整備
・保守業務のインフラとは、以下のものを指します。
a.保守に必要なドキュメント(資料)の整備
b.そのデータベース化(リポジトリ化)
c.データマネジメントの整備
・多くの保守業務担当者は、 プログラムソース以外は
何も頼りになるものがない状態で業務をしています。
「必要な情報はすべて頭の中にある」という状況です。
・このため、仕事の習熟に時間を要し、
「業務が属人化している」と言われています。
・こうなっている原因はいろいろありますが、
あらためて、保守に必要なドキュメントを決定して
(開発用のドキュメントとはかなり異なるのです)
それを整備するのです。
・この作業は結構大変ですので、
一念発起しないと取り組めません。
・必要ドキュメントが整備できたとしても、
便利に使えるのでなければ、
じきに使い物にならなくなってしまいます。
・便利に使える仕掛けがリポジトリ化です。
寄稿文ではそのポイントを示しています。
・次いで、データマネジメントの整備です。
・情報システムはデータの処理ですから、
基本となるデータの定義や取扱いが標準化されていなければ、
その基盤が揺らぎ、まともな処理ができるわけがありません。
・この整備も時間と労力がかかり、日本企業は遅れています。
寄稿文では、整備すべきという問題提起に留めています。
(5)システム部門の保守機能強化
・現在のシステム部門およびその代理人である情報子会社は、
経営に対してまともに責任を果たしているとはいえないのではないか、
ではどうすればよいのか、という非常に重大な問題提起をしています。
・中途半端な記述は誤解を生みますので、
ここではこれ以上述べません。
日経コンピュータ誌をご参照ください。
・それでも言葉足らずですので、
このブログで改めて解説させていただきます。
以上、かなり長くなりましたが、
半年以上の醸成期間のかかった寄稿の概要紹介を
させていただきました。
大事なことは冒頭の
「ソフトウェア保守業務の経営貢献を高めましょう!!」
です。
皆様と一緒にその実現を目指して
さらなる努力を続けたいと思っています。
0 件のコメント:
コメントを投稿