目的：ソフトウェア保守の将来を想定する。
ねらい：ソフトウェア保守業務の方向付けを誤らない。
ソフトウェア保守のあり方を検討する際に
広さと幅を持たせることができる。
ソフトウェア保守業務のあり方は
この１０年はおろか２０年間ほとんど変わっておりません。
人力依存、人頼みなのです。最近、少しだけ風向きが変わってきました。
それは、以下の理由によります。
１）多くの企業では開発がほとんど行われない。
２）保守の困難性（時間・費用がかかる、障害を起こす）が
経営の足を引っ張る。
３）経営・事業の要求にシステムが付いていけない。
そこで、
これからの１０年では保守業務がどう変わるのかを
予測してみます。
１．保守業務の対象案件
現在の保守業務の対象案件は、以下のような構成です。
（ＪＵＡＳ「ソフトウェアメトリクス調査２０１１」）
システムバグへの対応 １７％
ＯＳ変更への対応 ４％
ハード・ミドルソフト変更への対応 ３％
制度・ルール変化への対応 １４％
データ量変化への対応 １０％
業務方法変化への対応 １６％
担当者要望への対応 ２３％
ユーザビリティ変化対応 ８％
経営目標変化 ３％
その他 ２％
ほとんどすべてが、後ろ向きか守りの案件です。
システム再構築を含む新規開発が
ほとんど行われなくなっていますから、
「ビジネスを強化するのは保守しかない」
にも拘わらず、です。
この状態になっているのは、
「システム開発」がビジネスを強化するものであり、「システム保守」は、その言葉にも表れているように
守りの役割を果たせばよい、という時代の名残りです。
これではいけない、という機運は
盛り上がりつつあります。そこで、私の希望的予測では、
現在の守り型の保守は半分の力でできるようになり、残り半分の力は積極的にビジネスを支援する攻めの
システム強化に振り向けられるようになります。
２．保守の主体
当然、保守の主体・責任は、
システムを使う企業のシステム担当です。
ところが、多くの企業（特に大企業）では、
保守の実作業を外部企業に依存しています。
長くその体制を続けているうちに、
システムを使う企業側では、
保守業務の実態が分からなくなっています。
そのため、前掲の「時間・費用がかかる、障害を起こす」
に対して有効な手が打てず、
経営およびシステム利用者から不信を抱かれる
状態となっているのです。
その状態は今や限界です。
システムの経営における重要性が高い企業から
順次、外部依存をやめて行くことになるでしょう。
外部企業は、
システムを使う企業に要員を派遣して、
その企業が主体性を持って実施するシステム運営業務
のお手伝いをすることになります。
２．の変化も含めて考えると、
外部企業の要員の役割の重要性は
社内要員と同じになるはずです。
３．保守の担当
現在は、すべて内作（外部依存なし）の場合でも、
保守業務をその作業プロセスで分けて
分担している場合が一般です。
要件定義→詳細仕様決定→プログラム修正・作成→
テスト、などと分担するのです。
前掲の外部依存の場合は
当然プロセスでの分担となっています。
（組織分業区分でいえば、「横割り」です）
横割りだと、
一つの保守案件をこなすために、
他の担当との受け渡しが必要となります。
そのため、以下のマイナス面が発生しています。
１）作業を引き渡すための「ドキュメント」を作成する必要がある。
→工数・コスト増加となる。
２）引き渡しの際に齟齬が発生する。
→障害発生原因となる。
３）前工程の不備が、後工程の作業を阻害していても
自動的にはフィードバックされずに
生産性低下要因を温存したままとなる。
横割り方式は、システム開発時には
プログラミング部分がそれなりの量を構成しているために
正当化された方式です。
その方式を、保守でも踏襲したのが誤りだったのです。
保守では、ご承知のように
プログラミング部分はごくわずかですから、
分業するメリットはありません。
横割りをやめて縦割りにすると、
以下のような利点も実現できます。
保守の担当は、システム利用者との接点から始めて
保守業務固有のの検討、プログラミング、テストまでを
一貫して体験できます。
業務が分かるようになって、システム。ソフトウェア、
インフラまですべてを把握できるようになるのです。
これからは、業務が分からなければ、
経営に貢献できません。
実務の分からないシステム担当という汚名も挽回できます。
そうして、いくつかの業務を経験すれば、
経営全体に通暁するようになり、
ビジネス部門に転出すれば、
経営トップになれる可能性が大きくなります。
４．仕事のやり方
現在は、以下の理由で、仕事の実施方法は
個人依存で「属人化」状態と言われています。
１）明確な手順化がされていない。
２）対象システムの状態を説明する「ドキュメント」が
頼りにならない。
３）システムの作りが悪くて、変更を行う際の影響範囲が広く、
経験豊富な担当でないと検討範囲を押さえられない。
（これまでのシステムの作りは開発時に有利になっていて、
保守には向いていないようになっている）
４）作業を改善するためのツールがほとんど利用されていない。
ある調査では、各種ツールの利用率は１０％以下です。
このやり方は、多くの問題を発生させますので、
この１）～４）は改善されて行きます。
その前提で、担当のローテーションも可能となるのです。
５．対象システムの作り
１０年後にどこまで進んでいるかは未知数ですが、
現在の開発中心型システム構造は棄却されて
保守向きのシステム構造になります。
データベースは必要な範囲で分割し、
プロセスも分割してコンポーネント化し、
連携は疎結合方式（ファイル連携方式）とする。
こうしながらシステムとして整合性を保つために
ＭＤＭやＳＯＡの技術を用いる。
ビジネスの要求によって、必要であれば
どんどんコンポーネントあるいは「サービス」単位で
入れ替えて行くことが可能となります。
このことによって、
システムが経営の期待に機敏に対応していく
ことが実現するのです。
６．情報システムを作る技術
現在の多くの情報システムは
パッケージを利用して作るかプログラマが手作りする「手組み」
（スクラッチ開発）です。
パッケージを利用する場合も、
追加部分は多くは手組みです。
手組みは極めて、開発・保守の生産性が低く、誤りも起きやすい方法です。
手組みが行われたのは、
プログラムの自動生成方式だとコンピュータ処理のスピードが遅いために、
実用にならない場合が多かったからです。
ところが、
コンピュータの処理能力は飛躍的に高まりました。
そして、コンピュータの処理能力は飛躍的に高まりました。
プログラムの自動生成方式も大きく進歩しています。
手組みの必要性は薄れてきています。
２０１２年３月１５日号の日経コンピュータ誌の特集
「超高速開発が日本を救う」で以下のようなツールの利用実績が紹介されていました。
ｉｎｎｏＲｕｌｅｓ （韓国製）
ＧｅｎｅＸｕｓ （ウルグアイ製）
Ｓａｐｉｅｎｓ （イスラエル製）
ＰｒｏｇｒｅｓｓＣｏｒｔｉｃｏｎ （米国製）
Ｗｅｂ Ｐｅｒｆｏｍｅｒ （日本製）
ＰＥＸＡ （日本製）
これらのソフトウェアは機能の幅がありますが、
基本的には、プログラミングレスです。
この特集の中では、オリックス銀行の執行役員の方の
次のような発言が紹介されていました。
「自動生成なんてできるわけがないと思っていたが、
誤りだった。念願のノンプログラミングが
ついに実現できた」
今後のシステム再構築では、
順次このようなツールが利用されるようになり、保守の際にも、
ソースプログラムをさわる必要は
なくなっていくでしょう。
これ以外にも、変化は起きると思われます。
この続きは、いずれまた掲載させていただきます。
0 件のコメント:
コメントを投稿