g198satoのブログ

学んだ技術の備忘録など

チームでのアプリ開発を終えて、反省

卒業研究にて、チームでアプリ開発をしました。2年かかったプロジェクトで、私は半年遅れてのジョインでした。 メンバーからは「全体の8割は佐藤が作った」と言ってくれたりもしましたが、自分でもそうだと思います…。 私の責任でかなり自由に開発させていただけたので、とても学びが多い1年半でした。備忘録として、反省を行います。

目次

反省点

◯上手くいったこと、次回からも続けたいこと

読みやすいER図の作成

データベースの構造を確認する時間を短縮することができました。 一手間かけて、読みやすさ向上のための整形を行うことは重要だと感じました。

Dockerによるローカル環境の構築

私がプロジェクトにジョインした当初、1つのサーバに複数人で同時に接続して、そこでコーディングを行っていました。 この手法では、Linuxのコマンドの入力ミスが原因で、全員の開発が止まってしまい、かつ復元に長い時間を要することが度々ありました。

Dockerによるローカル環境での開発を導入したところ、大きなトラブルが発生することもなく、MailHog等のツールを導入する際も私個人の環境で動作確認を行ってから他のメンバーにも適応するといったことができるようになりました。

環境をコードで管理できることの恩恵を強く感じたため、TerraForm等、IaCの導入は今後も積極的に行いたいです。

GitHub-Flowによるブランチ運用、コードレビュー

他のメンバーにプルリクエストを送ってもらって、私がレビューを行いmainブランチにマージしていました。

最新のmainブランチだけをデプロイすれば良いというのは、ルールとして分かりやすく、ミスを防ぎやすいと感じました。 また、コードレビューを行うことで、全体のコードを把握でき、不具合の原因を突き止めやすかったです。

△一定の効果はあったが、次回からは改善したいこと

開発者用のドキュメント作成

Dockerのインストールからコンテナの立ち上げ方までを書いたのですが、こちらがとても効果的でした。 あるメンバーは、ジョインしてから1時間で開発を始めることができました。

ただ、手順を一個一個画像付きで示したドキュメントを書いても、読まない人は読みませんでした。 読むのが面倒らしいです。

何かいい方法がないものか、模索していきたいです。

✕できなかったこと、次回からは改善したいこと

誰もやりたがらないタスクを他人に消化してもらう

アプリのアーキテクチャの都合上、Laravelで処理すべきことの比率が大きく、私がやる必要があるタスクが多々ありました。

報告書の作成や各種データ入力等は、他のメンバーに一度はお願いしてみたものの、嫌がられたり、着手する気配が無いと見るや否や、 自分で済ませてしまいました。

卒業論文が書ければ何でもいいというメンバーが多数の中、アプリの完成度を少しでも高めたいというエゴに付き合ってもらうわけですから、私自身のタスクが多くなるのは当然だと思います。

しかし、もっとしっかり頭を下げてお願いした方が良かったです。

テスト及びデプロイの自動化

報告書に書ける、目に見える形での成果を上げ続けなければならないという思い込みもあり、テストコードの作成や、CI/CDツールの導入を最後まで後回しにしてしまいました。 これによってかなりの時間や労力をロスしたと思います。

残存タスクの可視化

取引先と折衝する中で、多くの注文を受けました。 バリデーション等、直接は目に見えない機能の実装を多く控えているため、工数の都合上ご要望に沿うことができない旨を伝える場面もありました。

そういった場面で、Redmine等で残存タスクを可視化し、共有することができていれば、ご説明する際に理解していただきやすくなる他、タスクの優先順位付けも円滑に行えていたと考えています。

気付いたこと

ユーザにとっては、アプリは目に見える部分が重要だと感じました。

私は開発にジョインしてからLaravelを必死に学び、将来的なアプリの拡張や、長期運用に耐えうるデータベースを設計したつもりです。 ですが、取引先やユーザにはなかなか伝わらないでしょう。

Bootstrapのドキュメントほぼその通りに作ったUIをお見せした時、取引先の方々は喜んでいらっしゃいました。

一般ユーザが「このアプリのバックエンドいいね!」なんて言うものでしょうか? フロントエンドの重要性をひしひしと感じましたし、自分がバックエンド偏重の考えに陥っていることを認識することができました。