最近のアジャイルのトレンドをキーワードで見ると「Continuous Delivery」や「DevOps」といったものが並びます。どちらも、ソフトウェアの開発だけにフォーカスをあてるのではなく、開発した後の運用にフォーカスをあてようとしています。そう、開発から運用にフォーカスが移ってきているように感じます。確かに、繰り返し作っていくということは、順に出来上がって運用に入っていくということなので納得できます。しかし、それでもまだ開発から運用に橋渡しする感じが否めません。そこで、発想を逆転してみて、運用のために開発があるのだと考えたらどうか、という話です。
Rail (HDR) / Sadi Junior Photography「アジャイル開発」は、その名の通り「開発」という行為にフォーカスを当てています。タイムボックスをきって、イテレーションを繰り返しながら、動くソフトウェアを少しずつリリースしていく。ソフトウェアを作って、繰り返すにしてもリリースすることがひとつの到達点として考えられているので、「開発」に力点が置かれるのは当たり前のように思います。しかし、本当に価値を産んでいるのは、作っている最中ではなく、実際にユーザが利用している間の筈です。
動いていないソフトウェアに価値はありません。そうであれば、プロセスの考えかたも動いている状態を保つ「運用」の方を中心に考えた方が良いのではないか、と考えました。ここで言う「運用」は、すでに完成されたものを、何事もなく動かすことだけを表すものではなく、ユーザからのフィードバックを受けて、パフォーマンスをチューニングするのは当然のこと、機能や使い勝手なども最高の状態にするべく改善していくことも含めています。
プロセスを考えるとき、「Point of Sales」と「Point of Use」で説明した通り、ビジネスとしてどこに力点を置くかということが前提になってきます。「Point of Sales」であれば、売って検収される時がお金の発生タイミングなので、開発（モノ作り）が全ての中心にきます。つまり、一括発注/請負の世界では開発中心プロセス（Development-centered Process）の方が正しくなってしまいます。一方で「Point of Use」のビジネスでは、ユーザに利用される時が価値が発生するタイミングなので、運用（動く状態）を全ての中心に置くべきです。よってウェブのサービスをするようなサービス企業においては、運用を中心に置いたプロセスが向いているように思います。
運用を中心に考えるというのは、ソフトウェアが動いている状態を正常の状態として、その動き続ける中でどのようにユーザからのニーズや要件を反映して改修をしていくか、となります。Continuous Deliveryに限らず、小規模リリース、テスト駆動開発、継続的インテグレーション、ソースコードの共同所有などの多くのプラクティスが、「運用しやすさ」を軸にするとしっくりきます。持続可能性（sustainability）を重視するのも運用中心ならば当たり前です。開発と運用の協業というDevOpsも当然のことで、むしろ分業せずに運用担当者が開発をする位が効率的です。
このように「Point of Use」を重視するウェブのサービス企業において有効な、運用を中心として考えたソフトウェア開発プロセスを「運用中心プロセス（Operation-centered Process）」と呼ぶことはどうでしょうか。
アジャイル開発と違い、運用中心プロセスが使えるケースはあえて限られていると考えます。ターゲットはウェブを使ったビジネスで使うソフトウェアが対象になるでしょう。例えば、リーンスタートアップの中でも特にウェブのビジネスをしようとする場合には、運用中心プロセスでソフトウェアを作っていく方が良いはずです。リーンスタートアップの両輪は「顧客開発モデル」と「運用中心プロセス」です。
テスト駆動開発に初めて出会ったとき、テストから先にコーディングするというパラダイムシフトに戸惑いました。ソースコードは普通、部品を積み上げるように作っていくものだと思い込んでいたのが、機能に必要な部分から作っていくためにテストから作ることが出来るとわかったとき、自然と受け入れることができるようになりました。テスト駆動開発はゴールを先に置く考えかただったのです。運用中心プロセスも同じです。従来の開発があって運用をするという考えかたから、180度変えなければいけません。まずは動くソフトウェアの運用がありきです。
最近「アジャイル」という言葉の適用範囲が広がっているように感じています。それ自体は言葉が広がるので良いのかもしれないですが、結局「何をやったらアジャイルなのか」わからなくなる時もあります。なんでもかんでもアジャイルという風潮は好きではないのですが、それは止めることも出来ませんので、ウェブのビジネスをしている企業に特化した名前があると、背景が共有されて良いかと思いました。「ビジネス中心」が良いか「顧客中心」が良いか、など考えましたが、それらにしてしまうと、どんなビジネスでも使えてしまうので、かえってわかりにくいと考えたんですよね。
ずっと、ソフトウェアはビジネス（お金の入るところ）と、もっと密接に寄り添うようになっていくと良いのに、と考えていました。一括発注/請負の中でアジャイルをしようとするとビジネスに直結することはならないので、経営に対する現場からの改善や抵抗といった風に映ってしまい対立を産みやすいと感じています。ビジネスにもっと近づく、つまりソフトウェアへの貢献が経営にシンプルに結びつくには、ビジネスモデルを前提とした開発プロセスがあると良いはずです。まだ思いつきの域を出てないですが「運用中心プロセス（Operation-centered Process）」で考えてみるのは良いかもしれないと感じています。
「運用中心プロセス」の具体的なところはこれから考えますが、一緒に考えてくれる方がいたら是非ご意見ください。
