お役立ちブログ|umbrElla

【b→dash #10】非エンジニアのエラー対応、まずは落ち着いてこの3ステップから

作成者: umbrElla編集長|2024/07/210

b→dashの導入・運用に対してお悩みをお持ちの  マーケターの方・その上司の方に向け、全12回に渡り解決のヒントをお伝えしていきます。

 

ABOUT 執筆者:umbrElla編集長

累計50社以上のb→dashプロジェクトを支援。クライアントは、金融・不動産・アパレル・食品・スポーツ球団・化粧品・人材・店舗ビジネスなど業界業種を問わず、企業規模も創業まもないベンチャー企業から大手上場企業まで幅広く担当。多種多様な観点からの助言や、豊富な経験をもとに先回りした提案を強みに、b→dash初心者がつまずきがちなポイントを強力にサポートしています。

 

第10回は、自分がb→dashで実装したデータがエラーになったらどうしよう...と心配されている方に向け『非エンジニアのエラー対応 まずは落ち着いてこの3ステップから』をテーマにお届けします。最後におまけ資料もありますので、ぜひ最後までご覧ください。

 

 

b→dashのことならumbrEllaへ!

 

多くのSaaSサービスが

「簡単」「誰でも使える」ことを謳っていますが、

確かに”使うだけ”なら問題ないでしょう。

ただ、多くのSaaSサービスにおいては

「そういうことは先に言ってよ~

ということが

プロジェクトを進める中で沢山でてきます。

そういった「共通する失敗」を避けるためには

信頼できるパートナーが必要不可欠です。

「代理店に頼むと高いしな...」

「とはいえ、社内に適任者もいない...」

「誰に頼んだらいいかわからない…」

このようなお悩みをお持ちの方は、

まずはお気軽にumbrEllaへ無料相談してみてください。

 

 

 

 

非エンジニアのエラー対応に必要なステップを解説するにあたり、まずは「優秀なエンジニア」さんのお話しをしてみたいと思います。

みなさんは、「優秀なエンジニア」と聞くとどのようなイメージを思い浮かべますか?私を含めた非エンジニアの方のイメージは概ね(おおむね)こうだと思います。「優秀なエンジニアは完璧なコードを書き、問題が発生しない」「優秀なエンジニアは革新的なソリューションを開発できる」と。

私はゴリゴリの営業マンからIT業界に転職したわけですが、これまでプログラミングを生業(なりわい)にしたことはありません。ただ、とある「エンジニアリングのできる起業家養成スクール」に一時期通っており(なんとか無事に卒業)、そこで「優秀なエンジニア」のお話しを聞く機会がありました。曰く(いわく)、「優秀なエンジニアは、エラー対応が上手いエンジニアだ」と。意外ですよね?エラーを起こさないことも重要ですが、同様にエラーが起きた時の対応能力で、エンジニアの優秀さが計られるらしいのです。

大前提、エラーを起こさないことが大事です。優秀なエンジニアの方は、プログラミングコードを書く段階で潜在的なエラーを予測し、対策を講じます。また、仮にエラーが起きたとしても影響する範囲を限定的に抑えるための全体設計を行います。そして、一度(ひとたび)エラーが起きると、そのエラーが発生した根本原因を徹底的に分析し、同じエラーが再発しないような対策を講じます。

一方で、「優秀」とまではいかないエンジニアの方の場合、エラーが発生した後に初めて対処を始めることがほとんどで、予防的なエラー対応力は不足しがちです。また、エラーの記録や監視を怠ることも多く、問題が発生してから気づくまでに時間がかかることもあります。そして、エラーの修正に関しても、一時的な修正で終わってしまうことが多く、根本原因を潰していないが故に(ゆえに)何度も同じようなエラーが発生することになります。

いかがでしょうか。「優秀なエンジニアとは、エラー対応が上手なエンジニアである」ことが少しでも伝わったなら幸いです。同時に、この理屈はb→dash担当者にも当てはまります。優れた担当者とは、エラー対応に優れた担当者とも言えます。それでは、具体的にどのように対処していけばいいのかを見ていきましょう。

 

 

非エンジニアのエラー対応に必要なステップとは?①

まず最初にやるべきことは、『影響範囲の特定』です。※大前提として、エラーが起きたらまずは上司に報告しましょう。決して1人でどうにかしようとは思わない方が賢明です。

「影響範囲」という言葉に馴染み(なじみ)がない方もいらっしゃるかと思いますので、少し説明させていただきます。読んで字のごとくではあるのですが、何かしらのエラーが発生した際にどこまで・どれだけの影響があるかどうか、です。影響の広さで言えば、1つの分析や施策だけかもしれませんし、多数の分析・施策にまで及ぶかもしれませんし、売上にも影響があるかもしれません、顧客にまで影響があるかもしれません。また、影響の度合い(インパクト)で言えば、一瞬で回復可能なものかもしれませんし、復旧に1日・1週間かかるかもしれませんし、修復不能かもしれません。売上・顧客への影響についても、軽微なものから甚大なものまで様々です。

b→dashにおけるエラーには2つの種類があります。1つ目は、「b→dash自体のエラー」です。これはどのようなシステムを利用していても起きることです。マイクロソフトのサービスでも起きますし、Googleのサービスでも起きえます。2つ目は、「自社のみに発生しているエラー」です。前者については、b→dashの提供元が影響範囲やその後の対応を指示してくれますので、基本的にはそれに従うしかありません。一方で、後者については、b→dashのカスタマーサポートの方に協力を仰ぎながら自分たちで解決せねばなりません。

影響範囲の特定でやるべきことは3つです。「いつから」「どこで」「どのような」エラーが起きているかの確認です。b→dashには、エラー通知機能があるので事前に設定さえしておけば基本的にはタイムリーにエラーを検知することはできます。また、エラー箇所も、エラーが起きうる箇所に分けて通知設定をすることができるので、比較的特定しやすいです。あとは「どのようなエラーが起きたか」の確認です。こちらについても、使用しているデータに不備があるのか、データに対する処理に不備があるのか、など大まかなエラー類型は表示されますので、あとはその類型から推測し、実際のデータや処理を見ていくことになります。

この「いつから」「どこで」「どのような」エラーが起きているかの特定が済めば、あとはある程度影響範囲を特定することは可能です。

 

 

非エンジニアのエラー対応に必要なステップとは?②

次にやるべきは、『リカバリ方針の決定』です。

分析や施策、自社の事業、顧客などへの影響がはっきりしたら、その影響をどう解消するか=リカバリ(復旧)の方針を決めねばなりません。

エラーそのものや影響範囲が軽微であれば、起きたことは仕方ないとしてデータの不備・処理の不備を解消して終わりです。一方で、エラーそのものや影響範囲が甚大(じんだい)である場合は、どのように・いつまでにリカバリするかを決めていかねばなりません。また、リカバリが完了するまでの暫定(ざんてい)対応も決めなければいけません。一番やってはいけないことは、エラーにエラーを塗り重ねることです。リカバリをするつもりが、さらに別のエラーやミスを引き起こしてしまい、影響範囲を拡大させてしまっては意味がありません。従って、リカバリ方針の決定は慎重かつ、とは言え迅速に行わなければなりません。

この点について、事前に取り決めておくとスムーズなことがあります。それは「責任範囲の切り分け」です。
まず、代理店等の支援会社を活用しているケースの方がわかりやすいので先に説明します。支援会社を活用している場合、事前にエラー発生時の工数(費用負担)や賠償責任の方針をある程度決めておかれた方がスムーズです。とは言え、ここでも第4回でお伝えした「アジャイルの発想」を忘れないでいただきたいです。責任逃れをするつもりはありませんが、どんなに優秀なプロフェッショナルであっても「絶対にミスをしないプロ」はいません。元プロ野球選手で、守備の名手であるイチロー選手もたまにはエラーするものです。それなのに、「エラーを起こしたのは御社のせいだ!すべてなんとかしろ!」と言われたら、怖くて誰も支援なんてできなくなってしまいます。プロ(支援会社)はミスをゼロにするために雇うのではなく、「自分たちよりもうまくやってくれると思うから」雇うのです。そして、プロはプロである以上、責任を持って職務を全う(まっとう)しなければなりません。
次に、社内の従業員がエラーを引き起こしてしまった場合です。こちらも同様です。ミスしたことを責めるのではなく、ミスが発生しうる状態だった仕組みを改善すべきです。人を憎むのではなく、仕組みを憎まなければいけません。

 

 

非エンジニアのエラー対応に必要なステップとは?③

最後は、『原因の究明(および説明を果たすこと)と再発防止策を講じる』ことです。

一番やってはいけないことは、「わからないことをわからないままにすること、わかったふりをすること」です。これはb→dash自体にエラーが起きた時も同様です。b→dashに限らず、システムベンダーからはエラーや障害時には基本的には原因説明があります。そこで「ふーんそうなのか」で終わらせてはいけません。特に、支援会社はベンダーからの説明を右から左にクライアントに流すということは絶対にしてはいけません。

また、これはb→dashのプロジェクトオーナーや担当者の上司の方にも当てはまります。担当者の方や支援会社からの報告を鵜呑みにしてはいけません。理解できていないのに「わかった」で済ませてはいけません。確り(しっかり)と仕組みを理解し、腹落ちするまで細かく確認しなければなりません。「本当にそうなのか?」を繰り返し自問自答すべきです。そして、少しでもわからないこと・腑(ふ)に落ちないことがあるならば、何度も繰り返し説明を求めるべきです。

原因への理解がままならない場合、意味のある再発防止策を講じることは不可能です。原因が的外れであれば、再発防止策は必ず的外れになってしまいます。また、再発防止策も対処療法になってはいけません。=モグラ叩きになってはいけないということです。大切なのは原因療法です。1つのエラーから、「こういう場合は考えられないのか」「こういう場合はどうなるのか」というように事象を抽象化し、連想し、根本原因に対する再発防止を検討せねばなりません。そうしないと、もし100個のエラーの種が埋まっていた場合、100回エラーを起こさないとすべてのエラーの種を取り除くことができないからです。それは時間の無駄ですし、多くの痛みを伴います。

根本原因を理解し、適切な再発防止策を上司やベンダー、支援会社と共に練っていきましょう。

 

いかがでしたでしょうか?全12回の連載のうち、今回は『非エンジニアのエラー対応 まずは落ち着いてこの3ステップから』というテーマでお伝えさせていただきました。「やっぱり始めのうちは経験者の方にサポートしてほしい...」とお考えになった方は、ぜひumbrEllaに一度お悩みをぶつけてみてください。きっと何かのお役に立てるかと思います。

 

 

最後までご覧いただきありがとうございました。

「問題はわかったけど、じゃあどうしたらいいの?」と思われたかと思います。続きが気になる方は以下の資料で「明日から使える3つのアクション」を解説しています。ご興味を持っていただけた方は、ぜひお気軽に資料請求をしてみてください(しつこい営業は一切行いません。※同業他社の方からの資料請求はお断りしておりますので予めご了承ください)。

 

明日から使える3つのアクション

 

エラー対応のステップはわかったけど、

「じゃあどうしたらいいの?」

という方のために

明日から使える3つのアクションをまとめました。

ぜひ併せてお読みいただき、

日々のマーケティング活動の一助にしていただければ幸いです。