こんにちは、商品開発事業部でエンジニアとして働いている成田です。普段は、専門知識がなくても簡単に使える国産CMS・MAツールである『LeadGrid』を開発しています。

みなさんが開発中に「一番辛いな」と思う作業はなんでしょうか？私が一番辛いなと思うのは、圧倒的に「デバッグ」です。デバッグとは、バグの原因を見つけて修正することなのですが、これが難しいです。

いきなり英語の赤文字で何行も何行も画面いっぱいに出てくるこの作業に、嫌悪感を抱く方が多いのではないでしょうか。

今回はこのデバッグについて、楽しみながら進めるために、自分が見つけた方法をご紹介します！

デバッグの重要性・注意点

バグ修正は、やらない後悔よりやって大成功！

みなさんは、漫才日本一を決める「M-1グランプリ2024」をご覧になりましたか？今年のチャンピオンは、令和ロマンというコンビだったのですが、彼らが漫才中に言っていたセリフが「やらない後悔よりやって大成功！」です。もちろん漫才中のセリフなのでボケなのですが、ことデバッグ界隈においては結構核心をつく言葉です。

バグを放っておくとどんなことが起こるでしょうか？思いついたことを羅列してみます。
・ユーザーの不満が溜まる
・信用を失ってしまう
・ユーザーも信用も何もかも全て失った開発チームの士気低下

大問題ですよね。ユーザーも信用も失った後に、最後に自分が全てを失ってしまいます。因果応報とはまさにこのこと、世の中はよくできています。「バグ修正をやらない」ことがいかに後悔を生むかわかってもらえたと思います。

では逆に「バグ修正をやる」ことは何を産むのでしょうか。
・ユーザーの不満が解消される
・迅速な対応によって感謝され、信用が増す
・ユーザーも信用も失わず、開発チームの士気は最高潮を迎える

やりましたね！これは大成功と呼べます。「バグ修正をやる」ことで、開発チームは何も失うことはありませんでした。信用など得られたものすらあります。

大前提なのですが、どんなすごい会社のどんな有名なプロダクトでも、必ずバグは発生します。これは人間が作業している以上これからも変わることはありません。大事なのはバグに対していかに早く正確に修正するかということです。まさに、「やらない後悔よりやって大成功！」です。

穴の空いたバケツに水を足していませんか？

ある論文で「バグ修正のための変更の40%が新たなバグを混入する」という研究結果が出ています。泣く子も黙る恐ろしい数字ですよね。さらに、このバグ修正で生まれたバグはなかなか気づくことが難しいです。

甘いテストだと、バグが起きていた部分だけのテストケースを確認して、「あ、直っている」としてリリースされてしまうかもしれません。こんな感じで何も考えずに愚直にバグを直していると、バグがバグを量産してしまいます。まるで1匹いたら100匹いるあの動物みたい......

先ほど、「やらない後悔よりやって大成功！」と言っていたくせに、「やって大成功」ではない可能性もあるということです。つまり、ただバグを直すことだけではなく、その直し方も結構大事だということです。

ここまででバグを直すことの重要性と注意点を述べてきました。ここからはいよいよ実際にデバッグの進め方について述べていこうと思います。

デバッグがぐんぐん進むチームの特徴

だめな例：こんな先生は嫌だ「君がやったんだろ！」

みなさんは、どんな先生が苦手でしたか？私は「君がやったんだろ！」と決めつけてくる先生です。

でも、大きくなってエンジニアとして働いている今、同じことをしちゃっていませんか？

つまりデバッグでいう「君がやったんだろ！」は、原因を自分で勝手に決めつけることです。

たとえば、フロントエンドでエラーログが見つかったとします。ここでいう悪い先生は、エラーの原因をフロントエンドと決めつけて疑うことです。しかし良い先生は違います。疑う心は奥底に秘めて、よく話を聞きます。

話を聞くと、フロントエンド君はどうやらバックエンド君から受け取ったデータをそのまま表示しているのです。しかし、まだバックエンド君と決めつけてはいけません。なぜならまだバックエンド君の話を聞いていないからです。

誰かの話だけを鵜呑みにせず、接する人全員に同じ扱いをします。すると、バックエンド君はデータベース君からとってきたデータをそのまま返しているだけだと言っています。データベース君に聞いたところ、どうやらそもそも入っているデータが間違っていたとのこと。どうやら原因はデータベース君だったみたいです。

わかりやすく抽象的な例にしましたが、これはクラス単位や関数単位にも同じことが言えます。デバッグ作業中は、ついつい「君がやったんだろ！」と決めつけてしまいがちです。しかし、決めつけたことが間違っていた場合、沼にハマってしまい時間だけを浪費してしまいます。大事なことは、自分の直感や予想で決めつけず、「ログ」というそれぞれの意見をちゃんと聞いて対応することです。

良い例：こんな先生は好き「給食食べるの遅い人にも優しい」

私は小さいときから少食で、食べるスピードが遅かったです。よく給食を食べきれずに、みんなが食べ終わって掃除をするなか、泣きながら残って食べていたのを覚えています。その後、成長期が訪れて体は大きくなり、今では悩むことはなくなりました。誰にでも成長する前のできない時期があり、それと同じように、誰にでも成長してできるようになる時期があります。

GIGでの実際の体験談を話したいと思います。私はフロントエンドエンジニアとして働いていたため、フロントの技術には自信がありました。しかし、それ以外の領域にはまだまだ知らない知識も多くありました。

そんななか、バックエンドのデバッグを任せてもらえる機会がありました。あまり経験のない分野のデバッグは、私にとって大きなステップです。少し緊張していましたが、タスクと同時に「今回はスピードではなく理解を優先してね」という言葉をもらいました。すっかり緊張のなくなった私は、理解に重点を置き、スペシャリストに質問しながら、ついには爆速でデバッグを自走することができました。

大文字・小文字があっているかなど、とても細かい部分まで見るデバッグのようなタスクでは、心理的安全性が大切です。焦って進めようとしてしまうと、かえって必要な時間が長くなってしまいます。

私が所属するGIGでは、この心理的安全性の担保をすごく大事にしています。気軽にその道のスペシャリストに質問できる環境、余裕のもったアサインが、結果的にデバッグのスピード感を高めているいい例だと思います。

穴の空いたバケツ、大船にのる。

ここまで、デバッグの重要性・注意点や、進め方について述べてきました。

具体的にまとめると
・バグを見つけたら、素早く解消を目指すこと
・ただ解消するだけでなく、解消の過程にも気をつけること
・デバッグを進める際は、原因を決めつけず、よくログを見ること
・デバッグを進める際は、実装者の心理的安全性を担保すること

です。

「じゃあデバッグって、技術力の高いエンジニアしかできないじゃんか！」というと、そうではありません。先にも述べた通り、デバッグは大文字・小文字レベルで細かくコードリーディングを行うので、むしろ勉強中の人ほどするべきだと思います。

デバッグに大事なのは、実装者ではなく実装者がいる環境です。環境によっては、穴の空いたバケツに水を入れるようなPull Requestも、コードレビューなどを通して水の漏れようがない大船のようなPull Requestになります。

GIGでは、一緒に大船に乗りたいエンジニアを募集しています！

また、国産CMS・MAツール『LeadGrid』を使ったサイト制作のご連絡もお待ちしています！

■株式会社GIG
サイト制作のお問い合わせはこちら
採用応募はこちら（GIG採用サイト）
採用応募はこちら（Wantedly）

成田 陽紀

2001年生まれ。そろばん1級（全国珠算教育連盟・日本珠算連盟）。学生時代は、株式会社GIGにインターンとして所属。2024年4月に株式会社GIGに入社。現在はLeadGrid開発チームにてエンジニアとして働いている。とても足が速い。