他人のWBS

最近、ほかの人のWBSに従って仕事する状況になりました。

Aさん「今回のWBSの説明をしたいんだけどいいかな？」

俺　　「はい」

Aさん「これなんだけど、うんぬんかんぬん・・・・。これでいい？」

っていうか、ただのタスク表じゃんかぁ～～～～～～～

俺　　「えと、このAタスクの前に○○の準備とそれを決める情報収集が必要ですよね？」

Aさん「。。そうだね。でも書かなくてもいいんじゃないの？そんなの」

俺　　「そうですけど・・・その情報は誰がどこから集めて、まとめるんですか？確認はだれが？」

Aさん「そこは任せるよ～、頼りにしてるよ。俺はよく知らないから」

ああ、30も半ば過ぎの人に、どう説明しよう・・・・俺を困らせないでくれ。。。。

そう、WBSって作成できない人はできないんですよね。。。

いい勉強、させてもらってますよ・・・・

自分を知る

マネジメントに限りませんが

自分の性格、またその性格がどう思われているかどこまで

わかっているのでしょうか？

他人にどう思われてもかまわない、と思っている人もいるでしょう。

しかし、他人が思ったことで「起きた（受ける）影響」まで、どうでもいいのでしょうか？

仕事をする上では、それはマイナスでしかない気がしています。

よく、人は恋をすると仕事に対するエネルギーが高まる、なんて話も聞きます。

相手を見返す（怨み？）パワーもすさまじいものがあります。

えらそうなことはいえませんが、自分を知り、自分が相手に与える影響（から相手が自分に与えてくる影響）

を考えることもマネジメントの一環かな、と思っています。

相乗効果なんてよく使われますが、できるマネジャーはそこができる、のでしょう

WBSを作成する際に気をつけること

WBSを作成する際に気をつけることって何点かありますよね。

・ゴールが明確で正しいか？

・タスクはMECEか？

・得意分野以外のタスクは正確か？

・ブレストは「きちんと意見をいえる人」を交えておこなったか？

・わかっていて「書かなかった」タスクはないか？

・WBSの見直しもタスクに入っているか？

など

WBSの作成経験が少ないときは

結構、ありきたりなウォーターフォール型の開発手順をそのままかいてるだけに

なりがちでした。

例えば、準備タスクや調達タスク、オーナーへのネゴなど

開発者が直接行わないものは抜けがちですね。

WBSを書く場合、自分の視点がおおまかにでも

「開発者」なのか「ユーザ」なのか「管理者」なのか？

それを素直にわかることが一番大切だなぁと。

不得意分野のタスクをいかにブレイクダウンするか？

ここが自分が気をつけている、最大のポイントです

ストーリーのチカラ

現在、新規プロダクトアウト製品のサービス開始の立ち上げをしています。

サービスメニューはとりあえず、当たり障りの無いものになると思います。

そこで、製品を売り込む

キャッチフレーズを考えたり、配布用のチラシ、営業向けの説明資料を用意したりする段階で

ふと、ストーリー（物語）のチカラについて思いだしたので、書いておこうと思います。

プロジェクトXなどの、苦労の末生まれたと聞いた製品や

品物にまつわる話などを聞くと不思議と、それ（製品や品物）がよく思えたりします。

歌なんかでもいいドラマ（ストーリー）で使われていると、相乗効果でとても印象に残ります。

IT製品にも、この考えを活用できないかな？と思っている今日の夜更けです。

リスクを管理する、リスクを負わない

ソニーの電池の不具合の回収は、とんでもないことになってますね。

今回の事件では、ソニーがリスクを管理できていないという印象を受けたと思います。

電池を製造しているのはソニーではないですが、結果としてソニーの責任なのは

誰が見ても明らかでしょう。

IT業界でも、大きな仕事は

元請→１次請→２次請→３次請・・・なんてことは

当たり前です。

では、品質に対するリスク管理がどこまでできているか？

はっきりいって、下の業者にまる投げですね。

（些細なことでも）何か問題があったら、兎に角、威圧的な態度と次の仕事をえさに

なんとかさせる、

つまり、リスクを負わないわけです。（意味がわからない方は・・・ですけど）

そして、下請け業者は、お金だけもらってさっさと逃げる。

または、余計なことをしなくなる（リスクが見えていても、関係ない場合はなにもしない）

リスクを管理する。

簡単そうで、とても難しく、また目に見えない（見えないのが当たり前なので）から

リスク管理や品質管理は、理解されない、評価されないのです。

これについては今度、具体的に書いてみたい内容です

システムアプローチを適用するには

ちょっと前に書いたシステムアプローチについて

IT業界のタスクはほぼ全て、システムアプローチが取れると思います。
が、現実はそうではないです。

なぜか？

「情報」を持っていることが、チカラであるといまだに思い込んでいる人間が多いからです。

つまり、ほかの人には「教えない」ひとが多いためですね。

なぜか？

会社の「目的」と「ルール」が明確ではないからです。
簡単に言うと「評価基準」ですね。

なにが目的で、そのために何をすれば評価されるかが明確ではないから
自分で情報を溜め込むのです。

会社の目的は「お金を稼ぐこと」です。
そのためには今いる人間が何をすればいいのか？
それを理解できない人間が管理職になっていること自体が
システムを崩壊させているのだと思います。

IT業界の人間も、PC上でのシステム構築だけではなく
リアルな世界のシステムも構築できなくてはいけない時代になっている、です

忙しいのは「誰」ですか？

誰もが「自分が一番忙しい」と思って（という前提で）、仕事の話をします。

そんなことないよ、という人もいるでしょう。

でも、ふとした会話のなかで、仕事を頼まれたとき、面倒な展開になった（なりそうな）とき。

相手（周り）が自分より、忙しいと考えられますか？

その日（その瞬間）は、自分が一番忙しいかもしれません。

でも、一週間、一ヶ月というスパン（過去でもみらいでもいいですが）で見た場合のことを考えてますか？

何がいいたいのか？

当たり前ですが、相手（周り）はいつものあなたの仕事の量や仕事中の態度などを見て

判断するのです。

自分だってそうです。

いつも暇そうな人が「ああ、忙しいなぁ～、いやになっちゃうよ」みたいな発言（またはそれらしき言動）をしたら

「いつも暇なくせに」と思うでしょう。

つまり、自分もそう判断されてしまうと。

本当に忙しくても、それを感じさせない（態度に出さない）

できそうでできない。

でも、これができれば、わかるひとにはわかってもらえるんですよね。

逆はダメですね。

暇なのに忙しそうに振舞っている人。。

ということで

・何か頼まれたとき

・（関わっている仕事の）雲行きが怪しいとき

（気分で）即答する前に、少し考える。

または、「ちょっと、待ってもらっていいですか？」といいつつ、考える。

なぜ相手が自分に（または他人に）仕事を頼む（または自分でやろうとしない）のか？

考えてみると結構面白いです。

管理したがる心理

どこにでもいるかとは、思いますが。

マネジメントではなく（一昔前の）管理をしている方（と本人は思っていませんが）

このような方たちに共通するのが

・具体的な指示はださない

・（その上の）上司から言われたことを、、もっともらしく言い直す

・部下の手柄は遠まわしに「自分の指示がよかった」とにおわせる

・仕事の範囲が安全なゾーンに限られる

・決断をできない

・建設的な人間、マネジメントができる部下を絶対に認めない

・もてない（？）

ですね。

今の職場は、かなり仕事のスピードは（決定・実行が）早い会社なのですが。

いまや技術者は

・提案能力

・気づき力

・マネジメント

などの能力のある、実務家が求められていると。

で、そんな人たちは

上司の立場なんてあまり考えないわけですよ。

プロジェクトの成功が目的なわけで

出世が目的ではないからですね

プロジェクトに支障をきたす場合

可及的すみやかに、排除してしまうわけです

で、排除されていない管理職というのは

組織上の部下に制約条件を加え続けるわけです

例えば

・無駄な週報・日報を書かせる（何を書いても対応・フォローは当然無い）

・組織をこえた仕事をしていても「俺の聞いてない仕事をするな」

・重箱の隅をつつくような、時間の無駄な指摘を繰り返す

・金の絡む部分だけは、自分の仕事（手柄にする）にする

など。

「馬鹿な上司、敵より怖い」

です。。

新製品なのはわかりますが～

最近、マイクロソフトの製品説明会なるものに参加。

VistaやらExchangeやらOfficeの2007の説明会です。

が、、、、エバンジェリストが説明しているにもかかわらず

「インストールがなぜか失敗するんですよねぇ～」とか

「うまくいったの、1回しか聞いたこと無いんですよね」と平気で言ってるし。

しかも。朝10時から夕方6時までですよ。。

最後のOSS（OfficeSharePointServer）にいたっては

「のこり1時間でインストールできるかわかりませんが、やってみましょう！」

で、結局できません。

しまいには「ポイントは説明できたので、大丈夫です」

おいおい。。

しかも今日で3回も同じ失敗したって。。自分で言ってるし。

エバンジェリストさん、いくら製品に詳しくても

それじゃあ、伝道師とはいえませんよ。。

これじゃあ、ただの自社製品マニアですよ。

ああ、1日損したなぁ。。

こんなんでマイクロソフトのエバンジェリストになれるなんて。。

私のほうが1000倍、うまく説明できますよ。

職人アプローチとシステムアプローチ その１

マネジメントで気を使っている点を書いてみる。

タスクを数値に（見積やリスク格付け）する際に

そのタスク、またはプロジェクト全体が

職人アプローチとシステムアプローチのどちら（の比重が大きいか）なのかを考える。

例えるなら、

職人アプローチは、街で評判の料理人である。

その人の経験、感性で料理を作る。その人でなければつくれないものである。

システムアプローチはチェーン店のハンバーガーである。

どこでも、いつでも、誰が作っても同じ味のハンバーガーが出てくる。

しかし、IT業界は職人の世界ではない。

また、ほとんどの場合、一定の品質が求められる。当たり前ある。

しかし、タスクによっては技術力や経験が無ければ

実行できないものもある。

実行できたとしても、結果は悲惨な場合が多い。

この２つをいかにうまく判別し、コントロールしていくのかを書いていこう。

眠いので今日は。。