TOP>企業情報>コラム>お客様の声>NO.07 ダイセル化学工業

NO.07 ダイセル化学工業

ダイセル化学工業(以下ダイセル化学)は、「業務革新プロジェクト」の一環としてのサーバ更新を、ノーミスで行うため、ある『異例のこと』を行った。その『異例のこと』とは何だったのか。また、そこにアシストがどう関わったのか。「怖かった。一歩間違えればプロジェクトは空中分解していたかもしれない」と語る、ダイセル化学のお二人に詳しく聞いた。

Guest Speaker
ダイセル化学工業株式会社
事業支援センター
システムグループリーダー(当時)
田中真哉氏(写真左)

井尾治道氏(写真右)


1. ダイセル化学の「業務革新プロジェクト」とは


まずダイセル化学の業態につきお聞かせください。

ダイセル化学は、セルロイド8社が1919年に合併してできた「大日本セルロイド株式会社」を母体とする、約90年の歴史を持つ化学会社です。「ダイセル」とは「大日本セルロイド」の略称です。

以後は、セルロイドのみならず、セルロース化学、有機合成化学、高分子化学、火薬工学などをコア技術とし、「化学」を軸にして事業展開を行っています。

アシストは今回、ダイセル化学が2002年から推進している「業務革新プロジェクト」の、サーバ更新の部分に関わりました。まずこの「業務革新プロジェクト」の狙い、意義をお聞かせください。

今回のプロジェクトの狙いは「業務の革新」であり、決して「情報システムの再構築(サーバ更新)」を目的としたのではないということを、はじめにお伝えしたいと思います。

今回の「業務革新プロジェクト」の意義は以下の通りです。

 1. まず業務プロセスの標準化を行う。システム化はその後で実施する
 2. 業務プロセスの一部分だけを改善するのではなく、はじめからおわりまでの一貫したプロセスすべてを
   調査し、改善する
 3. カンパニー制の短所である、システム不統一、業務プロセス不統一(あるいは重複)を解消する。部門
   最適を排し、全体最適を目指す
 4. 調達、加工、販売などといった各業務間での、重複や連携不全を解消する
 5. データ構造を整理する。誰でもデータを活用できるようにする
 6. 海外拠点での利用を考慮し、24時間365日、止まらないシステムを作る

2. 「業務プロセスが先。システム化は後」とは


それでは、少し掘り下げてお伺いします。1つめのポイント、「まず業務プロセスの標準化を行う。システム化はその後で実施する」というのは。

先ほども述べたとおり、今回のプロジェクトは「業務の革新」が狙いであり、「情報システムの再構築」は手段にすぎません。業務プロセスの革新と、情報設備の入れ替えはセットで行わないと効果が薄い。そして、どちらを先に行うかと言えば、まず土台となる「業務プロセス」を革新し、それから「情報設備という手段」を改善する順番になります。
もしこの順番を逆にしたらどうなるか。ERP、SCMなど華やかな3文字言葉の情報システムを先に導入し、業務プロセスの革新はそれから考えるという順番にしたらどうなるか。これは手段が目的より重視されている順番です。「システムの更新」は達成できても、「業務の革新」は達成できません。

このことは、工場など製造現場で、生産効率の革新を狙う時の手順と同じです。まず生産プロセスの改善を行い、その上で、改善されたプロセスに最適の製造機械を導入します。プロセス改善が先、機械は後です。順番を逆にしてはいけません。

2つめのポイント、「業務プロセスの一部分だけを改善するのではなく、はじめからおわりまでの一貫したプロセスすべてを調査し、改善する」については。

業務プロセスを革新しようとするなら、はじめからおわりまですべてを一貫して調査し、全体最適をめざして革新しなければなりません。部分最適で一部分だけ改善しても、求める成果は達成できない。そういうことを意味しています。

3. カンパニー制がもたらす「縦割りの弊害」とは


続いて、3つめのポイント、「部門最適ではなく、カンパニー間でのシステムおよび業務プロセスの不統一や重複を解消する」について詳しくお聞きしたいと思います。

まず御社が2002年より採用しているカンパニー制の特色についてご説明いただけますか。

カンパニー制は一長一短を持つ制度です。まず「長所」ですが、敢えて単純化するならば、以下のように言えると思います。

 1. 各カンパニーには高い独立性が与えられる。
 2. それにより、迅速かつ責任ある意思決定がなされると期待される。
 3. 独立採算による緊張感のある経営が実現されると期待される。

一方、ありうる「短所」、リスクは以下のようになるでしょう。

 1. 各カンパニー内の局所最適が進むあまり、会社全体として見た場合に、資産の重複や業務の不統一が
   生じうる。
 2. 特に情報システムにおいては、カンパニー毎に違うシステムが保有された場合、システム化の初期投資
   や維持費用も重複することになる。
 3. また、保有する情報のレベルや発生タイミングがカンパニーやグループ企業毎に異なることがありうる。

今回の業務革新プロジェクトでは、異なる各カンパニーのデータ構造とシステム構造、業務プロセス(仕事のすすめ方)を標準化し、今述べた短所を解消することを狙いました。

素朴な疑問としてお伺いしたいことがあります。「カンパニー間で情報システムにばらつきがあったりすると、初期投資や維持費用が重複するのでよくない」、これは分かります。確かにお金が二重にかかって、無駄といえます。しかしなぜ業務プロセスまで統一しなければならないのかが今ひとつ不明です。素朴に考えて、各カンパニーは、それぞれ独立した「別の会社」なのだから、互いに業務プロセスが異なるのは、ある意味当然。異なっていたからといって、特に問題がないように思えるのですが。

今あるカンパニー形態やグループ企業形態が永久に今の形で続くのなら、互いの業務プロセスが異なっていても問題はないかもしれません。しかし今の時代、昔のように組織が固定化することはありません。以下の場合に業務プロセスの不統一が問題となりえます。

 1. 分社や合併、事業単位の再編成が発生したとき
 仮にA部門とB部門を併合するという話が出たとして、両部門が別々のシステムを使っていたとしたらどう
 なるか。それらを統合するか、一から作り直すかしなければなりません。これは非効率です。

 2. カンパニー間で人の異動、行き来が発生したとき
 そんな時に、システムの体系、操作性が異なっていたらどうなるか。別のカンパニーに行ったとたんに、
 システムの操作方法や、データ構造を一から覚え直さねばなりません。これは良くありません。

上記のような弊害を未然に取り除くため、今回の業務革新プロジェクトでは、カンパニー間、グループ企業間で、共通化できる部分はなるべく共通化するよう努めました。

4. 業務領域ごとにシステムが異なる「横割りの弊害」とは


さて、ここまで各カンパニー間での仕組みの不整合をなくす取り組み、つまり縦割りの弊害をなくす取り組みについて伺ってまいりましたが、ダイセル化学では、横割りの弊害をなくすための取り組み、つまり、「調達、加工、販売などといった業務間での、重複や連携不全を解消するためのシステム側の取り組み」も行ったと聞き及びました。これについて詳しくお聞かせいただけるでしょうか。

ダイセル化学の業務領域は、製造業ですから、単純にいえば、1)原材料を「調達」して、 2)その原材料を、生産計画に従って「加工」、3)できた製品を「販売」する、つまり「調達→加工→販売」が1サイクルになります。以前は、これらに対し、システムを以下のように概念分けしていました。

領域の名前 担当する範囲 どこが管轄しているか
基幹系業務領域 販売、購買などを管理する 本社システム部門
操業管理領域 製造データを収集・加工し生産管理を行う 生産技術センター
運転管理領域 製造プラントをコントロールする エンジニアリング部門


かつては、このような横割りによる以下の弊害がありました。

1. 【各業務領域の間の連携不全】
かつては各領域が、それぞれ独自に(バラバラに)システムを構築していました。そのため、各領域同士での双方向の情報共有やシステム連携がスムーズではありませんでした。

2.【データの定義、構造、配置の不統一】
特にデータの定義や配置が、業務領域毎(あるいはカンパニー毎、工場毎)に、その時の業務都合でなされていました。まとまりや定義、理念に欠けるデータ構成でした。

3. 【データの検索も分析もできない。現場の著しい非効率】
今述べたとおり、データもシステムもバラバラだったので、現場社員が、何か業務に役立つデータを取り出そうとしても、どこのデータをどう見て良いやら、何が何やらわからない状態でした。データ検索は、部署内の専門家(あるいはシステム部門)に依頼しないとできない状態でした。

検索も分析もできないのでは、何のためにデータを蓄積しているのか、意味がありません。今回の「業務革新プロジェクト」では、この弊害を解消し、もっとスムーズに業務やデータを一気通貫させ、誰でもデータが使える状態にしようと考えました。

このことが冒頭で述べた、業務革新プロジェクトのポイント5、「データ構造を整理する。誰でもデータを活用できるようにする」に繋がってきます。

5. 事を進めるツボは、データ構造の統一化


「システムの横割りの弊害を解消するには、データ構造の統一化が肝要」ということでしょうか。

はい、データ構造の統一は、システム一気通貫を実現するための、『重要な土台』だと考えています。データ構造が異なっている状態は、いわばボタンの掛け違いのようなもの。ここを正さないまま、その上にどんな立派なシステムを載せても、一気通貫は実現しません。最初にボタンを掛け違っているわけですから。

そこで今回は、各領域のデータについて、全社単位で持つべきなのか、それともカンパニー単位、あるいは工場単位で持っていれば良いのか、などを子細に考え直しました。

さらに、構造化されたデータを、誰もが使えるようにするための「道具立て」として、WebFOCUSという、検索・レポートツールを導入しました。

6. 24時間365日ノンストップは単なるスローガンではない


最後のポイント、「海外拠点での利用を考慮し、24時間365日、止まらないシステムを作る」というのは具体的には。

現在、ダイセル化学では、海外生産の比重が徐々に高まりつつあります。ということは、冒頭述べた、カンパニー間やグループ企業間の業務統一の問題も、日本国内だけで考えるのではなく、海外拠点も含めて考えていく必要があります。業務革新プロジェクトを通じて構築したシステムは、今は国内拠点からの利用が中心ですが、今後は、海外拠点からも利用することを想定しています。

海外とは「日本と時差のある場所」、もっと平たく言うと「日本が夜の時に、昼になっている場所」です。ということは日本の夜時間であってもサーバが止まってはなりません。その間に他の国がそのサーバを使っているからです。ですから「24時間365日動くシステムを構築する」とはお題目やスローガンではありません。世界規模で事業展開する会社にとっての必然的な「要件」なのです。

その「必然的な要件」を詳しく描写してみます。日本にある業務サーバは、【絶対に】、停止してはいけません。「止まらない。万が一の時でも止まらない。止まってもすぐ復旧し、データは絶対に無事」が要件になります。また、深夜に保守で3時間ほど停止させるぐらいはいいだろうとの考えも通用しません。日本で深夜であっても、他の国ではお昼の業務時間中だからです。

言葉本来の意味、掛け値無しに【24時間365日ノンストップ】で稼働していなければならない。非常に厳しい条件です。そして、今回アシストにご協力いただいたのは、まさにその、最も厳しい条件を実現するための施策の1つ、サーバ更新の部分なのです。


7. アシストとの付き合いのはじまり


まず御社とアシストの関わりについてお聞きしたいと思います。アシストと付き合いが始まったのはどういう経緯からでしょうか。

90年代前半の、社内システムのダウンサイジングの際に、Oracleの調達をきっかけにして付き合いがはじまりました。その時に、データベース部分を担当したのがあるSI会社。アシストは、そのSI会社の下でOracleを調達する商社としての位置づけでした。

ということはその時点での御社にとってのアシストの位置づけは…

「Oracleを調達してきた商社」以上でも以下でもないですね。そのSI会社に隠れているような存在でした。

当時のアシストの印象はいかがでしたか。

あまり良くなかったですね。というのも、アシストはあくまで「Oracleを調達してきた商社」としてSI会社の下に隠れていた認識でしたので、アシストという会社の存在を意識するのはOracleのトラブルシューティングの時だけで、そういうトラブルの時にはOracleに対する印象が悪くなっており、それにつられて、アシストの印象も悪くなる…。そういう流れでしたので。

その後、アシストへの印象が改善したのはどのタイミングでしょうか。

96年に人事システムを、それまでの手作りシステムからパッケージに切り替えるというプロジェクトがありました。その際にデータ活用ツールが必要だということで、FOCUSというツールをアシストから購入したのですが、その時の営業マンの対応や提案が、非常に顧客本位だったのです。この頃から、アシストへの印象が徐々に改善されてきました。

また、それから後も、その営業担当者は、根気よく通って、様々な情報提供や提案をしてくれました。今回アシストには、業務革新プロジェクトの一環としてなされた「サーバ更新部分のプロジェクト補佐」という大きな役割を果たしていただきましたが、その背景としては、熱心に通ってくださった営業マンKさんや担当したSEの熱意を見込んでの部分も大きいですね。

8. サーバ更新プロジェクトの扇の要、「プロジェクト補佐」の役割とは?


「プロジェクト補佐」というのはどのような役割だったのでしょうか。

これは図をご覧いただいた方が分かりやすいと思います。以下のような位置づけです。


これを見れば分かるとおり、アシストさんは、データベースやハードウェア、ストレージを担当する各社よりも一段上の立場に設定されています。

このような体制を取った理由は何でしょうか。

箇条書きで述べると、以下のようになると思います。

 1. サーバ更新全体の推進において、業務範囲や技術的課題について抜けやモレをなくしたかった。
 2. プロジェクトに関わる各ベンダーが「自分の範囲以外は我関せず、知らぬ存ぜぬ」とならないように
   したかった。
 3. 各ベンダーと我々との間の「よき通訳者」が欲しかった。

プロジェクト補佐という体制を取った理由のその1、「業務全体の進行において抜けやモレをなくしたかった」とは具体的には?

プラントを建設するのと同じようにノーミスでシステムを構築したかったとも言い換えられます。製造業としての我々がプラントを建設するときは、網羅的に想定される項目をあげて、抜けがないようモレがないよう、リストアップして、それらの項目を一つ一つ、丁寧に実現していきます。また、その時に想定されるリスクも考慮し、事前対応と万が一起こってしまったときの対応までも明確にしておきます。逆に言うと、抜けやモレがあると安全なプラントは完成しません。システム構築においても、それと同じ姿勢で臨むべきだと考えました。

今回のサーバ更新プロジェクトでは、おおまかには以下のような手順で臨みました。

 1. サーバ更新に先立ち、まず現状を洗い出す。
 2. 次に更新後のあるべき姿を緻密に描き出す。
 3. 次に現状とあるべき姿との落差を計り、その上で、その落差を埋めていくための実装ステップを緻密に
   リストアップする。

さて、ここまでは良いとして、問題は、このように計画した各ステップが本当に実行されるかどうか、実装中に予期せぬ抜けやモレが発生しないか、です。

9. 計画に抜けやモレが生じるのはどういう時か?


どのような時に、抜けやモレが生じるのでしょうか。

計画した業務が頓挫する原因として、大いにあり得ること、いちばん怖いことは、「抜けやモレに、誰かが気づいていても、それが見過ごされてしまうこと」です。

アプリケーション領域担当、サーバ領域担当、IDC領域担当などベンダー各社は、自らの領域は、それは当然ながら誠実に遂行します。しかし作業を進めていく中で、自分の領域以外の所に、抜けやモレを見つけた時、どうするか。

率直に言いまして、自分たちの受け持ちの範囲の外のこと、契約の範囲外のことであれば、特に指摘もせず、見て見ぬふりをする…。これは大いにありえます。しかし、それはそれで、SIベンダーにとっては「経済合理的な行動」ですから、注意したり呼びかけたりして、改善するものではありません。

そこで、アシストを我々の脇に「プロジェクト補佐」として位置づけて、抜け、モレがあったら、それを指摘してもらおう、また指摘するだけでなく、全ベンダーをとりまとめての、修正作業の総監督もしてもらおうと、そう考えたのです。

10. どんな会社が「プロジェクト補佐」というポジションに適しているか


プロジェクト補佐という体制を取った理由のその3、「ベンダー各社と我々との間の『よき通訳者』が欲しかった」とは?

我々は、自分の業務のことには精通していますが、個々のシステムの個別技術の詳細まで熟知してません。ですから、前述した抜けやモレに気づいても、それを「技術の言葉」で表現できません。

これは非常に危険なことで、最悪の場合は、何と言ったらいいでしょうか、各ベンダーに「言いくるめられる」、「言い抜けられる」こともありえます。

そうならないように、我々の「業務の言葉」と「専門的な技術の言葉」の両方を理解している会社、つまり「業務の言葉を技術の言葉に通訳できる会社」を、横に置いておきたかったのです。

このような「プロジェクト補佐」に外部会社を据えるようなスタイルは、前例があることですか。

いや、ありません。今回が初めてです。

率直に言って、怖くありませんでしたか。今回のように、特定の一社だけを発注元の脇に据えるような体制は、その下の各ベンダーの反感を買う恐れもあると思うのですが…

怖かったですよ。一歩間違えばこの体制が空中分解するかもしれなかったわけです。ですが、今回は、どうしても成功させたかったし、「プラントを組むように、システムを構築する」という理想に妥協したくもありませんでした。だから、恐れを乗り越えて、踏み切りました。また冷静に考えても、アシストの「会社としての在りよう」は、こういう「プロジェクト補佐」という役回りに適していると思われました。

アシストの「会社としての在りよう」が、どういう点でプロジェクト補佐という役割に適していると思われたのでしょうか。

ざっと以下のような点が理由になるでしょうか。

 1. 今回のサーバ更新は、OracleによるノンストップDB構築が重要な要因であり、Oracleに精通している
   会社を中核に据えるべきだと感じた。アシストは、Oracleに関する知識、実績も豊富で、適役に思われた。
 2. アシストに顧客本位、問題解決本位の姿勢を感じたこと。
 3. アシストの、ソフトウェア商社という業態は、中立的でしがらみが少なかった。従って、各ベンダーの上に
   据えた時の 【角の立つ度合い】 が相対的に最も少なかった。
 4. 提案を作成したSEに熱意を感じたこと。

現在は、サーバ更新も終了し一段落ついた状態です。これまでの行程を振り返ってみてアシストへの評価はいかがでしょうか。

今回、非常に熱心に働いてくれたと思います。今回のサーバ更新への助力につき、満足しています。

プロジェクト中のアシストの活動で印象に残った点はありますか。

印象に残ったこととなると、やはりアシストのSEさんですね。【歯に衣着せず】を極みで行くようなSEさんでした。とにかく「システムの抜け、モレを無くす、整合性を取る」という、それ一点だけを考えていて、その他のベンダーに対してだけでなく、私たちに対してもまったく遠慮会釈なしの物言いでした。でも、それで良いのです。今回は、そういう動きを期待していたのですから。

11. ダイセル化学が考える情報活用


ダイセル化学の情報活用において特筆すべきことなどあるでしょうか。

特筆すべきことなのかどうか不明ですが、弊社では、「定型帳票」、「定期出力帳票」は極力無くす方向で進んでいます。つまり、ある形の帳票を、情報システム部門がわざわざ出力してあげて、それを各部に届けてあげること。それはやめました。

しかし業務上、帳票が必要になることもあると思います。そのニーズにはどう対処するのでしょうか。

各部門が、自分の欲しい帳票を、欲しい時に、欲しい形で、自分で出力できるような道具立てを整えました。これは以下のような経営トップの考え方に基づくものです。

1. 【情報システム部門の未来の仕事は…】
情報がいつでも簡単に取り出せるようデータ構造を整理し、専門家やエキスパートでなくても欲しい情報が検索できるように道具立てを整え、情報活用基盤を作ることである。

2. 【ところが、情報システム部門は、本来業務からはずれて…】
「現場からの依頼」の美名の下に、すぐ帳票を作ってしまう。こうして「本当に使われているのかどうかも不明な帳票」が、意味無く増えていく。

3. 【情報がタイムリーに、DBに蓄積され、いつでも簡単に抜き出せるようになっていれば…】
お仕着せの帳票など作らなくても良い。データを、どう使ってどんな形式の帳票にするかは、データを抜き出して利用するユーザ部門が個々のニーズに基づき、自分で決めればよい。

4. 【情報システム部門の未来の仕事は…】
情報システム部門は、各現場が、必要な帳票を作るための「基盤と道具立て」を提供することである。帳票そのものを作る必要はない。

そして、今回は、その「簡単な道具立て」として、アシストより推薦のあったWebFOCUSを活用しているのです。

12. アシストへの今後の期待


最後に、今後のアシストに対する期待などあればお知らせください。

あるユーザが「アシストの提案は断りやすい。だから良い」と言っていたとのことですが、我々も同感です。我々にとっては、アシストというのは、ソリューションの百科事典のようなイメージですね。何か困ったことがあったら、本棚から取り出してパラパラめくる。でも必要の無いときにはしまっておける。この便利さ、気楽さが良い。またアシストの営業マンが、弊社に足繁く通って、百科事典の内容を都度とりかえてくれる、アップデートしてくれるのも有り難いことですね。今後も、この「ユーザに役立つソリューション百科事典」としての良さに、磨きをかけていってください。そして、弊社の情報システムの進化と発展をご支援ください。




※現在、ご利用いただいている製品、サービス
  ・プロジェクト補佐支援(システム構成~サーバ/ストレージ選定等)
  ・リレーショナルDB(設計、可用性~実装支援)
  ・BIツール(実装支援含む)
  ・高速化ユーティリティ
  ・統合運用管理ツール(監視/バックアップ・リカバリ設計〜実装支援)
  ・各種運用標準化ルール策定
  ・機能検証(可用性検証、バックアップ・リカバリ検証、ロードバランス機能検証)
  ・各種保守サポート

※ ダイセル化学工業(株)Webサイト
※ 取材日時 2005年11月 【取材協力:(株)カスタマワイズ】


Facebookで情報をお届けしています

Facebookでは、アシストの「今」を週3回のペースでお届けしています。「めげない、逃げない、あまり儲けない」を合言葉に日々頑張っておりますので、応援よろしくお願いします。



ページの先頭へ戻る