The Doppler Quarterly (日本語) 春 2017 | Page 65

DevOps に対する
熱意が高まりつつある。
私たちのセグメントで
十分に機能を検証したので、
本番環境に統合しよう。
クラウドはまだ最小限か。
現実が見え始める :
この DevOps 担当者は
一体誰なのか。
素晴らしい
プロトタイプが
完成した。
幹部とお客様が
データプロトタイプを
気に入ってくれて
予算が増えた。
アジャイルな関係が
築かれる前
何を構築しているのか。
DevOps 担当者は
エクスペリエンスデザイナーと
連携しているのか、または
ソフトウェアエンジニアと
連携しているのか。
JIRA の谷底 :
この JIRA のチケットは
何を意味するのか。
「...できるようにすべての
データを確認したい。」
図 1: アジャイル関係の浮き沈み
スタートアップやコンサルティング会社でよく見られる、分散的
で変化できるチームでは、共通目標、個人目標、チームアイデン
ティティの継続した再編成や見直しと、相乗的な結果が得られ
る新しい戦略の探求を行わざるを得ません。動的、協力的、相
乗的で変化できるチームは、エクスペリエンス設計、アジャイ
ル、 DevOps の統合、 DevOps、アジャイル方法論をすでに実
イノベーションに向けたコラボレーション
CTP では、クライアントにも設計と開発競争に深く関わっても
らいます。また、私たちは、 CTP の内部とクライアントの外部と
の間でコラボレーションを促進します。
践しているように見えます。 • 継続的なフィードバック
革新的なソリューションを提供するアジャイルチームの構成に • 継続的な統合
は次が必要です。
• 製品オーナー
• エクスペリエンスデザイナー
• 設計者
• ソフトウェアエンジニア
• QA
• IT 運用
• 継続的な製品の繰り返し
• 継続的な展開とデリバリ
ソリューションが顧客、ひいては企業にもたらす価値について、
近視眼的に考えることを止め、問題を協力して解決すると、す
べての関係者が利益を得ます。では、チームが、エクスペリエン
ス設計、アジャイル、 DevOps の統合、アジャイル、 DevOps 方
法論の採用を受け入れるために、どのように支援をすればよい
でしょうか。具体的な手順を次に示します。
1. 以下のように、製品、設計、エンジニアリング部門に知識を
広く分散するように働きかけます。
• 設計と製品の会議にソフトウェアエンジニア、設計者
を招きます
2017 年春号 | THE DOPPLER | 63