クラウドワークスCTOである大場 光一郎氏に、サービスや開発組織を作り上げていく上で大切にしていることを語っていただきました。
開発組織において重要なのは、「共通言語化をすること」と「共通言語をシェアすること」と断言する大場氏のキャリアストーリーと合わせて、お届けします。
目次
PC2台と段ボール1つ、トリオプログラミングから始まった
私のエンジニアとしてのスタートは、10名ぐらいの小さなソフトハウス。当時はプログラムを書くのが大好きだったので、それができればどこでもいいという理由で就職先を選びました。
しかし、入社してみると非常につらい環境だったんです。先輩と2人で3人チームを組みます。そしてパソコン2台を並べて、まずは2人がコーディング。その間、残りの1人は後ろにひいた段ボールで仮眠します。
そして深夜23時以降は2時間毎に交代。それをぐるぐる回すみたいな状況になっていました。後から振り返って、24時間トリオプログラミングと名付けましたよ（笑）。
さすがにこれは体力が持たない。長くは働けなくなるなということで大手のSIerへ移りました。SIerで今も忘れない仕事は、自社のクラウドサービス立ち上げプロジェクトです。
ようやくサービスリリースができて「さあ、これから！」という時に、チームの縮小を指示されました。サービスは最初にできるだけ小さく立ち上げ、ユーザーやライバルの動向を見ながら機能強化していくことが、最適な進め方だと思っていました。
しかし、サービス開発でありながら、どうしてもSIの方法論で評価されてしまうような状況だったんです。例えば、カットオーバーしてリリースしたから完成で、納品したからもう開発にかける工数は不要といった扱い。「早く運用チームに全部渡しなさい」という位置付けになっていました。
それに対して「いや、サービスっていうのはそうじゃなくてね」みたいな事を3カ月ぐらいかけて説得したのですが、「大場の訴えはよく分かった。では、あと何人月必要なの？」と言われて。これはもう理解している世界観に大きな違いがあって共通の言葉で話せないなと（笑）。
株式会社クラウドワークス 執行役員CTO 大場 光一郎 氏
ソフトハウスを経て、大手SIerへ入社。受託システム開発や開発仕様の標準化などに従事した後、グリー株式会社へ転職。大規模なBtoCサービスを支えるエンジニアの開発環境整備やインフラ統括を推進した。2014年からは、クラウドワークスのCTOとして、開発チームを率いている。
グリー時代の上司を見て、CTOを志す
サービス作りを続けたかったので、新しい職場を探していた時にグリーと出会いました。BtoCサービス事業者でありながら、プラットフォーマーとしてBtoBの側面もある点が面白いと思い、入社しました。
最初はCTO室という立場で、エンジニア全体に対しての開発環境改善に取り組み、GitHub Enterpriseの導入や仮想化された開発環境の配布、デプロイできる仕組みの開発・運用と、いろいろな施策を推進しました。当時は開発者が作ったプログラムを本番環境に上げる部分が属人化して、職人技の領域になってしまっていたので、デプロイメント手順をシステム化したりしましたね。
中でも、CTOの藤本さんと一緒に仕事ができたのは、最大の幸運だったと思います。彼は技術者としても非常に優秀です。その上で取締役や事業部長として様々なマネジメント責任を負いながら組織を回すことも同時にやっていて、そういう姿を間近で見てこれはもの凄いなと感じました。
自分がそこまでのレベルでできるかは分かりませんが、チャンスがあればそういった役割にもチャレンジしてみたいと考えていたところに、クラウドワークスとの出会いがありました。たまたま次のCTOを探しているという話をいただいたんです。
クラウドワークスは、これからの拡大期を見据えて、組織やシステムを見直していかなければならないフェーズに入っていた。この点において、グリーでの会社での経験が活かせると思ったのと、あとはクラウドワークスのサービスがRubyで作られていたことも縁となって、意気投合してジョインすることになりました。
開発組織とは、些細なきっかけでギクシャクしてしまうもの
企業としての拡大期に参画できたのは楽しみな一方で、大変な役割だとも考えています。今まで急成長してきた会社を見てきた経験から、組織がギクシャクしていくのは非常に簡単で、些細なきっかけでみるみる状況が悪化していくものだと思っています。
中でも一番陥りやすいのは、部署間での「共通言語」がなくなっていくこと。同じ方向に向かってはいるのですが、細かい部分で共感まで至らなかったり、話が噛み合わなくなってきたりしてやがて派閥みたいに対立するようになったり…。
そうなると業務効率も悪くなりますし、人の成長にとってもマイナス面が大きい、全体としての悪いスパイラルに入っていくようになります。
特にエンジニアでありがちなのが、チームで開発を共にするという状況にありながらあまり人のことには興味がない、できればずっとコードと対峙していたいというタイプ。周囲も本人もそれでいいと思っている場合があります。
ここに問題意識がないことが問題で、短期的にはまわるのですが、中長期的には開発やサービス運営においてボトルネックになる可能性が高いと考えています。
また、技術の移り変わりは速くなる一方で一生同じ技術でやっていけるという領域は少なくなっていくと思います。結果的に自分がやりたいことができなくなってしまうという意味で、エンジニア自身にとってもリスクになるのでは、と危惧しています。
こうした状況に陥らないためには、「共通言語化をすること」と「共通言語をシェアすること」が重要です。
当社はクラウドソーシングサービスを運営していて、プロフェッショナルなフリーランスのエンジニアさんやデザイナーさんに向けて、インターネット上で完結する様々なお仕事とのマッチングを提供しています。例えばカスタマーサポートが受けたユーザーからの要望は、取りまとめて全社員へ定期的に共有しています。
これはサービス改善のためももちろんありますが、社内の共通言語づくりという意味もあります。開発・カスタマーサポート・マーケティング・営業などの部署の垣根を越えて、1つのサービスを作る上での共通言語を構築して、そこに自分の共感の気持ちを乗せていく、そうした良いものづくりのサイクルを大切にしています。
現状の当社の規模においては、共通言語をシェアした上での対面でのチームビルディングは効果が高いと認識しています。
社会とユーザーと、そして仲間と、共通言語で話せるエンジニアであれ
共通言語は自然発生的にできるものではなくて、サービスや仕事の価値を起点にして作り上げていくものです。
私がスタートアップのCTOとしてこだわっているのは、共通言語に対してオープンな人たちを集めること。事前に共通言語をシェアしていけるかどうかをお互いに確認した上でジョインしてもらえると、内発的にもそれを磨きこんでいける良いチームができ、社会やユーザーに共感してもらえる良いプロダクトが作れると信じています。
では、個人が共通言語化スキルを身に付けるためには、どうすればよいのか？これは実際に「サービスを作ってみる」ことに尽きると思います。既にサービス作りに対する敷居はかなり低くなってきていて、例えばherokuのようなPaaSを使えばコマンド一発でアプリケーション動かせる環境ができ上がります。
あとは何を実現したいかというアイデアさえあれば1人でサービスを作ってしまうことも現実的です。弊社のメンバーを見ても、趣味で作って運営しているサービスが結構人気だったりします。その経験がサービスエンジニアとしての強みにつながっていきます。
システムの一部分を担当する視点だけでなく、様々なユーザーやバターンに対応できる嗅覚とか感覚を鍛える上では、まずはサービスを作ってユーザーと対話してみることが、一番大事なのです。
※本記事はエンジニアのためのTechLife Magazine「motech」（※2014年11月21日掲載）からの提供記事です
8,568通り、あなたはどのタイプ？
グッドポイント診断で、あなたの隠れた強みを診断してみましょう。
診断結果は8,568通り。あなたはどのタイプ？
