こんにちは、株式会社エッグシステムの高橋翼です。

弊社ではシステムエンジニアコミュニティを運営しており、2019年8月末時点で16人が所属しています。
このシステムエンジニアコミュニティでは、弊社が受注した案件を弊社社員とコミュニティメンバーで一緒に対応しています。

・会社の枠を超えた、プロジェクト単位での仕事ができる
・実践を通してスキルと経験を身に付けられる
・収入も得られる（弊社からお支払いもする）

といった具合で、かれこれ2年弱ほど運営しています。

なお、コミュニティメンバーは全員が『複業』（ただ本業の収入を補う”副業”ではなく、プロ意識をもって本業以外の仕事に取り組み、仕事の相乗効果や新たな人脈の形成・今後のキャリアアップのための経験やスキル向上を目的としている”複業”）という形で、ジョインしてくれています。
そもそもなぜそんなことをしているのか…、という点はこちらの記事をご参照ください。

---

理想の働き方を手に入れるために考えること…会社って必要？

---

さて今回は、
『社員＋コミュニティの複業メンバー（本業の会社はバラバラ）』
『完全リモートワーク』
という開発スタイルで数ヶ月かけて行ったWebシステム開発を通して得たことを整理し、シェアしようと思います。
 

複業メンバーかつリモートワークという開発スタイル

「そもそも会社がバラバラの複業メンバーと一緒にシステム開発できるのか？」
「完全リモートワークで上手く進められるのか？」
という疑問もあると思います。
先に結論を書くと「完全リモートワークによる複業メンバーとのシステム開発プロジェクトはできます」。プロジェクト単位で案件をこなしていくことは可能ですし、リモートワークでも可能です。しかし、通常のプロジェクトと比べて、プロジェクトマネジメントやチーム運営の難易度は非常に高いです。
そのあたりも詳しく解説しようと思います。
 

システムの構成

まずはじめにシステム構成について説明します。
今回開発したシステムは、小売・サービス業の店舗で使うネット予約システムです。エンドユーザーである顧客が利用する予約画面（フロント）と、店舗スタッフが使う管理画面（バックエンド）を構築しました。なお、ソースコードはGitHubで管理し、メンバー同士のやり取りはslackで行っています。

　

フロント

Nuxt
　

バックエンド

Ruby（DBはMySQL）
　

インフラ

AWS（EC2、RDS、CloudFront、S3、Elastic Beanstalk）

　
 

規模と期間とプロジェクトへの参画人数

フロント

画面数は約10画面ほどで、会員登録機能やマイページ機能などもあります。バックエンドと連動してデータを取得したり、フロント画面で入力されたデータをInsert・Updateしたりする感じです。
　

バックエンド

データベースは約30個ほどあり、管理画面側ではデータのCRUDを行う画面を用意しました。
　

期間

約半年（大変申し訳ないことに当初予定より遅延してリリースしています…）
　

参画人数

・お客様との要件調整・全体マネジメント：1名（私）
・開発メンバー：4名（常時）　※ピーク時は最大6名

　
 

分かったこと①：ちょっとした曖昧さが命取りになる

複業メンバーは全員本業の会社が違います。そのため、曖昧な表現をすると全員が微妙に異なる認識を持つことがあります。 例えば、「まずは最低限動く画面を作ろう！」と話したときに、

• メンバーA：「最低限だから、モック（HTMLで動く紙芝居レベルのもの）を作ろう」
• メンバーB：「バックエンドと繋げて、最低限スタブで表示するものを作ろう」

ということが起こりました。 この時点で認識相違が発生し、それぞれが行うタスク量にも大きな差が生まれ、当然アウトプットのレベル感も異なります。

これはどちらが合っている・間違っている、という話ではありません。会社や現場が違う人同士が同じチームでやる場合、共通言語が異なるので、細かいレベルで認識合わせを行うことが重要になります。 上記例に限らず、こういったメンバー間の微妙な認識相違はいくつか発生し、進捗にも影響を及ぼしてしまいました。
　

対策

普段使っている用語は現場固有のものや、現場によってレベル感が異なるものがあるので、とにかく曖昧さを排除した認識合わせをする必要があります。
「まずは紙芝居で動くHTMLレベルの画面を作ろう」
「いずれにしてもバックエンドと連動しないといけないから、連動することを踏まえてスタブで動く画面を作ろう」
といったように、認識相違が生まれないような、一意に捉えられる表現をすることが重要です。

また、弊社ではプロジェクト開始時には必ずリアルの場で集まってキックオフを行うようにしています。プロジェクトの説明だけでなく、用語の認識合わせもそうですし、お互いの役割分担などについても認識合わせすることができるからです。
用語に限らず、とにかく曖昧さを排除するようにしています。

　
 

分かったこと②：タスクと稼働時間の可視化をしないとまわらない

リモートワークで開発する上で欠かせないことが『情報の可視化』です。
通常のプロジェクトのように自分の隣りの席で開発しているわけではなく、物理的な場所が離れています。それだけでなく、複業メンバーが仕事をする時間は人によって変わります。出社前の朝の時間帯を使うメンバーもいれば、平日帰宅後の時間を使うメンバーもいれば、土日の時間を使うメンバーもいます。すると「あの人は今何を対応しているのか分からない」という状態になります。
この状態で発生する弊害は2つあります。
　

１）進捗状況が掴めない

同じ場所で仕事をしていれば、「今の状況だけ整理したいから、この後30分だけ集まって打ち合わせしよう」と言って済むことが、リモートワークだとそうはいきません。すぐに集まることは難しいので、打ち合わせをする場合は、日程調整した上でzoom（Web会議）で打ち合わせを行うことになります。そうすると、最悪1週間後でないと全員の都合が合わない、ということも往々にして発生し、進捗状況をすぐに掴むことができなくなります。
　

２）お互いに質問しにくくなる

メンバーがお互いに何をやっているのか分からないので、「ここをAさんに聞きたいな…」と思っても、Aさんが忙しいのかどうかが分かりません。そうすると、気軽に質問しにくくなる状況が生まれてしまいます。
また、お互いに仕事をする時間も異なるため、単純に、「今知りたいことがすぐ聞けない」（すぐにレスがくるかどうか分からない）という心理的な障壁も出てしまいます。
 

　

対策

実は、「あのタスクってどうなってる？」と普段の現場でも会話するように、弊社でも最初のうちは、slackで適宜状況を確認しながら進めていました。
しかし、、、、結論から言うとこのやり方は上手くいきませんでした。理由は下記の2点です。

① マネジメントをする人（今回は私）だけが状況を把握することになり、メンバー間での状況共有ができない
② 進捗状況を俯瞰的に把握することができない

このやり方では、誰がどのタスクをやっていて、どれくらい進捗しているか、という情報が何となくしか把握することができないでは、結局マネジメントできていない状況と変わりませんでした。

大規模な開発ではないため、過度なマネジメントはしないようにしていましたが、それでも何かしらの仕組みを作り、進捗状況を把握する必要があります。そこで弊社が行った解決策はこの2点です。

・Trelloを使ってタスクを可視化
・slackで毎週定期的に報告する仕組みを構築

ホワイトボードに付箋をはって状況を可視化するのと同じように、Trello（https://trello.com/ja）でタスクを可視化し、担当割りとタスクの優先度付けも行いました。また、「ToDo」「Doing」「Checking」「Done」というリストも作り、進捗状況も可視化しました。これだけでもかなり状況が可視化されます。

もう1つは、slackのReminder機能を使い、日曜日の21時に「先週やったタスク」「来週やる予定のタスク」「来週の稼働見込み」を報告してください、というリマインドを送り、メンバー全員が報告する、という仕組みです。
ポイントは「来週の稼働見込み」を報告する点です。


開発メンバーはみんな複業をしているため、週によって本業が忙しくて時間が取れないこともあります。そのため、事前に稼働見込み時間を報告してもらうようにしました。これがあれば、「Aさんは今週忙しそうだから、もしかしたらこのタスクが遅れるかも」「Bさんは今週結構時間が取れそうだから、Aさんのタスクを巻き取ってもらおうか」という議論ができます。
 
ここで注意すべきは、メンバー自身が稼働時間が少ないやタスク量が少ないことに対して引け目を感じないようにすることです。
Trelloやslackを活用した仕組みで状況を可視化すると、否が応でも、メンバーそれぞれの稼働時間やタスク量が明らかになります。すると「時間が取れなくて、すみません…」という意見が出てきてしまい、言いたいことが言いにくい環境になってしまいます。
しかし、これらの仕組み化は『状況を可視化すること』が目的であるため、稼働時間が少ないことは問題ではありません。稼働見込み時間が少ないことが事前に分かれば、いくらでも対策を打つことができるからです。その点を明確にメンバー全員へ伝えて、共有しておくことも重要です。

 

まだまだ改善は続く・・・

完全リモートワークによる複業メンバーとのシステム開発プロジェクトマネジメントについて、弊社の実例を元に説明させて頂きました。ちなみに、これらの対策は私が考えて実行したのではなく、私を含めた開発メンバー全員で対面で振り返りを行い、対策を検討した中で効果的なものを実行したものです。
複業メンバーによるシステム開発において、メンバー全員できちんと振り返りを行うことも重要だと思っています。メンバー全員に当事者意識が生まれ、チーム・組織としての一体感が強くなるためです。
 
このように、複業メンバーによるシステム開発プロジェクトの仕組み化やチームビルディングは進めているものの、まだ課題も残っています。弊社でも日々改善をしながらプロジェクトを進めているので、またノウハウが溜まってきたらシェアしようと思います。

システム開発の事例紹介