Pedagogy #08 なぜソフトウェアエンジニアはシャワー浴びている時にバグを解決できるのか？
ラノベみたいなタイトルからのスタートと思いきや、まず、皆さんに質問を投げかけるというもっとややこしいスタートを切らせてもらう。
ソフトウェアエンジニアの職業の方、または学生の方にお聞きしたい。
丸一日かけても解決できないバグの解決方法が思い浮かぶ瞬間は、画面を見ている瞬間の方が多いのか、それとも、画面から離れた瞬間の方が多いのか。
自分は俄然後者である。バグを解決しようと切磋琢磨して頭が沸騰するレベルまで画面を凝視しても解決はできず、シャワーを浴びていたり、コーヒーを飲んでいたり、友達にバグを説明しているときだったり、ベッドで横になっているときに解決することの方が多い。
コードを入れ替えたり、編集したり、手がキーボードに触れていて画面を見なければ解決できない課題を、なぜコードを編集することも見ることもできない時に解決できるのであろうか。
課題を解決するヒントは、具体レベルにあるのではなく、抽象レベルにあるのだ。具体レベルで物事を見るときに起きるのは、「何が」ダメなのかを探すことだが、抽象レベルだと「なぜ」ダメなのか、といった思考回路に切り替わる。
言葉だと伝わりにくいので、実際に一つの思考実験から体験してもらいたい。
#include <stdio.h>
struct {
signed int flag: 1;
} status;
int main()
{
status.flag = 1;
printf("%d\n", status.flag);
return 0;
}こちらのコードの出力は以下になる。
-1コード上だと出力する変数に1を代入したのに、その変数を出力した際には、-1になる。コードのどこが、何がおかしいのか皆さんは見つけようとする。
ということで、一旦コードを見るのをやめてみましょう。そして、頭の中で解決できるまでこの記事から離れてください。
…
解決できましたか？「何が」ダメなのかから「なぜ」ダメなのか、思考を切り替えることはできましたか？まだ解決できていない場合、解決できるまで「なぜ」このような挙動なのか、自分自身が身につけている知識と質力されているアウトプットのギャップを埋めるために、一つ一つのコンセプトを再度ご自身でアップデートしてみてください。例えばsignedのコンセプトについて、bit fieldのコンセプトについて。
…
コードを見るからコードを見ないという行動は、思考回路を「何が」ダメなのか、から「なぜ」ダメなのか、といった形に切り替わることができる行動である。
さて、今回のような知的技能に関しては、規則（エンジニアの言葉で言うと、ユースケース ）を学ぶことで応用性、再現性の高いスキルが身につくので、今回のまとめとしては、「コードを何時間見ても解決できないバグがある場合、一旦そのバグから物理的に離れよ」という規則である。
追記：記事を書いてインプットアウトプットするよりも、obsidianで自己完結しているため、記事を書くことが少なくなってしまったが、読んでくれている学生がいることを知り、彼らにもちゃんと自分の思考や言葉を伝えたいという気持ちが強くなった。日本語っぽくて日本語っぽくない自分の文章を読んでくださり、ありがとうございます。リアルでもバーチャルでもお話ししたい学生いれば、いつでも連絡ください。
すごく無駄な雑談：ChatGPTがもてはやされている今、自分の文章もChatGPTにレビューして貰えば、何倍も読者に伝わりやすい文章が出来上がると思うのに、なぜしないのか。ChatGPTに今回の記事のタイトルを投げ掛ければ、この問いに答えてくれるかもしれないのに、なぜしないのか。それは、悩んで、考えて、解釈して、言語化するのがつら楽しいからである。自分の記事を書くときの優先順位度としては、この記事を書くプロセスが楽しいかである。読者に伝わる文章を書くことは、二の次であるので、記事を書く人としては失格だろう。それでも、自分が人間として、人間の醍醐味である、悩んで、考えて、解釈して、言語化するという贅沢な楽しさを満喫したいという自己満足型のプロセスで出力されたこの記事をみなさんにも楽しんでもらいたい。こういうオチがない雑談も贅沢だと思っている自分です。
