外資系企業に住む住人の視点からIT業界の出来事を伝えます。ご興味のある方は、メルマガの登録をお願い致します。Twitterやっています。→http://twitter.com/juntoku_yマイナビニュースで「IT業界裏講座」を掲載中です。そちらもヨロシクお願い致します。→コンサル直伝−IT業界”裏”講座EnterpriseZine(翔泳社)で記事掲載中です。そちらもヨロシクお願い致します。マネジメントセンター(JMAM)より「フレームワーク使いこなしブック」を上梓しました。仕事の質と効率を高める思考の枠組み・フレームワーク。本書は、架空のパンメーカー・ナイスハーベスト社を舞台に、新人のむぎ夫がフレームワークを使って課題を解決していくストーリーを追いながら、フレームワークを学べる仕掛けになっています。最終章では、オリジナルのフレームワークを作る方法も紹介。「わかる」レベルから「使える」レベルに無理なくステップアップできます。2012年7月末、同じくJMAMより「ビジネス思考法使いこなしブック」を上梓しました。こちらもむぎ夫が登場し、ロジカルシンキング・ラテラルシンキング・クリティカルシンキングの3つをどうやって使いこなすか、問題解決の発想技法を学べる仕掛けになっています。このジャンルでは、おそらく初めて3つのシンキングを体系的に1冊の本でまとめている本です。以下の書籍も執筆しています。こちらも合わせてどうぞ。『外資系企業に住む住人の視点からIT業界の出来事を伝えます。以前好評いただいた『資料作成の基本』から図解作成だけにテーマを絞って抽出した本が2018年6月23日に発売となります。https://www.amazon.co.jp/dp/4799106511本書は「資料」ではなく「図解」の作成に特化しています。図解は、論理的にわかりやすい内容、感覚的に心地よい見た目が好まれます。図形のカタチ(フォーム)と配置(ポジション)で生み出される「要素のバランス」、色の使い分け(カラー)によって醸し出される「コンテンツの強弱」です。それらを「図解キューブ」というモデルで表し、その実践例をチャートとグラフの「図解パターン」として体系的・網羅的に整理しました。これらを「エグゼクティブ図解術」と私は呼んでいます。本書を図解作成のハンドブックとして、ぜひ使ってみてください。1ヶ月ぶりの発行になります。本当に申し訳ないです。何人かの方からは安否を気遣うメールも頂きました。この場を借りてお礼を申し上げます。後ほど個別にお返事致します。生活のペースも整ってきましたので、またメルマガを発行できるようになりました。これからも宜しくお願い致します。記事内容に対する、皆様からのフィードバックを受け付けております。皆さんの忌憚のないご意見を遠慮なく書き込んで下さい。さんの職場ではどんなパッケージを利用していますか?物流系の会社ならSAPやi2、コールセンターだとSIEBELが有名なところですよね。他にもTIBCOやVitriaのようなBPMを扱うところもありますし、Oracleだってパッケージベンダーと言う事もできます。今回は、そのなかでも、本国の開発部隊が力を持つベンダーについてお話しましょう。SIプロジェクトでシステムを構築するとき、まず大きく2つの選択肢があります。合いのアプリケーションを購入するのか。このとき、後者を選択すれば、あなたはパッケージベンダーとお付き合いすることができます。次に、どのパッケージにするかを考えなければなりません。ここで海外に本拠地を持つベンダーを選べれば、あなたの不幸は始まったも同然。SAPやORACLEなど、日本支社も力を持っているところはダメですよ。開発が始まると、そのパッケージを取り囲むAdd-on機能の作りこみをすることが多いですよね。本人好みの請求書や領収書を発行するためにもガリガリ作ります。API(アプリケーションの外部仕様)を教えてもらって、それを利用して作成していくのですが、コーラを飲んだらゲップが出るのと同じ確率でトラブルに遭遇するんですよね。票出力結果が乱れてしまうとか。現場で懸命に解析した結果、パッケージがおかしいという結論に辿り着くことは往々にしてあることですが、大変なのはここからです。日本支社のサポート部隊に問い合わせます。報を受け渡すのがコツです。情報は一気に出しましょう。調べることは全て調べた、あとはお宅のソースコードだけしか残ってないよと伝えてあげるのです。これですんなり折れてくれる相手ではありません。全部調べたというにも関わらず、色々と確認を取ってきます。いや、彼らのやり方ももっともな対応だと思いますよ。クライアントのエラー報告が正しいとは限らないわけですから。報を全て伝え、後は相手が確認するだけにするのです。※間違ってもリバースエンジニアリング(*)の結果などを伝えてはダメですよ。契約違反で逆に訴えられてしまいます。ここでパッケージ自体のバグの可能性が出てくると、ベンダーも日本のサポート部隊の手には負えません。彼らはソースコードを改変する権利を有していないのですから。したがって、ここにきてようやくグローバル(本国)の開発部隊に問い合わせをすることができるのです。ここからがさらに長いのです。サポートセンターの対応で間に合わなかったということは、未知のバグである可能性が非常に高いです。世界初のバグということです。相手はパッケージを作った張本人ですから、バグ自体の特定は(大抵)苦労しないでしょう。問題は、それをどのようにして修正するのかという点です。通常はパッチ(追加プログラム)のリリースという形で対応することになりますが、パッチというのはリリース時期が決まっていることが多く、そんなに頻繁に作成してはくれないのです。こちらはカットオーバー寸前で今さら延期なんてできないよ、というシチュエーションであることも間々ありますよね。そんなとき、いったいどうすればいいのか!どうにもなりません。海の向こうで起きていることは、所詮対岸の火事なんですよ。こちらが燃えても火の粉は届きません。これが12月に起きた場合はもっと悲惨です。本拠地が北米にある場合、彼らは12月下旬からクリスマス休暇に入ってしまうんですね。これで年末年始は何も出来ません。うちは1月1日リリースなのにどうしてくれるんだ!って怒号も届かないくらい、海の向こうは遠いのですよ。これは実際にあった話で、かつクライアントは日本を代表する会社でした。日本支社のコンサルタントがかんばってくれたから何とかなったものの、これじゃクライアントの信用はガタ落ちです。それでもこのパッケージベンダーと手を切るのは難しいのです。額がバカにならないものだからです。それに、今のシステムがダメとの評価が下がると、担当役員の株も下がるので、なおさら後に退けません。皆さんの職場やプロジェクトで海外ベンダーのパッケージ製品を導入する際には、サポート体制について十分な契約を結んでおくことをオススメします。ここがしっかりしてないとベンダーとのやりとりで苦労すること必至ですよ。逆に言えば、契約さえしっかりしていれば、特別対応してもらうこともできるのですから、契約書は穴が開くほど眺めて確認して下さい。