コラム
フルリモートで自社サービスを開発しました|BorderlessGYMサービス開発の振り返り
前回は、オンラインで完結して簡単にCSVを変換できるサービス『DataConvert』の振り返りについて記載しました。
フルリモートで自社サービスを開発しました|DataConvertサービス開発の振り返り
本記事では2つ目に開発した自社サービスについての振り返りを記載します。
こちらのサービスは開発期間約5ヶ月、6名体制(複業メンバー4名)のアジャイル開発で進めました。毎週の定例ミーティングで振り返りを行っていたので、具体的な内容もご紹介しようと思います。今後複業メンバーと開発する、アジャイル開発をやってみる、という方にとって役に立つ情報になるかと思います。
売上を上げたいジムと仕事を探すトレーナーをマッチングする『BorderlessGYM』
サービス概要
まず始めに開発したサービス『BorderlessGYM(ボーダーレスジム)』の概要をご紹介します。
BorderlessGYMは、ジムとトレーナーが出会うための複業マッチングプラットフォームです。トレーナーの複業・副業を推進し、会社・組織の境目をなくしていくことで、 より柔軟な働き方を実現し、経済的・精神的な自由を得るためのサービスです。
BorderlessGYM
https://borderless-gym.com/
開発スケジュール・開発体制
約5ヶ月ほどかけて開発し、サービスをローンチしました。
時系列に沿って、開発状況と体制をご説明します。
◯ 2020年4月
ぼんやりとジムとトレーナーをマッチングするサービスを作りたいな、と思い進められるところだけ進めよう!と言って開発をスタートさせました。当初は3ヶ月くらいでMVP(Minimum Viable Product:実用最小限の機能)を開発しようと考えていました。
出来るところから開発する、という緩いスタートを切ったため、管理などは何も行っていませんでした。
〈開発体制:3名〉
高橋、社員のエンジニア1名、複業のエンジニア1名
◯ 2020年5〜6月
ビジネスモデルが概ね固まりました。
サービスの全体設計とデザインを検討しつつ、FIXした機能から開発を継続して実施し、LPの開発にも着手し始めました。
この時点では毎週定例のミーティングを設けていましたが、決まったルールはありませんでした。そのため、直近の進捗状況したり、デザインや画面設計の検討を行ったりしていました。
〈開発体制:5名〉
高橋、社員のエンジニア1名、複業のプロダクトマネージャー1名、複業のエンジニア2名
◯ 2020年6月下旬頃
複業メンバーの1名が、本業が忙しくなるということで7月以降は稼働を取れないという相談がありました。そこで、複業の開発メンバーを増員することにしました。
ここで使ったのは「AnotherWorks」という複業人材マッチングプラットフォームです。
余談になりますが・・・このサービスは非常にオススメできるので、少しだけご紹介させて頂きます。
AnotherWorksは、人手を募集する企業と、案件を探す複業人材をマッチングするサービスです。マッチング時の手数料が発生しないので、企業側はシステム利用料だけで人材を獲得することができます。また、AnotherWorksに登録しているエンジニアには優秀な方が多く、採用時には非常に迷いました。当社が募集をかけたところ、合計で20名以上からご応募があったためです。
複業の人材マッチングと言うと、スキルはないけどお金稼ぎたい人材が使っている印象が強いかもしれませんが、AnotherWorksではそういった人材はほとんど見かけませんでした。しっかりとスキルを持っていてさらなる成長を望んでいる人が多いという印象です。
このようにAnotherWorksでは、安価で優秀な人材を獲得できるので、今後も利用したいと思ったサービスでした。
詳しくはこちらです。
(当社とは全く関係ありませんが良いサービスなので勝手に宣伝しております!)
▶ https://aw-anotherworks.com/clients
◯ 2020年7〜8月
AnotherWorksでマッチングした二人のエンジニアに参画して頂き、6名体制で進めることになりました。
顧客へのヒアリングやPMF(Product Market Fit:プロダクトが市場のニーズに合っているかどうかを確認するプロセス)を進めつつ、必須で必要となる機能をアジャイルで進めていきました。
新たに開発メンバーが2名加わったということもあり、定例ミーティングでは進捗状況を確認しながらも、KPTを行うようにしました。
KPTとは、「Keep/Problem/Try」の略で、振り返りのメソッドの一つです。やり方は非常にシンプルで、プロジェクトの中での取り組みや進め方に対して「Keep=よかったこと」「Problem=悪かったこと」「Try=次に試すこと」についてそれぞれ考えていきます。
〈開発体制:6名〉
高橋、社員のエンジニア1名、複業のプロダクトマネージャー1名、複業のエンジニア3名
◯ 2020年8月下旬
ミニマムの機能の開発が完了し、α版として8月下旬にローンチしました。
開発環境
開発言語については、バックエンドphp(Laravel)、フロントエンドVue.jsでした。
インフラはAWSを使い、ソースコードはGithubで管理していました。
アジャイル開発で推進しました
GitHubのissueで機能・タスクを管理しながら、アジャイル開発で進めました。
下記のステータスを作り、各タスクを管理していました。やはり、かんばん方式だと見やすく便利でした。
・プロダクトバックログ
・スプリントバックログ
・対応中
・レビュー中
・マージ済
なお、アジャイル開発における役割は以下のようにしていました。
・PO(プロジェクトオーナー):高橋
・SM(スクラムマスター)兼開発者:社員のエンジニア1名
・開発チーム:複業のエンジニア3名
※UI/UX検討、デザイン:複業のプロダクトマネージャー
自社サービス開発の振り返りから学んだこと
ここからは、フルリモート&複業メンバーで自社サービスを開発してみて分かったこと、アジャイル開発において工夫したこと、定例ミーティングで実際に出たKPTなどについて、いくつかご紹介いたします。
作業時間を合わせてもくもく会を行うことで進捗の遅れをキャッチアップ
複業メンバーは週1〜1.5日の稼働で、稼働時間や勤務場所の制約を設けていなかったため、自分が好きな時間に勤務する状態でした。そのため、平日夜に1〜2時間作業をするメンバーも入れば、土曜日にまとめて8時間作業をするメンバーもいました。
勤務時間がメンバーによって異なるため、実装に関して質問をしたり、PRに対するレビューを行ったりしても、それを確認するのが翌日になり、対応するのは週末になる、といったことが発生し、結果的に進捗の遅れが発生していました。
以下は実際に発生した例です。
◯日 :担当者がPRを出す
◯+1日:レビューアーがPRの内容について質問する
◯+2日:担当者が回答する
◯+3日:レビューアーが回答を確認し、追加質問をする
◯+4日:担当者が回答する
このように、1つの質問と回答のラリーを行うだけでも5日かかってしまう、ということが実際に起っていました。
※PR(Pull Request、プルリクエスト):コードの変更をレビュワーに通知し、マージを依頼する機能です。
この対策として、開発メンバー同士で作業時間を合わせるようにしました。
例えば、水曜日の夜20時から22時まではzoonで繋ぎながら作業し(もくもく会のようなイメージです)、もし質問があればその場でzoomを使って行うようにしました。
時間を合わせることによって、質問に対する回答やPRのレビュー結果に対する回答などがスピーディーにやり取りできるようになり、進捗遅延を解消させていきました。
複業メンバーとは1on1を実施してフォロー
今回はAnotherWorksで募集して初めて一緒に仕事をするエンジニアが2名おり、かつフルリモートで開発を行っていたため、コミュニケーションの課題がありました。
対面で会うことができず、お互いに関係性を作りにくい状況だったので「こんなことを聞いても良いのだろうか」「自分で調べてもなかなか分からないけど、質問したら相手に迷惑がかかってしまうのではないか」といった思いを各複業メンバーが抱いていました。隣の机で仕事をしていれば声を掛けて5分で解決することでも、こうった状況では解決が難しかったのです。
また、実際に1on1をやって後から分かったことですが、一緒に仕事をするメンバー同士の性格が分からなかったため、質問しにくかったという要因もあったようです。確かに、オンラインでチャットや会議はしているものの、仕事の話し(かつ必要なやり取り)だけしかしていないので、相手がどんな性格なのか分からなかったようです。
性格というのは、気軽に質問してもすぐ返してくれるのか、具体的な質問をして欲しいと思っているのか、チャットでは冷たく見えても実際は優しいのか、といったことです。チャット上でのやり取りがメインになるため、例えば「◯◯をやっておいてください」とだけ送られてきたら、「怒っているのだろうか?」と思ってしまうかもしれません。しかし、その人の性格を知っていれば、「◯◯さんは文章だけ見ると冷たい感じがあるけど、実際は話すと優しい人だから、怒っているわけではないな」ということが分かります。
対策として、複業の開発メンバーと1on1を定期的に行うようにしました。
週次の定例ミーティングも行っていましたが、やはり全員がいる場では話しにくいこともあるだろうと思い、1on1の場で「困っていることはないか?」といったことをメインに聞くようにしました。どちらかと言うと、モチベーションややる気といった精神面のフォローが目的でした。1on1の場で、別のメンバーの性格を伝えるということもしました。「slackのやり取りだと冷たく感じるけど、普段はこういう性格だから気にしなくても大丈夫だよ」といったことを伝えるようにしました。
コンフリクトが発生する実装が多かったためPRのマージは全体周知した
フルリモートで開発を進めていたため、コミュニケーションはslackでしか取っていません。そのため、ちょっとした確認などがあってもslackで連絡をする必要がありました。
そのため、コミュニケーションを密に取ることができず、後になってコンフリクト(同じプログラムを同時に複数人が更新してしまうこと)していたことが分かる、ということがあり、手戻りが起こっていました。週次ミーティングでKPTを行った際にこの課題が共有されたので、それ以降はコンフリクトが起こりそうだったらslackで周知する、ということが徹底されました。
「コンフリクトが起こりそうかどうか分からなくても、明らかに問題ないとき以外はとりあえず周知する」という運用にしたので、この運用にしてからはコンフリクトの発生はなくなりました。
この運用に関連して、実装途中でもこまめにPRを出すようにもしました。目的は2つありまして、1つ目は途中経過が共有されるため進捗状況を把握できること、2つ目は認識のズレを早期に解消できること、です。
フルリモート開発においては、「周知する」「こまめにPRを出す」といったコミュニケーションが重要でした。
特定のメンバーの進捗が遅れ気味だったので、ペアプログラミングを実施
特定のメンバーの進捗が遅れ気味になったこともありました。他のメンバーと比べるとやや経験が不足していたためです。
この点についても週次ミーティングのKPTで検討し、ペアプログラミングを実施することで技術的なキャッチアップを図りました。進捗が遅れていたメンバーに対して、技術スキルの高い別のメンバーが教えながらコーディングをしました。
※ペアプログラミングとは、2人のエンジニアが共同でプログラムを書いていく開発スタイルです。 メンバー同士での知識の共有や、プロダクトの品質向上が見込めるとされており、多くの企業が導入を進めています。
ペアプログラミングはやって良かったです。技術的なキャッチアップができますし、進捗遅延の解消にも繋がりました。コーディングを行うエンジニアとしても、意外とペアプログラミングでコードを見てもらったことがなく、満足度も高かった施策でした。
POは開発チームの進捗に対してとやかく言わない
マネジメントに関して良かった点として、POが開発の進捗状況に対してとやかく言わないようにしたことです。
今回は、私高橋がPOを担当しましたが、始めから開発の進捗に対しては口に出さないようにしていました。個人的には過去にプロジェクトマネジメント経験をたくさん行っていたので、開発の進捗状況に口を出したかったのが本音ですが、それをやりだすと確実に開発メンバーのモチベーションが下がるだろうと思ったので止めました。
弊社とは別の事例で、アジャイル開発を行った際に適宜進捗状況を開発メンバーへ問い詰めるような運用をした結果、進捗状況が遅延して品質もよくなかったが、進捗に関しては開発側に任せた結果スピード感が上がった、という話しを聞いたことがあります。
POとして進捗を気にしなければいけない気持ちも分かりますが、ある程度任せた方が結果的に進捗遅延が起きにくいということは理解しておいた方が良いのではないかと思います。
(もちろんケースバイケースですので、しっかりマネジメントした方が良いこともあります)
まとめ
全2回にわたって、自社サービス開発に取り組んで見て学んだことを記載しました。
弊社では労働集約型であるシステムコンサルティングをメインで行っているため、自社サービス開発という新たな取り組みをやってみて、学んだことはたくさんありました。
自社サービス開発に携わるメンバーとしても良い経験に繋がるため、しっかり事業としても成り立つような形でまたスタートできればと考えています。
なお、振り返りでご紹介した下記サービスについてご興味のある方は、こちらからお問い合わせ頂ければ幸いです。
オンラインで簡単にcsvの変換ができる『DataConvert』
稼働を上げて売上を増やしたいジムと、働く場を求めるトレーナーをマッチングする『BorderlessGYM』
また、複業メンバーとのシステム開発に関するマネジメント方法、フルリモートによるシステム開発におけるコミュニケーション、アジャイル開発の進め方、など詳しくお話しさせて頂くことも可能ですので、詳しく聞きたい方はお気軽にご連絡ください。
▶お問い合わせはこちらから
システム開発の事例紹介
株式会社オリーヴジャパン様|システムはドライになりがちだけど、こちらに寄り添って急なお願いにも付き合ってくれました。
【代表取締役・町田岳様】新しい予約システムの導入により業務の生産性が上がり、1日の予約30〜40件の手作業の対応が全てなくなったというのが一番大きいです。
ECサイト導入支援及びRPAによる業務自動化で『年間約120時間』を削減
機器製造・卸売業のお客様からのご依頼により、ECサイトの導入支援から、ECサイトに関する受注業務の改善・自動化を行いました。