2010年11月8日月曜日

「プレゼンテーションzen」っぽいプレゼンのやり方が「だいたいわかった」になるエントリー

「プレゼンテーションzenっぽいプレゼンのやり方が誰でも1時間くらいでわかった気になるワークショップ」というのをやってきました。
そこで話したこと、話きれなかったことを順を追って説明します。


P1-P4 タイトル~注意
「プレゼンテーションzen」って言えばやっぱり画像を多く使って文字数を減らすっていうイメージがあると思うんです。そこでこのワークショップでは、メッセージとマッチする、メッセージを助けてくれる画像を探す作業を体験してもらうことにフォーカスしました。だから「プレゼンテーションzenっぽい」と表現したわけです。1時間であの本なりビデオなりの内容を全部喋ってワークショップまでやるのは無理です。

P5-P9 心得
このワークショップの説明で一番伝えたいことがこれですね。
大事なのは「しゃべり」と「しゃべるあなた」です。
(聴く人も大事ですが、理由を説明し出すと時間足らないから割愛)
オープニングのLTや、他のコミュニティのワークショップでもだいたい同じようなことをいっていた気がします。
(喋りながら聞き耳たててました)

P10- つくりかた あらすじ

SUCCESsは自分なりの例題を紹介したかったのですが、準備が間に合いませんでした。この時点でこのワークショップの説明はConcreteness:具体性に欠けているわけです(苦笑)。
この章では一枚の図を中心に話を組み立てています。
感情が先行して喋り出すと気持ちが空回りして伝わらず、情報を整理して順序立てて説明するとちゃんと伝わる、ということを視覚的にわかってほしくて描いてみました。



P21はクリティカル・シンキングで必ず登場するピラミッドストラクチャーです。分解の仕方はいろいろあるでしょうが、これも視覚情報重視。


P22は情報を取捨選択して順番を決めることを伝えたくて、麻雀パイの画像を貼り付けました。これは我ながら良い例えw。同じ麻雀パイでも役が付く付かない、点数が高い高くないの差があるってわかったら、ちゃんと考えますよね。人に何かを伝えるということはそういう面があると思います。
よく「スライドにはとにかく情報を詰め込む。その場の雰囲気をみて、喋る内容を選ぶ。」と言う方がいますが、これはプレゼンテーションに慣れている人だからできる芸当であって、慣れていない人には難易度が高すぎます。またスライドに情報を詰め込んだ結果、時間内で完了することが出来ないこともありますが、この場合、聴講者のほとんどは集中力が切れています。集中していない人に一所懸命に語りかけたところで何も伝わりません。アンコールみたいなもので、聴講者も得したと思うはず、と考えているなら勘違いです。ロックスターなみに熱狂をもって迎えられる講演者なんてほとんど存在しません。
時間内で伝えきること、そのためには情報を取捨選択し、適切な順番に並び替え、冗長な言い回しを避け簡潔な表現に直し、言葉より視覚的に訴えた方が伝わるのなら迷わず写真を探したり図を作成してください。これらを意識することでプレゼンテーションの完成度はぐっと上がるはずです。


P25- ターゲット

「ターゲットを絞る神話」は実際に仕事でも感じたことです。
絞りすぎること、特定しすぎることで大事な何かがなくなったりします。曖昧ですが…。


P31- つくりかた 演出/スライド

心得のところでも説明したのですが「パワポ作る」とか「スライドつくる」って表現はなんか気持ちが悪いのです。自分でも言っちゃうときがあるけど。
スライドは演劇における舞台装置だし、戦いにおける武器だし、登山における杖みたいなものだと思います。喋る人の助けにはなるだろうけど、喋る人以上ではありません。たまに本人とスライドの主従逆転プレゼンを見かけることがあり、そういうときはなんとも言えない気持ちになります。私も以前は間違いなくそうでした。
そうは言っても、自分を助けてくれるものだし、演劇だったら舞台装置が豪華な方が演じていて気持ちが良いじゃないですか(多分)。だから、主従が逆転しない程度に、自分をより良く演出してくれる存在として、スライド作りに注力することも必要なのかと。


(↑テキストをベタっと貼った状態)


(↑リリース版。写真や図がかなり増えている)

実際の作業については百聞は一見にしかず、画像で見てもらうとわかりやすいですね。今回のワークショップのスライドの作業着手時と完成版の一覧表示を見てください。最初はテキストをベタ貼りです。これを少しずつ要約したり、画像に差し替えられるところは差し替えたりしています。


P42- 喜怒哀楽

印象に残る物語は受け手の喜怒哀楽に振り幅を持たせています。
実は映画やドラマのストーリーの多くは凡庸で冷めた目で見るとどれも似たようなパターンにはまるのですが、それらは主人公たちを理不尽な境遇に追いやったりして視聴者の共感を誘うことで凡庸ではなくなります。怒りと哀しみに訴えかけ同情を買うのです。
逆の場合は面白おかしくすることで笑いを誘ったり、特殊な演出によって爽快感を生み出します。これらが喜怒哀楽に振り幅を持たせる、ということです。
プレゼンテーションについても近いことが言えて、どれほど良い情報を聴講者に伝えたとしても、そこに喜怒哀楽の振り幅がなければ印象に残りません。下手をすると「つまらなかった」と言われかねないのです。
そこで喜怒哀楽に振り幅をもたせる仕掛け(演出)が必要になります。
とは言っても、プレゼンテーションの場であまりにも怒りや哀しみの感情に訴えかけるのはやりすぎな気もするので、さりげなく笑いをとりに行く方が良いです。
ただし狙って笑いをとるのは難しい。それには場数を踏んで、どういったネタが喜んでもらえるのかを感覚として掴んでいく必要があります。もちろん天性の才でどっかんどっかん笑いをとる人もいるでしょうが、自分もそうだと思わない方が身のためです。笑いを扱うにも技術がいるのです。だから「ネタは扱える分まで」と考えましょう。前後関係を考え、微妙と思われるタイミングであれば削る勇気を持ってください。

P49- ペース

「Sec/Page(せっくぱーぺーじ)」は目安としては悪くないので是非使ってみてください。
プレゼンテーションの多くは制限時間内で終わりません。途中から急ぎでしゃべり始めるし、LTは時間が足らないことが度々あります(ドラ娘の出番です!)。時間内で終わらせる、ドラがなるどんぴしゃのタイミングで終わらせる、そのためにはペースを把握しましょう。
またじっくり説明するページに対して、ポンポンとめくってテンポを良くしていくページがあるのも効果的です。メリハリが効くことで、聴講者も飽きずに聴くことが出来ます。

P56- アニメーション
アニメーションやエフェクトは最小限にとどめる方が良いです。
様々な理由あります。
・まず動くものをスライドに出現させることで、聴講者の意識がそっちにいってしまう、肝心のしゃべりが伝わりづらくなる懸念。
・アニメーションは一定の時間が必要なので、ペースに影響する。その場に併せた臨機応変な対応に制約がかかる。
・スライド編集の難易度が上がる。
個人的にはアテンションで使う程度にとどめるのが上手いつきあい方だと思っていますが、世間にはグリグリに動かして楽しいプレゼンテーションをされる方もいらっしゃるので、必ずしもアニメーションをオフにしろとは言いません。

P63-P71 練習、手直し

とにもかくにも実際に声を出して確認をすることです。
多くの場合、私も含めてですが練習は嫌なものです。なんだか間抜けな感じがするし、途中で詰まったりして気分が良くありません。しかし、ここが大事です。練習ではたいてい詰まるのです。話慣れないことを喋るために体が(口が)付いてこなくて詰まること。しゃべりの内容に整合性が欠けていて自分で違和感を憶えて詰まること。これらは実際に声に出して練習することで気付くことが出来るし、本番でこういった問題に遭遇する確率をぐっと下げます。少なくとも1回、できることならスラスラと自然に喋れるようになるまで練習をしてください。やったかやってないかで結果は全然違います。
ここで注意ですが、業界を問わず、凄腕のスピーカーは「練習なんかしない」と言い切ってしまう人がいます。それはそれで構いませんが、人は人、自分は自分です。自分が最も上手くできるプロセスを模索してください。多くの人にとって、それが「練習なんかしない」になることは滅多にありません。「あのスティーブ・ジョブズでさえリハーサルをやっている」と思えば、人知れず練習をすることは恥ずかしいことでも何でもありません。貴重な時間を投資してくれている聴講者に対する礼儀です。
練習の段階でレビューを入れるか、入れないかは自由です。できれば入れた方が良いでしょう。しかしここにも落とし穴があって、よくわかっていないレビュアーが存在します。よくわかっていないレビュアーはそもそものコンセプトに否定的な意見を出し、講演者を混乱に陥れます。ですのでレビュアーは慎重に選んでください。もし適当な人が周りにいたいのであれば「ぼっち法」で乗り切ってください。

P72 伝えるためのプロセスを描いた図

ここで図は完成です。練習はしゃべりにも演出にも作用します。
練習以上のことは本番ではできません。実際は緊張と極限までの集中力が奇跡的なパフォーマンスを生み出すこともありますが、それは希です。
また図示したために段取りを追えばプレゼンテーションができそうな気がしますが、実際には卵と鶏みたいにあらゆる情報が錯綜し相互に関係し合います。手戻り作業は当たり前ですが、完成度を高めるためだと思ってがんばってください。

P73-P78 本番のコツ

なるべくリラックスし、自然な状態で語りかけるようなプレゼンテーションが理想的ですが、最初からそのようにできるとは限りません。カチカチになって喋る内容をわすれてしどろもどろすることもあります。私なんかは本当に酷くて、途中から声がでなくなったりしたこともあります。
何人か、場合によっては大勢の聴講者の前で緊張をするのは自然現象です。避けられません。ですから緊張すること自体は受け入れてください。そしてコントロールするように心掛けてください。
「照れ」や「恥ずかしい」といった感情もあります。ですが、これは打ち消してください。講演者が恥ずかしがっていると聴いている方はもっと恥ずかしいものです。そんな態度で披露したネタがスベったときにはもう!大惨事の始まりです。これを克服するのにもぼっち法は効果的です。是非、試してください。
そしてなるべく多くの本番を経験してください。ここで言う経験とは「人前で喋ること」です。
仕事、学校、地域コミュニティ、お子さんがいらっしゃれば保育園や学校の集まり、親戚の集まり…、飲み会の乾杯、いろいろあります。是非、積極的にそういった場を活用して喋ってください。たいていの場合、みんなはそういった勇気を持った人を受け入れてくれるし歓迎します。手を挙げた心意気に賞賛の拍手を送ってくれるでしょう。ただし話が長くなければです。ライトニングであることが大事ですね♪


P79- ワークショップ

このワークショップを企画したときは「KPT」について話してもらおうと考えていましたが、DiscoveryCoachさんとquindimさんからアドバイスをいただき、好きなものを説明してもらうに変更しました。これは大正解でした。お二人には本当に感謝です。

今回はあくまで「プレゼンテーションzenっぽい」プレゼンのやり方を体験してほしかったので、メッセージと画像を組み合わせる作業に特化しました。その楽しさがわかってもらうことが第一目標。実際にプレゼンテーションzenの本やDVDで説明されている内容はそれからで良いのかな、と。当日はワークショップに40分くらい使ったと思います。できれば1時間あると、お互いのプレゼンテーションに対する意見交換もできて良かったのですが、それはまたいずれどこかの会で。


P90-P95 画像を選ぶ

以前、DevLOVEのLTでやった闇アジャイラー(動画、スライド)のオチ画像で比較をしてみました。プレゼンテーションzenの本にでてくる比較画像だとあきらかに片方はありえんわ、というケースがほとんどなのですが(画像の使い方を説明しているので)、この4枚なら狙いによってはどれでもアリだと思います。個人のこだわりを前面にだしたければナウシカだし、キレイにまとめて良い話っぽくしたいなら木漏れ日です。しかしこの時はインパクトをとりました。タイミングもばっちりでしたし(マイクロソフト台湾がサイトリニューアルしたのはDevLOVE Energized Workの前々日くらい)。ちなみにあれから2ヶ月近く経った今でも「やっぱりキレイにまとめておくべきだったのではないか」と思うことがあります。

P96-P99 まとめ

まとめて言いたかったことは下記。
・プレゼンテーション作りには段階があること。大切なのはしゃべり。
・伝わることが大事。どんなに良いこと言っても伝わらないなら意味がない。
・今日スベっても明日があるさ。迷わずスベれ。スベればわかるさ!

P100- おまけ
おまけにはtipsみたいな情報を書いておきました。時間がなくて説明できなくても、あとでスライドを見てもらえればだいたいわかるかなー、みたいな。
良いプレゼンにはここ最近見た中で印象に残ったものを載せました。
どのプレゼンも型破りで聴講者に対して強いインパクトを与えます。そうすることで印象づけられ記憶に残ります。


本当は「提供 クラスメソッド」も紹介したかったのですが、なんとなく割愛しました。もしE社関係の方がこのエントリーを読んでいらっしゃったら、私のパクリに許可をいただけますでしょうか?


スライドのレイヤー構造はスライドの再利用性を高めることを目的でやっています。真ん中に入る「実際の背景」がキモです。今のところ、この方法でレイアウトが壊れたことがないので、多分、イケるんじゃないかなあ。スライド作成は時間がかかります。生産性を高めるには再利用しかないだろうというのが今日この頃の考えです。

無料フォトサイトはプレゼンテーションzenに記載されているサイトに最近知ったサイトを追加して載せました。こういったサイトを知っておくのも良いのですが、使えそうな画像は普段からDLしたりURLをメモったりしておくのが吉です。ただし権利とかには注意してください。


Slideshareをやろう、っていうのはこのワークショップで最も言いたかったことなんじゃないかと思っていますw。人から学べることは多いです。また公開したスライドがどう受け取られているのかはview、favs、downlords、tweets、sharesあたりからなんとなーく知れます。



参考資料にはもちろん「プレゼンテーションzen」シリーズが載っています。当日、他の方もプレゼンテーションzenをかなり薦めていたようです。すごい人気。強いて言うなら、読んだだけでは何も変わりません。読んで見よう見まねでいいからそれっぽいことをやってみることが大事です。
またプレゼンテーションzenはプレゼンテーションがどうあるべきかを説明しているのに対し、「パブリック・スピーカーの告白」はその背景にはどういったことがあるのかを説明しています。ワークショップの1週間前に入手してゆっくり読んでいます。良い本です。スコット・バークンさんの失敗談で腹筋が壊されそうになります。
目指すべきところが「プレゼンテーションzen」で、その過程が「パブリック・スピーカーの告白」だと思ってください。両方ともオススメです。
あと「Webレイアウトの「解法」」が参考資料に含まれていることに驚く人がいるかもですが、レイアウトに規則性をもたせることで見た目が良くなることを学んだのはこの本なので載せました。矢野さんの本もオススメです♪
それと「XP祭りの基調LT」は動画がアップされています。是非、見てみると良いでしょう。私の説明よりはるかに良い内容です。

ボツ

実は私が人前に出て話すことをちゃんとやるようになったのは今年の1月からでまだ1年経っていません。マーケティングの仕事は7月からです。初心者なりにいろいろ試行錯誤をしてきました。その結果がこのワークショップです。だからもっと良い方法を知っているよ、という方がいらっしゃったら是非、教えてください。
このページはワークショップに参加してくれた方たちにとって、私が初心者であるなんていう情報はなんら有益ではなくただのノイズだからボツにしました。

だいたい以上です。
ああ、長かった。こんなの最後まで読む人いるかな?
それとこのエントリー「あとで新聞」とかにのらないかなw?

駄文に最後までおつきあいいただき誠にありがとうございます。




2010年10月3日日曜日

闇アジャイラーの影でボツになったネタ

10/1(金)のエントリーでも書いたのですが、DevLOVE Energized Work!」で「闇アジャイラー」というネタLTをしてきました。



諸処の事情でボツにしたネタやスライド、そもそものLTの背景などをメモしておきます。

■「闇アジャイラー」について(P2-P11)
・なんで「闇アジャイラー」なのか?
冒頭で説明したとおり、XP祭の翌週、ネット上でにわかに盛り上がっていた「闇プログラマー」にインスパイア(笑)されました。アジャイル原則と架空の闇アジャイル原則を比較したらそこそこ笑ってもらえるだろうか、と。
実際のところはただ単純に闇アジャイラーって言いたかっただけなので、そんなに深いねらいはありません。LTだから出オチでいいだろう、という程度。

・カットしたスライド
当初、アジャイル原則と闇アジャイル原則の比較はもっと「エグい」話を入れていたため保険として入れておきましたが、エグい話はカットしたので不要となりました。

きっとみなさん律儀にEnergized Work!の話をするだろうなと予測しました。LTで14回もEnergized Work!の話を聞いたら参加者はみんな飽きるだろうと判断しカットしました。実際、Energized Work!については一言も喋っていません。
しかしテーマとしては外していないつもりですし、闇アジャイラーはEnergized Work!の障害の一種です。

「闇アジャイラーかわいいよ闇アジャイラー」
実は平鍋さんバージョンもあったのですが、ご本人の前でやるのは気が引けたのでカットしました。

■アジャイル原則と闇アジャイル原則の比較(P12-P19)
アジャイル原則は全部で12項目あので、闇アジャイルバージョンも12項目すべて作りましたが、しつこいのとエグすぎる(笑えない)ため4項目を残してカットしました。尚、アジャイル原則は言い方がいろいろあり、日本語訳も何種類かあるようです。

アジャイルを表面的に都合良く解釈して関わるメンバーに無理強いをさせる、前言を翻すためにアジャイルをもちだす、そういう人に対して言いたいことがあったりなかったり(※フィクションです)。

■【図解】闇アジャイラーが生まれるまで(P20-P45)
小ネタ(「絶対領域」、「すまぬ…すまぬ…」、「だが断る」)を仕込んでいますが結構まじめな話です。

「曖昧領域/調整領域/絶対領域」
twitter上で「あいまいなことが多すぎてプロジェクトの見通しが悪い」みたいなことをつぶやいたときに「あいまいなものはなくならない」ととある方がおっしゃいました。あらためて考えると確かにその通りで、プロジェクトの特性(独自性、有期性、段階的詳細化)を考えてみてもあいまいなモノゴトが存在するのは確かです。
しかし本当にマズイのは、あいまいなモノゴトを都合良く解釈したり、思い込みがあったり、またほのめかしをしたりすることで、それがステークホルダーで共有されていないことです。この「曖昧領域/調整領域/絶対領域」の図ではプロジェクトの様々な情報がどのような状態にあるのかを可視化することが大切であることを言いたかったのです。これはPMBOKのプラクティスが全てプラクティスの前後にインプットとアウトプットがあることがヒントになっています(それだけじゃないよ)。

加えると曖昧だから見積もれない、計画できないということもよくあるかと思いますが、そんなことはありません。確定していることは少なからずあり、それがあるのであればそれを制約として利用するという発想ができるはずです。何をしたいのか、何ができるのかをステークホルダーでちゃんと共有しましょう。
話はそれからです。

私が関わったとあるプロジェクトですが、そのプロジェクトでは技術はほぼ初めて採用するもの、期間は半年以上、検証をしつつ本番実装をする、ユーザー数未定、実装する機能も未定といった条件で見積もりと計画をつくったことがあります。その際、こちらの確保できる工数を伝え1ヶ月ごとのタイムボックスを切り、その都度、優先順位付けをしてスコープを検討し、見積もりを提出していく手法を提案して採用されたことがあります(この時はアジャイルじゃなくて統一プロセスを参考にしましたが)。毎月精査な見積もりを提出するのは本当にしんどかったのですが、プロジェクトの進め方としては悪くなかったと思います。
これはアジャイルや統一プロセスなどについて書籍を通じて学んでいたからできたことです。たとえ形式知のレベルであっても日々学ぶことで何かの役に立つことは多々あります。
また書籍のよいところは形式知化されているため他者に伝える際、伝え方の参考になることです。「わかっていはいるし実践もできるけど説明ができない」ことありませんか? 書籍を通じて体系的な形式知を学ぶことで助けられるはずです。

ところでこの「曖昧領域/調整領域/絶対領域」の図ですが、こういった情報を意識して共有することが大切なのでこの図や言葉を使う必要はありません。
貸借対照表のような書き方をするのも面白いかもしれませんね。

■ プロセスからオチまで(P46-P58)
プロジェクトは以下の特性を持っています。
1.独自性
2.有期性
3.段階的詳細化
これをちゃんと理解しているのであれば、万能なプロセスがないことはわかるはずです。
ウォーターフォールが悪いのではなく、ウォーターフォールが適さないプロジェクトを無理矢理ウォーターフォールにあてはめることが悪いのです。これはアジャイルもそうです。
様々なプロセスについて論じること自体は嫌いではありません。むしろ積極的に飛び込んで意見を出したり聞いたりすることは好きです。でもちょっと皮肉っぽくきのこ厨vsたけのこ厨の話を引き合いに出しました。
ちなみに私はtakeだけにたけのこ派です。

・カットしたスライド
「ガンプラ」
私がプロセス偏重の危険性を説明する際、よく使う喩えなのですが時間の都合と、そもそもガンプラの組み立てはアジャイルである必要はなく、話の流れの中で違和感が生じるためカットしました。

「曇りなき眼で見定めてプロジェクトを計画すること。」
スライドは残しましたが画像はカットしました。オチにでてくる光のインパクトを最大化したかったためです。

「不確実性のコーン」と「ブルックスの法則」
不確実性のコーンはネガティブな印象を持ちそうですが、これはプロジェクトの曖昧なモノゴトを明確にしていくという学習プロセスを象徴したものだと思うとなかなか良い図だと思います。しかし初期段階における不確実性を無視することで曖昧なモノゴトの暴走を許します。
ブルックスの法則に対する無理解こそが、人を機械部品のように扱う闇アジャイルの最たるものだと思います。
いずれも時間都合でカットです。

「光のアジャイラー」
このLTのオチになるところですが、3つの候補画像からどれをどのように使うかで悩みました。

1.森の中に光が差し込むパターン

2.ああっ女神様のベルダンディーが輝く地球のようなものを抱えているパターン

3.風の谷のナウシカが「いのちは闇の中にまたたく光だ!!」と言い切るシーンのパターン

無難に1.でスライドを作っていたのですが、本番の前日にMicrosoft台湾が光をリリースしたことによりあのようになりました。これは完全にラッキーですね。

いつも使っているThank you Marioのページ、Let'sで始めたらwith meはいらないよね。今更だけど恥ずかしいミスです。。

■さいごに
再度「曖昧領域/調整領域/絶対領域」

闇アジャイラーも2つのパターンがあって、一つは1人のリーダーやマネジャーによってもたらされるとき、二つめは関わる人の多くが暗黙的な考えや振る舞いによってもたらされるときがあると思います。
今回のLTの図では、闇アジャイラーが生まれる直前、カオス状態になって全員が「死ぬまで働けば」と思い詰めてしまいます。それは時間が経つと、その状態に否という人に対して攻撃や排除をし始めたりします。過剰な残業が常態化している組織であるのかもしれません。
個人的には1人のリーダーによってもたらされる闇アジャイルよりも、チームメンバーが暗黙的にやっている闇アジャイルの方が多くの不幸を生み出す気がします。これは組織の文化であることもあるので根深い問題です。
もしそういった状況におかれている方がいたとして、その方が「Energized Work!」を知って何かが変わり始めれば良いな、と思います。

2010年10月1日金曜日

DevLOVE Energized Work! のLT祭のまとめ

【追記】
当日の動画はこちらへアップされています(鋭意追加中とのこと)

平鍋さんのスライドは@daipresentsさんのblogから閲覧できます。


9/30(木)に行われた「DevLOVE Energized Work!」のLT祭のまとめです。
LTは一般的には5分で行うのですが、この日は何故かLTer数が多く、各自持ち時間わずか3分で喋る「ULT(ウルトラライトニングトークス)」となったのでした。

とりあえず、ざっとしらべてわかった人のスライドだけ載せてあります。
この後アップした人はTwitterでつぶやいていただけると助かります。

1.@jun116
 「Energized Work タイプ別分析」

2.@amameci

3.@mtg0003
 「いつか神保町に 本が詰まった ビルを持ちたい DEVLOVE ENERGIZED WORK !」

4.@fkino
 「活き活きとした仕事」

5.@kaji_3
 「DevLOVE energized work! 」

6.@take3000
 「闇アジャイラー」

7.@kohsei
 「婚活メソッド」

8.@oitomo
 「実証実験レポート ~人を活性化するモノは何か?~」

9.@kawasima
 「寝プログラミングのススメ」

10.@yujiorama
 「develove_20100930_yujiorama.pdf」
11.@ymkz303
 「とあるチームの開発事例」

12.@chachaki
 -UNKNOWN
13.@kawaguti
 「Energized Workに向けて、あなたが今日からできること」

14.@quindim
 「#○○○love」

個人的には司会兼務でLTのトップバッターを務めた@jun116と、DevLOVEの「ミニ」ドラ娘の@kuni02の2人がMVPだったような気がします。

2010年9月3日金曜日

[DevLOVE]iPhoneアプリ構築+管理勉強会「本当にあった怖い話」の開催しました。

何で企画したのかって、本当は@jun116がお願いしたんですけどね(笑)


LTで言いたかったことは、一応、結構、真面目な話です。
(SilverlightUGきてください、のとこじゃなくてw)
App Storeの登場によって個人でビジネスをやっていく土壌がものすごく進んでその世界でがんばっている人がいて、そうすると相対的に自分の立ち位置とか考える機会になるだろうな、と。

私は高校生の時、この世界で刀を振っていくのは無理だって思いました。
それでも縁があって、それとなんだかんだ言ってもIT好きだったから、この世界にいるわけで、やっていく以上、サラリーマンとして、つまりマネジメントとしてやっていく覚悟をもっています。
だからそれなりにこだわりあるしね。

それと一応、補足しておくとサラリーマンとフリーランスを否定してません。
組織を上手く使って己のスキルにレバレッジかけるのもありだし、素早く次々と新しいことをやるのも良いと思います。
本人の選択だと思ってます。

ま、そんな私の話はどうでもよくて、今回も良い感じにできて良かった。
@tilfinさん、@kotamzに感謝。
@jun116、@mtg0003、@kuni02に感謝。
それと参加してくれた#devloveな皆様に感謝。

2010年8月31日火曜日

Adobeさんとの共催セミナーで司会・進行・運営をやります。

Adobeさんとの共催セミナーで司会・進行・運営をやります。

【ビジネス編】Flex × Java 業務システム改善セミナー

【デベロッパー編】Flex × Java 業務システム改善セミナー

どちらも明日9/1(水)です。

今回のセミナーはビジネス編、デベロッパー編と対象者を分けてダブルヘッダーにすることにしました。私が知る限りでは新しい試みのはず。

運営側としては大きな会場を借りて1回で済ます方が楽です。
しかし、私達の想いとしては、ご来場された方と少しでも多くのコミュニケーションを、それも一方通行ではない双方向の対話の場を作りたいと考えました。

私個人の経験ですが、印象に残る勉強会やセミナーって参加者は少ないけど、発表者・受講者の双方から意見や質問がガンガン飛び交うようなものが多かったと記憶しています。
明日もそのようになれば良いと思うし、そうなるような雰囲気作りに努めるつもりです。

至らぬ点は多々あるかと思いますが、皆様のご来場をお待ちしております。

2010年8月27日金曜日

ナナナナ会 30±10代しゃべり場LT 「エージェント、Help、XP」

事の発端は@mongchangさんが仕事との向き合い方、距離の取り方について、いろんな人の意見を聞きたいぜ+話したいぜー、と言ったつぶやきをしていたので、じゃあ、それナナナナ会でやろうよ、ということにし、@papandaさんをはじめとする#devloveな人達を巻き込んでLT大会+ディスカッションをする会をやってみました。
そして自分もLTをやってみました。


このプレゼンテーション、実はすごい難産で、映画「ザ・エージェント」を引き合いにして、私なりに仕事と生活についてどう思っているのかを面白ろ可笑しく話そう、というコンセプトはするするとできたものの、そこから納得感のある話、スライドを作るのにすんごい時間かかった。もう、途中、無理じゃないかと思うくらい。

物質、精神とかを卓越した幸せを表す言葉として「クワン」をキーワードにし、運良くディスカッションでもそんな話ができたので個人的には良かったです。

※注意
この定義は映画「ザ・エージェント」と書籍「パターン、Wiki、XP」に登場する無名の質としてのクワンを、私が強引に抽象化したものなので適切かどうかは微妙。プレゼン作るのに手こずったのは、この抽象化に納得感を持たせるのが、私としては非常に難しかったから。

ディスカッションではいろんな話をしたし、話を聞けた。
いくつかメモっておくと、
  • デスマの我慢の仕方は?
  • お金って?
  • 技術者はサラリーマンでOK?
  • 何が大事?
  • 男女で違いある?
  • IT業界にもスーパースター的な高額所得者いてもいいのでは?
  • 育てていく意識
などなど。
(誤解を生みそうなのは伏せておきます)

LTも含めて、本当に、録画しておくべきだったと後悔するぐらい良い話がたくさんあった。あったなぁ。

さて、次ですが…。
コミュニティ活動をがんばることによって引き起こされる「ご家庭デスマ(by @papandaさん)」について話すのも良いかも。

ナナナナ会自体は@mtg0003企画の「お絵かきナナナナ」の予定です。

最後に、この会に参加した人、参加できなかった人、端から参加する気もなかった人、だまされたと思って「クワン」について考えてみると良いですよ。





多分ね。

2010年8月25日水曜日

【業務連絡】「30±10代しゃべり場(ナナナナ会)」のおしらせ

「30±10代しゃべり場(ナナナナ会)」のおしらせ

■開催概要
 日時:2010年8月27日(金)19:30~21:30
 主催:ナナナナ会
 参加費:割り勘
 (ビールとピザ程度を用意します)
 対象:30±10代のIT関係の人
 テーマ:仕事と生活のバランスについて語り合ってみよう

■アジェンダ
1.はじめに(5分)
2.自己紹介(10分)
参加者全員で順番で行う
3.LT&ディスカッション(5分+15分)×4~6くらい
(順番は当日の雰囲気で決めます)
4.ご歓談
5.お開き
6.(希望者で)近所の居酒屋で反省会※別途実費

受付に張り紙をしておきますので、そちらの案内にしたがって
セミナールームまでお越し下さい。

お問い合わせは@take3000にD下さい。

2010年8月24日火曜日

社内勉強会「プロジェクトマネジメント勉強会(PMBOK概要)」で喋った内容

1月にやったプロジェクトマネジメント勉強会が消化不良だったこともあり、社内で再び喋る機会を頂いたので喋ってみました。

しかし何となくまた消化不良。なんでやねん。


 以下、勉強会のために用意した原稿 ■

[note]_プロジェクトマネジメント勉強会(PMBOK概要)20100824

■P1
はじめます。
・このイラストの説明
・今日の勉強会に何を期待しているのか?
・PMBOKについてどの程度のことを知っているのか?

■P2 プロジェクトマネジメント勉強会(PMBOK概要)
技術部の嵩原です。
よろしくお願いいたします。

■P3 注意
最初にみなさんに注意です

■P4
注意①「この勉強会には新しい知識はありません」

この勉強会を通じて、皆さんは新しい知識を得ることはありません。
全て、実際のプロジェクトを通じて、もしくは書籍やWebの記事を読んで、
みなさんが経験や知識としてすでにもっているものです。
注意②「集中してください」

資料は後で差し上げます。

コンセプト③「わからない単語はその場で質問してください」

でも私が応えられなかったら、雰囲気でつかんでください。

コンセプト④「私はウソをつきます」

疑ってかかってください

■P5 はじめに
はじめに

■P6 プロジェクトマネジメントって何?
プロジェクトマネジメントって何?
はい、なんだと思いますか? って聞きたいところですが、
■P7 っていう漠然としたテーマで~
っていう漠然としたテーマではじめるとドツボにはまるので、
今日はPMBOKに沿ってお話しします。

■P8 PMBOKって何?
そうすると「PMBOKって何?」ってなりますよね。

■P9 Project ~
PMBOKはプロジェクトマネジメントの知識体系、
Project Management Book of Knowledgeの略で、最新は第4版です。
PMBOKとはPMI、プロジェクトマネジメント・インスティチュートが編
纂をした知識体系で

■P10 ウィキペディアによると
ウィキペディアによると

■P11 PMBOK --------
こんな説明があり、一言に縮めると、

■P12 先人達の知恵
こういうことになります。
じゃ、なぜこのようなものが生まれたのかというと、一昔前まで、
プロジェクトマネジメントの手法が属人的だったことがあります。
人によってやり方がずいぶん違っていますと。
あと同じ事を言っているのに名称が違うとかね。
そしてPMBOKにはどういったプロジェクトでも共通して
適応できそうな手法や考え方をまとめています。
これは非常に便利で良いぞってことで

■P13 多くのフォロワー?が生まれた
多くのフォロワーというか、派生体系が生まれ、今では

■P14 SWEBOK ~
こんな感じでいろいろあります。
(必要であれば、各項目を簡単に説明)
こんなに派生体系が生まれるくらい、よくできた編纂方法だったんですが、
ちょっと問題というか
■P15 ここで注意
注意があって、PMBOK自体はどういったプロジェクトにも共通して
有効な手法や考え方をまとめただけあって

■P16 この知識体系に専門知識はついていません
PMBOKだけあっても何も解決しません。
これは一頃言われた「PMBOKは現場で役にたたない」という風評被害の
一因になったんじゃないかと思います。
でもそれは間違いで、PMBOKはあくまでプロジェクトマネジメントの知識
体系であって、専門知識を扱ったものではありません。
しかし専門知識なきマネジメントなどあり得ないので、
■P17 ※用法用量は守ってお使い下さい。
用法用量は守ってお使い下さい。
私、個人的にはSWEBOKとの併用がお奨めです。
■P18 PMBOKによるプロジェクトの定義(特性)
さてプロジェクトマネジメントを学習する上で、必ず押さえておいてほしい
こと、それはそもそもプロジェクトってなんなんですか、という話です。
これにはプロジェクトが共通してもっている特徴を押さえるとわかりやすい
です。
それには3つあって

■P19 1.有期性 2.独自性 3.段階的詳細化
1.有期性 2.独自性 3.段階的詳細化 です。

■P20 1.有期性
1.から順に簡単に説明すると、

■P21 始まりがあって~
有期性は始まりがあって、終わりがあること。です。
毎日やる業務とかも、厳密に言えば始まると終わりがあると言えなくも
ないですが、プロジェクトは明確(時にはあやふやに定められます)
■P22 2.独自性
次の独自性ですが、これは

■P23 同じ物はない
同じ物はない。
プロジェクトは二つとして同じものはありません。
作り出そうとするプロダクトは二つとして同じものはありません。
仮に何かのプロダクトやサービスのパクリ構築プロジェクトだとしても、
オリジナルメンバーをそのままでやることはあり得ません。

■P24 3.段階的詳細化
次に段階的詳細化ですが
■P25 細かいことは(本当のことは)~
こうやって書くとちょっと嫌な感じがしますけど、最初から全部わかっ
ていることはありません。
個人的にはこの言葉は好きで、プロジェクトはわからないことをわかる
ようにしていく活動と言い換えることもできます。ある意味、学習の過程
であり、終わった時には知らなかったことを知ることになります。
だいたい今までの3つをまとめると
■P26 プロジェクトとは、ある一定の期間において~
「プロジェクトとは、ある一定の期間において、唯一の成果物
 (モノ/サービス)を生み出すための活動である。」
とも言えます。
そこであらためて

■P27 プロジェクトマネジメントって何?
プロジェクトマネジメントって何?な話を
■P28 あえて
あえて
■P29 一言で表すと
一言で表すと
■P30 フォースに調和をもたらすこと
フォースに調和をもたらすこと、かなと。
■P31 説明しよう
いちおう説明すると
■P32 ウィキペディアによると
ウィキペディアによると
■P33 (画像)プロジェクトマネジメント
■P34 プロジェクトマネジメント(プロジェクト管理)
「プロジェクトマネジメント(プロジェクト管理)とはプロジェクトを
 成功裏に完了させることを目指して行われる活動のことである。
 これにはプロジェクトを構成する各活動の計画立案、日程表の作成、
 および進捗管理が含まれる。」
と書かれています。
もちろん間違ってはいませんが、個人的な想いとしては
■P35 ちょっと足らない
ちょっと足らないと思っていて、何故かというのを説明すると
■P36 (画像)ビジネス、エンジニアリング、プロジェクトマネジメントの図
これは業務システムやソフトウェアの開発プロジェクトに必要な知識や
スキルをざっくりとわけたベン図です。
ビジネスはプロジェクトを通じて生み出されるプロダクトやサービスを用
いて利益を生み出すことが主な目的です。
これはビジネスアナリスト、システムアナリスト、ITストラテジストと
いった役割の人が考え音頭をとります。
クラスメソッドの場合はお客さまがやることが多いです。
エンジニアリングはそれを実現するための活動全般です。どうやったらそ
れができるのかを考え現実世界に適応していきます。いわゆるアーキテクト
やシステムデザイナーの仕事です。
ビジネスとエンジニアリングは敵と書いて「とも」と読むような関係です。
放っておくとすぐ闘い始めます。
しかし、現実の世界ではビジネスの方が権力をもっていることが多く、
エンジニアリングが泣きをみることが多いです。
しかししかし、世界は因果応報、エンジニアリングに泣きを見させると生み
出されるプロダクトやサービスが低品質なことが多く、結果的にビジネスも
泣きを見ます。
「誰得」なことになります。
■P37 プロジェクトマネジメント(プロジェクト管理)
それを踏まえた上で個人的な追記をさっきのウィキペディアにすると
「プロジェクトマネジメント(プロジェクト管理)とはプロジェクトを
 成功裏に完了させることを目指して行われる活動のことである。
 これにはプロジェクトを構成する各活動の計画立案、日程表の作成、
 および進捗管理が含まれる。
 また、利害が相反する関係者の意見を集約し、制約を利用しつつ、
 プロジェクトにおける共通目的を達成するために行うあらゆる活動。」
となるため、

■P38 だから
だから
■P39 フォースに調和をもたらすこと
「フォースに調和をもたらすこと」となるわけです。

(ここで一呼吸置く。気分転換にスターウォーズの話を振ってみる)
プロジェクトマネジメントとジェダイの関係について、皆さんにご理解
いただけたところで、先に進めます。
PMBOK、プロジェクト、プロジェクトマネジメントがだいたい何なのかが
わかったところで
■P40 じゃあ、何をするの?
じゃあ、何をするの?となると思うですよ。
そういうときのために、

■P41 プロセス順に説明
プロセス順に説明をします。が、
■P42 でも「プロセス」っていうと
でも「プロセス」っていうと、
■P43 こういうのとか(滝)
こういうウォーターフォールなやつとか、
■P44 こういうのとか(スクラム)
スクラムとかアジャイルみたいなやつとか、
■P45 こういうイメージがあると思うんです。(ラップ)
RUP、言い換えると統一プロセスみたいのを連想すると思うんです。
(RUP、アジャイル、スクラムについて知っているか確認しておく)

■P46 PMBOKのプロセス~
今、出てきたのは基本的には「ソフトウェアの開発のためのプロセス」
なので、あらゆるプロジェクトに共通して使える汎用的なものとは
ちょっと違います。
違いますって言っておいてなんですが、ここは話し始めると長いから
この場ではそういうことにしておいてください。
PMBOKのプロセスはもうちょっと汎用性のある(抽象的)なものです。
■P47 (画像)5つのプロセス
PMBOKではプロジェクトのプロセスを5つに分類しています。
・立ち上げ
・計画
・実行
・終結
・監視コントロール

立ち上げ
プロジェクトを公式に認可し、ステークホルダーを特定します。
さらに何を持ってステークホルダー、この場合は顧客がメインになり
ますが、の期待を満足することができるのか、要求事項を文書化する
プロセスです。
この立ち上げフェーズでは、プロジェクトマネジメント憲章という文
書を作成することがあります。

計画
作業全体のスコープを確定させ、アクティビティ、WBSを洗い出し、
プロジェクトの計画を策定します。
この際、プロジェクトマネジメント計画書という文書を作ることがあ
ります。
ていうか、できれば作ってください。
扱う情報は多岐にわたり、というかプロジェクトに関わる物事のほぼ
全部となります。
営業さんを含めプロジェクトマネジャーやプロジェクトリーダーで考
えます。

実行
プロジェクトの仕様を満たし、プロジェクトマネジメント計画書に
規定された作業を完了するための活動です。
プロジェクトマネジメント計画書に沿って、人と資源を調整し、
プロジェクトのアクティビティを統合し、実行します。
プロジェクトマネジメント計画書に従って活動をします。
主にプロジェクトリーダーによる作業指示と進捗管理が該当します。
このプロセスにおいて変更管理をきちんとしないと痛い目にあいます。

終結
プロジェクトの契約上の義務を公式に完結するために、またアクティ
ビティを終了するプロセスからなる。
納品から請求支払いが該当します。
終結は他のプロセスに比べて、情報量こそは多くありませんが、完了
条件を現実的で実行性のある内容にしておかないと、先立つものが先
立たなくなってしまう原因になりかねません。
わたしも苦労した経験がありますが、特に、納品、検収、請求、
支払いサイトについてはしっかりとした確認を行ってください。
そしてプロジェクトのレビューや教訓の文書化なども行います。
そこまでやってプロジェクトです。

監視コントロール
プロジェクトマネジメント計画書で定義されたパフォーマンス目標を
達成するため、進捗をチェックし、レビューし、統制する活動です。
プロジェクトチーム外から、プロジェクトの運営について適切である
かどうかチェックすることもあるでしょう。

■P48 確かに抽象的だけど、どんな~
「確かに抽象的だけど、どんなプロジェクトであってもこの5つは共通して
 必要。」
です。
ウォーターフォールとかアジャイルとかRUPを簡単に紹介した後に、PMBOKの
抽象的なプロセスの説明をしているのには理由があって、それは

■P49 プロセスの偏重は罠
プロセスの偏重は罠という思いです。
というか、○○プロセスを採用したら上手くいくとか、○○プロセスを
やってますとかは単純で分かりやすいから飛びつきたくなる気持ちはよく
わかるんですけど、罠です。
これを
■P50 身近な例
身近な例である、
■P51 ガンプラ
ガンプラで説明すると
■P52 (ガンダム)
例えばガンダムを組み立てるプロセスをこうしたとします。
1.頭 2.胴体 3.手 4.足 5.シールド 6.ライフル
しかし、同じガンプラでも種類が違うと
■P53 (ジオング)
ジオングに至っては足ない、シールドない、ライフルないで冗長なプロセス
を採用することなります。
しかも、よく見てください。
足の代わりに台座があります。見えますか?
■P54 プロジェクトは「独自性」の特性を備えている~
「プロジェクトは「独自性」の特性を備えていることに注意し、
 プロセスを盲信しないこと。
 アジャイルだから上手くいく、ウォーターフォールだから失敗する
 わけではないこと。」
ということをしっかり頭に入れましょう。
これはPMBOKでは

■P55 (~略)これにより、
こういった文章で解説されています。読みます。
「これにより、本書で述べる知識、スキル、プロセスを常にすべての
 プロジェクトへ画一的に適用すべきであるといっているわけではない。
 プロジェクト・マネジャーは常に、プロジェクト・チームと協力して、
 当該プロジェクトでは、どのプロセスが適切であり、各プロセスをどの
 程度の厳密さで実施すべきかを決定する責任がある。」
ある意味、これが全てです。
■P56 何をやるのか?
結局「何をやるのか? やらないのか?」をはっきりさせることが最低限
大事で、プロセスはそれから考えても良い話です。
イメージとしては
■P57 曇りなき眼で見定めてプロジェクトを計画すること。
「曇りなき眼で見定めてプロジェクトを計画すること。」
であると強調しておきます。
で、

■P58 「計画?」
計画をたてるわけですが、さっきの5つのプロセスを思い出してください。
■P59 5つのプロセス
粒度は違えど、計画立案は立ち上げプロセスから始めます。
ここでお伝えしておきたいのは、計画というのはメンテしながら使うもの
であることです。一回たてたら終わりじゃなくて、状況状況に合わせて、
変更していくことが大事です。
絶対計画通りになるというのは、段階的詳細化に反しますし、そもそも
そんなものは計画ではなくて、予言です。ありえません。
■P60 何をどう計画する?
さて、何をどう計画するのか?
■P61 PMBOKにはほとんどのプロジェクトで共通する知識領域が9つ
PMBOKにはほとんどのプロジェクトで共通する知識領域が9つ用意されてお
り、

■P62 1.統合 2.スコープ ~
並べるとこんな感じ。それらを更にブレイクダウンすると、それぞれ
こんなプラクティスを持っています。
P63~70はさーっと飛ばす
■P71 プロジェクト統合マネジメント
で、ここまで8つの知識領域を統合するのが、この
「プロジェクト統合マネジメント」の領域です。
この辺は9つの項目だけなんとなく憶えてもらって、プラクティスは
都度考えるとかでもとりあえずは大丈夫です。
それとどのプラクティスも
■P72 インプットとアウトプットに注目し、
「インプットとアウトプットに着目し、シンプルに考えること。
 全て下記のパターンでできてる。

○○のインプット
○○のツールと技法
○○のアウトプット」
インプットとアウトプットに注目してください。
かならずこのパターンになっていますし、プロジェクトの計画を立てたり
実際に作業をするときは、かならずインプットとアウトプットがあるはず
です。
そしてアウトプットの行き先に留意してください。
行き先のないアウトプットはムダな作業かもしれません。
もしくは利用者のことを考えてアウトプットをだすことも大事です。
これぐらいの情報を押さえれば、しっかりとした計画を立てられるで
しょう。でも、

■P73 いきなり全部細かにかくのはしんどいから、簡単なところから。
「いきなり全部細かにかくのはしんどいから、簡単なところから。」
でも大丈夫です。

■P74 顧客名 ~
私がプロジェクトに関わるのは立ち上げから計画に相当する時期が多い
のですが、だいたいこれぐらいの情報は把握し、その推移を管理するよ
うにしています。
■P75 このレベルでもしっかり書く(把握する)だけで~。
このレベルでもしっかり書く(把握する)だけで、プロジェクトの見通し
は随分違います。不足があれば都度、考えて追加してください。
(確認)

■P76 ここまでの内容に補足
ここからはサマった知識だけじゃなくて、ちょっとした注意点とか
TIPSをご説明します。
■P77 コミュニケーションについて
コミュニケーションは仕事をする上でもっとも大切な事の一つですが、
仕事をしていく上で最もムダな事の一つです。
なぜムダと言っているかというと、コミュニケーション自体がものを
つくるわけでありません。
しかし、私の数少ない経験上、コミュニケーション・マネジメントは
どこ行っても適当な扱いで、適当にしてしまったがためにプロジェクト
に重大なオーバーヘッドを発生させる原因にもなります。
クライアントが何気なく納品を求めたドキュメントはそのわかりやすい
例ですが、日常においても「なんでそんなこと知らないの?」みたいな
事は思いの外、時間をムダにするものです。

コミュニケーションに無理、ムダ、抜け、漏れ、冗長さがないか、根本
に立ち返って考えてみるのも悪くないはずです。
コミュニケーションをデザインすることを心がけてください。

■P78 コミュニケーションパス
それとコミュニケーションパスのはなし。
コミュニケーションパスの求め方を知っている人いますか?

n(n-1)/2ですね。

プロジェクトの人数が増えるときはコミュニケーションの時間も工数も
増えます。
1パスが1日当たり15分ほど時間を使うと仮定すると3人までなら管理者は
作業者兼務でいけますが、5人くらいから管理者は管理業務専門になり、
10人とかになると管理者を手伝う人が必要なります。
ちなみに1パス15分は楽観値です。
おそらく30分から1時間くらいはかかる可能性があります。
またステークホルダーとのコミュニケーションもバカになりません。
結構、もっていかれます。
定例MTGなんかもそういった活動に該当します。

余談ですが、営業の世界では、上長の下に付けられるメンバーの数は
7人程度だそうです。
7人はけっこうがんばってもらう感じ。
できれば5人くらいで勘弁してあげた方が良く、10人は管理しきれない
そうです。
この例でもあるように、マネージャー一人で10人も20人も、はてはそれ
以上のメンバーを管理する話は無理があります。


■P79 このパスは空間軸(他人)だけでなく、時間軸(未来の自分)にも発生する
またパスは空間軸(他人)だけでなく、時間軸(未来の自分)にも発生します。
未来の自分、未来の他人とのコミュニケーションは主にドキュメントに
なります。
それを踏まえた上で、どうするえばコミュニケーションしやすいか
考えましょう。

■P80 「計画」
あらためて計画に関する話。
■P81 不確実性のコーン
段階的詳細化を一目見てわかってもらえるグラフが不確実性のコーンと
呼ばれるグラフです。
プロジェクトに対してどの程度の工数が必要であるのか、フェーズごとに
その振れ幅を表しています。
諸説ありますが、プロジェクト計画時点では最大400%、最小25%ずれると
いう説があります。
契約締結の際、前半を準委任契約、後半を請負契約にすることの理由は
こういうところにあります。。

■P82 ブルックスの法則
「ブルックスの法則」はプロジェクトメンバーを増員しても縮められる
期間には限度があることを表しています。下手すると、余計に時間が
かかります。
プロジェクトは規模に応じて、適切な人数と期間があり、がんばって縮め
ようとしても限度があります。

■P83 PERT図
パート図はタスクの手順と関連を表した物で、古典「計画の科学」で詳しく
解説されています。
■P84 ガントチャート
ガントチャートはPERT図よりも全体の流れを俯瞰しやすく、またその作業
にかかる期間をイメージしやすい表現になっています。
私は好きなんですけど、これを使って進捗管理をすると、本当の進捗率を
隠蔽してしまったり、もしくは実態をよりも進んでいると錯覚を起こす
ことがあるので注意が必要です。
本来の目的はあくまで計画の見通しを知るためのモノです。
■P85 バーンダウンチャート
「アジャイルな見積もりと計画」という書籍に詳しい使い方が紹介されて
います。
簡単に説明すると、タスク総量を積み上げて少しずつ減らしていく
チャートです。
タスク総量と生産性(ベロシティ)と期間の3つのパラメータしか
ありません。
①タスク総量が把握しやすい。追加、変更による積み上げがすぐわかる。
②ベロシティを管理しているため、ペースを把握しやすい。
タイムボックス、スプリント、イテレーション、呼び方は何でも
良いが、期間を区切って使うと便利です。長くてせいぜい1ヶ月くらいです。
■P86 SWEBOKから一つだけ抜粋
あと、SWEBOKから紹介したい小ネタ。

■P87 「瑕疵」
瑕疵についてですが、瑕疵って一言いっても4種類あります。
よく計画たてたり、契約するときに、どっからどこまでが瑕疵なのか
という話になります。
■P88 1.エラー 2.フォールト ~
上から順に。
1.エラー (error):"計算された結果と正しい結果との間に存在する差異"
2.フォールト (foult):"コンピュータプログラムにおける不正なステッ
 プ、プロセス、またはデータ定義"
3.故障 (failure):"フォールトが及ぼす[不正な]結果"
4.間違い (mistake):"不正な結果をもたらす人のアクション"

それぞれの意味を補足すると、まずわかりやすい「4.間違い」について
ですが、これはユーザーの操作ミスによって引き起こされる欠陥
(現象といった方が適切だと思うが)であり、運用上の問題です。
「2.フォールト」「3.故障」は場合によってはテスト中、検収中に
発見するのは難しいかもしれません。
プログラムレベルの欠陥が紛れ込んで発生するのが希少な場合は実際に
使ってみるまで発覚しなかったります。
複数の欠陥が偶然重なり合って呼び起こされる場合もあるでしょうし、
ハードウェアの性能向上がもたらす欠陥もあったりします。
個人的には、想定された使用方法の中でおきたフォールトと故障に関して
は瑕疵扱いでかまわないと思います。
「仕様通りに動かない」のであれば「エラー」も瑕疵に含まれるでしょう
が、これはちょっと考えてほしい。
つまり「"計算された結果と正しい結果との間に存在する差異"」はテスト
と検収で十分、発見できるはずであるし、できないのであればその方法に
問題があると言えます。
言い換えれば検収自体がエラーでし、そういった計画を立てたこと自体が
問題です。
一応、検証責任は利用者、発注者側にあるので、お客さまにご迷惑を
かけないように現実的な計画立案を心掛けましょう。
■P89 そろそろまとめ
結構良い時間なはずなので、まとめます。
■P90 プロジェクトは人が為すこと
知識とかモノ的な話を中心にしてきましたが、言ってもプロジェクトを
やっているのは人間です。
■P91 知識も大事だけど、相手の気持ちを推し量ることも大事
知識も大事だけど、相手の気持ちを推し量ることも大事です。
そこで関わる人、メンバーとお客さまに対してどういったスタンスで
望むのが良いか、私なりにお伝えします。

■P92 メンバーに対するプロジェクトマネジメント
まずメンバーに対してですが、

■P93 正しい管理の四つの本質
「正しい管理の四つの本質
 1.適切な人材を雇用する。
 2.その人材を適所にあてはめる。
 3.人びとの士気を保つ。
 4.チームの結束を強め、維持する。
 (それ以外のことは全部管理ごっこ)

 「デッドライン―ソフト開発を成功に導く101の法則」
 トム デマルコ (著), 伊豆原 弓 (翻訳) 日経BP社」
MS-Projectできれいな予実線を引いて、それをメンテナンスすることは
プロジェクトマネジメントではありません。
参加しているメンバー全員で協調的な仕事ができるよう歩み寄りましょう。

■P94 って
って
■P95 (ジャック・スパロウ)
こんなPMの人も言ってましたよね。
■P96 お客さまに対するプロジェクトマネジメント
次にお客さまに対してですが、私なりに腑に落ちた話を紹介します。

■P97 “AgileConference2009”
“AgileConference2009”というイベントで聞いた話が元ネタで、
想い出補正が付いてます。
これはQ&Aコーナーで挙手した人が、スピーカーに、たしかThoughtWorks社
のコンサルタント氏に質問をしていました。
■P98 質問者
「アジャイル型の開発プロセスを導入したいが、日本では請負契約で
 ウォーターフォール型の開発が主流となっている。どうすれば良いか?」
これ、実は私も手を挙げようかと思って、ビビって上げなかったんですが
同じようなことを思っていた人がいたんですね。
会場中、よくぞ聞いてくれた、みたいな雰囲気。

■P99 回答者
その質問に対する回答はこの後です。
■P100
そういう問題は私たちも経験している。契約書はテンプレート化されて
おり、現場と接点の薄い調達部門で処理される。よって変えられない。

■P101
しかし、私たちが柔軟な開発を望むように、顧客だって柔軟な対応を
望んでいるのではないか?

■P102
そこで(アジャイルにある)、ショートサイクルリリースを行い、
少しずつ顧客の信頼を得ていくことを心掛けている。
実はこの日、このコンサルタント氏の話って、アジャイルに関して
興味を持って勉強をしている人にはごくごく当たり前の話だったん
ですね。
なんで今更こんな話してんの? みたいな。
でも、この質問の回答を聞いて腑に落ちました。
つまり「信頼の獲得」には当たり前のことをしっかりやりきること
が大事ですねと。
つまり

■P103 信頼関係の構築
信頼関係の構築。これにつきるよな。と。
しかし、ただやればいいってもんじゃありません。
信頼を得るために何でも言われたとおりに実装すればいい、
とかそういうことではないです。
これも良い言葉があって紹介します。

■P104 1対1もオフェンスの選択肢の~
「1対1もオフェンスの選択肢の
 一つにすぎねぇ
 それが わからねぇうちは
 おめーには負ける気がしねえ」

お客さまの抱える課題を本質的に改善するためには、言われたとおりに
実装するだけじゃなくて、プロジェクトの予算や技術的な実現性も含めて
より良い選択をしていく必要があります。
そうしていくのがプロの開発者であるし、そうしていくためには

■P105 「顧客要求の本質」を掴むことが大事!
「顧客要求の本質」を掴むことが大事になってきます。
つまり顧客をもっと理解しろ、ということですね。

しかし、顧客を理解するのは簡単ではありません。
先ほどの○○BOKでも顧客要求に関連する知識体系はBABOK、SABOK、REBOK
と3種類もありました。
かなり奥深いし、業務を理解しているSEが長生きできるのもそういう
ためです。
しかし日本にはBOK系よりも前から実践されていた優れた手法があります。
それが

■P106 (白本)
要求開発であり、つまり
■P107 次回 「要求開発」編
次回は「要求開発」編になるというわけで

■P108 乞うご期待
乞うご期待、と言い切ったところで、

■P109 完
今日はおしまいです。
■P110 (thankyou mario)
ご静聴いただきありがとうございました。