TsukuneA1

WINCというサークルの夏合宿ハッカソンでPMをやった話

前提

リポジトリ

早稲田大学のWINCというプログラミングサークルで毎年夏に開催されているアプリ開発ハッカソンに参加しました。 なぜかPMをやっていました。ハッカソンの題材としてgithubの情報をFFだったり、リポジトリをスターしていなくても受動的にfeedできるアプリを開発していました。 詳しい内容はリポジトリのREADMEを参照してください。 この記事ではそこで得られた学びをプレイヤーではなくマネジメント側としてまとめています。経験の浅いエンジニアですが、今回の経験からPMの難しさと面白さを学べました!

最終的な発表で使ったスライドはこれになります

プロジェクトのメンバーとして

という感じでした。

以下でPMをやっていて学んだことをセクション分けして述べます。

プロジェクトの目標を初期に言語化しておくことの重要性

自分は元々個人開発や大学の友人とチーム開発をやった経験から、プロジェクトの目標、目的を初期に言語化しておくことの重要性が分かっていました。これを最初にやらないと開発の途中で方向性が滅茶苦茶になりプロジェクト自体をたたむことになります。実際そういう体験も何度かあります。今回のハッカソンではそうならないよう最初からあまりにも難易度が高すぎない且つ全員が得をできるような目標設定をしようと考えていました。

そこでプロジェクトが開始し、メンバーが決まった段階で全員にこのハッカソンでの目標ややりたいことを聞き取り調査しました。その結果バックエンドの開発経験が積みたい、ポートフォリオに載せたい、Githubを使ったチーム開発経験が積みたいなどがあったと記憶しています。

それらを加味した結果全体での目標を

  1. ハッカソンの最後に自分たちの勉強したことを全メンバーが言語化でき、且つその内容が各メンバーのやりたいことに合致している
  2. アプリのコンセプトやその実現度をアピールできる

上記2点として定めました。

まず1つめはバックエンドの開発経験が積みたい人にはそうしたタスクをもちろん振るし、Githubを使った開発経験が積みたい人にはGithubの使い方をちゃんと教えようと思いましたが、結局それらを言語化できなければただやったどまりで意味がないのでタスクをこなし、言語化できるまでを目標と置きました。また1.が達成できた場合、多少アプリの受けが悪くてもこういう知見を得られましたとアピールでき、セーフティーネットになります。

次に2つめの目標に関してはアプリ開発をするので当然それで解決したいペインや、どのくらい解決できたかを発表できなければいけません。なので当然のことですが目標として定めています。


結局上記2つの目標の実現度としては1つめが80%, 2つめが30%くらいです。1つ目に関してはgoogle slideを見てもらえばメンバー全員が自分の学びを言語化できていることが分かると思います。2つ目に関してはリポジトリを見てもらえば「あ、こいつら時間なくて滅茶苦茶になったんだな」というのが分かると思いますw。


ただ振り返ってみると初期に目標を全員に言語化させること、またそれを踏まえた現実的な目標設定をする能力は今回でさらに磨かれたし、それの重要性も再実感できました。

AIを使って生産性を上げるためには

プロジェクトの始動時、AIの出現によって開発速度が上がり経験の少ないメンバーでもなんとかなるだろうと考えて見積もりを作っていました。しかし思ったよりもそれで生産性は上がらず、むしろ下がったのではないかとすら感じました。結構意外だったので理由以下に列挙します。


  1. 理由は一つ目にそもそもAIの使い方を分かっていないことです。具体的にはコンテキストの与え方が下手であること、セッションの管理ができないこと、モデルやAgentの選定がおかしいことなどがあります。自分は当たり前にCLI型AIエージェントを使いタブを複数開いてセッションを切り替えながら指示を出しますが、確かに今考えるとAIに慣れていない場合、この辺上手くやるのは難しいなと思います。(ただその辺のキャッチアップまでやってあげる時間はなかった。)
  2. 二つ目に技術力の基礎やチーム開発経験がないとAIを使ったところでただの技術負債生産機にしかならないというのがあります。これはAIに言われたことを鵜呑みにして全く違う実装に突っ走っていたり、レビューで差し戻しが起こったときに対応が遅延する、AIにあまりにも多くの差分を作成させ、大量の技術負債を作るなどがあります。
  3. 三つ目に自分の持っているコンテキストがチームメンバーに伝えきれていないというのがあります。これはできるだけ改善しようとしていてREADMEを頻繁に更新する、週1でmtgする、技術力高くて設計任せられそうな人には自分の思想を1 on 1で時間取って話す等やっていました。が、やはりそれだけでは伝えきれず、自分の中にはこうしてほしいというのがあるが言語化できておらずそれが伝言ゲームされてAIに伝わることで「そうじゃないんだよなぁ...」みたいな設計段階からずれたPRが送られてくることがありました。これは自分の落ち度です。

一つ上のセクションで示した学習内容の言語化的なことに焦点を当てて実装を度外視すれば、理解していなくてもPRを作れてしまうAIの積極的使用はむしろしないほうがいいのでは？とすら思いました。逆に上記3点を上手いこと解決できる組織体制であればAIでの爆発的な生産性向上が見込めると思います。

学生同士で開発をするときに意識した方がよいこと

このセクションはあまりにも書きたいことが多すぎますが特に重要だと思ったことをかいつまんで列挙します。

PMは求められるものが多すぎる

PMをやっていて面白いと感じた反面正直結構つらかったです。具体的には

などの辛みがありました。実装をやるは多分世間一般のPMはやりませんが僕がプログラミングがしたかった且つそう振舞うことがチーム体制的に最善と判断したため、実装もやりました。ただ自分が全部ハンドリングしている感覚(実際そんなことはない)は気分がよかったです。またいろんな人の作業の進め方や行動哲学みたいなのが垣間見えて参考になることがいっぱいあり、こういうのもPMやるメリットだと感じました。具体的には上述したコミュニケーション能力関連です。


マネジメント側から見ればすぐにメッセージに反応が来るとものすごい安心したりと管理する側から見たプレイヤーの見え方が結構勉強になったので今後インターンではプレイヤーなのでその時の立ち振る舞いに生かそうと思います。