Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
UBtech_vol7 データサイエンティストのための エクストリームプログラミング入門
Search
nonakakenya
March 29, 2023
Technology
1
470
UBtech_vol7 データサイエンティストのための エクストリームプログラミング入門
nonakakenya
March 29, 2023
Tweet
Share
Other Decks in Technology
See All in Technology
Zero Data Loss Autonomous Recovery Service サービス概要
oracle4engineer
PRO
1
5k
3年でバックエンドエンジニアが5倍に増えても破綻しなかったアーキテクチャ そして、これから / Software architecture that scales even with a 5x increase in backend engineers in 3 years
euglena1215
11
4.3k
「完全に理解したTalk」完全に理解した
segavvy
1
270
DUSt3R, MASt3R, MASt3R-SfM にみる3D基盤モデル
spatial_ai_network
3
510
20241220_S3 tablesの使い方を検証してみた
handy
4
870
サイバー攻撃を想定したセキュリティガイドライン 策定とASM及びCNAPPの活用方法
syoshie
3
1.7k
スケールし続ける事業とサービスを支える組織とアーキテクチャの生き残り戦略 / The survival strategy for Money Forward’s engineering.
moneyforward
0
240
いまからでも遅くないコンテナ座学
nomu
0
200
OPENLOGI Company Profile for engineer
hr01
1
17k
機械学習を「社会実装」するということ 2025年版 / Social Implementation of Machine Learning 2025 Version
moepy_stats
3
180
[JAWS-UG新潟#20] re:Invent2024 -CloudOperationsアップデートについて-
shintaro_fukatsu
0
150
rootful・rootless・privilegedコンテナの違い/rootful_rootless_privileged_container_difference
moz_sec_
0
110
Featured
See All Featured
The Cost Of JavaScript in 2023
addyosmani
46
7.2k
Bash Introduction
62gerente
609
210k
The Power of CSS Pseudo Elements
geoffreycrofte
74
5.4k
The Language of Interfaces
destraynor
155
24k
The Pragmatic Product Professional
lauravandoore
32
6.4k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
Producing Creativity
orderedlist
PRO
343
39k
How STYLIGHT went responsive
nonsquared
96
5.3k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Transcript
データサイエンティストのための エクストリームプログラミング入門 2023-03-28 株式会社ユーザベース 野中 賢也
2 自己紹介 • 野中賢也 • 前職:広告代理店で機械学習エンジニア • 趣味:読書(SFにはまりつつある) • XP歴もデータサイエンス歴も短め(1年と4年)なのでお手柔らかに
焼き肉を食べて微笑んでいる近影
3 【アイスブレイク】 (広告代理店出身なので?) 学生のときに聞いてなるほどと思った マーケティングのある定義の話から始めます
4 マーケティングとは継続的に売れる仕組みを作ることである
5 【本題】データサイエンティストの定義 • ChatGPTいわく ◦ 大量のデータから価値を生み出すことを目的とした...(略)...専門家
6 こっちの定義の方が良さそうではないですか? データから価値を生み出す専門家 ↓ 継続的にデータから価値を生み出す仕組みをつくる専門家
7 データサイエンティストの再定義 継続的にデータから価値を生み出す仕組みをつくる専門家 ↓ 「データから価値を発見する」 + 「発見した価値を継続的に生み出し続ける」
8 データから価値を発見する • データからビジネス的価値を発見するために使える方法論は多く存在 ◦ 「イシューから始めよ」などに代表されるコンサル本 ◦ 大学院で主に経験・学ぶことができる科学的方法論 ◦ 機械学習分野でも、このトピックに絞った書籍が執筆され始めている
▪ 「戦略的データサイエンス入門」 ▪ 「AI・データ分析プロジェクトのすべて」 ▪ 「評価指標入門~データサイエンスとビジネスをつなぐ架け橋」 ユーザベースのメンバーの一人も共 著者になっています!
9 発見した価値を継続的に生み出し続ける • なぜ継続性が重要なのか? ◦ 機械学習モデルの外の環境とニーズの変化が必ず起こるから ▪ 簡単な例 • サイトの回遊行動から、どのユーザーがConversionするかを予測す
るモデルを開発(当時state of the art!) • プロダクトが依存しているPlatformが、モデルが使用している特徴 量を提供しなくなる • その特徴量を使用しないモデルの開発する必要性 ◦ あるあるかな? ▪ 当時の担当者不在 ▪ ソースコードの可読性が低い ▪ 社内の誰も仕様を把握していない
10 発見した価値を継続的に生み出し続ける • データから価値を発見する方法論は、状況変化が考えられていない ◦ その時点のスナップショットで最適な機械学習モデル ◦ ビジネス環境の変動⇒提供価値の半減
11 発見した価値を継続的に生み出し続ける • 価値発見の方法論ほど、継続的な価値提供の方法論は発達していない印象 ◦ (私含め)多くのデータサイエンティスト/MLエンジニアのバックグラウンド ▪ =ある時点での分析や研究の成果に責任を負っている • 機械学習・人工知能の研究者
• マーケティングの定量分析の専門家 • 大学院で定量的な分野を学んだ・研究した人 • 物理学、経済学、心理学etcetc • 戦略・経営・分析コンサルティング企業出身者 ◦ 最近だとMLOps(DevOpsの考え方の適用)などもある ▪ 2018年にGoogleが提案
12 そこで、今回のテーマである エクストリームプログラミング(XP) 登場!
13 エクストリームプログラミングとは? • 1990年代:Kent Beckが開発・提案したソフトウェア開発の方法論 ◦ 「注意して、適応して、変更する」パラダイム エクストリーム・プログラミング、XP(英: Extreme Programming)は、
ソフトウェア品質 を 向上させ、変化する顧客の要求への対応力を高めることを目的としたソフトウェア開発 プロセスである。(引用: wikipedia) • 変化に対応した方法論がデータサイエンスコミュニティ内で発達していないのな ら、ソフトウェアエンジニアリングの成熟した方法論をパクろう!
14 原典である以下の書籍(2~4章)が言っていることをかいつまみながら 機械学習・データサイエンスの文脈で解釈して読んでいきます。 (具体的なソフトウェア開発方法よりも抽象的な考え方に注目します)
15 価値・原則・プラクティス • プラクティス ◦ 具体的にエクストリームプログラミングでは何をやるのか? • 価値 ◦ 好き嫌いの判断基準となるもの
• 原則 ◦ 価値から各プラクティス導くために必要となるもの,論点 • データサイエティストが好きそうな理解 ◦ 価値=公理、原則=定理、プラクティス=各定理の現実世界への応用
16 ここからは5つある価値(公理)をひとつず つ順を追って説明していきます!
17 コミュニケーション(Communication)
18 コミュニケーション • 最も重要な価値として位置づけられる ..最も重要なのは、コミュニケーションである。開発中に問題が発生したときには、すで に誰かが解決策を知っていることが多い。だが、その情報は変更する権限のある人に は伝わらない。 • コミュニケーションを重視することで変化に強くなる ◦
チームに情報が行き渡り業務が個人に属人化せず、退職異動に強い ◦ 適切な情報が早く手に入ることで、変化が起こったことに対応できる
19 コミュニケーション • データサイエンス業務においても聞けばわかることの方が多い ◦ データの前処理 ▪ 取りたいデータのエンドポイント ▪ APIから返ってくるデータ
▪ DBに格納されているデータの形式・意味 ◦ 問題の定式化 ▪ ビジネスサイドとのコミュニケーション ◦ アルゴリズム改善 ▪ アルゴリズムに強い人に聞きに行く
20 コミュニケーション • やってみるのは違う • 当たり前を「エクストリーム」にやっている感覚 ◦ ドキュメントをほぼ作らず、コードで表現することを重視 ◦ Gather,
オフラインペアプロ
21 シンプリシティ(Simplicity)
22 シンプリシティ • 単純な/簡単な方法を選ぶのではなく、課題を解決するために必要十分な方法を選ぶ 私は「最もシンプルで、上手く行きそうなものは何ですか?」と質問するようにしてい る。...私は、シンプルすぎてうまくいかないものについて質問しているわけではない。 無駄な複雑性を排除するために、何ができるかをかんがえてもらっている。
23 シンプリシティ • 機械学習的にもシンプルなモデルの方が好まれる ◦ より良い振る舞いをする ▪ モデル選択 • 情報量基準
▪ オッカムのカミソリ • L1,L2正則化 ◦ Neural Networkで皆が使いたくなるアーキテクチャ ▪ GAN ▪ Attention ◦ baselineから始める
24 フィードバック(Feedback)
25 フィードバック 最初に決まった方向性が、長期間そのまま有効であることはない。...変化は割けられ ないものであり、変化がフィードバックを必要とするのである。 • 状況の変化そのものへの対処方法
26 フィードバック • FBが有効な3つの条件=機械学習PJではすべて当てはまる ◦ 「正しく」やる方法がわからない ◦ 今日は正しかったとしても、明日間違っている可能性が高い ◦ 「正しく」やるには、時間がかかりすぎる
• ⇒最初から完成させるのではなく、できるだけ細かく早く多くフィードバック をもらって、漸進する
27 フィードバック • XPのフィードバック=機械学習システム全体のレベルでの勾配降下法 ◦ より多くより早く勾配方向を調べて、その方向にシステムを変化させる ▪ =ユーザーからのFeedbackをより多くより早く得る システムの価値 システムの可変要素
人手の運用、前処理、後処理、 モデル自体 真の目的関数はユー ザーだけが知っている と仮定 現時点でのシステムの出力
28 勇気(Courage)
29 勇気 • 勇気 ◦ 他の価値をより強化することができる 勇気をもって真実を語れば(たとえそれが不愉快なことであっても)、コミュニケーション や信頼が強化されていく。うまくいかない解決策を捨てて、勇気をもって新しい解決策 を見つければ、シンプリシティが促進される。勇気を持って現実の具体的な答えをもと めれば、そこからフィードバックが生まれる。
30 リスペクト(Respect)
31 リスペクト • いままでに上げた4つの価値が成り立つ前提 ◦ チームメンバー・他者に対するリスペクト チームメンバーがお互いに関心がなく、何をしているかを気に求めないようであれば、 XPはうまくいかない。... ソフトウェア開発に関係している人は、人間として等しく重要 である。
• 研究室とかアカデミア出身だと特に気をつけた方が良いかも(自戒) ◦ 自身の自由(な発想)を優先するあまり他者への配慮にかけたふるまいになっ ていないか? ◦ もちろん、アカデミア出身の人、皆が皆そうではない
32 プラクティス
33 プラクティス • 全員同席 • チーム全体 • 計画づくりと管理 ◦ 四半期サイクル・週次サイクル・ストーリー
◦ 情報満載のワークスペース • 実際のプログラミング作業 ◦ ペア・プログラミング ◦ テストファーストプログラミング ◦ インクリメンタルな設計 • 継続的インテグレーション・デプロイメント 後の二組が説明・実演してく ださいます! • 価値を実現するためのプラクティスという考えを持つ。
34 データサイエンティストの再定義 「データから価値を発見する」 ←サイエンスの方法論によって担保 + 「発見した価値を継続的に生み出し続ける」 ←エクストリームプログラミングによって担保
35 締めの自論 • 2つの方法論を一人の人間が高いレベルで両立させるのは難しいのでは? ◦ 重なる部分はありつつも違う部分は多いと思っている ▪ 仕事の範囲:個としての仕事⇔チームとしての仕事 ▪ 想定アウトプット:ドキュメント(知見)⇔動くソフトウェア
▪ コミュニケーション:一人で考える時間も重要⇔取れば取るだけ良い ▪ スキルセット:分析・リサーチ⇔ソフトウェアエンジニアリング • チームとして2つの方法論をマスターしている状態にできていれば良さそう? ◦ コミュニケーションの断絶を防ぐため、縦割りではなく、横に割った形
36 ありがとうございました! • XPの価値の部分しか説明できていないため、残りの講演や原典を 参照していただければと思います。