はじめに
現在、受託開発企業でプロジェクトリードをしている、@fussasyです。前職では、大規模開発プロジェクトの領域リーダーとして、メンバーも含めて出社し、オフィスでプロジェクトを回すことが多かったです。一方、現職ではリモートワークが進んでいることもあり、直近で参画した開発プロジェクトでも、フルリモートでチームリードをすることになりました。半年間ですが、その際の課題と工夫した点を、自身の情報整理と併せ、まとめておきたいと思います。なお、本記事では主旨に沿わないため、システム構成等の技術要素は割愛させていただきます。
フルリモート勤務でのプロジェクト進捗状況
利用ツール・サービスについて
コミュニケーション：Slack、Meet、Teams
チーム管理：Backlog、Google Workspace
成果物ドキュメント作成：Microsoft Office
成果物管理：BOX
コード管理：Github
開発環境：SAP BAS ※SAP BTPのWeb IDEです
他
弊社（弊部署）と、プロジェクト関係者について
基本的に、弊社（弊部署）ではリモートワークが推奨されています。そのため、部署のメンバーの所在地も関西から関東まで広く散っています。私も入社から今日に至るまで物理的な作業が発生しない限り、自宅で仕事をしています。実際の業務でも、入社して半年間はメンバーとして開発プロジェクトに参画し、フルリモートで要件定義・設計・実装・テストまで行ってきましたが、次の半年間はプロジェクトリーダー（マネージャー）の立場として、チームを率いて開発プロジェクトを主導しました。
リードしたプロジェクトのメンバー構成は、自分（リーダー）、配下メンバー3名～4名、技術（管理）支援メンバー（上司）で、全員が日本人です。顧客も含めて全員がリモートワークでプロジェクトに参画している状態です。半年間プロジェクトで頑張りましたが、一度も対面にて顔を合わせたことはありませんでした……笑
フルリモート環境で開発プロジェクトを進めるうえでの課題
①コミュニケーション
フルリモートでのプロジェクトでは、メンバー同士のコミュニケーションがリアルタイムで難しいです。業務関係以外のコミュニケーションも発生しづらい、というのも難しさを助長している気がします。
②スケジュール
リモートワークでは、プロジェクトリーダー（マネージャー）が作業の進捗状況を把握しにくいです。チームメンバーは各自でセルフマネジメントをして、自身で時間管理をする必要があります。リアルタイムな情報の情報共有が芳しくなく、スケジュール管理が不十分である場合、作業進捗の遅れや品質低下に繋がっていきます。
③チームビルディング
オフィスでの作業に比べ、リモートワークでは不慣れなメンバーが孤立しやすく、チームの連帯感が取りづらくなります。また、新しいメンバーが加わった場合、コミュニケーションの問題から、チームビルディングがスムーズに進まないこともあります。
④チーム内の技術力差
リモートワークでは、メンバーごとに技術レベルに差がある場合でも、オフィスで同時に働いているときと比べて、気軽に会話・質問をできるメンバーが限られてしまい、技術的な課題も解決に時間を要することがあります。
フルリモート勤務における工夫した点
①コミュニケーション：
毎営業日、朝会をMeetでのオンライン会議にて実施していました。業務に関係することで早めに共有すべき事は、この朝会で実施していました。そして、基本的にはSlackでの文面ベースにて、業務関係の報告・連絡・相談・依頼をしていました。そのため、Slackでのコミュニケーション方法（質問方法）の基礎動作については、Qiitaの解説記事を利用して案件開始時に説明していしました。
【初心者向け】爆速で質問・回答を回すTips7選
また、プロジェクト途中からの取り組みとして、朝会でMeetを繋いだ後に、ずっとオンラインミーティングを繋ぎっぱなしにした、というものがあります。1日の流れとして、Meetでの朝会時に挨拶から開始⇒業務終了時に挨拶で切断、といった環境になっていきました。これが、チームメンバーからは好評で、まるでオフィスに出社している時のように話しかけやすい環境だった、と話していました。
ただ、これもデメリットの側面があり、「会話内容（質問内容）がMeet内で完結してしまいSlack等での文面で残らないこと」および「声を掛けられず成果を出すことに集中できる、というリモートワークのメリットを消してしまう」といったことが感じられました。
他には、月末に振り返り（いわゆるスクラム開発における、レトロスペクティブ）を実施したり、弊社プロパーに限りますが1on1ミーティングも実施するようにしていました。
【マネジメント】フルリモート環境下でプロジェクトチームの振り返りを実施してみた
【マネジメント】エンジニアチームでチームメンバーと1on1ミーティングを定期的に実施する
②スケジュール
正直なところ、リモートワークでは作業過程が見えないため、結果（成果物）でしか、その人のことを評価・判断することできません。過程を評価してほしい場合は、リモートワークを求めてはいけませんね……。進捗のスケジュール管理では、やはりWBSが中心となっており、その人がWBS上のタスクを達成したかどうか、そして評価はタスクの成果物の出来のみでの判断となりました。こればかりは仕方ないと思います。
③チームビルディング
コミュニケーションはSlackとMeetが中心でした。業務を遂行する上でのチームワークは充分だったと思います。特に威力を発揮していたのが、先述した朝会からのMeetの常時接続です。しっかり挨拶から始まり（「おはようございます」～「本日もよろしくお願いします」）、挨拶（「お先に失礼します」「おつかれさまです」）といった感じで終わるという状態が、プロジェクトチームでは維持されていました。
エンジニアの中には、個人に閉じた動きが得意な方が居るのはもちろん認識しているのですが、チームで達成すべき大きなプロジェクトの場合、このような連帯感を示す動きは必要不可欠かと思います。協力会社から採用したメンバーには、個人の技術力が強い方もいたのですが、チームプレイが上手ではなく協力を仰ぐことが出来なかったことで、良い成果が生まれず、チームから外れていただいたこともありました。これは、採用面接に携わった自身の反省にも繋がりました。
④チーム内の技術力差
チームメンバーが全員、プロジェクトで利用する技術領域に精通していれば良いのですが、実態としてそんな奇跡のような出来事は存在しません。技術課題が発生すれば、各自で下記の様な動き方をしており、これで問題はなかったように思えます。プロジェクトへの新規参入者には併せて、参考となるQiita記事も共有し、意識してもらうようにしていました。
1) 自身で情報収集し技術検証を実施
なるべく早く身につけたいエラーとの向き合い方
技術検証がうまくいかないときに心がけていること
2) Meetで画面共有して他メンバーから情報を得る
3) それでも解決しない場合、Slackで技術支援メンバーに質問
4) 今後も共通で発生しそうな場合、解説動画を録画 or Backlog Wikiに残す
肌感的には、「2) Meetで画面共有して他メンバーから情報を得る」までで解決する場面が多かった（≒難易度がそこまで高くなかった）ものの、これだと難易度が高いものでなくても、情報資産として残らないよな…、と懸念は感じていました。
おわりに
入社時からフルリモートワークの環境で、メンバーとマネージャーの両方の立場を経験して感じたことは、マネジメントの難易度がオフィス出社時のときと比べ、数段跳ね上がるということです。メンバーの立場からすると出社が面倒くさい、という気持ちはすごく分かるのですが、マネジメントの立場からすると最低、週1～2出社して集まる機会を設けた方が、チームが機能しやすくなるのは間違いないと思います。他にも、開発プロジェクトの性質により、リモートワークの可否も変わりますね。
これまで書いてきた内容でも、まだまだ改善すべき点は多々あると思いますので、様々なプロジェクトを経験し試行錯誤をしながら、より良いプロジェクトコントロールのスタイルを突き詰めていきたいと思います。