ゆーたんのつぶやき

株式会社ノークリサーチにてIT関連のシニアアナリストとして活動しています。

ビジネス全体で捉える



ALM(Appication Lifecycle Management)という言葉が
登場してからしばらく経ちますが、新しい技術の中には
それ単独で考えるのではなく、ビジネス面も含めた全体
のライフサイクルで捉えた方が間違いがないものが多々
あるように感じています。


例えばSOAですが、WSDLの表現をどうするか?サービス
間のデータセキュリティはどう確保するか?といった個々の
ピンポイントの技術的な議論ももちろん重要です。ですが、
実際のビジネスで役立てるためには「ビジネスのどの部分を
SOA基盤に載せるか」「サービス化の粒度はどうするか?」と
いったことがむしろ肝要になってきます。


そうなると、「どんな業態でもカバーできる汎用的なSOA技術
とその手法」というよりは「コレコレの業界向けのSOAベスト
ラクティス集」みたいな感じでノウハウが蓄積されてくる
方が自然です。そういう観点で見れば、SOAというものは技術
だけが単独で存在するものではなく、ビジネス面での綿密な
検討と不可分な存在であると言えます。


ピンポイントの技術的な観点にすぐ収束させてしまわずに
まずはビジネス全体を把握して、ビジネスの観点からサービス
化の対象やその粒度を検討していくという手法がこれからの
SOAにおいては注目される部分になるのではないかと考えます。
実際、IBMでは「CBM(Component Business Modeling)」
という名称で上記のようなプロセスを実現しようとしています。


同様のことがMDAに関しても言えます。MDAを「コード自動生成技術」
と捉えてしまうと『そんな夢みたいなことできないよね』という話
になってしまいます。以前にも触れましたが、MDAの役割はむしろ
ビジネスレベルのモデリングと設計・実装レベルのモデリングの間の
「トレーサビリティ」を確保するための技術だと捉えるべきではないか
と個人的には考えています。


昨今ではシステムは元より、一つのビジネスそのもののライフサイクル
が短くなってきています。ビジネスの変革や再構築を頻繁に行なおうと
した場合、ビジネスのレベルで構築したアーキテクチャがシステムの
設計・実装レベルのアーキテクチャと乖離してしまう危険性は常に存在
します。変更頻度が増え、構築期間が短くなればそのリスクはさらに
増大するでしょう。MDAはそうした場面において両社の乖離を最小限に
留める効果があるのではないかと期待しています。ただし、MDASOA
同様に実際に使える技術・ノウハウの体系とするためにはある程度業界
や業態を絞り込む必要があると思われます。


結局のところ、SOAMDAが指し示している方向性は「システム構築の際の
ノウハウの重点が設計・実装レベルからビジネスレベルに移行しつつある」
ということなのかも知れません。従来であれば、システム構築の際に生じる
様々な問題や不整合は設計や実装のレベルで工夫をして、あるいはパッチを
当てて何とか回避していたというのが現実だったと思います。ですが、SOA
や今後登場するであろうJBIが普通に利用されるような状況では、システム
は従来のように一枚岩のモノリシックな構造ではなくなってきますし、実装
面で利用される技術は多岐に渡ります。結果として、「ちょこっといじって
辻褄を合わせる」ということはやりづらくなってくるでしょう。システムが
正しいものであるかの勝負の分かれ目は「如何に適切にビジネス上のアーキ
テクチャを設計・実装レベルのアーキテクチャに落とし込むか?」といった
より上流の工程にシフトすることになります。


ビジネスレベルを無視してSOAMDAを捉えようとすると、思わぬ罠にはまる
危険があるように感じています。例えば、とある顧客がごく単純なWEBアプリ
ケーションを使い、HTTPポストといった初歩的な技術を使って、子会社との
データ連携に成功したとしましょう。その結果を持って「システム連携なんて
HTTPポストのレベルで十分だ、この手法で『企業間連携ソリューション』を
打ち出すことにしよう!」と考えるのは余りに早計です。この顧客の場合には
システムの背後にあるビジネス上のシナリオや要件がたまたま実装技術として
HTTPポストを選択することを許容していたというだけであって、他の顧客の
ビジネスにも同様のことが当てはまる保証は全くありません。設計・実装面に
のみ視点が集中してしまい、ビジネスレベルがどうだったのか?を考えないと
こうした間違いをしてしまいがちです。SOAが関係するようなシステム連携や
MDAが関係するようなシステム刷新といった場面においてはビジネスレベルの
検討が必要不可欠です。


その部分の役割を担うのはコンサルタントであったり、アーキテクト
であったりするかと思います。いずれにしてもある程度以上の規模で、
SOA基盤を必要とするような連携を伴うシステム構築を行なう際には
・顧客の業態を理解し、ビジネスレベルのアーキテクチャが描ける
・ビジネスレベルのアーキテクチャを適切な設計・実装レベルに
 落とし込むことができる
といった人材を育成または確保していくことが競争力を維持する上で
今後は重要なポイントになってくるのではないかと考えています。


一方で、提案を行なわず「モノ売り」に力を入れた教育をしていた組織が
いきなり上記のような動きを営業マンに求めるのは無茶というものです。
「提案をしよう!」という声だけは大きいですが、実際に何をどうやって
提案すればいいのかを旗振り役の当人も理解できていないというケースが
あります。そうした組織に良く見られるのはビジネスレベルで顧客要件を
捉えるという訓練を常日頃怠り、とにかく受注を獲得することのみに社員
を奔走させるような組織運営手法だったりします。一つ一つの案件を大切
にし、そこで何を学んだのか?その案件に関連した事項で学ぶべきことは
何か?といったことをきちんと営業マン一人一人フォローしていくことが
大事です。そうしたことをやってこなかった組織がやってきた組織に追い
つくのに必要とされる努力は並大抵のものではありませんが、「提案」を
理解できていないリーダーはその辺りの理解が難しい場合が多いようです。


ビジネスレベルの視点を持っているリーダーであれば、
『A社はコレコレのビジネス要件の結果から、HTTPポストが最適だった。
 B社もビジネス要件はA社と違っていたが、実装面では同様にHTTPポスト
 でクリアできた。C社はA社とビジネス要件がほとんど同じだった。だが
 今度提案するD社はビジネス要件がまだ把握できていないので、HTTPポスト
 でカバーできるかも知れないし、もっと高度な実装を用いないといけない
 かも知れない。』
という捉え方をします。ですが、そうした視点に欠けたリーダーは
『HTTPポストで5件のお客さんの案件はカバーできたから、ウチでは
 システム連携手法としてHTTPポストを前面に押し出して、企業間
 連携ソリューションを打ち出そう!』
といったビジネス面での個々の顧客のニーズや背景の違いを無視した
少々短絡的とも言えるプランニングを実践し、これを「提案」と呼ぶ
といった間違いをしたりします。


「提案営業は重要」ということは昨今良く聞かれる言葉ですが、ただ単に
「提案、提案」と叫んでも、基本的な考え方をしっかり抑えていなければ
結局は実装技術偏重の誤ったソリューションやプランニングを打ち出して
しまう危険性があります。大風呂敷を広げる前に、まずはビジネスレベル
と設計・実装レベルの両方をしっかり意識して目の前の個々の顧客を一件
ずつ丁寧に見つめ直すというプロセスが大事なのではないかと思いました。