アジャイルから DevOpsへ ― 歴史的観点から見た DevOpsへの進化 ― 開発と運用が連携し、アプリケーションのリリース・サイクルの短期化を目指す「 DevOps 」。この新たなテーマ への関心が近年になり急速に高まっています。背景には市場の変化がさらに加速する中、業務基盤であるアプリ ケーションの新規開発や変更をより早いペースで可能にするアジャイルの重要性が、あらゆる企業で増しているこ とがあります。またクラウドや仮想化環境を中心とする新しい運用インフラの登場によって、より早いサービスを 提供できることになったことも大きな要因です。本稿では、歴史的観点からアジャイルとそのキーとなるテクノロ ジーを振り返り、DevOpsへ発展していく流れを解説します。 1. 日本におけるアジャイルに対する意識 （アジャイル・マニフェスト） 」をよりどころに、さまざまな アジャイル手法が開発されました。 ここに面白いデータがあります。2009 年から開催され IBM が2013 年に発表した「 C-Suite Study 2013 」 ［ 1 ］では、 「 CEO が考える自社に影響を及ぼす外部要 ているAgile ConferenceのIBMセッションでは、毎年 因 」のトップは、2012 年に引き続き「テクノロジー」にな アンケートでアジャイル開発の取り組み状況を聞いていま りました（ 図 1 ）。また特徴的なところでは「 市場の変化 」 すが、2013 年では実施中企業は38 %、取り組み予定を がトップ2に返り咲いています。日本のCEOに限定すると、 含めると約 8 割の企業がアジャイルを採用しようとしてい 逆に「 市場の変化 」 「テクノロジー」の順になり、最新の ます。2009 年の結果では同数値は約 35 %であり、5 年 ITを用い、いかに他社に先駆けて競争力のある製品・サー を経過したいま倍以上の企業でアジャイルに対する意識 ビスを迅速に市場に出すかがカギになっていることが分か が高まっていることになります（ 図 2 ）。日本では大規模な ります。 一括請負契約が多く、欧米とは契約慣習が違うことからア 市場の変化、ビジネス・ニーズの変化に対し、柔軟性と ジャイルの適用が難しいと言われてきましたが、IPAから アジリティーを持った製品・サービスを提供する。こう聞 非ウォーターフォール型開発に適したモデル契約書が公 いた時、 「アジャイル 」を思い浮かべる人は多いのではな 開されたり［ 2 ］、各種イベントでアジャイル適用の成功、 いでしょうか？ 1990年代後半から提唱・実践され始め、 失敗事例が講演されることで、開発ベンダーだけでなくシ 2001 年に宣言された「アジャイルソフトウェア開発宣言 ステムを発注するユーザー企業もアジャイルに注目してい 2004 2006 2008 2010 2012 2013 1 1 1 1 1 1 テクノロジー 2 2 2 2 2 2 市場の変化 3 3 3 3 3 3 マクロ経済要因 4 4 4 4 4 4 人材・スキル 5 5 5 5 5 5 法規制 6 6 6 6 6 6 社会経済要因 7 7 7 7 7 7 グローバル化 8 8 8 8 8 8 環境問題 9 9 9 9 9 9 地政学的要因 図 1. IBM Global CEO Studyに見る自社に影響を及ぼす外部要因 (2004–2013) 32 P ROVISION No.80 / Winter 2014 細かく計画を見直し修正していくことで、顧客から早期に フィードバックを得ようとしました。 2013 XPのプラクティスの数は初期には12でしたが、数度 の改定を経て19に増えています。この中でもDevOps 2011 につながる重要なものとして「 継続的インテグレーション （ Continuous Integration : CI ） 」 ［ 4 ］があり、開発の 2009 生産性や品質向上を目指しました。 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% ■ 実施中 ■ 取組み予定 ■ 情報収集中 引用：Agile Conference 2009, 2011, 2013 IBMセッション 図 2. アジャイル開発の取り組み状況の遷移 CIの適用により、 ●プログラマー当たりの開発 LOC（コード行数 ）が90 % 上昇 ●欠陥率が36 % 低下 という興味深いレポート ［ 5 ］が公開されています。 ると言えます。 ここからアジャイルの発展を振り返り、そこで発生したさ まざまな課題を新たな手法やテクノロジーによって乗り越 継続的インテグレーション（ Continuous Integration : CI） えた、DevOps へとつながっていく歴史的経緯を見ていき システムの結合は非常に労力がかかる作業で、プロジェ たいと思います。 クトの終盤で行うと品質問題を引き起こし、多くの場合プ ロジェクトの遅延の原因になっています。このことからCIは 2. 歴史的観点から見た DevOps への進化 チーム・メンバーがそれぞれの作業を早期に次々と結合し、 結合にかかわる不具合を早期に発見しようとする考え方で （ 1 ）2001年∼2005 年：XPの浸透 す。通常は自動化のためのCIツールを導入し、開発者が構 アジャイル開発の中で有名なものにXP（エクストリー 成管理ツール（ SCM ）に開発したコードを提出するとそれ ム・プログラミング ）があります。5つの価値と開発チー を検知し、あらかじめ設定されていた作業（コンパイル、ビ ムが行うべきいくつかのプラクティス（習慣、実践 ）が定 ルド、テストなど）を自動的に実行します。その結果はダッ 義されており、ドキュメントよりもソースコードを、組織的 シュボードやメールなどの手段で開発者にフィードバック 開発の歯車となることよりも個人の責任と勇気を重んじ されます（ 図3 ） 。コードを提出後にバックグラウンドで常 る、人間中心の開発プロセスであるとしています。1999 に指定した作業が実行されることで、デグレードを防止し、 年にKent Beck が執筆した「 XP 入門 」 ［ 3 ］により特に 修正部分を安全に取り込むことができます。CIを実現する 開発者によって熱狂的に受け入れられました。ドキュメン Jenkinsなどのオープンソースや多くの商用製品が登場し、 トを不要だとはしていないまでも動くソースコードを重視 IBMでもRational 製 品 群（ Rational Team Concertや し、またアジャイルの特徴である短期的な反復開発により Rational Build Forge ）でサポートしています。 フィードバック手段（ダッシュボードなど） フィードバック 開発者 ソースコードの提出 （変更のコミット） フィードバックの生成 ビルドスクリプト 開発者 監視 実行 CIサーバーから呼び出す 作業を記述 （ ・コンパイル ・ビルド ・テスト ） 開発者 構成管理ツール（SCM） CIツール SCMとCIツールが一つに統合されている製品もあります。 IBM製品だとRational Team Concertが該当します。 図 3. 継続インテグレーションの仕組み P ROVISION No.80 / Winter 2014 33 （2） 2006年∼2011年：スクラムと継続的デリバリー 継続的デリバリー （ Continuous Delivery : CD ） XPはプラクティスの集合体であり、開発の流れを明確に 継続的デリバリー（ CD ）とは、CIを通じて出来上がった 示していません。一方、1993年 Jeff Sutherland、John ビルド済み、テスト済みの成果物を、テスト環境やステー Scumniotales、Jeff McKennaによって提唱されたスク ジング環境、本番環境に継続的にリリースすることを示し ラムは開発プロジェクト管理の枠組み（フレームワーク）を ます。目的は、開発から運用に信頼されたソフトウェアを 提供します。XPのように具体的なプラクティスや開発手法 渡し、さらにプロセスを可視化し大部分を自動化すること には踏み込まないため理解しやすく、さまざまなプロジェク にあります。価値のあるソフトウェアを早いうちから徐々 トに適用しやすいことから、現在世界中で最も多く使われ に提供することは、顧客のフィードバックを増やし、ビジ ているアジャイル手法です。そのためプロジェクトによって ネス・ニーズの変化に柔軟に対応できることにつながりま は、スクラムとXPを組み合わせるハイブリット型を採用す す。またフィードバック情報は、開発だけでなくテストや運 るケースもあります。スクラムの用語や仕組みは多くの書籍 用チームにも伝搬され、組織間のコラボレーションを促進 やWebサイトで説明されていますのでここでは省略します。 します。当初はアジャイルに適用するために開発されたも スクラム+XPまたCIにより、ビジネス価値のあるソフト のですが、フォーカスしているのが適切な可視化と素早い ウェアを頻繁にリリースしていく土壌ができました。しかし フィードバックによる共同作業の改善なので、ウォーター ここで新たな疑問が浮かんできます。 フォールなどの非アジャイルにも適用されています。 このようにビルド、デプロイ、テスト、リリースを通した ●開発で作った成果物をテスト環境∼ステージング環境 全体のプロセスがエンド・トゥ・エンドで自動化されるよう ∼本番環境に、失敗せずより迅速にリリースするにはど に実装されることを、デプロイメント・パイプラインと呼び うするか？ ます。ここで重要なのは「ビルドは1回限りとし、できた 成果物をあらゆる環境で利用する」ことです。実際のプロ ●開発期間が1 年半の場合に構築したリリース・プロセス ジェクトでは環境ごとにコンパイル、ビルドを行うことがあ を１ヵ月サイクルに短縮したとしても機能するか？ りますが、何らかの差分が紛れ込むリスクや設定の不備 でアプリケーションの振る舞いが変わるかもしれません。 2011 年にIBM が調査会社に委託して行ったサーベ イ結果では、十分なテストができないため障害が本番に これが原因となったバグが本番まで残ることもよく聞かれ 入ってしまうことを経験した企業が45 %。またアプリケー る話です。またシステムを構成するモジュールの各バー ションのテスト環境構築に時間がかかりすぎていると感じ ジョンを集めたものをスナップショットと言い、このセット ている企業が41 %と、開発チームのCIだけでは解決で をコピーしていくことで品質を保証します（ 図4 ） 。 きない課題が出てきました。そこでCIをさらに推し進める IBMでは2013 年にCDをサポートするツールを提供す 考え方として継続的デリバリー（ Continuous Delivery : るUrbanCode 社を買収し、Rational 製品群に統合しま CD ） ［ 6 ］が登場しました。 した。 ビルド 開発テスト Web モジュール SCMから 取得 Java アプリケーション ビルド ミドルウェアの 設定 データベース システムテスト 開発 テスト システム テスト 受入テスト サインオフ ステージング スナップショット 3 開発 テスト システム テスト Config 展開 開発 テスト システム テスト SCMから 取得 開発 テスト システム テスト 2 受入 テスト サイン オフ 3 1 2 図 4. デプロイメント・パイプラインとスナップショットの活用 34 P ROVISION No.80 / Winter 2014 本番 ステージング 本番 CDを支える重要なテクノロジーとして、クラウドや仮 図 5はCDをサポートするIBM UrbanCode Deploy 想化環境があげられます。クラウド・サービスの普及によ と、仮想化のプロビジョニングをサポートするSCOや り、インフラの調達・提供期間が大幅に短縮されました。 IPASを連携したイメージです。SCOやIPASで作成した OSやミドルウェアの仮想イメージの配布を手動で行うこ テンプレートをUrbanCode Deployにインポートします。 とはミスも多く、失敗したときの環境の再作成も困難で UrbanCode DeployからSCOやIPASを呼び出して適 現実的ではないと思います。そこで「 Infrastructure as 切な仮想イメージをプロビジョンして構築した環境に対 Code（コードとしてのインフラストラクチャー） 」という し、デプロイメント・パイプラインを走らせるということも 考えが生まれてきました。つまり、今まで手順書を基に手 既に実現しています。SCOやIPASの代わりにChefを呼 動で行ってきたインフラの構成管理を、スクリプトや外部 び出して、プロビジョンを行うことも可能です。 ファイルに記述し自動的に行えるようにしたのです。これ らはソフトウェアのコードのように管理でき、変数化する ことで柔軟にプロビジョニング（ 展開 ）することも可能で す。またイメージをテンプレート化して管理することで、必 要に応じていつでも複製できるようになりました。IBMで （ 3 ）現在：そしてDevOpsへ ここまでCI、CDというDevOpsの重要なテクノロジー を見てきましたが、疑問がわいているかもしれません。 CDで開発から運用に信頼されたソフトウェアを渡し、 は、IBM SmarterCloud Orchestrator（ SCO ）やIBM 本番環境にリリースできるようになりました。また、デプロ PureApplication System（ IPAS ）でこの考え方を取り イメント・パイプラインの状況は可視化され、共有できる 入れています。またオープンソースではChefやPuppet ようになりました。これこそDevOpsではないでしょうか？ が有名です。 DevOpsは、Development（ 開発 ）とOperation（ 運 デプロイメント・パイプラインに仮想化技術をどのよう 用 ）を組み合わせた言葉です。そのため開発と運用を一 に取り入れられるでしょうか。システムのバグが発見され 体化するというコンセプトと考えると上記もDevOpsに他 たとします。その原因にありがちなものとして、 なりません。 一方、DevOpsの目的について改めて考えてみます。 ●アプリケーション・コードのバグ CEOの関心が、最新のITを用い、いかに他社に先駆けて ●テストの実行ミス、無効な期待値の指定 競争力のある製品・サービスを迅速に市場に出すかにある ●デプロイ、リリース手段の問題 とすると、 ●インフラ（ OSやミドルウェア）の問題 「 高品質で価値のあるソフトウェアを効率的で素早く、信 頼できるやり方で継続的にリリースし、開発して終わりでは があり、インフラの設定も要素の一つになります。再現で なく、ユーザーの利用状況やシステムの稼働状況をフィー きるインフラが残っていて自由に利用できればよいです ドバックし、次の商品提供や機能改善につなげること」 が、一から構築しなくてはならないケースも出てきます。 と言えるのではないでしょうか。実際、2013 年 7月に米 そんな時、仮想化技術を利用することが効果的です。 調査会社のForester Researchが発行したレポート ［7］ によると、 ビルド SCM 変更の 読み取り プロビジョニング CIツール Chef ビルドの配布 ● DevOpsは開発や運用だけでなく、顧客や事業部門 リリース自動化 IBM PureApplication Systems IBM UrbanCode Deploy 呼び出し IBM SmarterCloud Orchestrator （ Line of Business ）を含めたコラボレーションに広 がり、市場の変化に対応した迅速なリリースが求められ ている ●顧客への直接のフィードバックがイノベーション・サイ クルをドライブする テスト環境 ステージング 環境 本番環境 といったように、DevOpsは開発や運用だけにとどまらず、 プロビジョニング・プラットフォーム 図 5. IBM UrbanCode Deployを中心とした 継続的デリバリーの実現 ビジネスの視点まで含めるべきと提唱しています。 IBMではDevOpsを、ビジネスの視点に基づくソリュー ションの企画・設計から始まり、開発とテスト、デプロイ P ROVISION No.80 / Winter 2014 35 IBM UrbanCode Release IBM SmarterCloud Orchestrator IBM PureApplication System アプリケーション・リリース管理 顧客 事業部門 Chef クラウド・プロビジョニング IBM UrbanCode Deploy アプリケーション・デプロイの自動化 Rational Focal Point Rational Requirements Composer 開発 ビルド 成果物のリポジトリ Rational Team Concert Jenkins テスト環境 ステージング環境 Rational Quality Manager Rational Test Workbench Rational Test Virtualization Server Rational Build Forge 本番環境 IBM SmarterCloud Application Performance Management Coremetrix Tealeaf 図 6. DevOpsライフサイクルを支えるツール とリリース、モニタリングとその結果を関係者にフィード 調されることも多く、多大な労力や時間がかかりそうなた バックするというデリバリー・ライフサイクル全体を最適 め導入に躊躇している企業が多いことも確かです。 IBMでは、これまでの経験からDevOpsのプラクティス 化することとして位置付けています（ 詳細は今号の「 海外 寄稿：Introducing DevOps 」 ［ 8 ］をご参照ください）。 と成熟度モデルを定義し、企業が現在成熟度のどこに位置 開発ソリューションを提供するRational 製品を核にし しているか（ AS-IS ） 、今後どこを目指すのか（ To-Be ）を て、前述のUrbanCodeやSCO、IPASなどの仮想化技 お客様と一緒に議論し、フォーカスする領域を定め、今後 術、インフラのモニタリングをするIBM SmarterCloud のロードマップ策定の支援をすることができます（ 図7 ） 。 Application Performance Management、Webマー ケティング最適化ツールであるCoremetrix、顧客体験分 3. 今後のアジャイルと DevOps 析ツールのTealeafなど、DevOps実現に向けトータルな ソリューションを提供することができます。もちろん既存で 本 稿 で は 歴 史 的 観 点 からアジ ャイル を 振り返り、 使っているツール（ 例 JenkinsやChef ）を組み合わせて DevOps へ発展していく流れを見てきました。最後に今後 利用できるオープン性も備えています（ 図6 ）。 のアジャイルとDevOpsについて考えてみます。 もちろんDevOpsはツールを導入するだけでできるもの 現在のアジャイル開発の主流はスクラムとXPですが、 ではありません。組織間のプロセスや意識が異なるため、 一般的には同じ場所で作業し、シンプルな開発をする小規 そのギャップを埋めるための「 文化の醸成 」という面が強 模のチーム（ 15名未満 ）に効果があると言われています。 拡張可能 計画と測定 開発とテスト ビジネス目標によって リリースを定義 顧客価値への対応 開発インテリジェンスを 通じて継続性を向上 継続的テスト リリースとデプロイ 3 自動化による環境の管理 セルフサービスのビルド、 プロビジョンとデプロイ提供 モニターと最適化 問題発生時の分離と 解決の自動化 顧客のKPIを達成するため 継続的に最適化 密なコラボレーションを行う自己 組 織 化（ Self-Organized ）され たチームにするには、この規模が 限度と言われてきました。しかし 信頼できる 戦略的に計画と調達 ダッシュボード・ ポートフォリオによる測定 テスト・データの管理と テスト仮想化 継続的デリバリーと統合 目標とリリースをリンク 要求の一元管理 プロジェクト・メトリクスを 測定 開発ライフサイクル情報の リンク提出と ビルドを含めた テストの一元化と テスト管理の自動化 目標を局所的に記録 部門のリソースを管理 開発ライフサイクルの 成果物の管理 継続的インテグレーションと 自動ビルドとテスト 2 企業全体の標準化と自動化 パターンベースの プロビジョンと デプロイの自動化 アプリケーションの最適化 エンタープライズ向けの 問題解決手順の活用 最近では、製品の品質やチームの 効率、納期の改善などにより、よ り大規模のチームがそれぞれの 反復できる 1 部門別のリリースを計画、 ステータスを自動化する 標準トポロジーによる 自動デプロイメント ビジネスとエンドユーザーの 目標に対する モニターイベント通知と インシデントの 解決を一元化 環境でアジャイル原則の導入を 検討するようになってきています。 IBM Software Groupには全世 経験あり リリースを計画、管理 デプロイの標準化 リソースを常にモニター 開発/運用の コラボレーション 界に５万人を超えるメンバーがい ますが、2005年よりグローバル 規模でアジャイル・プラクティス 改善の段階： 1 2 3 完全に達成 一部達成 イニシアチブ目標 図 7. DevOpsプラクティスをベースにした成熟度モデルと改善目標の例 36 P ROVISION No.80 / Winter 2014 の導入を決めプロセスの変革に ネスの価値に変えるかという「 Time to Value 」につなげ チームサイズ 10名以下の 開発チーム 何千人もの 開発者 ています ［ 12 ］ 。 コンプライアンス要求 ロー・リスク クリティカル、 監査対象 DevOpsの取り組みにかかわるステークホルダー （ 利害 関係者 ）が目的・目標を共有し、それに向けて密にコラボ ドメインの複雑さ 地理的分散 非分散 グローバル 企業の原則 プロジェクト・ フォーカス 企業全体 フォーカス 単純 複雑 ディシプリンド・ わかりやすい 新しい アジャイル ア ャイ アジ イル・ デリバリー デ バリー デリ 組織の分散 （アウトソーシング、パートナーシップ） （DAD） 協調的 レーションすることで、ニーズに合った製品・サービスを迅 速に市場に提供し、日本の競争力向上につながればと切に 思います。IBMは、今後もDevOps実現に向けてより一層、 製品やサービス、コンサルティングを強化して支援してま 契約ベース いります。 組織の複雑さ フレキシブル ガチガチ 技術的な複雑さ 均質・ シンプル ヘテロ環境、 レガシー ［参考文献 ］ ［ 1］ IBM : C-Study 2013, 2013年 図 8. ディシプリンド・アジャイル・デリバリーによる アジャイルの適用範囲の拡大 http://www-935.ibm.com/services/jp/ja/c-suite/csuitestudy2013/ ［ 2 ］ IPA : 非ウォーターフォール型開発に適したモデル契約書の改訂版を公開、 2013年 挑みました。結果として成果物の再利用性の向上によるコ スト削減、品質の向上、コミュニティー・サイトの活用によ http://www.ipa.go.jp/sec/softwareengineering/reports/20120326.html ［ 3 ］ Kent Beck（著 ） 、長瀬嘉秀（監訳 ） 、 「 XPエクストリーム・プログラミング 入門 」, ピアソン・エデュケーション、2000年 るコラボレーション促進を達成しました［ 9 ］ 。これらの経 ［ 4 ］ Paul M. Duvall, Steve M. Matyas, Andrew Glover（著 ） 、大塚庸史ほか 験を基に2012年には「ディシプリンド・アジャイル・デリ ［ 5 ］ MacCormack, A.ほか : Trade-offs between productivity and quality in バリー （ Disciplined Agile Delivery : DAD ） 」 ［ 10 ］を ［ 6 ］ David Farley, Jez Humble（著 ）, 和 智 右 桂 ほ か（訳 ） 、 「継 続 的 デ リ バ 刊行し、チームの規模、地理上の分散、組織の分散、ガバ ナンスなどエンタープライズに対応するためのアプローチ を提唱しています（ 図8 ） 。またトヨタ生産方式を源流に持 （訳 ） 、 「継続的インテグレーション入門 」 、日経 BP社、2009年 selecting software development practices、IEEE Software、2003年 リー」 、アスキー・メディアワークス、2012年 ［ 7 ］ Kurt Bittner : Continuous Delivery Is Reshaping The Future Of ALM, Forrester Research, 2013年 http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=SA& subtype=WH&htmlfid=RAL14092USEN つ「リーン」や「カンバン」と、 「 Scrum 」をハイブリッドし ［ 8 ］ Sanjeev Sharma : Introducing DevOps - Adopting DevOps to た「 Scrumban 」という手法が出現しています。アジャイ ［ 9 ］ Julie King : アジャイル変革の実施 , 2012年 ルは試行錯誤しながらこれまでの課題の解決に挑戦しなが achieve Continuous Innovation -, PROVISION No.80, 2014年 http://www.ibm.com/developerworks/jp/rational/library/common/ julie-king-interview/ ら進化し続けており、日本企業でアジャイルに対する意識 ［ 10 ］Scott W. Ambler, Mark Lines（著 ） 、藤井智弘（監修 ） 、 「ディシプリンド・ が高まり適用が増えることは間違いないと思います。 ［ 11］Grischa Ekart : DevOpsとITILを知的な方法で統合 , InfoQ, 2013年 一方 DevOpsに話を戻すと、開発と運用の協業をいか にして行うかという議論が続いています。アジャイル開発 アジャイル・デリバリー」 、翔泳社、2013年 http://www.infoq.com/jp/news/2013/05/integrate-devops-itil ［ 12 ］吉竹 正貴 : Time to Value革命 - IBM 社内 IT 部門のアジャイル開発、クラ ウドソーシングの取り組み -, PROVISION No. 66、2010年 やCI、CDをベースとしてDevOpsは進化してきた一方、 運用ではITサービス・マネージメントのプロセスである ITIL（ IT Infrastructure Library ）を重視し、相容れる ことが難しいと言われてきました。しかし最近では、ITILに DevOpsの要素を組み込むことでITIL自体も改善し、頻繁 が語られています［ 11 ］ 。日本でも2013 年 11月に開催さ 日本アイ・ビー・エム株式会社 ソフトウェア事業ラショナル事業部 ITテクニカル・セールス アドバイザリー ITスペシャリスト れた「 第 10回 itSMF Japanコンファレンス/EXPO 」で、 黒川 敦 ITILとDevOpsを議論する講演や寄稿が多数あり、総じ Atsushi Kurokawa な変化に対応することでより一層の価値を提供する必要性 てDevOpsとITILの融合が提唱されています。事実、アプ リケーション開発・保守の業務ではアジャイル開発が採用 されており、IBM 社内 IT 部門では2008年からRational Team Concertをインフラとし、リモート環境によるオフ ショア開発でアジャイルを適用しています。組織を挙げて ［プロフィール ］ 2002年日本 IBM入社。 ソフトウェア事業にてWebSphere Application Severのテクニカル・セールスとして活 動。 その後お客 様 担当SEとして SOAプロジェクトに参加し、 2009 年からRationalテクニカル・セールスと して、 ソフトウェア・ライフサイクル全般のアプリケーション開発支援を担当。 2013 年から日本におけるDevOpsとUrbanCodeの立ち上げをリード。 developerWorks Rational管理者。 中小企業診断士。 推進し、コスト削減や品質向上だけでなく、いかに早くビジ P ROVISION No.80 / Winter 2014 37
© Copyright 2024 ExpyDoc
