「受託っぽい」というネガティブワードをもう少し分解したい

Webサービス系企業の人が「受託っぽい」「受託のようにはなりたくない」という言葉があります。これはなんらかしらのdisというかネガティブな文脈を含んだ言い方なのですが、僕自身が受託出身なのでこの言葉には半分共感しつつも、あまり言いたいことを理解できているわけではありません。

とりあえず自分の限られた経験から紐解いて見ようと思った。

受託開発の良さ

僕の経験における受託開発の良さは、間違いなく新規技術に触れる機会が多いということだと僕は思っています。Webサービスは一度作ると、そのコードを元にサービスを拡張していくので、もはや当たったサービスだと１０年付き合うことも稀ではありません。最初の頃に選んだ言語やフレームワークは、その後のありとあらゆるところに、大きな影響を与えていきます。

僕が携わっていた受託開発は、もっとショートスパンの寿命のサービスが多かったり、比較的手離れが多い案件に携わっていて、なおかつ、僕自身が関わるサービスが、リスクの高いチャレンジ案件だったが故に、常にファンタスティックで、常に新しい課題に取り組んでいました。当時はFlash技術を応用した提案案件は、Flash技術の隆盛にあわせて連携企業のサイズが大きくなったり、当時流行ったリッチインターネットアプリケーションの文脈でSIerさんの案件にも携わったりして学びが非常に多かったです。要するに大手のSIerさんやネットインフラを提供している会社が、Flash技術に関するノウハウがないから、当時いた会社に依頼が来るという流れで、それの要件定義から設計、開発を僕がやっていたと言う流れが得られていたからです。

こういう流れの中にいると、技術の変化への適応については日常なので楽しいです。それこそ終電近くまで開発する日々も送っていましたが、むしろそれがチャレンジングで心地よい日々を送っていました。バッサバッサ次から次に来る案件を切っていくようなイメージだったかもしれません。

今でも、「技術」を学ぶなら受託から入ったほうが良いという理由はここにあります。（もしくはソシャゲで鍛えられるコースもありそうですが。いずれにせよエンジニアにとっては比較的ショートスパンの時間軸を切りひらいていくイメージはありますね）

ただし筋の良い会社であることが大切なので、社長との相性とかは大切だよ、と。会社のサイズが大きいことは問題ではありません。むしろ最近の受託は、大きなところはものつくりができないと聞いてるのと、ミドルサイズが少なく2〜30人規模かそれ以下の少数精鋭がよいのかもしれず、いい会社の選択はまあまあ人の出会いが求められそうな気がしています。

案件の並行本数と１プロジェクトあたりの人数規模感、案件見積もりの規模で大体会社の安定性とか体制が見えてきます。僕がいた会社では案件イメージ300万円〜2000万円だったのかな。同時に数案件回していました。BASEに関わってみて、Webサイト作るのに300万円〜の初期投資ができる企業は決して小さくない企業だと思います。そういうお客さんにファンタスティックな提案ができる社長がいたところってのが、僕が唯一知ってるパターンでした。

受託開発を辞めてWebサービス企業に転職した理由

これは僕自身の変化に伴うものだったと思います。僕自身が技術に興味があったというよりは、元々、Webが人の生活にもたらす影響について携わりたいという趣向があったので、比較的単発で継続的ではないWebサイトの案件に飽きてしまったというのがあります。今は継続的にパートナーシップを生んでいく会社も少なくないし、多分、当時もあったので、僕がいた環境がそうであったというだけです。
ただ、そうでなくても、受託はお客様の依頼で成立するビジネスですので、自分がお客様がうまく説得できない時、とりわけ技術変化が混沌としているタイミングにおいては、パラダイムシフトをうまく説明する能力がなく、そこを棚に上げて「だったら自分の責任でコードを書きたい」という気持ちが強くなっていったように思えます。まぁ若さもあったかもしれないですね。

またそれ以外の理由でも、当時は若干病んでたというのは大げさまでも、病みかけてはいて、それなりに期待されている立場と役割を捨てて転職することに罪悪感はありましたし、それでも転職しないとと思ってエイヤーで動いたというのがあります。

転職します。

改行してなくて読みにくいのは病んでたわけじゃなくて、転職元の会社にあまり読まれたくない、申し訳ないという微妙な心理があったからですｗ

この時にもたらそうと思った変化としては、自分の幅を広げたくて、大学院に通おうと思って、仕事しながら通えそうなMOTの大学院の説明会を受けていたがあります。ただ、僕がやりたかったのは、「コードは考えれば自分で書けるから、Webサービスを作れる人間になりたい」というもので、どちらかというとクリエイティブに対する渇望だったため、薬のベンチャーとかゲノムとか割と大企業の社員が通う向けのカリキュラムで構成されていたMOTには結局行きませんでした。その代わりの転職ということになります。ここでMOTに行かなかったことは、その後にモバツイを作り、さらに8年後ぐらいにKMDに入る流れを生み、結果ドクターの学位を取れたので、これはこれで正しい選択だったと思います。

Webサービス企業に入って学んだこと

ずばり継続的にWebサービスに携わるということを学びます。それは安定的にサービスを提供し、ほおっておけばサーバは壊れたり、実際、目の前に流れているデータが増えてパフォーマンスが劣化していくことに関する面倒を見たり、改善したり、安定性を維持するためのサーバ構成を考えたりなどです。障害が起きた時にどうやって解決するか？を考えるのも、こう言ったら怒られますが大好きな仕事です。もちろん目的はビジネスを伸ばすこと。

当時から自分はそれなりの役割だったので、企画や仕様について自分で考える立場にいたので、責任と自由がそれなりにあったと考えています。Webサービスのプロデュースとエンジニアリングという視点で関わり方を学ぶことができました。

開発言語系のイベントでもWebサービス系企業の発表が多いことからも一つの技術を深堀りするという視点ではWebサービスのほうが腰を据えて取り組めるというメリットはあると思います。というか技術ブランディングをして、その技術を守っていくことが自社が採用したミドルウエアやプラットフォームを延命していくことにつながっていくので、運命共同体になるという視野でも時間を使えるということになるかと思います。

その辺のエンジニアリングマネジメントの考え方も面白さの一つ。ここが今は当たり前になってしまってるから僕の中で若干麻痺してるかもしれないですね。

という経験から、受託っぽいってなんだ？

ここで言う「受託っぽい」というのは、自社サービスに比べて受託ではできないこと、そうなりがちであることにおいてネガティブポイントがあるから言われるのでしょう。

あえてつたない自分の体験から洗い出すと、

・自分の選択がしにくい。お客様の判断に依存する。
・ありがちなイメージである「言われたことだけをやる人になったらつまらない」

ということでしょうか。つまり考える余地がないと思いこんでしまう人になるというイメージでしょうか。確かに、そういう人はいますね。お客さんの方にいるネットワーク屋さんとかで、とにかく楽をしたいみたいのが見え透いている人とは仕事したくないと思ってました。

ところが、技術サイドにはもう少し考えなきゃいけない余地があって、実際はお客様の依頼に対して技術でどう叶えるかという自由があるので、実はそんなことないと思ってしまう自分もいます。これは視点の違いかもしれず「Webサービスを作る人」と「技術者の矜持」と言う視点では、同じ状態であっても差があるかもしれないですね。

多分、僕がこの言葉を聞いて悩むのは、当時、技術者としての矜持は満たされていたけど、Webサービスを作りたい人としては満たされない状態になったから転職したというあたりがあって、この言葉については余計に悩んでしまうのかなと思ったりしてみました。簡単に言うとWebサービスのエンジニアと受託のエンジニアは同じに見える部分が少なくないと思ってしまってる自分がいます。

プロダクトオーナーやプロダクトマネジメントをする人の要望に技術で応えるという側面と、受託でお客様のシステムの叶えるという部分は技術者としては大して変わらないと思っている自分がいるんですが、どうなんですかね？？多分、技術という武器を通じて、人の期待に応えたいというのがエンジニアたる部分なのかなと思ったりするのだろうけど、どうなんでしょう？

あとはその人に何を期待するか？という期待値の差もあるかもしれないですし、ジョブディスクリプションの問題なのかな。いずれにせよ、みんな、そもそもどうありたいのか、もう少しいろんな人と話してみよ。

p.s.追記だけど、とはいえエンジニアの面接で受託から面接来た人達に「１文字変える仕事に意味や楽しみを持てないとWebサービスはつまらないよ」と言っているかも。これこそが継続的にWebサービスを維持するという意味なので、ここの言語化は必要か。