アイロベックスメールマガジン　携帯版

土曜日、リーダークラスが集まるセミナーで、話をさせていただきました。

このときに「バグが出たときにどうすればよいか」といった質問が出て、そうだ、そのことを書いてないなあと、思い出したので、今週のネタが決まりました。

毎週、テーマに困っているので、本当に助かりました。

さて、プログラマでもSEでも、開発会社の技術者であれば、納品後のシステムで「バグ」が発見されたという経験はお持ちのはずです。

お客様から「困った声」で連絡があるときもあれば、いきなり、営業を通じて叱責の連絡が来ることもあったでしょう。

事態は様々ですので、一概には言えませんが、それでも、バグが発覚した場合の発言、行動から、お客様は、あなたという人間の誠実さを見るのです。

若く未熟なプログラマは、時に言ってはいけない言葉を発してしまいます。

「ちょっとしたミスです」、「すぐ直せます」

まず、当たり前のことですが、プログラマにとって、例え、「ちょっとしたミス」だとしても、「ちょっとした」とか「些細な」といった形容詞は、明らかにお客様に失礼な発言です。

一番最初にしなければいけないことは、「大変、申し訳ありません」と、お詫びすることなのです。

次に、「すぐ直せます」という言葉。
これは、相手が「どのくらいで直せるの？」と問われたことに対する回答であれば、問題はありません。

しかし、相手が聞いてもいないのに、最初にこういう言葉を発すると、「悪いと思っていない。直せばいいと思っているんだ」といった誤解を受けることもあるでしょう。

お客様が、システムに何か問題を見つけたときに考えることは、「すぐに直す」ことではないのです。

それは、このバグによって「何が問題になるか？」、「業務のどこに支障をきたすか？」、「システム全体に、どんな問題が潜んでいることが分かったか？」といったことなのです。

優先順位としては、
【1．お客様の取引先に迷惑が掛からない】
【2．お客様自身の業務に支障をきたさない】
【3. 問題が起こった原因を探る】
【4．問題をつぶす】
といった順になるはずです。

ところが、この優先順位の1、2を全く無視して、（お客様の視点で、物事を考えたことがないからだと思うのですが）問題の原因を探りたい、プログラムを直したい、という気持ちだけが先走るのが、技術者の悪習なのです。

原因を追究することよりも先に、これ以上の被害を出さないためには、どう運用を変えるのか？とか、最悪、システムを止めることさえも、技術者が、自ら提案すべきことなのです。

技術者は、何があっても、「システムを止めてください」と言わない、言えない人が多過ぎます。

バグが潜んでいるシステムを使い続けることは、お客様にとって、多大なストレスになります。

そういった意味でも、システム稼動後のバグ発見は辛い話です。
できれば、"バグゼロ"にしてシステム納品を行いたいものです。

しかし、人間が作っている以上、バグがあることは明らかであり、「予測できる失敗」なのです。
予測できることなのであれば、対処を考えておく必要があります。

対処を考える場合の優先順序こそ、お客様の視点で考えることが必要なのです。

何か問題があったときまず、お詫びする。

そして、お客様の視点で、「どうすべきか。どう動くべきか。どうアドバイスするか」を考えるのです。

若手エンジニアと、仕事のポイントについて話す機会がよくあるのですが、「顧客が言ったものを、そのまま作ってはいけない」とアドバイスすることが何度もあります。

若手エンジニアの特徴として、何でも顧客に聞いてしまうということが挙げられるでしょう。
一つ一つ聞いて、一つ一つの答えを貰ったら、その通りに作ればよい、と考えてしまう人が多いのです。

設計をチェックしていて、まずい部分をみつけ、「どうしてこう作ったの？」と質問すると、「お客様がそう言われました」と頑として退かない技術者もいます。

つまり、自分の頭で考えた結果ではない、プロとしてそれが良い設計なのか悪い設計なのか、必要なのか不必要なのか、といったことを考えないで、顧客が言った通りに設計した、というわけなのです。

ここには非常に大きな問題が潜んでいます。

それは、「顧客がどんなシステムが欲しいのかを、本当に分かっているか？」ということです。

技術者の質問に対して、顧客が答えるといったやり方では、本来の顧客の日常の全貌を、技術者が理解しないで作ることもあるのです。

また、一つ一つの答えを結びつけてつくったシステムでは、組み合わせに問題があることに気づかずに、運用がうまくいかないこともあるのです。

顧客が考えているのは、「相手は、なんといってもプロだ。分かってくれて、うまく作ってくれるだろう」
ということなのです。

ここを開発側がどれだけ分かっているかが、ポイントとなるのです。

顧客にOKを貰っていようとも、ドキュメントを確認して印を貰っていようとも、実は、本当のところ、どんなシステムが出来上がるのかは、顧客が分かっていないことが多いというのも、事実なのです。

顧客が望むシステムをイメージできていないとしたら、プロである貴方はどうでしょうか？

実は、貴方は顧客よりも、もっと、実現したシステムのイメージが無いのではないでしょうか？

だから、一つ一つ細かなことを全部顧客から聞かなければ、設計できなかったのではないでしょうか。

では、プロとして、SEとして、何を聞き出したらシステムをイメージできるのでしょうか？

何だと思いますか？

それは、顧客の業務内容、日常の顧客の行動パターンや思考パターン、課題・問題を含めた、日常の些細なこと全てです。

それらについて知っていなければ、システムをイメージできないでしょう。

システムを作るということだけを目的に、一つ一つを顧客に質問し、顧客に選択してもらって設計するという作業が、どんなに怖い作業かおわかりでしょうか？

貴方は、顧客の何を知っているのか？

システム設計者に求められる最終的な責任は、そこだと思うのです。