新卒3年目で、新規事業開発の責任者に！

2014年に新卒でランサーズに入社しました。プログラミングはほぼ未経験でしたが、エンジニアとして機能開発をしたり、ディレクターのような役割をしたり、幅広く担当してきました。

そして2015年の末からは、新規サービス「ランサーズストア」の責任者をしています。

クラウドソーシングの「ランサーズ」には、仕事の依頼をいかに増やすか、そして仕事を請けるランサーさんの情報を提供して、いかにマッチングできるのかという2つの軸があります。当時、後者の「ランサーさんとその情報をストックする」ところが、まだ弱いというのが課題でした。

そこで、ランサーさんが自分が「何ができるのか」を公開し、そのスキルを売買できるスキルマーケット「ランサーズストア」の開発を開始したんです。

開発を開始するも、見積もりの難しさが…

新規事業として始まったランサーズストアですが、事業の最大化を図るために、ランサーズのユーザーイベントと同時期にリリースしようと考えました。イベントまでは約2ヶ月しかなくて（笑）、開発は私を含めて2名で進めていきました。

そうして開発がスタートしたのですが、すぐに問題が発生して。プロジェクトの開始当時、もう一人の開発メンバーがPHPを触り始めたレベルで、私との実装スピードの差が大きかったんですね。私が工数をすべて見積もってタスクを割り振っていたのですが、それが全く信用ならなくて（笑）。

2週間が経ったくらいで、「これはダメだね」という判断をして、スクラムのエッセンスを取り入れながら、いくつか改善をしていきました。

まず、タスクを工数ではなく「規模」をベースにしたポイントで見積もるように変えました。タスクの一覧はGoogleスプレッドシートで管理し、そこにポイントを書いていきました。

▼タスクと合わせてポイント（P）も記載

タスクが完了したら、実際にかかった工数も記録していき、毎週の振り返りの場でポイントを集計してベロシティ（開発速度）を出していきました。

▼スプレッドシートでベロシティも算出

すると次第にベロシティは上がり、見積もりの精度も良くなっていきました。バーンダウンチャートも作ったことで、「これは人を入れないとダメだ」という判断が早期にできたのも良かったです。

見積もりは「規模で語れ」。コミュニケーションミスを無くす方法

そのような問題もあったので、今では「工数で語るな、規模で語れ」と、口酸っぱく言っています。

「工数がどれくらいかかる？」と聞いても、さらっとしか答えないエンジニアも多いですから。「1日で終わります」というのが、丸一日時間を取れば終わるのか、明日までに終わるのかは、全然違いますよね。

ちょっとしたコミュニケーション不足で生まれる認識の違いですが、タスクがいつ終わるかなんて、誰がアサインされて、何人でやるのかによって変わります。

だから、認識がずれないように、絶対的な「規模」で話さないといけないんです。

GitHubのテンプレートも活用し、品質への意識を高める

他にも、ランサーズストアのプロジェクトで改善したポイントとしては、「GitHub（ギットハブ）」のPull Requestテンプレートの活用です。

Pull Requestのテンプレート機能は全社的に使っていて、「実装の目的・背景」「画面・機能」「非機能要件」といった項目を書いています。これに加えて、ランサーズストアのチームでは、「ソースコードの複雑度」などを追加しています。

▼テンプレートに沿ったPull Requestの内容

テンプレートを使うと、Pull Requestの粒度が揃うという狙いもあるのですが、それは第一段階だと思っていて。私は、テンプレートがあることで「気にするようになる」ということが大事だと思います。

テンプレートにあると、その項目を書かないといけなくなるじゃないですか（笑）。何かを書かざるをえない状況になるので、コードを書くときに、常に気にするようになるという効果があるのかなと思っています。このテンプレートは、全社に広げていきたいですね。

複数のロールを持つ人は、「ロールの切り替え」への意識が重要

このプロジェクトを通して感じたのは、アジャイルやスクラムも万能じゃないということですね。

あれは5人や10人くらいの開発チームで、一番効率が上がるものだと思います。新規事業だと、それほどの人数をかけられないので、そうなると1人でいくつものロールを担う必要があります。

私も、エンジニアとしてのロールと、プロダクトマネージャーとしてのロールという、2つのロールを持っていたんです。このときに重要なのは、ロールの切り替えを意識して、「今自分がどのロールとして話しているのか」を明確にすることです。

やっぱり「プロダクトマネージャーとしてはこうして欲しいけど、とは言えエンジニアとして言うとこうだよね」ということもあるので。メンバーに何かを伝えるときには、「ここからエンジニアの立場として話すよ」と明確にしてから伝えるようにしています。

「属人化させた」フェーズから、次のステップへ

複数のロールを担っているというのはデメリットに見えますが、メリットがある部分もあって。例えばエンジニアとプロダクトマネージャーのロールを併せ持っていたら、仕様を決めて作るところまでが、素早くできます。

その分属人化は避けられないのですが、そこは割り切って、リリースまでのフェーズは「今は属人化させるよ」と宣言をしていましたね。

ただ、これからはフェーズが変わってくるので、他の人も自立して動けるように、属人化していた部分の整理を始めています。

例えば、「この企画はどういう戦略に基いて、何を考えて実施したのか」ということを伝えたりしています。他にも、会議の中でもやっとした雰囲気を感じたときは、それを吐き出させて、解決したら書き残しておく。そういうことを、地道に進めています。

そうして、自分の中での答えを1パターンでも2パターンでも確立しながら、進めていけたらと思います。（了）