小野 今回、「美しいコード」をテーマに考えていこうということで、まず僕が興味を持ったきっかけについて話します。僕はこれまでパッケージをベンチャーでやってきた中で、プログラマーというのは美しいコードを目指すのが当たり前だとずっと思って生きてきました。ところが、4年前にセゾン情報と業務提携をして、そこでSIの実際の現場みたいなものに触れた時に、「美しいコードが当たり前」という考え方とは大きく異なる価値観で、いろんなことが動いている生態系を目の当たりにして。コードがあまり重視されてないというか、作業的に見られていることにショックを受けたわけです。これまで芸術性を極めて、大切にするべきもの、崇高なるソースコードへの探求の道みたいに思っていたものが、なんか雑作業扱いになってる？！みたいなところがあって、ものすごく傷ついたんですよね。自分が大事にしていたものが、この世界では価値を持たないと。
その後、いろいろと話を聞いたりしていくうちに、結局SIの中でも本当は美しいコードの持つ意味は決して損なわれることはなくて、僕が生きてきた世界と本質的にはほとんど変わらないなというふうに思うに至ったんだけど、ただあまりにも業界のこれまでの慣習であったりとか、常識であったりとか、そういう前提のところが、どうしてもコードを軽視することが背景にあるように思えていて。コードを大事にすること、美しいコードを求めることの重要性みたいなものが、このSIの世界で少しでも広められたらすごくいいなと思っています。
ただ僕１人で話しても、それは「パッケージ屋の小野がそう思ってるんでしょ」となってしまうので、実際SIをずっとやってきた有馬さんと会話する中で、コードの美しさが尊重される世界と、SIの世界が交わるきっかけが見つかるんじゃないかなと思っていて、本日の対談と相成りました。
というわけで、有馬さんには今日、SIerの人として来てもらっています。まず、有馬さんはどんな仕事をしているのかを教えてください。
有馬 私は本当に「ザ・SIer」として、PL、SEなどのいわゆるSE職をほぼ20年近くやってきました。対応してきたプロジェクトは大きいものから小さなものまでさまざまです。ただ、他のSEと大きく違うなと思うのは、最近でも専門のプログラマーとして、実際のプロジェクトで開発しています。
通常SEというのは、最初は簡単なプログラミングを書いているんだけど、その後、出世魚のように、設計をして、リーダーをして、あとはプロジェクトマネージャーって…という形に進化してゆくんですが、僕はプロジェクトマネージャーをやったあとにプログラマーをやったりして、上流や下流を行ったり来たりしているところに、特殊性があると思っています。今回、小野さんのおっしゃる美しいコードについては、現場に近い立場で、SIerで使われているコードの現状について話せるんじゃないかと思います。
コードが美しくあるべき理由
小野：たぶんコードって言った場合に、本当はすごくいろんなレベルがあって。この業界の比喩として、最近ネットで話題になったもので「猫踏んじゃったしか弾けない人間を500人集めてもショパンの曲は演奏できない」っていうたとえ話がありました。僕はピアノは専門じゃないからわかんないけども、設計とか実装のプログラミングの世界でもそういう高みっていうものが実際にはある。あるんだけど、そこへ猫踏んじゃったが書ける人を何人月、集めたみたいなことが起きているわけですね。スキルとして交換可能というか、作業として代替可能であるっていう考え方です。指示書さえあれば誰がやったって同じなんだっていうような感覚ですね。詳細設計に基づいたコードでテストが通れば、それは同じものなんだとみなされているような、そういう価値観とか見方がSIの世界にあるように思えていて。Webや外資系の企業、パッケージの世界っていうのは全くそういう見方をしない人達が支配的だと思うんだけども、日本のSIに限って言えば、プログラミングは代替可能な作業であって高みのようなものの存在が意識されていないように思えているんだけど、そこについてはどう思いますか？
有馬 「どうだ、僕らが作ったソースコードはすごく美しい」と自慢しているSEや現場って、聞いたことないですよね（笑）。いわゆるSEは開発中にプログラムを見るということが、あまりありません。なぜそうなるかと言うと、SIerっていうのはウォーターフォールに基づいて、要件定義、設計、開発という形で開発を進めていくことが多いので、どうしても開発工程は「下流である」とか、「SEがやるものじゃない」と、「もっと簡単なものだ」というふうに思われがちです。美しいプログラムがどうこうという議論や、美しいプログラムを考えるという場面に、そもそも出くわさない。
小野 なるほど。そういう議論は行われていないんですね。ただ一方で、たとえば美しいプログラミングが必要とされていない世界なのであるならば、その概念がなくても問題ないと思うんですよ。だけど、よりその高みを目指して、美しく設計され、実装されたコードであれば、問題が起きなかったり、迅速にいろんなものに対応できたりとか、本来、得られた潜在的利益があったとしたら？ ソースコードの美しさの高みが足りないというか、低かったことが理由でいろんな問題が起きたり、すごくお金がかかったりと、つまり美しくないことによるディスアドバンテージが発生したみたいな話が伝わらないと、趣味の話をしてるみたいになっちゃうと思うんですよ。だから美しくないがための痛み、みたいなものっていうのが、SIであるのかないのかっていうのが重要だと思うんだけど。
有馬 SIにおいても、コードが美しくないがための開発上の痛みっていうのはやはりあります。それはどういう時かと言うと、仕様変更や改修の時ですね。SIの現場では、ウォーターフォールで上から仕様や設計を固めた後に、プログラミング工程に入ります。ですので、開発の途中で仕様変更が入った際に美しいコードであればソースの見通しが良いので、改修や仕様変更が非常にしやすい。ただ、SIerのソースコードっていうのは、プログラミング経験が不十分な人が設計していることが多く、それに基づいて書かれたコードは状況によっては変更に非常に弱くなってしまう。ですから、美しいコードで作られている場合は、仕様変更に対する痛みを大きく和らげると思います。
小野 仕様変更って実際にあるかないかで言うと、けっこうあるわけですよね？
有馬 ウォーターフォールは仕様を最初に固めるっていうのが基本ですけど、仕様変更がない現場っていうのは見たことないです。
小野 そうでしょうね。実際の美しさを追求していって、美しいコードで構成されたSIのチーム、またはその美しいコードの価値を理解しているお客様とか、そういう全体として美しさみたいなものの価値が共有されている現場がもしあるとしたら、きっといろいろな問題が起きにくくなる。
有馬 起きにくくなりますね。ただ、ソースコードが美しい美しくないという以前に、大きな開発現場では、そのソースコードの存在自体が無視されがちになります。ソースコードの美しさが議論されるような状況にないというのが大きなSI現場の課題ですね。
