2013年02月06日

「彼女欲しい」という欲求はプロジェクトとして考えると破綻している

「嫁欲しい」「彼女欲しい」というのは、具体的な成果物設定がないままゴールだけを規定しているという、プロジェクトマネジメントとしては失敗プロジェクトのモデルケースみたいな欲求なので、「○○さんを彼女にしたい」みたいな対象物を伴った適切なゴールラインの設定をした方がいいと思います。




ということで、タイトルと最初の三行で言いたいことは全部言ったので、以下は補足。文中「彼女」というのは全て「彼氏」にも読み替え可能だとは思いますが、正直、あまり真面目に受け取ることはお勧めしません。



一般的に言って、プロジェクト構築の際には、最低限以下のような項目を設定しておくことが必要になると思います。

1.プロジェクトの目的設定
2.プロジェクト達成の為のアウトライン設定
3.ステージごとの成果物設定
4.ステージごとの課題・リスク想定
5.ステージごとのスケジュール設定
6.予算想定
7.リソース・体制設定


細かいところは他にも色々とあると思いますが、ざっくり以上のような項目は必須と言えるでしょう。

「彼女欲しい」という欲求をプロジェクトとして捉えた場合、「1.プロジェクトの目的設定」はまあ、「彼女出来た」というゴールラインが明示されている点で及第と言えなくもないのですが、2以下の設定は一切ありません。勿論全てを最初から設定することは難しいとはいえ、幾らなんでも漢気に溢れ過ぎています。若干厳しい言い方をしますと、プロジェクトとしては破綻が見え過ぎていて、私が請負業者なら見積依頼書を受け取った時点で6時方向に裸足で逃げ出すレベルです。

このエントリーでは、「彼女欲しいプロジェクト」をまともに実施出来そうなプロジェクトにする為には、どのような手順を踏めば良いか、物凄い適当さで考えてみたいと思います。


1.プロジェクトの目的設定

「彼女欲しい」はゴール設定ではあるのですが、聊か具体性に欠ける為、要件定義の工程が不可欠になります。出来ることなら、「○○さんを彼女にしたい」といった具体的な成果物設定をしたいところです。

要件定義の工程をまるごと省ける上、その後のアウトライン設定や、課題・リスク想定もより具体的になり、プロジェクトとしての背骨がぐっと引き締まります。


2.プロジェクト達成の為のアウトライン設定

彼女を作る為のざっくりした工程を考え、ステージ設定します。

私は彼女を作った経験がそれ程ないので適当な想定ですが、一般的には、

・要件定義(どんな彼女が欲しいのかを具体的に想定)
・外部設計(どういった状況、場所、手段で当該彼女と仲良くなるかの計画)
・内部設計(上記工程の為に必要と思われる事前準備)
・実装(実際に工程を実施)
・納品/リリース(彼女が出来る)
・保守/運用(彼女と仲良くする)


といったアウトラインになるのではないでしょうか。よく知りませんが。

リリース直後に不具合が頻発して業務停止、といった事態を間違っても招かない為にも、実装段階におけるリグレッションテストは綿密に行うべきでしょう。彼女モジュールとの意思疎通は密に行うべきかと思います。


3.ステージごとの成果物設定

上記ステージごとの細かいゴールを決めます。外部設計時点では当然外部設計書が成果物になることが多いでしょうし、実装したら当然彼女モジュールが成果物になるのでしょう。なんだかよくわかりませんが。

運用手順書はあるに越したことはないと思いますが、そこら辺の彼女運用手順書っぽいものを中途半端に参照すると却って彼女モジュールの機嫌が悪くなったりすることもあるらしいので気を付けてください。


4.ステージごとの課題・リスク想定

ステージごとにどのような障害が起こりえるのか、ということを事前にある程度想定しておくと、プロジェクトの遂行におけるリスクが減り、プロジェクトの実施をスムーズに出来ます。

例えば

・具体的な恋愛対象となる女性の心当たりがない
・そもそも周囲に女性が存在しない
・母親以外の生物学的女性を8年程目にしていない


といった障害は、内部設計段階における重大なリスクです。それに対して、

・女性がいる環境へのアクセス手段を考える

といった対策をざっくり想定しておくとスムーズにプロジェクトが進行出来るのではないでしょうか。


5.ステージごとのスケジュール設定

ステージごとにざっくりどの程度の期間が必要か、ということを想定します。

これは、要件定義の内容次第で本来大きく変わることですので、プロジェクト計画時点では仮のスケジュールということでいいでしょう。ただ、設計期間に二年とか、余りに時間を掛けすぎると途中でどうでも良くなってしまう可能性もある為、ある程度スピード感をもったスケジューリングをするべきだとは思います。

また、この際定期進捗確認ミーティングなど、会議体の定義とその開催頻度についても決めておいた方が後々揉めないのではないかと思います。何と揉める可能性があるのかはよく分かりませんが。


6.予算想定

ざっくりいくらくらいの予算を必要としそうか、またいくらくらいまでの予算を投入可能か、ということを考えます。

これも、要件定義の内容に基づいて見直すべき項目ではありますが、プロジェクト計画時点でも仮設定ということで設定しておけば、後々の予算調達がやりやすくなるでしょう。



7.リソース・体制設定

本来「誰が何を担当するのか」「どの程度の人員、設備を投入出来るのか」ということを設定する為の項目ではあるのですが、彼女欲しいプロジェクトの場合、大体「俺」としか書き込まない項目です。仮にあなたがエロゲーの主人公であれば、「悪友」とか書き込む箇所もあろうかと思います。



ということで、駆け足になりましたが、プロジェクト構築の際必要と思われる項目について見て参りました。これを参考に、彼女欲しいプロジェクトをより明確化具体化し、皆さんが健やかなプロジェクト運営をされることを願ってやみません。

今日はこの辺で。
posted by しんざき at 21:00 | Comment(17) | TrackBack(2) | 雑文 | このブログの読者になる | 更新情報をチェックする
このエントリーをはてなブックマークに追加
この記事へのコメント
小職の周りにも、40歳を超え『彼女が欲しい、嫁が欲しい』と言いながら、ほぼ破綻しているプロジェクトを推進しようとし繁華街の無限ループにはまっている友人が少なからずいます…
Posted by 直江山城守 at 2013年02月07日 02:21
短い期間で彼女の構築とリリースを繰り返すagile方式のほうが、最終的な成果物(嫁)のクオリティは高くなりそうです。
Posted by samurai at 2013年02月07日 02:45
○○さんを彼女にしたい、という目標になる○○さんがいる人はそれがよいのかもしれませんが、
多くの彼女が欲しいと言っている方達は、その○○さんがいないのではないかとも思いました。その場合は、まず対象となる○○さんに出会う、ということがプロジェクトの最初の成果となるわけですね。
手前味噌で恐縮ですが、目標となる○○さんがいない方は私たちが開発している「7人の物語」をご利用されてみてはいかがでしょうか?
以下のように、本日(2/7)締め切りの男女7人マッチングで、男性が圧倒的に足りない状況です。(女性の応募は既にそろっています。)
https://www.facebook.com/storyof7
Posted by 林秀明 at 2013年02月07日 03:00
面白いです。応援します。
目的と目標という言葉をしっかりとつかいわけるとよいと思います。
Posted by どーそん at 2013年02月07日 08:02
気持ち悪い
Posted by at 2013年02月07日 09:09
開発以前のマーケティングに問題がありと…
Posted by nyo at 2013年02月07日 09:18
フラれたら、ダメな理由を教えてくれ!って食い下がるタイプか。
Posted by at 2013年02月07日 09:58
しかし「○○さんを彼女にする」をゴールにしてしまうと,その後でふられそうな気がします。運用にも目を向ける必要があると思います。
Posted by わたやん at 2013年02月07日 13:06
この二点には異論があります。
> ・外部設計(どういった状況、場所、手段で当該彼女と仲良くなるかの計画)
> ・内部設計(上記工程の為に必要と思われる事前準備)

外部設計とは、インターフェースの設計です。すなわち、ユーザーインターフェース、サブシステム間のインターフェース、外部接続インターフェースの設計をします。それに対して、内部設計は、インターフェースをどう実装するかの設計です。これを本プロジェクトにあてはめれば、

・外部設計 (寸法、重量、温度、湿度、発声、匂い、味などの設計)
・内部設計 (それを実現するための物理的・化学的・生理学的な設計)

が正しい工程です。
Posted by at 2013年02月07日 16:27
計画から逸脱した際の措置手順も盛り込んだ方が良いかと。
またプロジェクト自体のGo / No goを決める判断基準、判断時期の設定も必要かと思われます。
Posted by at 2013年02月07日 21:23
プロジェクトが重複して炎上してるのなら見かけた。
タスク管理は重要だは
Posted by at 2013年02月08日 06:14
単純に、○○の穴に入れたいっていうのは最初から破綻してるのか。
Posted by at 2013年02月08日 10:20
プロジェクトにアサインする人員のスキルレベルも相当必要で、
プロジェクトの難易度は高いし、24時間365日サポートとなると、
元が取れるのでしょうかね。

競合製品が多いので、納品先の契約破棄リスクを考えると、
保守に影響が出ない程度に納品先を複数作る必要がありそう。
※ 営業戦略、広報戦略(コンパ設定など)も絡んできますね。

やはり samurai さんの言う通りアジャイルですかねー。
# 仮想環境(2次嫁、妄想・・・)でのデバック担当なら任せろ
Posted by xxxSTFxxx at 2013年02月08日 12:48
現在のしんざき氏の考え方(手順・工程)を基に、しんざき氏と奥様の愛の成長過程を客観的に表現してほしいです。とても興味があります。
Posted by クロマル at 2013年02月09日 15:53
そうですね。
ここは是非、御社の構築、導入、運用実績事例のプレゼンを一発。
Posted by Gross1610 at 2013年02月12日 11:26
前向きに検討します。。。
Posted by しんざき at 2013年02月12日 22:09
プロジェクトってみんなC/O目指して張り切るけど、その後いつも運用フェーズで破綻するよね…
Posted by at 2013年09月14日 04:38
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:


この記事へのトラックバック

相当な感無量
Excerpt: 【「彼女欲しい」という欲求はプロジェクトとして考えると破綻している】 (不倒城...
Weblog: 【小人閑居シテ駄文記ス】
Tracked: 2013-02-09 00:14

2013年2月に追加したお気に入りエントリまとめ(Web制作/面白ネタ)
Excerpt: ようやく梅も咲きはじめ、寒い冬が終りを告げる感じですね。個人的には一年で最も嫌いな梅雨まで、あと3ヶ月弱です。\(^o^)/梅雨といえば、先日書いた防湿庫の記事がGIGAZINEのヘッドラインニュー..
Weblog: すしぱくweb|susi-paku <楽しければいいのです)
Tracked: 2013-02-28 01:09