2012年10月1日月曜日

ソフトウェア保守内製化の勧め

【このテーマの目的・ねらい】
目的:
 ソフトウェア保守はシステム部門
 (およびその分身である情報システム子会社)
 が自ら実施(インソース)すべきである、
 という意見を知っていただく。

 その場合のメリット・デメリット・その対策案を知っていただく。

ねらい:
 ソフトウェア保守の内製化をご検討いただく。
 その結論とその先の対応はさまざまでしょう。

ーーーーーーーーーーーーーーーーーーーーーーーーー
 

私の会社システム企画研修株式会社では、
現在ソフトウェア保守(改良)業務の改善推進を
主事業としています。

そのコンサルテーションや研修・研究会を実施しているのです。

ソフトウェア保守(改良)業務の改善の対策は、
数多くあるのですが、その内の一つが「インソース」です。

以下ソフトウェア保守業務を単に保守業務と言います。

これまでは,
あらゆる領域でアウトソーシングが流行りでした。
目的はコストダウンと社員の有効活用です。
有効活用とは、社員はアウトソースする以外の
価値のより大きな仕事をしよう、という意味です。

ところがアウトソーシングしていると、
コストダウンにはなりますが、
社員の能力に欠落部分が生じたり、
変化への対応力・機動力が弱くなった、
という面が感じられるようになってきました。

その流れを受けて、
日経BP社から「開発・改良の切り札 システム内製を極める」
という書物が2011年7月に出されたりしています。

私たちが、保守業務のインソース(内製化)を提唱するのは、
以下の背景・ねらいからです。

1.現在は、通信・流通・新種サービス業を除く多くの業種では、
  情報システムの新規開発案件はほとんどない。
  ・全国的には開発関係業務の8割は保守です。

2.したがって、ビジネスの変化に対応し、ビジネスを強化するのは
  保守ガ担っている。

3.したがって、保守業務はビジネスの要請を的確に受け止めて、
  迅速に対応する必要がある。
  ・アウトソーシング体制では、
   このニーズに十分応えられていないのです。
 

4.保守業務は、1件ずつが小さく委託する大量処理のメリットがない。
  ・それにもかかわらず、
   保守業務をアウトソース(外部委託)するのは、
   開発のアウトソースの延長の発想・類推でしかありません。

5.保守業務の工数分布は、
  保守要請に対して既存システムでどのように対応するかの検討と、
  考えたとおりに保守がなされたかどうかの検証(テスト)
  が比率として大きく、
  開発の際に大きなウェートを占める専門的作業の
  プログラミングの部分は比率が大きくない。

  ・このことを指して、
   保守の業務はフタコブラクダだ、と言われます。
   なおさら、専門家に依存する必要性が小さいのです。

   
 
インソースすると、
保守業務の迅速性・機動性が高まる以外に
以下のメリットがあります。

1)一連の作業を他社と分担するために発生する成果に直結しない
 連携のための手続き・作業が発生しない。
 ・そのための資料作成、など。

2)連携の際に発生するコミュニケーションの齟齬が発生しない。
 ・伝達ミス、伝達漏れなどです。
 ・これは保守起因の障害に繋がります。

3)一連の作業を一つのグループで担当するために、
 担当は、情報システムに関わる総合的な能力を身に付けられる。
 ・システムの利用者の業務を理解し、ソフトウェアの構造を理解し、
  プログラミング作業を習得し、
  保守(改良)後のシステムを移行するための方法を習得する、
  ことができるようになるのです。
 ・開発では多くの場合、工程ごとの分業で総合的な能力は
  身に付きません。

4)一連の作業を担当していると、前工程の不備を自ら認識するので、
  保守作業の自律的改善が行われる。
 ・一連の作業が分断されていると、
  前工程の他人の不備を自分の作業の中で吸収してしまう
  (本来ならやらなくてもよい余計な工数を費やしている)。

こんなに良いことずくめなのです。

前掲の「システム内製を極める」でも、以下の事例が紹介されています。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
東京証券取引所は、システムの種類に応じて、
アプリケーション保守のやり方を使い分けている。
株式の売買単位の管理や銘柄のマスター管理など、
顧客の差異化につながるアプリケーションの保守作業は、
外部委託からグループ内に戻した。

「売買システムを高速化するだけてなく、
それを使った新しい顧客サービスを素早く提供することが
競争力の強化には不可欠。
ここは外部に任せきりにするのではなく、
自社で素早く対応できる体制が必要だと考えた」
と鈴木義伯専務取締役CIOは狙いを語る。


アプリケーション保守を強化するために、
保守担当者を大幅に増員している企業もある。
ソニー生命、三井住友海上火災保険、日本郵船グループなどだ。

ソニー生命は2006年からシステム部員の増員を始めた。
当時60人ほどだった部員は現在約130人と2倍以上になった。
このうち100人以上がアプリケーション保守の担当者だ。

保険会社の新商品の大半は、
既存の保険商品が基になっている。
そのためシステム側も、既存システムを保守することで対応する。

保守人員を倍増したことで、
法改正があった場合でも(上野注:その対応をしながら)
年2回の新商品提供ペースは維持できるようになった。


80人いる開発担当者のほとんどを保守担当に切り換えたのが、
日本郵船グループである。

日本郵船グループの情報子会社の武田敏明社長は
「保守という言葉の意味が変わってきた。
そのままの形を保って守るのではなく、
手を加えながら新しい価値を創造することが、
これからの保守だ」

上野注:まさにそのとおりです。

当書には、
ソフトバンクモバイルが、保守の仕組みを改善して
1週間で新サービスを提供できるようにした事例や、
ビジネス・ブレークスルー大学大学院学長の大前研一さんが
「学生に提供する遠隔学習システムを、
自分も使いながら自ら改修していく」事例も紹介されています。
ーーーーーーーーーーーーーーーーーーーーーーーーーーー

これらの事例は、
保守のあるべき姿の究極を示していると言えそうです。

ところが、完全インソースを行うには一つのネックがあります。
それは、多くのシステム部門要員がプログラミングができないことです。

インソースのために、プログラミングの研修を始めている
システム部門もありますが、
習得にはそれなりの時間がかかるようです。

その解決策があります。
それは、JAVA等の一般的なプログラミング言語を使用しないで、
ソフトウェアの自動生成ツールを使用することです。
かなり現実的に有効なその種のツールが存在しています。

ところが、新規開発の時には、そのツールを使えばよいのですが、
保守の場合は、
既存システムがそのツールを使っていなければ、
保守部分だけそのツールを使うというわけにはいきません。

このネックに対する解決策が実現しつつあります。

私が得ている情報では、
間もなく、既存のソフトウェア(対象は順次拡大されます)を
自動的に「ソフトウェアの自動生成ツールに変換する」ツールが
リリースされます。

そうなれば、システム部員はJAVA等を使えなくても、
「自ら保守」を実現できるようになるのです。

必要は発明の母と言いますから、
このようなツールは、どんどん成長して、
「インソース」を促進してくれることになるでしょう。

早くその時代が来ることを期待したいものです。

なお、システム部門になり代わって、
一貫してソフトウェア保守を引き受けましょう、
という戦略を立てている情報サービス業が出てきています。

その成果も見守りたいものです。

当社では、そのための要員を育成させていただく
Sweeper養成研修(半年コース)を定期的に実施しています。
ご関心ある方は、以下のご案内をご覧ください。
  http://www.newspt.co.jp/data/sweeper/sweeper.html




0 件のコメント:

コメントを投稿