相手も人間だと理解することの重要性

先日、漫画のドラマ化に関連し、原作者さんが亡くなりました。
物語をどれくらい原作通りにするかを巡ってトラブルがあり、『自身で現場に入る』という選択をして相当な無理を重ねられたようです。

この事件を巡っては様々な意見が出ています。
が、一部の原作者の立場の方から、ちょっと気になる声明が発表されることがあります。
「原作者はとても苦労して原作を作っている。だから黙って従え」

まるで、『芸術家でいる権利は原作者だけのもの』と言わんばかりです。

もちろんあくまで極論するとこういう言い方になるだけで、ご本人はちゃんと理論武装もオブラートに包むこともできています。
なので彼らが社会人として問題があるではありません。

また、このような考え方の人は別に彼らだけでなくどこにでもいるもので、我らＩＴ業界にも方々で見かけます。
それどころかフィレンツェ十賢者の１人たるミケランジェロですら、「芸術家は世界にオレ１人でいい」という言葉を残しています。

彼らはなぜ、こんな極端な主張をするのか。
そこには、『人間は《他人》という概念を、実は正確に理解できていないのではないか』という仮説が潜んでいるように思います――。

いつもお読みいただきありがとうございます。
または初めての方も、この記事を見つけてくださって嬉しいです。

私は、システムの開発事業に携わる、エンジニアの中島と申します。
この 絶対バグらないシステム作ろうぜの会 では、バグの出ないシステム・問題を起こさないチーム運営のやり方などを、なるだけ面白く・分かりやすくお伝えする主旨で記事を配信しております。

今回は、取引の際に、他人という異なる意見を受け入れることの重要性について。

1. 相手の権利を尊重する ＝ 相手を人間扱いする

今回亡くなった原作者さんを巡っては、何名かの漫画家さんが「あくまで原作通りを貫くべきだった」という意見を出してらっしゃるようです。
それらについては、それぞれが個人の意見なので主張するのは別に問題ないのですが、一部『芸術家でいる権利は関係者全員にある』という意識が薄い人がいるのがちょっと気になります。

もちろん、著作権法には《同一性保持権》という権利が存在しており、原作者は、メディアミックスされた翻案物が原作通りかどうかをチェックする権利を持つとされています。
そうでなくても、原作が曲解された挙句、言ってもいないことを「あいつ、あんなこと言ってた」と視聴者に伝わったのではたまったものではありません。

ですがそれ以前の問題として、「想いを表現したい」という欲求を持っているのがプロの芸術家だけじゃないことは、考えた方がいいのではないでしょうか。
原作者に表現したい想いがあるのと同じように、それをメディアミックスする側にも表現したいものがあります。

そしてその２つは、常に必ずそれぞれ別物です。

これは「おしゃべりしたい」「分かってほしい」「良い評価を受けたい」といった類の本能と全く同じ。
人間としての基礎欲求の１つであって、法律なんかよりよっぽど根幹的なものです。

そんな根本欲求を「それはオレだけのもの！」なんて主張したら、そんなのトラブって当たり前なんです。
そんなこと言うから “原作者 vs その他大勢” なんて極端な構図ができあがります。

このようなトラブルを防ぐには、原作者は自分が同一性保持権を保持していることを理解しつつ、なおかつ、その権利を濫用しない意識も同時に持つことが重要です。
なぜなら『他人の心から生まれたキャラクターは、たとえ原作そっくりでも他人の子』だからです。

他人の子を、自分の子と全く同じように動かそうってんだから、メディアミックスにおける『原作通り』ってのは、原作者にとって文字通り曲芸です。
原作者がそれを納得・了承できないのなら、そのメディアミックスは今後止めた方がいいかもですね。
みんなが不幸になるだけです。

これは言い換えれば『他人に表現権があることを納得できるか？』、
突き詰めれば『あなたは他人という概念を理解しているか？』と聞いているのと同じです。

なぜなら、表現する権利は全ての人が平等に持つ権利だからです。

2. 意図しない改変を防ぐ方法

さてさて。
当記事は社会批判ブログじゃなく、あくまで単なるエンジニアブログですので、ここいらで話をＩＴの方向へ戻そうと思います。
（無理やりグイッと）

原作者と現場の対立構図はなにも漫画のメディアミックスのときだけでなく、システムエンジニアリングの発注のときにもしばし起こるものです。
開発者と意見が噛み合わず意図しない製品が納品されてしまうことは、ＩＴ関連の発注者にとっては日常茶飯事のことかと思います。

「オレはこうしてほしいのに理解してくれない！」
そんなトラブルがなぜ起こるのでしょうか。

その理由はごくシンプル。
“同意すべきプレミスポイントがあまりに多すぎる” んです。

プレミスポイントってのは小説用語で『ようするにやりたいこと』です。
つまり『絶対に改変されるべきでない、確実に守ってほしいポイント』。

小説の書き方の本とか読むと書いてあるんですが、このプレミスポイントは１商材（１作品、１製品）あたりの数に限界があって、それは “１つ” のみ。
絶対に１つキリであることが大事。

• 勇者が料理テクで魔王を篭絡する物語の映画

• ＳＥＳ事業の日常業務を集約するWebシステム

• 我が社のフランチャイズ事業を運営する社内システム

• 靴のように気軽に履けるモビリティグッズ

などなど。
世の中には数々の製品がありますが、その設計を行う際に、まず最初に発想される根幹部分がそれに当たります。

どんな製品でも、その根幹となる “ようするにやりたいこと” は、いつだって１製品につき１つきりなんです。
というより人間としての限界として、そもそも１作品に２つ以上のプレミスポイントを入れるのは不可能です。

世の中には製品が出来上がってからトラブルになるケースは多いです。
が、その中でも「言った言わない」の問題に発展しやすいのは、発注者・開発者のどちらかが、大量のプレミスポイントを相手に押しつけすぎた場合です。
人間が人間である以上、絶対に守ってほしいポイントが１０個も２０個もあったところで、守れるわけがありません。

なぜなら “こうしてほしい” というポイントが複数あると、そのプロジェクトが長くなればなるほど、ときどき競合するからです。

たとえば「物語が主人公の長い人生の一部であることを、きちんと描写してほしい」というポイントは、「ドラマとして結論をつけなければいけない」というポイントと、ときどき競合します。

同じように、「プログラムは高速に動くように作ってほしい」というポイントが、「不具合がないように堅牢に作ってほしい」というポイントと競合することもあります。
システムの高速性と堅牢性は、ときに両立不可能となるんです。

なおかつ、その２つのポイントが両立不可能であることが、プロジェクトが十分に進んでから判明することもあります。
そうならないためには、一見すれば共存可能なように見える部分も含め、あらゆるポイントにあらかじめ優先順位を付けざるをえません。
製品の中にある《ポイント》なるものは、『この２つはどっちも大事』が基本的にありえないことになるのです。

従って、製品の “もっとも重要なポイント” も、常に必ず絶対に１つきりになるんです。

そしてそれを理解できない人がいるかぎり、今回のような事件は何回でも、どんな業界ででも起こるんじゃないかなと、私なんかは思うわけです。

ではまた。