» 【第102号】SI業での方法論の衰退

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第102号】SI業での方法論の衰退

DRI通信102号「SI業での方法論の衰退」 2005.3.2
風はまだひんやりしますが、陽の光は春の明るさになりました。風邪や花粉
を吹き飛ばして、せわしない期末を乗り切りましょう。
さて、DOA+コンソーシアムでは、2月15日、教育・普及を目的とする第
3分科会の第1回、「データモデリングって実際どうなの」を開催しました。
参加者は70名。はじめにテプコシステムズの国澤さんから基調講演があり、
その後パネラー真野(CAC)、堀越(データ総研)、渡辺(DBC)、稲見
(PFU)、佐野(NECネクサ)のみなさん、これをとりまとめる本村さん(ケン
システムコンサル)の名司会により、充実した内容になりました。かなり詳しい
報告がDOA+のWEBサイトに掲載されていますので、ご覧ください。
また、第1分科会第2回は2月28日、[アーキテクチャの整理とモデルメタ
構造]をテーマに議論しました。システム、DB、モデル、パターン、フレーム
ワークなどいろいろな言葉が登場しますが、人により、ときによりその意味や
相互関係が違い、かみ合わない無駄な議論が発生します。これを少しでも
解消していくために、まずどのようなアーキテクチャでこれらを考えているのか、
そのベースを整えるためでした。一度では無理でしょうが、そのきっかけが
多少はできたのではないかと思いました。
■方法論のShelfware化
2007年問題が取りざたされています。団塊世代以降のSEは、「出来上が
ったシステムに手を入れただけで、ゼロベースで考える力を持っていない」
などと言われます。われわれも、90年代はじめまでは、PLAN−DBの普及
を通じて、データモデルをベースに噛み合った議論のできる人が大勢育ち、
ユーザ会でも充実感のある議論ができていたのに、90年代半ば以降は、
そのような人がめっきり少なくなったように感じております。
一方、大手SIerの方法論なども名前は残っているものの、ほとんどShelfware
(棚の飾り物)化しているかに見えます。実際の開発は中小のSIerに任せる
ため、そのPMに強制することもままならず、QCD(Quality, Cost, Delivery)
だけに関心を持つ手配師となっていったかに見えます。


■設計ドキュメントはPM任せ
方法論は、設計ドキュメント、手順、担当者から成りますが、その中核は設計
ドキュメントです。これが下請けのPM(あるいはその配下の担当者)任せに
なっていると言うことです。するとどうしても、モデルよりも不定形な自然言語
に依存する部分が増え、属人化し、品質は下がります。レビューが甘くなり、
コミュニケーションが行き届かなくなります。過去の経験の蓄積が個人レベル
になり、共有化が難しくなります。部下はPMが変ると、一からやり直しになり、
教育の効率が低下し、組織の流動性が阻害されます。
プロジェクトを統括すべき大手SIerも、下請けPMごとのドキュメントでは、
全体を横断的に把握することが難しくなります。発注するユーザ企業は、もと
より丸投げ的になっていますので、システム全体を視野に、その整合性を見て
いる人がどこにもいなくなってしまう危険性が大きくなります。オフショア化が
進み、PMが外国人となったとき、この危険性はどうなるのでしょう。
■本格開発の減少
方法論衰退の一番大きな原因は、定められた方法論にしたがった本格的な
開発が非常に少なくなった、と言うことかと思われます。大手企業は80年代
に、メインフレームを用いて、一通り機械化を行いましたので、手付かずの分
野は限られています。このため、手直しレベルのコストダウンをねらったC/S
化や、ERPなどのパッケージによる統合化など、再構築が主体となります。
「安く、早く」が要求されますので、業務モデルによる可視化など、たとえ技術
的に可能であっても許されません。物理差分メンテナンスに走り、暗黙知化、
劣化が進行することになります。同時にこれを担当するSEのレベルダウンが
生まれます。修理工に自動車が作れないようなものです。「開発がひとを作る」
と言われますが、そのチャンスが枯渇したわけです。
■方法論の不備
また、それまでの方法論が万全でなく、定着が十分でなかったことも、大きな
原因かと思われます。「是非この方法論でやりたい」というほどの成功事例が
なかったのではないでしょうか。
万全でない点の第一として、筆者は方法論の上流における「実装独立の不
徹底」を挙げたいと思います。当然、はじめは実装独立の概要のユーザ要件
が提示されるのですが、従来の方法論の多くは、詳細化するときにいつの間
にか実装従属になってしまうものでした。実装環境は、プロジェクトごとに変化
しますが、これに対応して標準を用意することができませんので、PMの責任で
都度対応せざるを得ません。その過程で属人化が進行するのではないかと
思われます。そうなると当然レビューが甘くなりますから、品質も不十分、引き
継ぐたびに品質は劣化します。
実装独立の正しくかつ詳細な業務のモデルができていれば、保守や再構築に
際しこれを改定してから、実装の改定に入る流れが作りやすい。しかし「詳細
は実装モデル、あるいはソフトウエアしかない」ということであれば、保守や再
構築は、実装環境が変らなければ物理差分メンテナンスに、また実装環境が
変れば、一から再設計とならざるを得ません。
「実装独立の不徹底」の原因は、やはり「動いて何ぼだ。ソフトこそが目的で
あり、業務モデルは、そのための開発段階の一過性の手段に過ぎない」といっ
た、昔の使い捨てプログラム時代を引きずった「短期的ROI重視」にもとづく
「業務モデル軽視」、「開発優先」の認識にあると考えます。やはり「ソフトは
業務モデルの実装環境へのマッピングである。業務モデルは半永久的な寿命
を持っている。ビジネス環境の変化に応じて、業務モデルを変えていかなけれ
ばならない。ユーザとシステム担当は業務モデルならば共有できる。業務モデル
を介してコミュニケーションを行う」といった長期的認識に立たなければならない
のではないでしょうか。
筆者は「情報システムは、ビジネスニーズやITによって変化する部品(いわば
葉っぱ)と、これらの影響を受けず安定した部品(いわば幹)とから構成できる。
前者にはコード値や使い捨てプログラムによって、また後者にはデータモデルや
データ定義によって対応すべきである。ドキュメンテーションは、前者にはペイ
しないときもあるが、後者には十分ペイするし、効果的である。ところが、葉と
幹を分離する方法論でないため、ドキュメンテーションの効果が出せず、目的
があいまいになって、不徹底になっているのではないか」と考えます。
■業務モデル
業務モデルの中核はデータモデル図と業務プロセス図です。情報システムは
ビジネスを駆動するための画面・帳票をその製品として作り、ユーザに提供する
わけですが、その画面・帳票を構成するデータ項目(正確には属性)の意味、
相互関係を示すのがデータモデル図であり、画面・帳票の位置づけ−いつ誰
が作り、いつ誰が使うか−を明示するのが業務プロセス図です。ユーザは一人
ではありません。そのニーズが矛盾したり重複したりしているため、これを調整の
上作成します。これらは機械における、設計図や取り扱い説明書に相当します。
この品質が悪ければ、ユーザのニーズを満足させることができません。
情報システムにおけるコミュニケーションはデータベースを介して行われますが、
そのデータ項目の意味を、簡潔かつ正確に規定しているのがデータモデルです。
しかも、一般に業務内容を大幅に変えない限り、取り扱うデータはほとんど変
りません。このため機械の設計図に相当するデータモデル図は、業務モデルを
規定する最も重要なドキュメントになります。一部先進企業では、アウトソー
シングの際の媒体としては「全てモデルにする」と宣言して準備を進めておられ
ます。またMDA(Model Driven Architecture)としてモデルからプログラムを
生成する方向での検討も進められています。
しかしこの業務モデルが今逆に、多くのプロジェクトにおいて、手配師化した
元請SIerの手を離れ、下請けSIerのPMや担当SEに任され、属人化ある
いは作成省略の危機にあると伝えられています。これはどのくらい本当なので
しょうか。またその場合一体これにどう対処すべきなのでしょうか。この続きは
次号で扱いたいと思います。