データエンジニア2人がデータ整備周りの採用難について考える
風音屋 アドバイザーの “たけっぱ”（@takegue） です。
データを整備できる人材が見つからない、採用できない――。 データ活用を考える多くの企業がぶつかる問題です。 どうすればデータエンジニアに来てもらえるのか。 そもそも「データの整備」はデータエンジニアだけの仕事なのか。
風音屋代表の “ゆずたそ”（@yuzutas0）さん と僕のデータエンジニア2人で考えてみました。
※この記事は、YouTube動画「データマネジメント.fm」の第2回目「データ整備の人材獲得」 を書き起こし、加筆・修正したものです。
書き起こし・編集：松本香織
この記事で話していること
- 便利なツールを積極的に取り入れよう
- データを使う人が自分で整備しよう
- 業務を分解して適切な部署に渡そう
- 必要なのは整備人ではなくCDO
便利なツールを積極的に取り入れよう
ゆずたそ：いま、多くの企業がデータを整備できる人材を求めています。でも、データエンジニアはなかなか採用できない。たけっぱさんは、なぜだと思いますか？
たけっぱ：そもそも論になるけど、いいですか？ データを使いたい人はたくさんいる。 一方、「みんなのためにデータを整備したい」というボランティア精神に溢れた人は多くない。 つまり、データエンジニアの絶対数が少ないのではないかと。
ゆずたそ：だとすると、どうしたらいいですかね？
たけっぱ：「データの整備」そのものの負荷を減らしてはどうでしょう？ BigQueryのように（インスタンスの使い分けや管理を考えずに済む）便利なツールを積極的に使い、やるべきことを減らしていくとか。
ゆずたそ：確かにそれは必要ですね。
データを使う人が自分で整備しよう
たけっぱ：あとは、データの整備すべてをデータエンジニアの仕事にせず、データを使う側に一部担当してもらう。
ゆずたそ：ふむふむ。
たけっぱ：データエンジニアとして働いていると「世の中に“きれいなデータ”など存在しない」と分かります。 だけど、使う側が「“きれいなデータ”は存在する」という前提でいると、トラブルが起きるじゃないですか。 そこで使う側にメタデータの整備などを任せれば、データエンジニアの負荷が減るだけでなく、彼らにデータの品質について考えてもらう機会になるかもしれません。 まあ、DevOps（※）的な考え方ですね。
DevOps： 「開発」を意味する「Development」と「運用」を意味する「Operations」を組み合わせた言葉で、開発チームと運用チームが連携しながらソフトウェアを改善する活動を指す。 読み方は「デブオプス」。
ゆずたそ：データを使う側の人材が携わる工程を広げていく。それは健全な発想ですね。
たけっぱ：一部の人だけがデータの整備を担当すると、サイロ化（※）の原因になり、組織のデータ活用を阻害しかねません。 それに、データエンジニアだって「データがバグっているぞ」というクレームを受け続けるのは嫌じゃないですか。 やっぱり組織全体でうまく回す仕組みを作りたいですよね。 ゆずたそさんはどう思います？
サイロ化： 部署ごとにシステムやデータが孤立し、連携していない状態。
業務分解して適切な部署に渡そう
ゆずたそ：「組織全体」という観点からすると、「データの整備」の中身を見直し、適切に業務分解することも重要かなと。 たとえば「分析データのセキュリティ」が問題ならば、情報セキュリティ担当者が担うべき作業があるかもしれない。 全ての作業をデータエンジニアが受け持つのは、無理筋な気がします。
たけっぱ：なるほど。いま「DX推進」のことを思い浮かべながら話を聞いていました。 DXではIT部門にすべてが託され、他の部署は他人事みたいになりがちじゃないですか。 本当は現場の主体性こそが肝心なのに。 同じ構造が「データの整備」にも当てはまりそうな……。
ゆずたそ：「データの整備以前に組織としてどうなのよ」ってことですね。 そういう話は他にもあるかなと。たとえば、ログが汚くてデータ分析に使えないから整備したいとしますね。 アプリケーションから出ているログなら、本来、アプリ開発チームが対応すべきです。 でも、ログを受け取る側がデータを加工して何とか分析に使えるようにする……。 こういうケースでは、アプリ開発チームが疲弊していたり、チーム間の距離が遠くて気軽に相談できなかったりする可能性があります。
たけっぱ：「データの整備」はとにかく大変。 でも、そのつらさに勝る喜びやメリットが提示できれば、かかわる人がもっと増えるかもしれません。 それには 「データを整備する人」と「使う人」を同じにしていくといい のではないかと。 使いたいデータを自分で整備するようになれば、みんなにも使ってほしくて教えるというインセンティブが働くじゃないですか。 でも現在は多くの場合、「整備する人」と「使う人」が完全に分離しています。 このままでは誰かにつらい役割を押し付けることになる……。
必要なのは整備人ではなくCDO
ゆずたそ：どうすれば、この構造が変えられると思います？
たけっぱ：CDO（※）として組織全体を見渡し、データに関する戦略を策定して引っ張っていく人が必要でしょうね。
CDO： 「Chief Data Officer」の略。 「最高データ責任者」の意で、経営的な視点からデータの利活用を考える役割を指す。 最近は日本でもCDOを置く企業が増え始めている。
ゆずたそ：同じ認識です。 みんな現場で手を動かす人を求めたがるけれど、本当に必要なのは戦略の策定かもしれない。 となると、今度は「CDOとしてデータ戦略が策定できる人材」の話になってきますね。 そういう人材は世の中にどのくらい存在しているのか、そして採用できるのか……。
たけっぱ：「いる」とは思います。 いまは大企業であればあるほど、データの重要度が上がっているじゃないですか。 だから絶対どこかにはいる。 ただ、そういう人は……どうすれば採用できるんですかね？
ゆずたそ：僕は最初から幹部候補として迎えたほうがいいと思います。 そもそもがつらい仕事でもあるし、そういう人材には「下積みをして信頼できたらポストを作る」と話しても響かないでしょう。
たけっぱ：確かに。 すでにシステムができあがっていて、データを膨大に持っている企業ほど整備が大変ですからね。 早く始めるほどラクになる。 後からそれをやるとなると、想像するだけでつらくなってきます。 だから僕は新卒入社のときに、早い段階からデータの整備にかかわれる企業を選びました。
ゆずたそ：戦略的ですね。
本日のまとめ
ゆずたそ：では、まとめに入りますか。 「データを整備できる人材はどうすれば採用できるのか」という問いに対しては「そういう人材を求めるのはやめよう」と。 そして次のように対応しましょう。
- 便利なツールを積極的に取り入れ、「データの整備」そのものの負荷を減らす
- データを使う側の人が扱う工程を広げ、整備の一部にかかわってもらう
- 「データの整備」を適切に業務分解し、適切な部署が担う
- データに関する戦略を描ける人をCDOに据える
――こんな結論でいかがでしょうか。
たけっぱ：きれいにまとめましたね。 ありがとうございます！ ……でも、これでいいのかな？ 「データエンジニアが採用できない」という問題そのものは、何も解決していないけど（笑）。
ゆずたそ：きっと大丈夫（笑）。 こうして論点を整理すれば、みんなの道しるべにはなるはずですよ。 少なくとも「人材の奪い合いに疲弊する前に、社内でやるべきことはたくさんあるよ」ということは伝わったと思います。 そういう議論がちゃんとできる環境のほうが、働くうえでの満足度は高くなるでしょうし、結果として優秀な人を惹きつけられるはず！
たけっぱ：確かにそうかもしれない。 今後もデータ整備をめぐる問題を話し合い、論点を共有していけたらいいですね。
CDO（Chief Data Officer）を目指そう！
風音屋 は、各社がデータ人材を奪い合っている状況を打開すべく、データエンジニア育成やデータチームシェアリング（他社への出向制度）に注力しています。
実際にCDOとしてクライアント企業（事業会社）に兼務・出向し、データ戦略を策定・推進している案件もあります。 CDOへのキャリアアップを最短で目指せる環境です。 ご関心のある方はぜひカジュアル面談にご応募ください。
また、ジュニア人材向けには「第2新卒が3ヶ月でデータ人材への転職を目指す講座」を提供しています。 入社後にも一人前のデータエンジニアとして成長できる機会を提供しますので、ぜひご応募ください。
編集後記
今回の文字起こしにあたって、ゆずたそさんから以下のコメントが寄せられました。
ゆずたそ：Youtube動画を収録した当時はフリーランス的に動いていたので好き勝手に偉そうな立場から採用の話をしていましたが、いま風音屋もちょうど採用や育成を試行錯誤しているので、過去の自分に正論を言われて「お前〜〜〜〜〜！」という気持ちになっています（笑）。
