敏腕PMブログ

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

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

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

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

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

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

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

–

・朝決められた時間までに出社する。
・出社したら「おはようございます」と挨拶をする。
・挨拶をされたら挨拶で返す。

当たり前のことを書いてみました。
でも必ずできている訳ではないことを書いてみました。

年間通して無遅刻の人の割合ってどれくらいなのでしょう？
寝坊した、忘れ物を取りに帰った、電車が混んでいた、等々
遅刻の原因は至る所にひそんでいます。

でも会社の規則では遅刻しないことが「当たり前」。

世の中当たり前のことを当たり前に実行するって
すごく難しいことなんだと思います。

ダイエットでも
・食べる量よりも消費する量を増やす
という「当たり前」が実際は難しいんでしょう。

プロジェクトマネジメントも当たり前の積み重ねです。

・議事録は打合せ翌日の午前中には提出
・会議資料は事前にメールで送付
・スケジュール通りに開発を完了

それくらいできてるよ、と言われそうですが、
議事内容が正確に抜け漏れなく書かれている議事録は、
なかなかお目にかかることはありません。(本人調べ)
真っ赤に添削することもしばしばです。

ここで注意しないといけないのが、「当たり前」のことは
・人によって
・プロジェクトによって
・プロジェクトマネージャーによって
変わります。

プロジェクトマネージャーは、プロジェクトの「当たり前」
を定義する立場にあります。
もちろん、自分ができてもないことを「当たり前」とメンバーに
伝えることはできません。

プロジェクトマネージャーをはじめとし、
メンバー全員が当たり前のことを当たり前にできれば、
非常に強いチームができると思ってます。

算数も基本問題が解けなければ応用問題は解けない。
当たり前のことを当たり前に行うことが、
プロジェクト成功へ向けた第一歩と考えています。

–

みなさん、ビジネス書は読まれますか？
ビジネス書にはブームがあります。

会計ブーム、レバレッジブーム、勉強法ブーム、HACKブーム、
といろいろありますが、
一時期ロジカルシンキング(論理的思考力)、仮説思考
といった思考ブームがありました。

本日はその中から「仮説思考」についてお話します。

仮説思考というのは、誤解を恐れずひとことで言うならば
「結論から先に考える」ということです。

常に先を見なければならないプロジェクトマネージャーにとって
必須の思考だと思います。

具体的な事例で説明しましょう。

最近ECサイト構築の要件定義を1ヶ月かけてみっちりやりました。
要件を理解し、定義するにはいくつも質問しなければなりませんが、
忙しいお客様の貴重な時間を無駄にしないよう、
少ない質問で全ての疑問を解消したい、
そんなことを考えていました。

質問に至るまでの過程には2つあります。
①疑問レベル(なんでだろう？)
↓
②仮説レベル(答えはおそらくこうではないか？)

お客様に質問をするときに①のレベルでするのか、②のレベルでするのかは、
雲泥の差があります。

①のレベルで質問すると、お客様はこちらがどこまで分かっているのか、
を判断できません。
ですので回答に困ってしまったり、回答が長くなってしまいます。

②のレベルで質問すると、こちらの理解度がお客様に伝わり、かつ
間違っている場合にはその「仮説」に間違いがあるので、
なぜそこに間違いがあるのかを訂正してくれます。
回答が明確で、短くなり、時間を無駄にしません。

最短のルートで、最適な答えが返ってくる、
これが仮説を持った質問をする効用です。

「仮説思考」は戦略コンサルタントが使う上級テクニックではなく、
日々の作業効率を上げる誰でも使える道具です。

ぜひまずは質問から仮説思考を取り入れてもらいたいです。
お客様の反応が変わりますよ。

–

要件定義フェーズの目的は何でしょうか？
要件定義書を作成することでしょうか？
いえ、「要件を定義すること」、これが目的です。
(当たり前ですね。)

要件定義書は要件を定義する(目的)ための
「手段」です。

実際のプロジェクトでは、
目的と手段が入れ替わっていることがよくあります。

-課題を解決するため(目的)の会議なのに、会議を開く(手段)だけで
満足して課題解決は先送り
-品質を上げる(目的)のためテストなのに、テスト仕様書の作成(手段)に
時間を取られ、テストをする時間が取れていない

世の中でも
キャリアアップしたい(目的)ので資格のスクールに通う(手段)が、
スクールに行くこと自体が目的になってしまっている。
という状況も見受けられます。
この状況に陥らないためには、常に目的を意識するしかありません。

・何のためにドキュメントを作るのか
・何のための打合せなのか、何を決めればよいのか
をひたすらまず考える。
そして何が「目的」で何が「手段」かを自分で定義する。

プロジェクトマネージャーはメンバーに「目的」を伝えるのも
重要な仕事です。
最初はどうしても手段が目的化してしまいますから。
「それって目的？」「それって手段？」
こんな会話がプロジェクト内で起こるといいなーと思います。

と、ここまでが本日お伝えしたかったことです。
ここからはちょっと補足です。

キャリアアップ > 資格取得 > スクールに通う
といった流れの場合、目的と手段は入れ子構造になります。

・キャリアアップ(目的)のために資格を取得する(手段)
・資格取得(目的)のためにスクールに通う(手段)
・スクールに通う(目的)のためにお金を貯める(手段)

なので本当は状況によって目的は手段にもなり得るのです。
だからこそ、大事なのは状況に応じて「目的は何か？」
を考え続けることです。

–

プロジェクトマネージャーの役割は？と聞かれたら皆さん何と答えますか？
僕の答えは、「プロジェクトを成功に導くこと」です。

では「プロジェクトの成功」の定義って何でしょうか。
・お客様が喜んでくれたら成功でしょうか？
・自社で利益が出れば成功でしょうか？
たとえば以下の状況は果たして成功と言えるでしょうか。

・お客様は大満足、でもプロジェクトメンバーが大疲弊
・自分は楽しくても周りのメンバーはつまらなそう
・お客様とプロジェクトメンバーどちらも大満足、でも赤字プロジェクト

僕はどのプロジェクトも成功とは思いません。
プロジェクトを評価するには、複数の軸が必要だと思っています。
僕が考えるプロジェクトの評価軸は以下です。

①お客様に対して：
お客様の期待値を超えられたか、お客様は投資対効果は得られたのか
②自社にとって：
プロジェクトによって利益が出たか、次の案件につながるプロジェクトだったか
③自分にとって：
やりがいはあったか、マネジメントスキルは伸ばせたか
④メンバーに対して：
キャリアプランに照らしたタスクを割り当てられたか、モチベーションコントロールはできたか

上記①～④全てが満たされたとき、はじめてプロジェクトは成功と呼べると考えています。
プロジェクトマネージャーは、全体のバランスを見ながら、これらの視点でマネジメントを
行い、プロジェクトを成功に導かなければなりません。

では具体的にどのように成功に導いていくのかを、
これから書いていきたいと思います。

–

みなさんこんにちは。
エスキュービズムの武下です。

今日からプロジェクトマネージャーブログ(PMブログ)をスタートします！
日々の業務での気づきや、プロジェクトマネジメントで外せないポイントを
具体的に、分かりやすくお伝えできればと思います。

・現在SEだけど、そろそろプロマネに挑戦したいと考えている方
・プロマネをやっているけど最近プロジェクトがうまくいってない方
・IT系の会社へお仕事を依頼している外注管理担当の方

を読み手とイメージしています。

IT業界では、デスマーチや動かないコンピュータといった単語がよく聞かれますが、
このブログがプロジェクトの成功へ貢献できればこれほどうれしいことはありません。

ではこれからよろしくお願いします！