IT訴訟解説筆者が考える「セクシー田中さんドラマ化」問題と破綻プロジェクトの共通点――原因と再発防止案は？：「訴えてやる！」の前に読む IT訴訟 徹底解説（115）_特別編（3/4 ページ）

IT訴訟事例を例にとり、システム開発にまつわるトラブルの予防と対策法を解説する本連載。今回は特別編として、IT紛争の回避と解決のプロフェッショナルであり、IT小説のクリエーターでもある細川義洋氏が、「セクシー田中さんドラマ化」問題を解説する。

[ITプロセスコンサルタント 細川義洋，＠IT]

トラブル発生時に必要なふるまいと、コミュニケーションの重要性

　本作の場合、企画段階での話し合いは持たれず、ズレた意識の修正がないまま、脚本の執筆が開始されました。この段においても、やはり話し合いの不足が影を落とします。原作者と脚本家の意識とズレと、そこからくる不信感です。

　報告書を読む限り、原作者と脚本家は対面することなく、その意思伝達はテレビ局および出版社の担当者によって行われました。脚本家は、原作者の意図や大切にしたい思いを受け取ることなく、テレビ局の意図に従って執筆を続けていったようです。その結果、脚本は原作者の意図とはズレたものになりました。

　原作は、朱里が田中さんと過ごすうちに徐々に自らを囲む枠を超えて新しい自分を獲得する様をさまざまなエピソードで描きますが、そこには順序も必要です。人の心が徐々に変わっていくエピソードですから、最初は小さく、徐々に大きくといった展開が必要です。これを心が変わっていく過程ではなく単なるエピソード集と捉えて、順番を変えたり、新たなエピソードを加えたりすると、原作の意図が壊れかねません。

　ドラマと漫画を見比べると、確かにエピソードの順番が変わっています。もっとも、ドラマは原作者の要望でかなりの部分を修正した脚本を基に制作されましたので、放映された部分にある変更は原作者の許容範囲だったのかもしれません。

　ただ報告書には、大量の変更要望を出さざるを得なかった原作者が脚本家への信頼を失い、また疲弊しながら、9、10話を自分で書かざるを得ない状況に追い込まれたことが記されています。脚本家も、度重なる修正に疲弊した上で、自身の脚本は途中で打ち切られ、クレジットにも名前が載らない（9話）という屈辱を味わいます。結果、脚本家が不満をSNSに投稿し、原作者を深く傷つけたことは周知の通りです。

　やはり原作者と脚本家が直接対面して、原作意図の共有と各場面に込められた思い、ドラマ化に当たっての制約なども含めて話し合うというプロセスが必要だったのではないでしょうか。

　IT開発でいえば、ユーザー企業とベンダーが頻繁に対面しながら徐々にモノを作り上げていくアジャイル開発に似ているでしょうか。無論、アジャイル開発は、多くの場合、ウオーターフォール開発と比べてユーザー企業の負担が大きくなる開発方式です。脚本の執筆についても、頻繁に面談することは、原作者にも脚本家にも負担がかかります。

　加えていうなら、私も含めたモノを書く人は、執筆中にいろいろな注文を受けることが嫌いですし、自分の作品を他人によっていじられるのも良い気分ではありません。

　しかし、そこでは前述した「みんなで新しい作品を作る」という意識が大切に思えます。自分も参加して新しいモノを作るという意識であれば、おのおのの負担も必要な役割分担であると思えますし、結果として、原作の意図とテレビ化の意図がうまくマッチした良作につながるのではないでしょうか。

　今回のように原作者と脚本家が直接会話をせず、テレビ局や出版社の担当者が間に入るやり方は、あまり良い方法とは思えません。これがドラマ制作の当たり前だとすれば、変革が必要なのではないでしょうか。

　報告書によると、テレビ局の担当者は脚本制作の最終段階まで原作者が込めた意図を理解していなかったように思われます。

　本作は脚本執筆段階ではまだ完結しておらず、終盤はドラマオリジナルの脚本となることは最初から決まっていました。最終的に脚本家は外され、原作者が脚本を書くことになったのですが、その前にテレビ局からストーリーの提案がありました。朱里が最後は、田中さんと同じベリーダンサーになるというものでした。

　原作者はこのストーリーを受け入れられませんでした。作品の意図からすると、朱里は自分の周りにあった枠を超えて新しい世界に飛びこむことが必要です。しかしベリーダンサーになるのでは、単に田中さんに憧れて後を追っているだけに見えてしまいます。

　私見ですが、これでは“新しい世界”が薄まり、モヤモヤから一歩抜け出すという大切な部分が理解されづらくなるのではないでしょうか。この提案は、作品に対する理解不足だと私は感じました。

　これは、テレビ局や出版社の担当者の能力の問題ではありません。企画から執筆に及ぶプロセスにおいて、原作者の意図を反映させたり、原作者の理解を得るように努力したりしない、これまでの慣習が原因だと私は考えます。

　ITのアジャイル開発はその時々の状況に応じてさまざまな機能が付け足されたり、削除、変更されたりしながら進められます。その結果、当初想定していたシステムとは全く違うものになることも珍しくはありません。

　ただその際にも、変えてはいけないものはあります。それは「開発が完了したときの新しい業務の姿」です。システムの機能はどうあれ、「今までは会社でさまざまな業務を行っていたが、今後はリモートでどこにいても業務をできるようにして、皆のライフスタイルが改善する」というような夢は譲ってはいけないわけです。

　この夢が実現できるなら、システム実現方法は会社のPCにSIMを入れるでも、スマホを業務に使えるようにするでもよいわけです。ドラマの脚本がどう変わっても、その意図するところは変えない。そうした考えはとても大切です。設定やストーリーを変えても、朱里がそれまでの枠を破ってモヤモヤ感を払拭（ふっしょく）することが大切という線だけは外せないと原作者が考えていたのと同じです。