要約
アプリ開発における複数の役職間でのコミュニケーションは、明確な資料や情報の共有を通じて行われ、そのプロセスは開発の完成度を高める役割を果たします。異なる視点からの情報の差異を最小限に抑えることが重要です。早期に重要な決定を下すことで、コミュニケーションコストを削減し、効率的な開発が可能になります。
ここ数年はサーバーサイドのwebアプリケーション開発をしていましたが、最近は数週間前からAndroidアプリとiOSアプリの開発をしています。
Android・iOSアプリの開発は久しぶりです。チームにAndroid・iOS専任のエンジニアが不在という状況で、リリースしたい機能があるということで、その機能だけ実装する事になりました。
Android・iOSアプリを開発するとき、開発チームではディレクター、デザイナー、バックエンドエンジニア、Android・iOSエンジニア(以下アプリエンジニア)という職種で分かれて開発することが多いので、そのときの他の職種とのコミュニケーションについて、アプリエンジニア視点で、どんなコミュニケーションをしていて、どんなコミュニケーションがいいと思っているかを言語化してみようと思います。
| 職種 | 必要な資料 | アプリエンジニアの行動 | 相手に伝えることの例 | 良いコミュニケーションのポイント |
|---|---|---|---|---|
| ディレクター | 仕様書(ドキュメントやスプレッドシート) | 仕様書を読んで影響のある画面を確認し、エッジケースや技術的な考慮点を考える。 | 技術的な筋のよさやエッジケースについて具体的に説明し、問題点や改善点を提案する。 | 仕様が明確であり、ヌケモレが少なくなるように努める。開発初期、開発中、リリース前など、プロジェクトの各段階で適宜確認を行う。 |
| デザイナー | Figmaなどのモックアップ | デザインを詳細に確認し、OS間での差異や実装上の問題点を特定する。 | 片方のOSで実装可能なことがもう片方でできない場合、具体的にどの部分が問題か説明し、代替案を提案する。 | できるだけAndroid/iOS両方のデザインを用意してもらう。また、デザイナーとの優先順位の違いに配慮し、デザイナーが他の関係者との調整を行いやすい状況を作る。 |
| バックエンドエンジニア | APIスキーマ(用意するのはアプリエンジニアでもバックエンドエンジニアでもよい) | APIが必要な機能を満たせるか、命名などに不自然な箇所はないか確認する。 | APIの変更が必要な理由を伝える。開発中にAPIからダミーデータがほしいときにはその旨を伝える | APIスキーマは都度確認するより、仕様とデザインが固まったら早めに決める。変更が最初にアプリエンジニアから必要な変更がAPIを伝えるか、APIスキーマを提案すると進めやすい。 |
まとめ
どの場面でも仕様書やFigmaやAPIスキーマのように具体的な対象をもとにコミュニケーションをとります。立場の違いによる情報の差を減らすことで、その対象の完成度を高めることができます。またそれらを行う決めるタイミングによって全体のコミュニケーションコストが変化するので、早めに決めることで、コミュニケーションコストが下がって効率的に開発が行なえます。
