初めまして、2021年9月より経済産業省に参画しました浅見と申します。本日は簡単な自己紹介とコラム的なものを手短に記載しようかなと思います。

1. 自己紹介

改めまして、浅見と申します。他の情報プロジェクト室のメンバー同様、私も民間出身の人材です。ただ、少し特殊なのは、ファーストキャリアは法務省だったので、行政(法務省)->民間->行政(経産省)の出戻り組です。

法務省退職後は、損害保険会社や証券会社、外資コンサルティングファーム、直近ではタクシー配車アプリを手がける企業のAI技術開発部でデータサイエンティストをしておりました。

この度、ありがたいお声がけをいただき、行政の世界に戻ってきました。在任期間中は、新卒（法務省）時代の宿題を返すつもりで、微力ながらデータ利活用の分野で貢献できればなと思っております。

よろしくお願いいたします。

2. データサイエンティスト？なにそれ

「データサイエンティスト」はバズワードなので、人によって定義が少しずつ違うのかなと思います（時々、この言葉を巡って仁義なき定義論争が巻き起こることも・・・・・・）。

私は、（全くMECEではなく粗い分類なのですが）以下のような数理科学の知識と実装能力を持つエンジニアのことをデータサイエンティストと呼んでいます。

補足-1： 全部に精通しているデータサイエンティストはおそらくいません。分野によってはほとんど素人状態というのも普通です。それでも、「だいたい機械学習であればこんなことができるな」「この問題は〇〇の専門家なら解けるかもしれないな」といった大まかな分野地図を有しているのかなと思います。

補足-2：「ビジネス力が入っていない！けしからん」という指摘もあるかもしれません。ただ、（ビジネス力をどう定義するか次第だと思うのですが）ある職種を定義する際に、ビジネス感覚から独立であることが許される職種なんてほとんどないと思うんです。当たり前すぎて（情報量がほぼゼロなので）、あえて入れる必要もないのかなと思います。

データサイエンティストと一言でいっても、蓋をあけてみると、上の図からわかるように色々な専門性の方がいたり、理論系に強い学者肌の方や、データエンジニア方面に強い方など多様な人材がいる不思議な職種かなと思います。

企業・事業所の目的に応じて必要なスキルセットは変わってくるので、「○○が真のデータサイエンティストだ！」と汎用的な定義を考え込むのはあまり意味がないのかなと私は思います。今後、私のnoteでデータサイエンス/データサイエンティストは上記のような緩い意味で使用かと思います。

💡 データサイエンティストの緩い定義：　　　　　　　　　　　　　　　　　　数理科学の知識と実装能力を持つエンジニアのこととする（どこを強調するかは、それぞれの組織/プロダクトの目的や役割によって異なる）

3. これからやること（仮）

小職にとって最初の記事なので、今後どんなことに力を入れていくか簡単に箇条書きで記していこうと思います。

まずは、（いきなりは）やらないことから、、、

❌ やらないこと１：いきなりAIプロジェクト

私はAI、より正確に言えば、機械学習（以下、「ML」と言う。）ありきでプロジェクトをスタートさせるのはあまり好きではありません。

「最新のAI/MLを使った 〇〇」というのは、プレスリリース的には見栄えの良いものかもしれませんが、手段と目的の峻別は重要です。

いきなりMLありきでスタートするのではなく、何を（どんなメトリクスを）最適化したいのか、そのメトリクスを監視できるような体制はあるか、といったところから考えるのが王道かなと思います。

冷静に考えてみると、今のステータスでMLを無理に導入する必要がない（開発及びメンテナンスコストに見合っていない）なんてことはよくあることなので、冷静に順を追って考えてみることが重要かなと思います。

💡 MLは問題解決手法の一つであり、あくまで目的は課題を解決することです。MLを使うことを目的としてはいけません

❌ やらないこと２：いきなり立派なデータ分析基盤の構築

当たり前ですが、霞が関はデータサイエンティストにとって、恵まれた環境とは言えません。PCの性能制約はもちろん、インターネット接続制限、使えるツールの規制など、民間（特にITベンチャー）の開発環境に慣れてしまった者にとってはかなり不便な環境です。

個人的には「”イケてる開発環境”、早急に欲しい・・・」が本音ではあります。

ですが、今の状況でコストをかけて、イケてる分析環境基盤を作るのはかなりリスクがあるかなと個人的は思います。「コストをかけたけど、誰も使ってくれなかった（使ってくれなくなった）」事案は、民間企業でもよく見てきました。

具体的な分析ニーズから独立した「良い」分析基盤というものは存在しません。少しずつプロジェクトをこなしながら現場に根付いた分析環境を築いていきたいと考えています。

ちなみに、経産省でもPythonの一般的な統計/MLライブラリーは使用できますし、gitも共有フォルダで（やろうと思えば）使用できます。個人的には、もっと厳しい日系企業で働いた経験もあるので、絶望的な環境というわけではありません・・・。

💡 まずは、手元の環境でスモールスタート。徐々にベストプラクティスをスケールさせていきたい。

⭕️ やっていくこと１：再現性のある集計＋α

「難しいことやりたい！」「（流行りの）Deep Learningで何かしたい」など、それが知的好奇心から来るものであれば、こういった衝動は決して否定するべきではないかなと思います。

ただし、やはりデータ分析の基礎となるのは、データの加工及び集計を正確に、かつ再現性が確保された状態で遂行できる能力だと思います。

品質が怪しい野良データマートからできた高度なモデル／分析より、しっかり検証されたデータマートからできたモデル／分析の方が、たとえそれがシンプルな線形モデルだったとしても、私は後者を選びます。皆さんも同じですよね？

テック系の大企業であれば、データエンジニアと分析官の分業も可能かもしれませんが、多くの組織ではそのような幸せな状態は望めません。まずは、地道に基礎体力作りから始めていきたいと思います。

💡 データの前処理は確かに地味。でも、この大切さを一人でも多くの職員に伝えるのが使命だと勝手に思ってます。Excelコピペは本当に危険ですからね・・・

※ 現在、他部署と協力して実践研修を実施中です。一人でも多くの職員がSQL /Pythonと仲良くなってくれるよう研修を盛り上げていこうと思います。

⭕️ やっていくこと２：よりよいデータドリブンな組織風土に向けての議論

データ分析（特に効果検証系のプロジェクト）は基本的に「不都合な真実をみる」という苦行です。

ここで大切なのは、高度な分析技術や高価なインフラではなく、組織風土と適切な制度設計です。これがなければ、必ず分析系のプロジェクトは形骸化すると思います。

これに対して残念ながら万能薬といえるソリューションがあるわけではなく、現行の制度や課題を丁寧に整理しながら、職員一丸となって議論していく他に道はないと考えます。

幸いにも、経産省は風通しがよく、幹部も含めてEBPMに関心の高い人も多い。少しずつ仲間を増やして、経産省におけるEBPMの文化を根付かせていきたいと思います。