椙田太郎

日本から海外に生産・営業拠点を移しビジネスを行うケースが加速している。
その際に、ITの活用は欠かせない課題となるが、日本人スタッフが海外ITプロジェクトを主導することには難しい点があるという相談を頂くことも多い。

そもそも、IT活用には、ビジネスとITとの橋渡しという翻訳作業が必要なうえ、日本と現地との橋渡しという翻訳作業まで入るので話しは複雑にならざるを得ない。
そのような際に、いくつか留意点・対策があるので、それらを次回以降に渡ってお伝えしたいと思う。

まず、最初のステップとして、意思が伝わることが重要である。
『英語公用化』のような形で言葉の壁をなくせば良いかというと、そもそも、現地というのも多様で、第2外国語としての英語をお互いに使ってコミュニケーションをとるという場合も多いだろう。その際に、肝心なのが、言葉だけで伝えるのではなく図式化して伝えると言う点ではないだろうか。

そこで、思い出されるのがピクトグラムである。
ご存知の方も多いと思うが、ピクトグラムというのは、駅や空港などで絵によって説明している表示で、身近なところでは、電車の優先席近くには、席をゆずってほしい対象者の人の絵や、携帯電話をOFFにするよう求めるものなどがある。もともと、日本では東京オリンピックで広まったといわれており、海外の人とのコミュニケーションをとる際に、今のビジネスにも活かせる発想だと思う。

それでは、ピクトグラム作成時にも考慮されているステップをあげて、メッセージの伝え方を考えてみよう。

1．メッセージを明確に絞り込む

ピクトグラムには様々な内容を伝えるものがあるが、推奨されるアクション・禁止されるアクションなど、伝えたいメッセージが明確になっている。
コミュニケーションをとる際に、最初はまずメッセージを整理すると良い。できるだけ伝える内容をシンプルにしないと、認識のずれが生じてしまう。

メッセージを絞り込むためには様々な方法があるが、例えば、伝えたいと思う内容を思いつくままに書き出してみて、
・人と役割　関連する組織・人とその役割は何か
・もの　関連するものは何か
・アクション　誰が何をするのか、１つ１つのアクションとその前後の状態
・時間と場所　近い未来とゴールの状態
を思い浮かべて、内容を見直してみると良い。

２．メッセージを図式化する

伝えたい内容が決まったら、それを、
・くくる 並べる：　似た内容は１つにくくり、近い内容のものを並べてみる
・つなぐ：　時間的な前後関係や、物・コミュニケーションの流れを線でつないでみる
・言葉を選ぶ：　一言で内容を表しているか、間違って別の意味にとられないか試して、もっとも良いと思われる言葉にするという作業を行い、メッセージの内容を構造化して見る。

内容がピクトグラムのように1つの絵で伝えられるようなものであれば、それが一番良いが、中々そんなにシンプルにはならないと思うので、その際は『人・組織』『アクション』『アクション前後の状態』を並べる・線でつなぐことで図式化してみたりすると分かりやすい。

図式化しても分かりにくい場合は、そもそものメッセージが絞り込まれていない可能性が高いので、内容を見直せというサインである。

３．文化の違いを考慮する

図式化するときに留意する点が、絵・図・記号の意味が文化によって違う場合がある点だ。
例えば、良くあるのが○×△のような評価に使われる記号で、△などは、日本以外では何を意味するのか分からない。記号化した方が簡易に伝わると判断できれば、凡例を言葉で補うことで使えば良い。


以上、意思を伝えるための図式化に関して簡単にまとめてみたが、分かりやすく伝えるためには、オーソドックスに表・グラフを使うという方法もある。
グラフ・表にも読み取るスキルというものが求められるので、対象者に応じて適宜検討されると良いだろう。

長澤毅

ソーシャルメディアの活用を検討する前に

コンシューマー分野で躍進しているソーシャルメディアを企業側でも活用しようという動向が盛んである。
最近の例だとトヨタ自動車が展開している『トヨタフレンド』が挙げられるし、それ以外でもツイッターによるメッセージ発信が消費者に好評を得て企業イメージが向上したという事例はよく目にする話である。

取り掛かりとして一番分りやすい分野がダイレクトマーケティングでの活用だ。
FacebookやTwitterでは消費者と直接コミュニケーションが図れるので、そこにアクセスして顧客に自社の商品を訴求するという手法だ。
従来のネット広告と違う点を上げてみると、繋がっている知人の情報が共有されているので、消費者側は知人が「いいね！」ボタン等でその商品やブランドに好意を示している事が分かり、加えて大概のソーシャルメディアでは類似したクラスタの消費者同士がネットワークを築いているものなので、効率的かつ波及効果を期待できるマーケティングを展開できる点であろう。

ソーシャルメディアを活用したビジネスというのは、個人が特定可能なメディアで行われている限り、実態を持ったビジネスとして継続するのではないかと思う。人間は社会的な存在であり、かつ、顔を突き合わせた関係維持には物理的な限界があるので、今時点の技術だとネットで関係の維持を保持するのが最も合理的であると考えられるからだ。だからこそではあるが、ソーシャルメディアというものは、決して『綺麗事』だけでは済まないと私は考える。ソーシャルメディアに対応しようとする企業は、事前に慎重な人間系を考慮した『設計』が必要になるはずである。

ソーシャルメディアでは、実名であってもなくても心地よくコミュニティに参加し続ける為に、ある程度の節度を持った振る舞いを暗黙のうちに要求される。その力学で押さえ込まれている欲求を理解することなくソーシャルメディアに進出しても、貴方が投げかけるメッセージはソーシャルメディア上で期待した効果を発揮しないだろう。


ソーシャルメディアで人は何をしているのか？

消費者の日々の購買は単なる価値交換には留まらない。
例えばコーヒーを例に挙げてみよう。朝コーヒーを飲むとする。コーヒーショップでラテを買ってリラックスしたいという人もいれば、現場に出る前に缶コーヒーを二つ買うという方もいる。一方では自分で豆を轢くという人もいれば、そもそもコーヒーは飲まないという人もいる。既にバラバラである。もちろん多様な価値観が共存することは平和の証で、コーヒーに対する態度で人間の優劣など決まるわけがない。しかし、朝のコーヒーの飲み方一つでもその人の人柄がなんとなく見えてくるのではないか？
ここで重要なのは人間が日々の消費活動の中で自身の価値観の表明という副産物を大なり小なり絶えず生み出しているという点である。高価でも環境に優しい商品を進んで選択する人々の行動が最たる例である。彼らは経済的効率よりも自身の価値観を優先するのである。

こうした消費者の日常にソーシャルメディアが加わるとどうなるだろうか？
人々は日々の人間関係の中で起る出来事と一緒に買った商品や受けたサービスを公開し始め、友達から「いいね！」や「お気に入り」で共感を獲得しようとする。日々の雑貨をいちいちソーシャルメディアに掲載する功徳な人は少ないだろうが、苦労して入手した物や人々の反応が期待できる物は進んで公開しようとするだろう。なぜだろうか？そこには人間の弱点をついたソーシャルメディアの巧妙さが見え隠れする。すなわち友達が公開した自慢話に負けまいと自分も何か公開しようとする人間の心理が、反応連鎖のエンジンとして存在するのである。似たような価値観を持つ友達に囲まれ所属の欲求を満たしつつ、商品を選択するという行動で手軽に承認欲求を満たすという、ソーシャルメディアのトリックだ。
（このメカニズムを応用すると、某アイドルグループのＣＤを数百枚で買うだとか、某携帯ゲームの電子データに数万を払うといった、一見意味不明な出来事の数々が理解できるようになるだろう。仲間内での評価が購買動機として作用しているのである。）

ソーシャルメディアで起っているのは、その名の通りの人間関係構築だけではなく、他者の視点を意識した自己の属性付けなのである。


企業はソーシャルメディアを通して何を与えるべきか

ここまで読んでいただければ筆者の主張は理解して頂けたのではないかと思う。企業がソーシャルメディアを活用するには消費者の自尊心を満たすよう設計されなくてはならないのである。自社の商品を購入して頂いたことがいかに正しい選択であったのか、ソーシャルメディアを通して消費者に訴え続ける仕組みが顧客満足度向上に直結するのである。
多くの企業が顧客への商品アピールにソーシャルメディアを活用しようとしているが、製品のライフサイクルで考えると、購入後のサービスに重点を置き、保守サービスや次回購入に繋げる働きかけを継続した方が賢明だろう。商品購入前のフェーズでは消費者は何も自慢できないからである。個人的な観測であるが、ソーシャルメディア活用で効果的なのは高価で個人の価値観が購買に大きく影響する自動車や家電ではないかと考えている。そのような商品の消費者にソーシャルメディアを介してサポートしてタイムラインに花を添え、ロイヤルカスタマーを増やしてゆく事が企業の執るべきソーシャルメディア活用の戦略ではないだろうか。

中山宗央

2012年がスタートしたが、多くの日本の大企業が「グローバル化の促進」をテーマに挙げている。もちろんこれは国内市場の飽和感や、不安定ではあるものの新興市場の成長性に魅力があること、経済・金融のグローバル化、などを背景にしたものだ。

そんななかで、海外進出を先駆けて行ってきた製造業においては新たな課題が出てくる。

製造業はこれまで「生産」分野においては、国際化・現地化を成功させてきたといえる。日本でやってきたことが海外でもほぼ同様にできるようになったり、現地で行っていることがよく分かる状況を作ってきた。
これによって、コスト削減が実現し企業の競争力を保つ成果を得られてきた企業は多い。

そして、今後はモノを「作る」海外拠点からモノを「売る」新たな市場として捉え、企業の方針や取組をシフトして行く段階にきている。

しかし、対市場活動である「営業・マーケティング」分野は全く異なる状況である。これまで、現地の代理店網、商社などを経由した「現地任せ」。要は数字さえあげてくれればよい、プロセスまでは統制しないしそこまで見ようともしない、という企業が多い。今まではこれでよかったが、ここを変えていかないと、本当にグローバル化した企業として成功を収められるか、という課題に直面する。

ところが、製造のノウハウをそのまま海外に移転し日本品質のモノ作りを継続する事は時間をかければ何とかなるという点で比較的容易であっても、販売やマーケティングのノウハウは日本で培ったものは、まず通用しない。相手のある業務であり、現地の商習慣・文化の違いなどから、いくら本社があせっても本社の意向や仕事のやり方を実行させることは困難である。

その状況を打開するためには、せめて、海外拠点の営業活動や市場の情報を本社でも見える化し、具体的なデータに基づいた業務の継続的な改善と指示・支援が取り組める仕組みを築かないとはじまらない。

また、単なる定量的な数値の把握だけではなく、課題や成功例など現場からの定性的な情報を吸上げた対応や活用まで踏み込んで取組まないと、本社と海外拠点での「思い」にギャップがあるままと言う事も我々は経験的に知っている。


弊社ビジネス アソシエイツでは、このような状況下にあるクライアントに対して、クラウドによる営業管理やCRMの展開などを行ってきた。本社の意向と現地の要望を上手く取込みながら、スピード感のあるシステム構築や改修が可能であるのがその理由だ。

そのような実績が積み重なってくると、各海外拠点の定量・定性的な情報が本社で把握できるという「情報の見える化」だけにとどまらない相乗効果が生まれてきた。

クラウドであれば各海外拠点間でも情報の共有を容易に実現ができる。例えば以下のようなケースでは本社を中心としたスター型のネットワーク形態でなく、メッシュやフルコネクトに近い情報共有の形態としての効果例である。

・販売先が複数の国にまたがるグローバル企業の場合、他国での販売実績や商談・提案情報の共有による受注率の向上
・類似案件の提案資料や受注要因などの共有による販売効率の向上
・海外の子会社が提供している製品やサービスをグローバルで販売する場合の、製品/サービス情報の取得や問合せ先の共有による販売機会の増加
・特定の知識に詳しい人材・スキルに特化した人材に直接アプローチして、商談や顧客からの問合せなどに適切かつ迅速に対応

など、海外拠点の現場レベルでも情報が連携する事で、当初の目的であった海外拠点でのマーケット拡大から飛躍した、営業・マーケティングナレッジのグローバルでの共有が実現するようになった。

この相乗効果・想定以上のメリットを享受できた背景は、繰返しとなるがクラウドのアプリを用いたことが大きく起因していると考えられる。SaaSにより共通のプラットフォームで個々に構築や改修が迅速に進められるだけでなく、SaaS間での情報共有が容易に実現できるからだ。

具体的な例をあげると、Salesforce.comでSalesforce-to-Salesforceという他組織間での情報共有機能があり、顧客情報や商談情報がアプリの設定で(コーディング不要で)簡単に同期が出来る。(実際には個々の拠点の要望などを考慮したカスタマイズを行うケースが多い)

また、このSalesforce.comではChatterというマイクロブログ機能も提供しており、このChatterを使う事で、Twitterやfacebookのようなソーシャルメディア特有のコミュニケーションメリットを特定の人達に閉じた世界で実現できるようになった。

例えば自身の商談で困っている事を発信する事で、技術部門から解決案のコメントや資料が寄せられたり、類似の案件を成約した他国の営業からアドバイスをもらえるかもしれない。それも一度も会った事も無い人達から。
そしてそのやり取りは一過性のものではなく関係者間の今後の資産にもなる。

このように、日本企業の海外進出において、安価でスピーディーなシステム導入というメリットのもと個々の拠点にクラウドを採用してきた事が、次はグローバルで情報を共有することでより次元の高いCRMを実現するという段階に入りつつある。

金融市場、政治情勢、自然災害など世界中で日々めまぐるしい動きか即座に自社の業績へインパクトを与える昨今のビジネス環境において、リアルタイムな情報共有の重要性は益々高まって行くだろう。そしてその基盤としての情報システムの構築にじっくり時間をかけて…という時代はとっくに終わっているのかもしれない。




追記：
ちょうど、このコラムを執筆中に本稿に関連するニュースが飛び込んできた。

◆日本経済新聞社　2012/1/23　より一部抜粋
—–　—–　—–　—–　—–　—–　—–　—–　—–　—–　—–　—–　—–　—–　—–

トヨタが社内ＳＮＳ、50カ国で10万人　16年までに

トヨタ自動車は月内にも、日本を含む世界50カ国にまたがる販売部門とマーケティング部門の社員を対象に社内向け交流サイト（ＳＮＳ）を立ち上げる。効果的な販売や宣伝の手法を共有し、業務効率を高める。トヨタが昨年、ＩＴ（情報技術）分野で提携した米セールスフォース・ドットコムのノウハウを活用。2016年までに10万人規模が利用する世界有数の企業内ＳＮＳに育てる。

—–　—–　—–　—–　—–　—–　—–　—–　—–　—–　—–　—–　—–　—–　—–

トヨタのような企業がこのような取組を積極的に始める姿勢は、他の企業も追随する事が容易に想像できる。そうなると、グローバル企業においてこのような情報共有の基盤の有無とその活用の仕方が圧倒的な企業の競争力の差に現れる時は、すぐそこまで来ていると言えるのではないだろうか。

蝦名祥征

「多くの人は、見たいと欲する現実しか見ていない」

　とは、古代ローマ帝国の皇帝制の礎を作った、ユリウス・カエサル（英語読みだと、ジュリアス・シーザー）の弁である。

　カエサル率いるローマ軍がガリア（今のフランス）に攻めいった際に、カエサルはガリア人たちにスパイを放つ。ガリア人たちは、そのスパイが話す（ガリア人が）喜びそうな作り話にまんまと乗せられてしまい、後に攻め込まれる要因となったことに対して、カエサルがそう解説している。

　世の中に溢れている情報をどうとらえるか、という点が問われる時代にあって、非常に示唆に富む言葉ではないだろうか。
ビジネスの現場での、「思いこみ」や「希望的観測」で物事を判断してしまい情報活用に失敗するケースと、相通ずるところがある。


　近年のスマートフォンの普及に伴い、データトラフィック量が増大し、通信電話会社ではパケット定額制を見直す必要があるという話題も、世の中の情報がより増大化している流れを示す好例だろう。

　そういった状況を反映してか、最近IT業界におけるキーワードの１つとして「ビッグデータ」が取り上げられるようになった。基本的な考え方としては、一昔前によく語られていた「データウェアハウス」として言われてきたものと、いろいろなデータを蓄積し分析に活用するという点では似ている。異なるポイントとしては
・ データ規模がペタ単位といった、クラウドなどを用いて超巨大な（文字通り「ビッグ」な）データを対象とすること
・ 非定型データを扱うこと
といった点があげられる。

　大量、且つ、非定型データを取り扱うという点で、ゴミデータも相当量発生することになる。それだけに、データを分析する側に情報を取り扱う目がより求められるところがポイントである。

　実際、弊社に頂くご相談の中でも、社内に蓄積された情報をどう分析し業務に活用していくか、という要望は高まっており、その流れは強く感じている。


　そこで、今回は情報分析業務に対する心構えを取り上げてみたい。それぞれ当り前のことではあり、本コラムを読まれるような方には今更目新しいことでもないだろうが、改めて確認するという意味で読んでみていただけると幸いである。

1.　目的を明確にする

　言わずもがなではあるのだが、何はともあれ、分析の目的が明確でないところに正しい結果はありえない。
　良くないケースの代表例は、「分析が言われる世の中だから、とりあえず分析してみたら何か見つかるのではないか」である。

2.　仮説を作る

　目的は明確にしておくにせよ、具体的な結果が出てこないと、その分析アプローチが自分の期待する分析が行われたかがわかりづらい。そのため、ある程度の仮説を定めて、分析を進めたほうがスムーズである。ただ、カッチリ内容を決めきってから分析を行うよりは、スパイラル形式でどんどん試していく方が、手間はかかるようでいて、結果的に得られるゴールまで早いと思われる。

3.　仮説にとらわれ過ぎない

　前述の通り、仮説は重要である。だが、危険なのは自分の仮説に固執してしまい、得られた結果を否定し、自分の仮説を裏付けるアプローチを探し続ける場合である。もちろん、検証として別アプローチで確認することも重要だが、得られる結果を客観視できることも重要である。

4.　分析自体が目的化しない

　こうして仮説→検証と分析をいろいろと進めるうちに、分析自体が目的化し、何のためにやっているんだっけ？という状態になってしまうのが、最悪のケースである。分析自体が延々と続くようであれば、戻るべきは最初に明確化された目的である。目的と合致しているのかどうか、確認を取りながら進めていきたい。


　そして、改めて認識しておくべきポイントは、「多くの人は、見たいと欲する現実しか見ていない」という点である。客観性を失い、自分が見たいデータを集めていないか、自らへの問いかけを忘れてはいけない。

　それに加えて、多くの場合、分析結果は自分の理解のためだけでなく、第三者への説得・説明材料として利用されることが多い。すなわち「見てなかった（もしくは、見たくない）現実を見せる」ためにも使われるということである。その結果として、見たくない現実をきちんと受け止められる人もいれば、受け止めない人も出てくるだろう。

　情報分析自体はロジカルなアプローチで行われる割に、結局この非常に感情的な事柄に最終的な判断が委ねられてしまうことも多い。非常に悩ましい話である。


　そこで最後に、改めてユリウス・カエサルを取り上げたい。

　カエサルは、現実を受け止められない人にも見たかった現実のように見せること、導くことが非常に巧みであったとされる。それは「嘘をつく」のが上手だったということではない。そういった相手の建前なども踏まえて、「ストーリーとしての納得感を作る」のが巧みであった。

　そこまで配慮して進められたが故に、共和制であったローマ帝国において、権力者たちを納得させながらも彼らを抑えて、皇帝制に切り替えることが出来たのである。

　これは、仮説検証を繰り返し、方向性を描き、最終的な意思決定に導く、という、分析の次のレベルまでを実現するには、分析力だけではない「情報の使い手の力量」が大きく影響することを示している。それについてはまた今後のコラムで解説していきたい。

椙田太郎

プロジェクトの基本で大切なのがスコープ決めである。目的・範囲を決め、成果物を定義してプロジェクトを進める。システム化のプロジェクトであれば、顧客からの要件をいかに絞り込んでコントロールできるかがカギになったりする。上流工程で要件が膨らむのが
一番プロジェクト全体に影響を与えるからだ。

　我々ビジネス アソシエイツの業務では、システム構築より前段階の企画や、導入後の定着・活用支援などを含めた範囲で業務を行っているが、プロジェクトの推進を行う上で、スコープが重要なことに変わりはない。

ただ最近は、そもそもスコープを決めること自体が難しいプロジェクトが増えている気がする。目的や成果ぐらいは決められるが、それを具体的にどう実現したら良いのか、どれが正解かが最初からは見通せないような業務課題をプロジェクト化したいという要求があるからだ。企業の主戦場はますます海外に出て行き、IT技術も日々進化している。昨日までとは違う条件で業務を行うため、過去の延長では正解が出ない課題が増えている。

　単純で機械的な作業はすでに定番化されIT化されているし、そこには企業の利益を拡大する要素はあまりない。人間の判断が関与する必要があり個人やチームのスキル・成熟度に依存する業務こそ、ITにより更に成果をあげようとする要望があるように思える。だからと言って何もスコープを定めなければ、早晩立ち往生することになるのは目に見えている。それでは、どうすれば良いのか。

１．目的は明確にし、成果はある程度の想定を置く。
２．成果を評価するための基準を明確にして、作業を組み立てる。
３．作業計画を遂行しながら、細かく評価・改善を行い、作業の組み立て自体を見直す。
作業を組み立て、少し進んでは成果を確認し、作業組み立てを変える。この繰り返しを行いながら、最初の目的に近づけるアプローチをとる。

　目的と成果はぶれないようにしながら、作業とその組み立てを細かいサイクルで調整しつづける。こうすると、プロジェクト全体のスコープは変動し続けてしまうので、コストやスケジュールも細かいサイクルで同じようにチェックして、全体のかじ取りをする必要がある。いわば、管理された朝令暮改が今求められているプロジェクトではないだろうか。

　スコープを固定して計画どおりに遂行するのは、実はコンサルティングサービスを提供する側にとってやりやすい仕事の進め方である。プロジェクトが終わったときに、顧客にとって望ましい地点に到達できなくても、プロジェクトのスコープ通りに仕事を完遂させればプロジェクトとしては成功したことにできるからだ。例え、顧客側で明確にゴールへ到達する道筋が見えていなかったとしても、本当に役に立つ成果をあげられるアプローチを提案できる柔軟さを大切にしていきたいと思う。

長澤毅

要件定義、設計、開発、テスト、運用、・・・。このような古典的なシステム開発工程の形成には、そもそも「システムは一度作ると変更が難しい」という前提が作用している。

　昨今の潮流であるITサービスのクラウド化は、基本的にはこの開発工程には影響しないはずである。なぜならサービスが外部に構築されるだけで、顧客の要望、カスタマイズ、運用保守の手間が減るわけではないからだ。これは基本的に正しいと思う。

　しかしプラットフォームレイヤーの外部化以外でも、クラウド化による目立たない変化に注意を向ける必要があるのではないだろうか。それはカスタマイズの容易化である。

　しかし、どれだけカスタマイズが容易になっても、それはシステム開発のコスト低減に影響範囲が限定されるのではないかという反論があるかもしれない。私はそれに留まらないと思う。

　例を挙げよう。ブログが流行する前のインターネットを思い出してほしい。
インターネットの黎明期では情報発信できるプレイヤーはHTML等のコーディングができる一部の技術者に限られていた。それができない一般人は業者に依頼するしかなかった。この状況はブログの登場によって一変する。難しいシステムの知識は不要となり、無数の情報発信者がインターネットに参入してきた。(このトレンド自体については散々議論し尽くされていると思うのでここでは割愛しよう。)

　では業務アプリケーションのカスタマイズが容易になると、何が起こるのか。それは前述している不可逆的なシステム開発を前提とする開発工程の見直しではなかろうか。

それでは、カスタマイズが容易になると、どのような開発方法が効果的になるのだろうか？

　SFDCのシステム構築を例に挙げてみよう。(もちろんシステム構築方法は開発ベンダーにより千差万別だが、以下の例は我々の経験則から導き出された方法論である。)SFDCでは標準的な使用方法から外れない範囲であれば、機能のカスタマイズはほぼブラウザのみで完結する。反映は即時である。経験則から言うと、パワーポイントの概要図とエクセルで書いた項目定義を見ながら話を詰めるよりも、ホワイトボードで概要図を描きながら実際の画面を作って見せてユーザに確認してもらった方が早いのである。

　もちろん、保守をする上で裏に潜むコードはしっかりと管理しなくてはならないが、それは事後でよい。議論の中で出たキーポイントとなる図も後でしっかりと電子化はしたいところだ。

　ポイントは、要求定義から設計までユーザと密度の高いセッションで固めてしまう点である。外部設計までは、このセッションを続けたい。ユーザに意識してもらう画面やデータ構造は全てこのフェーズで詰めるという原則までは変わらない。ユーザとの打合せでは、数回のミーティングを設け、ユーザからの要望をヒアリングしながらその場で画面をカスタマイズする進め方がいいだろう。蛇足だが、事前にユーザの業態を調べ、ある程度の機能を作り込んでおくとスムーズである。

　しかし、それだけでは完璧とはいえない。せっかく動くシステムがあるのだから、このフェーズで運用確認まで進めたい。ユーザに画面で入力しながらデータを転がしてもらうことで、必要な項目やレポートが早期に見つかるものである。

　ただこの考え方自体は目新しいものではない。昔、言葉として流行ったスパイラルモデルもしくはプロトタイプモデルが、より現実的になったというだけの話である。もちろん、ユーザの長時間の拘束を必要とするデメリットもあるが、動くシステムを介さない古典的な方法論では、この方法と比較して結果的に出戻りが多くならざるをえないと思う。

　筆者にも開発の経験はあるが、両者の違いで例えるとコンクリートによる建造と粘土細工ぐらいの違いがある。もちろん「簡易に変更可能」という謳い文句「壊れやすい」という側面もあるわけで、そこには確認にリソースを割く必要があるわけだが、業務の変化のスピードにどちらが適しているかといえば、いわずもがなであろう。

　こうして外部設計と仮運用テストまで固めた後で、数週間の間に裏側の開発とデータ移行を行う。ここではまだ古典的なシステム開発の手法が有効だと思われる。できれば構築費の安い新興国の開発ベンダーと協業できれば理想的である。(余談となるが、このような経験則からSFDCを活用したシステムは英語をベースに構築することを筆者は強く勧める。)

最近の我々が行っているSFDC導入プログラムの一環として行っている項目がある。それは「ユーザ企業の担当者にSFDCのカスタマイズ方法を教育する」プログラムだ。

　影響範囲が少ない範囲で簡易なものに限定している限定しているものの、業務上の要件の大半はこれで対応できる。(当然これには経験則から導き出される線引きと情報共有のスキームを提供できることが前提となる。)

　システムはシステム屋だけが面倒をみる。そんな常識さえも捨てることを視野に入れる時期なのかもしれない。この考え自体一昔持て囃されたEUCの焼き直しにしか過ぎないのだが、クラウド上にあるプラットフォームを使う前提に立てば、システム部門からのサポートが得られる新しいEUCの姿が見えてくるだろう。