アプリ開発のディレクションをしてみた感想・反省

こんにちは、株式会社Pentagonでアプリ開発をしている石渡港です。

今回はアプリ開発のディレクションをしてみた感想・反省についてまとめました。

【この記事を読むメリット】

• アプリ開発のディレクションをしてみた所感・注意点について理解できます

【こんな方に参考にしていただきたい】

• アプリ開発を担当しているディレクター

【調査の動機】
弊社のアプリ開発のディレクションをしてみた感想・反省についてまとめて、次回の開発に活かすため。

【調査結果】

• ディレクションの際に気をつけていたことがまとまった
• ディレクションの際に上手くできたこと、上手くできなかったこと, 困ったことを洗い出せた
• 今後の改善案（自分視点とチーム視点）を把握できた

【結論】

今回は、ディレクションの際に上手くできたことや困ったこと、そして今後の改善案（自分視点とチーム視点）についてまとめました。

ディレクションの際に気をつけていたこと

• デザイナーチームとの密なコミュニケーションの意識
  前回のプロジェクトの改善点・反省点です。
  エンジニアとデザイナーとのコミュニケーションが不足しないように、MTGを週1回15〜30分程度行って、互いのチームの捉え方の相違をなくし手戻りを減らす意識をしました。
• Issue作成にかける時間を減らす意識
  個人的な反省点ですが、前回のプロジェクトで細かくIssueに記載を行っており、わかりやすさは向上しましたが、時間をかけすぎていました。
  そのため、Issue作成にかける時間を減らすように心がけていました。
• スケジュール調整・遅れの意識
  前回のプロジェクトの反省点です。
  スプレッドシートでガントチャートを作成して、スケジュールの調節を行って、遅れを意識することでスケジュールの見える化を行いました。
• 開発ルールの徹底
  前回のプロジェクトの反省点です。
  開発のルール（レビュー、マージなどの手順）を明確にREADMEに書くことによって、誰がジョインしてもすぐに開発に着手できるようにドキュメント化しました

ディレクションの際に上手くできたこと

• デザイナーチームとの密なコミュニケーション
  デザイナーチームとの密なコミュニケーションの意識をしたことで、互いのチームの捉え方の相違を減らして手戻りを減らせたと思います。
• 開発ルールの徹底
  開発のルール（レビュー、マージなどの手順）を明確にREADMEに書くことによって、今回ジョインした2名が迷うことなく開発に着手できたと思います。

ディレクションの際に上手くできなかったこと, 困ったこと

• お客様とのコミュニケーション
  今回のプロジェクトでは、前回・前々回と違いバックエンドの開発がお客様側でした。そのため、序盤に連絡手段を持ち合わせておらず、スケジュール・ドキュメントの点で手戻りが多く発生してしまいました。
• スケジュール調整・遅れの意識
  今回のプロジェクトでは、私やチームメンバーの事情で工数の割り当てがうまく行かず、スケジュールどおりに進まなかったです。
  途中、増員や効率化である程度は巻き返せましたが、序盤に工数が減ったため予定していたリリースが行えませんでした。
  また、人数不足や工数不足によって遅れが生じてしまい、レビューを受ける時間が少なかったです。
  その結果、セルフレビューが多くなりバグを事前に発見できない事情も発生しました。
• テスト不足
  • 機能ごとの単体テスト、レビュー時のレビュー不足、結合テストそれぞれが不足した

今後の改善案（自分視点とチーム視点）

• お客様とのコミュニケーション
  • 自分視点
    プロジェクト開始時に懸念点を洗い出して、スケジュールとのすり合わせを行います。その後に懸念点による初期スケジュールとの差を伝えることでスケジュールに余裕をもたせつつ、お客様に安心感を与えられると思います。
  • チーム視点
    プロジェクト開始時点でお客様とのコミュニケーションルートを明確にして、連絡を定期的に取り合うことで、スケジュールの調整を容易にできそうです。また、手戻りを減らすことができると思います。
• スケジュール調整・遅れの意識
  • 自分視点
    今回のプロジェクトで起きた遅延やテスト不足を見越して、余裕があるスケジュールを組むことを心がけようと思います。
  • チーム視点
    他プロジェクトで利用を始めたbacklogを利用してチケットを作成する。そうすることでガントチャートを利用できるため、スケジュール・遅れの見える化を行えると思います。また、ガントチャートを利用して第3者にスケジュールレビューを行ってもらい精度を上げることも大事だと思いました。
• テスト不足
  • 自分視点
    今回のプロジェクトでは、PR単位のレビューのレベルが低かったことでテスト不足が起きやすい環境だったと思いました。そのため、レビューのレベルを上げるように意識したいです。また、機能の追加毎に単体テストを行っていなかったのでこちらも行うように意識すべきでした。最後にスケジュールにフェーズなどを設けて、フェーズごとに結合テストを行うなどルール化して、定期的に結合テストをしたいと思います。
  • チーム視点
    自分視点と被る部分でもありますが、全体でもレビューのレベルを上げるように意識するべきだと思いました。また、今回のプロジェクトでは自動テストを行っておらず、未然に防げたバグを見つけきれていないと思いました。最後に各々で開発したコードを自分でテストした際にバグを発見しづらい問題があります。対策として、テスターを雇う・他プロジェクトからレビュアーを連れてきてもらうなどをした方が良さそうです。

まとめ

この記事では、ディレクションの際に上手くできたことや困ったこと、そして今後の改善案（自分視点とチーム視点）について感想を述べました。
ディレクションをやってみて、チームメンバーの工数予測やお客様のスケジュールなど予測できない要因が多く、プロジェクトの後半になるまでうまく調節ができず悔しかったです。
今後は、本記事にてまとめた対策を施して、プロジェクトをうまく回したいと思います。