読み終えた直後は、感動したり、様々な読後感が残っているのですが、
多読ゆえか、速読ゆえか、
なかなか、これ1冊をという本がありません。

SE、経営者になってからは、専門書も読むようになりましたが、
1年も経ってしまうと、本を読んだということは覚えていても、
本に何が書いてあったかまで、覚えている本は本当に少なく、
これって読書する意味があるのだろうか？と
自分でも疑うくらいなものです。

このメルマガは、どちらかといえば若いSEを対象に書いています。
紹介するには、要件定義について書かれた本がいいのか、
コミュニケーションについて書かれた本がいいのかと迷っていましたが、
冬休みに読むには適していないと思い、これに決めました。

「7つの習慣　成功には原則があった」
スティーブン・R・コヴィー著 ／ キングベアー出版
http://www.amazon.co.jp/exec/obidos/ASIN/4906638015/ilovex-22/ref=nosim/

既に、読まれた方も多いかもしれませんが、
読み返すごとに、何か新しい気付きがあります。

この素晴らしい本を要約するのは、
恥ずかしく、気が進みませんが、
なぜここで紹介しようと思ったかを簡単に説明したいと思います。

SEやプロジェクトマネージャーという仕事上の職務において、
普通の人は「業務知識を得たい」、
「コミュニケーションスキルを磨きたい」、
「見積でミスしない方法を知りたい」、
「リスク管理の勉強をしたい」と思っています。

もちろん、私自身も長い間、そう思ってきて、
技術的な専門書をひたすら読んできました。

しかし、どうしても技術的なテクニックだけでは、
うまくいかないことがあるのです。
いいえ、うまくいかないプロジェクトの方が
多いと言っても過言ではないでしょう。
ほとんどのプロジェクトが、問題を抱えているのです。

予算が厳しい、納期が短いといった、在り来たりの問題だけでなく、
チーム内部の問題、取引先との問題もあるでしょう。
それ以外にも、メンバ間の人間関係、本人の家族の問題があります。
家族だけでなく、彼女や彼との問題、
広げれば友人との関係性の問題もあるのです。

こういった場合に、個人の価値観の違いが出てきます。
お客さまの価値観、奥さんの価値観が、
「人が足りない」「仕事が切羽詰っている」という、
技術者としての自分の考えと合わず、苦しむのだと思います。

この本が示している「原則」で、一番素晴らしいのは、
公的成功の前に個人としてのあなたの考え方、行動において、
「毎日の私的成功」をしなさいと言っていることです。

仕事をとるか家庭をとるか、などという選択は
この本には書いてありません。

私たちの人生が1つのプロジェクトだと考えれば、それは明らかでしょう。
仕事なのか、家庭なのか、遊びなのか、
といった選択肢の中から1つだけを選ぶのは、
人生においては、明らかに間違っているからなのです。

原則で考え、主体的に選択しなさい、と教えてくれます。
また、原則に忠実、スケジュールに柔軟であれ、とも教えてくれます。

特に人の問題については、短絡的に
能率を考えることはできないと教えています。

「個性主義のテクニックやスキルだけで、人間関係を円滑に、
そして、スムーズに進めようとする風潮がある。
しかし、そういったテクニックではなく、
本来は、私たちの人格そのものが問われるのである。」
と言っています。

人生について、私生活をどう生きるかについて、
大きな示唆を与えてくれるこの本を読めば、
たった1つのプロジェクトが抱えている問題など、
取るに足らないことだと思えてきます。

その上、プロジェクトが抱えている問題こそは、
人生の中でもっと大事な、常にあなたの前に立ちはだかってくる
あなた自身の問題そのものであることに気が付くのです。

人生はあまりに長いように思え、また、多くの成功がちらつきすぎて、
何に向かって努力してよいか分からず、
人は迷ってしまうのでしょう。

この本を読むと、プロジェクトの成功のために
SEとして何をすべきかが、きっと分かるでしょう。
そしてそれは、人生における自分自身の成長のためにすべきことと
同じなのだということも理解できるでしょう。

オンラインシステムが導入された頃は基幹系業務について
企業は3年～5年をかけて導入を進めました。
あれから20年以上、使い続けています。

その後90年代に入り、基幹系システムの導入が一巡すると
情報系と呼ばれる、日々のエントリーデータを活用することを
目的に蓄積し、加工し、情報共有していく流れが活況を呈してきました。

また、基幹系に入れなかった、非定型業務の処理や商習慣による
業務も補完的にシステム化されています。

90年代のクライアントサーバー時代には情報系処理の効率化と
本来、基幹系に入るべき内容まで含め、企業課題に対応していく
流れになりました。

この当時は、レガシーシステムと呼ばれる基幹系システムと情報系システムの
統合が叫ばれ、ダイレクトに基幹系にアクセスしたい欲求に
様々なホスト連携手段にチャレンジした時期でもありました。

ここではデータウエアハウスと呼ばれる業務データ分析を元に
データを蓄積し、情報に転換していこうとする動きです。

データマイニングにより、様々な切り口で分析し、経営に役立てていく
ビジネスインテリジェンスと呼ばれるデータ分析が活用され始めました。

このタイミングでは販売データや人事データ、経理データを元に
分析されています。

ビジネスプロセスモデリングと呼ばれる、業務プロセス単位に定性情報、
定量情報を可視化し、進化していこうという流れになっています。

業務プロセスで可視化を進めているのが、営業情報やＷＥＢのアクセス解析等、
日々の売上に直結するデータ収集と分析が行われるようになり、
企業サイトのログ解析は40％以上の企業が導入しています。

こうしたことから、社内業務であっても業務プロセス単位に可視化を進め
日々進化していくことが、より重要になってきています。

実績データからの分析とは異なる、潜在的なマーケティングの可能性を
探る上ではネットマーケティングを活用した分析は今より重要な意味を
持ってくるでしょう。

ネットマーケティングでの仮説や分析をもとに、営業戦略や事務処理フローの
見直し等、業務改善が進んでいくものと予測されます。

今後のシステムインテグレーターはビジネスプロセスのプロフェッショナル
になって行かなければ困難な状況になっていくことが予想されます。

上流工程のＳＥはビジネスを理解し、仮説立案できる能力が必要になります。
是非、ネットマーケティングの分析とそれらを改善する技術にも目を向けて
チャレンジして頂ければと思います。

忘年会も頻繁に行われるし、
年明けの納品を睨んでいる人たちにとっては、
厳しいスケジュールが続いていることでしょう。

今年の年末から来年のお正月にかけてのお休みは、
9日間という企業が多いようです。
（当社も、珍しく9連休とさせていただきます）

この休みを嬉しいと思っていたSEも、いざ休みを目の前にすると、
スケジュール通りに仕事が進んでいない現実を目の当たりにして、
どうしようと悩んでいる場合が多いのではないでしょうか。

休みになると、好きなときに、好きな時刻に会社にやってきて、
ちょっと仕事をして、すぐ帰ってしまうという技術者を見かけます。
（こういう人達が出社するのは、
午前中ということは、決してありません）

彼らが単に「前倒し作業」を心掛けて、
部下が少しでも仕事をしやすいように準備しているのだとすれば、
それはとても良い心掛けです。

しかし、そういう人ばかりではありません。

遅れてしまっている作業を行うためであったり、
タスク一覧には載っていなかった作業で、
人には言えない作業を行うために、
会社に来る人もいます。

また、納期を守るためという御旗のもとに、
納期前日になって徹夜をする技術者がいます。
私には、納期前日の徹夜作業という事態が、疑問に思えるのです。

例えば、その作業が工数24時間以内程度の小さな仕事であったならば、
多少の見積もりミスが生じて、
徹夜作業になってしまったということはあるでしょう。

しかし、数人の作業者が何週間もかかる作業が、最後の1日に徹夜して、
ぎりぎりで間に合うということがあるものでしょうか？

要するに、何を言いたいかというと、
納期の前日になって徹夜しなければならなかったという仕事は、
完全に作業を終えていないのではないか、ということなのです。

納期直前になって、到底終わらないことに気づき、
徹夜作業になったが、結局、時間切れになってしまったのではないか、
ということなのです。

あとどの位で作業が終わるかを、勘に頼ってスケジューリングしていると、
こういう事態になります。

もちろん、システム開発の仕事というのは、
スケジュール通りに進むことが難しい仕事です。

だからといって、それまで徹夜していなかった作業者が、
最後に、つまり納期の前日に徹夜して、
ちょうどぎりぎりで間に合った、
などという偶然を信じることはできません。

納期の前日の昼間にきっちり終了していない仕事については、
どう考えても、徹夜をするのではなく、
1日、2日伸ばしてもらうべきなのではないか。
徹夜をすれば、ぎりぎり間に合いそうだと思ったとしても・・・。

いやいや、その何日か前に交渉すべきだとか、
もっと生産性をあげるとか、仕事を調整して減らすとか、
他にできることは1週間前ならもっとあったはずです。

SEは、プログラマを抱え、部下の管理だけでなく、
お客さまとのやりとりをしなければならない、
日々、常に多くの仕事があります。

その日常の中で、雑用に追われ、
仕事で「やっていないこと」が見えてないことがあるのです。
だから、こういう長い休みのときに、
1日、会社に出て、客観的に全体を見直すこと、
役割、分担、売上、原価、手法などあらゆる面から見直すのは、
良いことだと思うのです。

そこで提案です。

「休みの日に、プログラムを作る、直す、チェックするなどの
現場作業をしない。」
と、一度、宣言するのはどうでしょうか。

その上で、自分がしなければいけないタスクを再度洗い出して、
チーム全員で残作業を常に共有していく。

本来のPMの仕事は、潔く、真実を見つめることから始まるのです。

だから、「何をすべきかを管理する」というお話をさせていただきました。
そこで、自分自身が何をすべきか、それを管理するツールとして、
手帳があるということでした。

では、プロジェクトのスケジュールを管理するのは、
どんなツールなのでしょうか。
もちろん、プロジェクト管理にもスケジュール表があります。

システムの見積金額は“人月”という言葉で表されるように、
人が1ヶ月働いて幾ら、という見積もりが基本となります。
SEが3人投入されて、1ヶ月で出来る仕事は“3人月”と呼びます。
だからこそ、1ヶ月で終了すると決めた要件定義が、
2ヶ月経っても終了しないとすれば、
そのコストは、明らかに2倍以上かかっているのです。

しかし、「管理する」という言葉を、
「最初に決めたスケジュール通りに実行する」
ということだと誤解してはいけません。

なぜなら、プロジェクトにおいては、
「突発的な出来事」、「予想外の出来事」が、
起きないことのほうが珍しいからです。
規模が大きくなればなるほど、
最初に決めた順番が、守られなくなることが多くなります。

そんな時、大抵のSEは
「魔法で事態をリカバリする能力があればいいなあ」と
天を仰いで思うものです。

もちろん魔法などあるはずもありません。

そこで、
・現時点におけるスケジュール進捗状況
・見積りの見直し
・要員の増加の検討
が必要になってくるのです。

急に顧客企業の事業戦略が変わった、
などの理由による追加仕様が優先されるのか、
それとも、これまでやってきた約束作業の完了までが優先されるのか、
このような適宜な判断も必要になってきます。

もちろん、時間が管理できないのである以上、プロジェクト管理においても、
管理されるものは、「何をすべきか」「何をしないでおくべきか」
ということになってくるわけです。

プロジェクトマネージャに必要とされる能力は、
何かを拾うために何かを捨てるといった「トレードオフ能力」、
最終的には、深い洞察と野性の勘からくる「統合バランス能力」
なのではないかと思います。

差し迫った状況内においてだけでなく、
何かをする時には必ず、
限られた時間を使って、本当にこれをする必要があるのか？
そしてそれは、「最優先事項であるのか」を問う必要があるのです。

ベトナムで仕事をするようになって、外国語と文化について少し考えさせられたことが
あったので書いてみたいと思います。

ちなみにここで出てくる外国語は、外国人にとっての日本語の話です。

きっかけは、社外の通訳の人と会話をしたときのことなのですが、その話の前に
弊社のベトナム人の通訳のことをまずお話ししたいと思います。
彼女はまだ若い社員なのですが、日本語の資格も１級を取得している非常に
優秀な社員です。

彼女とはかなり難しいレベルの話まで、問題なく日本語のみで会話をすることが
出来ます。

もちろん、どんな話題でも日本人と話すときと全く同じというわけにはいきませんが、
普段の仕事・日常の会話では、特にこちらが意識してゆっくり話さなくてはいけない、
などと気を使うことは、ほとんどありません。

でも彼女と話をしていて、こちらが「外国人と話をしている」という気をあまり
使わなくてよいのは、彼女の語学力がただ優れているというだけではなく、
日本の文化をよく理解しているからだと思うようになりました。

それは社外の通訳の人と話をしていたときのことです。　彼女の日本語の語学力も、
うちの社員と変わらないレベルだと思っていました。

でも、とても「外国の人と話をしている」感を強く感じていたのです。

それは、彼女がYes／Noをとてもはっきりと断定して言う、また自分の意見を強く主張する、
というところから来ていた違和感でした。

こう言うと誤解されてしまうかも知れませんね。　うちの社員もきちんと
Yes／Noは伝えますし、自分の意見も主張します。　でも、そのときの言い方が、
とても日本人らしいのです。

例えば、その社外の通訳の方は、とてもハッキリと「○○です！」「××ではありません！」
「それは違います！」と言います。
どちらかと言うと、しゃべっている言葉は日本語ですが、内容は非常に英語的だと感じました。

それに対して、うちの社員は、「○○ではありませんか？」
「これは××ではないのではないかと思うのですが」「それは多分違うと思います」という
ような言い方をするのです。

言っている内容はどちらも同じですが、あきらかに答えがわかっているようなときでも、
あまり日本では、特に年下の女性が年上の男性に対して、断定してものを言う文化はありません。

いい・悪いは別として、少し遠回しな言い方をするのが、日本の文化なのだと再認識をしました。

以前、どこかで読んだのですが、日本で働いている韓国人の方が、部下に仕事上の命令を
「○○しなさい！」と、文字通り命令形で言ったら、とても反感を買ったという
話がありました。

日本語に命令形はあるが、実際には業務上の命令をするときでも
「今日中に○○出来る？」とか「○○お願いしたいんだけど」などと言うのが、
最初はわからなかった、と言っていました。

真の語学力というのは、学問としての語学だけでは足りず、文化まで学ばなくてはならないのだと
感じました。

ビジネスを成長させる５つ目の成功法則。それは・・・

「見込客の基盤をつくる」です。

ビジネスが成長するかどうかは見込客の多さにかかってきます。

見込客が少なくても一時的に売上をあげることはできます。
しかし、持続的に成長しようと思ったら、見込客の基盤をつくることが
とても重要になります。

どの会社でも、顧客の構造はほぼ同じです。

見込客が多い存在していて、その何割かが既存客、そして、そのまた何割かが
リピート客になります。

　見込客＞既存客＞リピート客

見込客を底辺として、まさにピラミッドのような構造になっています。

ここでポイントが２つあります。

●なだらかなピラミッドになっているか？

底辺から頂点まで階段がなく、極端に数が減っていたりしていないでしょうか？

もし、なだらかなピラミッドになっていないようなら、段階に応じた商品やサービスを
用意する必要があります。

例えば、見込客向けには、低価格で購入リスクの低いフロントエンド商品（集客商品）を
用意し、既存客向けには、高収益のバックエンド商品（本命商品）を用意するのです。

●ピラミッドの底辺の裾野が広いか？

ピラミッドの底辺が広ければ広いだけ、経営は安定します。
ここが狭いと、常にお客を追いかけなければならなくなります。
できるだけ裾野を広くすることにより、お客が行列をなすような状況を作り出すことが必要です。

そのためには、名刺交換した人に対して、無料のニュースレターを送るなど、
まだ取引のない見込客とのパイプを幅広く持っておく必要があります。

この基盤をつくれるかどうかがビジネスが成長続け、安定するための鍵です。

あなたのビジネスは見込客の基盤づくりができていますか？

さて、これから数回に掛けて、
システムエンジニアを目指しているプログラマ、
そして、SEの若手に向けて、
基本中の基本の考え方について紹介したいと思います。

今回は、その1「日時」についてです。

最近のシステム開発は、分析系システムであったり、
ECサイト系の開発が多いのでしょうから、
日時というのは、常に、リアルタイムの年月日、
時刻を意味することが多いのでしょう。

そんなシステムばかり組んでしまうと、
会計システムや販売管理システムといった、
基幹業務の年月日についての感性が、
育たなくなってしまうことが少し心配です。

そこで、知識だけでも、「日時」について考えてみたいと思います。
本当に初心者向けの当たり前のことばかりですので、
キャリアが3、4年以上ある方は、読み飛ばしてください。


●日時には、今、そのとき、その瞬間という意味と、
　過去のある日時を意味する場合がある。

例えば、Aイベントホールの座席表を考えてみましょう。
予約受付システムを請け負った貴方が考える予約済の座席数、
これは、お客様や担当者が画面照会したその瞬間、
つまり、今現在です。

1秒後には数が違う可能性があります。

一方、あるイベントは、11月15日受付分までを
先行予約分として、チケット料を10パーセント値引きすると
宣言していた場合はどうでしょうか。

この場合、予約済数が分かるだけでなく、
値引き販売数もシステムで把握する必要があります。
例えば、11月26日昼13時現在の予約済数が623名で、
11月15日までの受付分は、324名であるという、
過去のある時点までの集計値をとっておく必要があるわけです。

もちろん、ハードやデータベースの性能が十分にある場合は、
集計値をデータベースに項目として持つ必要はなく、
クエリで、日付範囲指定で集計すれば大丈夫ということもあるでしょう。

しかし、次の場合はどうでしょうか。

B社では経営会議が毎月開かれています。
営業の月間成績表は、翌月3日には集計され、
その表を基に5日に経営会議が行われます。

項目として、月間受注金額、（半期）累計受注金額、
受注残金額が載っています。

Cさんの10月の営業成績は、
　・月間受注金額　         1600万円
　・（半期）累計受注金額   1600万円(10月は半期の初めの月です）
　・受注残金額　　　　　　 4300万円
であったとします。

11月は、
　・11月30日までの新規受注金額　700万円
　・受注から売上になった金額　　2300万円
ありました。

ところが、10月に受注した案件でトラブルがあり
　・400万円が受注取り消し
となってしまいました。

しかし、
　・12月2日付け新規受注金額　 　3200万円
取ることができました。

さてCさんの12月3日に出した営業成績表はどうなるでしょうか。

＜答え＞

　・月間受注金額　         300万円 (700-400)
　・（半期）累計受注金額   1900万円
　・受注残金額　　　　　　 2300万円

ここで注意すべき点は2つ。

11月の帳票でも、10月の訂正分は、マイナスされるということ。
受注残金額といった、一瞬の残を表示するようなものも
固定月報に印刷する場合は、11月末日を締として、
翌月分の日付の伝票は集計しないということです。

特に、経営会議で検討するような表には、
リアルタイム性よりも、月間、月間で積み上げた場合に
正しい合計となるものが求められます。

もちろん、ここで集計のキーとなる日付は、入力年月日ではなくて、
伝票年月日（受注伝票であれば、受注年月日）です。

こういった、「伝票」としての業務の集計方法を覚えておきましょう。

そして、これらの数値は、何ヶ月後に見ても、
常に同じ値が表示、集計されることが、
ほとんどの場合必要となるのです。

９６年頃に国内に登場した『ロータスノーツ』は企業の部門単位でグループウエアとして
情報共有の仕組みを構築してきました。その後、グループウエア専業の企業が登場し
ＥＩＰと呼ばれる企業情報ポータルに統合されてきました。

部門単位や顧客単位、担当者毎に必要な情報をエントリーし、検索しやすい環境の構築
と暗黙知、形式知を企業の資産として活用していこうという流れです。

デジタルダッシュボードとも呼ばれ、必要なときに必要な情報を引き出し、必要と思われる
情報を整理された形で登録していく。

さまざまな企業へ導入されましたが、大きな成果に至らない事態も多く見受けられました。

ひとつめは暗黙知を定型化しづらかったこと。これらの情報は同僚や職場の仲間の間で
雑談的に継承される特性の情報であったからです。

もうひとつは人事制度の未整備にも問題がありました。

ノウハウを保持するスタッフが情報を公開する際の人事考課も合わせて導入しないと
積極的な情報共有の動機づけが機能しなかったからです。

これらは現在、ビジネスブログと呼ばれる、ブログを活用した社内、社外の情報共有また
情報発信として活用されています。

社内の埋もれている情報をブログにエントリーし、お客様に公開してよい情報は公開していく。

この流れが加速しています。

ここでは、承認ルートや決済機能も導入され、企業内情報共有の仕組みと広報、営業ツールとして
の機能が備わっています。

中小企業にとっても導入しやすく、情報の整理という意味でも導入効果があがっている企業が
増えてきています。

ＥＤＩの流れを見てみると、９０年代後半から始まった企業関連携の仕組み。

業界で標準化されたフォーマットにてデータ交換を行い、企業間取引での受発注、
事務処理業務の効率化が期待されました。

ここでは各業界での固有の商習慣に対応するためのデータ連携の難しさが露呈しました。

業務効率を高めるはずが、事業処理を定型業務に落とし込むか、パッケージに業務を合わせるか
困難な選択を行うことになりました。

データフォーマットはＸＭＬフォーマットが採用され、データ属性により、アプリケーションの
振る舞いを行い、入力データの属性により、制御を行っています。

これらは現在、ＲＳＳと呼ばれるメタデータの情報共有の仕組みでも活用されています。

今後はＷＥＢサイトの更新情報だけでなく、ＤＢや企業間連携フォーマットとしても
発展していくことが予測されます。

駐車場の混雑状況、交通渋滞情報、レストラン予約や医療の予約等々これらを活用し
携帯電話やカーナビとも連動した活きた情報とＤＢによるトランザクション管理による
正確な情報発信が実現されます。

これらが普及していくとＥＤＩの理想とされていた、フレキシブルな企業間連携が実現できるのです。

現在のＲＳＳがメールコミュニケーションと同じでないのは既にＥＤＩによる企業間連携の
フォーマットとして定着していることから、今後の発展に期待されるフォーマットです。

なぜなら、現在のビジネスブログと同様に、販売、セールスの場面でも活用できることから
企業の積極的な導入が期待されるからです。

ソフトウエア産業には業務の効率化だけでなく、販売、セールスでの効率的な活用も期待されています。

「7つの習慣」という全世界で1,500万部、日本で100万部を売った、
ビジネス書の大ベストセラーがあります。

この本に書かれている、
「時間は管理できない。
（なぜなら誰にでも24時間しかないからである）
しかし、自分の行動は、管理できる」
という観点から、自分が、本当に大切に思うことを実行する為のツールとして、
この手帳があります。

私の印象では、コンサルタントや経営者には、
この手帳を使っている人が多いように思えます。

以前は私自身も、小さな貰い物の手帳や、
ザウルスのようなPDAなどを使っていましたが、
そのときには、手帳に、人との約束（自分が誰と、どこで、いつ会うのか）
といったことを書き記すに過ぎませんでした。

2、3年前からフランクリン・プランナーを使い始めたのですが、
気に入って手離せなくなりました。
手帳の中身を見ただけでは、他の手帳とどこが違うのか、分からないかもしれません。

しかし、明らかに思想が違うのです。
時間の使い方に関する思想というのは、次のようなものです。

●「時間とは、何か？」
　「時間とは、連続した出来事である。
　出来事というのは、朝、起きた。顔を洗った。食事をした。家を出た。
　といったものである。
　一人の人に与えられる時間は、1日24時間、誰にも同じである。
　ところが、時間は、連続した出来事であると考えると、
　人が何をしたか？ということは、人によってまったく異なるのである」

●「時間は、管理できないが、
　何をするべきか、何をするかは、管理できる」

これらが、手帳を使う最初の思想となっています。

次に、自分が何をすべきかを分類分けして教えてくれます。

●第1領域　緊急性が高く、重要であること

●第2領域　緊急性は高くないが、重要であること

●第3領域　緊急性が高いが、重要でないこと

●第4領域　緊急性が高くなくて、重要でないこと

この、第1領域の出来事は、
何が何でもやらなければならない、必須のこととなります。
これが多い人は、ストレスが非常に高くなります。

第3領域は、
「人が約束なしで尋ねてきた」
「電話がかかってきた」
「意味のない会議やドキュメント作成をすることになった」
「急に雑務を言いつけられた」
といった、そこまで重要ではないが、緊急性が高いものです。
この第3領域に、人は時間を浪費してしまうようです。

そして、第2領域。
例えば、1ヶ月後の納期のプロジェクトの仕事であったり、
1週間後に約束したプレゼンテーションの資料といった、
緊急性は高くないが重要なものです。
これを、つい後回しにしてしまうのです。

つまり、重要性よりも緊急性を選択してしまうわけです。

本質的に、時間をどのように使うべきか、という視点でみた場合には、
当然のごとく、緊急性がないときに重要なことをやっておく、
つまり、第2領域の仕事をつぶしておくことが、
第1領域に入った場合に楽ができることになります。

常に第2領域に注力して、
前倒しで作業をすすめるということが、とても重要になるのです。

なぜならば、第2領域の出来事は、
放っておけば、確実に第1領域に移るからなのです。
第1領域に入ってしまえば、
すべてのことよりも優先させなければならないからです。

これらの思想は、
スティーブン・R・コヴィーの「７つの習慣」にも書かれており、
フランクリン・プランナーがセミナーを幾つか開催しています。

わたし自身も、この本や手帳で人生がずいぶんと変わりました。

自己啓発に興味を持っている人には、
おそらく、最強のツールだと思います。

ベトナムに会社を作った２つ目の理由として、日本国内の技術者不足があります。

人手不足が深刻になりすぎる前に、日本へ優秀な技術者を連れてくるための
礎を築いておきたいと考えたのです。

これはまだ一時的に連れてくることしか実現できていませんが、
将来的には長期に渡って日本側で仕事をするエンジニアを育てたいと考えています。

そして３つ目の理由です。

これは、将来のベトナムの発展を見据えて、今のうちにベトナムで会社を
作っておきたいと直感したからです。

私は経済の専門家でも国際情勢に詳しい訳でもないので、「将来の発展」の根拠は？と聞かれても、
きちんと答えることが出来ないかもしれません。　でもハノイ・ホーチミンの街を歩いて、
ＩＴ業界の人達と触れて、これはいける！！と肌で感じたのです。
もちろん、予想はハズれるかもしれませんが、やらないことで後悔はしたくありませんでした。

それに今のベトナムでソフト開発の会社をスタートするというのは、全く同条件とはいえませんが、
７０年代のバブル前の日本に戻ってソフト会社を起業するようなメリットがあるのではないかと考えました。
いろいろな人の話を聞いた中でも、ネットワークや電機、ビルなどのインフラ面でも整ってきた今は、
ちょうどいいタイミングだと感じられました。

さて、そんなこんなでスタートした会社もすでに８ヶ月がたち、
人数も１２人と順調に増えてきています。

でも、これからが本番です。　会社をスタートすることは、ある意味誰にでも出来ますが、
難しいのは継続することだからです。

とりあえず今回で「ベトナムに会社を作ったその訳」は終了です。

駄文にお付き合いいただきましてありがとうございました。

コミュニケーションチャネルでネットが無視できない存在となり
ネットマーケティングでの販売の仕組みや顧客関係の流れに変化が起こりつつ
あります。

現在までは営業支援システムとしてのＳＦＡ、顧客関係管理としてＣＲＭが
活用されてきました。

イベント、セミナーによる集客後のフォローアップの際のプロセスを見てみると
興味関心があるが、直ぐに購買に至らないお客様をどのようにフォローしているでしょうか。
お客さまのステイタスは把握していますか。

営業マンがフォローを行うにも限界があり、また、企業サイトからのアクセス分析も
可能になってきたことより、どの企業がどのようなコンテンツにアクセスしているのかを分析し、
次のアクションに役立てています。

はじめて訪問された情報、何度か訪れた方の情報、コンテンツの遷移に伴うニーズ分析を実施し、
購買に至らないお客様の分析とフォローが行われています。

このように、営業現場で活用されてきたＳＦＡはネット上でも活用され、
購買されたお客様に対して行ってきた顧客関係の構築についてもネット上で
実施されつつあります。

データを収集、分析しやすく、また、リアルタイムにコンテンツを更新できる
ネットならではの活用方法ではないでしょうか。

購買後のお客様との関係構築についても変化が見られます。

きっと気に入って買ってくれたお客様なので、そのままお客様の言葉で友人や知人に勧めてください。
有名なアマゾンでのお勧め機能が活用されています。
これらは『レコメンデーション』や『リコメンデーション』『リコメンド』と呼ばれています。

お客様にとっては自分の好む情報を選択することができ、情報を提供する側にとっては
顧客の購買率を高めることができる。
まさに、顧客満足の向上と販売促進との双方を兼ねたサービスの手法として、
急速に普及しつつあります。

このように、買って頂いたお客様との関係深度を追及し、ロイヤリティを高める、
優良顧客化の流れだけではなく販売パートナーとして、また、購買後のご意見伺いとしても、
関係性の構築を実施していくことが顧客との対話につながり、商品やサービスの改良につながると
期待されています。

お客様の言葉で書かれた言葉やお客様の不安、不満を改善していくことができれば
商品やサービスが強化されていくと思っています。

サービサー側の理論でこれはできない・・・等々、自身もよく思うことなのですが
前向きに捕らえ、お客様の声に対応していきたいと強く思う、今日このごろです。

若手エンジニアの特徴として、
何でも顧客に聞いてしまうということが挙げられるでしょう。
一つ一つ聞いて、一つ一つの答えを貰ったら、
その通りに作ればよい、と考えてしまう人が多いのです。

設計をチェックしていて、まずい部分をみつけ、
「どうしてこう作ったの？」
と質問すると、
「お客様がそう言われました」
と頑として退かない技術者もいます。

つまり、
自分の頭で考えた結果ではない、
プロとしてそれが良い設計なのか悪い設計なのか、
必要なのか不必要なのか、
といったことを考えないで、
顧客が言った通りに設計した、というわけなのです。

ここには非常に大きな問題が潜んでいます。

それは、
「顧客がどんなシステムが欲しいのかを、本当に分かっているか？」
ということです。

技術者の質問に対して、顧客が答えるといったやり方では、
本来の顧客の日常の全貌を、
技術者が理解しないで作ることもあるのです。

また、一つ一つの答えを結びつけてつくったシステムでは、
組み合わせに問題があることに気づかずに、
運用がうまくいかないこともあるのです。

顧客が考えているのは、
「相手は、なんといってもプロだ。
分かってくれて、うまく作ってくれるだろう」
ということなのです。

ここを開発側がどれだけ分かっているかが、ポイントとなるのです。

顧客にOKを貰っていようとも、
ドキュメントを確認して印を貰っていようとも、
実は、本当のところ、
どんなシステムが出来上がるのかは、
顧客が分かっていないことが多いというのも、事実なのです。

顧客が望むシステムをイメージできていないとしたら、
プロである貴方はどうでしょうか？

実は、貴方は顧客よりも、もっと、
実現したシステムのイメージが無いのではないでしょうか？

だから、
一つ一つ細かなことを全部顧客から聞かなければ、
設計できなかったのではないでしょうか。

では、プロとして、SEとして、
何を聞き出したらシステムをイメージできるのでしょうか？

何だと思いますか？

それは、
顧客の業務内容、
日常の顧客の行動パターンや思考パターン、
課題・問題を含めた、日常の些細なこと全てです。

それらについて知っていなければ、
システムをイメージできないでしょう。

システムを作るということだけを目的に、
一つ一つを顧客に質問し、
顧客に選択してもらって設計するという作業が、
どんなに怖い作業かおわかりでしょうか？

貴方は、顧客の何を知っているのか？

システム設計者に求められる最終的な責任は、そこだと思うのです。

それは、今までの概念でメディアという媒介を示すものではなく。

一方向のコミュニケーションから双方向へシフトしている。

一般的なセミナーではこう語られています。

私自身もそう話しています。

これは、雑誌、編集の現場や通販の業務でも、以前より実施されて
きたことで、お客さまの声やユーザ連動企画等々が行われています。
また、メーカー様のお客様推進センターでも、情報を収集、分析し
販売企画や製品企画へ繋げようと、様々な工夫を凝らしてきました。

現在でも、ハガキやお客さまの声を店舗で回収し、また、
サンプル品や試供品のアンケートを収集し、役立てています。

このプロセスの課題はお客さま側には生活をしていく上での背景
があるということです。

それぞれの顧客の生活実態や置かれている環境が異なることから
言葉に変換された時点での暗黙知から形式知に置き換わる
言葉の地図が異なることに起因します。

こうしたことより、覆面調査やブログ、ＳＮＳ等に代表される
ソーシャルメディアでの調査が重要視されています。
また、グループインタビューや座談会等の生の生活実態を把握する
ことも重要になってきます。

企業側では企業コミュニティーを企業側で運営したい欲求に駆られますが
そうすることで、結果的には現在のサンプル提供やアンケートと同様に
生の本音を収集することは困難になるでしょう。

企業が運用しているコミュニティーで本音を書かないのは当然なのです。

コミュニケーションの質を高める為には第3者の中立的な存在が必要になります。

メディア側が行ってきた役割がオンラインでリアルタイムになり、その結果
としてメディアによる深いコミュニケーションが求められています。

また、消費者側でも検索サービスによって、情報収集の量が莫大に増えたこと
から、自分のほしい情報に近しい道しるべ的存在を求めるようになってきました。

オンラインメディアの信頼性についても、自身が判断していくスキルを
求められているからです。

以前は薬を医療機関から貰うと、それを疑いもなく飲んでいました。
現在は薬の説明があり、ネットで調べて、副作用はその他の問題がないかを
確認しています。

この文書を読まれている方も、この文書は何らかの影響を受けた、目的を
持ったコンテンツであるかを、様々なリンクや筆者のバックグラウンドから
正しいか正しくないかを判断しています。

人は、こうした情報に対して敏感であり、情報を操作すると解ってしまいます。

専門的なコンテンツを扱うソーシャルメディアへの記事投稿もソーシャルメディア
最適化への第一歩になりますし、ブックマークサービスや話題になるコンテンツ
を発信していくことも最適化に繋がってきます。

そうした最適化への手段としてＰＲやＳＥＭ、ＳＥＯ、コミュニティの運営
アフィリエイト等々の手法があります。

広告プロモーションにおける、ブランディングやコミュニケーションの絆を含んで
ソーシャルメディア最適化が語られます。

近年注目されている『クロスメディア』の効果としてソーシャルメディア最適化
があると思います。

コミュニケーションの量と質でこれらを測定していくことは
今後の課題でありますが、仮説、検証を実施していく以外に道は開かれないでしょう。

次回からは本題でもあります。

いよいよ情報サービス産業様が深く関わる内容に移ります。

ネットマーケティングと連動するＣＲＭやＳＦＡについてお話を進めていきたい
と思います。その際にリテンション（お勧め）レコメンドとも呼ばれています
話題にも触れ、その後、ＥＤＩやナレッジマネジメント、ＥＩＰに進み
基幹系システムへお話を進めていきます。

消費のトリガーや消費へのアクションに変化が起きているのですから
企業システムの情報系や基幹系のシステムについても変化が起きてくるのは
当然のことなのです。

久しぶりに物凄く面白い（興味深い）と思った本でもありました。

ちょうど「リスク管理」のことを考えていた、というタイミングも
あったかもしれませんね。

しかもNHKで放映された8回の番組のDVD付きなので、
2,800円という値段も高くないと思える内容です。

人間はいつの時代も失敗を繰り返してきた。

なぜ同じような失敗が繰り返されるのであろうか？

これは、社会共通の問題でもあり、
プロジェクト管理の問題でもあるわけです。

第一章では、六本木ヒルズの回転ドアで起こった
痛ましい死亡事故について例示されています。

もともと、ヨーロッパから回転ドアが取り入れられたとき、
ヨーロッパでは、

「ドアは軽くてゆっくり動かなければ危ない」

という暗黙知があったそうです。

それを日本に取り入れたときに、
「風圧が強くても耐えられるものにしたい」
「見栄えよくしたい」
といった要求があり、骨材がアルミから鉄に変更され、
ステンレス板で飾られ、
その重みに耐えるためにドアの外周に
モーターやブレーキを取り付けた結果、
当初の3倍近い2.7トンもの重量になってしまったということなのです。

そして事故の防止策としてセンサを取り付け、
何かが挟まったときに、ストップするようにしたということなのです。

つまり、要求に応えることで、つぎつぎと設計を付け足す
「付加設計」を行ってしまったのです。

安全性を実現しながら機械やシステムをつくるためには、
「本質安全」と「制御安全」があるそうです。

一つ目は、事故が起きたとき、
たとえ安全を守るためのシステムがうまく作動しなかったとしても、
大きな危険を及ぼさないようにする考え方、これを「本質安全」といいます。

二つ目は、安全を守るためのシステムを取り入れて、危険を防ごうという考え方です。
これが「制御安全」です。

まさに、六本木ヒルズの回転ドアは、暗黙知であった
「ドアは軽くてゆっくり動かなければ危ない」
という「本質安全」をないがしろにして、
「制御安全」だけを考えて設計されてしまったというわけです。

しかし、このメーカーでは、この失敗をもとに、
「本質安全」の立場に立ち返り、
ドアに触れれば、ドアが折れ曲がるといった形に変えているそうです。

そしてその上に、緩衝ゴムや透過式センサをつけて、
「制御安全」を補助として追加したそうです。

私たちのシステム開発においても、同じことが考えられます。

つまり、どんなに単体テストを繰り返そうとも、
他人テストを行おうとも、100%のバグは取れない、ということを
心に焼き付けてシステム設計する必要があるのです。

これは、「テストは、いい加減でよい」ということとは全く違います。

しかし、「本質設計」として最低限、安全な設計をする。

つまり、バグが出ても、最悪のことが起こらないような設計をする。

ということが求められているのだと思うのです。

その上で、バグが出た場合に、どのようにエラーメッセージを表示させるか、
どうやって処理を止めるか、といった「制御安全」が付加されるべきだと思うのです。

単に「制御安全」だけのシステムは、本末転倒なのです。

起こってしまった失敗を、社会全体の共通の財産だと考えてこそ、
失敗が初めて生かされる。

徹底的に失敗の原因を究明する。

失敗を活かし、失敗に学ぶ。

失敗が起きると「誰が悪い」「何がおかしい」といった
責任の追及に走りがちな私たちですが、
まず原因の究明をしてから、責任の追及というように、
価値を変えていくことも必要なのだと語っています。