ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

目標がはっきりしないとき、無茶な目標なときは。。。

2005-01-28 11:31:43 | コピーされるほど儲かるシステム!
システム開発などで、目標がはっきりしないことは、よくあります。
もっと多いのは、成功哲学をふりかざし、無茶な目標を立てる場合です。
(出来ると思わないからできない。もう、達成したと思えとかいって、
 むちゃくちゃな目標を立てる)

今回の、「コピーされるほど儲かるシステム」も

「コピーされるほど儲かるシステム」を作りたいのか、
「簡単に自分の作品を発表できるシステム(仕組み)」を作りたいのか、

はっきりしません。

こういうときは、どうするか。。。

適当な線の目標をたてて、それに、落とし込んで(誘導して)いきます。

適当な線とは、
・実行可能性が高い
・いろんな目標、抽象的な目標を、具体化している
 (あるいは、具体化しているように見える)
というものです。

 実行できない目標を掲げることは、それが出来た場合、たしかにプロジェクトX
のようにかっこいいですが、出来なかった場合、責任問題になります。
 その場合、処分されるのは、現場です。

 さらに、仮に成功しても、出来ない目標を無理に実行して犠牲者(うつ病になった
り、その他健康を害したり。。。)がでるのも現場です。
 現在のシステム開発の多くは、この無理な目標を実行しようとしているからだと
思います。どこらへんが、無理なのかは、今後、述べていくと思いますが。。。

 でも、成功すると、上の人たちは、「俺の目標設定が良かったからだ!だから、
できないなんて、言うべきでない」などと、現場の犠牲を省みず、平気で成功哲学
を並べ立てます。
 はっきり言い切ります。出来そうも無い目標をたてて、出来るのは、現場の努力
と運と、それを続けられる財務力です。別に上の人の指導力とか、目標設定のよさ
では、ないです。
 なのに、雑誌で成功者としてインタビューを受けるのも、上の人です。

 当然、こんなことをやっていれば、いつかは大きくつまずくのですが、
そんなことより、自分の身の安全です。
 目標は、出来そうなことにしましょう。
 それと、抽象的なのはだめです。目標になんないです。

 たとえば、「コピーされるほど儲かるシステム」の目標だったら、

 7話のExcelファイルを利用して、「自分の作品を発表できるシステム」をつくる

 というふうにしましょう。

 そうすると、要素は3つ
  ・7話のExcelファイルを作る
  ・自分の作品を発表できるシステムをつくる=>多分ホームページ
  ・「自分の作品を発表できるシステム」のどこかに「7話のExcelファイル」
   をつなぐ
 ということになります。この要素技術ができればOKです。
 これらの要素について、できそうだ!ということは、今後、示していきます。

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

目標の立て方について

2005-01-27 11:51:34 | 開発ネタ
 コンピューターシステムの目標でも、それ以外の目標でも、目標っていう
のは、大きく2とおりの考え方+なにも考えてないがあると思います。

 この2とおりの考え方について、ちょっと古くなりますが、日経ビジネスの
2004年10月4日号で、松井証券の松井社長を評した文が、分かりやすい
ので、ここに引用しておきます(以下、かぎ括弧内が引用)

「改革者には、旧弊などの世の中の問題を解決することに意欲を燃やすタイプ
と、夢のある世界の実現に意欲を燃やすタイプの2通りがある。
 後者はウォルト・ディズニーやソニーの井深大だが、松井は前者だ」

 この文は、楠木 建先生が、松井社長を評して言ったことで、目標について
述べたのもではないですが、目標についても、同じことが言えると思います。

 つまり、

・現在の状況の問題を変えるための目標
 →悪い見本にしろなんにしろ、一応ベースがある

・まったく新しい、夢のような(できるかどうかわからない)目標
 →ゼロベースで作る。出来ないリスク大

 目標の実現性としては、前者のほうが、可能性が大きい場合が多いです。
 また、企業としても、まったくゼロベースからはじめるということは、
他の人でもできる可能性があるということで、いままで蓄積してきたもの
を捨て、他者に追いつかれやすくなります。

 ただし、実現する際の障壁は、後者のほうが楽だと思われていると思います
(かならずしも、そうではない)。
 後者で、一番問題となるのは、できるかどうかわからないリスクです。
 実現できればそれこそ、「プロジェクト X」ものですが、出来なかったら、
みんなから、集中砲火で非難されます(で、システム開発では、出来ないこと
のほうが、多い気がする)

 システム開発的に大事なことは、前者と、後者では、進め方は違いますが、
どっちかなら、手が打てるということです。
 でも、もうひとつの「なにもかんがえてない目標」(実際これ、多い)の
場合、動きようが無いので、動けるまでの目標に、ブレイクダウンすることが
大切だと思います。

 なにも考えてない目標は、こんなのがあります。
 ・判断基準を示したもの(戦略に近い)
   例:このシステムを開発することによって、顧客とのコミュニケーションを向上する
     →で、どういうシステムを作りたいんだい?

 ・数値目標だけしか上げてないで、なにをしようとしたいかわかんないもの
   例:売上20%向上
   →どうやって??そもそも、システム作ると売上、上がるのか?

 ・総花的なもの
   なんとかの改善、かんとかの向上、。。。と並ぶやつ。。
   →で、なにがしたいの??

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

3月に発売されるSweetというケータイ

2005-01-26 13:59:18 | ケータイ
 3月に、お菓子をイメージしたSweetsというケータイが出るみたいですけど

http://www.itmedia.co.jp/mobile/articles/0501/25/news039.html

 どんなケータイかって、いうと
・あの昔懐かしい水森亜土が、待ちうけを描いている
・女性が持ったらいいけど、
・男性が持ったら、萌えと思われるやつだ
・機能はA5507SAと、あんまり変わらないらしい

 っていうことは、きっと、中身はひょっとしてA5507SAで、外観だけ変えた??
 うーん、それじゃあ、そのうち、萌えケータイとか、外観だけ萌えてるケータイとか、いろんなバリエーションが「他社からも」、「他キャリアからも」出そうな気が。。。

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

「コピーされるほど儲かるシステム!開発日記」第十号、26日発行

2005-01-25 11:09:45 | コピーされるほど儲かるシステム!
 このブログのメルマガ、「コピーされるほど儲かるシステム!開発日記」
の第十号が1月26日にでます(午前中、25と書いてあったのは、書き間違いです。明日です)。

 といっても、このブログしか見てない人は、「なんのこと??」と
わかんないと思うので、たまには、説明します。

--------

 このブログ&メルマガは、はじめ、「コピーされるほど、儲かるシステム
を思いついた!」って、ただ、それだけの動機で、はじめたものです。

 で、それを、
    ・開発する内容をまとめたものがメルマガ
    ・メルマガを書くために思いついたことを書くのが、このブログ
 です。

なので、ブログを読むと、意味がつながってないと思いますが、
 メルマガを読むと、意味がつながるように出来てます。

 現在メルマガは、その開発をするために、開発の初めの工程から、
順番に書いています。今回の10回目では、開発の一番初めの工程である
キックオフミーティング前後でやることを書いています。

ちなみに、そのメルマガのサイトは、ここ
http://www.geocities.jp/xmldtp/mag.htm
(まぐまぐを利用してます。まぐまぐの購読へのリンクもあります)

 
 で、そのメルマガについての、感想などは、ここの「コメント」にどうぞ!

 メールと、ウィリアムのいたずら自身のブログについては、このブログの
「コピーされるほど儲かるシステム!開発日記」へのメールについて
http://blog.goo.ne.jp/xmldtp/e/a58b79b40b1148c2f744556e27b76a79
を参照してくださいです。


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

ソケット間通信を使い、HTTPプロトコルを自分で送る場合、1.1の規約で送ろう!

2005-01-24 20:08:56 | Weblog
ソケット間通信で、ポートの80番を開いて、直接、HTTPプロトコルの
データを送って、webにアクセスしたいときってあるよね。
(提供されているHTTPプロトコルがうまく動かないときとか)

そういうとき、HTTPプロトコルの1.0を使って

GET / HTTP/1.0\n\n

って送ると、サーバーで、エラーになるサイトがある
(エラーコード302 一時的移動、リダイレクション使ってるところかなあ??
 はっきりしないけど)

そんなサイトでも、HTTP1.1のプロトコルで送ればOKの場合あり!
HTTP1.1のプロトコルは、ここにある
http://www.studyinghttp.net/rfc_ja/rfc2616.ja#sec5.1.2

その例だと、こんなかんじ。

GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org

たしかに、この形だったら、302エラーで帰ってくるところでも、OKだった。
(ちなみに、YAHOOは、1.0の上記の形でも、この1.1の形でも、どっちもOKなのよね)

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

ITILって、どーなんでしょー??

2005-01-22 18:04:21 | 開発ネタ
 最近のIT業界の話題って言うと、ITILがありますよね。

 ITIL(ITインフラストラクチャ・ライブラリ)の意味については、
http://www.atmarkit.co.jp/aig/04biz/itil.html
ちなみに、本家、イギリスのサイトは、ここのようだ。
http://www.ogc.gov.uk/index.asp?id=2261
 ちなみに、ITILを広める団体、itSMFの日本でのもの「itSMFジャパン」はこちら
http://www.itsmf-japan.org/

 この手の話って、かならず、「この技術を導入すると、ばら色に」
みたいな話があるけど、やっぱ、これにもあるのです。
こんなの
http://www.atmarkit.co.jp/fbiz/cbuild/serial/doukou/06/doukou06.html

 でもでも、うーん、どうなのかなあ。。。
 って、ウィリアムのいたずらが、よく知らないで書いたりしたら、
 関係団体の人なんかから、怒られそうな気もするので、やめとくけど。。。

 。。。うーん、どーなのかなあ??
 情報修理試験用には、勉強する必要のありそうな単語であることは間違いない。
 実務的には、参考にする価値はあると思うけど。。。


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

木梨憲武と片岡鶴太郎のホームページ

2005-01-21 19:22:19 | コピーされるほど儲かるシステム!
前に、歌手のホームページについて、どういう構成になっているか
しらべたので、今度は画家??と、写真家

■■ 画家のホームページと、項目

・木梨憲武(ちがうような気がするけど、YAHOOの画家>個人の作品集にあったので)
  http://www.kinashinoritake.com/
 項目:profile,About this site Gallery,News,Mail,Link

・片岡鶴太郎(うーん??)
  http://www.kataoka-tsurutaro.com/jp/index.html
 項目:プロフィール、ギャラリー、番組OAスケジュール、個展スケジュール、
  リンク

■■ 写真家のホームページと項目

・アラーキー
  http://www.kanroshobo.com/KANROKANRO/ARAKI/index.html
 項目:写真集、写真全集、書誌、販売目録、戻る

・篠山貴信
  http://shinoyama.cplaza.ne.jp/
 項目:会員登録、会員入口、はじめてのかたへ、ワンデイ、Whats'new
その他、有料のサイトへの入り口??

---

うーん、写真家の人は、すぐ、お金のにおいのするサイトなのね。

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

BREWで、ICAMERAで書き出すと、1枚目は書き出せるけど、2枚目以降、書き出せない場合の対策

2005-01-21 11:32:10 | ケータイ
またまたBREWねた。
 ICAMERA_RecordSnapshotを使って書き出したとき、1枚目は書き出せるけど、2枚目以降、書き出せないっていうときは。。。(同じファイル名で、何回も書き出そうとして、書けない。書く前にIFILEMGR_Remove()してるのに)

 ICAMERA_Release()のタイミングが悪いと、なんか、書き出したファイルがうまくクローズしてない気がするんだけど。。。はっきり、わかんないんだけどね??

 ICAMERA_Release()を、コールバック関数の、 CAM_STATUS_DONEで帰ってきたときに
やると、うまくクローズして、2枚目以降、ちゃんとかきだせることがあるみたいよ。

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

着Flashにみる、EA(エンタープライズアーキテクチャ)なんかの危険性

2005-01-20 18:28:15 | 開発ネタ
やっぱ、そうきましたか。。。って感じですね。
auは、「WINの新機種「W31SA」「W31K」に」「「着Flash」機能を搭載した」
http://www.kddi.com/corporate/news_release/2005/0120/index.html
ですね!

 うーん、やっぱり、au、BREWよりも、Flashのほうに行くんじゃない
かなあ、今後??
 そうすると、Docomoも、Flash動くと思ったから(バージョン違うけど)
今後の、ケータイのアプリ開発は、JavaやC(BREW)よりも、Flashで、
ってことになるかもね。

 こーいう、急激な外部戦略の大きな変化っていうのがあると、
EAなどやって、将来の全社的な情報管理戦略を立てている場合、
こまるよね。

 EAの場合、現状の業務プロセス(as-is)から、将来、どう変わる
べきかを(to-be)考えるけど、それを、情報戦略に落としていく
場合、現状の技術をベースに考える。

 たとえば、現状、営業日報を手書きしているけど、そんなのは、
ケータイから、出先で入力してもらうのがいい。
なーんて決まったとする。

 そうしたら、情報化戦略としては、ケータイの開発に力を入れる
だろうけど(だからJavaな人を増やすとか)、ある日突然、
「Javaより、Flashにしまーす!」って、
3大キャリアが決めちゃったら。。。
計画、まるつぶれ!

だから、EAとか、大きな計画を時間をかけて決めるより、
今の時代、外部変化をwatchして、その変化に合わせて、業務を
変えていったほうが、いいと思うよ。

つまり、定型業務のプロセスを決めるより、
異常系の処理手順をラフにきめたほうがいいってこと。


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

情報誌のホームページの作り方のまとめ

2005-01-19 12:17:03 | コピーされるほど儲かるシステム!
前の記事で、歌手の場合は、パターンがありました。
では、情報誌は、どうか?

-------

オリコン
http://www.oricon.co.jp/
HOME・ミュージック
    トピックス、ニュース、インタビュー、試聴・動画、リリース、
    CDレビュー、アーティスト情報、インディーズ
MOVIE
    ニュース、特集、予告編、リリース、DVDレビュー
ランキング


TVガイド
http://www.tvguide.or.jp/cgi-bin/top.cgi
 最新ニュース、番組表、映画情報検索、RECOMMEND、HOTインフォ、リンク
 Internet TVGuide Movie、今日のオススメ番組、TVガイドから

Tokyo Walker(Wakkers Plus)
http://www.walkerplus.com/tokyo/
 初めての方へ、会員ページ、新規登録
 東京、グルメ、映画、ウェディング、占い、旅行、カー&ドライブ、エンタメ、
 プレゼント、ショッピング、ケータイ、デジMONO

--------

情報誌の場合、特定のホームページの作り方というのはなく、
最新情報(トピックス)が載っていることぐらいしか、共通項は
ないです

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

各レコード会社のホームページの作り方のまとめ

2005-01-19 12:01:08 | コピーされるほど儲かるシステム!
前のブログで、「業務内容が決まってないで、業務を語れる人がいない場合は、
・他のシステムで、参考になるシステム、パッケージソフトを調べまくる。」
と書いた具体例。

これから、インディーズバンドなんかで、ホームページを作るとした場合、
どんな項目が、必要か?を調べるため、各社、売れていそうな?歌手の
ホームページにある、「項目を!」しらべてみました。

------

モーニング娘。(zetima)
http://www.helloproject.com/
項目:ニュース、新着情報、プロフィール、ディスコグラフィー、グッズ、
   ファン倶楽部、リンク、ハロー学園、ハローネット、
   メディア・イベント・ツアー情報、有料サイト

氷川きよし(コロムビア)
http://columbia.jp/~hikawa/
項目:Whats New、プロフィール、作品、制作秘話、ファンクラブ、スタッフリポート、
   インフォメーション、表紙、更新情報

大塚愛(エイベックス)
http://www.avexnet.or.jp/ai/index.html
項目:Whats New、Pickup Infomation、News & Infomation,Scedule,profile,
   Discography,Gallery,Diary,Special Contents,Request,BBS

ケミストリー(SONY ミュージック)
http://www.chemistryclub.net/pc/top.jsp
項目:Topics,Infomation,PROFILE,DISCOGRAPHY,BIOGRAPHY,BBS,Request,CLUB Member

-------

だいたいまとめると、
Whats New、プロフィール、作品、ファンクラブ、インフォメーション、
位が必要で、あとは、BBSとか、お好みで。。。というようです。


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

ビルゲイツによる、コピーの問題の発言

2005-01-18 15:36:19 | コピーされるほど儲かるシステム!
「コピーされるほど儲かるシステム」のメルマガの中でもとりあげた、
DRM(著作権管理)の問題や、さらにコピー=悪かどうかということに
関係したような話が、以下のページに出ているようです。

http://ittousai.org/gates_drm_interview.html
ビル・ゲイツ インタビュー : 共産主義者とDRM

しかーし!内容が(っていうか、いいまわしが)むずかしいぞ!
ウィリアムのいたずらには、よーわからん!
たぶん、メルマガでお話した内容のようなことだとおもうけど。。。
うーん(^^;)

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

業務について、語れそうな人がいないとき、どうシステム開発する業務を決めるか

2005-01-17 12:12:44 | コピーされるほど儲かるシステム!
 例えば、新規ビジネスのシステムを開発する場合などで、

    業務を語れる人がいないのに、
    開発するシステムを決めなきゃいけない場合、

 ってありますよね。
ソフト開発の教科書などでは、業務分析をして、システムを決めることになっている
ので、こういう場合、開発できない。。。けど、こういう開発って、ふつーに
ありますよね。
 こういう場合、どうするか?

ウィリアムのいたずらはこうします。

 ・他のシステムで、参考になるシステム、パッケージソフトを調べまくる。
 ・で、共通している部分をぬきだし、こんな業務じゃ、ないかなー??
  というものをつくる。
 ・そしたら、それを決定権者のところにもっていき、これで、いいっすか?
  と聞き、良くなかったら、他のものと入れ替える。

 この場合、業務が決まれば、あとは、いわゆる(パッケージソフトなどで行う)
フィットギャップ分析に落とし込めます。

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

今日から、情報処理試験の受付ですね。

2005-01-17 11:33:26 | Weblog
 今日から、春の情報処理試験の受付ですね。
http://www.jitec.jp/1_02annai/h17haru_exam.html

 「試験費用 5100円」!

 ウィリアムのいたずらは。。。
 うん、お金が入ってきてから、うけるかどうか、何をうけるかを
考えよう。今、5100円の出費は。。。最近のマックのクーポンを
使ったら、マックで、セットがいくつかえるか・・・

 と思ってしまいました。。。

(ちなみに、上記の問題の答えは、12個です。クーポンを使うと
 400円になりますので。あ、15日・16日のクーポン、
 22日・23日のクーポンを使うと、もっと買えます。
 わたしは、15日・16日のクーポンを3回も使いました。)


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

プロジェクト開発のデファクト(PIMBOK)に従うと、プロジェクトって、失敗しないか?

2005-01-15 19:32:40 | 開発ネタ
 プロジェクトマネジメントのデファクトとしては、PIMBOKがあげられると思う。
 しかし、PIMBOKの標準的な方法で行うと、プロジェクトは、自動的に、失敗しないか??

 PIMBOKでは、プロジェクトマネジメントを立上げ・計画・実施・コントロール・完了
にわけてますよね。で、行うべき内容が、「スコープ、タイム、コスト、品質、人的資源、コミュニケーション、リスク、調達、統合」という9つのエリアにわかれますよね。
参考:
http://coin.nikkeibp.co.jp/coin/nc/gk05/
 で、これはOK、さらにいうと、立ち上げもOK。

 でもねでもね、計画のところで、スコープ(つまり、開発の範囲)を決めた後で、タイムとか、コストにすぐに落とし込みますよね(この部分、今度、詳しく書きます)。

 たしかに、営業や、管理部門が長いプロマネや、プログラム書いてないSEから、プロマネになると、このやりかたでやるけど(まあ、そういう人が多いから、世の中の平均は、こうだけど)そーすると、失敗するよね。論理的に。。。

 だって、スコープに割った、開発範囲が出来る保証、無いじゃん。

 例をあげるよ。

 たとえば、au端末で、インベーダーゲームを開発するとする。
 このインベーダーゲーム、
   ・玉が、まっすぐ飛ぶのと、
   ・玉が斜めに飛ぶのでは、
 開発工数が、めちゃくちゃ違う危険があるよね。
 それ、スコープに割った時点じゃ、開発やったことないプロマネだと、わかんないでしょ。普通。

(ぜーんぜんわかんない人へ。
 au端末において、インベーダーゲームを作るとすると、BREWで開発することになる。
 玉がまっすぐ飛ぶ場合は、整数値で処理できるよね。
 玉が斜めに飛ぶってことは、三角関数を使うよね。BREWで三角関数使うのって。。。
 たーいへんなのよ ^^;)

 スコープに割って、そのあと、この開発の人をアサインして、期間決めちゃったら、
   開発中に、「えー、これって、どーやるの??」ってことになって、
   そのときに、みんなまじめで調査熱心な人だったら、
   どーする??三角関数で実現しようとしちゃって、
   ものすごーい工数かかって、その上、モジュールが大きくなりすぎて、動かない!
   って、どツボにはまって、開発工数が、何倍にもなっちゃうよ!

(ちなみに、いいかげんなウィリアムのいたずらなら、どうするかって?
 ななめに飛ぶ、玉の角度をきめちゃうの。そうすれば、三角関数つかわないで、
 ななめ「その一」のときは、Xいくついったら、Yいくつって、きめられるじゃん。
 そしたら、それを関数にすればいい。工数的に、そんなにかかんないよね。)


 つまり、スコープで割った後で、要素技術に展開して、その要素技術ができなかったら、
 人的資源にしろ、ソフトウエアにしろ、調達してこないといけないよね。
 で、その後調達のめどがついたら、コストとか、期間とか、人の割りふりとかって、決められる話だよね。もし、調達できないなら、(上の「ななめその一」のように)逃げ手を考えないといけないよね。逃げ手が思いついたら、その時点で、スコープって、変わっちゃうよね。


 で、さらに問題なのは、プロジェクトマネージャーが、要素技術に正しく分解できなかっ
たら、(例の場合、玉が斜めに飛ぶのは難しいので、そのリスクを取る必要があるって、
プロマネが気づかなかったら)おわっちゃうじゃん。

 つまり、今のPIMBOKっていうのは、技術的に、要素技術が全て分かっている場合
(昔の、銀行のオンライン勘定系システムの開発とか、小売店の会計システムの開発とか)
なら、それでOKなんだけど、最近の、
  ・うーん、できるかどうかわかんないよ。
  ・その技術と、この技術ってつながるわけ?相性とか、ないの??
  ・だれも、全部の範囲は分からない
  ・そのうえ、業務仕様も、わかんないぜい!
っていう、開発には、むいてないプロジェクトの考え方だと思うぜい!
  

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする