アジャイル開発をよりアジャイルに

Copyright © 2016 NTT DATA CCS Corporation
ESM 事例カンファレンス 2016 ～チーム運営と、アジャイル開発～
「アジャイル開発をよりアジャイルに」
2016年11月22日
株式会社NTTデータCCS
ビジネスソリューション事業本部
コンシューマシステム事業部第3システム開発部
佐藤竜一

2Copyright © 2016 NTT DATA CCS Corporation
講演者紹介をアジャイル事業部のメンバー紹介っぽく猫いてみた
1976 年高砂幼稚園中退後、DOA / OOA に基づくシステム開発に従事。
2004年より SI / 製造業 / 流通業の現場にて開発標準策定及び技術コンサ
ルティングを主業務としながら、プログラマとしてプロダクションコード
を書き続ける。著書『エンジニアのためのJavadoc再入門講座』、訳書
『実践プログラミングDSL』など多数。座右の銘は「論よりコンパイル」。
佐藤竜一 Rue’ichi SATOH
シニアソフトウェアアーキテクト、リヴィング中二

Copyright © 2016 NTT DATA CCS Corporation 3
弊社におけるアジャイル開発

弊社の紹介
• NTTデータグループの総合力を活かした、様々な業界のシステム提案 / 開発 / 保守 / 運用
• 総合エネルギー・資源・素材企業グループであるJXグループのシステム提案 / 開発 / 保守 / 運用
株式会社 NTT データ CCS
株式会社 NTT データ (60%)
JX アイティソリューション株式会社
(40%)
JX グループ向け事業ビジネスソリューション事業X
アジャイル推進部隊

受託開発 + アジャイル
• もう 10 年以上「できるか」「できないか」の議論
この辺りについては色々あるでしょうが今回は割愛
ムリ
できない
アジャイル
じゃない
何か

発注側にも発注側の都合がある
• 予算取るには稟議通す必要があるよ
• 稟議通すには総工費が必要だよ予算
• いつ終わるか分からないんじゃ企業活動成り立たないよ
• 進捗が計測可能じゃないと完了可能性が見えないよ期間
• 「コレ」を作らないとダメなんだよ
• でも「コレ」が何かはこのタイミングでは定義できないよ成果物
他にもいろいろありますが、上記のようなテーマは発注側内部でのコミットメント

受注側にも受注側の都合がある
• 出てきた定義が「現行と同じ」
• とか言いながら「業務が回らない」とかで仕様変更曖昧なスコープ
• 善管注意義務は果たすけど…
• 成功が確約されたプロジェクトなんてあり得ない実現可能性
• 「ソフトウェアは目に見えない」の話
• 「本当にほしいのはこれじゃなかった」可視性
よく言われる「不確実性のマネジメント」が求められるが、さてどうやって実現する?

アジャイルの前に UP (Unified Process) やってました
• 過去のプロジェクトの失敗 / 敗因
• 仕様変更に伴う手戻り作業の増加 (下流工程ほど深刻)
• 顧客 (ユーザ) と SIer (開発者) の仕様 (イメージ) 認識齟齬による作り直し
• 実装不可能な設計の発覚、要求された性能が出ない
• 誰も必要としていないドキュメントの作成
• 計画への不信感の増大
• 何とかするために Unified Process をベースに標準を策定した
• 反復開発
• 要求駆動開発 (ユースケース駆動開発)
• 視覚的モデリング
• ドキュメント: スケッチと設計書
• DOA と OO の融合
２００２年～２００５年

今も大きな進め方は変えてません
• 根本にあるのは「不確実性のマネジメント」
• 動作するソフトウェアを早期に提供し、実際に動かしながら顧客との調整を図る
• 高いリスク要因を最初に潰す
• 技術的リスク
• ビジネス上のリスク

基本的な進め方
• UP における「方向付け」フェーズで「ゴールの共有」
• 予算・期間の明確化
• 準委任契約
• 「推敲」フェーズで高リスク部分を可能な限り排除
• 「作成」フェーズで段階的にリリース、新たに出た要求を取り込み
• 対象領域の定義
• 範囲・期間に基づく見積 (ベースライン)ゴールの共有
• ビジネスが回らなくなるリスク
• 技術的なリスクリスクの排除
• ソフトウェアを実物で確認
• 確認した結果から、本当に必要なモノへの軌道修正段階的リリース

ゴールの共有
上記の検討結果に基づき、見積を提示して顧客と合意
• このプロダクトスコープを
• この期間で実現するには
• このくらいの費用がかかります
ビジネス全体の俯瞰
• BFD でビジネスの流れを
• ERD で対象とするデータを
それぞれ可視化
機能セットの抽出
必要とする機能の洗い出し
• ユースケース定義
• FDD 的にフィーチャの抽出
アーキテクチャ概要の立案
• 技術的な実現可能性
• 既存の制約
などを勘案しながらアーキテクチャの
概要を検討
優先順位付け
抽出した機能に対する優先順位の設定
• 絶対に必要な機能は?
• 実現に向けたリスクが高い機能は?

リスクの排除と段階的なリリース
見えないモノを早期に見えるようにして、その上で調整と合意を繰り返す。
ドキュメントでは可視化できない部分
• 使い勝手
• 「顧客の当然」と「開発者の当然」
動くシステムで確認
• 反復毎に動くシステムをリリース
• 顧客側での確認
• フィードバック
新たに生まれる要求
• 「こう思ってたけど違ってた」
• 「企画時点からビジネスの状況が変
わった」
「機能の出し入れ」
• 優先順位の見直し
• 優先度が高いものをスコープに入れる
• 優先度が低いものはスコープから外す
顕在化する技術リスク
• 夢と現実
• 数の暴力
早期実装と実データでの検証
• 重要・技術的難易度が高いユース
ケースから実装
• アーキテクチャの検証と軌道修正

反復型開発の実現に必要なプラクティス
• 段階的な開発と継続的な変更の取り
込みに必要
• 変化に対応するための手段として各
種のアジャイルプラクティス
• 変更への追従容易性
• 繰り返しリリースが可能な形へ
• スコープの管理
• 必要最小限のドキュメント
• TDD
• CI
• 反復計画
• ふりかえり
• 朝会
• ソフトウェアかんばん
• リファクタリング
• 品質傾向の計測とトレンドの管理
皆様御存知のものばかりです

そんなこんなで 10 年以上やってきた
今は回ってるし、今後も基本的にはいけると思う、けど…
• 人も入れ替わるし、新しいメンバもどんどん入る
• かつてのコアメンバーも今じゃすっかりいいオッサンになって金勘定ばかりしてる
(漠然と) 何か昔とは違う
• 進め方、考え方をどう組織に根付かせていくか
• 外部から参画するメンバをどう巻き込むか
継続した育成
• 既に実績があって手順として決まっているもの
• チームの自立性
• 動けているチームもある
• イマイチうまく動けていないチームもある
硬直化してきた感?
• 「誰かが決めた」
• 「上から降ってきた」
プロセスになっていないか?
• 何が違うのか?
• どこが違うのか?

10 年以上やってきたから、こそ
• チームの評価・改善に向けた手法
• 評価の方法
• 測定の方法
外部から客観的に見てもらう機会があっても面白い

アジャイル・コーチングを受けてみた

永和さんでやってるアジャイルコーチング
• 以前から色々と興味はあった
• コーチの参画方法には幾つかのパターンがあるが、今回は以下のイメージ
個人
ヒアリング
チーム評価
(before)
現場指導相談会現場指導相談会
イテレーションイテレーション
チーム評価
(after)
現場の課題を整理
コーチング前の状況
を評価
チームの成長を評価
コーチもふりかえり
に参加
チーム運営の疑問
解決や座学
コーチもふりかえり
に参加
チーム運営の疑問
解決や演習
• こちらで選んだ2つのチームの支援
• 1イテレーション2週間
• 1イテレーション中に2回訪問頂き、現場指導

コーチに入ってもらったのはこの方です
ちなみにメンバーが抱いていた「アジャイルコーチ」のイ
メージはこちらだったので、ギャップが大きかったとか。
永和システムマネジメント
コンサルティングセンターセンター長
天野勝さん

チームプロファイル
• メンバー 6～7 名
• アジャイル開発はほぼ全員初心者
• 開発期間5ヶ月
• コーチングのタイミングでは結合テスト～最
終リリース準備
• メンバー 7 名
• アジャイル開発経験者は 4 名程度
• 継続案件
• コーチングのタイミングは通常の開発フェー
ズ
D チーム T チーム
• 両チームとも、反復開発そのものは回っており、リリースも出来ている
(ビジネスとしては成功していると言える)
• …が、PDCA サイクルはうまく回せていないように見える
• 基本中の基本となるが、コーチにはふりかえりを中心に見てもらおう
• 未経験者も多いチームなので、復習も兼ねて座学 / 演習も実施しても
らおう

チーム評価
• 8 カテゴリ / 26 項目について評価
• 個々の項目に対して、個人ではなくチームとしてのスコアを出す
• 4 (常に出来ている) ～ 1 (全く出来ていない)
• 気づいた点をメモで残す
カテゴリ主な評価項目
PDCAサイクルイテレーション / スプリント / プラニング
品質動作の保証 / 仕事へのこだわり
情報共有共有の方法 / 鮮度
意思決定決定の責任所在 / 情報提供
ゴールゴールの定義 / 問題 / リスク
協働メンバが行っていること / チーム内でのサポート状況
学習新しいことへのチャレンジ / フィードバック
周囲の巻き込み利害関係者の特定
• コーチング後にスコアが下がるケースもあるので、スコアだけでは測定できない
(コーチングによる気付きの結果、新たに評価しなおして低いスコアになることがあった)

実際にチーム評価をしてみた
カテゴリ「ゴール」
問題への取り組み
カテゴリ「ゴール」
チームへの貢献
カテゴリ「協働」
他メンバの状況
カテゴリ「協働」
期待に対する行動
• 評価スコアとは別に、メンバが個別に抱いているイメージや不安点が浮き彫りになった
• チームを表から見ているだけではなかなか見えてこない部分が見えてきた

リーダー層とメンバーの意識の差
チーム評価の結果、リーダー層はチームとして出来ていると思っていたが、メンバーはそう思っていないという部
分が見えてきた
• コーチング前はメンバーとリーダー層の意識の差が大きかったが、コーチング後はその差が埋まってきた

朝会も見てもらいました
朝会のチェックリスト (12 項目) を元に、朝会の状況を確認したところ…
主なチェック項目評価評価結果
定時・定位置・定メンバー ○ 場所は決まっていてメンバーも固定
状況の可視化 ☓ タスク管理ツールを朝会で活用しきれていない
司会者の態度 ○ 適宜発言を促していた
発言者の態度 △ チームへの共有ではなくリーダーへの報告になっている
:
コーチから以下のような提言が。
• 朝会がPLへの報告になっていたのが気がかり。
• 部外者から見た朝会の質と、参加者の満足度に乖離がある。朝会が形骸化している。

改めて認識した「よくない兆候」
• メンバー間の能力における圧倒的な差 (優秀なメンバーに頼りがちになる状況)
• 顧客との接点の多寡 (顧客とより多く接するメンバーがイテレーションプラニングの中心を担う)
• チームメンバーの増減 (長く活躍しているメンバーと、新規に加わったメンバー)
…といった理由により、チーム内にコアメンバーを中心とした上意下達関係が出来てしまうと危ない。
他のメンバーへの遠慮が発生することにより、以下のような問題が顕在化しやすくなる。
初めはこうだったのが… いつの間にか上意下達関係が出来上がっている
• ノンコアメンバーのチームに対する「線引き」 (ここまでは俺、ここから先はチーム)
• 朝会などで問題が報告されなくなる
• スキルが埋もれてチームとして活用できなくなり得る

役割期待の再確認
コーチの助言により、チーム評価 (after) で個々のメンバーに対する期待を再度挙げてもらいました。
メンバー
Aさん役割(単体テスト、製造、結合テスト)をしっかり遂行して
ほしい、問題定義、フィードバックをしてほしい、浅いと
ころをなんでもやってくれる、困ったところをいろいろ
やってくれた、広く浅く活躍。
Bさんお客さんとの調整、チームのスケジュール／計画を立て
る、進捗確認、お客さんへの確認、少し離れたところか
ら客観的に見てくれる、朝会の司会を和やかにしてくれ
る、リーダーDさんの相談役。
Cさん要件定義、全体とバッチ、裏方回りをやる、DBの設計、
お客さん含めて全体から自分の作業かどうかを判断す
る。
Dさんスケジュールや仕様面に関しての決定、PJをしっかり回
す、リーダ、画面、APIでお客さんとの調整含めて円滑
に回す。
メンバー
Aさん決定してくれること、意思決定するうえでの相談に乗っ
てくれる、チームメンバーの育成の面、キャリアの育成、
要員の調整(人手不足)、育成。
Bさんインフラのことを教えてほしい、細かい作業の確認、
バッチのことを教えてほしい、インフラの意思決定をし
てほしい、インフラに対する提案をしてほしい(対お客さ
ん、対チーム)、安心させてほしい。
Cさん作業に対する指摘(テスト以外も)、強み作りを頑張って
ほしい、何をやりたいかを明確にしてほしい、なにか
あったときに「わからない」で終わらずもう少し自力で頑
張ってほしい、失速しないでほしい。
Dさんシステムのことをもっと吸収してほしい、いっぱい指摘し
てほしい、他のアプリケーションもお願いしたいので技
術を覚えてほしい、継続して積極的に、今後も幅広く業
務をやってほしい、インフラについても助けてほしい、幅
広くやってほしい(DBA)。
D チーム T チーム
• 他のメンバのことを知り、サポートし合えるようなチームになるには、メンバ間での期待の定期メンテナン
スが必要。
• プロジェクト開始時点だけでなく、定期的に個々人に対する期待を再確認したい

コーチングを終えて

外見だけだとチームの実体は分からない
• チーム評価シート / 朝会チェックリストを用いた継続的なチームのアセスメント
• スコアそのものより、スコアの変動から状況を把握して適切な支援を
• 役割期待は常に確認し合えるようにしたい
• チーム相互で、他チームの活動をファシリテート
• チームのふりかえりを、他のチームのメンバーがファシリテート
• チーム間同士で刺激し合えるような雰囲気を醸成したい
外部から見て「うまく回っている」ように見えても、実際はそうではないかもしれない
見え方よく見てみると…
朝会を毎日やっている朝会が PL / PM への報告会になっているかも
かんばんのチケットが消化されているホコリをかぶったチケットが残りっぱなしになっているかも
ふりかえりが行われている解決できない Problem、手のつけようがない Try が挙がっているかも
: :
今後は以下のような取り組みをしていきたい

アジャイル開発をよりアジャイルに

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie アジャイル開発をよりアジャイルに

Ähnlich wie アジャイル開発をよりアジャイルに (20)

アジャイル開発をよりアジャイルに