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

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

　ところがドラマを制作する日本テレビの企画書には、本ドラマの企画ポイントが以下のように記されています。

1. “自分を縛る呪縛”から解放されたときのカタルシス
2. 真反対なふたりの女の友情がスゴイ！
3. 9笑って、1グッとくるドラマ
4. あらゆる世代に響く！　60代専業主婦の第一歩
5. 田中さんと笙野の恋の行方は!?？

　「自分を縛る呪縛」は一見、原作者の意図と重なるようにも見えますが、そこで描きたいものが「カタルシス（恍惚〈こうこつ〉感）」であるなら、原作とは異なります。むなしい毎日を送る女性がベリーダンスのもたらすカタルシスに浸るというのは、確かにありそうな設定ではありますが、漫画の「セクシー田中さん」にはそうした場面はないように記憶しています。

　もっと気になったのは、「9笑って、1グッとくる」です。前述したように原作の最も大切な部分が朱里や田中さんの中にあるモヤモヤであるなら、9と1の間にそうした思いを入れ込む隙間はありません。そういうものは排除して、日曜日の夜に家族で見るのにふさわしい、楽しくてちょっと泣けるドラマにしたいという意図を感じます。

　もしも企画段階で原作者と出版社がテレビ局と納得いくまで話をしていたら、このズレが修正されたか、あるいは原作サイドがテレビ局の企画に乗ってしまうという選択肢もあったかもしれません。

　ズレが修正できなかったら企画がつぶれるだけで、その後の苦しみはなかったはずです。本作の場合、ズレの修正とはテレビ局が漫画の伝えたいメッセージを再度理解し、それを軽視しない企画に練り直すことに他なりません。報告書を見る限り、芦原さんがテレビ局の企画に合わせて原作の意図を縮退させたドラマ化を許可したとは思えないからです。

　このことは正に、ユーザー企業とベンダーがIT導入の目的意識を共有しないままプロジェクトが始まり、ベンダーが自分の思いだけで勝手にシステムの機能を作り込むような事態と同じといってよいでしょう。

　通常、情報システムの企画段階ではベンダーは参加しません。従ってベンダーは、システム開発における“企画意図”たるシステム化の目的を、最初は知らないわけです。そこでユーザーにはベンダーにシステム化の目的を十分に理解させる必要があるのですが、実際にはこれを怠り、機能や性能が足りないなどで業務に使えないシステムを作ってしまうという結果に陥ります。

　本作は、原作のドラマ化に当たって原作者が企画段階から参加しないまま脚本の執筆が進んだ結果、原作とは似て非なる作品を生み、原作者をはじめとする関係者を傷つけ苦しめることとなりました。

　ドラマの企画に当たっては、原作者の意図を知り、原作者の理解を得るために企画段階からの原作者の参加を求めるべきだったといえます。企画にベンダーが参加することが難しいITの現場では、RFP（提案依頼書）の提出や提案、プロジェクト計画などを行いながら、ユーザー企業とベンダーが目的を共有し、1つのチームになることが大切です。

　またプロジェクトの開始後も、そうした目的の再確認や、そこから外れる要件の調整、システム構成の見直しなどが必要ですが、そうしたことが不十分だったドラマ「セクシー田中さん」は、IT開発の視点から見ても、一つの「反面教師」と言えるでしょう。

原作者サイド＝ユーザー企業の協力義務と心構え

　「セクシー田中さんドラマ化」問題は、ユーザー企業がシステム開発に臨む上で必要な心構えと協力についても大切なことを教えてくれているように思えます。

　2つの報告書を読むうちに私は、原作者の方にも、ドラマ化を受けるに当たって自らの心を守るために幾つかの心構えが必要だったように思いました。

　これは私自身が登場人物を設定した物語を書く身であることからの考えですが、「自分の作品を忠実にドラマ化するのは、テレビ局だけでは無理である」という考えがどうしても必要です。

　ドラマ制作にはいろいろな制約があることは報告書にも書いてあった通りです。時間的な制約もありますし、連続ドラマなら1話ごとに何らかの盛り上がりを作る必要もあります。放送時間帯や視聴者に合わせてテイストを変える必要もあります。だからこそ、前述したようにドラマ「セクシー田中さん」の企画意図は原作とズレたものになってしまったのでしょうが、それはドラマの制作上、ある意味避けられないことだったのかもしれません。

　ですから、原作者がそうした制約の中、それでも原作の意図を再現してほしいと考えるなら、ドラマ企画から撮影の終了まで、積極的に打ち合わせに参加し、自分なりの意見を述べることが必要となります。その結果出来上がるのは、恐らく原作の意図をくみながらも、さまざまな設定やストーリーを変えた「新しい作品」になるはずです。それでも原作者が十分に自分の意見を通せるなら、今回のように原作者が苦しむことはなかったのではないでしょうか。

　ドラマ化とは「新しい作品をテレビ局や脚本家と一緒に作る活動」だという考えが必要だったように思えます。無論、そうさせなかったのはテレビ局のドラマ制作プロセスや出版社とテレビ局の担当者が原作者と脚本家の間に入るというコミュニケーションの方法に問題があったからなのでその点は後述しますが、いずれにせよ、テレビ局、出版社、脚本家と共にチームに参加して新しい作品を作るという心構えと責任分担が必要であるように思えます。

　これはIT開発の現場でユーザー企業の積極的な参加が求められるのと同じです。ユーザー企業は要件をベンダーに示した後でも、ベンダーの作業にさまざまな意見や提案をしなければいけません。

　開発中に必要となる情報や意志決定はプロジェクトの完了まで続きますし、要件定義書では示しきれなかった細かい要望もたくさんあります。こうしたことを小まめに伝え、ベンダーと調整し、あるときは妥協しながらもシステムを作っていくのがユーザー企業の役割であり、いかに多忙でも欠かせない行動です。ユーザー企業には厳しい話かもしれませんが、自社を守るためにこそ必要な心構えだと思います。