Data Developerのメモ帳

機械学習とかデータ分析とかしているData Developerのメモ帳です

ドメイン知識について解説してみた

f:id:Grahamian:20210722125857p:plain

データサイエンティストとかデータアナリストみたいな仕事をしていると「ドメイン知識」って言葉を聞くとおもうのですが、具体的な内容や身につけ方を解説している記事などが見つからなかったので配信を通して自分なりに解説してみました。

youtu.be

詳しくは配信を見てね!って感じなんですけど私が言いたいことは下記の2枚のスライドに集約されています。

f:id:Grahamian:20210722005702p:plain

f:id:Grahamian:20210722005709p:plain

ドメイン知識って、プロダクトや現場をブラックボックスにできるビジネスモデルみたいな領域から始まって、業界や商習慣などを理解する次のレイヤーがあって、最後は具体的でサービスごとに異なる現場やシステムの特徴の3つレイヤーに分解できるよねって話をしています。
上のほうが汎用的で下にいくほど社内で有識者を探したりしないといけないという構造です。
この構造や理解の仕方は現状で思いついている整理なのですが、もうちょっとわかりやすく使いやすい形に整理し直せる気はしている。良い方法あったら誰か教えて。

一般に、データを分析したり実験といった科学的検証をおこなうためには対象の構造や特徴、実験の性質を理解している必要があります。
これはビジネスアナリティクスというか科学的検証という行いをするために必要不可欠なことなんですけど、地味だからなのか話題になりにくい感じがしますね。

もし、ほかにも解説してほしいネタとかあったら言ってもられば解説していきたいと思うので動画のコメントやTwitterで教えていただければ嬉しいです。

↓チャンネル登録よろしく↓

www.youtube.com

会社を辞めてフリーランスになってみた

4月末をもってCrezit株式会社を退職し無職になりましてフリーランスになりました。 せっかくなので考えたことを書いておこうと記事をかいています。

辞めた理由

いろいろあるけどメインの理由は会社の事業が方針転換をして自分がやる業務内容が変わってしまい興味からハズレたことですね。これはシード期だからしょうがない。

なんでフリーランス

前からフリーランスをやってみたかったというのが半分、入りたい会社が特にないというのがもう半分。

まず前者ですが、IT業界はフリーランスがやりやすいということもあり経験できるなら経験したかった、という理由です。
個人事業主なので大したものではないですが自分の名前だけで金を稼いで生きてみるということに興味がありました。

後者はそのまんまですね。いろいろと調べたのですが現状はピンとくる会社がないです。
それなりにスタートアップも含めていろんな会社の情報を調べているのですが、なかなか自分がやりたいとおもうことが見つからず、半ば自分探しの旅だと思ってます。

あと、IT業界に入ってから私なりにずっと全力疾走してきたのでちょっと休みたいという気持ちもあります。フリーランスなら働く時間を調整できるので。

仕事あんの?

前から副業として業務委託をほそぼそと受けており、ちゃんと仕事を探せば食っていく分はあるだろうなとおもって始めたので不安は特にありませんでした。
実際は食っていくには困らないくらいというか思ったより忙しくなりそうです。ありがとうございます。
とはいえ、データ界隈はエンジニアほど仕事がたくさん市場にあふれているわけではないので少し難しさはありますね。ここらへんはそのうち配信で話したい。

おわりに

ということで、しばらくはフリーランスとしてふらふらして生きていきます。
そのうちいい感じの会社を見つけたりしたら会社員になるかもしれませんし、会社立ち上げるかもしれないし、Youtuberになる世界線もあるかもね。 とりあえず5月はほぼ仕事がないので積みゲーを消化するぞ。

宣伝

最近はYoutube頑張っているのでよかったら遊びにきてください!
↓みたいな、ゆるゆるとデータ界隈のことを話す配信をしたりしてます。

youtu.be

webサービスに関わるうえで読んでおいてうれしかった本20選

タイトルのとおりです。自分の備忘録というか個人的なまとめ。

統計学とか機械学習とかプログラミングの本を紹介している人はたくさんいるので、それ以外の分野において読んでおいてよかったと感じた本を並べました。
ほとんどがいろんな場所で紹介されるような本ばかりですが、名著はそれだけの価値があるのでやっぱり読んでおくべきだとおもってます。
それぞれの感想とか書きたいんですけど無限に時間が溶けそうなのでとりあえずリストアップだけ。

プロダクトマネジメントマーケティング

たぶん、この分野の本を一番読んできました。市場を理解するという意味ではプロダクトマネジメントマーケティングは同じなのでひとまとめにしています。Lean Analyticsはデータの話が中心なんですが考え方の軸はプロダクトマネジメントなのでここに入れました。どれか1冊を選ぶならINSPIREDかな。

1. Lean Analytics ―スタートアップのためのデータ解析と活用法
2. INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント
3. リーン・スタートアップ
4. コトラーのマーケティング4.0 スマートフォン時代の究極法則
5. グロービスMBAマネジメント・ブック
6. キャズム Ver.2 新商品をブレイクさせる「超」マーケティング理論

カスタマーサクセス

悪い本ではないんだけど今はもっといい本があるかも。「これだ!」って感じの本がないんだよなー。

7. カスタマーサクセス――サブスクリプション時代に求められる「顧客の成功」10の原則
8. THE MODEL マーケティング・インサイドセールス・営業・カスタマーサクセスの共業プロセス

UX

UXの入門者向けの教科書的な本はいくつかあるのですが、どれも同じような内容が網羅的に書かれているのでどれか1冊を読めば大丈夫です。

9. Mind Hacks ―実験で知る脳と心のシステム
10. ゲーマーズブレイン -UXと神経科学におけるゲームデザインの原則-

組織・マネジメント

reworkとwork rulesは鉄板として、『なぜ人と組織は変われないのか』はセルフマネジメントで迷っている人にオススメ。

11. ワーク・ルールズ! ―君の生き方とリーダーシップを変える
12. re:Work(本じゃないけどとても良いので)
13. 1兆ドルコーチ――シリコンバレーのレジェンド ビル・キャンベルの成功の教え
14. SCRUM BOOT CAMP THE BOOK
15. なぜ人と組織は変われないのか ― ハーバード流 自己変革の理論と実践

考え方・思考法

イシュードリブンはぜひ読んでほしいな。

16. イシューからはじめよ ― 知的生産の「シンプルな本質」
17. 申し訳ない、御社をつぶしたのは私です。
18. 人間はいろいろな問題についてどう考えていけば良いのか

その他

ドキュメント書く機会が多いので理科系の作文技術はオススメ。理学部出身の方なら読んだことある人も多いかとおもいますが。

19. 決算書がスラスラわかる財務3表一体理解法
20. 理科系の作文技術

いじょーです。読書は大事。

宣伝

最近はYoutubeでもデータの話をしはじめたのでよかったらチャンネル登録してね www.youtube.com

データ分析基盤とアナリストはどちらが先か?卵と鶏問題

2021/02/26 最後尾に追記あり

酒を飲んでるけどブログなんてそんなもんやろと思いながら書く。

旧知*のTJO氏がこんな引用RTをしていました。
Twitterでは、の意味

これは自分もはむかずさんの意見に近くて、最初に3をやってその人に全権委任して1と2をやってもらう(その代わり相応の待遇で報いる&完遂するまで忍耐強く待つ)というのがベターかつ現実的だと思ってます。全体像が見えない中で1と2を先にやろうとすると、それまでに組織が疲弊して3に辿り着けない

ここで挙げられている下記の3軸が組織でのデータ活用において重要であるということは言うまでもないでしょう。

  1. 基盤の構築
  2. 組織内への浸透
  3. アナリストの採用

その中で順番は非常に重要になります。で、私もTJO氏やはむかずさんの意見に全く同意で専門家を雇う(もしくはコンサルタントなどに短期で入ってもらう)ことで全体像をみてから具体的に作っていく流れが必要だと思っています。

これは極めてシンプルな理由で、使う人の意見なくデータ基盤を構築するというコストを払うことはリスクが高いからです。プロダクト開発と同じような考え方なんじゃないかな。特にデータ活用は専門性が高い領域なので専門家が全体像を見せることが重要になってきます。

ここで「データの専門家を先に雇うことは無駄なんじゃないか」という意見がでてきます。「高い金を払ってアナリストやデータサイエンティストを雇ったのに実際にやっていることは分析環境作るためにテーブルのcreateみたいなことしてるの金の無駄じゃない?」みたいなコスト感に対する意見がでてくるのはまっとうだと思います。しかし、私はそれが必要だとわかること自体に専門家を雇う価値があるとおもってます。専門家を入れていなければ、おおよそ見当違いのデータ基盤を作って時間と金と精神力を無駄にしていた可能性があるからです。

なぜ、このような意見のすれ違いが発生しうるのかというと「コスト」というものを考えるときにリスクを考慮にいれるか否かという点に尽きると考えます。「何を作ればよいのかわからないけど、とりあえず作る」をするよりも(場合によっては業務委託など費用を抑えた上で)「なにを作るべきか見極めながら作る」ほうが最終的な損失が減る可能性が高くなる、実質的な利益を得やすくなるわけです。

なので、TJO氏がいうようにデータの専門家にまず参加してもらいプロジェクトの権限を渡して基盤開発を行ってもらうという流れが妥当な判断となる、というのが私の意見になります。

ちなみに、まともなデータサイエンティストやアナリストならば十分に整った分析基盤がなくてもある程度の価値を発揮することが可能です。なぜならデータ分析は分析基盤がなくても可能だからです。たとえば、サービスのデータベースから直接データを抽出して手元でアルゴリズムを構築したりスプレッドシートで分析するようなことはできます。これでも、実行速度やセキュリティの課題などはありながらもアナリストとして価値を発揮することはできます。(あくまでも分析基盤というものをBigQueryのような分散処理基盤やデータマートのようなもの、と仮定した場合です)

まとめると、まずは専門家を招き入れ全体像の認識を整える、専門家に権限を渡して必要なものを構築する指揮をしてもらいながら可能な範囲で分析をしてもらうというのがデータ活用な第一歩になると私は考えています。
(こういう「まずなにからしたらいいんだ…」みたいな課題感を抱えている会社の方いたらご相談いただければコンサルするのでご連絡を!)

追記 2021/02/26 鮭さんの意図を誤読していたようです。大変失礼しました。 こちらの考えは私の意見と全く一致しますね。

最近はYoutubeでもデータの話をしはじめたのでよかったらチャンネル登録してね www.youtube.com

効率が良いとおもう会議のやり方

前職でやっていた会議のやり方が効率よいとおもうので備忘録を兼ねて書き出してみます。やっていることは単純でデメリットはほぼないのでやり得です。

主に下記のような効果を狙っています

  • 確実に会議で成果を得る
  • あとから見てもわかる
  • 周りからみてもなんとなくわかる
  • 無駄を省く

定刻に始めて定刻に終わる

当たり前なんですけど予定通りに初めて終わらせることを意識します。ある程度待っても始まらなかったらリスケしましょう。議論が盛り上がると延長したくなりますが予定時間を過ぎたら改めて別の時間に設定し直しましょう。

予定どおりに始めることは待ち時間という無駄を減らします。待っている時間は何も生みません。生産性が0です。これは確実に減らしていくべきでしょう。

予定どおりに終わらせることは生産性の低い議論を打ち切る効果があります。だいたいにおいて予定よりも議論が長引いているときは会議を設定したときの仮説が間違っていることに起因します。そのときは検討事項を整理して再度会議を行ったほうが効率が良いです。

基本は30分で1時間を超える会議を避ける

感覚ですが1時間を超えると一気に集中力が落ちます。集中できない会議をダラダラやるよりも短く何度かに分けたほうが良いと想います。確認や認識合わせならば30分で完了できます。議論が必要でも1時間あれば十分ですし、それを超えるならば議題を盛り込みすぎでしょう。後述しますが、1つの会議で議論する対象は絞ったほうがよいです。

例外的に長時間の会議をしてもよいのはチームビルディングのように長時間過ごすことが目的の場合や難しい議題を深く議論することが目的の場合です。逆にこの場合は3時間とかもっと長く確保してもよいかもしれません。それでもリフレッシュを挟むなど集中力を維持できる工夫は必要でしょう。

必要ない人を呼ばない・無駄に感じたら参加しない

私が知る限り、ほとんどの人間は一度にたくさんの人の発言を聞きながら議論することはできません。そのため、会議の効率を考えたとき参加できる人数には限りが生まれます。なるべく少人数でおこないましょう。逆に自分が不要だと感じたら会議の参加を辞退しましょう。「とりあえず参加しておいて」という発言は黄色信号です。

大量の人を呼んで会議をすることに慣れている人からすると参加者を絞ることは難しいでしょう。これを行うためにも後述するように会議の目的を明確にし議事録を作成することは必要です。絞ったテーマであれば多くの参加者は不要ですし、議事録があるならば関係者に情報を伝達することが可能です。

会議の目的を明確にする

その会議は何をするのか事前に明らかにし共有しましょう。「○○を決定する」とか「XXの進捗を共有する」とかそんな感じです。たとえば進捗確認をする会議では確認だけおこない途中で生まれた検討が必要な課題は別の会議へ切り出しましょう。もちろんその場で結論が出る場合はその限りではありませんけども。

すべての問題を1つの会議で解決することはできません。なんでもかんでも1つの会議に詰め込むことが好きな人は多いです。私はそのような会議にでくわすと無駄に責任をもっている関数を見たような気分になります。解決できていない課題があることが明確になったのならばそれは会議の成果です。ぜひ別の会議で検討しましょう。

議事録は簡潔にみんなで書く

議事録は絶対に重要です。あとから振り返ることができますし議事録を共有すれば周りの人にも何を話したのか知ってもらうことができます。このとき、少なくとも社内向けであれば、議事録はキレイな文章で書かれている必要はありません。むしろ簡潔であるほうが読みやすく好まれます。私は箇条書きで書く方法が好きです。テーマごとにブロックでわかれているので書きやすく読みやすいです。

くわえて、議事録はみんなで書きましょう。もちろん議事録係などを設置してメインに書いてもらう方法は良いですが、議事録を完成させることは会議参加者の義務です。全員で良い議事録を作りましょう。前述した箇条書きを使うと書きたいところに書きたいこと追記しやすいのでオススメです。また、みんなで書くためにも共同で編集できるGoogle Docsなどを使うことはとてもよい方法だとおもいます。

議事録は事前に作る・目を通す

会議を実施する前に議事録をある程度作成しておきます。具体的には検討事項や決定したいこと、相談したいことなどを書いておきます。話す予定のことはすべて書いておきましょう。また、共有したい資料などがあればそれらも添付しておきます。会議が開始した時点で想定されるアジェンダが出揃っており全員が把握していることは理想です。難しければ会議開始の5分をこの時間に使いましょう。事前に議題を並べることで話忘れのような無駄を避けることができますし、時間配分もうまくできるようになります。逆に会議を進めながら後出しで議題を出すと無限に会議が続きます。うまくこの方法を使う技として定例会議の場合ならテンプレートを作成しておくと良いでしょう。

この方法を話すと「事前に情報が出揃っているなら会議をする必要がないのでは?」という意見を聞きます。その意見は全くそのとおりです。事前に洗い出した時点で会議をする必要がないなら会議をする必要はありません。会議は目的ではなく手段です。

次のアクションを明記し合意する

会議が終わったのに何も進まないという現象はこれができていないことが多いです。会議が終わるときは次のアクションを言語化し議事録に記述し参加者と合意しましょう。たとえば「タスク○○をAさんがオーナーになってすすめる」とか「次の定例までに○○についてBさんが確認し事前に展開しておく」といった感じです。重要な点は "誰が" "何を" "いつまでに" やるのか書きましょう。つまり会議が終わったあとに何をすればよいのか明確になっている状態を目指します。これを行うためにも会議の進行は5分程度の余裕をもつべきです。


私が効率がよいと思っている会議のやり方について簡単にまとめてみました。もちろん、他にも細かいテクニックはたくさんあるんですけど重要だとおもった点を記載しています。広く一般に使える方法論だと考えていますが、状況によって変わるのでそこらへんはいい感じにしてください。会議の生産性って大事なのでみんなで生産性高めるように習慣づけていきましょう。

データサイエンティストという仕事について分解してみた

ふと考えたので書きます。個人の感想です。Amazonのレビューくらいの気持ちで読んでください。

モチベーション

世間でデータサイエンティストという言葉が流行って数年経ち、そろそろこの言葉を使う人も減ってきた昨今ですが、データ周りの仕事って相変わらず曖昧で外からみたらなにやってるかわかりにくいですよね。で、ザックリというならデータ周りの仕事ってデータアナリストと機械学習エンジニアという2つの職種にわけることができるなーとおもったので文章にするかーという気持ち。

データアナリスト

データアナリストはデータを分析したりモデリングして戦略とか戦術を検討する人、もしくはそれを助ける人。アナリティクスチームはここ。ビジネス側のチームであることが多くてファイナンスや需要予測、KPI設計などをやるイメージです。

古典的な仕事でいうと経営企画とか事業戦略というポジション。マーケターも近いかも。リソース配分の決定をしたり、シミュレーションをしたり、必要な数値をもってきたり、施策の結果を検証する仕事。そういう仕事自体は昔からあったので、それが特化したポジションかな。

高度な機械学習技術やエンジニアリングスキルよりも問題を見つけたり事象を分解、数値におきかえるスキルが重要です。やっていることはビジネスコンサルタントなので、コンサルタントに必要なスキルはデータアナリストも必須で、そこに加えて統計学や実験設計みたいなスキルが必要です。ロジカル・クリティカルシンキングとかビジネス理解とか。ファイナンスとかそういう経営スキルみたいな知見はそこまでじゃないかも。数字と数学で問題を解決することに特化したコンサルタントという感じ。

機械学習エンジニア

機械学習エンジニアは機械学習を得意とするエンジニア。フロントエンジニアがフロントエンド技術に詳しいのと同じ感じです。機械学習を使ってサービスを開発するイメージ。

名前のとおり機械学習エンジニアはエンジニアなので開発をすることが仕事。メインは機械学習を使った機能開発になるけれど、実際にサービスを開発するときは機械学習以外にもwebサービスとしての実装やインフラ構築が必要になるので、場合に応じてそれらの開発を行うことも仕事になると思います。また、機械学習をサービスに組み込む場合はML Ops的なインフラ構築が必要になることもあるので、そこらへんも含めて機械学習エンジニアチームの仕事ですね。

前述したように機械学習エンジニアはエンジニアなので機械学習に特化しているけれど最低限の技術は必要だと考えてます。とはいえガッツリ高いレベルが必要って感じではないので、ひととおりサービスを実装できるくらいあればなんとかなると思います。基本的に機械学習を使ったwebサービスといってもマイクロサービス化して独立していることが多いので、高いレベルの技術は必要に応じて学ぶくらいで大丈夫だとおもうけど。

雑感

なんとなく「データサイエンティスト」と呼ばれる人をデータアナリストと機械学習エンジニアにわけて書いてみたらスッキリした。やっぱりフワッと思っているデータサイエンティストとはこの2つなんだろう。データサイエンティストって単語はあいまいだから使うのやめよ。

Crezit株式会社へ転職します

はい、タイトルのとおりです。

今日が最終出社日で、9月末をもって3年と9ヶ月お世話になりましたfreee株式会社を退職し、10月よりCrezit株式会社へ転職します。

Crezit株式会社とは?

消費者与信の領域で頑張るFintechスタートアップです。まだ2期目のできたてほやほやで、私も社員一桁。特にモバイルに特化した融資・与信サービスの展開をしています。

corp.crezit.jp

↓こんなサービスを展開しています。

モバイル完結の少額融資サービス

crezit.jp

賃貸初期費用分割サービス

openup.crezit.jp

なんでCrezit?

Crezitへ転職しようと思ったのは「私がやりたいこと」と「Crezitが求めるもの」が一致していることがかなり大きいです。与信というデータサイエンスが強力に活きる舞台があり、データ関係のチームや基盤をゼロから立ち上げるというチャレンジングな機会などは自分の求めているものでした。ここまで合致することはなかなか珍しいと思います。Crezitがなかったらfreeeにそのまま在籍していたと思います。

ちなみに、声をかけてもらったのはTwitter経由で、Crezitができたばかりのころに声をかけていただき軽くランチを食べたのがキッカケでした。当時はわたしがやれることが少ないため一旦ながれましたが、そこから1年経って改めてオファーの相談を受け、今日に至る感じです。

やること

Crezitのデータまわりを全部やります。クレジットスコアリングモデルを作ったりデータ基盤構築したりデータ分析したりデータ周りのチームの立ち上げもやります。freeeでもAIラボという機械学習チームの立ち上げをしていましたが、今回はそれ以上になにもないのでマジでなんでもやらないといけません。ゼロから始める異世界転生ハードモードです。

おわりに

3年9ヶ月という短い間でしたがfreeeでは技術的なハードスキルに限らず、コミュニケーションやメンタル面などソフトスキルも含めて大きく成長する機会を得ることができました。クソ生意気なガキがまともな人間になれたのはfreeeのおかげだと思っています。自分の関わった人もそうでない人もありがとうございました。本当に心から感謝しています。辞めはしますが、freeeはとても良い会社でした。

10月からはできたてスタートアップという濁流に揉まれるような生活が始まるので久々にエキサイティングな日々が送れそうです。忙しくはなりますが、Twitterやblogはいつもどおりなので、今後ともGrahamianをよろしくお願いします。

ちなみにCrezitでは様々な職種で人材を募集しているのでご興味ある方はぜひご応募いただけると嬉しいです!

[追記] その後、退職しました。

grahamian.hatenablog.com