Slide 1
Slide 1 text
データサイエンティストのための
エクストリームプログラミング入門
2023-03-28
株式会社ユーザベース 野中 賢也
Slide 2
Slide 2 text
2
自己紹介
● 野中賢也
● 前職：広告代理店で機械学習エンジニア
● 趣味：読書(SFにはまりつつある)
● XP歴もデータサイエンス歴も短め(1年と4年)なのでお手柔らかに
焼き肉を食べて微笑んでいる近影
Slide 3
Slide 3 text
3
【アイスブレイク】
(広告代理店出身なので？)
学生のときに聞いてなるほどと思った
マーケティングのある定義の話から始めます
Slide 4
Slide 4 text
4
マーケティングとは継続的に売れる仕組みを作ることである
Slide 5
Slide 5 text
5
【本題】データサイエンティストの定義
● ChatGPTいわく
○ 大量のデータから価値を生み出すことを目的とした...(略)...専門家
Slide 6
Slide 6 text
6
こっちの定義の方が良さそうではないですか?
データから価値を生み出す専門家
↓
継続的にデータから価値を生み出す仕組みをつくる専門家
Slide 7
Slide 7 text
7
データサイエンティストの再定義
継続的にデータから価値を生み出す仕組みをつくる専門家
↓
「データから価値を発見する」
+
「発見した価値を継続的に生み出し続ける」
Slide 8
Slide 8 text
8
データから価値を発見する
● データからビジネス的価値を発見するために使える方法論は多く存在
○ 「イシューから始めよ」などに代表されるコンサル本
○ 大学院で主に経験・学ぶことができる科学的方法論
○ 機械学習分野でも、このトピックに絞った書籍が執筆され始めている
■ 「戦略的データサイエンス入門」
■ 「AI・データ分析プロジェクトのすべて」
■ 「評価指標入門~データサイエンスとビジネスをつなぐ架け橋」
ユーザベースのメンバーの一人も共
著者になっています！
Slide 9
Slide 9 text
9
発見した価値を継続的に生み出し続ける
● なぜ継続性が重要なのか?
○ 機械学習モデルの外の環境とニーズの変化が必ず起こるから
■ 簡単な例
● サイトの回遊行動から、どのユーザーがConversionするかを予測す
るモデルを開発(当時state of the art!)
● プロダクトが依存しているPlatformが、モデルが使用している特徴
量を提供しなくなる
● その特徴量を使用しないモデルの開発する必要性
○ あるあるかな？
■ 当時の担当者不在
■ ソースコードの可読性が低い
■ 社内の誰も仕様を把握していない
Slide 10
Slide 10 text
10
発見した価値を継続的に生み出し続ける
● データから価値を発見する方法論は、状況変化が考えられていない
○ その時点のスナップショットで最適な機械学習モデル
○ ビジネス環境の変動⇒提供価値の半減
Slide 11
Slide 11 text
11
発見した価値を継続的に生み出し続ける
● 価値発見の方法論ほど、継続的な価値提供の方法論は発達していない印象
○ (私含め)多くのデータサイエンティスト/MLエンジニアのバックグラウンド
■ =ある時点での分析や研究の成果に責任を負っている
● 機械学習・人工知能の研究者
● マーケティングの定量分析の専門家
● 大学院で定量的な分野を学んだ・研究した人
● 物理学、経済学、心理学etcetc
● 戦略・経営・分析コンサルティング企業出身者
○ 最近だとMLOps(DevOpsの考え方の適用)などもある
■ 2018年にGoogleが提案
Slide 12
Slide 12 text
12
そこで、今回のテーマである
エクストリームプログラミング(XP)
登場！
Slide 13
Slide 13 text
13
エクストリームプログラミングとは?
● 1990年代：Kent Beckが開発・提案したソフトウェア開発の方法論
○ 「注意して、適応して、変更する」パラダイム
エクストリーム・プログラミング、XP（英: Extreme Programming）は、 ソフトウェア品質 を
向上させ、変化する顧客の要求への対応力を高めることを目的としたソフトウェア開発
プロセスである。(引用: wikipedia)
● 変化に対応した方法論がデータサイエンスコミュニティ内で発達していないのな
ら、ソフトウェアエンジニアリングの成熟した方法論をパクろう！
Slide 14
Slide 14 text
14
原典である以下の書籍(2~4章)が言っていることをかいつまみながら
機械学習・データサイエンスの文脈で解釈して読んでいきます。
(具体的なソフトウェア開発方法よりも抽象的な考え方に注目します)
Slide 15
Slide 15 text
15
価値・原則・プラクティス
● プラクティス
○ 具体的にエクストリームプログラミングでは何をやるのか?
● 価値
○ 好き嫌いの判断基準となるもの
● 原則
○ 価値から各プラクティス導くために必要となるもの,論点
● データサイエティストが好きそうな理解
○ 価値=公理、原則=定理、プラクティス=各定理の現実世界への応用
Slide 16
Slide 16 text
16
ここからは5つある価値(公理)をひとつず
つ順を追って説明していきます！
Slide 17
Slide 17 text
17
コミュニケーション(Communication)
Slide 18
Slide 18 text
18
コミュニケーション
● 最も重要な価値として位置づけられる
..最も重要なのは、コミュニケーションである。開発中に問題が発生したときには、すで
に誰かが解決策を知っていることが多い。だが、その情報は変更する権限のある人に
は伝わらない。
● コミュニケーションを重視することで変化に強くなる
○ チームに情報が行き渡り業務が個人に属人化せず、退職異動に強い
○ 適切な情報が早く手に入ることで、変化が起こったことに対応できる
Slide 19
Slide 19 text
19
コミュニケーション
● データサイエンス業務においても聞けばわかることの方が多い
○ データの前処理
■ 取りたいデータのエンドポイント
■ APIから返ってくるデータ
■ DBに格納されているデータの形式・意味
○ 問題の定式化
■ ビジネスサイドとのコミュニケーション
○ アルゴリズム改善
■ アルゴリズムに強い人に聞きに行く
Slide 20
Slide 20 text
20
コミュニケーション
● やってみるのは違う
● 当たり前を「エクストリーム」にやっている感覚
○ ドキュメントをほぼ作らず、コードで表現することを重視
○ Gather, オフラインペアプロ
Slide 21
Slide 21 text
21
シンプリシティ(Simplicity)
Slide 22
Slide 22 text
22
シンプリシティ
● 単純な/簡単な方法を選ぶのではなく、課題を解決するために必要十分な方法を選ぶ
私は「最もシンプルで、上手く行きそうなものは何ですか?」と質問するようにしてい
る。...私は、シンプルすぎてうまくいかないものについて質問しているわけではない。
無駄な複雑性を排除するために、何ができるかをかんがえてもらっている。
Slide 23
Slide 23 text
23
シンプリシティ
● 機械学習的にもシンプルなモデルの方が好まれる
○ より良い振る舞いをする
■ モデル選択
● 情報量基準
■ オッカムのカミソリ
● L1,L2正則化
○ Neural Networkで皆が使いたくなるアーキテクチャ
■ GAN
■ Attention
○ baselineから始める
Slide 24
Slide 24 text
24
フィードバック(Feedback)
Slide 25
Slide 25 text
25
フィードバック
最初に決まった方向性が、長期間そのまま有効であることはない。...変化は割けられ
ないものであり、変化がフィードバックを必要とするのである。
● 状況の変化そのものへの対処方法
Slide 26
Slide 26 text
26
フィードバック
● FBが有効な3つの条件=機械学習PJではすべて当てはまる
○ 「正しく」やる方法がわからない
○ 今日は正しかったとしても、明日間違っている可能性が高い
○ 「正しく」やるには、時間がかかりすぎる
● ⇒最初から完成させるのではなく、できるだけ細かく早く多くフィードバック
をもらって、漸進する
Slide 27
Slide 27 text
27
フィードバック
● XPのフィードバック=機械学習システム全体のレベルでの勾配降下法
○ より多くより早く勾配方向を調べて、その方向にシステムを変化させる
■ =ユーザーからのFeedbackをより多くより早く得る
システムの価値
システムの可変要素
人手の運用、前処理、後処理、
モデル自体
真の目的関数はユー
ザーだけが知っている
と仮定
現時点でのシステムの出力
Slide 28
Slide 28 text
28
勇気(Courage)
Slide 29
Slide 29 text
29
勇気
● 勇気
○ 他の価値をより強化することができる
勇気をもって真実を語れば(たとえそれが不愉快なことであっても)、コミュニケーション
や信頼が強化されていく。うまくいかない解決策を捨てて、勇気をもって新しい解決策
を見つければ、シンプリシティが促進される。勇気を持って現実の具体的な答えをもと
めれば、そこからフィードバックが生まれる。
Slide 30
Slide 30 text
30
リスペクト(Respect)
Slide 31
Slide 31 text
31
リスペクト
● いままでに上げた4つの価値が成り立つ前提
○ チームメンバー・他者に対するリスペクト
チームメンバーがお互いに関心がなく、何をしているかを気に求めないようであれば、
XPはうまくいかない。... ソフトウェア開発に関係している人は、人間として等しく重要
である。
● 研究室とかアカデミア出身だと特に気をつけた方が良いかも(自戒)
○ 自身の自由(な発想)を優先するあまり他者への配慮にかけたふるまいになっ
ていないか?
○ もちろん、アカデミア出身の人、皆が皆そうではない
Slide 32
Slide 32 text
32
プラクティス
Slide 33
Slide 33 text
33
プラクティス
● 全員同席
● チーム全体
● 計画づくりと管理
○ 四半期サイクル・週次サイクル・ストーリー
○ 情報満載のワークスペース
● 実際のプログラミング作業
○ ペア・プログラミング
○ テストファーストプログラミング
○ インクリメンタルな設計
● 継続的インテグレーション・デプロイメント
後の二組が説明・実演してく
ださいます！
● 価値を実現するためのプラクティスという考えを持つ。
Slide 34
Slide 34 text
34
データサイエンティストの再定義
「データから価値を発見する」
←サイエンスの方法論によって担保
+
「発見した価値を継続的に生み出し続ける」
←エクストリームプログラミングによって担保
Slide 35
Slide 35 text
35
締めの自論
● ２つの方法論を一人の人間が高いレベルで両立させるのは難しいのでは?
○ 重なる部分はありつつも違う部分は多いと思っている
■ 仕事の範囲：個としての仕事⇔チームとしての仕事
■ 想定アウトプット：ドキュメント(知見)⇔動くソフトウェア
■ コミュニケーション：一人で考える時間も重要⇔取れば取るだけ良い
■ スキルセット：分析・リサーチ⇔ソフトウェアエンジニアリング
● チームとして２つの方法論をマスターしている状態にできていれば良さそう?
○ コミュニケーションの断絶を防ぐため、縦割りではなく、横に割った形
Slide 36
Slide 36 text
36
ありがとうございました！
● XPの価値の部分しか説明できていないため、残りの講演や原典を
参照していただければと思います。