ざ～ちゃんブログ

この前のブログで「戯曲をもっと読みます」と宣言しましたが、さっそく野田秀樹の戯曲集をKindle版で買って、大好きな「パンドラの鐘」読みました。じっくり読んでみると新たな発見があって面白いね。



タマキさんの最後のセリフ

「日本には王がいるわ 。」
「あたし達だけは知ってるじゃない 、ヒメ女とミズヲの物語 。もしアメリカが 、もうひとつの太陽を爆発させようとしたって 、王が守ってくれる 。滅びようとする日のあのヒメ女のように 、ヒメ女が 、この土地を救ったように 、王ならば 、必ずその地が滅びる前に 、きっと 、わが身を埋めるでしょう 。」

これを素直に解釈すると、長崎でパンドラの鐘が爆発したってことは、昭和天皇には古代の心が届かなかったってことになります。高校時代は俺もそう解釈してました。

でも、それから15年経った今改めて読んでみると、マッカーサーに「全ての戦争責任を負う」と伝えた昭和天皇には、ヒメ女の心が届いていたって解釈もできると思いました。というか俺はそう信じたい！

日本の天皇って決して「王」ではないじゃないですか。「君臨すれども統治せず」なので、自分の一声で何でも国が動くわけではない。「我が身を埋める」と天皇が本気で思っても、それだけじゃうまく行かないのが現実の世の中です。

野田さんは単に前者のつもりで書いたのかも知れんけど、そこの解釈は読み手の自由。だから俺の今の解釈は、「古代の心は未来に届いた。パンドラの鐘は爆発してしまったけど、それでも未来の国は滅びなかった。滅びる前の日に、未来の王は未来の国を守ってくれた」って思うことにしました！

さてさて余談ですが、何気にインパクトあったミズヲのセリフ。。。

「人はいつも未来を相手にしか戦争できない 。戦争をはじめた日 、誰もその事に気付かない 。そして人は未来に 、決して勝てない 。」

これ、開発前の見積もりが甘く、始まってみたら納期もコストも全然割りに合わないことにやっと気付いて、あとはデスマーチ赤字プロジェクトになるソフトウェア開発そのものじゃないかー！と思った次第です。。。「赤い風景」ってそういうことだったのかーー(´；ω；`)

やはり、ソフトウェア開発に演劇から得るものは大きいですね(笑)
ではでは～。

最近、ソフトウェア開発と演劇の共通点について色々考えを巡らせてたんですが、そんな矢先にこの記事を読んでかなり面白かったです。
http://synodos.jp/culture/14752

前は何となく「戯曲=ソースコード」と思ってたんだけど、今思うのは、ソースコードは戯曲ではなくて「役者のセリフ」と考えた方がしっくり来るなぁと。そしてプログラマーが役者。なんか、良いプログラマーと良い役者って共通するものがある気がするんです。

そんで戯曲はというと、プログラミングに入る前の「仕様書」に相当する気がしています。

アジャイル開発とかで、仕様書をしっかり書かずに作るのが流行ってますけど、最近それに似た開発を少し試してみて「やっぱ仕様書は大切だな」と思い直したところもありました。特に離れた場所のメンバーにプログラミングを振るときは、それなりの仕様書を作らないとうまく回らないですよね。

かと言って、読んだらそのままソースコードに落とせるような詳細な仕様書まで書くのは意味がないとも思うのです。仕様書を読んだプログラマーが、各自工夫してプログラミングする余地を残しつつ、ベースの部分は読めばしっかり分かるという仕様書が理想だと思うんですが、それって俺が考えてた「良い戯曲」の条件と同じなんですよね。役者の一挙手一投足まで書かれてる戯曲を読むとちょっと嫌になります…そういうのは「戯曲」じゃなくて「上演台本」としか言わんのかもしれんけどね。

さっきの記事に「戯曲を見直そう」と書かれていたのを読んで正にそうだなと思いました。「仕様書を見直そう」と。伝えるべき大切なことはしっかりと書き、かといって必要以上に細かく書きすぎず、そういう素敵な仕様書を書くために、ちょっと色んな戯曲を読んでみようと思いました(笑)

こんなアプローチを取るプログラマーはなかなか世の中に少ないんじゃないだろうかw 高校大学と芝居やってたことが、今になって仕事にプライベートに色々活きてるのを実感しています。

まぁそうは言っても、素敵な仕様書を書くために時間ばっかかけてしまうとビジネスとして成り立たんのでね…コストとクオリティとのジレンマは非常にシビアなところでありますが……(´；ω；`)