先日、某SIコンサル社にいる方が、まだ転職を悩んでるという前提でのカジュアル面談に臨んだ。その人の転職理由というのは、僕が受託の会社から転職した時に言っていたこととそのままだったので、是非、本面接に進んで欲しいと思った。
その一方で、受託からWebサービスに来る人に、よく言うことして、
「受託からWebサービスに来ると、ファンタスティックな案件がなくなってつまらないかもしれないですよ」
と言う話をする。これはどういうことか？というと「技術的チャレンジ」を求めるならば、筋の良い受託の会社にいる方が楽しくて、Webサービスはコードを書いている瞬間から技術的なレガシーを産んでおり、先々に渡って最初の選択の影響を受けるので、あなたの技術力の定義が「話題の言語でコードを書けること」であるならば、Webサービスはあんまり勧めません、という話をする。
当時僕がいた会社は、技術の共通化がまだ進んでおらず自由だった。社長が新しもの好きで、提案力が高いので、面白い案件、不確実性の高い案件がバシバシやってくる現場で、若手だった僕らはワクワクしながら仕事をしていた。
僕自身が不確実性の高い案件にアサインされる立場だったので、案件ごとに使いたいと思った技術を提案しやすい立場だったのもある。
とあるFlash動画の案件では、Flash Communication server（今で言うFMS）と、JRunの組み合わせでログを取得するための動画プレーヤーコンポーネントというのを、Flashのライブラリを活用して作ったが、その際の交渉では、「最後に僕が責任を取ります」という言葉を言うことで、不確実性の高い技術が割と自由に採用できることを知った。FCSはFlash動画のストリーミングサーバにも使われているもので、ノンブロッキングなI/Oでマルチスレッドプログラミングによる処理ができる。
今で言うnode.jsやらFluentdみたいなものを作ったといわけ。それをDBに保存するところでJrunを繋ぐことができるのが当時のマクロメディアのソリューションで、ActionScript2.0を使うとFlashコンポーネントから、一気通貫でサーバまでデータを送ることが出来るということで、それに乗った。
そういう状況で、割と好き勝手にやらせてもらっていたわけだが、とはいえ、技術選択ができることが楽しいというタイプではないので、それはそれで虚しいものがあり、Webサービス企業に転職した時に書いた記事が以下の転職エントリ。
丁度ペパボに転職する前でしたね。これまでPHPを触ったことがなくて、ペパボに入ってから初めてPHPを触りました。
コード書きにとっての受託か？サービスか？の分水嶺は、一番簡単なのは、後から発生する「１文字直すチケット」タスクに価値を感じないならサービスは向いてない可能性があるということ。
「その１文字を直す」のが、UXにとって有益であるならば、その１文字にこだわらなくてはいけないのがWebサービス。だから面倒臭がってもいいが、そのタスクに対する有益性はしっかり見出しているというのが、Webサービスにおけるエンジニアに求められる態度だ。
受託の場合は、「その１文字」を直すのに場所によっては、テストを含めた作業が追加になるので、お金がべらぼうにかかったりするので、すぐに直したくても直せなかったりする。
これが仕事として当然だと思うなら受託のほうが向いているのかもしれない。
受託は案件ごとに技術を変える余地があるし、案外作り直す機会も多いので、まるっきりスクラッチから作り直す機会に恵まれることがある。それがビジネスとして安定しているかは謎だが、新規の不確実性の高い案件が強い会社と、最近、東証１部上場になったメンバーズさんのように運用に思いっきりシフトしている会社も存在するので、受託と言っても一概にどっちとも言えないので、冒頭では「筋の良い受託」と表現した。何が筋が良いのかは価値観次第。
それに対してWebサービスで開発技術の言語を丸ごと切り替えるなんて話は、１０年に１度あるかないかのプロジェクトである。基本的には、それにともなう事業成長が見込めないのであればNGである。
基本的には、最初に選ぶところまでがハイライト。そこでの技術選択を間違えると、結構後々まで引きずる。
ということは、今は素敵な言語を扱うことができたとしても、そのサービスが「成功したならば」、必ずレガシー化する。先日のCookpadのYoshiori氏が年に１度は新しい言語を覚えるのは割と続けているという自己研鑽の話を聞いたが、それぐらいのペースで「イキの良い言語」が出てきてしまうのであれば、最新の言語なんて、サービスが有名になった頃には、その多くはレガシー化しかねない。最近だとgo言語あたりが評判が良いが、すでに話題はrustに移ってるし、P言語なんてのもでてきたね、と。
それ故に、経営者としては、ここに囚われていてはたまったもんじゃないわけだが、そうは言っても技術経営の観点では全くの無視もできないという、成功したWebサービスを長く継続するにあたって、悩ましい要素が存在する。
別に書いてるコードに求められるシステム設計力も応用力もほとんど変わらないのにね。
こういうのは若い野球選手のようなもので、毎年毎年、イキの良い新人がコロコロ出てくるわけなので、そこに企業ブランドの礎を置くのはあまりにもリスクが高い。
こないだ聞いた面白い話で、Webサービス企業が成功をすると、必ず自分達で言語を開発したくなる、という話を聞いた。
確かにそれは理解できる。結局のところ若いエンジニアに興味を持ってもらうためには、話題をしっかり掴んでいかないと存在感がなくなってしまうので、それなら自分達で言語を作って話題の中心になるか、話題の中心を維持しつけるために言語を改良し続けるという選択肢を取るのは自然だ。コミッターとして他社の人とすったもんだやって、スピード感が間に合わないというのが最悪なのだから、プロプライエタリ的に自分達のスピードで進める方が技術選択のリスクが低い。
やっぱり、そういうことは大事なんだな、と改めて思わされる話であった。
ところで、僕がペパボ時代に絡んでメインでコードを書いていたものにカラメルというショッピングモールのサービスがあるのだが、あれはいわゆるモールの検索画面の方と、ユーザーアカウントに連携する側でフレームワークが違う。
もうrailsに変わってしまったかもしれないが、多分、後から入った人は、「なんで、途中でフレームワークが変わってんの？」って思ったに違いない。
一応、言い訳をしておくと、前者は古いMVCの設計を踏襲したフレームワーク。いわゆるM+V+C+Logicが適切に分かれているもので、すこし設計が古い。当時で言うmovaviとかZendFrameworkがその辺に近しいか。後者はモバツイでも使わせてもらったrailsライクなフレームワークで、スピード感高くコードを書くことができる。意識しないとファットコントローラを作りやすい直感的な構造。たぶん、今メルカリさんで公開されているDietCube程度の薄いフレームワークで、使いやすさに惚れたので、途中の追加開発でFWを切り替えさせてもらいました。ただ元々あったコードを置き換える余裕は、そのタイミングでもなかった。
もう少し言い訳をさせてもらうと、僕にとっては、それぐらいの変化は「どっちもPHPのコード」ぐらいの感覚でしかなかったので、どうでもよかったというのが正直なところなのだが、当時の段階で、すでに後から入ってきた人には評判が悪かった記憶がある。ごめんなさい。
余談ながら、DietCubeを見た時に、「これぐらいのFWが一番バランスが良い」と思ったのが本音でありまして、モバツイのFWが薄いのは、少しコンプレックスでしたが、それはメルカリの成功を見て間違ってたことに気がつきました。あの頃が一番良かったです。イマドキのFWはちと重すぎますね。便利機能は沢山ありますが、新人に求められる構造理解の負荷が大変すぎます。サービスが成長してパフォーマンスネイティブになった瞬間に主従が逆転する感じと言いますが。
脱線しました。まぁ昔話の何がいいたいかというと、もし、いろんな技術で修行をしたいなら、受託の会社で素敵な案件をやっているところで鍛えられると、そんな程度のことは割とどうでもよくなりますので、自分が書いてるコードがレガシーコード化していくことが、明確に見えているWebサービスが本当に良いのか？は考えたほうがいいかもしれないですね。
少なくともサービスの成長にコミットができないなら、Webサービスという業種自体はあんまりオススメしないかもしれないですよ。
逆に言うと、サービスの成長にコミットして、「継続的発展」をしていくことに強い興味を持っている人であれば、言語の選択は表現技術の技法の一つでしかないことを知っているハズなので、こういうことで悩まなくてもいいはずなんだけど、みんなそこまで自覚するには、もしかしたら、それなりの経験が必要なのかもしれない。あと「世間で言われる技術力が高い人」というのはこの話とはまた直交した概念だったりするから、若い人の成長欲とは少し折り合わない。
そのあたりで、みんな、いつも悶々と悩むんですよね。
オッサン会話でごめんよ。
でも若者をどう惹きつけ続けるか？という部分は全然無視できないので、自分達が無理したり、本来のサービスを伸ばすところから余計な労力をかけない範囲で、ちと頑張らないとね、という話でした。多分、技術経営として、こんなことを考えなくてはいけないのはWeb系だけだと思う。
最後に、
これ、よく社内でも引用してる図なんですが。世間で言われる「有名なエンジニア」は、A象限、「サービスコミット力が高い」人は往々にしてC象限にいます。「B象限」が理想的な人材ですが、そういう人はほとんどいません。いたら即リードエンジニアとかマネジメント対象です。
ということで会社としては、理想を言えば「B」を目指して活動をしていくわけですが、割とあるケースとして「A象限、有名なエンジニア」は、「サービスコミット」にあまり興味がない人がいたりします。また、「C象限 サービスコミットが高い人」はあまり仕事で求められる技術以外の技術力の研鑽には興味がありません。また家族がいたりして、そこに時間を割く余裕がなかったりします。それ故に、人が辞めていくパターンは、A象限の人は、他社によりファンタスティックな技術を求めた場合が多く、C象限の人に難易度の高い技術を渡して、興味の範囲を超えると心折れて辞めていったりします。
それ故に、チャレンジはその人のペースを見ながら適切にね、というマネジメントが求められるわけですが、それはそれは大変ですね、というお話ですが、それは諦めてはいけないので、我々はこういうことを意識しながら、サービスの成長を実現する仕事をしていくんだ、という話です。
ちなみに、これは会社のフェーズにあまり関係なく存在するようですね。より有名な会社は有名なエンジニアで同じ経験をするようです。逆に言うと、入ってくれるエンジニアは、「その人のチャレンジ」が必ず連想していることが重要なので、チャレンジと我々のフェーズが折り合う人にジョインしていただくのが望ましいということです。
【PR】ご意見、感想などは是非、mstdn.fmのローカルタイムラインでお聞かせください