Data Analystのメモ帳

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

企業のデータ分析は4つのアクションで成り立っているという話

この記事ではデータ活用が進んでいる企業で実際に見かけたデータ活用方法を4つのアクションにわけて説明します。 やや抽象的に書いていますが、多くの企業では共通して下記に説明するようなことを実施しています。 どこの会社も具体的な部分は異なりますが考え方は同じです。 やっていることはシンプルで単純だということを感じ取ってもらえると嬉しいです。

データ活用の4つのアクション

データを用いた経営やサービス開発では大きく下記の4つのアクションに基づいて行われます。 それぞれが完全に独立していることはなく組み合わせて実行されることもあります。 このなかで1~3に対して4番の監視は少し趣が違うアクションですが、まずは説明のために併記します。

  1. 調査
  2. 予測
  3. 検証
  4. 監視

調査

データからユーザやマーケットなどを調べることです。 たとえば「機能Aを使っていないユーザ属性の調査」とか「課金までに離脱しているプロセスの特定」など。 多くの場合で、データのみならずドメイン知識やヒアリングのような定性情報を踏まえて分析されます。

予測

データから将来の需要や施策の効果を見積もることです。 たとえば「在庫発注数を見積もるために4月の商品Bの需要を予測したい」とか「施策Cが寄与するユーザ数から効果を見積もりたい」といった場合です。

検証

施策の効果を客観的に評価することです。 たとえば「広告DとEでどちらのほうがCTRが高くなったのか知りたい」とか「施策Fが売上にどれくらい貢献したのか知りたい」といったケースです。

監視

KPIのような指標として継続的に観察し改善をおこなうことです。 たとえば「サービスの継続率をKPIとして改善しよう」というケースです。

実際の運用

ここまでに4つのアクションを紹介しましたが、実際の現場ではそれぞれが独立に考えられることはあまりないでしょう。 多くは複数のアクションをつなげたサイクルとして実行されます。

実際の現場で多く見かけるパターンは、常時KPIを監視しつつ施策に関して調査・予測・検証をおこなうという方法です。

KPIを監視する

データを活用している企業ではKPIを設定し、それに対して施策を行い改善する方法がよく取られます。 KPIを設定することでチーム内外に対して自分たちの目的を明確に成果を定量的に評価することができます。

KPIの監視は誰もがいつでも見られる状態にし定期的に観察し振り返りを行います。 KPIの変化をとおして自分たちが目標に対して自分たちがどのような位置にいるのが常に把握できるようにしましょう。 ダッシュボードを作成したりメールやSlackで定期的に通知が届くようにする方法もよいですね。 定例会議などで数値をメンバーで確認して変化について議論する方法は取り組みやすく効果的です。

大事なことは、チームはKPIを改善することを目標に動いているのだ、ということをメンバーが心の底から理解し行動することです。 ダッシュボードやSlackの通知は見るキッカケを与えますが、それによって考えや行動に変化が起きないのであれば意味がありません。 KPIを見る、考察する、行動を変えるという一連の流れが起きる必要があります。継続的かつ明示的にKPIを利用しましょう。

どのような施策をおこなうか調査する

前述のようにKPIを改善するために施策を打つことを検討します。そのときに、どの領域に課題があるのか調査するのがこのフェーズです。 定量データに限らずドメイン知識やヒアリングなどで得られる定性データなどを加えて課題の分析と打つべき施策を検討します。

クリティカルな問題を見つけることは一般的に難しい行為です。 問題を見つける方法はいくつもありますが、基本的にはサービスに詳しい人の意見を参考にしながら論点を洗い出し、その周辺を集中して検討する流れが良いでしょう。 全体を網羅的に探す方法は見落としが生まれやすく時間もかかるため、あまり良い方法ではありません。 問題を定量的に調査する際はファネル分析やセグメント分析が役に立ちます。 たとえば、離脱率の改善であればファネル分析をとおして離脱ポイントを解析したり、離脱するセグメントを特定するという方法です。

このようにして課題となる領域を見つけたら、それらの領域を改善するアイディアを出して施策を行います。 施策を定量的に検討する方法として、セグメントによって離脱率の差があるならば上手くいっているセグメントを参考にするやり方があります。 たとえば、離脱率の低いセグメントの多くがなにかの機能を使っているが、離脱率の高いセグメントにおける機能の利用率が低いことがわかっているならば、その機能を使うように促すという施策を考えます。 これは上手くいっているやり方を横展開するという方法なので時間がかからずやるべきことが明確なので非常にやりやすい方法です。 とはいえ、このように改善を行うための施策が定量的に見つかるとは限りません。 なぜなら問題はすでにデータとして蓄積されていますが、上手くいっている状態は未来に話でありデータに存在しないことが多いからです。 そのような場合はドメインに詳しい人から意見を集めたりユーザリサーチをおこなう必要があるでしょう。

施策の効果を予測する

施策を行うときはなにか効果を期待する領域があり、それに対して期待する効果量があるはずです。これを見積もる行為が予測になります。 これは古典的な経営戦略を立案する際にシミュレーションをおこなうことを想像するとわかりやすいでしょう。 調査から得られた施策の効果を見積り優先度やリソース配分、スケジュールなどを決定します。

予測をおこなう最もシンプルな方法は指標の現在と値と施策による変化を経験や一般的な効果から置く方法です。 これはいくらか主観的な予測になりますが何度か繰り返すことでそれなりに実用的な精度になります。 過去に似たような施策を行っている場合はそのときの結果を引用するのがよいでしょう。

重要なことは、どのセグメントにどれくらい効くのか数と割合をそれぞれ考えることです。 たとえば、あるターゲットに対して出している広告を変えることを考えましょう。 このとき、影響を与えるのは当然ターゲットになっているユーザのみになります。 広告を変えたときCTRが1ポイント増加してもクリックするユーザの数はターゲットユーザの領域のみになります。 もし多くのユーザが属しているセグメントが対象となる施策であれば効果は大きくなりますし、少なければ効果も小さくなります。 一方で、広いユーザをターゲットにするほど効果量は小さくなりがちですし、狭いユーザ層であれば効果は大きくなりやすいです。 自分たちのおこなう施策のターゲットになるユーザの数と施策の効果の割合を考慮することでKPIの改善を予測し目標へ必要な施策の種類や数を見積もりましょう。

施策の結果を検証する

施策を行った結果を定量的に検証します。事前にこの検証方法は施策を行う前に考慮しておく必要があります。 検証方法は統計的な手段を用いることが多いですが、難しければ単純に数値を比較するだけでも価値があります。 重要なのは感覚だけで判断せず数値を通して客観的かつ定量的に判断するということです。

検証方法には様々なやり方があります。最もシンプルな方法はKPIを中心に事前に見積もった効果に対して実際の効果を数値で比較するやり方です。 たとえば、広告を既存のものと変えることでCTRが1ポイント向上することを期待していた場合、実際に新しい広告でCTRが何ポイント改善したのか比較します。 新しい広告が2ポイント上昇していれば期待以上の成果ですし、変化が0.1ポイントだったら効果がなかっただろう、という結論になります。 この方法はシンプルで簡単ですが広告以外の影響を除外することができないため確実な方法とは言えません。 広告を入れ替えたと同時にSNSでバズったから伸びただけ、ということもありえます。 しかし、数値も出さずに感覚で判断するよりはずっと良いことは間違いありません。 数値を比較するよりも良い方法としてランダム化比較試験や差分の差分法など様々な統計的手法があります。 詳細は他の専門書に譲りますが、ケースに応じて適切な手法を用いるのがよいでしょう。

数値を用いた検証をおこなう際に難しい点は、事前に検証方法を踏まえて施策を行う必要があることです。 数値を単純に比較するだけならばさほど問題になることはありません。 しかし、統計学的手法を用いる場合は検証に必要な数字を記録したり適切な手法をとおした実験を行わなければいけません。 たとえばランダム化比較試験をおこなうためには対象をランダムに選ぶ必要がありますし、どのサンプルになにが適用されたのかログを残す必要があります。 施策を行う前に検証方法を決めておかなければ妥当な検証を行うことができないということです。

サイクルを回す

以上を踏まえて、KPIを監視しながら課題を調査し施策の効果を予測し結果を検証する、というサイクルをまわします。 データをビジネスで活用するという営みにおいて最も重要なのは1度で終わらせずにサイクルを回し経験を積み重ねることです。 サイクルを回し続けることでビジネスにおける投資の効率がよくなります。

サイクルをとおして経験を積み重ねることで大きく2つのメリットを得られます。 1つ目は成功・失敗する方法が客観的な評価を元に蓄積できること。 2つ目はデータを活用する方法自体の経験値が積まれることです。

1つ目の成功・失敗する方法が客観的な評価の蓄積はデータドリブンの強力な利点です。 データで評価を行うことで再現性のある成功・失敗施策を積み上げることができます。 サービスを成長させるためには継続して成功できる方法を獲得することが必要です。 つまり施策の再現性です。 勘や経験で評価する場合に比べて定量的な評価、特に統計的な手法による評価は客観的に事象を検証することが可能です。 たまたま上手くいった施策にずっと投資したり、運悪く失敗したように見える施策への投資を止めてしまうケースが減ります。 データを活用したサイクルを回すことで再現性のある成功施策を積み重ね、失敗する施策を除外することでサービスの成長への投資が効率よくなるでしょう。

2つ目のデータ活用の経験値をためるということは精度が上がり横展開も可能になるということです。 経験値を貯めることができれば過去の施策の結果を参考にすることで類似の施策を行う際に施策の効果を見積もることが可能です。 精度よく効果を見積もることができれば計画と実績の乖離が減り、適切な投資が可能になります。 また、最初は1つの機能や部署で行っていたことを別の機能やサービスへ横展開することで会社全体でデータを使った管理をより上手く実行することが可能になります。 経験や勘を横展開するためには経験豊富な人材を異動さえる必要があるなど、横展開に限界があります。 一方で定量的に行われた施策は効果が数字として残るため他の人からもわかりやすく参考としやすくなります。 このようにしてデータを活用した管理を精度よく全体へ広げることで会社全体で投資の効率を向上させることが可能です。

まとめ

本記事では、実際にデータ活用を行っている現場でどのようにしてデータを用いた施策実行を行っているのか抽象化し解説しました。 大きく調査・予測・検証・監視の4つに分類し、それらをどのように扱うのか1つのサイクルにまとめています。 データ活用とは抽象化してしまうとやっていることはとてもシンプルでどこも似たようなものだということです。

この記事は抽象的に書いているのでこれだけだと具体的な施策として落とし込みにくいかもしれません。 具体的なケーススタディなんかを参考にアクションに落としやすい解説を追加でやりたいですね。

蛇足:例外について

データドリブンな運営において、KPIへ寄与しないがどうしてもやらなければいけないことは発生します。データをもちいて管理することは強力な手法ですが、データに紐付けることができない、もしくは、紐付けることが難しい状況は生まれてしまいます。そのようなときは悲観せず定性的な感覚から施策を実行してもよいでしょう。これは今までの考え方を破壊するようなやり方に見えますが何事も例外は存在します。

一方で、例外は稀に起きるから例外です。例外が起きる頻度を下げる工夫をおこなったり、自分たちが行っていることが例外であることを自覚することは重要です。例外が増えすぎて常態化するとデータで改善サイクルを回すことは困難になります。そのような状態に近づいてしまった場合は施策の緊急度や重要度をリストアップしてみたり、KPIを中心に目標の認識を揃えるのがよいでしょう。

宣伝

最近はYoutubeで活動しているのでよかったらチャンネル登録してね!

今回の記事の解説配信とかやるよー

www.youtube.com

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

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つなんだろう。データサイエンティストって単語はあいまいだから使うのやめよ。