活動の様子

FinanSuのPMをやってみて

By [imaimai] 24 June 2023

FinanSuのPMをやってみて

いまいまいです。 FinanSuのPMをddさんから受け継いで、リリースまで結びつけることができたので、それに際して、やって良かったことや、もっと改善できることをまとめました。

なんでPMをやったんや

そもそも、なぜ自分がPMをやったのかについての経緯を話します。

技大祭が開催される頃、自分のNUTMEGに対するモチベーションはほぼありませんでした。 大まかにReactやNext、デザインの初歩を学び、今まで独学でやり通してきた自分にとって、これ以上NUTMEGにいなくても成長できるだろうと思ったからです。

自分はプログラミングを学ぶために技大祭に入りました。 誰かのためにサービスを作るというより、面白そうな技術を使って、面白いことをしたかったのです。 なので、これ以上NUTMEGにいなくても十分やりたいことができるだろうと思いました。

しかし、NUTMEGの創始者こと大場さんに、それを見透かされたのか、以下のようなことを言われました。

NUTMEGはプログラミングサークルではない
⇩
技術系団体ではない技大祭実行委員会の中で開発をする(=内製化)
組織の問題を見つけて、それを解決する(=DX)
 
内製化DXを学生のうちに体験できるのはNUTMEGだけで、とても貴重な経験
プログラミングの勉強なんて、独学でやってきた人なら、就職したってできる
でも内製化DXを学生のうちにできるのは今ここしかない
 
技術力は、世代を経るごとにどんどんレベルが上がっていくし、いずれ抜かされる
でも、学生のうちに内製化DXをして、解決思考を身につければ、この能力はなかなか抜かされない

これを受けて、自分が成長するためにやるべきことは、NUTMEGに最大限貢献できる動きをすることだと思いました。 それが、複数の局に関わるFinanSuのPMをやることでした。

やってよかったこと

実際の納期は見積もりの1.5倍を想定する

by 百々s アドバイス

例えば、完成までに6ヶ月かかる場合は、実際のリリースまでは9ヶ月かかると想定するべきということです。バグとかバグとか仕様変更とか仕様追加とかあるからね

FinanSuは10月に受け継いだので、募金まで7ヶ月ほどあります。 この7ヶ月から逆算して、大体4~5ヶ月でできるタスク量を想定しなくてはなりません。 なので、受け継いだ当初は、以下のようにめっちゃスモールな目標を立ててました。

  • 次の5月までにやること
    • 激おもFinanSuの解消
    • 購入申請・報告のバグ修正
    • Chakra UIからTailwindCSSへのリファクタ
    • 予算・支出ページの実装
    • (できれば)募金のスマホ対応
  • 来年以降やる予定だったもの
    • 協賛全ページの実装
    • FinanSu全ページのスマホ対応

しかし、タスクを進めるにつれて、「あれこれできるんじゃね？」が重なり、結局全部達成しました。

やったぜ〜〜

また、スケジューリングはFigJamで管理してました。 多分概ねこの通りにできたのかなと思います。

ヒアリングした結果を優先度と重さに分ける

ヒアリングで上がった問題を参考に、それぞれのタスクを切り分けで、どれが重いタスクで、どれが優先度の高いタスクかをわけ、それをもとにタスクを振っていきました。

やるべきラインを見積もる

上がった要件と、NUTMEG側の実装したい要件から、最低限何をすべきか、追加でやれることは何かに分類しました。

無駄なissue / PRを絞る

自分が引き継いだ当初、何年も前からあるissueやPRが40個とか残ってました。 これを残したままにすると、現環境との乖離が進み、結局やるのかやらないのかはっきりもせず、プロジェクトを進める上で負債となってしまいます。 百々さんやりゅうせいさんに聞き、今残すべきissueとPR以外をcloseして、今現在ではissueが16個、PRが2つになっています。

ルールを厳密に

issueやPRのテンプレート作成し、各タスクについてどのような開発をするのかを明確にするようにしました。

また、commitメッセージやブランチ名のルールも設定し、誰がどのように開発したのかを明確にするようにしました。

commit: [prefix] content
例: [fix] 協賛活動のバグ修正

branch: {prefix}/{user}/{issueNo}-{content}
例: feature/imaimai/532-add-activity-page

よくないissueの例

issueは 5W1H を意識しましょう。全部は考えなくていいです。

  • 解決したい内容
  • なんでそれを解決するのか
  • どのように解決するのか
  • いつまでに解決するのか
  • etc…

また、Assigneesを指定して「誰が解決するのか」 Lablesを「指定してどのような問題なのか」も示した方が良いでしょう。

GitHub Projectsの活用

issueの一覧をGitHub Projectsによって、TODOリストのように管理することができます。 FinanSuのProjects 各進捗ごとによってボードを変え、タスクの大きさと優先度のプロパティも追加しました。

GitHub Actionsの活用

GitHub Actionsを使って、Gitへのアクションをトリガーとした便利機能を増やしました。

  • commitやpushをすると、自動でLintやBuildが走ってテストできるようにする
  • ブランチ名から、BugやEnhancementといったタグが自動でつくようにする
  • mainにmergeすることで、自動でリリースノートが書かれるようにする

ミーティングや進捗管理のあり方

情報局MTやキックオフミーティングでは、チームビルディングをしてみんなで仲良くなろうという流れがありますが、あくまで他人の時間を奪っていることを忘れないようにしました。

最初のうちは

  • チームビルディング
  • 決めるべき要件や話し合う内容があればそれを決める

ようにしていましたが、互いのことがある程度わかって、話し合うことも特にない場合は、MTは作業会にし、Slack上で進捗管理をするようにしました。 また、期限中に終わらない場合は、すぐに巻き取れる環境を用意して、心理的安全性を保つようにしました。変に伸ばさず、「終わりません」と自ら早めに言える環境は大事だと思います。

運が良かったこと

チームメンバー

自分がPMになった時、FinanSuのチームメンバーは以下のような編成でした。

  • わい：PM初心者・フロントまあまあ
  • どどさん：フロントつよつよ・前PM
  • りゅうせいさん：局長・バックエンドつよつよ
  • くまさん：渉外プロ
  • ひなさん：財務プロ

めっちゃバランスよかったです。 そこに

  • くぼ（どどさんが誘った）：バックまあまあ、最近はフロントもかける
  • のぶ（ぼくが誘った）：モバイル・バックまあまあ、最近はフロントもかける

が加わったので、結構盤石になった気がします。二人とも自走力が高いので、今はフルスタックになりつつあります。 良さげな人はバンバン声かけて行って良かったなと思います。

絶対必要ってわけじゃなかった

やベェFinanSu作らねぇと募金も協賛も終わる！！ って思ってたんですが他局長も馬鹿ではないので、FinanSuに代わるパーフェクトスプレッドシートを作ってくれていました。 FinanSuが仮に終わってもクッションがあるので、心理的安全性高かったです。

もっというと、失敗した場合にどうするべきかまで考えるといいと思います。 それが動かなくてもいい方法を用意しておくとかね（スプシ・GoogleForm）

悩んだこと

精神的不安

これ終わるんか？という不安や、FinanSuという大きいプロダクトを引っ張っていく責任が思った以上に大きく、PMを初めて数ヶ月は苦しかったです。 Seedsのどどさんとの1on1でボロ泣きしたり、NUTMEGの飲み会で「PM辞めたい！」って喚いたりしたこともありました。

何が苦しかったのか

  • やりたい開発ができない
  • レポート・仕事&インターン・就活・PMという多重苦
  • 就活や仕事など、高レベルの体験が始まり、NUTMEGにいる意味もわからなくなってきた
  • でもPMは受けた手前辞められないし、今更NUTMEGをやめるのも違う気がする

どう解決したか

  • 仕事を1つに絞った
  • 就活とレポートを終わらせた
  • 責任や不安がどうでもよくなるくらい、ひたすらFinanSuを開発した（PMもやりながら）
    • あれ〜意外と間に合うんじゃねってなってきた
  • ついでに自分のやりたい開発も、睡眠を削ってひたすらした
  • スマホページ&協賛関係ページの完成まではPMをやり切ろうと決めた

悩まなかったけど他の人が悩みそうなこと

PMってつまり何すればいいの？

課題管理

  • 現状のタスクは何か
  • 誰が何のタスクをやっているのか
  • そのタスクが間に合うか

対応策

  • GitHub Projectsの活用
  • 頻繁な進捗確認

要件定義・仕様確認

  • ヒアリング
    • 現在の実装が間違ってないか
    • 追加でやるべき仕様はないか
  • 他局への報告
    • ちゃんと進んでるか
    • いつまでに終わりそうか

対応策

  • 他局の局長と仲良くなろう（in サークルの活動場所)
  • 兼局

メンタルケア

  • 自分自身
  • チームメンバー

対応策

  • 1on1
  • チームビルディング

自分がPMになって大丈夫か

大丈夫じゃないかもしれない

  • 大丈夫じゃないことに気付くことができる
  • 就職してからPMやって失敗したらガチ損害が出るので、自分の適正に早く気付けるのは良いこと

もしものことを考えよう

  • 意味もなく失敗していいわけじゃない
  • 失敗した場合にどうするのか
    • 要は納期に間に合わないということ
    • スプシで間に合わせるのか、最低限何か使えるように整えるのか
      • そのために、他局長と事前に打ち合わせたり、最低限やるべきタスクの見積もりが必要
  • ❌ 失敗は成功のもと → ⭕️ 反省は成功のもと
    • 無謀と挑戦は全く違うので、ちゃんと後から反省できるように、最善を尽くすことが重要
    • 行き当たりばったりで進めないほうが良い
    • 「やってみなきゃわからない」「失敗して学べばいい」みたいな失敗をすでに可能性に含んで進めるのは危ない

私は、やって失敗した時の後悔に比べれば、やらずに後悔したほうがマシと思っている慎重派なのでこう言っているが、チャレンジできる環境があるならチャレンジしたほうが徳なので、臆さずに挑戦してほしい。

やりたいならやるべき

最善を尽くしてやって後悔しない道を進もう。

PMは技術を深く知っているべき？

答えは否である

技術選定はテックリードやアーキテクトに趣が深いメンバーに任せよう！ やるべきは以下の三つです。

  • 何を実現すべきか（要件定義・ヒアリング）
  • いつまでに実現すべきか（スケジューリング）
  • どのように実現すべきか（タスク管理・チームビルディング）

あとはメンタルや！がんばれ

PMの辛いところはクライアントとエンジニアの板挟みになることである。 辛い時は仲間に泣き喚いて発散しよう。

最後に

PMはメンタルとの戦いがでかいです。 大人の立派なPMでも、失踪した人を何人か見ました。 それぐらいクソでかい経験だと思いますし、それを失敗してもなんとかなる今こそチャレンジしてみてもいいと思います。