DevOps実践の鍵と、情シスの新しい役割：特集：DevOpsで変わる情シスの未来（4）（2/3 ページ）

[内野宏信，＠IT]

一般的な企業にとって、やはりDevOpsは非現実的なのか？

編集部　では、そうした企業が「動き続けるビジネス」に追従するシステムを作る場合、アジャイルやDevOpsを適用するのは現実的に見て難しいのでしょうか？

契約、発注、セキュリティ、ガバナンスといった要素で各部門が組織的に分断されている場合は「対話」が大きな鍵を握る

平鍋氏　確かに難しいのですが、ビジネス、システムを取り巻く環境が変化している今、アジャイルやDevOpsが提示する考え方は、真に役立つシステムを作る上で無視できないものだと思います。そこでポイントになるのが各種制約の解消――より具体的に言えば、アジャイルの根幹である“対話”に実践の鍵があると考えます。

　例えば先の委託開発の場合、「システムを作る人」（開発）や「システムを提供する人」（運用）が一次受け、二次受けといったピラミッド構造になっている場合も多いですし、個々人の視点でピラミッドの中を見渡せば、多数の承認プロセスが重なっていることになります。「何らかの障害が起こったときの責任特定の問題」なども存在します。つまり、各組織とも職務の階層・権限構造の中に、開発・運用プロセスがマッピングされている。もちろん、相対的に適用しやすいとお話したWebサービス分野の企業にも壁や制約は存在します。例えばITガバナンスやセキュリティなどへの配慮から、開発部門と運用部門が互いの業務範囲に立ち入ることが難しい場合があります。

　しかし、ここで「制約があるからできない」と考えてしまうと前に進めない。そうである以上、立場、視点が異なる人同士が、それぞれの知を持ち寄って対話をする必要がある、と発想を転換する。そうすれば制約を解消し、連携・協働して良いシステムを作るための方法がたくさん出てくるはずです。

「作る人」「提供する人」「使う人」まで含めた「対話の円環」を作る

　ここであらためてDevOpsの定義を振り返れば、その解釈にもよりますが、開発を行う「作る人」、運用部門である「提供する人」たちが対話を行い、皆で制約を解消して連携・協働しようという概念が、すなわちDevOpsですよね。

　さらに、この対話にB to C、あるいはB to B市場のエンドユーザー、つまり「使う人」まで入ると、システムのフィードバックが得られて“対話の円環”ができる。この円環を市場のコンシューマにまで拡大したフィードバックループが「リーンスタートアップ」になるといえるのではないでしょうか。こうした対話の円環をどこまで広げていくかは、システムの目的、規模、内容によって変わってきますが、いずれにしても、ポイントはあくまで対話の場作りにあります。

関連記事：書籍でたどる「リーン」の本質

　ただ、ここで気を付けたいのは、「アジャイル／DevOpsありき」で考えることなく、要件に応じて最適な手法を選ぶことです。例えば、非常に高品質なシステムが求められる製造業の組み込み開発の現場では、まずアジャイル開発でプロトタイプを作成してスピーディに試作開発を積み重ね、最適な設計とコストを見極めた上で、ウォーターフォールで量産システムを開発する、といった実践的な手法が採られます。

　「動き続けるビジネス」を捉える上では、アジャイルやDevOpsは確かに重要な手段になります。しかし何より大切なのは、「DevOpsをやろう」とか「アジャイルをやろう」と考えるのではなく、「どうすれば今より効率が良く、品質が高く、利益が出るシステム、そしてエンドユーザーがもっと笑顔になるシステムを作ることができるのか」と考えることです。これらの全てを取れなければ、「優先順位は何か」を対話で共有することから始めるだけで、現場のモチベーションも上がり、一体感の中で、その最適解を実践することにつながるのだと思います。それがDevOpsの“ハート”だと思うんです。

参考リンク：「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」（slideshare）