第24回例会報告
3月12日、第24回の例会が開催されました。
今回のテーマは「情報システム部門の組織 ユーザー企業の情報子会社のあり方について」。
講師は、DIC株式会社の小田滋さんです。
昨年、DIC株式会社は、情報子会社のDICインフォメーションシステムズを簡易吸収合併しました。
それを事例としてお話いただき、ユーザー企業の情報システム部門、情報子会社のあり方についてディスカッションをおこないました。
DICについて
売上の半分以上が海外（欧州比率高い）、生産は60%が海外、日本人従業員は3割。
世界の3分の1のインキ、その原料である顔料は世界の4分の1、それを溶かす樹脂など年間230万トン強を製造販売している化学会社。色彩化学世界トップ。
2008年に創業100周年をむかえ、「大日本インキ株式会社」から「DIC株式会社」に社名変更。
情報伝達技術の転換期
人財とデータの活用をはかりたいということ。
ビッグデータの時代が来た。管理会計のため、伝票会計だけをしている場合ではない。
情報系のしくみが重要。分析の方に注力したい。
経営に資する、という意味が「気付き」という言葉に込められている。
IS部門の組織
人財育成、システム部門はどうあるべきかといったことが全て入っている。
世界4局体制。全部バーチャルな組織。CFOである代表取締役専務執行役員がグローバルCIOを兼務。
グローバルCIOオフィス室長が小田さん。従来のDICの情報システム部の機能は全部ここに。
合併前、本体側の情報システム部員は６人ぐらいしかいなかった。それ以外は旧子会社メンバー。
欧米、中国、APAC、日本にそれぞれCIOがいる。
ITガバナンスグループをつくり、ベンダーマネジメント担当、CSR・オーディット・セキュリティ担当、
プロジェクトマネジメント担当、技術担当を置いた。
「気付きのシステム」への思いが入った組織。
吸収合併に伴うさまざまな問題：人事労務
営業譲渡とは違い、人も仕事も100％飲み込む簡易吸収合併のようなハードランディングには、さまざまな問題が伴う。
もともと、子会社の7割近い社員がプロパー、外販比率が低いなど、恵まれていた部分はあるが、それでも以下のようなことが重要。
・基本的労働条件と労使関係の調整
・給与の一本化
・就業規則の一本化
・資格ならびに昇格判断の一本化（本体基準にあわせる）
吸収合併に伴うさまざまな問題：定款
100周年の社名変更のときに、定款の見直しの話が出た。会社法では子会社の事業を全て定款で謳う必要は厳密にはないが、情報子会社の事業を定款に入れてもらったので、吸収合併するときには定款の変更はしなくて済んだ。
吸収合併に伴うさまざまな問題：ビジネスの移行
・外販を2％まで絞込み
・1万本の契約の移管
100％子会社で吸収合併するので、あまり問題なかったが、よその資本が入っていたり、
全く違う業種だと、移管の制限条項つけられることがある。「同業他社に契約譲渡するな」とか。
生産性向上のための取り組み
子会社時代から、社員のスキルの把握と人材育成に注力し、生産性の向上をはかった。
ゴーイングコンサーンのためにも生産性向上が重要と考えた。
人財育成
トーマツ・イノベーションクラブを活用。社長教育もあるので自分も受けた。
中堅若手社員は積極的に受けて、「初年度にこんなに受講した会社はない」と驚かれたほど。
若い人は飢えているのだなと思った。
社員のスキルの把握
カッツモデル（ヒューマンスキル、テクニカルスキル、コンセプチュアルスキル）を意識して把握。
育成プログラムの結果評価にも使った。
・UISS（テクニカルスキル）をベースに、600項目以上の調査項目をDIC用に作り直した。
開発、保守、運用などは高いスキル。
上流工程が比較的弱い。結果としてシステムテストも弱い。
運用保守をメインとするユーザー企業の情報子会社はこのような傾向になりがち。
・日立中央研究所の「ビジネス顕微鏡」でコミュニケーション量やアクティブ率を計測（ヒューマンスキル）
自分の業務を客観的にみてほしかった。
しっかり働いて、しっかり休んで、生産性上げて、楽しく仕事しようということ。
「原点回帰」と「基本に忠実に」と言い続けた。
結果、2007年のベンチマークから、2009年に社長になって3年で、
1人あたりの売上高が、2007年比125％。
1人あたりの生産性も、2007年比125％。
情報システム部門の役割
経営の要件をITでどう実現するかを考える
経営は、営業利益の目標を定める。そのために売上を伸ばし、経費は減らし、
総合力の発揮や成長地域で実績をだすよう要件を定める。業績管理も売上利益から目標管理にする、
というようなことを業務側（事業部門）におろす。業績管理の指標算定以外はITとは直接には何も
関係ない内容である。業務側は様々な検討を行い、取捨選択をした後、システム化要件を抽出する。
IT側は、その要件について役割責任を明確にし、例えば「数字の議論をしなくてよいデータを出す
基幹システムをつくる」といったことを考える。このように経営の要求と要件が背景にあることを
理解して、業務側の要件をはっきりさせ、きちんと見積もりに落とし込むが重要である。
そのためには、ぶれないビジョン、スコープが大切。
情報子会社が外にあったとき、親会社はIS戦略策定と評価だけをして、あとは全部子会社の仕事とした。
「企画も親会社側でやれ」と言われたこともあるが、企画から携わっていなければ、いいシステムは
つくれない。子会社の人はがんばって提案してくれた。自分達にその分野の提案力がなかったら、
きちんとRFIをだして、業者から情報をとってくれた。
情報子会社の選択肢４つ
情報子会社時代は、会計、特に営業会計を取り込んでサービス機能をやっていたこともある。合弁を考えたこともある。
木内会長から、以前示された「情報子会社の選択肢４つ」を見て考えた。
1. 子会社を本体に吸収（全部本体でやる）
2．グローバル対応を情報子会社化（子会社ですべてをまかなう。子会社を大きくする）
3．有力ベンダーとジョイントベンチャー（10年前に流行った）
4．情報システム部門を全部外に出す（他社がやった例がある）
1と２：人財育成がとても大変。事業会社にITに強い人はなかなか来ない。
2：さんざんやった。
3：ベンダーロックインが怖い。業務委託費も負担になる。
4：全額経費になる。IT投資がいくらなのか、わからなくなる。戦略上問題。DICの場合これは論外。
３から１への移行は至難の業。 １なら３への可能性を留保できる。
結果、DICの場合は１にした。人財の問題は、大学からのインターンシップを活用した採用でクリアしていく。
講演の後には、さまざまな面でディスカッションが行われました。
Q＞そもそもなぜ情報子会社を吸収したのか？
A＞ 技術領域は広がっているし、深みも増している。
経営への関与度だけでなく、製造の現場のシステムも高度化。
パートナーシップ構築を前提に、自分達は「つくる」から「考える」へシフトするため。
Q＞「つくる」から「考える」という中で、社内のデータを把握したり、IS部門だけでなく
マーケティングのようなデータに関連する部門や人材を育てたりしないといけないと思うが？
A＞2006年から、メインフレームのデータHDBを、RDBにミラーリングして公開した。
データがほしい部門の人間が聞きにくる。そこで使い方を教えるといったことをして
データの重要性を認識してもらうことをやってきた。
いまの組織には、DB担当、共通基盤、技術情報を作った。
これらの器を作った理由で忘れてはいけない大事なことはデータの重要性である。
これとは別に会計系のDWH担当もいる。DBに人をさいている。DBを使う文化を強化したい。
構築はベンダーにやってもらってもいいが、利活用には仮説設定能力が必要なので、内部の要員は必須。
パートナーリングするにも内部に社内とのブリッジができる人が必要。
Q＞ユーザー部門と情報システム部門の関係はどう変わったか？どう変わるべきか？
A＞意外とエンドユーザーはITの可能性に気づいていない。
情報システム部門が、気づかせないといけない宿命を担っている。
ユーザーと情報システムは対等でなければならない。むしろこちらから押していく。
「こういうITの使い方をしないといけないんじゃない？」と。
ユーザー部門は、そういう問いかけに対して、真摯にうけとめる度量をもたないといけない。
そういう関係をどう築くか？ローテーションや業務知識に逃げてはいけないと思う。
ユーザー部門と情報システム部門の仲が悪いというのは、実体を知らない人達が
まことしやかに話していること。本当にデータの重要性を知っているユーザー部門は
データ構造を熟知している情報システム部門の手を借りないと、よい成果が出せないことを知っている。
だがその人達はほめてくれないので、声に出してほめてもらうしくみをつくりたい。
また、システム部門もユーザーを説得しきるようにならないといけない。
「経営に資する（＝気付きの）システム」づくり、「データを活用する会社」になるという目的のために、
これまでのすべての施策がつながっているのでした。
最後に木内会長からコメントがありました。
JUASでも、いつまでやるんだろうと思うぐらい情報子会社の議論をしている。
それだけ皆が問題を抱えている。情報子会社はさまざまで、十把一絡げではいえない。
健全な会社も多いが、情報子会社をつくった動機が不純な場合が多い。
人の受け皿にするとか、ITコストを外出しにして見えなくする（これは連結で関係なくなった）とか、
雇用のベースの違いを利用するとか。これは結果的に品質が下がる。
これだけITが経営の基盤になって、戦略的な投資をしないといけないときに、どっちが大事なのか？
はやくこういう話は結末をつけて、IT部門が求められる役割、ミッションに答えられるように体質改善しないといけない。
システムイニシアティブにやるとどうなるかというのが今日の例だと思う。
