多くのアプリケーション開発の流れは、そのフェーズごとにコミュニケーションが発生していると思います。本記事ではそのフェーズ毎に私が最も良いと思ったコミュニケーションを 1 つ選んでまとめます。
| フェーズ | コミュニケーションの場 | |
|---|---|---|
| 1. | キックオフ | Meets |
| 2. | 設計・仕様等 | slack |
| 3. | 実装・UT | slack（ハドル） |
| 4. | レビュー | GitHub PR |
| 5. | UI/UXテスト | オフライン |
1. キックオフは Meets でリアクションを意識
キックオフでは主に要件や仕様について発表・相談する場です。
真剣に聞くのも大事ですが、発表者は画面共有することが多い都合上、参加者の状態がチェックし辛いです。Zoomとは異なり Meets のリアクションは画面共有上にも表示されるので 👍 や 👏 💖 などのリアクションを多めにすることで、互いに気持ちの良いコミュニケーションを意識しましょう。
2. 設計相談・仕様調整は slack ベースにすることでログも一緒に残す
キックオフが終わると、調査や設計に入ると思います。
途中設計や仕様への相談は発生すると思います。そこで大事にしたいは『認識齟齬を発生させない』ことです。ビデオ会議のほうが伝えるのは簡単ですが、コミュニケーションロスは発生しやすいです。
よくある例
エンジニア：ボタンのデザインは他と同じですか？（Bかな？
デザイナー：他のボタンと同じでお願いします！（Aのことかな？
エンジニア：わかりました！（よし B ボタンだな）
口頭だとひと言で終わってしまいますが、文章ベースにすると...
エンジニア：ボタンのデザインは A と B どちらにしますか？
デザイナー：Aボタンと同じでお願いします！
エンジニア：わかりました！（よし A ボタンだな）
こうなると結合テストのタイミングで何が起こるか一目瞭然ですね。しかも口頭だと「言った・言ってない」の砂かけ論にもなりやすく、結果としてチームのコミュニケーションとしては成立しなくなります。
3. 実装は ハドル で気軽に画面共有しながら相談
プログラムやデザインが仕様通りに開発できているか確認することが出てきます。
上とは異なり、ここを文章ベースにしてしまうと文章量が増えてしまい、逆に伝えたいことが伝わなくなります。
出社時と同じ状況を作るためにも、画面を共有しながら相談したほうが効率的でした。
4. レビューは PR ベース
ここは基本変わらないですね。GitHub が一番いい。
5. UI/UXテストはインタラクションやログを見ながら行おう
正直ここはテストする内容やチームによって異なってくると思います。在宅ベースの場合はそれぞれのデバイスや環境でテストしたほうが効率的な状況も出てくると思います。
私はAndroidアプリのチームにいますので、今回は私の経験談でまとめます。
AndroidやiOSはWebとは異なり、クライアントサイド・アプリケーションになります。そのため同じデバイスであっても通信の状況やバックグラウンドの常駐アプリケーションによっては再現されるバグやクラッシュに違いがでてしまいます。
いざクラッシュが発生した際、非エンジニアからログやレポートを貰うことは難しく、また Firebase Crashlytics などを利用してエラーイベントをキャプチャしたとしても、再現パターンを見るけるのは難しいです。
ではUI/UXのときはどうでしょうか？ デザインを 1px 動かすにも確認するためには都度デプロイが必要になったりと、生産性は高くないと思います。またアニメーション 1 つとっても、速度は感覚に近いためそれをオンライン上でうまく表現して伝えるのも容易ではありません。
もちろん上記までのことはハドル等でも再現することはできますが、そうなるとそれぞれ同じOSの同じ端末・同じ通信環境を再現させる必要があるため、こちらも容易ではありません。
ここは割り切って出社して、隣に座りながらテストしましょう。なんだかんだ言ってオフラインにまさるコミュニケーションはありません。
まとめ
実際どういったコミュニケーションが効率的で生産性が高いのかはチーム次第になるというのも答えですが、私の経験則上「オンラインとオフラインのハイブリット・コミュニケーション」が一番良い！と思います。
オフライン（出社）するとしても、テストタイミングのみと考えれば隔週程度にはなると思いますので、そこまで負担もかからないと思います。