年単位でプログラムまともに書いてませんが、気分だけは今でもプログラマだと言い張り続けています( ´ ▽ ` )ﾉ

プログラムといえば、バグはつきものというか…

基本的に人間が書いている物なので、ミスもあれば勘違いもある。

プログラムのXX行にYY個はバグがある、というのは実際の所正しいと思っています(^_^;)

そんな中で、いざバグが見つかったとき、所謂BTS(Bug Tracking System:バグ管理システムなどで管理される事になるわけですが…

その中身というのは、大体「事象」や「原因解析結果」や「その対処方法」などを取りまとめて管理することが出来るようなテンプレートになっていることが多い。

これはバグに限らず普通に「失敗した」という時の汎用的な対処法として良いと思う部分もあるわけなので、ちょっと紹介してみようかなと( ´ ▽ ` )ﾉ

ということで、三つほど纏めてみました。

1. 言い訳をしない

バグが発生したという「事実」は、動かし様が無い訳です。

なので、それに対して言い訳をするのは、それを考える時間なども含めて、単に無駄な時間でしかありません。

逆に、変に言い訳したところで、相手の心証が悪くなるだけでメリットは皆無と言って良いでしょう。

なので、発生した事象について、単に「何が起きたのか」ということを冷静に分析すればよいかなと。

起きてしまった事は変えられる物では無いので、そこに気を使いすぎる必要は無いわけです( ´ ▽ ` )ﾉ

# でもここで、メールや文書などの客観的に判断してもらえる記録が残っていて明らかに「事実」が間違っている、というのであれば、それは言い訳ではなくて証明になるので、ガンガン反抗してしまいましょうｗ

2. 「何故」そうなったのかを分析する

発生した事象には、必ず理由が存在します。

何も考えて無かった(気づかなかった)から必然として問題が起きた、とか、何か考えていたけど誤っていた、という様な形でパッと思いつく物があると思います。

ここで後者の場合は考えていた事があるはずなので自明です。

ただ、前者は「考えていない」というのは理由としては正しくない。

この場合「考えなくても良いという決断」をしたという主体的な理由があるはず。

ここで理由を分析する場合、「何故？を繰り返し考える」という方法が有名だと思いますが…

• 問題が起きたのは何故？→思いつく理由(1)を考える
• その理由(1)になったのは何故？→思いつく理由(2)
• その理由(2)になったのは何故？→思いつく理由(3)

…キリがないので、三つだけにしておきますがｗ

結構繰り返し考える事で、少しずつ表面的に現れた最初の事象から、根本的な原因(3)に近い物が見つかるらしいです(たしか)

ポイントは「(1)になったのは(2)だから」→「(2)になったのは(1)だから」というような無限ループになるような思考をしないこと。このループに嵌った時点で、何かがおかしいので、この場合では(1)の理由が実はおかしな方向に突き進んでいるはずです。

3. 「どのように」やれば上手く行くというシステムを作る

「失敗しました→次は頑張ります」では何も解決しないのです。

人間には限界があるので、頑張るだけではどこかで破綻します(^_^;)

なので、頑張らなくても上手く行くような仕組み作りの方が大切だと思います。

僕はあまり朝が得意ではなく、よく遅刻を繰り返していた訳ですが…

対処法として「目覚まし時計を一個増やす」とか、「目覚ましの置き場を枕元→布団から出ないと行けない距離に移動する」などの、具体的な対処方法を考えてましたｗ

ここで「頑張って早起きする」と言ったところで、上司に怒られる回数が増える以外の対策にはならないわけです。

自分が頑張らなくても(目覚まし時計が頑張ってくれる)仕組み作りを優先した方が、対策として有用です( ´ ▽ ` )ﾉ

# 「目覚まし5個くらい掛けてるのに、起きられないんですよおおお」と上司に上手く言えば(※)、怒られるどころか「最近疲れてるのか？」と心配され、早く帰らせてもらえる理由に早変わりするかもしれません (妄想ですが)

まとめ

要するに、5W1Hのテンプレートから

1. What
2. Why
3. How

の三つだけを取り上げている形になっています( ´ ▽ ` )ﾉ

5W1Hのテンプレートは非常に汎用的ですが、上記以外の、いつどこでだれが(When/Where/Who)というのは、責任逃れするときに使いたくなる単語でしかなく、実際の所余り問題解決には役に立たないと思うわけで(^_^;)

蛇足

上記の三箇条はある程度汎用的に応用できるかなと思うのですが、それ以外にも何かと便利な考え方を蛇足としてご紹介( ´ ▽ ` )ﾉ

4. 可能な限りTATは短く

何か起きたとき、例えば一週間近く放置してから回答するなど、無駄にTAT(ターンアラウンドタイム)を長くするのは危険です。

それをやるなら、とりあえずの一次回答で良いから、出せるレベルの報告は早めに出す事を意識すると相手も安心できます。別に回答は一度に纏めなきゃいけないということはないはずです。

# 内容の薄い一次回答を頻繁に出す、などは逆効果なのでバランスは必要ｗ

5. 同じ事は繰り返さない

バグとは言え人間のミスなので、同じ様なバグはどこかにある or 今後発生しうるものであるというのが前提です。

もちろん、上記の3番で今後発生しないようなシステム作りを意識しておけば起こりづらくなるわけですが(^_^;)

地味に大切なのは、前者で「同じ事をどこかでやっているかもしれない」という視点を持つこと。

折角の「機会」なので、一度問題事象を水平展開して、同じ様な事をやっていたという事を振り返るのもいいのではないかなと( ´ ▽ ` )ﾉ

# どちらかというと余りロジカルな方法論というよりも精神論なので蛇足ｗ

- スポンサードリンク -