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

■優れたPMは質問の達人

　筆者は「優れた質問は優れたアイディアを惹きつける」という。では、優れた質問とは何か? ここでは5章で紹介される、アイディアを生み出す方法から、「質問」に焦点を絞って考察する。

1. 焦点合わせの質問
2. 創造的な質問
3. 修辞的な質問

　まず「焦点合わせの質問」から。プロジェクトのどんなフェーズであろうとも、質問者が誰であろうとも、最もパワフルな質問がある。わたし自身、ミーティングで必ずする質問。自問も含めると、一日に何回、この質問をすることやら。その「質問」は、反転表示で以下に記す。ドラッグの前に、ちょっと考えてみて欲しい↓

　解決しようとしているのは、どのような問題なのだろうか?

　仕様書の記法について議論しているときも、不具合の正体を見極めようとしているときも、「問題の本質を定義しなおす」行為は、ホウレンソウ並に基本動作となっている。ものすごく重要なので、わたしの手帳の第一ページ目に大書きしてある（ちなみに次の行には、「頭にキたときは、呼吸することを思い出せ」と書いてある）。

　なぜなら、皆の注意を議論の本質へ向ける唯一の質問だからだ。ともすると、表層に拘泥し、因果関係や責任論の不毛地帯へ迷い込むことがある（とってもしばしば！）。事実関係や各人の思いはよく分かり、議論が深まった気分になるが、穴を掘る場所が違っていたら目も当てられない。この罠から逃れるための質問が↑のやつ。

　例えば、システムの不具合の場合を考えてみる。解決しようとしているのが、以下のどれかによって、議論はずいぶん違ってくるだろう。

• 不具合の事象そのもの
• 不具合の原因
• データ汚染部位の除去
• 不具合の再発防止
• 責任所在の追及とオトシマエ
• 追加費用の手当て
• 対策のスケジュール調整

　こいつをいっぺんに語ろうとするから収拾がつかなくなる。いちどに一つずつ、問題の定義を行いながら段階を踏むことで、驚くほど効率的に進めることができる。優れた質問は、議論の触媒となる。だから、「ちょっとマテ、今すぐ決めなきゃいけないのは、データ汚染範囲を拡大させないようにする方法じゃなかったっけ?」と具体的に振ってもOK。あるいは、「○○とは、結局△△のことですね?」と焦点を言い替えるのも良い。"って結局"メソッドは質問のフリをした議論の軌道修正テクでもあるし。

　次の「創造的な質問」は、ちょっと思い浮かばなかった。著者は、「創造的な質問とは正反対に、今まで考慮の対象となっていなかったものの、探求すべき方向を指摘する質問」と述べている。わたしの経験と照らし合わせても、こうした質問はしてこなかったため、自信を持って紹介できない。興味のある方は本書を読んで欲しい。

　最後の「修辞的な質問」―― これは邪悪な質問だという。どう邪悪かというと、次の例を見て欲しい。

• おいおい、私の話はそんなに退屈か?
• バグとか不具合とか、表現のしかたがそんなに気になるかね?
• あっはっはっは、どこへ行こうというのかね?
• 左舷、弾幕薄いよ、なにやってんの!?

　これらは、質問の形をした非難や嘲笑であるため、最も避けるべきだという。質問者の意図ばかりに注意がいってしまい、考えるべき焦点がおろそかになる。このテの質問が、いかに相手を傷つけるかは、子どもができて初めて分かった。今までどれほど酷いこと言ってきたか、恥ずかしいなり。家庭でも職場でも、修辞的な質問を避けるよう、ものすごく気を使っている。

■「見える」懸案一覧は強力なツール

　激しく同意。著者は、仕様書作成フェーズやや、イテレーションの端境期で使っているようだ。懸案一覧のTipsは次の通り。

• 懸案事項とは、意思決定を行う、もしくは答えを見つける必要があるものとして洗い出されたものの、まだ手をつけられていない項目のこと
• 懸案事項の一覧は、本質的には疑問の一覧
• 行う必要のある全てのことが、優先順位付けされていなければならない
• ホワイトボードが望ましい。ウェブサイトで公開すると、まず見てくれない
• 誰かがオフィスにやってきて、進捗状況を尋ねた場合、傍らのホワイトボードの一覧を指差して「あればまさに状況をあらわしています。あの一覧から項目が全てなくなれば、仕様書作成を完了することができます」←【超重要】

　この詳しいテクニックは、6.7「懸案事項の一覧」から学び取ることが出来る。同じことをここで書いても意味がないので、ここでは、わたしが最も使う（使ってきた）懸案事項一覧について述べる。

　それは「課題管理表」と呼んでいる。一緒じゃんという莫れ、懸案を優先順位別に並べたものとは一味違うなり。必用なのは、複数のホワイトボードと書記役の若手数名。

　いわゆる懸案一覧と最も違うのは、アタマに「問題」が付くところ。「サーバ初号機のレスポンス性能問題を解決する」とか「リリース直後のトラブル対応」といった"お題"がある。

　そして、その「問題」を課題へブレークダウンしていくわけ。必ずしもロジックツリーの形をとっていなくてもいいが、個々の課題の総体が問題の全体となるようことに気を配る←つまり、モレヌケがないか見張る。

　課題はたいてい、不具合の形をとる。故障票からの転記/お客さまご指摘/現場からの問い合わせを簡潔に記し、課題を担当する人・チーム、解決までの期限、クリア条件を記す。クリア条件とは、「その課題が解決したことをどうやって知るのか/測るのか/分かるのか」のこと。

• 今発見された不具合
• 仕様モレだとわかった事象
• 実装されていない仕様（理由はともかく）
• 次のリリースで回復する（はずの）バグのうち、知らされていないもの
• この期に及んで顧客が言い出した「あるべき姿」
• 未確定のバグ

　課題（直すべき内容や不具合）は書けるが、担当が書けない場合は、その課題をさらにブレークダウンする必要がある。あるいは、期限が書けない場合は、「いつまでにこの期限を決める」を書く。あるいは、期限を決めるために必要な作業/議論/情報を書く。

　そうしておいて、各個撃破していくわけだ。全ての課題をクリアすれば、元の問題は解決するはず。ファーストインのスタック形式だから、優先順位別にソートしない（できない）。だから重要度別に朱色を使ったりポストイットで"修飾"する。

　課題をホワイトボードにまとめる最大の理由は、「問題を問題化する」ことにある。問題を、コレ、と指差すことができる。非常によくあることだが、問題は、それを抱える人と同一視される場合が多い。あるいは、その問題について詳しく説明できる人や、その問題を伝えてきた人のものとして白眼視される。これまで、何人のプログラマが「当事者」として扱われてきたことか。事象の本質から分かっている分、自分のせいでもない不具合の原因を自分が書いたプログラムで対応させられたりする（自分の分は仕様どおりであるにもかかわらず！）。

　これを回避するために、問題をホワイトボードに「転記」する。問題があるというとき、その場所を指差すのが人からボードに移るわけだ。つまり

you vs me

の人対人の対決から、次のようにする。

problem to us ( you and me )

その「問題」は、ホワイトボードに全部書いてあるというわけ。

　火を噴くプロジェクトに落下傘部隊よろしく投下されたとき、わたしが最初にすることは、この課題一覧を作ること。問題は目に見えているが、課題は断片化されている。各人の頭の中や仕様書に書いたメモ、共有されていないメールにバラバラになっていて、おのおのそいつを抱えて走り回っている（あるいは走りつかれている）。それを、「ここさえ見ればその問題の全てが囲い込まれている」に注目させる。

　その結果、おのずと問題を抱える人や、解決のアイディアが出せる人が、そのボードの前に集まってくる。

　あとは書記役が不在にならないように交代させながら、24時間体制でこのボードをメンテナンスする。これにより、すくなくともこのプロジェクトが何を問題としており、どうやって対処しようとしているかがリアルタイムで分かるようになる。困憊したらボードの傍らにダンボール敷いて寝てればよろしい「課題が追加されたら起こして」と言い残して。