2024.12.19
システムの穴を運用でカバーしようとしてミス多発… バグが大量発生、決算が合わない状態から業務効率化を実現するまで
リンクをコピー
記事をブックマーク
アイシア=ソリッド氏:マスターのストーリーはどうでもいいんですよ。過去の話だから。私はみなさんに、あなたのストーリーを始めてほしい。そう思ってここに立っています。では、あなたのストーリーを見てみましょう。
実はあなたは、やり方を知っているし、おもしろい仕事をすることは絶対にできます。あとでお伝えしますが、順番を踏むのはやったほうがいいんじゃないかと思います。
まず「自分の技術力、分析力はどこだろう?」というのを、ちょっと考えてみましょう。例えば、分析結果から意味のある洞察を得たり、意思決定できますか? 平均を比べるとか、なんとか率が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の時代なんだからやるでしょう!」と、試しもしないで突っ込む人もいるかもしれませんが、いやいや、技術のときそんなことしなかったでしょ? まずは自分でやってみるんじゃないですか?
そして「あ、なんかいけそうだな」と思ったら上を説得する。こういうやり方だと思います。プロジェクトを進めるという観点において、結局エンジニアのときと一緒だから、そのときにできているならやればできます。特に技術でがんばっている人は置き換えるだけです。簡単。
(次回につづく)
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2024.12.19
12万通りの「資格の組み合わせ」の中で厳選された60の項目 532の資格を持つ林雄次氏の新刊『資格のかけ算』の見所
2024.12.16
32歳で成績最下位から1年でトップ営業になれた理由 売るテクニックよりも大事な「あり方」
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
2024.12.13
ファシリテーターは「しゃべらないほうがいい」理由 入山章栄氏が語る、心理的安全性の高い場を作るポイント
PR | 2024.12.20
モンスター化したExcelが、ある日突然崩壊 昭和のガス工事会社を生まれ変わらせた、起死回生のノーコード活用術
2024.12.18
「社長以外みんな儲かる給与設計」にした理由 経営者たちが語る、優秀な人材集め・会社を発展させるためのヒント
2024.12.12
今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは
PR | 2024.11.26
なぜ電話営業はなくならない?その要因は「属人化」 通話内容をデータ化するZoomのクラウドサービス活用術
Climbers Startup JAPAN EXPO 2024 - 秋 -
2024.11.20 - 2024.11.21
『主体的なキャリア形成』を考える~資格のかけ算について〜
2024.12.07 - 2024.12.07
Startup CTO of the year 2024
2024.11.19 - 2024.11.19
社員の力を引き出す経営戦略〜ひとり一人が自ら成長する組織づくり〜
2024.11.20 - 2024.11.20
「確率思考」で未来を見通す 事業を成功に導く意思決定 ~エビデンス・ベースド・マーケティング思考の調査分析で事業に有効な予測手法とは~
2024.11.05 - 2024.11.05