necにおけるアジャイル開発の位置づけと取り組み ·...

NECにおけるアジャイル開発の位置づけと取り組み

情報処理学会第79回全国大会イベント企画日本の実情にマッチしたアジャイル開発に向けて

2017年3月17日日本電気株式会社ソフトウェアエンジニアリング本部⻑岩崎新一

目次

n はじめに

n アジャイル開発⽅法論：

NECアジャイル

n SI・サービスフレームワークとの関係：

アジャイル開発 in DevOps

n 現状の課題と今後の展望

はじめに

5 © NEC Corporation 2017

NECにおけるアジャイル開発対応概要

▌10年前頃から危機感を持ち、調査（動向、コミュニティ、事例、ツール）/準備（ガイド、教育）を推進

▌製品開発を中心に経験値を増やし、ガイドをブラッシュアップ

↓

昨今のビジネス/技術環境変化に対応し、更に強化中


アジャイル開発に対する取り組み変遷

アジャイル開発の推進を⾏うも、ビジネス的盛り上がりはなく活動は限定的

世界的にアジャイル開発が普及している状況に危機感

「NECアジャイル」としてツールや⽅法論の整備・⼈材の育成を⾏い、アジャイル開発の備えを整える

製品開発を中心にプラクティスを積み、ノウハウ蓄積＆技術トレンド/事業環境変化の中で重要性アップ

⇒ アジャイル開発をフレームワークの中核へ

2000年代中〜下旬

2010年

2013年

～

～

現在


本日のご紹介内容

アジャイル開発の推進を⾏うも、ビジネス的盛り上がりはなく活動は限定的

世界的にアジャイル開発が普及している状況に危機感

「NECアジャイル」としてツールや⽅法論の整備・⼈材の育成を⾏い、アジャイル開発の備えを整える

製品開発を中心にプラクティスを積み、ノウハウ蓄積＆技術トレンド/事業環境変化の中で重要性アップ⇒ アジャイル開発をSIのフレームワークの中核へ

2000年代中〜下旬

2010年

2013年

～

～

現在

① NECアジャイルアジャイルの特徴を活かし、品質を担保するための手法。ガイドを2011年に社内公開して活用中。

② SI・サービスフレームワーク（SS-FW）SIを⾏うための技術、ノウハウ、ツールを体系化。従来のSoRに加え、SoE領域に拡張。

アジャイル開発⽅法論：NECアジャイル


アジャイルへの期待

お客様がアジャイル開発を希望している

品質が確保できる

仕様書が不要

コストが安い

早く出荷できる

効果の出そうなツール、プラクティスが揃っている

残業が減る

何時でもリリースできる

変化に俊敏に対応できる

アジャイル開発は銀の弾丸？


わかってきた現実

開発が軌道に乗るまでに時間がかかる

形骸化しやすい

バグが多い

開発ツールがうまく使えない

生産性が低い

品質の状況を説明できない

お客様/オーナーが疲弊する

何時でもリリースできるわけではない

仕様が不明になる

アジャイルにも問題は多い


独⾃⽅法論開発のモチベーション

アジャイル開発の有益なプラクティスを活用したい

＋既存の品質管理技術との整合を取りたい

＝NECアジャイル


NECアジャイル概要▌スクラムを中核にＸＰのプラクティスを追加▌NECが⻑年培ってきたソフトウェア品質会計＊のエッセンスを追加して品質を確保

＊ソフトウェア品質会計：NEC独自のソフトウェア品質管理手法

各種条件要員のアサイン条件、等

XP

• ペアワーク• ソースコードの共同

所有• 継続的インテグレー

ション

…

Scrum• 要件管理：

プロダクトバックログ• イテレーション管理：

スプリント• プロセス改善の仕組み：

ふりかえり• 役割定義：

P.O./S.M./チーム…

ソフトウェア品質会計

• バグ予測• バグ傾向分析• バグ分析と１＋ｎ施策• バグ収束判定

…


ソフトウェア品質会計：Software Quality Accounting とは

▌「品質」が作り込まれたことを、確かな根拠をもって説明するソフトウェア品質管理手法l1982年頃、基本ソフトウェアの開発現場で考案されたNEC独⾃の品質管理⼿法l“account”とは、もともと「理由・根拠を説明する」という意味を持つlバグ件数を主要メトリクスとして⽬標管理

▌品質会計を特徴づける技法lレビューでの早期バグ摘出：バグを摘出⼯程と作り込み⼯程の両⾯から管理l確実なテスト完了判断：バグ傾向分析、バグ分析と1+ｎ施策、バグ収束判定の3点を満

⾜したとき完了

▌品質会計の適用範囲l設計〜テストの計画駆動型プロセスに適用可能lソフトウェア領域（エンタプライズ、組込み等）には依存しない

▌専用の管理システムによるサポートlソフトウェア開発に特化したデータ管理；変更履歴を全て保持するなど


設計・製造レビューおよびテスト

ソフトウェア

バグ

作り込まれる

ソフトウェア

バグ

摘出する

バグ

「品質会計」の語源▌設計・製造で作り込まれたバグを、借⾦とみなす▌借⾦は、利⼦が膨らまないうちに、レビューやテストによって返済する

（バグがバグを生まないうちに、レビューやテストによって摘出する）▌すべての借⾦を返済したとき、そのソフトウェアを出荷する

（すべてのバグを摘出したとき、そのソフトウェアを出荷する）


NECアジャイル3つのフェーズ（⽴ち上げ、基本サイクル、出荷判定）で構成3つのフェーズ（⽴ち上げ、基本サイクル、出荷判定）で構成

出荷判定

出荷判定

立ち上げ

リリース計画

準備スプリント

開発スプリント



リリーススプリント

立ち上げ基本サイクル出荷判定

• スプリントは原則2週間• 基本サイクルは8週間※出荷が不要であれば、基本サイクルを繰り返す


出荷判定

• ペアワークとレビュー• テスト⾃動化+継続的インテグレーション• 設計メモのみ ⇒ 設計仕様書作成へ変更

• 役割の決定• マイルストーンを共有

• 要件を整理• 開発ルールの整備• 大まかなスケジュールの検討

• 基本設計およびアーキテクチャの検討

• 開発環境のセットアップ• 規約の作成

• システムテスト• 仕様書作成• テスト完了判断

・出荷判定基準に基づく出荷判定

NECアジャイルの全体像

※各スプリント終了時のスプリントレビューでは、ふりかえりを実施

立ち上げ

リリース計画

準備スプリント




リリーススプリント


ここまでのまとめ▌NECアジャイルは、フレームワーク化により、高いプロジェクト成功率を確保l効果確認済プラクティスの組み合わせを必須化し、基本サイクルでしくみ化l「アジャイル的」（いきあたりばったり、なんちゃってアジャイル）は失敗する

▌品質確保の本質は、開発モデルに依らないl早期に品質を作り込むl問題が残存していないことを確認するlしくみで品質を保証する

▌開発対象、ビジネス特性によっては更なる⼯夫が必要l [現状] 月単位リリース ⇒ [将来] 週単位リリースを実現lサイクルタイムが「日、時」レベルのリリースは別な考えも必要lスケールアップは、ウォーターフォールモデル併用で実現

SI・サービスフレームワーク（SS-FW）との関係：アジャイル開発 in DevOps


NECにおけるSI・サービス事業のためのフレームワーク

SS-FW(全体)：SI･サービスを⾏う際に参照するべき全ての活動を網羅SS-FW(コア)：SWエンジニアリング施策としての中核SS-FW(全体)：SI･サービスを⾏う際に参照するべき全ての活動を網羅SS-FW(コア)：SWエンジニアリング施策としての中核

SS-FW(全体)

SS-FW(コア)＝SWエンジニアリング施策

<ITを規定>ツール/開発環境/

実⾏環境

<手順/成果物を規定>標準プロセス/

開発⽅法論

<対象/構造を規定>アーキテクチャ/

APフレームワーク

<Output/Outcomeの評価指標を規定>開発・運用メトリクス / ビジネスメトリクス

リスク・コンプライアンス

開発支援活動

リソース強化(

育成、調達)

要員教育

パートナー戦略

資格制度

モニタリングとフィードバック

状況把握

監査

アセット活用現場革新/品質保証/プロセス改善セキュア開発

各種遵法ガイド、規定全社規定（契約関連、開発/管理標準）


アジャイル開発できるシステム

提供機能（提供サービス）

システム仕様（非機能要件含む）

納期（リリース時期）

自らコントロールできる

対象が明確で確定しているならば計画的に開発した⽅が効率的⇒ ウォーターフォール開発が優位


アジャイル開発するべきシステム ≠ アジャイル開発できるシステム

どう作ればいいのか分からない/知らない

今はとりあえずこうするが、後で変更するかもしれない（多分変更する）

突然、事情が変わり変更が必要となる

SoE（System of Engagement）

売上、アクセス、CSなどに関わるシステム群

Web販売、SNS、ゲームなど

SoR（System of Record）

従来的企業情報システム群会計、経理、⼈事、⽣産管理など

*SoE,SoR: Geoffrey Moore, Systems of Engagement and The Furute of Enterprise IT, 2011

アジャイルするべきアジャイルできる


SoEの実現に必要な要素としてのアジャイル開発

ビジネス成功のためにフィードバックを受け、改善を続けるようなトータルな施策が必要

⇒ DevOps

アジャイル開発のプラクティスはSoE領域のシステムに有益

だが、これだけで良いのか？


タイプ別のプロセスのパターンSoE型の開発プロセスにおいてはソリューション（SL）企画と

俊敏な開発、運用を含めた高速開発が必要となるSoE型の開発プロセスにおいてはソリューション（SL）企画と

俊敏な開発、運用を含めた高速開発が必要となる

SL企画開発運用ウォーターフォール

SoR型プロセス

SoE型プロセス・SL企画・アジャイル開発・DevOps

SL企画（UX、リーン・ス

タートアップ）

開発アジャイル開発

マネージドサービス

…SoR型プロセス…SoE型プロセス

…繰り返し

凡例

PoC

NECアジャイル

開発と運用の融合＝DevOpsプロセス

ビジネスコンサル、企画・営業の活動


DevOpsプロセス全体イメージ不確実性の高いビジネスゴールに対して、仮説検証を⾏うための⽅法論開発結果を実ビジネスで検証し、フィードバックループを高速に回す不確実性の高いビジネスゴールに対して、仮説検証を⾏うための⽅法論開発結果を実ビジネスで検証し、フィードバックループを高速に回す

• プロビジョニング・デプロイ

• コンテナ管理

ソリューション企画

（ＵＸ・リーン）

中小規模案件

ウォーターフォール開発大規模案件

• ビルド• 静的テスト• 動的テスト• 非機能テスト

CI

CD

運用（ITIL)

Dev

Ops 運用メトリクスのチェック

運用メトリクスのチェック

⾃動化を指向⇒ノンプロセス化⾃動化を指向⇒ノンプロセス化

モニタリング

ビジネスメトリクスのチェック

ビジネスメトリクスのチェック

契約

要修正判断

契約

要修正判断

契約

要修正判断

契約

要修正判断

契約

アジャイル開発アジャイル開発アジャイル開発

アジャイル開発システム企画

要件定義

⽅式設計

契約

クラウド、PaaS選定などクラウド、PaaS選定など

相互に関連

相互に関連

契約


DevOpsでアジャイル開発が機能するための要件

開発規模も極めて重要；検証しきれない⇒ モジュール化が不適切だと更に深刻

中・大規模開発

要件コントロール

不可

分散開発

アジャイル開発の理想条件

小規模開発

要件コントロール

可能

１つのＰＪルーム

国内SIにおける開発状況

GAP

必須

10KL未満


（補足）対象システムの規模/構造とアジャイル開発是非

テスト必要部分

変更部分

凡例

カプセル化されていれば大規模システムでもコンポーネント

単位でアジャイル開発できる

スパゲッティ構造のシステムは修正量が少なくても評価⼯数が膨大で迅

速なリリースは不可能


アジャイル開発を実現するためには

アジャイル開発プラクティス

開発プロセス

テストの⾃動化⇒ CI/CD

開発環境

必要

小規模・疎結合⇒ マイクロサービス化

アーキテクチャ

必要


(補足) マイクロサービスアーキテクチャ（MSA）

▌小規模/軽量なサービスを複数連携させることで業務システムを構築する設計⼿法

▌成功しているWebシステムの特徴を分析し整理したもの▌I/FはRESTful API、Dockerによるコンテナー仮想化とセット

DockerDockerDocker Docker

Docker

HW

OS

Docker Docker

ＭＳ

コンテナー仮想化

プラットフォーム

マイクロサービス（MS）化された

サービス

Docker

ＭＳ

ＭＳＭＳＭＳ

ＭＳ

サービス

サービス

REST

REST

REST

業務APのサービス全体スケールアウト単位

MS化による、(1)規模の抑制、(2)独⽴性がアジャイル開発、分割検証、分割デプロイに適合


(補足) マイクロサービスアーキテクチャ（MSA）

l SOA/CORBAとMSAのアーキテクチャはトポロジー的には同等l MSAは作る側（北⽶ではサービス事業者と同一）の効率化/高速化に焦点l SOAPは、巨大で複雑な仕様 ⇒ 最近は敬遠され、急速にREST化進むl SOAPは、業務APやサービスの大きさ、変更容易性に関しては⾔及しない

l SOA/CORBAとMSAのアーキテクチャはトポロジー的には同等l MSAは作る側（北⽶ではサービス事業者と同一）の効率化/高速化に焦点l SOAPは、巨大で複雑な仕様 ⇒ 最近は敬遠され、急速にREST化進むl SOAPは、業務APやサービスの大きさ、変更容易性に関しては⾔及しない

DockerDockerDocker DockerDocker

SOA:サービス指向アーキテクチャ

サービス

サービスサービス

NW上に存在するサービスを業務上の⼀処理に相当する機能と⾒⽴て、業務システムを構築する設計⼿法。I/FはSOAP。

業務AP

MSA:マイクロサービスアーキテクチャ小規模/軽量なサービスを複数連携させることで業務システムを構築する設計⼿法

HW

OS

Docker Docker

ＭＳ

コンテナー仮想化

プラットフォーム

マイクロサービス（MS）化された

サービス

Docker

ＭＳ

ＭＳ

ＭＳ

ＭＳ

ＭＳ

サービスサービス

REST

REST

REST

業務APのサービス全体業務APのサービス全体スケールアウト単位

SOAP


（補足）DevOpsのITアーキテクチャに求められる要件

従来の堅牢性・安定性を重視したアーキテクチャに加え、後の要件追加・変更を前提としたリリーススピード、変更容易性を重視したアーキテクチャが求められる従来の堅牢性・安定性を重視したアーキテクチャに加え、後の要件追加・変更を

前提としたリリーススピード、変更容易性を重視したアーキテクチャが求められる

従来（SoR型）堅牢性・安定性重視

DevOps（SoE型）リリーススピード・変更容易性重視

モジュール粒度リクエスト単位の大きな塊（モノリシック）

単一の機能を持つ独⽴したサービス（マイクロサービス）

モジュール独⽴度

密結合化※メソッドコールによる同期呼出し

疎結合化※メッセージングによる非同期呼出し

ポータビリティ低い高い（オンプレ＆マルチクラウドへの対応）

スケーラビリティ低い高い（ステートレス化、セッションの永続化）

アプリ連携重厚なプロトコル（SOAP）軽量プロトコル（REST）デプロイ重厚なデプロイ

（ＡＰサーバ活用）軽量なデプロイ＋インフラ構築を含め⾃動化（APサーバレス）

アプリケーションを更新アプリケーションをコンテナから廃棄＋追加（Immutable Infrastructure）

扱うデータ構造化データ非構造化データトランザクション ACID属性 Eventual Consistency(結果整合性)


DevOpsツールチェーン〜主要構成要素

開発効率化、CI/CD⾃動化、ならびにそれらを統合的に管理する共通機能クラウド技術の活用により運用まで含めた⾃動化を促進し、デリバリスピードをさらに向上開発効率化、CI/CD⾃動化、ならびにそれらを統合的に管理する共通機能クラウド技術の活用により運用まで含めた⾃動化を促進し、デリバリスピードをさらに向上

ログ収集・分析ツール

ログ収集・分析ツール

システム監視ツール

システム監視ツール

共通機能統合ビルド、コード・モジュール品質検査（メトリクス評価）

インフラ環境プロビジョニング、アプリケーションデプロイ

開発・運用管理、ダッシュボードフィードバック

ロードバランサ(アクセス制御)ロードバランサ(アクセス制御)

Blue-Green Deployment、A/B Testing、Canary releases

リソース監視ツール

リソース監視ツール

バックアップツール

バックアップツール

非機能テスト動的テスト（ホワイトボックス）

コンテナ管理

設計支援ツール

設計支援ツール

ドキュメント検証ツール

ドキュメント検証ツール

ソースコードジェネレータソースコードジェネレータ

テストケーステストデータジェネレータ

テストケーステストデータジェネレータ

開発環境（コーディング・

デバッグ）

開発環境（コーディング・

デバッグ）

ビルド・テストツール

ビルド・テストツール

コンテナイメージ管理ツール

コンテナ実⾏管理ツール

セキュリティ検査ツール

ユニットテストツール

カバレッジ計測ツール

性能測定ツール

ビルドツール

コード検証ツール

メトリクス計測ツール

プロビジョニング・デプロイブート

ストラッピングコンフィグレーション

オーケストレーション

動的テスト（ブラックボックス）GUIテスト

ツールAPIテスト

ツール

バージョン管理ツール

CI/CD管理ツール

チケット管理ツール

（要件、障害）管理コンソール

CI ⾃動ビルド・⾃動テスト

CD⾃動デリバリ・⾃動デプロイ

Dev 統合開発ツール

Ops 運用・モニタリング

システム企画

要件定義

⽅式設計

ビルド静的テスト

コード開発（AP, テストコード, インフラ構築）、デバッグ

運用メトリクス、ビジネスメトリクス評価


NECのDevOpsコンセプトイメージ

必要性：ビジネスの成功がICTの俊敏性/柔軟対応⼒に直結する時代DevOpsとは：ICTの俊敏な対応を⾏うためのコンセプト⇒関連する構成要素の組み合わせで総合的に実現される

必要性：ビジネスの成功がICTの俊敏性/柔軟対応⼒に直結する時代DevOpsとは：ICTの俊敏な対応を⾏うためのコンセプト⇒関連する構成要素の組み合わせで総合的に実現される

マイクロサービスRESTful

規模の抑制と疎な結合を実現するアーキテクチャ

必要必要

相互関連

相互関連

DevOps相互関連

相互関連

相互関連

相互関連

ビジネス環境変化への俊敏な対応

アジャイル開発早期リリースのための

プロセス

開発⾃動化CI/CD開発系のPaaS/SaaSと連携するツールチェーン

IaaS/PaaS/SaaSコンテナ(Docker)

PFの柔軟な追加/変更を実現する実⾏環境

メトリクスベースの運用・監視

開発速度、ビジネス状態の監視、変更判断（IoT/AIの活用


DevOpsにおけるメトリクスの考え⽅

価値の源泉にフォーカスして、コントロール可能な評価指標を設定価値の源泉にフォーカスして、コントロール可能な評価指標を設定

▌6つの視点からみた価値の源泉l 政府/官庁の視点継続的な収益(納税)、国内雇用の確保 ⇒ SSフレームワーク対象外l 監査法人の視点企業信頼性の担保、企業統治の実施 ⇒ SSフレームワーク対象外l 市場/顧客の視点製品/サービスによるビジネスの成功 ⇒ ビジネスメトリクスl 企業経営の視点迅速な要員調達/育成、要員の最適配置 ⇒ SSフレームワーク対象外l 部⾨管理の視点移転可能な技術アセット、高い投資効率 ⇒ SSフレームワーク対象外l 現場の視点リスク抑制、計画(QCD)どおりの遂⾏ ⇒ 開発・運用メトリクス

▌パフォーマンス測定のための「拡張システムモデル」

InputsInputs ProgramProgram OutputsOutputs QualityQuality OutcomesOutcomes

Effectiveness(有効性)

Efficiency(生産性)

Quality(品質)

出典：Measuring the Performance of Human Service Programs 2nd

速さ事業成功DevOpsにおける主要なメトリクス

現状の課題と今後の展望


現状の課題

▌DevOpsの構成要素の成熟度アップに期待l開発プロセス：アジャイル開発lアーキテクチャ：マイクロサービスアーキテクチャl開発環境：特にCI/CD、Infrastructure as Codel実⾏環境：OpenなPaaS、コンテナー型仮想化lメトリクス：ビジネス、開発、運用

▌最重要課題：DevOps環境向き人材l人材タイプ、カリキュラムの定義l必要数を⾒極め、調達/育成

まだまだPremature

• 先進ITへの知⾒（クラウド、新⾔語、AI、IoT…）• Outcomesの最大化を目指すビジネスセンス


▌新しい技術/開発パラダイムは、早めに/上⼿に失敗し、教訓/ノウハウを蓄えることが重要l この数年アジャイル開発を⾃部⾨で常時実施中

⇒ アジャイル開発は分かった感あり

l DevOpsは先⾏PJで知⾒を増やしているところ⇒ 修⾏中。基本的なところでつまづくことも分かった

▌技術、ビジネス環境の変化が急でウォッチ強化l 特にOSSは変化が激しいので流れを作る側にシフト

今後の展望

“地域、国によって様々”なのではなく、“日本とグローバルしかない”

という認識が必要

最後に、アジャイル開発を含むSWエンジニアリングの地域性について

necにおけるアジャイル開発の 位置づけと取り組み ·...

Documents

necにおけるアジャイル開発の位置づけと取り組み ·...