2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

初めてのチーム開発!KPTA振返り

Posted at

目次

はじめに

突然ですが、人生初のアプリ開発をしました!

開発のきっかけは、未経験者同士で構成されたチームが、アプリ開発からプレゼン、そしてメンターによる講評を経験する学習プログラムへの参加でした。

チーム開発の実装は1週間!

厳しい日程でしたが、生徒+メンターからの投票の結果、Best Award賞をいただきました!(評価していただいた方、ありがとうございます。)

今回の投稿では、このチーム開発を通じた学びを振り返るために、KPTAフレームワークを用いて分析します。

スケジュール

期間 内容
10/7(月) - 10/20(日) アイデア決め
10/21(月) - 11/3(日) スライド作成、要件定義、設計
11/4(月) - 11/17(日) タスク出し、環境構築
11/18(月) - 12/1(日) 今まで未完了のタスクを完了させる
12/2(月) - 12/8(日) 実装、プレゼン準備
12/8(日) プレゼン

プロダクト概要

プロダクト名

Health Vison(ヘルスビジョン)

使用技術

・フロントエンド : HTML / CSS / JavaScript
・バックエンド : Ruby(Webrick erb mysql2)
・データベース : MySQL
・ソース管理 : Git/GitHub
フレームワークを使用せず、生の言語を学ぶことを目的に開発しました。

背景

このアプリを開発した背景として、「健康は最高の財産!」という言葉に注目しました。健康を維持するためには運動が欠かせません。

実際、厚生労働省が作成した「健康づくりのための身体活動・運動ガイド」のよると、運動不足は喫煙・高血圧に次いで3番目の危険因子とのこと。また、運動は全ての国民が取り組むべき重要課題として位置付けられております。

↓以下、厚生労働省のHPです。

課題

しかし、現代社会では「とにかく忙しい」という大きな壁があります。運動の重要性を頭では理解していても、実際に習慣化するのは難しいですよね。

ちなみに、ガイドラインによると成人の運動推奨量は、1週間に消費カロリー2,00cklが必要です。

どうですか?2,000kclといわれてもあまりピンとこないですよね。

機能

そこで、以上の背景・課題を踏まえ以下の要件を満たすアプリを開発しました。
・運動実績を記録でき、一覧で確認することが可能。
・運動継続日数を表示。
・継続日数に応じたバッジが付与、コメントを表示。
・1週間周期で消費カロリーが更新され、推奨運動量(2,000kcl)に対しての達成率を表示。

こんな人につかってもらいたい

  • 普段忙しいが、運動を習慣化したい人
  • 運動した実績を記録して可視化したい人
  • 運動モチベーションを高めたい人
  • 健康意識を高めたい人
  • シンプルで使いやすいアプリを求めている人

画面遷移図

本アプリは、「ホーム」「実績入力」「運動履歴」の3つの画面から構成されています。
スクリーンショット 2024-12-14 9.07.30.png

ホーム

メインとなるホーム画面では、以下の情報を確認できます。
image.png

  • 達成状況:
    推奨消費カロリー(2,000kcal)に対して、1週間あたりの消費カロリーと達成率を表示します。
    達成率に応じたグラフも表示され、進捗状況が一目で分かる設計です。
    消費カロリーは1週間周期で更新されます。

  • 継続日数:
    運動した継続日数を表示します。1日でもサボると0カウントにリセットされるため、継続意識が高まります。

  • バッジ:
    継続日数に応じたバッジを付与します。バッジシステムによって、次の目標に向けたモチベーションを高められます。

  • コメント:
    継続日数に応じて異なるコメントを表示します。

    • 継続日数が0日の場合: 運動不足による健康リスクを知らせ、運動を促します。
    • 1日以上継続した場合: 運動のメリットや健康に関する豆知識を提供し、モチベーション維持をサポートします。

【参考】バッジシステム
スクリーンショット 2024-12-14 9.37.32.png

実績入力

各運動の実績を入力する画面です。今回は、腕立てと腹筋を30回、仕事の往路で歩いたと仮定して徒歩1時間と入力してみます。
image.png
すると、フォーム送信完了画面へ遷移するのでホーム画面へ戻ります。
image.png
ホーム画面へ戻ると達成状況等が更新されます。
image.png

運動履歴

入力した運動実績を一覧で確認することができます。今回は、3種類のみのしか登録していないので3行しかありませんが、本画面は過去の全ての運動実績を対象に表示されます。
image.png

ユーザーへのメリット

1. 運動習慣の定着をサポート

  • 継続日数が少ない場合、運動不足による健康リスクを知らせる仕組みがあり、健康を意識するきっかけを提供。
  • モチベーションを上げるポジティブなコメント機能で、ユーザーが行動に移しやすくなる。
  • 健康に関する豆知識やメリットを提供するコメント機能で、単なる運動記録ツール以上の付加価値を提供。
  • バッジシステムや達成率グラフにより、達成感を得やすく、継続のモチベーションを高める。

2. 手軽に健康管理ができる

  • 忙しい日々の中で簡単に運動記録を残し、1週間ごとの進捗を確認できるため、手間をかけずに健康管理を行える。
  • カロリー消費や継続日数の情報を一目で把握でき、効率的な健康管理が可能。

3. 忙しい人でも使いやすい設計

  • 簡潔な画面構成と直感的な操作性により、忙しい人でも手軽に利用が可能。
  • 必要な情報が集約されたホーム画面で、詳細な操作をしなくても進捗確認が可能。

KPTA

以上が、開発したプロダクトの概要です。
講評後、メンターさんよりKPTAという振り返りフレームワークというものを紹介いただきました。
早速、チーム開発の振り返りを、KPTAフレームワークを用いて分析します。

KPTAとは、
有名な振り返り手法にKPTがありますが、そこに「Action」を追加したものになります。


Keep(維持するべき点)

HRT

未経験者は技術力で劣るため、チームの活発さや生産性を向上させることが重要です。
そのために大切にしたのが HRT

  • Humility(謙虚さ)
  • Respect(尊敬)
  • Trust(信頼)
    です。これらを実践するために、以下のような行動を心がけました
  1. Humility(謙虚さ)
    • 自分がわからないことを素直に認め、積極的に質問することで理解を深める。
    • 他のメンバーの助けを求める際に感謝の気持ちを伝えることで、良いチーム関係を構築する。
       
  2. Respect(尊敬)
    • 他のメンバーの意見を否定せず、まずはしっかりと耳を傾ける。
    • メンバーが努力した成果を認め、感謝の気持ちを言葉にして伝えるよう心がける。
    • 自分の意見を述べる際も、相手を尊重した言葉遣いを意識。
       
  3. Trust(信頼)
    • 進捗状況を頻繁に共有し、他のメンバーに安心感を与えるよう努めた。
    • チームのゴールを最優先に考え、個人の成果よりも協力を重視。
    • チーム内の雑談を大切にし、仕事以外の話題も交えることで、メンバー同士の距離感を縮めた。
      例:過去の失敗談、恋愛トーク、最近のお気に入りの音楽。

逆に、これらが欠けてしまうと、衝突が生じてチームの目標達成が難しくなる可能性になると思います。

WOL

Working Out Loudの略であり「自身の作業や思考を可視化し・共有し、チーム全体相乗効果を高める方法」です。チーム開発前に以下の記事を発見し、未経験者が意識しなければいけない点だなと思ったため、チーム開発時にもこれを意識していました。

以下のような具体的な行動を心がけました。

  1. 進捗のこまめな共有
    • 作業の進捗や取り組んでいる課題を、チーム内のミーティング等でこまめに共有する。
      • 例: 「〇〇の実装が完了しました。次は△△に取り組みます。」
      • 例: 「現在、クエリ結果をフロント部分に埋め込みができない課題に直面しており、解決にもう少し時間がかかりそうです。」
         
  2. 「見える化」の工夫
    • 作業の進行状況をgoogleドキュメントや、コメントアウトを活用して作業の透明性を向上できるよう励みました。
      • 例: タスクのステータスを「未着手」「進行中」などで分類し、Google slideで共有。
      • 例: こまめなプルリクを作成し、きめ細かく実装状況を共有。
         
  3. 仮説やアイデアを積極的に発信
    • 完成形ではなくても、思考途中のアイデアや仮説を共有することで、早い段階でフィードバックを受けるよう意識しました。特に今回は、Railsを使用しずに実装していたため、どんなGemがあるのか、または使えるのか手探り状態だったため、新しい知識や情報が見つかったらすぐに共有する環境を雰囲気作りをすることができました。
      • 例:  記事を探して、新たな発見があった場合はチャットで共有。また、その雰囲気、仕組みを構築。  
         
    • 自分がチーム内で最年長だったため、チーム全体のマネジメントは意識しておりました。具体的には、開発の初期段階から、アプリの背景・課題・要件等をmd形式で取りまとめたものをすぐに共有するなどして、開発方針がぶれないようにする点にはこだわりました。
        - 例:  発表スライドや、フロント部分の実装は早めに終わららせ、開発の方針がぶれないように早めにフィードバックを受ける。

WOLを実施することで、自然と思考と実績を整理することができました。また、作業状況の透明化を図ることで、相談のハードルが下げられることにもつながったと思います。


Problem(問題点)

  1. 役割分担の不明確さ
    • フロントエンドやバックエンドの基本要件を担当しており、短い時間の実装だったため負担が大きかった。
    • そのため、タスクの遅延がたびたび発生。結果として、リソース配分が非効率になってしまいました。
       
  2. ユーザー視点の不足
    • アプリの設計がデスクトップ利用を前提としており、実際のユーザーが使用するモバイル環境を十分に考慮できていませんでした。
    • ユーザーのニーズや行動パターンを事前にヒアリングするプロセスがなかったため、実装の一部が現実の利用シーンにそぐわない結果となってしまいました。
        
  3. GitHub運用の課題
    • 短期間の開発だったため、コードのコンフリクトは発生しませんでしたが、これは運用が適切だったというよりも、単純に作業範囲が限定的だったためだと推測します。
    • 実務を想定すると、複数人が同時に作業を行うことため、コンフリクトが発生する可能性が高いです。その解消スキルや運用ルールの不足が課題として残っています。
        
  4. 技術不足
    • 他のチームのプロダクトには、高度な技術が多数取り入れられており、その完成度に感心しました。講評後の交流会を通して、同じような学習歴を持つメンバーが作成したものと比べても、自分の技術力やアイデアの練り込み不足を痛感しました。  

    • コンセプトに沿った機能が実装されれば十分という認識で進めていましたが、他のチームはより幅広いユーザーのニーズを考慮したり、機能同士を連携させたりして、プロダクトをより魅力的に仕上げていました。その「機能の深さ」と「使い勝手の高さ」に圧倒され、自分たちのプロダクトの改善点が多く見つかりました。


Try(試すべき新しいアプローチ)

Try(試すべき新しいアプローチ)の項目では、Problemに対して、実施すべきと感じたものを列挙します。挙げた項目に対して、具体的に何が必要なのかは次項のAction(実行する具体的な行動)で整理します。

  1. 役割分担の明確化
     
  2. ユーザーファーストの対応
     
  3. GitHub運用の強化
      
  4. 技術力の強化

Action(実行する具体的な行動)

それでは、選択したTryに対するActionを挙げていきます。

  1. 役割分担の明確化
    • 次回のチーム開発では、機能単位やフロント・バックエンドごとに役割分担を真っ先に決定。役割分担を決める際は、きめ細かなタスクばらしをし、全体のバランスを見ながら分担するよう試みる。また、タスクバラシによりやらなくてもいいタスクも明確化が可能。
      • 例:  見積もりをする。0.5h, 1h, 2h, 4h。4hを超えるならタスクを分解、ゴール達成に必要なタスクをリストアップする
         
    • チーム開発のメリットはその手数、知識の豊富さ。各メンバーの得意分野や成長したい領域を踏まえてタスクを割り振り、効率的に開発を進めるように意識する。
        
  2. ユーザーファーストの対応
    • 機能要件を満たせば、満足するのではなく、逐一ユーザー視点に立ち、どんな設計・実装が必要なのか意識する。
       
    • また、実際にテストユーザーに利用してもらい、フィードバックを受けるとともに改善すべき点を定期的に議論し、迅速に対応する等のユーザーファーストの精神をもつ。
        
  3. GitHub運用の強化
    • 次回のチーム開発前に、チーム全員がコンフリクト対応を経験するシミュレーションを実施。
       
    • 次の技術力研鑽にもつながりますが、コードレビューの頻度を増やす。レビューを通して、コードの可読性・保守性を意識した議論をし、開発の品質向上に努める。また、レビューを受ける際には、周りの空気を読んだ、自分勝手ではないコーディングを意識。
        
  4. 技術力の強化
    • これは、継続的な学習あるのみです。朝は脳も活発になるため、学習効率も高く、たいてい予定がなにので、「毎日やる」ことが実現しやすいかと思います。これは、継続できてはいますが、周りの技術力の高さに感化されたのは忘れず、どんな忙しい日でも朝の学習時間は確保する点は必須項目にします。
        
    • また、モチベーションを維持するために、今日できたことに注目するよう意識します。学習性無力感から脱するために必要なのは「毎日、自分の成長をちょっとでも実感する」ことです。

最後に

未経験者にとって、チーム開発に携わる機会はなかなかありません。そのため、今回のチーム開発は非常に貴重な経験となりました。

特に、**HRT(謙虚さ・尊敬・信頼)WOL(作業の可視化と共有)**を意識した行動が、チーム内の信頼関係や協力体制を築く上で大きな効果を発揮したと実感しました。この学びは、今後の開発においても大きな武器になると確信しています。

また、今回のプロジェクトを通じて明らかになった以下の改善点を次回のプロジェクトで活かすためにも、定期的に本記事を見返すべきです。

  • 役割分担の明確化
  • ユーザーファーストの対応
  • GitHub運用の強化
  • 技術力の向上

また、交流会を通して周りの技術力の高さに感化されたのは、良い劣等感として、前向きにとらえたいですね。

最後まで読んでいただき、ありがとうございました!

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?