第3回:「スピード」と「アジリティ」その①

ソフトウェアアーキテクト四方山話

みなさんこんにちは。システムエグゼの相田です。

前回のコラムは力を抜きすぎたので、今回はちょっとだけ真面目に。ちょっとだけ。

さて、第三回目は「スピード」と「アジリティ」です。

xTech やデジタルトランスフォーメーション(DX)に関するご相談をいただいた際に、お客様にはどうしてもこの違いをご理解いただかなければならないのですが、この説明がなかなか難しいので・・・

システム開発は1日にして成らず・・・

「開発スピード」は、我々 SI ベンダーにとっても非常に重要なテーマの一つです。当然ながら、開発期間を可能な限り短くしお客様へのデリバリを速やかに行う事が ビジネス上非常に重要です。

しかしながら現実問題として、日本情報システム・ユーザー協会(JUAS)の調査資料にもあるように、IT プロジェクトには「最適な工期」が存在します。JUAS の調査によれば「むやみやたらと短納期にするとプロジェクトが炎上する」事が示されていますし、実際にその通りだろうと思います。
(余談ですが JUAS さんはユーザー企業の情シスさんの団体です。我々ベンダ側の団体ではありません)

1人が10日かけて作るシステムを、10人集めれば1日で開発出来る、というものでは無いですよね。

特に我々 SI ベンダーは通常「請負契約」でお客様から発注いただいております。請負契約というのは、要するに「完成品」を売ってお金をいただくビジネスであり、契約上「完成品」の定義についてお客様と合意する必要があります。
(これも余談ですが、これは民法の規定に従っているのであり、我々ベンダが勝手にそう考えているわけではありません)

「完成品」の仕様で合意し、それから設計を開始し、製造し、「完成品」である事を証明するためにテスト、テスト、テストする、これがいわゆるウォーターフォール型開発モデルです。ウォーターフォール型の開発は、このような契約モデルに対応して確立された開発モデルなわけです。 従って「完成品」をいかに短い期間で完成させるか、それが SI ベンダにおける請負契約での「スピード」の考え方です。

しかしながら。

「それでは間に合わない」というシーンが多くなっているのですよね・・・

バスで旅行 Vs バイクでツーリング

「xTech」や「デジタルトランスフォーメーション(DX)」といった言葉で表現される「IT を使った新たなビジネス領域」は、まさに日進月歩の領域であり、半年先は闇であり、生き馬の目を抜くような競争の世界です。

競争相手の動きによっては、数ヶ月以内に同等のサービスを開始しないと競争優位性を失いかねなかったり、差別化を図るため即座に別のサービスを開始しなければならなかったり。企画も計画もその後の開発も、ゆっくりじっくりやっている暇なんてありません。正直に言って、従来のようなシステム開発の枠組みでは無理です。ところがクラウドベンダーやベンチャー企業、スタートアップ企業の方々はそれを実現していますよね。何故そんな事が実現出来るのでしょうか?

それはズバリ、彼らが実現しているのは実は「スピード」ではなく「アジリティ」だからです。

SA_0826.jpg

この二つは似て非なるもので・・・
最近良い例えを思いついたのでご紹介すると・・・

この二つの違いは「バスに乗ってゆく団体旅行」と「週末にバイクで繰り出すツーリング」の違いなのです。

バスに乗ってゆく団体旅行

sa_01.jpg

システムの「完成品」とは、言ってみれば「旅行に参加する人数と、全員の目的地が決まっている団体旅行」です。この場合は(ご存知のように)計画が重要ですし、バスのような乗り物を確保し大人数を一度に移動させた方が「効率的」です。

計画し、バスを用意し、一箇所に全員を集めて乗せて、全員をまっすぐ目的地まで運ぶ方が「スピード」が出ます。あと、バスの運転スキルを持っている人が少数で済みます。

逆に、この旅行は「一人だけ速く移動しても意味が無い」「急に目的地を変更する事が出来ない」「旅行費用を一度に払う必要がある」わけです。

週末にバイクで繰り出すツーリング

sa2_0826.jpg

では、システムの「完成品」という条件を取り去った場合はどうでしょうか。つまり「旅行に参加する人数は不確実で、全員の目的地が一箇所に決まっているわけではない」旅行です。
これはバイクや車が趣味の方が週末に繰り出すツーリングに当たります。不確実な要素が多いので、計画は大雑把にすべきですし、一人ひとりが自分のバイクや車といった「小さな単位」で移動した方が「効率的」です。
(この条件ではバスを予約出来ませんよね)

計画は大雑把に速やかに、乗り物はバラバラで、個々人が最初の目的地を目指すものの、状況に応じて目的地を変えたり旅行をやめたりする事も出来る。この状態が「アジリティ」がある状態です。

逆に、この旅行は「最初に完全に計画する事が出来ない」「誰がいつ目的地に着くのかは移動してみないと分からない」「全体のトータル費用が不明(※)」なわけです。あと、ほぼ全員がバイクか自動車の運転スキルを持っている必要があります。

・・・

xTech や DX の領域では「これまでやった事が無い新しいビジネス」が要求されます。新ビジネスの世界は「最初に完全な計画が出来ない」「最終的にどのようなビジネスになるかは市場状況次第」「最終的な投資額がどうなるかはビジネス状況次第」な世界であり、「スピード」よりも「アジリティ」が重要になって来るわけです。

では、システム開発において「アジリティ」を実現するにはどうすれば良いのでしょうか?

アジリティ、アジリティ、アジリティ・・・アジャイル!

もうアジリティ(agility)という言葉を使った時点で半ば答えを言っているようなものですが、つまりはアジャイル(agile)開発というのは、アジリティを実現するためのアイディアなのです。

「アジャイル開発はスピードが速い」と表現する事は間違いではありませんが、実はかなりの誤謬を含むわけです。実際にはウォーターフォール型開発の方がスピードが速い状況が多々あります。つまり、「バスに乗ってゆく団体旅行」の場合であり、いわゆる基幹システムや業務システム開発のほとんどがこちらのタイプです。
(企業の基幹業務って、そんなにコロコロ変わりませんので・・・)

これに対して xTech や DX で開発されるスマホアプリや SNS と連携する Web API、何らかの会員向けサービスなどは「他社との競争上とくにかく急ぐ」「先行しないとビジネスにならない」「リリースは急ぐしお客様の反応次第でどんどん改修する必要がある」「現段階では、最終的にどんな機能が必要になるか予測出来ない」といった開発になりがちです。こんな場合はスピードよりもアジリティを優先させなければならないので、まさにアジャイル開発の出番です。

ただしアジャイル開発は、1台のバスではなくたくさんのバイクを用意しなければならないように、或いは一人のバス運転手ではなく多くのライダーを揃えなければならないように、計画を立てないのではなく「立てられない」事を前提に、我々ベンダーだけではなく、お客様側のやり方も変えていただかなくてはなりません。

アジリティ実現のために何が必要なのかと言うと・・・

・・・と、少々長くなってしまったので、続きは次回、「スピード」と「アジリティ」その②でお話します。

それでは、また第四回(続けば)でお会いしましょう。