DevOpsというバズワードに流されないために：特集：DevOpsで変わる情シスの未来（5）（2/4 ページ）

[内野宏信，＠IT]

アジャイルが難しい本当の理由

編集部　DevOpsの核となるアジャイル開発も、それ自体が目的化しがちな傾向があるようです。しかしそうした問題をクリアした上でも、アジャイルは大規模な企業システム開発には適用が難しいといわれていますが、原因は何だとお考えですか？

鈴木氏　それも、そもそもアジャイルが向かない状況でアジャイルを適用しようとしていることに問題があると思います。アジャイル実践には幾つかのポイントがあります。中でも開発者とビジネスサイドの人間が対話をしながら、開発要件の優先度判定をすることが核となります。しかし、この優先度判定を確実に行うためには、共通理解という土台の上で「この要件を変えよう」とか「この要件を追加しよう」といった具体的な議論を交わす必要がある。つまり「これから作るものに対する共通理解」という土台がしっかりできていないと、アジャイルをやろうとしても有効な対話ができずうまくいきません。

「共通理解」という土台がなければビジネスサイドと開発サイドが有効な議論を行うことは難しい

　逆に運用の保守フェーズでアジャイルが向くといわれているのは、土台がしっかりしているためです。つまり、システムというモノが実際にあり、エンドユーザーも使っている。従って、具体的かつ正確な議論をしやすいため、アジャイルは非常にやりやすくなるんですが、逆に「新規システム開発のため探索的に始めなければならない」場合、アジャイルはなかなかできないのが現実だと思います。

　なぜなら、ビジネスサイドはソフトウェアやシステム開発のことは「よく分からない」というケースが多く、「あれを作ろう、これを作ろう」と開発の優先順位を付ける際、そのために必要となるシステムの規模、作業工数などについての共通理解が生まれにくいんですね。

　特にこの共通理解はシステムとビジネス、双方について求められるのはもちろん、「あれ」「それ」といった言葉も通じるような、日頃からの人間関係――例えば、「ビジネスサイドも開発サイドも自社の社員である」といったこともポイントになります。新規システムを作る時こそ市場の反応を見ながらアジャイルで作るべきだという意見もありますが、そうした共通理解がなければ最初にタスクリストを作ることも難しいと思います。

DevOps実践の現実解

編集部　DevOps実践の上でも、ビジネス、開発、運用の対話が鍵になるとされています。では、SIerとして数多くの開発案件を受託されている貴社の場合、どのようにDevOpsやアジャイルを適用しているのでしょうか。

鈴木氏　弊社も当然、最初は顧客企業の業務のことをよく知りませんから、会話を軸に業務を理解し、顧客企業との共通理解という土台を構築する作業から入ることになります。従って、そこではアジャイル開発は行いませんし、行うべきではないと考えています。ウォーターフォールで始めて、まずは満点ではなく合格ラインのシステムを作ることで共通理解の土台を固めます。その上でアジャイルに移行してスピーディに改修を進めるといったケースが多いです。

　ウォーターフォールの美点は、ある程度、全体観を固めないとフェーズを進められないことにあります。この手法を使うことで、システムというモノがない状態でも、まずは設計を通じて全体観をしっかりと作ることができる。これを端からアジャイルで作っていく方法もありますが、あとで矛盾が生じるリスクを避けるために、まずはウォーターフォールでモノという土台をしっかりと作ります。

　その上で、スクラムやイテレーションを回して調整していく。例えば、メイン機能のサブ機能を新しく作ろう、少しアレンジして再構築しようといった場合も、モノが既にあれば議論しやすいですし誤解も防ぎやすいですよね。もちろん、ウォーターフォールの方が優れているといった話ではなく、土台を作るという目的に照らして採用しているにすぎません。

　リーンスタートアップの手法を最初に取り入れるのも良い方法だと思います。というのも、この手法では最初にビジネスモデルに基づいて何を作るかを明確化するための「プロダクトキャンバス」を作る。これは従来の要件定義に比べるとロジックを組み立てるのがはるかに大変なんですが、その分、ビジネスサイドの人にも参画してもらい共に土台を作ることになる。これができると、そのシステム／サービスをどのように評価すべきかという評価指標の仮説ができる。後はその仮説を検証・改善するスタイルになるので、アジャイルに移行する上で非常に有効なんですね。

　最初にリーンスタートアップで顧客企業と共にロジックを組み立て、その上でウォーターフォールで土台となるシステムを作り、それ以降はアジャイルに移行するといったケースは弊社でも多いです。何よりビジネスサイドが仮説を立てて、それに対して開発サイドが何ができるか考えるというスタイルは非常に健全な関係だと思います。

編集部　あくまで課題や目的主導でウォーターフォール、アジャイル、DevOpsを使い分けるのですね。

　そうですね。DevOpsにしても、まず共通の土台があった上で、アーキテクトの知見・観点を持つ人間がステークホルダーと協議し、調停をしながら進めていきます。中には開発だけ受託し、運用は顧客企業の情報システム部門が行う、といったケースもありますが、そうした場合も共通の土台に基づき、企画・開発・インフラ・運用という各担当業務が連携できるような体制を調整、整備します。

　こうした共通の土台の上でプロジェクトを進めるスタイルは、システム開発のプロではない人たちの目的とニーズを細やかにくみ取り、より速く実現していく上で、必然的に形成されていった経緯があります。ウォーターフォールがやりたい、アジャイルがやりたいといった形ではなく、後から振り返ったときに「あ、これはアジャイルだね」「DevOpsだね」といったことを確認できるようなイメージでしょうか。あくまで目的主導のプロジェクトがシステムのエンドユーザーに最も納得いただきやすい形だと思っています。