自分の技術力、分析力はどこだろう？
アイシア=ソリッド氏：マスターのストーリーはどうでもいいんですよ。過去の話だから。私はみなさんに、あなたのストーリーを始めてほしい。そう思ってここに立っています。では、あなたのストーリーを見てみましょう。
実はあなたは、やり方を知っているし、おもしろい仕事をすることは絶対にできます。あとでお伝えしますが、順番を踏むのはやったほうがいいんじゃないかと思います。
まず「自分の技術力、分析力はどこだろう？」というのを、ちょっと考えてみましょう。例えば、分析結果から意味のある洞察を得たり、意思決定できますか？ 平均を比べるとか、なんとか率が2パーセントと2.5パーセントで違うとか、そういうのでいいです。とにかく数字から自分の意見を出したり、なにかを読み取ったりできますか？
例えば、Excelでできるような分析はできますか？ たまに、Excelのことをバカにする人がいますが、Excelをバカにしちゃダメです。Excelは極めて便利でメチャメチャ使いやすいし、動きも早いし、いろいろなことができるツールですから。
「これさえできればほぼ大丈夫」という重回帰分析もできます。重回帰分析の発展系でメチャメチャいろいろなモデルも、もうなんでもできます。Excelオタクになる必要はありませんが、平均や分散、クロス集計などはちゃんとできますか？
“多変量解析”というものを聞いたことがありますか？ Python、R、Stanは使ったことがありますか？ マシンラーニング、ディープラーニングはどうですか？ まずこれを自分に問うてみるところからではないかと思います。
忘れがちですが、やはり自分のビジネス力が、仕事でデータを使っていくことにおいては最も重要になります。
例えば、対象のドメイン知識、自分がやっている事業はどのような構造でできているの？ どうしてそのデータは生まれてきているの？ どこが勘所で、どこをよくしたらこの世界はよくなるの？ この事業は伸びるの？ それをちゃんとわかってますか？
自分が「分析やろう！」となったときに、巻き込める人数は何人いますか？ データサイエンスは1人ではできません。「できるものならやってください。よろしくお願いします」という感じですが、まあできません。
簡単なExcelレベルでちょこちょことか、1歩目、2歩目、3歩目と踏んでいく部分はもちろん1人でできるし、ぜひがんばってほしいところです。ただ、本当に会社で分析プロジェクトをやって、分析文化を作ろうとなったら、1人ではできません。
それをやったときに、自分のことを信じてついてきてくれる、一緒にやってくれる仲間は何人いますか？ 人を巻き込もうと思ったときに、自社の人はどういうことならテンションが上がって、どういうことのためなら取り組もうとしてくれますか？
このあたりはDeveloper eXperienceともかなり関わるところですが、みんなは何が楽しくて、何ならやりたいですか？ そういうことを、ちゃんと知っていますか？
最後に、ビジネスに影響を与えない分析は結局はすべて無意味です。「楽しかった」で終わっちゃうだけです。なにかビジネスにインパクトを与える、つまり顧客に価値を届けることを絶対にやらなければいけません。何をしたら、あなたのビジネスはよくなりますか？ それを知っていますか？
ここを押さえておかないと、「機械好きがまたなんか始めたわ」で終わってしまい、みんなに広げることができません。こういうところも踏まえて、しっかりと日頃の行いからなにから、修行を積んでいくことが大事だと思います。
めっちゃつまんない話でしょ？ 夢のような、魔法のような、これをやったらAIでDXでディープラーニングでボーン！ かと思いきや。でもね、現実はこんなものです。
自分の得意不得意を可視化するチェックリスト
ここからは具体的な話をしていきましょう。まず、スキルのアセスメントには、「データサイエンティスト協会スキルチェックリスト」というものがあります。これメチャメチャ便利なので、ぜひ使ってほしいです。QRコードがあるので、読みたい人は読んでみてください。
スキルの全体像がわかって、自分の得意不得意がメチャメチャわかります。超絶便利なのでぜひ見てみてください。チェックリスト形式で、サイエンス、エンジニア、ビジネス領域のそれぞれで、どういうスキルがあるかがドバーっと数百個くらい書いてあります。
全部できる必要はありません。たぶん無理です。全部見ることすらけっこう大変。しかし、これを見てみることによって「スキルってこういうものがあるんだな」「自分はここ得意だけど、ここはあんまり得意じゃないんだな」というのが可視化されます。1回見てみると、すごくやりやすいんじゃないかなと思います。
スキルチェックリスト自体はPDFですが、スプレッドシートにまとめていい感じにしたものもあるので、よかったらこれも使ってもらえればと思います。Googleドライブで共有していて、そのままで作業してしまうと全世界に自分のスキルを公開してしまうので、コピーしてから使ってもらえればと思います。
エンジニアリングに置き換えて考える
というわけで、なんか説教くさい話をしました。前半はそういうパートです。後半、ここからが楽しいパートです。「わかった、わかった、基礎が大事なんでしょう。でもどうやったらいいの？」。この疑問に、今日はバシッと答えしたいと思います。先にネタバレします。
みなさんはもう、データサイエンスのプロジェクトをどうやったらいいか、このやり方は完全に知っています！
データサイエンス、それを全部エンジニアリングに置き換えてください。一応、今日はエンジニアの方やエンジニアチームをマネジメントしている方、とにかくエンジニアに関わる人がいる想定でお話しています。
「まだ学生です」という人は自分の研究領域や、「そんなのやったことなくて～」という人でも就活のときにやると思いますが、バイトでバイトリーダーでがんばったとか、サークルでがんばったとか、なんでもいいです。とにかく自分が頑張った領域に置き換えて考えてみましょう。そうすれば、データサイエンスを進めるときの悩みは、だいたい全部解決します。
「これって勉強した方がいいですか？やる必要ありますか？」
データサイエンスあるある、一番でかい質問はこれです。「数学って勉強しなきゃダメですか？」。どうですか？ 「うわぁ、数学だけはやめてくれ～、頼むから～」という人もいますよね。わかります。
でもこの疑問にも、実はみなさんが答えを出せます。これをエンジニアリングに置き換えてみましょう。データサイエンスにおける数学は、「まあ知っていたほうがいいんだろうな。これが基礎なんだろうな。でも基礎的だからすぐ使え……え、本当にそれやる必要ある？」。そういうものだと思います。
エンジニアに置き換えましょう。例えば、Webエンジニアをやっている人が、1年目の社員に「TCP/IPって勉強したほうがいいですか？」と聞かれる。
組み込みエンジニアが、「自社ハードのネジがどうとかって細かいところ、知ったほうがいいですか？」。フロントエンドエンジニアが「マテリアルデザインって、勉強しなきゃダメ？」。新人の人から質問されたときに、あなたはどう答えますか？
これ、完全に同じ答えになると思います。「最初はやらなくていいから、とりあえずやってみなよ」と。「困ったときに調べていくと、深くいくと結局ここに行き着くから、そのときにやりなよ」と、たぶんそういう話になります。
みなさんも「っていうことは、数学やらなきゃいけないのか～。うわぁ、もう無理だ～」となっているかもしれませんが、大丈夫です。ちょっと想像してほしい。みなさんがエンジニアを始めたときに、TCP/IPとかって勉強したかったですか？ TCP/IPは、みなさんの好きな分野の基礎的なものに読み替えて聞いてください。
自分のやりたいことや、自分の実装したいものをやったり、自分の疑問を解くために深掘っていったら、結局、TCP/IPやインターネットプロトコルがどうなってるとか、ハードウェアが、メモリがとか、GPUが……となっていく。みんなそれで勉強したでしょ？
勉強したことによって理解度が深まって、より表のところをやるとなってもメチャメチャこの知識が活きるようになって、「うわ、勉強してよかった！」ってなってるじゃないですか。だから大丈夫。結局いつかやります。
やってるときはつらかったかもしれないけど、「意外とやってみたらおもしろいじゃん」というテンションになっているかもしれない。やったあとメチャメチャ理解度が深まって「やったー！」ってなってるじゃないですか。
その同じことを、もう1回やればいいだけです。「あなたにはできる」と言ったのは、もう同じことをやってきたからです。だから、絶対できるんです。
確かに、こと数学と言われるとTCP/IPとは違っていて。数学はヤバくて、人生の中で、みんなこいつにメタメタにメンタル破壊されてきています。人生のどこかで数学がわからないタイミングが、必ずくるじゃないですか。
マスターも、数学のドクター出る過程で1回「やばい。うわ、ここから先わかんねぇ」となって、マジで苦しんだときがありました。そういう人でもそうです。
しかも高校で理系だったら週3時間とか5時間わからないものやらされて、苦痛で、しかもわからなかったら大学受からないみたいな。圧をかけられまくった存在で、苦い思い出がメチャメチャあるとは思います。
でも大丈夫です。大人になって、必要だから必要な部分をやっていくとなったら、意外とできます。メンタル、苦手意識は越えないといけない事実はありますが、別にやったらできる。TCP/IPができたらできます。そういうものです。
「なにからやったらいいかわからない」も答えを知っている
では、データサイエンスをエンジニアリングに置き換える、その2。これもあるあるです。「なにからやったらいいかわからない」という質問はめっちゃ聞きます。
でも実はみなさん、これも答えを知っています。トン！ なにからやったらいいかわからないときって、だいたい「データ分析でなにかしたいなぁ」と思っている状態だと思います。このときってエンジニアリングで例えたら、「技術力を高めたいなぁ」くらいの漠然とした野望です。
自分も含めて、例えば「自分も含めて、会社のチームみんなを技術力の高いチームにしたいな」と思ったとしましょう。あなたが実際にエンジニアだったとして、技術力を高めるためにはどうしますか？
ちょっと思い浮かびませんか？ 「勉強会してみて」とか、「あれやってみて」とか。「でも実戦で使ってみなきゃ」とか、いろいろ思いつきますよね。同じです。ちょっと整理してみましょう。
技術力を高めたいとして、でも技術力を目的にすると、稟議だのなんだのとおりません。予算もついてこないと思います。結局、私たちは遊びじゃなくて仕事で、ビジネスでやっているので、バリューにつながることを絶対やらなければいけません。逆に、これに紐付けてしまえばなんでもできるのが、ビジネスのおもしろいところだと思います。
今、私たちが解かなければいけないビジネス上の課題は？ もちろん、これは実装上の課題で、負荷や負債が溜まりまくって開発が遅いとか、そういうのでもいいです。そういうのをちょっと思い浮かべて、ではそれを解決するためにはどうしようか。その軸で考えるのが、ビジネスパーソンとしては普通ではないでしょうか。
となったときに、その課題を解くために解決にベストな選択肢を選定することが、次にやることになると思います。技術力を高めたい裏目的があるなら、たとえ難しくとも、その技術がベストなのであればそちらを選ぶ。
今回の場合はわかりやすく、開発環境をDockerにしてみようというプロジェクトになったとしましょう。Dockerという単語がわからない人は、なんかすげぇかっちょいい技術だと思っておいてください。
となったときに、みなさんどうしますか？ Dockerのことをなにも調べず、「ネットでいいって言ってたから、使おうぜ。イエーイ！」とはいかないでしょ？ まず自分で試してみませんか？
エンジニアなんて、土日とか夜とか、勉強する生き物じゃないですか。ちょこちょこって自分のプロジェクトでやってみたり、自分の会社で使うならこうかなと想像してみたり試してみて、よかったら周囲にプレゼンして説得して、GOとなるのがエンジニアの普通のやり方だと思います。
一緒です。データでなにかしたい場合も、まずはビジネスの課題を解くことを考えましょう。ごく稀に、ビジネス上の課題を解くことではなく、機械学習することそのものが目的になっているときもあります。それは必ずしも悪いことではないです。
そういうのって、大企業によくあると思います。大企業で機械学習に投資するかどうかの判断しなければいけないとき、機械学習に100人や1,000人突っ込むことになります。
その単位の人の人生を突っ込むなら、その前に検証しなきゃいけなくて。じゃあ機械学習でなにかおもしろいことできるんですか？ どうですか？ というプロジェクトが始まると思います。
課題を解くためには、Excelで済む問題であっても、機械学習を使わないと目的が達せられないから。でも、ビジネス上の課題を解決するために、今までの手法よりデータサイエンスのほうがよかったら、普通はそっちを使うことになるはずです。
解決にベストな技術を選定する
では自分が解決しなければいけないビジネス上の課題がなにか考えたときに、解決にベストな技術を選定してください。一緒です。先ほどは技術力を高めることが目標だったから、たとえ難しくてもベストなものを選んだと思います。たとえ簡単でも、ベストなものを選ぶのがデータサイエンスの場合は大事です。
でもエンジニアでもそうでしょう？ 負債など長期的な視点はあるとしても、難しいことをやってページを作るより、同じことができるなら簡単なほうがいいじゃないですか。
とにかく最初に始めるときは、誰にでもわかるExcelくらいでいいです。同じ結果が出るなら、手法は簡単であれば簡単であるほどいいです。
データは絡まなくてもいいかもしれない。とにかくベストな方法を選んで、ベストな方法にデータが絡まっていたら、「しょうがないなぁ」とニコニコしながらデータを始めるわけです。
例えば、ぜんぜん簡単ではないですが、「〇〇予測に機械学習を使おう」というプロジェクトになったとします。ではどうしますか？ 「AIの時代なんだからやるでしょう！」と、試しもしないで突っ込む人もいるかもしれませんが、いやいや、技術のときそんなことしなかったでしょ？ まずは自分でやってみるんじゃないですか？
そして「あ、なんかいけそうだな」と思ったら上を説得する。こういうやり方だと思います。プロジェクトを進めるという観点において、結局エンジニアのときと一緒だから、そのときにできているならやればできます。特に技術でがんばっている人は置き換えるだけです。簡単。
（次回につづく）
