激論! 情報マネージャ「情報システム部門の緊急課題」@IT情報マネジメント開設記念スペシャル

ITを統括する情報マネージャの今日的な役割とは何だろうか? 本稿では先進的なIT活用をしている清水建設、ダイアナ、サントリー各社の情報システム部の方々に、それぞれが抱える課題とその取り組みについて話を伺った。

» 2003年11月18日 12時00分 公開
[垣内郁栄,@IT]

開発業務の3大課題──業務設計、システムの柔軟性、コスト

清水建設 情報システム部 課長 安井昌男氏

 建設業界最大手・清水建設の情報システム部 課長 安井昌男氏は、情報システム部が担うシステム開発業務を「現実のビジネスの仕組みや構造を、システムの世界に投影すること」と定義する。つまりはビジネスプロセスとその結果を、ITシステムに反映させるということ。いわば、企業において“確立すべき業務”が前提としてあり、その業務をITにより効率よく実現し、他社に対する競争力を向上させるために情報システム部があるという認識だ。

 婦人服・雑貨販売のダイアナの管理本部 情報システム部 部長 池田賢一氏も同様の考え。「ダイアナでは業務が先に設計されていて、それに沿ってシステムが作られる度合いが高い」と語る。ITが業務を変えるのではなく、そもそもの業務プロセスに沿ってシステムを作るという形だ。

ダイアナ 管理本部 情報システム部 部長 池田賢一氏

 ただ、業務を基に構築したシステムであっても、利用部門からデータの出力依頼などで週に60件以上の問い合わせが情報システム部にあるという。これは「業務の事前設計度が低く、システム化されていない」ということを意味する。

 だが、池田氏は「だからといって、業務をギチギチに設計するとかえってうまくいかない。業務を止めるわけにはいかないし、動かしながら改善していくのがよい」という考え。そのためにも、開発するシステムは柔軟性に優れたものでなくてはならない。また、システム化しやすい業種と、困難な業種があるのも事実。こうした点から池田氏は、ベンダ主導の“画一的なシステム化”に警鐘を鳴らす。

 一方で、同一企業がさまざまなビジネスを展開している場合、情報マネージャには別の悩みがあるようだ。片山隆氏が情報システム事業部 情報システム部 課長を務めるサントリーは、今年10月から事業別に5つの社内カンパニーを設立した。情報システム部ではこれらの各カンパニーから依頼を受けて、システムを開発・運用している。情報マネージャは、サントリーグループ全体の最適を考えると同時に、各カンパニーの部門最適も考慮して業務システムを設計するという難しい仕事を抱えている。

 もう1つ、普遍的な課題として挙げられるのが「コスト」だ。業種・業態を問わず、多くの企業ではIT投資に消極的という現状がある。「1円でも余分なコストを出したくないのが経営層」(ダイアナ 池田氏)。その半面、めまぐるしく変わる経営環境に対応するため、開発期間はどんどん短くなっている。いかに費用を掛けずに、開発生産性を上げるか。これも情報システム部門が抱える大きな悩みだ。

Check!

  • 業務を動かしながら改善できる柔軟性あるシステムの開発とは?
  • 業務プロセスの部分最適と全体最適を融合させるには?
  • コストをかけず、生産性を上げるには?


運用業務の最大課題──固定費をどう削減するか?

サントリー 情報システム事業部 情報システム部 課長 片山隆氏 コストは開発業務に限った課題ではない。サントリーの片山氏は「コスト問題は非常に大きい」と言い切る。同社では「システムの新規開発にコストが掛かるのは仕方がない」という認識があるが、経営トップからの運用固定費ダウンに対する要求は強い。

 片山氏がいう“コスト問題”とは、単に低コストでシステムを開発・運用することだけを求められているのではなく、同時に業務の生産性を向上させるシステム開発も求められるということを指す。情報マネージャは、コストと生産性の両方をにらみながら、開発・運用を行う必要がある。

 以上のように、情報マネージャに求められる要件の中でも最も厳しく、客観的に評価されるのはコストに関すること。情報システム部では従来、経営トップがITに詳しくないことから、極端に予算が少ないか、逆に過剰な予算が投入されていた。しかし、現在は適正なコストを掛けて、期待値以上の効果や生産性の向上が求められている。ITに関するコスト構造が透明化し、常に経営の主要問題としてトップマネジメントで議論されている。

Check!

  • 「運用固定費の削減」は経営トップからの強い要求
  • 適正な開発・運用コストで最大限の効果を上げるには?


こうした課題について、各社どのように取り組んでいるのだろうか。

開発業務の課題解決のカギ──モデリングとコンポーネント技術の採用

 こうした複雑な問題を抱える情報システム部が、システムの開発・運用を行う場合、効率的な開発手法、言い換えるならば開発プロセスが不可欠だ。清水建設の安井氏はシステム開発について、「物事の本質や特質をとらえて抽象化することがポイント」と明らかにし、モデリング技術や、RUPなどの開発プロセスの重要性を訴えた。また、UMLを用いた図を使うことで、システム開発の対象となる業務を視覚化・構造化し、効率的な仕事につなぐことができる。安井氏はUMLの表記法としての流通性を活用し、スタッフ間の業務を都合によって差し替えることができるようにしているという。

 ベンダとの付き合い方についても安井氏は信念を持っている。それはシステム開発の基本設計を情報システム部で行い、「リーダーシップをベンダに渡さない」ということ。もちろん情報システム部にはベンダとやり合うだけのスキルや知識が必要になるが、ベンダに頼り切ってしまうとリスクが吸収できず、プロジェクトが失敗することもある。システム・インテグレータ(SI)やベンダのエンジニアと共同作業する場合も「現場監督はわれわれだという認識」を持っている。SIやベンダへのシステム開発の丸投げで、低品質なシステムが構築されるユーザー企業が多い中で、清水建設では「基本的なシステム設計はシステム部門で行う。一発目のクラス図(概念クラス図)の作成から、SIに仕事を丸投げするようなことは絶対にやらない」が信条。ダイアナの池田氏も「ベンダはシステムが納入できればいいだろうが、われわれは使い続けないとダメ」といい、ベンダと情報システム部の意識のずれを説明した。

 ちなみにサントリーでは、開発生産性と柔軟性の向上を目指し、2年ほど前からJ2EEによるコンポーネント開発に取り組んでいる。業務ロジックをEJBコンポーネントに実装し、再利用していくことで、開発生産性を向上させていく計画だ。だが片山氏によると「生産性の向上は、まだ目標値に達していない」という。1つはコンポーネントの粒度がまだ小さいという問題。再利用可能なコンポーネントを開発しているが、いくつかのエンティティーをラッピングするといった小さな単位にとどまっている。実際のビジネスプロセスを汎化して1つのコンポーネントとして提供できないと、ほかのカンパニーのシステムへ流用する際、結局作り込みが発生するという。「どの粒度でコンポーネントを開発するか」が大きなポイントだ。また別の原因として、「技術的にも難しい」ということもある。片山氏は「分かりやすく、効果的な技術を」と、ベンダ側に再考を促す。

 また、オープンソースの採用もコスト課題に対する切り札。初期費用が低価格で済むというメリットに加え、サポート切れやバージョンアップに振り回されることもない。片山氏は「運用フェイズのことを考えるとオープンソース採用のメリットは大きい」と語る。

Check!

  • モデリング技術や標準開発プロセスを有効に使い、最適な業務を設計
  • プロジェクトをベンダに丸投げしない
  • オープンソースを採用し開発・運用のコストを下げる


運用課題解決のカギ──運用コストが掛かるレガシーを“切る”〜新たな課題「IT投資効果をどう評価するか」

 次に運用面におけるコスト課題への取り組みを見ていこう。片山氏が所属するサントリーでは、サポート・保守に多額のコストが掛かるメインフレームの依存度を下げて、オープン環境のシステムに移行することで、固定費の削減を狙っている。2004年にはメインフレームへの依存度は2000年に比べ半分程度に下がる見込みだが、そこで重要になるのが、利用部門へのシステムリプレースの説明。情報システム部が利用部門に対して、説明責任(アカウンタビリティ)を果たせないと、利用部門の理解は得られず、リプレースは失敗する。サントリーでは現状のシステムと、リプレース後のシステムのコストパフォーマンスを示すためにKPI(Key Performance Indicator:重要業績評価指標)に取り組む計画がある。片山氏は「IT部門の説明責任は非常に難しいと感じている。他社の取り組みに興味がある」という。どの企業の情報マネージャにとってもアカウンタビリティやIT投資の評価、計測は課題になっている。

 システム投資の効果を評価するといっても、変動する要素を正確にとらえ、効果を測ることは難しい。ダイアナの池田氏は「システム運用の評価やモニタリングは必要だと感じている。しかし、まだ行なっていない」という。なぜなのか。池田氏は「だれのためのシステムかによって評価、計測のポイントと粒度が変わるからだ」という。単純にIT投資が適正だったかを評価するだけなら、そのシステムの利用部門にヒアリングすれば分かる。しかし、システムの運用コストや利用率、経営戦略への貢献度など、システムをいろいろな角度から見ると、計測のポイントが変わってくるのだ。池田氏は「どれを考えても私はしっくりこない。情報システムに対する評価を、一般的な法則に対応させることは難しいのではないか」と疑問を呈した。情報システムに対する評価、計測の必要性は誰もが認めながらも、実際の方法はこれから探る、というのが共通の認識といえるだろう。

Check!

  • メインフレームをリプレースして運用コストを削減
  • リプレース/新規開発の際には投資効果を説明することが必要
  • システム評価の方法論は今後の課題


情報システム部門を強くするカギ──突き詰めれば「ITスタッフ」の課題に行き着く?

 情報マネージャにとって、スタッフの管理や教育も重要な業務だ。ベンダやSI任せのシステム開発・運用ではスタッフが育たず、情報システム部の(社内的な位置付けも含めて)地盤沈下を招く危険がある。ただ、技術知識の偏重ではダメというのが情報マネージャの共通認識。重要なのは「製品知識ではなく、業務に技術を適用させる力」(清水建設・安井氏)だ。ダイアナの池田氏も「技術は会社にとって重要ではない。むしろ、プレゼンテーション能力やRFPを書く技能が優先される」と訴える。池田氏は情報マネージャがITスタッフに求められる専門能力として、「管理能力」が最も重要で、次いで「プロジェクト・マネジメントなどの技能」、3番目に「技術力」が続くと説明している。スタッフに必要な技術は「初級シスアドくらい」という割り切り方だ。

 清水建設の安井氏も「重要なのは個人のスキルではなく、チームのスキル向上」という。個々の製品やテクノロジについての専門知識はベンダのエンジニアなど専門家に任せた方がコストも安くなり、効率的という考え。単なる個別製品に関する技術ではなく、基本的な工学的知識に加えて、ベンダとのコミュニケーションなど、ビジネスマンとしての基本能力が求められるということだろう。また、スタッフに対しては「利用部門からの要求に対して、フォーカスがぶれないこと」を求めている。「要は『何が出来ればいいのか』ということを見失わない」ということだ。こうした基礎的なビジネス力が、上記のアカウンタビリティの向上にもつながってくる。

 ただ、サントリーの片山氏がいうように、オープンソースなど新テクノロジを最適なタイミングで採用しようとすると「技術力は不要」といい切れなくなる。開発現場の作業がないと、スタッフにとって必要な最低限の技術力やコミュニケーションスキルも健全に育たないことになる。情報システム部のスタッフはIT戦略の立案を行うのか、それとも現場でシステム開発や運用を行うのか。そのバランスが難しいというのが情報マネージャの本音といえるだろう。

Check!

  • 「技術力」だけのITスタッフは不要
  • コミュニケーション能力、理解力があってこそ技術力が生きる
  • 開発現場の経験を積んでこそ必要なコミュニケーション力・技術力・理解力が培われる


情報システム部門あるべき姿とは──自らの「職務」と「サービスの受容者」を常に意識せよ

 情報マネージャが自らの業務を評価、計測することは、己の存在意義を常に問い直すことともいえよう。

 清水建設の安井氏は「時代を通じて変わらない情報システム部のアイデンティティがあるのではないか」と自問する。その明確な答えは安井氏自身も見いだしていないが、安井氏は「情報システム部門の意義は、『全社最適』を踏まえたうえでの、IT投資についての意思決定支援と、適用、実践、そして運用ではないか」と仮説を述べた。ダイアナの池田氏の考えでは、「だれに対してどのような仕事を行うのか」ということを常に明確にするのが情報システム部の理想の姿だ。

Copyright © ITmedia, Inc. All Rights Reserved.