デバッグという総合芸術

デバッグが好きな理由

一般に好まれない作業ですが、個人的に好きなもののひとつが、

「デバッグ」

です。デバッグとは、うまく動かないものの原因を究明して修正するというものですね。デバッグの対象は色んな可能性がありますが、一応、ソフトウェアプログラムとしておきましょう。ソフトウェアファーストの時代ですしね。

なぜ好きか？
基本的に地味な作業だなとは今でも思っていますが、問題を解決できたときの達成感・爽快感を何度も体験しているからでしょう。

デバッグという作業を取り巻く問題

あまり好きな人がいない、このデバッグという作業。でもプロジェクト全体を考えると相当インパクトがある作業になり得ます、それは、

１）担当者によって、所要時間が5分にもなるし、1ヶ月にもなる

という感じに振れ幅が大きいからです。デバッグを効率的に進めるには、幅広い知見と経験、それに先入観のないゼロベースの発想が必要になります。

・何人かでああでもないこうでもないと悩んでいるところ、たまたま後ろを通りがかった、プロジェクトに無関係な人のアドバイスで突破口が見つかった

・社内で何年も使いまわししていて充分検証されていると思っていたブロック（もはやブラックボックス）のなかにバグの原因があった＝当初はそこを検証すらしていなかった

といった経験が私にもあります。
プログラムの開発自体のスケジュールを引くことができても、問題が発生してからのデバッグのスケジューリングは非常に難しいのが現実です。でもスケジュールのお尻は決まっているものですけど。

２）知見が属人的になる

デバッグにかかる時間が、人による、という状態になりやすいと書きました。結局、いろんな事例に頭を突っ込んで経験している人には知見が集まっていくのですが、そういう地味な作業から逃げるひとには知見が貯まりませんので、差は広がります。詳細なドキュメント化とその共有によって属人化を避けようとする企業・プロジェクトもありますが、小さな会社ではそこまで手が回ってないところが多い印象です。

３）評価されにくい

何度も書きますが、デバッグ作業はとても地味で、かつ、問題の修正という後ろ向きな作業のため、他人が出した不具合を調べている場合でも、なぜか悪者扱いを受けることがあります。
また、非常に短期で問題を究明・修正出来た場合でも、評価されにくい傾向にあります。あくまで個人の印象ですが笑。
ですので、

デバッグのような、地味だけど重要な作業に対し正当に評価できるマネージャ

というのが重要です。日本にいるでしょうか？

デバッグの知見を増やし視点を改善する方法

私の思うところです。

１）いろんな事例に首を突っ込む

せっかく（？）まわりで問題が起こっているのなら、とにかく首突っ込んでみることですね。まあ、下手に突っ込むと自動的に involve されてしまうので加減が難しいところですが。

２）デバッグが上手いひとにアタマのなかの思考回路を聞く

問題解決が上手いひとがいるので、そういう人を捕まえて、話をききましょう。エンジニアは総じて、自分の得意分野の話を聞かれるのは嫌いじゃありません。ランチ、ディナーを奢ってでも話を聞く価値はあるのです。

３）過去の経験を確実に蓄積していく

昔の話は雰囲気しか覚えてなく、細かいところどうだったっけかな？となることが多いです。せっかくの経験なので、そこはもうひと踏ん張りして、
・そのケースでの自分の思考過程
・トライしたこと
・どうすれば未然に防げるか、など、そのとき感じたことなど何でも
こんな、自分用メモをざっとでも書いて蓄積しておくと良いと思います。