敏腕PMブログ

‘EC-Orange2.0’ カテゴリーのアーカイブ

背中と口で引っ張る

2008 年 7 月 14 日 月曜日

今日は人材育成についてのお話です。

プロフェッショナル仕事の流儀というテレビ番組で
前回はヤクルトの宮元選手がゲストでした。

ヤクルトのキャプテンであり、
日本代表のキャプテンでもあります。
星野JANPANのキーマンですね。

そんな宮本選手の流儀として
「背中と口で引っ張る」というのがありました。

「背中だけ見せても言わないと分からないことがある。
だから僕は言う。」

というスタンスです。
かなり共感しました。

キャプテンなので、プレーで周りにアピールすることはもちろん、
気を抜いた選手には厳しい激(言葉)が飛びます。

プロジェクトメンバーに対して僕は、
言われたら分かる = 言われないと分からない
と思っているので、積極的に言うようにしています。
(アドバイスの場合もあれば、注意事項の場合もあります)

それが相手にとっても自分にとってもHAPPYだからです。
どうせ気づくんだったら、
1年後に気づくより、今日気づいたほうがいいですから。
しかも言われたら気づくんですから。

人材育成の観点から考えると、人間は
①言わなくても分かる人(1割)
②言われたら分かる人(8割)
③言われても分からない人(1割)

の3パターンに分けられると思っています。(注:割合は単なる感覚です)

僕は②のパターンの人が”人材育成”の対象だと考えています。
②⇒①へ自分が誘導できたらとても強力なチームが作れます。

なので僕の人材育成についてのスタンスは
・俺から盗め!
ではなく、
・俺のノウハウ全部伝えるから1日でも早く成長して!
です。

1歩間違うとただの”過保護”なので、
相手との最適な距離を見つけることが大事ですけどね。

あと1ヶ月しかない、ではなくまだ1ヶ月ある

2008 年 7 月 11 日 金曜日

納期が近づいてくると誰でもあせるものです。
最近メンバーから「あと1ヶ月しかないですよー」
という声があがってきました。

僕は、「違う、あと1ヶ月もある」 と伝えました。
メンバーに1ヶ月で何をやるべきか、を伝えるのが
プロジェクトマネージャーの役目です。

”1ヶ月”という期間に意味は無く、そこに意味を与えるのは
自分達です。

追い込まれた時こそマインドはポジティブに、
今できることをコツコツやる。

最後の追い込みは、みんなバグ修正や要望対応への
スピードが格段に速くなります。
「慣れ」とか「成長曲線」っていうのはなかなか侮れません。

スケジュールは守られるためにあります。
学校の宿題も、システムのカットオーバーも、
なんだかんだで最後はギリギリ間に合うものです。

伝えたかったのは、
“ネガティブなイメージをポジティブにとらえ直す”
プロマネは悩んでたらきりがないですから。

嫌われてもいいと思えるか

2008 年 7 月 10 日 木曜日

郵政民営化法案を成立させるためには、
「殺されてもいい」と小泉純一郎さんは言いました。

プロジェクトマネージャーは命までとられることはありませんが、
「嫌われてもいい」くらいの気概は必要だと思います。

お客様と長期的に良好な関係を築くためには、
一時的にはお互いの意見を交換するための衝突も必要です。
顧客に迎合することが必ずしも最善策とは限りません

弱音を上げるメンバーに対して、手取り足取り教えてあげるのも
一つの方法ですが、時には突き放してみて自分で乗り越える試練を
与えることも必要です。

・なぁなぁになる
・馴れ合いになる
ことは楽ですが、プロジェクトマネジメントの観点から正しいとは言えません。

時にはビジネス上での喧嘩をしたり、
とことん腹を割って話し合ったり、
嫌われてもいいと思って正面からぶつかることも必要です。

プロジェクトマネージャーは日々外部・内部問わず調整力を発揮すべきですが、
調整型人間でいればいいというわけではありません。
時には厳しく厳格な態度、小泉前首相のように凛とした姿勢が求められます。

小泉さんも首相時代は各方面から色んなことで叩かれました。
トップに立つ人は誰かからは嫌われる、叩かれる比率は多くなります。
でも退任してからほとんど悪く言う声は聞かれません。

プロジェクトマネージャーも、信念を曲げず、自分が正しいと思うことを
やり続けていれば、道中いろいろ叩かれたり嫌われたりしても、
必ず最後はHAPPYな結末を迎えられると思います。

「嫌われてもいい。プロジェクトが成功するならば。」
ちょっとかっこよすぎますかね。

会議の数は少ないほうがいい?

2008 年 7 月 8 日 火曜日

「この会議は本当に必要か?」
この問いは会議の質を意識するために非常に重要です。

・お客様との定例会議
・社内メンバーとの情報共有会議
・社外デザイナーとの打合せ
・インフラベンダーとの打合せ
等々、プロジェクトマネージャーは色んな会議に呼ばれます
さらに複数のプロジェクトに関わっていると、これが2倍、3倍になっていきます。

週1回の定例会議がある場合でも、僕はよくお客様やメンバーに、
「来週の会議は無しにしましょう」と提案します


それは会議が面倒くさいのではなく、議題が少ないからです。
お客様も各人が貴重な時間を割いて会議に参加されます。
メールや電話で終わらせるほうがお互いに有意義だと思います。

最近の僕の挑戦は、
1時間の会議内容を、1本のメールに込められないか?
です。

これをやりだすと、会議に参加するより自分の席でメールを書いているときが
一番仕事がはかどります
。(プロジェクトが前に進んでいると感じます)
複数の人とほぼタイムラグなくやり取りができ、文章によるコミュニケーションなので、
記録にも残り、言った言わないでもめることもありません。

将来的には1度もお客さんと対面式の会議は行わず、
要望を全て満たす完璧なシステムを作ってみようと
ひそかに野望を抱いています。

”会議室を予約するより会議質を考えることが仕事”
明日から会議室のドアに張り紙をしてはいかがでしょう?

経験がない。だから・・・

2008 年 7 月 7 日 月曜日

以前こんな言葉を聞きました。
「提案書を書いたことがないから、書けないです。」
せっかく上司から提案書作成を依頼されているのに、
自分からチャンスを逃しています。

たぶん自信がなくて、自分が書いても良いものが書けない
といった不安があるのでしょうが、
上司からするとそんなことどうでもよい。
新しい仕事を任せて成長の機会を与えています。

仮にミスをしてもそれほど大きいことはありません。
大抵上司はリスクヘッジしているものです。
できなくても提案書は誰かが書きます。

どこかでこんな言葉を聞きました。
“自分が克服できないレベルの課題は与えられない”
言い方を変えると、今抱えている課題は必ず解決できる
レベルのものである。

エンジニアにはエンジニアが解決すべき課題が与えられ、
プロマネにはプロマネが解決すべき課題が与えられ、
社長には社長が解決すべき課題が与えられます。

エンジニアにいきなり経営戦略を考える、という社長が
取組むべき課題は与えられません。

“経験がない、だからやらない”
ではなく
“経験がない、だからやる”

個人や企業の成長において、大切なマインドだと思います。

はじめはモノマネから

2008 年 7 月 3 日 木曜日

学ぶ」の語源って知ってます?
真似ぶ(まねぶ)」なんです。

プロジェクトマネジメントスキルを付けるには、
“モノマネ力”がものすごく必要だと思います。

スポーツ選手や歌手は、キャリアに関係なくある程度の
素質やセンスがものを言う世界で、若手がベテランを追い越す
シーンがしばしば見受けられます。
仕事で言うと営業職というのも上記に近いですね。

これに対しマネジメントというのは、コツコツと知識やスキルを
積み上げていく職人系の分野だと思います。

新人は上司の職人芸を盗まなければなりません。
若いころはまずは毎日モノマネをすればいいんです。

・時間管理術
・顧客折衝の方法
・読んでいる本
・ユーモアのセンス
等々、上司のマネできる部分はどんどんマネして自分のものにしていく

「上司と自分は仕事の内容が違うから」
なんて言っている暇はありません。
1年も経つと会社には新人が入ってきますから、自分もその日から上司です。

若手料理人の仕事が最初は皿洗いでも、
お店が閉まってから大将の包丁さばきをまねして
食材切っている人は、成長スピードが違うでしょう。

・プログラマー時代に先輩エンジニアのソースコードをマネする
・プログラマー時代に先輩SEの設計書を見て研究する
・SE時代にPMがお客さんと交渉する会議に同席させてもらう

モノマネ力 = 吸収力 です。
先輩、お客様、同僚からスキルをビュッフェ形式でモノマネしていく。
プロジェクトマネジメントスキルの身につけ方は、
はじめはモノマネからでよいと思います。

仕事を依頼されるときの心がけ

2008 年 7 月 1 日 火曜日

昨日は“仕事を依頼するときにはまず目的から伝える”という
ことを書きました。

今日は立場が逆の場合で、
仕事を依頼されるときの心がけです。

プロジェクトマネージャーはお客様から仕事を依頼されます。
プロジェクトメンバーは
プロジェクトマネージャーから仕事を依頼されます。

依頼された仕事の結果を報告したら
「依頼したものとは違うんだよねー」
と言われたこと、ありませんか?

依頼されるほうにも原因があると思っています。
依頼される側の心がけを書いておきます。

①目的の確認
⇒依頼されるほうからも目的を確認するようにしましょう。
「目的は何ですか?」という質問ではなく、
「目的はXXXですよね?」くらいがトゲがなくていいですね。

②期限の確認
⇒依頼するほうは急いでいる場合もあるので、
「いつまでに仕上げればよいですか?」と聞きましょう。
1時間後、1日後、1週間後くらいのレベルでOKです。

③Outputイメージの確認
⇒これが一番大事なのですが、仕事を依頼された瞬間にOutputをできるだけイメージしましょう。
ドキュメント、プログラム、デザイン何を依頼されても、最終的には
・どのような形式で
・どのようなレベルで

その仕事を完了させればよいのかを確認します。
紙やホワイトボードを使ってより具体的にOutputイメージの刷り合わせを行うのも効果的です。

実際の作業に入ってから仕事が完了するまでに、2回は報告すると良いですね。

・完成度40%程度で1回目の確認
⇒これは方向性がずれていないかの確認です。
仕事の依頼者へ安心感を与えることもできます。

・完成度80%程度で2回目の確認
⇒これは最終仕上げ前の確認です。
仕事の依頼者から細かな要望が聞きだせると共に、
クオリティを一気に引き上げることができます。

いかがでしょう?
「依頼したものとは違うんだよねー」
と言われる割合が減れば幸いです。

標準化の本当の意味

2008 年 6 月 27 日 金曜日

皆さん、仕事の標準化ってされてます?
おそらく企業に勤めている方なら気づかないうちに
標準化された業務の中にいるとは思います。

プロジェクトにおける標準化の一般的な定義は、
「誰がやってもある程度同じ結果が得られるようにすること」
くらいに僕はとらえています。

標準化することのメリットは、大きく分けて
①品質向上
②コスト削減

です。

①品質向上について
例えば議事録やスケジュール表、課題管理表といった、
どのプロジェクトにおいても必要なドキュメントテンプレートは、
全社で統一することが「標準化」です。

これによって、今まで上記ドキュメントを作ったことがない人でも、
テンプレートに沿って作成することで、一定の品質が保てます

②コスト削減について
①の例で言うと、標準化されたドキュメントテンプレートがあると、
ドキュメントのフォーマットを考える「時間」が少なくなります。
既にあるものを使えますので。

プロジェクトではほぼ時間=コストなので、時間を少なくすることで
コストを同時に削減しているのです。


ただし、標準化には落とし穴があります。
標準化されているからといって、それを鵜呑みにしてはいけないということ。
標準化はあくまでも「標準」であって、「絶対」ではありません。

プロジェクトの状況によって、標準化されたものを都度応用していく
必要があります。

最後に、僕が考える標準化の本当の意味を書きます。
それは、「本来業務に注力できること」です。

お客様はドキュメントのフォーマットがどうだとか、ほとんど気にしていません。
その中に書かれている内容を非常に気にされています。

プロジェクトではその内容を深く考える必要があります。
その考える時間を確保するために「標準化」があるとも言えます。

「標準化して努力しなくても品質が保ててコストも削減できた!」
ではなく、
標準化して本来考えるべき内容に時間を使うことができた!
が標準化の本当の意味なのです。

現場で使えるパレートの法則

2008 年 6 月 26 日 木曜日

パレートの法則ってご存知ですか?
80対20の法則と言うこともあります。

例えば、
・売上の8割は、全従業員のうちの2割で生み出している
・仕事の成果の80%は、費やした時間の20%から生まれる
のように

“重要な20%が結果の80%を占める”という法則です。
意外にこれがプロジェクトマネジメントに生かせるんです。

例えば要件定義のフェーズでは、
お客様は要望に優先度を付けずにどんどん伝えてきます。
その中にはそれを満たさなければ業務が成り立たなくなるものから、
無くてもそれほど問題はない要望まで様々です。

そんなとき、パレートの法則で言う重要な20%を探します。
木にたとえると、要件が
・木の幹にあたる「重要」レベルなのか
・木の枝にあたる「普通」レベルなのか
・木の枝の先の葉っぱにあたる「補足」レベルなのか
この重み付けをして上位20%の重要な要件を深堀りします。

テストフェーズでは不具合がてんこ盛りになってくることがありますが、
例えばECサイトだと
①商品をショッピングカートに入れられない
②会員規約のページで文章の折り返し位置がおかしい

という2つの不具合があった場合、①はかなり重要な不具合で、
②は対応優先度の低い不具合になります。
①のような重要な上位20%の不具合の修正が完了すれば、サイトは8
完成、という発想は稼動を目前にしたフェーズでは有効です。

・締め切りが迫っているとき
・仕事が山積みでどうしようもなくなったとき
・あれもこれもと欲張ってしまいそうなとき

ぜひとも「パレートの法則」を思い出していただければと思います。

優秀な人とそうでない人の違い

2008 年 6 月 24 日 火曜日

「あの人は優秀だ」なんて言葉を耳にすることがありますが、
優秀な人とそうでない人の違いって何でしょう?

・知識量の違い?
・論理思考力の違い?
・コミュニケーション力の違い?

色々あるかと思いますが、僕が考える優秀な人の定義は、
当たり前にこなすことのレベルが高い人」です。

当たり前」というキーワードが昨日に引き続き出てきました。
実は昨日のブログと今日のブログはセットで読んでいただきたい
内容なのです。

“優秀な人” = “当たり前にこなすことのレベルが高い人”
話が抽象的なので、具体的な例で説明します。

経営者の例では、
日本電産の永守社長は、元旦の午前中以外は毎日出社するそうです。
土日祝も含めた365日です。
これは永守さんにとっての当たり前

スポーツ界の例では、
陸上の末續(すえつぐ)選手は毎日腹筋を2000回しているそうです。
腹筋を足の一部にしたかった、と聞いたことがあります。(発想に脱帽。)
これは末續選手にとっての当たり前

このように、
普通の人が「すごいなー」と驚くことも、
本人にとっては「当たり前」のことになっている。
その「当たり前」のレベルが優秀な人とそうでない人を分ける気がします。

プロジェクトの現場に話を移すと、

・ドキュメントの質
・会議の質
・プログラムの質

といった、各タスクの「当たり前」レベルを引き上げ続けることが、
自己の成長を促し、プロジェクトを成功へ近づけると思います。

昨日書いた “当たり前のことを当たり前に”
本日書いた “当たり前にこなすレベルを高く”

この2つをセットでお伝えしたかったのです。