都議会、ソフトウェアのソースコードを規制する条例を可決
2010年12月某日、都議会ではソフトウェアのソースコードを規制する条例案を可決した。
条例の内容は、可読性やメンテナンス性の悪いコードを不当に賛美あるいは誇張する書物を規制するもので、ソフトウェア工学を学んでいる学生の目に触れないようにすることを目的としたものである。条例が運用段階に入ると、都内の大学生協の書籍売場からはそういった書籍が姿を消す可能性が高い。また都議会では、今後都に対して納入されるシステムについてもソースコードを厳しく監視し、可読性やメンテナンス性に著しく劣ると判断されたコードは検収を上げないとも述べている。
これに対し、都内のギークたちが一斉に反発。「可読性」「メンテナンス性」「不当に賛美」といった指標は判断基準が明確でなく、解釈次第で規制の対象がどこまでも広げられるというのがその理由だ。
一方で、条例には賛同する声もある。都内のとあるSEは「ひどい連中は誰にも引き継げないようなひどいコードを書き残して辞めていってしまう。ショートコーディングなどといって不必要にコードを短縮して暗号にしてしまうヤツもいるし、オブジェクト指向だの関数型だのと次々と新しいオモチャを職場に持ち込んではプロジェクトを壊してしまうタイプも多い。都がこういった規制に乗り出してくれるのはありがたい。」と今回の条例に肯定的だ。またシステム企業勤務で管理職の男性は「オブジェクト指向はまったくもってしっくりこない。すべて static 関数で記述するべきだ。」と憤っており、オブジェクト指向技術を賛美する書籍の全廃を訴えている。
プログラマからは不安を訴える声が挙がっている。あるプログラマは「僕は三項演算子が好きでよく使用するが、時折三項演算子を敵視する人を見かける。都がどう判断するのか不安だ。」という。また別のプログラマは、「私はC++プログラマで boost ライブラリを頻繁に利用しているが、boost のコードはスキルが高くないと理解が難しく、可読性が悪いと受け取られかねない。今後都への納入案件に boost を利用していいのか悩む」と訴えている。
ツイッター上では、あるユーザーが「『Modern C++ Design』という本にはかなり変態的なコードが載っているが規制の対象になるのか」と問いかけたところ、イーノッセ副都知事から「大丈夫だ、問題ない」との回答を得たという。しかし別のユーザーの「brainfuck で納品しても大丈夫か」との問い合わせには「一番いい言語を頼む」と回答したとの噂もあり、その判断基準について様々な憶測を呼んでいる。副都知事はその後の多くの批判にも一切の聞く耳を持たず、ツイッターでは「あいつは人の話を聞かないからな」と不満の声が高い。
ソフトウェアの進化はギークたちの偏執狂的ともいえる強い拘りが支えてきた部分も大きい。そういったこだわりが構造化プログラミングやオブジェクト指向プログラミングなどといったパラダイムを生み出す源泉となっており、今回の条例はそのようなギークたちの活動を萎縮させるのではないかと危惧されている。このような批判に対して石魔羅都知事は、
「世の中には変態ってやっぱりいる。気の毒な人で、DNAが狂っていて。やっぱりアブノーマル。闇プログラマーの変態的なコーディングなんてものは、障子に穴をあけることも出来ない。何の役にも立たないし、（百）害あって一利もない」
と述べ、規制の必要性を改めて強調した。
なお、東京都では近く大型のシステム開発案件の公募を開始するが、現在のところ大手 SIer で入札をボイコットする動きはないようだ。
（この記事はフィクションです。実在の人物・団体・事件とは一切関係ありません。）
ニュートラルを意識する
オシゴトではニュートラルを常に意識するといいんじゃないかなー、という話。
まず余談から。ここ数年、テニスをやっている。週イチでスクールに通っているのだけれど、サッパリうまくならんね。まーこの年になって運動不足解消のために始めたスポーツはなかなか上達は難しい。しかも週イチだし。勝つためにやっているわけじゃないのが上達しない最大の理由だろうね。
そんな僕でも、たま〜にするどいストローク（当社比）が打てる時があるわけ。ただ、決定的にダメなのは、そうやって打った球を目で追っちゃうんだよね。「お、俺ちょっと今いい球打ったんじゃね」とかいい気分に浸って、自分の打球に見惚れてしまう。だけどそういう打球に限って、相手からも鋭い打球を打ち返されちゃうことって多い。だけどこっちは自分の打球に惚れ惚れしちゃってまさか返されるなんて思ってないものだから、当然そこで負け。あー情けない。
要するに、ストロークを振り抜いたそのままの体勢で打球に見惚れているから、ニュートラルの体勢に戻ってないんだね。体勢が崩れちゃってる。だから次のボールに対応できない。これがダメなところ。ダメだと分かっているのに一向に改善する気配がないのがもっとダメなところ（苦笑）
小学生の頃とかに「家に帰るまでが遠足です」って言われたじゃない？家にいる状態がニュートラルなんだね。ニュートラルに戻すまでが遠足です、ってことなんだよね。
テニスもそうなんだろうなー。ラケットを振って、スプリットステップしてニュートラルの体勢に戻すまでが「ストローク」なんだろうね。
オシゴトでもそう。ソースコードが綺麗に整理されてて、機能はテスト済みの状態がニュートラル。そのニュートラルの状態を常に意識することが大事。体勢が一時的に崩れても、できるだけ素早くニュートラルに戻すことが大事。
機能を追加したら、必ず状態はニュートラルと比べて崩れる。それは当然だよね。もともとニュートラルな状態だったものに外乱を加えているわけだから。でも出来るだけ素早くニュートラルに戻すべき。
「ニュートラルに戻すまでが機能追加です」
つまり、コード書いて、リファクタリングして、テストして、そこまでが「機能追加」。コード書いただけで自分の仕事に惚れ惚れしてちゃダメ。ニュートラルに戻さないとお客さんに打ち返された打球に対応できない。
正直なところ、これが分かってない人とは仕事がやりづらい。コードをどんどん書いて、本人はたくさん「機能追加」をこなしたつもりになっているんだけど、体勢はどんどん崩れてニュートラルから外れていってる。先日「それじゃあダメなんだよ」と伝えたところ。真剣に聞いてくれたので、きっと分かってくれたと思う。
信じてるよ！
STL修正ソフト MoNoGon のデモムービーが出来ました
宣伝広告っぽいエントリが連続してしまい恐縮ですが。
先日株式会社カタッチからリリースしたSTL修正ソフトMoNoGonのデモムービーが出来ました。とある方が作ってくれたのですが、これがまたカッコイイのですよ・・・。開発者の立場からするとカッコ良すぎて照れくさいですね。
MoNoGonは下記URLからダウンロード可能で、無償で機能を体験することが出来ます。
http://www.quatouch.com/products/monogon/download.html
MoNoGonは「モノになるポリゴン！」の合言葉の下で生まれたソフトウェアです。
3Dプリンタ（RP機）の登場により、ポリゴンデータを簡単にモノにできる時代になりました。昨今は3Dプリンタの低価格化も進んできています。
しかし、すべてのポリゴンデータがモノに出来るわけではありません。データの不具合により3Dプリンタに正しくデータを受け渡せないというトラブルがしばしば発生するのです。つまり、「モノになるポリゴン」と「モノにならないポリゴン」があるのです。
「モノにならないポリゴン」を3Dプリンタに渡すためには、修正して「モノになるポリゴン」にしなくてはなりません。この修正作業の強力な助けとなるのが MoNoGon です。MoNoGonを使えば厄介な不具合データもスムーズに「モノになるポリゴン」に修正することができます。
3Dプリンタに限らず、これからはポリゴンデータを元にしたモノづくりが盛んになっていくでしょう。MoNoGon はそんな先進的なモノづくり −ポリゴンでモノづくり− を現場で支えるソフトウェアでありたいと考えています。
ポリゴンデータ（STL/OBJデータ）の修正ソフト MoNoGon を発売しました
モノになるポリゴン [MoNoGon] − 3Dプリンタ（立体出力）のためのSTL修正ソフト / 株式会社カタッチ
ようやく、株式会社カタッチとしてパッケージソフトを世に送り出すことになりました。ここまで漕ぎ着けることが出来て本当に嬉しいです。もちろん「売れるかどうか」という切実な問題はこれからが本番なわけですが、まずは自分が今、この位置に立っていることが単純に嬉しく、また誇らしくも感じています。と同時に、共に同じ進路を目指し一緒に船を漕ぎ進めてきた人たちにも深い感謝の念を感じています。
カタッチを興してからもう5年目です。カタッチの英語表記は QuaTouch であり、Quality Touch の略です。この社名は、単にバグが少ないとか高機能とかという意味の「品質」だけではなく、ユーザーとの触れ合う部分 − touch − にこだわったソフトウェアを創りたい、という思いでつけた名前です。今振り返ってみて、5年目にしてもう一度初心に戻ったソフトウェアづくりが出来たような気がしています。（ちなみに quality という単語には「品質」という名詞の意味だけでなく、「高品質な」という形容詞としての意味もあります。）
まあ、ちっぽけなソフトですよ？客観的に見れば。例えば自動車産業などと比べれば海に浮かぶ塵芥といっていいほどちっぽけなソフトです。でもね、塵芥でも水面にさざ波くらいは起こせるんじゃないかと思ってる。一寸の虫にも五分の魂ってヤツですよ。
なぜそう思うかというと、少なくともオープンスペースにボールを蹴り込んだはず、という感触があるからです。サッカーの喩えですが、ディフェンス側もオフェンス側も観客も誰もが右サイドに注目している局面で、ポッカリと空いた左サイドのスペースにボールを蹴り込んだみたいなイメージです。もちろん、単に的はずれなボールで失敗に終わる可能性だってありますが、うまくすればゴールに繋がるかもしれない「面白いボール」じゃないかと思っています。
その「面白いボール」のひとつが「当日ライセンス800円/年間ライセンス10万円」という売り方です。とりわけ当日ライセンスという考え方は少なくともこの業界では画期的なのではないかと自負しています。
SaaS - Software as a Service という言葉があります。ソフトウェアをモノと考えるのではなくて、サービスと捉える考え方ですね。資産として数えるのではなくて経費として扱う感じでしょうか（実際の会計処理がどうなるのか私は知りませんが・・・）。これはウェブアプリケーションの方面では常識的な考え方になってきているようです。しかしデスクトップアプリケーション、特にCAD系のソフトウェアにはまだこういった考え方は浸透してきていないように思います。そもそも SaaS という言葉はウェブの世界のものであってデスクトップアプリには関係ない話、と捉えられているのではないでしょうか。
しかし私は自社アプリにも SaaS 的な考え方を取り入れてみたい、とかねてから考えていました。当日ライセンス800円という売り方はある程度 SaaS 的な要素を備えることが出来たと言えるのではないでしょうか。これが「画期的」と呼べるのかそれとも「的はずれな愚策」なのかは今後数字となって現れてくるものでしょう。ただこの数字は短期的に評価すべきではなく、今後２〜３年の推移をみて評価していきたいと考えているところです。
今後ともカタッチと MoNoGon をよろしくお願い致します。
「美しいソースコード」に価値はない
「美しいソースコード」を書くために頭を捻っている時間は「コスト」だ。「価値」じゃない。
同様に、「醜いソースコード」の解読やデバッグに費やす時間も「コスト」。
要件定義も設計もテストもリファクタリングもみーんなコスト。どれもそれ自体に価値なんてない。
それがお客さんの手に渡って、きちんとお客さんに利便性を提供したときに初めて「価値」が生まれるんだと思う。
つまり「価値」を自分だけで生み出すことは不可能ってこと。「価値」とは「評価」だから。他者に評価してもらって初めて「価値」になる。僕たちが自分だけで出来るのは、ただ「コスト」を積み上げるだけ。それに「価値」を認めてもらうにはお客さんの存在が絶対に必要。
できるだけ大きな「価値」を最小の「コスト」でお客さんに届けたい。そう考えたときに「美しいソースコード」にこだわるべきか否か。コードの洗練にかかるコストと、醜いコードのまま放置した場合にメンテでかかるコストと、どちらが大きくなってしまうか。そういう問題。
僕はコードは美しいほうがいいと思うよ、もちろん。でもそれはコストを最小に抑えるため。美しいコード自体に価値があるからじゃない。美しいコードは手段であって目的じゃない。
だから、例えば美しいコードにこだわりすぎて納期に間に合わないとか、ダメダメ。どんなに美しいコードでもお客さんに届かなかったらコストにしかならない。価値が生まれない。
もっと踏み込むとね、「私」という人間に「価値」はないと思ってる。私はコストしか産まない。私が行うありとあらゆる活動はコストに過ぎない。その活動の結果がお客さんに評価されて初めて「価値」が生まれる。
まーここで言っている「価値」は、身も蓋もない言い方をすれば「売上」のことであって、狭義の価値を指しているに過ぎないのだけれど・・・ね。「美しいソースコード」というものに、売上とか金銭的な価値を超えた「価値」を見出そうとするのは、それはそれで素晴らしいことかもしれないけれど、職業プログラマとして幸せになれるかというとちょっと苦しい気がするよ。
読むと感動するようなすごいコードって実在すると思うし、そういうのを競いあう文化とかも好きだし、そういうのを目指す努力も楽しみとしては良いと思う。でもそういう「美しいソースコード」を書くのが我々プログラマの矜持だ！などと思い詰めると結構辛い職業人生になるんじゃないかと思う。
「プロ」の定義は価値をお客さんまで届けることであって、「美しいソースコード」を書く事ではないよね。
複素世界
「複素数」ってのがあるよね。実数と虚数の線形和。complex number。
「虚数」ってのがまた不名誉なネーミングだ。英語にすると imaginary number。想像上の数。
実数君が虚数君を揶揄している姿を想像してしまう。
「ねえ、虚数君。数ってのはさ、僕みたいな実体があるもののことを言うんだよ。君なんて、方程式の解を無理やり解くために便宜上作られた想像上の存在に過ぎないじゃないか。」
・・・なんだかライブドアが「虚業」と揶揄されたあの事件を思い出すね。
しかし大数学者ガウスによる複素平面の登場によって、虚数から「虚」なイメージは拭い去られ、実体のある数としての扱いを受けるようになった。・・・なんて話をどこかで読んだ。うろ覚えだが。
このエピソードを読んだときは、「数が『在る』という感覚って、何なんだろなー」などと考えたものだ。僕も初めて「負の数の平方根」などと聞いたときは「なんだそりゃ？意味あんの？」と思ったよ。しかし複素平面を習ったことで複素数が平面上の点と認識出来るようになり、さらに流体力学で、電気回路で、量子力学で、と様々な分野で複素数が利用される場面に出会うと徐々に虚数も『在る』ような気がしてくる。と同時に、ε-δだとか連続体濃度だとかを知るにつれて実数の『在る』という感覚に自信がなくなってきて、「数ってなんだろなー」という素朴なギモンは常に付きまとう。
閑話休題。
virtual という単語がある。日本語ではよく「仮想」と訳されるけど、これって殆ど誤訳だよね。本当の意味は「実質上の、事実上の、実際上の、実質的な」。だから "virtual reality" は「事実上の現実」。"virtual function" は「事実上の関数」。"virtual memory" は「事実上のメモリ」。
虚数も imginary number じゃなくて virtual number と呼べば面白いのに。
さてここからは、"virtual" と書いたら本来の「実質上の、事実上の」という意味、「バーチャル」と書いたら誤訳の「仮想の」という意味だと受け取って欲しい。
「電脳コイル」というアニメがあった。「電脳メガネ」という特殊なメガネをかけると電脳世界が見えるという設定。子供たちにとってはその世界は virtual だったけど、大人たちにとってはそれはバーチャルな世界でしかなかった。
面白いと思ったのは、子供たちにとっては電脳物質とか電脳生物は『在る』ものだったのに、大人にとってはそれらは『虚』でしかなかったという点だ。『在る』と感じるその感覚、『虚』と感じるその感覚は、一体どこから来るものなんだろう。
お金に価値は『在る』と感じる？
「欲しいものと交換できるのだから価値はある」という頭での理解を聞いているんじゃないよ。実感として感じるかどうか。
僕は数百万の札束を見たら多分心臓がドキドキする。多分脈拍が上がる。だから札束には価値が『在る』と感じていると思う。札束自体は本来ただの紙のはずなのに、実質的な価値が『在る』と感じる。virtual な存在。バーチャルではない。
でもATMに表示される口座残高とかスイカみたいな電子マネーとかだと、札束ほど『在る』という感覚はない。この時点でたぶん、僕はオールドタイプなんだろうな。
あなたにとって、グッチやシャネルのブランドはvirtual？それともバーチャル？
ベンツやフェラーリはvirtual？それともバーチャル？
億単位の値段がつく現代アートはvirtual？それともバーチャル？
顔を合わせたこともない「メル友」はvirtual？それともバーチャル？
初音ミクの歌声はvirtual？それともバーチャル？
ラブプラスの「彼女」はvirtual？それともバーチャル？
この世は複素世界だ。XYZの空間軸と並行して様々な virtual 軸が存在している。僕たちは同じ世界に住んでいるように見えて、実はぜんぜん違う virtual 軸で生きている。わずかに共有しているXYZ空間で一瞬すれ違うことしかできず、他人の住んでいる virtual 軸は自分にはバーチャルにしか見えない。
ケータイゲームの2000円の釣竿はvirtual？それともバーチャル？
「自分がもう一人いればいいのに」
僕の脳がまたあの病気に侵され始めたようだ。病名は仮にJMHと名付けよう。「(J)自分が(M)もう(H)一人いればいいのに」の略称だ。
このJMHはストレスを喰って肥大化する。「忙しい」という思念が大好物のようだ。時間に追われてバタバタしていると気づかぬうちにこの病が進行し、自分の無意識が支配される。「自分がもう一人いればいいのに」という思考から抜け出せなくなる。
自分がもう一人いるならばプロジェクトのコンセプトを伝える必要もない。タスクの優先順位も分かってくれる。進捗に苛立つこともない。コミュニケーションも以心伝心。何のストレスもなく、ただ自分の仕事が2倍の速度で進行する。ああ、素晴らしい。しばし現実から逃避し、そんな甘美な夢想に酔いしれる。
場合によっては、このJMHという病は別の症状を示す。
あるときは「魔法の部屋があればいいのに」と夢想する。部屋の中で二日経っても外に戻ると一日しか経っていないという、まさに精神と時の部屋。そんな部屋にしばらく篭ればこの仕事も終わるのに。
また別のときは「変身」を夢想する。明日の朝になると何故か自分が底なしの集中力を持つパワフルな男に変身していて、無駄なネットサーフィンで時間を潰すことなく驚異的な集中力を深夜まで持続させ普段の倍以上の仕事量をこなせるのではないか、という妄想。
いずれにせよそのような妄想が現実になることなどない。つかの間の現実逃避に過ぎない。
だがこの病に自覚的になれれば得るものはある。症状を分析することで自分がいったいどんな「現実」から逃避しようとしているのかが見えてくる。
メンバーにプロジェクトの目的やコンセプトをしっかりと伝えることを怠っているのかもしれない。タスクの優先順位を明示してメンバーに提示できていないのかもしれない。勝手に伝わることを期待していて、きちんと伝えることを怠っているのかもしれない。
いや、そんな生ぬるいことではない。JMHとはつまり、自分より劣った人間とも優れた人間とも仕事をしたくないと思っているということだ。これに気づくと己の醜さに愕然とする。猫の手も借りたいなどと云いつつ猫の手を借りる気はさらさらなく、かといって自分より優れた人間にあっさり仕事を片付けられるのも面白くない。そうではなく「自分」と仕事をしたいのだ。なんと醜い思考であることか。
しかも、「自分がもう一人いればいいのに」と思うことはあっても、他人（例えばX君）を見て「X君がもう一人いればいいのに」などとは絶対に思わない。他人を見てその彼がもう一人いればいいと思うことはまずないのだ。逆に言えば、他人が客観的に僕を見て、僕がもう一人いればいいのになどと思ってくれることは有り得ない。そして、こういうのは客観的な判断の方が正しいに決まっている。同じ人間が二人いたって面白くもなんとも無いのだ。違う人間が互いの欠点を補い合いながら協力するときにこそ成果は上がるものだ。
つまりは、僕は自分と違う人間に向きあうことから逃避しているのだろう。
JMHは手強い。気づかぬうちに意識の隙間に入り込み、駆除するのはゴキブリよりも難しい。それでも、頭を整理してJMHは妄想に過ぎないと冷静に理解すれば、少しだけ脳から追い出せるような気がしている。
