[Puppeteer] mm botを作ろう、、と思って挫折しているあなたへ (01:要求はまとまらない)
要求はまとまらない
前回のまとめ的な部分に「要求をまとめよう」って書いておいて、今回のタイトルを見て「言ってることが違うだろ！」って怒った方もいるのではないでしょうか。
別に炎上商法にするつもりはないのですが、実は「要求をまとめる」も合っていて、「要求はまとまらない」も合っています。
かつて日本のソフトウェア企業がメインフレームで活躍していたころのソフトウェア開発手法の主流は
ウォーターフォールモデル
という開発手法でした。
水が上流から下流に流れ落ちるように要求→要件→仕様→設計・・・というように段階を経て開発を進めていく手法です。
開発に数年という時間を費やすことが可能であり、最初にばっちり要求を確定させることが出来る、もしくは要求に変更があっても全体へのインパクトが軽微であるような開発の場合に非常に威力を発揮する開発手法です。
しかし、昨今のように顧客や市場の要求の変化が目まぐるしい時代では、この「最初に要求をばっちり決めて」おいたとしても、数ヶ月もすると状況は変化して、新しい要求を取り入れたり、大幅に変更する必要が生じます。
開発プロセスの良い悪いという問題ではなく、今のような変化の激しい環境に対応できないで作成されたソフトウェアは出荷時点で過去の遺物になってしまいます。
そのため、ソフトウェア開発手法も色々と試行錯誤を繰り返し、現在では
アジャイル
的な手法が主流です。
（アジャイル”的”といった理由はまた別の機会に）
ですが、間違えないで欲しいのは「ウォーターフォールモデル」が使えなくなった訳ではありません。
要求の追加や変更がコントロール可能な開発ではまだまだウォーターフォールモデルは有効です。
アジャイル的な開発手法には色々あるので、詳細はその専門書を当たってもらうとして、もう少し話を進めていきましょう
仮想通貨bot開発の世界も日進月歩
私が仮想通貨の存在を知ったのは不覚にも2018年の年始を過ぎたときでした。
そうです。2017年末まで暴騰していたBTCが一気に下落し始めた頃です。
まだ黎明期の仮想通貨は世間の注目を浴びていたので、私も名称くらいは知っていました（色々事件もありましたからね）。
しかし当時の私は仮想通貨を「電子マネーの親戚か？」くらいに考えていました。そんな私は息子に勧められて初めて仮想通貨なるものの実態を知ることになります。
息子曰く
仮想通貨っていうものが世間を賑わわせているけど、稼いでいる人は「ぼっと」というものを使って稼いでいるらしい。
俺も仮想通貨をやっているんだけど、親父はソフトウェア・エンジニアだよな。今度「ぼっと」を作ってくれないか？
って言われたのが事の始まり。
discordやnoteについて教えてくれたのも息子でした。
息子の奴いつの間にこんなものを、と内心びっくりしました。
あれから月日が経ち、私もbot製作を始めてから約一年半ほど経ちます。
仮想通貨bot開発を開始してから、いくつかのdiscordグループに参加させてもらい、noteの執筆もなんとか継続でき、自分なりのbotを数個作成できた頃、discordでお世話になっている方たちから以下のような話を聞くことが多くなりました。
noteや他のサイトで仮想通貨自動売買のためのbotを買ったんだけど、うまく動かせないんだ。製作者は売り切りだって言ってるから製作者に質問できないし、かと言って、俺じゃあbotの改造も難しいしなぁ
とか、
数万するbotを買ったんだけど、全然勝てない。っていうか負けすぎ。
もう止めるしか無いか。ロジックが悪いのか、環境が悪いのか、俺にはわからん。。
などなど。
知り合い（あくまでdiscord上での）の中には販売されているbotを次々と購入しては「また駄目だった」と悲壮感たっぷりな方も居ました。
そんな方々の多くは裁量ではそれなりの実績を有し、私のような「ただのソフトウェア・エンジニア」ではなく、トレーダーと言っても良いような方々が多かったように思います。
何がいけないのか？
botを運用して勝てない理由は一つではないと思いますが、思いつく原因を一つ上げるとすると
・瞬間的に利益を出したbotを前提条件に関係無く運用している
ではないでしょうか。
当然ですが、どんな環境・条件でも勝ち続けるbotは存在しません。
そんなものが作れたら取引所は潰れるでしょうし、そもそも勝ち続けるbotを開発した人がそれを公開するはずがないのです。
（”絶対に儲かります”という謳い文句の商品に騙される人は居ないでしょう）
なので、そのbotが「詐欺」のようなbotでない場合でも
・勝てる前提条件がある
のと同様に
・負ける前提条件もある
と思って運用しなくてはなりません。
以前一大ブームになった「ドテン君」と呼ばれるbotを購入した人から、ドテン君のソースコード行数を教えてもらったときに絶句した覚えがあります。
特に、売買タイミングを判定する部分のロジックの行数は本当に少ないとのこと。
ある意味、たったそれだけのソースコード行数で判定可能な優秀なロジックを考えついた人は天才だなと思う反面、使い方を誤るととんでもない事になるだろうと簡単に予想は付きました。
ソースコード行数が少ないことは悪いことではありません。
実際に動作する少ないコードこそ優秀だと私は考えています。
機能を絞って、ターゲットを固定したからこそ、「ここぞ！」というときに威力を発揮するのでしょう。
購入者の方は「トレンド相場だと威力を発揮するんだけど、ヨコヨコ（レンジ）だとボロ負けなんだよなぁー」って言ってました。
ドテンくんのメインロジック（思想）は次のチャネルブレイクアウト戦略に基づいたものだと言われています。
これを読めば「レンジ相場で無闇に勝負しちゃ駄目だよな」と予想はつくと思います。
トレンド相場で稼いだ資金をレンジ相場でジリジリと失っていくことでしょう。
最初からすべてに対応することの難しさ
ドテン君の「得意な相場」を見つけてあげるのは、実はまだ人間の役目だったわけで、ドテン君が自分で得意な相場を探し出して勝負してはくれません。
そこを理解して運用しなくてはならないのです。
（私が運用したbot「ヘカトンケイル」は、実はトレンド相場を”諦めたbot”です）
では、最初からトレンド相場とレンジ相場の両方に通用するように
全部の機能(トレンド相場用、レンジ相場用)をてんこ盛りにしたbotを開発すればいいじゃないか？
と思われるかもしれません。
不可能だとは言いませんが、すべてのケースに対応するbotを作成するのは至難の業だと言わざるを得ません。
要求の多さに比例して要件、仕様、設計の難易度は増し、実装されるソースコードの量は増えます。
（ソースコードの量がリニアに増えるとは限りませんが、多くの場合減ることはないです）
そしてbotを試験して評価する時間も膨大になります。
そして時間が経てば経つほど仮想通貨界隈の環境も変わり、取引所の仕様変更や市場で競合するbotの台頭への対応も必要になってきます。
で、さらに要求を変更・追加していく、、イタチごっこになりますね。
いつまで経っても完成しないbotになってしまいます。
さっと作って、さっさと稼ぐ
のも戦略の内だと思います。
YAGNIの法則
ソフトウェア開発には、次のような法則（経験則？）があります
YAGNIの法則
です。
Wikipediaを見ると
「"You ain't gonna need it"、縮めて YAGNI とは、機能は実際に必要となるまでは追加しないのがよいとする、エクストリーム・プログラミングにおける原則である。」（Wikipediaより）
とあります。
つまり、「あれにも対応できるようにしておこう」「こんな状況にも対応できるようにしておこう」と機能をどんどん実装していっても、それらが実践で利用されることはなく、実装や試験のために無駄な時間を消費してしまう、という法則です。
要は
シンプル・イズ・ベスト
ということですね。
必要な機能は必要になったときに実装すれば良い、ということです。
要求をまとめる（思考実験）
ここまで述べたことをまとめてみましょう。
半ば強引ですが、今回は
mm botを作る
というタイトルに沿わせた結果ですので、着眼点（発想、企画）が異なれば違ったストーリーになりますからね。
１．最初から全方位的な目標は持たせない。
ターゲットを絞り、まずは単機能で狙ったところを狙い撃ちする。
ターゲットを絞り込むことで、要求を実現していく順序をはっきりさせます。
２．botに要求することを書き出す。
可能な限り箇条書きで書き出しましょう。
物語にはしないで良いです。
制約条件（前提条件）があるなら、それも書き出します。
要求は「・・・したい」であり、制約条件は「・・・でなければならない」です。
３．将来拡張用の構想まで実装しない。
必要になったら機能を追加していく。（ただし、最初の実装がお粗末だと、機能追加もままなりません）
実装はしないだけで、着想は将来のために取っておきましょう。別のひらめきの素になるかもしれません。
以上を踏まえて、botに「要求すること」を書き出してみましょう。
まず、最大の目的は「利益を上げる」ことであり、
そのためには
・勝つ（攻め）
・負けない（守る）
が必要ですね。
「勝つ（攻め）」については
スプレッド差益をさくさく（高速）と得たい
高速の定義：10秒以内の周期 ＝ いわゆるスキャルピング
としてみましょう。
「負けない（守る）」については
ナンピン買い・売りは必要最低限にしたい
参入価格と最新価格の差が大きくなりすぎたら損切りしたい
ポジションを必要以上に保持することはしたくない
としてみましょう。
めちゃ簡単ですが、上記をまとめるとユーザ要求としては
①スイングでも、デイトレでもない、スキャルピングをしたい（スピード感）
②スプレッド差益を狙いたい（狙い目＝マーケットメイク戦略）
③ナンピン買い・売りは出来るだけしたくない（ブレーキ）
④参入価格と最終価格が大きく乖離したら損切りしたい（脱出）
⑤ポジションを必要以上に保持しないようにしたい（しきい値）
というところで「一旦」はまとめましょう。
（今回は思考実験的にお話しているので、本来はもっと要求を分析して、まとめ上げる過程があります）
実際には後から必ずと言っていいほど追加の要求が発生したり、要求の変更が発生します。
でも、それはそれで受け止めなくてはなりません。
とにかく今は俊敏（アジャイル）に動くことにします。
ユーザの「・・・したい」から、システムの「・・・できる」へ
要求はまだ「ユーザ視点に立った」表現です。
そのままをプログラムに実装するにはまだまだギャップがあります。
そのために、システムサイドに立った表現に変換します。
その過程で我々の視点が「ユーザ境界」から「システム境界」の側に移ります。
要求を要件に変換する過程についてはまた次の回にてお話しましょう。
いいなと思ったら応援しよう！
