今朝も朝食した後にキャンセルされたセッションがあるか、スケジュール表で確認してからの始まりです。幸いにも行く予定をしているセッションは変更がありません。
アドバイスは止めて質問をしよう
9:00～10:15はJudith Mills氏とChristopher Avery氏による「When NOT to Have All the Answers: Stop Giving Advice and Start Asking Quesitons」に参加しました。Avery氏が有名なためか、大部屋の4分の3程度まで席が埋まっていました。Mills氏も自分でコンサルティング会社を経営している方らしいですが、どうやらAvery氏の弟子のようです。発表は今回が初めてだと語っていました。集客と助けのためにAvery氏も参加されたようです。
本セッションは対話とワークショップ形式で進みました。主にMills氏が話し、足りない部分はAvery氏が話し、それから理解を深めるために参加者同士でワークショップを行います。
セッションの内容はコミュニケーション能力です。専門家は他人に意見ややり方を教える傾向が強いですが、それでは自分も組織も成長しなくなります。
たとえば、優秀なプログラマがチームに一人いたとします。このチームは、その優秀なプログラマがいなければ無理な顧客からの開発依頼を、そのプログラマがいるためにすべて受けてしまいます。スケジュール通りにプログラムは完成して、顧客は大満足しました。とくに問題がないように思えますが、実際には大きな問題があります。できるプログラマがほとんどの仕事をこなしてしまったので、チームの他のメンバーがやる気を無くしてしまったのです。つまりチームが崩壊したことになります。
Mills氏も、自分が経験を積んで知識豊富になったら、他人にアドバイスを与えることが役割になる、と思い込んでいた時期があったと言います。しかし実際には、これは自分の価値に制限を掛けることになるのです。なぜならこうした場合、複数のプロジェクトに自分が少しずつ参加して意見を言うのですが、そういう関わり方が各プロジェクトのボトルネックにもなってしまうからです。専門家はいろいろなプロジェクトに意見をして良い気分になっているかも知れませんが、長期的に見るとプロジェクトをダメにしているのです。
人はマルチタスクをすると生産性が下がります。また専門家に依存して作業を行っていた場合、もしその専門家が病気になったら、その専門家が参加していたすべてのプロジェクトが影響を受けます。すべてのプロジェクトが失敗で終わってしまう場合もあります。専門家がすべきことは、他人に自分の知識を与えるのではなく、人がうまくできるようになるために指導し、自分が行った作業の責任を感じさせることです。
責任プロセスは、「 責任」「 義務」「 恥」「 正当化」「 罪のなすり」「 否定」の順に進みます。「 義務」「 恥」「 正当化」「 罪のなすり」は、問題から学ぶことをせずに対処する方法です。また、「 義務」と「恥」が続くと、その仕事を辞めることになりかねません。「 義務」で行った作業は、ただ最低基準を通る程度のものとなります。文句を言うと、その時は一時的に満足するかもしれませんが、問題は解決されません。
どんな質問、どんな答えを言えばいいのか
勘違いされることが多いですが、実際には質問を受ける側ではなく、質問をする側の方が力を持っています。質問のコツは、ただ単純に「はい」や「いいえ」で回答ができる質問をしないことです。
この説明の後に参加者同士でロールプレイングを行い、質問の仕方を勉強しました。
デモの後に「質問はありますか？」と聞く人をよく見かけますが、これは間違っています。なぜなら、見た人はただ「いいえ」と返事をするだけで話が終わってしまうからです。正しい質問は「どのように思いましたか？」と聞くことです。
「何をしたら良いのでしょうか？」といった質問に指示を出してはいけません。質問者はただ責任転送しおうとしているだけです。自分が行う作業の責任を他人になすりつけているだけです。「 べき」とは「恥」 、「 正しい／間違い」とは「罪のなすり」です。たとえば「何をしたらよいのでしょうか？」や「正しいやり方を教えてください」とはこの類の質問です。
今回のセッションでは、ほんの基本的な考えしか知ることができませんでした。深く理解するには専門の教育を受ける必要があるそうです。
生産性を上げるために必要な「決断」とは？
10:45～12:00は、私の申請、論文、発表をチェックしていただいたJohanna Rothman氏による「Transparent Decisions: Managing the Project Portfolio」に参加しました。発表の内容は、事前にネットに登録されているビデオと同じものでした。
製品は完成して販売できるようになった時点でやっと価値を生み出すことができます。それまではビジネスで使えないので価値はありません。
実際の世界では複数のプロジェクトが走っているので、それらを管理して、できる限り早く完成させる必要があります。そのためには、実際の世の中のことを知る必要があります。たとえば、2月は日数が少なく、東海岸では天気も悪い日が多い月です。休みの日もあります。そのため、2月の作業は他の月よりも少なく計算した方が賢明だといえます。
一人の人に多くの作業を与えると、その人の作業効率は下がります。人は機械ではないので稼働率を100％にしない方が、その人の実際の生産性を高く保つことができます。それを行うためには、プロジェクトを選択する必要があります。何でも行うようにするのではなく、停止やキャンセルすることも考える必要が出てきます。
14:00～15:15の間は、RebeccaWirfs-Brock氏とJoseph Yoder氏の「Agile Quality Scenarios: How to Be Nimble and Precise」に参加しました。いろいろと面白い内容を話されていましたが、残念なことに睡魔に襲われて理解する余裕がありませんでした。スライドの写真を撮りましたので、後でスライドとメモをすり合わせて、復習する予定です。
Tim Lister氏の40年
15:45～17:00はキーノートです。今年はTim Lister氏の「Forty Years of Trying to Play Well With Others」です。Tim Lister氏はトム・デマルコ氏の友達で、共著で「ピープルウエア 」を出されています。
今回はご自身の人生の中の40年間についてのお話です。この40年間を、写真にあるように9項目に分けて話されました。
Brown大学に入学しました。そこでWangさんという人の息子と会うことができました。ある日、Wang氏がコンピュータを部屋へ持って来ました。その時代はまだコンピュータをなかなか自由に触ることができない時代だったのですが、このおかげで楽しくプログラムを書くことができました。やってて楽しい時間を過ごすことができないなら、他のことを探した方が良いと言います。
大学を卒業しての初めての仕事は、ウォール街にあるアメリカン・エクスプレスでのプログラマでした。その時は、まだ部門には6名しか人がいませんでした。入社してから2ヵ月間、教育がありました。主にIBM360用にアセンブラ言語でのプログラミングです。上司の上司の上司くらいで29才のチームです。経歴よりもできる人を雇っていました。そのため、ここではいろいろな「できる人」と会うことができました。
残念なことに自分の上司が転職し、新しい上司は自分のことを信頼してくれませんでした。そのため、指示されたことだけを行う日々になりました。前の上司がどのようにして、仕事をあれほど楽しくしてくれたのかを考えるようになり、プロジェクトマネジメントに興味をもつようになりました。結果的に自分も転職することにしました。
1年間チームリーダーになりました。新しい仕事には契約社員として入たのですが、そこでは良いチームを作ることに興味を持ちました。正社員でなければ新しい人を雇うことができないため、3時間だけ正社員になりました。しかし、そこで採用した新しい社員に自分が楽しいと思うように接したら、次の日から来なくなってしまいました。
1995年の夏。エドワード・ヨードン氏に雇われました。その会社の8番目の社員となりました。ここでも良い人を集めていました。良いプログラマは間違いをしません。コードも綺麗です。アジャイルマニフェストは2001年に署名されましたが、それ以前から多くの人たちがそのための種を蒔いています。
American Arbitration Association（AAA）の仲裁人になりました。争いが起こった場合、当事者は両方とも必ず感情的になります。たとえば自分が関わった120万USドルの仲裁は、プログラムの開発を依頼したが、収められたプログラムが動かなかったというものでした。最初から失敗するとわかっているプロジェクトもあります。
ヨードン氏が進みたい方向とはすれ違って来たので、独立することにしました。プレゼンテータと著作者になりました。
1992年にアメリカ国防総省のSoftware Program Manager's NetworkのAirlie Councilに参画しました。大勢の優秀な人を集めて、結果を出すことができました。
「くそったれ」にならないルール：最後に以下のようなことをおっしゃって、自分の40年間の話を終わらせました。
今の仕事が楽しいと思えないのであれば、足を使え（転職せよ） 。人生は短すぎる。自分で自分の人生の道を拓け。
