Bさん
はじめに🐶さんの悩み事：BIツールとの付き合い方について🦡さんの悩み事：良いレポートとは？事業会社におけるデータ分析業務のKPIは？🦌さんの悩み事：SE からデータサイエンティストになる時に、気をつけないといけないポイント、頭を切り替えなきゃいけないポイントは？🐋さんの質問：データサイエンスに必要な能力を得るために参考にすべき書籍は？🐋さんの質問：データサイエンスのすごい人は全部一人でできる？😼さんの質問：「私はデータサイエンティストです」と名乗って良いレベルとは？🦡さんの質問：データサイエンティスト多数!って誇張されると怪しい？システム提供会社との付き合い方🦡さんの質問：孤軍奮闘している人の見つけ方終わりに
はじめに
時間になりましたので、2月のコミュニティハブ委員会を開催します。
今回は九州からの参加もありリモートならではの全国での展開が広がっております。
改めましてコミュニティハブ委員会では、決まったテーマはなく毎月1度参加者が今困っていることを共有し会員同士で解決に向け”わいがや的”に話し合います。
今回は事前に議題があったので、そこから入っていきましょうか。
🐶さんの悩み事：BIツールとの付き合い方について
🐵さん：
うちのケースだと、Tableauを使い始めたきっかけは、生産性が高いプレゼンツールとして私が前職から使っていたことでした。
それとは別の取り組みでデータ活用の普及の取り組みの一環として使われ始めましたが、データ普及の取り組みの中では、活用が促進しませんでした。なぜかというと、データを作ることをできる人がおらず、アウトプットが作れなかったからです。それではダメだということで、今までエクセルで加工できるような集計データ抽出をTableauで閲覧できる状態にして納品したりすることで、関係者がTableauに慣れていきました。結果、現在ではTableauを使ってプレゼンすることが主流となり、Tableauでドリルダウンして分析するようになっています。普及するには知ってもらうことと、使ってもらうことが必要ですが、使ってもらうためにはデータ(データマート等)を作る必要があることから、それは私や分析チーム、集計チームの部署が担っています。
🐶さん：
なるほど、ありがとうございます。みなさんどうですか？
🦍さん：
ビジネススキルを身につけてもらいたいんだけど、ダッシュボード作りの仕事が多くなっちゃってるから、ビジネススキルを身につけるのが後回しになっちゃう、ってことを気にしてるという話ですか？
🐶さん：
そういう側面もあるんですが、メインとしては皆さんがBIツールとどうやって付き合ってるのかが聞きたいです。
🦍さん：
ありがとうございます。私の会社では、BIツールを入れようとしているところなんですが、BIツールのダッシュボードを作るチームと分析するチームを分けています。育成みたいなところで言うと、若手は、ダッシュボード作成を含め最初にプログラミングで解決する部分を担ってもらっています。そこと並行で、会議やOJTを通してビジネススキルを覚えてもらっているような体制でやってます。
🐶さん：
ダッシュボード作るチームと分析するチームを分ける理由ってなんでなんですか？
🦍さん：
特殊なところはあるんですが、今のチームが構成される前の組織体制やそのアウトプットが要因です。
元々の組織では、データ分析をするチームと新しい技術を試す(PoC)チームに分かれていたんですが、PoCチームのアウトプットが実益につながっていませんでした。PoCチームの役割として、ビジネススキルの素養が薄くて済む分析チームの業務に当てる必要があったのが要因です。
ビシネススキルが必要なダッシュボードを作るチームに対して、今までビジネススキルを会得していない人員(PoCチーム)を活かすために、結果的にダッシュボードを作るチームと、分析するチームに分かれました。
🐶さん：
ありがとうございます。
🦁さん：
他の方はいかがでしょうか？
🦁さん：
うちの話をすると、事業会社なんで、データサイエンスチームは2層に分けています。
1層目はフロントでビジネスユニットに向き合うチーム。簡単なBIやダッシュボード作成までを行います。2層目はCoE(center of excellence)チームがいて、BIやダッシュボード、機械学習のアルゴリズムを開発するチームがいたりします。フロントチーム(1層目)は、課題を落とし込んで、自分たちで解決できることがあれば解決します。簡単なBIツールなら作ってしまいますね。より高度で重たいものは、CoE(2層目)のチームに回される体制で進めています。
🐶さん：
ちなみにその場合、BIをやってる人でも機械学習をしていたりしますか？
🦁さん：
データエンジニアやBIツールのスキルを持ったエンジニアは、キャリアパスとして機械学習やデータサイエンスをやっていきたい意向が強いので、部署の異動含めキャリアパスを用意しようとしています。
🐶さん：
ありがとうございます。BIツールは分析のツールというよりは、把握をして、その先で問題が見つかって、それをどうアルゴリズム(機械学習など)で解決するかという流れで使うものと思っていて、その気づきのため必要なものが、BIツールだと思っています。その入口として、データの取り扱い、表現の仕方など一貫した流れにある認識で、違う職種として捉えられてるような気がして確認した次第でした。
🦁さん：
あと、相対する人(ビジネスサイドやお客様)の成熟度にも変わりますよね。最初は見える化から入ってあげる方が良くて。いきなり高度な分析アプローチを提示してもなかなか理解を促すのが難しいとおもいます。最近そんなことを考えながら懐かしい書籍『分析力を武器にする企業』の”(表６・２)分析力の発展過程”を読み返して、今の業務のフレームワークを整理してるんですが、整理のフレームワークとしては良いかなと思ってます。
🦁さん：
他の方はどうですか？
🐵さん：
答えになってないかもですが、旧来的な普通のモデリングだと、そこにあるデータの全体を見て、”あたり”をつけるプロセスがありました。その時は、SASや、R、Modelerを使って、データをざらっと眺めて、切り口や仮説をつくっていかないといけませんでした。SASはデータを部分的に見たり、統計的に見たり、グラフを作るにも不便でした。その点Rは便利。全体を見る時にはTableauも便利です。データ分析をやる人がデータをざらっと見るにはタブローは便利です。
他方、それがいいのか悪いのかは悩んでいるところがあって、アンサンブル学習でもディープラーニングでも、BIツールを使って知った情報が予見になってしまって、データの見方に偏りが生じていると感じています。”主観”と”データが語っていること”を切り離して考える必要性があると感じているので、BIツール無しで分析する意義はあると思っています。だから、TableauやRのアプローチをしないことにも意義は感じています。だから、それが良いのか悪いのかは別にして、速度を早めるにはTableauはすごく便利なツールだけども、データを見る予見になってしまうのは、ちょっと気になりますね。
🐶さん：
ありがとうございます。確かにそうですね。
Tableauは便利だと思うんですけど、綺麗に見れる分、作ったモデルに対してロバスト性が生じると言うか、ノイジーな部分に耐性がなくなるような気する点には共感しました。たしかに昔はとりあえずやってみようという心持ちでやってましたね。
🦁さん：
誰が見るかが大事だなと感じました。
定形レポートのようにビジネスサイドの人が見る分には良いと思うんですが、分析する側の人が見ると、思考が偏ってしまう可能性は感じるので、難しいところではありますね。
🐶さん：
そうですね、それは考えさせられました。良いことばかりではないなと。
データに慣れていない人にハードルを下げて簡便に、データに意味があることをBIツールを通して伝える分にはツールとしては良いですね。
分析するような実応用する人には、アルゴリズムや分析手法に落とす時に、過学習というか、変なものに弱くなってしまう、耐性が作れない気がするので、バランスが大事だなと感じました。ありがとうございます。
🦡さん：
“Tableau(BIツール)だと視野が狭まる”ことに対する対策はありますか？
🐵さん：
対応策はなくて、今はちょっと困ったなとなっているところ。ビジネスの観点からいうと、Tableauは便利だし、Tableauでプレゼンテーションさせるべきだと思ってます。ただ、便利なあまり自分でデータを可視化して把握する、特徴量をみつけていくプロセスとか、データを綺麗にしていく、データの中でやらねばならない処理プロセスを探していくプロセスでTableauを使っちゃうと、「これってやっぱり効いてそうだな」とか、「これは面白そうだな」みたいなポイントに注目し過ぎて、アルゴリズムの良さを殺しちゃう気がするんですよね。最近、分析者の「こうゆう変数つくってみました」といったアウトプットの中にも、データの分布を見ずにTableauで可視化したらこんな形になりましたといったアウトプットがあり、また変数を作るアルゴリズムがそこからは生まれてこず、再現性がなかなかない事象があり、さて困ったなという状態です。
🐶さん：
今の話って、前半で気づくことができたはずが、後々で気づくことになってしまうので、問題に気付くことが遅れるってこともありますよね。「このケースうまくいかないじゃん！」みたいなのが後で大量発生しちゃうこともあると思います。綺麗な情報にだけFITしちゃうモデリングをしちゃうとか。
🦡さん：
なるほど、絶賛困り中なんですね…。
🐵さん：
ビジネス課題を高速で解決するのにTableauは良いんですけど、果たして良いもの(ずっと使っていくもの等)を作る時に見逃してしまうものが出てくることはないのかと危機感を持っています。
🐶さん：
大きいトレンドを見るのか、ミクロに捉えないといけないのか、問題設定のバランスを見間違えないようにするリテラシーがあればうまく使いこなせるんでしょうね。(分析結果が)綺麗にまとまっていたりすると、それを信じてしまうことが多いので、それを適切に疑えるかというか。
🦡さん：
ありがとうございます。
🦡さんの悩み事：良いレポートとは？事業会社におけるデータ分析業務のKPIは？
🐵さん
誰が見てもわかりやすいのが一番だと思っていて、人によってスタイルが色々あるのは良いんですが、きちっと使う側に示唆が生まれるようなものが良いレポートだと思います。客観的に”データが言っていること”を分かってもらった上で、だったらこれをやってみようといった示唆がそこから出てくるようなレポートになってないといけないと思います。その観点が入っていれば、構成の良さや絵が多いかなどはを気にする必要はないかと思います。
テクニカルな部分の伝え方という観点では、テクニカルなことをきちっと伝えないとお客さんがぐっとこちらに来てくれないので、それは入れるよう指導しています。つまり、アナリティクスから出てきた分析技術をわかるようにしています。
ただし、分かりやすく説明するのが苦手な方が多いので、専門的なことを簡単に説明できるようにして欲しいということはあまりは伝えていません。それは慣れてくればできるようになるし、補助すればいいだけなので。
とにかくレポートを見てもらって、レポートした先から「じゃあこうしようか」と相手から言ってくれるレポートが良いレポートだと思います。例で挙げるなら、会議で「こうしたらいいの？」と質問が出てくるようなレポートが良いレポートと思います。
🦡さん：
次のアクションに気づいてもらうのが重要なポイントで、🐵さんたちの部署(データ分析の部署)からそれを提示することはしないという理解で合っていますか？
🐵さん：
そこはそうでもなくて、僕らは僕らなりの考えで、「こうゆうことができる」という提案はできるだけ入れてくださいと指導しています。ただ多くの方は、現場の業務を100%分かっている訳ではないからと、提案を遠慮しています。指導としては、そんなスタンスでやっていると100年この部署にいることになるよと半ば脅していて（笑）。自分なりに新しいビジネスに対して考えられることがあれば、提案してくださいと伝えていますが、半年に2件前後しか出てこないですね。
🦡さん：
分析チームが提示したものを、ビジネス部門が気づき、アクションを決めて行く。そしてそのアクションをした結果またフィードバックが来て、新しい気づきをまた提示していくっていう、そのサイクルを回してらっしゃると理解しました。ありがとうございます。
😼さん：
私は銀行勤めなんですが、レポートする対象は預金残高や貸出残高の伸びの目標対比だったり、あとは債務不履行(デフォルト)の割合だったり、広告を打ち出した時のCPOをレポートしています。分析した結果として数字は出せますが、次のアクションに繋げることができているのかというところは弱くて四苦八苦しております。上層部から次のアクションに繋げられるストーリー(戦略)を描くことを求められているので、そこは課題と思ってます。同僚の🐿️さんどうですか？
🐿️さん：
銀行に限らずだとは思うんですが、私は良いレポートの条件がいくつかある中で、分析レポートが恣意的な方向に寄ったレポートにならないように事実と考察(自分の考え)を分けることが大事だと思っています。
🦡さん：
ありがとうございます。他金融系の人だとどうですか？
🕊️さん：
レポートで大事にしているのは私は３つあるんですけど、１つめは誤読がされ辛いことです。正しいことが書いてあっても、間違った方向に読めてしまうレポートは最悪ですね。２つめはみなさんが仰っている通りそのレポートを読んで次のアクションが見えること。少なくとも議論が熱くなることですね。３つめは背景が分かることで、レポートは上位層ほど背景が失われ、伝わらなくなることが多いと思います。「あれ？これなんだっけ？」と、時間を無駄にすることが多いかなと。分析者あるあるだと思うのですが、情報が全て頭の中で保管されているので、自分は当たり前だと思って自然に前回の話を飛したり、背景を飛ばしたりすることがあるので、「これ、そもそも何のお話しだっけ？」と時間を無駄にしちゃうことを避けるのも大事ですね。
🦡さん：
ありがとうございます。なるほど、目的を見失ってしまいがちということですか？
🕊️さん：
それもあるんですけど、最初・中間・最終で報告する時に時間が開く時がありますよね。そうすると、レポートを受けとる方が前のこと覚えていないことがあると思うんです。レポートを受けとる方に振り返る情報を与えないと理解が進まず、本来聞いて欲しい分析の話まで理解が辿りつかず、振り返るための質問ばかり飛び交うことになると思うんです。なのでハイライトとして、必要な粒度で必要な情報を添えることが大事だと思ってます。
🦡さん：
なるほど、それはどんな業務にでも言えそうですね。🦍さんはどうですか？
🦍さん：
弊社では報告(レポート)のタイミングが複数回に分かれておりまして、中間報告と最終報告といった位置付けで報告されてます。最終報告は全案件必須で、必要に応じて中間報告をすることになっていて、分析結果が出た段階でレポートする位置付けになってます。弊社でいう最終報告が、ここまでの話に出た”レポート”に近いと思うのですが、最終報告で大事にしていることは、元々どのような課題認識や背景で始まった分析なのかということと、明らかにしたいことが何なのかを必ずリマインドとして差し込んだ上で、分析の結果と成果、それを踏まえた上で次のアクション(打つべき施策等)をレポートに組み込むことです。あえて付け加えるのであれば、使ったデータや、使ったデータの紐付けをした時の課題も可能な限り載せるようにしています。
🦡さん：
使ったデータや、使ったデータの紐付けをした時の課題を入れる理由はなんでなんですか？
🦍さん：
「こういうやり方がしたかったです」とか「本来であればこういう検証がしたかった」いった当初の想定がある中で、データ不足等でできなかったこともあると思うんですね。なので、”次にもっとうまくやろうと思ったらこういう対応が必要です。”という意味を込めて載せています。想定に到達できていないのはデータが悪いからです。というデータ起因の理由を差し込んでいる感じです。
🦡さん：
ありがとうございます。事実として発生した課題を掲示することで、環境がさらに改善していくようにもなるかもしれませんね。
🦍さん：
そうですね、弊社の良いレポートの条件として、滅多に作れないんですけど次の案件が出てくることがあると思います。今回できなかったことや、次のアクションはこうですみたいな話をしていった結果、次の分析テーマが起案されることが稀にありますね。
🦡さん：
なるほど。
🦍さん：
そういえば背景や前提知識が抜けてしまう話で、下からの突き上げがあると、今日出席している🐘さんからありましたね。
🐘さん：
そうですね（笑）。ちょうど前述のような話で、間が補完されておらずわかり辛いレポートがありまして、よくある話なのかなと。
🦡さん：
次のアクションを提示できる理由って、🦍さんの組織が、現場の方が集まってデータ分析組織を作っていらっしゃるからで、その次にやることの認識が揃いやすいからかなと私は思っているんですけど、どうですか？あまり誰にでもできることではないのかなという気がします。
🦍さん：
そうですね。仰る通り業務経験者もいるので具体的な話ができるというのはありますが、分析を依頼している部門と分析しているメンバーで毎週会議をやってるんですね。その会議では、分析結果を出し、仮説やその検証結果、提案の擦り合わせを繰り返し行なっています。なので、分析チームから100%真新しい提案を出してるというよりは、向こうのご意見を概ね含めた上で、提示するアクションに反映してるような形ですね。
🦡さん：
なるほど、コミュニケーションをビジネスサイドととっていくことで、次のアクションが自然に見えてくる。そういう感じですか？
🦍さん：
“自然に”とと言われるとちょっと「はい」とは言い辛いですけど、細かく提案していって、向こうの意見をその都度取り込んでいくことによって、結果マッチしたものになっていくイメージで、それを頑張って成し遂げてる感じですね（笑）
🦡さん：
なるほど、私はお客様が属する業務スキルがない状態でお客さんと接していることは課題と思ってましたが、弊社でも細かくお客さんとミーティングを開き、お客さんがやりたいことが何なのかを擦り合わせながら先に進んで、次のアクションを決めいていき、アクションした結果をまたフィードバックしてもらって、というサイクルを回していけば、必ずしもビジネススキルがないとできないわけじゃないんですね。自分の中で自信につながりました。
🦁さん：
今のに被せるんですが、分析依頼する人と、分析をする人って分かれなくてもいいよねという話があります。僕らは事業者なのでワンチームになってもいいんじゃないかと話をしてました。上手く回っているチームは定型レポートを作るんじゃなくて、Tableauや Excel の画面を見ながらビジネスチームとアジャイルに仮説検証を繰り返していくのではないか。上手くビジネスサイドと協働しているような気がするんですよね。
テーマにもよりますが、アウトプットを作ってレポートして、Authorizeしながら進めることが重要な場面はあるのですが、ビジネスサイドとワンチームになってアジャイルに仮説検証を繰り返してビジネスのアウトカムを作っていくほうが、うまくいくチームなのかなと思います。事業会社だからできることかもしれませんが。
あと、レポートを作っている時間があるなら、もうちょっと中身のある仕事してもいいかなと思うところがあるんですよね。いつまでも分析を依頼する人と分析をする人じゃなくて、どんどんスキルトランスレーションしていって、事業サイドの人が自分たちでいろんなことができるようになっていくのが良いと思います。
弊社では事業側の成熟度上がってきていて、分析サイドが事業側を教えていたりするんですね。Tableauの作り方とかダッシュボードの作り方を教えていて、事業サイドが自走できているんです。分析するチームはもうちょっと高度なことをやろうよということにシフトしていっているんですよ。なので、分析提供会社と事業会社とアプローチは違うかもしれないけど、そういうのもひとつ大事なのかなと思いました。
🦡さん：
ありがとうございます。
🐶さん
今までの話を聞いて、うちのメンバーにレポートを作るときに必ずしている話があるんですけども、Alexander Simonの『システム科学』という本の中で、「”事実”から”データ”が使われて、”データ”から”情報”が作られて」という話があるんです。結局のところ、その”情報”をどうやって活用するかを僕らは手助けしているだけなんですよね。その時に、”事実”は”データ”からしか導き出されないですけれども、それを導き出せるのはアナリストにしかできないとは思うんです。
だからこそ、必ずその”情報”に至るまで”データ”を昇華させて欲しいと伝えています。”情報”がなかったら知能は生まれて来ない中で、”事実”や”データ”とは違う次元の”情報”とは何なんだろうかということを自分たちなりに考えてもらっています。それが“アナリティクス”なんですってことをそれぞれに考えてもらっています。
良いレポートを作るには、それらがちゃんと分けられてるのもそうなんですけれど、それは”データ”や”事実”からしか導き出されてこないということを常に相手に理解してもらう努力はしてほしいと伝えています。仮説は事実からしか出てこないので、最初から仮説があるわけではありません。仮説を作るマーケターに「データがない中で仮説は作れないですよ」と言うと、すごい怪訝な顔するんですけれど、絶対にデータがなかったら仮説はできないと思います。
🐶さん：
私がよく部下に言ってるのは、良いレポートというよりは、レポート全般こうあるべきだという意味で「自分達が大学の実験で取り組んだレポートのように書きましたか？」という問いかけをしています。今までの皆さんの話と一緒で、背景や目的を書いて、先行例や仮説・検証方法・アルゴリズム・今発生している問題への対処・結果・その結果に対して考察・結論を記載することですね。
私は、(大学の実験レポートの要領は)ビジネスでも一緒だよと部下へ伝えていまして、このフレームワークはどこにでも通じてると思います。もちろんExecutive summary等、相手によって伝える濃淡はありますが、基本このフレームワークでまとめれば相手に伝わる情報が整理され、わかりやすいレポートになると思ってます。
🦌さんの悩み事：SE からデータサイエンティストになる時に、気をつけないといけないポイント、頭を切り替えなきゃいけないポイントは？
😼さん：
私は前職で電子カルテの開発をしていて、バリバリエンジニアをしていました。今がデータサイエンティストというわけではなくて、データを扱ってる部門でエンジニア部分を担っていくっていう役割になっていますが、システムエンジニアと全然違うなと思う部分は”失敗が許容される”部分でした。やってみてダメだったら次のことで考えればいいじゃんという文化があり、多少の失敗で怒る人はおらず、さらに言うと品質もそんなに問われない部分もあって、この辺りが一番カルチャーショックでした。
🦁さん：
さっきも少しお話したんですが、仮説検証を繰り返していくアプローチが重要なことの１つなんですよね。🦌さんはシステム開発をウォーターホール型(要件定義してアウトプットから整理していく)で考えるのが染み付いてるのかもしれないんですけど、開発アプローチとして、アジャイルをしている人たちには馴染みやすいかなと思います。
ただ、システムエンジニアの経験がある人は重要です。役割として完成したモデルをシステム化していくことが多くなっている中で、ぶっちゃけデータサイエンティストが書くPython コードってお粗末だったりするので、使いものにならないことが多くリエンジニアリングしなきゃいけなかったりするんですよ。なので、できた機械学習のモデルをちゃんと実装までもってく時には、システムエンジニアリング経験は重要かなと思います。今までの経験を生かすところと、ちょっとマインドチェンジしてくところと、2面あるかなとお話を伺っていて思いました。他の皆さんはいかがですか？
🕊️さん：
僕はエンジニアではなかったんですが、データサイエンストでハマるというか、1つポイントがあるかなと。
「過去にデータ分析した結果は、未来でも同じとは限らない」ということです。
例えば、過去にDM1万人に送って同じ人にモデリングして、過去5%反応したからもう1度同じことをすると5%だと定義すると、ほぼ100%失敗します。それは過去に送ったという情報が、過去時点では無い状態だったのに対して、今やると(過去に実行したことが)残ってしまっているからなんですね。
情報や状況が変わる中で、データ分析によってより成果を出すのは、未知への挑戦みたいなところがあって、どうしてもデータからじゃ拾えない要素がいくつもあります。例えば金融なら金利状況等、過去に経験してない状況が次々とやってきます。その中で、どれだけ妥当なところを今ある情報から導くか、(ある意味)論理構築するか、なにがそれを帰結させるのかを想像する力のようなところが問われる仕事だと思うし、データサイエンスの難しさだと感じています。
🦌さん：
ありがとうございます。
今日は、1月から同じく私と一緒に勉強を始めてる若手が2人参加しておりますので、🐊さん、🐋さん、何かありますか？
🐊さん：
初めまして、🐊と申します
私は大学の時に実験で、イチゴの栽培をデータを扱って実験してたりした。今回はたくさんお話を聞けてすごいなと思いました。でもこれからも勉強して色々データを使えるようになったらいいなと思っています。
🦁さん：
今悩んでることとか困ってることとかってあります？
🐊さん：
今はデータサイエンティストの世界に入ったばかりで正直わからないことばかりで、困っていることというか本当に勉強する毎日です。何に困っているかもわからない感じです。
🦁さん：
コミュニティハブ委員会は毎月やってるんで、困った時に参加してくださいね。ずっと参加する必要もなく、困り事のある時に参加して、カジュアルに話す場なのでいつでもお越しくださいね。
🐊さん：
ありがとうございます。
🐋さん：
皆さん初めまして、🐋と申します。この場を借り話したいんですけれども、私も1月から、先ほど紹介いただいたようにデータサイエンスの部門に入りまして今までの皆さんの会話を聞いて非常に勉強になるなと思っていた次第でございます。そこでちょっと気になったことがありまして質問させてください。
🐋さんの質問：データサイエンスに必要な能力を得るために参考にすべき書籍は？
🦍さん：
書籍ではありませんが、最初に身につけることって一人で全部やらないことだと思います。データサイエンスのスキルってものすごい幅が広くて、一人で全部身につけるのは不可能に近い。うちのチームは色々な部署から人が集まっているのですが、システム開発経験があるメンバーが1/3、アクチュアリーという数学に強いメンバーが1/3ぐらい、後は私のように営業出身だったり、実務経験がある人が1/3で構成されていて、それぞれの知っていることや、できることがバラバラなんですね。何を言いたいかというと、一人で全部やろうと思うと必ず限界が来るので、周りと一緒に頼ってやっていくことを覚えましょうってことです。いつも一年目の人へ私が伝えていることですね。
🐶さん：
あと、前も話ししたんですが、大城さんの本『AI・データ分析プロジェクトの全て』ですね、本当にとてもよくまとまってますし、初めての人にもわかりやすくて何からやるべきだとかそういうのすごいよくまとめられているので、オススメです。”どろ臭いよ”ってこともちゃんと書かれており、知っておくべき最低限の知識(基礎知識)が体系立って整理されていて、僕は良い本だなと思いました。
🐋さんの質問：データサイエンスのすごい人は全部一人でできる？
🦁さん：
トップランカーって、kaggleのトップランカーのイメージです？
🐋さん：
データサイエンティストとして有名な方のイメージです。
🦍さん：
トップランカーが一人でできているのであればそれで良いんですが、必ず全部一人でやらなきゃいけないのかというとそうではないということが、先ほどお伝えしたことですね。初めからトップ層くらいのスキルがある人がいたら、もちろんそうした方がいいんですけど、そこはマストではないよというのがお伝えしたい内容でした。
🐶さん：
トップランカーは、本当に全てにおいてトップっていう人はあまりないのかなと思ってます。データサイエンティスト協会のスキル設定されてる”ビジネス”と”データサイエンス”と”データエンジニアリング”の中で、どれかに強みを持ってて、どれかのトップっていうのはあると思うんですけど、全てをトップでやりきっている人はいないのかなと思います。その意味で分業としてビジネスに強い人の力を通してニーズ把握し、データサイエンスのトップの人がその力を発揮するような形になっているものかなと私は思っています。”データサイエンス”のトップの方がビジネスのことをどこまでわかっているのかは、少し疑わしいのかなとか、ちょっと想像したりして聞いてました。（笑）
🐋さん：
ありがとうございます。
🦌さん：
どんな業界でもそうだと思うんですけど、始まったばかりの頃は幅広く一人で何でもやることが多いと思うんですけど、どんな仕事でも分業に向け進んでくるのかなと思います。今データサイエンスの分野も徐々に分業化していくのかなとは思ってますね。なかなかスーパーマンはいないし、続かないので。
🐵さん
参考になるかわかりませんが、前職で日本においてはかなり初期にデータサイエンスモデリングのビジネスを始めた社長と一緒に働いていました。その方は全てを一人でやる感じでした。私が一緒に働いてきて感じることですけれども、例えば彼が今、全部一人でこなせるかというと、金言はたくさんあるし、すごく言葉も深いし、的を射たビジネスに仕立て上げるとは思うんですが、そこには若い人たちのサポートがないと新しいことはできないと思うんです。
彼のすごいところは、そういう新しい人達をどんどん育てていくことで、その意味でスーパーマンみたいな人です。ビジネスを作る(組み立てられる)人がいると、組織はすごく深くなってくんだろうなと感じています。
今自分がしていることで、若い人たちに向かっていろんなところでアドバイスしていることのほとんどは、彼からもらったことが100%で、焼き直しみたいなことやっているんですけれども、そういう人がいるといないのでは違うと思いますね。
🦁さん：
フルスタックの知識とスキルは一定レベルで持っておかないといけないとは思いますね。その上でプロジェクトに取り組むときは役割分担して、分業して、質のいいアウトプットを作っていくことかな。なぜかというと、エンジニアリング領域でもフルスタックエンジニアってあるじゃないですか。だけど彼らが一人でできることは限られている。スケールを考えると、チームアップして活動していかないといけないので、そういう点では似てるかもしれません。
あと、ディレクションやマネジメントの人は、相当幅広い知識が求められるかなと思います。データサイエンス領域だけじゃなくて人材マネジメントなども含めた能力が求められる。うちのチームではそういう人材が少なくて、どう育てていけばいいかが悩みの一つでもあるんですけど。そういう組織を作っていく立場の人なら、ある程度フルスタックで知った上でチーム集めてなきゃいけないでしょうね。
🐋さん：
ありがとうございます。勉強になりました。
😼さんの質問：「私はデータサイエンティストです」と名乗って良いレベルとは？
🦁さん：
みんな答えを持っていないと思うな。なんだろう（笑）。
これまでの話にもある通り、幅広い領域を求められるんですよね。縦も横(ビジネスドメイン等)も求められるので、なかなか答えるのが難しいですね。一応協会でもスキル定義を出してますけど、そのスキル定義ができる人がデータサイエンティストかっていうとみんな首を縦に振らないと思うんですよ。なので、難しい問題ですが、これに対して答えらしきものを持っている人いますか？
🦍さん：
ビジネススキル、ITスキル、分析スキルにおいて、「自分はこのスキルだったら戦えるぞ」みたいなものがあれば、データサイエンティストの一端として名乗って良い気はしますね。
😼さん：
軸になるものがあって、足りないところもあるにせよ、そこも少しずつ伸ばしていけばいいって感じなんですかね。
🦍さん：
横断的に基本となるような知識は持った上で、得意領域があって、ある程度戦えるものがある人ですかね。うちの会社では社内認定制度があるんですけど、データサイエンティストとして一定の認定がされてますね。
😼さん：
そのスキル定義は社内で作られたんですか？
🦍さん：
そうですね、あの DS協会のものを参考にしつつ、(コンサルティング会社さんから頂いたものを踏まえ)社内でつくりました。
🕊️さん：
当社でもレベル認定がありまして、認定制度におけるデータサイエンティストレベルが上位の人は実業務で使えるかどうかです。
レベル４まであって、レベル３が自分の得意領域でデータサイエンスを実業務で使えるレベル。レベル４は様々な分野で使えるレベル。といった区分けになってます。それは１つの視点になるのかなと思います。
あとこれは個人の感想なんですけど、データサイエンティストじゃない人のオープンMLを使ってできることを、データサイエンティストのアウトプットは超えないといけないと思っています。そうじゃないとデータサイエンティストのバリューが出ない。それがなんなのかと言うと、使い方なのか、知識なのか、正しく使えるなのか、ビジネスまで繋げるってことかもしれないし、実装まで含めてわかるっていうのか。。。少なくとも、オープンMLようなガラガラポンで出てくる結果で代替できるアウトプットだと置き換わってしまうので、超えないといけないレベルかなとおもいます。
🦁さん：
確かに、どんどんアップデートしていかないといけないですよね。5年前に同じ質問したら多分皆さん違ってたと思うんですよ。
弊社でもエキスパート制度っていうデータサイエンティスト職を設けていて、ジュニア・ミドル・シニアの区分けで、持ってるスキルセットを定義してます。ITコンサルティング企業と共同で作成した人事制度なので若干の弊社色はあれど、それを参考に外に対してデータサイエンティストとして名乗っていいかっていうのはなかなか難しいとは思います。。。
あと、やはりビジネスアウトカム作るのが付加価値だと思うんですよ。なので、いくら高度な機械学習やディープラーニングができても、そこに価値を見い出さなければいけないと思うので、そういったところも含めてこの職種って難しいところもあるんですけど、なかなか「これがデータサイエンティストです」って呼びにくいところかなと思うんですよね。
🐶さん：
私も結局は、データを用いてソリューションを提供できたって思えたら、その人はデータサイエンティストを名乗っていいんだよ。って感じます。
🐵さん：
そうだと思います。データを好きじゃないとこの仕事やってないし、データがあれば何でもできるって思ってるし、前の会社いた時は多岐に渡る業種業界へ提案してたんですけれども、私は必ずデータがあればなにか提案できるって言う自信があったんです。なので、他の人が何と言おうと、データサイエンティストって名前かどうかは脇に置いておいて、”これで飯を食っていけるな”って思えたらいいんじゃないかなと思います。
🦌さん：
この例えは不適切かもしれないんですが、競馬屋はその予想を当てて利益を生み出す人が競馬の予想屋で、会社にとって利益を生み出せる人がデータサイエンティストなんだなと思いました。
😼さん：
ありがとうございます、明確な答えがないってことだけでも収穫でした。
いろんなスキルが必要な分野だということは認識してますので、それを使ってちゃんとビジネスを立ち上られる、最終目標が達成できるかどうかなんだなっていうところが分かりました。ありがとうございます。
🦡さんの質問：データサイエンティスト多数!って誇張されると怪しい？システム提供会社との付き合い方
🦁さん：
データサイエンティストの定義にもよるんですけど、分析提供会社から提案をもらう時はその人のレジメをもらって、キャリアのバックグラウンドを教えてもらった上で人選してます。分析提供会社の人って「データサイエンティスト多数！」と言わないとビジネスならないとは思うんですよ。さきほどの話にもあるように、データサイエンティストとはいえ人によって知識もスキルも経験もバラバラなので、スキルセット・知識・経験の観点で、どういう仕事、どういう経験をもって仕事をしてきたかを見て仕事を発注してます。あとは試してみないとわかんないんで、3ヶ月お試しでよければ半年、1年と期間を増やしていく感じで進めてます。”外れる”ことも多いので（笑）
🐵さん：
最近多くの会社さんからアナリストや、データサイエンティスト多数在籍してますっていう話を聞くと、それはそれで僕はいいのかなって思ってます。データを使える人間が増えてくれたら、それはそれで僕らとしてはありがたいし、この先もアナリストって日本の場合やっぱりまだまだ足りないと思ってるので。
データサイエンティストの端くれでも、かじった程度でも、仕事をやってみて嫌にならなければ強制的にでもこの世界で食っていかねばならぬって思ってくれる人がたくさんいればいるほど僕はありがたいなと思ってます。🦁さんおっしゃるように、経験や考え方、サボるやつなのか等、それらは一緒に仕事してみるとわかります。
他方、メンバーの中にもいろんな得意不得意があるので、得意不得意を活かせるようになんとかやる気を出させて行ったりその気にさせて行ったりすることが年寄りの役割かなと思ってますので、データサイエンティスト多数！と言うような会社が増えてくれば、そのような会社の人たちとも話をしていきたいなと思ってます。
🦡さん
なるほど、ありがとうございます。
さきほど「”外れる”ことも多い」って仰ってましたけど、「外れる」って具体的にどんな感じですか？？
🦁さん：
残念ながら、コミュニケーションできなかったりすることがあるんですよね。自社のメンバーにも責任はありますけど、”外注の人”と”社内の人”で壁ができた上で業務を進めると、コミュニケーションでGAPが生じてしまうので、コミュニケーションGAPを乗り越えられることが大事だと思ってます。あと、プロジェクトによって求められるところが違うので、最低限自社のメンバーとコミュニケーションができること、場合によってはビジネスサイドとコミュニケーションを取ることもあるので、コミュニケーションの観点が一番大きいですかね。外の人にお願いする時の大きなGAPって、紙のスキルに表れていないところなのでなかなか難しいと思ったりしますね。
🕊️さん：
良い悪いって話ではないんですが、システム会社さんに限らないかもしれませんが、実務を知らないデータサイエンティストが来ると失敗する気がします。モデルを作った後、どう運用するかっていう目線がないと、結局どう使っていいか現場の人もわからないので、お見合いになるっていうのがあるのかなと。アラートを出すにしてもどこまで出すのか、どの基準値で出すのかなどですね。データサイエンティストってかなりのドメイン知識を求められると思うんですけど、システム会社さんって、引き受ける業務によって強い分野も弱い分野もあると思うんですね。弱い分野だった場合、最後の出口が分からずに、データサイエンスを始めてしまって、ただ始めてしまった以上、なんとか形になり、よくわからないものができるような、不幸なケースがあるのかなと。データサイエンティストがいて、データ分析ができるっていうのはできるとは思いますが、そこにドメイン知識がある人がいらっしゃると嬉しいですね。
🦍さん：
🕊️さんが仰ったのがまさしくだなと思うのが、今の組織が立ち上がる前、複数のコンサル会社さんに依頼していた部門があったんですね。その成果物が納品され時に「これどう使えるんですか」みたいな話が始まってしまったりとか、そもそも「これ言ってた要望とちょっとずれてるよね」みたいなところが出てきたんですね。さきほどの🦁さんのコミュニケーションの話もそうですし、ドメイン知識もそうだと思うけど、ヒヤリングして何が課題なのかちゃんと特定できて、それに即した成果物になってるかどうかっていうのが一番気になるところかなと思います。「データサイエンティストがたくさんいます。」みたいなことに対して訝しさは個人的にはないのかなと思ってて、どちらかと言うと、”過去こういう成果がありました”みたいなことがあった方が具体的にイメージしやすくて頼みやすいのかなと思ってますね。
🦡さん
ありがとうございます。
🦁さん：
あ、整理できてきた。
今日のテーマでもありますけど、プロジェクトはチームで作るので、ピン(個人)で人を評価しないんですよね。そのプロジェクトにミッシングパーツがあった時に外の人と、うちのメンバーとでチームを作って課題解決していくので、そのプロジェクトごとに必要とされるスキルセットが変わってくるんですよね。ビジネスサイドとコミュニケーションしなきゃいけないパーツが足りないケースもありますし、言われたことをきっちりできる人が足りないパーツのケースもあるので、プロジェクトに対してチームを作った時、そのチームがworkすることが重要なのかなって思いました。
明らかにうまくworkしてるケースは、そのチームのパートナーさん(外注先)のデータサイエンティスト束ねたりプロジェクトマネージメントしたりチームマネジメントできる人が優秀だったらうまくworkしますね。
例えば、今10人希望でお願いしてる会社さんがあるんですけど、そこでチームマネージメントもプロジェクトマネジメントもできる人を入れてもらっていて、その下に彼の人選で何人かアサインしてもらってるんですけどそこはうまくいってますね。なので、そのような方がいると信頼できるし、お任せしやすいかなっていうのはあります。ピン(個人)で優秀なのも一つなんですけど、会社としてそういうマネジメントができるというのも、お願いする上で重要かなってちょっと今話を聞いてておもいました。
🦡さん
ありがとうございました。
🦡さんの質問：孤軍奮闘している人の見つけ方
🐶さん：
ちょっと答えはないんですけど、縦割り度合いによりますが、私の場合は横串機能を果たす役割があってキャッチアップができたんですよね。基盤組織というか、他の部署と横に薄く繋がってる組織がきっかけになったり、意外とそういう組織が孤軍奮闘してるケースももしかしたらあるのかもしれないですね。
あとは、トップダウンでスキルアセットを整備していく目的で動く組織をまず立て、リサーチをしていかないと拾えないんじゃないかなと思います。私の場合はトップダウンの後ろ盾もありましたし、横串的な機能の役割もあったので、たまたま孤軍奮闘している人を知る機会がありました。
🦡さん
ありがとうございます。この会で話していることを私は自分の部署に持ち帰って「こんな話ししました。」って報告をしているんですけど、その中でも「言っていることは分かるんだけど孤軍奮闘してる人をどうしたら見つかるんだろうね？」みたいなことをみんなで話していたんですね。以前に🦒さんも仰ってましたが「データ分析をする組織に「これやって」っていうお願いが来るんだけど、それ誰に売るのか設計されていない」っ事象が起きているって話がありましたが、当社でも起きていて。。。
全然ビジネスのことが考えられない人が新しいものを作ろうとしているので、売れないビジネスを量産しちゃっているのを見たくなくて、組織で一人で頑張ってる人をどうやって見つけてあげられるのかなっていうのに悩んでいました。
🐶さん：
話を聞いて思い出したことで言うと、定期的な部長会のような場で報告や共有されたアウトプットの中で「何でこの部署でそれが出来るんだろう」って違和感を感じたことがあって、それを深掘りしていくと孤軍奮闘してる人がいて、それを部長が報告してたりしたのがある気がしました。
僕の経験上ですけど、縦割りの部署全体が集まった報告や共有を受けるような場で、アンテナを貼り、違和感に気付くことができると、組織で一人で頑張ってる人を見つけられるんじゃないかなと。
🦡さん
ありがとうございます。ちょっと考えてみたいなとおもいます。
🐶さん：
上司は上司で自慢話っぽく言いたくなるのかなと思っているところもあり、それを深掘りしてみると一人でやってたりするので、アンテナ貼っていれば気づけることはある気がします。
終わりに
はい、じゃあそろそろ良い時間なんで終わりにしましょうか。 ご参加ありがとうございました。
同じテーマなような気もしてるけど、同じテーマでも新しい発見があるので、気兼ねなくまたお越しください。
毎回必ず参加しなくても、何か困った時にここに来ればいいっていう場なので、今日みたいに色んな広がりもあったりするので、来月も同じ感じで続けたいと思いますので、皆さんよろしくお願いします。お疲れ様でした。