Naoki Takahashi
株式会社SHIFT
Actions
2007年からシステムエンジニアとしてのキャリアをスタート。
直近ではHR系システムに携わることが多く以下を経験。
・社内人事系システムでのプロダクトエンジニア/POアシスタント/スクラムマスター/QAリード
・勤怠・請求のための基幹システムのサービスマネジメント
・契約業務のための基幹システム刷新案件でのプロジェクトマネジメント
Links
QA分業を越えて品質を作り込む開発チームへ ～「作るためにテストする」品質フィードバックサイクルの実践～
■発表概要
プロダクト開発で「実装は開発、総合テストはQA」という分業が進むと、品質の学びが循環せず、リリース直前に手戻りが集中しがちです。
私はプロジェクトマネージャーを務める案件で、まさにその状態を作っていました。
QAを「テストする人」として開発から切り離したことで、相互の成長につながるフィードバックが生まれず、チーム全体が品質ではなくタスク消化を追う構造になっていたと振り返っています。
そこで、開発チームとQAチームが分断されていた体制を見直し、開発チームがテストと品質分析を担い、QAチームは“自走支援”へ役割を転換しました。
その結果、開発チームが自律的に品質を改善し続けられるフィードバックサイクルを確立することができました。
本セッションでは、「テストを開発がやる」だけで終わらせず、不具合の原因分析を開発の改善に接続することで、同種不具合の再発を減らし、チームの品質主体性を高めていった実践を共有します。
■アジェンダ
- 分断体制で起きていた問題（なぜ学びが循環しないのか）
- 方針転換：QAの再定義。実行担当から自走支援へ（教育・伴走・型づくり）／開発がテスト設計、実行を担う
- 品質分析の進め方：不具合を“改善の入力”に変える
- 得られた変化
■発表の範囲
話すこと：役割移行の進め方、開発が品質の学びを取り戻すための運用・工夫、QAの役割の再定義
話さないこと：特定ツールの使い方の詳細、テスト技法の網羅的解説
■対象者
品質改善を“現場で回る形”にしたい方、役割分担によるサイロに悩む方、開発チームでの品質意識を向上したい方
仕様は“書く”より“語る” - 分断を超えたチーム開発の実践
設計チームと開発チームが分かれ、ドキュメントを通じて仕様を受け渡す。そんな体制は、初期リリースには効果的でした。
しかし、背景や意図が共有されず、開発チームの自己組織化が進まないという課題に直面します。
本セッションでは、体制を見直し、設計・仕様検討の段階から開発チームが関わるようになった実践を紹介します。
リファインメントや仕様共有の取り組みを通じて「システム仕様を語る」文化を育てていったプロセスと、そこから得たチームの変化・学びを共有します。
サクラエディタでのコーディングを通して学ぶ開発生産性
6年ぶりのJavaでの実装作業（既存プロダクトの改修）を体験しました。
開発環境を構築していない私用PCでの開発を通し実感した、
オンボーディングと開発者体験、開発生産性をあげるために必要となるゆとりについての学びの発表となります。
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top