« 2006年9月17日 - 2006年9月23日 | トップページ | 2006年10月1日 - 2006年10月7日 »

「アート・オブ・プロジェクトマネジメント」読書感想文(その1)

アート・オブ・プロジェクトマネジメント 最近、マネジメント系の仕事ばかり振られるようになったので、予習のつもりで一読 したが、これはスゴい。読んでる途中から振り返り読みを繰り返し、再読も再々読もしなければならないことに気づいた。本書で紹介されるアート(技芸)は、How to モノと大きく異なり、根っこから考え→実践に適用し→フィードバックが必要なものばかり。

 あ、最初に結論を述べておくと、これは今年のNo.1スゴ本なり。ふり返ると「No.1スゴ本」の称号をいくつかの書籍につけてきたが、本書は間違いなくNo.1だと言い切れる。読み手の経験に応じ、必ず得るものがある。概要はamazon紹介文をどうぞ(太字はわたし)。

 「ものごとを成し遂げるためには何を行う(あるいは行わない)べきか」という実用的な視点からプロジェクトを捉えて、ものごとを成し遂げるための考え方やヒントを、スケジュール、ビジョン、要求定義、仕様書、意思決定、コミュニケーション、トラブル対策、リーダーシップ、政治力学といったさまざまな角度から考察しています。マイクロソフトで多くの巨大プロジェクトを成功へと導いてきた著者の豊富な経験とノウハウが凝縮された1冊として、マネージャやチームリーダーだけでなく、プログラマ、テスターなど、プロジェクトに関与するすべての人にお勧めです

 うーん… プログラマやテスターといった、いち"役割"での人よりもむしろ、その間のノリシロとして働く人── チームリーダーやプロジェクトマネージャ向けだと思う。マイクロソフト社内では、プログラムマネージャと呼ばれている、リーダーシップ役+調整役を行う人のための本だろう。言い換えると、以下の仕事をする人にとって、必ず役に立つ本となるだろう。


  • 仕様書の記述
  • マーケティング企画のレビュー
  • プロジェクトスケジュールの立案
  • チームの指揮
  • 戦略の立案
  • バグ/欠陥の優先順位付け
  • 士気の鼓舞
  • 誰かが(ちゃんと)作業できていない場合のフォロー

 本書は16章で構成されており、それぞれの章は、ミッション駆動型でまとめられている。つまり、プロジェクトの企画立案→計画→設計→実装→テスト→リリースといったライフサイクルに沿った構成となっていない。1章がPMの定義、2~6章が計画フェーズ、7章が設計フェーズ、14章が実装フェース、15章がテスト~リリースとなっている。計画フェーズにこれでもかと注力して書いているにはちゃんと理由がある。ここで交わされた会話、メール、ミーティング、ドキュメントは、プロジェクト全体を通じて利いてくるからだ。

 特に、


  • 8章:優れた意思決定の行い方
  • 9章:コミュニケーションと人間関係
  • 10章:メンバーの邪魔をしない方法
  • 11章:問題発生時に行うこと
  • 13章:ものごとを成し遂げる方法

 は初読なのに繰り返し読んだ。8~10章はプロジェクトライフサイクル全般を通じて必要となるだろうし、いまあなたが何らかのトラブルに見舞われているのなら、11章と13章から読めばいい。

 本書で紹介される関連書籍や参考Websiteも充実している。既読本/サイトから察するに、未読本はすべて押さえておく価値がある。

 以降、この読書感想文シリーズでは、初読→再読の際に考えたことを章順に書く。著者と一緒になって自分も悩んだり思い出したことを書き付ける。つまり、本書から想起した過去の思い出(苦いのも含む)から再度教訓を引き出したり、現在やっている仕事へのフィードバック計画をメモるつもり。したがって、正確な意味でのレビューにならないかもしれないので、ご容赦。

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

「仕様」という言葉の罠を回避する

 結論→ 「仕様」と「機能」を意識的に使い分けることで、顧客のテクニック「言葉のすり替え」を見抜くことができる。

 客先での仕様調整の場で、新人が手もなくひねられている(騙されているともいう)。もう少し手加減してやればいいのに、顧客の脅しが酷すぎる。


  1. あたりまえじゃないか、その機能が入っているのが仕様です
  2. なぜなら、いま私が現場に電話で確認したら、そういう運用になっているからです
  3. だから、その機能が入っていないのはバグなんです
  4. したがって、あなたは無償で今すぐこれを実装する必要があります

 テストフェーズ末期やリリース後、何らかの要求を満足していない場合、顧客より一方的に伝えられる最終通牒は、こんな論法だ。非常に強い口調で伝えられると、なんとなく「そうかも?」という気分になり、顧客が正しいという空気が場を支配する。

 その結果、ほとんどの場合、泣く泣く自腹で実装していることだろう。ひとつひとつは小さかろうと、チリ積も山にスケジュールは悲鳴をあげるかもしれない。あるいは、仕様通りに書いたプログラマにバグとして対応させることで、その良心に致命傷を与えるかもしれない。

 ここでは、「顧客の認識を再確認することで、本当のところを証明する」ことを目的とする。決して「顧客をやり込める」ではない。本当のところを明らかにして、後でどう扱うかを決めるべし(←カネの話ね)。結局自腹になるかもしれないけれど、ウソ暴論がまかり通ることはあってはならない。モチベーションが下がるからね。

 さて、先の顧客の言い分に戻ろう。上の1~4のうち、どれが間違っているだろうか? 答えは「ぜんぶ間違っている」なんだけど、あと一つ足りない「立場だけでこんな論を押し通す輩が仕様窓口の担当であることそのものが間違っている」が満点。

 では、なぜ間違っているか? それは、「仕様」と「機能」を巧妙に言い替えているから。こんなことを言い出す顧客とは、要件定義・分析フェーズでこんな会話をしているはずだ→「仕様はこうしてください」とね。

 ここで言う「仕様」は、「要求」だ。要求仕様と言い替えてもいい。

 つまり、○○のときは、△△というチェックをして欲しい、画面から操作者が△△というチェックを起動できるようにして欲しい… と、顧客からの要求のひとつひとつをとりまとめて、モレヌケ矛盾がないか確認してきたはず。

 そうした要求を実現するものが、「機能」なんだ。間違えてはいけない、要求(仕様)が先、機能が後なんだ。

 しかし、後になって「これが足りない」「あれが足りない」と騒ぎ出すのは、「機能」を指している。たしかに、要求が誤解、誤読されることもあるだろうが、その数はこの罠に比べると、微々たるものに違いない。思い出してみて欲しい、「この『要求』が実装されていない」という言い方をする顧客は、皆無だろう。後付けの「要求」であることがバレてしまうからだ。

 しかも、要求が足りなかったことを「機能不足」に置き換えている。その機能がない理由は、ほとんどの場合その要求をしなかったからだ。自分の誤りを棚に上げて声を荒げる。その機能が実装されていることを前提として、現場は待っているんだ、今電話で確認したんだ、と来る。たったいま見つかった要求が実装されていないことで、機能モレを主張するのは本末転倒なのだが、そのときのマジックワードが「仕様が実装されていない(抜けている・モレている)」。

 ここで言う「仕様」は、スペックそのものだ

 ある要求がないから、対応するスペックがない、そのスペックがないから、対応する機能が実装されてない ――この、ごくあたりまえの事実が、「仕様」という言葉を混ぜることで、見えなくなる。つまり、プロジェクトの最初は「仕様」を要求寄りの言葉として使い、プロジェクトの後半で、いざ要求をねじ込む段階になって、「仕様」を「機能」と等価と見なす(もしくは言い替える)。

 これは、狡猾というよりも、顧客の基本的な戦術だと思ったほうがいい。顧客の間で講習会でもやってるのかと邪推したくなる。「違うか!?」と詰め寄ってくるその場でロジックを粉砕してもいいのだが、間違いなくカドが立つ。実際、誤りを指摘すると、文字通り「顔を真っ赤にして」怒る。そりゃそうだ。みんなのいる場で、自分自身もダマしていたウソを暴かれるのだから。

 では、「顧客を言い負かす」ことが目的ではなく、本当のところを明らかにするには、どうすればよいか? それは、あなた自身が、「仕様」と「機能」を使い分けるしかない。気をつけないと、「仕様」と「機能」は、ごちゃごちゃに使ってしまうかもしれない。「この機能の仕様は…」なんてよく言うでしょ。

 ならば、どう使い分けるか? 顧客の言う「仕様」が「要求」である場合は、「ご要望」「要求仕様」とし、「機能」を指している場合は、「機能」と言い替えるんだ。

 例えば、顧客の言い分を反復するときに、こう言い替え【もどし】をする。


  1. つまり、その機能が入っていることがご要望だったんですね
  2. 現場に確認していただいて今分かったことは、そのような要求仕様があるということなんですね
  3. すなわち、その要求仕様が入っていない、というのですね

 するとどうなるか? 「機能が入っていない→仕様化されていない→要求していない」の順にさかのぼって考えることができる。あるいは「そんな"要求"がある、なんてことが"今"わかった」となる。前者は口に出さない方がいい。顧客を責めることになるから、みんなの脳内で遡及してもらおう。いっぽう、後者は、顧客の論理の言い替えのタイミングでさりげなく述べるといいかも。

 要求していないことが明らかになれば、触れる程度にとどめ、言い立てる必要は無い。すり替え戦略が破れたことが分かったならば(バカではない限り)、最後の結論にはもってこれないはずだ。すなわち、

  「したがって、あなたは無償で今すぐこれを実装する必要があります」

 …なんて、どう転んでも言えなくなる。顧客が自分の誤りを認めることは皆無だが、少なくともバーター対象にはしてくれるだろう。その機能は、結局無償で追加することになるかもしれない。しかし、手持ちのカード(いわゆる"貸し"というやつね)を増やし、今後の交渉を有利にすることはできる。カネにするのか、期間を調整してもらうかは、会議が終わった後、その顧客との二者間で決めればいい。

 立場でしか仕事ができない人の顔を潰すということは、その人の存在意義そのものへの問いを突きつけることになる。その場合、あなたの政治的立場に脅威となるかもしれない。そうしないためにも、この「言い替え」を上手に活用してみて

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

このツンデレ小説がエロい「ROOM NO.1301」

ROOM NO.1301 秋だし、たまにはエロい本をご紹介。[エロいライトノベルトップ5]… という謳い文句にふらふらと読む。結果は【激しく同意】、mizunotori さん、ありがとうございます。

 これはエロいツンデレ小説。エロツンデレとでも呼べばいいのだろうか。これ、ホントにラノベか? 絶句するほど妙に生々しい。同時に、なんかこう、他人のまぐわいの残り香を胸いっぱいに吸い込んだようなせつなさを味わう。

 主人公の高校生は、村上春樹の小説に出てくるようなキャラクターだなぁ。著者による恣意的なモテ率と、それに反比例する無自覚さに殺意を覚えるかもしれない。ストーリーを転がすために、おにゃのこに迫らせるやり口はまさにギャルゲ―― そう、これは読むギャルゲなのかもしれない。

 読むギャルゲとはいうものの、まぐわう描写はない。あたかもHシーンがカットされた全年齢対象版の美少女ゲームのようなもの。脳内補完に勤しむしかないが、これまた自分のアタマながらエロい。普段いかに視聴触覚に頼りきっているか身にしみると同時に、自分の想像力のエロい使い方を思い起こさせてくれる。やっぱね、このエロな妄想に悶悶とする夜は必要だね。

 amazon紹介文に誤りがある。

 普通の高校生・絹川健一は学校帰りに、公園に呼び出されて、同級生の大海千夜子に告白される。恋とか、愛とかにあまり実感もわかない健一はいったん返事を保留する。しかし、その帰り道にいき倒れている女性・桑畑綾を助けたことで、健一の人生はなんでか少しおかしな方向へ進むことに。ちょっとHで、ちょっと切ない恋に悩む健一の日常を描く、ハート・ウォーミングな物語

 直接的な描写がないだけで、かなりHで、ずっと切ない恋の話だと思う。そして、全てのエロゲに共通するように、恋に悩むのは多分に女のコたちであって、そいつに振り回されるのが男の役割というもの。ハートが暖かくなるかどうかは分からないが、顔がほてってくるかもな。

 さて、核心に触れずに紹介でけた。スゴいツンデレ小説[参照]と称される理由はあえて書かなかった。唯一ファンタジックな1301号室の設定を除き、妙にどこかで聞いたことがある現実感あふれる人間関係は、著者の体験に基づくのか、エロゲ歴によるのか。

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

« 2006年9月17日 - 2006年9月23日 | トップページ | 2006年10月1日 - 2006年10月7日 »