「夏のロケット」と「なつのロケット」

　まなめはうすでベタ誉めだったので読んでみた。これがスマッシュヒットだった。面白いよーと一気に読める「夏のロケット」（川端 裕人）は、最後までハラハラさせられ通しだった。

　高校の同級生が集まって、ロケットを作って宇宙まで飛ばしてしまおうとする「青春小説」なのだが、そこへ至るまでのウヨキョクセツとトラブルの数々がすごく良く書けている。ネタバレになるが、ラストのロケットの打ち上げに成功するシーンまで読んだなら、きっと感動するはず。いつのまにやら登場人物の誰かに感情移入している自分に気が付いて。読者をここまで連れてくる筆力はスゴいと思う。

　ただ、ロケット工学の考証に濃淡があり、綿密に検証して書いているトコもあれば、科学的根拠をスルーして強引にお話を進めているなぁ、と思ったトコもあった。やるならトコトン勉強して緻密に書いてほしかった。

　この小説に出てくるのが「火星年代記」で、劇中劇ならぬ小説中小説の気分を味わえる。なんたって、この短編集の第1話は「ロケットの夏」という題名なのだから。わずか2ページにも満たない話だが、ローンチされるときのワクワク感、噴射がひきおこすひと時の"夏"、そして彼の地（未来）への不安が描かれている。余談だが、最終話「百万年ピクニック」が一番好き。淡々+衝撃的なラストシーンは味わっておかないと。

　「夏のロケット」に触発されたマンガが「なつのロケット」（あさりよしとお）で、これまた面白い。「夏の…」がリーマンだとしたら、こっちは小学生がロケットを作る話。ロケットを飛ばす理由はずいぶん違うが、情熱は一緒。ラストの日暮れ時、「成功していたら衛星は今どこを飛んでる!?」「この辺を飛んでたら見えるかも…」の次の一コマ「今、真上…」は鮮やかな感動。そう、宇宙はいつだって「今、真上」にあるもの。

　特筆すべきは「なつのロケット」に出てくるセンセイ（女）が、「メガネ」「ジャージ」「三つ編み」と3属性を全て備えていること。作者があさりよしとお先生だもの。お約束なのかもしれませんな。しかし、最重要な「ドジっ娘」要素が欠けているため、萌えキャラとなりえないことを予め断っておく。

　「なつのロケット」で小学生にでも飛ばせるなら、私だって…！と思うなら、なつのロケットは本当に飛ぶか！？をどうぞ。ロケット工学からの観点で「飛ぶため」の考証がなされている。わたしのような横着者は計算式は飛ばしていきなり実物の図面をひきたくなる（なんせ設計図まで公開されてるし…）。ロケットの先端に爆発物を取り付けたら立派なミサイルになるのだから、こうした情報はそのうち規制対象となるかもしれないねっ。

　最後に。シロートがロケット飛ばす話ならプラネテスPHASE.4「ロケットのある風景」とか「オネアミスの翼」を思い出す。打ち上げるとき、プラネテスは冬でオネアミスは春だったはずだが、記憶の彼方の光景ではもくもくとわきあがるロケット雲がどうしても入道雲とだぶってしまう。

夏にはロケットがよく似合う。

「東大で教えた社会人学」と「東大で学んだ卒業論文の書き方」

　「東大で教えた社会人学―人生の設計篇」は、購入前に立ち読みするべし。さもないと「常識」を買わされたと憤慨するかもしれない。

　なぜなら、社会・会社での暗黙知をまとめてあるから。会社での泳法、所得控除、借金・ローンの方法など、フツーの人なら会社でイヤでも身につけていくものが、講義になっている不思議。確かに、学生時代から知っているのと知らないのとでは、大きな違いが生ずるかもしれない。例えば会社選び。就職ジャーナルや会社案内からでなく、四季報を読め！というアイディアは面白い。

　しかし、端々にただよう典型的な東大臭のこうばしさにはいただけない。選民としての自尊心からなのか、ステレオタイプなラベルを張って「だから○○はダメなんだ」→「だからキミたち（選ばれし者）は○○するべきなんだ」と展開される。例えば「文系・理系」「特急・鈍行」ラベルが未だ現役なのには驚かされる。東大臭とは加齢臭なのかもしれない。

　この講座を企画した畑村洋太郎氏は「失敗学」というとてもユニークな考え方を提唱している。その成果として、失敗事例を分析→データベース化している（失敗知識データベース）。彼が 「失敗した東大卒（理系）」を目の当たりにしてこの講義・本を思い立ったのかと想像したらちょっと笑えた。臭いさえ気にしなければ学生さんにとても役立つかと。

　この本のレビューを漁っていて、すばらしいサイトを見つけたのでご紹介。中田　亨氏の東大で学んだ卒業論文の書き方はとても役立つ。学生のみならず、仕事でレポートを書くときも使える。HowTo本は巷に数多にあれど、買う前にまずここを一読してみてはいかが。類書の大半は駆逐されるぞ。いくつか引用するので惹かれたら全文読むことを強くオススメする。もちろん「あとで読む」でも。

• 題名：説明的なタイトルを付ける。例えば「人体計測装置の研究」では舌足らずであり、「赤外線平行投影法を用いた人体計測装置」とか、「海中でも使用可能な人体計測装置」などがよい
  
• 要約：この研究が新聞記事になったなら・・・と、イメージしてまとめる
  
• 結論：「要するに～～～だった」を書き、結論表を掲げる
  
• 参考文献：足りないなと思う場合は、大型書店に行き、専門書の本棚を眺めてみることである。東京なら、八重洲ブックセンター（東京駅八重洲口）、神保町の書泉グランデ、池袋のジュンク堂、渋谷のブックファースト、渋谷の大盛堂、神保町の三省堂などである。必ず関連する本が見つかるはず
  
• 謝辞：すぐ書く！実は非常によく読まれる部分
  

　「いい論文とは何か?」「ダメな論文を書く14の方法」や、推敲のやり方など、論文を書く上で必要十分な情報がまとめられている。小話「卒論の代書屋さん」は笑った。真実だから。「研究の心得」「研究と不正行為」は2回読んだ。凝るな。凝ったアイデアより素朴なアイデア。問題に突き当たったら、直接的で露骨な力技に走るよりも、問題の前提を洗い直す。問題を分解する。「ＡもＢも行うもの」は得難いが、バラバラにできるなら簡単になる。いっそＡなしでＢは出来ないか。思考の惰性を無くすという箇所は何度も読むことになるだろう。

　末尾にブックガイドがあるがこれも良さげ。既読した本から察するに、良本が紹介されていることがわかる。わたしが知らないスゴ本がありそうな予感。

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

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

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

Foresight7月号「スピードとパワーの源泉『情報共有』という組織原理」より

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

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

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

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

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

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

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

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

ネタバレあり。「ナラタージュ」は特に女性（あたりまえか）に絶賛されているらしいが、退屈だった。濡れ場でﾊｧﾊｧしたことは秘密だ。ｾｯｸﾙって女性が書くとｴﾛいっす。レディコミが青年誌を凌駕していることと同じ。

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

（amazon出版社からの紹介）

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

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

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

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

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

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

Wikiでプロジェクトマネジメントする4つの方法

「ブログでプロジェクトマネジメントする10の方法」への反応を見ていると、独り考え込むのでなくUPしてみるものだな、と思った。実務に適用している例や、Wikiでの試みがあることを知った。言及していただいた皆様、ありがとうございます。賛否ともども大変参考になり、中の人は感謝多謝することしきり。

　　Wikiを発展させた開発支援コラボレーションツールMrkrgnao（via:marsのメモ）

　　Wikiを使った「Web向けLotus Notes」Jotspot（via:関心空間ラボ）

　　社内限定の非公開型ブログイントラブログ

さらに、「Wiki との優位性が見えない」「ストレージサービスでええやん」というコメントがあったが、そのとおりだと思う。実際、前のプロジェクトでは Wiki+CVSで「設計書+コード管理」してたし。時系列に情報を積み重ねるのがブログなら、Wikiは樹構造的な展開に向いている。各人のPCのディスクを圧迫している共有情報を吸い上げる装置がブログなら、ストレージは一定のまとまった情報（RFPや設計書）を最初から一括して保管しておくのに良いかと。

ま、大切なのは道具ではなくいかに使うか（使えるように仕向けるか）なんだろうが、ここではWikiでマネジメントする方法をご紹介。例によってネタ元はFour ways to use wikis for project managementであることは秘密だ。このブログはPMにオススメなのだが、中の人の自己紹介"Hire Us!"（雇ってください）を見るたびに「さきっちょの就職日記」を思い出してﾆﾔﾘ

1.有機的なアジェンダ

事務局はアジェンダ（会議事項）の一覧までは作成するだろうが、個々の詳細はプレゼンする担当しか把握していないはず。どうするかというと、アジェンダ一覧をステークホルダー全員に送りつけて、「関連する担当は当日までに資料を作成しておいてください」と依頼するわけだ。

当然、会議当日まで、資料がどんな内容なのか「題名」以外は知る由もなし。よしんば事前配布だとしても、Excelやらのデカいファイルが「全員に」メールされるのだ（訂正される場合も、全員に同報される）。同じ資料が幾度も同報されるのを見ていると、全員のinboxを破裂させたいのかとウンザリ。

これをWikiで解決するなら、アジェンダのURLで周知。資料作成の担当はファイルをUPすればヨロシ。更新のたびに同報されるのはテキスト文のみ。事前に目を通しておきたいならご自由に。「更新が許されるのは会議前日まで」なら、その日に事務局がロックすればOK。

2.リアルタイム議事録

良いプロジェクトの条件として「会議は少なく短く」があるが、プロジェクトマネージャにとって必要不可欠なもの。「誰が何を発言し」「何がどう決まり」「次にどうするか」は会議が終わった直後に即座に共有したい情報だ…が、現実は議事録をシコシコ書いて→一斉同報→「ここが間違ってる（抜けてる）ぞｺﾞﾙｱ！」とお叱りを受けて訂正→一斉同報を全員が飽きるまで繰り返す。

これは、1.のアジェンダに対し、それぞれの議題に対し議事録を書き込めるようにすれば解決する。議事録を受け持った人がドラフトを書いて、あとは出席者が好きに訂正すればよい。訂正内容は即座に全員の目に触れるため、「言った／言わない」も少なくなろうかと（願いたい）。Wikiの履歴を使えば、誰がどのように直したのかも追える。1.2.は少人数だとありがたみが薄いかもしれないが、デカい会議だとラクできる。

3.ブレーンストーミングツールとして

複数人でブレーンストーミングする際のプレゼンテーションツールとして使える。ネタ元は簡単にできるような口調で書いている…私はWikiの実力が分かっていないので、どれぐらい難しいのか（あるいは簡単なのか）は不明。そのまま紹介すると↓

共同でプレゼンの準備をするのは大変だ。特に複数で一つのコンテンツを同時にいじくろうとするとき、バージョン管理がやっかいとなる。

このとき、パワーポイントの代わりにWikiでやってみてはどうだろうか。Wikiなら追加も変更も簡単にできる。パワーポイント形式にエクスポートできるWikiのプラグインがある。レイアウトテンプレートを適用し、クリップアートを追加すればプレゼン準備は完了だ。

さらにパワーポイントを離れ、Wikiページそのものをプレゼンテーションにつかえないだろうか。その優れたページフォーマット機能を使えば、ブラウザからそのままプレゼンすることができる。

ステイツの方のプレゼンテーションを見る限り、確かに彼らのスライドは「メッセージ+黒い人の画像」が圧倒的（コンサルタント会社が作る美麗なやつは例外）。ネタ元の中の人はイギリスの方だが似たようなものだろう。だから↑のような使い方が可能。しかし、日本だと表やらグラフやらマンガ（しかもオリジナルなやつ）が一枚のスライドに盛りだくさんなので、向いていないカモ。

ブログと異なり、Wikiは「あとで直す」「誰かが直す」ことを想定しているため、時空間が隔たったメンバー同士のたたき台（というかたたき場所）として有効。アイディアを出し合う「しゃべり場」だね。具体的にはデルファイ法でスコープ、見積もり、リスクリストの洗い出しをするときに使える。

4.常に最新のドキュメントにする

共有ドライブにドキュメントを保存するのではなく、Wikiで管理する。バージョン管理機能を使えば定型的な変更管理はラクになる…が、ちゃん「お守り」をする人を充てておかないと風化する恐れが。なまじ簡単にはじめられるので、忘れ去られるのも簡単になる可能性が。Wiki によるマネジメントの成功パターンは、

• プロジェクトマネージャが使う（絶対条件）
  
• 入口はFrontpage限定（ただし全業務いきなり移すのはムリがある。まず進捗会議や仕様変更管理に限定する）
  
• 「お守り役」が必要（全体責任は無責任）
  
• 「共有情報を載せる」のであり「情報を載せて共有しようとする」のでない（via:swat_memo）
  

渦は自分で起こせ。まずはスモールスタートで。

ブログでプロジェクトマネジメントする10の方法

マーケティングツールとしてのブログが流行らしいが、開発現場のマネジメントとしてブログを使えないかという提案。イントラネットに閉じたローカルブログ導入のヒントとして自分メモでもある。

1.ステークホルダーのコミュニケーションツールとして

進捗報告やマイルストーン毎のレポートなど、プロジェクトでやりとりする情報はかなりのものだが、それらを全て一斉同報メールで送るのは大変かも～というのであれば、ブログが有効かと。

日報、週報、月報のような定期レポートだけでなく、随時更新されるリスクマネジメントリストや、毎時参照されるトラブルレポートも対象となる。更新するタイミングでステークホルダーにお知らせメールを送るのも簡単だし、RSSリーダで読むようにすれば、それすらも要らぬ。その際、以下のルール決めをして浸透させておく必要がある。

• どのタイミングで
  
• 誰の責任において
  
• どのような情報が
  
• 公開されるのか（公開してもいいのか）
  

2.紙媒体の代わりに

定型書式を定めても、「その帳票の見た目が定型」であって、元のテンプレートとはかけ離れたレポートに出会ったことがある。極端な例は「一文字一セルのExcel報告書」で、定型書式が原稿用紙のようなマス目を埋める形式あったため、利便性を一切考えないトンデモ書式がまかり通っている。

それは極端だとしても、テンプレートや格納場所を系列化する作業を、作り手からシステムで受け持つことができるブログは、見えにくいトコロの効率化を図ることができる。

　　　　　　　a) メールでExcel形式の報告書を提出
　　　　　　　b) 受信者が紙に出してファイリング
　　　　　　　c) その紙を見ながら勤怠管理システムへ手入力

…ってしてない? a,b,cさんが別人だから視えにくいけれど、トータルで視るとかなりの労力をブログというテンプレートで巻き取ることができる。

3.議論の自動ログ化ツール

プロジェクトでおきる議論（問題・課題などのイシュー）は、通常、メーリングリスト、報告書での言及、それに特化した報告書など、バラバラな形で提示される。話題に対し、いわゆる「まとめ報告書」などを作ればよいのだが、よほど大きなものでない限り書かない。

これはトラックバックを使うことによってトレーサビリティが格段に向上する。議論の流れや話者により断ち切られること無く「結論→元の話題」や関連する話題を参照することが容易になる。また、コメント機能により結論や次のステップをオーソライズすることができる（曰く、○○マネジャーがOKとコメントしたから）。普及したら「過去ログを嫁」が一般化するかもしれない(w

4.情報の断片をつなげ合わせる

そのプロジェクト固有の「暗黙知」といった情報（共通パスワード、業務用語一覧、コードのお約束 etc）は、訊いてはじめて出てくるものでなかなか「まとめ」の形で存在しないのが普通。これらを掲示してもらうことで情報を共有することができる。皆の断片を持ち寄ってナレッジベースを作ることは、 Wiki の方が有効かも。ナレッジはテキストに限定されないため、googleデスクトップ検索と組み合わせるとさらに強力になるかと。

5.プロジェクト進捗をガラス張りにする

プロジェクトマネジャーにとって有効なのだが、「このプロジェクトに関するあらゆる情報がこのブログにある」というルールが守られている限り、「便りがないのは良い便り」といえる。問題があるなら新着情報が new ! であふれているだろう。

これを守ってもらうためには「良いことも悪いことも上げる」ことを徹底させる。システム開発に限らず、悪いニュースを知らせる人を悪者にする風潮があるため、問題はなかなか表面化しにくい。プロジェクトマネジャーかシニアマネジャーが最初にキッパリと言い切ること「悪いニュースを知らせてくれる人を重視します」

6.メールの呪縛を解く

仕事にメールは不可欠なのだが、「そのメール」は本当に不可欠かというとそうでもない。ミソもクソも一緒くたに inbox に入ってくる。アドレス振分けもできるが「話題」「重要度」で振り分けることはできない。開けて から分かるのだから。おまけに長いccリストを見ると、ブログに投稿すればずっと楽になるのに、と思わないでいられようか。

メールを読むという作業の大部分を占めているのは「重要度」「緊急度」「話題」を順位付けすることだろう。ここでいう「話題」とは、自分の作業との関連性ととらえてほしい。inboxの新しい順に頭から添付ファイルまでじっくり読んでいる人はまずいないだろう。ブログを巨大な inbox と考えて、話題は全部そこで共有し、題名やサマリで重要度や緊急度を判断する。取るべきアクションがあり、かつ指示する「人」が明確になって、初めてメールを送るようにするのだ。

7.要望を吸い上げる

ネタ元の"10 waysto use blogs for managing projects"には、顧客要望を集め、ディスカッションする場としてのブログが提案されている。はてなが典型だが、プロジェクトに閉じたブログで考えるならば「改善要望をディスカッションする」アイディアが浮かぶ。通常は発言者を明確化して投稿・コメントするルールだが、例外としてanonymous （名無しさん）を設ける。そこでプロジェクトの運営の仕方やルールの改善要求を上げてもらうということができる（これがメールだと非常にやりにくいし、掲示板だと一行コメント一行レスで終わりがち）

8.画像や文書ファイルとの連携

メールを「仕事用データベース」として使っていないだろうか? 添付ファイルが主でメール本文をプロパティのようにして、全てのデジタル情報をメーラーで管理。さらにメーラーの検索機能を使うことで、ToDoブラウザのように使っている人はいないだろうか?

しかし、同一プロジェクト内で全員が同じ情報を同じように「添付ファイルを保存」しているのなら、ディスクのムダ使いというもの。個々人はそうした意識が無くても、プロジェクトチーム全体からすると、同じ情報をそれぞれのPCで保存・管理していることは結構なムダになるかと。ブログなら記事＋参照先で共通化できる。PCを使って仕事をする人は、自分のPCのディスクの面倒見はいいくせに、全体としてムダがないかという視点が欠けていると指摘されたことがある。

9.プロジェクトの情報を最新に保つ

「このブログにはプロジェクトに関する情報の全部がある」「Frontpage には全ての最新情報が一覧化されている」とすれば、ステークホルダーは必ずチェックするようになる。また、全ての記事には投稿者が記名されているため、その情報を常に最新に保つように動機付けられる。

10.追跡調査に役立つ

問題が予め問題の姿をとって現れればよいが、必ずしもそうではない。最初はよくある話題（見解の相違、情報の行き違い）だったのが大きな問題となってたち現れてきたとき、その初期症状までたどることができる。さらに、「不具合発生→原因解析→対策実施→解消確認」の4ステップは、一つのトラブルで括りつけられているが、実はそれぞれのステップで「他にはないか?」という視線が抜けている場合が多い。それぞれのステップで過去ログを検索し、関連するものはトラックバックを打つことでより有機的な関連づけを行うことができる

最後に。もちろんここに書いたのは元記事に触発されたアイディアであり、ネタや願望がかなり混じっていることを白状しておく。また、「それってそんなに昔でない以前に流行したグループウェア（死語）じゃねーか！」というツッコミは予め自分で入れておく。

--
ネタ元
10 ways to use blogs for managing projects

関連
using wikis inproject management
「ブログでビジネス」失敗と教訓

マッキンゼーITの本質

ここしばらく開発現場を離れ、「こんさるたんと」のお手伝いをしている。そこでマッキンゼーの中の人と仕事をしているのだが、奴らはスゴいの一言に尽きる。激務という言葉はまさに奴らのためにある。

たしかに、私も佳境に入ると夜討ち朝駆け徹夜仕事になる。システム屋は盆と正月こそ稼ぎ時だ（悲しいけどこれ現実）。しかし、奴らの場合はそれがデフォルトで、言葉どおり休みがない。「オレも休みなんてずいぶんもらっていないよ」と言いたい人は沢山いるだろうが、もう何年も一日たりとて休んだことないよという人はいないだろ。でも奴らはそれが普通。24時間戦えますか?（死語） もちろん、という連中。

だから奴らは、通勤時間を惜しんで六本木や新宿にマンションを買っている（←激務に見合うだけ給料もハンパじゃないといっておく）。まぁマッキンゼーですら一つのステップで、激務の見返りにノウハウやパイプを吸えるだけ取って独立するつもりで身を粉にしているわけだし。

じゃぁその論文「マッキンゼーITの本質」もスゴいのかというと、そうでもない。とっぴなことは一切書いていない。膨大なデータを元に「仮説→検証→仮説→検証」の議論を反復した結果がこの本。サブタイトルの情報システムを活かした「業務改革」で利益を創出するうたい文句に偽りはないが、実行するには経営者の鉄の意思を要する。まさにマッキンゼーのやり方。

ITへの投資とリターンについて悩むエライ人が読むと、ああやっぱりな～と身につまされること請け合い。社畜が読んでもタメになるのは第1章。ITによる課題解決が何故うまくいかないのかと、その処方箋がまとめてある。自分のプログラムは完璧なのに、業務システムのレベルになるとどうして上手く実装されないかがよく分かる。

■IT課題解決を阻む5つの理由

1.ITの企画・推進に関するアカウンタビリティがない

CIOが具体的に何をする人で、何に対する責任を有するのかを明確化しないまま、CIOに命ぜられている。ぼんやりと「社内のITシステム全般について責任を有する役員」というあいまいなミッション定義のまま、IT便利屋の窓口になっている。

IT投資の企画における目標設定は誰が行うのか?　要件定義やプロジェクト管理はどの部門がどのように行うのか?　業務改革を含めた新システムの現場への定着はどの部門がどのような責任と権限で推進するのか? こうしたアカウンタビリティが存在しない。

2.目標がQCD（quality/cost/delivery）の面から定められていない

ITで業務を変えようとする際、最終的にどう変えたいのかが明確になっていないまま「システム改善」が着手されている。顧客満足度などの業務アウトプットの品質（quality）なのか、労働総量・残業代や不良在庫削減などのコストカット（cost）なのか、業務処理の時間短縮や顧客リクエストの迅速対応（delivery）なのかぼやけている。

いつまでに何を達成しなければならないのかが曖昧なままだと、それを「どう」達成するのか（=システムに何を求めるのか）は絶対に明らかにならない。

3.外来語をわからないまま受け入れる

オープン化、ERP、CRM、EA、SOAなど、何かいいことがありそうだが具体的に突き詰めてみるとよく分からないまま意思決定をしてしまう。その結果、ふたをあけてみれば「そんなつもりじゃなかった」という台詞が双方から聞かされることになる。

ITベンダーが提案するソリューションは、経営・業務の観点からするとただのツールでしかない。何のためにどのような道具が最も有効か、議論をつくす必要がある。

4.ベンダーとの協働がうまくできない

法律なら法律事務所、会計なら会計士事務所があるが、ITには背景に法・規制を伴ったルールが存在しない。さらにITエキスパートは開発業務を請け負うベンダーであることが多い。その結果、エキスパートといいながら仕事を請け負う立場としての遠慮から、顧客企業の指示や要望に従う下請けになりがち。

5.システムの完成が目的化し、成果や構築プロセスがなおざり

システム開発にまい進しているうちに、予定通りのカットオーバーが目的となってしまい、完成したシステムが実際に役立っているかを確認・検証する機会が忘れ去られている。ユーザ企業のIT投資・推進におけるPDCAサイクルが絶たれている。

■6つの処方箋

1.ITコストの可視化

自社がどれぐらいの資産を有し、どこにいくらのコストがかかっているかを可視化する。いわばITバランスシートを作成することで、どこに優先順位がつけるべきについて、現場担当レベルではなく、経営者が判断できるようになる。ITバランスシートは開発費、運用費だけでなく、ライセンスコストや稼働率も考慮して作る。

2.CIOをコアにした議論の場

システム単体を取り上げて事業への貢献を議論することは無意味。システムも含めた業務改善が事業にどれだけ貢献したかについて考えるべき。

3.PMOによるチェック

狭量になりがちな情報システム担当ではなく、PMOに第三者的なチェック視座を設けることで、システムの企画段階からIT投資・運用の効率性を経営者がチェックすることができる。

4.ユーザ部門のノウハウ集積

ファーストリテイリング（ユニクロ）の例。情報システム部ではなく、業務システム部を設け、主業務のプロセス担当者を置き、その担当者が業務改善を企画し、一環としてITの企画・導入・運用を行っている。

5.事業の本質に根ざしたIT戦略

全体最適されたIT投資を行うため、その目的・コンセプトを明確化する。次に、事業の生産性・収益性を向上する最大のレバー（梃子）は何か、その向上のために業務を、組織を、どう変えるべきかについて検証する。

6.ベンダーとのwin-win

仕様確定などベンダーとの共同作業を重視する。そこまで議論してきた業務フローなどの本質を理解できないままなら、いくら要件定義を緻密におこなっても似て非なる代物になるだけ。すべてをさらけだすつもりでベンダーを取り込むことで、システム改善の「肝」を腑に落ちてもらう。

なんてあたりまえな…という印象をもたれたかと思う。アタリマエなことがあたりまえにできていないことが問題なのだが、翻って私はどうかと。経営者の視点ではなくとも、分析の基本であるMECEやロジックツリーをやっているか? 否とよ。そこいらのHowTo本で分かった気になって、ちょっと使って上手くいかないとすぐに「MECEは現場離れしていて使えない」と断定。恥ずかしい限りだ。

一方、マッキンゼーの中の人は本当に使う。定石どおりに使うというよりもむしろ徹底的に使う。徹底的に使うとは、人が1時間考えるなら10時間考えてきている。だからプレゼン中に思いついただけの反論にもびくともしない。反論への反駁も準備万端（つまり客を不快にさせないように反駁するところまで考え抜いている）。

最後にネタばらし。マッキンゼーの中の人とはいっても、コンサルタントやプリンシパルだけがスゴいのではない。奴らの後ろにデータ解析屋がいて、パワーポイントの猛者がいる。彼らがスゴいのだ。莫大なデータをひたすらピボットテーブルしまくって傾向→対策を洗う解析屋。出てきたアウトプットを見栄えのいいストーリーに仕立て上げるパワーポイントマスター。彼らのおかげでコンサルタントはひたすらコンサルタントができる。マッキンゼーのプレゼン術なるHowTo本が書店にあるが、奴らのパワーポイントファイルを読んでみるだけでいい。そのスゴさ（あたりまえのことを徹底的に積み重ねること）が良く分かる。

SWEBOKを選ぶ理由

この業界でメシを食べさせてもらって幾年月、いわゆる下を育てる立場になった。そこで、ソフトウェア開発にあたる素養というか基礎的な考え方を養うテクストを探しているのだが、なかなか見あたらない。

書店にはいわゆるHowToや資格対策本が溢れているが、いらない。新人さんが何語を知っていようとも（あるいは知らなくとも）無問題。言語は重要だが後で「実践で」身につけてもらえばよし。むしろ、考え方の枠組みや基礎的な用語とそれを支える思想など、これから一緒に仕事をする上で最低限必要な勉強をしてもらうために、何を渡せばいのか?

　　　SWEBOKをきちんと読んでみようという動機は、ここにある[注1]。

ふりかえって、自分がどのように学んできたかを思い出すと、「盗んだ」のがほとんど。当時はまとめ本なんてなかった。合間をぬって質問したり、ソースをもって帰ったり（今は厳禁）、関係ないレビューの「議事録役」を買って出たりして積み重ねてきた。

その結果、知識としてモレヌケがあったり、俺流な書き方になっている。また、実践的でないもの、すぐに役に立ちそうでないものを見下したりしていた。いわゆるアカデミックなものや教条主義的なやつだ（たとえばSWEBOKのような！）。体系だった勉強をせず、「いますぐ」「使える」「便利」をキーワードとして刹那的な知識を追い求めた結果がこれだ。

　　　SWEBOKをきちんと読んでみようという動機は、ここに「も」ある。

たとえばテストの種類を挙げてみる。よく使うのは受入れ検査や性能試験なのだが、SWEBOKではこれだけ紹介されている。ちなみに単体テストや統合テストは、テストの"レベル"なので、"種類"とは別に紹介されている。

• 受入れテスト（受入れ検査）
• インストールテスト
• アルファ/ベータ版テスト
• 適合テスト/機能テスト/精度検査
• 信頼度検査
• 回帰テスト
• パフォーマンステスト（性能試験）
• ストレステスト
• Back-to-back テスト（同一製品の前バージョンと同じ結果が得られること）
• リカバリーテスト
• コンフィギュレーションテスト
• ユーザビリティテスト
• テスト駆動開発によるテスト

（SWEBOK2004 Objectives of Testing より翻訳）

こうやって書き出すとあるある知ってる～なのだが、テストプランを立てるときに、いくつかは一顧だにしなかった。受入れ検査に含めればいいや、と楽をしようとしたからだ。その結果、必要な観点が抜けたまま実行フェーズに至り、「あれも必要、これも抜けてる」とテストケースを追加するハメになったものだ（んで、テスト期間がズルズル延びたり、徹夜テスト、リリース「後」のこっそり追いかけテストになったりする）。

アカデミズム・権威主義を嫌い、実践ありきのつもりが、結局SWEBOKに戻ってくるという皮肉。ガルシア・マルケス「百年の孤独」に、二次方程式の解法を独力で編み出した男のエピソードが出てくるが、もう嘲笑（わら）えなくなった。perlしか知らないのに「perl以外なんてぶっちゃけありえない」と恥ずかしげもなく言い切る人を、もう嘲笑（わら）えなくなった[注2]。

学而不思則罔
思而不学則殆

--

[注1]　うろうろしてたらakonさんのエントリー[参照]に出会えた。たくさんの気付きをいただき、感謝多謝。SWEBOKを読むと（まだナナメ読みだが）私の基礎にはかなり穴があり、そこにはハッタリで埋めてあることが分かった

[注2]　断っておくが、perlを貶めたいわけではない。perlは素晴らしい言語だが、少し前までは「いろいろな言語をやってきたが、perl がいちばん性に合う」人がほとんど。今じゃ他言語を知らないくせに（知ろうとすらしないくせに）「perl 以外ありえな～い」と言い張る人が出てきた。ハンマーを持つと全てが釘に見える典型だと笑っていたが、私もたいして変わらない

SWEBOKを読む前に

もとはといえば燃えるプロジェクトをなんとかしようという動機で始めたPMBOK。理解に2年、普及に1年かかったが、今その果実(?)を得ているところ。既に上長を巻き込んだので、次は全社に風を起こしてみようかと。ちなみにいまだにPMPは受験していないorz。

その過程で知ってはいたが食指が動かなかったSWEBOK（ソフトウェアエンジニアリング知識体系（Software Engineering Body of Knowledge）について、akonさんが非常に興味深いエントリをしている[参照]。これは「ソフトウェア開発へのSWEBOKの適用」の書籍の紹介なのだが、SWEBOKを理解するのになかなか良いとのこと。2004改訂版が出るまでのウォームアップとして読んでみようかと。

SWEBOKとは何か。その概説（overview）をまとめるとこんなカンジ[SWEBOK overview]。

世の中には、「ソフトウェア専門家」がごまんといる。あるいは「ソフトウェア専門家」を育成する機関がこれまたごまんとある。にもかかわらず、ソフトウェア工学は正当な教育機関や職業のステータスにまで達していない。なぜなら「ソフトウェア専門家=プロフェッショナル」のための一般的な知識をまとめたカリキュラムが存在しないから。

「これだけやればプロフェッショナル」ではなく、「プロと名乗るなら、せめてこれぐらいは知っておけ」という知識体系が求められている。それはソフトウェア工学に限らず、一般的な知識や、知識にとどまらずそれを適用する方法論なども対象とする。

こうした背景をふまえ、SWEBOKは以下の目的でまとめられている。

• ソフトウェア工学の各知識分野を特徴づける
• ソフトウェア工学の今日的な話題を提供する
• ソフトウェア工学での一貫した視座を促進する
• ソフトウェア工学の位置づけを明確化する（コンピュータサイエンス、プロジェクトマネジメント、コンピュータ・エンジニアリング、数学との関係）

SWEBOKは以下の人を対象としている

• ソフトウェア工学の教育機関（大学、専門学校、職能訓練校）
• ソフトウェアの職能・業績評価を行う機関
• ソフトウェア工学の学生
• ソフトウェアエンジニア

SWEBOKプロジェクトのための原則は以下の2つ

• 透明性：SWEBOKプロジェクトそのもののプロセスは、完全にドキュメント化され、公表される
• 一貫性：ソフトウェア工学を実際に用いる開発者や研究者の中でSWEBOKは構築され、各界でのコンセンサスを得ることで一貫性が保たれるようにする

公開されている2004年版[SWEBOK official]をナナメ読みする限り、教条主義的なにおいがして、アカデミックな雰囲気なり。上の翻訳にあたり、"Software engineering"を「ソフトウェア工学」としたが、この「ソフトウェア工学」という言葉はずいぶんとビミョーな語になりつつあるようだが、これまた別の話。