事例をもとにした不具合考察 その１
いずれそのうち、こういうのしてみようと画策していましたが、ちょうどいい感じにネタがあったので、触れてみたいと思います。
すいません、ゲーム自体は未経験者です。
スマホゲームですかね。なんか人気みたいです。ゲームユーザーから見たら完全部外者の私ですが、あくまでＩＴ的な「不具合」が起きる傾向や分析のネタにしているだけなので、ゲーム自体を「知ったか」するつもりはありませんのでご安心ください。
状況の整理
さて、そんなゲームが２周年を迎えて少々大きな不具合を起こしたそうです。ざっと情報を拾い集めた感じでは
現象：あるキャラクターのスキルが想定していた以上の効果を発揮し、
ゲームバランスを崩しかねない結果となった
…ってことでしょうか。
また、その発見までにずいぶん時間がかかってしまっていたようです。
まぁ、「止まる」とか「重くなる」とか、システム運用そのものにダメージ与えるような「エラー検知がされる」とかじゃない場合、ビジネス向けシステムでも意外と発見できなかったりするものです。特に当事者は「あってるはず」と思い込む傾向が強いため、思い込みを持たない第三者でなければ、発見が難しい側面があるのも事実です（それをたやすく検知するチェック方法もあるにはあるのですが、やりたがる人はあまり見かけません）。
そして、その原因はと言うと
一言でいえば仕様通りの設定が行われなかったというミスです。
また、確認不足もあります。
そして、発覚後に分かったことですが 、仕様書や内部資料に曖昧な点があり、担当者間でも一部認識に齟齬がありました。そのため、リリース前に行う動作チェックにおいて、発動する効果の大きさについては、問題がないものとして通ってしまいました。
チェックをする側のメンバーに正しく情報が渡っていなかったことも、事態を防ぎきれなかった要因のひとつです。
と書かれていますね。シンプルで、客観性があり、かつ事実重視で主観が含まれていない点に好感が持てます。要旨をまとめた「報告」とはこうあるべきですね。
純粋な成果物品質に関する不具合の中で、私的には最も多い原因ではないかと思います。一般的にどういうかはわかりませんが、この手の問題はすべて
一人ひとり、コミュニケーションレベルには差異があるはずなのに
そのことを想定したプロセス運営や、成果物様式になっていなかった
ことが技術的原因ではないかと私はみています。
いつも「自然言語」の影が見え隠れする
どこの言葉でもそうなのですが、自然言語（人間によって日常の意思疎通のために用いられる言語）で文書化された資料は、
・"送り手"の表現力と"受け手"の読解力に差があった
・主語や目的語の省略を用いた
などと言う場合に、送り手と受け手の情報共有に齟齬が起きやすいことがわかっています。特に前者は、
表現力 ＜ 読解力：送り手が伝えるべき情報を100％伝えられない
表現力 ＝ 読解力：同じレベルでコミュニケーションが成立する
表現力 ＞ 読解力：受け手のレベルが低く、100%伝わりきらない
ことが容易に想像できます。自然言語を多用すること自体が、不具合の温床になるのです。だからこそ、ＩＴの世界ではＵＭＬ（Unified Modeling Language：統一モデリング言語）と呼ばれるダイアグラム（図）によってコミュニケーションを図る方法などが提案されていたりもするわけです。マトリクス図やデシジョンテーブルを用いることも推奨されていたりしますね。
特に、昨今では老若男女さまざまな世代で、「長文」を忌避しようとする人もいます。ＳＮＳなどが普及したせいですかね。Ａ４用紙１枚分の文章を読むことも嫌がるような人が非常に多くなっています。
情報を100%発信しないと、受け手は100%理解することは難しくなると言うのに、「長文になる」「読むのが面倒」と言うだけで、『斜め読み』しかできない人や、そもそも『読まない』と言う人も出てくる始末です。
これでは、コミュニケーション不良が起きるのは当然です。
今回、「仕様書や内部資料に曖昧な点があり」とありましたが、"曖昧"の一例として「目的語を省略した場合」などは、正しい仕様説明文が次のとおりとすると、
（正しい仕様）
・覚醒スキルにおいて、1回のバレットによる攻撃に1個分のバレット効果がのり、バレットの所持数に応じた単体の1回攻撃が対象をランダムに最大10個分行われる。
たとえば、仕様書上に
・覚醒スキルにおいて、バレット攻撃がランダムに最大10個分行われる。
とだけしか書かれていなかったらどうでしょう。
エンジニアは、「なるほど、こういうことか」とイメージし、
（現在の誤った実装）
・覚醒スキルにおいて、1回のバレットによる攻撃に最大10個分のバレット効果がのった連続攻撃が対象をランダムに最大10回分行われる。
と解釈して、作りこんでしまう可能性もあるわけです。
大事なのは「誰がやっても同じ」結果となる仕組み
「 また、確認不足もあります」という説明も書かれてありましたが、仕様書の段階で誤解を与えるような表現が含まれていれば、テストエンジニアが実装するエンジニアと同一人物となっている場合や、あるいはテストエンジニアと実装エンジニアが同じレベルの読解力だった場合、不具合であると気づけないのは当然ですね。
かと言って、上位の仕様決定者（有識者）だけに押し付けて、すべての機能においてチェックさせるなんてことは現実的に不可能です。
だからこそ、「誰がやっても同じ結果になる」…この場合は「誰が読んでも同じ解釈になる」仕様書や設計書を作るようなルールやプロセスが必要なんです。
古くから何も変わらない
こうした不具合は、本当によく起きます。
私がストレートで入社した1996年時点ですでに多発していましたし、そのちょっと前に大きく変化したなんて話を聞きません。おそらく３０年以上は変化していないのではないでしょうか。
私自身が経験してきた２０数年の中で、対応してきた数々のトラブルプロジェクトや製品不具合対応などでも、おそらくは半数以上がこの
コミュニケーション差異による認識齟齬
が根本的な原因でした。手を変え、品を変え、経緯は色々あったと思いますが、突き詰めると毎回同じ結論に行きつきます。「私に変更する権限があれば、すぐにでも変更してやるのに」と言うのは、最低でも10年以上思い続けてきたかもしれません。
ですが、多くの企業が「仕様書」「設計書」の大半を、自然言語を書き連ねるだけのものとして利用するところが多く、
・「てにをは」などの助詞の乱用
・関係代名詞（こそあど言葉）の多用
・（主語や目的語など）文章の省略
・形容詞を用いた曖昧な表現
によって、今もどこかで不具合が作りこまれているかもしれません。
この手の問題はなかなか解決が難しく、開発プロセスや企業ごとにあらかじめ用意されている仕様書／設計書などの定型フォーマットが見直されない限り、同じような問題はなかなか減らないと思います。
残念ながら、私が現在所属している会社ではそうした定型フォーマットは存在しておらず、また現場のエンジニアたちは過去に利用したプロジェクトの資産を使いまわそうとします。私自身の力及ばず、いくら指摘しても、目先の「手間」や「負担」を嫌って改善されることはありません（気持ちはわかるけど、トラブっても呼ばないでね？）。
一部の大手SIerのマネージャーさんにも、参画してきたプロジェクトをきっかけに何度か提案したことがありますが、鼻で笑われたり、苦笑いされるだけでした。
いきなり全てを完璧に解決するような時間も予算もないでしょうから、私もそこまで言いませんが、過去に発生した問題個所から、徐々に改善していけばいいのに…といつも思っているのですが、なかなか受け入れられることはありません。
不良が減れば、ユーザーはうれしい。
不良が減れば、緊急対応などで生活が安定しないエンジニアも減る。
不良が減れば、生産性があがる。
不良が減れば、余計なコスト消費も減る。
いいこと尽くめのはずなので、あまり面倒くさがらず、この現場では柔軟に対応してくれるといいなー、と心から思います。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。