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

ローファイ日記

出てくるコード片、ぼくが書いたものは断りがない場合 MIT License としています http://udzura.mit-license.org/

過去の自分を救いたいプログラマの話

闇 Advent Calendar 2013では、青臭い話もネガティブな話もして良いそうなので、これから小説を書きたいと思います。



ぼくはプログラマなのだが、ぼくの仕事の考えの真ん中にあるのは、実は技術的なエッジに触れているとか、あるいは給与がいいだとか、そういうことは結構どうでも良くて、たとえば孤独なチームメイトを作らないとか、業務知識を一人で抱え込むのを辞めさせるとか、一人一人に当事者意識を持ってもらうとか、そんな青臭いけど単純なことである。

ただのスクラムの影響、言われればそれまでだが、その根底にあるのは「過去の自分を救いたい」と言う感情だと思っているし、この考えの根底が作られた当時はスクラムの本なんかろくに読んでいなかった。



過去、とある会社に所属していたとき、辞めるまでの後半の1年ほどは本当に辛くて、入社して2年ほどしかたっていないぼくが、2000年代の初めだかに誕生したレガシーシステムのあるコンポーネントについて唯一把握しているエンジニア、と言う立場になり、営業だとか、経理の人間だとか、マーケティングの人間の質問に対して調査をして答える、新規機能の開発の時間はない、それが業務の時間のすべてを占めるような状態になっていた。その前まで創業初期からのエンジニアの上司は、あっさりと競合他社に移った。その後facebookか何かでその競合すらあっさり辞めたようなので、何をしたかったのかよくわからない。離れたかったんだな、と言うのは分かるけど。

時にはバグについて責められる立場になった、解せなかったのは、そのエンバグをしたのはぼくではなく、2003年にそのコードを書いた、コメントの日付と作成者名だけはやたら丁寧に書くとっくの昔にやめたプログラマ氏であった、ということもあったが、何より同じチームの人間のはずなのに、職種が違うと言うだけでぼくは「外注先」、向こうは「顧客」になって、後片付けは「外注先」がやるのが当たり前と思っている態度だった。「社内外注」と言う表現は当時のぼくが心の中で使っていたものだ。

一度あったことを話す。確かに要件をインタビューして、SQLについては向こうが提案するなど、チームとして開発したある機能があった。その機能に後日バグと言うか要件漏れが見つかった。そのときに、その機能のオーナーであったマーケティング担当者から社内で怒鳴り散らされたことがあった。いわく、お前の変更のせいでエンバグをした、お前のせいなんだから徹夜をしてでも直せ、とにかく非常に感情的だった。

たしかに、エンバグの原因となった、一部機能を見落としていたと言う事実はぼくの責任かもしれなかったし、非専門家がSQLで表現した業務要件を形式知にできなかったのは力不足なのだ。しかし、まず、怒鳴り散らした彼は間違いなく同じチームで、完成した機能を確かに「検収」していたはずなのだ。つまり、責任の一部を負ってくれたと思っていたのだ。

実は、チームでたった一人作った人間だけが責任があり、バグや不具合の責任を取るのが当たり前だと思っていたのだろうか。そう思って仕事をするのは勝手だが、だれがそのようなチームで「作る側」に回ろうと思うだろうか? こと、ぼくは自己分析するに、「人が作りたいものを実現するモノ作り」に魅力を感じるたちなので、当時なおさら強く思った記憶がある。

ここまでで作り手とそうでない者の壁をさんざん批判した。にもかかわらず、際限なく降ってくるあらゆるバグ改修要望に対して、「予算が取られていないから」と言う理由を盾に「ノー」と言い続けたのもぼくだった。ぼくは、自分を守るために、「社内外注」と言う立場を利用せざるを得なかった。本当はサービスを良くするために要求を言う人たちの話を深く聞き出したかったし、予算はもっと大きなスケールで考えるものだ。でも、彼らは「要求を言うだけ」で、「一緒になって考える」習慣が無いので、その習慣をつけてもらうところから始める、そのための技術が当時のぼくには無かった。



その後ぼくは「社外でのオープンソース活動」に注力し、少しだけ自信を取り戻したあと、チームを大事にする人たちが集まる会社に移った。

その会社で、ぼくはたったの一年半で、それまでの自分とは別人であるかと思うほどにいろいろなことを身につけた。何より、チームを作るとはどういうことか、人を巻き込むとは、形式知を広めるにはどうすればいいか、技術的な視点を共有するには、などなど、前の会社ではぼんやりとやりたくても誰も十分に教えてくれなかったことだった。教えられるほど深く考えていた人は居たのだろうかと思う。居たのかもしれないが、ぼくは盗めなかった。

順調に転職したかのように書いたが、それでも、ぼくにはその会社でも一つ後悔していることがあった。「チームを大事にする人たちが集まる会社」とはいえ、よく言えばものすごいエネルギーの集まる、見方によってはいびつな成長を続ける会社だったので、考え方の違う人も居た。たまたま、チームに興味の無い人が集まってしまったチームがあって、エンジニアをすりつぶすような開発が定常化し、壊れたチームのまま放っておくような状態になっていた。

そのチームに対して何かぼくはできなかったのだろうか、と今でも思う。気の合った後輩が居たのだが、そのチームに疲れてある日居なくなってしまった。ただの雑談では彼を救うには不十分だった。

未だにそのチームのエンジニアから伝え聞いていた内容を思い出すと、腹が立つようなものだった気がするが、それもまた一方的な視点だし、そのチームが本当にどうなっているか飛び込んでみることはできなかったのだろうか? チームを壊していると思われる張本人に、どうして壊れるような言動を取るのかインタビューできなかったのか? 同じエンジニアの間でも視座に違いがあったのを一緒に正せなかったのか? 「ぼくら側」となっている、つまり「チームを大事にする」側として相談してきているエンジニアにも問題があったと当時から思っていたのだが、それをちゃんと適切に伝えられなかったのか?

彼らも、ぼくも、ここで「殻を破れなかった」のだろうと思う。



最初の会社で味方がいない訳ではなかった。気を掛けて、ぼくの苦手なJavaについて時々教えてくれた同僚とは、その後一緒に飯を食ったりした。しかし結局彼と話していて思ったことは、彼は「自分の殻」からどうしたって出たくない人なんだろうなあと言うことだった。楽しく好きなSpring Frameworkバッドノウハウを追いかけることができれば満足なんだろうな、と思った。あの会社には、そういう人が多かったのかもしれない。

彼の話を聞くと、事業のボトルネックになっていたような人物は幾人か去り、社歴は浅く、さらに一から何かを作る力のある人たちによって、昔ながらのシステムはどんどんと無くなって、業務知識自体が刷新されているように思われる。事実がどうなのかは分からないが、ただぼくが居た頃は一番タイミングが悪かった、と言ってしまえばそれまでなのか。そういうことも今ではよく分からない。

ぼくはまた転職をし、今は別の会社で、まるで「殻を破る」ことが専門かのような仕事を毎日のようにこなしている。ここでもチームを大事にしたい人たちに囲まれているので結構楽しくやれているが、冷静に考えると、ストレスフルであるような気もする。でも、意地になって続けている。それは、過去の自分が責め立てていて、苦しいような気がするからなのだ。



闇 Advent Calendar 2013 の25日目のストーリーでした。

モノ作りに携わるすべての人の幸せを願ってメリークリスマス!