気づけば一度も出社しないまま製品リリースしてました～フルリモート開発の利点と反省点～

こんにちは、Windowsアプリ開発を担当しているYurikaTakeuchiです。 2021年2月よりアイキューブドシステムズに入社し、同年9月にリリースされたCLOMO MDM Agent for Windows Ver.3.0.2の開発を行いました。

入社時期および開発時期がちょうどコロナ禍による緊急事態宣言の期間と重なったこともあり、ついに一度も出社する機会のないままの製品リリースとなりました。

本記事では、開発期間中のチームの様子を振り返り、工夫した点やうまくいった点、今後改善していきたい反省点を記載しています。リモート業務の取り組み方についてお悩みの方の参考になれば幸いです。

はじめに

アイキューブドシステムズの開発拠点は福岡にありますが、私は現在兵庫県で暮らしています。

入社時からフルリモート勤務を希望しており、入社してから今まで一度も出社することなくずっと自宅で勤務しています。必要な場合には出社可能ですが、基本的にはコロナ禍が終息した場合にもリモート勤務を継続する予定です。

入社後～プロジェクトチームJoinまで

入社時のキャッチアップ

入社に当たり、まず開発対象である製品への理解や開発環境の構築などのキャッチアップ作業が必要でした。

私自身フルリモート業務を行うのは初めての経験でしたので、スムーズに開発業務を開始できるか、何か分からないことがあったときに気軽に質問ができるかどうか不安でしたが、その点は案外すんなりとクリアすることができました。

CLOMOの開発スタートガイド作成までの道のりでも紹介のある通り、弊社では新入社員のための「クイックスタートガイド」というドキュメントが準備されています。

このドキュメントのおかげですぐに開発環境を構築できたため、短期間ながら製品の仕様やソースコードの理解がかなり深まりました。

他のメンバーとのコミュニケーション

何もわからない状態の人間は往々にして「何が分からないのか分からない」「これは今質問してもいいことなのか？」「おそらく初歩的なことなので自分で解決したほうがいいのだろうか…」といった不安を抱えやすいものです。まあだいたいはいつでもなんでも質問して良いものなのですが…。

初対面でお互いに顔と名前もおぼつかないなか、さらにリモートで相手の表情も見えないとなれば特にその辺りの不安が顕著になってしまいます。

そんな時は転職したらリモートワーカーだった件にも紹介のある、teams上のtimes_{name}という自身の分報チャネルを活用するようにしていました。

誰かにメンションが飛ぶわけではないので、キャッチアップの中で分からないことや疑問に思ったことはなんでも呟くことができ、周囲の方々もそれを放置することなく親切に教えてくださいました。

また、技術的なことだけでなく個人的な呟きに対しても反応を返してくださる方が多く、リモート業務での孤立感は全くありませんでした。

プロジェクトチームの課題と改善策

キャッチアップの終了後、Windows開発チームの一員として、プロジェクトの定例ミーティングなどに参加するようになりました。

当時、Windowsアプリ開発プロジェクトのチームは以下のような構成になっていました。

チームリーダー（１名）
テクニカルアドバイザー（１名）
実装メンバー（１名）

そこへ私が実装メンバーとして参加し、チームは合計４名となりました。

また、定期的なミーティングは週に一度の30分で、着手中のタスクの確認と今後一週間の予定を共有していました。コミュニケーションツールはTeamsを使用し、ミーティング以外ではプロジェクト用のチャネルでチャットベースのやり取りを行っていました。

しかし、当時のWindowsの開発プロジェクトチームは社外メンバーと協力してそれぞれの開発拠点にて作業を行っている状況であり、プロジェクトとしてもスタートしたばかりの時期でした。

そのためか、まだタスク管理の方法やチーム運営の方法が確立されておらず、私がチームに入った頃には以下のような問題がありました。

開発状況の情報共有が遅い

デイリースクラムのような毎日の打合せが無く、問題点や検討事項の共有の場が実質週に一度のミーティングのみになってしまっていたため、個人が抱えているタスクや課題が見えづらくなっていました。 Teamsのチャネルはあるものの、一日の作業内容の報告のような形式的な連絡がメインで、それ以外の困りごとや悩んでいることなどを共有しづらい雰囲気がありました。
ミーティングの時間が肥大化しやすい

1.にも関連しますが、定例ミーティングが一週間分の連絡事項をまとめて共有する場になりつつあったため、回数を重ねるごとにミーティングの時間がだんだん伸びていきました。相談事項やチームで検討が必要なものの共有もミーティングの場で行われるようになっていき、他の参加メンバーにとっては初見の問題をその場で考えなければいけなくなってしまいました。これではプロダクトのための十分な検討が行われているとは言えません。

上記の課題について、開発期間中に行った工夫とその結果を記載します。

情報共有の効率を上げるための工夫

個人的な意見としては、SkypeやTeams、Slackなどの便利なツールはあるものの、チャットによるテキストベースのコミュニケーションのみでは時間的な効率が良くないと感じています。

なぜなら、多くの人は文字をタイプするよりも口頭で伝える方が速いですし（※特殊な訓練を積んだ人を除く）、誤字脱字、文章の解釈違いで認識の齟齬が発生することもあるからです。

しかしチャットでのやり取りにも、非同期でのやり取りが可能、記録が残り後から検索しやすい、テキスト化する過程で思考が整理される、などの利点は確かにあります。

そのため、チーム内で情報共有する方法を、ケースごとに以下のようにしました。

緊急事項、漠然とした相談など、口頭で説明したほうが楽で手っ取り早い場合は積極的に通話したり、オンライン会議を設定する
- 例えば、タスクを進めるうえでの具体的な作業内容の確認や、メンバーに割り込み作業をお願いしたいときの連絡など（10~20分程度）。
- なお、口頭で決定したことは、メモレベルでもいいので文章化して残しておくことを意識しました。これは思考の整理にもなりますし、後から話の内容を忘れたときに役に立ちます。
少し優先度の低い連絡事項や問題点の共有など、確実にテキストで残したい場合はチャンネルのチャットに残す
- 例えば、設計の相談やコードレビューでの指摘・質問事項など。
- 基本的にはそのままチャットベースで内容を検討し、うまく伝わらないときには通話に切り替えて会話する、など議論を活発に行うようにしました。
メンバーの問題意識を一元管理するための「課題管理ページ」を作成する
- 例えば、誰かにすぐに質問や相談をするほどではないが、自分の中で問題意識を持っていることの共有など。
- チームメンバーがタスクを行う上で見えてきたTODO事項などを書き込めるドキュメントを作成しました。備忘録的にも使えますし、メンバーが今取り組んでいることが可視化されるため、それぞれのタスクの状況が共有されやすくなりました。

定例ミーティングの効率化

定例ミーティングの肥大化の原因として、共有事項や検討事項などが同じレベルで報告されてしまうことがありました。

そこで、定例ミーティングをより効率化できるよう、取り上げる議題を以下のように精査しました。

タスクの状況確認としてカンバンボード形式の確認方法を取り入れる

調査中、実装中、レビュー待ち等、タスクを細かい進捗状況ごとに分けた状態で確認するようにしました。どのタスクがどの段階で手間取っているかがすぐにわかるようになったため、緊急性や重要度の高い議題を優先して取り上げられるようになりました。
検討や調整が必要なものについては別途検討会を開催する

課題管理ページを作成したことで、検討が必要な事項を即座に共有できるようになりました。個別の検討会を定例ミーティングとは別枠で実施するようにしたことで、チームでの議論に十分な時間を割けるようになりました。

上記の取り組みを行ったことで、定例ミーティングの時間は大幅に短縮されました。

各タスクの内容についての確認や検討は日々のコミュニケーションの中で行われるようになったため、ミーティングはスケジュールや進捗の確認を行う程度のボリュームになり、最大で１時間以上延長されていた定例ミーティングが、予定通り30分以内に終了するようになりました。

まとめ

以上の取り組みにより、チーム全員がリモート業務であるにもかかわらず、無事に全ての開発アイテムを消化し、リリースすることができました。リリースを終えた後も、些細なことでもすぐにチーム内で共有・相談する習慣が定着化しており、以前よりも非常に良い雰囲気の中で業務を行えています。

このことから、私は複数人でリモート開発を行う際には以下のことを意識しなければならないと感じました。

チャット、口頭それぞれの利点が活きるよう、共有したい情報の内容によって手段を使い分けられるようにする
メンバー同士のコミュニケーションのハードルを下げ、細かな情報共有を日々行えるようにする

反省点

問題を改善しつつも、開発期間中に感じた反省点には以下のようなものがありました。

タスクの優先度の認識がメンバー全員に共有できていなかった

特に開発の終盤で、割り込みの作業などが発生した場合に、スケジュールとの兼ね合いから「どの程度の緊急度なのか」「今の作業を止めてまで優先したほうが良いのか」という判断に迷う場面が多々ありました。

そのような場合には、チャット上や口頭でも「こちらを優先して先に取り組みましょう」「今の作業が一息ついたらこちらに着手してください」などを明確に発言するようにしていましたが、理想としてはメンバーが自ら優先順位を判断できるようになるのが良いと思っています（そもそも、作業内容以外の部分で迷うこと自体がストレスとなります）。

オフラインで顔を合わせながら作業を行っているときには、なんとなく相手の様子などで緊急度が分かったりするものですが、オンラインでは「なんとなく」で共有できていた情報はほぼ伝わりません。　この対策としては、例えばアジャイル開発で用いられるトレードオフ・スライダーの導入などが考えられます。

トレードオフ・スライダーアジャイルにおけるキックオフとインセプションデッキの役割（NADP解説）より転載