見出し画像

開発PM勉強会vol.17の参加記と、考えたこと

はじめに

こんにちは!amixedcolor(エイミ)です。今日は開発PM勉強会に参加してきました。今回が初参加です。このイベントに参加して自分が考えた話について書きます。

今回のイベントについて

イベントは、「0→1システム開発のPMが経験してきた"PJの進め方"を聞いてみよう【開発PM勉強会vol.17】」です。

今回のテーマ協賛でもある株式会社Relicは、実は僕の就職先です。今年2023年の4月からお世話になります。(既にお世話になっていますが)

この記事について

イベントの中でお話しのあったことをスクショを貼りつつ伝えると共に、 僕自身がどう感じたか、どう考えたか を書いて行きます。

LT1: レガシーSier社員がアジャイルにDX企画・実装してみた

エピソード1

  • 7人のスクラムチームで、まずはリーンキャンバスなどのフレームワークを使いつつ、ステークホルダと初打ち合わせ

  • しかし、目的がフレームを埋めることになってしまい、理解されなかった

  • アジャイルコーチの方に、フレームワークにとらわれずに自分たちのイメージを掴んでと言われた

手段の目的化が起きている例だと考えました。こういった時に、アジャイルコーチの力を借りなくとも気づけるようになりたいけれど、どうすればいいのかがわからない。それが困難だからアジャイルコーチといった職業があるのだろうか…?

エピソード2

  • 2週間、スプリント0を行なった

  • ベテランに萎縮する若手というアルアルは発生せず、スムーズに纏まった

  • スプリントが始まっても、下手に肉付けしなかったのでスムーズだった

  • アジャイル開発あるあるにはつまづきつつも成長していった

スクラムをスクラムガイドに忠実にやるだけでも(それ自体難しい)、良いチームになり良いプロダクトができていくのかなと感じました。具体的に何を肉付けしなかったのかは気になるところ…。

エピソード3

  • プロダクトはスプリント2から動く状態で、改善点に気づきやすかった

  • ステークホルダとの関係性も時間を経るごとに深まり、具体的な要望をもらえた

  • エンドユーザーと取締役へのデモも高評価だった

「包括的なドキュメントよりも動くプロダクトを」この価値を、新入社員が4名、アジャイルの実務未経験者が5名いる中で体現できていたのは何故なのか気になる。

得られた学び

  • エピソード1

    • ステークホルダとの関係構築の重要性と構築方法は、WFにしろアジャイルにしろ同様である

    • 似た人間を集めるより、バラエティに富んだ人間を集めた方が面白い

  • エピソード2

    • チームを分断しうる境界「距離・権力・知識」を意識し壁を壊そう

    • 人の性格にも依存するが、人間の隙は大事で、隙のない人間はとっつきづらい

  • エピソード3

    • DX推進のステップはタカorハトが迷いポイント

    • DXにモチベを持つ社員を育てたことに、プロダクトを作れた以上の価値を感じる

多様性の話とか、分断しうる境界の話が、最近気になっている部分なのでそこの学びが得られているのが面白い。どういう経緯でこの学びに気付いたのかは気になるなー。

LT2: コスプレUXで仮説立案がうまくいく

コスプレUXとは

立ち上げたい新規事業のペルソナになりきること
それによって仮説の量と質が上がることで、失敗してからの仮説の転換が早くなる

チームの中にペルソナに近い人がいない時は難しそうだと考えたことがあったので、そのための手段になりそう。

失敗から辿り着いた新規事業の進め方

いかに開発せずにPMFまで辿り着けるか

開発は負債になるかもしれないし、開発しなくても仮説の検証はできるんだろうなと考えているので、同感だった。

コスプレUXのやり方

インプット→アクション→イメージ→レビュー

インプット:ひたすら情報を集める、特に、新しい情報
アクション:現場に行くことで、観察する
イメージ:実際にプロダクトを体験するなどして、解像度を上げる
レビュー:有識者に、どれくらいなりきれているか聞いて、活かす

ここでも、しっかりレビューをもらうことが大事そう。僕はフィードバックを得ることは何をしていても大事だと思うので、もらえる方法をもっと知りたいな。

まとめ

Because not failure, but the way showed that it doesn’t work, that’s success.
それは失敗じゃなくて、その方法ではうまくいかないことがわかったんだから成功なんだよ

トーマス・エジソン
  • コスプレできるほど、なりきろう

この失敗の考え方はRelicの北嶋さんも持っていそう。なりきることが、コスプレできるほど≒細部までよく観察されていてその再現が可能なほど、と言うことにつながっていて面白かった…。

LT3: 新規事業におけるプロダクト開発の難しさとRelicで実施していること

IXとは

IX: Innovator Experience

  • 「事業家体験」「起業家体験」

  • Relicが独自に提唱する概念

  • アイデアを尺そうしてから、事業を創出し、成長・拡大させる間における事業家/起業家視点での体験

そういえば質問しそびれていた部分なので、ここで定義を聞けてよかった。

新規事業におけるプロダクト開発の難しさ

  1. 何も決まっていない中で要件定義をし、時間も予算も少ない中で無事作り切ること

  2. プロダクトを作ったものの、新規事業として市場に受け入れられない

他にもたくさんあると予想するけれど、この2つに集約されていくのだろうか。それとも、他のはさして大きなことではないのだろうか。

POへのヒアリング

  • はじめは、作りたいプロダクトの機能要望をヒアリングしていた

  • 今は、プロジェクトの詳細や、どういう展望を持って何がしたいのかをヒアリングしている

Relicでは、ヒアリングチェックシートを設けている。

スライドp6より

これもずっとカイゼンを繰り返してきたんだろうなと予想しつつ、足すだけではなく削っていくことをどれだけやったのか気になった。

プロジェクトの種類とアプローチ

スライドp9より

特に右の、誤ったアプローチをしてしまうことが多い。そのためにはどうするか、そこを具体的に話したのが以下。

スライドp11より
スライドp12より

「価値あるものに注力する」

スライドp13より

このマインドはやはりアジャイル開発によく通じているなぁと感じた。スクラムマスターという名前が出てこないのは、スクラムを用いない時、たとえばWFの時でもこのマインドが使われるのだろうと考えた。

まとめ

スライドp14より

プロジェクトの種類があることが一番興味深かった。パターン化されていっているノウハウがあって、それも改善を繰り返しているだろう、というのが面白い。新規事業開発に関しての解像度が少し上がった感覚もあり、それも興味深い。

LT4: 自社プロダクトのPMばかりをやっていた私がクライアントワークのPMをやって気付いたこと

自社プロダクトのPM(以後自社PM)とクライアントワークのPM(以後クライアントPM)の違いや共通点を理解して、試してみたこと、失敗したことの紹介

クライアントワークの先入観

実際は、

  • 工数の余裕は少なめ

  • 要件定義では共通言語化が必要

  • 成果物はプロダクトの価値提供(一部例外はある)

何かしらないことに臨む時、これまでの考え方にとらわれてしまうのはよくあることだと考えています。それに気がつき、補正をかけられる、あるいは学び直しができる、というのは大事なスキルなのだろうと考えました。

おわりに

開発PM勉強会には初めて参加しましたが、まだまだわからないことばかりなのは痛感しました。それでも、少し知っている部分もあって、スッと入ってきた部分もありました。ここで得た知識を活用できるのはまだ先だとは思いつつ、この勉強会に継続して参加するのがいい学びになりそう。

と、いうわけでありがとうございました!また不定期に記事を書いていきます。amixedcolor(エイミ)でした!それでは!!

この記事が気に入ったらサポートをしてみませんか?