チャレンジングな課題に惹かれてCTOに。実際は…？

僕は、いくつかの会社でウェブデザイナーやバックエンド、フロントエンドの開発、事業立ち上げの経験を積んで、2015年にランサーズに入社しました。現在はCTOとして、プログラム開発部長と企画部長のような役割をしています。

前職は、エンジニアとしては幸せな環境でした。売り上げも立っていて、仕事が終わった後は、オフィスに敷いた畳の上でビールを飲みながら勉強会をしたりと、メンバーの意欲も高く充実していました。

でもあるとき、「これでいいんだっけ。たった畳3つの自分の庭が、自分の求めていたものだっけ」と強く感じたんです。次は、全然知らない会社で挑戦したいと思い、見つけたのがランサーズでした。

「時間と場所にとらわれない、新しい働き方を創る」というビジョンと、エンジニアとしてチャレンジングな課題がありそうなところに惹かれました。実際、入社してみると課題ばかりでしたね（笑）。

特に、組織拡大に伴ってエンジニアチームの仕事が受託開発化していたことが、一番の課題でした。エンジニアが日々のタスクに追われて、疲弊しきっていたんです。

エンジニアの「受託開発化」という課題に、どう立ち向かう？

エンジニアチームの受託開発化の主な原因は、サービスの数が増えてきたことでした。

弊社は、クラウドソーシングサービスの「ランサーズ」から始まった会社です。ですが近年は、ディレクションから依頼したいというニーズに応えるための法人向けソリューションサービス「Lancers for Business」、コンテンツマーケティングシステム「Quant」など、サービスの幅を広げています。

事業拡大により、50人ほどだった社員は1年半で2倍になり、100人の壁に直面しました。

当時は15名ほどのエンジニアに、営業やカスタマーサービスの現場から、バラバラに開発オーダーが降ってくるという状況でした。もちろんエンジニアの工数を完全にオーバーしていて、500個くらいの案件が積まれている状況で…。

現場とエンジニアの距離が近く、直接依頼を受けているというのは、小規模の会社であれば健全なコミュニケーションだと思います。ですが、100人規模の会社では、そうはいきません。

エンジニアは工数が足りない中、それぞれの部署から「まだ終わらないの？」と言われるようになり、日々の業務を消化するのに手一杯で、モチベーションも下がっているような状況でした。

開発フローを再定義。案件を「プロジェクト」と「タスク」に分解

そのような状況で最初に取り掛かったのは、開発フローの再定義です。

具体的には、開発をオーダーするパスを限定し、案件の種類と優先度を明確にした上で、開発メンバーに渡すフローを整えたんです。

案件の種類は、開発に1ヶ月以上かかる「プロジェクト方式」と、比較的細かい粒度の「タスク方式」に大きく二分しました。それ以外では「障害対応」「基盤」というのも、別途分類しています。

▼再定義した開発フローの概念図

プロジェクト方式の開発オーダーは、プロダクト戦略を元に優先度を検討した上で、開発メンバーに伝えます。「会社の方針としてここを強化していきたい」という、Push型のオーダーですね。

一方タスク方式の開発オーダーは、Pull型です。エンジニアが手が空いたときに、自律的に案件を選んで開発しています。実施してほしいタスクは、「タスク依頼フォーム」という目安箱に各部署が投稿できるようにしています。

「優先度は決められない」ことを認め、自律性に任せていく

プロジェクト方式とタスク方式の工数配分は、週ごとにコンセプトを決めて変動させています。

例えば、「ガンガンいこうぜ」というコンセプトの週には、プロジェクト方式の案件に70%の工数をかけ、残り30%をタスク方式の案件に配分しました。

この配分はただのコンセプトで、厳密に決めすぎないようにしています。数字遊びのゲームになってしまっては意味が無いので、あくまでも全体のバランス感覚としてこれくらいの配分にしましょう、という意識で取り組んでいました。

優先順位も、「売り上げ・KPIに関わるもの」「オペレーションコストの削減に関わるもの」「ユーザーからのフィードバック」の3つの観点から、経験則で決めています。

優先度も工数配分も、1つひとつ正確に決めていくことって、現実的に無理ですよね。細かい粒度の優先順位は自律的に決めていくという合意が取れたことは、大きな成果だと思います。

ツールは使い方よりも、何を実現したいのかを見定める

開発フローの再定義に合わせて、Googleスプレッドシートやタスク管理ツールでバラバラにされていた案件の管理方法も改善しました。

「GitHub（ギットハブ）」のIssuesとPull Requestに案件をすべて移し、「Waffle.io（ワッフル・アイオー）」を連携させて、より管理しやすくしています。

こうして一元化することで、エンジニアは自分たちの開発速度を知ることができ、プロジェクトとしても異常値にすぐ気付ける、健全な状態となりました。

▼タスクや進捗を可視化することで、チームの開発速度を俯瞰できるように

ただ、Waffle.ioのようなツールを入れるときに、「こういう機能があって、こう使っていきましょう」という、表面的な話だけしてしまうと、やっぱり続かないんですね。私たちも、それで何度もツールやプロセスの導入に失敗しているんです。

そうではなくて、今回はまず開発全体のコンセプトとして、「プロジェクトにおける6つの問い」というのを定めたんです。「ステークホルダーと合意したものが可視化されているか」「進捗が実績ベースで出ているか」「いつでも人に見せられる状況を作っているか」といった内容です。

▼プロジェクトにおける6つの問い（一部）

私は、「これらの問いに応えられる状況を作ってください」という話をしただけで、その答えがWaffle.ioやGitHubなんです。

マネージャーとしては、求めるものだけ明確にして、それをどう実現するかというのは、メンバーに自発的に決めてもらうということが重要だと思いますね。

受託化していた仕事から、「未来へつながる」仕事の創造へ

案件の優先順位づけが上手くいくようになっても、依頼された仕事をこなすだけではメンバーのモチベーションは上がりません。

ランサーズは9年前から続くサービスなので、アーキテクチャはレガシーになり、コードも複雑化していました。その状態では、何をするにもリスクの話が先行するようになり、新しい技術にもチャレンジできなくなってしまいます。

それはハッピーなことではないし、創造性もないですよね。今までは、家が建っているところに、どんどんシステムを積み上げていくようなイメージでしたが、これからは未来につながることをしようと、意識を変えていきました。

そのためにも、まずはCTOである僕自身が「こういう技術を取り入れてみましょう」と、積極的に手を動かしていきました。すると、メンバーからも「React.jsを入れたいです」「開発環境にDockerを取り入れたいです」と、提案が出てくるようになったんです。

僕はよく、「コードにビジョンをのせる」と伝えているのですが、その技術を入れるとどういう未来が描けるのかを考えて、小さなひとつの機能を実装するときにも、何か未来につながるものを入れようと意識しています。

Pull Requestで、組織も人も変わり続けていく

これからは、必要とされる技術も事業ごとに最適化されていくので、その技術をどう全体に波及させていくのかが課題ですね。

これはまだ試行錯誤の途中なのですが、「地獄めぐり」という取り組みを始めています。

ひとりの人に、すべてチームを1週間ごとに回ってもらうんです。まずは新卒の人を中心に始めてみたのですが、スキルセットの幅も広がり、良い結果が出ていますね。

ただこの取り組みも、例えば子会社が何十社にもなると無理が出てきますよね。今現在は効果的な取り組みでも、組織は変わり続けなければいけないんです。

実は、先ほどの「プロジェクトにおける6つの問い」も社内のGitHubで公開しているので、常に新しく更新し続けられるようになっているんです。

ランサーズの根っこにある、「時間と場所にとらわれない、新しい働き方を創る」社会を実現できるよう、組織も人も変わり続けていきたいと思います。（了）