プログラマのキャリアを考えたとき、経験を重ねた先は管理職、もしくは独立してフリーランスといった選択肢がほとんどです。
しかし、どちらもプログラマとして腕を磨き続けることが難しい環境です。
そんな状況だからこそ、会社に所属しながら、ずっとプログラマを続けられる「第三の道」を選んだ方々に、プログラマを一生の仕事にした先に見える景色を語っていただきました。
第1回の対談相手は、ソニックガーデンに入社して8年目のベテランプログラマ、遠藤大介さんです。
小学校の卒業文集に「夢はプログラマになること」と書くくらい、根っからのプログラム好き。いろいろな技術の流れを追いかけるのが好きで、いつも新しい技術で遊び続けている遠藤さんは、まさに「遊ぶように働く」を体現している人でもあります。
ソニックガーデンでのこれまでを振り返りながら、プログラマとしての戦い方を語りました。(全4回)
開発者の帽子を脱いでお客さんとワンチームになりながらも、プログラマとして作る/作らないの判断をうまくコントロールする難しさも経験してきた遠藤さん。
プログラマの役割に戻って実際に開発を進める際には「コードが負債にならない形にまとめること」を意識していると話します。
プログラムのコードは「負債」

倉貫
これまでお客さんとの関係性について聞いてきたけど、遠藤さんがプログラマとして開発をするときに意識していることはある?

遠藤
僕はコードの「フットワークを軽くすること」を意識してますね。

倉貫
それはどうして?

遠藤
何が当たって何が当たらないかがわからない世の中だから、いろんなチャレンジをしていくことが求められると思っていて。そのためにはフットワークを軽く、いかにコードが負債にならない形にまとめ上げていくかが、プログラマの腕の見せどころだと思ってるんです。

倉貫
「コードを負債にならない形にまとめる」って、どういうことだろう?

遠藤
僕はプログラムのコードは基本的に「負債」だと思ってるんです。コード量が多くなると、それだけメンテナンスが必要なものも増えて、どんどん身動きが取りにくくなる。それってコードが負債になっている状態なんです。
それを防ぐために、より短いコードでよりすごいことができるよう、常に最新の技術に追従する。そして、それを自分の道具として使える状態に維持することを大事にしてます。

倉貫
なるほど。技術の進歩についていくことでフットワークが軽くなると「納品のない受託開発」のように毎週ミーティングをして、毎週リリースするやり方がスムーズに進むよね。


遠藤
そうですね。「いかに負債を増やさないように作るか」は僕だけじゃなく、ソニックガーデンのプログラマはみんな気をつかっていると思います。
たとえば、作り始めたときのフレームワークのバージョンで固定して、その後はメジャーのバージョンアップをしないこともよくありますけど、僕たちはどんどん最新にしていきます。

倉貫
最新化を止めた瞬間から負債が溜まっていくから、やっぱりコードはずっと改善し続けなきゃいけないよね。

遠藤
そうですね。なんかもう息を吸うように最新化してますね(笑)

倉貫
納品のない受託開発のように、お客さんのパートナーとして長期的に開発を続けている場合、事業のフェーズによって捨てる機能が発生する。そのときに「いかに捨てやすいか」は大きなポイントです
。

遠藤
僕はさっきも言ったとおり、「ソースコードは負債」だと思ってます。だから、捨てることに一切の躊躇はないし、お客さんにも「この機能いらなくない?捨てちゃおう?」って言い続けてるんだけど、ソースコードを資産だと思ってる人が大半なんじゃないかな。

倉貫
そうだよね。私は経営的な観点で、「ソフトウェア開発はPL化(※1)して考える」ことが機能を捨てやすくするために大切だと考えてるんだよね。
これまでのソフトウェア開発は、BS(※2)で判断しているケースが多くて、システムを「資産」として考えてました。そうすると、お金をかけたし・・・となって、どうしても捨てにくくなってしまう。
一方、PLでシステムを「経費」として見ると、作ってみたけどヒットしなかったときに「コストになってるから機能を捨てよう」という判断が、めちゃくちゃしやすくなると思うんです。
(※1)PL=Profit & Loss Statement:損益計算書
(※2)BS=Balance Sheet:貸借対照表


遠藤
なるほど、システムを経費として考える。その考え方は納品のない受託開発だからできることですね。
最高に楽しいインフラ委員会

倉貫
遠藤さんは、ソニックガーデンのインフラにも中心的に関わっているよね。

遠藤
そうですね。うちは共通基盤があって、僕がメインでやっているRailsについては、基本的にAWS(アマゾン・ウェブ・サービス)上で動いています。

倉貫
普通のシステム会社だと、プロジェクトごとに毎回ゼロベースでシステム構築をすることが多いじゃない?

遠藤
ですね。ソニックガーデンだと、個人でインフラ設計することはないですね。共通基盤で必要なリソースはほぼ自動で作る仕組みになっているし、常に改善しながらその時点での最善の構成にしているので、「インフラ構成で悩む」というフェーズが存在しないです。

倉貫
お客さんも、インフラの運用を気にしなくていい状態。共通基盤を管理する上で、ソニックガーデンらしさってどんなことだと思う?

遠藤
インフラが好きな人やインフラに強いメンバーが数人集まって、基本的な部分の仕組みや、安定運用するための改善をし続けてることですかね。社内では「委員会」と呼んで定期的に集まって活動してます。

倉貫
私たち自身が100社以上のお客さんを見て構築してきた運用基盤だから、非常に効率性が良くて、信頼性が高い運用の仕方ができているよね。

遠藤
そうですね。今もいろいろな新しい概念を取り入れて、時代について行けるように毎週ワイワイしながらいじってます。そうやって、足回りすら自分たちで改善していけるっていうのが最高に楽しいですね。


倉貫
環境自体を自分たちで作り出していくって、プログラマにとっては楽しい仕事だよね。インフラ委員会のようなチャレンジの場で新しい技術を試すことができるし、それをお客さんとの開発に取り入れることもできる。

遠藤
僕にとってはインフラの改善は趣味でもあるし、仕事でもあるし、なんだったら遊びでもあるんですよね。
当たり前ではあるけど、自分のやるべき仕事をして成果を出すことは必要です。その上で、個々人が興味関心のあること、好きなことにも自由にチャレンジしていいのがなにより楽しいなと。

倉貫
さらにインフラまわりが共通基盤だから、遠藤さんが新しいチャレンジをして改善するほど、他のメンバーも喜んでいく良い循環になってる。

遠藤
どこかを便利にすると納品のない受託開発をやる上での労力を下げることができて、みんなの力を別のところに使うことができますからね。

倉貫
受託開発とインフラの改善を両方できる環境ってすごいことだよね。

遠藤
うん。やっぱり自分の意志で全部できるってのがいいですね。遊ぶように仕事をしながらみんなのためにもなって、お金までもらえる。
みんなの趣味や好きなことは少しずつ違うから、それぞれが力をかける場所はバラけるんです。そしてソニックガーデン全体として見ると大きな円になるのが最高に面白いですよね。
「内製化」のハードル

倉貫
ソニックガーデンのインフラ委員会って、内製の仕組みと考えられるじゃない?私はWebサービスの開発会社は、「内製」で改善し続ける開発スタイルが一番良いと思ってます。 内製だと社員がずっと開発に携わることになって、納品が存在せずにエンハンスし続けることができるからね。

遠藤
最近は、事業会社でも内製で開発することが当たり前になってきてますよね。

倉貫
とはいえ、お客さん側で内製化ができない事情や状況もよくある。そもそもプログラマの採用自体が難しいし、プログラマのキャリアパスやマネジメントが事業会社のビジネスモデルと合わないことも多い。

遠藤
たとえプログラマという仕事が好きでも、事業会社で出世をするには管理職にならないといけないことが多いですもんね。


倉貫
そういう内製化が難しい会社に対して、僕たちが内製チームのような形で開発を提供しようというのが納品のない受託開発のコンセプトの一つなんだよね。だからこそ、遠藤さんのようにお客さんと二人三脚で頑張るとか、お客さんと同じ目線に立つことがソニックガーデンのプログラマとして価値を発揮するために重要になる。

遠藤
たしかに、お客さん側のメンバーの一員として関わっていますね。

倉貫
そうなると、もはや事業会社のプログラマとして内製する道は考えないの?って疑問が出てくるんだけど。遠藤さんはどうしてソニックガーデンで納品のない受託開発に取り組むことを選んだんだろう?
ソフトウェア開発では、様々なチャレンジをしながらコードが負債にならない形にまとめ上げることを大切にしているという遠藤さん。「内製チームのような開発を提供する」納品のない受託開発に取り組む中で、フリーランスや事業会社に所属することとの違いを聞かれることも。遠藤さんがソニックガーデンで働くのは「背中を預けられる人がいるから」だと答えます。
(第4回につづきます。)
文=小野寺ちひろ(ソニックガーデン)/編集=マチコマキ