【勉強会】いまさらアジャイル巡業inTokyo2016
複雑さに挑む！カンバンによるプロジェクトマネジメント
- アトラシアン 長沢智治さん
タスクボードの話ではなく、プロジェクトマネジメントの話
エンタープライズの複雑さ
言葉の定義
ここでいうエンタープライズとは、 * 「複数の部門で構成される」ような * 比較的「規模の大きな法人」に向けた * 市場や製品のこと
エンタープライズは以下の点で複雑 * 複数の組織、大人数、サイロな組織、組織の統廃合、複数拠点、マルチベンダー、、、
複雑さを簡素化して考える
複雑さを簡素化して捉えるために様々な手法 * モデリング * 開発プロセス
価値の提供までをシンプルに測る * リードタイム：アイデアが出てから価値を提供するまでの時間 * 仕掛り作業（WIP）：作らなければいけない機能 * スループット：単位時間に作れる機能数
リードタイム＝WIP／スループット スループットをあげるか、WIPを減らせば、リードタイムは短縮される
複雑さへの各開発プロセスの対応
WFの考え方
事前に全て計画、作業分解（WBS）、きっちり定義することで品質担保 変更に弱い、変更管理委員会でなるべく変更を抑える（べき。）
スクラムの考え方
プロダクトバックログで、優先順位を付けて進める 変更に強い、スプリントごとの計画時に変更を踏まえることができる
カンバンの考え方
各ステップのWIPの数を制限して、作業を溢れさせない
カンバンの特徴
プロセスによらない
agileにもWFにも適用可
タスクボードとは違う
TODO/DOING/DONEだけではない ステップ（工程）を定義できれば何でも適用可 各ステップのWIPを制限するだけ
単位時間のWIPを定義する
各ステップのスループットを出して、単位時間にいくつのWIPがこなせるか しかし、大体の現場ではスループットが算出できない 時間内で限界までこなす体質だから まずはスループット（＝生産性）を見えるようにすべき
プル方式
前工程で終わったものを後工程に渡すのではなく、 後工程で手が空いたら前工程から取ってくる方式 ※各ステップ内ではTODO/DOING/DONEで管理
エンタープライズカンバン
（本質的には変わらないが組織的な問題で、）日本では、組織横断的なカンバンが難しい サイズの違うカンバンを入れ子にするといい ビジネス用の大きいカンバンと、開発チーム用の小さいカンバン、とか
安心・安全な開発を目指して
ｰ NTTデータCCS 森達彦さん
Agile初導入の顧客への提案・実践を参考に、「安心・安全」のポイントを整理する
お客さまの不安
- 不安1：現行システムではドキュメントが陳腐化している
- 不安2：要件の確定に時間がかかる
- 不安3：性能要件が厳しい
アジャイルを提案
- 不安1に対して、ドキュメントのみでなく、動くモノをみながら進められる
- 不安2に対して、確定した要件から着手できる
- 不安3に対して、動くモノが早くできる、早期に負荷テスト実施できる
安心安全への実践
定期的な動確で安心
要件と実装の乖離を最小に抑えるため、イテレーション毎に動作確認会を計画
ここが大事 * 動作確認会、必ず「対面」、雰囲気からのFBや一体感 * EU確認、システム担当のみでは終盤でひっくり返る * FB、毎回必ず受ける、仮リリースの意味がない
開発範囲が見直せて安心
予算内で最大の価値を提供するため、PJ中に数回、開発対象の見直しを計画
「実装機能」ではなく「開発規模」で話すとよい * 追加要件の優先順位が高ければ、同規模の既存要件を落とす * 具体的には、FPで会話すると定量的 * 契約時点でのFP分を担保すればOK * 現実的には、細かい仕様変更はFP計算できない、工数からFP逆算もあり
ここが大事 * 契約時に、この手法を合意しておくこと * 決定権のある人に、取捨選択をしてもらうこと
継続的な品質確認で安心
保守性を高めるため、品質に対する活動を計画
不安にさせてしまったことも
仮リリースで不具合が出た * 機能のすり合わせがしたいのに、不具合にFBが集中してしまう * システム部門とユーザ部門は別々にレビューしてもらう * 動作確認の目的を明確にしておく
Re:エンタープライズへのアジャイル開発の導入事例
- ウルシステムズ 吉原庄三郎さん
Agileで絶対に外せないコアプラクティス 書籍通りでは、実際うまくいかない、特にエンタープライズでは制約が多い PJごとにテーラリングが必要な部分がある
http://www.slideshare.net/shozaburoyoshihara/re-20161119
「過ぎたるは猶及ばざるが如し」
Agileの、4つの価値と12の原則、30〜のプラクティス（多すぎる） 忠実にやりすぎると大変な上、肝心のシステム開発が遅延する アジャイルのプラクティスよりもまず、システム開発をがんばるべき agileの価値を達成するための最低限の取組み（＝コアプラクティス）
Agileの価値
「超短期イテレーションの繰り返し」で 「ユーザが本当に望むシステムを実現する」こと
机上の要件定義と、実際に動くシステムのギャップを埋めること ギャップを埋めるためには？ * 超短期イテレーションで、動くシステムをユーザに見せる * 動くシステムをユーザが確認して、FBする * FBを計画的にシステムに反映する
コアプラクティス
コアプラクティスは３つのみ * 優先度に従った開発 * ユーザレビューの実施 * ふりかえり・デイリーミーティング
これ以外はWFで構わない。慣れてからプラクティスを追加すべき。 アジャイルコーチが、状況見ながら適用してくのがいい
事例紹介
プロダクトオーナー
理想は、業務部門がプロダクトオーナーだが。 日本のエンタープライズでは、情シ部門がプロダクトオーナーが現実的
コーチングプラン
agileの価値を、早く実感してもらう。開発にもユーザにも。 * 動く画面があると、ユーザが喜ぶ * ユーザが喜ぶと、開発も嬉しい
生産性を高める * プラクティスを最低限に * 学習コスト最低限に（既存の開発プロセスをなるべく踏襲） * 作業場所を一箇所に
やったこと
- 超短期イテレーション：イテレーション2週間
- インセプションデッキ：ゴールと進め方の共有
- ユーザーストーリー：要求を端的に表現
- 相対的な見積もり：ストーリーポイントで
- 全体計画
- イテレーション計画
- デイリーミーティング：１日単位で進捗と課題
- ふりかえり：チームがより高い能力を発揮するための議論
- プロダクトバックログ：要求、完了条件、優先順位
- カンバン：作業内容の見える化
これらは途中からやった * CI：問題の早期発見 * テスト自動化：デグレ防止
最初の2週間
前半：インセプションデッキ・ユーザストーリー 後半：全体計画
ユーザーストーリーで100点を狙わない * 今わかるものだけ、70点でいいから、課題を出しておく
ベロシティが控えめでPJ期間を超えても気にしない * そもそも見当がつかないので始めてみる、正確なベロシティはどうせ取れない
次の1週間
開発標準、開発環境の整備 開発標準は既存のものでいい、WF向けの標準から不要なものを間引く感じ ふりかえりの練習もここでやっておく
最初のイテレーション
イテレーション計画・ユーザヒアリング・開発・ふりかえり とにかく、動く画面を確実に作る ユーザの反応 * 指摘をすぐに修正してくれるのがいい * 今までは完成したものを見せられていた * 今までは文言修正でも費用がかかったり。。。
次のイテレーション
メンバー主体で動けるように、自己組織化させていく デイリースクラムやふりかえりをメンバーが仕切るようにする 自己組織化に向けて、企業文化が障害となる場合がある * チーム主体に対する上長からの不信感 * チーム内での先輩後輩問題
3つめ以降のイテレーション
状況を見ながらプラクティスを追加 チームが自分達から効率化をほしがるようになる 課題を吸い上げて、解決できるプラクティス 例えば、WFに比べて品質的な不安→CIまわす、など
自己組織化の見える化
- 初期：メンバーはタスクを指示される、課題解決に動けない
- 自律：メンバーはタスクを指示される、課題解決ができる
- 課題解決：メンバーはタスクを指示されるが、他のメンバーの課題も積極的に解決
- 自己運営：メンバーはタスクを自分たちで作れる、進捗・課題管理も運営できる
- 自己改善：自分たちで改善、ルール設定までできる
まとめ
シンプルなagileに徹して、ユーザ価値を追求しよう ユーザから好評を得て、開発チームのモチベーションを高め、良いサイクルを回す そのためには、コアプラクティスを実践して、とにかく動くモノを開発することに集中 あと、agile経験者からの支援は重要
質疑応答
自己組織化の難しいところは？
企業文化のハードル * 肩書きのせいでフラットなコミュニケーションができない * メンバーは、喧々諤々な議論に慣れてない * 人の意見に反論させてみる、反論がないと掘り下げができない * 議論させることで壁を壊すきっかけになる
2ヶ月程度のPJでの導入は？
短すぎるPJではむり、やめた方がいい
コアとは逆にやらない方がいいものは？
CI * やりたくなるが、必須とも言えない * Jenkinsやテスト自動化になれるために最初のイテレーションを潰してしまう
アジャイルモデリング
- ウルシステムズ 田上悠樹さん
アジャイルモデリング
心得集、包括的な方法論ではない
- ユーザの世界の言葉を
- システム踏まえて絵にしてあげて
- 共通意識を持つ ために、モデリングを使おうという考え方
本来agileなら動くモノを素早く提供して共通意識を詰めるもの だが実際は、例えば、イテレーションが1ヶ月の場合、 * 結果が見えるまでに1ヶ月かかる * その期間の意識合わせをどうする？ →モデリングの出番
モデリングのポイント
「本質的な側面」で「俯瞰的」に表現する
要求の全体像、マクロ視点
- ビジネス要求：Why：インセプションデッキ
- 業務要求：What：要求モデル
- システム要求：How：設計モデル
要求の各側面、ミクロ視点
- 振る舞い：動的な挙動やフロー、イベントや時系列
- 構造：静的な構成
- 境界：UI、システム間連携
- 制約：ビジネスルール、決定表、デシジョンテーブル
全体像を各側面でモデル化
What/How × 4つの側面、8つのモデル化 すべて埋めるのが必須ではない 各領域が包括的に情報共有できてれば
トークセッション：「エンタープライズにアジャイルって怪しい！？」
とはいえ、アジャイルのプロセスはエンタープライズにベストフィットしない フィットしないところにフォローをかけるのがエンタープライズアジャイル
チームが固定される前提じゃないと難しい 相対的な見積もりできないし スループットが計算できない 少なくとも、基準となるタスクは作るべき
上下関係の撤廃
偉い人が入ると、ファシリテーターになってしまって、意見が出にくくなる 一番若い人をファシリテーターにすると意見が出やすい
ユーザの説得
完全受託だったら、やりやすいのでは？ 森さんの手法で、トレードオフさせれば説得できそう ユーザにとってのagileの価値は？というと、途中で止められる アジャイルという言葉に拒否反応があるなら、その言葉を使わない、やり方だけ伝えて納得してもらう方法もある
