導入事例〜製造業のデータ分析基盤を支えるメンバーの育成〜
約1,000名が利用する製造業のデータ分析基盤
創業90年以上、従業員約2,000名の国内大手製造業の会社で、すでにデータ分析基盤のツール（DataSpider・Dr.Sum・MotionBoard）を導入済みのお客様に対し、運用コストを抑えた構築手法と、以降の構築を内製化できるようにメンバー育成を実施した。
お客様が抱えていた課題
ツールを導入した業者の製品知識の低く、信頼できなくなった
BIツールを導入した業者のコアメンバーが退職してしまったことを境に、製品に詳しい人がいなくなってしまい、業者に問い合わせても「メーカーに確認する」という回答が返ってきて、その業者を頼ることができなくなってしまった。
独学で構築したため、管理に工数がかかっていた
自社内で製品マニュアルを読みながら構築を進め、一通りを完成させたが、使用している機能に一貫性がなくそれぞれが独立して動いていたため、エラー時の復旧や全体を管理するコストが膨大になっていた。
弊社からの提案
上記を課題に感じたお客様は、独自にDataSpider・Dr.Sum・MotionBoardに詳しい業者を探し、弊社にお声掛けいただいた。
弊社からは以下の点を提案した。
- ・運用コストの低い構築が可能なサンプルの提供
・内製化するためのメンバーの育成
また弊社はお客様が自社内でデータ分析基盤を操作することを望んでいるため、弊社に支払う月額の保守料を年々下げていき、内製に力を入れる方針を提案した。
実施内容
テクニカル
運用コストを抑えたDataSpiderの構築
着手前の状態はDataSpiderのスクリプト、DataLoaderのトリガー、Dr.Sumのタスクスケジューラが混在し、100本近い処理が非同期で実行されていて、エラーの検知も難しい状態であった。
そこでDataLoaderのリアルタイム機能の必要性を確認した後、DataSpiderとDr.Sumの仮想テーブルからのデータ取り込みに処理を統一し、３世代スクリプトを作成することで、夜間処理と日中処理を一本化した。
※詳細の方法については下記の記事に記載している。
Dr.Sumのメンテナンスや構築のベストプラクティスの提示
Dr.Sumのテーブルの再構築やバックアップのタイミング、また仮想テーブルを使用すると裏でワークテーブルを作りながらデータ取り込みを行う点などを活用し、管理のしやすいデータベースの作り方やチューニング方法を伝達。
また複雑なビューを組んだ際のレスポンスを考慮したテーブル実体化のプランを提示。
流用できるMotionBoardのダッシュボードや構築手順の提供
ダッシュボードは形状を似せたテンプレートを流用することで、ユーザーへの新しいダッシュボードへの慣れや運用コストを減らす効果が期待できる。実務で流用しやすいテンプレートの提供を実施。
またダッシュボードの要件定義に必要な項目など一般的にダッシュボードを構築しやすい手順をレクチャー。
チームビルディング
すでに企画部門で３名、システム部門で２名、事業部部門で１名のメンバーがアサイン済みの状態であったが、それぞれが個々に開発作業を実施していたため、メンバーのタスクや能力が顕在化せず、同じ悩みを個々で解決することもある状態であった。
チームの体制を確立するための仕組みと個々のモチベーションを上げ、データ分析基盤を支えるメンバーとして自立性と協調性を持ち、管理・運営に取り組んでもらえるように以下の施策を実施した。
Backlogによる課題管理でメンバーの課題やタスクの共有
Backlogを効果的に活用することにより、個々のタスクの顕在化を実施。また弊社への質問をBacklogに記載していただくことで、課題の可視化をし、横からメンバーが補足を入れたり、共通課題の解決につながった。
wikiの機能に自社のノウハウを溜めることで、例えばバージョンアップの手続きや検証方法など、数年に一度の作業の手順書になり、引き継ぎの際のコストを減らす役割も担っている。
また特に下記の点では弊社サポートについてお客様から高く評価をいただいている。
レスポンスの良さ
弊社の担当メンバーは１名だが、Backlogに投稿された課題に対してのレスポンスの速度に高く評価をいただいている。また回答をする際にもお客様環境を確認し、解像度の高い状態で回答をするので、キャッチボールの数が少ない。
状況に応じて個別ミーティングを設定
課題の内容によっては言葉やキャプチャだけでは発しにくい情報がある、また弊社側にも質問があり、キャッチボールの数が多くなることが予測されるときにはWebミーティングで画面を見ながら直接会話をすることで、コミュニケーションにかかるコストを減らしている。
課題に対しての複数ツールに対する問題の切り分け
課題に対しての回答が単体ツールでの解決ではなく、実施工数や管理・運用コストを鑑みて複数ツールを跨いだ解決策を提示している。また他部門のシステム管理者にどのように質問をすべきかなどのコミュニケーションを含めた総合的な解決策を提案している。
定例会で積極的に意見を出し合う
月例で定例会を実施している。定例会では以下の内容を共通の議題としている。
共通の課題の周知や対策の議論
バージョンアップや全体に共通するエラー、さらにメンテナンス系などの状況報告は担当者以外も把握する必要がある。文面だけの周知だと熱量が不足するため、担当者との議論の様子を共有している。
個々の目標と進捗、および成果物の共有
個々の実績を本人から共有する。自分の活動内容や苦労をした点を中心に共有してもらいメンバーよりフィードバックをする。この定例会で実績を報告するために自分のタスクを棚卸しし、言語化することが第一歩となる。やがて共有内容の質が上がり、メンバー固有の特長が共有内容に反映されてくる。
弊社からの新しい情報の共有
自部門の業務や既存製品の知識だけでなく、現在のAIの使われ方や実践方法などメンバーの刺激となる情報発信をし、外部からの情報に敏感になってもらう機会を作る。
情報発信の重要性やモチベーション向上への取り組み
定例会で個々の個性のあるノウハウを蓄積したタイミングで外部への情報発信の機会を検討する。小さなイベントで情報発信をすることからスタートし、その情報を受けた方々の感想を見つつ、情報発信の重要性や、イベントでの情報収集の必要性を体感していただく。
実施効果
弊社にお声掛けいただいて約１年でテクニカル面の基盤づくりを実施し、管理・運用コストを落とすことに成功。並行して定例会をしてチームビルディングを実施。お声掛けいただいてから２年後には、定例会で積極的に発言をするメンバーが増加した。
また自社で経験したノウハウを外部コミュニティで披露するメンバーも増え、チームの士気が上がった。自社のデータ分析基盤の構築やそれらのノウハウを積極的に情報発信していった結果、メーカーのコミュニティでAWARDを受賞するまでとなった。