IT サービスマネジメントフォーラムジャパン

10

はじめに

　ビジネス変革の速さに対応するため日本でも短納

期のシステム開発が要求されるようになって久し

い。海外では短期のビジネス変革に対応する開発手

法として非ウォーターフォール型のアジャイル型開

発と総称される軽量の開発手法が普及してきた。

　ITIL®* というサービスマネジメントの手法が開発

と運用を含めた IT サービスのライフサイクルのプ

ロセス指向アプローチとして既存のものとなった一

方で、上記のようなアジャイル開発をベースにした

システムライフサイクルでは DevOps という非プロ

セスもしくは極端に簡略されたプロセスを指向する

アプローチが新興の IT 企業で広がりを見せており、

アンチ ITIL® 的な位置付けで受け取られている面も

否定できない。

　本稿では、開発方法論から見た ITIL®、サービス

マネジメントの動向を整理しつつ、アジャイルや

DevOps と ITIL® の親和性を考察し、クラウドの普

及によるライフサイクルの変化を含めて論じてみた

い。

*ITIL® is a Registered Trade Mark of the Cabinet Offi ce.

I. 従来のシステム開発とサービスマネジメント

　近年普及するアジャイル開発に触れる前に、企業

の IT 運営において確固たる位置付けを築いている

システム開発標準について ITIL® ／サービスマネジ

メントとの関係を整理しておこう。

I.1　CMMI にみるシステム開発標準の動向

　CMMI は、ソフトウェアプロセス成熟度の改善を目

的としたフレームワークとして米国カーネギーメロ

ン大学ソフトウェアエンジニアリング研究所で開発

され、1990 年の SW-CMM 公表以来改訂を重ね、世界

的な注目を得ている。

　特に 5 段階の成熟度レベルの定義は ITIL® におけ

る改善活動においても参照されているお馴染みの手

法であり、日本国内でも多くの企業 IT 部門や IT 企

業がシステム開発の品質保証に取込み、また CMMI

の公式のレベル評価を受けて対外的なアピールを行

っている。

　このように主にシステムの開発面で業界標準の位

置を得てきた CMMI であるが 2006 年の CMMI v1.2 で

は「開発」以外の目的にも使用できるような複数の

モデルに発展させた。既存の CMMI を CMMI-DEV( 開

発のための CMMI) とし、CMMI-SVC( サービスのため

の CMMI) をサービスマネジメント領域のモデルとし

て追加している。またこの時 CMMI-ACQ( 調達のため

の CMMI) も追加されている。［1］

図 I-1. CMMI のモデル群

会員寄稿

ITIL®、 アジャイル、 そしてクラウド～実際のところ OpsDev じゃないかと考えてみる～

11

I.2　CMMI-SVC と ITIL®

　CMMI のモデルの一つである CMMI-SVC は ITIL® の

他 ISO/IEC 20000 や CobiT を参考にして開発された

と言われている。表 I-1 に CMMI-SVC のプロセス領

域を列挙するが、特に CMMI-SVC 固有のプロセス領

域が ITIL® の特徴的なプロセス群を反映しているこ

とが見て取れる。

　残念ながら CMMI-SVC の企業認証 ( 公式のレベル

評価 ) 取得の動きは CMMI-DEV( 以前の CMMI) のよう

に日本では普及していないが、ウォーターフォール

型のシステム開発に普及していた開発標準がサー

ビスマネジメントを取り入れた代表的な例と言え

る。CMMI-SVC の認証取得が普及しなかったこと自

体は、日本の IT 組織が対外的なアピール方法とし

て先行した ISO/IEC 20000 を選んだ結果だと言えよ

う。しかしながら ISO/IEC 20000 が全プロセスを対

象とした外部評価つまり All or Nothing、なのに対

し、CMMI-SVC は成熟度レベルの要求に合わせて段階

的なスコープを設けて外部評価を得ることが可能で

あり、また一部のプロセスしか担当していない組織

が外部評価を得ることの出来る点で柔軟性に優れた

標準と言うことができる。このことはまた CMMI-SVC

が、ITIL® を段階的に導入しようという組織にとっ

て、対象領域の優先付けを客観的な成熟度の視点か

ら検討するためのリファレンスとしても活用出来る

ことを意味している。

I.3　共通フレームとサービスマネジメント

　CMMI の他、日本国内の開発標準として共通フレー

ム ( ソフトウェアを中心としたシステムの取引に関

する共通フレーム ) があり、システム開発における

ガイドラインとして 1994 年から改訂を重ねている。

今年 3 月には情報処理推進機構ソフトウェア・エン

ジニアリング・センターより共通フレーム 2013 が

発行された。この改訂により「運用・サービスとシ

ステム開発の連携を考慮した、サービスプロセスの

導入」が行われサービスマネジメントプロセスがプ

ロセス群に追加されている。この追加には、「業務

システムは、取得しただけでは何の価値も生まない。

システムを運用し、業務で利用されて初めて価値を

生む。」「ISO/IEC 20000（JIS Q20000）を既に導入

している企業が共通フレームとの整合を図れる。」

という意図が込められている。(IPA/ エンタープラ

イズ系総合セミナー 2013)

表 I-1. CMMI-SVC のプロセス領域と ITIL®　　　　 * 筆者訳

12

　これも、特に国内で既に確立されたシステム開発

標準が ITIL® をベースにしたサービスマネジメント

や運用プロセスを取り入れた事例と言えよう。

II. アジャイル開発とサービスマネジメント

　従来のウォーターフォール型の開発が「計画重視」

とされる一方、アジャイル開発は「適応的」と対比

的に説明されている。このことはアジャイル開発が

「計画軽視」と言う訳では無く、アジャイル開発が

短期のサイクルで計画と実行を反復することで、要

件の変化に短期に適応できることを示している。

　ビジネス要件が短期間に変化を求めていく状況に

おいて、一般に長期に渡り計画の変更を制御・抑制

しなければなりたたない「計画重視」のウォーター

フォール開発よりも、変化に対して「適応的」つま

り「変更ありき」のアジャイル開発が適用されるよ

うになっている訳である。

　本章では近年普及が見られるアジャイル開発手法

における ITIL® ／サービスマネジメントとの関係を

整理しておこう。

II.1 統一プロセスと ITIL®

　アジャイル開発に適用さ

れる手法の も良く知られ

るものとして統一プロセス

=UP(Unifi ed Process) がある。

オブジェクト指向開発や反復

型開発プロセスのベストプラ

クティスをまとめ 1998 年に出

版された。UP では反復の繰返

しで構成されるライフサイクルを下記のフェーズに

分けている。

●方向付けフェーズ

●推敲フェーズ

●作成フェーズ

●移行フェーズ

　上記は、ウォーターフォール型の開発の「要求分

析」「設計」「実装」「テスト」に「展開」を加えた

ライフサイクルに相当するものと言える。

　UP がソフトウェア開発のプロセスフレームワーク

であるのに対し、企業全体の IT 業務を網羅するプ

ロセスフレームワークに拡張したものとして 2005

年に EUP( エンタープライズ統一プロセス ) が出版

され、企業の IT 全体プロセスにおいて UP が整合を

とれることを示している。［2］

　EUP ではライフサイクルに上記の UP のフェーズに

加えて、稼働フェーズ、引退フェーズを拡張し、こ

れに必要な「運用及びサポート」作業分野を加えて

いる。また企業全体の IT 業務として「エンタープ

ライズ管理」作業分野群を加え、UP に含まれる作業

分野とのインターフェースを記述してる。

　EUP の「運用及びサポート」作業分野や「エンタ

ープライズ」作業分野群には、ITIL® の参照を促す

記述や、ITIL® のプロセスが対応する作業分野が多

く記載されており、アジャイル開発における普及し

た手法が ITIL® をベースにしたサービスマネジメン

トや運用プロセスを取り入れた事例と言えよう。表

II-1 に EUP の作業分野と ITIL® の対比を示すので参

考にされたい。

　表 II-1.EUP の作業分野と ITIL®

II.2 DevOps と ITIL®

　従来のウォーターフォール型の開発方法論だけで

なく EUP に見られるようにアジャイル開発の方法論

においても ITIL® ／サービスマネジメントが受け入

れられている。その一方で、アジャイル開発の普及

に伴う動向として DevOps と呼ばれる、ともすれば

極端な開発と運用の連携、頻繁なリリースを促進す

る手法が注目されるようになっている。(DevOps は、

13

Dev: 開発、Ops: 運用からの造語 )

　このDevOpsという新しい動向は既存の方法論と対

立するように論じられることも目にするが、今や既

存の方法論と言える ITIL® についての対立ポイント

を整理してみよう。表 II-2 に下記の有名な DevOps

の原点と言われるメッセージと Wikipedia の記述か

ら DevOps の主要な観点と ITIL® での対応をまとめ

てみた。［3］

　Ops'job is NOT to keep the site stable and fast

　Ops'job is to enable the business

　The business requires change

　Lowering risk of change through tools and culture

　DevOps も ITIL® も IT 運用の目的や開発との関係

については近い部分もあるが、基本的に変更の実施

についての考え方は対立的と言える。

　　　　　　表 II-2 DevOps と ITIL® の比較

II.3 身近にあるアジャイルな開発と DevOps そして ITIL®

　短納期型開発のビジネス要件に対する開発手法と

してアジャイル開発の採用が増えてきているが、反

復型開発としてのアジャイルな開発は、実は運用保

守の現場でしばしば採用されてきたものである。

　本番稼働に入ったアプリケーションのシステム管

理チームが設置される際、ある程度開発スキルをも

ったメンバを含むベンダーチームにシステム運用作

業と合わせて業務委託を行うことが良くある。外部

のデータセンター利用が普及す

る前は、企業のコンピュータ室

や情報システム部門のエリアに

ベンダーチームが常駐する形態

が多くとられてきた。

　この常駐型の契約において

は、１ヵ月から数ヵ月程度の契

約単位で定期的に固定メンバに

工数を割当て、その決まった

期間と工数の中でシステム管理作業の他に必要性の

高い保守開発要件を継続的にこなしていくといった

作業形態がとられることが多い。これは開発方式と

しては反復型のアジャイル的な開発であり、システ

ム管理の側面では開発と運用が相互依存する DevOps

型の IT 運用ということもできる。

　このようなアジャイル開発的・DevOps 的な運用

保守の環境は、ITIL® の普及については対立的なも

のではなく寧ろ日本型の草の根的な ITIL® 普及の舞

台となっていた ( もしくは成熟した現場では元々

ITIL® 的な運用管理を行っていた ) というのが筆者

の認識である。これらの現場では ITIL® の柔軟な側

面、つまり変更管理で言えば「標準的な変更」やリ

リース管理で言えば「デルタリリース」の頻度を日

常的なプロセスとして運用してきたのである。II.2

で述べたように ITIL® では変更はコントロールすべ

きものとして扱われる一方で、変更モデルと

いう概念により「標準的な変更」を定義し、

リスクの無い変更が効率的に実施できるよう

な変更管理プロセスを提示している。

　昨今DevOpsに言われるような、極端に頻繁な変更・

リリースを促進する運用も、上記の延長線で ITIL®

のプロセスに包含するべきではないかと考えてい

る。表 II-3 に ITIL® の標準的な変更と DevOps で頻

繁に行われる典型的なリリースの比較をまとめる

が、変更スコープを小さく切出して影響を限定でき

る場合や、特に DevOps を支えている自動化ツール

や仮想サーバ環境などのリリース関連技術により、

変更のリスクを担保できる「標準的な変更」の範囲

とすることで従来からの ITIL® の変更管理に沿った

ものと言えるのではないだろうか。

表Ⅱ -3. ITIL® の標準的な変更と DevOps のリリース

観点観点 ITIL®の「標準的な変更」ITIL®の「標準的な変更」 DevOpsのリリースDevOpsのリリース

記述記述リスクが低く、比較的よくあり、手順または作業指示書に従って行われる事前許可済みの変更

開発と運用の協働により、1日に10件ものデプロイを伴うビジネス要求に対応するリリース

例例・パスワードのリセット・新しい従業員に対する標準的な　機器の支給

・機能変更・修正プログラムのデプロイ・アプリケーションの追加機能など　新モジュールのデプロイ

承認の要否承認の要否事前許可を得ておくことにより個々の変更についての承認プロセスを省略

現場の判断・合意により上位職の承認を必要としない

リスクの担保リスクの担保・影響範囲が小さい変更に限定・繰り返し実施される変更に限定・明確な手順や作業指示

・変更スコープの抑制、切り出し・デプロイやテストの自動化・定型化・仮想技術による瞬時の切り戻し

14

　仮想サーバ環境では複製やスナップショット ( 変

更前の状態を保存しておき適宜保存時点の状態で稼

働できる ) 機能などデプロイ ( 展開 ) 時の切り戻し

のサポートが充実した製品が既に普及している。ま

た DevOps を支えるアプリケーション開発ツールと

して、ITIL® と同様にライフサイクルの管理を意識

した ALM( アプリケーション・ライフサイクル管理

) ツール、テスト自動化ツール、デプロイ自動化ツ

ールが製品として市場に提供されており普及に伴い

ITSM ツールとの相互利用が予想される。今後はプロ

ダクト／ツール・レベルで ITIL® と DevOps の同時

実践事例の報告が期待されよう。

III. クラウドとサービスライフサイクル

　Ⅰ、Ⅱ章で従来の開発方法論のみならずアジャ

イル開発方法論においても ITIL® が受け入れら

れ、また 近の DevOps 開発においても ITIL® に沿

ったプロセスの適用が可能になり得ることを述べ

た。本章では、アプリケーション開発に

影響の大きいクラウドの動向から、特に

IaaS(Infrastructure as a Service) や

PaaS(Platform as a Service) によるイン

フラ調達の変化による開発工程への影響に

ついて述べる。

III.1 ウォーターフォール型開発とインフラ調達

　従来のウォーターフォール型開発におけるインフ

ラ調達の位置付けを整理しておこう。ウォーターフ

ォール型開発の大きなフェーズの括りをアプリケー

ション管理ライフサイクル (ITIL® 2011 edition サ

ービスオペレーション P.181 参照 )にあてはめて「要

件」「設計」「構築」「展開」とすると、インフラ調

達への要件を確定していくのは、「要件」において

いわゆる非機能要件を定義し、その他の要求分析結

果を受けて「設計」における方式設計を、更には具

体的にインフラ設計と呼ばれる工程を経ることにな

る。

　これによりシステムに求められるスケーラビリテ

ィなどの要件を満たすサーバ HW などのインフラへ

の要求仕様が確定しインフラ調達のプロセスに入る

ことができる。調達されるインフラは「構築」工程

の開発環境として 初に必要となるが、インフラ調

達自体に競争入札の手続きやメーカの在庫状況によ

り数ヵ月間を要することになる ( 図Ⅲ -1 参照 ) 。

　インフラ調達までの時間を短縮するためには大ま

かにインフラ設計を前倒しで進め、性能など仕様に

余裕をもったハードウェア、つまり過剰な性能をも

つハードウェアを調達するような投資面での対策も

行われている。それでもハードウェア調達のリード

タイム中にプロジェクト要員の稼働損が発生しない

ように「設計」工程に十分な期間を費やしてシステ

ム全体の設計を一括で行うことを促すことになる。

このことはウォーターフォール型の重量開発手法を

投資面と設計面から正当化してきたことを示してい

る。これに加え発注側が自身のリスクを担保するた

めに請負契約を求める傾向や、コスト抑制のための

オフショア開発における仕様の明確化の必要性がウ

ォーターフォール型開発を採用する要因として考え

られる。

図III-1 ウォーターフォール型の開発における従来のインフラ調達

III.2 クラウドにより変わるインフラ調達

　クラウドの利用は、Ⅲ .1 で述べたインフラ調達

のタイミングや期間に大きな影響をあたえるもので

ある。IaaS や PaaS といったインフラや開発プラッ

トフォームをサービスとして提供するクラウドサー

ビスの普及により、インフラ調達は先倒しが可能に

なり、またインフラ調達期間も大幅に短縮できるよ

うになった ( 図Ⅲ -2 参照 ) 。これは主に以下の要

因によるものである。

・インフラ調達後もダイナミックにスケーラビリテ

ィの拡張が可能であるため、スケーラビリティを

精査しないままインフラ調達に入ることができる。

・初期投資が不要で従量課金として費用が小額に平

準化されるため、予算化の制約が少ない。

15

・仮想化技術と自動化された契約プロセスにより、

早ければインフラ構築が数分で完了する。

　上記は企業内でもインフラのキャパシティを事前

に確保しておくような仮想化環境の整備・運用によ

り、同様にインフラ調達のリードタイムを短縮でき

ることを示している。国内でも大規模な企業 IT 組

織では仮想技術の利用実績を踏まえて企業内クラウ

ドを構築するという選択をとるケースも出てきてい

る。

　　　　図III-2 クラウド活用によるインフラ調達の短縮

　インフラ調達の短縮は、ライフサイクルとしては、

その間に実施しておけば十分だった設計工程期間の

短縮への圧力となる。この圧力は、全体の設計を完

了して次工程にすすむウォー

ターフォール型の開発より、

アジャイルなどの反復型の開

発により優先される部分の要

件 / 設計 / 構築 / 展開を短期

間で進める開発手法の選択を

求めることになる。このこと

は以降のライフサイクルで更

に DevOps のような運用 / 保守

開発に遷移する可能性を示し

ている。

III.3 企業 IT における DevOps

　以上で述べたように、クラウド活用や仮想環境の

利用によりインフラ調達の期間は短縮され、システ

ム開発のサイクルが短期間になるにつれアジャイル

のような反復的な開発手法の採用や DevOps 的な開

発を継続していく状況が整いつつある。

　企業 IT でのアプリケーション管理ライフサイク

ルに当てはめてみると、初期開発は通常開発ベンダ

への委託開発となりこれはⅠ .1 で述べた CMMI で言

えば ACQ つまり調達という行為である。新たな技術

を駆使する DEV つまり開発は開発ベンダ側の役割で

あり、多くのシステム開発プロジェクトにおいて企

業側は ACQ の立場と言える。また SaaS(Software as

a Service) やアプリケーション・パッケージの採用

によりそもそも「開発」という行為が縮小し「調達」

の期間も短縮することになる。

　システム稼動に伴い運用工程ではサービ

スオペレーションから得られる利用者から

のリクエスト（バグ修正依頼や操作性の向

上など）や変化するビジネス要求を元に

適化に向かう。 適化にシステムの保守開

発や拡張開発が必要であれば、次の開発サ

イクルがスタートする (図Ⅲ -3 参照 )。

　企業側はシステム開発プロジェクトの終

了に伴い必要な技術トレーニングによる知識移行も

しくは技術要員の採用により保守開発体制を構築・

維持していく。これらの保守開発体制が次の開発サ

イクルに対応し、ある程度の開発規模であれば体制

内で対処していくことができる。

図III-3 アプリケーション管理ライフサイクルに見るAcq, Ops, Dev

　このように企業ITにおけるアプリケーション管理

ライフサイクルでは、Acq( 調達 )-Ops( 運用 ) -Dev(

保守開発 / 拡張開発 ) の順で出現し、Ops における

適化を契機にして Ops-Dev というサイクルを継続

していくと考えられ、運用体制にはその能力が求め

られることになる。

16

　SaaS を含めたクラウド利用による調達期間の短縮

を考えると Acq-Ops-Dev どころか更に Ops-Dev とい

う序列で表現すべき状態にしていくことを運用体制

は意識すべきではないだろうか。

　今後、単に下流工程としての「運用」は過去のも

のとなっていくと考えるべきである。少なくともイ

ンフラなどクラウドに移行するコンポーネントは運

用業務の対象ではなくなっていくのである。企業の

IT 運用組織は大きな変化に挑む時期を迎えている。

IT スタッフとしても運用専門、開発専門という棲み

分けではなく、運用マネージャとしてはクラウドサ

ービスの統制に加え、ビジネス要求を把握して次の

ライフサイクルの上流 (「要件」「設計」) へと改善

サイクルを回さなればならないし、運用スタッフで

あれば簡単な保守開発や開発管理に取り組んでいく

ようなスキルエリアの広がりが今までに増して求め

られてくるはずである。

IV. まとめ

　本稿では、当初システム運用に受け入れられた

ITIL® がその後にシステム開発にも受け入れられて

きた状況を、代表的なシステム開発方法論を例に確

認した。

　また近年のアジャイル開発の方法論だけでなく

DevOps の動向にも ITIL® が十分に受け入れられうる

ことを考察した。

　更に今後のクラウドサービス利用の動向が加わ

り、これまで Ops( 運用 ) 専門だった組織、スタッ

フについても Dev( 開発 ) に関わるべく業務内容・

スキルエリアの拡大・シフトが求められるものと考

えている。このことが本番稼働する情報システムに

も関わってきたシステム運用にとって、ITIL® V3

以降明確に要求するようになったサービス・ライフ

サイクル全般へと視野を広げていくことの促進につ

ながっていけば幸いである。

＜参考文献＞

[1]「CMMI for Services, Version 1.3」Software

Engineering Institute(2010/11)

[2]「エンタープライズ統一プロセス」スコット W. アン

ブラー / ジョーン ナルボーン / ミカエル ヴィツドス

(2006/7)

[3]「10+ Deploys Per Day : Dev & Ops Cooperation at

Flickr」John Allspaw & Paul Hammond(Velocity 2009

にて発表 )

株式会社シグマクシス /マネージャ

　　　　　　　　　　　 小澤 一友

ITIL® V2 Manager / V3 Expert Certificate, PMP,

ISO/IEC20000 Consultant Certifi cate

1992 年、自然言語処理への関心から IT企業に入社、

システム開発／保守、特に広域監視システムの研究・

構築などシステム運用管理関連の経験を経て、2004

年 4月 ITIL® マネージャ認定を取得、組織的な ITIL®

活用推進、品質改善活動に取組む。以降 IT企業数社

にて IT運用改善、ITサービスマネジメント導入コン

サルティング、ITアウトソーサ創業に際した品質マ

ネジメントシステムの構築などを経験。ITSM 運営組

織とソーシング管理研究分科会副座長。