読者です 読者をやめる 読者になる 読者になる

きっと、ずっと、会議は踊る

エンジニアリングとアイドルとロックンロール

-- しゅう (@shoe116) の徒然なる物思い --

安保法改正とSEALDsに対する当たり障りない感想と、技術的負債の話

無駄に難しい考え事 engineering

はじめに

このエントリの「当たり障りのなさ」を担保するために、以下のことを確認しておく。

このエントリの目的

このエントリの主眼は、あくまでもライブ告知だ。

これが伝えられれば、とりあえず満足だ。

安全保障関連法案と、このタイミングについて

正直な話、僕は「こうするべきだと思う」という意見を論理的に発信できるほどちゃんと理解していないので、法案が通るまでこのテーマでBlogを書くのを保留していた。でも、今回の”騒動”はそんな無知なWebエンジニアから見ても興味深いことがいっぱいあったので、今更感があるのを自覚しながら以下の2つの観点でBlogを書いてみる。

  • 一連のゴタゴタと、いわゆる「技術的負債」の関係
  • SEALDsに対する共感とデモに対する違和感について

法案が国会を通過して一週間も経って、大学生の夏休みも終わって、しかも福山雅治が結婚した今なら、もう当たり障りもないだろう。

一連のゴタゴタと「技術的負債」の話

技術的負債 (Technical debt)という言葉を聞いたことがある人はどれくらいいるのだろう?Martin Fowlerという人の"TechnicalDebt"という解説がわかりやすくて好きなんだけれど、当然英語で書かれている。恥ずかしいことに僕は英語がそれほど得意ではないのだが、Martin Fowler's Bliki (ja)という、有志の方々による素敵な日本語訳がGitHubにあるので、その該当ページ「技術的負債」からありがたく引用させていただく。

システムに新しい機能を追加するとしよう。2つのやり方があるはずだ。ひとつは、早いけれど、ぐちゃぐちゃになるやり方(将来、変更が困難になることは分かっているよね)。もうひとつは、キレイな設計だけど、導入に時間のかかるやり方。


「技術的負債」とは、Ward Cunningham が作ったメタファーである。上記の問題について考える際に、この言葉が役に立つ。このメタファーを使うと、早いけれど汚い解決方法は(ファイナンスの負債と同じく)技術的な負債が発生する、ということになる。 通常の負債と同じく、こちらの負債も利子を払う必要がでてくる。 早いけれど汚い設計を選んだせいで、将来の開発において余分な労力をさかねばならなくなる、というわけだ。 これからずっと利子を払いつづけていくことも可能だし、 リファクタリングによって良い設計に修正し、元本を減らしてしまうということも可能だ。 もちろん元本を減らすのにはコストがかかる。

憲法9条と安全保障なんて技術的負債そのものだ。「キレイな設計」、つまり憲法改正をしないで自衛隊を作ったせいで、それ以後の安全保障周りの機能拡張には常に「余計な労力」を割く羽目になっている。もちろんリファクタリング憲法改正)によって元本を減らすことも選択肢の一つだが、それには膨大なコストがかかる。今の日本にそのコストが払えるかどうか、僕にはわからないけれど。

誤解してほしくないのは、はじめに「キレイな設計」をしなかったのが悪いと言っているわけじゃないということだ。技術的負債より、リリースまでのスピードを優先しなければならない案件なんて腐るほどあるわけで、多分日本の安全保障はずっとそうだったんだと思う。

もちろん、そんなやり方を繰り返して拡張してきたシステムの可読性は下がるばかりなので、「今となっては、ちゃんとは誰も把握しきれていないけれど、とりあえず(少なくとも致命的な)問題なく運用出来ている」という状態が出来上がる。一度こうなってしまうと、システムのメンテナンスできる人は限られてくる。憲法9条の元で集団的自衛権の議論とか立法ができるなんて、僕の理解が及ぶところではないし、当然どれだけ説明されてもわからない。だって、可読性が低すぎるんだもん。

しつこいようだが、僕はそれが一概に悪いとは思っていない。「速度を優先する」という選択を繰り返してきたシステムが、適切なタイミングでリリースされ、ちゃんと売上に貢献しているのを僕は何度も見てきた。

SEALDsの共感とデモへの違和感について

別に僕はSEALDsの主張やデモという表現手法に対して、正しいとか間違ってるとか、素晴らしいとか頭が悪いとか言いたいわけではなく、あくまでも僕が個人的に感じたことを書く。

SEALDsに対する共感

安全保障の問題は、法治国家である日本国における技術的負債だ、ということはすでに述べた。これは、SEALDsのWebページ冒頭の

私たちは、戦後70年でつくりあげられてきた、この国の自由と民主主義の伝統を尊重します。そして、その基盤である日本国憲法のもつ価値を守りたいと考えています。この国の平和憲法の理念は、いまだ達成されていない未完のプロジェクトです。

 というメッセージと矛盾しない。これはそのまま、日本の平和憲法の理念には「70年分の技術的負債がある」ということだ。先人たちは、「アメリカが日本の武力解除を目的として作った平和憲法の元で、そのアメリカと事実上の軍事同盟を結ぶ自衛隊を持ち、なおかつ民主主義を維持する」という信じられないようなプロジェクト運営を行ってきた(書いていて、これぞhack!という感じがする。きっとどのhackathonに出ても優勝だ)。

 僕は、今回の彼らの主張は

  • わかりにくすぎる、ちゃんと説明しろ
  • なんでお前らだけで決めるんだ、本当に必要なのか?
  • 改正するリスクが大きすぎる

だと理解していて、これについてはもうそのとおりだ。僕も、何度も思ったことがある。

  • 設計もコードもカオス過ぎる。1から書き直したい、時間ないけど。
  • これに機能追加するの?無理矢理過ぎる、なんで今更?
  • デグレのテスト不十分だから、事故っても知らないよ・・・

技術的負債を目の当たりにした人の、至極真っ当な感情だ。

デモに対する違和感

その一方で、デモを見るたびになんとも言えない違和感を感じる。軽蔑や嫌悪感と言ってもいいかも知れない。別にこれはSEALDsに関してだけではないし、そのデモの主張に自分が賛成か反対か、ということもほとんど関係しない、「デモ」という表現方法そのものの話だ。この理由がイマイチ自分でもはっきりしていなかったんだけれど、この違和感はどうやら「デモの主張が、僕にはわかりやすすぎる」ということに起因しているようだ。

以前「エンジニアが日々何を考えているか、ということ」というBlogでも書いたけれど、『ソフトウェアアーキテクトが知るべき97のこと』という有名なエッセイ集*1のなかに

本質的な複雑さは単純に、 付随的な複雑さは取り除け

というニール・フォードさんのエントリがあって、僕はこれを座右の銘としてエンジニアをしている。

どう考えても「平和憲法の元で、自衛権の話をする」と言うのは本質的な複雑さだ。もちろん、できる限り単純にしたいところだが、前述の通り技術的負債のためにそれも相当に難しい。しかし、だからといって「本質的な複雑さ」を付随的な複雑さとして取り除くのは本末転倒だ。大勢で「戦争法案反対!」と叫ぶ姿は、その本質的な複雑ささえ取り除いてしまっているように、少なくとも僕には見える。「TPP反対!」も「原発反対!」もそうだ。どの主張も、解決すべき問題の複雑さに比べてあまりにも単純で、わかりやすすぎる。これが僕がデモに対して抱く違和感の正体だ。

この過度な単純さは、おそらくデモという表現手法の制約だ。みんなで集まって効果的にメッセージを発信するには、内容は出来る限りシンボリックな、単純化されたものにするしかない。本質的であろうが付随的であろうが、複雑さはすべて取り除く。考えてみれば、ほとんどのデモの主張は「OO反対!」なわけで、逆に言えば「建設的な対案を論理的に主張する」みたいなことは、デモでは難しいということなのだろう。

結局何が言いたかったか

はじめに書いたとおり、これはライブ告知*2を目的とした「技術的負債に苦しんだことのあるエンジニアの当たり障りのない感想文」で、それ以上でもそれ以下でもない。

そういえば敬愛するGreen Dayのビリー隊長がlive "Bullet In A Bible" のholidayのイントロで叫んでいた

This song is not anti-American, its anti-war.

という言葉をふと思い出したので、そのlive動画を貼ってそれで終わりにしようと思う。

ではでは10/18、お暇でしたら是非下北沢まで遊びに来てください!

www.youtube.com

 

 

*1:

CC-by-3.0-USというcreative commonsライセンスに準拠して、webでも読める。エンジニアじゃなくても楽しめると思うし、エンジニアが如何にエモい人種かが垣間見えると思う。

xn--97-273ae6a4irb6e2h2ia0cn0g4a2txf4ah5wo4af612j.com

*2:

ライブ詳細

学生時代の友人のギタリスト・現フィドラーのkatsu氏も一緒に出てくれます。

詳細は もしもし世界? — schedule をご確認ください