第10回例会報告
1月31日に第10回システムイニシアティブ研究会（例会）が開催されました。
今回のテーマは「変化する時代、問われる企業IT化のあり方」。
講師は、札幌スパークル・システムコーディネータの桑原里恵さんです。日経コンピュータなどの連載多数、IT Leadersの創刊コンセプトづくりにも関わられ、IT Leaders Live!にも毎回出演されています。 ファシリテータの田口さんによると「毎回頭爆発！」だとか。
企業はもっとわがままでいい
桑原さんは、30年間ユーザー企業の立場で「システムデザイン」を支援されてきて、「ITはもっと事業に貢献できるはず」「企業はもっと個性的で、わがままでいい」と言います。事業の強みを活かし、個性に応えるためにも、ITの力を発揮するにも、「まずはデザインの力が大事」とも。
「事業とITが一体化してくると”求める姿”を”求める条件で”実現する必要があるが、長い間『費用を削るなら機能を絞れ』と言われ、”システムが動く上で必須ではない”機能は後回しにされてきた。その機能の多くは”事業にとっては大事”だったり、差異化に直結しているもの。
とはいえ、費用は無限ではないし、システムが動くための機能も必要。そこで、それらと事業にとって大事な機能とのバランスをとっていくのが、システムデザインをする人の重要な役割」と、桑原さんは言います。「デザインは”How it works”だ」と言ったのは、スティーブ・ジョブズ。 桑原さんによると「デザインとは実現すべき状態を定義し、それを構成する物理的な要素に分解して、 達成可能にする一連の行為とそれによる成果物」であり、 その3条件は「全体像であること」「動くこと（想定通りの状態になること）」「実現できるように分解できること」とか。
本講演では「事業と一体化するシステム」について、次の３つの観点でお話いただきました。
①事業と一体化するシステム…業務プロセスの違い
②技術の変化…クラウド化をどう取り込むか
③事業と一体化したIT企画の進め方
観点① 事業とITの一体化
事業とITの密着度が高くなり、より最前線へとシステムが出てきている。 従来のERPが「世界のベストプラクティスにあわせなさい」と言えたのは、システムがバックエンドにあり、確定処理よりも後ろの部分が主だったから。 事業と密着したシステムほど、変化が激しく、多様性に富む。共通性が低くなる。業務系/情報系という括りもない。 実現像が変わり、使う技術が変われば、それに合った方法論が必要。 求める姿を求める条件でつくるために、新しい技術・アーキテクチャー、方法論、そして実現内容の工夫で、実現の解を考えなければならない。 “できるなり”では、事業の方向性や経営のニーズに応えることができない。
事業と一体化するシステムの定義のしかた
事業と一体化するシステムとは、「システム視点」ではなく、「事業視点」で定義されたもの。 ねらいを定義するときは、「動機は何か」「それによって何が変わるのか」を考える。変わるのは「事業からみた業務プロセス」。 事業の視点でみた業務プロセスには、複数のシステムも入るし、手作業や社外でやることも含まれる。 この、当り前のことに取り組むようになったのは、基幹系の世代が変わってERPを導入しはじめた2000年頃。 事業視点でプロセスを描きはじめたら衝撃だった。それまでの「システム視点で描いたプロセス」は１つにつながっていて、あたかもデータが流れているようにみえたが、現実には、はみ出したり、入力の手前の処理などが手作業で行われている。 プロセスが分断していた。その手作業には「判断」が行われていることが多い。そこにITが寄与していないことにも気づいた。 また、事業視点では、プロセスは少なければ少ないほどいい。 業務プロセスが一貫で流れて、作業ステップがより少なく、人が判断しているところでITが貢献するような見直しを本当に一生懸命にやると、見違えるようにITが役にたつ。
事業と一体化したシステムは何が違うか
- 事業視点（利用視点） 「事業部門の視点」ではない。事業部門が満足するようにシステムを作ることを「事業との一体化」ととらえる傾向があるが、それは違う。 事業が目指す方向へと変化していくこと。そのためにITが使われる。あるいは、その変化を支えるためにITが基盤となる。
- 「作るシステム」を定義するのではなく、「達成する状態」を定義する。 「システム開発プロジェクト」と考えてしまいがちだが、担うことはシステムを組み込んだ事業全体であり、業務プロセス。 しかも、事業は日々流れている。 仕事が流れているところに合流させて「どういう状態にするのか」ということを描くことが重要。 状態とは、人がいて、複数のシステムがあって、それぞれに動いて、情報が流れているということ。その全体の姿。
- １つの業務プロセスには、複数のシステムが関わる。 そこに手作業も、社外も。＝情報起点。情報が流れて、複数のシステムが合流する。イベント駆動型になる。
- １つの業務機能には複数のシステム機能があり、システム機能は個々に違うシステムに属する場合がある。
- 事業視点をつきつめれば、「顧客起点」（プロセスの出発点が顧客）になる。 顧客ライフサイクルをきちっと定義して、精神論にしない。 個別機能で顧客が満足する機能だけをのせればいいということではない。 企業には効率性も求められ、組織の活動として最適な形もある。 よって、顧客ライフサイクルと組織との両面から最適解となる事業ライフサイクルを描く。
- まずはペルソナをひとつ作って、典型的なひとつのプロセスをとことん突き詰める。 これは事業部門にとって大事なこと。これを通して、システムが手段になっていく。
- 「これが実現できないなら、やらない」という機能があってしかるべき。 骨格要件（=骨格構造に影響するような要件）。これが一番大事。 事業に密着すると、絶対譲れない一線があるはず。 ねらいと同時期に定義をして、いかにこれを達成するかをデザイン上の最重点に反映する。
システムの視点と事業の視点はつくづく違う。そして、この２つを両立させる全体像を描く。 事業視点を共に考えていくためにも、これを立体的に考える方法論が大事になる。
- システム視点：システムが安定的に動いて、トランザクションや機能が正確に流れて、ということを重視
- 事業の視点：事業の発生現場でおこること（顧客との接点での価格の扱い、販売条件など）が扱えないといけない。 そうするとマスター構造や価格決定ロジックが決定的に大事だったりする。
観点② 技術の変化…クラウド化をどう取り込むか
事業とITが一体化すると、複数のシステムにまたがって業務プロセスが一貫していることが重視される。 これが昨今のコンポージット・アプリケーションやWeb2.0のマッシュアップにつながってきた。 業務には複数の機能が入っている。確定受注処理ひとつにも、受注登録と納期回答というのがあるし、 そこに原産地の確認や、各国のレギュレーションにあわせた出荷チェックが入ったりもしてきている。 クラウドも、大きな単位のサービスではなく、小さな特化したサービス（与信だけチェックとか、為替レートだけ）を使い、 自社のシステムと組み合わせてひとつのアプリケーションを実現するという発想がある。 リアルタイムにデータを共有し、プロセスを一貫するという使い方もある。 こうしたシステム作りができるのは、データの流通を初めとする統合基盤を構築しているから。フロントエンドも認証などの基盤が要る。 しかし、この「基盤化」を自力でやるとなると、技術負担が重くきつい。投資負担も重い。 ということで、基盤部分をクラウド（PaaS）に任せるという解決策にいきつく。 こうして、コンポージット・アプリケーションに向けたSaaS、基盤部分を任せるPaaSと、インフラ部分（IaaS）以外にもクラウドの必要が広がっている。
クラウドに取り組む３つの背景
- 事業とITの一体化をするときの手段として、クラウドは役に立つ。
実現像と費用のトレードオフバランスを変えていく（条件面の優位性） 実現のスピードや、グローバル展開には（新興国などにでるときは特に）よい。 また、ビックデータの処理には、コストメリット考えるとクラウドの方においた方が有利な場合が多い。 月末処理が極端に大きいとか、特定シーズンだけ極端に処理が多くなるようなものにクラウド（IaaS）を使う例も増えている。 - 「つくる」から「使う」へ。 パッケージ利用の先にクラウドがくるのは自然な流れ。
- 共通と固有、SOAとコンポジットアプリへの流れ。 事業の視点で業務プロセスを考え、その中の業務機能を考えると、それは複数のシステムから構成される。 その中には非常に業務特化の専門性の高いものもあれば、企業間で共通性の高いものもある。 共通性の高いものをパブリッククラウドにゆだね、その上に個性的なものをのっけるという発想。
ポイントは、ハイブリッド利用を前提に最適解を求めること
クラウドかオンプレミスかという二者択一ではない。 むしろ、ハイブリッド利用を前提に考える方が自然。オンプレミスとクラウドのシステムを組み合わせて使う。
観点③ 事業と一体化したIT企画の進め方 …３つの工夫と２つのスキル。
3つの工夫
- 成果物連鎖：企画を策定する方法論 要件定義というのは、とかく、システム開発側に作りたい内容を引き渡す言葉として使われているが、 事業視点で重要なのは「何を実現するかを考える瞬間」であり「何を要件とするかを考える部分」。 「いかに正確に伝えるか」だけでは足りない。 ユーザーが主体性をもつべきなのは、特に、「何を実現するか」を事業視点で考える部分。
- ワークスタイル ITの視点がまざると、「へえ、そんなことができるんだ」という驚きが生まれ、それが刺激になって業務の新しい発想が出てくる。 事業とITのそれぞれの専門家が集まってひとつの成果物を考える。これがとても楽しい。 5～10年前にヒアリング＆レビューという方式をやめて、事業部門などとIT部門が一緒に話す「ワーキングセッション」という形をとるようにした。 ヒアリング＆レビューは、考える人が片方によっている。 ユーザーとベンダー、あるいは、事業部門とIT部門、そこに＋１人のすぐれたエンジニアで、目指す成果物を決めてディスカッションする。 利益代表の集まりではなく、その成果物をベストにするために、知見をもちより、議論する。 この過程を通して、実現像を共有し、どこに重点をおくかということを明らかにする。
- 工程マイルストーン 「統合サンプル開発」というやり方で、まず1プロセス分（あるいは一部）を作るということをやっている。 一種のプロトタイプ開発。ただし、 「おもちゃ」のようなものを作るのではなく、必要な技術を盛り込み、難しい部分を取り込む。 今は、統合部分が肝心なので、統合シナリオにあわせて全部統合したものをつくってみる。
ユーザーが主体となって進める上で不足しがちな２つのスキル
- インテグレーションの計画で、「どんな製品を組み合わせるか」というインテリジェンス。 ちょっとした情報を知らなかったために苦労している方々がいる。 企業が主体性をもってやるというときに、それが大きなハードルとなっている。 そこは、私たちや田口さん（メディア）の使命だと思っている。
- 規模の見積もりスキル 主体性を失っていく契機に、費用を見積もれないということがある。概算費用を知るために、自分たちのプランができていないときにベンダーを呼んだり、見積もりをとるために、RFPまで書いてもらったりする。 何をどういう手段で実現するかを「決める」部分で、主体性を持てることがとても大事。黙っていると費用はどんどん高くなるので、費用を落とす具体的な施策を知らないと、結局は主体性をとれなくなる。少なくとも、実現内容と費用のバランスは工夫（技術の選択、方法論と進め方）によっていくらでも変わってくる、ということを知っている（そういう勇気を持つ）ことが大事。中でも、要件定義を含めた方法論や工程は費用と実現性への影響が想像以上に大きい。
まとめ：桑原さんからのメッセージ
いまの技術を、ユーザー主体の武器として取り込むにはどうしたらいいかを考えていきたい。企業ITは本来もっとわくわくするものであるし、事業とITの両面から可能性を追求するものである。 例えば、どんどん複雑化してバリエーションがたくさんあるが、共通と固有はきちんと整理できる。複雑を複雑につくるのは仕事をしていないも同然。複雑なものをシンプルにするということが、「ユーザーが主体性をもってする仕事」の醍醐味のひとつであると思う。 従来は弱点部分をシステム化することが続いてきた。守りのシステム化。それは一通り終わり、リプレイスや拡張のフェーズ。これからは強みを伸ばすシステム化。そうすると、多少はでこぼこしていてもよい。システムの対象も内容ももっと個性的になっていくはず。
ユーザーが主体性をもつために
ユーザーが主体的にやるのは自然のこと。そこに今日の進化をどう取り込んでいくか。 ユーザーが主体としてやるからといって、枯れた技術だけでやるというのはナンセンス。 従来ユーザー企業にとってつらかったのは「試せない」「情報がはいってこない」ということだったが、新しい技術はコンシューマリゼーションで、どんどん安くなって、ほとんどのサービスは試用ができる。小さな企業でもできる。もちろん、大きな企業の大規模プロジェクトにも有益。 企業のIT化は、事業の最適化に向けて、もっとわがままでよいと思う。 求める姿を、求める条件で実現することにこだわってよい。そのために実現像をとことん考える。 「デザインファースト」。めざす状態をとにかくベストに描いて、それをどういう構成でつくるかを分解して手段を組み合わせて、また全体像にもどす。それが、デザインサイクル。 ユーザー主体ということは、「SIerと協業しない」という意味ではない。 事業視点でみれば「使えることは何でも使え」「よりよいパートナーを得ていこう」ということ。 あらゆる手段を使って、事業の強みに合った個性的なプロセスを作っていきたい。そのお手伝いをしていきたいと思っている。
吉田太栄（システムイニシアティブ研究会事務局）
※本編（講演の動画）はこちら http://youtu.be/rbF0rsXLvOA
