今年は、はじめてプロポーザルを提出した年でした。
合計31本提出し、採択6本／不採択23本／選考中2本という結果になりました。
これまで登壇やプロポーザル提出の経験がなかった私にとって、プロポーザルを提出するということはエンジニアリングの世界の扉をノックするような行為でした。
そして、自分やチームの実践を「外の世界」に認めて欲しいという想いでもありました。
ある意味上手くいったと思うし、上手くいかなかったところもあると思っています。
ただ、とにかくドアをノックし続けて、そのドアの反響音から自分のいる場所の空間が見えてきたこともあります。
また、開いた扉からは広い世界を知ることができました。
そうしたことを繰り返して、プロポーザルの内容に対する捉え方を変えていくこともできました。
年が明ける前に自分のプロポーザルをまとめました。
自分が見直せるためのメモ書きとなります。
- 25/3/15-17 DevOpsDays2025
- 25/6/7 JJUG CCC 2025 Spring
- 25/7/26 TechRAMEN 2025 Conference
- 25/8/29-30 スクラムフェス仙台
- 25/9/5-6 スクラムフェス三河
- 25/9/6 大吉祥寺.pm
- 25/9/18 Platform Engineering Kaigi 2025
- 25/9/26-27 PyCon JP 2025
- 25/10/4 XP祭り2025
- 25/10/4 スクラム祭り2025
- 25/10/4 builderscon 2025
- 25/10/23 Product Engineering Night #10 〜10月号〜
- 25/11/1 KomeKaigi 2025
- 25/11/13-14 Agile Japan 2025
- 25/11/15 JJUG CCC 2025 Fall
- 25/11/20-21 アーキテクチャConference 2025
- 25/11/29 BacklogWorld 2025
- 25/12/6 Developers Boost 2025
- 25/12/11 Product Engineering Night #11〜２周年＆PdEWorkshop〜
- 26/1/7-9 RSGT2026
- 26/01/09-10 BuriKaigi 2026
- 26/2/18-20 Developers Summit 2026・Dev x PM Day
- 26/3/4 Engineering Management Conference Japan 2026
- 26/3/6-7 Scrum Fest Fukuoka 2026
- 26/3/20 JaSST'26 Tokyo
- 26/3/20-3/22 PHPerKaigi 2026
- 26/4/4 アウトプットの背中を押すカンファレンス「ワンストップ アウトプット！」
- 26/4/12 PHPカンファレンス小田原
25/3/15-17 DevOpsDays2025
【不採択】開発チームの品質意識をイネーブリングする～QAtoAQとチームトポロジーからの品質へのアプローチ
25/6/7 JJUG CCC 2025 Spring
【不採択】サクラエディタでのコーディングを通して学ぶ開発生産性
25/7/26 TechRAMEN 2025 Conference
【採択】プロダクトという一杯を作る - プロダクトチームが味の責任を持つまでの煮込み奮闘記
25/8/29-30 スクラムフェス仙台
【不採択】後悔！はじめてのスクラムマスターとしての失敗
25/9/5-6 スクラムフェス三河
【不採択】“スクラムって何？”をもう一度問い直す 〜手段ではなく、目的からはじめるスクラム開発〜
25/9/6 大吉祥寺.pm
【不採択】サイロを壊す～極私的DevOps体験
【不採択】娘の未来に続くチームトポロジー
25/9/18 Platform Engineering Kaigi 2025
【不採択】DevがOpsも担うべき？盲目的なDevOps信仰から学んだPlatformの本質
25/9/26-27 PyCon JP 2025
【不採択】40代で始めるPython開発 ～ PM/POアシスタント/QAからプロダクトコードの世界へ帰還して見えたこと ～
投稿タイトル：40代で始めるPython開発 ～ PM/POアシスタント/QAからプロダクトコードの世界へ帰還して見えたこと ～
概要： PM、POアシスタント、QAリーダーとしてプロダクトの初回リリースに向けて携わってきた私は、今年から初回リリース以降のアジャイル開発に置いて改めて開発者としてもPythonで書かれたプロダクトコードに向き合っています。
本セッションでは、再び実装の現場に立つことで初めて実感した「開発者の認知負荷」、そして外部からは見えづらかった苦労や工夫について共有します。
業務要件に向けてプロダクトコードをどのように育てていきたいかを自身の体験を通して語ります。
シニア世代の挑戦として、また開発と非開発を往復するキャリアの一例として、共感と発見をお届けできれば幸いです。
詳細： 私はこれまで、PM、POアシスタント、QAとして、プロダクト開発に「開発者ではない立場」で関わることが多くありました。
プロジェクトの管理や開発チームの支援、品質担保に注力する一方で、プロダクトコードそのものに触れることは少なくなっていました。
そんな中、2025年4月から再び開発者としてPythonコードを日々書くようになり、いくつもの「発見」と「後悔」がありました。
・外部からは見えづらかった実装の認知負荷
・要件と実装のあいだで起こる乖離
・認知の抜けやすさと、レビュー・テストの意味
このセッションでは、そうした体験を共有しながら、非開発の立場で得てきた視座と、実装に立ち返ることで見えてきた新たな価値の接続点を探ります。
Pythonという言語を通じて、自身のキャリアを再構成していく——
そんな試行錯誤の最中にある私の発表が、
・久しぶりに開発に戻る方
・開発チーム外のロールを経験してきた方
・これからキャリアの越境を考えている方
にとっての一助となれば幸いです。
25/10/4 XP祭り2025
【採択】空間を設計する力を考える
25/10/4 スクラム祭り2025
【採択】定期的な価値提供だけじゃない、スクラムが導くチームの共創化
25/10/4 builderscon 2025
【不採択】作ることにオーナーシップを - 受託エンジニアとしての私の分岐点
25/10/23 Product Engineering Night #10 〜10月号〜
【不採択】プロジェクト思考からプロダクト思考へシフトしていくための実践
■概要
長年受託企業で働いてきた私は、開発案件を転々とする働き方の中で、
エンジニアとしてのモチベーションをどこに見出すべきか悩んでいました。
転機となったのは「プロダクト」という考え方との出会いでした。
ただソフトウェアを開発するのではなく、ユーザーに利用され、継続的に成長していく「プロダクト」を作る。
この視点の転換により、エンジニアリングの目的は「ユーザーに使われ続けるものを作ること」だと理解できました。
本LTでは、「使われ方を考える」ということを5W1Hで整理しエンジニアがオーナーシップを持つことを再考します。
25/11/1 KomeKaigi 2025
【不採択】40代を越えて“新米”として始めた学び
25/11/13-14 Agile Japan 2025
【不採択】管理型PMからアジャイル型PMへの意識変遷 ～自己組織化へのリブート～
25/11/15 JJUG CCC 2025 Fall
【採択】仕様は“書く”より“語る” - 分断を超えたチーム開発の実践
25/11/20-21 アーキテクチャConference 2025
【不採択】最強のアーキテクチャ決定戦の開催：チームで合意した再設計の進め方
プロダクトの機能追加を重ねる中でソースコードは扱いづらくなり、コントローラーにドメイン処理が集中、単体テストも壊れやすい状態に陥りました。リアーキテクチャの必要性は共有できていたものの、トップダウンで押しつけず、チーム全員が納得感を持てる形にしたいと考えました。そこで「最強のアーキテクチャ決定戦」を開催しました。議論を通じて知識をキャッチアップし合いながら、新たなアーキテクチャの方向性を描きました。本セッションでは、チームでアーキテクチャに向き合う土壌づくりのヒントを持ち帰っていただけます。
25/11/29 BacklogWorld 2025
【不採択】契約を果たすのではなく目的を守るプロジェクトマネージャーに 準委任PMが経験した失敗からの学び
・セッション概要
準委任契約のもと新規でのプロダクト開発に受託企業のPMとして関わる中で、私は「契約達成＝成功」と捉え、プロダクトをリリースに導くことばかりを考えていました。
しかし、その過程で、チームの分断や属人化を促し、チームが持続的なプロダクト開発を可能とする学びと成長の機会を奪っていたことに気づきました。
リリース後にはサイロ化した状況が招いたチームの停滞が待っていました。
そこから私は、アジャイル型のプロダクト開発におけるプロジェクトマネージャーとは、契約達成を主目的に案件を推進するのではなく、チームの持続的なプロダクト開発を実現することを目的に案件を推進することこそが、求められる役割だと学びました。
本セッションでは、属人化や分断の課題から、チーム主導の意思決定への移行をどのように進めたのか、現場のリアルと失敗を交えながら、何を実践したのか、うまくいったこと、うまくいかなかったことも含め共有します。
25/12/6 Developers Boost 2025
【不採択】価値の対流で回すチーム開発
▼セッション概要
チーム開発は、年齢や経験年数で上下を作らず、互いの強みを双方向に生かす営みだと考えます。
年齢や役割でサイロをつくらず、「いまの感覚」と「積み上げた地力」を往復させ、判断は“誰が言ったか”ではなく検証された根拠でそろえます。
状況に応じて全員がリーダーシップを発揮し、価値が巡る状態をめざします。
本セッションでは、その前提と帰結を簡潔に示し、思考の型を共有します。
【不採択】1999→2025：昔話で鍛えるプロダクト嗅覚
▼セッション概要
1999年のインターネット体験（ダイヤルアップ、ICQ、個人ホームページ、“怪しい.exe”）を素材に、現代のチーム開発に役立つ三つの原則を提示します。①新情報は「出典・再現・権限」で検証します。②PVではなく完了率・所要時間など意味のある指標で評価します。③予期せぬ動作を避ける“驚かせないUI”を基準にします。これらを時代を越えて機能する判断軸として整理します。
25/12/11 Product Engineering Night #11〜２周年＆PdEWorkshop〜
【不採択】作ることに価値を宿す――エンジニアリングにオーナーシップを持つということ
26/1/7-9 RSGT2026
【不採択】プロジェクトマネージャーの“最強の一手”から、チームで続く改善への変遷をふりかえる
【不採択】押しつける管理からチーム主導へ――準委任プロジェクトマネージャーが気づいた“成長の場を守る役割”
26/01/09-10 BuriKaigi 2026
【不採択】群れで育てるプロダクト：役割横断バグバッシュのすすめ
26/2/18-20 Developers Summit 2026・Dev x PM Day
【不採択】サイロを超え、チームがコードをプロダクトに進化させていく
■セッション概要
ソフトウェアはリリースして終わりではない。
準委任での新規プロダクト開発で私は受託側のPjMを務めました。
リリースに意識が偏り、チームを役割で分割し属人化とサイロを生み出しました。
最後は個人のハードワークでリリースを実現したものの、プロダクトを継続的に成長させるためには大きな課題を残しました。
そこから「作って終わりのプロジェクト思考」から「チームで価値を持続可能とするプロダクト思考」への転換が始まりました。
当セッションでは、エンジニアリングをリリースで終わらせないために、サイロを超え、チームがコードをプロダクトに進化させていくための実践方法をお話しします。
■セッション概要の補足
・当セッションでお伝えしたいことについて
私は長年、受託企業のエンジニアとしての仕事に対して、売上や粗利と自分の成果につながりを実感できずにいました。
ただ、今回扱うプロジェクトでの経験とそこからの学びを通じて、
エンジニアの作ることの本質は、一過性のプロジェクトではなく、継続的なプロダクトの価値実現にあり、
そのためには個人の力ではなく、チームで実現していくことが重要である、と捉え直すことができました。
そうした学びからエンジニアの方たちにコードを書くことの意義を捉えなおすきっかけを作れたらと考えています。
・想定構成（アウトライン）
1.導入：リリースを目的にしたプロジェクトで生んでしまったサイロと属人化。チームを設計/開発/QAと分散し、チームでプロダクトを育てる成長を阻害していた。
2.転換のきっかけ：リリースは無事に成功したが、属人化によるハードワークに持続性はなく、持続的にプロダクトを育てることができるチームの重要性に気づいた
3.実践① 仕様策定のチーム主導化と「使われ方」起点の議論へのシフト
4.実践② テストと品質フィードバックをチームに取り戻し、「納得してリリースする」文化づくり
5.実践③ PM自身のマインドセット転換と、メンバーのオーナーシップを引き出す関わり方
6.まとめ：プロジェクト型からプロダクト型への意識の転換と、それによるエンジニアのオーナーシップ獲得
・Learning Outcome
- 受託／準委任の現場で、「作って終わり」から「育て続ける」への意識転換の重要性を理解できる。
- サイロ化・属人化がプロダクトの持続的成長を阻害するメカニズムを理解できる。
- ソフトウェア開発におけるプロジェクト型からプロダクト型への視野の拡張の必要性を理解できる。
- エンジニアとして、コードを書くことの意義を「プロダクトの価値実現」という視点で捉え直せる
26/3/4 Engineering Management Conference Japan 2026
【不採択】EM不在ならEMの役割を担うーープロジェクトマネージャーのEMロードマップ
26/3/6-7 Scrum Fest Fukuoka 2026
【選考待ち】リリースはゴールではない：分断から統合へ、準委任PMが学んだ持続可能なチーム成長
26/3/20 JaSST'26 Tokyo
【不採択】持続的なプロダクト成長を支える開発チームの実践 ～作るためにテストするフィードバックサイクルの確立～
■概要
本事例は、開発チームとQAチームが分断された体制の中で、品質に関する学びが適切に循環せず、継続的な改善が困難だった状況から、開発チーム自らがテストや品質分析を担い、QAチームからの自立を果たした取り組みである。品質に関する責任の主体を移行させる過程と、それにより開発チームが「使われること」を意識した品質向上サイクルを実現していった実践を共有する。
■問題提起
プロダクトの初回リリースまでの開発では、実装・ユニットテストまでは開発チームが、総合テストはQAチームが担うという機能分化された体制で進められていた。しかしこの体制では以下のようなギャップが存在していた。
・QAチームが不具合を発見しても、その知見が開発チームに効果的に伝わらず、プロセス改善につながらない。
・開発チームがテストの重要性や品質の全体像を把握しづらく、実装と品質が乖離したまま進行してしまう。
・結果として、リリース直前の総合テストで大きな手戻りが発生した。
目指すべき姿は、「開発チーム自らが作るものに対する品質への責任を持ち、QAチームはそれを支援する存在になる」ことであった。
■個々の問題に対する課題を示す
・チームの分断とともに品質の知見が分断される問題
→ 不具合の原因がコード・仕様・プロセスにあるかの分析が開発が主体的に受け取れる形でフィードバックされない。
・プロセス改善が進まない
→ 同様の不具合が繰り返されるが、開発チームの実践に繋がる形での原因分析と改善がなされない。
・開発チームの品質意識の希薄化
→ テストはQAの仕事という意識が無意識に醸成し、作ったものに対する使われ方に対する視点や品質観点が弱い。
■個々の問題に対する対策を示す
・開発チームがテスト全般を行う方針に
- 初回リリース後の適応型開発（スクラム開発）においては、単体・ユニットテストのみならず、結合テスト・シナリオテストも開発チームで実施。
- 自分が作ったものをテストすることで品質に対するフィードバックを直接受け取れる形に変更。
・品質の知見を開発に統合するための取り組み
- 品質分析を発生したひとつひとつのバグに対して行うことで、プロセスの改善を実現。
・QAチームの役割を「自走支援」にシフト
- QAチームはテスト設計・分析のナレッジをもとに開発チームに支える役割に注力。
- 初期は教育やペア作業を通じて支援し、徐々に開発チームが独力でテストや品質改善ができる状態を目指した。
■結果・まとめ
この取り組みにより、開発チームは以下の変化を実現した。
・役割で分断されたことによるサイロの解消
開発チームが設計からテストまでを行うことでプロダクトに対する主体性を持つことができた。
・品質に対する主体性の向上
不具合の傾向から自らプロセス改善を行う「学びのサイクル」が確立した。
・使われる視点での開発文化の醸成
作ることの意識だけではなく、使われることを意識した「価値の検証のため」という意識が醸成された。
今後の課題としては、開発チーム内でも品質に対する知見や認識にばらつきがあるため、メンバー全員が同じ目的をもとに品質保証ができるような仕組みづくりが求められる。
