« 2005年6月12日 - 2005年6月18日 | トップページ | 2005年6月26日 - 2005年7月2日 »

はてなでの「情報共有」のやり方

Foresight7月号の「シリコンバレーからの手紙106」は、はてなの情報共有のやり方が紹介されている。前のエントリーで提案していた社内ブログ[参照]がほぼ完璧な形で実施されている。梅田氏によるとこうだ。

私が、はてなで仕事を始めて、まず不思議に思ったのは、彼等が社内で電子メールをあまり使わないことだった。その代わり社員全員が、ビジョンや戦略の議論、新サービスのアイディアから、日常の相談事や業務報告に至るまで、ほぼすべての情報を、社内の誰もが読めるブログに書き込む形で公開し、瞬時に社員全員で共有するのである。
Foresight7月号「スピードとパワーの源泉『情報共有』という組織原理」より

一方、大きな組織だとこうはいかない。組織の情報は隠蔽されていて、権能により開示される。情報を握ったものが組織を生き抜くという原則…と、

情報共有型 はてな vs 情報隠蔽型 大企業

で論が展開されていてめっぽう面白かった。情報共有型の代表としてはGoogleもそうだという。ただ、梅田氏も手放しで誉めちぎっているわけでな。情報共有型組織でやっていくには適正サイズがあることを示唆している。はてなは11名、Googleは3,500名だそうな。

きっと、それはプロジェクトのサイズなのだろう。プロジェクトチームとしての最大数が、情報共有型組織としてやっていける最大数だと考える。わたしのシステム開発の経験では、その最大数は40名。もちろん数百人規模のプロジェクトチームもあるが、それが一丸と同じ役割をやっているわけではない。○○部門とか○○サブといった「別名」「枝名」がついてくる。大きな幹から枝が派生しているカンジ。

40名は、だいたい学校の1クラスの人数。全員が全員にボールを投げて、受け取る側が必要性・重要度を判断して処理する組織は、きっと全員が全員の顔と名前が一致するサイズに収束すると思う。これよりでかくなると、ボールを投げてもそれっきりだったり、返球があっちからもこっちからもたくさんやってきて収拾がつかなくなったりするんじゃぁないかと。もちろんその場合は、「別のクラス」に分けるんだろう。

また、「情報隠蔽」はネガティブな香りただようが、そのおかげで余計なノイズに邪魔されることなく、自分の仕事に専念できるともいえる。会社の情報が全部見えたら面白かろうが、面白すぎて仕事にならんだろう。組織の複雑性はカプセル化され、必要なインタフェースしか見えない仕組みになっている。従って、それぞれクラス(組織)の責務もシンプルに限定させることができる。組織にとってのメソッド(責務)やパラメータ(情報)が多すぎる場合は、「別のクラス」に分けることを考える。

こうして、ゆるやかな疎結合で結ばれた組織が全体として一つの方向に向かうとき、最大のチカラを発揮するんじゃぁないかと…もちろん理想の話で、現実は、超蛸足クラスがデンと中心にいたり、スパゲッティコードならずスパゲッティクラス図のような組織だったりする。

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

「ナラタージュ」より「____の_」の方が良い

ネタバレあり。「ナラタージュ」は特に女性(あたりまえか)に絶賛されているらしいが、退屈だった。濡れ場でハァハァしたことは秘密だ。セックルって女性が書くとエロいっす。レディコミが青年誌を凌駕していることと同じ。

壊れるまでに張りつめた気持ち。そらすこともできない二十歳の恋 大学二年の春、片思いし続けていた葉山先生から電話がかかってくる。泉はときめくと同時に、卒業前に打ち明けられた先生の過去の秘密を思い出す。
(amazon出版社からの紹介)

先生(30代)の一人称が「僕」で、彼氏(20代)の一人称が「俺」であることに注目。一貫して抑制された感情で接しようとする先生と、最初は控えめ→肉体関係が入ると俺様化する彼氏(DVまがいなことまでする)の対比が読みどころ。

同情は愛であることは、既に漱石先生に教えてもらった(三四郎"Pity is akin to love")が、それを微塵も感じとらせないまま最後まで連れてこられた。読み終えた後、最初のこのメッセージを読むと、実はそんな小説だったのだ、ということが分かる仕掛け。

子供だったから愛とは違うとかじゃなくて、子供だったから、愛してるってことに気付かなかったんだよ

一方、展開はみえみえ。誰が自殺するかは最初の伏線で分かった。二人がどうなるかも合点承知。イントロの「彼」が誰で「ない」かも分かった。伏線のショボさに流行の叙述形式かな?とも考えたが、違っていた。

しかし、ラスト1ページを読んだとき、熱くこみ上げてくるこれはなんだ。
肝心の「先生のほんとうの気持ち」が最後に明らかにされる。
そのタイミング、彼女の表情、そして幕。
涙をぬぐって扉を開くと、こうある。

子供だったから愛とは違うとかじゃなくて、子供だったから、愛してるってことに気付かなかったんだよ

日本語は主語を省略できる。ズルいがスゴいと思う。

--

これ系の話なら「センセイの鞄」が一番かと。マンガでも良いなら「五年生」も推す。泣くことはないだろうが。


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

「はじめてのプロジェクトマネジメント」はお買い得

良い本に出合えてうれしいので、報告。枕詞「入門」「やさしい」が付く本はハナから使えねェと思っていたが、「はじめてのプロジェクトマネジメント」は優れた一冊。ただし、下手な小説仕立ての小話がなければもっと良し。

PMの入門書をイチから書くと、どうしても底本(PMBOK)のダイジェストになる。ところが、これは「実用企業小説 プロジェクト・マネジメント」のエッセンス本なので、より実践的なツールが紹介されている。二番煎じという声もあるが、これだけのノウハウが880円なのはコストパフォーマンスが非常に良い。

また、このテの本にありがちなのが、エラそうに一席ぶっている筆者の経験の「狭さ」「浅さ」を垣間見て思わず微苦笑を招くこと。しかし、この著者は本物の(残虐非道プロジェクトを潜り抜けかつ生き残った)人だなぁ、と気の毒に思った。なぜなら彼のいうプロジェクト成功要素の一つに、「犠牲者を一人も出さないプロジェクト」が掲げられているから。また、反面教師の台詞「プロジェクトとはタコ壷であり骨壷でもある」は、けだし名言。文字通りお亡くなりになった方がいたんだろうなぁと忖度→黙祷したくなる。

特に使ってみたい方法はPRP。PRPとは Project Re-Plannning の略で、「プロジェクト再計画」のこと。即ち、プロジェクト開始前の制約条件に基づいて、プロジェクト計画をメンバー自身の手で組み立てることを指す。

一般に、PMであれメンバーであれ、プロジェクトに参加するときには、プロジェクト計画は「すでに決定されている」こととして与えられる。計画そのものが「前提条件」となるのだ。スケジュールやリソースは与件として与えられ、その変更は認められない。

そんな中、PMやメンバーができる最大限のことは「与えられた条件でいかに成功に近づけるか」であるにもかかわらず、成功/失敗の二択でしか評価されない。これって非道くねぇか? 営業や上層部がともするとテキトーに決めた「計画」が「制約」としてノシ歩き、自分がしたわけでもない「約束」に振り回されるのはもうゴメンという人は、p.68を読むといいかもー

p.68のPRP手法をまとめると、プロジェクト計画は2つ存在することになる。

  1.最初の受注レベルのプロジェクト計画
  2.プロジェクト開始前の制約条件に基づいた再計画(PRP)
  3.プロジェクト完了後の実績

1.営業や上層部が「約束」してくるプロジェクト計画のインプット情報は極めて限定的であるが故、「ざっくり」「エイヤっと」決めた計画[案]で、こいつを後生大事に実行フェーズに移すのは正気の沙汰とは思えない。

2.だからこそ、プロジェクト開始直前/直後で再度プランニングをする。するのはPMとメンバーだ。つまり、そのプロジェクトを推進する人が「これならできる」「これでしかできない」ものを作り上げるのだ。この本では詳細まで触れていないが、具体的にはWBS作成だろう。自分が携わるタスクを洗い出すことで、プロジェクトの全体像の見通しをつけ、メンバー間でスキルや個性を知ることもあるだろう。

3.完了後の実績は確定情報。1.や2.が天気予報ならこれは天気後報。実際にマイルストーンを通過した日や成果物の量・質を洗い出す。

で、「3と1」を比較し、「3と2」を比較するわけだ。
で、「3と1」の結果と、「3と2」の結果を比較するわけだ。

「最初のプロジェクト計画は絶対」「時 間 が な い」「メンバーだけの再計画は、ただのマスターベーションにすぎない」「そもそも1と2乖離しているはず。いつ誰がオーソライズするんだよ?」というツッコミはわたしもした。しかし、これこそPMの仕事。上層部とのネゴシエーションを通じ、1→2に近づける。1の「できない理由」と代案を提示し、改変を迫る。2の甘い部分を絞り込んで、1との親和性を高める。上層部は撥ねつけるかもしれないが、折にふれ粘り強く説得するしかない。
2の作業ポイントは、


  • どのように評価するかといった指標値も織り込んでおく
  • 基準値は目標値ではないため、右肩上がりに設定しない
  • ともすれば易きに流れがちな各人の議論は、最終的にPMの責任で(独断で)決める(「全員で議論→PMが独断」が王道)

成功するべくして成功する、これ最強。非現実的な計画を現実的なものに落とし込む。これこそプロジェクトマネジャーの仕事。他の使える手法をピックアップすると…

■プロジェクトの理念

そのプロジェクトでどうしたいのかを自分の言葉で(できれば下手でも自筆で)書いて貼っておく。多少こっ恥ずかしいが、メッセージを出さないよりも1000倍まし。「このプロジェクトでは一人の犠牲者も出さない」「このプロジェクトの全員に○○を身につけてもらう」など、成果物やマイルストーンに関係ないものが面白いかと

■プロジェクト計画フェーズの決め台詞

[問] リーダーの言っていることは分かりますが「みんなで話し合いながら決めていこう」といわれても前に進めません。「これをこうする」というように具体的に指示していただかないと

[答] あなたが言いたいことは分かるが、プロジェクトマネージャの私が全てを知っているわけじゃないんだ。むしろ、私は今のプロジェクトについてもメンバーの皆についても何も知らないに等しい。だから計画を立てることを通して知っていくしかないんです。これは私だけでなく、皆にも同様だと思う。

■問題解決のための臨時チームを作る

問題発見時の対応方法をルール化しておく(しないと全ての問題を故障処理票で管理することになる)。ポイントは「発見者≠対応者」にすること。期間限定、人数限定、特定された課題だけを解決する。全権を与えられる。若手を据えてとことんまでやらせるといい(ただしバックアップはちゃんと)。んで、解決の暁には「発表の場」を与えてきちんと活躍させる。

■オフサイトミーティング(p.88)

  • 「気楽にまじめな話をする」場
  • 主語は「私」(肩書きや役職でない)
  • 批判なし、人の話を聞く(ブレーンストーミング)
  • 分かり合うための場、メンバー全員の個性や能力を知るための場
  • 酒は入れないこと(その後に飲み会なら可)

■DPM(Decision & Progress Meeting)プロジェクト意思決定会議(p.94)

  • リーダー全員参加、欠席不可(代理可)「聞いていなかった」とは言わせないため
  • 議事は全て即断即決(するのはPM)
  • 議事録はアクション項目を登録、PMのメッセージを記入
  • 方法、計画をオーソライズ、問題解決、方向性の決定、進捗管理、作業項目のフォローアップ
  • 全員で議論、PMが独断

■問題提起を歓迎する(p.103)

  • 問題検出をルール化
  • 問題対策をルール化
  • ともすると故障処理票しか問題提起できない状況を打破するため
  • 問題を内在化させないため。これは特に組織が大きくなるときに効いてくる

■作業者が申告した内容で管理する(P.117)

  • PMが管理したいのは「今全体のどこ」「あとどれぐらいかかる」「それを阻害するのがあるか」「あればそれはどうオミットするのか」
  • 画面数で管理するのはおろか。実装方法(サーブレット、アプレット、HTML、DBアクセスありなし、参照テーブル数、コミットあるなし)で管理
  • 作業の進捗度合い(分子)ではなく、分母に着目。検討するべきことが出てくるのなら分母が変わってくる。だから順調なら分子を、問題を見つけるなら分母の増え具合を見る

すべては成功するべくして成功するために。

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

« 2005年6月12日 - 2005年6月18日 | トップページ | 2005年6月26日 - 2005年7月2日 »