2009年6月17日

Webディレクション標準ガイド

Webディレクション標準ガイド 横浜関内伊勢佐木町のカフェバー 音楽好きが集まる洒落た飲み屋 ウェブ担当がオススメする書籍

ポータルな一冊

  • 企画 制作 スマートイメージ
  • 発行 ワークスコーポレーション

ウェブサイト構築の各フェーズを掘り下げているようで、
漠然とした表現が多く、モヤモヤする・・・
まぁ、全体の流れを把握するには丁度良い書籍。

解説部分の段落分けが半端なので、
途中で途切れて読み難く、さらに誤字脱字が多すぎる。
内容と可読性を考慮すると、この価格は高い。

2005年発売なので、情報としては古いが対象者は下記

  1. 異業種から転職して、ウェブディレクターになる人
  2. 専業性の高い会社でコーダーやデザイナーをやっていて、
    これからディレクター的役割になる人

プロジェクトリーダー、プロジェクトマネージャー、ディレクターが
網羅すべき情報が掲載されている。

漏れや抜けがないように確認するコトであったり、
ディレクターの心・技・体のうち、本書で扱っているのは「技」の部分

この一冊を丸暗記したところで、プロマネやディレクターの実用力が
上がるワケではないが、月刊のウェブ専門誌が掘り下げられない部分まで
情報が整理されている。

ディレクター経験があるなら、知っている内容だが、
ウェブ関連の書籍では、フォローしきれない範囲(KJ法など)での解説も多い。

  • ウェブディレクターの仕事
  • プロジェクトマネジメントについて
  • マーケティング
  • フレームワーク
  • 新規案件の見積書フォーマット
  • 運用更新の見積書フォーマット

過不足なく表記してあるので、初めてディレクターをやる人が読むと、
その膨大な範囲にウンザリしてしまうが、流し読みするだけでも価値がある。

ディレクターは翻訳者

P.18
クライアントは諸条件を度外視して、
要望や理想を述べることが少なくない。
(悪気はないが成果とそれに必要な工数との関係が理解できていない
場合に特に多い)

制作者は自分の作りたいものを提案したり、
面倒だという理由で手を抜いたり
逆に、必要以上に過剰なサービスを制作したりしがちだ。

巻末の関連用語集は、的確な情報量で
各用語が解説されているのが嬉しい。

  1. プロジェクト管理用語
  2. マーケティング用語
  3. CSR、サステナビリティ関連用語
  4. 情報セキュリティ、個人情報保護用語
  5. インフォメーション・アーキテクチャ用語
  6. ユーザビリティ用語
  7. アクセシビリティ用語
  8. アクセスログ解析用語
  9. WebとHTML用語
  10. Weblog (ウェブログ)用語

ディレクションの入り口として観ると、
全体的な情報が掲載されているところが本書のウリ。

2009年6月16日

ソフト契約と見積りの基本がよ~くわかる本

ソフト契約と見積りの基本がよーくわかる本―実践・ソフト取引契約文書作成の手引き 谷口 功 横浜関内伊勢佐木町のカフェバー 音楽好きが集まる洒落た飲み屋 ウェブ担当がオススメする書籍 契約締結は
お互いの利益

重要なのは、お互いの合意を証明してしておくこと。

  • 著作権の全貌
  • プログラム内部(モジュール)に対する著作権
  • 請負契約と委任契約の違い

契約書の各項目について、図解で解説されているので
大変わかりやすい。

実用性は乏しいが、各事項の読み取り方が
個別にアドバイスされているので、"基本"以上に役立つ書籍。

2009年6月12日

アート・オブ・プロジェクトマネジメント

アート・オブ・プロジェクトマネジメント 横浜関内伊勢佐木町のカフェバー 音楽好きが集まる洒落た飲み屋 ウェブ担当がオススメする書籍 プロジェクト
大災害で
大炎上

・・・しないために。 疑問を投げかけ前提に挑む。
そんなプロマネの存在理由が明らかに。

機能的な書籍というよりは、如才無いプロマネの心構え。

著者のScott Berkun (スコット・バークン)さんは、
マイクロソフトで、OfficeやVisual Basic、IE等の
プロジェクトに関わってきたようだ。

プロマネの経験がある人なら、それらのプロジェクトが
どれほど壮大か想像できるだろう。
その場で、吐き気をもよおす人もいるかもしれない。

プロセスに取り憑かれ、方法論への執着が
間違った方向へ行っている場合、力が大きいほど、修正はきき難い。

チームメイトに心配を抱かせないためにも、
プロジェクトマネージャーだけではなく、チーム全員が読んでいただきたい。

スケジュールが狂うのは何故か?

スケジュールが遅延するということは、
誰も把握していないコストが隠されていた、
あるいは無視されていたということを意味しているわけです。

以下の2つ、笑えるけど、自分がやっているとしたら、
まったく笑えない。 その詳細も解説

  • 「よく見かける悪い手段」
  • 「質の低いビジョンのドキュメントに見られる特徴」

大胆さ、図太さがプロジェクトを邁進させる。
あなたへの命令が大切なコトか試す方法

私は、自分が理解できない、遠回しで曖昧かつ官僚的で組織的な
プロセスは無視するようにしています。

無視した事案が大事な場合、偉い人がスッ飛んでくるハズ。
重要でない場合は、当然、誰も来ない・・・

現場を守る、プロマネの領域

誰かが優先順位を無視した指示をしてきたと思った時には、
「ノー」と言ってください。

あるいはその指示をした人に対して、私が「ノー」と言っていたと伝えれば、
その人は私のところに来るはずです。

もし彼らが文句を言ったとしても、
議論して時間を無駄にしないようにしてください。

とにかく私のところに来るように、その人に伝えてください。

"計画すること"が目的ではない。

計画に従うことで勝利できるような戦いはないが、
計画なくして勝利できるような戦いもない。

ドワイト・E・アイゼンハワー

(ドワイト・D・アイゼンハワーのこと?)

それでは、何故計画をするのか?

戦闘というものは計画通りに行えるものではない。
計画は変化に備えた共通の基盤
でしかないのだ。

重要なことは、全員が計画を知っておくことで、
容易に変更が可能になるということなのだ。

近代戦は非常に流動的であり、
意思決定は迅速に行わなければならない。

そしてそのほとんどは計画に従ったものとはならないのだ。

しかし全員が少なくとも、
自分はどこから来て、
(その後)どこに向かっていくのか

ということを知っているのだ。

イスラエル防衛軍司令官 ダン・ラネル陸将補

つい、行うタイミングを逃しがちな、プロジェクトの検死報告(反省会)

打ち上げの偉大性、組織を構成するメンバー、個別の利害にも目を光らせる

皆さんが気になるのは、16章の「社内の力関係と政治」ではないだろうか?

  • 「政治的な理由で・・・」
  • 「大人の事情で・・・」

と言った言葉は、逃げの言葉だ。
語る者同士の思考を停止させてしまう魔力がある。

2009年4月10日

「協力する組織」のマネジメント

「協力する組織」のマネジメント ハーバード・ビジネス・レビュー 横浜関内伊勢佐木町のカフェバー 音楽好きが集まる洒落た飲み屋 ウェブ担当がオススメする書籍

大規模
プロジェクトの
失敗マネジメント

ハーバード・ビジネス・レビュー系列って
なんだか揃えたくなりますよね。

特集は、オンラインRPGを題材とした、
ゲーマー達の組織論

流動的な状況でリーダーに抜擢されるときの資質や、
まとめ役が決定していない流れの中で、
自発的に組織の長が生まれる過程を解析する。

現実のビジネス世界でも活かせるのか?
指導者のエキスを抽出する。

複数でプレイするオンラインゲームでも重要な
リーダーの資質は、下記に関連している様子。

  • インセンティブを見極める
  • 周囲の環境

実際の企業でも、社内メールに仮想通貨を付けて、
情報の価値を計測する試みもされているそうです。

ゲーム上のコミュニケーションが仕事に活用できるのか、
大まじめに調査、分析しているところがイイですね。

3000組の夫婦から導き出された解析データから、何が観えるのか?

人間関係がこじれると高くつく

人間関係を破壊する要素。

  • あら探し
  • 自己防衛
  • 拒絶
  • 軽蔑

膨大な修羅場データが基になっているだけに、
禍々しい説得力がありますね・・・

エアバスA380などの、ジェット機を製造する
大規模プロジェクトを例に挙げ。

複数のプロジェクト間で、どのように情報共有が行われているのか、
管理に活かす方法を探る。

  • DIM (デザイン・インターフェース・マトリックス)
  • TIM (チーム・インタラクション・マトリックス)

以上の2つを照らし合わせて
アラインメント・マトリックスを作ってみると、
視覚的に把握できるようになるらしいです。

経験豊富なプロジェクトマネジャーが
失敗する理由も、読み応えあり。

他の人が、どんな経路で失敗したか気になるし、
そこから学べるコトも多いですよね。
あまり表に出てこないから、本書はチャンスです。

2009年1月29日

「顧客対応」掟と極意153

ITエンジニア必携!顧客対応の掟と極意153  本園 明史 やりたいコトは
膨張する

今のプロジェクト、景気好くポシャってますか?
それとも、デスマーチってますか?

真面目な人ほど、
遅々として進まない案件に関して、
キーっ! となってることでしょう。

本書は、プロジェクトマネジメントに関して、
マニュアルや体系化された方法論から一歩踏み込み、
相手の心理的状態を想像し、「人間模様」に焦点をあて
サンプル事例別に解説している。著者は本園明史さん。

"議事録"は自分とプロジェクトを守ってくれない。
と知っているなら読む必要は無いかもしれないし、
人ごとだと、笑いながら楽しく通読しているだけじゃ、
明日は我が身かもしれない。

ワンマン社長や、わがままクライアントに振り回されている
お疲れの方々にもオススメ。

歴戦のプロマネにとっては、2,280円は高い。
うなずける事例があるものの、
具体的な解決策は出てこないからだ。

だが、経験豊富な者にとって、プロジェクト毎によって異なる状況に、
どうやら普遍的な解など、存在しなさそうだ・・・
ということにも気づいてしまっている。

頻繁に出てくる"システム"という単語は、
それぞれの職種で頻度の高い単語に置き換えられるので、
過去のプロジェクトや、現在進行中の案件に対して、該当する例を発見し
大変なのは自分だけじゃないんだ、という一体感を味わって慰めよう。

逆に、初めてプロマネに就任する人にとっては安い価格だ。
トラブルが発生する前に、モメ事の種類を把握することができるのだから。

どのプロジェクトでも、モメそうな箇所。

  1. 事実認識の誤り
  2. プロセスや手段の相違
  3. 目的レベルでの衝突
  4. 価値観や信念レベルでの衝突

上記のポイントを分析して、
自分と顧客がどの位置で騒いでいるのか把握する。

後で喧嘩にならないように、事前に釘をさしておく
ということを重視しつつ、まとめ。

  1. キーパーソンを探す
  2. やらないコトを決める
  3. なめられない
  4. 覚悟して怒る
  5. ステークホルダーごとの要求を知り、システムの目的に合わせて精査する
  6. 言葉の齟齬を放置しない
  7. 正論で相手のプライドを傷つけない
  8. リクエストは受けるのではなく、検討する
  9. 過剰なサービスを提供しない
  10. "このやり方が正しい"という錯覚に浸らない

ミーティングや、顧客のプロファイリングで活用できそうな小技。

  1. 突っ込まれた部分を切り出して会議化
  2. ラベリングの共有化
  3. 会議での議題の順番を意図的に入れ換える

教訓。

P.67
ベンダのマネジャーはジェット機のパイロットのようなものです。
その飛行機のオーナーがどれほど強く要求したからといって
素人の指示に従ってはいけませんし、
素人に操縦桿を握らせてはいけないのです。

P.79
ワンマンに説得が通じることはまずないと考えていた方がよいでしょう。
正論を言っているのだから一生懸命に説得すれば何とかなるはずだ
と考えるのは甘いと言わざるを得ません。

残念ながらワンマンは
人から説得されることはありません
手は一つです。
事実だけを告げて、あとは自らの判断で
「こちらの思う方」に向かうように仕向けるしかありません。

P.82
ベンダに対して感謝の気持ちも「借り」の感覚も持っていません。

             (~中略~)

 「すみません」「すみません」と常に申し訳なさそうに
しているのですが、

             (~中略~)

最初のうちはベンダも頑張ります。
しかし、頑張れば頑張るほど
顧客は甘えるようになります。

             (~中略~)

顧客第一主義は重要です。
それでも難しい顧客はいます。中にはこちらが
赤字覚悟で提供したサービスにも
まったく満足しない顧客もいます。

要求は膨らむものであり、
ある意味これは仕方のない面もありますが
限度もあります

P.102
顧客の組織文化は実に多様です。
システムに対する考え方も多様です。

したがって「システムとはこうであるべきだ」
「システム開発はこうであるべきだ」
という思い込みを持って顧客に対応すると、
仮にその思い込みが一般的に常識と呼ばれるものであっても、
思わぬ抵抗にあってびっくりすることがあります。

こうした状況こそ、顧客を理解するチャンスです。
常識を顧客に押しつけたり
説得しようとするのは後になってからもできることです。

まずは常識との乖離が
どのような理由で生じているのかを明確にしましょう。

P.155
理屈はわかってもらえたはずなのですが、
最後のYESを言ってくれません
そしてその理由も言ってくれません。

"やりたいこと"の制御

P.134
要件は一般的に「この機能は○○することができる」
というような書き方で表されますが、それと同時に
「○○が達成できれば機能要件が満たされたものとする」
というような機能の要件定義の終了条件
を明確にしておくのです。

警戒心を緩めない。

P.163
顧客は「聞いた」かもしれないが、
「理解した」か「納得したか」はわからない。

             (~中略~)

相手は意味を理解しただけなのか、
それともきちんと内容に納得したのかを、確認するくらいの
用心深さは欲しいものです。

P.187
そもそも見積りというものは、求められている要件、納期、品質レベル
をベースに計算されたものです。
それが交渉によって上下の変動が可能ということであれば、
インプットとなった要件や納期や品質は何だったのか、
ということになります。

交渉によって値引きに応じることは、
自らの見積りの信頼度を否定する行為
と言えるでしょう。

合理性や、正論を、相手の触れて欲しくない部分に突き刺さない。

P.221
どれほど不合理なものであっても、
顧客には顧客にとっての合理性がある。

本編には出てこないが、
インテルの共同創業者、アンディ・グローブ(アンドルー・グローヴ)の言葉は
我々を励ましてくれる。

Only the Paranoid Survive
病的なまでの心配性だけが生き残る

2008年10月18日

Webプロジェクトマネジメント標準

Webプロジェクトマネジメント標準 真のwebプロマネ

PMBOK(ピンボック)という知識体系の型と、
ウェブ制作現場のリアル。

本書ではウェブ用にPMBOKが簡略化されカスタマイズ
されているようだが、ウェブに限らず
ハッピーエンドを迎えるプロジェクトを量産したい
管理職の方々は手元に置いておくべき。

値段は「2,180円+税」だが、
プロジェクトの規模によっては、200万、2000万、2億にだって化ける。
このポテンシャルで、この価格は超お買い得、激お薦め書籍。

  • 1章:PMBOKの考え方
  • 2章:ウェブ・プロジェクトにおける活用法
  • 3章:プロジェクト・マネジャーの心構え、リーダーシップについて
  • 4章:現場で活用できるテンプレート集

プロマネのフレームワークを活用し、人材が流動する環境の中で、
いかにして、失敗を知的資産にするか。

アウトプットがインプットとなる仕組み。
「終わりをつくる」とは?
ライン・マネジメントとプロジェクト・マネジメントの決定的な違い。

あなたは信頼されているか?
尊敬されているか?
プロジェクトメンバーが離れていかないためにも、
先人が創り上げ、練り上げた体系的な知恵を活用しよう。
(テンプレートがメチャメチャ役に立つ!)

2008年5月24日

受託開発の極意

jyutaku_kaihatu_no_gokui.jpg

受注時にしっかりと要件定義しておくことで、
後々お互いの間でモメることがない。

見積の基礎から、要件定義の方法、
設計、実装、テストの流れから、メッセージ性のある
スケジュール表の作り方。トラブル時の心構えまで。

見積の手法も、ユースケースポイント法、
ファンクションポイント法、タスク分解法など、色々あるんですね。

システム要件での定義も、機能性、信頼性、効率性、使用性、保守性、
移植性とわかれている。細かくまとめておくことで、穴に気づきやすい

決まらないくせに変わりやすいのが要件

クライアントに想像力がないのか、受注側に確信がないのか。
どちらのせいとも言えるが、うなずいているアナタが、ガッチリとした要件定義を
構築してみよう

ウェブ担当のスキルの一部として、繊細な要件定義や
行程の詳細を弾き出しての予算交渉などもありますが、
最近、先方も漠然さを理解している案件の見積提出を求められました。
こういった場合、本書のような細かい計算から概算見積を出す時もあったり、
状況によっては、フェルミ推定を使って、概算の概算。

つまり、1億かかるのか、5000万円なのか、1000万円以内で収まるのか。
大まかな単位を算出することにより、短時間で発注側とのズレを無くすコトができる。

すげぇ細かく。概算で3333万円です。とか息荒く言っても。
お客様側から「100万もあれば十分かと思ってた・・・」
なんて返されることもあるから、お互いの時間の無駄を排除するやり方も大切

Excelを使う前提なのですが、「1行1テストケース」を徹底

セルの結合を使ったり、2行にすると、コピペの時や
スタッフ間で混乱が発生するのでやめておいたほーが吉とゆー話

受託開発の場合は、「開発終了」=「プロジェクトの終了」と
なる人が多いからです。しかし、特に運用を担当されるお客様にとっては、
開発が終了してからが仕事のスタートであり (~中略~)
あなたの作ったプログラムはいつか実際に運用され、
誰かが保守することになるのです。

先の先までイメージして、お客様との信頼関係も保守しよう

記憶に残る「意志決定の癖」を持ったリーダーになるために

【バリバリ・リーダー】 トップダウン型プランニング重視
事前の計画とそれに従った意思決定を好む
バリバリといいつつ意外に慎重な行動が特徴

【サクサク・リーダー】 トップダウン型アドリブ重視
その場その場の素早い意思決定を好む。軽やかな行動が特徴

【よしよし・リーダー】 ボトムアップ型プランニング重視
事前の計画に従いことを運ぶが、重要な局面ではメンバーの意見を取り込む。
ただし、メンバーの意見ですら事前に織り込み済みの場合もある

【ふむふむ・リーダー】 ボトムアップ型アドリブ重視
ほとんどの場面でメンバーの意見を重視する。
優柔不断にとられがちな部分もある

あなた自身や、まわりのリーダーはどのタイプ?

変わったとしても、ほかの人に影響を与えないと意味がありません。
人が自分を変えたいと願うとき、奥底では他人や社会との関わりを変えたいと
考えているはずです。

環境に文句を言うのではなく、自分を変えてみる

普段は淡々と仕事をこなし、定時帰りをモットーとしているメンバーが
いわゆる「火消し」としてチームに加わり、ほかのメンバー以上に遅くまで
頑張ってくれる姿を見るとき、そこには行動によって何かを示す彼の哲学が
宿っていると思うのです

こんな、イイ人がチームにいますか?

付録のプロジェクトファシリテーション入門
朝会や、プロジェクトの見える化促進の「かんばん」
改善のための「ふりかえり」など、今すぐにでも導入したいテクニックが満載

解説付き参考文献も、片っ端から目を通しておきたい。


【追記】 解説付き参考文献の中で気になったもの

「アート・オブ・プロジェクトマネジメント」
「ソフトウェア見積り 人月の暗黙知を解き明かす」
「失敗のないファンクションポイント法」
「成功する要求仕様 失敗する要求仕様」
「ユースケース実践ガイド」
「基本から学ぶソフトウェアテスト テストのプロを目指す人のために」
「アジャイルと規律 ソフトウェア開発を成功させる2つの鍵のバランス」