Agile Japan 2018 エンタープライズ企業におけるアジャイル開発 … ·...

©Tokyo Electric Power Company Holdings, Inc. All Rights Reserved.

東京電力ホールディングス株式会社

田中勧（TANAKA Susumu）

小室毅司（KOMURO Takeshi）

株式会社テプコシステムズ

田中啓史（TANAKA Keishi）

Agile Japan 2018エンタープライズ企業におけるアジャイル開発の取組み

WF文化の企業でSoRにアジャイルを導入してみて起きたこと。


自己紹介

田中勧（たなかすすむ）東京電力ホールディングス(株)

経営企画ユニットシステム統括室情報保証室室長

経歴

入社後5年間、柏崎刈羽原子力発電所で機械設備の保全を担当

情報システム部門へ異動後、主に発電部門向け情報システムの企画、パッケージソフトウェアの導入を担当

2017年から現職

事例紹介するプロジェクトには2015から2年間関与。

2


助っ人

田中啓史（たなかけいし）(株)テプコシステムズ発電設備システム部

発電設備システムグループマネージャ

主に原子力向けシステム開発を担当

事例紹介するプロジェクトのリーダー

小室毅司（こむろたけし）東京電力ホールディングス(株)

原子力・立地本部原子力システム担当

入社後、原子炉の炉心設計を担当

現在は原子力部門のシステムの統括を担当

3


電力事業の変化と東京電力グループの取り組み

4


東京電力グループ概要

5

2016年にHD制へ移行

システム部門はガバナンス機能を残して再配置【企画・開発】各事業会社【技術統制・支援】テプコシステムズ

情報子会社


電気事業のビジネスモデル変化

6

Utility 1.0 : 垂直統合型（電気事業の誕生と急激な発展）

De-carbonization 脱炭素化Decentralization 分散化（分散化電源）Depopulation 人口減少Digitalization デジタル化

Utility 3.0 : 他産業・事業との融合（Game Change）

Utility 2.0 : 送配電事業の分離（発電・小売の競争）

Deregulation 自由化

電力業界のメガトレンド “5D”


デジタル化への挑戦

7

ITシステム OTシステム

電力業務

カイゼン

デジタル化

新ビジネスの創造生産性倍増


Open

パートナーとの連携外部知の活用

Co-creation

共創User eXperience

Speed

Fail First, Fail often.

多くのアイディアを高速で検証

基本的アプローチ

8

新ビジネスの創造生産性倍増


デザイン思考と高速PoC

9

1,000アイディア創造

100短期検証

2~3

サービス化0~1

ビジネス化

仮説高速PoCデザイン思考

プロトタイプ

評価


インキュベーションセンター(6月22日開設)

10

ワンストップ

アイディア創出短期開発（PoC）

事業化/業務適用

アジャイル開発ハッカソン・共同検証

デザインシンキングアイデアの具体化

顧客の要望反映継続的なカイゼン


東京電力グループの設備量と顧客数

11

燃料調達発電流通小売お客さま

2,700万個スマートメータ

600万本電柱

50,000基送電線支持物

57ユニット火力発電所

11ユニット原子力発電所

164箇所水力発電所

1,600箇所変電所

6万契約大口

9,000億円資材調達

34,000人社員数

15,000km送電線亘長

60万件太陽光契約数

需要データ(5分・30分値)

2,700万契約一般家庭

顧客属性

家電情報燃料価格

２LNG基地

３貯炭場


福島第一原子力発電所

12


福島第一原子力発電所事故

13

事故時の運転状況

建物の水素爆発

溶けた燃料の有無

1号機運転中爆発あり溶けた燃料あり

2号機運転中爆発なし溶けた燃料あり

3号機運転中爆発あり溶けた燃料あり

4号機運転中爆発あり溶けた燃料なし

5号機停止中爆発なし溶けた燃料なし

6号機停止中爆発なし溶けた燃料なし


福島第一原子力発電所廃炉作業ロードマップ

14

30年～40年の長期的なプロジェクトとなりますが、安全を最優先にしながら、全力で取り組みます。

第1期第2期(10年以内) 第3期(30～40年後)

2018.7現在


福島第一原子力発電所の今設備の状況

15


福島第一原子力発電所の今作業環境

16

事故当時、福島第一原子力発電所ではすべてのエリアで全面マスクと防護服を着用しての厳しい環境下で作業していました。

現在は様々な取り組みにより、ほとんどのエリアにおいて、簡易マスクと一般の作業服で作業できるようになりました。


アジャイル開発の事例紹介原子力入構者管理システムの開発

2011～2017

17


システム概要（レガシー）

目的：原子力発電所の放射線管理に関する業務の支援

人：人の被ばく量管理業務

作業：作業の放射線管理業務

場：管理区域立入許可業務

システムの特色

1997年リリースしたホストシステム（COBOL 100万step）

作業現場に合わせて24時間365日稼働

個人情報を扱う

複数の制御・計測装置との連係

関係法令が多く、業務毎に担当部門が異なる（3部門＋α）

18


発電所の外発電所敷地建物放射線管理区域

Why Agile?

20

発電所では「ヒトの出入り」と「ヒトの放射線被ばく量」の管理が必要

作業員の安全確保が最優先。法令や業務設計と並行して、早急なシステム対応が必要！！

法令に準じた「ヒトの出入」「被ばく量」をシステムで管理

法令や業務の前提が崩れ、これまでのシステムでは管理が行えなくなった。

事故

事故により漏えい

アジャイル開発を採用


プロジェクトのヒストリー

21

フェーズ１

Microsoft Accessで

最低限の管理機能を提供。

2011.3▼

Ph5

2011.4

▼

2011.8▼

2016.1

▼

2012.10

▼

2011.11

運用開始▼

Microsoft Access

データセンター設置

2017.6

▼

フェーズ３

本格的なシステムの構築。

Microsoft Accessでの運用が限界を迎えてきたため、アジャイルで構築開始。初回リリースは3ヶ月後。

フェーズ4

APD(警報付ポケット線量計)システムとの連係、官公庁への報告機能等の実装。

フェーズ5

ホストレガシーとの統合

（ホスト脱却）

柏崎刈羽、福島第二で稼働中のホストシステムが保守期限を迎えるため、本システムに統合。

Ph4Ph3Ph2Ph1

②プロジェクト停滞時期

フェーズ2

Jヴィレッジ(作業拠点)での管理機能追加。

①アジャイル導入時期

東日本

大震災

2015年頃

③ホストレガシー統合


①アジャイル導入時期アジャイル開発の事例紹介

原子力入構者管理システムの開発

22

2011.3▼

Ph5

2011.4

▼

2011.8▼

2016.1

▼

2012.10

▼

2011.11

運用開始▼

Microsoft Access


2017.6

▼

Ph4Ph3Ph2Ph1東日本

大震災

2015年頃


業務精通し意思決定が行えるPOの確保事故対応で業務部門の要員が割けない中、業務とシステムに精通する

メンバーがシステム部門に（たまたま）居た。


23

Mr.K

なぜWF文化の会社でアジャイルが導入できたのか？

非常事態と二つの偶然「風土・文化」「ヒト」

非常事態（風土と文化）震災直後、非常事態のため「やれることは何でもやる」（普段では内部調整に時間を要し、挫折しかねない。）

高いスキルと意欲を持ったチームの確保TEPSYS内で高いプログラミングスキルと新技術へのチャレンジ指向のある

リーダー・チーム、現行システムを熟知した要員を確保できた。



裏を返せば

非常事態と二つの偶然がなければ

アジャイルの導入はなかった

かも

24


②プロジェクトの停滞と解決アジャイル開発の事例紹介


25

2011.3▼

Ph5

2011.4

▼

2011.8▼

2016.1

▼

2012.10

▼

2011.11

運用開始▼

Microsoft Access


2017.6

▼


大震災

2015年頃


②プロジェクト発足から3年、内外の変化

プロジェクト「内」の状況・変化

苦労しながらもプロジェクトは順調に進捗

システム・プロジェクト規模が拡大

要件の複雑化とステークホルダーの増加

プロジェクト「外」の状況・変化

システム統制部門、業務部門の非常態勢が沈静化

各部門、プロジェクトへ関心を向ける余裕がでてきた

26


業務部門C業務部門C

業務部門B業務部門B

業務部門A業務部門A

セキュリティ部門セキュリティ部門

システム統制部門システム統制部門

②プロジェクトの停滞

何時完成するの？

まだアジャイル続けるの？

制御システムと連係危ないよ！

使い勝手良くして！

法律変わるから仕様が変わるよ！

何でウチの要件優先しないの？

27

プロダクトオーナー

PO

スクラムマスター

SM

チーム

TEAM

Mr.K

投資対効果は？

規制からOK出てるの？

データの補正お願い！

この前頼んだ改良速くやって！

専門用語分からん

技術標準に乗れよ保守大丈夫？

社外団体から頼まれて

連係システムが遅れて


②プロジェクトの停滞解消

28

プロダクトオーナー

PO

スクラムマスター

SM

チーム

TEAM

Mr.K

業務部門A

業務部門B

業務部門C

セキュリティ部門

システム統制部門POに業務部門から

代表者招聘

代表部門を設定調整・最終判断者に

各業務部門長でステアリングチームを構成

PO内ファシリテートとステアリングとの調整

バックログとチームを目的別に分割


③フェーズ5 ホストレガシー統合アジャイル開発の事例紹介


29

2011.3▼

Ph5

2011.4

▼

2011.8▼

2016.1

▼

2012.10

▼

2011.11

運用開始▼

Microsoft Access


2017.6

▼


大震災

2015年頃


③フェーズ５レガシー統合要件

1997年リリースしたホストシステム

（COBOL 100万step）の機能移行、データ移行

作業現場に合わせて24時間365日稼働

（止められない）のデータ移行、切り替え

ホストの保守期限切れが迫っており、

デリバリ制約はマスト（約1.5年）

30

要件・仕様が明確なので普通ならウォーターフォールで進めたい案件


③フェーズ５ Why Agile？

32

アジャイル継続

パフォーマンス

リスクコストホスト脱却スケジュールの厳守確実なデータ移行

アジャイルに慣れたチームの維持（士気・パフォーマンス）ホストレガシー統合中も割り込み要件に対応する体制

リスク対策を検討

WF/アジャイルコスト比較


フェーズ５（ここからTEPSYSが請負います）

33

Mr. K

Scram Master（４代目）

Hey氏

ということで引き続きフェーズ5も

アジャイルでよろしく！

おまかせください♪

汗💦Hey氏紹介

㈱テプコシステムズ在籍第4代目スクラムマスター(2014.4～現在）

2011年開発当初はプロダクトオーナー側でアジャイル経験を積んだ猛者である。4代目スクラムマスター襲名後は当システムの品質向上、品質保証に取り組み、アジャイルガイドラインを策定する。


100万Step360機能！

プロダクトオーナ3部門を相手に仕様決まるかな

フェーズ５もアジャイル？

34

1年半で！

品質保証どうしよ

大勢集めてできるの？

期限絶対！

リビジョン管理どうする？

途中で割り込み改良入るの！？

移行データ20年分！切り替え

一発！

Scram MasterHey氏



フェーズ5はアジャイルに不向き！？

1. 大規模である

2. 初めに全体のスコープが決まっている

3. 期限が決まっている

4. 改良ベースである ← アジャイルは新規開発のほうが望ましい

↑ フェーズ４までのソフトウェア資産流用を前提にした予算と工期

フェーズ5はアジャイル向き！？

1. 途中で緊急性の高いスコープ外の改良の見込み

2. 早めに利用したい機能がある

35

大変だけどアジャイルでやる・・・決め手は…


プロジェクトの思い

アジャイルに慣れたチームの維持（士気・パフォーマンス）


36

発注側からも受注側からも「大事にしたいもの」が

ありました


フェーズ５（お伝えしたいこと）

37

大規模アジャイル

改良

開発工程の工夫

開発体制の工夫

プロジェクト

運営の工夫開発手法の

工夫


フェーズ５（開発工程の工夫）

38

Scram MasterHey氏

スプリントに分けないとな

インクリメンタル（段階的開発）的なやつ？

スコープは決まっているし

仕様決定って遅れるものだし

割り込み改良入ると…


654321

３ヶ月 4ヶ月 4ヶ月 4ヶ月 2ヶ月 2ヶ月

スプリントバックログ

テスト・移行中心エントリ系機能

連けい機能報告系機能

マスター系

プロダクトバックログ優先度案件規模

1 機能１ 5

2 機能２ 5

3 機能３ 5

4 機能４ 1

・

・

361 機能 361 4

1. 優先度を決めて案件を６スプリントに振り分け

最後はテスト中心に全体品質を担保

2. 契約はスプリント単位で請負

全体の完成義務は発注側に

瑕疵責任は受注側に

リリースにより途中で業務利用も可能

契約は見直しを反映しながら順次

契契契契契契

要件定義フェーズ

リリース


39



40

Scram MasterHey氏

さらにスプリント分けないとな


2w

sp1 sp2

2w 2w

sp3 sp4

2w 2w

sp5 sp6

2w

sp7

2w

sp8(ラストsp)

2w

コード開発

テスト実施仕様確認テスト計画

移行計画

1. １スプリント内を２週間の小スプリント(sp)に分割

3

4ヶ月

契


契


41


案件内容と課題の状況確認

1. １スプリント内を２週間の小スプリント(sp)に分割

スプリントレビューにてスプリントバックログの達成状況を確認

最後のスプリントレビューにてＰＯ上位マネジメントが完成を判断

2. 並行して次スプリントの方針検討

早めに準備、プロダクトオーナと課題共有（遅延リスクの軽減）

コード開発

テスト実施仕様確認

次スプリント方針検討（課題抽出）

テスト計画

移行計画


2w

契

2w 2w 2w 2w 2w 2w 2w

スプリントレビュー








仕様決定テスト・移行方針合意業務適用判断

sp1 sp2 sp3 sp4 sp5 sp6 sp7 sp8(ラストsp)


42



43

Scram MasterHey氏

仕様決定って遅れるものだし

期限までに決まらなかったら…

割り込み改良が入ると…

計画も契約も変更しないと！


後回し後回し

計画外案件のスコープイン

案件の規模拡大

前倒し




契契契

1. プロダクトバックログ内案件の入れ替えルールを定める

案件規模の増減に応じ、要員稼働率を平準化するために実施

入れ替えはスプリントレビューで承認

2. 計画外案件（予算外）は厳格に対応要員リソースが急増しないよう計画案件の規模縮小や後回しにす

る等の調整を行う

プロダクトオーナ上位マネジメントの承認が必要

案件の中止・縮小

※契約書記載事項にかかわる変更は契約変更を実施


44


フェーズ５（開発体制の工夫）

45

Scram MasterHey氏

40人くらい必要かな

プロダクトオーナ３部門と合意していかないと


プロジェクトルーム

1. プロダクトオーナ（３部門）ごとに開発チームを編成

2. 全体の整合性を統括する体制（ＰＯ間の利害競合を解消）

3. 大部屋、会議もオープンコーナ

ＰＯ-Ａ２名

ＰＯ-Ｂ３名

ＰＯ-Ｃ２名

開発チームＡ

８名

開発チームＢ

１２名

開発チームＣ

６名

仕様総括２名

インフラチーム

移行チーム

会議エリア

会話の内容が全員に聞こえるので業務課題も開発課題も、速やかに議論ができる。

1チーム10名までが目安

フェーズ５（開発体制の工夫）

46


フェーズ５（プロジェクト運営の工夫）

47

Scram MasterHey氏

ここまでくれば普通にスクラムで

行けそう…


1. スプリント計画バックログからタスクを抽出しスケジュールとメンバを割り当てる。

タスクやリソース配分は他チームの意見も取り入れ作成していく。

案件の内容により開発チーム編成を変える。

テスト体制は他チームも含めて混成編成とする。

2. タスクボード、スクラムミーティングタスクの状況、直面している課題を各自がホワイトボードに書く

スクラムミーティング（毎朝３０分）は持ち回りの司会進行で冒頭に小話（５分スピーチ）ホワイトボードの内容を共有していく➡相互理解がアップし、協力関係も生まれた

3. 振り返り１リリース完了後に開催

よかったこと、できなかったこと、これからの目標を共有しあう

※基本的にスクラムフレームワークに準拠し実践しました

フェーズ５（プロジェクト運営の工夫）

48



改良

フェーズ５（開発手法の工夫）

49

Scram MasterHey氏

「開発」じゃなくて「改良」なんだよね

既存プログラムにかなり手を入れそう

まずは規模や改変度について実績値をご覧ください

ここからソフトウェアエンジニアリング上の工夫になります



参考：開発前後データモデル比較（実績値）

50

フェーズ５

２９９テーブル３６５テーブル

Ｐｈ４完了Ｐｈ５完了

内訳テーブル追加：１２５テーブル削除：５７テーブル変更：２４０

計：４２２

既存データモデルに大きな変更が必要でした

66テーブル追加22%割増し



参考：開発前後規模比較（実績値）

51

FP

34万ステップ

フェーズ５

FP 175%

47万ステップ（138%）

Ｐｈ４完了Ｐｈ５完了

100万ステップ

１３万ステップ増

規模の割にステップが増えていませんもともとステップ/FP値も小さいです

（理由はこのあとで）



改良


52

Scram MasterHey氏

データモデルもプログラムも

再構築・再構成・再テストそして毎度のリリースと不幸なバグ対応；；

そんな不毛な作業を気持ちよく楽しく進めるための３つの工夫を紹介します


簡単理解Ｍ

ＱＣＤＳ


53

単純構造

共同所有

otivation

atisfaction


フェーズ５（開発手法の工夫１）

54

ソフトウェアメトリクスが小さな

プログラムを書きます。

モジュール数（クラス数）

インタフェイス数（関数および引数）

分岐数（エラー処理の if 文）

定義数（xmlファイル）

単純構造化のためにはソフトウェアメトリクスが小さくなるようなアーキテクチャやフレームワークを採用、あるいは設計＆コーディング上の工夫を行います。

※具体的な方策については長くなるので割愛します。工夫の一部に Convention Over Configuration 思想を採用しています。

単純構造


★プログラムが身軽になると、

書く人の動きもよくなります。

改修時の影響範囲が小さく（工数⇩）テストケース数が少なく（工数⇩）変化への対応の柔軟性（やる気⇧）リファクタリング（やる気⇧）

フェーズ５（開発手法の工夫１）

55

プログラムの構造＝詳細設計書の記述粒度になることが理想です

単純構造

34万ステップ

47万ステップ

工夫済み工夫済み

100万ステップ

大改修でしたが気持ちよくできました


フェーズ５（開発手法の工夫２）

56

日本語でプログラムを書きます。

Map dMap = (HashMap)dto.getObject(Const.DTO_KEY_INFO);Map bMap = (HashMap)dMap.get(Const.MAP_KEY_BASICINFO);List aList = (List) dMap.get(Const.MAP_KEY_ATTACH_LIST);for (Iterator it = aList.iterator(); it.hasNext();) {

HashMap aMap = (HashMap) it.next();if (Const.ATTACH_OPERATE_INFO_ADD.equals(

(String)aMap.get(Const.MAP_KEY_TEMPU_JOHO))) {FileManage fm = new FileManage(getModuleLogger());String fileId = (String) aMap.get("HKEI_DOC_FIL_ID");String fileNm = (String) aMap.get("HKEI_DOC_FIL_NM");fileId = fm.storeManagementFile(dto, fileId,

SystemConst.FUNC_KBN_SCRAM_MASTER,(String) bMap.get(Const.MAP_KEY_PLANET), fileNm,

FileManage.FIL_KAR);if (fileId != null) {

aMap.put("HKEI_DOC_FIL_ID", fileId);}

public void on検索ボタンClick(){入力チェック年月日妥当("I.作業開始日");入力チェック年月日妥当("I.作業終了日");if(入力エラーがある()) {

return;}ＤＢロード検索結果一覧(承認待ちデータ取得SQL);

}

簡単理解


フェーズ５（開発手法の工夫２）

57

日本語でプログラムを書きます。変数名、関数名、クラス名、ファイル名

HTMLリソース（タグのname属性等）

テーブル名、項目名

簡単理解

★ドキュメントの簡略化が可能になります。

★「単純構造」と組み合わせることにより設計者もコードを読めます。苦痛ではなくなります。

理想は・・・です。プログラムの言語＝詳細設計書の言語プログラムの構造＝詳細設計書の記述粒度

例：on登録Click(), get社員情報(社員番号)String 企業名称, ログイン画面.java


フェーズ５（開発手法の工夫３）

個人が自由に気軽に無申請で正本登録（コミット）します。

他者のソースも修正します。ペアプログラミング時、レビューコメントをコード上に直接記載時、後追い共通化、類似不具合箇所修正時など

共同所有

自分の修正分を登録(コミット)

正本ソースコードリポジトリ

個人の開発環境（ＰＣ）個人の開発環境（ＰＣ）個人の開発環境（ＰＣ）個人の開発環境

（ＰＣ）デバッグ

数回/日/人

※フェーズ５実績コミット回数：14010回／385日（稼働日）≒36回

コミュニケーション協調、協力共同所有状態

ほぼリアルタイム共有状態

互いの開発活動が見えてくる

58

他者の修正分を取込み



59

みんなでソースを見る会コードをプロジェクタで投影

コードに対して意見交換

わかりにくい、他と違う、混乱を招く名前付けしている、効率が悪い、無駄な処理をしている、使用方法を間違っている、共通化すべき、共通を使用すべき、類似の処理があるので真似るべき、など

全員が耳を立てて聞いている

共同所有

★気づきが水平展開されます。★コードの良し悪し（価値観）が共有されます。★ばらつきがなくなり、品質が平準化されます。



60

共同所有

テスト実施

１ヶ月

リリース

テスト開始時に起こりがちな問題は日々の活動で解消されていきます。

環境定義、設定ミス

インタフェイス齟齬ダメソース書き直し対応性能改善

正本ソースコードリポジトリ

個人の開発環境（ＰＣ）



個人の開発環境（ＰＣ）デバッグ

数回/日/人

…日々の開発作業を続けていくと…

★大規模でも計画通りに完了できました

遅延リスク

ソースを共有し、結合状態でデバッグすることで開発側都合の遅延リスクを軽減できます。


フェーズ５（お伝えしたかったこと）

61

Scram MasterHey氏


改良

開発工程の工夫

開発体制の工夫

プロジェクト

運営の工夫開発手法の

工夫

うまくいったぜ♪


まとめ

62


振り返り

ガチガチのWF文化な我が社でも、

SoRにアジャイル導入して成功した

ファクト

フェーズ5は、計画したQCDを達成

開発生産性は社内平均より高い

業務部門の満足度が高い

63


振り返り

気づき

大規模プロジェクトのリスクヘッジ手法としても機能した

要件（やること）定義、プロジェクト計画はWF以上に重要

課題

開発手法、プロダクトオーナーなど、やや属人的

契約の整理が必要

今後の展開

他プロジェクトへの水平展開

手法の標準化、人財の育成など、属人的要素排除

規模の拡大

40人/月以上のプロジェクトへの適用

64

Agile Japan 2018 エンタープライズ企業におけるアジャイル開発 … ·...

Documents

Transcript of Agile Japan 2018 エンタープライズ企業におけるアジャイル開発 … ·...