ソースコードは資産か、負債か？この問いに自信を持って資産であると断言する方は、残念ながらこの記事とは縁が無かったので回れ右をして帰っていただきたい。今回は思うところが有ったので技術的な話題ではなく、その思うところについて書いてみようと思う。
「ソースコードは負債である」
流行り言葉そのままで申し訳無いが、「ソースコードは資産である一方で負債でしかない側面が有る」と、僕個人としては思う。ソースコードが生み出す価値は資産足り得るがソースコードそのものは紛れもなく負債だ。ソースコードは収穫が約束されない代わりに無限に広げられる畑に例えることが出来ると思う。ソースコードは恵みをもたらすかも知れない。故に、その恵みを最大化するために畑を広げたいと考える。しかし、無闇に畑を広げることは害獣に襲われる土地を増やすことでもあるし、耕し、監視し、水やりをしなければならない範囲が広げるということでもある。つまり、無闇に広げた分だけバグに怯えながらメンテナンスする人を増やす必要があるということだ。
ソースコードを増やす時に計算しなければならないコストは増やすためのコストだけではない。むしろ、そのコストは背負う負債の量からすれば微々たるものであるとも言える。増やしたことで背負わなければならない負債、その負債こそが計算されるべきなのだ。その負債は増やす時に背負ったコストのような一時的なモノではなく稼動し続ける限り延々と背負い続けなければならない。言うなれば咎人の枷だ。だから、ソースコードを無闇に増やしてはならない。ソースコードを増やすことで問題を解決しようとするのは、その負債について考えるならば最後の最後の手段であるべきだ。使うかどうか分からないソースコードを増やすのは、10年ぶりに電話をかけてきた友人から怪しい壺を買うために高金利の消費者ローンを組むのと同等の行為だ。コピぺで重複コードを撒き散らすことなど有ってはならない愚行だ。同じプロジェクト内で同じ目的のコードを複数人で別個に作って重複するなどは、もはや出来の悪いコントだ。コードを増やすのであれば資産をもたらすコードを最小限の負債として実装しなければならない。
・半年から1年がかりの大仰なロードマップを引いて使われる見込の少ない負債を量産していないか?
・使われなくなった負債を放置していないか?
・コピペで負債を膨らませていないか?
・想定されているアーキテクチャを無視して大きな負債を実装していないか?
・書き捨てるだけ書き捨てて、書き捨てた負債から目を逸らしていないか?
あるあるネタではあるが、これらは少くなってきているように感じる。コードに対する意識や進め方で、どうにでもなってしまうからだ。だから、スタートアップの時に「こういうのやめましょう。こういうことしていると、やがて成長速度が鈍るから」と言うように進めてきていれば問題は発生し難くなる。しかし、初めは小さかったシステムも段々と大きくなってくる。目が届かなくなってきて同じようなソースコードを実装し始める。そうして背負った負債のために人を増やす。増えた人に声を届けられずに、さらに負債を呼ぶ。負債は負債を呼ぶのだ。そして大きな負債のためにシステムが本来持ち得る成長速度を阻害して、その大きな負債の中で見逃したバグでユーザーに迷惑をかけ、信用を損ない、その信用を取り戻すために、さらに負債を増やす。などというように、結局大きな負債を背負うことになる。
ならば、どうすれば良い? 今回の論旨は、この部分にある。これで全てが解決する訳ではないが、 ひとつ提示出来ることがある。
「プログラマはもっと会話をするべきだ」
プロダクトマネージャーと、チームと、社外に居る仲間と。僕らはディスプレイにばかり向かっていて会話をすることをサボっていたのかも知れない。会話をサボることで負債を増やすという罪を犯してきたのかも知れない。
今、プロダクトマネージャーが入れたバックログはコードを書かなくても解決出来るかも知れない。誰かが、同じ目的のコードを書こうとしているかも知れない。会話をして負債を減らせるかも知れない。誰かが、より良い解決策を持っているかも知れない。誰かが、会話に入れないために負債を増やしてしまったのかも知れない。それは、ちょっとした雑談を話しかけたことで未然に防ぐことが出来たのかも知れない。僕は、プログラマの部門こそが、社内でもっとも五月蝿い部門であって良いと思っている。そうすることで背負わなければならない負債を減らすことが出来ると考えているからだ。
そもそもソースコードを書くという作業を、ひとりで黙り込んでするべきではないとすら思っている。ソースコードを書くという作業は会社の負債を増やし、それをリリースすることでバグで信用を損う可能性の有るリスキーな作業である。世の中に一発で会社がぶっ飛ぶ恐れすら有るリスキーな作業を、たったひとりで進めさせる業種が他に有るだろうか? 極端な例えをするならば、ビルの爆破解体を一人でダイナマイト仕掛けさせて、どこに仕掛けたかを報告させて、ひとりで周りに人が居ないことを確認させて、ひとりで爆破スイッチを押させてるようなものだ。ペアプロはこの項目をクリアするための解決策として、そして重複コードを減らす解決策としても優れているのだがペアプロについては本稿の論旨からズレるので一旦横に置いておかせてもらおう。要旨としては、もっと会話をすることで会社の成長速度を阻害する負債を減らせるかも知れないということに尽きる。特に「今、書こうとしているコード。今、書いているコードについて、もっと隣の人と見せ合って、話合って欲しい」ということだ。僕らはリナスでもリチャード・ストールマンでもラリー・ウォールでもポール・グレアムでもない。スーパーマンではない僕らは簡単に巨大な負債を背負う。せっかくのチームなのだからお互いに足を引っぱり合うのではなくて、お互いの力を利用して背負う負債を減らしていけることを切に願う。
アライドアーキテクツでは、メンバーの中心で話の出来るエンジニアと、ブログ記事のタイトルと内容が一致しないエンジニアを募集しております。
なるべく他のメンバーは書かないであろう流行りとは程遠いところや、 枯れたキーワードについて書いていこうと思います。 Perl / Java / PHP 及び周辺技術に興味があります。
