困った時の自分用メモ

読んだ本を考察してメモったり、自分でいじった物の感想をメモったりする場。週1更新を目指します。

考察〜伝わらない、コミュニケーション、認識齟齬2〜

10年業務をしてきて、ずーっと不思議に思ってきたことがある。
それは、口頭・文面問わずコミュニケーションを取っているにも関わらず、
双方が認識していることが合致していないケースが多発していることだ。

これは、新人・中堅・ベテラン・役職・男女に限らず発生している。

今回は、前回の記事での趣旨から外れていたが、考察に値する余談をまとめていく。

○仕様書の必要性
前回の記事では、人と人の間の認識齟齬をなくす為には、
実物を確認して細かく齟齬がないか確認を取るというアプローチを提案した。

その説明の中で
「仕様書を用意しても、読み手次第で認識は変わる」
という趣旨の記述をした。

これはその通りではあるのだが、それは

「どうせ認識の齟齬が出て、成果物だけ確認するなら、仕様書要らないね!」

とは、ならない。

○仕様書とは「意思決定」の書面化
作品作りは知らないが、製品作りをする際に必要な物の一つに
誰が、何を、何のために、どのように作るのかという
「意思決定」
というものが必要になる。

この意思決定がないと、作業をする側は、一体何のために作業をしているのか、わからなくなる。
誰がなぜこれを欲しいのか、わからないからだ。

この意思決定が、どういう経緯で成されたものか、
また、それを覚えておくために、一貫した内容を記述しておく備忘録の側面が

「仕様書」

というものには存在すると、筆者は考えるようになった。

 

この意思決定を、いついかなる時も違えず、相手の認識齟齬もなく口頭で伝えられるというのであれば、
仕様書は不要という意見も、少しは理解できる。
しかし、現実問題、そのような事ができる人間はこの世に存在しない。
理由は、前回記事で述べた通りだ。

なので、仕様書は作成する必要がある。

○仕様書とは、試験(テスト)を作るためにも必要
筆者は、システム業界の事は経験がないのでわからないが、
製品を納品する工程には

・顧客が欲しがっている製品の「要件」と、
・その「要件」を満たしていると判断する為の「試験(テスト)」

が存在すると聞いている。

この「試験(テスト)」を通らなかった場合、契約違反となるわけだ。

よく聞く、QA会社にテストをお願いしようとしたが、正しい挙動を示す「仕様書」がなくて正しい挙動かどうかわからないというのは、この問題に関係する。

「要件」を満たす為の動作を「意思決定」した人間が考えた通りに動いているか「テスト」をする事で、要望通りの挙動が確認できるわけであり
これができないという事は、即ちなぜこれが正しく動いているのかという根拠が示せなくなる。

そう考えると、前回の記事で提案した解決手法の1と2を使い分ける条件としては、
正しく動いているという根拠を、実動作レベルでの各所共有で納得いただけるかどうか、という部分に焦点が当たるように思える。

ゲーム業界は、「実動作レベルでの各所共有で納得いただけるかどうか」という仕事で比較的通りやすい風潮があるように感じるが、
システムエンジニアの知人から言わせると、「ヌルくて雑な仕事」と映るようだ。

なので、要件を満たしている根拠をテストで示す場合、仕様書が必要になるという事だ。

○作業指示する側(ディレクター)の苦悩
前回の記事の内容は、言ってみれば

・作業指示する側(要件を作って、それを伝える)と作業する側(要件を理解して、実装する側)の組み合わせ

の、認識齟齬をできるだけ減らそうといった趣旨の内容だった。
開発内部と言ったのは、現場レベルで発生する内容だったからだ。

では、その作業指示する側が要件を作る為には、何が起きるのかを少し話をしていく。

作業指示する側は、様々な縛りプレイを要求される。

まず、決定権を持っているのは「作業指示する側」の人間とは限らないという事だ。
この決定権を持っているのが「権力者」だった場合、苦悩が始まる。

大前提として、「権力者」の決定は絶対だ。
その絶対を覆したいのであれば、生半可な説得ではダメで、各種根拠に基づいたデータとメリットデメリットを提示した上で、
その権力者の人格や尊厳を失わないように考慮しながら、権力者が自分の意思でその変更の決定を行なった、という段取りを踏めるような手順を考える必要がある。
しかし、これは手段があるというだけであり、原則は覆らないと考えておいた方がいい。

パズルゲームのコマに、何の脈絡もない肉まんの絵を使わなければならないと言った事を受け入れたり、
株主の子供の名前を、ゲームのキャラが身につける衣類に記載すると言った事を受け入れなければならなくなる。

都市伝説のように感じるかもしれないが、事実である。

ディレクターは、この縛りプレイ条件を考慮しつつ、最低限製品としてに違和感を無くす為の要件を考える。

そして、一番防がなければならない事は、権力者to作業する側の直接のやり取りを阻止することだ。

権力者は、前回話した内容のうちの

「・さらに言えば、自分が伝えたいことが、自分で理解できておらず、自分の中だけでも間違っていて、さらに自分で気づけない」

に該当する可能性が非常に高い。これは経験則だが、非常に高い。
この理由は、彼らの能力がそもそも低いということも考えられるが、おそらく根本の原因は、彼ら「権力者」は自分の意思決定に向き合う時間が極端に少ないからだと推測される。

この人間が出した指示で作業をさせると、間違いなくおかしな物が出来上がる。
事実、出来上がっている(経験済み)

なので、ディレクターは権力者の日本語を、作業する側の人間が解読できる日本語に翻訳する作業が必要となる。

筆者は、今はこの理不尽な事象をどうにか普遍的な方法で対策が取れないか試行錯誤と考察を重ねているところである。

○まとめ
1. 仕様書は、意思決定の備忘録
2. 仕様書は、要件を満たしている証明をするテスト内容の記載
3. 1,2があるので、仕様書を作らなくてもいいという事にはならない
4. ディレクターは、好き好んでふざけた要件を要求しているわけではない可能性がある


最後の方は愚痴となってしまったが、こういう事は都市伝説ではなく実際に起こっている、つまり、あなたが一般的な会社に勤めていたとしても、上流工程では同じような事が発生している可能性があるという事を、考えの一つとして覚えておいてもらえれば幸いである。