日本のシステム開発とDevOpsテクノロジ

ＪＥＩＴＡソフトウェアエンジニアリング技術
ワークショップ２０１３

日本のシステム開発とＤｅｖＯｐｓテクノロジ
２０１３年１２月１９日
株式会社ＮＴＴデータ
丹羽隆

Copyright © 2013 NTT DATA Corporation

アジェンダ

背景
日本のシステム開発とＤｅｖＯｐｓテクノロジの関係
ケーススタディ
今後の方向性


1

背景

クラウドやＤｅｖＯｐｓ、といった新しめの技術について、
「業界の古参」として何か語ってほしい、とのお話をいただきました。
今回は、それらの技術がトラディショナルな「日本のシステム開発（ＳＩ）」
に及ぼす影響をお話してみます。


2

ＤｅｖＯｐｓおさらい

「ＤｅｖＯｐｓ」は「アジャイル」と強く関係
速くアプリケーションを作ることはできるようになった（アジャイル方法論）
次は、速く本番環境で動く状態にしたい（ＤｅｖＯｐｓ）

品質確認
回帰テスト

開発

(C)Rajiv.Pant 2012 on Wikipedia


ここは速くなった

ＱＡ

本番環境移行
インストール

運用

ここが次のボトルネック
3

余談：ＮＴＴデータとアジャイル

ＮＴＴデータだってアジャイル頑張ってます！


4

ＤｅｖＯｐｓのキーテクノロジ
自動ビルド・デプロイ（Ｊｅｎｋｉｎｓ, ｇｒａｄｌｅ等）自動プロビジョニング（Ｃｈｅｆ, Ｐｕｐｐｅｔ等）

自動テスト（Ｓｅｌｅｎｕｉｍ等）


クラウド（仮想化、インフラのＳｏｆｔｗａｒｅ化）

5

日本のシステム開発とＤｅｖＯｐｓ

前置き
今日の話の中では、
日本のシステム開発＝ウォーターフォールで作られた企業の基幹系システム
くらいの感覚で捉えてください

本題
アジャイルやってないシステム開発は、ＤｅｖＯｐｓとはあまり関係ない？
もしかして、日本のシステム開発は、ＤｅｖＯｐｓとはあまり関係ない？

そんなことはありません

6

世の中的な動向：スピードへの要求は高まる
２０１６年までに、ＤｅｖＯｐｓは、大規模クラウド・プロバイダーが採用するニッチな戦略
から、Ｇｌｏｂａｌ２０００企業の２５％が採用する主流の戦略へと進化する。
出典：ガートナー「ITサービス提供の迅速化に向けたDevOpsのベスト・プラクティス」 2013年9月

◆基幹系システムもスピードが重要に
・携帯キャリアが、他社の新料金プランに追随するには？
・損保会社が、他社の新型特約に追随するには？
⇒フロント系システムの変更だけでは対応できない
特にＢ２Ｃ企業のコアビジネス直結システムのスピードアップはクリティカルに

◆基幹系システムに依存した難しさも
・単純に「品質より速度優先で」とは言ってもらえない
・お金に直結することが多く、誤りは許容されいくい
⇒日本のシステム品質のよいところを残したスピードアップが大事に

7

ＮＴＴデータ社内の動向：実際にスピードアップの要求は来てる？
◆「リリースの迅速化」は、ＮＴＴデータ内でも課題になっているか？
・５件の社内ヒアリングを実施 ⇒ １００％のプロジェクトでＹＥＳ
・現状のスピード感で満足しているお客様はほとんどいない
◆ただし、厳しい「コストダウン圧力」についても、１００％のプロジェクトでＹＥＳ
・大きな費用をかけずに、スピードは上げてほしいと思っている

「スピード＝価値」を説明して、必要な費用をどういただくかはＳＩｅｒの課題だが
とにかく、スピードアップを実現できる状況にしないと！


8

ところで、ウォーターフォールとＤｅｖＯｐｓは相容れるの？
実は、日本のシステム開発でも、維持・機能追加フェーズはウォーターフォールではない
リリース

要件定義
設計
製造

新規開発

テスト
リリース前手続き

リリース
リリース待ち

機能追加#1
バグ改修#2

維持・機能追加

機能追加#3
バグ改修#4
機能追加#5
機能追加#6

リリース待ちのコードは多く存在している ⇒ アジャイル／ＤｅｖＯｐｓの課題と類似

9

こんな感じに変えられるとうれしいのでは
リリース#1
リリース#1
機能追加#1
バグ改修#2
機能追加#3
バグ改修#4
機能追加#5
バグ改修#6

リリースタイミング
増やす

期間あたりの案件を
増やす

リリース前手続きを
短くする

（6ヶ月毎→3ヶ月毎とか）

（10件/月→15件/月とか）

（３週間→１週間とか）

リリース#1
リリース#1
機能追加#1

機能追加#5

バグ改修#2

バグ改修#6

機能追加#3

機能追加#7

バグ改修#4

バグ改修#8
リ前手続


リリース#2
リリース#2

リ前手続

10

何がボトルネックなのか？

◆テスト環境
・人数に比べて、環境数は不足気味
・環境利用調整による待ち・環境設定変更の待ち
機能追加#1

テスト環境は
プロジェクト全体の
共有リソース

バグ改修#2
機能追加#3

チームＡ

・資材リリースの待ち

バグ改修#4
機能追加#5
機能追加#6

テスト環境
テスト環境

機能追加#7
バグ改修#8

チームＢ

機能追加#9
バグ改修#10
機能追加#11
機能追加#12


11

何がボトルネックなのか？

◆回帰テスト
・プログラムの規模が大きい・品質への妥協はできない ⇒ 回帰テストの量も多い
・人手によるテスト作業
リリース
機能追加#1
バグ改修#2
機能追加#3
バグ改修#4
機能追加#5
機能追加#6

テスト量をさばくために
人手と期間が必要

12

ＤｅｖＯｐｓテクノロジ活用のケーススタディ①

◆テスト面の徹底拡大～クラウド（ＩａａＳ）活用～
クラウドを利用し、テスト環境を何面も用意し、作業並行性を向上
人・チームが何重も並行で開発を進められる
ソース
リポジトリ

クラウド（IaaS）
環境①
Web/AP バッチAP

DB

帳票

ジョブ管理

ルータ

CI・Build
自動チェックアウト
・ビルド・デプロイ

環境②
Web/AP バッチAP

DB

帳票

ジョブ管理

ルータ

CI・Build

クローン＋
プロビジョニング

環境③
Web/AP バッチAP

DB

帳票

ジョブ管理

ルータ

CI・Build

Web/AP バッチAP

DB

帳票

ジョブ管理

ルータ

CI・Build

環境④

13

ＤｅｖＯｐｓテクノロジ活用のケーススタディ②

◆ビルド・デプロイの徹底自動化～Ｊｅｎｋｉｎｓの活用～
ある時間がきたら、テスト環境のＡＰが最新版に更新される仕組み
１日あたり環境２０面×５回の更新を実施


14

ＤｅｖＯｐｓテクノロジ活用のケーススタディ③

◆回帰テストの徹底自動化～Ｓｅｌｅｎｉｕｍの活用～
ブラウザバリエーションテストをＪｅｎｋｉｎｓ＋Ｓｅｌｅｎｉｕｍで自動化


15

ケーススタディから考える日本のシステム開発でのＤｅｖＯｐｓ技術活用
◆日本のシステム開発の特徴
①プログラム規模が大きい ②人・チームが多い ③基幹システムは品質も大事
◆ケーススタディから考えるＤｅｖＯｐｓ技術活用
クラウドによるテスト環境数拡大は効果的
それに、自動プロビジョニング × 自動ビルド・デプロイ × 自動テスト
を組み合わせて、リリーススピードを上げることができそう
運用（本番環境移行など）に関わるＤｅｖＯｐｓ技術活用例はまだ多くなさそう
（日単位、週単位のリリースまではまだ求められないため？）
開発

ＱＡ

ここのスピードをＤｅｖＯｐｓ
技術で上げられそう

運用

こちらはもう少し後かな？
16

日本のシステム開発でのＤｅｖＯｐｓテクノロジ利用イメージ

A開発者
SCM/変更管理
B開発者
C開発者

D開発者

バイナリ
リポジトリ

プッシュ/
プル

FeedBack

デプロイ

自動テスト
デプロイ

ビルド
サーバ

Aテスト環境
A自動テスト
Bテスト環境
Cテスト環境 C自動テスト
Dテスト環境

商用環境
お客様
ユーザ

自動プロビジョニ
ング

自動ビルド
デプロイ
デプロイ
クラウド基盤


17

課題になりそうなこと
① 回帰テスト自動化は失敗例も多い
ＱＡ専門チームを立てているところが少なく、定着しづらい背景も
⇒プロセス、ツール、体制の再検討が必要では
粒度（ショートシナリオｏｒロングシナリオ)
範囲（手動テスト範囲をどこまで自動化するか）
量（テストスクリプトをメンテナンス可能な量に）
人（スキル人材の確保と維持）
② 構成管理の複雑化
作業並列性の向上 × テスト環境の多面化 × テストリリース頻度の向上
⇒ブランチ・マージの複雑さが従来より増す可能性あり
管理ルール（緩くても人が間違いにくいルールに）
管理ツール（ブランチ・マージが容易なツールへの乗り換えも）


18

最後に「ＤｅｖＯｐｓのもう少し先」
Ｄｅｖ＋Ｏｐｓではなく、Ｂｉｚ＋Ｄｅｖ＋Ｏｐｓなのでは？
ＮＴＴデータには、３ＤＶａｌｕｅＣｙｃｌｅという概念があります

ＤｅｖＯｐｓは
この部分


Ｏｐｓ→Ｂｉｚとの
リンクが次の課題
かも！
19

日本のシステム開発とDevOpsテクノロジ

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a 日本のシステム開発とDevOpsテクノロジ

Semelhante a 日本のシステム開発とDevOpsテクノロジ (20)

Último

Último (8)

日本のシステム開発とDevOpsテクノロジ