放送とＩＴの融合トーンダウン！？本当なら、ライブドアをどこかに買収してもらうしかない

ライブドアの放送とＩＴの融合の話。

このブログでも、いろいろと取り上げたのに、なんか、トーンダウンしてるらしい。
（以下の掲示板の記事によると）。。。
http://messages.yahoo.co.jp/bbs?.mm=FN&action=m&board=1004753&tid=a5aaa5sa1a6a56a1a6a5a8a5ca5b&sid=1004753&mid=482326
http://messages.yahoo.co.jp/bbs?.mm=FN&action=m&board=1004753&tid=a5aaa5sa1a6a56a1a6a5a8a5ca5b&sid=1004753&mid=482370

本当なら。。目からビーム！
うーん、放送とＩＴの融合をやると思ったから、期待したのに。。。

かくなるうえは、
・リーマンは、ライブドアの社債を株に転換するから、
・その株をどこかの会社が買い占めて（時間外取引で ^^;)
・その会社が放送とＩＴの融合をやっていただく
しか、ありませんな。
　それが、一番無難なおとしどころでしょう。

　ちなみに、計算上、それが可能！ってことを示しているサイトがあるみたいね。
http://www15.ocn.ne.jp/~hiro-hmx/mscb5_4753_3.htm
（一番最後のほうの「と言った愉快な事態を起こせる可能性がある事を示しております
」の前に書いてありますね）

　じゃあ、どこが、ライブドアを買収してくれたら、世の中のためになり、フジも納得！放送とＩＴの融合が、実現するか。。。

　フジが増資する前は、フジがリーマンからライブドアの株を買ったら、面白くなると思ったんだけど、その可能性はなさそうなので。。。


　　　　　　　　　やっぱ、ソフトバンク？

　日テレの読売ジャイアンツに対抗して
　フジのソフトバンクって、どうかしら。これならフジもニッポン放送も提携しやすい・・・

　って、あんまりコンピューターに関係しなくなったから、今度、暇なときに、本家にかきますね。

長井秀和のネタから考えると、中途半端にいろいろ知ってるユーザーのシステム開発が一番危険だ

　前のブログで、 「完成後のシステムの使用方法（シナリオ）が読みきれるかが、システム成功の鍵だ」って書いたけど、たまに、どーいうシステムを作りたいのか、ノーヒントのお客さんがいるんだよね。

　なんか、営業とかに吹き込まれたらしく、
　「Ａｃｃｅｓｓで業務をつくりなおしましょう」
　とか、
　「何部と何部の情報共有」とか。。。

　まあ、私のお客さんにはまだいないけど、「ナレッジマネジメント」とか、「ＳＦＡ」とか「ＣＲＭ」とかを、唐突に言う人も、この部類なんだろうね。

---

　話が、ほとんど目標と夢で、実際の業務内容（手順）が話せないとき。
　仕方ないから、こっちがいろいろと、こんな感じ？とか聞くんだけど、「違う違う！」と文句ばかり言うケース。

---

　長井秀和のネタに、「母親が、テレビを見てて、ほらほら、あのひと、だれだっけ？というのに気をつけろ」っていうのと、おなじ感じで、

　ほとんど、どんなシステムなのか
　「ノーヒントだ！」

　で、こんな感じ？？って聞くと、
　「ちがう、そーいうかんじじゃないのよね」

　っていわれる。

---

　こういう、なにをやるのかの手順を語れないのに、キーワードや技術用語を並べるケースは、できるだけ逃れたほうがいい。
　ものすごく、リスクが高いケースだ。

　前に書いたように、リスクの見積もりは、完成シナリオを描いてそこから分析する。
　完成シナリオが描けない、このケース（目標や夢は、シナリオではない。目標や夢を実現して、なにをしたいのかが、完成シナリオ）は、当然、リスキーだ。

---

　逆に言うと、やる内容がはっきりしていて（入力と出力がはっきりしていて）なんの技術を使ってもいい場合は、成功しやすい。完成図がイメージしやすいから。

　つまり、キーワードや技術用語を並べられる、中途半端にいろいろ知って、わかってる（ひどい場合、自分がコンピューター通だと思ってる）ユーザーのシステム開発が一番危険だ。

　ちなみに、本当にシステムを知っているユーザーとは、自分が何を知らないかを知っているユーザーだ。

完成後のシステムの使用方法（シナリオ）が読みきれるかが、システム成功の鍵だ。間違いない！

　前のブログで、「ぜーんぜん決まってないとき（ＲＦＰ段階など）の見積もり例」っていうのを示しました。
http://blog.goo.ne.jp/xmldtp/e/549962a4b3b56339747e748af40d5078

　で、そこで、スケジュールのたてた「期間で、できそうかっていうことを考えて、リスクがあればヘッジするわけです」と、かきました。
　今回は、そのやり方について、一般的に述べます。

---

　私の場合、システムが完成したとき、使用する流れ（＝業務のながれ）をまず考えて、それが想像つくか？とはじめに考えます（ただし、かなりおおざっぱです）。
　これが、考えつく場合とつかない場合でリスクの度合いは、相当違います。

　考えつかないときは、技術的な要素に基づいて、その技術を使って開発できるか？とかんがえるんですが、先が見えない仕事をやるわけですから、かりにその要素技術のやり方が見えても相当危険です（はじめに想定しないものが出てくる可能性がある）。
　フリーのウィリアムのいたずらの場合、断る権利がある場合、こういうケースでは、なにか適当な理由をつけて断ります。

---

　完成後の使い方の流れが思いつくときは、それを実現する技術（方法）を考えます。

　で、その方法がきまったら、その方法を実現する手順を考えるわけです。
　で、この作り方が思い浮かぶ場合、大体、このリスクは限定的になります。
　作り方が思い浮かばなかったり、日程などで無理な場合は、他の実現方法を考えて、入れ替えます。

---

　つまりですね、一言で言うと、

（１）まず、ユーザーの利用の仕方の絵を書く
（２）つぎに、その絵を実現するための技術を書く
（３）その技術を実現する手順の絵を書く

ということです。
　（１）は、（コンピューター用語で）シナリオと呼ばれています。
　シナリオというと、演劇などでもやりますよね。
　そう、システムをつかってはじめから、最後までやる小芝居をつくるかんじです。
　そんな感じでやるかというと、（コンピューターシステムには、関係ないんですけど）、ここの「台本ができるまで」に似ています。
　ウィリアムのいたずらのメモも、ひらがないっぱい。
　そのブログの中に、「頭の中で自分以外の人間二人が会話してるなんて、ちょっと危険ですよね」ってありますけど、シナリオを考えてるウィリアムのいたずらも結構危険かも。


　で、（２）、（３）は、（１）がしっかりしていれば、あとは知識だけです。これは、専門技術なんで、知ってるか知ってないか、やったことあるかないかっていう感じの世界です。
　ウィリアムのいたずらの場合、（１）が出来ちゃうと、（２）、（３）は、無意識に頭に浮かんできて、浮かんでこないと、「やばい！」と判断しちゃいます。


　つまりですね、システムを使ったシナリオの絵が書けるかどうかが、すべてです！
　これが、かけなかったり、ぶれたりすると大変なことになり、火をふいちゃいます。
　逆にこれがばちんとはまれば、どーにか、押し込めますね。