「にっぽーくん」で変わる日報作成：チーム開発のアイデアから実装まで

開発したアプリの概要

アプリの名前: にっぽーくん

主な機能と目的:

にっぽーくんは、日報作成の負担を軽減し、効率的かつ質の高い日報を作成するためのアプリです。主な機能として、以下の特徴があります。

• 日報作成の負担を軽減: Notionのような機能とショートカットキーを搭載しており、簡単に日報を記入できます。
• PDCAサイクルテンプレート: 日報の内容をPDCAサイクルに沿って記入できるテンプレートが用意されています。
• AIレビュー機能: AIが日報の内容を自動でレビューし、フィードバックを提供します。
• 余談や相談の入力: 余談や相談を自由に記入できるスペースを設け、より柔軟なコミュニケーションをサポートします。

これらの機能により、ユーザーは手軽に日報を作成し、日報の質を向上させることができます。また、日報を通じて情報共有やコミュニケーションを促進し、学習意欲を高めることができます。

対象ユーザー:

にっぽーくんは、特にアプレンティス生を対象としています。アプレンティス生とは、エンジニアを目指して学習を進める人々で、日報作成が日々のタスクに含まれています。彼らは仕事をしながら学習することが多く、効率的な時間管理を求めています。また、独学で学ぶことが一般的であり、コミュニケーションの場が限られているため、日報を通じての情報共有とコミュニケーションが重要です。

開発の背景と動機:

日報作成は、内容が偏ったりマンネリ化しがちで、モチベーションの低下を引き起こすことがあります。この問題を解決するために、にっぽーくんは企画されました。日報作成をより簡単かつ効果的にすることで、学習の継続性を高め、学習効率を向上させることを目指しました。また、学習中の挫折を減少させるために、コミュニケーションを促進し、ユーザー同士が支え合える環境を提供することも目指しています。

技術スタック:

にっぽーくんの開発には、以下の技術スタックを使用しました。

• React: フロントエンドの開発に使用しました。
• Redux Toolkit: 状態管理を効率的に行うために使用しました。
• Gemini API: AIのレビュー機能を実装するために利用しました。

開発プロセス

にっぽーくんのアイデアが具体化し、いよいよ開発が始まりました。このプロセスを通じて、私たちがどのようにアイデアを形にしていったかを紹介します。

アイデアの発案と企画:

にっぽーくんのアイデアは、日報作成の負担を軽減し、学習のモチベーションを保つために生まれました。日報が偏ったりマンネリ化する問題を解決し、学習中の挫折を防ぐことが目標でした。初期の企画段階では、PDCAサイクルの実践と日報提出率の向上を目指しました。具体的には、以下のようなポイントが考慮されました。

• 提出率の向上: 100%の提出率を目指し、PDCAサイクルを効果的に回す機能を追加。
• 日報作成の簡便化: 5分以内で日報を記入できるように工夫。
• コミュニケーションの促進: ユーザー間のコミュニケーションを活性化し、モチベーションの向上を図る。

開発チームの構成:

開発チームは3人で構成され、役割は流動的でした。メンバーはそれぞれの得意分野に基づいて選ばれ、必要に応じて役割を変更しながら開発を進めました。特定のリーダーを置かず、全員がリーダーシップを発揮する体制をとりました。

開発の進め方:

プロジェクトのスケジュールは以下のように進行しました。

• 4/8(月) - 4/21(日): アイデア決定
• 4/22(月) - 5/5(日): スライド作成と要件定義
• 5/6(月) - 5/26(日): 設計とタスク出し
• 5/27(月) - 6/2(日): 環境構築
• 6/3(月) - 6/9(日): 実装とプレゼン準備
• 6/9(日): プレゼン

プロジェクト管理にはGitHubフローを採用し、GitHubのタスクボードを活用してタスクの進捗を管理しました。

テクニカルなチャレンジ:

開発中に直面した主な技術的な課題は以下の通りです。

• Reactの学習と実装: 筆者はReactを初めて使用したため、学習しながら実装を進めました。
• AI機能の実装: Gemini APIを用いてAIレビュー機能を実装は、メンバーに担当してもらいました。

これらの課題は、チームメンバーの協力と指導を通じて解決しました。

テストとデプロイ:

アプリのテストは手動で行い、デプロイはVercelを使用して実施しました。デプロイに関しては、専門知識を持つチームメンバーに担当してもらいました。

開発におけるチームのコミュニケーションの取り方

チーム開発において最も重要なのはコミュニケーションです。以下に、私たちがどのようにして効果的なコミュニケーションを図ったかを紹介します。

ミーティングの頻度と形式:

チーム開発期間中、ミーティングは週に3回程度行いました。チーム開発週間には、毎日ミーティングを実施しました。ミーティングはオンライン形式で、Discordのボイスチャネルを使用しました。主な議題は以下の通りです。

• 実装中の課題共有
• 必要な機能の再確認
• 実装の優先順位付け
• プルリクエストの依頼と詳細説明
• コーディングに関する補足説明

コミュニケーションツール:

チーム内のコミュニケーションには、DiscordとGitHubを活用しました。

• Discord: 音声でのやり取りや画面共有を通じたコードレビュー、アプリの見た目確認、参考資料の共有に使用しました。
• GitHub: コードや開発環境の共有、タスク管理に使用しました。

情報共有の方法:

プロジェクトに関する情報共有は、主にGitHubとFigmaを使用しました。GitHubでコードを共有し、Figmaでアプリの見た目や機能を共有しました。詳細な説明はDiscordで行いました。

フィードバックの取り方:

コードレビューやフィードバックはGitHubのプルリクエスト機能を使用して行いました。各自のローカル環境で動作確認を行い、必要に応じて修正を加えました。プルリクエストには、レビュー待ちのラベルを付け、レビューが必要な状態を明確にしました。

GitHubを用いたコミュニケーション

効果的なプロジェクト管理とスムーズなコミュニケーションを図るために、GitHubをどのように活用したかを紹介します。

リポジトリの構成:

GitHubのリポジトリは以下のように構成しました。

.github: GitHub関連の設定ファイル

• nippo-kun: アプリのメインディレクトリ
• public: 公開リソース
• src: ソースコード
• .gitignore: Gitが無視するファイルリスト
• README.md: リポジトリの説明文書
• package-lock.json, package.json, yarn.lock: パッケージ管理関連のファイル
• server: サーバーサイドのコード

ブランチ戦略として、mainブランチにはユーザーが利用できる安定したコードをマージし、developブランチに各機能のfeatureブランチをマージする方法を採用しました。

タスク管理:

GitHubのタスクボードを使用して、機能ごとにカラムを分割し、各カラム内でタスクを細分化しました。タスクが完了したらDoneカラムに移動し、ラベルを付けてタスクの状態を一目で確認できるようにしました。

プルリクエストとコードレビュー:

各機能ごとにブランチを作成し、機能が完成したらプルリクエスト（PR）を作成しました。コードレビューはGitHubのレビュー機能を使用して行い、必要に応じて直接話し合いながら進めました。レビュー待ちのPRにはラベルを付け、レビューが必要な状態を明確にしました。各自のローカル環境で動作確認を行い、問題があれば指摘し、修正を行いました。

コミットメッセージ:

コミットメッセージには期待する動作や変更内容を明確に記載し、見た目の確認が必要な場合は画像を添付しました。また、どの部分を重点的にチェックしてほしいかをコメントに記載しました。

個人開発とチーム開発の違い

個人開発とチーム開発の違いについて、私たちが感じたことを共有します。

役割分担:

個人開発では全ての役割を一人で担う必要がありますが、チーム開発では役割を分担することで効率的に進めることができます。今回のチーム開発では、特定のリーダーを設けず、各メンバーがリーダーシップを発揮するようにしていました。役割分担は流動的で、必要に応じてヘルプに回ったり、全体の進捗をコントロールしたりしました。これにより、自分のタスクだけでなくメンバーの状況や開発全体の状況を把握することが重要となりました。

コミュニケーション:

チーム開発では、タスクの進捗状況だけでなく、メンバーにどれくらいの負担がかかっているのかを把握する必要があります。進捗状況だけを見ると順調に進んでいるように見えても、過度な負担がかかっている場合もあるため、そのようなこともコミュニケーションを通じて共有することが大切です。また、日常的な雑談も交えながら関係性を良くしておくことで、開発に関する話題を気軽に話し合える雰囲気作りが重要です。

効率とスピード:

個人開発では、自分のペースで作業を進めることができるため効率的に感じることがありますが、問題に直面した時には自力で解決する必要があります。一方、チーム開発では、コミュニケーションに時間がかかる一方で、問題を共有して複数の意見を反映させることで迅速に解決することができます。

品質管理:

チーム開発では、複数の視点からコードをレビューすることで、個人では気づきにくい点を指摘し合い、より良い品質のコードを作成することができます。個人開発では、自己レビューに頼るため、多角的な視点を持つことが難しくなります。

課題と解決策:

個人開発では、コミュニケーションコストが少ないため、実装に集中しやすいというメリットがありますが、チーム開発では問題解決のプロセスが短縮されるという利点があります。チームメンバーとの良好な関係性を築き、心理的な負担を軽減することで、コミュニケーションコストを抑えつつ、迅速に問題解決に取り組むことができます。また、個人開発では、多角的な視点を意識して自己レビューを行うことで、コードの質を向上させることが重要です。

開発を今後に活かすために

最後に、今回の開発経験を今後にどう活かすかについてお話しします。

学んだ教訓:

今回のチーム開発を通じて、いくつかの重要な教訓を学びました。まず、時間的な余裕を持ってタスクに取り組むことの重要性です。計画通りに進まない場合もあるため、余裕を持ったスケジューリングが必要です。また、問題が発生した場合は早めにチームに共有し、ヘルプを求めることが大切です。メンバー間でのコミュニケーションを円滑にする雰囲気作りも欠かせません。そして、自分のタスクだけでなく、メンバーの状況や開発全体の進捗を把握することが、プロジェクトの成功に繋がると実感しました。

改善点:

次回のプロジェクトでは、以下の点を改善したいと考えています。まず、自分から積極的にコミュニケーションを取るようにします。そして、開発全体の状況を正確に把握し、余裕を持ってアプリを完成させるためにスケジュールを微調整します。メンバーに適切に質問やヘルプを求めることで、自分のタスクが滞ることなく、チーム全体の開発が円滑に進むようにします。また、自分のやっているタスクをチームにも共有し、透明性を高めることが重要だと感じました。

スキルの向上:

今回の開発を通じて、新しいスキルを身につけました。特にReactを使った初めての実装経験が大きな収穫でした。ただし、APIやサーバー、デプロイに関する部分はメンバーに任せていたため、今後はこれらの分野も学習し、取り組んでいきたいと考えています。また、GitHubの機能を活用したチーム開発の経験も大きな財産となりました。

チームの協力:

今後のプロジェクトでは、もっと効果的にチームとして協力するために、以下の方法を取り入れたいと考えています。まず、自分のことだけにフォーカスせず、メンバーや全体の進捗にも気を配るようにします。また、リーダーでなくても、開発全体の進捗を意識し、チーム全体の成功を目指して行動することが重要です。

個人の成長:

今回の経験を通じて、チームで開発する際に自分はどのように振る舞うべきかを学びました。また、自己成長のためにさらに学びたい分野を明確にすることができました。これからもチーム開発の中で、自分の役割を理解し、より良い成果を出せるように努力していきたいと考えています。