ここから本文です

DevOps導入で知っておきたい最大の障壁とは?

5/31(水) 11:24配信

ITmedia エンタープライズ

 以前、IBMで働いていた頃は、「DevOps」という単語が日常で使われていました。その理由は、「価値のある成果物を提供するためには“アジャイル開発とDevOps”を切り離すことができない」からです。

 アジャイル開発は、各イテレーション(反復)で実際に動くソフトを作成し、一般的にはユーザーにUIや動作を確認してもらうなどの作業を含みます。そのためイテレーション中にビジネスユーザーから運用面での課題をもらうこともあります。

 そしてDevOpsでは、信頼性の高いアプリをより早くリリースできる環境を作成することだけではなく、「継続的なデリバリー」を目指し、保守性を最大化することも目指しています。

 このようなことから、DevOpsとアジャイル開発を組み合わせて使うことで、「開発の生産性」が上がるといわれており、45%も生産性が上がったという記事もあります。

 では、実際の現場で、DevOpsはどのように受け止められているのでしょうか。

 私が今使っている「Pega」というモデル駆動の製品は、主にアジャイルもしくはDCO(AgileとWaterfallの中間)手法を使います。ある程度の要件定義をした後にUIを簡単に作成し、実際の画面をユーザーに見てもらい、フィードバックをもらうというパターンが多いです。

 そのような場面で良く耳にするのは、「ドロップダウンのリストや割引率などを変更したいというビジネスユーザーの要望がある」ということです。なぜなら、今日のビジネスでは、それらの値が毎週変わることも珍しくないからです。

 ビジネスユーザーに一部のルールや値の変更権限を委任するためには、アプリケーションの設計段階でその可能性を想定し、デザインする必要があります。また、委任するためのグループや権限なども考えながら、全体のアーキテクトを作っていく必要があります。

 「適切なルール(表示するリストやロジックで使う値など)の委任」は、ビジネスユーザーがスピーディーに対応する武器を与えるだけではなく、運用コストを大幅に削減する効果も期待できます。

 これらがDevOpsという考え方で、アプリケーションの作成段階から、運用側やユーザー側の目線に立って考え、満足度の高いアプリケーションを一緒に作っていくのです。

 ただ、DevOpsを推進するためには、その企業や部署の人たちが、従来の「依頼するだけ」の開発手法から「一緒に開発するという文化に変わっていく」必要があります。

 実際、「DevOps+アジャイル開発」を進める上での最大の障壁は、「企業文化(部署文化)」ではないかと考えています。どんなに素晴らしい方法も、その考えを理解し、一緒に動いてくれる人たちがいなければ成り立ちません。

 プロジェクトチームの最初の挑戦は、「お互いの考えを理解すること」と「結果を出すために協力をしてもらう体制」ではないでしょうか。時代が変わっても、「人を動かすことが成功につながる」というのは普遍の真理のようです。