日本データマネージメント・コンソーシアム

会員コラム

【vol.70】協和キリン 岩本晃幸さん、事業会社のIT部門が「データマネジメント」推進に求められることってなんだろう?

JDMC会員による「リレーコラム」。
メンバーの皆さんそれぞれの経験・知見・想いをリレー形式でつなげていきます。今回、バトンを受け取ったのは、協和キリン株式会社の岩本晃幸さんです。

 

協和キリンはグローバル・スペシャリティファーマとして日々奮闘している製薬企業です。 

皆様、はじめまして。2021年よりJDMCに参画しました、協和キリン株式会社の岩本と申します。

まず初めに、簡単に協和キリンの紹介をさせていただきたいと思います。

協和キリンは2008年に協和発酵工業とキリンファーマの合併により発足した、バイオテクノロジー、抗体医薬を強みとする製薬企業です。また、2030年に向けたビジョン「日本発のグローバル・スペシャリティファーマとして病気と向き合う人々に笑顔をもたらすLife-changingな価値の継続的な創出を実現」を達成すべく国内外問わず日々邁進している会社です。

そのような会社の変革期に立ち会うべく、私は2019年12月に俗にいうITコンサルから協和キリンに転職し、データ・クラウドに関わる仕事に従事しております。  今回は、「事業会社のIT部門が「データマネジメント」推進に求められることってなんだろう?」というテーマでの私見をコラムとして書かせてもらえれば、と思います。

 

製薬企業にあるデータってなんなんだろう

社内にはたくさんの種類のデータが存在します。例えば一以下のようなものです。

  • 研究領域:化合物のデータ、遺伝子の画像データ、論文のデータ
  • 開発領域:非臨床・臨床試験のデータ、当局への申請データ
  • 生産/SCM領域:生産計画のデータ、工場のIoT機器のデータ、受注/出荷/在庫といった基幹業務のデータ
  • 営業領域: MR(営業)の訪問計画/実績のデータ、医師/病院のデータ、有害事象報告のデータ
  • 共通機能領域: 人事データ、財務データ、法務データ

これらのデータには、内部生成/外部購入/オープンデータといったデータ発生元の違いや、構造化データや非構造化データといったデータの形式の違いが存在しています。また、製薬業界は規制業界でもあるため、データの種類によってはALCOA(※)といったような厳格なデータ保全のための基準が求められます。

(※)Attributable(データ生成者に帰することができること)、Legible(読みやすく恒久的であること)、Contemporaneous(同時的であること)、Original(オリジナルであること)、Accurate(正確であること)の頭文字をとったもの。

 

データっていったい誰の物なんだろう

では「それらのデータはなぜ生成されるのか」と考えたとき、企業内においては以下の2つの理由があると、これまでの私の経験上考えています。

  • 自分の業務のインプットとして参照/引用したいため
  • 自分の業務のアウトプットとして記録に残したい/他メンバーに伝えたいため

上記を踏まえ、生成・参照、管理、保管場所(器)の観点でデータを整理すると、

  • データを生成・参照する人:(IT部門も含めた)業務部門の担当者
  • データを管理する人:(IT部門も含めた)業務部門が定めた責任者
  • データを保管する器:ベンダーやIT部門が構築したシステム

となるはずです。

我々IT部門は上記を踏まえてデータマネジメント推進を行っていきたいのですが、ここで、業務部門のよくあるスタンスに「システムを作っているのはIT部門・ベンダーなんだからきちんと中身のデータも管理してよ!!」というのがあります。

 気持ちはわかります。             

器(システム)が難解だったり、簡単に手が出せない位置にあったりすると、どうしても「器の中身のデータ」についてもIT部門やベンダーに全てを頼りたくなりますよね。とはいえIT部門としても、「器の中身のデータ」の背景となる業務をすべて理解しているわけではありません。だからこそ、業務部門とIT部門が歩み寄って一体となり、データと器(システム)の両方を適切に管理していく必要があるのです。

 

データをマネジメントする って何だろう?        

私の思うデータマネジメントのポイントとして、以下2つがあります。       

1.役割や責任範囲を明確化し、それらを業務的にかみ砕いた言葉でわかりやすく明確に定義する。

例えば〇〇さんに「あなたは明日から「データオブエクセレンスオーナーフォーカスタマー」として顧客マスタを管理してね」と言ったとします。〇〇さんは「?」だし、全力でその職務を拒否するでしょう。意味不明な責任を負いたくないですし。       

上の例は誇張して書いたので皆さん失笑してもらえていると思いますが、実はこれって現実の業務でよく起きています。「あなたがデータオーナーです」と簡単に言ってしまっていたりします。特に外部から関わる人々に上記の傾向が大きいように感じます。         

このようなミスコミュニケーションを避けるためにも、事業会社のIT部門のデータマネジメント推進担当は「業務部門に寄り添って業務の言葉で何をしなければいけないのか」を定義するのが最も重要だと思っています。            

例えば、「データスチュワートとして、顧客マスタを管理する」という1行に対しても、

  • 社内ユーザへの役割の周知
    「顧客マスタは一度この人/部門に聞こう」ということを社内のユーザに認識してもらう。その為に職務分掌を更新する、その他の手段で周知する、等の手段を検討する。           
  • 業務イベントや関係者の整理
    顧客マスタが「生成・更新される業務イベント」や「廃棄すべきタイミング・業務イベント」をあらかじめ整理する。データ生成/更新/削除時に確認/承認/周知が必要な関係者を整理する。
  • データ生成/更新時
    ユーザからの顧客レコード追加依頼を受けて、顧客コードをルールに従って発番する。ユーザが申請してきた属性項目について、整理した各担当部署に妥当性を確認する。追加された情報を利用ユーザに共有する。
  • データ削除時
    整理した業務イベントに基づき、定期的に使われていないレコードを棚卸して削除する。その内容を関係者に確認・周知する。       
       
  • データ参照時
    ユーザからの問い合わせに対応する。

というような業務の定義が必要です。ここまできて初めて業務ユーザも納得して責任を負ってくれるはずです。

 

2.業務部門の役割や責任範囲がうまく回るようにサポートする。

上記1.で、「役割や責任範囲を明確化する」と書きましたが、「責任範囲や役割は決めたのでやってください」と突き放すのではなく、データマネジメント推進担当として、各業務ユーザのタスクをサポートすべきだと思っています。

依頼する業務ユーザにとって、初めての業務であったりするので、最初はうまくいかないケースがあります。その際には、IT部門として誠意をもってサポートするべきだと思います。ただ最初に、「役割と責任範囲を明確にする」をしておかないと、ただただIT部門がすべてをやらないといけない、という事態に陥ってしまいがちなのが注意点です。 「お互い助け合うけど依存しない」そんな関係を業務部門とIT部門間で築けるのが一番だと思っています。

このように、「業務に寄り添って業務部門が自立した形でデータマネジメントを行っていく」ことを目指すのが事業会社のIT部門のデータマネジメント推進の目標だと思っています。

 

最後に

新卒の時、当時の社長は次のように言っていました。

「ITコンサルタントとして最も重要なのは、業務とITの両方を理解し、推進していく事である」            

役割やポジションは変われど、そのスタンスをぶらさずに仕事をやってこれたことが、今この「データマネジメント推進」に役立っているのかなと思っています。そして、これまで概念的なことを語ってきましたが、直近の最大の課題は「財務指標レポートの数字突合」という感じで、泥臭い仕事もしています(笑)

今後はコミュニティへの参画を通して、JDMC及びデータマネジメントの発展に微力ながら貢献していきたいと思います。どうぞ、よろしくお願いいたします。

 

岩本 晃幸(いわもと てるゆき)
協和キリン株式会社 ICTソリューション部 DX推進グループ

1981年生まれ、京都出身。
2006年にIBMビジネスコンサルティングサービス(現日本IBM)に新卒入社後、2012年にアクセンチュアに転職。その間、SAPやSalesforceといった基幹システムからのデータ連携、DWH/BI構築に従事。2019年12月に協和キリンに転職後は、より業務ユーザに近いポジションにて、より幅広い業務分野に対するデータに関わる仕事を推進中。

 

 

RELATED

PAGE TOP