手抜きをしたいＰＭのための、楽々プロマネ術

いやぁ〜２年間ほどかかったプロジェクトを先週サービスインさせました。
サービスインの立会いは、何回やってもハードですね。
精神的にも肉体的にも・・・

サービスイン時の手抜きテクといえば、

�@１時間ごとに必要となる報告作業の手抜き
お客様に問い合わせ（または障害）の一覧の作成・更新をお願いするのです。。そして、お客様との状況確認会時には、その開発側の対応状況を口頭で報告するだけにするのです。　
お客様への報告書というのは、誤解を受けないように内容・言葉使いに対して最新の注意が必要となります。（サービスイン時には大抵多くの関係者へ報告がなされるので、この報告書が誰の目に留まるか分かりません）そんな最新の注意をサービスインの超多忙の中、できるでしょうか？　　できるはずがありません。
できないのであれば、最初からお客様にお願いするのです。
（サービスイン作業も一括で請け負っているときは別ですが・・・）

但し、開発側の内部的な作業管理用の一覧は作成します、当然です。　これは、手抜きをしてはいけないポイント。

�A.障害「調査」作業の手抜き
エンドユーザーから障害報告されたとしても、障害報告はバグと思い込まず、「オペレーションミス、環境設定ミス、マスター登録ミス」がないかを確認させることです。
私の過去の経験上、プログラムバグは２割程度です。

�B障害「対応」作業の手抜き
お客様の指定する障害対応優先順位を、そのまま信用しない
お客様の対応優先順位は、現場の方が怖かったり、代替策が思いつかなかったりと、あまり考えずに優先順位を付けてきます。
そんなのいちいち聞いていたら、休む暇もありません。
開発側で熟慮した後、お客様に優先順位の見直しさせることを、必ず実施してください。

�C障害「対応」作業　および　クレーム処理の手抜き
　サービスイン直後はいろんなことが起こるので、とにかく暫定対応をしてその場をしのぎ、本格対応は後回しにします。　これにより現場のクレームを減らすことができます。
まぁ、くそ忙しい中で本格対応なんて、できるはずもありません。

�D土日、深夜作業の手抜き
　基本はオンコールにしておくことです。
プロマネが土日、深夜に現場にいても、あまり役にたちません。
電話での各リーダへの指示、お客様応対で十分です。
お客様から要請があれば別ですが・・・
ゆっくりソファーでリラックスしながら、出番を待ちましょう。
（かならず出番はありますから）

２時間くらいで一気に読んでしまった。　著者がITジャーナリストだけあり、読みやすい、理解しやすい、おもしろい。
この本の特徴は、他のWEB2.0関連本と比べて、著者の考える新しいビジネスモデルを惜しげもなく、沢山お披露目されているところ。
「もしかしたら、わたしでも新ビジネスを考え付くかも・・」とさえ、思わされてしまった。
プロマネというよりも、システムアナリスト（IT戦略立案者）や経営者的な立場の人が読まれるとよいかもしれません。

他のWEB2.0関連本とは違い、プログラミング例を多様してWeb2.0を説明してくれています。
プロマネなら、この本を読んでシステム面からweb2.0を理解することも必要ではないかと感じました。

次に読んだのはWeb2.0 BOOK。
Web2.0とは？　Web2.0的サイトの紹介などたくさんの情報が掲載
されており、広く浅くweb2.0を理解できると思います。

「柔軟性のあるWebアプリケーションを非常に短時間で開発することができる」ものの、「高度なエンタープライズ統合機能では対応できないかもしれない」Rubyは、２００７年１月時点では、大型プロジェクト案件には、時期尚早といったところですかね。

利用するなら、５０人月以内のフィージビティ的なプロジェクト、または、一部マスタメンテナンス機能など限定するとか・・・
言語選びも、枯れた言語にしないとPMは手抜きができないってところですね。

参考文献：以下のIBMのサイト

■Ajax on Rails


URLhttp://www-06.ibm.com/jp/developerworks/java/library/j-cb12056/index.shtml

Ajax に問題がないわけではありません。うまくいく場合には、息をのむような効果が得られます。しかしうまくいかない場合には、デバッグがまったく別次元の作業となり、デバッグの手法やツールは、とても他の言語に匹敵するレベルに達していません。Ruby on Rails には大きな利点があります。それは単純さです。Rails ラッパーと素晴らしいコミュニティー・サポートのおかげで、ごくわずかの初期投資のみで、この新しい世界に容易に入り込むことができます。しかし Rails で実現できることは、そこまでです。Ajax という連続体の全体には広がらない 2 つのフレームワークでは、すべてのユーザーを満足することはできません。

Java 言語の場合には、Ajax のフレームワークや手法に関して、ずっと幅広い選択肢があります。柔軟さにも富み、また、素晴らしいサポート・ベースもあります。しかし柔軟さにはかなりの代償が伴います。強力な Ajax フレームワークを選ぶ必要があるだけではなく、Web 開発フレームワークも選ばなければなりません。例えば、JSF フレームワークを統合するための作業は、Struts を統合する場合と劇的に異なります。新しい技術は、単純さを要求することが多いものです。Ajax on Rails は、UI に Ajax の洗練された部分が必要な問題に対して、単純な答えとなるかもしれません。そうした問題は、Java 言語による高度なエンタープライズ統合機能では対応できないかもしれないのです。次回は、JavaScript を詳しく探ることにします。それまで、境界を越え続けていてください。

■Ruby on RailsによるWebアプリケーションの高速開発

URLhttp://www-06.ibm.com/jp/developerworks/linux/050708/j_l-rubyrails.html

Railsを使用すると、柔軟性のあるWebアプリケーションを非常に短時間で開発することができます。この記事では、Railsでの作業がどのようなものか、ほんの少しだけ紹介しました。完全なフレームワークには、Webベースのアプリケーションでよく使用されるアクションを実行するための便利なクラスとメソッドが多数含まれています。

Railsの最もよい点は、必要なサポート・コードのすべてが付属しているので、「Rails流の考え方」を身につけられることです。これは、作業対象となる生の材料を与えるだけの他のツールキットやフレームワークにはない大きな利点です。Rails開発は、漠然としたアイデアから完全に機能するWebアプリケーションへの明確な道筋を示してくれます。

遅ればせながら、WEB2.0の勉強をはじめました。
2006年1月から発行された本を１０冊ほどピックアップして購入しました。
第一弾は、「RSSマーケティング・ガイド」

複数人の共著でり文の構造に統一感がなかったため、ちょっと読みにくかったので余白にキーワードや図をメモ書きを入れて、自分なりに整理しながら読みました。
１ＷＫ。（一日３０分程度）
内容が事実に裏付けられており、非常に納得感があり、RSSとは何か？がよく分りました。

＜まずはキーワードのみをずらずらと・・・＞

ＷＢＳ作成
スケジュール見積もり
コスト見積もり
コミュニケーション
会議体
意思決定
マスタースケジュール
課題、ＴＯＤＯ、リスク、ペンディング管理
情報共有
議事録
目標設定（マイルストーン設定）と動機付け
テスト計画


作成途中　ごめんなさい

計画されていないリスク対応策を「迂回策」という。

逆に言うと、あらかじめリスク識別され、リスク対応計画が作成されているものは、「迂回策」とは言わない。

結構、穴。

基礎知識
期待値(３点加重平均) = (悲観+4×標準＋楽観)／６
標準偏差σ＝(悲観-楽観)／６
確率±1σ = 68.26％
　　±2σ = 95.44％
　　±3σ = 99.73％

応用問題
コストが１億を超える確率が１５％であるとき、これは何σ以内であるといえるか？

考え方
以下のように読み替える。
コストが１億を超える確率が１５％　＝　１億以内で収まる確率が８５％　
以下のグラフより、１σ＝８４．１３％　＜　８５％

　　　　　　　　　|
　　　　　　　　<---> 68.26%
　　　　　　<----------> 95.44%
　　　　　<---------------->99.73%
　　　　　　　　　|
==+==+==+==+==+==+==+==+==+==+==+==+
　　　　-3　-2　-1　0　+1　+2　+3（σ）
　　　　　　　　　|
<*************************99.76%以内
<********************** 97.72%以内
<******************* 84.13%以内(=50%+68.26/2%)
　　　　　　　　　|

クリティカルパス法として、ＧＥＲＴが忘れがちなので覚えておくこと。

ＧＥＲＴ：分岐やループが可能,確率的処理