最近、ソフトウェア開発と演劇の共通点について色々考えを巡らせてたんですが、そんな矢先にこの記事を読んでかなり面白かったです。
http://synodos.jp/culture/14752
前は何となく「戯曲=ソースコード」と思ってたんだけど、今思うのは、ソースコードは戯曲ではなくて「役者のセリフ」と考えた方がしっくり来るなぁと。そしてプログラマーが役者。なんか、良いプログラマーと良い役者って共通するものがある気がするんです。
そんで戯曲はというと、プログラミングに入る前の「仕様書」に相当する気がしています。
アジャイル開発とかで、仕様書をしっかり書かずに作るのが流行ってますけど、最近それに似た開発を少し試してみて「やっぱ仕様書は大切だな」と思い直したところもありました。特に離れた場所のメンバーにプログラミングを振るときは、それなりの仕様書を作らないとうまく回らないですよね。
かと言って、読んだらそのままソースコードに落とせるような詳細な仕様書まで書くのは意味がないとも思うのです。仕様書を読んだプログラマーが、各自工夫してプログラミングする余地を残しつつ、ベースの部分は読めばしっかり分かるという仕様書が理想だと思うんですが、それって俺が考えてた「良い戯曲」の条件と同じなんですよね。役者の一挙手一投足まで書かれてる戯曲を読むとちょっと嫌になります…そういうのは「戯曲」じゃなくて「上演台本」としか言わんのかもしれんけどね。
さっきの記事に「戯曲を見直そう」と書かれていたのを読んで正にそうだなと思いました。「仕様書を見直そう」と。伝えるべき大切なことはしっかりと書き、かといって必要以上に細かく書きすぎず、そういう素敵な仕様書を書くために、ちょっと色んな戯曲を読んでみようと思いました(笑)
こんなアプローチを取るプログラマーはなかなか世の中に少ないんじゃないだろうかw 高校大学と芝居やってたことが、今になって仕事にプライベートに色々活きてるのを実感しています。
まぁそうは言っても、素敵な仕様書を書くために時間ばっかかけてしまうとビジネスとして成り立たんのでね…コストとクオリティとのジレンマは非常にシビアなところでありますが……(´;ω;`)
http://synodos.jp/culture/14752
前は何となく「戯曲=ソースコード」と思ってたんだけど、今思うのは、ソースコードは戯曲ではなくて「役者のセリフ」と考えた方がしっくり来るなぁと。そしてプログラマーが役者。なんか、良いプログラマーと良い役者って共通するものがある気がするんです。
そんで戯曲はというと、プログラミングに入る前の「仕様書」に相当する気がしています。
アジャイル開発とかで、仕様書をしっかり書かずに作るのが流行ってますけど、最近それに似た開発を少し試してみて「やっぱ仕様書は大切だな」と思い直したところもありました。特に離れた場所のメンバーにプログラミングを振るときは、それなりの仕様書を作らないとうまく回らないですよね。
かと言って、読んだらそのままソースコードに落とせるような詳細な仕様書まで書くのは意味がないとも思うのです。仕様書を読んだプログラマーが、各自工夫してプログラミングする余地を残しつつ、ベースの部分は読めばしっかり分かるという仕様書が理想だと思うんですが、それって俺が考えてた「良い戯曲」の条件と同じなんですよね。役者の一挙手一投足まで書かれてる戯曲を読むとちょっと嫌になります…そういうのは「戯曲」じゃなくて「上演台本」としか言わんのかもしれんけどね。
さっきの記事に「戯曲を見直そう」と書かれていたのを読んで正にそうだなと思いました。「仕様書を見直そう」と。伝えるべき大切なことはしっかりと書き、かといって必要以上に細かく書きすぎず、そういう素敵な仕様書を書くために、ちょっと色んな戯曲を読んでみようと思いました(笑)
こんなアプローチを取るプログラマーはなかなか世の中に少ないんじゃないだろうかw 高校大学と芝居やってたことが、今になって仕事にプライベートに色々活きてるのを実感しています。
まぁそうは言っても、素敵な仕様書を書くために時間ばっかかけてしまうとビジネスとして成り立たんのでね…コストとクオリティとのジレンマは非常にシビアなところでありますが……(´;ω;`)