まったく節操がないとお叱りを受けそうですね。先週のブログで「システムインテグレーション崩壊のすすめ」を声高にさけびながら、今度は「クラウド時代のSIビジネス」ですから（笑）
でも、先週のブログをご覧頂いた方はご理解頂けたと思いますが、お客さまの価値創造のためにテクノロジーやプロセスをインテグレーションする「顧客価値としてのSI」は、その必要性を失うことはありません。崩壊すべきは、人月単価で金額を決めておきながら瑕疵担保という完成責任を負わされる「収益モデルとしてのSI」です。
では、「顧客価値としてのSI」とは何でしょうか。
システムを所有しないクラウドは、その資源を必要に応じて自由に拡大、縮小できる「スケール」、変更や変化に柔軟、迅速に対応できる「アジリティ」、意志決定したことを直ちに実行に移せる「スピード」といった価値をもたらしてくれます。ただ、このような価値は、これまで通りのウォーターフォール型の開発では、引き出すことはできません。
ではどうすればいいのでしょうか。その答えは、「作らないこと」です。つまり、クラウド時代のSIビジネスは、「作らないシステムインテグレーション」を目指すことなのです。そのことによってクラウドの価値を最大限に引き出すことができ、お客様は幸せになれるのです。
できるだけたくさん作ることを目指してきたこれまでのSIビジネス。作れば作るほど、工数が積み上がり、売上が拡大します。
しかし、現実には、お客様は、支払いを減らしたいので少しでも工数を減らして欲しいと望みます。しかし、これだけの工数がなければ、要求機能を実現できないとSI事業者に主張されれば、それを受け入れざるを得ません。
それは、開発の実践から離れているユーザー企業の情報システム部門が、工数の妥当性を判断できないからです。だから、複数企業の見積もりを比べて、そこに大差がなければ、だいたい妥当な工数だと判断します。そして、単価交渉の末、安いところに仕事を依頼しているのが実態です。
しかし、クラウド時代を迎えると、このやり方は、通用しなくなります。システム資源や機能は、サービスとしてクラウドから提供されます。必要なプログラム・モジュールもフレームワークやオープンソースとして提供されます。それらをマッシュアップして作ることが常識となるでしょう。
必要となるリソースが変わる、あるいは、もっと使い勝手がいいリソースが出現すれば、利用するサービスを変更することも比較的容易にできます。これまでなら、「買ってしまったから使わなくてはいけない」という縛りから逃れることはできませんでした。所有しなければ、そんな縛りを気にする必要はなくなります。
クラウド・コンピューティングは、コンピューティング資源を必要なときに必要なだけ使える仕組みです。見方を変えれば、いつでもやめられる、変更できる仕組みでもあります。
このような前提を踏まえた「作らないシステム･インテグレーション」を目指すことが、お客様の幸せになるのです。
「できるだけたくさん作ることを前提としたこれまでのSI」は、お客様の幸せとは反するものです。お客様に幸せをもたらさないビジネスは、いずれ排除されます。
ただ、全てがマッシュアップで実現できるはずもありません。必ず、お客様独自の業務プロセスやニーズに対応した作り込みは必要になります。両者を組み合わせてシステムを開発することが必要となります。そこで威力を発揮するのが、アジャイル開発です。
アジャイル開発とは何かという話は、既に多くの方が語られていますので、ここで申し上げる必要もないかとおもいます。そこで、ここでは、これからのSIビジネスのひとつの可能性として私が関心を持っている「アジャイル型請負ビジネス」について言及させて頂きます。
「アジャイル開発」の狙いは次の言葉に集約されます。
- 徹底した現場主義により、エンドユーザーの満足度を追求すること。
- 改善の積み重ねにより、高い品質を実現すること。
- ビジネス価値の高いプロセスや機能を優先し、作らなくていいものを作らずに、時間とコストを最適化すること。
システム開発は、要件定義からはじまります。しかし、ユーザーの要求は時間と共に変化します。ビジネス・サイクルのスピードが速まるなか、要求変化のスピードもまた早まっています。全ての要件を定義することからスタートするウォーターフォール開発では、この変化への対応は、容易ではありません。
また、早期に仕様確定しようとすると、ユーザーはリスクを見越して何でも仕様に入れようとし、その結果、使われない機能が盛大に作り込まれることにもなります。いざ、完成してみるとそんな機能は、使えない、使わないとなり、無駄な工数と時間を費やしただけになってしまいます。しかも、瑕疵担保がありますから、工数に関係なく、現場が納得するまで変更要求に応えて改修しなければなりません。
アジャイル開発では、このような事態を避けるために、開発すべき機能やプロセスをMVP(Minimum Viable Process)という検証可能な最小単に分割し、この単位で開発を積み上げてゆきます。その優先順位は、ビジネス上の重要度で決定されます。開発は、MVP単位で開発し、完成すれは、その都度リリースして、ユーザーの検証を仰ぎます。これを繰り返し、システム全体の完成度を高めてゆくのが、アジャイル開発の考え方です。
ビジネス上の重要度で優先度を決定するとは、「このプロセスがなければ、このシステムは成り立たない処理プロセス(ボディ・プロセス)を優先させること」です。
例えば、例外処理やUIなどは、このボディ・プロセスに付帯するもので、重要性は、ボディ・プロセスよりも低くなります。そんな中でも、頻発する例外処理や誤操作の起きないようにするためのUIなどは、なくては困りますから、優先度はこれに続くことになります。このように決められた優先順位に従って、順次積み上げてゆくことで、システムの完成度を上げてゆきます。
プロジェクトの途中で優先順位が変わっても、開発に着手していないプロセスであれば、変更可能です。その結果、ユーザーの最新要求を反映させることが可能となります。
また、リリースはMVP単位で行われます。その度にエンドユーザーのフィードバックを得られるので、プロセス毎に改善や変更を施し、ユーザーのニーズを反映させます。さらには、リファクタリングや継続的インテグレーションの手法を使い、コードの美しさと完成度を高めてゆきます。つまり、プロセス単位で高い品質を担保し、前工程の問題を後工程に引き継がず、確実にMVP単位で完成させてゆく開発手法でもあるのです。
このような手法を駆使することで、先に示した3つの狙いを実現しようというのが、アジャイル開発です。
また、アジャイル開発では、リソースと納期をあらかじめ固定し、開発するプロセスの数と金額を決め、その範囲において開発を行います。そして、ビジネス価値で決められた優先順位に応じてプロセスをひとつひとつ完成させてゆきます。
重要なプロセスから完成させてゆきますから、リスクはフロント･ヘビーになります。しかし、早い段階でユーザーの検証と完成度を高める取り組みが行われますので、期間後期になると重要なプロセスの完成度は相当高いレベルにあります。また、後期になればなるほど重要度の低いプロセスの開発ですから、全体に及ぼすリスクはほとんどありません。
また、最初の段階で予算と開発するプロセス数を確定できますので、改善の努力次第では、原価を低減させ、利益を拡大させることも可能となります。
これに対して、ウォーターフォール型では、先に要求仕様を全て確定してから、開発を始め、全てが完成してからユーザーの検証となります。そのため、リスクは後ろに片寄せされ、最後になって大きな負担を強いられる可能性があります。何を改善すればいいかも、最後にならなければ分かりません。そのため、仕様書に忠実であることに専心せざるを得ず、開発の過程で現場の要望に臨機応変に対応する機会を与えられることはありません。
お客様の現場の反応が見えない開発者、どんなシステムができあがってくるのか最後にならないと分からないエンドユーザー。両者はそんな不安を抱えながら開発が進められているのです。
だから、「ウォーターフォールは悪で、アジャイルは善」である。私は、ここでそんなことを申し上げたいのではありません。変更の可能性は少なく、あらかじめ要件をしっかりと確定しなければできないシステムもあります。それは、ウォーターフォールがふさわしいかもしれません。しかし、ビジネス・サイクルやユーザー嗜好がこれまでになく早いスピードが変化する中、あらかじめ要件を全て確定できるシステムが少なくなってきたとこともまた事実です。
また、クラウドの時代になり、作らないシステムインテグレーションが広く受け入れられるようになれば、開発に求められるスピード感も大きく変わってくるでしょう。
こういう変化に対応するための手段として、アジャイル型請負開発は、ひとつの選択肢になるのではないでしょうか。
「徹底した現場主義なんて、現場の業務が分からなければできません。まずは、そういう勉強をさせてからでないと・・・」
マネージメントや経営者から、こんなご意見をいただくことがあります。しかし、これは順番が違うような気がしています。現場にエンジニアを送り込み、経験を積ませることで、結果として現場の業務を学ばせるべきです。
マネージメントや経営者が、リスクを冒す勇気が必要です。エンジニアは、自分の努力によってエンドユーザーの喜ぶ顔が見えるわけですから、きっとモチベーションは上がるはずです。
「アジャイル型請負開発」は、「クラウド時代のSIビジネス」のひとつの選択肢になるはずです。ただ、これだけで全てがうまく行くとも思いません。前回のブログでも申し上げたとおり、多様な選択肢を模索すべきです。唯一確かなことは、「人月単価の積算+瑕疵担保」のビジネス・モデルが難しくなることです。
そろそろ、重い腰を上げるべき時期ではないでしょうか・・・
補足———-
ここで紹介させて頂いた「アジャイル型請負開発」については、戦略スタッフサービスの社長である戸田孝一郎氏から大いにインスパイヤーされました。彼は、単なる可能性としてではなく、既に実践の現場で成果を上げています。ここに紹介させていただいた資料は、そんな戸田氏からご教示頂いたものを私なりにアレンジしたものです。もし、誤りや説明不足があれば、それは全て私の責任に帰するところです。ただ、こういう可能性を少しでも多くの皆さんに知ってもらいたいという想いから、分不相応とは思いつつも紹介させていだきました。ご容赦頂ければ幸いです。
■ Facebookで、是非ご意見をお聞かせください。
■【ITソリューション塾・第14期】日程と内容が決まりました!
開始は10月2日(水)から、
毎週水曜日18:30-20:30
全10回です。
今回も既に多くの参加意向のご連絡を頂いております。恐れ入りますが、正式のお申し込みの前に、早々にご意向だけでもお知らせ頂ければ幸いです。
今回もこれまで同様、テクノロジーやビジネスの最新トレンドを抑えつつも、表層的なキーワードを追いかけるのではなく、トレンドが生みだされた歴史的背景や顧客価値など、トレンドの本質を抑えることを力点に置くつもりです。
新たたテーマや改善点としては・・・
- 仮想化をSDxの視点で捉え直しそのビジネス価値を整理する。
- SIビジネスに危機感が漂う中、現場価値の徹底追求と現物主義により、顧客満足と高い利益を実現している「アジャイル型請負開発」の実践事例の紹介。
- ストレージとデータベースのテクノロジーの大きな変化がITのプラットフォームやアプリケーションの開発をどう変えるのか。
- ビッグデータの本質と新しい動きを踏まえたビジネスの可能性。
- セキュリティやガバナンスの原理原則とクラウド･ファーストに向けた取り組み。
- システム･インテグレーション崩壊とポストSI時代のビジネス戦略。
・・・など、これからの変化を先読みしつつ、その次の手を考えるヒントを提供したいと考えています。
