エンジニアとアナリストの間で兵站を担う「データアーキテクト」は1つの役割として確立しておいた方が良いと思うので整理してみた

「データ整備人(仮)」改め「データアーキテクト」にしよう

という2つの記事を書いたところ思わぬ反響があり、特に前者は非常に多くの人に読んでもらった。どうも自分が考えていた以上にこの役割というか業務に関わっている人は多いらしい。

そこでこの役割が何かを考えると、業務の範囲、求められるスキルの幅広さ、その重要性を考えるとこの役割はデータ活用における「兵站」と表現できそうで、だとしたら一つの役割や職種としてきちんと扱うべきではないだろうかと考えるようになった。

そこで、この役割についての改めて整理する。名前もつけないと何かと不便なので、そのことにも触れる。

「エンジニア」と「アナリスト」の間を埋める役割の存在

まずデータ分析に関わる人には「エンジニア」と「アナリスト」がいる。エンジニアはデータの収集を技術で実現する、アナリストは文字通り分析することで意思決定の不確実性を減らそうとすることが役割だ。

さらにこれらのエンジニアとアナリストの間には様々な仕事があり、うまくやるためには「分析するわけではないがアナリストの視点や経験と、何かを実装するわけではないが多少の技術とエンジニアと話せる知識」が必要になる。

ところがこの役割は「エンジニア」が片手間でやっていたり「アナリスト」の肩書なのにこちらばかりが主業務になってしまうことで不満が溜まっているという話を聞く。

誰かがやらないと別の誰かが困るのにその役割に名前もなく、他の仕事のおまけのように邪険に扱われ、やってもまともに評価されないというなんとも不思議な状況だ。

どこかで聞いたことがある話だなと思ったらそれは多分正解で、これは「アナリティクスディレクター」とは「データ分析プロセスのマネジメントを行い、様々な部署や人とのつなぎ役となる役割」であると状況が似ている。

もしこの仕事を誰もやっていないと思ったら注意してみたほうがいい。

  • 気づかないところで誰かがやっているが評価されないので不満が溜まっている
  • 誰もやっていないので実は生産性がひどく低い状態のままであることに気づいていない
  • エンジニアないしはアナリストが業務の1つとしてやってはいるが片手間&本来やるべき役割がおざなりになっている

といった状態になっている危険がある。

「エンジニア」と「アナリスト」の間には具体的にどのような仕事があるのか

これだけでは抽象的なので、具体的にどういった仕事があるのかを列挙してみよう。

この中には「それはエンジニアの役割では」「それはうちではアナリストがやっている」という話は当然あると思うが、まずは「エンジニア」と「アナリスト」が本来の役割だけに集中できるとしたらそれ以外は何があるかという視点でみている。

データ収集の企画・設計

エンジニアはどのように技術で実現するかを考えて実行するのが役割だとしたら「どんなデータを集めるか」を考えるのは別の人の役割であろう。これはエンジニアは決められたことを実現するだけと言っているわけではなく役割の違いだ。

データを集めると言っても検討することはデータの種類だけでなく、量も対象になる。それには当然予算との兼ね合いもあるし、保管についても検討する必要があるだろう。どこかに保管はしてあっても取り出すのにとんでもない負担がかかるのでは保管しておく意味も薄れる。

それと忘れてはならないのは設計する際には最終的に誰がどう使うのかについても考えることだ。誰も使わないデータを集めたところで何の利益にもならない。

ということは技術面では何をどう実現していくかをエンジニアと折衝する一方で利用者であるアナリストとはどういったデータが必要なのかを協議しながらデータ収集の企画・設計を行う役割があるということだ。それはエンジニアかアナリストどちらかがやるのではなくまた別の役割だと考えるほうがよいだろう。

データの管理

あらゆる区分は誰も管理しないと、同じ意味なのに表現が違ったり重複が起きたり知らないところで変わってしまったりとすぐにデータが汚くなる。性別1つとっても「1,2」といった値にするとして、それを数値型で持たせるのか文字列で持たせるのかは些細なようでバラバラになっているとあとで面倒だ。

同じように、データをどのように扱うかも混乱が起きやすい。リピーターはどれぐらいの期間が空いたら、週の初めは日曜なのか月曜なのか、年齢は何歳以上は異常値と見なすか、古いデータを使わないならいつからを正規のデータと見なすか、などいくらでもあるが誰も管理していないと隣に座っているのに扱い方が違うなんてことも起きる。

他にも数年前のデータを使おうとしたらその値の意味を誰も知らず、作った人ももういない、調べるために過去の記録を探したり知ってそうな人に聞いて回ったり、という経験がある人は少なくないだろう。

やはり誰かが管理しなければならない。ルールを策定・運用し、データが常に綺麗な状態となっていればすぐに躊躇わず使うことに集中できる。データの内容を毎回調べなければならないのは本当に時間の無駄だ。

また、あちこちでいろいろな人が色々なところをいじっていると以前は取っていたはずのデータが取れていなかったり、2重に取るようになってしまったりということはよくある。なので正しくデータが取られているかを監視し、正しくない場合は原因の調査と特定、エンジニアへの修正を依頼することもここに含まれるだろう。

理想としては社内での統一ルールを作り、管理する人に従わせる権限を持たせることであろうし、それ以外に正しいデータを保つ手段はないのではないか。

データウェアハウス・データマートの企画・設計

データレイクに集められたデータはアナリストがそのまま使えるような状態になっていないのが普通である。そのまま使おうとしても整理されていなかったり無駄なデータが多いので、使えないことはなくてむ非常に無駄が多くなる。

なので事前に使いやすいように整理したり、特定の目的に合わせてさらに整理・加工しておくことで業務を効率化しておくことは重要だ。

システムによらないデータの収集・管理

データというとログや会員情報などシステムによって生成され、データベースに入っているデジタルデータを思い浮かべる人も多いだろうがそれだけではない。

例えばFYIとしてメーリングリストやSlackに様々な情報・データが流れてくるが、これをきちんと管理している企業はどれぐらいいるのだろうか。

大抵は個人任せで非体系的だろう。なので企業やチームとしての知識にならない。業界知識、技術動向、様々なメディアにばらばらに発表される有用な情報、リクルートのための人材動向などを欲しい人が欲しい時に入手できる環境は手間をかけて作らなければならない。

データに関する依頼への対応

営業・マーケターなど分析を本職としない人がデータを利用したいと思っても実現できるプログラミング能力を持つ人は少ないのが当然だ。だからといってエンジニアに依頼しても片手間にやっているとごく簡単な依頼でも毎回1週間待ちになっていてはやる気も失せてしまう。

アナリストがやればという意見もあり、実際にそのようにしている企業もあるが、アナリストの本文は「分析」することでありいくらデータの扱いが得意だからといってこの仕事ばかりになって分析ができないのでは元も子もない。

なのでこれも切り分けて「エンジニア」と「アナリスト」の間にあると考えるのが良さそうだ。もちろん実際にはきっちり切り分けることは現実的でもないしその意味もないだろうが、それでも違う役割だと明示しておく方が判りやすい。

具体的には以下のようなことになる。

  • 依頼内容を整理し、どういったデータが必要かを考える
  • 依頼者が求めていることと依頼内容のギャップを見つけて埋める
  • データが無かったり足りない場合に代替案の提示
  • 工数と納期が合わない場合に代替案の提示
  • 依頼に基づいてデータ主にSQLを使って抽出する

データ分析プロセスにおいて、要求フェーズから収集フェーズの部分を技術的にサポートしている、と解釈するとわかりやすいだろう。

BIツールの活用

ダッシュボード設計・作成するのはもちろん、項目の追加変更やデータが代わった場合にメンテナンスすることまで含まれる。どういったツールを使うかの選定に関わることもあるだろう。

この役割は実に幅広い

以上、「エンジニア」と「アナリスト」の間にある仕事を概観してみたが、実に幅広い。もちろんこれらを全て1人で高レベルに行うことはできない。それはアナリストがあらゆる分野のあらゆる手法を使えるわけではいのと同じだ。

現状これらは大体「エンジニア」や「アナリスト」が本職ではなくその合間に仕方なく行っているようだが、本職が忙しくなればそうでない仕事は後回しになるし、求められるスキルも経験もそれらとはまた違う。

だからといって誰もやらないとデータは滅茶苦茶、営業やマーケターがデータを必要としても簡単に出てこない、データの定義はあちこちで違うらしいけれども何が正確なのかも調べられないなどあちこちで仕事が滞るので必要ないということは決してない。

そしてまた奇妙なことに、この役割には名前が無い。名前が無いから「あのへんの役割」と存在自体がもやっとしておりわかりづらさに拍車をかけている、というのがこの役割の現状ではないだろうか。

そこでまず名前を付けたほうがよさそうにも感じるが、果たして本当に必要なのか。

この役割に新しく名前を付ける必要があるのか

「わざわざ新しく名前を付ける必要があるのか?」と思うのは当然だと思う。実際のところ、直接関わっている人の中だけであれば「あのへんの仕事」でなんとなくは通じるだろう。

しかし、上記のように非常に実に幅広い役割について当事者だけでなんとなく伝わるだけでは何かと不便だし、それ以前に当事者の間でも日常の会話ではなんとなくで済んでも実務ではそうはいかない。

さらにこの仕事の経験が無い大半の人には名前が無いとどういった仕事をしているのか伝える術が存在しない。そうなると経営者、上司、他部署の同僚、クライアントには何をしているのか伝わらない。

その弊害はすでにあちこちで起きていて、認知されないから重要性が理解されず金も人も使われない。評価もろくにされないので給料は増えないし、転職しようにも他の会社も似たような状況だから何をしているのかを伝えることも難しい。

挙句の果てには「データアナリスト」や「データエンジニア」の業務だと理解されてしまって、求人においてもこの混乱が非常に見える。「データアナリスト」だというから入社したら実際にはこの仕事ばかりで分析はどこへやら、なんて話も随分聞く。

さらに言うと、名前が無いのは重要でないからとばかりにこの役割が雑用扱いされている感もある。直接関わっている人でもそう考える人もいるのだからそうでない人からみたらなおさらだろう。

そう考えると、名前を付けることで1つの役割として認識してもらう必要はあるのではないか、というのが結論だ。

そこで、この「エンジニア」と「アナリスト」の間にある役割を「データアーキテクト」と呼ぶことにしたい。

なぜ「データアーキテクト」と呼ぶことにしたか

そこでこの役割を「データアーキテクト」と呼ぶことにしたい。「データ整備人(仮)」悪くないとも思っていたのだが

  • 役割を整理してみると「整備」だけでは表現しきれない
  • 他の役割と並べるとカタカタの方がおさまりが良さそう
  • 「整備人」だといまいち雑用っぽい

といったのが理由で他の名前を付けた方がよさそうだと考えた。

そこでどういった名前にしようか考えていたところ、システムアーキテクト試験にあったシステムアーキテクトの業務と役割を見つけた。

 (1) 情報システム戦略を具体化するために、全体最適の観点から、対象とする情報システムの構造を設計する。
 (2) 全体システム化計画及び個別システム化構想・計画を具体化するために、対象とする情報システムの開発に必要となる要件を分析、整理し、取りまとめる。
 (3) 対象とする情報システムの要件を実現する最適なシステム方式を設計する。
 (4) 要件及び設計されたシステム方式に基づいて、要求された品質を満足するソフトウェアの設計・開発、テスト、運用及び保守についての検討を行い、対象とする情報システムを開発する。
なお、ネットワーク、データベースなどの固有技術については、必要に応じて専門家の支援を受ける。
 (5) 対象とする情報システム及びその効果を評価する。

IPA 独立行政法人 情報処理推進機構 システムアーキテクト試験

この「システム」を「データ」とすると概ね合っているのではないか、ということで「データアーキテクト」が良いではないかと考えた(ちなみに「ソフトウェア」は「データマート」でよさそう)。

なおデータアーキテクトというのは新しい言葉ではなくすでに使っている企業もある。まったく新しい名前を付けるか迷ったがあまり言葉だけ増やしても仕方ないので既存だがしっくりいく言葉にした。

これはこのブログでそう言っているというだけなので、別の人が違う役割を指しているから間違えているといったことではない。その場合でも概ねは同じような役割のことを言っているだろうから大きな混乱はないと思うが、それでも正確なところはやはり都度確認して欲しい。

データアーキテクトについてのいろいろな話

実は他にもいろいろ書いていたのだがあまりにも長すぎるので記事を分割することにした。

  • データアナリストやアナリティクスディレクターとの関係
  • データエンジニアとの関係
  • BIエンジニアとの関係
  • データアーキテクトはデータの民主化で何を担うのが良いか
  • データアーキテクトの仕事ははいつか自動化されるか
  • データアーキテクトはどんな人がやればよいか
  • データアーキテクトは雑用なのか
  • データアーキテクトの不在がもたらすこと
  • データアーキテクトの仕事はなぜこうも嫌われるのか

また都度書いていこう。

データアーキテクトは「兵站」である

データアーキテクトを一言で表すとしたら、これはデータ活用における「兵站」と言えるのではないだろうか。

データ分析プロセスを食事に例えてみるとアナリストは料理人であるが、プロセスの中には出てこないデータ(食材)を集めたり育てたりするデータエンジニアは生産者にあたる。となれば生産者から料理人に食材を運んだり、必要な加工を行う人がどこかにいるはずで、それがこのデータアーキテクトにあたると考えられる。

だとすれば、なるほど情報とともに兵站も軽視する日本の文化においてこの役割が無視ないしはおまけや雑用として扱われているのは当然だったのかもしれない。その文化に一石を投じることになれば幸いだ。