Product Engineering Night #8 〜他領域への越境〜にオンライン参加しました。
イベントの概要
Product Engineering Night はプロダクト志向を持つエンジニアたちが集まり、知識と経験を共有し互いに学び、議論を深める場を創ることを目的としています。
「Product Engineer」という新しい職種を定義する企業が国内外で出始めており、技術中心のエンジニアリングから一歩進み、プロダクトの価値を中心に据えたエンジニアリングへと進化する動きが出ています。プロダクト開発はその不確実性が特徴であり、単一の知識や手法だけでは価値を生み出すことは難しい総合戦とされる領域です。多様な知見と視点を持つことがプロダクト価値追求には欠かせません。
プロダクトエンジニアに関する note はこちら（https://note.com/niwa_takeru/n/n0ae4acf2964d）
過去の参加者アンケートでのNPSは9.4と非常に高く、LTだけのイベントではなく全員が楽しく議論をする熱狂的なイベントを実施しています。現在プロダクトエンジニアとして第一線で活躍されている方だけでなく、プロダクトエンジニアという働き方・姿勢に興味がある方もぜひ奮ってご参加ください！
引用：
イベント参加の背景
- プロダクトエンジニアという概念にここ１年ぐらい魅了され続けている。
- プロダクトを主軸にした越境の話が気になる。
- 急遽オフラインでの参加が難しくなってしまったけどオンラインで…！！
他領域への越境セッション
- 全エンジニアへのFigma導入とその効果
□メモ
開発するものが多くある。
だからこそ、プロダクト領域を意識した開発が重要。
デザイナーがいない開発はデザインへの越境が重要。
越境とは？
PdEは機能を作る人ではなく、プロダクト体験の構造を作る人。
３領域を越境し、思考の幅と行動を一致させる。
PdEは情報構造の設計者。内部構造と外部表現を接続する。
エンジニアがデザインを学ぶと、UIではなく体験を考えられるようになる。
デザイナーと情報構造を議論できる共通言語が育つ。
Figmaを書きながら考える道具、考えを高度にビジュアル化する道具として採用した。
モックを通して開発のスピードが上がるだけでなく、構造の見える化が進んだ。
開発と体験の距離が縮まった。言葉だけでなく、図で語られるようになった。
□感想
開発者がデザインを意識することは重要性を感じました。
特に開発チームの外にデザイナーがいる場合、
開発と体験に気付きづらい距離が生まれていることに気付きました。
ただ、エンジニアがデザインまで意識はできているので、
向き合いが良いことにも気づくことができました。
内部構造と外部表現の接続、意識していきたいです。 - 漂流してたらPMになった
□メモ
越境を通じてキャリアを築いた。
エンジニア：SaaS立ち上げ、CRE組織立ち上げ、CSとの協業によるプロダクト開発
↓
PdM：グロースPM。テクニカルプロダクトマネージャー。
越境はキャリアの転換期。越境により希少価値が生まれた。
但し、自然と生まれてきたもの。
キャリアの8割は偶然で生まれる。
キャリアデザインとキャリアドリフトの繰り返し。
キャリアの軸が重要。ユーザーの本質的な価値を届ける。
肩書に捉われず、自分がやりたいことが何かを考える必要あり。
□感想
改めて自分の中に芯を持つことの重要性を感じました。
少し前に開発領域からほぼ離れた状態でエンジニアに関わる形になり、自分が何をする人なのか不安になったことを覚えています。
最近は改めてエンジニアの領域に滲み出し、自分は課題解決が好きだったんだと気づきました。
じゃあ、何を成し遂げたいのかを考え、芯を持ちたいと思いました。 - SREからゼロイチプロダクト開発へ ー越境する打席の立ち方と期待への応え方ー
□メモ
バクラク勤怠の開発チームに参加してみて。
・打席に立つ
常に新しい仕事を探し、種をまいておくことが重要。
・期待に応える
機能開発ではうまくいかない面もあったが、
動くものを示してフォードバックを受けるサイクルを１日１回行った。
・持ち帰れたこと
プロダクト開発者のマインド理解が進んだ。
Product as a Platformの考え方に活かせた。
越境に当たり、計画的偶発性理論を重視する。境界はひかない。
越境は大変だが見返りもある。
□感想
Platform as a Productを改めて解釈できた気がしました。
今日一日まだ馴染まないソースコードと戦い続けていたため、フィードバックサイクルの話は刺さりました。
１日１回でもアウトプットすれば少なくとも前進はする。
勇気を貰いました。 - エンジニアが挑む、限界までの越境――現場体験が生み出すプロダクト開発への功罪
□メモ
・エンプラクライアントへのオンボーディングに越境
高速開発。
エンジニアだからこそ要件定義を高速にできた。
議論のオーナーシップを握り続けて、持ち帰らず提案からのFIT&GAPを行った。
GAPを深掘り、代替案の提案などを行った。
・スキャン・郵送という物理業務への越境
難易度高い業務に対してプロダクトで圧倒的な効率化をした。
要件定義を飛ばして、高速開発。
効果と開発規模のバランスを取り、100%ではなく、70%を目指した。
越境メリデメ。
・メリット
ユーザーや業務解像度が上がる。特にメンタルモデルの理解。
使われるまで高速開発できる。
業務効率化、ではなく、業務を無くすことがしやすくなる。
（OPS面がコントローラブルに）
事業成長への貢献。
プロダクト組織を越えた企業全体でのコミットメントカルチャーを醸成できた。
・デメリット
開発生産性に悪影響。
難易度の高い業務の実現により現場からなかなか抜け出せない。
だからこそ、先に期間を決めた計画が重要。
とはいえ、事業視座での全体最適を考えられるカルチャー醸成は重要。
□感想
ASIS聞かない、要件定義すっ飛ばすの決断力に刺さりました。
業務領域への越境は開発生産性落ちるけどカルチャー醸成は重要という話には、主目的を見失わず、越境する価値を感じました。
守りに入りそうになる時に思い出したい。
まとめ
今回はオンライン参加でした。濃厚な時間を過ごせました。
プロダクト志向を持った越境。
よくよく考えてみたらdevopsと同じ話なのかと思い至りました。
そのうえで、中心軸にプロダクトを据えて越境することの重要性を感じました。
役割間のサイロを壊すことで、デザインや業務に滲み出していく。
プロダクト志向を持ちプラットフォームを扱えるようになる。
プロダクト志向を中心にして、役割にとらわれないキャリアを描くことができる。
先日参加のQAとSMの複数ロールの視点を持つことについてのセッションに重ねて聞いても興味深かったです。
DEVもQAもプロダクトを志向する。
そのうえでQAは品質富士山のように品質の裾野を広げるし、DEVはよりプロダクト価値にフォーカスするようサイロを壊すのか。
そのうえで、やっぱり自分が何者であり、何を志すのかという定義は重要だと感じました。
今まで準委任で開発エンジニアとして以外に、PjM、POアシスタント、SM、QA、サービスマネージャーといろいろな役割を担ってきて、自分自身の仕事にオーナーシップを感じられずにいました。
ただ、最近は実際に開発で携わるプロダクトと、準委任で支援するサービスの両面のプロダクトに対してオーナーシップを持っていたいと感じています。
そうした意味でもPdEという存在に魅力を感じるし、その実現の濃度を上げる越境を自分の領域に照らして考えたいと思いました。
今回、仕事と家族の都合で急遽オンラインに変更させて頂きましたが、オフラインで参加して色々な方のお話を聞きたかったです。
アンカンファレンスの重要さを感じます。次回こそはまたオンライン参加したいです。
貴重なお話をたくさん聞くことができました。
プロダクトエンジニアリングナイト最高です。
