エンジニアとは全く関係ないと思われる物理学ですが、実は物理学の研究プロセスは、システムトラブルの調査やプログラムのデバッグの際に重宝すると筆者は考えています。

今回は文系出身のエンジニアや「物理学とか蕁麻疹出るわ！」と思っている方に向けて、物理学を学んでいるとこんなにメリットあるんだぜ！ってのを紹介していきたいと思っています。

※ちなみに筆者は自社開発企業でWebアプリケーションエンジニアをしています。大学では物理学科で物性物理を専攻していました。

そもそも物理学の研究ってどんな感じなの？

まず物理学に明るくない方向けに、物理学の研究がどのように進められているのかを説明していきます。

一般に物理学とは「自然界で起きている現象を数学を使って記述する」学問です。
数学を使って記述するためには「現象」が「数式」で示せることを実証していく必要があります。※数式でない場合もある。

現象の例

• リンゴが地面に落ちる
• 地球が太陽の周りを公転する
• 風が吹く

これは超簡単な例で誰でも知っている現象だと思います。
しかしこれを数式でどう表すか知っている人は物理学をやったことある人でないとわからないかと思います。
現在ではこの現象がいずれも数式で表すことが可能です。
ではどのように「数式」で表せることが実証されたのでしょうか。。。

いずれにも共通して言えることは

• 影響範囲のものを計測する
• 複数回同じことを試行する
• 対照実験（1つのパラメータだけを変えて実験する手法）

これらによって、「普遍的な法則」を現象から導き出します。

仮説を立てて、それを検証する

例えば、1つ目であれば 「自由落下運動」 といいますが、

• 重いモノのほうが先に落ちるだろう
• 高いところから落とすと高さに比例して落ちる時間がかかるだろう

と 「仮説」 をたてることができます。
仮説とは上記のように「きっとこうなっているだろう」と「予想」を立てておくことです。
すると、

• リンゴの質量を量っておく
• 落とす高さを測っておく
• 地面に到達するまでの時間を計測する

というように影響するだろうものの計測（記録）をすべきものが明らかになります。
そして

• リンゴを鉄球に変えて実験してみる
• 高さを2倍のところにして実験してみる
• 数十回、数百回と試行し、毎回時間を計測する

というように、「仮説」に対する「実証実験」をしていきます。
すると、

• リンゴでも、鉄球でも同じ高さから落としたら、同じ時間で地面に到達すること
• 高さを2倍にしてもかかる時間は2倍ではなく、√２倍であること

などが実験からわかります。
これにより「仮説」を「検証」することで、現象の特徴が理解でき、これにより、

• 自由落下運動に質量には関係ない（すべてのものに同じ大きさの重力加速度がかかっていること）
• 自由落下運動の落下時間は高さの√に比例している（力学的エネルギー保存則）

が導かれます。（歴史上こういう順番だったかはわかりませんが）

ここで言いたいこと

物理学の簡単な研究の例を用いましたが、ここから言いたいことは

• 問題や解き明かしたい事象に対して 「仮説」 を立てる
• 仮説を立てたらそれに対して必要な要素を 「計測（ベンチマーク）」 し、実際に 「実験」 する

このプロセスを何度も実行してきた結果が今の物理学を作り上げています。

※重要なことを忘れてましたが、サイエンスの考え方は同様に「仮説→検証→普遍的法則の実証」と言うプロセスは変わらないと思います。
ただ、私が物理学専攻だったこともあり、物理学が伝えやすいただそれだけです。

エンジニアの仕事に置き換える

システムトラブル調査やプログラムの不具合修正においてこの物理学の考え方が非常に重要です。

• 「ボタンを押しても画面遷移しません。何でですか？」
• 「100と表示されるべきなのに10と表示されます」

のような問い合わせや質問がまぁまぁあります。
これは上の物理学の考え方がなっていない問い合わせです。
こういう問い合わせを受けるとエンジニアは2通りに分かれます。

• 隅から隅まで原因を総当たりで調べる(私は 「ホワイトボックス調査」 と勝手に呼んでいます)
• 現象に対し影響する設定やオペレーションをヒアリングし、ひとつづつ可能性をつぶしていく（仮説→検証→実証のサイクル）

前者は、言うまでもなくえげつない工数がかかります（IT人材不足のこのご時世にこんなエンジニアは存在してはならない）。
後者は、発生条件を絞り込んでいき、「設定の組み合わせが原因か？」、「このオペレーションでしか発生しないようだ」のように、影響範囲を小さくしてから、根本的な原因を1つずつ検証していきます。

今回の1つ目の例であれば

• XXXの設定とYYYの設定はどうなっていますか？
• ボタンのある画面の前の画面はどの画面ですか？
• ほかのボタンは問題なく動きますか？

のようにあらかじめその動作に及ぼす影響範囲から必要なものをヒアリング（計測、ベンチマーク）しておき、

• XXXの設定をx1からx2に変えたらどうだろうか
• ほかのボタンは意図通りに動いているみたいだからこのボタンのバグかもしれない

のように仮説を立てることができ、あとは順に検証して聞くという作業になります。

不具合修正の場合も、
まず「設定やオペレーションから再現する状態を明らかにする」→「設定やオペレーションを1つずつずらしたら再現するか？」のように絶対発生する状態をベンチマークしておき、そこから仮説に基づき検証をしながら影響範囲を絞って、最終的な修正方針を固めるというプロセスを踏むと思います。

終わりに

新人エンジニアや、一部の論理的思考に欠ける人材が、優秀な人材の工数を奪わないためにも、IT業界で「エンジニア」を名乗る人にはぜひこの物理学のプロセスである「仮説を立て→検証し→実証していく」のサイクルを実行できるようになってほしいです。
日々のトレーニングは必要ですし、前提知識も必要だと思いますが、多くのエンジニアは「技術などに対する知的好奇心」は高いはずなので、合わせて今回紹介した物理学のプロセス、ロジカルシンキング、クリティカルシンキングのような思考方法なども学んで、優秀なエンジニアを目指していきましょう。

※クリティカルシンキングについては私の個人ブログにざっくりまとめていますので参考まで↓↓↓