« 2005年9月18日 - 2005年9月24日 | トップページ | 2005年10月2日 - 2005年10月8日 »

「おうさまのみみはロバのみみ」をここで言う

 ごめんグチ書く。中の人はテンパってると思いねぇ。ネットインフラなら都会と田舎、年代なら団塊を境にディバイドがある。四十五十のイタい人は確かにいる。マナー常識云々の前に、「今までどうやって生きてきたの?」と問いたくなる。それでもプライベートの範囲ならスルーできる。

 しかし仕事でソレをやるなよ。「TOCって何?」「MECEってどうやるの?」聞 く 前 に ま ず 調 べ ろ や 教 え て 君。「やったことないんだよねー」「どーすりゃいいの! オレ知らねぇよ?」と逆切れ。だから何だっつーの? やり方を調べてやるんだよ、自分で。

 職歴長いのにマネジメントを任されていないということは、プロフェッショナルなことを求められているんだよ。何もテクニカルな話をしてねぇよ、ゼネラリストを極めてもいいんだよ。ただし、「技術のプロ」であれ「ゼネラリストという名のスペシャリスト」であれ、日々是研鑽、学び続けないと。なぜなら、その対象は変化するから。

 ヒューマンスキルは年齢で身につくと思ってる厨房と、仕事を覚えたら十年一日繰り返すヤシ、放課後わたしのところへ来るように。「知らないことを知る」ことを教えよう。「知らない」と認識する以前に「聞けばよい」と思考を止めている自分を見つめてもらおう。

 何のために今その仕事をしているのか、分かっていない。いや分かろうとしない。新人なら許す。目先の作業で苦しんでいるなら、優先付け→分担手伝いもオッケー。しかし、四十五十でソレをやるな。翻訳サイトを知らないとか、ピボットテーブルが使えないとか、ぱっと見「デジタルディバイド」に見えるが、それは違う。知ろうとしていないだけ。オレはココマデと枠を引いているだけ。知る方法があるのに、知ろうとしないだけ。

 なぜか? どうせ団塊マス世代に押さえつけられて考えない習慣を身につけちまったんだろ。「言われたとおりにしたんですケドねー」なんて、いまどきの若造すら吐かねぇぞ(ごめん若い人)。

 考えることを止め、学ぼうともせず、口だけは達者。

 うがー!! おまえなんか、ねこのうんこふめ!






…と、十年後の私が罵倒されませんように






| | コメント (2) | トラックバック (2)

空気が読めないSE、話を聞かないコンサルタント

 ここしばらく開発の現場を離れ、「こんさるたんと」のお手伝いをしている。彼らのやり口が分かるにつれ、これもアリなんだと納得できるようになった。一方、彼らの「実態」を垣間見て、SE/PMとしてやりきれない無力感を抱かされたことも事実。ここでは「なぜすれ違う? SEとコンサルタント」の感想文に擬装して書きなぐる。

 本書によると、SEとコンサルタントの決定的な違いは2点ある。

違い1 : SEはKPI無知
 目標に対しどれだけ達成できたかを測定するための指標値をKPI (key performance indicator)という。KPIは以下の4分野において設定され、モニタリングを繰り返すことで経営全体を把握する。SEはそのうち(3)のみに囚われ、全体的な視座が抜け落ちている場合が多い。

  (1)財務的視点
  (2)顧客の視点
  (3)社内ビジネス・プロセスの視点
  (4)学習と成長の視点

 あるいは、SEにとって「現場の声」こそが天の声であり、これを順々に実現していくことが目標の達成だとする。その結果、「システム化対象」の現場だけにのめりこむあまり、予算や納期をオーバーした部分最適なシステムを作ってしまうことがある。あるいは「偉い人」が出席する場で(3)を強調するあまりヒンシュクを買う。

違い2 : コンサルタントは見積もり弱い
 ホント? と思うかもしれない。確かに、数値やチャートを駆使して颯爽とプレゼンする姿を見ると数字に強そうに見えるが、実際は「見えている数字に強い」だけ。あるいは「説明のつく数字に強い」だけとも。

 コンサルタントは「大きい/小さい」「短期/長期」ぐらいしか分からない。もちろん現状分析する上で出てくる数字は押さえているが、網羅的にやっているわけではない。80/20法則でどこまで深堀りしたら適当なのかを把握している。良い意味でのドンブリ勘定。

 その結果、コスト/スケジュールのインパクトを具体的に語ることができない。例えば、「この施策を導入した場合、現行システムへのインパクトは、○○千万円で、リリースまで○週間かかります。その内訳は…」なんて会話になると部屋を出て行くかそっぽを向く。

 不得手の土俵では戦わない(そもそも入ってこない)のが彼らのやり方。自分のフィールド以外は「それは検討の対象外です」を繰り返し、話は既に終わっている顔をする。

コンサルタントの成果物で最も使えるのは…
 そんなんでも、彼らの仕事の中で最もありがたいのは、

  ・問題点の整理と課題の洗い出し
  ・組織構造と業務とシステムの協同的なあるべき姿
  ・情報システム投資理由の明確化←←←←←←←(・∀・)コレダ!
  ・効果の算出と業務評価の目標設定
  ・情報システム構想

 なぜなら、テンコ盛りの変更・追加がきたとき、あるいは顧客が「全て最優先だぁ」とぬかしたときに役に立つから。そもそも論は顧客の枕詞だが、そういう彼らに対し「そもそも何でこのシステム作ってんの?」と切り返せてなおかつ反論できないのがこれだから。

 彼らの描く情報システムは穴だらけなのでそのまま利用すると酷い目に遭うことは本書でも言い訳されている(限られた期間で全て網羅するのは不可能、と)。だからSEは泣きながらイチから描きなおすのが常なんだが、それでもコンサルからの引継ぎ時に網羅性のチェックぐらいはしておこう。弱い環が分かるだけでもグッと楽になるから。

コンサルタントの成果物のチェック方法
 彼らはとても頭がいい。そして、しっかりと訓練されている。だからフレームワーク的な抜けは無いと信頼してもいい。ところがフレーム=骨とスジばかりで肉がない。だからこの切り口で網羅する。「深堀り資料で抜けている視点が以下のいずれかにあるか?」 と自問しながら成果物をレビューする。

 what : 品種、原材料、商品、間接財
 where : 地域、国内、海外、マーケットエリア、事業所
 when : 時間軸、日次、月次、四半期、上半期
 who : 組織、自社、仕入先、取引先、監督庁

コンサルタントにとってのプロジェクト
 彼らは次々とプロジェクトを渡り歩き、キャリアを築く。後ろに残してきたプロジェクトがどのような残骸と成り果てようとも、彼らは再び見(まみ)えることは無い。「コンサルタント」はキャリアパスのいち期間であり到達点ではないから。契約期間を過ぎたらサヨウナラ、そこまでにいかに「実績」をあげるかが彼らの仕事。

 一方SE/PMはプロジェクトにずっとついてゆく。成功も失敗も最後まで面倒をみる(あるいは看取る)。よくも悪くも一蓮托生。中には仕様書やコードに携帯番号を残す猛者もいる。仕事上ドライに徹することが求められるのに、ドライになりきれない人情味あふれる人がいる。業務分析の主役はコンサルタントではなくIT技術者だという企業の健康を診断する「業務分析」の結論に激しく同意。

 最後に。「なぜすれ違う? SEとコンサルタント」はSE/PM向けにコンサルタントが書いた本だが、読むと頭にクるかも。なぜなら、本書の主張を一言にすると「プロジェクト成功のためにSEはもっとコンサルに協力せよ」だし、これに続く文は「なぜなら、失敗の原因はSEが歩み寄らないか、コンサルの仕事に無知だから」となる。いわゆる「コンサルティング・ファーム」が書いた本だし。SE/PMが立ち読みするなら3,5章をどうぞ。

| | コメント (2) | トラックバック (0)

« 2005年9月18日 - 2005年9月24日 | トップページ | 2005年10月2日 - 2005年10月8日 »