【開発録】作らない判断をどう設計するか。MT4ツール40案のうち7案を中止した、実装前評価の4基準
FX
1.本稿の目的と前提
Semura Lab.では、MT4向けの環境可視化ツールを、当初27案、追加13案の計40案で計画した。現時点の内訳は、完成29、中止7、保留4である。
本稿は、このうち中止した7案を題材に、「作らない」と判断した根拠を整理する。EAやツールの開発に共通する、実装前評価の考え方としても読める内容にしたい。
2.中止した7案の記録
7案の名称と、中止の理由は次の表のとおりである。
理由は一見ばらばらだが、整理すると4種類に分かれる。取得できないデータを近似で埋めようとしたもの、導入前の手間が重いもの、完成しても使う場面が見えないもの、入力値から計算するだけの汎用型である。次章で順に検討する。
3.中止理由の分析
3-1. 取得できないデータを、近似で埋める設計(18番)
18番「実弾スリッページ結線インジケーター」は、発注価格と約定価格のズレをチャート上に線で結ぶ構想だった。しかしMQL4には、発注した瞬間のリクエスト価格を後から取得する手段がない。約定価格は残るが、比較の基準となる側が残らない。
代替として、発注時刻の1分足の始値を使う近似案を検討した。だがこの場合、描画されるのはスリッページそのものではなく、別の価格との差である。スリッページを可視化するツールが、スリッページを近似で置き換える。測定の目的と手段が食い違うため、中止とした。
測定対象そのものを近似で代用すると、数値の意味を利用者に説明できなくなる。ここが、この案の核心的な問題である。
3-2. 導入と環境のコスト(16番、26番)
16番「肥大化ログファイル・アラート」は、MQL4のファイルアクセスの制約から、ログフォルダへ確実に到達できない。確実に届かない場所を監視するツールは、成立しない。制約を迂回する実装に手間をかけても、割に合わないと判断した。
26番「Pingジッター監視メーター」は、MQL4単体では本物のネットワークPingを取得できない。DLLを使わない方針のもと、WebRequest()による擬似的な測定を検討した。ただし、利用者がMT4側で接続先URLを許可リストへ登録する必要がある。
ここで重視したのは、作り手が負担に感じる手順は、利用者にとっても負担になるという点である。ツールの価値より、利用開始前の作業が重くなる設計は、採用しなかった。
3-3. 意思決定に寄与しない(22番)
22番「サーバー時間&ローソク足カウントダウン」は、サーバー時刻と、次の足が確定するまでの残り時間を表示する。実装とコンパイル確認までを完了した後に、「何の役に立つのか」を改めて確認した。
想定された用途は、足の確定を待ってエントリーする際のフライング防止と、サーバー時間とPC時間のズレへの対策である。説明は妥当だった。しかし、その数字を見て利用者が何を判断するのかを、具体的に描けなかった。実装済みの状態で、中止とした。
3-4. 汎用計算型と、実データ集計型(B2〜B4とB1)
追加案のB2(加重平均建値)、B3(連敗シミュレーター)、B4(リスク%ベースのロット計算)は、入力値から答えを計算するタイプである。B4は実装前に却下し、B2とB3も不採用とした。入力された数値を計算するだけの機能は、独自のツールとして提供する理由が見つからなかった。
対照的に、同じ追加案のB1(通貨エクスポージャー重複チェッカー)は採用し、完成している。こちらは、保有ポジションの実データを集計して、同一通貨への偏りを示す。口座内の実データを使うか、外から数字を入力してもらうか。これが、採用と不採用を分けた。
4.実装前評価の4つの基準
以上の事例から、実装前に確認すべき問いを4つに整理する。
(1) 測りたいものを、そのまま取得できるか。取得できない場合、近似で測定の目的を満たせるか。
(2) 利用者に、事前の設定や環境変更を求めていないか。
(3) その数字を見て、利用者は何を判断するのか。
(4) 口座や端末の実データを使っているか。外部の計算機で代替できないか。
(1)は18番、(2)は16番と26番、(3)は22番、(4)はB2〜B4とB1の対比から導いた。いずれも、コードを書き始める前に答えられる問いである。
使い方としては、4つのうち答えに詰まる項目を、先に洗い出すことが考えられる。(1)で近似にしか届かないなら、近似でも目的を満たす用途に絞れるかを検討する。(2)で利用者の操作が必要なら、その操作が許容される範囲かを、実装の前に決める。(3)と(4)で詰まる場合は、そもそも独自のツールとして出す理由があるのかを問い直す。
5.実装後に止める判断について
22番は、実装まで済ませた後に中止した。投下した工数を考えれば惜しいが、利用者が使う場面を描けないツールを公開することは、商品としての信頼を損なう。
ただし、(3)の問いは、実装前に確認できたはずである。「何を判断するための数字か」を、企画の段階で言語化できるかどうか。この点を、評価の工程に組み込む価値は大きい。
6.EA検証への含意
18番の「1分足の始値で代用する」という近似は、EAのバックテストが抱える構造と重なる。バックテストも、理想的な環境を、補間によって近似して作っている。
近似が許される問題と、許されない問題がある。測定の中心にある数値を近似で置き換えると、結果の意味が変わる。ラボが掲げる「4つの設計上の欠陥」のうち、④テスト環境とリアルの乖離は、まさにこの構造を指している。ツールの開発と、EAの検証は、根は同じ問いに行き着く。
7.結論
我々Semura Lab.は、40案のうち29案を完成させた。同時に、7案を作らないと決めた。作らなかったものの理由を記録することは、残ったものの設計基準を明確にする作業でもある。
近似で代用しない。利用者に事前の負担を求めない。数字の先にある判断を描ける。口座の実データに基づく。この4点を満たすものだけを、ラボは出す。
EAやツールの設計判断、検証に関するご相談は、よろず相談所までどうぞ。