はじめに
部活のプロジェクトで「技術好きの学生向けのSNSアプリを開発しよう！」ということになりチーム開発をすることになりました。
そこで、TechTrainというエンジニア志望のU30向けメンタリングサービスを利用し、インターンという形でリリースを目指して開発を続けてきました。
結果としてはリリースならず...！となってしまいましたが...
メンターさんの指導のもと、実務レベルでのアプリ開発を4~12月の8ヶ月間行なってきたので得られたものが非常に多かったです...！
今回、僕はAndroid担当兼PMというポジションでこのプロジェクトに関わってきたので、それぞれの立場から記事を書こうと思う次第...
本記事は後半のPM/PL編です！
時系列に沿って書いていこうと思います。
また、以下に各プロジェクトメンバーの記事を紹介します。
デザイン
デザインをメインタスクとした人の「SNSアプリプロジェクト」活動記録
Server
開発初心者が8か月間のチーム開発に参加して感じた反省
[サークルでGoサーバ書いて成長した話]
(https://qiita.com/tknd/items/0e7396245e3ef4dd34f9)
Android
TechTrainを利用してチームでアプリ開発をした話（Android編）
【Android】MVPでQiitaアプリを作ってみる・そしてポエム
iOS
チーム開発って難しい
【注意：本記事はプロジェクトマネジメントの手法というよりも個人的なアウトプットと意見が多くなっています。純粋にマネジメント手法を知りたいなどの場合は他記事を当たられることを推奨します。予めご了承ください】
プロジェクト序盤
プロジェクト立ち上げ時、まずやったことはアプリの主要な機能を決めるでした。
もちろん、「全国の技術好きの学生達を繋げたい」という思いからスタートしたのですが、それを実現するための機能を考える必要があります。
そこで必須とした機能は以下の通りです。
- SNS機能
- イベント一覧表示機能
- マイページ機能
次に、これらの機能の他にどの機能をサブとしてつけるかの議論を行いました。
以下のような機能をつけたいとまとまりました。
- 検索機能
- いいね機能
- お気に入り登録機能
- 外部ID連携
- 返信機能
- 画像投稿機能
ここまでは結構スムーズに決まりました。
続いて、これらの機能を画面に落とし込むのですが、ここでかなり難航しました。
なぜ難航したのかというと
- いきなり細かい仕様を詰めようとし過ぎた
- クライアント担当者とデザイン担当者の認識のギャップを合わせる必要性があった
- 議論が煮詰まってくると全く言葉が無くなる雰囲気になっていた
- 迷ったらメンターさんなどに「相談する」ができていなかった
ここら辺の要因がかなり大きいように感じました。結果として連日長丁場の会議になってしまいがちで、個人的にもかなりストレスの溜まった期間でした。
なら、どうすべきだったかというと...
- 迷ったら、まずメンターさんや、クライアント（今回で言うとTechBowlさんの社員の方々）などに聞いてみる。
- そもそも今悩むべき問題であるのか取捨選択する。（悩むべき問題とは、今後修正が効かなくなってしまうような問題）
- 長時間の会議をするよりも、「議題」と「時間」を定めて効率的な会議を実施する。
ここら辺をできるようになると、もっといい雰囲気でスムーズな会議になりそう
一方で、この画面割りと同時進行で行なったのが**「スケジュール決め」**です。
取り決めた機能に対して工数を割り出し、全体のスケジュールを組みます。
これに関しては、実装したい機能自体はしっかり決まっていたのでスムーズに決めることができましたが、後から考えると個々のメンバーがいつ忙しいのかをもっと加味して考えるべきでした...
例えば、後々「テストで忙しかったので全くできなかった」「旅行に行くので作業できない」等の事情が必ず出てくるので、ある程度バッファとなるような期間を設定する必要もあったのではないかと考えています。
プロジェクト中盤
この期間は、以前作成したスケジュールに従って、各専門に別れて作業に取り掛かりました。
- Design：各画面のデザインのモックを作成
- Server：Go言語の学習とデータベース設計の構想
- Android, iOS：アーキテクチャの設計
このとき、まさしく各メンバーがテストで忙しくなってしまいます。
これによって全体的に2週間ほどスケジュールから遅れることになってしまいます。
さらに、デザイン担当者の作業量が爆発します。
と、いうのもかなり作り込んだ状態の候補案を3つほど作ってクライアント側に提案するという手法をとっていたので、非常に大変な思いをしていたと思います。
このような場合、大まかなデザインの方向性がクライアントのイメージからずれていないか、確認し少しずつ詳細を詰めていくことが重要だと学びました。
プロジェクト終盤
サーバーサイドはデータベースとAPIの構築、クライアントサイドでは完成したモックを参考に画面の作成と各種内部実装に取り掛かりました。
この時期になると、各班遅れが顕著になってきました。
毎週行なっている進捗報告でも、「特に理由はないが遅れている」といったことがありました。
この時、メンバーによってはタスクの粒度が大きすぎる場合があるといった問題が潜んでいたのです。
すなわち、一週間単位で割り振っていたタスクを、メンバーによっては粒度的にも日数的にもさらに分割すべきである段階だったのです。
さらに、進捗報告の仕方にも問題がありました。
今までは、口頭および文章上での報告で、**「何が終わっていて」「何が終わっていないのか」「何が問題なのか」**が把握しにくかったのです。
この問題を解決するために教えていただいた手法の中から、私個人が最も効果的だなと思い、導入したのがGitHubを利用した進捗管理です。
以下の記事を参考にしました。
新入社員におくるGitHubでのプロジェクト管理の初歩
簡単にいうと、GitHub上で必要となるタスクをIssues書き出し、PRに結びつけることで進捗管理を行います。
さいごに
さて、いよいよ最後となりましたが、今回のプロジェクトを通して各メンバーが多くのことを学び、アウトプットを行なってきました。
頭にある内容を説明できるステージまで押し上げることで理解力は大きく前進すると私は考えているので、各メンバーにも是非記事を書いて欲しいと思い、実際にこのAdvendCalenderの場をお借りして全員に執筆してもらいました。
さらに、今回メンターさんから教えてもらった知識を、次は他の誰かに教えることで還元していこうという心構えも重要だと思います。実際、全員が教えて頂いた知識を実践しているので、各個人の実体験が伴った説明ができるようになります。このような知識を記事で紹介したり、部の後輩に継承していくことに価値があると考えます。
書きたいことは他にも山ほどありますが、細かい話が多くなりそうなので、とりあえずこのあたりで切り上げたいと思います（笑）
メンターの皆さん・メンバーのみんな、本当にお疲れ様でした！！
曖昧になりがちのPMの疑問に対して適切なアドバイスをくださったメンターの皆さん、ありがとうございました！！
各分野のタスクで忙しいのに、力を貸してくれるメンバーのみんな、本当に助かりました！！
私も部は引退しましたが、今回の経験を元に、もう少ししたら新しい悪だくみを始めたいと思います（笑）