The Doppler Quarterly (日本語) 春 2017

エクスペリエンス設計、アジャイル、 DevOpsの統合 Salina Brown、 Chett Rubenstein、 Ray Young アジャイルな関係を確立し、ユーザーフィードバックを早期に捉え、迅速にソフトウェアを開発することで利益を得るのは簡単です。とはいえ、ほとんどの企業がそうした環境の構築に苦心しています。 Hasso Plattner Institute of Design at Stanford (the d-School) の主要な創設者で同校の教員である Dr. James Patell は、人間中心の設計を信じており、それは、真の共感を確立することで達成するとしています。同氏はこう説きました。リューションに絶えず取り込むことができません。DevOps とエクスペリエンス設計、アジャイル、 DevOps の統合を積極的に採用することで、市場の変化に対して繰り返し迅速に対応できるようになります。 DevOps で重要なのはソフトウェアではなく、コミュニケーションとコラボレーションです。ソフトウェア工学、運用、製品の間でコラボレーションとコミュニケーションを促進する DevOps と同様に、エクスペリエンス設計、アジャイル、 DevOps の統合は、ソフトウェア工学、製品、ユーザーの間でコラボレーションとコミュニケーションを促進します。しかし、ソフトウェア工学、運用、製品、ユーザーの間でコラボレーションを管理できるのであれば、それはそれで、かなりの成果です。「次の 2 つのブランクを埋めてください。ユーザーは __ するのによい方法を求めています。なぜなら __ だからです。なぜなら、の部分が重要です」。しかし、 CTP は、自社の SDLC での迅速な展開によって、継続的なフィードバックループを可能にし、価値をすぐに提供できるようにしています。私たちは、さらに適切な表現を次のように考えます。「3 つのブランクを埋めなければなりません。ユーザーは ___ するのによい方法を求めています。なぜなら ___ だからです。私たちは、明日朝の本番環境へのベータ版リリースに ___を展開できます」。 Dr. Patell の考えを拡張して、ソフトウェア開発のライフサイクルにおける DevOps の機能を説明しました。エクスペリエンス設計、アジャイル、 DevOps の統合では、ユーザーフィードバックを早期に捉え、コラボレーションの問題の解決を早めることで、この「なぜなら」を明確に述べることができます。しかし、迅速な「展開」がなけば、こうした有益な情報を製品またはソ 62 | THE DOPPLER | 2017 年春号サイロをなくすほとんどの大企業が、イノベーションではなく、予見性と効率性を目的とする最適化を望む集中的なリーダーシップに従っています。機能ごとに静的なチームを構成し、エンジニアなら当然プログラミングといったように、チームメンバーのアイデンティティをその機能に結びつけます。チーム間のアジャイルな関係の確立に必要な組織変革により、エクスペリエンス設計、アジャイル、 DevOps の統合と DevOps の方法論が可能になりますが、往々にして個人と組織のアイデンティティが脅かされます。そうなると、チームメンバーは適切に定義された役割をこなすに留まり、サイロ化を助長し、協力を拒みます。私たちはあなたが現行の組織モデルを廃止して権限を分散すること、または、従来の肩書きを「素晴らしすぎるマネージャー」のように変えてしまうことを提案しているわけではありません。しかし、私たちは、チームメンバーが、外に目を向けるように促され、役割やチームの機能の外でコミュニケーションを支えるようになると、問題解決が早まると考えています。

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