【アプリ制作】チーム開発で気をつけるべきこと8選

リリーススケジュールがずるずる伸びてしまう

アプリ開発を行っていて、しっかりとスケジューリングをしているつもりなのに リリースする日がずるずると伸びてしまう事はないでしょうか。
この記事では、自分が実際に今現在行っているチーム開発で、 リリース日のスケジュールが何度も伸びてしまった原因をまとめ、 リリース日が延期しない様に気をつけるべき事項を書きたいと思います。

失敗から学ぶ

この記事を読むことで、チーム開発でのリアルな失敗談を事前にインプットし、同じ失敗を繰り返さない様に準備をし、アクションを考えておくことができます。

失敗したことリスト

1. イレギュラーなシチュエーションを見込まなかった工数見積もり。
2. 集中力を考慮した見積もり。
3. リーダーがいなかったチーム開発。
4. チームの認識の一致・不一致。
5. 外部SEに依頼する際の仕様書。
6. デバッグ方法の知識不足。
7. 一つの端末で開発したこと。
8. タイトなスケジューリングが産んだバグの多い成果物。

イレギュラーなシチュエーションを見込まなかった工数見積もり

工数見積もりをする時、大体の場合、その作業に掛かる工数のみを見積もります。しかし、実際には自分たちが予想できなかった本来の業務とは全く別の業務が入ったりすることがあります。

予想外のエラー、研修、ミーティング、仲間のフォローや電話対応。
たくさんの小さな対応が蓄積され、気づけば予想した見積もりをオーバーしてしまいます。1タスクの予想した工数 +2時間 くらいでぴったりの感覚だと考えておいた方がいいかと思います。

集中力を考慮しなかった見積もり

こちらも工数の見積もりについての失敗です。 見積もった時には想像できない集中力の上がり下がり。 今日の作業を終わらせる為の残業のはずが、次の日の寝不足を生み出し、思考能力が低くなってしまったことなどがありました。
また、プレッシャーから頑張っている最中の集中力は非常に低く、次の日の朝に10分程で解決してしまったり。
しかし、集中力が高い時低い時をしっかりと理解し、消化するタスクを選んでいけば見積もった工数を縮めることも十分可能だなと思います。

リーダーがいなかったチーム開発

開発する際にはっきりとした開発リーダーがいなかった為に、それぞれが独自の方法で担当分のタスクを消化していった結果、互いの成果物を結合する際に時間が掛かってしまいました。
仕様書をしっかりと作っておくというのも解決策の一つではありますが、開発リーダーを決めておくことをおすすめします。
理由としては、ソースコードには様々な書き方があり、どちらの進め方も正解という場合があります。ミーティングの無駄な時間を省く為にも、最終的なジャッジを下すリーダーの役割が必要だと感じました。

チームの認識の一致・不一致

認識に一致・不一致はチーム開発の永遠の課題でもあります。 何度もミーティングをしても、やはり伝わっていないことがあります。

これを解決するのはチームメンバーの心の距離だと思います。 ちょっとした気まづさや、はっきりとした上下関係、敬語などの日本独特の文化が作り上げてしまった微妙な距離感を解決する様なアクションを取ることが重要になってくると思います。実際に僕が海外で仕事をしていた時、認識の不一致ということはあまり頻繁に起こるものではありませんでした。
そういった意味でも、社内公用語が英語の会社は将来的にコミュニケーションの円滑な会社になっていきそうです。
とはいえ英語にすると話せることも話せなくなるので、まずは定期的にお昼を一緒に食べるなど、仕事以外の場所でコミュニケーションが行える機会を作るのも一つ案ですね。

外部SEに依頼する際の仕様書

今回自社では開発の助っ人としてフリーランサーの方に、お手伝いしていただきました。 が、成果物に問題が僕たちチームが予想したものと異なるモノが。。。依頼した機能についてはしっかり実装されていたのですが、ソースコードの保守性がとても低く、結果リファクタリング作業に工数をかけてしまいました。

コミュニケーションの面では、毎週こまめにリモートでミーティングをして下さったりと問題なさそうだったので、問題点としてはこちらの依頼の仕方かなという結果になりました。
コーディング規約、保守性や汎用性のレベルについてもしっかりと決めておくなどをしてから依頼することが重要ですね。

デバッグ方法の知識不足

今回はアンドロイド開発が初めてだったこともあり、AndroidStudioの利用に苦戦しました。 慣れない開発環境で色々試しながらのデバッグ作業だったのですが、初めて利用するIDEについてはデバッグ方法や便利な機能について勉強しておくことを強くおすすめします。

一つの端末で開発したこと

これもAndroidStudioの機能にアスペクト比の違う端末のレイアウトを表示する機能があることを知らずに、自分の持っていたGooglePixel2のみで開発をしたため、別の端末でテストをした際にレイアウトに違和感のある場合がありました。

別の記事で "AndroidStudio内で様々な端末のレイアウトを確認する方法" を解説したいと思います。

タイトなスケジューリングが産んだバグの多い成果物

この失敗がリリース日をズルズルと延期した一番の原因になると思います。 タイトなスケジューリングというよりは、元スケジュールを自分でどんどんタイトにしていってしまうといった方が正確かもしれません。

それらは全て上記に書いた様な問題が重なり、時間を割き、その結果進捗が遅れ、 スケジュールに追いつこうと妥協したり、汎用性の低いコーディングをし、バグが起きる。
結局リファクタリングをしなければいけない時がいつかきます。 短期的な進捗を気にするだけでなく、長期的な進捗を考えた仕事の仕方が重要になっていくということを改めて感じました。

最後に

今回自社のアプリ開発での失敗はものすごい学ぶ事が多く、チーム開発としてのノウハウになりました。チームとしての開発は一人ではできない中規模から大規模のシステム開発ができるので、その楽しさを感じれますね。 この記事が誰かのお役に立ってくれることを心から願っています。 最後まで読んでくださり有難う御座いました。