情報システム部門／情報システム会社の強みとは
久しぶりの今回は、情報システムを使う側、ユーザー企業の情報システム部門、および情報システム会社の状況について書きたいと思います。
情報システム部門/情報システム会社にとって重要な課題を挙げると、①データをどう戦略的に使うか、②コスト削減、③人材育成、この3点だと言われています。どれも重要な課題ですが、今回はデータの戦略的活用をからめて、強みとは何かを掘り下げていきたいと思います。
現場の状況
稼動中のシステムは質・量ともに増加し、ビジネス部門の要求は多岐にわたります。さらに、多くの新しい技術が提供される環境で、その中心に位置づく情報システム部門、および情報システム会社のメンバは、過去のような経験実績を積むことができない中で、ヘッドカウントを絞られつつも高い品質でのシステム運用を求められています。
このような中で、普通にできていて当たり前で、少しでも問題が発覚すれば、IT系は業務を分かっていないと、一刀両断にされます。
また、データ活用のポイントで、ビジネス部門や経営層から様々な要求が来ることもしばしばで、あちこちのファイルからデータを抜き出しては編集・加工する作業が発生します。いくらBI、ERPと言ってもいまだにExcelでゴリゴリ加工していることが多いのが現状です。ああでもないこうでもないというやり取りが増え、当然のことながら多くの工数を割かれることになります。
先ほども述べたように、要員のヘッドカウントはぎりぎりまで削減され、パートナーもコスト見合いで減らされる方向にあります。そうすると一人で受け持つシステムの数が増え、以外の作業も膨大になり、今やらなくてはいけない日常の作業に埋没してしまうことになります。
そうなれば、こうすればよくなるなど分かっていても改善に至らず、今後のことを考えて―、という思考が停止した状態になり、黙々と働くということだけが残ってしまうというのは、言い過ぎでしょうか。
何が強みか
それなりの位置にいる内外の方々から、情報システム部門/情報システム会社のメンバはもっと業務に強くなり、ビジネス視点で考えることが必要だという発言をよく耳にします。
確かにそうなればベストなのですが、理想と現実は異なります。ビジネス部門とのローテーションが頻繁にあるだとか、IT採用があるなどによって状況は変わりますが、ほとんどの企業ではビジネス部門の方より、業務に詳しくなることは通常ありえません。
では何が強みなのか。いつもビジネス部門の言いなりになっていなくてはならないのか。
筆者が考える情報システム部門/情報システム会社の人材の強みは、まさしくシステム化する能力を持っていることです。もう少しわかりやすく言えば、プロセスをファンクションとして捉え、全体を抽象化・論理化する能力、データをモデル化して一望することができる能力を持つことです。これらは、IT系の人材でしかなし得ないことだと言えます。
もちろん、ビジネス部門の方と業務について会話できる知識を持つことは最低限必要ですが、IT側でしかできないことを強みにしていくのは、ごく当たり前のことです。
プロセスとファンクション
通常、一連の業務の流れは、組織でぶつ切りになっています。組織の中にいるビジネス部門の方々は、自組織外のことより自組織内の業務に強いと言えます。さらに業務をプロセスとしてとらえていることが多く、そのままヒアリングすると、まずこうして次にこうしてという話になってしまいます。上流工程で、業務を明らかにする必要がある場合は、このインタビューの仕方は適していません。プロセスをファンクションとしてまとめ、組織の枠を外すという抽象化、論理化の手法が必要です。組織の枠を外せば、本当の業務のスタートとエンドが見えます。
また、プロセスは時間軸に沿って流れますが、時間軸の考えを取り去ることにより、ファンクションとしてまとめることができます。これが、プロセスとファンクションの違いです。
プロセスはプロセス・フローなど手順書で表現され、ファンクションはDFD(Data Flow Diagram)で表現することができます。また、通常前者は組織に閉じた記述をすることが多く、後者は組織の枠を外した書き方をします。
Data Flow Diagramの例
組織や時間軸の考えを外すことによって、ファンクションの構成による全体像を明らかにすることができる訳です。これはIT人材にしかできないことであり、ビジネス部門の方にはできません。
さらにファンクションを使ってDFDで表現すると、そのファンクション間でどんなデータが流れるかが明確になります。
データモデル
データは、それだけで独立したものです。新たにシステムを作り直す場合、例えば人事システムが対象だとすると、通常置き換えられるものを旧人事システム、新しく作り直すものを新人事システムと呼びます。
しかし、データには旧データも新データもありません。データ移行するだけです。もちろん、新システムで今までなかったデータ項目が追加されることはありますが、基本的に項目類は引き継がれます。データ量は増えてはいきますが、構成内容としては基本的に変わらないということです。
その考えから、DFDよりデータを取り出した時点で、システム構築の流れには左右されず、データ分析の作業を並行して実施することができ、データモデルを形作ることが可能です。ERモデル(Entity Relationship Model)を使用するのが一番分かりやすい方法ですが、筆者は中でも最も初期のPeter Chenの記述法が適していると考えています。
ある製造系企業のコーポレートデータモデル(ERモデル)
ERモデルと言えばデータベースの設計を思い浮かべる方が多いですが、ここではそのステップではなく、業務の流れをファンクションで表現し、次にデータの流れをDFDで記述し、さらにデータのつながりの全体感を書き表すためにERモデルを活用します。このレベルでの全社のERモデルをコーポレート・データモデルと呼びます。そのことからも、基礎であるモデル化技法が適していると考えているのです。
システム分析全体観
大阪の製造業・情報システム部門の方から「システム分析・3日間コース」のご依頼を受けたのが数ヶ月前で、日程調整の結果実施は今月中旬と迫りました。もともとトレーニング主体のビジネスではありませんが、重要なこのコースだけはご希望があれば提供することにしています。
日立SE時代にメソッド策定のチームで実践を積みました。DOA(Data Oriented Approach)の第一人者である堀内一先生に師事し、このメソッドの適用第一号である大阪の生保会社の担当SEをしていたこともあって、活用法について深く経験することができました。そのノウハウを基にワークショップ形式のトレーニングにまとめたわけです。
日本オラクル時代には、当時の松下電器グループ向けに実施していました。ワークショップ形式なので、1回で4チーム、16名程度しか受講できませんが、200名以上の方が受講されました。結構タフな内容ですが、その後オラクル社内やHP主催で外部にも実施していました。
システム分析の流れ
自分自身も3日間拘束されるので頻繁にはできないのですが、このトレーニングを望まれる大きな理由は「変わらない技術を身につけたい」ということからです。名うてのコンサルファームから中途入社してきたメンバも、このように実戦的で体系だった方法論を学んだことがない、と言っていたのをよく耳にしました。
実装技術はめまぐるしく変化していきますが、IT人材の基本として持っていないといけないスキルは変わらないものだと考えています。クラウド化などにより、作らない時代になっても同じです。いかに情報を戦略的に使えるか、この一点に尽きます。
裏を返すと、これができることこそ、情報システム部門/情報システム会社の強みだと考えています。