世界線航跡蔵

翔泳社の「君のために選んだ1冊 ソフトウェア開発の名著」という企画に寄稿を依頼されて、以下のような文章を書いた。ブログ等で公開して良いとのことだったのでここに公開したいと思う。 この企画は他の人の分を読むのが楽しみだ。早く本ができあがらないかな。

ちなみに「きっと何者にもなれないお前たちに告げる一冊」というタイトルを最初に思いついたけれど、長く読み継がれる本であってほしいという企画の趣旨を鑑みて流行のネタを使うのは避けた。

yuguiがレガシーコードに絶望した人に贈りたい一冊 - 『レガシーコード改善ガイド』

振り返るに私のキャリアの大部分はWebアプリケーション業界のレガシーコードとの戦いであった。 多くのシステム開発者にとって全くのゼロからシステムを開発する機会よりも既存のシステムの拡張や保守に携わる機会のほうが多い。それは私にとっても同様であった。

これは恵まれたことであった。私は先人の遺産(=legacy)とともに仕事をしてきた。 現在私が暮らしている業界自体を作り出した黎明期の開発者たち、あるいはやんちゃな天才ハッカーたち、彼らの仕事に触れることができた。 Webアプリケーションの黎明期には出遅れた、論文を書けるような先端技術に通じているわけでもなく、競技レベルの優れたコーダーでもない平凡な私が彼らと同じ開発の場に立つことができた。

ここで問題は、それらのシステムの多くがいわゆるレガシーコードであったということだ。 適切なデザインのシステムにおいて、ある変更をするとどのような影響があり得るかは自明である。あなたがそのシステムを知って数日しか経っていなくとも自信を持って変更を行うことができる。しかしレガシーコードにおいてはそうではない。多くの情報が目に見えない形で埋もれていてそのすべてを知ることを要求し、新参者の貢献を拒んでいる。 レガシーコードは変更のコストを増やすのみならず、見通しが悪いためにリスク評価自体を困難にする。

先駆者や天才たちは前人未踏の領域ですばやく動いて生き延びるためにこのコードベースを作り出した。あるいは抽象化や分割統治、すなわち複雑と多量を凡人が取り扱うための工夫を必要としない故に。 そして先駆者にだけ通じる暗黙知を前提とした拡張や、天才が次の挑戦を求めて旅だった後の担当者による生半可な保守行為がレガシーコードを静かに腐らせていた。 拡張しづらく、複雑で理解に苦しみ、ちょっとした変更が予期せぬ副作用を産むレガシーコードに私は絶望した。 あなたもまたレガシーコードに絶望してきたのではないだろうか。そうでなくともあなたが先駆者や天才でないならば、いつかレガシーコードに出会いその中で開発することだろう。そんなときにどうすれば良いのか。

最悪の選択はレガシーコードに向き合うことをやめて、適当に目に付いたところに拡張を施しては壊れませんようにと祈ることだ。そうした半端な仕事こそがコードをますます腐らせる。それは先人の遺産を食い潰して生きることに等しい。その果てになんの望みがあるだろう。

いっそ初めからやり直したくなることもある。レガシーコードを捨てて新たに同じ機能を書き下ろす。それが適切なときもある。けれども先人の知恵が詰まったそのコードを、大体は完璧な仕様書など存在しないというのにどうやって漏れなく再実装するのか。こうしたリスクを取れないこともある。

だから、朽ちていくレガシーコードに出会ったならばそれを殺さぬまま再生に導かねばならない。 生まれたてのシステムのように適切なモジュール化を施せ。考古学を行なって暗黙の知識を発掘しコードに明示化せよ。 『レガシーコード改善ガイド』はこうした作業をなすための知恵を説く。

まず本書は独特の意味でレガシーコードを定義する。「テストケースの無いコードはレガシーコード」である。これは過激なようだが上手な定義だ。 適切にテストケースを書こうとすれば自ずとシステムは適切にモジュール化され、前述のような欠点はなくなる。つまりまだテストケースのないシステムはそのような欠点を抱えている可能性が高い。

次に、いかにしてテストケースを取り付けるか、それから著者が「テストハーネス」と呼ぶテストでソフトウェアを固定してリファクタリングすることを述べる。 更にいくつもレガシーコードでの開発によくある状況を挙げて対処法を教える。

私はレガシーコードを多く見てどのようなときに何が悪い設計なのかを知った。多くの本を読んでは実践し、あるべきソフトウェアデザインを考えた。 しかしレガシーコードをどうやってあるべき姿に導くのかは手探りを続けていた。そんなときに本書を読んだ。自分のやり方が正しかったことを知ったり、思いつかなかった大胆なやり方に息を呑んだりした。

あなたもレガシーコードに出会うだろう。そんなときに本書から知恵と勇気を得て欲しい。

whoisしてみると分かるようにrubykaigi.orgドメインは現在私が所有している。

元々RubyKaigiは独自のドメインというのは持っていなかった。その頃、確か高橋さんか角谷さんにだったと思う、rubyconfみたいにドメイン取らないのかと聞いてみた。取るつもりはないというお答えであった。思うに、当時は今にも増してイベントの継続性は神のみぞ知るところだったわけで、ドメインを取ってそこで継続的にサイトをメンテナンスするのはそぐわないということだったのだろう。

それにしても、RubyKaigi 2007が行われようかという時点で既にruby-talkやruby-coreでも"RubyKaigi"という文字を目にするようになっていた。と、すればいずれここに目を付けるスパマーもいるだろう。みすみすこのブランドをスパマーにスクワットされるがままに放置しておくのは惜しいように思われた。そこで私が勝手にrubykaigi.orgを登録してRubyKaigi 2007のサイトに転送するように設定して運用していたのである。

その後、実行委員会は方針を変えたようで角谷さんから「rubykaigi.org持ってるよね?」と連絡があった。必要ならいつでも引き渡すよーとは言ったのだけれどもなんか特に必要にも迫られなかったので、結局所有者兼ドメイン設定担当者みたいな形でずるずるとここまでやってきている。角谷さんから要請があるとその都度私がDNSレコードを変更したりしていた。

この度、日本Rubyの会が法人格を取得すると言うことで、関係する個人ではなく会そのものがドメインを所有することもできるようになる。そこで「近いうちにrubykaigi.orgは日本Rubyの会に引き渡そう」という話をしたりもした。それで、思い出話を書いてみた。

先に報告したようにこのたびGoogleに転職した。 ここで、Googleのトランスセクシュアルへの対応に感心したので書いておく。

履歴書

まず、US系の企業としては当たり前の慣習であり法的自己防衛でもあるのかもしれないけど、履歴書に性別を書かされない。

背景

履歴書に書くべき何か簡潔な性別の記述というものが存在するのであれば私にとっては問題ないのだけれども、実際のところはそうではない。 この話は以前も書いた。

人は性別という単一の二値属性が存在することを信じるが、残念なことに自然はそういう風にはできていない。人の信じる仮構は単に、少数者を例外として排除してしまえば幾つかの性別要素にまつわる量が成す数ベクトル空間について2つの同値類が存在し、それを「男」「女」と呼べるというだけの話に過ぎない。

残念なことに最初に省いた特異点を含めると単純な同値類は成立しない。都合の悪い例から逃げずに一般にこの空間の性質について話をするならば、性別というものは「今どの切り口におけるどういう定義での性別を必要としているのか」「仮に性別属性を二値に落とすとして、二値の境界をどこに置くか」を与えなければ記述が困難だ。 上掲記事のように数ベクトルを成す個々の値についての話を羅列して、これが私の性別であると述べることは可能かも知れない。しかしおよそ、一般に簡潔な表記が得られるとは限らない。そして見ての通り、私が試みた自己の記述は簡潔ではない。あれでも、あんまりみんなを煩わしてはいけないと思って多少の不正確は覚悟の上で若干の情報をそぎ落としてあるんだけどね。^*1

大抵の書類は受付者が必要としている性別の定義を書いていない。だから私は上のようなことを毎度毎度考えたあげくに、この人はどの定義における性別情報を必要としているのだろうか、私にとってはこれは面倒で下手をすれば性別違和感を喚起される甚だ不快なことなんだけれども、そもそも私の辛抱に見合うほどこの人はこの情報を必要としているのだろうか、また、この場面においてこの切り口の性別情報を提示させることは政治的に適切な態度だろうか^*2と悩むことになる。

Googleの場合

Googleの採用ページには、「性別、生年月日、年齢、門地、兵籍、国籍、個人識別番号等を書くな」とある。 これらは確かに採用に当たって能力を測るには必要がない。またこれらの情報を知らなければ、性差別をするつもりなのではないか、年齢差別をするつもりなのではないかと勘ぐられずに済む。合理的である。

以下で見るように入社前後の手続きで性別にまつわる何らかの属性情報を必要とする局面は確かにあるのだけれども、そんなものは血圧やコレステロール値と同じく、採用を決めて必要になってから必要な限度において収集すればよい情報である。

労務系

社会保険に健康保険、雇用における男女共同参画の資料やらなんやら、労務系の資料では「法律上の性別」が必要となる局面が存在する。

Googleでも入社するとこれらの手続きのために必要な情報を提供するように求められる。今回私はこの段階になって担当者に次のようなメールを送った。

レジュメから参照可能なオンラインリソースにも明記してありますのでご存知かも知れませんが、私はトランスセクシュアル(MtF-TS)です。このため、現在の戸籍/法律上の性別と社会生活上の性別は異なります。入社手続きフォームは主としてlegalな手続きのためのものとお見受けしましたので性別欄は戸籍上のデータ(男性)を入力しましたが、もし社会生活上のデータが必要でしたらご相談ください。

フォームの趣旨に関する私の推量は適当だったようで、その旨返信があった。当たり前だけれどもGoogleはこの点ではフェアな会社である。上のような申告で特に問題は無かった。

性同一性障害に関する判例の中では、大きな問題となって「選考過程で虚偽の申告があったため解雇」とかいうことで係争になった事例もある。その点でGoogleはまともな会社である。

医療系など

これだけであれば私は特にこの記事を書こうと思うことはなかったろう。その後、人事の方からフォローがあった。曰く、

• USではトランスセクシュアルの従業員もそれなりにいるが、東京ではまだ事例が少ないので今後のために何か改善してほしい点などがあれば教えて欲しい。
• 今後、特に健康診断などで不愉快な思いをさせないかと心配しているが、どのような対応を希望するか
  • 基本的には契約した病院の集団検診に参加して貰っているが、これは不愉快な思いをさせるのではないか
  • 契約した病院に個別の健康診断を依頼したほうがよいか
  • その他の方法があるか

これについて、私は次のように答えた。

• 入社手続きフォームの性別(Sex)という記入欄は、どのような性別を意図しているのか推察可能ではあるけれども明瞭ではないので法的性別(Sex in Law)などのように明確にしてほしい
• 健康診断については配慮して頂いて有り難い
  • 集団検診についても、事前に病院に話を通して頂いてちょっとだけ配慮を頂けるならば(個人的には、検診のやり方の詳細をその場で訊いた限りでは)問題ないように思える
  • 個別に依頼してもらえるのが最も良いように思える。その場合も会社から病院に話を通しておいて頂けると有り難い。
  • 埼玉社会保険病院のように、性同一性障害者の健康診断の事例の豊富な病院もあるので、健康診断で必要な検査項目をリストして貰えればこちらで検診を受けてくることも可能である。(私は塚田攻医師に相談して、以前の健康診断はこちらで受けた)
• 私は性同一性障害者であることをオープンにしているが、すべての当事者がそうであるとは限らない。ヘイトクライムの危険性などもあるので性同一性障害であることの情報は本人の判断に沿って管理されるべきである。今後オープンにしないことを希望する当事者が入社したらそのように対応して欲しい。
• ここでの私の回答はあくまでも私の場合の個人的な回答であって一般化はできないので、個々の事例ごとに対応して欲しい

日本の医療は健康保険を通じて法的性別と医療上の性別とが接する場であるので、両者が一致しないケースや医療上の性別を単純に男性もしくは女性と記述できないケースでは問題になりやすい。一方、トランスセクシュアルであっても完全にSRSを終え、法的性別の変更を済ませてしまっている場合はあまり問題にならないと考えられる。

その他

また

• 社内のLGBTIのためのコミュニティとしてGayglersというのがあるので見てみてはどうかと案内してもらった
• ここでは伝え忘れたけれども、労務系のための法的性別の収集と社内のプロフィール設定における社会的文化的性別(Gender)の入力が独立しているのは素晴らしいと思った。
• 開発合宿や研修旅行の目的でで温泉などを利用する場合、浴室設備が大浴場だけだと、SRSを受けていないトランスセクシュアルの利用に際して摩擦が発生しやすい。以前に提唱された解としては近場にビジネスホテルの部屋を別途用意するなどの対応が考えられる。これにしても問題が無いわけではないけれど、間に合わせの回避策としてはとりあえず機能するだろう。

考察と展望

このように、プロフェッショナルな仕事をする人事がいれば従業員がトランスセクシュアルであることは問題にならない。

トランスセクシュアルと労働というと、日本では何かと暗い話題もよく耳にする。やれ、面接で侮辱的な扱いを受けただの、性同一性障害であることを理由に解雇されただのと。しかしWeb業界は、全体に若い業界であることも手伝って既に「トランスセクシュアルかシスセクシュアルかなど、仕事に当たって気にする方がおかしい」という流れである。少数の変な信念を持った差別的な企業があってもじきに淘汰されよう。

これから職に就こうとする若いトランスセクシュアルに特に伝えたい。あなたは何にでもなれる。もう時代は変わった。だから、トランスセクシュアルであることで何か職業選択上の可能性が制約されるとは考えないで欲しい。

Web業界でLGBTであるということを理由に積極的に排除しようとする人はほとんどいない。日系の大きな組織になると、銀行系の妙な人材が経営層に流れ込んでいる関係か少しばかり硬直的な制度があることもある。けれども、それは交渉すれば変えられるものだ。なんと言っても現場の人たちは味方なのだから。^*3

それに企業は日系企業だけではない。たとえばGoogleもまた、LGBTに対してフェアである。採用時の差別は存在しないと思われる。よく分からないことについては相談しつつ、喜んで多様性に対応できる人事がいる。法的性別、医療における性別、社会生活における性別が必ず一致すると仮定した誤った設計の社内システムが存在しない。

世界はあなたに対して開けている。私はこれを理解しているつもりで、そして私自身が一つの事例を提供し続けることで後の世代に伝えたいと思ってきた。しかし、私は理解していなかった。私が肩肘張って自力ですべてを変える必要もないのである。 今回Googleの人事はプロの仕事をして、受動的に必要な対応をしてくれるだけでなく積極的に動いてくれた。世界には優秀な人たちがいて、世界はこんなにも開かれている。

^*1具体的な数値はそれこそプライベートなことだし、記事を書くときに検査票を資料の山から引っ張り出すのも面倒だったので
^*2センシティブかつプライベートな問題であるので、社会的に適切とされている以外の軸についての性的属性の収集は一般的に言って性差別またはセクシュアル・ハラスメントである。例えば職場でパンツの色を聞いたり包茎かどうかを問題にするなど。勿論、性的なジョークが許される間柄ならば良いけれども、一般的に職場で性器の形態について問題にするのは望ましいことではない。トランスセクシュアルがしばしば直面する、社会生活上の性別が必要とされるべき局面で医療的性別情報を要求される類も同様にしてセクシュアル・ハラスメントに包括されると私は考える。「セクシュアリティに関する射影関数の不適切な選択｣がセクシュアル・ハラスメントなのである。
^*3今回私は途中でうんざりしてきて日系企業の相手をするのはやめたからあんまり大きな口は叩けないけど