<< ITシステムにおける新製品の採用について | main | ITシステムにおけるツールの利用について >>

ITシステムの基盤更改への取り組みについて

基盤更改とは

基盤更改とは、ITシステムの、ハードウェア・ソフトウェアの入れ替えを目的として実施するプロジェクトだ。

業務システムは何れ、基盤更改というプロジェクトに取り組むことになる。その契機は、ハードウェアやソフトウェアのサポート・保守切れ対応になる。

従って、この世の中で最も多いタイプのSIプロジェクト型と言えると思う。

基盤更改で最も問題になるのはコスト。業務サービスの継続性・安定稼働は大前提だが、業務要件を契機として始まる案件ではないため、投資よりも経費寄りの案件と言えるため、コストが問題になることが多い。

基盤更改案件で最も大きなコストになるのは、最低限度、購入する必要があるハードウェアやソフトウェア以外では、業務アプリのリグレッション試験のコストが最大になる。基盤更改プロジェクトの成否は、業務アプリのリグレッション試験を、どれだけ広く・深く実施できるかに掛かっていると言って良いと思う。

基盤更改への取り組みの歴史

歴史を遡ると、まずは、オープン系のシステムが実装され始めた2000年代前半。初期に構築されたオープン系システムが5-7年経過して、基盤更改のタイミングを迎えるようになった頃。

当時は、「基盤のハードウェア・ソフトウェアだけを入れ替える、業務アプリへの影響は極力最小限度にする」、というポリシーが採用されることがあり、仮に業務アプリ更改要件があっても、「まず基盤更改先行し、追って業務アプリ更改する」、という、基盤と業務アプリの更改タイミングをずらす方針が採用されたことがあった。その理由には以下のようなものが挙げられると思う。

  • 当時はまだオープン系のシステムは今ほど多く・複雑でもなかった。
  • システム部要員がメインフレーム経験に基づいていた。

メインフレームは、シングルベンダーによる垂直統合型で実装されている。ハードウェアとソフトウェアが、特定のベンダーによって実装されており(もしくは互換機ベンダー)、後方互換に対して高い互換性が維持されていた。数十年前にコンパイルされたバイナリモジュールがそのまま動作することが求められており、仕様はかなり詳細なレベルで明記されている(IBM社の「Principles of Operation」など)。

そのため、メインフレームの基盤更改の場合は、「業務アプリはほぼ変更せず、本業務稼働環境の横で別途構築された更改後のシステムに、本業務データを流し込んで、一定期間現新並行稼働させて、出力データに差異がないことを確認してから本番Go Liveする」という方式をとることができる。

オープン系システムにおける基盤更改の困難

上記の方針をオープン系のシステムにおいても採用しようとした基盤更改の取り組みが、2000年代前半に行われることがあったが、残念ながら、大きな問題を引き起こすことになる。その要因としては以下のようなことが挙げられる。

  • オープン系のシステムは、メインフレームと違って、ハードウェア・ソフトウェアの各スタック階層で、マルチベンダー実装が混在する。
  • スタック階層間のインタフェースレベルの整合性は何とか保たれるものの、振る舞いレベルの互換性の維持は困難。
  • オープン系では、メインフレームのように数十年前のプログラムに対する後方互換性よりも、機能追加の多さ・速さが求められていたため、後方互換も無視するわけではないが、注力する比率が相対的に低かった。
  • 実装が準拠する仕様が日進月歩で変化していったことで、仕様に準拠して振る舞いが徐々に変化していった。
  • 日進月歩での機能追加競争の中で、更改前はバグによって振舞っていた動作が、更改後は修正されて振る舞いを変えるということが発生する。
  • 明記された仕様に基づかない暗黙的な挙動が変更される。

その結果、業務アプリのリグレッションテストは、メインフレームのように、「完全に同じものを流せば同じ結果になる」というわけにはいかず、「入り口と出口だけ確認すればよい、差異が生じることは例外で、各々に対処すればよい」とはならなくなった。メインフレームではある程度成り立っていた、「現行踏襲」という要件は、オープン系システムでは要件として成り立たなくなったし、方針としても採用困難なものとなった。

そのため、全画面・全帳票・全バッチの機能確認試験および、性能試験・障害試験・運用試験を、人系のインテリジェントな判断を前提として実施する必要があり、システムの規模・複雑度が拡大するにつれて、コストと期間が、幾何級数的に拡大していった。

上記の経緯で早々に破綻した結果、各企業では、基盤更改は莫大なコストが掛かることから、投資案件となる要件、すなわち業務アプリ更改とタイミングを合わせて実施することが多くなった。

基盤更改に対してどのように取り組むべきか

基盤更改は、基盤更改単独ではなく、業務アプリ更改とセットで実施するべきだ。

業務アプリ更改でも、基盤更改でも、プロジェクトのコストの大半はテストに費やされる。「どうせコストが掛かるのであれば、両方を一緒のタイミングでやって、テストに掛かるコストを相殺しよう」、ということだ。

テストの次に多くの工数が掛かるのは、要件定義だ。「現行踏襲」という要件が使い物にならなくなった結果、暗黙的に現行踏襲を前提として始めたプロジェクトは、事実上、定義されていない要件に基づいて開始されることになるため、プロジェクト実施中に次々と未決事項・課題事項が発生し、やがて管理できる限界を超えて破綻してしまう。これを避けるためには、きちんと要件定義に取り組むことが必要であり、基盤更改の方が幾分かは楽になるが、業務アプリ更改のときに比べて格段に楽になるわけではない。

その結果、基盤更改のプロジェクト計画では、以下のようなことに注意が払われるようになった。

  • システム部予算の中期計画・長期計画で、基盤更改予定時期に合わせて、業務アプリ更改を計画する。
  • 基盤更改の目的は、製品保守切れ対応ではなく、現行維持保守課題の棚卸しと位置づけて、案件の計画時に、ユーザー部・基盤チーム・業務アプリチーム・運用チームの課題の洗い出し・吸い上げに注力する。(保守が切れることも維持保守課題の1つ。)
  • 経営課題は、業務アプリ更改にタイミングを合わせて、とりまとめと対策検討を行う。

上記の中でも、特に、アプリチームからの要件ヒヤリングは重要だ。

クライアント・ソフトウェア・スタック階層をフルに作り直してテストするには、投資案件として収益向上・コスト削減に直結する案件として予算確保して取り組む必要があるわけだが、5〜7年間程度の保守・運用期間で蓄積されてきたLessons Learned(教訓)を忘れてフルスクラッチで作り直すと、保守・運用期間の蓄積がゼロリセットされて、却って品質が低下してしまう。

こういうことは、現行本業務サービスの保守・運用に携わってきた業務アプリチームが多くの知見を有していることから、まず、プロジェクト計画フェーズで、十分に、変更要求・改善要望のヒヤリングを行い、当該プロジェクトではどこまで実施するのかを合意してから着手することが重要だ。

また、基盤更改プロジェクト開始後も、現行本業務サービス提供を通して生じた変更要求・改善要望が発生する。一般に、プロジェクトは、予め計画していた事柄に対する変動に弱く、プロジェクトの開始後に、予期せぬ変更が多く発生することは、プロジェクトを大混乱に陥れるに足る、重要なリスクとなる。いくら、ウォーターフォール型でフェーズ分割して、フェーズ間でイグジット・クライテリアを設けて取り組んでも、どうしてもその時々で、本業務サービス提供中に発生した変更要求・改善要望が生じてしまうものであり、通常、それらを切り捨てることはできないため、これらをコントロール下におくためには、着手後の要求・要望を吸収できるように、開発早期フェーズにおけるイタラティブ&インクリメンタルなプロジェクト設計が必要となる。

基盤更改プロジェクトの計画でやってはいけないこと

以下のような特徴を持つ基盤更改案件は、大炎上して失敗するリスクが非常に高いアンチ・パターンと言える。「予算が必要十分に確保できない」、「プロジェクト開始後に急速に未決事項・課題事項・変更要求が生じて管理・吸収できる限界を超えてしまう」、といったことが発生し、いわゆる炎上案件、デスマーチになってしまう可能性が高い。

  • 基盤更改と業務アプリ更改をセットにせず、業務アプリは極力変更しない方針とする。
  • 業務アプリチームで実施すべき事柄について定量的に見積もらずに過小評価する。
  • 業務アプリチーム、運用チーム、経営層からの要件のヒヤリングが浅い。
  • プロジェクト計画の策定時に、「案件が開始後にメンバーが揃ってから精緻化しましょう」と云って、具体的な検討を後回しにする。

コスト削減のための工夫

オープン系システムの規模と複雑さが拡大の一途を辿っている一方で、コスト削減の圧力が高まっていることから、コスト削減・CTOのために、以下のような取り組みも平行して行われている。

  • テスト自動化ツールの利用
    • リグレッションテスト
    • 負荷試験
    • 本業務サービス状況のキャプチャと、テスト環境での再生
    • CIツール
  • Webフロントなどのミッションクリティカル以外のシステムでのパブリッククラウド(XaaS)の利用(AWS, Azureなど)
  • 各種のSaaSの利用(Salesforce、サイボウズなど)
  • 初期投資コストは最小限度にしてシステム構築し、1/Nスケールのシステムでの負荷試験実績に基づいて、本業務環境で必要なリソースを追加調達する。

おわりに

上記は2010年頃までには成熟していたことであるため、現在から振り返ると10年以上過去から知られていた旧聞に属することであるが、現在でも、さまざまな規模の、さまざまな事情の企業があり、未だに黎明期に位置する企業もある。

そういった企業は、先行企業の実績を踏まえて最新技術を利用し始められる優位性がある一方で、AI、コグニティブ(という名のエキスパートシステム)、クラウド、と言ったバズワードに翻弄されて、成熟する機会を逸している面もある。

各企業、各アカウントで、各々、事情が異なるものだが、基盤更改は何度も繰り返されてきた営みであり、ある程度は、やるべきこと、やっていはいけないことが分かっている。自分の頭で考えて、咀嚼することは必要なことだが、考えるだけでは正しい解決方法にたどり着けないことが多いのも事実だ。常に、リファレンスする事例を調査して、Fit&Gapを評価してGapに対して集中して検討することが必要である。

| 日記 | comments(0) | trackbacks(0) |

スポンサーサイト

| - | - | - |
コメント



この記事のトラックバックURL
http://msugai.jugem.jp/trackback/1078
トラックバック
CALENDAR
Sun M T W T F Sat
   1234
567891011
12131415161718
19202122232425
262728293031 
<< March 2017 >>
WATCH
SEARCH THIS BLOG
LATEST ENTRIES
CATEGORIES
SELECTED ENTRIES
RECENT COMMENTS
RECENT TRACKBACKS
Twitter
MY WEB SITES
PROFILE
ADMIN
MOBILE
qrcode
ARCHIVES
SPONSORED LINKS