ITサービスのQCDを考えるソフトウエアエンジニアリング講座

Size: px

Start display at page:

Download "ITサービスのQCDを考えるソフトウエアエンジニアリング講座"

ふみなふくだ
5 years ago
Views:

1 第 26 期 ITソリューション塾特別講座ソフトウエアエンジニアリング講座 Agile and DevOps デジタルトランスフォーメーション平成 29 年 11 月 29 日戸田孝一郎株式会社戦略スタッフサービス社団法人 TMS&TPS 検定協会理事 Copyrights 2015 SSS Corporation 1

2 デジタルトランスフォーメーションとは? IT の浸透が人々の生活をあらゆる面でより良い方向に変化させるという概念既存ビジネスをアナログからデジタルへデジタルからアナログへとシームレスに変換できる組織への変革全ての企業は IT を中心とした組織に変わる全ての組織が IT サービスプロバイダーに変質するという事 IT( 情報技術 ) が一般化すると優位性はデータを保有する側に移る

3 デジタルフォーメーションの型 Speed 機敏性を重視 ( トヨタ型 ) ビジネスプロセスのスピードを上げて競争力を生むビジネス戦略イノベーションを重視 ( アップル型 ) 今まで世の中にないイノベーティブな商品 / サービスを作り競争力を生むビジネス戦略あらゆるモノをサービス化スピードとイノベーションの複合 ( アマゾン型 ) 究極のデジタル化で上記二種の要素を複合してあらゆる製品サービスを組み合わせられるサービスを作り出して圧倒的な競争力を生むビジネス戦略

4 VeriSM とは? Digital Transformation の時代全ての組織がサービスプロバイダー化する可能性があるどの様に IT サービスを提供し維持するのか? VeriSM とは組織が持っている固有の環境を前提にしたサービスマネジメントからのアプローチ基本的価値観 Value-driven ( 価値主導 ) Evolving( 発展展開する ) Responsive( 敏感に反応する ) Integrated( 統合結合された ) Service( サービス ) Management( マネジメント )

5 対象は経営者管理者 ( 事業部 &IT) サービスオーナーサービスマスター IT 専門職 (DevOps チーム ) 活動 IFDC (International Foundation for Digital Competences) プラクティスの本発行

6 VeriSM の基本概念ガバナンス ( 企業統治 ) サービスマネジメント指針顧客 ( 消費者 ) の要望定義制作提供顧客 ( 消費者 ) の反応マネジメントメッシュ敏感に反応

7 DevOps = Development + Operation Copyrights 2015 SSS Corporation 7

Development + Operation の造語 DevOps とは 2009 年に Velocity 2009 においてのエンジニアにより初めて公の場で用いられたこのプレゼンテーションでは開発と運用が協力することで 1 日に 10 回以上のペースでリリースが可能になる

サプライチェーン全体に適用される ALM( アプリケーションライフサイクル ) の視点での管理プロセスビジネスプロセスとしての側面開発側 DevOps とは人文化 DevOps is not Tool, DevOps is People, People use Tool.

8 Development + Operation の造語 DevOps とは 2009 年に Velocity 2009 においてのエンジニアにより初めて公の場で用いられたこのプレゼンテーションでは開発と運用が協力することで 1 日に 10 回以上のペースでリリースが可能になるという発表とともに DevOps という単語が用いられた IT コンサルタントのパトリックデュボア氏は開発と運用を結び付ける手段として DevOps を提唱し 2009 年に最初の DevOps カンファレンス DevOpsDays を開催しているアジャイルとリーンの原則がソフトウエアサプライチェーン全体に適用される ALM( アプリケーションライフサイクル ) の視点での管理プロセスビジネスプロセスとしての側面開発側 DevOps とは人文化 DevOps is not Tool, DevOps is People, People use Tool. (Carnegie Mellon SEI) JIT での IT サービスの提供運用側企業におけるITの価値の本質に立ち返る活動 ITの価値の本質 = ビジネスをタイムリーに支援するビジネススピードを牽引するビジネス領域を拡大させる見えなかったモノを見える様にする Copyrights 2015 SSS Corporation 8

9 Copyrights 2015 SSS Corporation 9

10 ITIL V1. (1986 年 ~) ITIL V2. (2000 年 ~) ITIL V3. (2007 年 ~) バッチプロセスから一個流しプロセスへ運用系でもアジャイル &DevOps ITILの進化プロセス化 : ITサービスの利用と提供のガイドライン業務中心 : 単体業務からプロセス ( プラクティス ) で体系化と業務の均一化 1プロセスアプローチとベストプラクティス 2IT 技術とビジネス視点で 7つの領域に整理してサポート ( 青本 ) とデリバリー ( 赤本 ) を定義 : オープン化への対応とビジネスの継続性 (BCP) 重視 1ビジネスとITの統合ビジネス価値を意識 2バリューネットワークの概念を導入ビジネス視点を原則としALMの実践 DevOps( アジャイル開発 ) ⅰ アプリケーション開発 ( 調達 ) 要件定義設計構築 ⅱ サービスマネジメント展開運用最適化自動化 ⅲ アプリケーションポートフォリオ 3SMO(Service Management Office) 2011 版で追加プロセスの成熟度を上げる目的プロセスの構築とプロセスの成熟度を上げる活動を明確に分ける (CMMI で言う PMO と同様 ) Copyrights 2015 SSS Corporation 10

11 DevOps の最終的なゴールビジネス目標の達成 ( 売上利益 ) 顧客への価値を創造し続ける価値あるITサービスを提供し続ける ITサービスのサプライチェーンの構築現行の縦割りプロセスの改善 : ゴールの共有企画部門のゴールビジネス目標サービス戦略投資効果開発部門のゴール品質 (Q) コスト (C) 納期 (D) 運用部門のゴール安定稼動継続性運用コスト縦割りの企業情報システム & IT プロセスの仕組み 11

12 Process エンタープライズ DevOps 概念図計画要求設計開発移行運用 E O L VeriSM Project Charter SIAM Require ment Definitio n User Story SLA SDP SAC ACDM Test Story Scrum Continuous Delivery SLA SDP SAC Operation Story LW- ITSM 手法 P D M 見える化されたプロジェクト管理 (TPS での大部屋方式 ) 計画から運用までの全体最適による整流化されたプロセスの構築トヨタの TPS の様な一個流しによるマイクロサービスの提供クラウド環境 (Docker) Dev. Environment Test Env. Transition Run Environment ALM (Application Lifecycle Management) MSDPM:Micro-Services Delivery Process Management Copyrights 2015 SSS Corporation 道具立て 12

13 サービスバックログサービスマスターイテレーションプロセスマスター大部屋バリューストリームマップ見える化ボード類 DevOps2.0 概念図サービスバックログタスクボードサービスバックログタスクボードタスクボードタスクボードスクラムチームアジャイルチーム ( スクラム ) アジャイルチーム ( スクラム ) アジャイルチーム ( スクラム ) アジャイルチーム ( スクラム ) デプロイメントバックログタスクボード一個流しのフローデプロイメントパイプライン DevOps エンジニアオペレーションバックログリライアビリティーエンジニアタスクボードゲートキーパー運用運用チーム週日単位タスクボードアジャイルチーム ( スクラム ) 計画から運用までの全体最適による流水化されたプロセスの構築 13

14 DevOps のプロセス ( 模式図 ) 開発チームビルド管理 A プロジェクト B プロジェクトパイプラインテスト受入稼働 C プロジェクト D プロジェクト 14

15 デプロイメントパイプラインの概略フロービジネス戦略企画 IT サービス状況 ( コストも含む ) PBL IT サービス仕様 + コスト + EOL サービスマスター PBL item SBL タスクコード開発プロセスマスターリライアビリティエンジニア開発チーム単体テスト仕様コミットステージ自動テスト仕様テストストーリー手動テスト仕様 TPI Next 運用ストーリーキャパシティテスト仕様受け入れ手動テスキャパシティテストトテストステージステージステージ NG NG NG NG 稼働状況ゲートキーパー本番決定本番運用運用チーム DevOps エンジニアデプロイメントパイプライン開発時フィードバック単位目標タスク単位 PBL item 単位 IT サービス単位開発構築リリース前稼働状況軽量化した IT サービスマネジメント PBL : Product Back Log SBL : Splint Back Log 15

16 MRI(Minimum Required Information) を決める事が大事各作業現場では正しく作業を行うためにそれなりの情報が創出されている 16

17 DevOps2.0 の事例 2009 年アジャイル開発を開始 2011 年秋アジャイル開発は成功裏に導入できたが課題噴出 : 開発工程はボトルネックでは無かった 2012 年 4 月ビジネスプロセスの全工程の見直しと整流化のプロジェクト開始 2013 年 10 月 DevOps の導入 ( 全プロセスの見える化同期化と大部屋化実現 ) 事業規模が 2 年で 3 倍以上非製造業で初の大部屋の実現バリューストリームマップ xx 事業部ビジネスプロセスプロセスの同期化 ( 管理サイクル ) とタスク粒度の均一化一週間一時間企画営業管理デザイン開発移行運用コールセンタービジュアルボード 17

18 アジャイル開発 Copyrights 2015 SSS Corporation 18

19 Waterfall Development IT システムの開発手法ソフトウエアを作成することが目的評価は計画通りに完成する事 19 世紀のフレデリックテイラー (IE の創始者 ) の科学的管理法が基本思想 Agile Development IT サービスを実装し提供することが目的評価はビジネスの成果フェレデリックテイラーの考え方に疑問? を唱える (Kent Beck) 問題となる三つの単純化された仮定 1 通常物事は計画通りに進む 2 局所最適は全体最適に繋がる 3 人はほぼ代替可能であり何をすべきかを指示する必要がある

20 ウォーターフォール型開発要求仕様設計開発手法の違い ( 概要 ) コーディングユニットテストシステム統合納期水が流れ落ちる様にプロジェクトのプロセスのステップを順を追って作業を進めていく方法プロセスの各ステップで必要な全ての作業が完了しなければ次のステップに移行しない同類同質な作業を貯めてまとめて行う最終的にリリースは一回で実行される時間経過 ( 月 ) 運用保守反復 1 アジャイル型開発リリース 2 反復 2 反復 3 反復 4 リリース 2 反復 1 反復 2 反復 3 期間を決めてその期間内で小さな稼働可能な部分のリリースを小まめに実施しフィードバックを得て修正を加えつつユーザーの望むシステムを完成させる方法反復 4 リリース 2 反復 1 反復 2 反復 3 反復 4 各反復期間内では開発チームによって設計コーディング単体テスト結合テストが実施され常に稼働可能な状態で段階的にリリースを繰り返す 20

21 価値観スピード働き方時間の使い方計画プロジェクトリスク役割進捗管理見える化評価基準要求設計開発コード品質ドキュメントデプロイ & リリース運用運用管理リーダーシップ何を変えるべきか? ウォーターフォールを中心とした従来の方式計画重視遅い仕事はまとめた方が効率が良い残業を認める仕事の目的を達するまでの時間計画重視全期間にわたる計画立案 ( 計画通りにコトは運ぶ ) しっかりと計画を立て理論的に進めるプロジェクト後半に増大専門家 ( 分業化 ) 管理指標作業が終わらないと見えない計画に対して管理可能 100% 定義可能機能中心設計基本は個人 ( 専門家 ) 属人化する管理強化 ( 当たり前品質 ) 多種多様管理基準半自動分権独立 ITIL 統率型 ( 指示 & 命令 ) アジャイル DevOps の新しい方式リソース重視適応性重視早い仕事は一つづつこなした方が効率が良い残業を認めない ( 定時間労働 ) 区切られた時間内で仕事の目的を達成タイムボックス計画作り重視 ( 朝令暮改 ) 当面 1 ヶ月は詳細に後は粗い計画 ( 計画通りにはコトは運ばない ) 反復的 ( イタラティブ ) に進めるフィードバックが重要プロジェクト前半に集中多能工化 (T 型人材 )) 現地現物管理 ( 働くプログラムのみ ) ほぼ何時でも見える化 ( 透明性 ) ビジネス価値 ( ビジネスの成果 ) 管理不能定義不能 ( 標的は動く ) プロセス中心設計チームの連帯責任属人性の排除向上可能性あり ( 魅力的品質 ) MRI ( 最低必要限 ) 使用目的の明確化自動化 ( デプロイメントパイプライン ) オペレーションの一体化軽量化した IT サービス管理 &ISO20000 サーバントリーダーシップ ( ファシリテーション )

22 アジャイル開発の仕事の基本構造イテレーション ( スプリント ) 何故反復的に開発を行った方が良いのか? 何故そうしなければならないのか? 従来の考え方課題目標 100 点狙いアジャイルの考え方課題目標フィードバックフィードバックフィードバック 20 点 40 点 60 点合格点狙い 80:20 の法則時間の使い方 ( タイムボックス ) 透明性品質

23 要求の変質要求を明確に定義できれば良いシステムができるという迷信要求の時間的変質 100% 要求の信憑性 75% 50% 平均的な値 24 ヶ月後では 25% 程度 25% 時間経過 ( 月 ) Copyrights 2015 SSS Corporation 23

アジャイル開発の基本行動基本的な価値観 : 与えられたリソース ( 資源 ) の制約下で最大のパフォーマンスを発揮する常にカイゼンを行い作業効率の向上を目指すタイムボックスでの働き方で時間の有効活用反復 ( イタレーション ) を利用してこまめにフィードバックを得て軌道修正を常に行うゴール ( 標的 ) は

24 アジャイル開発の基本行動基本的な価値観 : 与えられたリソース ( 資源 ) の制約下で最大のパフォーマンスを発揮する常にカイゼンを行い作業効率の向上を目指すタイムボックスでの働き方で時間の有効活用反復 ( イタレーション ) を利用してこまめにフィードバックを得て軌道修正を常に行うゴール ( 標的 ) は固定されていない常に動く常に動作するソフトウエアで確認する品質を犠牲にしない品質を高め維持する努力ウォターフォール機能固定項目工期 ( 時間 ) アジャイル工数 ( コスト ) 品質品質? 変動項目工期 ( 時間 ) 工数 ( コスト ) 機能 Copyrights 2015 SSS Corporation 24

25 システム設計方法の変化何故オブジェクト (SOA) を使用しているのに再利用が困難なのか? 再利用されないのか? ソフトウエアの標準部品 ( コンポーネント ) は簡単に設計できるのか? いきなり標準部品 ( コンポーネント ) の設計に入って居ませんか? プロダクトサブシステムサブシステムサブシステムプロセス + ルール機能機能機能機能機能機能機能機能機能業務プロセスで設計するという方法がありますユーザーストーリーボディープロセス (Body): 業種を問わず共通している基本プロセスオルタナティブプロセス (Alternative): 業種特性に影響を受けるプロセスオプションプロセス (Option): 企業の商慣習や慣行に影響を受けるプロセス 2015/11/26 25

26 アジャイル開発におけるソフトウエアの作り方反復 1 反復 2 反復 3 反復 4 Copyrights 2015 SSS Corporation 26

27 アジャイル開発概論高品質でムダの無い且つ変更要求に対応できるソフトウエアを作成する為の適切な一連の手順に従い高い協調と自律的なプロジェクト関係者によって実施される反復 ( 周期 ) 的インクリメンタルなアプローチであるダイナミックシステムズ開発技法 (Dynamic Systems Development Method) デインフォルナー (Dane Faulkner) ほかアダプティブソフトウェア開発 (Adaptive Software Development) ジムハイスミス (Jim Highsmith) クリスタルメソッド (Crystal Methods) アリスターコックバーン (Alistair Cockburn) スクラム (Scrum) ケンシュエイバー (Ken Schwaber) ジェフサザーランド (Jeff Sutherland) XP( エクストリームプログラミング ) ケントベック (Kent Beck) エリックガンマ (Eric Gamma) ほかリーンソフトウェア開発 (Lean Software Development) トムおよびメアリーポッペンディーク (Tom and Mary Poppendieck) フィーチャ駆動開発 (Feature-Driven Development) ピーターコード (Peter Code) ジェフデルーカ (Jeff DeLuca) アジャイル統一プロセス (Agile Unified Process) スコットアンブラー (Scott Ambler) 反復 ( 周期 ) 的 (Iterative) --- 定期的なリリース漸進的 (Incremental) --- 徐々に機能を増加適応主義 (Adaptive) --- 変化に対応 ( 即応 ) 自律的 (Self-Organized) --- 学習する組織多能工 (Cell Production) --- 一人多役 (SE プログラマーテスター ) Copylights@2012 SSS Corporation 27

28 アジャイルマニフェスト 2001 アジャイルソフトウェア開発宣言我々は自らアジャイル開発を実践するとともに人々がアジャイル開発を実践するための支援を通じてより優れたソフトウェア開発方法を見つけようとしているこの活動を通じて我々は人と人同士の相互作用をプロセスやツールよりも動くソフトウェアを包括的なドキュメントよりも顧客との協力を契約交渉よりも変化に対応することを計画に従うことよりも尊重するに至ったこれは右側にある項目の価値を認めつつも左側にある項目の価値をより一層重視するということである Kent Beck James Grenning Robert C.Martin Mike Beedle Jim Highamith Steve Mellor Arie van Bennekum Andrew Hunt Ken Schwaber Alistair Cockburn Rin Jeffries Jeff Sutherland Ward Cunningham Lon Ker Dave Thomas Martin Fowler Brian Marick SSS Corporation 28

29 マニフェストの思想を支える重要な方針 ( アジャイル原理 ) 1. 我々の最優先事項は素早いそして継続的な価値あるソフトウエアの提供を通して顧客の満足を得る事である 2. 開発局面の後半であっても要求の変更を歓迎するアジャイルなプロセスを顧客の競争優位の為の変化に利用する 3. 稼動するソフトウエアをより短かい期間を優先して数週間から数ヶ月で定期的に提供する 4. プロジェクト期間を通して業務ユーザーと開発者は共同して作業をしなければならない 5. やる気のある人々を集めてプロジェクトを組織し彼らが必要とする環境と支援を与え仕事が完了するまで信頼する 6. 開発チーム内あるいは開発チームに対するコミュニケーションで最も効率的かつ効果的な手法はフェイスツーフェイスの会話である 7. ソフトウエアが正常に機能するということが進捗の基本的な評価である 8. アジャイルプロセスは持続可能な開発を促進するスポンサー開発者ユーザーは無期限かつ不断に保守できるようにしなければならない 9. 技術的に優れた良い設計に継続的に配慮する事は機敏性 ( アジリティー ) を増長させる 10. 簡素が基本 - やらない仕事をできるだけ多くする 11. 最良の構想 ( アーキテクチャ ) 要求仕様設計は自己統制された ( 自律的 ) チームより出現する 12. 定期的にチームは振り返りを行いより効果的に出来る方法を思案しそれに基づいてチームの行動に協調と調整が働く Copylights@2012 SSS Corporation 29

30 Copyrights 2015 SSS Corporation 30

スクラムプロセスプロダクトオーナー r ( お客様 ) プロダクトバックログ 1.--------------- 2.--------------- 3.--------------- 4.

---------------- c.---------------- d.---------------- e.---------------- f.

31 スクラムプロセスプロダクトオーナー r ( お客様 ) プロダクトバックログスプリントプランニングパート 1 確実な優先順位付け ( 同位は無し ) 追加修正変更可能 (Sprint に入っている物以外 ) Product Owner が全て責任を持つ e タスクボードパート 2 To Do On Going Done c d b g a f 2 時間 2 時間スクラムマスター ( ファシリテーター ) タスクリスト ( スプリントバックログ ) a b c d e f 週間 4 週間 4 週間 4 週間 4 週間イタレーション 1 イタレーション 2 イタレーション 3 イタレーション 4 イタレーション 5 毎朝 15 分のスタンドアップミーティング納品納品納品納品納品デイリースクラムチーム開発者バーンダウンチャートデザイン開発テストスプリントレビュー 3 時間レトロスペクティブ ( 振り返り ) 3 時間 h スプリント ( 反復期間 ) 1 週間 ~4 週間 Copylights@2012 SSS Corporation 31

32 スクラム (Scrum) Ken Schwaber & Jeff Sutherland (1995 年 ) 特徴軽量理解しやすい ( シンプル ) でも会得するのは難しい三本の柱 Transparency ( 透明性 ) Inspection ( 視察検査 ) Adaptation ( 適応順応改作 ) 基本的考え方タイムボックス (Time Box) 時間を区切ってその時間内に目的を果たす仕事を行う仕事の仕方機能横断的な固定化されたチームチーム内で役割分担を決めず全員が必要な仕事をこなす多能工 (T 型人間のチームでできるだけチームメンバーを固定化した方が良い持続可能なペース徹夜や残業を排除して安定した持続可能な一定のペースで開発し定期的にリリースを行う Copyrights 2015 SSS Corporation 32

33 ( 参考 ) アジャイル開発におけるタイムボックスの価値 = やる気と集中力仕事の量は完成の為に与えられた時間を全て使い切るまで膨張するイギリスの歴史学者経済学者であるパーキンソンの言葉時間には弾力性がある時間は何となく使ったのではいくら有っても足りない同じ仕事量でも意識の違いでかかる時間は全く異なる生産性はやる気と集中力で高まるやる気のホルモン = ドーパミンドーパミンはご褒美によって放出されるやる気はご褒美の事を考えるだけで出るしかし裏切られると一瞬で低下するご褒美の 60 秒ルール = ご褒美は直ぐに貰える事が重要楽しく想像できる事が重要スピードを上げるほど脳は活性化する集中していればミスは少ない時間を計ればムダに気づく事ができる集中力は長く続かない休む事で充電される時間が読めるからリラックスできるやる気と集中力の高め方東京大学医学博士森田敏宏著より抜粋

34 開発チーム自己組織的なチームである自律性メンバーが自ら日々の仕事を管理する自己超越常に目標を達成するように自らを追い込み常に自身のプラクティスを改善する相互交換作用機能横断的かつ定めた役割が無い目標にコミットする義務があるチームはスプリント計画ミーティングでコミットした目標を達成する責任を持つ目標達成につながるならば方法を限定しないチームはすべての決断を下す権限必要なことを何でも行う権限あらゆる障害の除去を依頼する権限を持つ争議はチーム内で解決する作業規約を作る Copyrights 2010 SSS Corporation 34

35 ミッションと責任プロダクトオーナープロダクトの完成図と方向性を示すプロダクトに必要な機能の詳細を決めるリリースの内容と日程を決める市場価値に基づくプロダクトバックロイグの優先順位を決めるスプリント毎に優先順位を変更できる権限を持つプロダクトの収益性 (ROI) の責任を持つプロダクトオーナーが行う事プロダクトのビジョンを作成し関係者に示す ( 共有する ) 対象プロダクトのビジネス要求 ( ビジネス環境 ) の説明エピックユーザーストーリーの確定とペルソナの作成ユーザーストーリー毎の受け入れ基準の承認プロダクトバックログの優先順位付けとプロジェクト期間中の維持管理開発チームへのユーザーストーリーの説明開発チームの DoD( 完了の定義 ) 作成の支援リリース計画の承認稼働環境の定義 EOL( プロダクトの終焉 ) 条件の設定

36 スクラムの管理者 ( スクラムマスターの仕事 ) チームの機能や効率化を支援するチームが最大のパフォーマンスを発揮できる環境を作る ( 妨害からチームを守る ) チームがスクラムプロセス通りに作業を実施できる様に支援するチームに気付きを与えるチームの自律を支援するチームの能力をユーザーに売り込むプロジェクト関係者 ( ステークホルダー ) 間の信頼感を醸成するお客様 ( ユーザー ) 第一の思想ジャストインタイムの徹底カイゼン活動の促進チームのモチベーションの向上 Copyrights 2010 SSS Corporation 36

37 オープンな作業環境スクラムの環境チーム全員のコミュニケーションがとり易く一緒にいる時間が多くなるような環境が良い広い区画の無い共有作業スペースパーティションは人を引き離しチームを分離するペアプログラミングの風景タスクボードビルド用 SSS Corporation 37

38 DoD (Definition of Done) 完了の定義各作業の完了基準閾値 ( 標準値 ) を決める作業経過結果を計測する自工程完結の基本的な姿勢 ( 現場での意思決定 ) 仁 = 他人の努力を無駄にしない思いやり発生防止 X検 X 検 X検 X 査査査査検査検査検査プロセスプロセスプロセス検納入流出防止 DoD

39 継続的インテグレーション ( 常時結合 ) 毎日実施行灯 ( パトライト ) 自動テストテスト正常終了テスト異常発生チーム全員でメンテ実行開発したプログラムを毎日統合して動作確認を行うシステムの進捗を日々の動作機能で測る事が可能開発チーム内での統合動作不良改善を日々行う事が可能自動化ツールを使用して開発チームが休息している間も統合試験が可能品質向上に貢献 10 分間ビルド Copyrights 2015 SSS Corporation 39

40 XP( エクストリームプログラミング ) Kent Beck(1999 年 ) テスト駆動開発 (TDD)=テストファーストプログラミング実装する機能をテストするプログラムを書くコードを書いてテストするデザインを見直す信号が青になるまで2&3を繰り返すリファクタリング完成したコードの見直し ( 実装された機能を変えずにコードをシンプルに見やすくする ) 任意の作業 ( 全員が行う時間が空いたら行う ) ペアプログラミングドライバー ( コードを書く人 ) ナビゲーター ( コードをチェックする人ナビゲーションをする人 ) この役割を 1 日の中でペアの間で途中で交代するペアの組み合わせを毎日替える 10 分間ビルド自動的にシステム全体をビルドして全てのテストを 10 分以内に実行させる ( 理想形 ) Copyrights 2015 SSS Corporation 40

41 テスト駆動開発 (TDD) テスト駆動開発テストの自動化アクセプタンステスト ( 完了終了の定義 ) テストコード小さいテストのコード作成次にソースコードを作成最後にデザインをリファクタリングするこのプロセスを廻すデザイン Copyrights 2015 SSS Corporation 41

42 リファクタリング (Refactoring) 正常に動作確認したプログラムに対して下記目的でソースコードの調整を行う作業プログラムの可読性を高めるクラス化部品化変更容易仕様レベルでの調整使い易さ誤操作抑止仕様変更リファクタリング用 (10%) リファクタリングのルールリファクタリングと機能改変を同時にはおこなわないリファクタリングをしてから新しい機能を追加するリファクタリングを始める前と後にはユニットテストを実行しコードの機能が変更ないかを確認するパフォーマンスよりもメンテナンス性を重視するこだわり過ぎてはいけない小さなリファクタリングとテストの組み合わせを繰り返す決して一度に大きなリファクタリングをしない大きなリファクタリングは惨事のもとである ~Kent Beck Copyrights 2015 SSS Corporation 42

43 ペアプログラミング (Pair programming) 二人で一台の端末に向かってプログラム製造を実施する毎日違ったペア緊張感の維持この瞬間にこの作業しか出来ない!! 役割を一時間前後で交代作業者とチェッカー曖昧な作業が無くなる手戻りの軽減品質の向上動けば良いと言うような安易なプログラム製造ではない可読性の高いコード頭脳労働のムダとり一人で考え込む時間が無くなるドライバーナビゲーターペアの交替 ( 定期的 : 毎日 ) 作業の交替 ( 一定時間毎 ) : ドライバーとナビゲーター静かなペアプロは機能してない Copyrights 2015 SSS Corporation 43

44 品質について考える当り前品質魅力的品質顕在品質潜在品質リリース 1ヶ月イタレーション ( スプリント ) 1 週間スタンドアップミーティング 1 日常時結合 5~8 時間ユニットテスト 2~3 時間バグフリーアジャイルプラクティスの徹底 ( 守 ) 頻繁なフィードバックループの設計メンテの容易性ソースコード = ドキュメントメソッド名と変数名 ( 名は体を表す ) 簡易に書けるセカンドランゲージ ( 自分のツール作成 ) ペアプログラミング秒 / 分 Copyrights 2015 SSS Corporation 44

45 アジャイル開発で品質が向上する理由ムダ取りの原則作業にムラがあるからムリをするようになるムリな作業をした結果ムダが生じるムラを防止するのは一定の作業リズム ( タクトタイム = タイムボックス ) タスクの粒度を小さくする作業手順 ( 工程設計 ) を考えなければタスクは小さくできないタスクが小さくなればミスを容易に発見できる手戻りも小さいタスクを小さくするとムダが見えてくる正味 ( 本来の価値を作り込む ) 作業付帯 ( 事前事後の ) 作業ムダな作業タスクを小さくすることで整流化が容易になる ( ボトルネックの解消 : 一個流し生産 ) 全員での作業で透明性が高まる一人で抱え込む仕事がなくなる事前に他人の目が届く ( チェック ) トヨタ生産方式 (TPS) の自働化の思想をプロセスに組み込める不良作業をしない不良品を流さない不良品を受け取らない ( 自工程完結 ) 不良が起こったらラインストップをして関係者全員が異常に気づく ( 見える化 ) 作業者 ( 開発者 ) に直接フィードバックする仕組みが構築できる擦り合わせをしながら作業が進む Copyrights 2015 SSS Corporation 45

46 タスクの粒度タスクの粒度を小さくすることは TPS における小ロット化と同様流れを作り負荷を平準化し柔軟性を高める Application size, Test Cases, and Test Coverage. Logical source code statements By Caper Jones Statements of Source code Test Cases Test Coverage % % % タスクの粒度は小さいほど良い 1 日以内理想は 1 時間責任を持って見積ができるバグを作り込まない ( 簡単にテスト可能 ) 他のペアと同期がとれるダイナミックなプロジェクト運営が可能となる ( チーム編成の増減分散開発など ) タスクが小さくできないのは作業対象の内容把握に問題が存在するのではないか? タスクを小さく分割するという事は作業指示書を作成する事 1, % 10, % 100,000 4, % 1,000,000 50, % 10,000, , % Copyrights 2015 SSS Corporation 46

47 タスクを小さく ( 粒度 ) する例えばレポートを作る業務 ( 仕事 ) をタスク分解する 1. レポートの主旨を確認しレポートのストーリーを練る 30 分 2. レポートの章立てを決める 10 分 3. 各章の基本を決める ( 文章図グラフデータイラスト等 ) 30 分 4. 文章の下書きをする 30 分 5. 図やグラフを作成するためのデータを決めデータを収集する 30 分 6. PCを立ち上げ EXCEL PowerPointを起動する 5 分 7. データをEXCELに入力する ( データをインポートする ) 20 分 8. グラフを作成する 10 分 9. 文章を構成し PowerPointに入力する ( コピーする ) 30 分 10. PowerPointのレイアウトを決め文章図グラフイラストを配置する 5 分 11. 4~10を必要ページ分繰り返す 12. レポート全体を通して確認する ( 校正する ) 30 分 13. 作成日作成者名レポートの題名を記入し完成させる 5 分 14. レポートを提出する 5 分 240 分 (4 時間 ) Copyrights 2015 SSS Corporation 47

48 55.5 時間

49 経験事例の報告 ( エンジニアの声 ) エンジニアAさん : アジャイル初体験ウォーターフォール開発経験約 15 年 ( 主任クラス )37 才 > 情報処理技術者 1 種 > UMTP L1 > 業務 SE( 物流 / 生産管理 / 公共サービス ) 8 年 > ホスト汎用機テクニカルSE 7 年 > 今回.NETは初めての経験 > JAVA(web) 3 年 > PL/SQL 2 年 > VB.NET (2 週間 : 本アジャイル開発で初 ) > COBOL C++ etc( 細かい開発は多数 ) アジャイル開発の効果 : コーディングの生産性は変わらないが開発作業内で手戻りが無く結果的に早く完了できる体験した感想 : とにかく頭が疲れる集中する品質が高くなる技術的な問題や方式で悩む時間が少ないので効率は良い気を抜く暇がないので稼働率は高い二人でやっているので生産性は倍まではいかないただし品質が高いので改修やテスト時の修正工数は少なくなるペアプロ / クロスファンクションによりソースコードレベルで情報を共有するため自然に可読性 / ロジックのシンプルさが感じられる実装となる随時に動かしながら機能拡張をするため潜在バグ / デグレードのリスクは低い実装が不慣れな要員がいてもペアの組み合わせにより品質の高い実装が可能となる作業の完了が視覚的に理解できる実装の成果がすぐに見れるスタンドアップミーティング / 振り返り / タスクの割り振りによりメンバー全員が全体の作業を見渡せる司会を持ち回りすることにより参加意識が強調される人に見られているのに適当な ( 動けばいい ) コーディングはできない悩んでいる時間が少ない ( 随時相談 / 調査 ) 具体的な目標を随時持つことができるタスク担当を明確にすることにより責任範囲の当事者意識を持つことができる Copyrights 2015 SSS Corporation 49

50 経験事例の報告 ( エンジニアの声 ) エンジニア B さん : アジャイル初体験ウォーターフォール開発経験約 5 年 28 才 > Oracle Master Bronze 10g > VB.NET:1 年 > HTML JavaScript CSS など Web 関係 :1 年 ( 随時 ) > PHP:1 年 > VB6:3 年 > PL/SQL:1 年 > XML:1 ヶ月アジャイル開発の効果 : 生産性が上がった ( 体感 ) 体験した感想 : 個人のコミュニケーション能力が高く問われる二人で作業を行っているため単純ミスも少なく精度が高い思った以上に疲れる気を抜く暇がないエンジニアCさん : アジャイル初体験ウォーターフォール開発経験約 4 年 27 才 > 初級アドミニストレータ > 詳細設計 PG / テスト ( 物流 / 在庫管理 /Web) 4 年 >VB.2 年 > JAVA(web) 3 年 > PL/SQL 三ヶ月アジャイル感想 : 一人で開発をしている時は技術的にわからないことがあるとネットや本等で調べて解決し作業を進めていくがペアプロの場合横で他の人が見ているので気軽に調べ物がしにくい ( まだメンバーに慣れていないため気軽に質問ができない ) 仕様をよく知っている人とペアを組むとプログラミングの道筋を立てて開発ができるので良いと思う反対にある程度わかっている人が作業を行いほとんどわかっていない人が横で見ている場合作業者はどこまで説明しながら進めればいいのかわからないペアプロだと常に他の人と一緒に開発を行うので緊張感が保てるその反面気を抜くことができないので一人で作業をするよりもかなり疲労度が高いタスク毎に見積もり時間を出して作業を行うこととプログラム 1 本の見積もり時間しか出ていない状態で作業を行うことと比べるとタスク毎の方が作業を進めやすい ( プログラム 1 本の見積もりの場合ペース配分が上手くいかないことがある ) ウォーターフォール型の開発に慣れているので要件定義からいきなりプログラミングに入ることにまだ戸惑いを感じる外部設計書内部設計書があった方が開発がしやすいペアプロに慣れてきたので作業進捗が早くなってきた常に隣に他人がいる環境でずっと開発を行うのは疲労度が高く辛い時もある

51 日経コンピュータ連載コラム総合タイトル : 前編現場を元気にするチーム運営術年 4 月 13 日元気が無い現場に四つのサインあいさつが元気を取り戻す第一歩年 4 月 27 日コミュニケーションが取れない組織他人をどれだけ知っているのか年 5 月 11 日残業が減らない組織属人的な仕事を無くしているか年 5 月 25 日多忙で夏休みを取れない職場改善活動の停滞乗り越え取得率向上年 6 月 8 日助け合いの無いシステム部門心のマネジメントが改善のカギ年 6 月 22 日アジャイル開発でチームを元気に初挑戦でも成功カギは見える化年 7 月 6 日発注者の信頼をどう得るのかアジャイル開発成功のカギ年 7 月 20 日チームの透明性はアナログで高める自らを律するのが成功の秘訣年 8 月 3 日暗すぎるウォーターフォールの現場やる気引き出す心のマネジメントを年 8 月 17 日進捗が90% から先に進まない 1 時間の作業に分割しているか総合タイトル : 後編現場を元気にする DevOps 年 9 月 14 日今こそ大量生産時代の常識に決別トヨタ由来の方法論で元気になろう年 9 月 28 日自ら改善を続けるチームに変える働き方改革への第一歩年 10 月 12 日人を大切にするのが強い企業仕事のやり方を変えて近づこう年 10 月 26 日サイロ現場を3 段階で変革個別最適では幸せにはなれない年 11 月 9 日アジャイル開発の品質向上策 7つの視点で作業の様子を観察年 11 月 23 日伝達ゲームは開発失敗の元凶業務プロセスの観点を貫こう 51

52 もの作りもの作りとシステム作りの相違品質とコストの設計検証製品企画機能検討 (VE) 製品設計生技検討 ( 生産設計 ) 工程設計試作量産製造品質検査 ( テスト ) 出荷 / 納品設計製造テスト / 納品システム開発 VE の視点が必要ではないでしょうか? この生産技術に関する作業無しで高品質のシステムが確実に製造できるでしょうか? システム企画要求定義システム設計 DB 設計??? コーディング単体テストシステムテストドキュメンテーション納品設計仕様を図面上のみの検討で十分でしょうか? 擦り合わせ微調整が必要ではありませんか?( 誰が何時どの様に作業できますか?) Copyrights 2015 SSS Corporation 52

<4D F736F F F696E74202D208A4A94AD82C6895E977082F082C282C882AE B8DC C E >

<4D F736F F F696E74202D208A4A94AD82C6895E977082F082C282C882AE B8DC C E > 開発と運用をつなぐアジャイル最新トレンド ~ アジャイルを誤解していませんか? ~ 会社紹介会社名本社設立資本金代表者事業内容株式会社テクノロジックアート (Technologic Arts Incorporated) 東京都文京区小石川 1-28-3 NIS 小石川ビル 2 階 1989 年 12 月 5 日 39,980,000 円代表取締役長瀬嘉秀コンサルティング ( アジャイル開発

ITサービスのQCDを考える ソフトウエアエンジニアリング講座

ITサービスのQCDを考えるソフトウエアエンジニアリング講座