新年あけましておめでとうございます。紆余曲折してはてなぶろぐにもどしてみました。この一つの所にとどまれない感じ、自分の性格があらわれてて残念ですが…それはさておき。

2014年に30歳を迎えたので、冬休みで暇っつーこともありますし、なんとなくこの10年間を振り返ってみようかなぁ、と思います。 この10年を振り返ってみると、本当に多くのイノベーティブな技術が世界中で共有され、あたらしいサービスやモノをどんどん生み出してきました。

IT企業とオープンソースはもはや切っても切れない関係でして、オープンソースと共に歩み、オープンソースの発展になにかしら貢献してこれたのではないかと思っています。大きな成功を共有できればそれが一番かっこいいのですが、小さなコントリビューションをしたり、失敗を共有することも大切な貢献でもあると思っています。

それとそれと、ぼくが一番大切にしているTechnologyのいちばん根っこの部分はエンジニアとして働いていて楽しい、というのと、大好きな人たちを守るために学び続ける！ということです。まぁテクノロジーという武器をつかうなら幸せにしたいよね、という。そうなるとやっぱ勉強しないといけない、ということで次の10年にしっかりと意識を向けるために、この10年を振り返ってみたいと思います。

tl;dr

まぁそんなに有用なエントリというわけでもなく、ぼくの思い出補正で書いてるだけなんですが:

• オープンソースにとって激動の10年を振り返る
• 当時生まれた技術的負債について考える
• エンジニアみんながCTO視点になるためにできること

ということをかいています。ひさびさにはてなぶろぐに戻って書いたのがエッセーかよ、みたいなツッコミは置いておいて。

技術的な資料として多少は価値があるようなものを載せているだろう、と思っているのでご勘弁を。また、グラフに関しては温かみのある手書きですので厳密ではない値の部分などご容赦願います。

はじまりはPHPから

とりあえずぼくの歩みをふりかえってみると、PHPとは切っても切れない関係だったりします。僕がエンジニアになった頃、といったらPHP4がリリースされていくばくかの年月がたち、WEBサービスを作るにはどうすればいいか実際に実験しつつ過ごす日々だったりしました。

考えてみれば今働いているグリーとぼくとの出会いもオープンソース活動がきっかけだったりします。あー、そういえばPHP勉強会でふじもととあったのがはじめてなのかなー、と（こじつけ）

激動の10年間 技術的負債とのつきあいかた

いやしかし、今はGithubをはじめとしたオープンソース活動に参加しやすい文化がありますので、若い方にはあまりそんなギャップに実感がないかもしれませんが。当時の記録を見返しても分かる通り、あの時代はオープンソース活動に参加している人が今ほど多くはなく、どのコミュニティでも人が足りない状態でして、だからこそ、どんな簡単なことでも手伝えば喜んでもらえますし（今でもそうですね）、それに返事を貰えるのはコミュニケーション取るのが苦手なぼくらにとって単純に嬉しいものだったりもします。

なんだかよくわからないですが、オープンソース・ソフトウェアを良くしていく活動を通して、国も言葉も立場もまったく違うひとたちが、ひとつのものを良くしていこう！と行動している事実にきっと心動かされた人も多いのでしょう。ぼくもそのひとりです。

はじめてのPull Request送るのに1時間ぐらいかんがえながら送ったりしていたのがいま思い返せば懐かしいです。

過去の記事を調べる限りですとグリーCTOのふじもとも、そうしたオープンソース活動を積み重ねながら、はじまって間もないグリーと出会い、これまたよくわからないけどサービスへの本気の情熱を目の当たりにして開発に関わっていくことになります。あのころはまだWeb開発の定石というものも定まっておらず、「とりあえずあのフレームワークで」なんてこともなく、というかリポジトリ管理にはCVSを使ったりしていましたし（なつかしい！）、そうしてEthnaというPHPフレームワークを作りながらサービスを作っていったのです（今のEthnaはぼくが最低限新しいPHPで動かす、ぐらいでしかメンテしてませんけど。今となっては新しくて洗練されたFrameworkなんていっぱいありますし、そっちを応援するっていう時代なのかな、と）

今も昔もWebサービスが当たった時のトラフィックの増加量なんて変わりませんが、当時はAWSもまだありませんでしたし、一度ヒットすると想像を超えるスピードで増えつづけるトラフィックを処理し続けなければならず、サーバーの発注数をがんばって計算しながら負荷計算をしたりしていたので、ああいったケースではCでゴリゴリ書いてしまえ！という力任せなアプローチもコストを抑えるよい選択ではありました。

しかし、そうした技術が、いざ進化に追いつこうとする時に大きな足かせになったりしてったりもしたので、組織としての中長期的な技術選択はほんとうに難しいなー、と思います。

（いままでぼくがやってきた経験則から感じてるイメージ）

サービスが成長していく為の技術的なイノベーションと、それに応じて発生する望ましくないコードをどう改善していくか、というのは今後もエンジニアとしてサービスにたずさわる上で、ずっとありつづける大きな課題になると思います。いき過ぎたテクノロジーはいつか誰にも手がつけられないものなります。

とはいえ、Facebookみたく負債に対してガチInnovationでひっくり返すと手法もあるのがIT業界のいいところでもありますが。

テクノロジー選択のジレンマ

そんなこんなで、インターネットの爆発的な発展と共に育ったぼくたちのサービスはPHP4と共に育ち、サービス成長の影響からPHPの発展速度に一時期追いつけなくなります。恐らく2004年前後に生まれたサービスはこうしたジレンマを抱えていたのだと思います。

(一般的に言語の最新バージョンが商用環境に入るのは1〜2年ずれることが多いです)

PHPの言語仕様もどんどん前進していきましたし、DebianをはじめとしたLinux ディストリビューションも、計画にそって数年単位で変わっていきます。言語が変わるだけならまだしも、ディストリビューションの提供するパッケージが変わっていくとライブラリも全部更新されてしまいます。

もちろんPHPでも多くのCライブラリを利用しており、バージョンによってはPHP拡張の挙動が変わってしまうという問題にも当たったり（本当に辛いのなんの）これはまさにこの時代ならではの技術的負債（Technical Debt）だ、と実感するようになったのはこの頃からです。

さて、ひとえに技術的負債と言いますがあの時代は（ぼくだけかもしれませんが）とても特別に感じていて、純粋にアプリケーションだけの問題であれば、返済計画はまだそれほど難しくありませんが、基本となるOS、付随する関連ライブラリの変化、変わり続ける言語仕様、はてはユーザー環境までどんどん変わり、そんななかでの改善となるとやはり難易度がとても高いものとなってしまいます。そんな状態になるだろうなんて誰が想像できたことでしょう。

その後会社も大きくなり、エンジニアの数も多くなるんですが、それと同時にプロダクションのコードはそのままどんどん膨らんでいくのです…

なんだか霧がこくてあまり画面が見えない…のでこのはなしは一旦おいておいて

この10年のIT技術のうつろい

当時、世の中でどういうことが起こっていたか、というとGoogle File SystemやMapReduceの論文発表がされてから数年経過し、Hadoopが生まれ、気がつけばビッグデータ処理が一般的なサーバーで動作できるというイノベーションが生まれます。

インターネットとオープンソースの発展により、まさに爆発的な勢いで環境が変わっていく激動の時代を過ごしてきたわけです。当時小さくても数百Gバイトもあるデータセットに対して現実的な手段で分析ができるなんて、考えてもいませんでしたし、いやはやほんと素晴らしい時代に生きてるんだなと思います。

とはいえ、そんなめまぐるしく進化し続けた中で技術的負債をうまく返し続けるノウハウなんて、たぶん、あの当時誰も持っていなかったんじゃないかと思います。みなさんが崇めているレガシーコード改善ガイドは2004年の著書ですし、ちょっと時期的にあの超絶的な技術の拡大よりはちと早いんですよね。 レイヤを超えて複雑に絡み合った課題を返す方法に銀の弾丸なんてない、というのはわかりきったことですし。そうした業界的な成長の背景もあり、技術的負債を溜め込みがちになってしまったのも仕方なのなかったことなのかな、とも思います。

理想的な形ではないけれど、それもまたサービスのひとつの形なのかな。 ほら、人間数十年も生きれば身体のどっかしらは調子悪いところとかでてきますし、全部が理想通りなんてムリなんで、変えることは難しくともなにか別の形で補えればいいんじゃないかな、と僕は思っています。

OSSの爆発的な成長の理由を探す

唐突ですが、あの時期はなぜ移り変わる速度が速かったのか理由を考えてみます。2004年にRailsが生まれ、2005年にはGit、3年後の2008年にはGithubが公開されました。Githubが出来たことによりオープンソースへの参加の敷居が大きく下げられ、オープンソースソフトウェアが育ちやすい土壌になったことも大きくあると思います。

もともと自社の作ったものをどんどんオープンソースとして出していこうという流れ自体は以前からありましたが、RailsやGithubが大きな追い風になったのはまちがいありません。今じゃ当たり前になってしまいましたが、Githubで活動していることがカッコいい、なんて時もありましたね。

時期的なものは多少前後しますが、現在も有名なオープンソース・ソフトウェアをあげさせてもらうとjQuery, Markdown, MessagePack, Thrift, ProtocolBuffers, Google Chrome, Puppet, Chef, Cocos2d, Cassandra, Redisなどでしょうか。 思い出ベースでつらつらと書きだしてみたので生存バイアスが大きくかかっていますが、図にしてみるとこんな具合です。

(曖昧だったりするので多少公開年ずれてるのあります。)

2008年前後に公開されたオープンソースソフトウェア達はタイミング的に本当に素晴らしく、先端企業でしか扱えなかったビッグデータ処理のためのオープンソース・ソフトウェアが出始めたり、先行アイデアから派生したミドルウェアやサービスも沢山生まれるわけです。

当時を振り返っても、大きく成長した組織はオープンソースの流れをうまく乗りこなしていたと感じています。成長途中で丁度必要なオープンソースのミドルウェアが出てきたりする、なんてのが日常だったのでとてもエキサイトな日々で、いやはやRedisとかすごく便利だったので、やっぱりみんな同じような問題を抱えていたのだなと。

こうした歴史から分かるようにもはやIT関連企業の成長はオープンソースの成長無しでは語れなくなってきています。たとえば、自社用のツール的なサービスを内製でつくるかどうか、という点に限定しても、恐らく自社で必要になるようなツールは他の会社でも必要になるでしょうし、そうなるといつしか似たような物がオープンソースのライブラリや、サービスとしてでてきます。

例えば外製のオープンソースのソフトウェアを選ぶにしても、これからじぶんたちのサービスが運営され続ける間は少なくとも一緒ですので、何故作られたのか、何を目指して活動しているのか、とった背景を知ったほうがそういったリスクの判断がより正確に行えます。

下手にベンダーロックインしてしまった挙句、向いている方向が違った場合は自社の開発が鈍化してしまう、なんてこともありますのでよりシビアに見ていかないとリスクだと感じています。

また、自分たち特有の問題がでて改善を加えた場合に、OSSプロジェクトとの利害が一致しないケースも当然考えられるので、使うだけでなく、日頃からよい関係を築いていかなければ最悪なんともしがたい技術的負債をつくってしまいがちです。

こうしたことから、外製のライブラリ・サービスを使う場合は

• 自分たちのサービスにとってどれくらいのインパクトがあるか数値を出す
• 代替できるソフトウェア、競合はどれくらいあるのか洗い出す
• 何に依存しているのかを洗い出す（特にCのライブラリを使う場合)
• どういった思想・開発体制なのかをはっきりと書き出す
• 将来的におおきな改変があった場合追随できる体力があるか考える
• もし別のものに変更した場合どれくらいのコストがかかるのか数値を出す

といった、より確率的に失敗しにくい方法を前もって考えておいたほうが健全です。なんだか、そんなこと当たり前じゃないですかーという天の声が聞こえてきますが、ついついサービスをつくってるタイミングだとこういう面倒くさいことは後回しにしてしまいがちです。でも、ときにはそんな細かいこと考えずに大胆に動くのもひつようです。

オープンソースと共に生きつづけるには、どうすればいいか。
ぼくたちも常に変わり続け、お互い変化しあえる仲でありつづけるしかないのです。

変わり続けなければ最後は何も身動きできなくなってしまうか、多大なコストを支払って一括返却する必要がでてきます。オープンソースについていくだけでなく、一緒に年齢を重ねていく必要があるのです。2015年以降、オープン化していく開発スタイルの中でそうしたDeveloper Relations的な外部に対しての活動もとても重要な位置を占めてくるでしょう。

次の10年を考える

どんな人であれオープンソースに参加できる文化や、ビッグデータを手軽に扱える土台が整い、巨大なデータセットに対して数クリックで集計が行える世界にぼくたちは生きています。今まで考えもしなかったことができるような時代に生きており、次の10年もきっとそんなわくわくするようなイノベーションで溢れるのだと思います。

一方で、いちエンジニアの視点で考えると、今のIT系エンジニアという職業は覚えることが多くとても大変だな、とも感じています。

もともとこういう技術系の商売なんて勉強し続ける職種なんですけど、2000年の頃はHTMLとプログラミング言語とあとちょっとSQLチョット分かればやっていけましたが、2014年となった今は必要になってくるスキルセットがWeb方面の基礎技術に加え、2D/3D描画系の知識が必要になったり、はたまたビッグデータからの分析手法をしらなければ運用面で立ちいかなくなったり、そうなると数学的な素養がないと理解できなかったり、とか。自分の専門領域に加えて他の分野も知っていかないととても辛い、というのはより強まったと思うのです。テクノロジーにかぎらず、きっと英語とか数学とか切羽詰まりながら学習しているのはぼくだけじゃないはず。

いや、知らないことを覚えるのは楽しいからいいんですけど。

そうはいいつつも、専門系の知識はクラウド系の運用サービスを使えば自分たちでやらなくてもおまかせできたりしちゃうご時世ですので、なんだか逆に選択が難しくなっただけのような気もします。ただ、外部サービスに任せっきりとなると今度は適切なタイミングで脱出しないとサービス拡大したときのコストが多くかかってしまいますし、いざ自分たちで運用できるかっていわれると、そんなのノウハウないとムリですし。

そうしたなかで、ぼくが思う素敵なエンジニアとしてやっていく上で大切な事は:

• どうすれば何ができるかという引き出しを沢山つくる
• 貯めこむだけではなく、かならず自分で考えながら1回はやる
• 必要なタイミングですぐ問題解決のアイデアが出せるように日々整理する
• 仮に自分がCTOだったらこういう考え、判断をするだろう、という思考のトレーニングをし続ける
  • 具体的にサービスのライフサイクルを考えどういった技術や行動が最適化を考えたり
  • 自分や周りが与える影響を良い方向にするにはどうすればいいか考える

ということを常日頃からやっていれば少なくとも大きな失敗はないかな、と、思います。 対外的な評価はなくてもすごい人世の中にいっぱいいるんで、5年後、10年後の自分どうありたいかをきちんと書き出して、それができるように毎日励みましょう。ぼくも着実に行動していきたいと思います

ということで、みんなCTOになろうよ

(起業しようぜ！ってコンテキストじゃないよ＞＜)

どんなエンジニアであれ、必要な技術をその時その時に応じてすぐに判断して、チームや会社をリードしていったり、モチベーションをコントロールしあったり。今後はそういった、より現場に近いCTOとしてのエンジニア力を養うのが必要不可欠になると思います。これからもどんどんスタートアップの企業が増えると思いますし

なにより、同じ方向を向いて走り続けられる仲間が沢山いれば、企業として大きな競争力になりますし、 それにエンジニアとして働いていて社内とか周りにCTOのように相談したい人がもっともっと身近に居たら世界はもっとおもしろく出来るのではないでしょうか？

チームでもなんでもいいんですけど、たとえばPHP CTOはこの人、MySQL CTOはこの人…みたいな。まるでCTOのバーゲンセールだな、なんて声がどこからか聞こえてきますが。 あ、でもそんな人がいっぱいいたらそれはそれですごく面倒くさそうですね。えらい人の胃をキリキリさせちゃいそうです。

とまぁ長々とこの10年間を振り返ってみたり、趣味全開で好きなコト書いてみたんですがまとめますと:

望めばなんでも出来る時代にぼくたちは生きています

むかしはハードウェアのスタートアップなんて想像するのも難しい時代ではありましたが、今となってはWeb上でアイデアを公開して投資を一般から募ることもできますし、モックも3Dプリンタを使って作る、なんてことも十分実現できます。機械学習の分野でのスタートアップも生まれ始め、技術が交差する瞬間というのは本当に興味深い事がたくさん起こるのです。

いまよりもっと面白いサービスを提供できるようにとことん大好きなことを楽しんでいく。

言葉ではうまく説明できないけれど、それがサービスクリエイターとしてのぼくたちのこころを突き動かしていく神様からもらったMissionなんだと思います。

さいごに

オープンソースと共に生き、共に成長する中で。次の10年どんな楽しいことがおこるのか楽しみにしつつ、日々進みつづけたいと思います。 いや、ほんと年を重ねる毎に自分の時間捻出するのが大変になってくんですが、昔尊敬していた先輩は「1流なら好きなことのために時間をなんとかして作るんだ」なんて言っていたし、実践していたのでぼくも精進したいと思います。

それでは、今年も楽しんでコード書いていきましょう