Dear Great Hackers

  1. PR
  1. 求人

チームラボエンジニアリングに聞く、受託開発で成長できるエンジニアとは?


エンジニアの就職や転職において、大きなポイントともいえる「自社開発」か「受託開発」か。

受託開発は「決まったものを作るだけ」「納期が厳しい」「辛そう」など、ネガティブなイメージを持たれがち。

自社開発の方が「裁量があり、いろんなことにチャレンジできるので、エンジニアとしてよりスキルやキャリアがつめるのではないか?」と思う方も多いのではないでしょうか。

最新のテクノロジーを活用したシステムやデジタルコンテンツの開発を行い、今年はお台場にデジタルアートミュージアム、豊洲に超巨大没入空間をオープンさせるなどアート事業のイメージが強いですが、受託開発でもスマホ対応自販機「acure pass(アキュアパス)」や「メチャカリ パーソナルスタイリング AIチャットボット」、「マルイウェブチャネル」など、数々の実績を残すチームラボ。

そのグループ会社としてエンジニアを採用し教育する役割を担う、チームラボエンジニアリングの創業者である森山洋一氏に、QiitaやQiita:Teamなどの自社開発を行うIncrements代表取締役社長の海野弘成が、受託開発の話を伺いました。

本質をしっかり理解したうえで開発する。最終的に利用するエンドユーザーの視点を持つ
チームラボエンジニアリングは、幅広く密度濃く成長できるチャンスに溢れている
1フロアまるごと仕切りなし。お客様との打ち合わせも、社内ミーティングもすべてここで
チームラボエンジニアリングにフィットする人材とは?
チームラボエンジニアリングで輝くのは主体性を持った人
対談を終えて海野から

プロフィール

森山洋一(もりやまよういち)
チームラボエンジニアリング創業者
1979年、東京都出身。文系出身で学生時代は米国留学などを経験。
社会人になると同時にプログラミングを学び始め、2007年チームラボに参加。Javaエンジニアとしてチームラボのキャリアをスタートし、その後、ソリューション分野における大規模案件や新規立ち上げ案件のプロジェクトマネージャーを多数経験。2016年2月チームラボエンジニアリングを設立。

 

海野弘成(うみのひろしげ)
Increments 代表取締役社長/Qiita:Zine編集長
1988年兵庫県生まれ。京都大学工学部情報学科卒業。 プログラマとしてGoogleやはてなのインターンを経験し、在学中の2011年にプログラマのための技術情報共有サービス「Qiita」をリリース。大学卒業後の12年2月、Increments株式会社を設立し代表取締役に就任。プログラマ出身の経営者として、プログラマが成果を出しやすい環境や自立した組織づくりを推進。

本質をしっかり理解したうえで開発する。最終的に利用するエンドユーザーの視点を持つ

海野:今回、チームラボエンジニアリングで行っている受託開発の“ホントのトコロ”を伺えればと考えています。実は私自身、受託開発を行った経験がなく実態と異なるイメージを抱いているかもしれないので、ぜひリアルなところをお聞かせください。

森山:受託開発/クライアントワークというと「言われた機能を、どう言われたように作るか」に注力しているイメージを持たれていると思うのですが、我々の場合は、ただ言われた通りに作るのではありません。「ユーザーにとって最適な体験は何か」「このサービスでお客さまはどう喜ぶのか」など、本質をしっかり理解したうえで開発するようにしています。お客さまからも「体験や構想の部分から一緒に考えてほしい」とご要望いただくことが多く、受託開発のイメージとしてよく抱かれるような、「この技術を使ってこのように作ってください」という案件は、実は少ないです。

私たちの受託開発は「ただ言われた通りに作るのではない」と森山さん。

海野:典型的な受託開発のイメージだと、作り手として「こうした方がより良くなるのに」と感じても、予算や期限といった制約があってジレンマに陥るイメージがありました。

森山:それはあるかもしれませんね。ですが、我々は最終的に利用するエンドユーザーの視点を持ち続けたいと考えています。というのも、我々の成り立ちが関係しているかもしれませんが、社内には営業職の人間がおらず、お客さまのご紹介で新たなお客さまとつながるケースがほとんどなので、「アウトプットをしっかり出す。出し続ける」ことを心がけているんです。

海野:営業がいないからこそ、作り手であるエンジニアとお客さまと直接コミュニケーションを取りやすいのですね。

森山:そうですね。エンジニアであっても積極的にお客さま先のミーティングにも同行します。社内のコミュニティだけで完結するのではなく社外に出ることで、エンジニアとしての視野も広がり、自身の成長になります。

森山さんから、一般的な受託開発のイメージと異なるお話が次々飛び出します。

チームラボエンジニアリングは、幅広く密度濃く成長できるチャンスに溢れている

海野:エンジニアの成長という観点では、「納期が厳しい」「決まったものを作る」など、受託開発の現場では技術的な追求やチャレンジがしづらいのではないかと懸念している方もいるのではないかと想像しますが、チームラボエンジニアリングではどうでしょうか?

森山:私たちは、案件ごとに人をアサインしてチームを組むというスタイルを採用しています。案件軸でチームを編成するので、様々な案件に携わることができます。案件ごとに使う技術も異なり幅広く技術に触れる機会があるため、エンジニアとして領域を広げやすいと思います。

また、案件ごとにリーダーやメンバーといった役割もシャッフルされるので、ステップアップしやすいのも特徴です。経験の幅や学びの密度が濃いのは、チームラボエンジニアリングならではなのではないでしょうか。

海野:我々のような自社開発する会社では、リーダーからメンバーに役割が変わると降格と捉えられがちですが、案件軸ではそんなことはないですね。

森山:あと、分野を限らず様々な業界のお客さまの案件があり、エンジニアであっても、幅広い業界知識や、例えばEC系のシステムの勘所や不動産系の業界知識といった業務的側面なども学ぶことができるのも、クライアントワークならではのメリットだと思います。

受託開発実績例:ファッションサブスクリプションサービス「メチャカリ(MECHAKARI)」アプリの新機能「パーソナルスタイリング AIチャットボット」

森山:開発プロセスについても、アジャイル、ウォーターフォールいずれも採用していますので特に縛りなどはありません。

Incrementsさんでは開発プロセスはアジャイルですか?

海野:ええ、アジャイルに近い形で行っているものが多いですね。アジャイルを取り入れたことで、いままで見えなかった開発ベロシティー可視化や、リリースが早くなるというメリットがありました。

一方で、Incrementsの場合開発チームの自主性に委ねている面があるので、本質的にユーザーにとって価値がある機能にフォーカスできているのか、適切なKPIを追えているかという点は、ぶれないように常にチェックしていく必要があると感じています。

森山:その点で言えば、私たちはどちらの方が本質的に良いか、クオリティが出せるかという観点で合理的に判断していて、プロセスもアジャイルは少なくウォーターフォールでの開発が多いです。

既に多くの会員が存在するサービスや売上のあるサービスのリニューアルの場合、あまり時間をかけられず短期間でアウトプットを出さなければいけない。なので、要件定義フェーズではモックアップを作ってアジャイル的に進め、設計フェーズ以降は一気にウォーターフォールで作り込んでいく。このやり方が、短期間でクオリティの高いアウトプット効率良く出すやり方として定着しています。

海野:要件定義にもエンジニアが入っていくんですか?

森山:そうですね。むしろ提案の段階からエンジニアが入っていきます。他社でディレクターやプロジェクトマネージャーと呼ばれる役割を、弊社では「カタリスト」と総称していて、お客さまとのコミュニケーションやスケジュール管理などを行います。そのカタリストが軸になり、エンジニア、デザイナー、お客さまの中間で動き回るイメージですね。

海野:こうして一般的なイメージと対比してお聞きすると、受託開発のイメージとギャップを感じますね…!

実際にジョインしたメンバーからも「入る前のイメージと違った」といった意見を聞いたことはあったりしますか?

森山:中途採用のエンジニアからは、前職とはまったく違ったという話はよく聞きます。

前職と比較して圧倒的に実装量が増えたと言われますね。前職では設計をしっかりやって実装はちょこっと、後はテストを行う役割だったのが、今では業務の大半は実装している、といった感じです。

また、弊社ではインフラにAWSを利用していて比較的自由に触ることができるため、エンジニアとしての幅が広がったという話も聞きます。

インフラ周りはインフラ専任者しか触れないというケースが多いですよね。アラートが立った時に、インフラ側とエンジニア側でボールを投げ合ってしまうようなケースが他社ではあると思いますが、弊社では基本的にひとつの案件に対してひとりのエンジニアがインフラ周り含めまるっと受け持っているので、エンジニアがひとりで原因を調べ解決してしまう。

そういった経験も、エンジニアとしての成長につながりやすいのではないかと考えています。

チームラボエンジニアリングに実際にジョインしたメンバーは、エンジニアとしての幅が広がるなど良い意味でイメージとの違いを体験しているようです。

1フロアまるごと仕切りなし。お客様との打ち合わせも、社内ミーティングもすべてここで

海野:自社開発の場合、ひとつのプロダクトを構築し続けるので知識やノウハウの蓄積がわかりやすいですが、案件軸でチームを組むチームラボエンジニアリングではどのように蓄積させているのでしょうか?

森山:ツールを使っていますね。プロジェクト管理ツールとしてRedmineを活用していて、複数の案件を横断的に見ることができるようになっています。ソースコードなどはすべてGitHubにあげ、「ここを見ればわかる」という情報の集合体を構築することで共有を図っています。

海野:受託開発/クライアントワークの場合、クローズドで管理しているようにイメージしていましたが、基本的に社内ではオープンにしているのですね。

森山:知識やノウハウは発信しようとすると難しいものなので、このように情報の集合体を作ることで対応しています。

その他にも、メンバーが中心となって「LT大会」のような、今携わっている案件についての発表や個人的に興味のある技術について話す場も設けています。普段はPC上から情報の集合体にアクセスする。場合によってはLTに足を運んで話したり聞いたりする。そういった形で知識やノウハウの蓄積を図っています。

海野:オフィスの会議スペースも、仕切りもなく非常に開放的で距離がとても近いですよね。受託開発を行っている会社は、情報が拡散しないよう閉じるイメージがありましたが、全然雰囲気が違いますね。

本対談はこの会議スペースで行われた。メンバー同士のミーティングをしているすぐ隣の机で、お客様が打ち合わせしていることも多い。

森山:びっくりされる方も多いのですが、このフロアでメンバー同士のミーティングはもちろんお客さまとの打ち合わせも行っています。

例えば、ミーティングの際に何か技術的にわからないと次の機会に先送りしてしまうことがありますが、オープンスペースにその分野に詳しい人材がいてその場で解決できたりする。スピードアップやクオリティを高めるという部分に直結できていると実感しています。

海野:そこも受託開発のイメージと異なるかもしれません。横断的に情報を共有できるというのは良いですね。

「そこのテーブルとその隣のテーブルも、実は片方はお客様との打ち合わせで、もう片方が社内の打ち合わせなんですよ」と説明してくれた森山さんに、「あ、ほんとだ」とびっくりする海野

チームラボエンジニアリングにフィットする人材とは?

海野:チームラボエンジニアリングにフィットする人材、受託開発にマッチする人材とはどのような方でしょう?

森山:第一に「プログラミングが好きな人」ですね。これがないと始まらない。

もうひとつ、クライアントワークに向いていると感じるのは、「よく質問をする人」です。

自分の解釈で勝手に作られてしまうと、場合によっては手戻りせざるを得ずプロジェクトに大きなインパクトを与えかねない。

最初・中間・最後でキチンと確認する習慣を持っているエンジニアは活躍しています。

受託開発に限った話ではないかもしれませんが、よく質問をする人は、よく伸びる印象があります。

新規開発の案件以外に保守案件も多いのですが、稼働しているサービスで何かトラブルが発生してしまうとお客さまからの信頼を一気に失ってしまう。そうならないためにも、事前に確認してくれるエンジニアの方が案件の品質も保てます。

海野:その確認や質問など、社内でのコミュニケーションはどのように図られているのですか?

森山:座席が近いので直接口頭で質問もできますし、コミュニケーションツールとしてSlackを導入しておりそこでも行えるようになっています。

海野:よく質問をする人が評価されることになると思いますが、他にはどんな評価ポイントがあるでしょう?

森山:いかにクオリティの高いアウトプットを出したかで評価すべきだと考えています。バグがないという品質。使いやすいという品質。それらを保つことができているかですね。あとは、チームでの開発を行っている性質上、協調性をもって開発できるかも重視しています。

海野:ちなみに……そうした御社で成長し巣立つ方は、どういったところに転職をされているのでしょう?

森山:クライアントワークを豊富に経験しているだけあって、転職先として特定の業界や分野は特にありません。例えば、上流工程が得意だったメンバーはコンサルティング系の企業に転職したり、技術が好きなメンバーはスタートアップに転職して自分でサービスを作ったりと、けっこう幅広くネクストキャリアに進んでいますね。

また、手がける領域が広くいろんな経験もできるため、転職先は特定領域ではなく、役割としてサービス全体の設計がわかるポジションに進む傾向にありますね。意外と独立したりフリーになったりするエンジニアは少ないですね。

「チームラボ卒業生の転職先」という、センシティブな内容を海野がおそるおそる(?)聞いたときも、「あ、聞きにくいですよね(笑)」とフォローして、かなり答えていただきました。

海野:入社後、抱いていたイメージとのギャップで退社されるような方はいらっしゃいますか?

森山:そのギャップでの退職はないですね。選考の段階でキチンと説明して理解してもらえているので、とても向上心高く積極的なメンバーばかりです。
それに加え、月に1度、全メンバーと私とで個別面談を持つようにして、積極的に話す機会を設けています。エンジニアが潜在的に持っている“見られていたい”という欲求を満たしつつ、案件の話や教育課題についてざっくばらんに話すのです。

イメージのギャップという点では、社名からアートや展示イベントの印象が強いためか、採用面接時に「私もアートの仕事ができますか?」といった質問を受けることがあるのですが、そもそもの領域が異なることはお伝えしています。

アートの分野で活かせる専門性を有していればもちろん可能ですし、実際に移動したエンジニアもいます。「エンジニアからカタリストにステップアップは可能ですか?」といった質問も多いのですが、それも可能です。求められるスキルに合わせて適材適所での配置を行っています。

海野:エンジニアの採用という面で、使える技術も重要になりますよね?

森山:そこはお客さまの案件の特性によって変えています。開発言語に関してはJavaとPHPで9割を占めていますが、一部Railsを用いたりGo言語を用いたりもしています。これからはサーバサイドの開発言語でKotlinを積極採用していこうという計画も進んでいます。新しい技術に挑戦したいと考えてはいますが、クライアントワークということで、情報が少ないことや障害が発生した時のリスクとの兼ね合いをみています。

また、私たちの場合は、受託開発ということと、大きなクライアント様が増えたことなども影響してか、設計書やテスト項目書などのドキュメントを作成します。
そうしたドキュメントを作成するのも、もちろんエンジニアです。実装するだけ、コーディングするだけではなく、ちゃんと設計書も書くしテスト項目書も書いてテストも実施しますし、開発の一連のフローを経験してそれができるようになってもらいたいと思っています。エンジニアとして、将来的にPM等を目指すのであればテストフェーズで得られる経験はぜひ自分のモノにしてもらいたいですね。

開発の一連のフローを経験してほしいと森山さん。自身、エンジニア時代に培ったテストフェーズのノウハウが後のPM時代に活きたのだそうです。

チームラボエンジニアリングで輝くのは主体性を持った人

海野:先ほどの評価される人のお話にも通じますが、どのような人が制作の現場で活躍されているでしょうか?

森山:技術力がトガッている人もそうですが技術力がトガっていなくても周囲のテンションを盛り上げることができる人も活躍しています。チーム開発を行っているので、チームの雰囲気はとても大事なので、そういった人がチームに存在すると、業務効率が目に見えて上がります。

エンジニアの性格は、周囲の雰囲気に染まりやすい部分もあり、逆にネガティブな人がいるとそちらに染まってしまうケースもあるので、チーム編成は意識していますね。その人の持つスキルや特徴を踏まえて編成します。

それ以外にも、メンバー同士の仲の良さも意識しています。

その辺は面談だけで把握することは難しいので、気になっているメンバーの仲の良い人に何気なく聞き込みしたり……しいて言うなら“クチコミ”になるでしょうか。

もし何かあれば情報を得られますし、本当にふと気になった瞬間に話をしに行くようにしています。後回しにすると、取り返しのつかない状態になってしまっている場合もありますから。

海野:人の流動性が高い仕組みだからこそのメリットですね。

森山:あと、成長するエンジニアはあるタイミングで一気にバリューを出すんですよね。当然、バックグラウンドや技術的なものも含めアサインするのですが、全部が全部万全を期せるわけではないので、「やらせてみるものだね!」と驚かされることも多いですよ。

弊社は、メンバーはみなフラットという環境なので、ある案件ではリーダーだったけど別の案件ではこの機能を実装するメンバー、というように、あくまでも役割としてそれぞれの責任をまっとうしていきます。

海野:エンジニアのキャリアパスとしては、メンバーからリーダーになることが目標になっているのでしょうか?

森山:様々ですが、チームラボエンジニアリングのエンジニアはリーダーになりたいという人が多いですね。普段寡黙でも「実はリーダーやりたい」と内に秘めた人もいます。自分の思想でシステムを設計したいという考えを持つエンジニアが多く、リーダーであれば裁量が与えられ反映させやすくなるので、その立場に身を置きたいのでしょう。目の前にある仕事をするだけでなく自分で主体的に動く人の方がチームラボエンジニアリングのカラーに合っていると言えますね。

海野:なるほど。チームラボエンジニアリングの受託開発のことがだいぶわかりました。

お話をお聞かせいただきありがとうございました。

海野:最後に、森山さんからQiita:Zineの読者に向けてメッセージをお願いします。

森山:とにかく、チームラボエンジニアリングはエンジニアの集団です。エンジニアとして技術を成長させたい、領域の幅を広げたい。そういった意識を持った人を歓迎していますし、皆さんの成長を実現するためのサポートも行っています。エンジニアとして、密度濃く成長したい人はぜひ、門を叩いてみてください。

対談を終えて海野から

森山さんから伺った開発の考え方や取り組み方は、受託開発に抱かれがちなイメージを覆すものでした。
様々なクライアントの開発に携われる環境で、エンジニアとしての幅を広げるとともに深い学びが得られるとのことで、向上心を持つエンジニアに最適なフィールドが、チームラボエンジニアリングにあるように感じられました。

キャリア採用説明会の案内ページを見る

チームラボエンジニアリングの教育体制についてもっと詳しく知りたい方へ
チームラボエンジニアリングで活躍中の方と教育担当の方へのインタビュー記事はこちら

「作りたい人」を集めてエンジニアを育てるチームラボエンジニアリングの教育体制とは

PRの最近記事

  1. プログラミング研修「TechAcademy」をエイチームが使い続ける理由

  2. チームラボエンジニアリングに聞く、受託開発で成長できるエンジニアとは?

  3. マイクロサービスへの挑戦、ラクスが考える技術的負債を返済する最適なタイミング

  4. Udemyで400コース学んだ黒澤さんがおススメするデータサイエンスコース10選+α

  5. Udemyで学んでAWS認定合格やAIの実装ができたQiitaユーザーの5つの事例紹介

関連記事

PAGE TOP