エンジニア人生初のPM体験を終えて
エンジニア人生初めてのPM体験について振り返ってみて、色々思うとことがあったので記事にまとめてみました。
📝 プロジェクト概要
OpenAIを使った開発案件。納期は1ヶ月。
フェーズ1は終えており、今回は機能強化フェーズ。
👨💻 技術スタック
Frontend
Next.js in Typescript
Reactフレームワーク。開発体験もよくTypescriptの相性も抜群。
Backend
FastAPI in Python
Node.jsやGoに並ぶ高速な動作環境を提供できる。また、Pydanticを合わせて使うことで型定義が可能になり、パフォーマンス向上につながる。
データベース
MongoDB(NoSQL)
Firebase(Firestore)と同じNoSQLを提供しており、データ管理が簡単に行えて、データ設計も容易に変更可能なため、仕様が急遽変わってもすぐに対応できる便利なデータベース。
認証
Firebase Authentication
関数1つで認証処理が行え、フロントエンドからでもバックエンドからでも手軽に認証情報を取得できる。
👨👩👧👦 プロジェクトの規模感
・チームメンバーは以下の5人体制
- 1x PM (Project Manager)
- 2x Frontend Developer(うち1人が私)
- 2x Backend Developer (うち1人が技術顧問)
- 1x Infrastructure Engineer
・納期
1ヶ月(9/1~9/30)
🏃♀️ 走り切った感想
今振り返って、なにより無事にプロジェクトを走り切れたことにかなりほっとしています。☺️
正直なところ納期1週間前の段階では、無理かもしれないと思っており、メンタル的にも若干やられていました。
それでも初めてのPMということもあり、絶対にプロジェクトを成功させたいという気持ちが強く、また、PMを任せてくれた先輩の期待にも応えたい一心で残り1週間は、このプロジェクトだけにフルコミットしました。(スケジュール管理をしっかりしろって感じなんですが、、💦)
結果として、プロジェクト自体は成功に終えることができました。本当にチームメンバーには感謝しかないです。
共に苦難を乗り越えてれ、抽象的なイシューだったにも関わらず、しっかりと実装してくれたり、夜遅くにも対応してくれて本当に助けられました。
集められたメンバーの中には初めましての人もいて、チーム内でのコミュニケーション問題も不安に感じていましたが、逐一わからない点・実装が難しいところなど共有してくれたり、途中経過なども報告していただき、メンバー間のコミュケーションに関して何も問題なく進められることができました。(いいチーム恵まれました。)
かなりハードなスケジュールでしたが、お疲れ様でしたです。
💪 失敗から学ぶ
プロジェクトを通して、「この部分もっとうまくやれたな」とか、「もっとこうしておけばよかったな」などいくつかあったのでその反省についてまとめてみました。
1.納期がギリギリ
1週間前になって、もしかしたら間に合わないかもと思ってしまい、急いで残ってるタスクを洗い出し、チームメンバーに緊急でタスクを振ってしまった。
改善点
チームのスケジュール管理をもっと細かく把握して、いついつまでに実装を終わらせるか機能ごとに話し合って決めるべきだった。
今回の場合は、最初の段階で全てのイシューをお願いして、納期は今月末までだからそれまでに終わらせてほしいという雑な振りだったのでとても申し訳なく思ってます。
2.ドキュメントの詳細化
環境構築の部分で時間をとらせてしまった。windows環境とmac環境の両方にドキュメントを対応させていなかったため、windows環境側でエラーを起こしてしまい、開発に遅れをとってしまった。
改善点
window環境・mac環境を想定してドキュメントをまとめる。
また、ドキュメントは確認・困った時ようの材料として用意しておき、zoom等を通して環境構築はレクチャーした方が、時間の節約にもなるし、あわせてイシューの説明・プロジェクトの流れ等も確認できるので、次回以降はこちらを採用したいなと思いました。
3.イシューが抽象的
イシューがかなりざっくりとした説明のみで、⚪︎⚪︎機能を作って欲しい、このライブラリ使って実装してほしいなどざっくりとしたイシューを振ってしまった。
改善点
もっと細かくイシューを切るべき。具体的には機能ごとにイシュー切らず、機能を1段階深ぼりする。
今回の場合だと、「ファイルのアップロード」機能で、まず
①フロントエンドからデータを受け取れるかのテストする
②受け取ったデータを元になんのファイルデータ(pdf,xlsx,docx...etc)なのか明確にしてプロントで渡して、回答が生成されるかをテストする
③そのデータをフロントで受け取って表示できるかをテストする
など細かければ細かい分、実装しやすいし開発側との認識のずれもなくせるかなと思いました。
4.要件の深掘りが甘い
要件定義のすり合わせの部分でもっと深掘りするべきだったなと思います。実装してる途中でここの部分曖昧だったけど、どうするのがベストなのかなと感じた部分が何箇所かあり、自分の深掘りの甘さを実感しました。
改善点
要件定義のすり合わせの段階で、ただ「わかりました!」で終わらせるのではなく、実際に完成段階をイメージしながら話を聞き、不明な点はすぐに質問したり、自分から提案できるような姿勢・意識をしていこうと思いました。
5.コードの品質管理
スケジュールもギリギリで、リファクタリングにさく時間がなかったこともあり、フロントエンド側でかなりカオスなコードになってしまった。また、無駄なState管理も多くみられ、後半で予期せぬエラーを出してしまった。
改善点
定期的なリファクタリングをする。一気にするのではなく自分の中で目安をきめ、⚪︎⚪︎機能と⚪︎⚪︎機能が終わったら一旦リファクタリングするなど決めておく。
6.リサーチ不足
今回の場合だと、langchainについてリサーチ不足だった。履歴を元に回答を生成する場合も課金対象に入ることを知らずに納品する所であり、欠陥なものをクライアントに提出する所だった。(本当に危ない所でした)
改善点
検証を行ったり、詳しい人に教えてもらったり、ドキュメントを読み込むべきだった。
🐈 終わり
PMは想像の何倍も難しかったです。 プレイヤーの時とは違ったスキルが求められかなり苦戦しました。
でも多くのとこを学ぶことができ、今振り返ればPMをやってよかったと思ってます。
この1ヶ月はかなり濃い経験をすることができました。(少しレベルアップできたかな?と思います!)
🚀 おまけ
弊社では、スマホやPC1つで完結する網羅的な教材と、無制限で解ける本番と同形式の模試で、短期間での資格取得を目指すことができる簿記のアプリ 『Funda簿記』 を運営しています。
少しでも興味のある方がいれば、リンクよりアクセスしていただくか、メールにてお願いします☺️
Discussion
認証でFirebasAuth使うのWebでも流行ってるんですかね?
IDaasの一種ですよね。JWT認証とかが使われてるイメージで自作してるかなと思ってました。
ベアラートークンっていうんでしたったけ?
Jboyさん、コメントありがとうございます!☺️
流行ってるかどうかは何とも言えないのですが...小~中規模向けのWebアプリ/サービスにはFirebasAuthでもいいのかなって自分の感覚的には思ってます!
記事に記載通り開発者視点では、実装コストが減るので開発体験はいいです!!
おおおお!
やはり、Webの人にもFirebase人気あるんですね!
実装コストが減るのか〜
mino_.さんお返事ありがとうございます!