2007年12月30日日曜日

プロジェクトが火事になったらどうする

今まで、時系列・あるいは思い出した順に、あれこれと書いてきました。
ここで、一旦、情報を整理したいと思います。

今回は、プロジェクトが火事になったとき、すなわち問題発生時にやってはならない、しかしそのような人が後を立たない共通点を挙げてみたいと思います。

①自分では何もせず、部下に対応させようとする。
 まさか!と思われるでしょうが、多いんですこれが、ご自分は、「新規の仕事を取ることで忙しい」とお っしゃいます。

②上司に泣きをいれる。
 上司に報告することは、義務ですから当たり前です。ただ、上司に「一緒に行ってくれ」と言うのかと思 うと、まったく違って、他の管理部門(リスク管理・レビュー部門など)に問題を投げてくれと頼むので す。信じられないかも知れませんが、これのなんと多いこと。上司も上司で、「新規の仕事を取ることに
 忙しい」部長のために、他の部門に責任転嫁に走ります。もう救いようがありません。

③現場に行ってただ謝る。
 謝るのは当たり前です。礼儀と言ってよいでしょう。しかし、ただ謝るだけで何もせず帰ってゆく。
 これでは、お客様は不安を増すだけです。

④お客様の言いなりになって何でもする。
 現場に行って、お客様と一緒になって部下を怒る部長さんがいます。「彼が勝手にやりました」などと言
 ってしまえば、部下にとってこんな不幸は無いでしょう。「徹夜しろ!」「はい」・「人をを替えろ!」
 「はい」・「インストールからやり直せ!」「はい」・・ときりがありません。部下であるプロジェクト メンバーのモチベーションは落ち、いらぬ手を入れたために、障害事象を再現できなくなる、悪弊はそれ こそきりがありません。

まだ一杯あるかもしれませんが、私が見た間違った対応です。皆様からも意見をお願いします。
次は、重複するかもしれませんが、成功例に触れて見ましょう。

2007年12月29日土曜日

動かない製品

問題のプロジェクトは、違う見方をすればモデルプロジェクトでした。当時持っていた製品を全て使っていたからです。中でもSCMの最適エンジンとしての製品に、周りの目が集まるプロジェクトでもありました。

だから、失敗する訳にはいきません。ドイツの開発部隊との連携が必要になります。
当時のその製品は、とても使えたものではありませんでした。Version1.0は、ドイツのある顧客のニーズのみを搭載したものだったからです。こうなると、お客様の業務プロセスで使えるように開発させなければなりません。ところが、日本はドイツに取っては小さな存在でしかありませんでした。

日本に目を向けさせないといけません。
早速、顧客仕様をまとめて開発の優先をあげなければなりません。しかし、お客様はドイツの開発者に何をどう伝えてよいのか、分かるはずもありません。

変わって、我々が仕様を作り、日本の社長・副社長からエスカレーションを何度も繰り返しました。
事態は進みません。そこで、とうとうお客様と一緒にドイツに乗り込む形をとるしかなくなりました。

プロジェクト開始時には想定してなかった問題です。でもどうにか、顧客の要望は反映されました。
Version2.0は、ドイツの1顧客の機能+日本のお客様の仕様+アメルカのコルゲート社の仕様を合わせたものとして、出荷されました。1社が3社になっただけで、またあちこちで問題続出です。

この経験の通じて、国やそのほかの用件で品質管理の質がかなり違うということが分かりました。
日本が世界一厳しくまた、当たり前のレヴェルなのです。

ともあれ、この製品の問題で、ドイツの開発の品質管理が強化されたのは、最下と言えるでしょう。

このような場合、先ず我々が顧客仕様を持ってドイツに行き、品質を確かめてから売るようにすることも、
忘れてはなりません。

大変な目に会いましたが、収穫もありました。日本は、もっとグローバルに協力関係を作らねばなりませんでした。

2007年12月24日月曜日

安らぎを・・・



父の日・ギフト・花束・母の日



業務とシステム

「金は払ったんだから、お前たちでやってくれ。」システム開発の現場でよく聞きますよね。
私の場合はSoftwarPackegeを売ってましたから、「買ったのだから、あとはよろしく」と言う感じでしょうか。
当たり前のことなんですが、業務(仕事)のことはお客様しか知らないわけですよね。IT業者だから何でも知ってると言うわけはありません。

何故、こんなことが起きるのか?それは、営業プロセスの中で決まってしまった思い込みなのです。
営業は、パッケージにせよ、プロジェクトにせよ、売れれば良いわけですから、大変な思いをする導入プロジェクトの話なんかしません。(中には超優秀な営業がいて開発はもとより保守のことまで考えて提案します。当然プロジェクトで問題は発生しません。)お客様が心配して相談すると、パートナー企業を紹介して終わりです。(丸投げという得意技です)

お客様がシステムのことを覚えるのと、IT業者がお客様の仕事を覚えるのとどちらが早いかを考えれば、当然のごとく、お客様が考えて、エンジニアが実現してゆくのが理想です。それも、ただ人数を集めればよいと言うわけではありません。決定権を持った人がお客様側にいないとだめです。

今回のプロジェクト体制は、お客様が怒り出す前、「お前たちの製品の全機能を説明しろ。そうしたら
自分たちでやってやる。」という体制でした。システム子会社の若手社員に、これまた質問をうけたら
答えるとう自社のコンサルタントの待ちの姿勢が相乗効果をおこして、ぜんぜん進まない状態でした。

だから、予算はあまる、何もできない、どうしたら良いのか分からないの3重奏になってしまっていたのです。人数も多すぎました。

ですから、私たちは、先ずお客さんの業務ごとのキーマンを決めていただく、この方はプロジェクト開発のあとで、自部署に使い方を教えるというミッションも持ちます。その上でこちらのベテランを書くモジュールごとに用意する提案をしました。分かりにくいと思うのですが、ペアを組むのではありません。
こちらのコンサルタントが、全業務担当者の相手をするのです。これは、課長は喜ぶ資料ができても
営業現場が、回らなくなるようなことを防ぐためであり、完全にインテグレートされたパッケージを適用する際の効果的な方法です。

とにかく、提案は受け入れられ、先行していた工場のプロジェクトに適用しました。
何とか形になったところ、思いもよらない問題が、自社内で発生しました。
これは、ドイツとの問題でもあり、次回触れようと思います。

2007年12月16日日曜日

観察する

貴方が、プロジェクト導入の責任者であったら、当然急いで解決したいと思うでしょう。
しかし、事象も正確に捉えず、原因もはっきりしないまま、思い込みで対処すると、かえって事態を悪くします。

先ずここは一番、じっくり観察しましょう。

黙って皆の動きをみるのです。会議にも参加しましょう。
すると必ず、単純で明らかな間違いを容易に発見できます。私の場合は、テレビ会議の場で発見しました。

工場側の顧客担当者(おそらく情報子会社の社員)が、ある報告をしました。
「(パッケージの)購買機能と会計機能の親和性に問題があります」
私は、現場をいくつも経験していたので、指摘されたことについては、いくつかの具体的な問題(特徴)を知っていました。

そこで私は、具体的な問題を挙げ、そのどれにあたるのか質問しました。そうでないと対処方法が決まらないのです。
担当者は、黙ってしまいました。こちら側に座っているプロジェクト責任者からも「どうした、早く答えろ」
との言葉が飛びました。
そして、彼は「すみません、分かりません」と答えました。これで、現場でどのようにして業務プロセスを
決めるかという作業で、分からないことは全てこちらが販売したソフトウエアパッケージの機能のせいにしているのが明らかになりました。
「現場に派遣している関連するコンサルタントに、分かる範囲でよいから話をして、一緒に調査してください」と私は言いました。すると、相手側の責任者も「もうその位で勘弁してやってくれ」との発言があり
会議は打ち切られました。

ほんの些細なことでも、見つけて解決することで、相手の見方が変わります。
ただし、実際の対処については、1つの事象に対し3つ以上の原因があるものなので、原則どおり調査するのは言うまでもありません。

「ちゃんと見ている」「解決ができる」奴がきた、と思わせることです。すると徐々にプロジェクトの雰囲気が変わってきます。

こんなこともありました。
ある業務プロセスをどうやって、パッケージで実現するかという会議に、ベテランのコンサルタントを送り込んだのです。10分もたたないうちに怒鳴り声が聞こえました。「お前、幾つだ。それが年長者にものを聞くときの態度か!」相手の責任者と私が行ってみると、静まり返っていた会議場に、笑い声が起きてました。
卑屈になってはいけません、前にも言ったように、立場は同等なのです。

次回は、プロジェクト体制に関することを投稿します。

2007年12月12日水曜日

自分(自社)だけが悪いと思わない

お客様の現場に着きました。
先ずは、’ご迷惑をおかけしてます’と、低姿勢で話しましょう。
ただ、ここで大切なのは、自分たちだけが一方的に悪いと思わないことです。
実際に、片方だけが一方的に悪いなどど言うことはありません。

最悪なのは、自分たちが悪いと思い、顧客の要求を何でもかんでも聞いてしまうことです。
いいですか、お客様も事態を正確に把握してないのです。
お客様の言う事をそのまま実行して、もっと事態を悪くしかねません。

日本では、発注側と出入り業者とう、従属的な慣習があるのは分かっています。
でも、実際にはこちらも資源を投入しているのですから、関係は、50:50です。
そう思って、冷静に行動することが大切なんです。

「状況を正確に把握しましょう」という点で、お客様と同意してください。
これが、第一歩です。

2007年12月11日火曜日

先ずは現場に行きましょう

お客様から、怒りの電話がかかって来ます。
貴方は、どうしますか?

先ずは、電話で一言’申し訳ありません。今すぐ伺います’と伝えましょう。
お客様は、如何すれば良いか分からないのです。
また、貴方も状況が分かりません。

先ずは、現場に行きましょう。
もし、原因がある程度推定可能であれば、技術者も一緒に。

とにかく、お客様が’対応が始まった’と思うようにしましょう。

IT業界の皆様

始めまして。谷本淳介と申します。
私は、26年間IT業界で働いてきました。
いろいろなことがありました。

この度、私の経験の中から、Projectのトラブルシューティング、つまり火消しについて、
私なりのノウハウをまとめてみたくなり、ブログを開設しました。

皆様からの、ご意見をお待ちしております。