SQiP シンポジウム 2016 アジャイルプロジェクトにおけるペアワーク適用の改善事例 日本電気株式会社小角能史 2016 年 9 月 16 日

アジェンダ 自己紹介ペアワークとはプロジェクトへのペアワークの適用方法 スクラム適用ルール作成 最適化の流れ KPTを用いたふりかえり 適用ルールの改善事例 適用プロジェクトの概要ペアワーク適用ルール ( 初期 ) 改善例 1 - ペアのローテーション改善例 2 - 集合レビュー改善例 3 - 休憩の取得ペアワーク適用ルール ( 改善後 ) メンバ交代発生時の生産性の変化 考察 ペアワークとソースコードの共同所有他プロジェクトへのルールの適用可能性 まとめ

自己紹介 小角能史 (NEC) 入社以来ソフトウェア工学に従事 開発支援ツールの開発 (2003~) 組織内の品質保証担当 (2007~) ソフトウェア品質会計を習得 品質重視のアジャイル開発手法を検討 (NEC アジャイル ) 社内システムの開発管理者 (2013~) ウォーターフォール型 アジャイル型 4 NEC Corporation 2016

ペアワークとは アジャイル開発のプラクティスの 1 つ 2 人の開発者が 1 つのコンピュータを共有して作業 ペアワークの効果 高品質のソフトウェアを開発できる 1 人でやるよりも 見落としが減る 情報共有の促進 作業中会話をすることで ペア内で情報共有 ペアをローテーションしてチーム内で情報共有 NEC のアジャイルプロジェクトではペアワークを推奨 ペアワーク 5 NEC Corporation 2016

プロジェクトへのペアワークの適用方法 ペアワーク適用ルールを整備 最適化 アジャイル開発のプラクティスは プロジェクトの条件にあわせて適用方法を工夫することで より高い効果を得る ルールを最適化するためのアプローチ 初期のルールを作成 適用 ふりかえりにより適用ルールをプロジェクトに最適化 初めてペアワークを適用するプロジェクトにとっては 初期の適用ルールの決め方自体が課題 6 NEC Corporation 2016

スクラム スクラムの全体像 プロジェクト 要件一覧 ( プロダクトバックログ ) 優先順に選択 スプリントスプリントスプリントスプリント 高 スプリント ( 反復 ) デイリースクラム 成果物 優先順位 スプリント計画 設計 製造 テスト スプリントレビュー ふりかえり 低 1 日程度 1 日程度 スプリント 2 週間 (1~4 週間 ) 要件を複数のタスクに分割作業量の見積もりを実施 成果物 ( 動作するソフトウェア ) を確認 開発のプロセスを見直す 7 NEC Corporation 2016

適用ルール作成 最適化の流れ ペアワーク適用開始 スプリント 1 回目終了 スプリント 2 回目終了 スプリント 3 回目終了 スプリント 4 回目終了 スプリントスプリントスプリントスプリント 初期の適用ルールを作成 ふりかえりを通じて適用ルールを見直す 実際に発生した問題をもとに開発者自らの判断でルールを見直す 自分達で作成した適用ルールは 必ず守る問題があれば次のふりかえりで見直すことが可能 8 NEC Corporation 2016

KPT を用いたふりかえり プロセス改善のフレームワークとして KPT を採用 Keep プロジェクトで継続したいこと Problem 改善するべき問題点 Try 問題を改善するための次のスプリントで取り組むこと Keep Problem Problem と Try を改善で利用 開発者の意見を書いた付箋を貼る Try KPT ボード 9 NEC Corporation 2016

適用プロジェクトの概要 項目アジャイル開発手法開発者開発期間スプリント1 回の期間開発対象のシステムの特徴ドキュメント スクラム 4 人 1 年 10 か月 2 週間 内容 社内向けの Web アプリケーション ( データベースを検索し 結果をグラフ形式で表示 ) 開発の難易度は平均的以前のバージョンではペアワークを未適用 以下の目的の設計ドキュメントを作成 機能間の仕様整合性の確認 保守 10 NEC Corporation 2016

ペアワーク適用ルール ( 初期 ) 観点適用ルール考え方 適用範囲 ペアの組み方 ペアのローテーション 適用対象 調査 設計 プログラミング テスト設計 テストコード作成適用対象外 テスト実施 スパイク ( 調査目的のプロトタイプ作成 ) 少なくとも 1 人は 対象タスクに必要なスキルを持たせる 少なくとも 1 人は 既存機能の設計やコードを理解している 可能な限り毎日ペアをローテーションさせる 上記ルールでペアワークの適用を開始ふりかえりを通してプロジェクトに最適化 ペアワーク未適用時 成果物をレビューした作業はすべて対象 知識 スキルをどちらかが持っていないと 見落としに気付けない ローテーションによりチーム内で情報共有を促進 11 NEC Corporation 2016

改善例 1 - ペアのローテーション Keep Problem 問題があれば元に戻せばよい ペアのローテーションができない (2 つのペアで同時にタスクの切れ目にならない ) Try 毎朝新しいペアにする 仕掛中のタスクがあっても 必ず前日とは違うペアにする 仕掛り中のタスクがある場合は 前日の作業者を 1 人は含むペアが続きを行う 改善の結果 混乱なく毎日必ずペアをローテーションできるようになった ペアのローテーションにより より広く情報共有できるようになった 12 NEC Corporation 2016

改善例 2 - 集合レビュー Keep Try ペアワークだけですべての情報を共有するのは難しい Problem 後戻りが発生した他のペアが作った機能の設計を知らなかったことが原因 外部設計は開発者全員で必ず集合レビューする 改善結果 外部設計の知識が開発者全員で共有できるようになった 改善前よりも後戻りが削減できた 13 NEC Corporation 2016

改善例 3 - 休憩の取得 Keep Problem 疲労が続くとペアワークを続けられない ペアワークは疲れる相手がいるのでずっと気を抜けない Try 定期的に休憩をとる ( 目安 :1 時間で 10 分 ) 疲れたら ペアのどちらでも休憩を提案してよい 改善結果 疲労が軽減できた 14 NEC Corporation 2016

ペアワーク適用ルール ( 改善後 ) 適用範囲 観点 適用ルール 適用対象 調査 設計 プログラミング テスト設計適用対象外 テスト設計 テスト実施 スパイク ペアの組み方 少なくとも 1 人は 対象タスクに必要なスキルを持たせる 少なくとも 1 人は 既存機能の設計やコードを理解している 新規開発者が参加した場合は その人とペアを組む相手は十分な経験とスキルを持った人にする ペアのローテーション 仕掛中のタスクがあっても ペアを毎日交代する 仕掛中のタスクがあるときにペアをローテーションする際は そのタスクの続きを担当するペアの1 人は前日の作業者にする 改善例 1 集合レビュー 外部設計の成果物は開発者全員で集合レビューする 改善例 2 休憩 定期的に休憩を取る (1 時間働いたら10 分を目安に ) ペアのどちらでも 好きな時に休憩を提案してよい 改善例 3 赤字下線は初期のルールからの変更点 15 NEC Corporation 2016

メンバ交代発生時の生産性の変化 メンバ交代直後でも生産性の低下は見られない (%) 140 120 100 80 60 40 20 0 生産性 (Line/ 人 H の単位で V2.0 を 100% として比較 ) メンバ交代発生 V2.0 V2.1 V2.2 V2.3 V2.4 V3.0 V3.1 バージョン スプリント回数 新規機能の割合 メンバ交代 V2.0 10 回 68% - V2.1 4 回 67% - V2.2 4 回 60% あり V2.3 5 回 37% - V2.4 6 回 41% - V3.0 7 回 94% あり V3.1 4 回 72% あり 新規機能の割合が低く リグレッションテストが多かった 16 NEC Corporation 2016

ペアワークとソースコードの共同所有 ペアワークにより ソースコードの共同所有 を実現 開発者全員がすべての設計 / コードの知識を持ち どのファイルでも修正可能 X さんだけが知っている という成果物はない 開発チーム全員で 成果物全体に責任を持つ 設計の共有には集合レビューの活用も効果的 レビューするために必要な設計書を作成する 効果 ビジネス要求の変化への柔軟性 開発者のスキル 知識にバラツキがなければ要求を優先順に開発可能 特定の開発者しかできない作業は 後回しになる場合がある 開発者の交代への柔軟性 通常は 開発者の交代時に設計などの知識の引き継ぎが必要 事例のプロジェクトでは 特定の開発者に依存した作業はなくなった 初めは特定の人に依存していても 時間の経過で全員ができるようになった 開発者の交代が 3 回発生したが 引き継ぎは不要と判断した ペアワークにより新メンバへの知識の移転もスムーズにできた 17 NEC Corporation 2016

他プロジェクトへのルールの適用可能性 改善後の適用ルールは 他プロジェクトでも効果があると考えられる 開発対象のソフトウェアに特化したルールがない 初期のルールとして適用可能 適用開始後 プロジェクトの特性に合わせて最適化できる 他プロジェクトへの適用時の注意点 適用対象 難易度の高いタスクは そのタスクをペアワークの適用対象とすることで 1 人での抱え込みや 成果物の品質低下を防止 ペアのローテーション 開発チームの人数が多いとペアのローテーションによる全員との情報共有に時間がかかる 開発チームは通常 9 人以内なので 問題は起きにくい 人数が多い場合は適切なサイズにチームを分割する 18 NEC Corporation 2016

まとめ ペアワークの実プロジェクトへの適用を通じて 最適化されたルールを得た 最適化した適用ルールについて以下を考察した ビジネス要求の変化への柔軟性および迅速性の点で効果的である 他プロジェクトでも初期の適用ルールとして利用可能である 今後の課題 最適化した適用ルールを異なる条件のプロジェクトで適用 評価する より多くの開発者 より大きな規模の開発 19 NEC Corporation 2016