SlideShare a Scribd company logo
1 of 75
アルゴリズム取引のシステムを
開発・運用してみて分かったこと
2017/02/17
Satoshi KOBAYASHI (satoshi-k at iij.ad.jp)
目次
• 自己紹介
• 背景
• システムの概要
• 遭遇した問題と得られた知見
• 最近の状況
• まとめ
自己紹介
誰?
• 名前: 小林 智史 (Satoshi KOBAYASHI)
• 所属: インターネットイニシアティブ (IIJ)
• 職業: ソフトウェアエンジニア
• 備考: 普段の業務は金融とは一切関わりがない
元々、投資は好き
• 普段の投資について
• 堅実枠
• 海外ETFを使った長期分散投資
• 趣味枠
• 好きな (応援したい) 企業の株を銘柄買い
ちなみに
• 年齢が若いことは投資では有利に働きやすい
• 長期間で時間分散できる
• 時間分散?→ドル・コスト平均法など
• 長期間に渡って複利が効く
• 複利?→利益がさらに利益を生む仕組み
• 損をしたときもダメージが少ない
• 何故?→人的資本が多く残されている (定年まで長い)
背景
お金儲けについての研究
• 知識と技術を使ってお金儲けができないか?
• 大学時代の研究室の先輩と二人三脚で研究
• どちらも社会人なので余暇を利用
• データを駆使して市場に打ち勝つ
• 今回作ったシステムはその一環で生まれた
大学時代の研究室の先輩
• 名前: 加川 敏規 (Toshinori KAGAWA)
• 所属: 情報通信研究機構 (NICT)
• 職業: 研究者 ※博士(工学)
• 備考: 先輩も投資が好き
システムの概要
どんなものを作ったか
• ある金融資産を全自動で取引するシステム
• 特定のアルゴリズムにもとづいて動作する
• 24 時間 365 日休まず取引し続ける
• アルゴリズムの基本
• 安く買って高く売る (商売と同じ)
• 統計の考え方を用いている
どのようにして作ったか
• Python を使ってスクラッチで実装した
• 最初ワークフローエンジンを使おうとした
• Apache Airflow とか
• 学習コストの高さ、クセの強さから断念
• その後は、ひたすら下回りから書いていった
システム構成図 (概要)
情報収集
プログラム
取引用
プログラム
レポート用
プログラム
取引所RDB
(MySQL)
トーク
(Slack)
集計用
プログラム
取引所API
ライブラリ
可視化
(Re:dash)
板の取得や注文など
何かあったときは
Slack に通知する
(自作部分)
定期実行
ユーティリ
ティ
設定管理
ユーティリ
ティ
など…RDBの内容を
グラフにする
各種データの集積所
システム構成について
• 役割ごとに細かくプロセスを分けた
• ティッカー、板などの情報を取得する役
• 得られた色々なデータを処理して発注する役
• これは正解だった
• 疎結合でデバッグしやすい
用語の補足
• ティッカー?
• 最後に成立した取引の情報
• いくらで売られたか、買われたか
• 板?
• まだ成立していない取引の一覧
• いくらで売ります、買います
サーバ
• 某 VPS 上で稼働させている
• OS: Ubuntu 16.04 LTS
• CPU: 3C
• RAM: 2GB
• DB: MySQL 5.7
遭遇した問題と得られた知見
取引はいつか必ず失敗する
…それも連続で
取引が失敗する主な原因
• 外的要因
• 取引所のメンテナンス・障害など
• 内的要因
• 自作した取引システムの障害
• 連携させている口座の残高不足など
一旦失敗すると長引くことも
• 一過性 (数分〜) のものなら特に問題はない
• Slack のログが汚れるだけ
• 長期間 (数時間〜) に渡って失敗することも
• 意外とよくある
• 人間が介入しないと直らなかったり、とか
取引が失敗するデメリット
• 機会損失
• 失敗している間はお金儲けができない
• スプレッド分の損が連続して発生しうる
• これが特にやばい
何がヤバイのか
• 複数注文の組み合わせで取引したいことがある
• 組み合わせはトランザクション的に扱いたい
• つまり All or Nothing にしたい
• もし失敗したときはロールバックさせる
• 買った所で直後に売ることになる
• あるいはその逆
何か問題が?
• 売値と買値はイコールではない
• 必ず売値 < 買値の関係になっている
• 高く買って安く売りたい人はいない
• 両者の差額をスプレッドという
• 単純に買って売るだけでも差額分を損する
失敗し続けるのはまずい
• 買って売っての繰り返し
• スプレッド分を延々と損し続ける
• それも、数時間単位で!
どう解決する?
• 単位時間あたりの失敗数に上限を設ける
• 閾値を超えて失敗すると、関連する注文を中止
• これをペナルティーと名付けた
• 復帰条件
• 一定期間が経過する
• 人間が介入して状態を解除する
取引手数料は最大の敵
前述したスプレッドに関連
• 多くの取引所では取引自体に手数料がかかる
• 一回の約定あたりでいくら、とか
• 板に最初から上乗せされていることも
• ギャンブルでいう「控除率」に相当する
• 胴元の懐に入るお金という意味で同じ
控除率の壁を超える必要あり
• 超えられないと損し続けることに
• HFT 的なことをすると特に問題になる
• HFT?→高頻度取引
• 頑張って手数料ばっかり払い続ける
どう解決する?
• なるべく手数料の少ない取引所・商品を選ぶ
• 最初、高いものを使って痛い目を見た
• アルゴリズムを改良して壁を超える
• 壁を超える利益が得られそうかを計算する
ティッカーの値段では
買えない
ティッカーは単なる過去の実績
• 開発の初期において
• ティッカーの情報を元に注文を入れていた
• 想定と異なる約定が頻発した
• 成行注文: 想定より高い・安い
• 指値注文: 買えない・売れない
得られた気づき
• ティッカーだけを見ていてはいけない
• 直近の取引で成立したというのに過ぎない
• 市場は刻一刻と変化している
• 過去の実績と今の市場は異なる
• 約定した取引量も分からない
どう解決する?
• ティッカーの代わりに板の情報を使う
• 板の情報は成立していない注文の一覧
• 今出ている注文を見て自分の注文を入れる
• いくらで売買できそうかを計算する
板の値段でなら買える!
…と思った?
想定外は減った、しかし…
• 板の情報を使っても完璧ではない
• 他の人も注文をバンバン入れている
• 板は取得した直後に過去の情報となる
• 想定外の約定は生じうる
どう解決する?
• 板を見てから注文までのディレイを減らす
• 処理の最適化・高速化
• 「想定外」の取捨選択をする
• 成行取引: 想定より高い・安いを許容する
• 指値取引: 中途半端な約定に対処する
中途半端な約定?
• 商品が売買される単位はバラバラ
• 「100 買う」という注文を指値で出したとする
• その値段で 50 だけ買えた (約定)
• 残りはいつまでたっても買えない
• 上記のような状況が起こりうる
• アルゴリズムが複雑化しがち
ちなみに高速化では…
• ボトルネックが自作システム以外にあること
も
• 取引所や途中経路が重いこともよくある
• 注文が受理されるまで数秒かかるとか
• その間クライアントがブロックする
• 別のスレッドにして他の仕事させよう…
買えなかった (´・ω・`)
…いや、実は買えていた!
取引に時間がかかるのは困る
• 注文内容が市場の相場から乖離してしまう
• 一定期間で API 呼び出しをタイムアウトする
• しかし取引所では処理が続いていることも
• 「実は買え (売れ) てた!」がたまに起こる
どう解決する?
• システムが「実は」を直後に検出する
• 検出後は失敗時のロールバックと同じ
• この「実は」の検出が意外と難しい
• または問題が顕在化した時点で対処する
• アルゴリズムによってはこれで済むことも
その他の雑多な知見
複利を活かすなら
口座情報を活用しよう
取引量
• 何をいくつ売買するか
• 口座情報を元に調整すると複利が効きやすい
• 固定量だと人間が定期的に調整する必要あり
余談
• ギャンブルで賭け金をいくらにすべきか?
• 色々な手法が考案されている
• マーチンゲール法 (倍プッシュだ…)
• ケリーの公式
※ ここらへんの話は
『ツキの法則 -「賭け方」と「勝敗」の科学』
という本を読むと面白い
貯めたデータを可視化しよう
Re:dash
• RDB のデータをグラフ化できる
• 定期的に実行してモニタリングとか
• 色んなデータの推移を見られるように
注意点
• クエリによっては RDB に負荷がかかる
• 普段から結構メモリを食う
• 以前は RAM 1GB のサーバで運用してた
• ある日 OOM Killer が発動して大惨事に
バックテストについて
バックテスト?
• 過去の履歴を使った検証
• 仮にあるアルゴリズムで運用していたら?
• 機械学習系の知識は役に立ちそう
• 教師信号への過学習で喜んでないかとか
二つのフェーズ
• 第一段階
• 上手くいくのか?
• アルゴリズム自体の検証
• 第二段階
• 利益を最大化するには?
• ハイパーパラメータの調整
しかし…
• 高精度なバックテストは意外と難しい
• 必要なデータが揃うとは限らない
• マーケットインパクトが読みづらい
• このスライドにあるような幾多の落とし穴
データが揃いづらい
• 例
• ティッカーの値段では売買できない恐れ
• 精度を上げるには板の情報もほしい
• 一般には公開されていない場合が多い
• 年単位のバックテストがしたいとき困る
マーケットインパクトの評価
• 自分たちの取引が市場に与える影響
• 注文を入れた世界と入れなかった世界
• 金額が大きくなるほど影響が増す
• アルゴリズムによってはこれを逆手に取る
セキュリティについて
考えよう
大前提
• それぞれ適切にセキュリティ対策を施す
• サーバ:ファイアウォールとか
• 取引所:二要素認証とか
仮にサーバが乗っ取られたら?
• 乗っ取られたときのことを考える
• 嫌がらせ以上のことができないようにする
• 外部に送金されたりするとまずい
• 取引所によっては API 経由でできてしまう
• 権限を適切に絞る
問題が起きたとき
気付けるようにしよう
開発の最初期
• 色んな問題が起こった
• いつの間にか止まってた
• 想定外の○○
• 気付けないと対処のしようがない
• 気付けるようにすることが大事
Slack への通知
• 何かあったときは Bot が発言する
• 取引の失敗とか例外とか何でも
• スマホのアプリがおすすめ
• 問題が起きたことに素早く気付ける
運用やデバッグで
REPL が活躍する
REPL?
• Read-eval-print loop
• 対話型評価環境
• Python には組み込みで付属している
• ちょっとしたスニペットを気軽に試せる
運用やデバッグへの応用
• 何か問題が起こったときは REPL に入る
• 取引システムの API を手動で実行できる
• デバッグに大活躍する
• これがなかったらと思うと…
スモールスタートしよう
実装の面でのスモールスタート
• 優先順位をつけて作れるところから
• データ収集は最優先、取引部分は後回し
• データさえあれば取引はシミュレートできる
• 実際にやってみると失敗も多い
• 増改築しやすいように作る
金額の面でのスモールスタート
• 最初はシミュレーションから始めた
• 実際には注文せず「もししていたら?」を分析する
• 次のフェーズとして数週間は少額の取引をやってみた
• 一取引あたり数百円規模
• 上手くいくことを確認しながら繰り返し増資
• 今ではひとつの取引で数十万円が動いている
最近の状況
Q: で、儲かってるの?
A: 割りと
どれくらい?
• 半年間の実績: 投入資金が 1.3 倍になった
• 内、金融資産の価格上昇由来: 82.7%
• 仮に全てを買って放置していても増えた分
• 内、アルゴリズム取引由来: 17.3%
• 取引することで増えた分 (こちらが重要)
ある日の取引益 (24H)
※ 上記はチャンピオンデータではなく、
この資料を作っているときに、ふと取得したもの
長期間で見ると振動しながら
上昇トレンドを続ける
ごく短期間で見ると
マイナスに振れることもある
このグラフでは、金融資産の
価格変動分を補正して除外している
とはいえ
• 一年だけ成績の良い金融商品はゴロゴロある
• 継続して良い成績を残すことが重要
• まだ本格稼働してから半年しか経っていな
い
今後も儲け続けられるか?
• おそらく!ただし…
• 全く同じ手法が通用する期間は限られるはず
• 以下のどれか、あるいは組み合わせの影響
• 市場の傾向が大きく変化する
• 壁を超えるのが困難なレベルで手数料が上がる
• マーケットインパクトが大きくなる
まとめ
• アルゴリズム取引のシステムを作ってみた
• 開発と運用を通して色々な知見が得られた
• 楽しい!
• ✌('ω'✌ )三✌('ω')✌三( ✌'ω')✌
ありがとうございました

More Related Content

What's hot

ビジネスパーソンのためのDX入門講座エッセンス版
ビジネスパーソンのためのDX入門講座エッセンス版ビジネスパーソンのためのDX入門講座エッセンス版
ビジネスパーソンのためのDX入門講座エッセンス版Tokoroten Nakayama
 
よくわかるHopscotch hashing
よくわかるHopscotch hashingよくわかるHopscotch hashing
よくわかるHopscotch hashingKumazaki Hiroki
 
事業の進展とデータマネジメント体制の進歩(+プレトタイプの話)
事業の進展とデータマネジメント体制の進歩(+プレトタイプの話)事業の進展とデータマネジメント体制の進歩(+プレトタイプの話)
事業の進展とデータマネジメント体制の進歩(+プレトタイプの話)Tokoroten Nakayama
 
トランザクションの設計と進化
トランザクションの設計と進化トランザクションの設計と進化
トランザクションの設計と進化Kumazaki Hiroki
 
研究分野をサーベイする
研究分野をサーベイする研究分野をサーベイする
研究分野をサーベイするTakayuki Itoh
 
そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?takezoe
 
統計的係り受け解析入門
統計的係り受け解析入門統計的係り受け解析入門
統計的係り受け解析入門Yuya Unno
 
C#とILとネイティブと
C#とILとネイティブとC#とILとネイティブと
C#とILとネイティブと信之 岩永
 
解説!30分で分かるLEAN ANALYTICS
解説!30分で分かるLEAN ANALYTICS解説!30分で分かるLEAN ANALYTICS
解説!30分で分かるLEAN ANALYTICSしくみ製作所
 
データサイエンティスト養成読本の解説+書き忘れたこと
データサイエンティスト養成読本の解説+書き忘れたことデータサイエンティスト養成読本の解説+書き忘れたこと
データサイエンティスト養成読本の解説+書き忘れたことTokoroten Nakayama
 
マッチングサービスにおけるKPIの話
マッチングサービスにおけるKPIの話マッチングサービスにおけるKPIの話
マッチングサービスにおけるKPIの話cyberagent
 
君にグロースハックはいらない
君にグロースハックはいらない君にグロースハックはいらない
君にグロースハックはいらないTakaaki Umada
 
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?Yoshitaka Kawashima
 
ドキュメンテーションを加速するストレスフリーの作図ツール『blockdiag』 jus2011年6月勉強会
ドキュメンテーションを加速するストレスフリーの作図ツール『blockdiag』 jus2011年6月勉強会ドキュメンテーションを加速するストレスフリーの作図ツール『blockdiag』 jus2011年6月勉強会
ドキュメンテーションを加速するストレスフリーの作図ツール『blockdiag』 jus2011年6月勉強会Takayuki Shimizukawa
 
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLiveDXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLiveTokoroten Nakayama
 
正しいものを正しくつくる
正しいものを正しくつくる正しいものを正しくつくる
正しいものを正しくつくるtoshihiro ichitani
 
リアクティブシステムとAkka
リアクティブシステムとAkkaリアクティブシステムとAkka
リアクティブシステムとAkkaTIS Inc.
 
トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2Takashi Hoshino
 
【CEDEC2018】一歩先のUnityでのパフォーマンス/メモリ計測、デバッグ術
【CEDEC2018】一歩先のUnityでのパフォーマンス/メモリ計測、デバッグ術【CEDEC2018】一歩先のUnityでのパフォーマンス/メモリ計測、デバッグ術
【CEDEC2018】一歩先のUnityでのパフォーマンス/メモリ計測、デバッグ術Unity Technologies Japan K.K.
 

What's hot (20)

ビジネスパーソンのためのDX入門講座エッセンス版
ビジネスパーソンのためのDX入門講座エッセンス版ビジネスパーソンのためのDX入門講座エッセンス版
ビジネスパーソンのためのDX入門講座エッセンス版
 
よくわかるHopscotch hashing
よくわかるHopscotch hashingよくわかるHopscotch hashing
よくわかるHopscotch hashing
 
事業の進展とデータマネジメント体制の進歩(+プレトタイプの話)
事業の進展とデータマネジメント体制の進歩(+プレトタイプの話)事業の進展とデータマネジメント体制の進歩(+プレトタイプの話)
事業の進展とデータマネジメント体制の進歩(+プレトタイプの話)
 
トランザクションの設計と進化
トランザクションの設計と進化トランザクションの設計と進化
トランザクションの設計と進化
 
研究分野をサーベイする
研究分野をサーベイする研究分野をサーベイする
研究分野をサーベイする
 
そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?
 
統計的係り受け解析入門
統計的係り受け解析入門統計的係り受け解析入門
統計的係り受け解析入門
 
C#とILとネイティブと
C#とILとネイティブとC#とILとネイティブと
C#とILとネイティブと
 
解説!30分で分かるLEAN ANALYTICS
解説!30分で分かるLEAN ANALYTICS解説!30分で分かるLEAN ANALYTICS
解説!30分で分かるLEAN ANALYTICS
 
データサイエンティスト養成読本の解説+書き忘れたこと
データサイエンティスト養成読本の解説+書き忘れたことデータサイエンティスト養成読本の解説+書き忘れたこと
データサイエンティスト養成読本の解説+書き忘れたこと
 
マッチングサービスにおけるKPIの話
マッチングサービスにおけるKPIの話マッチングサービスにおけるKPIの話
マッチングサービスにおけるKPIの話
 
君にグロースハックはいらない
君にグロースハックはいらない君にグロースハックはいらない
君にグロースハックはいらない
 
Paxos
PaxosPaxos
Paxos
 
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
 
ドキュメンテーションを加速するストレスフリーの作図ツール『blockdiag』 jus2011年6月勉強会
ドキュメンテーションを加速するストレスフリーの作図ツール『blockdiag』 jus2011年6月勉強会ドキュメンテーションを加速するストレスフリーの作図ツール『blockdiag』 jus2011年6月勉強会
ドキュメンテーションを加速するストレスフリーの作図ツール『blockdiag』 jus2011年6月勉強会
 
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLiveDXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
 
正しいものを正しくつくる
正しいものを正しくつくる正しいものを正しくつくる
正しいものを正しくつくる
 
リアクティブシステムとAkka
リアクティブシステムとAkkaリアクティブシステムとAkka
リアクティブシステムとAkka
 
トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2
 
【CEDEC2018】一歩先のUnityでのパフォーマンス/メモリ計測、デバッグ術
【CEDEC2018】一歩先のUnityでのパフォーマンス/メモリ計測、デバッグ術【CEDEC2018】一歩先のUnityでのパフォーマンス/メモリ計測、デバッグ術
【CEDEC2018】一歩先のUnityでのパフォーマンス/メモリ計測、デバッグ術
 

Viewers also liked

OpenFlow OAM ツール - OKINAWA Open Days 2014 Day1
OpenFlow OAM ツール - OKINAWA Open Days 2014 Day1OpenFlow OAM ツール - OKINAWA Open Days 2014 Day1
OpenFlow OAM ツール - OKINAWA Open Days 2014 Day1Satoshi KOBAYASHI
 
アラート対応自動化を組み込んでみた
アラート対応自動化を組み込んでみたアラート対応自動化を組み込んでみた
アラート対応自動化を組み込んでみたIIJ
 
年間1,000万件のアラートを自動処理してみた
年間1,000万件のアラートを自動処理してみた年間1,000万件のアラートを自動処理してみた
年間1,000万件のアラートを自動処理してみたIIJ
 
事業成長にコミットするエンジニア組織への道のり
事業成長にコミットするエンジニア組織への道のり事業成長にコミットするエンジニア組織への道のり
事業成長にコミットするエンジニア組織への道のりRecruit Lifestyle Co., Ltd.
 
Pythonによる機械学習入門 ~Deep Learningに挑戦~
Pythonによる機械学習入門 ~Deep Learningに挑戦~Pythonによる機械学習入門 ~Deep Learningに挑戦~
Pythonによる機械学習入門 ~Deep Learningに挑戦~Yasutomo Kawanishi
 

Viewers also liked (6)

OpenFlow OAM ツール - OKINAWA Open Days 2014 Day1
OpenFlow OAM ツール - OKINAWA Open Days 2014 Day1OpenFlow OAM ツール - OKINAWA Open Days 2014 Day1
OpenFlow OAM ツール - OKINAWA Open Days 2014 Day1
 
アラート対応自動化を組み込んでみた
アラート対応自動化を組み込んでみたアラート対応自動化を組み込んでみた
アラート対応自動化を組み込んでみた
 
年間1,000万件のアラートを自動処理してみた
年間1,000万件のアラートを自動処理してみた年間1,000万件のアラートを自動処理してみた
年間1,000万件のアラートを自動処理してみた
 
20130426 慶応大学での講義
20130426 慶応大学での講義20130426 慶応大学での講義
20130426 慶応大学での講義
 
事業成長にコミットするエンジニア組織への道のり
事業成長にコミットするエンジニア組織への道のり事業成長にコミットするエンジニア組織への道のり
事業成長にコミットするエンジニア組織への道のり
 
Pythonによる機械学習入門 ~Deep Learningに挑戦~
Pythonによる機械学習入門 ~Deep Learningに挑戦~Pythonによる機械学習入門 ~Deep Learningに挑戦~
Pythonによる機械学習入門 ~Deep Learningに挑戦~
 

Similar to アルゴリズム取引のシステムを開発・運用してみて分かったこと

【営業企画】イチから始める営業戦略
【営業企画】イチから始める営業戦略【営業企画】イチから始める営業戦略
【営業企画】イチから始める営業戦略sasy777
 
【営業企画】イチから始める営業戦略
【営業企画】イチから始める営業戦略【営業企画】イチから始める営業戦略
【営業企画】イチから始める営業戦略sasy777
 
【営業企画】イチから始める営業戦略
【営業企画】イチから始める営業戦略【営業企画】イチから始める営業戦略
【営業企画】イチから始める営業戦略sasy777
 
ビジネスモデル・ジェネレーション読書会資料
ビジネスモデル・ジェネレーション読書会資料ビジネスモデル・ジェネレーション読書会資料
ビジネスモデル・ジェネレーション読書会資料Mari Takahashi
 
フラッシュボーイズ:読感
フラッシュボーイズ:読感フラッシュボーイズ:読感
フラッシュボーイズ:読感Ginpei Kobayashi
 
職務発明制度の主要な論点と判断基準
職務発明制度の主要な論点と判断基準職務発明制度の主要な論点と判断基準
職務発明制度の主要な論点と判断基準Genichi Kataoka
 

Similar to アルゴリズム取引のシステムを開発・運用してみて分かったこと (7)

【営業企画】イチから始める営業戦略
【営業企画】イチから始める営業戦略【営業企画】イチから始める営業戦略
【営業企画】イチから始める営業戦略
 
【営業企画】イチから始める営業戦略
【営業企画】イチから始める営業戦略【営業企画】イチから始める営業戦略
【営業企画】イチから始める営業戦略
 
【営業企画】イチから始める営業戦略
【営業企画】イチから始める営業戦略【営業企画】イチから始める営業戦略
【営業企画】イチから始める営業戦略
 
ビジネスモデル・ジェネレーション読書会資料
ビジネスモデル・ジェネレーション読書会資料ビジネスモデル・ジェネレーション読書会資料
ビジネスモデル・ジェネレーション読書会資料
 
フラッシュボーイズ:読感
フラッシュボーイズ:読感フラッシュボーイズ:読感
フラッシュボーイズ:読感
 
JaSST'18 総括
JaSST'18 総括JaSST'18 総括
JaSST'18 総括
 
職務発明制度の主要な論点と判断基準
職務発明制度の主要な論点と判断基準職務発明制度の主要な論点と判断基準
職務発明制度の主要な論点と判断基準
 

アルゴリズム取引のシステムを開発・運用してみて分かったこと