ソフトウェアのバグはテクノロジーの世界ではよくあることです。 10 行を超えるコードを書いたことがある場合は、誤ってコードを作成した可能性があります。 さて、最後にバグについて慌てている顧客や同僚からメッセージを受け取ったときのことを思い出してください。どうやって終わりましたか？作業を中止しなければならないほど、そのバグは緊急性がありましたか? この記事では、バグについての従来の考え方に疑問を投げかけ、各バグがあなたとあなたのチームにどれだけのコストをもたらすかを探っていきます。 私について こんにちは 👋、私の名前は Krste です。7 年以上スタートアップで働いているフルスタック開発者です。最近、私は、ユーザーが直面する重大なバグについてソフトウェア チームに警告するバグ監視プラットフォームである を共同設立しました。 Bugpilot 私がこの記事を書いたのは、バグに関する従来の考え方や「できるだけ早く修正する必要がある!」という考えに異議を唱えることを目的としています。それぞれの問題の真のコストを調査する必要性を疑問視しています。  100% バグのないソフトウェア。神話か現実か？  100% バグのないソフトウェアを達成するという目標は、常に困難なものでした。バグのないアプリを作成するというアイデアは理想的に思えるかもしれません が、実際に可能でしょうか? 真実は、複雑なビジネス ロジック、人的エラー、テクノロジーの継続的な更新により、ソフトウェアのバグは避けられないということです。注意深くテストと品質チェックを行ったとしても、それらを完全に排除することは困難です。 しかし、新しい開発者ツールと改善されたプロセスのおかげで、チームは現在、関連性と競争力を維持できるよう、新しい機能を驚異的なペースでリリースしています。 そして、コードベースに変更を加えると、常に何かが壊れる可能性があります。 (多くのデバイスと複数のブラウザをサポートしなければならないことは、まったく役に立ちません。) もちろん、バグをゼロに近づけなければならない場合もあります。銀行、医療、航空宇宙などの特定の業界では、  ため、間違いを最小限に抑える必要があります。 人命に関わる可能性がある これは、これらの業界のほとんどのソフトウェアが数十年前のテクノロジーで書かれている理由、そして人々が今そのテクノロジーに触れるのをためらっている理由を説明しています。 しかし、最終的には、   」と自問する必要があります。マーケティング ツールや CRM を構築しているほとんどの人にとって、 その理由を説明していきます。 「それだけの価値があるのか? バグを放置するよりもバグを修正するほうがコストがかかることが多いと思います。 すべてのバグが平等に作られているわけではない あなたが電子商取引 Web サイトで作業しているときに、バグによりチェックアウト プロセスが中断され、顧客が購入を完了できなくなったと想像してください。 このバグはコア機能に直接影響を与え、売上の損失や顧客の不満につながる可能性があるため、このバグは直ちに対処する必要があることは痛ましいほどに明らかです。 同様 に、新規ユーザーが新しいライドシェア アプリに参加できない原因となっているサインアップ ページのバグを、プロフィール写真の更新に関連する問題と同じように扱うことはできません。 これらの白黒の例は、バグを検出する必要があるだけでなく、 しかし、実際には、物事は白か黒かが決まるわけではありません。ほとんどの状況はグレーゾーンに当てはまります。 バグの影響を理解する方法も必要であることを示しています。 そこで問題は、何を修正すべきかをどうやって知るかということです。  「今すぐ修正しなければ顧客が離れてしまいます。」 私たちは、顧客が見つけたバグに対して「特別な」緊急感を加える傾向があることに気づきました。 おそらくあなたも、 顧客の 1 人が軽微な問題を抱えていて、まるで世界が燃えているかのようにチーム全体にメッセージが殺到する、同じような状況に陥ったことがあるでしょう 🔥 大口   「ジョバンニは、テキストを右揃えにできないと不満を言いました  1 彼らは重要な顧客です。今すぐバグを修正しなければなりません!」 。11  - あなたの上司 私の経験に基づくと、カスタマー サクセス、サポート、販売などの顧客と関わる役割は、顧客の反応やそれが評判に与える影響に応じて問題を優先する傾向があります。だからこそ、彼らにとってはすべてが大したことのように思えるかもしれませんが、それは当然です。 悪い印象を与えたり、否定的な評判を持ちたくない人はいません。バグはまさにそれを引き起こす可能性があります。 バグの影響を受けるユーザーが増えるほど、バグを修正することが（おそらく）より重要になります 場合によっては、生産上の問題が発生したときに対処されることがあります。特に私たち開発者は、受信トレイに届いたバグやコーディング エラーにすぐに飛びつきます。 あなたまたはあなたのチームは、  や のツールを使用して監視し、エラーが発生したときに通知を受け取る場合があります。 Sentry Bugsnag など エラーが見つかると、すぐに開発者に割り当てられ、誰もが Slack でアップデートを待ちわびます。 通常、これらのツールは、発生頻度と影響を受けるユーザーの数に基づいてエラーに優先順位を付けます。  Human.prioritizeBugs() ただし、ほとんどのチームにおけるほとんどのバグの優先順位は、製品所有者または主任開発者のいずれかによって決定される可能性があります。 これらの役割は通常、ビジネス ロジック、基盤となるテクノロジー、現在のワークロード、今後の優先事項を理解し、それに応じて計画を立てます。 次のようになります。 優先順位付けの基準は 最初の質問ですが、すでに少し難しくなってきています。 クリティカルには明確な定義がありません。コア機能が使用できない場合、それを修正する必要があることは明らかです。 それは重要ですか? クリティカルとは何ですか? しかし、上の例で見たように、重要な顧客が影響を受けた場合はどうなるでしょうか? 一つだけです？みんな？私たちも知っていますか？多数のユーザーが影響を受ける場合、たとえそれがマイナーな機能に関連するものであっても、問題に対処する必要がある場合があります。 何人の顧客に影響を与えていますか? 次に、  プロセスの所有者は、問題を修正するのにどのくらい時間がかかるかを尋ねます。数時間しかかからない場合は、それを今週の作業に組み込む方法を見つけるでしょう。  直すのにどれくらい時間がかかりますか？ 「バグトリアージ」  「（できるだけ早く）直すか、直さないか、それが問題だ。」 開発者は、「緊急」のバグに対処するときにジレンマに直面することがよくあります。彼らは現在のタスクを急いで終わらせてバグを修正する可能性があり、その過程で新たなバグが発生する可能性があります。彼らは、突然バグに注意を切り替え、現在のタスクを完全に放棄する可能性があるため、 を頻繁に無視します。 コンテキスト切り替えのオーバーヘッド これらのシナリオには 3 つの重大な問題があります。 チームは優先順位を誤っており、その結果、時間を無駄にし、関連性の低いバグを修正する可能性があります。 重大ではないバグに不必要な緊急性を加えると、チームは不必要に焦点を切り替えることになります。 バグに対処する前に、その を考慮することが重要です。では、バグによってチームは実際にどれくらいのコストがかかるのでしょうか?それを直すのに相応の費用がかかるのでしょうか？ コスト バグの修正にはどれくらいの費用がかかりますか?   「無料のランチなどというものはない」という言葉を聞いたことがありますか？ コストについて話すとき、開発者として最初に考えるのは、インフラストラクチャのコスト、サーバー、Lambda 関数、MongoDB クラスターなどのコストです。 ただし、バグに関しては、人的コスト、つまり について話しています。 注意力 コンテキストスイッチング コンピューター工学を学んだことがある方、または OS の仕組みについて読んだことがある方は、おそらくコンテキストスイッチについて聞いたことがあるでしょう。 コンピューティングにおける 、プロセスまたはスレッドの状態を保存して、後で復元して実行を再開し、以前に保存した別の状態を復元できるようにするプロセスです。 コンテキスト スイッチは  (  [Wikipedia](https://Context switch https://en.wikipedia.org › wiki › Context_switch) より)  OS コンテキスト スイッチングの 1 つのケースは、マルチタスク です。コンテキスト スイッチングは、CPU からプロセスを切り替えて別のプロセスを実行できるようにするマルチタスクの特徴です。 この言葉をどこで聞いたことがあるでしょうか🤔? - ああ、はい：  「私はマルチタスクの達人です。」 マルチタスクは、誰かが 2 つのタスクを同時に実行しようとしたり、あるタスクから別のタスクに切り替えたり、2 つ以上のタスクを素早く連続して実行しようとしたときに発生することがあります。 友達と話しながら洗濯すればきっとうまくいくでしょう。難しいのは 、コードを書くなど、精神的に複雑なタスクを実行する場合です。 。彼らは、人々がタスクを完了するのにかかる時間と、タスク間の切り替えにかかる時間コストを測定しました。結果は次のとおりでした。 心理学者は、タスク切り替えのコストを決定するために、タスク切り替えに関する複数の実験を行ってきました   「 切り替えコストは比較的小さく、1 回の切り替えあたりわずか数十分 1 秒の場合もありますが、タスク間で繰り返し切り替えを行うと、コストが膨大になる可能性があります。 … タスク間を切り替えると、生産的な時間の 40% が費やされる可能性があります。」  "ちょっと時間ある？" これを想像してください。あなたは閉じ込められ、完全に没頭しており、この新しい輝かしい機能を完了するのを妨げるものは何もありません。外の世界は存在すらせず、あるのはあなたとあなたのコードだけです。しかし、どこからともなく呼び出し音が聞こえます...携帯電話に新しい通知が届きます。 今週末、あなたの友達があなたを飲みに誘っています。そうやって、 、あなたの人生の次の 20 分は過ぎてしまいます。 もう あるいは、同僚から、特定の問題について手伝う時間があるかどうかを尋ねる Slack メッセージを受け取ったところかもしれません。   2 番目の状況は最初の状況よりも受け入れられるでしょうか? まあ、結局は  Eclipse と Visual Studio を使用する 86 人のプログラマーから記録された と、414 人のプログラマーに対する調査 (   ) に基づいて、次のことがわかりました。 関係ないんですけどね。 10,000 のプログラミング セッションの分析 Parnin:10 プログラマーが中断から作業を再開した後、さらにコードを記述するのに 10 ～ 15 分かかります。 メソッドの編集中に中断された場合、プログラマが 1 分以内に作業を再開したのは 10% のみでした。 プログラマーは、中断のない 2 時間のセッションを 1 日に 1 回だけ受ける可能性があります。 開発者は、無駄な会議に関するコンテキストの切り替えを避ける ( ) 傾向があります。それでも、「開発者のタスク」の間でコンテキストを切り替え、その悪影響を完全に無視すると、私たちは何らかの形で盲目になる可能性があると私は信じています。 そして嫌う 最終的な考え 現実の世界では、私たちは常に、お金、時間、 など、限られたリソースを扱っています。 注意力 バグの修正には代償が伴います。  「いいえ」は、1つのことに対して「いいえ」ということです。  「はい」は多くのことに対してノーです。 – ジェイソン・フリード マルチタスクは表面的には効率的であるように見えますが、タスク間の切り替えには時間がかかり、最終的にはより多くのバグが発生します。 バグの修正に「はい」と言うということは、機能に対して「いいえ」と言うことを意味します。 どのバグがすべてを削除する価値があり、どのバグがそうでないか (ほとんどはそうではありません) をより適切に選択できるようになります。 コンテキスト切り替えの隠れたコストを理解すると、 虫のことを気にするのをやめるべきでしょうか? うーん、ダメ。 落ち着いてバグを受け入れるのは難しいことですが、私たちは皆、高品質の作品を生み出し、誇りに思えるものを作りたいという内なる願望を持っています。 ただし、少なくともバグ修正のコストを認識し、  自問する必要があります。 「修正する価値があるか?」と 残念ながら、これらの厄介なバグが邪魔になることがよくあります。 トム・デ・マルコが著書 で書いているように、これは品質を気にするのをやめるのが難しい理由を説明しているかもしれません。 「Peopleware」 私たちは皆、自分の自尊心を、自分が生産する製品の品質、つまり製品の量ではなく質と強く結び付ける傾向があります。 (何らかの理由で、大量の平凡なものを結果として出すことに満足感はほとんどありません。ただし、それは特定の状況で必要なことかもしれません。)  – ピープルウェア バグ予防にもっと力を入れるべきでしょうか? 先ほども述べたように、多くの業界では選択肢がありません。そこでは、間違いの発生を防ぎ、できるだけ早く修正するために必要なすべての措置を講じる必要があります。 しかし、ほとんどのアプリにとって、 余分な努力をする価値はあるでしょうか?  PS 結局のところ、たとえすべてのバグを修正する魔法の杖があったとしても、ユーザーは依然としてアプリを悪用する方法を見つけることになるでしょう 😅 

Find hidden bugs

Book a Call

Bugpilot

このオーディオは、ストーリーの元の言語で制作されています。

虫があなたの勢いを奪っていませんか？

About Author

コメント

ラベル

この記事は

Related Stories

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

デジタルノマドの皆さん、タイの新しい DTV ビザについて知っておくべきこと

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

Claude Sonnet 3.5 システムプロンプトの漏洩: 法医学的分析

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

デジタルノマドの皆さん、タイの新しい DTV ビザについて知っておくべきこと

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

Claude Sonnet 3.5 システムプロンプトの漏洩: 法医学的分析

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps