やっぱ、お客さん直接の受注は怖いよね！

　今出ている日経ソリューションビジネス（３／１５号）の５６ページ、あの劇の記事の表題で、「プライム受注の怖さ」ってあったけど、やっぱ、（プライムって言うほどの規模でなくても）お客さんから直接受注もらうのは、怖いよねー。
　現実的に、お金はらってくれるかどうか、わかんないもんねー。

　とくに、小さい仕事の場合、お客さんが、結構羽振りがよさそうにしている場合、実際には儲かっていなくて、おおざっぱ（どんぶり）って言う場合があって、そういう人って、払えないから、開発をやらせといて、急に払えないとか言い出したり、なにかとプログラムにけちを付けて、払わないでいいように仕向けようとしたりとか。。。このシステム使って、お金が入ってきたら払うとか。。。
　そういう話じゃないジャンみたいな。でも、売っちゃうと営業も必死で、なぜか、その会社のために、仕事見つけてきたりすると、もう、わけわかりません。

　ウィリアムのいたずらも、お客さんからの受注っていうのは、散々懲りたし（いまも、そのため、収入に影響を受けていることは確かだし）、ウィリアムのいたずら以外でも、お客さんが、お金を払ってくれない＆条件を途中で変えられて、大損害を与えられた。。。その他もろもろのトラブルで、もう、お客さんとの直接の取引をやめた人（会社）って、多いんじゃないかなって気がする。最近。

　まあ、こんな感じだと、結局、お客さんと直接取引きするのは、体力のある会社と、お金がすぐには必要のない、週末企業とか、大企業に勤めている人の副業とかになって、ソフト会社やフリーの人は、どこか大きい会社の下請け的に入るっていう形になるのかな？と思うぞ。

プロジェクト計画書に書くこと

　そろそろ、要件定義の話が中心になるとおもうので、プロジェクトの開始段階で書き残した話をメモ書きしておこうと思ういます。書き残したことは３つ
　　１つは、プロジェクト計画書に書くこと、
　　２つはＷＢＳとスコープと要素技術とＲＦＰ、
　　３つは、ＲＦＰと提案内容が違う場合の対処法

このうち、１つめのプロジェクト計画書に書くことは、すぐにかけるので、今書いちゃいます
（あとの２つは、気が向いたときに書きます。長い話なので）

---

プロジェクト計画書の構成に関して、聞かれることがあるんですが、これは、「プロジェクトマネジメント知識体系ガイド」Ｐ４５にある。そこを引用すると、以下のとおり

---以下、引用、一部ウィリアムのいたずらが省略・修正----

プロジェクト計画書の内容

・プロジェクト憲章
・プロジェクトマネジメントの方法や戦略
・スコープ記述書
・ＷＢＳ（コントロールレベルまで）
・（ＷＢＳに対する）コスト見積もり、スケジュール、責任分担
・技術スコープ、スケジュールのベースライン、コストのベースライン
・主要マイルストーンと目標期日
・主要スタッフ、予想コスト、作業工数
・リスクマネジメント計画書
・固有のマネジメント計画書
　　・スコープマネジメント計画書
　　・スケジュールマネジメント計画書
　　・コストマネジメント計画書
　　・品質マネジメント計画書
　　・要員マネジメント計画書
　　・コミュニケーションマネジメント計画書
　　・リスク対応計画書
　　・調達マネジメント計画書
・未決課題と未解決事項
・詳細資料
　　・他の計画からのアウトプット
　　・追加情報（当初知りえなかった制約など）
　　・技術文書
　　・関連企画文書
　　・プロジェクト初期段階の仕様書

---引用ここまで---

実際にかく場合の問題とかは、べつに書きます。