バグだ仕様だ戦争に終止符を。

ボス:「バグだ!一覧で3枚目の写真がない。すぐ直して!」
エン:「いえ仕様です。そこスマホ考慮しての制御なので。」
ボス:「え?そんな指示してないよ。」
エン:「いえ、されてます。なので仕様です。」
ボス:「でもおかしいじゃん。見たらわかるでしょ。」
エン:「うーん、そうですか?でもそういう仕様なんで。」

バグだ仕様だ戦争
巷でよく見かける不毛な言い争いです。事実がそうである限りそれがバグか仕様かはどーでもよくて、より良くするための議論に時間を割くべきところです。


拝啓、非エンジニアのみなさまへ

非エンジニアの皆さんにまずお伝えしておきたいことは、「バグ」という言葉の攻撃力の高さです。しかもそれは「ロトの剣」ではなく「もろはのつるぎ」です。ダメージは自分にも返ってきちゃいます。

全ての仕様を把握するのは難しいですし、自分の思った通りの挙動になってないことを報告するのは問題ありません。少なくともユーザー視点のUXフィードバックですから、改善につながる発見もあることでしょう。
しかし、「バグ」という言葉はいたずらに開発者を傷付けてしまいます。

経験上、バグだと報告されるもののうち、本当のバグは半分もないくらいです。下手すると完全にその報告者の勘違いなんてことも。報告する前に、まずは本当にバグなのか、自分の思い違いじゃないかをよく確認した方がいいと思います。

そして報告する段に至った場合におすすめしたいこととしては、「バグ」という言葉は使わないことです。

わかりやすく例えると、素人がガンですって言うようなもんだからです。プログラムコードの中に悪意ある挙動をする異物が混じっているという意味合いでは合ってるんです。ただ、医者でもない素人がガンを識別することはできないんです。

つまりバグという単語を使っていいのは、ガンを見極められる人。
環境依存なども含めて十分な検証ができ、再現手順を示すことができ、原因の推測と改修箇所のあたりまで付けられるほどに仕様を把握できている人です。エンジニアもしくは仕様を把握しきっているプロマネなどに使用が許されている、それがバグという言葉なんです。

繰り返しますが、報告するなとは言ってません。報告することは良いことです。ただ言い方に気をつけた方がいいという話です。

「申し訳ないけど、ちょっとおかしな挙動に感じるので確認して欲しい。」といった切り出し方であれば、エンジニアサイドも心やすらかです。その人に対して「いえ仕様です」といった返しはしないでしょう。エンジニアにはまじめで優しい人が多いですから、攻撃しなければ仕返しもされません。

【非エンジニアのみなさまへ贈る標語】
・不具合報告は積極的かつ気遣いを忘れずに
・「バグ」という言葉の封印


パグ
これはパグです。濁点が丸に変わるだけで和みますね。


拝啓、エンジニアのみなさまへ

そうだ!そうだ!と思って読んで頂いていたエンジニアの皆さま、お待たせしました。エンジニアの方にもお伝えしたいことがあります。

開発の都合も知らずに勝手な機能ブッ込んできやがって言われた通りやるけどどーなっても知らんからな!という投げやりな気持ちで指示通りに実装しちゃったことはありませんか?
そこまで悪意を持ってやらないとしても、最終型に思いを馳せず実装した後の検証段階でイケてない状態に気付いたけど、仕様通りだしそのままステージングにデプロイしちゃえーってことはありませんか?

もし指示が来た時に気付いたのならツッコミを入れるか、もしくは、確実に良い案があるのであれば自信を持って思いやり実装したいところですね。もちろん判断に困る場合は依頼者に確認を行った方がいいです。いずれにせよ途中のひと手間をかけるだけで、その後の流れが随分変わって出戻りも少なくなるはずです。

気付いたがあえて言わず、悪意をもって指示通り実装してしまう方もいるかもしれません。そういう精神状態になってしまった背景があるのだと思われます。

仕様どころか要件定義もままならないまま要求だけを伝えられ、せめて要件を固めようとして質問を返しても面倒がられ、仕方ないので想像を膨らませて実装したら思ってたのと違うと怒られてうんざり。そんなことがあったのかもしれません。
そりゃプロダクトへの愛情もすり減ってそういう態度になってしまいますよね。よくわかります。

しかしあなたがまだ愛情を失っていないなら、プロジェクトマネージャーに全部ぶちまけてみることをおすすめします。良いマネージャーであればチームに適切な処方箋を出すでしょう。そうでないなら、そのまま続けても絶対に幸せになれないので他所へ行くことをおすすめします。不遇でもプロダクトへの愛情を失わず戦える素晴らしいエンジニアであるあなたは引く手あまたです。

【エンジニアのみなさまへ贈る標語】
・気付かないフリはやめよう
・プロダクトへの愛情は捨てない


バク
これはバクです。濁点を抜いたら毒気も抜けました。でも夢は食われてはいけません。


背景、ディレクターのみなさまへ

非エンジニアでもありエンジニアでもある。そんな中間の位置でプロジェクトに参加するディレクターの皆さまに向け、最後に少しだけ書いておきます。

途中でも書きましたが、バグだ!と報告が上がってくるものの多くはバグではありません。どちらの立場でもあるディレクターの方であればこの肌感がわかると思います。

バグと呼んでいいものは2割くらい。発見者の勘違いや環境依存などが2割くらいで、残りの6割は認識齟齬や考慮漏れなどによりUXが良くない実装になっているもの、といった感じではないでしょうか。

報告段階で「バグ」という言葉を使わないことで、戦争に突入することは最低限回避できると思いますが、それ以前にできるだけこういった報告を減らす努力もしたいものです。

そのためにやるべきことは非常にシンプルで、エンジニアに意図や目的など要件以外の情報もしっかり伝えることです。

新機能の追加や改修についての指示書はきちんと届くが、その意図や目的、将来展望などは届けられないケースが多いです。企画側からエンジニアまで伝達されるどこかの段階でそのあたりの情報が欠けてしまうのです。そこにあるのは悪気ではなく、必要最低限の情報を伝えた方が良いだろうという配慮かもしれません。

実装前に周辺情報までしっかりと伝わっていると、アウトプットの精度は自然と上がります。もちろん、付加情報を入れたことで、エンジニア側の最初の仕様の読み込みや設計の時間が増えたり、ディレクターに対しての質問が増えたりするかもしれませんが、そこでかけた時間は無駄にはなりません。

認識齟齬や考慮漏れなどは少なくなるはずで、結果的にトータルコストも下がりますし、当然ユーザーにも喜ばれるプロダクトになるはずです。

仕様面の話ではないですが、「とにかく急ぎで!」という指示もイマイチです。少し情報が足りません。
なぜ急ぐのか?その理由や背景まできちんと伝えたいものです。やるべき理由が明確になれば気合入れて早く仕上げようとしてくれます。なんのために急ぐのかもわからいまま急かされたらイラっとして当然です。

かくいう自分もディレクターのポジションで動くことが多いので、この辺りは常に頭において立ち回るようにしています。特に自分がよく知っていることは相手も知っていると思い込んで共有がうすくなったりしてしまいがちですからね。

【ディレクターのみなさまへ贈る標語】
・100%の理解と100%の依頼を
・面倒くさいことほど喜んで巻き取る



どんなプロジェクトもコスパを要求されますし、所詮は人間がやることです。完璧なものができあがることなんてまずありません。チーム内でバグだ仕様だと罵り合う不幸なプロジェクトを世の中から減らすために、そこに参加する全員で少しずつ歩み寄りながらがんばりたいものですね。

ハグ
これはハグです。

  • 2017-08-16 23:03

© 2014 watanukikikaku, ltd.

※四月一日(わたぬき)の読みの由来は、4月が綿の収穫時期だから説、衣替えで綿を抜くから説など、諸説あります。