業務に使えるかもしれない、ゆるコントロール実験

# はじめに
これは実験計画を立てる上で、基本的な知識である(はずの)コントロール実験の知識・考え方をゆるく仕入れてなんとなく開発業務に適用できそうな気になるための記事。

※もう科学実験とかしなくなって幾年たつので雰囲気で書いています。

誤った点をご指摘いただくことは大いに歓迎しております。
しかし、うっかり「対照実験」とか「コントロール + 実験」とかググってここへたどり着いてしまった学生諸子は回れ右してもっと高尚な情報を求めた方が身のため、あなたのためです。

****

## 業務で実験？
業務で実験と言われてもピンとこないかもしれません。
ですが我々は日々の業務を行う中でかしこまって **”実験”** などと表現をしないだけで様々な検証を行っているものと思います。

技術検証、不具合調査、成果物のチェックなど。

これもいわば一種の実験と言えるでしょう。
仮説があり、その検証のためにデータを取り、結果を観測し、解釈する。

我々は日ごろから多くの実験をしています。

****

## 実験計画
実験は何よりその計画が重要です。
誤った手順を如何に正確にこなしても徒労に終わります。
そして計画なき実験はしばしば手順を誤ります。

それでは仮説の証明に必要なデータをいつまでも得られず仕事が進まないどころか、不十分なデータから誤った結論を導き出してしまうかもしれません。

さらに言ってしまうと、どれだけ良い結果を報告されても実験デザインがお粗末なら他人はそれを半信半疑でしか受け取れません。

「ま…まあ あんたほどの実力者がそういうのなら………」なんて言っていては痛い目にあいます。

(今回の主題ではないですが、少ない作業で多くの有益なデータを採取するためにも実験計画は重要です。)

****

# コントロール実験(対照実験)
> 対照実験（たいしょうじっけん、英: control experiment）とは、科学研究において、結果を検証するための比較対象を設定した実験。コントロール実験とも呼ばれる。条件の差による結果の差から、実験区の結果を推し量る基準となり、実験の基礎となる。1つの条件のみ変更し他条件は一致させるようにする。
(https://ja.wikipedia.org/wiki/対照実験)

コントロール実験を行う上での基本は
- 変化させる条件は1つにする
- コントロールを置いて比較する

以上2点であると思います。

****

## 変化させる条件は1つにする

実験を行う際には、効果を調べたい特定の1条件のみを変化させるのが基本です。

幾つもの要因を一気に変化させてしまっては、せっかく求めていた現象を観測出来てもなぜそれが起こったのか証明できなくなってしまい、実験の意義が失われてしまいます。

複数の条件を一気に変化させてしまうとどうなってしまうか、例で見てみましょう。

****

### 例1
|ある暑い夏の日、A君は小腹がすいたので冷蔵庫からチョコレートを取り出し、包み紙をはがしました。<br>しかし、ここで急ぎの用事を思い出し、このチョコを日の当たる窓辺に放置してしまいました。<br>15分後、A君は戻ってきましたが、その時にはチョコは溶けてしまっていました。
|:-|

![melt_choco.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/315470/7756f1d8-a759-14ca-e725-e416d7fa451a.jpeg)

この時、なぜチョコが溶けてしまったと言えるでしょうか。
もちろん、我々は熱でチョコが溶けてしまうことを知っていますが、一度忘れてこの文から分かることだけを考えましょう。

****

恐らく断言できるのはせいぜい
**高温化で、外気に晒し、光を当て続けると溶けてしまった。**
といったところでしょう。

この例ではいくつもの条件を一気に変化させてしまったので、チョコを溶かす外的要因がその内のどれなのかを断言できなくなってしまいました。

我々が承知している、熱で溶けるという現象を**仮説**として、それを**証明**するデータを得るには
冷蔵庫から取り出したチョコの包みをはがさず、暗所に静置することでやっと熱で溶けると言えるデータになります。

****

### 例2
|画像投稿 Web サービスを作り上げたあなた。<br>早速動作テストを行おうと、自分のスマートフォンから画像を投稿したところ、正常に動作しました。<br><br>あなたのスマートフォンは Android OS であったため、iOS のデータも欲しくなったあなたは iPhone を持っている隣の席の同僚にテストをお願いしました。<br><br>同僚は快く協力を受け入れ、試しに iPhone のカメラロールの一番上の画像をアップロードしてみたところエラーを起こしてしまいました。<br><br>なのであなたは、iOS では動作しない不具合を抱えていると結論付けました。
|:-|

****

この時、iOS ではエラーが起こるなどと結論付けるのは誤りです。

同僚は、自身の端末にたまたま入っていた画像を利用したため、この画像がエラーの原因かもしれません。
ブラウザの指定も無いため、あなたは chrome、同僚は safari を使ってテストをしているかもしれません。

(厳密には OS が違うと同名のブラウザでも動作が違ったりしますが、)同じ画像を同じブラウザで、それぞれの端末からあげることで初めて妥当なテストと言えるでしょう。

<br><br>

まぁ、特定の日時に動かすとバグるという例もあるのでできれば時間も同じ方が良かったり、条件は挙げだすとキリがありあませんが、そこは実験コストと得られると予測される結果を考えて妥協できるラインを設定するのも実験計画です。

****

## コントロールを置く
さて、目的の事象ばかりを追い求めると他の要因を見落として不十分な条件設定を行ってしまうことを見てきました。

では、適切に1条件のみを変化させる実験計画を立てられたらそれでよいでしょうか？

実はこれでもまだ目的に意識が向き、証明に必要な情報が足りていない場合があります。

そこでコントロールと呼ばれる比較に使うための結果の予測できる実験条件を置きます。

****

### ネガティブコントロール
コントロール(対照)の内、基本的に何も手を加えない、結果の出ないと予測できるものをネガティブコントロール(陰性対照)と呼びます。

ここからも不足すればどうなるのか例でみてみましょう

****

#### 例1

|大腸菌の培養条件についての実験<br><br>大腸菌を培養するときに A~C の試薬、どれが一番増殖を促進するかを実験する。<br>大腸菌の増殖具合は、プラスミドへ蛍光タンパク質をコードしている DNA を導入した大腸菌を培養対象とし、培養後にこの蛍光を測定して評価する計画。<br>試薬を加える以外、(温度、時間等)はすべて同一の条件とする。<br><br>実験の結果、試薬 C を加えた培地が最も強い蛍光を発した。<br><br>なので、試薬 C が最も大腸菌の増殖を促進すると判断して、今後の培養には試薬 C を使うことにした。 
|:-|

![3.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/315470/2300ad5f-f47e-2118-79b7-38246ecba4aa.jpeg)

****

さて、この実験はちゃんと加える試薬のみを変化させる条件にして、先ほどの基本が守られています。
ですが、ネガティブコントロールを置かなかった結果、結論が間違っている**可能性があります。**

この場合のネガティブコントロールは**試薬を加えない**での培養です。
質量が変わってしまうので、試薬と同量の水を加えておくのが普通でしょうか。

この結果、水を加えた培地が
- C と同じ程度の蛍光を発した → A, B は増殖を抑制していただけで、C にも効果は無い。
- C よりも結果が出た → どの試薬も増殖の邪魔。加えない方がいい。

という結果になります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/315470/5a4d401f-88bf-6466-da50-0f1f01aadeec.png)

****

#### 例2

|システム内のとある処理がとても遅く、5分もかかっている。<br>本番環境に手を加える訳にはいかなので、テスト環境を立てて2つの代替手段を試してみた。1つは3分、もう1つは2分で処理を終えた。<br>なので、より性能の良い後者の実装を採用することにした。
|:-|

この場合のネガティブコントロールは、元々の実装と言えるでしょう。
ポイントは、元の実装と同じ環境で新しい実装は一度も検証されていないことです。

****

テスト環境を起こすときに何らかのインフラ構成が変わった。
他のメンバーの改修で関連ライブラリが更新されて単純に問題の処理のパフォーマンスが改善された。
など、速度が改善された理由はいろいろ考えられてしまいます。

このように、ネガティブコントロールを用意しなければ実験結果を正しく比較できず、実験系自体が崩壊します。
誤って効果を判断してしまわないように、比較対象としてデータを取る必要があるわけですね。

****

### ポジティブコントロール
コントロール(対照)の内、結果が必ず出ると予測できるものをポジティブコントロール(陽性対照)と呼びます。
まぁ、そもそも条件を探る探査的な実験の場合は設定できないこともあるでしょう。

****

#### 例1
|safari 環境だと正常に動作しないシステムをあなたは抱えている。<br><br>このシステムの改修案を思いついたあなたは、それを実装してもう一度 safari でシステムを動かしてみた。<br>しかし、残念ながら今回もうまく動作しなかった。<br><br>なので、この改修案は見当違いであったと結論を下した。
|:-|

この判断はやはり間違っている可能性があります。

****

この場合のポジティブコントロールは safari 以外の、元からうまく動いている chrome 等の環境での動作確認でしょう。

もし chrome でも動作しなかった場合、
- 改修中に全体の実装そのものを崩壊させていてそもそもまともに動いていなかった
- 検証手順に誤りがあり、意図せずシステムが想定していない操作を行って、別種のバグを引いていた
など動作不良の原因は改修内容以外にいくらでも思いつきます。

ネガティブコントロールが誤って有効であると判断してしまわないためのものなら、
ポジティブコントロールは実験系や実験操作の誤りで、誤って効果が無いと断じてしまわないために取るものと言えるでしょう。

また、実験の目的が**効果があること**ではなく**効果が無いこと**を調べるものの場合、役割は逆になり得ます。


# さいごに
目的の条件に絞り、対照を取って比較をすることで初めて意味を持つ実験結果は多くあります。

どうしても調べたいことがあるとそれだけに専心してしまうものです。

そのせいで他の条件を見落としたり、無視したりしてしまいます。
比較もせず1つの結果だけを見て結論を急いたりします。

実験に取り掛かる前に一度目的を考え、それを証明するには何を調べなければならないか、何と比較しなければならないかをよく考えて計画を立ててから実験に臨むことが大事でしょう。

****

# 余談

それと、余談ですが不都合なデータでもしっかりと記録しましょう。
大事なのは確かな計画と確かなデータです。
これさえあれば仮説の証明に失敗してもその実験には価値があります。

悪意を持ってデータを捨てる人はいないと信じたいですが、善悪も無くそういったことをしてしまう人はたまにいます。
「10回実験をしたら9回はまともなデータが取れたが、1回だけ変な数値が出た。実験操作をミスったかな？ノイズになるからこのデータは無視しておこう。」

これは勝手にやってはいけません。取れたデータはすべてちゃんと記録し、無視をするにしてもその理由を実験結果にまとめるべきです。
もしかしたらその1回がとても珍しい有益な結果かもしれません。
必要ならば追試をしましょう。

今の仮説を今すぐ、なにがなんでも証明することが目的ではありません。
最終的に正しい仮説を見つけ出すことが目的です。