Webサービスが沢山の人に受け入れられると、そのソースコードは長く運用ができる。外れると、気軽に廃棄することができる。
既にPHPやPerlで書かれたWebサービスが10年以上ビジネスに貢献している事例は沢山ある。Webシステムは気軽に作れて気軽に廃棄できます、というフェーズを超えている。そのコードが長期にわたって沢山の人に貢献し、かつ、それを維持することで沢山の人がお給料をもらっている事実が存在する。
もしそのサービスが、最初から10年動くことがわかっているなら、どういう技術を選ぶべきだろうか？
Web業界の問題は「最新のネタが欲しい、新しい話題を作りたい」と思っている人たちの影響で、その構成要素である開発言語がレガシーな技術になってしまい、人材採用の足かせにになるという構造的問題が起きること。「10年持つ技術」とは？を考えると、「10年人気を維持できる技術」という論点にすり替わってしまう。
新しく作られた会社はいつも有利だ。今、新鮮な技術を採用するだけで、あたかも先進的な企業のように振る舞える。
新しい会社にとっては新規の人材を獲得する格好のネタになり、成功した歴史ある起業には、自社製品が何故か足かせになってしまい人材採用がしにくくなる、という問題はなかなか悲しい状態と言える。
例えばこういう記事
PHP、かつてWebで人気だった言語が下火になりつつある | ReadWrite Japan
じゃぁ人材採用のために、成功したサービスの開発言語を変えることがあるか？というと相当それは難しい。
どのフェーズにおいてもサービスの実装を大幅に変える決断は辛い。もし変えるなら早ければ早いほど良いが、そこに人をアサインしている間、確実にサービスの成長は止まる。理想は完全に２ラインを持たせて、同時並行で開発することだが、それも大抵のケースで、新しいコードに既存のコードでは起きなかったバグが出る。それはもう覚悟の上で進めていくことになる。
サービスの成長率のことを考えると、コードが少ない時のほうが、コードは沢山あって、技術者にとっては作り直しは辛いものの経済的に潤沢な状況よりも、言語変更の決断は難しい。コード量が少ないフェーズのほうが、１人日がサービス存続に与える重要度が大きいからだ。つまり最初の１行を書く段階で、ある程度先までの運命が決まると言っても過言ではないだろう。そういえばニコニコ生放送は、PHPからScalaに変えたんでしたっけ。お疲れ様です。
ドワンゴ吉村総一郎氏「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」@デブサミ2014 2日目 – tchikuba’s blog
サービスの実装言語を変えて後の技術者ブランディングにも成功した会社はcookpad社が有名だが、cookpadは元々ColdFusionで、国内の人材採用に先がないことは見えていた言語だったため苦渋かつ比較的容易な決断だったのではないだろうか。もし最初からPHPで書いてたら、今のcookpad社はあっただろうか。
（昔、創業者の佐野さんのお話を聞くという勉強会に参加した時の感想として、主婦向けサービスというUXを最優先にしている会社さんで、技術者のための技術選択はないと思っている。今、最先端で走っている技術は、あくまでもUX実現のための手段だと言う認識を持っている）
と、こうやってPHPをネタにすると、そこは、はてブ的な言論には確実な地雷であり、いろいろ言われるのはわかってて書いてるが、大切なのは、こういう感覚であるが故に、Perlだってレガシー化してる局面に入ってるし、Railsだって、いつまで今のホットな状態を続けられるかどうかは謎だということだ。
もちろん技術的なトレンドやパラダイムシフトを超えて、技術が変わっていくこともある。それは仕方のないことだ。
しかし、やっていることや成果物が劇的に変わるというわけではない範囲で、価値観ベースで死んだと言われてしまう状況というのは、それがオープンソースの生態系の特徴だったとしても、成果物側から見ると、なかなか辛い。
もちろん解決法は、だから既存言語でもいいじゃん！という価値観を強制しよう、という話ではない。
１つは、技術者が成長する視点を「そのサービスに関わっているからこそ得られる経験である」という部分を意識していくこと。会社に技術を売る実装屋ではなく、お客様に優れたユーザ体験を提供する「Webサービス」を作っているんだ、という自覚を持っていただく。
もう１つは「どんな言語トレンドでもどんとこい」という自信をつけていくこと。技術的興味を維持することは大切だし、また、技術的に置いて行かれる不安感を解消するためにも、仕組みが必要だと思っている。
また聞きなので名前は差し控えるが、ゲームで成功したある会社さんは、ゲームの大作の合間にミニゲームを大量に作ると聞く。それは戦略に基づいているというよりも、息抜きのように好きなものを作ってもらうという意図だと聞いたことがある。
同じように、自社のサービスのアーキテクチャ自体に多様性をもたせ、その先のものであれば好きな言語で機能を作ることができる、その代わり責任を持って、引き継げるように勉強会をしたり、普及活動もしてね、というのもよいかもしれない。（もちろんその責任とは限定的な意図としてね）。トレンドになっている言語であれば、情報も沢山あるので、そういうのはすごくやりやすい。
それに新しいサービスを作ろうとした時に、いつまでも古いアーキテクチャに縛られるのは避けたい。事業としては「最短で作れること」が求められるからこそ、多様な技術に触れている技術者がアップしていることこそが、最新技術で最短リリースを実現する選択肢を増やす。
あと、人材募集でよく思うのは、「Railsが好きな人、ウォ(ry…」という人材募集メッセージは短期的には良いが、長期的には、その価値観を自社の魅力へと転換していかないと、技術トレンドの変遷に影響され、その人材を失うリスクもあるのではないか。短期的に成果物を作るほうが優先だというのであれば、受託や人材派遣に頼むというレベルで、ガーッと行くのはもちろんありだが、「一緒にやっていく仲間」を募集するなら、あくまでもサービスの理念への共感を求め、技術で釣らないほうがいいように思えるのだが、どうなのかなぁ。
まぁでも多くの技術者はやっぱり技術トレンドを大切にして、それについていくことで自分の市場価値を維持したいという気持ちがあるのもよくわかるので、それの方がいいのかもしれないが、そこはWebにおいては、永遠に付き合っていくべきところなのかなぁ。ここは少しお悩みポイントですね。他社さん事例を見て勉強させていただきます。
最近、セルフブランディング的に「言語に詳しい人」という先端を走ってた人が、自分でビジネスを始めたり、新旧交えた多様な技術を扱うプロマネに転換しつつある動きも見ているので、ポジティブな意味での35歳定年説に符合しそうな部分ってのは、76世代ももはやアラフォーになっている今、起きているのかもしれません。そういう人が増えていけば、また空気が変わっていくかもしれないなぁとは思いつつ、いろいろ勉強していきたいと思っています。
ここに書いた関連する話として、Zerobaseの石橋さんが面白いURLを引用してたので貼っときますね。
ロードマップ指向とエコシステム指向 – アンカテ
