» 【第104号】SI業の方法論再建のシナリオ(後編)

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

DRI通信104号「SI業の方法論再建のシナリオ(続き)」 2005.5.9
発行が遅れました。5月2日と6日が、DRI20周年の特別休暇となったため
です。「20年経ってまだこんな規模?」という声と、「よくも20年続いた」という
声とが聞こえます。「商品がソリューションになってない、ROIが悪い」との指
摘があります。でも20年前にわれわれが支援させていただいて、20年間で、
私の勝手な試算ですが、コンサルフィー5千万円投入し、100億円は回収
した会社があります。このROIはどう計算するのでしょうか。このような商品、
あと2,3年で引退するCIOはどう評価し意思決定するのでしょうか。
■再建の条件
先回述べたように、理想とのギャップは通常非常に大きいのですが、基本的
条件は満たさなければなりません。方法論は何を(ドキュメント)、いつ(手順)、
誰が(体制)、を規定するわけですが、やはり個人差の出ない高品質の部品
を切り出すドキュメントが鍵となります。ドキュメントは、自然言語の文章やプロ
グラムのように順次トレースしなければ理解できない、いわば「順次記述ドキュ
メント」と、建築図面やデータ構造図のように一見して理解できる、いわば「状
態記述ドキュメント」とになりますが、レビュー効率の点で「状態記述ドキュメン
ト」が有利です。さらにレイアウト規則を導入し人間の優れたパターン認識能\n力を活用できるドキュメントは、エキスパートの経験が短時間で活用でき、高
品質を実現する上で極めて有効です。羽生名人が一目で形勢判断をする
ようなもので、モデルによる「可視化」のねらいは、まさにここにあると考えてよい
でしょう。


部品化は必須ですが、ひとつの部品が、ITの変化、ビジネスニーズの変化な
ど種々の変化に影響を受けるような部品化は失敗です。ITの変化を受け止
める部品、ビジネスニーズの変化を受け止める部品など、部品が変化を分担
して受け止めるような部品化でなければなりません。また、木は温度の変化に
応じて葉をつけ、葉を落としますが、幹はほとんど変化しません。葉の生命活
動を幹というインフラが支えているわけですが、情報システムも画面・帳票やプ
ログラムなど変化するサービスと、これを支える変化の少ない実装独立のデー
タインフラを区別してしっかり位置づける必要があります。OOはこの問題をどう
解決するのでしょうか。
問題を解決するのは、身についた知識と熱意のある人間です。この養成を欠
いては問題の解決はありません。座学で学んだ知識だけでは、厳しい開発環
境の中では問題解決に繋がりません。「開発がひとをつくる」と言われますが、
実戦の中でのきめ細かく配慮された指導が、知識を身につけさせ、問題解決
を通じてひとをつくります。システム規模に比して人材が不足する場合は、もの
づくりよりひとづくりを先行させた方が、結局早く出来上がります。「トップダウン
手法は2割の人しかついていけないが、ボトムアップ手法は8割の人がついて
いける」は多くの場合成り立つようです。したがって大規模プロジェクトの場合は、
ボトムアップ手法により人材育成を先行させると、はじめは「これでよいのか」と
心配があっても、後半一挙にスケジュールを取り戻すものと思われます。「シス
テム開発プロジェクトは人材開発プロジェクトでもある」と考えなければなりません。
■方法論再建のシナリオ
方法論再建とは、立派な方法論を見つけてきて、そのマニュアルを各部門に
配布することではありません。方法論を身につけた人材を育成し、またデータ
インフラのコンテンツやテンプレートを蓄積することです。
はじめに、方法論のコンセプトや用語を学ぶための座学は受けますが、直ちに
実作業に入ります。一般には「大型の開発プロジェクトの中で」になるかと思わ
れますが、それは長期的に回収する、人材育成やデータインフラ開発の負担
に耐えるのは、期間的にも予算的にも、大規模プロジェクトを措いてほかにない
と考えられるためです。
しかし理想は、TOP主導のEAなどの全社をスコープに入れた、インフラ構築を
意識した、可視化・標準化プロジェクトです。開発プロジェクトとなると、どうして
もカットオーバー時期の制約から範囲や品質に妥協が発生しがちだからです。
いずれにしても未経験の大規模なスコープ、未経験の方法論の適用になるため、
試行錯誤を最小限に抑え、効果を見せながら継続するマネジメントの配慮が
必要になります。初めはプロジェクトをリードしてゆく核となるチーム−筆者はこれ
をPMO+DMOと呼びたい−を、プロジェクト本番前に作り上げるのが効果的
です。このためには、取付きやすい個別アプリを選び、パイロットプロジェクトを先
行させるのが有効です。SIerの要員も、このチームに参加して、個別アプリケー
ション横断の、そして開発後の保守を含めた最適化を指向する、PMO+DMO
要員としての腕を磨くことができるでしょう。
パイロットプロジェクトでの作業の大部分は現状のAs-Is分析、それも現状の
データモデリングになります。これによって現状の業務やシステムの問題点の大
部分が可視化され共有化されます。よくAs-IsをそこそこにTo-Beに入りたがる
人を見ますが、現状や問題点が可視化・共有化されていないため、ユーザ要
件が二転三転し、失敗の原因をつくる結果になりがちです。一般に現状分析
を通じてその企業文化に適した人材育成の方法が見えてきますし、現状の
データと新規のデータは、商売換えでもしない限り、90%は重なりますから、
その骨格を掴むことができます。
PMO+DMOがしっかりすれば、人数に応じて、いくつもの大規模プロジェクト
をリードすることができるようになります。PMO+DMOは開発・保守のスタイル・
文化を担っていくべきものですから、かなりの人数を集めて常に自社の文化を
育成する活動を続けなければなりません。腕は立っても俺流にこだわる人は外
さなければならないでしょう。初めが肝心、要件定義を正しく捉え、共有しなけ
ればなりませんから、これまでの「火消し」とは違った、プロジェクトの初期に重点
を置いた活動になるでしょう。
ややPRになってしまいますが、人材育成と独立に全社業務の実装独立の現
状(As-Is)を可視化するものを、われわれはESV(Enterprise System
Visualization)と呼んでいます。この場合、アプリケーション内とアプリケーション
横断を分離し、後者をまず攻めます。これを固めてからアプリケーション内にアプ
ローチした方が効率的だからです。1個のアプリケーションの大きさをどう設定す
べきかは、易しくありませんが、このESVを方法論再建に活用することも考えら
れます。
一旦新規の業務モデルができれば、次回からはこれが現状として活用できます。
最初は現状が暗黙知のためこの可視化や調整/標準化に苦労しますが、
可視化した後は現状が常に用意されていますから、これをもとにTo-Beを作り、
ソフトに反映すればよいという好循環になります。しかも、最近ソフトの大部分
をプログラミングレスにする研究が進んでいます。SIerはこのようなプロジェクトの
中で人材を育成し、方法論を再建してゆくのが、有効な解決の方向ではない
でしょうか。