クラウド時代のSIビジネスと「アジャイル型請負開発」

まったく節操がないとお叱りを受けそうですね。先週のブログで「システムインテグレーション崩壊のすすめ」を声高にさけびながら、今度は「クラウド時代のSIビジネス」ですから（笑）

でも、先週のブログをご覧頂いた方はご理解頂けたと思いますが、お客さまの価値創造のためにテクノロジーやプロセスをインテグレーションする「顧客価値としてのSI」は、その必要性を失うことはありません。崩壊すべきは、人月単価で金額を決めておきながら瑕疵担保という完成責任を負わされる「収益モデルとしてのSI」です。

では、「顧客価値としてのSI」とは何でしょうか。

システムを所有しないクラウドは、その資源を必要に応じて自由に拡大、縮小できる「スケール」、変更や変化に柔軟、迅速に対応できる「アジリティ」、意志決定したことを直ちに実行に移せる「スピード」といった価値をもたらしてくれます。ただ、このような価値は、これまで通りのウォーターフォール型の開発では、引き出すことはできません。

ではどうすればいいのでしょうか。その答えは、「作らないこと」です。つまり、クラウド時代のSIビジネスは、「作らないシステムインテグレーション」を目指すことなのです。そのことによってクラウドの価値を最大限に引き出すことができ、お客様は幸せになれるのです。

できるだけたくさん作ることを目指してきたこれまでのSIビジネス。作れば作るほど、工数が積み上がり、売上が拡大します。

しかし、現実には、お客様は、支払いを減らしたいので少しでも工数を減らして欲しいと望みます。しかし、これだけの工数がなければ、要求機能を実現できないとSI事業者に主張されれば、それを受け入れざるを得ません。

それは、開発の実践から離れているユーザー企業の情報システム部門が、工数の妥当性を判断できないからです。だから、複数企業の見積もりを比べて、そこに大差がなければ、だいたい妥当な工数だと判断します。そして、単価交渉の末、安いところに仕事を依頼しているのが実態です。

しかし、クラウド時代を迎えると、このやり方は、通用しなくなります。システム資源や機能は、サービスとしてクラウドから提供されます。必要なプログラム・モジュールもフレームワークやオープンソースとして提供されます。それらをマッシュアップして作ることが常識となるでしょう。

必要となるリソースが変わる、あるいは、もっと使い勝手がいいリソースが出現すれば、利用するサービスを変更することも比較的容易にできます。これまでなら、「買ってしまったから使わなくてはいけない」という縛りから逃れることはできませんでした。所有しなければ、そんな縛りを気にする必要はなくなります。

クラウド・コンピューティングは、コンピューティング資源を必要なときに必要なだけ使える仕組みです。見方を変えれば、いつでもやめられる、変更できる仕組みでもあります。

このような前提を踏まえた「作らないシステム･インテグレーション」を目指すことが、お客様の幸せになるのです。

「できるだけたくさん作ることを前提としたこれまでのSI」は、お客様の幸せとは反するものです。お客様に幸せをもたらさないビジネスは、いずれ排除されます。

ただ、全てがマッシュアップで実現できるはずもありません。必ず、お客様独自の業務プロセスやニーズに対応した作り込みは必要になります。両者を組み合わせてシステムを開発することが必要となります。そこで威力を発揮するのが、アジャイル開発です。

アジャイル開発とは何かという話は、既に多くの方が語られていますので、ここで申し上げる必要もないかとおもいます。そこで、ここでは、これからのSIビジネスのひとつの可能性として私が関心を持っている「アジャイル型請負ビジネス」について言及させて頂きます。

「アジャイル開発」の狙いは次の言葉に集約されます。

1. 徹底した現場主義により、エンドユーザーの満足度を追求すること。
2. 改善の積み重ねにより、高い品質を実現すること。
3. ビジネス価値の高いプロセスや機能を優先し、作らなくていいものを作らずに、時間とコストを最適化すること。

システム開発は、要件定義からはじまります。しかし、ユーザーの要求は時間と共に変化します。ビジネス・サイクルのスピードが速まるなか、要求変化のスピードもまた早まっています。全ての要件を定義することからスタートするウォーターフォール開発では、この変化への対応は、容易ではありません。

また、早期に仕様確定しようとすると、ユーザーはリスクを見越して何でも仕様に入れようとし、その結果、使われない機能が盛大に作り込まれることにもなります。いざ、完成してみるとそんな機能は、使えない、使わないとなり、無駄な工数と時間を費やしただけになってしまいます。しかも、瑕疵担保がありますから、工数に関係なく、現場が納得するまで変更要求に応えて改修しなければなりません。

アジャイル開発では、このような事態を避けるために、開発すべき機能やプロセスをMVP(Minimum Viable Process)という検証可能な最小単に分割し、この単位で開発を積み上げてゆきます。その優先順位は、ビジネス上の重要度で決定されます。開発は、MVP単位で開発し、完成すれは、その都度リリースして、ユーザーの検証を仰ぎます。これを繰り返し、システム全体の完成度を高めてゆくのが、アジャイル開発の考え方です。

ビジネス上の重要度で優先度を決定するとは、「このプロセスがなければ、このシステムは成り立たない処理プロセス(ボディ・プロセス)を優先させること」です。

例えば、例外処理やUIなどは、このボディ・プロセスに付帯するもので、重要性は、ボディ・プロセスよりも低くなります。そんな中でも、頻発する例外処理や誤操作の起きないようにするためのUIなどは、なくては困りますから、優先度はこれに続くことになります。このように決められた優先順位に従って、順次積み上げてゆくことで、システムの完成度を上げてゆきます。

プロジェクトの途中で優先順位が変わっても、開発に着手していないプロセスであれば、変更可能です。その結果、ユーザーの最新要求を反映させることが可能となります。

また、リリースはMVP単位で行われます。その度にエンドユーザーのフィードバックを得られるので、プロセス毎に改善や変更を施し、ユーザーのニーズを反映させます。さらには、リファクタリングや継続的インテグレーションの手法を使い、コードの美しさと完成度を高めてゆきます。つまり、プロセス単位で高い品質を担保し、前工程の問題を後工程に引き継がず、確実にMVP単位で完成させてゆく開発手法でもあるのです。

このような手法を駆使することで、先に示した3つの狙いを実現しようというのが、アジャイル開発です。

また、アジャイル開発では、リソースと納期をあらかじめ固定し、開発するプロセスの数と金額を決め、その範囲において開発を行います。そして、ビジネス価値で決められた優先順位に応じてプロセスをひとつひとつ完成させてゆきます。

重要なプロセスから完成させてゆきますから、リスクはフロント･ヘビーになります。しかし、早い段階でユーザーの検証と完成度を高める取り組みが行われますので、期間後期になると重要なプロセスの完成度は相当高いレベルにあります。また、後期になればなるほど重要度の低いプロセスの開発ですから、全体に及ぼすリスクはほとんどありません。

また、最初の段階で予算と開発するプロセス数を確定できますので、改善の努力次第では、原価を低減させ、利益を拡大させることも可能となります。

これに対して、ウォーターフォール型では、先に要求仕様を全て確定してから、開発を始め、全てが完成してからユーザーの検証となります。そのため、リスクは後ろに片寄せされ、最後になって大きな負担を強いられる可能性があります。何を改善すればいいかも、最後にならなければ分かりません。そのため、仕様書に忠実であることに専心せざるを得ず、開発の過程で現場の要望に臨機応変に対応する機会を与えられることはありません。

お客様の現場の反応が見えない開発者、どんなシステムができあがってくるのか最後にならないと分からないエンドユーザー。両者はそんな不安を抱えながら開発が進められているのです。

だから、「ウォーターフォールは悪で、アジャイルは善」である。私は、ここでそんなことを申し上げたいのではありません。変更の可能性は少なく、あらかじめ要件をしっかりと確定しなければできないシステムもあります。それは、ウォーターフォールがふさわしいかもしれません。しかし、ビジネス・サイクルやユーザー嗜好がこれまでになく早いスピードが変化する中、あらかじめ要件を全て確定できるシステムが少なくなってきたとこともまた事実です。

また、クラウドの時代になり、作らないシステムインテグレーションが広く受け入れられるようになれば、開発に求められるスピード感も大きく変わってくるでしょう。

こういう変化に対応するための手段として、アジャイル型請負開発は、ひとつの選択肢になるのではないでしょうか。

「徹底した現場主義なんて、現場の業務が分からなければできません。まずは、そういう勉強をさせてからでないと・・・」

マネージメントや経営者から、こんなご意見をいただくことがあります。しかし、これは順番が違うような気がしています。現場にエンジニアを送り込み、経験を積ませることで、結果として現場の業務を学ばせるべきです。

マネージメントや経営者が、リスクを冒す勇気が必要です。エンジニアは、自分の努力によってエンドユーザーの喜ぶ顔が見えるわけですから、きっとモチベーションは上がるはずです。

「アジャイル型請負開発」は、「クラウド時代のSIビジネス」のひとつの選択肢になるはずです。ただ、これだけで全てがうまく行くとも思いません。前回のブログでも申し上げたとおり、多様な選択肢を模索すべきです。唯一確かなことは、「人月単価の積算+瑕疵担保」のビジネス・モデルが難しくなることです。

そろそろ、重い腰を上げるべき時期ではないでしょうか・・・

補足----------

ここで紹介させて頂いた「アジャイル型請負開発」については、戦略スタッフサービスの社長である戸田孝一郎氏から大いにインスパイヤーされました。彼は、単なる可能性としてではなく、既に実践の現場で成果を上げています。ここに紹介させていただいた資料は、そんな戸田氏からご教示頂いたものを私なりにアレンジしたものです。もし、誤りや説明不足があれば、それは全て私の責任に帰するところです。ただ、こういう可能性を少しでも多くの皆さんに知ってもらいたいという想いから、分不相応とは思いつつも紹介させていだきました。ご容赦頂ければ幸いです。

なお、戸田氏には、私が主宰する次回ITソリューション塾でもお話し頂く予定です。


■　Facebookで、是非ご意見をお聞かせください。

■【ITソリューション塾・第14期】日程と内容が決まりました!

開始は10月2日(水)から、
毎週水曜日18:30-20:30
全10回です。

今回も既に多くの参加意向のご連絡を頂いております。恐れ入りますが、正式のお申し込みの前に、早々にご意向だけでもお知らせ頂ければ幸いです。

今回もこれまで同様、テクノロジーやビジネスの最新トレンドを抑えつつも、表層的なキーワードを追いかけるのではなく、トレンドが生みだされた歴史的背景や顧客価値など、トレンドの本質を抑えることを力点に置くつもりです。

新たたテーマや改善点としては・・・

• 仮想化をSDxの視点で捉え直しそのビジネス価値を整理する。
• SIビジネスに危機感が漂う中、現場価値の徹底追求と現物主義により、顧客満足と高い利益を実現している「アジャイル型請負開発」の実践事例の紹介。
• ストレージとデータベースのテクノロジーの大きな変化がITのプラットフォームやアプリケーションの開発をどう変えるのか。
• ビッグデータの本質と新しい動きを踏まえたビジネスの可能性。
• セキュリティやガバナンスの原理原則とクラウド･ファーストに向けた取り組み。
• システム･インテグレーション崩壊とポストSI時代のビジネス戦略。

・・・など、これからの変化を先読みしつつ、その次の手を考えるヒントを提供したいと考えています。

「システム･インテグレーション崩壊」のすすめ

「システム･インテグレーション崩壊」は、時間の問題です。むしろ積極的にSI事業者自らが、この創造的破壊に取り組んでゆくことが、最良の生き残りの選択肢ではないかと考えています。

SIビジネスの課題は、Pay for Time (人月単価の積算で金額が決定するビジネス)であるにも関わらず、成果保証(瑕疵担保責任)を負わされることです。

ですから、ユーザー企業にしてみれば、金額を一旦固定し、請負契約にしてしまえば、後は納得いくまでいくらでも作り直しをさせることができます。これでは、人月の積算で金額を決めた意味がありません。

偏見を交えて申し上げれば、ユーザー企業、つまり仕事を発注する情報システム部門は、金額に形式的かつ客観的な根拠が欲しいのです。それがなければ、社内を説得できないからです。

本来、提示された見積もり金額の妥当性は、開発や運用などの実践的なスキルなくして評価できるものではありません。しかし、現場から遠ざかってしまった情報システム部門の担当者には、そういったスキルに裏打ちされた勘が働きません。そこで、客観的な根拠としての人月単価の積算を求めるのです。

見積もりを複数の企業に提示させ、似たような積算になれば妥当と判断し、その中で一番安いところ、あるいは自社の業務に長年携わっていて、細かいことを言わなくてもツーカーで話が通じるところ、などの評価基準で発注先を選定することになります。SI事業者の業務遂行能力や創意工夫などという数字に表しにくい価値は考慮されません。

当然、SI事業者は自分たちの価値を上乗せしたいところですが、他社に負けたくないので、結局はぎりぎりで金額を提示します。当然、十分な利益は得られませんので、エンジニアのサービス残業は前提です。そうなると、彼等は忙しさに封殺され、新しい技術を学ぶ意欲も、時間も生まれません。当然、会社としても少ない利益の中で教育にお金を回す余裕はありません。

SI事業者は発注を請けると要求仕様に忠実であることで無駄な時間を使わないように努力します。つまり、エンド･ユーザーの使い勝手や満足ではなく、情報システム部門からの要求仕様を満たすことが目的となります。ここに、現場のユーザーとSI事業者のゴールの不一致が生まれることになります。ここにこそ、SIビジネスの本質的な問題があるのです。

情報システム部門も業務の現場を十分に斟酌することなく仕様をまとめてしまいますから、できあがったシステムはユーザーの使い勝手を満たしたものではありません。また、ウォーターフォールですから、仕様を決めてから開発に着手するので開発をしている期間に業務が変わり、要求仕様も変わることを想定していません。当然、できあがったシステムはユーザーの要求を満たしたものではなくなっています。

使い勝手が悪い、この機能はもう必要ない、こんな機能が新たに必要になった・・・といって改修を求めます。情報システム部門の担当者は、瑕疵担保を根拠に現場が納得いくまで改修を求めます。支払いが人質に取られているわけですから、SI事業者はそれに従わざるを得ません。

ユーザー企業の情報システム部門は、とにかく作らせてみて、問題があれば瑕疵担保の範囲で何とかすればいいと考えています。SI事業者はそんなユーザー企業の情報システム部門を信頼できません。

SI事業者もまた、業務の現場を知らないので、強いことがいえません。また、情報システム部門の担当者をいらだたせることは得策ではありません。結局は発注者の言いなりになり、利用する現場の満足に気が及ばないままに物事が決まってしまうのです。

そんな、お互いの努力不足と相互不信の構図が、今のSIビジネスに内在していると思っています。このやり方をどう変えるかです。この関係を変えなければ、SIビジネスに未来ははありません。

ところが、こういった旧態依然としたやり方で閉塞感を感じているといいながらも、新しいことに踏み出すことを恐れている、いや、未だこのままでも何とかなると思っているSI事業者の経営者やマネージメントが少なからずいる現実。そろそろヤバいのではないかと気付いて欲しいのですが・・・。

当然、そういう取り組みには、優秀な人間を投入しなければ、ことが進みません。しかし、それをやらないのです。

そういう企業の言い訳は、「あいつは優秀だから現場から抜けない。お客様に迷惑をかけるから(=彼で個人力でもっているので、お客様の現場から抜くと仕事を切られるから)」という決まり文句。ならば、若手の未熟ながら志の高い人を出せないかというと、それもそこそこ優秀で単価も安く、文句も言わず残業もしてくれるので現場からは抜けないという・・・そうこうしているうちに、そういう優秀な若手は、結局会社を辞めちゃうんですよね。

じゃあ、どうすればいいのかと言うことですが、残念ながら絶対といえる正解はありません。ただ、以前、このブログでも取り上げた、「収益モデルとしてのSI」と「顧客価値としてのSI」という視点を持ってみてはどうでしょうか。

また、次の図にもあるように、人月単価の積算だけではない収益モデルもあるように思っています。

開発の手法もウォーターフォールに固執するのではなく「現物実証主義と徹底した顧客志向」を目指すアジャイル開発に現状を打開する突破口を見出してはいかがでしょうか。事実、「アジャイル型請負ビジネス」で成功を収めている企業もあります。

とにかく、そういうチャレンジを片手間ではなく、事業プロジェクトとして、投資してやっていくべきです。アベノミクスで一時的に仕事が増えても、SIビジネスの本質的な構造を自ら破壊し、変えていかない限りその次はないのです。

「分かっているけど、簡単にはできませんよ。」

そういう発言をする人たちは、過去の成功体験に引きずられている人たちです。過去の成功法則が通用しない今、その基準でこれからの戦略を考え、善し悪しを判断すること自体無理があることを自覚すべきです。

若い人たちはもっと柔軟です。そして、真剣に会社や自分の将来を憂いています。そういう人たちに自分たちの将来を、自分の責任で描かせてみてはどうでしょうか。どうせ彼等の時代が来るのですから・・・

偏見や過去の栄光を棚上げし素直な気持ちで彼等にチャンスを与えてみてはどうでしょう。それは、会社の未来のためであり、そして、彼等自身の成長のための投資なのです。

過去の成功の延長線上に未来の成功はありません。この現実を素直に受け入れ、真剣に向き合うべき時期なのかもしれません。

■　Facebookで、是非ご意見をお聞かせください。

提案書の最初を見れば営業の力量が見えてきます

提案書の最初の数ページを見れば、この提案書を仕上げた営業の力量が見えてきます。

「お客様の立場に立って考えてみました。」

「お客様のご期待に応えようと思っています。」

「お客様の期待に応えることが私達の役割です。」

そういう言葉を涼しい顔をして語っていても、提案書の最初の数ページを見れば本性は暴露されてしまいます。

先日、ユーザー企業の情報システム部に、運用を委託しているITベンダーから、運用自動化の提案がありました。その説明は、運用の自動化を進めることの価値から始まり、自動化のためにはどのような取り組みが必要か、スケジュールはどうなるかなど手順を踏んだわかりやすい説明でした。そして、今後の検討の段取りについても話が及びました。

最後に金額の提示です。それを聞いて驚きました。月額費用は変わりませんが、初期費用に数千万円かかるというのです。

「ちょっと、待ってください。これ、話が違いますよ。こちらが聞きたいのは、どうすれば運用コストが削減できるかであり、どうすれば自動化できるかではありませんよ。」

情報システム部長の発言に、場は静まりかえりました。

“運用コストを削減したい。その手段として、運用の見直しや自動化に取り組んでゆかなければいけないのなら、その進め方を提案して欲しい”が、ユーザー企業からの依頼でした。

しかし、話はいつの間にか、「どうすれば自動化できるか」にすり替わっていたのです。お客様が知りたいことではなく、ベンダーが伝えたいこと=売りたいことを伝える内容となっていたのです。

どうしても運用コストを下げると月額の売上が減るから「自動化すればコストは下がらないが利便性は向上する。これで何とか乗り切ろう・・・」とでも考えていたのでしょうか。もし、そうだとしたら、お客様の立場や気持ちなど、何も考えていなかったことになります。

もし、お客様の立場で考えるのなら、まず、提案の冒頭で、現行のコストがいくらで、今回の提案を実施することで、いくら削減できますと語り、その上で、上記のような手順を説明すべきなのです。

この提案説明が始まったとき、なかなか結論を語ろうとしない彼等に、私は内心この展開を予測していました。もし、結論に自信があれば、笑顔でそれを先に語るでしょう。それがないままに、段取りだけが進んでゆくことにいらだちを覚えつつも、オブザバーの立場として発言を控えていたことが悔やまれます。はやく、それを指摘してれば、お互い無駄な時間を費やす必要がなかったのですから。

提案書とは、お客様の知りたいことを伝える手段であり、こちらの伝えたいことを伝えるものではありません。

「一生懸命、準備に時間をかけ資料を作ったのだから、全部伝えないともったいない」という気持ちも分からないことではありませんが、それがお客様の知りたいことなのでしょうか。いくら自己満足のために、嵩を積みかねた資料を丁寧に語っても、そこにお客様の知りたいことがなければ、何の価値もありありません。

どうでもいい、あるいはあとでもいい膨大な話の最後に、「知りたいこと」が語られる提案もまた、お客様の立場や気持ちへの配慮が欠けています。

では、お客様の聞きたいこととはなんでしょうか。それは、結論です。理由や背景、手段は、結論に魅力を感じることができれば、聞かせて欲しいと思うでしょう。結論に魅力がなければ、その他の話は、全て無駄です。

魅力的な結論が最初に説明されていない提案は要注意です。それは、魅力的な結論を持っていないためかもしれません。仮に、最後に「魅力的な」結論が示されていたとしても、その提案は、相手の立場への理解や配慮を欠いたものと言わざるを得ません。

相手の知りたいことは何だろう。相手に何を伝えれば受け入れてくれるだろう。それを考え抜き、議論した結論をまずは最初に提示することです。その結論に相手の合意を得て、次に手段や段取りについて話を進めれば、相手も安心して提案を聞くことができるでしょう。

何も難しいことではありません。相手の「そうしてもらえれば嬉しい」を想像することです。これは、提案の時だけはありません。そんな心の有り様を持ち続けることが、営業という仕事には常に必要なのです。


■　Facebookで、是非ご意見をお聞かせください。