SIer出身のエンジニアが 機械学習を取り入れた ASPサービス開発で学んだこと
•
2 gostaram•430 visualizações
2018.08.21 「機械学習工学研究会 現場を交えた勉強会 #1」で登壇した際に使ったスライド。 https://mlxse.connpass.com/event/97131/
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a SIer出身のエンジニアが 機械学習を取り入れた ASPサービス開発で学んだこと
Semelhante a SIer出身のエンジニアが 機械学習を取り入れた ASPサービス開発で学んだこと (20)
SIer出身のエンジニアが 機械学習を取り入れた ASPサービス開発で学んだこと
- 1. 2018.08.21 機械学習工学研究会 現場を交えた勉強会 #1 株式会社ブレインパッド 栁原 淳宏 SIer出身のエンジニアが 機械学習を取り入れた ASPサービス開発で学んだこと
- 2. 誰？
- 5. ブレインパッド？
- 7. © BrainPad Inc. 7
- 16. 本日皆さんと お話ししたいこと
- 19. 何が変わったのか？
- 24. 開発工程における違い
- 25. 仕様決めが難しい 業務システム CRM(DMP) BrainPad以前 BrainPadに入ってから 仕様策定決 め や す い 難 し い = 要件定義が難しい = 設計が難しい ● 仕様に合わせた技術選定が可能 ○ 言語、アーキテクチャ、環境... ● 状態遷移（結果、解答）が定義しやすい ○ 業務フローは状態遷移の把握がしやすい ので、データフローがわかりやすい ● 仕様がふわふわした状態なので、色々と試行錯誤 が必要 ○ 言語、アーキテクチャ、環境、アルゴリズ ム... ● ビジネス、サービスへの価値付与はゴールが明確 でなく、答えが一つではない ○ システム化のための定義が難しい
- 26. 開発プロセス ☞ アジャイル(スクラム)風 なぜ、〜風？ ● 仕様が流動的なので、ウォーターフォールは不向き →反復型(アジャイル開発)の方が相性が良い ○ スプリント単位で、細かくスケジュールが修正できるのは良い ○ スプリント内でのスコープ変更が発生しやすいので、タイムボックスで縛ると苦しくなる時がある ■ 結果が積み上がらない時がある ■ 特にアルゴリズム開発時に作成したモデルの結果が芳しくない時など、見通しが悪い時は変更したくなる 管理画面開発サブチーム コア機能開発サブチーム ユーザー分析機能開発 サブチーム レコメンドエンジン 機能開発サブチーム Rtoaster開発での工夫 ● 機能単位でサブチームを分けて、サブチーム毎に開発プロセスの詳細を委任。複数のプロセスを同時並行で動かすことで全体の 影響度合いをコントロール 従来のソフトウェア工学の 知見を活用しやすい もうひと工夫必要 （課題が...）
- 27. 設計・検討において 色々な面で、サイクルが早い ● 技術のサイクル ○ どんどん新しい機械学習の手法、技術、環境、基盤が出てくるので、選ぶ方が追いつかない ■ 開発部では別部署に所属するデータサイエンティストから最近のトレンドをキャッチアップすることでなんとかやって いる ■ 自力では無理 ● 業界のトレンド ○ デジタルマーケティングの世界の移り変わりも早い ■ 競合のキャッチアップ、連携先など色々な面での情報収集が必要 = 技術の陳腐化が早い
- 28. 実装において 仕様(ロジック) 決めが難しい問題が先送りに = どちらかと言うと、作りながら決まっていくことが多い（行ったり来たり） = 試作、設計、実装の線引きが曖昧 ● どの工程にいるのかわからなくなる時がある(=スケジュールをコントロールする上でリスク) ● 実装段階で、どの技術を選択するか候補はあるものの、まだ決まっていない時がある ● レビューが難しい ● ツールは通常のソフトウェア開発時とそんなに変わらないと思う
- 29. 検証 単体テスト(＝ユニットテスト) ● 妥当性の評価 ○ 例えばレコメンドの場合、予約システムと優先順評価のケースとは異なり、レコメンド対象の優先順が正し いか定義しにくい ● アルゴリズムの評価 ○ 確率的なモデルを採用している場合、結果が変わってしまうので、同値分割や境界値テストのような手法 が使えない。 ○ 集計ベースのモデルならそこまで問題にはならない ➡ 評価が難しい 業務システムと比べると、 結果が自明じゃない場合が あり、困ることがある ... 総合テスト ● 非機能要件に対するテスト ○ アルゴリズムによって負荷テストに対する特性が異なり、評価しにくい ■ 単純に入力データ量に対して処理時間が線形に比例しない場合がある ■ 現実的にはありえない特殊なデータ入力によって、処理コストが爆発するなど想定仕切れないこと もある
- 30. 運用・保守における違い
- 31. 変化のスパンが短い 業務システム CRM(DMP) BrainPad以前 BrainPadに入ってから 仕様変更変 わ り に く い 変 わ り や す い = 運用・保守の変更が 発生しやすい ● パッケージリリースサイクルが比較的長い ○ 安定した運用ルール、保守しやすい ● 業務、業界で採択する標準規格が存在することが 多い ○ 保守しやすい ● パッケージリリースサイクルが短い ○ 変更が発生しやすい ● デジタルマーケティングの世界では、連携方法が サービス毎に異なることが多い ○ 連携先が増えると、保守が大変 ○ Rtoasterでは、CrossOven、CrossFeedと いったサブプロダクトに分離することで、こ の問題を回避
- 32. その他 (時間調整ネタ)
- 33. とあるエンジニアが直面した壁 ことばの壁 ● データサイエンティストとエンジニアにある微妙な用語の違い ○ 入社直後、とあるシミュレーターのシステム開発プロジェクトの仕様策定の場面で、モデルと言う用語をアーキテクチャー の話だと思って聞いていたら、実は式(数理モデル)を指していて話があっているようで違うこと言っていた ● 実は数式を見るのが苦手 ○ 相談に乗ってくれるデータサイエンティストは最近、Python等のコードでサンプルをくれる コストの壁 ● Rtoasterは自社サービスで、利用料の一部でレコメンドエンジンを運用している以上、ランニングは常に意識 ○ 新しい技術を検討するときの費用感は意識 ○ リソースを節約 ■ レコメンドリストは表示する部分まで計算したら最後までしないとか、ユーザー毎の訪問頻度に応じた更新など、分 析フェーズとは違うテクニックが必要 異業種の壁 ● 元々ECサイト向けのレコメンドサービスとしてスタートしたが、現在同じECでも単品通販からモールまでバリエーションは増え、旅 行系、メディア系、金融系、人材系などの様々な業種での利用が始まり、解決したい問題が複雑化した。業務システムでは考えら れない応用力が問われた ○ 内部パラメータで業種やサイトの特性に応じたチューニングポイントを多数用意することで、表現力を増やし、問題解決能 力を強化した
- 34. まとめ
- 36. 仮説検証→設計→実装の境界が曖昧 その３ 機械システムにおける課題 ● 計画の立て方（見積の精度をどう担保するのか） ● 責任の所在（何が問題かの発見が従来より難しい） 品質の担保 ● 検証(テスト)において、ベストな方法がまだありそう ● 運用、保守における変更の強度をどう高めていくか 新技術への追従 ● 機械学習分野における進歩は早く、業務システムで使用する規格、基盤に比べて、 陳腐化が早い ○ 既存機能がリリースして終わりではなく、メンテナンス・改善の観点が必要
- 37. というわけで
- 39. ご静聴 ありがとう ございました
- 40. 株式会社ブレインパッド 〒108-0071 東京都港区白金台3-2-10 白金台ビル3F TEL：03-6721-7002 FAX：03-6721-7010 www.brainpad.co.jp info@brainpad.co.jp やぎぞう yanagihara@brainpad.co.jp Facebook : https://www.facebook.com/atsuhiro.yanagihara Qiita : https://qiita.com/yagizo こっそり告知 当社では、開発エンジニアを積極的に募集しています！ぜひ、新卒採用・キャリア採用ともに皆さまのご応募をお待ちしています！ 興味ある方はこちらから https://hrmos.co/pages/brainpad/jobs/4010401