[ザ・プロジェクト]

2009年8月27日(木)田口 潤（IT Leaders編集部）

─ 日本製紙は2006年、BIシステムを導入。ユーザーによる情報活用を進めているそうですね。新システムは、グループ全社に共通なんですか。

井田： まだ全社というわけではありません。今のところ、日本製紙のほか安田が所属する日本大昭和板紙など6社が活用しています。

─ 情報分析用のシステムは、これが初めて？

井田： いえ。2000年にTeradataのデータウェアハウスを導入して、販売や製造といった基幹業務データを、ユーザーが自由に分析できる仕組みを構築しました。

萩原： 約2000人いる営業担当者向けには、日本テラデータのAccess Navigatorを、経理担当者向けにはOLAPツールのEssbaseを、経営層向けには経営ダッシュボード製品のDecision Webを使っていました。

─ 3つのツールを導入していた。

井田： 利用者の属性や目的別に、最適なツールをと考えた結果です。当社は財務会計システムにSAPのERPパッケージを使っているので、財務会計データを分析するためにSAP BWも導入していました。

─ それらを刷新することにした。きっかけは何ですか。

井田： 1つは、情報分析用のシステムが4系統あったので、2重3重の運用管理の手間がかかっていたことです。より大きいのは、営業担当者向けの分析機能はユーザー数が最も多いはずだったんですが、限られた人しか使っていなかった。

─ 高価なツールが使われていなかった？

勝呂： 営業部門を対象にアンケートを実施したところ、生データをそのまま提供するがゆえの使い勝手の悪さを指摘する声が多かったんです。

─ 具体的にはどういうことですか。

勝呂： 従来のシステムでは、取引データを明細レベルのまま蓄積していました。データを開くと、取引先コードや売上金額、販売数量などがずらっと並んでいるだけ。顧客や製品の切り口で分析するには、ユーザー自身が必要なデータをデータウェアハウスから抽出し、それぞれが作ったテーブルと結合する、といった手間をかけなければならなかったんです。

─ ちょっといいですか。それは特殊な分析をするケースですよね？ユーザーの多くが利用できる定型的な帳票は、あらかじめ用意していたんでしょう？

勝呂： そうではなかったんですよ。帳票類はすべてユーザー自身に必要に応じて作成する、という方針でしたから。例えば、月次売り上げ明細もユーザーごとに作ってもらっていました。

─ それは徹底している。データ加工は簡単にできたんですか。国井さんは2009年3月までユーザー部門に勤務していたそうですが、どうでした？

国井： それなりにIT知識を持つ人でないと、難しかったですね。一部のパワーユーザーに帳票作成の負荷が偏っていたと思います。

─ ユーザーからは、さぞかし不満が出ていたでしょう。

井田： それが、そうでもなかった。

─ 「使いにくかったら使わないだけ」ということ？

井田： まあ、そういうことでしょう（苦笑）。その一方で、旧システムではデータの増加にともない、データウェアハウス自体を拡張する必要が出てきていたことや、OLAPのレスポンスが遅い、といった問題もありました。

製品選択の決め手はETL機能

─ 利用率の低さに加えて性能面に限界が見え始めたことで、システム刷新を決めた。プロジェクトが実際に動き出したのはいつですか。

井田： 2005年10月に、システム統合・再構築を検討開始。2006年1月に、従来のシステムから新たなシステムへのデータ移行に着手しました。

─ なるほど。その間を、コンペやベンダー選定に充てたんですね。

井田： いいえ。この段階ではもう、SAS Institute JapanのSAS Enterprise Intelligence Platform（SAS EIP）で行くと決めていましたよ。

─ あ、そうなんですか。

井田： 実は、ベンダー各社が提供する分析ツールを事前に調べておいたんですよ。

─ SAS EIPの何を評価したんですか。

井田： 1つがETL、つまり基幹系からデータを抽出したり、適切な形に変換する機能です（本誌注：ELTはExtract/Transform/Loadの略）。以前のシステムにおいて、ユーザー側にデータ加工の手間が発生したのは、このETL機能がなかったからでした。機能や実績も、もちろん大きいですけどね。

─ ほかには？

井田： ETLと分析ツールを1つのプラットフォーム上で運用できるところも魅力でした。4つの分析ツールを個別に動かしていた従来に比べて、運用管理の手間を大幅に削減できますから。

萩原： SAS製品を選んだ理由はもう1つあります。ユーザーごとのライセンス費用が発生しないという点です。SAS EIPの価格体系は、ユーザー数に関係なく「サーバー1台でいくら」なんですよ。

─ プロジェクト開始前に製品選定はほぼ済んでいた。となると2005年10月からの3カ月間、何を検討したんですか。

井田： 情報分析用のシステムを全面的に入れ替えるという方向性が、ユーザーのニーズと本当に合致しているのかについて、議論を尽くしました。多くの社員が活用しないと、意味がありませんから。最終的に、社内の情報活用を進めるにはシステム刷新が不可欠だという結論を出したわけです。

─ なるほど。では2006年1月のプロジェクト開始では何から着手？

萩原： データ移行です。Teradata上の過去データをいったんCSV形式に変換して、それをSASに取り込んだんですよ。

─ データ量はどれくらいでしたか。

萩原： そうですねえ、400〜500ギガバイトくらいだったでしょうか。

─ 日々新たに発生するデータは？

萩原： TeradataとSASの両方に蓄積するようにしました。

─ そう聞くと、あっさりできたようですが、実際は大変だったでしょう。

井田： 一通り移行を終えたのが2006年10月ですからね。販売予算や実績、在庫といった営業向けデータの完全移行は2007年3月に延期しました。

─ どうして？

萩原： 営業向けデータを作り直す必要が出てきたんですよ。先ほど話に出たように、ユーザーは従来、帳票のテーブルをそれぞれ個別に作っていました。このため、データ項目名がユーザーによってばらばらだったんです。

勝呂： 例えば、取引先の社名です。その会社の正式名称を使う担当者もいれば、略称を使う担当者もいました。略称も、3ケタだったり5ケタだったり。

─ システム刷新を機に、1つの名称に統一すればよかったのでは。

井田： それはそうなんですが、ユーザーからすると、自分たちが慣れた様式で帳票を作って分析をしたいんです。

勝呂： このため、営業関連データの移行をいったん中止。データ項目名を追加する作業を進めました。追加した項目名は、数百あったと思います。

─ 使い勝手を考えると、重複するとわかっている部分も切り落とせなかった。でもそれってユーザーに優しすぎるというか、過保護ではないですか？

勝呂： 項目を無理やり一本化しても、ユーザーとしては抽出したデータを自分たちのこれまでのやり方に合うよう加工するでしょう。それでは、システム刷新の意味がありませんから。

─ 営業向けデータの整備を終えるまで新システムの稼働を延期した？

井田： いいえ、新システムは当初の予定どおり、2006年10月に運用を開始しました。その後、2007年3月に整備済みの営業向けデータをシステムに流し込んだということです。