Test Japan

レガシーシステムをサービス化することは非常に困難

http://enterprisezine.jp/article/detail/2327/?p=2

以前受講したセミナーで、ＩＢＭ出身の講師が「ＳＯＡは幻想だった」と述べていた。
汎用機で運用中のレガシーシステムをサービス化するのは、確かにかなり厳しい。
但し、成功すれば、その価値は絶大である。
結局、経営陣が納得できるＩＴか、金を払う価値があるか否かである。

 
 
 

ビジネスモデルを考案し、プログラムのコードを書いて動くプロトタイプぐらい作れる人材。

常日頃、思っていて、自分もそうなりたい理想像。

http://it.nikkei.co.jp/business/news/index.aspx?n=MMIT0z000018062008&cp=2

明快に述べていますが、言葉以上の含蓄があります。

企業内情報システム部門とITベンダーの理想的な関係。

 
差別化した新たなサービスを提供することのできる、ごく少数の優良ITベンダー（サービス・プロバイダー）と密接な関係を結び、ビジネス・プロセスの改革／改善に取り組んでいく。　これが情報システム部門の理想の姿。

外部からの調達を前提にした情報システムの新しいライフサイクル。

 
【今後、企業内情報システム部門において重要になっていく機能／能力】
●ビジネス要件をユーザー部門と協議しながら定義していくコンサルティング機能
●エンド・ツー・エンドでのビジネス・プロセスの設計機能
●自社内の開発標準を定め、それを実現する構成を組み上げるアーキテクト能力
●外部サービスを調達するか、カスタムメイド開発を行うかの選択能力
●異なるサービス・システムを組み合わせた環境でのサービス品質の保持能力

最終的には、ユーザー部門に対してビジネス・コンサルティングの機能を果たし、かつコンサルティングをするだけでなく、実装から運用サービスまでの実現案を具体的に提示／実行していくプロフェッショナルが求められる。

すごく、当たり前の話なんですが、日本の企業においては、なかなか実現できてないですね。以前、私自身が勤めていた外資系ベンチャーでは、まさに、このスタイルで仕事していましたし、そうでないと評価が下がりました。

ＭＶＣの境界と限界。

ＭＶＣで開発する場合でも、Ｖｉｅｗの部分でＤＢの項目に依存する記述をしていませんか？　そうした途端、ＳＯＡとしてのサービス切り出しが困難、いや実質無理になります。これを回避するには上述した「ＤＢの項目」の代わりに一般名称を使用し、この一般名称を辞書引きするようにすれば良いですね。辞書には一般名称とＤＢのテーブル・項目がマッピング定義されている前提です。但し、一般名称項目を参照する度に本来は不要であるＤＢアクセスが発生するのではオーバーヘッドがかかり過ぎですので、コンパイル・生成するイメージでＤＢの項目に置換する方が現実的です。こういう製品って、ありますか？　なければ作っちゃいます。

要求開発とプログラミング。

日頃、「システムを提案するには実装できるスキルが必要」、「要求開発にはプログラミングの経験が不可欠」と訴えている私にとって、「やっぱり、そうだよなぁ～。そう感じてるの俺だけじゃないよなぁ。」と思わせた記事です。

ITアーキテクトの要求開発力向上作戦

でも、現場、特に上流のコンサル部隊の人には理解して頂けないんですよね。だから、いつまでたっても、高い金とって絵に描いた餅ばっかり作ってるんだよなぁ。困った人達です。

業務も解かってプログラミングも出来る日本人て、ユーザ企業の情シス以外、極端に少ないと思いませんか？　てことは、ここがとても求められている人材ということですよね。そこを目指して奮闘中です。

「要求→システム」

ユーザから要求仕様を聞き出して基本設計書を記述し、これを元にプログラム作成することの難しさを端的に表した図を発見しました。

元は「要求」と「システム」のしなやかな平衡に掲載されたものですが、作者に掲載許可依頼したら、原画を送付して頂けました。

 

ウォーターフォール型開発の壁

従来のウォーターフォール型開発は、もう無理がきているのではないでしょうか。要件定義、基本設計、詳細設計、プログラミング、テスト、本番稼動という流れの各フェーズにおいて成果物として「ドキュメント」を残し、次工程は、そのドキュメントを元に進められるというのは、「ドキュメントが正しいことが前提」です。しかしながら、現実には１００％正しいドキュメントは皆無であり、この結果、やり直し、作り直し、泥沼の人海戦術、赤字・失敗プロジェクトが多発しています。

であれば、もうウォーターフォール型開発は止めましょう。では、どうするのか？　早期に、ドキュメントの代わりに動くものを作ればいいんです。（これを仮に実行ファースト型開発と名付けましょう。テストファーストではありません）　動くものを触ってテストできれば、ドキュメントのレビューなんかより、よっぽど効率的ですし品質も高いものができます。エンドユーザさんから見ても実感をもってテストできるため、「こんなはずじゃなかった！」ということが激減します。

ソフトウェア業界も、この点には気が付いているはずです。では何故未だにウォーターフォール型開発を続けているのでしょうか？　それには、すぐに変えることが出来ない事情があるんです。ウォーターフォール型開発なら、各フェーズで納品、請求することも出来ますよね。ところが、本来お客様にとってメリットのある実行ファースト型開発では、それがしづらいんです。もしするとしたら、機能単位とかサブシステム単位とかで、どこまで出来たら何千万円とかの契約にしないとなりません。これも実際には難しいです。また、協力会社（実際には下請けイメージが強い）に開発を依頼することも難しくなります。なにぶん、きちんとした設計書が無いのですから。

実行ファースト型開発はスパイラル型開発となるため、「作って見せて直してテスト」を繰り返すことになります。このため、なかなか収拾がつかなくなると心配する人がいます。しかしウォーターフォール型開発の最後で大幅変更を要求されるより、よっぽど良いのではないでしょうか？

実行ファースト型開発の具体的手法を策定中です。希望される方（但し法人に限るため社名を明記）にはドラフト版を差し上げますのでコメントorトラックバック下さい。

つづく

SOA導入の留意点

SOA導入の留意点をまとめてみました。備忘録でもあるため、加筆もありかな。

情報システム担当者の視点から
1.   導入コスト対効果
  SOAの導入にあたって発生するコストは決して安いものではないため、その費用対効果を吟味した上で、適用範囲を決定すべきである。

2.  開発プロセスの確立
SOAの考え方と開発プロセスは切り離せないものである。これは、ミドルウェアによって緩く結合される、つまり束縛されないソフトウェア構造の宿命であり、サービス切り出しにおける粒度の検討、プログラムのコンポーネント化における単位の決定など、旧来のウォーターフォール型開発では困難であることが多い。しかしながら未だ確立された手法はなく、むしろユーザ自身が自社の特性に合わせた手法（開発プロセス）を確立していくのが現実であり理想である。

3.  ボトムアップ手法の適用
後述する経営層またはユーザ部門による「トップダウン手法の適用」と合わせ、情報システム担当者からボトムアップ手法を適用することを推奨する。これは既存システムのリプレイスにあたっては特に重要である。何故ならば、既に動いているプログラムがあるのだから、その構造を解析・可視化し、場合によってはSOAの１サービスとして利用することも出来るからである。また、サービスとして利用できないまでも、構造を解析・可視化できたならば、全くの新規プログラムを作成する場合と比較して、不具合の少ないプログラムを低コストで作成することが可能となる。

経営層の視点から
1.   コスト負担と強い導入意思
  現状の情報システムに大きな不満がないのであれば、SOA導入は前向きに検討されないかもしれない。しかし、そのような企業においても、将来の変化に耐えうる情報システムを望むのであればSOAは現在において最適な解決方法である。但し、導入にあたって発生するコストは決して安いものではないため、導入目的を明確にした上で、情報システム部門はもちろんのこと、ユーザ部門の合意を得て、適用範囲を決定すべきである。そしてSOA導入を軌道にのせて、その効果を得るためには、強い意志をもって、開発、推進、適用、運用、さらにそれらの見直しを進めることである。

2.  開発プロセスの確立における調整
開発プロセスの確立が重要であることは前述した通りであるが、SOAに適した開発プロセスにおいてはユーザ部門の参画がより重要であるため、その協力を得るために調整が必要である。本来、情報システムはユーザ部門のために存在するものであり、その意味では「協力者」ではなく「主担当」であるべきだが、レビューやテストは主業務でなく、その作業を負担と感じるユーザが存在するのも事実である。このため、上記 1. に記述した通り「合意」を得た上でスタートし、経営層は強い意志を表明、これを継続することが重要である。また、ウォーターフォール型開発と比較すると各工程後の変更も許される場合が多く、この点においても部門間の調整が重要である。

3.  トップダウン手法の適用
限られたコストで最大の効果を得るためには、SOAを適用するビジネス領域を定める必要がある。このビジネス領域はトップダウンの最上位に位置し、ここからビジネスプロセス、ビジネスサービスへと分解してゆく。これがトップダウン手法である。情報システム担当者は、ややもするとプログラムばかりに気をとられ、非常に狭い範囲の部分最適になってしまいがちである。これを避けるために、経営層によるトップダウン手法は全体最適のために重要である。加えて、情報システム部門によるボトムアップ手法と合わせて適用、つまりトップ、ボトムの両面から始まり合流する手法が適用できればベターである。

SOAの優位性

SOAの優位性について、まとめてみました。備忘録でもあるため加筆もありかな。

何故SOAが有利なのか？

情報システム担当者の視点から
1.   システム保守性の向上
旧来のプログラム開発手法と比較してプログラムの独立性が高いため保守性が向上する。今までもプログラムを共通利用および将来再利用する目的で重複する部分を切り出し、１つのプログラムとする「関数化、サブルーチン化」は行われていたが、その独立性が低いため保守性が悪く、結局は似たようなプログラムを作ることも多かった。
SOAを導入すると、ユーザに提供するサービスを１単位として保守対象とすることが可能となる。このサービスとプログラムの結びつきはミドルウェアと呼ばれる管理ソフトウェアによって行われるため、ある業務に変更が発生した場合、どのプログラムを改修すべきか容易に把握できる。また、管理ソフトウェアに従いプログラムが動作するため、従来のようにドキュメントとプログラムが異なる心配がない。その結果、従来発生しがちであったプログラム改修による悪影響、例えば「こんなところで使っているとは思わなかった。変更したら動かなくなった。」という無駄を減らすことも出来る。

2.  運用・保守コストの低減
上記 1. で記述した「システム保守性の向上」により、保守コストの低減が図れる。また、SOA導入にあたり必然的に業務フローが可視化されるため、内部監査（もしあるなら外部監査）におけるコスト低減、日常発生する問い合わせに回答するためのコストも低減することが出来る。

3.  新規開発コストの低減
一旦SOAを導入すると「システム保守性の向上」と同様の事由により、新規開発コストの低減が図れる。

経営層の視点から
1.   ビジネスプロセス保守性の向上
変化への対応が迅速かつ容易となる。ビジネスプロセスフローの変更は、詳細技術を知らなくても可能であるため、経営層およびユーザ部門が保守できるようになる。

2.  業務フローの可視化
SOA導入にあたり必然的に業務フローが可視化される。副次的効果であるが、現実に即したフローであるため効果は大きい。フローに従いプログラムが動作するため、従来のようにドキュメントとプログラムが異なる心配がない。このフローから、ボトルネックの発見、現状の問題点など経営に有益な情報を得ることが出来る。

3.   内部統制への応用
上記 2. で記述した「業務フローの可視化」により内部統制を図ることが可能。