デバッグのやり方がわからない人へのアドバイス

僕は以前（というか少し今も）ウェブサイト制作においていわゆる「コーディング」とされる業務をしていました（というかたまに今もしています）。最近の多くはゼロから任させるのではなく、「どうも思うようにならないんですが、なんで？」という検証というか解消というかその類が多いんですね。

もちろんそれはコーダーと呼ばれるコードを書く人から相談受けることもありますが、どちらかというとコードを書かないディレクターと呼ばれる人からの相談もあります。

そんなとき、どうやら僕は解決が早いみたいです。

コーディングをするという経験則は確かにありますが、そこまでしっかり今も技術の様子を追っているわけではないので、結構しっかり調べながらなのですが、解決までのスピードが早いみたいです。

もしかしたら、どうやって解決しているのかを少しここに書いてみたら誰かの役に立つかもしれない・・と思って、ちょっと列挙してみようというのが今回の趣旨です。前置きが長くなりました。

まず初めに行うことは、状況の把握です。
何をしたいのだけど何ができないのか・・・を明確にすることです。
基本的に、プログラム（Webサイトをプログラムというかは別でとりあえずプログラムとさせてください）はきっかけがあって動きます。

なので、その「きっかけ」が何なのかをはっきりさせることです。

次に行うのは、「きっかけ」周辺の状況をコードやらなんやらで確認します。これはどこに施しを加えたらいいのかを把握するためです。

そこがわかったら次にすること・・これが意外にやってない人が多いみたいなのですが、その「施し」を消してみるということと数値だけ変えてみるということです。

まず「消してみる」というのは、この施しがないときにどんな症状が出るのかを確認するためです。そして数値だけ変えてみるというのは、間違っていたとしても機能するのかを確認するためです。

この辺りの現状をしっかり把握した上で、ターゲットを絞り消しては確認、を繰り返し、解消しなければいけないターゲットを１つにします。

あとは検索との勝負ですが、検索の前に１つに絞った問題をきちんと自分で日本語で説明できるようにします。これは、その後自分でやるかやらないかに限らず、「何となくの課題にしない」という掟です。

もちろん、当てが外れることはありますが、外れたらまた戻ってくり返すという作業になります。

ここまでくれば、検索。今や、こういうトラブルは検索すればガンガン出てきます。もしかしたら、ChatGPTに聞けばわかるのかもしれませんが。。。

ということで技術的な解決策を知ってるわけでもなく、立派なプログラムがソラで書けるわけでもなく、解決が早いポイントは、「しっかりした調査と言語化した仮説」であるということです。

今回デバッグというテーマで書きましたが、これって「企画」というものでも「チームメイキング」というものでも使える考え方です。小さいところでミクロなPDCAを回す・・・みたいなもんです。

もしよかったらお試しください。