決まらないリリース日、属人化、ユーザー価値より優先される開発工数…　少ない工数で成果を上げるための改善

株式会社Another worksについて

塩原基弘氏：あらためまして、よろしくお願いします。Another works CTOの塩原と申します。

Another worksは令和元年の5月7日にできた5年目の会社になります。タイトルにもあるように、創業5年目の会社です。現在は60名ほどの規模の会社となっています。Another worksが何をする会社なのかを一言で言うと、複業という新しい働き方を作っていく会社になります。

今日は30秒ほどの動画を用意したので、そちらを流せればと思っています。

このような動画でした。

「複業クラウド」の特徴

弊社の具体的なサービスは「複業クラウド」になります。こちらは複業をしたい人と企業をマッチングするサービスとなっています。僕らはまず日本人の誰もが複業できるような状態を作っていくというところで、このサービスを始めました。

複業クラウドはどういったところがユニークなのか、3つ紹介させてください。

1つはユニークな複業というところで、スタートアップの求人だったり大手企業の求人だったり、そういったものももちろんありますが、他にもスポーツチームや、さまざまな地域の地方自治体や学校など、いろいろな複業を取り扱っているところが1つの特徴になっています。

もう1つは求人を自動で生成できるというところで、「複業ってこういう働き方も、こういう業務もあるよね」というところをイチからワンクリックで生成できるという、企業さま向けの機能になっています。

あとは業務で探すというところで、求人は職種で探すことが多いかと思うんです。例えば業務でいうと「Salesforce」の構築はエンジニアでも得意な人がいたりするかなと思うんですが、そういったかたちで、業務で自分ができることを探せるのが1つの特徴となっています。

「複業クラウド」の“複業”とは？

（スライドを示して）複業クラウドの複業ってどういう立ち位置の複業なの？　というところですが、こんな感じで簡単に図にしました。「顧問」というのは技術顧問ですね。例えば、自分のノウハウを売るようなところでスキルはかなり求められるんですが、一方で、自分のやったことが中心になるので、経験価値は真ん中ぐらいかなと思っています。あとはアルバイトだったり、クラウドソーシングといった案件の回答とか、ライティングで「何文字いくら」みたいなところになります。

複業クラウドはどういうものかというと、ハンズオンで自分で手を動かして実際に会社に入って仕事をする。自分のスキルを提供するというところよりスキルは少しだけ必要にはなるんですが、顧問と比べるとそれほど高いスキルがいるわけではない。社会人3年目ぐらいからができるような複業を主に扱っているようなサービスとなっています。

「複業クラウド」の技術スタック

技術スタックになります。こちらはフロント、サーバー、インフラも含めて、だいたいオールTypeScriptで書かれています。Expressを使っていて、Next.jsとReact Nativeで構成をしています。

イベントの主催・共催も実施

Another worksはイベントを主催したり共催させてもらうことがけっこう多いんですが、おかげさまで累計1,000人以上の方に来ていただいています。今日も何回も来てくださっている方が何人もいらっしゃるんですが、いつもありがとうございます。

労働人口減少の問題も先ほど動画であった内容になっています。「僕らはこれに立ち向かっていますよ」というところです。僕らは複業クラウド以外にもこういったものをやっていくぞというところで、複業自体を社会に実装していくというところを目指してやっているような会社です。

今日話すこと、話さないこと

では本題に入ります。「創業5年目、組織変化と開発生産性向上の取り組み」というところになります。今日伝えたいことですが、僕らは5年目というところで人数もそんなに多くない中で、いわゆる本に出てくるような開発生産性、Four Keysみたいな話はできないかなと思っています。

じゃあ代わりにどういったことを話すのかというと、とにかく成果を上げる。そのために開発生産性を上げるという手段がきている中で、じゃあ少ない工数でどうやって成果を上げるか。それを考えるきっかけだったり、どういうふうに考えたのかといったところをぜひ伝えられればなと思います。

今日は実際に事例ベースで伝えていくんですが、その事例が使えなかったとしても、そこにたどり着いた背景だったり考え方を持ち帰ってもらえればうれしいなと思っています。

“生産性が高い”とはどういう状態なのか？

生産性が高いとはどういう状態なの？　というところなんですが、小さなコストで大きな成果を出せているというところが、生産性の高い状態かなと思っています。当たり前のことではありますが、じゃあ成果って何なのか？　というと、一言で言うとプロダクトが売れ続けている状態だと思っています。

売れるだけなら、いわゆる営業トークでうまく売るということもできるんですが、実際に使い続けるだったりとか、サービスの質だったりとかが良くないとやはりいけないし、お客さんの本質的な解決したい課題を解決しなければ成しえないというところで、成果というところを意識して今日はお話ししたいなと思っています。

じゃあ成果を上げるために（どうするのか）というところですが、プロダクトとしてやれることは他にもあると思いますが、主に3つに絞りました。1つはユーザーを満足させること。そして安全に使えること。

不安やセキュリティはもちろんのこと、プラットフォーム内、例えば「Twitter（現X）」だったり、そのような人と交流するサービスの場合、人から攻撃されるとか、嫌な思いをする、不安な気持ちになる。そういう安全性も重視すべきかなと思っています。

あとは成長率というところで、世の中が変わり続ける中で、サービスが一時的には良かったものの、そこ（成長率）に追いついて常に成長していかなければ、いずれは使われなくなる。というところで、成長率というところも、プロダクト、エンジニアとしては重要なキーになるかなと思います。

生産性が高い状態というのは、解決したい課題と解決した課題がしっかりと合っているところが大事かなと思っています。

あとは、コストよりも成果のほうが大きい。「コストをいっぱいかけても成果が小さければ、それって成り立っていないよね」というところがあります。

あとはvelocityという言葉があるんですが、いわゆる生産性が低い状態というのは「先々週はメチャクチャがんばって良かったけど、今週はぜんぜんダメだ」みたいな感じで、バラつきがある状態ですね。

「じゃあ来週はどれぐらいの成果が出せるの？」がわからないということ。それよりかはvelocityが少しずつだけど確実に伸びていっているという状態を作れるのが、生産性の高い状態かなと思っています。

その中で、僕らの取り組みとしては開発プロセスと技術の改善をとおして、この開発生産性を向上させるというところを紹介していければなと思っています。

抱えていた課題

最初に開発プロセスの改善について話したいと思います。僕らがどんな課題を抱えていたのか。

これは当てはまる人もいるかもしれないんですが、「決まらないリリース日」ですね。いつ果たしてリリースされるのか。「明日できます」「明後日できます」「明々後日、来週になります」みたいな感じでどんどん伸びていくような状態です。僕らもそういった状態がありました。

あとは「自分の担当じゃないのでわからないです」みたいな状態がちょっとある。いわゆる属人化というやつですね。

あとは、ユーザー価値よりも、どうしても開発工数のほうが気になっちゃう。「ここは難しそうだから」「ここは時間がかかりそうだから」が先に来ちゃう状態。こういったところは、先ほどの成果というところをベースにおくと、開発生産性が良い状態か・悪い状態かというと、悪い状態になっているかなと思っています。

こういった課題に対して、どうやって開発プロセスを改善して取り組んでいくかをお話できればと思います。

課題に対する開発プロセスの3つの取り組み

（スライドを示して）こんな感じで開発プロセスを見てみて、その中でエンジニアが関わるプロセスみたいなのを書きだしてみました。要件定義会は僕ら独自のものではあるので、後ほど紹介します。リファインメントがあったり、プランニングがあったりというのは、いわゆるスクラムの代表的なものになっています。

要件定義会はどういうことをやっているのかというと、要件を作って、実際にデザインを作って「さぁ、実装に入るぞ！」というところでリファインメントをして。そこをどうやって開発していくのかを考えると思いますが、リファインメントに行く前に、PMがいまいち固めきれていない状態の中で、エンジニアとかデザイナーが入って、要件を固めて、じゃあどうやって解決したい課題を解決するかを話し合っていく。

こうすることによって、より成果、ユーザーの価値に趣を置いて、より良いものを作るという会を設けたりしています。開発規模が大きいものに関してはこういったものを挟んで、成果を向上させる取り組みをしています。

あともう1個はDailyリファインメント＆プランニングというもので、実は毎朝15分やっています。プランニングって1時間とか2時間でやるようなイメージがありますが、どうしても長くて、ダレてきちゃう。

僕らは人数も少なくて急いで開発しなきゃというのもあるので、後半メチャクチャ巻くみたいな。1人か2人がわかっていればもうすぐに次へみたいな感じで、あまり良くない状態だったんですね。

そこを改善するために毎朝15分だけやる。だいたい1チケットが終わるか終わらないかぐらいにはなるんですが、そこの中でリファインメントとプランニングを毎日少しずつやっていくというところで、集中を保った状態で、かつ属人化しない状態だったり、ちゃんとユーザー価値を見直した状態だったりで進めるようにしたというのが、この取り組みになります。

じゃあプランニングが難しいものについてどうするんだというところです。要は、話し合いだけではぜんぜんわからない部分。「新しいライブラリを入れる必要があるよね」とか、既存の技術でどうしてもできないところ。

そういったものを対処するために、例えばプロトタイプ実装を本実装に入る前にやってからもう1回リファインメントをやるとか、あとは技術調査というタスクを積んで、そこをやってからまたリファインメントに入るようなことをしています。

あとは、優先順位を上げづらい開発がありました。例えば技術負債。小さめの技術負債とか、ライブラリアップデートとか、リファクタリングみたいなものですね。そういったものも固定で時間を押さえる。

例えば「木曜日の何時から何時までは、みんなでライブラリをアップデートしましょう」みたいな。ちょうど今日ライブラリアップデート会というものをやってきたんですが、そういったかたちで固定で押さえちゃうことによって、最初からそこはない時間として、他はプロダクトバックログの開発に重視して開発をしていくような取り組みをしています。

課題に対する技術的な3つの取り組み

続いて技術のほうの取り組みになります。技術のほうではどんな取り組みをしているかということで、3つほど紹介をします。

1つはSQLのテストというところで、SQLを発行している層のテストになります。もちろんORM（Object Relational Mapping）にはTypeORMというものを使っていて、ORMである程度は担保できています。

しかもTypeScriptを使っているので型チェックはできているんですが、どうしても複雑なjoinを2個、3個したりとかすると、Stringでけっこう書かないといけなくなったり。そのミスがわりと多くなるというところから、「このSQLレイヤーの動作確認をしないといけないよね」という課題がありました。

一方で、これを手動でやっていくとなると、データを用意して、そこを実際に実行するのがけっこう大変だったというのが課題でした。なので「じゃあSQL、DBにつなげた状態でテストできるようにしようよ」ということでやったのが、この取り組みになります。

（スライドを示して）こんな感じで、DBにつないだテストとDBにつながない単体テストの2つに分けてサーバーサイドのテストを書いています。

じゃあDBにつないだテストの課題ってどういうことがあるのかというと、例えば、テストケースごとにデータベースを初期状態に戻す必要があります。最初に作ったデータが影響して他のテストがこけちゃうとかがあるので毎回リセットをしなきゃいけない。ただし、TypeORMだとテスト単位でのトランザクション貼ることがどうしてもできなくて、リセットを毎回実行することになるので遅くなるという課題がありました。

あとは、並列実行をするとduplicateだったりが発生して、DBを使ったテストがしづらくなっちゃうという課題がありました。

すごくシンプルな解決策ではありますが、「workerの分のDBを立てちゃおう」という対応になります。

じゃあこのDBをworker1、worker2、worker3、worker4で、それぞれつなぐDBを完全体　で、マイグレーションもそれぞれで回してというところで、並列実行をするようにしました。

jestはworkerコマンドでworker数を決められると思いますが、このworker数を決めた時にJEST_WORKER_IDというIDが入ってくるので、ここをデータベース名に使うことで課題を解決しています。

もう1つはルールの自動化です。先ほどESLintが出てきたと思うんですが、僕らはESLintとプラスして、dependency-cruiserを使っています。

このdependency-cruiserがなかなか渋いライブラリではあるんですが、けっこういろいろやりたいことができます。

例えばモジュール間同士のコードで、「moduleAとmoduleBでお互いのコードを使わないでくれ」みたいな問題だったり、あとは、弊社はオニオンアーキテクチャを今使っているんですけど、この依存のルールとかを破られないように。

そういったことも書けるようになっているので、そのコーディング規約に則ったかたちでコードを書けるようにということを取り組みとしてやっています。

3つ目は技術変遷になります。これは「組織フェーズとか、プロダクトのフェーズに合わせて技術も変えてきましたよ」という内容になります。先ほど紹介した時はオールTypeScriptという話をしたんですが、実は最初からそうだったわけではなく。

創業当初は私1人だったので、そこでRails＋Vueで立ち上げて。インターンばかりの組織だったので、比較的誰でもわかりやすい簡単な技術。TypeScriptも使わず、というかたちでやっていました。

そこから複業がやっと世の中で認められてきたタイミングでReactに変えたり、オールTypeScriptにしてさらに生産性を上げていこう、採用をより強化していこうというところで取り組みを変えていきました。なので、組織の規模だったりとか、プロダクトの変遷に合わせて技術を変えていきましたという背景があります。