1 All Rights Reserved Copyright IPA 2018 はじめに本書はアジャイル開発のプロセスアジャイル開発チームにおけるメンバーの役割および必要なスキルについて解説していますアジャイル開発には複数のアプローチ ( スクラムや XP など ) があります本書では

Size: px

Start display at page:

みひなたけはな
5 years ago
Views:

2 1 All Rights Reserved Copyright IPA 2018 はじめに本書はアジャイル開発のプロセスアジャイル開発チームにおけるメンバーの役割および必要なスキルについて解説していますアジャイル開発には複数のアプローチ ( スクラムや XP など ) があります本書では代表的な手法であるスクラムを例にしてその特徴を解説しています唯一の正しいアジャイル開発というものはありません自分のいる組織に合ったやり方がその組織のビジネスや活動文化から自然と育っていくのがアジャイル開発の本質です基本的なことを書籍や外部の人を通じて学んだ後組織内で自律的に推進できるようにすることが必要ですアジャイル開発の進め方には厳格な決まりごとや規範はありません本書で説明 ( 例示 ) する進め方メンバーの役割 ( ロール ) など実際のソフトウェア開発プロジェクトでそのまま適用するものではありません実際のプロジェクトや組織に適したやり方を取捨選択しカスタマイズすることが必要となります

3 本書におけるアジャイル開発のスコープと体制について ( 前提 ) ITSS+ / アジャイル領域へのスキル変革の指針 2 All Rights Reserved Copyright IPA 2018 本書での前提ソフトウェア開発の進め方には規模や開発方針の違いによりいろいろなバリエーションがあります本書ではアジャイル開発の基本的な進め方を理解するため開発モデルとしてシンプルなものを前提に考え下図における開発の流れ中におけるプロジェクト立上げ ~ 開発の範囲を説明対象としています開発の流れプロジェクト立上げ本書での説明範囲要求要開テ求発スト第 1 反復開発要開テ求発スト第 n 反復第 1 リリース第 1 反復運用要開テ求発スト要開テ求発スト第 n 反復第 n リリース体制開発チーム事業部門チーム運用チームプロジェクト立上げ時に開発チームを編成しユーザー側の事業部門内のチームと連携を図りながら開発を進めていきます比較的大規模な開発では機能を設計開発するチーム ( 複数 ) と基盤共通部を設計開発する共通的なチームを設置する場合もあります

4 3 All Rights Reserved Copyright IPA 2018 目次アジャイル開発のプロセス -アジャイル開発のプロセス( スクラムの例 ) -アジャイル開発の進め方の特徴( スクラムの例 ) - 役割 ( ロール ) の特徴 ( スクラムの例 ) - 開発プロセスと役割 ( ロール ) の関連 ( スクラムの例 ) アジャイル開発チームのつくり方 -アジャイル開発チームのもつべきスキル -スキル一覧参考資料 < 参考 1> 従来型ロールとアジャイル型ロールの比較表 < 参考 2> アジャイル開発の概念整理

5 All Rights Reserved Copyright IPA 2018 アジャイル開発のプロセス ( スクラムの例 ) アジャイル開発には複数の進め方があります本書では

7 6 All Rights Reserved Copyright IPA 2018 アジャイル開発のプロセス ( スクラムの例 ) スクラムは反復 ( イテレーション ) を繰り返す開発プロセスですこの反復の単位をスプリントと呼びますスプリントの中身はスプリントプランニングデイリースクラムスプリントレビュースプリントレトロスペクティブ ( ふりかえり ) そして実際の開発作業ですスプリントは 1~4 週間の時間枠 ( タイムボックス ) であり予定されている機能が完成できなくても延長されることはありませんこの期間内で開発チームはスプリントバックログの開発に集中しリリース判断可能なインクリメント ( プロダクト ) を作り出しますスプリントバックログはプロダクトバックログから抜き出された今回のスプリントで追加する機能のリストを言いますスプリントプランニングでプロダクトオーナーの決めた順位と開発チームが決めた見積りの両方の情報を合わせて抜き出されますこのリストは一回のスプリントにだけ使用されますリリース判断可能なインクリメントとは一回のスプリントにおける成果を指しますスプリント終了時にはプロダクトが動く状態であることが必要となりこれをレビューしてプロダクトオーナーが実際にリリースするかどうかを決定しますすなわちスプリント終了時にはリリース判断可能になっている必要がありますプロセス中における各イベントの特徴を次ページ以降に説明します

8 7 All Rights Reserved Copyright IPA 2018 アジャイル開発の進め方の特徴 ( スクラムの例 ) 名称プロダクトバックログ特徴プロダクトバックログはプロダクト ( 製品 ) へ追加する要求 ( ストーリー ) のリストをいうユーザー ( 顧客 ) の分かる言葉で書かれている必要があるこのリストはプロダクトオーナー (PO) が管理するこのリストは順位づけされて並んでいることが重要であるまたプロダクトの開発が続く間変化し続け維持されるチームの中で作業の完了についての共通見解を合意して定義 ( 完了の定義 (Done の定義 )) しておくこの定義は開発者だけでなくプロダクトオーナーや顧客との間で合意しておき可能な限り定義を全員が常に認識できるようにしておくことが望ましいプロダクトバックログの決定は単なるプロジェクトやタイムマネジメントのための計画行為とは異なることに注意する提供すべきユースケースとプロダクトとしてのインフラ共通部分 ( 非機能要求などのバックログ項目 ) を見極めつつユーザーにとっての価値とビジネスとしての成功開発のスピードや品質をプロジェクトゴールに照らしてバランスさせる必要があるその前提で各スプリントで必要なストーリーの実現とそれらのストーリー ( およびそこに含まれるインフラ機能 ) の組合せとしての複数回のスプリントでアウトプットするリリースとを決めていくユーザー価値とビジネス ( 経営 ) ニーズと開発チーム能力とのマッチングの総合判断となるユーザーストーリーストーリー項目 1 ストーリー項目 2 ストーリー項目 3 プロダクトバックログバッグログ項目 1 優先 1 バッグログ項目 2 優先 2 バッグログ項目 3 プロダクトバックログは作りたいプロダクトの提供すべき価値 ( ユーザーストーリー : 機能要求ユーザーエクスペリエンスなど ) のリストである各ストーリー項目に優先度をつけて開発対象のバックログ項目を決めるプロダクトバックログに含まれる項目に対して詳細の追加見積り並び替えをすることをプロダクトバックログのリファインメントと呼ぶこれはプロダクトオーナーと開発チームが協力して行う継続的なプロセスであるプロダクトバックログのリファインメントによってバックログ項目のレビューと改訂が行われる

9 8 All Rights Reserved Copyright IPA 2018 アジャイル開発の進め方の特徴 ( スクラムの例 ) 名称スプリントプランニング特徴スプリントプランニングはスプリント ( 直近の 1 反復 ) の開始に先立って行われるミーティングをいうプロダクトバックログから今回のスプリントで扱うスプリントバックログを抜き出して決定するプロダクトオーナーが順位にしたがって今回扱うバックログを選び出しスクラムチーム全体でそれらを理解するそれらを開発チームが見積もり前回のスプリントで測定された開発実績に照らして順位の上からどこまでを今回のスプリントに入れるかを決めるさらにその後開発チームが計画を詳細化しタスクにまで分割する通常タスクは時間単位 (2~8 時間程度 ) で見積もられる 1 つのタスクは 1 人に割り当てられるスプリントプランニングは直近のスプリントでやるべきタスクを単に並べるだけではなくユーザー視点の意味を意識しながら ( 適切な境界で適切な粒度で ) 実現のためのタスクを切り出すことが必要となるそのスプリントのゴールを意識しながらそのストーリーを実現するためのユーザー観点と開発者観点の両方でのアクションの切り出しが必要となるその際それを支えるアーキテクチャを構想しストーリーの各ステップの具体的なアルゴリズムやデータ構造インターフェース実装技術を想定して作業時間の見積りを行う ( あくまで仮説ベース技術的に不確かな要素があればその調査タスクを別途切り出して追加する ) その切り出しの単位は同時に他のタスクとの接続性やテストしやすさを考慮したものにする必要があるつまり計画しながら設計と見積りと自主的な要員アサインとを同時にやっており総合的な判断作業といえるプロダクトバックログバッグログ項目 1 バッグログ項目 2 スプリントで扱うバックログ項目バッグログ項目 1 スプリントバックログ要求要求直近のスプリントで扱うバックログ項目を抜き出すタスク設計実装設計実装設計実装テストテストスプリントプランニングではユーザー観点と開発者観点の両方で実装するタスクを切り出す

10 9 All Rights Reserved Copyright IPA 2018 アジャイル開発の進め方の特徴 ( スクラムの例 ) 名称特徴スプリント内の開発作業はコーディング作業だけではなく要求の確認とテスト計画詳細設計 ( 場合によっては外部設計へのフィードバックも発生 ) コーディングと単体テストビルドと部分的なシステムテスト UI の確認といった有機的に繋がった非常に幅広い作業の集合体であるこのことから開発チームが協働しなければならないこと ( 各人の得意分野の違いを互いに補い合えるよう ) それぞれが得意分野を持ちつつも広い範囲の仕事がこなせる多能工でなければならないことになる要求設計実装テストスプリント内の開発作業開発チームが協働して要求 ~ 設計 ~ テストまでの作業を繰り返すスプリント内の開発作業開発の進め方はテスト駆動に基づくことが基本であるまずそのタスクが完了した際に満たすはずのテストプログラムをコーディングし現時点ではそれが失敗することを確認する次にそのテストを満たす最もシンプルな設計のコードを完成させテストが成功することを確認するここで他のタスクの成果物とビルドしたうえでのテストが実行されるそのうえでコードの構造や設計をさらに望ましい形にリファクタリングしテストが成功することを確認するこのとき要求の見直しやストーリーの一部省略変更も発生する最初に詳細レベルのテストを仕様化するということはテストで確認すべき機能仕様を定義する活動でもあり前もってこれらのテスト内容を書くということはソフトウェアの設計について考えるということになるこの繰り返しのサイクルを速くするため自動化できるものは全て自動化することが肝心であるリファクタリングテスト駆動開発の流れ失敗するテストを書くテスト駆動開発 (TDD) 繰返しテストをパスさせる開発の進め方はテスト駆動に基づくことが基本繰り返しのサイクルを速くするために自動化できるものは全て自動化する

11 アジャイル開発の進め方の特徴スクラムの例名称特徴デイリースクラム開発チームが全員の活動状況を共有し前回のデイリースクラム以降に行っ担当 To Do Doing Done た作業と次回のデイリースクラムまでに行う作業を確認するスタンドアップバックログミーティングとも言われ立ったまま毎日決まった時間に決まった場所で 15 項目#1 分の短い時間で行う朝行うことが多いため日本では朝会あさかいバックログ項目#2 という呼び名で知られるチームは1人ずつ昨日やったこと今日やること障害になっていることのバックログ 3つを順に話す開発チームが解決できない障害を取り除くことがスクラムマ項目#3 スターの仕事になるまたデイリースクラムの状況はプロダクトオーナーに報告開発チームが全員の活動状況を共有するするスプリント① スプリントレビュースプリントレトロスペクティブ (ふりかえり) スプリントの終了時関係者を呼び集めてできあがったプロダクトのデモンストレーションを行う開発チームにとっては自分たちが作ったバックログの項目が動いていることをアピールする機会であるうえに他の関係者にとってはスプリントが上手くいっていてプロダクトが徐々に成長していることを確認する機会でもあるスプリント② ステークホルダー利害関係者 ITSS+ アジャイル領域へのスキル変革の指針 10 スプリント③ レビュー社内営業部門事業責任者などスクラムチーム c a b c a b スクラムマスタープロダクトオーナー社外顧客やユーザー開発チームスクラムチームと関係者が各スプリントの終了時にスプリントの成果をレビューする Keep スプリントレビューの後に行われる今回のスプリントを振り返る機会をいうレトロスペクティブともいわれるここではこのスプリントでうまくいったことうまくいかなかったことどうやったら次のスプリントでよりうまくできるかが話し合われるこれが成長の機会となりチーム学習やチーム改善の活動となるうまく行ったこと Try 改善法 Problem うまく行かなかったこと新しい問題解決法新しいアイディアスプリントごとにふりかえりを繰り返すことでチームが成長していく All Rights Reserved Copyright IPA 2018

アジャイル開発の進め方の特徴スクラムの例前述のような総合的な作業を日々チームで会話を交わしながら毎日行うので初心者でも計画見積り設計個々のフレームワークや環境言語の使い方の実践的な練習が繰り返されることになりますいわばトレーニングをごく自然に受けている状況になり自分たちの判断したストーリーの定義環境の選択設計コーディングの成功失敗はそれぞれ 1スプリント

12 アジャイル開発の進め方の特徴スクラムの例前述のような総合的な作業を日々チームで会話を交わしながら毎日行うので初心者でも計画見積り設計個々のフレームワークや環境言語の使い方の実践的な練習が繰り返されることになりますいわばトレーニングをごく自然に受けている状況になり自分たちの判断したストーリーの定義環境の選択設計コーディングの成功失敗はそれぞれ 1スプリント 1~2スプリント 1スプリント数日数日数週間後には結果としてフィードバックされる環境で作業を進めることができます失敗も成功も自分たちチームの経験としてスキルアップに直接つながっていくことが実感できますおのずと技術向上が効率的に行われる開発プロセスです上記に関連して開発中に活用することのできるフィードバック例を下図に示します１フィードバックの例 ①ビルドとテストに基づくフィードバック -ユニットテストの結果 -コード解析の結果など ②デプロイ可能性に基づくフィードバック -デプロイメントの実行結果など ③実行時の振る舞いに基づくフィードバック -結合テストの結果 -ストレステストの結果など ④顧客からのフィードバック -機能収益など最初の2つの種類のフィードバックは主にソフトウェアの内部品質にかかわるものである他の2つは主にソフトウェアの外部品質にかかわるものである Copyright 2017, ITpreneurs Nederland B.V. All rights reserved. Copyright Devops Agile Skills Association LLC All rights reserved. 出典:DASA DevOpsファンダメンタルコース受講者用参考資料 ITプレナーズ 2017 参考ソフトウェアデリバリープロセスのフローのうえで発生するフィードバック例 ITSS+ アジャイル領域へのスキル変革の指針 11 All Rights Reserved Copyright IPA 2018

13 12 All Rights Reserved Copyright IPA 2018 役割 ( ロール ) の特徴 ( スクラムの例 ) スクラムで決められている役割 ( ロール ) はプロダクトオーナー開発チームスクラムマスターの 3 種類ですこれら全体をスクラムチームと呼び 3 つの役割が協調することで大きな効果を創出します開発チームはプロダクトの開発プロセス全体に責任を負い開発プロセスを通して完全に自律的である必要がありますスクラムではこの自律したチームのことを自己組織化されたチームと呼びますチームがプロダクトを開発するために必要なスキルを全て備えている必要があります従来型では特定の専門性をもったメンバーが役割分担して開発することが一般的でしたがスクラムの開発チームは一人が複数のタスクを担う多能工である必要がありますステークホルダー ( 利害関係者 ) スクラムチーム社内 ( 営業部門事業責任者など ) スクラムマスタープロダクトオーナー社外 ( 顧客やユーザー ) 開発チーム

14 13 All Rights Reserved Copyright IPA 2018 役割 ( ロール ) の特徴 ( スクラムの例 ) ロール説明詳細プロダクトオーナー開発チームスクラムマスター何を開発するか決める人実際に開発作業に携わる人々全体を支援マネジメントする人開発への投資に対する効果 (ROI) を最大にすることに責任をもつチームに最も価値の高いソフトウェアを開発してもらうためにプロダクトに必要な機能を定義しその機能を順位づけする機能がプロダクトバックログというリストになっているバックログへの追加削除順位づけはプロダクトオーナーに最終的な責任があるまたプロダクトオーナーには開発チームに機能を説明して理解してもらう責任があるもちろんプロダクトのビジョンを示すことも大切な仕事である実際に開発を行うチームのことで開発者たちを指す従来型では役割ごとにタスクや役割が決まっているのが一般的であるスクラムではビジネスアナリストプログラマーテスターアーキテクトデザイナーなどの明示的な区分けはない個人の専門分野はあってよくむしろ強みを持ち寄りその垣根を超えて貢献しあう機能横断的な様々な技能を持った人がプロダクトを中心に集まり自律的に行動する開発チームはバックログに入っている項目を完了状態にしプロダクトの価値を高めていくことに責任を持つスクラムマスターはスクラム全体をうまく回すことに責任を持つキーパーソンといえるスクラムチーム全体が自律的に協働できるように場作りをするファシリテーター的な役割を担うときにはコーチとなってメンバーの相談に乗ったり開発チームが抱えている問題を取り除いたりするスクラムチーム全体をマネジメントするがコントロール型の管理を行うのではなくチームを支援する役割を担うサーバントリーダー ( 奉仕型のリーダー ) といえ開発チームを外部の割り込みから守りチームの障害を取り除くために外部との交渉を行う開発のやり方に関する決定はスクラムマスターではなく開発チームが行うスクラムマスターが細かい指示を出すのではなく自分たちで決めながら動く自律したチームを作ることが生産性をあげる鍵となる

15 開発プロセスと役割 ( ロール ) の関連 ( スクラムの例 ) アジャイル開発のプロセスと役割 ( ロール ) の対応関係について次表に示します大分類中分類小分類評価項目スクラムプロジェクト立ち上げプロダクトバックログの決定スプリント繰返し ITSS+ / アジャイル領域へのスキル変革の指針プロジェクト方針の初期検討プロジェクトチームの編成プロセス役割 ( ロール ) ビジネスのビジョン戦略を共有するプロジェクトとしての目標あるべき姿基本的価値観の共有を図るプロダクトオーナースクラムマスターの役割を決定する開発メンバーを決定するプロダクトオーナー開発チームスクラムマスター / - - / - - 事業部門との体制構築事業部門と体制役割について合意する / - - システムの目的の合意システムの目的やゴールの共有を行うリリース計画スプリント計画 ( イテレーション計画 ) スプリント ( イテレーション ) ユーザー要望を受けユーザーストーリーを決定するスプリント期間を決定するスプリント計画を準備する最初のプロダクトバックログのグルーピングを行うプロダクトバックログアイテムを見積もる次のスプリントの目標を定義する仕事量の見積りを行いスプリントで扱うストーリーの数を決定する実施するタスクをスプリントバックログに追加するタスクを実施する ( 毎日 ) デイリースクラムでチームの状況を共有する ( 毎日 ) デイリースクラムの状況をプロダクトオーナーと共有するスプリントレビュー ( デモ ) スプリントの成果物をプロダクトオーナーにデモするふりかえり ( レトロスペクティブ ) スプリント中の改善事項を検討し次につなげるプロダクトバックログリファインメント更新されたストーリーをプロダクトバックログに追加する記号意味主体となって実施するタスク他のロールが主体となって実施し補佐的にかかわるタスク実施にはかかわらないがタスクの情報を共有する何も行わない ( 実施にかかわらずタスクの情報も共有しない ) アジャイル開発ではどのロールも実施しないタスク 14 All Rights Reserved Copyright IPA 2018

17 16 All Rights Reserved Copyright IPA 2018 アジャイル開発チームのもつべきスキルアジャイル開発へとパラダイムシフトする際の最も重要な側面の 1 つは開発チーム内の役割の違いを理解することですアジャイル開発におけるチームの特徴は機能横断 ( クロスファンクション ) 型のチーム体制ですチームがプロダクトのライフサイクル ( 設計ビルドテストデプロイ実行 ) を通じて完全に自律的であるためにはチームとしてバランスのとれたスキルセットを備えることが必要ですチームメンバーは仕事をこなすための深い開発スキルを持つと同時にチームとしてパフォーマンスを最大化するためのスキルが必要ですメンバー A メンバー B メンバー C チームアジャイル開発に必要な全てのスキル知識を持つ人材を育てることは必須の条件ではありません一人の個人だけではスキル領域ごとのレベルに凸凹がありますがその凸凹をチームとして埋めていきます一人の個人だけでは不足している知識スキルをチームとして補っていくのですメンバーのスキルの凸凹をチームとして埋める

18 17 All Rights Reserved Copyright IPA 2018 アジャイル開発チームのもつべきスキル従来型の開発では要件定義設計開発からテストを経て運用へと明確な役割分担のもとにプロセスが進みます初期工程で仕様をきっちりと決めるため誰が何をすべきかを明確にすることができます一般に SE( 設計者 ) プログラマーテスターなどを専任の役割としておくということは珍しくありませんこのような役割分担で開発を進めるとタスクの切れ目に人のアサインや引継ぎなどのオーバーヘッドが生じますアジャイル開発ではチーム員同士で教えあいチーム一丸となってプロダクトを開発していきますチームで仕事をすることにより個人が得意とする分野だけでなくより広範な分野の業務を実施できるようになり個人の成長につなげることができますこのため専門領域以外のスキルを埋めるためにチーム内の他の人材や他ステークホルダーと連携する能力も備わっていることが重要となりますアジャイル開発では最終プロダクトをリリースするために必要となる全てのスキルが 1 つのチーム内に備わっているためタスク間の引継ぎが最小限に抑えられプロセス全体のスループットが最適化されますアジャイル開発ではスピードが重要でありできるだけ早くユーザー機能を顧客に提供することが重要です組織は価値あるフィードバックループを活用でき自分たちの進んでいる方向が正しいかどうかを判断できることにもつながりますあるタスクの高度な専門家が活動できない場合でもプロダクトやサービスを継続的に提供するためには各開発者が自分の能力にさらに多くのスキルや知識を追加していくことが重要となりますアジャイルなチームにおいてはリソースは通常は複数のスキルを持ち必要な場合には積極的にスキルを向上させようと努めます

19 18 All Rights Reserved Copyright IPA 2018 スキル一覧アジャイル開発に必要なスキルを分類して示します下図ではアジャイル開発を推進するスキルとソフトウェア開発の各局面で必要なスキルとに分類して示します前者はアジャイル開発に特化したものですが後者は従来型においても必要な開発スキルになりますリリース計画要求開発テストアジャイル開発を推進するスキル共通して必要なスキル次ページに一覧を例示特定の局面で必要なスキルアジャイル開発プロセスアジャイル開発プロダクトアジャイル開発プラクティス継続的改善勇気リーダーシップ事業価値理解やビジネスマインドセキュリティリスクおよびコンプライアンス理解アーキテクチャおよび設計チームビルティング顧客接点マネジメントファシリティワークスペースソフトウェア開発の各局面で必要なスキル特定の開発過程で必要なスキルシステム企画立案 UI デザインシステム要件定義方式設計運用設計移行設計基盤システム構築アプリケーションシステム開発プログラミングシステムテスト移行導入 ( システムリリース ) ソフトウェア保守

20 19 All Rights Reserved Copyright IPA 2018 アジャイル開発を推進するスキル例 (1/4) スキルカテゴリスキル項目知識項目別名リリース計画ミーティングイテレーション計画ミーティングイテレーションプランニングポーカー計画ゲームスプリント計画ミーティング反復型計画タイムボックススプリント反復見積りポーカーアジャイル開発プロセスベロシティ計測日次ミーティング朝会朝礼デイリースクラムスタンドアップミーティング技術スキルふりかえりかんばんスプリントレビュータスクボードバーンダウンチャートユーザーストーリーレトロスペクティブリフレクション内省反省会 Kanban フィーチャーパイプラインデモスクラムボードタスクカードストーリーカードアジャイル開発プロダクトスプリントバックログインセプションデッキプロダクトバックログマスターストーリーリスト

21 20 All Rights Reserved Copyright IPA 2018 アジャイル開発を推進するスキル例 (2/4) スキルカテゴリスキル項目知識項目別名ペアプログラミングペアワークペアリング自動化された回帰テストリグレッションテストテスト駆動開発ユニットテストの自動化受入テストデベロッパーテスティング顧客テスト機能テストストリーテストシステムメタファ技術スキルアジャイル開発プラクティススパイクソリューション実験曳光弾リファクタリングシンプルデザイン YAGNI 逐次の統合継続的インテグレーション常時結合 CI 集団によるオーナーシップ共同所有コーディング規約コーディング標準

22 21 All Rights Reserved Copyright IPA 2018 アジャイル開発を推進するスキル例 (3/4) スキルカテゴリヒューマンスキルスキル項目知識項目別名私たちは今日昨日よりもうまく仕事をするカイゼンのマインドセット源流管理継続的改善最初から正しく知識の共有順応性総合伝える情熱コーチング自信自発性勇気反省信頼オープンな議論実験早く失敗すること変更する勇気チームのハイパフォーマンス化の促進リーダーシップ謙虚さサービスライフサイクルのマインドセット利害関係者のマネジメント

23 22 All Rights Reserved Copyright IPA 2018 アジャイル開発を推進するスキル例 (4/4) スキルカテゴリヒューマンスキルスキル項目知識項目別名顧客プロキシオンサイト顧客プロダクトオーナーファシリテータスクラムマスターアジャイルコーチ自己組織化チームチームビルディングニコニコカレンダー他者の視点の理解コラボレーション相互の説明責任共通の目的サービス / プロダクトを総合的にサポートする能力対面コミュニケーション顧客起点顧客接点マネジメント価値起点場づくり共通の部屋チーム全体が一つにファシリティワークスペース人材のローテーションインテグレーション専用マシン

従来型ロールとアジャイル型ロールの比較表について従来型ロールとアジャイル型ロールの比較表は従来型ウォーターフォール型開発に従事してきた人材がアジャイル開発について学ぶ時従来型ロールとアジャイル型ロールの実施するタスクの違いを比較するための参考資料です本表のタスクは icd2017を参照して SI型アプリケーションシステム開発に典型的なタスクを抜き出しています従来型ロールは企画

DV06 ソフトウェア製品開発開 DV07 組込みソフトウェア開発発 DV08 Webサイト開発フサイクル利 DV09 システムテスト DV10 セキュリティテスト DV11 移行導入システムリリース DV12 ソフトウェア保守ファシリティ設計構築イサービスデスク US02 IT運用コントロールシステム運用管理 US04 Webサイト運用管理 US05

26 従来型ロールとアジャイル型ロールの比較表について従来型ロールとアジャイル型ロールの比較表は従来型ウォーターフォール型開発に従事してきた人材がアジャイル開発について学ぶ時従来型ロールとアジャイル型ロールの実施するタスクの違いを比較するための参考資料です本表のタスクは icd2017を参照して SI型アプリケーションシステム開発に典型的なタスクを抜き出しています従来型ロールは企画開発を職務とするロール icdではタスクプロフィールと呼ぶを抽出しタスクとの関連を示しています今回このタスクに対してアジャイル型ロールではどう対応するかを例示しています従来型の各ロールが実施して各タスクをアジャイル型ロールがどういうフォーメーションで実施しているのかを確認することができます役割別タスクプロフィールロール基盤システム構築 DV05 アプリケーションシステム開発 DV06 ソフトウェア製品開発開 DV07 組込みソフトウェア開発発 DV08 Webサイト開発フサイクル利 DV09 システムテスト DV10 セキュリティテスト DV11 移行導入システムリリース DV12 ソフトウェア保守ファシリティ設計構築イサービスデスク US02 IT運用コントロールシステム運用管理 US04 Webサイト運用管理 US05 ファシリティ運用管理改善 I デ DV14 US03 U ハードウェアソフトウェア製品導入 US01 US 06 マサネジビメスントタスク大分類コードタスク大分類 PL02 システム企画立案タスク中分類コードタスク中分類タスク小分類コードタスク小分類評価項目コード評価項目開発チーム PL 事業環境業務環境の情報を収集し事業課題を分析するン PL システム化構想の前提となるIT戦略を把握する PL 事業環境および業務環境の分析結果と情報システム化目標の関係をIT化方針として文書化する PL 現行業務システ PL 現行業務を調査し業務実態を把握するムの調査分析 PL 現行システムの状況を調査し現行システムの稼働状況を把握する PL ロールの実施するタスクを比較 PL 現行の業務やシステムの状況から開発改善改革対象の範囲を把握する新業務の全体像 PL システム化で対応する業務機能のあるべき姿を描く把握と評価指標の EV01 PL あるべき業務機能に求められる主要機能を明らかにする EV02 IT戦略評価改善 PL 企画するシステムにおける業務運用の定量的評価指標を設定する EV03 IT製品サービス戦略評価改善 EV04 事業戦略評価支援改善支援 EV05 事業戦略評価改善比較表では青色のタスクを抽出スクラムマスターシステム化構想の立システム化構想基 PL02.1 PL PL システム化構想によるビジネス課題解決の達成目標を確認する案本方針の策定システム評価改善資産管理評価アジャイル型ロール例プロダクトオーナー DV13 用価ウォーターフォール型ロールザ活評プロジェクトマネジメント ITサービスマネジメント移行設計 DV04 アプリケーションデザイン DV03 DV 15 テクニカルエンジニアリング運用設計 ITアーキテクチャデザイン DV02 ビジネスアナリシスシステム要件定義方式設計意味主体となって実施するタスク他のロールが主体となって実施し補佐的にかかわるタスク実施にはかかわらないがタスクの情報を共有する何も行わない実施にかかわらずタスクの情報も共有しないアジャイルではどのロールも実施しないタスクプロジェクトマネジメントシステム企画立案 DV01 記号 PL 03 ビジネスプロデューサ PL02 IT戦略策定実行推進 ITサービスマネジメント PL01 アプリケーションデザインイ IT製品サービス戦略策定テクニカルエンジニアリングラ事業戦略把握策定支援 ST03 ITアーキテクチャデザイン企画 ST02 ビジネスアナリシス戦略各タスクに対して従来型ロール(下図の赤枠とアジャイル型ロールの対応下図の緑枠を示している記号の意味は次のとおり事業戦略策定プロジェクトマネジメント ST01 タスクとロールとの対応 icd2017より抜粋タスク構成図 icd2017より抜粋 PL 企画するシステムにおける業務運用の定性的評価指標を設定する PL 投資規模の策定 PL 企画するシステムの開発一次費用に関する期間体制工数設備費の概算を見積もる PL 企画するシステムの保守運用継続費用に関する体制工数機器保守費の概算を見積もる PL ビジネスモデルとシステムアーキテクチャによる企業目標経営戦略およびIT戦略の実現性を評価する従来型ロールとアジャイル型ロールの比較表注意本表は従来型開発のタスクの違いを比較するためにスクラムのフレームワークで登場するロールを参考に示していますそのため従来型のロールとスクラムのロールとで比較するタスクをあえて同一項目にして表しています本表は参考資料として示すものであり全てこのとおりに実施することもしくはこれだけ実施すればよいことを示すものではありません ITSS+ アジャイル領域へのスキル変革の指針 All Rights Reserved Copyright IPA

27 タスク大分類コードタスク大分類 DV15 プロジェクトマネジメント DV15 プロジェクトマネジメントタスク中分類コードタスク中分類 DV15.2 プロジェクト計画策定 DV15.2 プロジェクト計画策定 DV15.2 プロジェクト計画策定タスク小分類コード 1 DV DV DV DV DV タスク小分類プロジェクト企画書の作成プロジェクト企画書の申請と説明プロジェクト企画書の完成スコープ計画の策定スコープ計画の策定スコープ計画の策定評価項目コード DV DV DV DV DV DV DV DV DV DV DV DV DV DV DV DV DV DV プロジェクトの目的目標成果物を明らかにするプロジェクトの実施期限とマイルストーンを明らかにするプロジェクトの体制と要員計画の概要および必要な資源を明らかにするプロジェクトの課題とリスクを明らかにする審査担当者決裁者が判断しやすいように企画の要点を記述するプロジェクト企画書を必要な関係者に配布し承認の手続きをとるプロジェクト企画書の説明と質疑応答を行い必要な関係者の理解を得る承認手続きを通じて設定された制約が支障とならないことを確認する組織体における実行可能性を検討するプロジェクトマネージャを任命しその役割任務権限を明らかにするプロジェクトマネージャに企画内容をプロジェクトの初期要求として伝えるプロジェクト成果を組織体の経営戦略事業戦略等に貢献するものとして明らかにするユーザに対する品質保証基準としての満足度基準を明らかにするプロジェクト推進組織が果たすべき役割と任務を明らかにする成果物費用期間品質利用者規模機能技術リスク等のプロジェクト情報を定義し範囲を明らかにするプロジェクト推進の前提条件および制約事項を明らかにするプロジェクト計画および実行時に解決すべき課題を明らかにするスコープ管理方針を提示する評価項目ビジネスアナリシスビジネスアナリシスビジネスアナリシスプロジェクトマネジメントプロジェクトマネジメントプロジェクトマネジメント IT アーキテクチャデザイン IT アーキテクチャデザイン IT アーキテクチャデザインアプリケーションデザインアプリケーションデザインアプリケーションデザインテクニカルエンジニアリングテクニカルエンジニアリングテクニカルエンジニアリング IT サービスマネジメント IT サービスマネジメント IT サービスマネジメントビジネスプロデューサプロダクトオーナービジネスアナリシススクラムマスタープロジェクトマネジメント IT アーキテクチャデザインアプリケーションデザイン開発チームビジネスプロデューサビジネスプロデューサビジネスアナリシスビジネスアナリシスプロジェクトマネジメントプロジェクトマネジメント IT アーキテクチャデザイン IT アーキテクチャデザインアプリケーションデザインアプリケーションデザインテクニカルエンジニアリングテクニカルエンジニアリングテクニカルエンジニアリング IT サービスマネジメント IT サービスマネジメント IT サービスマネジメント従来型ロールとアジャイル型ロールの比較表の見方本表を次に示す観点で比較することにより従来型ロールとアジャイル型ロールを比較してくださいウォーターフォール型ロールアジャイル型ロール ( 例 ) スクラプロダクトムマス開発チームオーナーター観点 1 アジャイル型ロールは従来型ロールとは概念が大きく変わり従来型より広範な能力が求められるアジャイル型ロールは多様なタスクをこなす ( 多能工化している ) ことを理解するタスク大分類コードタスク大分類タスク中分類コードタスク中分類 PL02 システム企画立案 PL02.1 システム化構想の立案タスク小分類コードタスク小分類 PL システム化構想基本方針の策定現行業務システ PL ムの調査分析全てのタスク新業務の全体像 PL 把握と評価指標の PL 投資規模の策定評価項目コード PL システム化構想によるビジネス課題解決の達成目標を確認する PL 事業環境業務環境の情報を収集し事業課題を分析する PL システム化構想の前提となる IT 戦略を把握する PL 事業環境および業務環境の分析結果と情報システム化目標の関係を IT 化方針として文書化する PL 現行業務を調査し業務実態を把握する PL 現行システムの状況を調査し現行システムの稼働状況を把握する PL 現行の業務やシステムの状況から開発改善改革対象の範囲を把握する PL システム化で対応する業務機能のあるべき姿を描く評価項目観点 1 アジャイル型では多様なタスクを実施 ( 多能工化 ) している PL あるべき業務機能に求められる主要機能を明らかにする PL 企画するシステムにおける業務運用の定量的評価指標を設定する PL 企画するシステムにおける業務運用の定性的評価指標を設定する PL 企画するシステムの開発 ( 一次費用 ) に関する期間体制工数設備費の概算を見積もる PL 企画するシステムの保守運用 ( 継続費用 ) に関する体制工数機器保守費の概算を見積もる PL ビジネスモデルとシステムアーキテクチャによる企業目標経営戦略および IT 戦略の実現性を評価するウォーターフォール型ロールアジャイル型ロール ( 例 ) スクラプロダクトムマス開発チームオーナーター観点 2 観点 3 ITSS+ / アジャイル領域へのスキル変革の指針従来型では単独で行っていたタスクをアジャイル開発では複数のロールが協働して行う従来型の PM の仕事の多くの部分はチームメンバー各人が自律的に行うことになるプロジェクトマネジメントのタスクのうちアジャイル型のチームメンバーが担わない仕事がスクラムマスターの担う役割となる逆にいうとスクラムマスターの果たす役割は従来型の PM の仕事に比べてサーバントリーダーの位置づけとなるためコマンダー型のタスクには対応しなくなるタスク大分類コードタスク大分類タスク中分類コードタスク中分類 PL02 システム企画立案 PL02.1 システム化構想の立案タスク小分類コード DV15 プロジェクトマネジメント DV15.1 プロジェクト立ち上げ DV15.1. PL システム化構想基本方針の策定現行業務システ PL ムの調査分析全てのタスク PL タスク小分類新業務の全体像把握と評価指標の PL 投資規模の策定プロジェクトマネジメントのタスク評価項目コード PL システム化構想によるビジネス課題解決の達成目標を確認する PL 事業環境業務環境の情報を収集し事業課題を分析する PL システム化構想の前提となる IT 戦略を把握する PL 事業環境および業務環境の分析結果と情報システム化目標の関係を IT 化方針として文書化する PL 現行業務を調査し業務実態を把握する PL 現行システムの状況を調査し現行システムの稼働状況を把握する PL 現行の業務やシステムの状況から開発改善改革対象の範囲を把握する PL システム化で対応する業務機能のあるべき姿を描く PL あるべき業務機能に求められる主要機能を明らかにする PL 企画するシステムにおける業務運用の定量的評価指標を設定する PL 企画するシステムにおける業務運用の定性的評価指標を設定する PL 企画するシステムの開発 ( 一次費用 ) に関する期間体制工数設備費の概算を見積もる PL 企画するシステムの保守運用 ( 継続費用 ) に関する体制工数機器保守費の概算を見積もる PL ビジネスモデルとシステムアーキテクチャによる企業目標経営戦略および IT 戦略の実現性を評価するウォーターフォール型ロールアジャイル型ロール ( 例 ) 観点 3-2 アジャイル型のPM( スクラムマスター ) は従来型のPMのタスクがカバーしない要素が多い 26 All Rights Reserved Copyright IPA 2018 評価項目観点 2 従来型では単独で行っていたタスクをアジャイル型では複数のロールが協働して行う観点 3-1 従来型ではプロジェクトマネージャーのみが担っていたタスクをアジャイル型では各ロールが行っている

28 従来型ロールとアジャイル型ロールの対応イメージ従来型のロールでは実施するタスクの括りが異なるアジャイル開発のロールは従来型開発では複数のロールが実施していたタスクを実施する場合があるステークホルダー ( 利害関係者 ) スクラムチームアジャイル型スクラムマスターの実施するタスク吹き出しの中はは従来型開発のロールが実施するタスクを表す < ロールの略称 > BP: ビジネスプロデューサ BA: ビジネスアナリシス PM: プロジェクトマネジメント (SL: サーバントリーダー型 ) AP: アプリケーションデザイン ITA:IT アーキテクチャデザイン TE: テクニカルエンジニアリング ITSM:IT サービスマネジメント社内 ( 営業部門事業責任者等 ) 社外 ( 顧客やユーザー ) プロダクトオーナースクラムマスター開発チームアジャイル型プロダクトオーナーの実施するタスク従来型 BP のタスク従来型 AP のタスク従来型 BA のタスク従来型 PM のタスク従来型 ITA のタスク従来型 ITSM のタスクコマンダー型 PM のタスクサーバントリーダー型 PM のタスクコマンダー型の PM タスクには対応しないことを表すアジャイル型開発チームの実施するタスク従来型 ITA のタスク従来型 PM のタスク従来型 TE のタスク従来型 ITSM のタスク従来型 AP のタスク従来型ロールとアジャイル型ロールとの対応 ( イメージ ) ITSS+ / アジャイル領域へのスキル変革の指針 27 All Rights Reserved Copyright IPA 2018

30 アジャイル開発の概念整理アジャイル開発の目的顧客にとっての価値を知るにはアジャイル開発とはビジネス価値の最大化に向けて顧客に価値のあるソフトウェアを早く継続的に提供するためのアプ顧客にとっての価値とは何かを知るために実際に作ったものを使ってもらって顧客が満足しているかどうかを確認しますローチですこれを実現するためにアジャイル開発で重要となる事項について説明します常に状況は変化すると考える昨今のビジネス環境は絶えず変化しますそれに俊敏に対アジャイル開発の本質応するためベストではないもののベターなビジネス解を徐々アジャイル開発での最終的な目標はビジネスの価値の最に改善していく傾向が強くなっていますこうした状況から生み大化です開発者も常に顧客と同じ目線で顧客にとっての出されるシステム要求もビジネス解の継続的な変化に対応価値が最大となるよう取り組む姿勢が必要ですし変更し続けることになりますアジャイル開発では変化に一方でアジャイル開発を作業効率化の１つの手法として考対応して価値のあるソフトウェアを早く継続的に提供してえている方がいるかもしれません開発者としてなるべくムダないくことが求められます作業を行わないことはアジャイル開発では基本的な考え方ではありますがいくら作業を効率化できたとしても価値あるものを創出できなければ意味がありません変化に柔軟に対応するためには顧客の要求も絶えず変化しますので顧客からのフィードバックを短いサイクルで得ながら提供したものに価値があるかどうかを継続して確認します ITSS+ アジャイル領域へのスキル変革の指針 29 All Rights Reserved Copyright IPA 2018

31 アジャイル開発の概念整理ビジネス価値のある動くソフトウェアとは開発チームは開発プロセスのライフサイクル全体を通して完アジャイル開発ではソフトウェアを提供するためタイムボック全に自律している自己完結している必要がありますそスを使用した反復型のアプローチをとります顧客が評価できのためチームは顧客とエンドツーエンドでコミュニケーションするソフトウェアを提示し顧客からのフィードバックを短いサイクるとともに開発プロセス全体を遂行するために必要な全てのルで得ながら提供したものに価値があるかどうかを確認しま専門知識やスキルをチームとして備えている必要がありますす現場現物現実高速仮説検証サイクルこれにより要員アサインや承認のための待ちなどを排除してムダをなくすことができます顧客とのWin-Winの関係を構築する顧客からのフィードバックを効率的効果的に得るためには技術プログラミングの重要性人間の能力を最大限に活用するために開発者は何を身開発者と顧客が直接対話しながら Win-Winの関係を築に付けておくべきでしょうかいていることが肝心ですアジャイルソフトウェア開発宣言の背後にある原則の1つにあ自律的なチームで人の能力を最大限に発揮するるように技術的卓越性と優れた設計に対する不断の注意アジャイル開発に限った話ではありませんが組織やプロジェが機敏さを高めるため常に最新の技術を身に着ける努力クトにおいて一番大切なものは人ですが必要となってきますアジャイル開発では動くソフトウェアに価自動化が進んでもやはり人間でなければできないことはたく値を求めるためとりわけプログラミングに関する知識やスキルさんあります特にアジャイル開発ではムダな作業を極力減は必須とも言えるでしょうらし空いた時間で人間の能力を最大限に活用できるようにすることが求められます ITSS+ アジャイル領域へのスキル変革の指針 30 All Rights Reserved Copyright IPA 2018

32 アジャイル開発の概念整理技術の尊重アジャイル開発の活動を支える柱大原則として人間中心と技術の尊重をあげることができます技術力をもって生産性と品質信頼性を担保するとともに常に適切な技術とスキルを学習しそれを社会に還元し次人間中心世代に継承する努力を怠らず学習する組織社会をす目人間中心は従来の顧客起点ではなく社会を構成する一人一人顧客だけなく経営者も従業員もの生きる意味を考えることが社会の価値につながるということを示していますまた提供する人間の能力を最大限に活かすことが重要です個人個人の能力が社会の中で創造的かつ健全に開花し多様なチーム組織コミュニティに価値を提供しその中で指すことも重要です技術活用はプログラミング的思考よい技術よい設計によりよい品質を追求することできるだけ自動化し人の無用な負担を排除することなどが該当します人間中心と技術活用のバランスが重要生きがいを持って協働できる働きやすい社会を目指すことが人間中心と技術活用という２本の柱のバランスが重要です重要です ITはそれをエンパワーするものであるべきです２本の柱でイノベーティブな社会変革を人間中心で仮説設定検証を繰り返しながら進めていきます特に技術中心で考えてきた日本の企業に対して人間中心なイノベーションを個人組織に植えつけることが必要です本質を理解せずに形だけ真似しても成果は創出することはできません ITSS+ アジャイル領域へのスキル変革の指針 31 All Rights Reserved Copyright IPA 2018

33 アジャイル開発の概念整理継続的な改善成長を目指すマインドセットあるべき姿にむけて改善しつづける人材に決められたプロセスに沿って作業を進めることも重要ですがアジャイル開発は一度やり方を決めたらそのままやり続けるアジャイル開発では状況の変化に応じてプロセスも柔軟に変ことを善しとするものではありませんアジャイル開発では常に更して対応することが求められます同じやり方を続けていてあるべき姿にむけて改善し続けるにはどうしたらよいかを考えまはそこに改善や成長は生まれませんたとえ期待した効果がす例えば過去の技術が足かせにならないように常に技得られなかったとしてもその経験から学べることもあります早術動向を追い続けソフトウェアの提供をより早く行うためにはく実践あるいは失敗すればその分早く改善することもでどうしたらよいかを常に考え続けますアジャイル開発の実践のきますまた改善は開発プロセスに限った話ではありませんア場は継続的に改善しつづける人材になるための学びの場とジャイル開発では自分自身も常に成長を求め続けるマインもいえますドセットを持つことが重要です ITSS+ アジャイル領域へのスキル変革の指針 32 All Rights Reserved Copyright IPA 2018

アジャイル開発の概念整理これまでの説明を総合してアジャイル開発全体の概念構造をアジャイル開発の家として表現してみました家をモチーフにアジャイル開発の目指すもの屋根梁開発活動を支える大原則柱土台そして目的を達成するための活動家の中を表していますアジャイル開発とは何かを整理する上での参考としてくださいアジャイル開発とはビジネス価値の最大化に向けて顧客に価値のある

顧客からのフィードバックにより継続的に改善する人間中心活動を支える原則柱/土台人間中心設計とモジュール化実働検証アーキテクチャ顧客との協調持続可能な社会/ 組織/働き方チームワーク人間中心持続可能な社会/組織/働き方チームワーク技術の尊重プログラミング思考価値の継続的デリバリーのためのツールと自動化理論と実践継続的改善活動(家の中)

34 アジャイル開発の概念整理これまでの説明を総合してアジャイル開発全体の概念構造をアジャイル開発の家として表現してみました家をモチーフにアジャイル開発の目指すもの屋根梁開発活動を支える大原則柱土台そして目的を達成するための活動家の中を表していますアジャイル開発とは何かを整理する上での参考としてくださいアジャイル開発とはビジネス価値の最大化に向けて顧客に価値のあるソフトウェアを早く継続的に提供するためのアプローチですビジネス価値の最大化顧客満足の向上変化への対応活動の目的屋根梁現場現物現実ビジネス価値の最大化を実現するため顧客満足の向上何に価値があるかを見極めること変化への対応素早く提供しつづけることを意識する役に立つ動くソフトウェア現場現物現実で実際に役に立つ動くソフトウェアを提供し顧客からのフィードバックにより継続的に改善する人間中心活動を支える原則柱/土台人間中心設計とモジュール化実働検証アーキテクチャ顧客との協調持続可能な社会/ 組織/働き方チームワーク人間中心持続可能な社会/組織/働き方チームワーク技術の尊重プログラミング思考価値の継続的デリバリーのためのツールと自動化理論と実践継続的改善活動(家の中) ビジネス価値の最大化を実現するための活動高速仮説検証サイクル実働検証と継続的改善顧客との協調個人とチームの尊重人間中心設計とモジュール化アーキテクチャ技術の尊重と継承プログラミング的高速仮説検証サイクル個人とチームの尊重アジャイルを推進する組織文化技術の尊重技術の尊重と継承思考価値の継続的デリバリーのためのツールと自動化理論と実践アジャイルを推進する組織文化アジャイル開発の全体像 ITSS+ アジャイル領域へのスキル変革の指針 33 All Rights Reserved Copyright IPA 2018

スクラムと監査についての一考システム監査人協会近畿支部近藤博則

スクラムと監査についての一考システム監査人協会近畿支部近藤博則スクラムと監査についての一考システム監査人協会近畿支部近藤博則自己紹介近藤博則 ( こんどうひろのり ) 昭和 54 年 11 月 4 日生まれ平成 27 年システム監査技術者試験合格関西支部報告 2 本支部メルマガ巻頭言寄稿など支部活動に参加アンケートスクラムを知っていますか? スクラムを使ったとがありますか? スクラムを監査した事がありますか? スクラムが生まれた背景ビジネスの不果実性の増大