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

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

ソフトバンク、「ホークスケータイ」の次は「横浜F・マリノス オフィシャル携帯電話」

2007-01-16 22:26:51 | Weblog

 以前、ソフトバンク、「ホークスケータイ」来春以降に発売っていうのを紹介して、そこで、

でも、この手のやつって、今後、いろんなのが出せそうですよね。。。

たとえば、サッカーの各チームのケータイ、
「浦和レッズケータイ」とか。。

って書いたけど、世の中、おんなじことを考えているのですね(^^;)

ここのプレスリリース
「横浜F・マリノス オフィシャル携帯電話」を1,000台限定販売
~サッカーチームとしては日本初の特別限定モデル携帯電話~
http://www.softbanktelecom.co.jp/release/2007/jan/0116/


横浜F・マリノス携帯電話がでるそうです。。

でも、スラッシュドットに(以下、斜体はリンク先のスラッシュドットの記事から引用)


ソフトバンクモバイルの方は旧ボーダーフォン時代から同じくJ1の浦和レッズのスポンサーであったが、今回のような公式携帯電話の発売はしていなかった。今後はシェア拡大とあいまって他のスポーツスポンサーでも同様の動きが出てくるのであろうか?


なぜ、横浜F・マリノス?

ひょっとして、他のスポーツではなく、ほかのチーム、つまり、浦和レッズとかも、今後やっていくのかなあ?

ところで、他のキャリアも同じ様なこと、考えるのかなあ??


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

ユースケースシナリオを作る方法

2007-01-16 17:59:40 | 開発ネタ

 DOAやオブジェクト指向の図を業務をまとめたシートと、入出力についてまとめたシートをつかってつくるというシリーズの話の続きです。

現在、
 DOAの
   ・DFD
   ・ER図

 オブジェクト指向の
   ・アクティビティ図
   ・ユースケース図

 については、書きました。
 クラス図については、先にフレームワークを決めないとということで、ちょっと置いてあるので、
 今回は、ユースケースシナリオにいきます。
 といっても、前回、アクティビティ図から書くケースの問題については書いたので、今回は、業務をまとめたシートから、ユースケースシナリオに落とす話です。




■ユースケースシナリオを作る手順

 で、ユースケースシナリオを作る手順について。

●1.まず、何のシナリオを書くか、きめる。
 1つの業務でも、いくとおりのケースがありえる場合がある。
 たとえば、給与計算でも、アルバイトで時給の人の場合、社員で年俸制の人の場合、超えらい社長さんでは、計算方法、いや入力方法からちがうかもしれない。
 そのように1つの業務で、いくつものケースがある場合、それぞれが、ユースケースになりえる。そこで、どんなケースがありえるか考え、そのうち、今はなにについて書くかを決める。

 このとき、利用者指向で外部入力を分析、体系化してるとやりやすい

●2.対象業務の入力を決める
 いまから、ユースケースシナリオを書こうとしている業務の、入力値をきめて、それを書く。
 このとき、業務をまとめたシートの入力項目について、実際の値を決めて書くわけなのだが、その際、入力項目で、自分のアクティビティの子アクティビティになっているものに関しては、その時点で入力するので、いまは書かなくていい。それ以外の入力値(システムを動かす前から決めておくべきような商品に関する情報など)をきめて、初期状態の値とする。

●子アクティビティを書く(入力:処理:出力)
 その後、そこに書いてある子プロセスについて、
   **を入力とし、~~を行い、XXを出力する
 と書いていくのだが、このとき、入力とは、システム外部からの入力について書く
 (つまり、画面入力とか)

 子アクティビティ間でやりとりする変数は書いちゃダメ!とは言い切れないが、

 ユースケースシナリオは、お客さんが見て、合意をとる可能性があり、その際、このアクティビティで、ABCという値が出力され、そのあとで、次のプロセスが入力し。。とかいっても、そのABCが、内部の変数だったら、お客さんにとっては、???なので、書かないほうが、すっきりすると思う。

 そうすると、あくまでも

   **を入力とし、~~を行い、XXを出力する

 は、基本形であり、入力がなかったり、出力がないときもある。

 画面入力、DB書き出しなどについて、書かれることになる。
 なお、値は、具体的な値を記述する(画面を書くというケースもありえる)。
 また、入力、出力に関しては、子アクティビティのシートの、入力、出力を参照する。

●そうすると
 最終的に、何ができているはず。。っていうのを、具体的に書く

●これをまとめる
 ひとつにまとめる。




こんな感じだと思います。


 

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

「著作権フリー国家」樹立を目指し、BitTorrentサイトが「世界最小国家」買収に名乗り

2007-01-16 15:43:54 | Weblog

ここのニュース
「世界最小国家」買収にBitTorrentサイトが名乗り
http://www.itmedia.co.jp/news/articles/0701/16/news027.html

によると(以下斜体は上記記事より引用)


 スウェーデンのBitTorrentトラッカーサイトThe Pirate Bayが、売りに出されているシーランド公国の買収を計画している。

 The Pirate Bayは、P2PネットワークBitTorrentでコンテンツをダウンロードするための「トラッカー」を提供する世界最大のサイトとうたっている。昨年スウェーデン警察により著作権侵害のかどで閉鎖されたが、その後再開した。

 一方シーランド公国は、英国の沖合に位置する小さな人工島を領土とする「国家」。40年前に元英国陸軍少佐のパディ・ロイ・ベーツ氏が移り住み、独立を宣言した(ただし、同国を独立国家として承認している国はない)。先日、同国が6500万ポンドで売りに出されたことが報じられた。

 The Pirate Bayはシーランド公国買収のための寄付を募るサイトBuy Sealandを立ち上げ、公国買収の暁には、寄付をした人は公国民になれるとして寄付を呼びかけている。

(中略)

 The Pirate Bayは早速シーランド公国との交渉を開始しており、1月16日にThe Pirate Bayを支援するネット人権団体ACFIと同国政府関係者がネット上で今後について会談すると報告している。



著作権違反をかわすため、国家ごと買収。。

そ、その手があったか。。(^^;)


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

普通のアーンドバリューマネージメントを個別プロジェクトでやる場合の手順

2007-01-16 14:48:49 | Weblog

 まえに、事業別の管理において、変動費部分はEVM(アーンドバリューマネージメント)ってかいたけど、そもそも、アーンドバリューマネージメントに関し、ふつうの計算の仕方について、まとめていなかったので、まとめておきます(前の場合にはこれをアレンジした形で、情報処理試験で載っていた形で紹介したんですけど、今後その方法は、問題が出そうな気がするので。。それについては後に書きます)




■まず、ふつうにEVM(アーンドバリューマネージメント)とは

 その内容は、ここ
EVMS(前) 
http://pmos.jp/honpo/method/EVMS1.htm

が詳しいと思います。

 つまり、計画をたてて(PV)、達成度合いを元に金額を換算した場合(EV)と、実際のかかった金額(AC)をだし、

   達成度合いを元に金額換算(EV)-計画値(PV)=スケジュール差異(SV)

で、スケジュール上の問題を計算し、

   達成度合いを元に金額換算(EV)-実際のかかったお金(AC)=コスト差異(CV)

で、コスト上の問題を分析します。




■実際のプロジェクトの場合

 プロジェクトの場合は、

1.まず、WBSなどでプロジェクトの工程が、いくつかの部分に分かれると思います
  (まったくわかれないで、1つだと、困るんです >_<!)

2.で、その工程ごとに、工数と、単価が出ると思うんです
  っていうか、出して!
  そして、その工数と単価をかけたものが、計画値であるPVになります。

3.では、ある日の状況について、アーンドバリュー分析してみましょう。

 たとえば、1日2個ずつ画面を作成し、5日で10個、1日3万円ずつ支払うと
 いう計画があったとする。

 今日が3日目だとすると、1日2個だから、6個完成していて、
  (1日あたり)3万円 X 3日 =9万円、これが、計画値PV

 だけど5個しかできてなかったとすると、

  1日あたり2個なので、5個÷2個=2.5日分っていうこと。
  (1日あたり)3万円 X 2.5日 =7万5千円、
      これが、達成度合いを元に金額換算(EV)

 でも、徹夜して作ったから、実際には残業代がかさみ10万!
 この10万が実際のかかったお金(AC)

4.上記PV(例だと9万)、EV(例だと7.5万)、AC(例だと10万)
  をつかって、コスト差異、スケジュール差異などを求めます。

  他の式や、評価法については、上記にあげたサイトの後半
EVMS(後)
http://pmos.jp/honpo/method/EVMS2.htm

 を見てください




■情報処理のときの問題点

 情報処理ででてきたEVMの変形の話は、実際のコストまでも、すべて時間で計算していたと思います。これは、昔は有効でした。時間を意識していたので。。。

 でも、ホワイトカラーエグゼンプションとか、サービス残業とか導入されると(って、サービス残業は、「導入」なのか?)時間いくら働いても、かんけいないわけです。

 とすると、今後、時間って言うのは、アーンドバリュー上は関係あるかも知んないけど(達成期日という意味で)実計算上は、関係なくなるのかなあ。。っていうことで、やっぱり、ちゃんとした式にしたほうがいいかと。。




■さらにすすむと。。

 さらに進むと、時間がPV、EVでも必要なくなります。

1.WBSにより、いくつかの工程にわけ、その工程に対して、お金を割り振り

2.今日までに達成していなければいけない工程を合計した金額がPV
  実際に達成した工程を合計した金額がEV
  支払ったお金をAC
  として

3.以下コスト差異、スケジュール差異計算します。

たとえば、工程A=50万、工程B=30万、工程C=20万として、

 現時点で、工程Aが完了、工程Bが、20%終わってるはずだとすると、
  PVは、50万X100%+30万X20%+20万X0%=56万

 でも、今、工程Aが80%、工程B,Cとも手付かずだとすると、
  PVは、50万X80%=40万

 で、実際には、残業した人がいるので、100万はらったとすると、ACは100万

 などというようにもできます。
 こうすると、時間というよりは、いま、工程のどこまでできていないといけないかという判断さえできれば、使えるので、こっちのほうが、便利になってくるかも。。



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

アクティビティ図から、ユースケースシナリオを作る方法が紹介されてるけど。。

2007-01-16 13:15:24 | 開発ネタ

 DOAやオブジェクト指向の図を業務をまとめたシートと、入出力についてまとめたシートをつかってつくるというシリーズ話、クラス図はすぐにできないということで、ちょっとおいておいて、ユースケースシナリオについて書きたいと思います。

 その際、ちょっと「うーん!」という話をまず書いてから、シートからシナリオに落とす方法を書きたいと思います。



前に紹介した本、

UMLシステム設計実践技大全 ナツメ社 ISBN: 4-8163-3635-4

の82ページ83ページに、「アクティビティ図でシナリオを代替する」という方法があります。これは、アクティビティは機能であり、データ入出力がないので、コメントでデータ入出力を書くというものです。

 ひとつの方法であり、これで済むときもあるのですが、問題もあります。




 その問題というのが、入出力は、画面やDBというケースも多いわけです。
 そうすると、コメントに画面全体の項目を書くとか、複数のテーブルの内容を書く(^^;)っていうのもねえ。。っていうか、実際、かけないしって言うことになります。

 そうすると、できることといえば、入力:受注画面(別紙32)とか、そいういふうに別の紙に書くしかないことになります。

 その場合、アクティビティ図と別の紙。。ってなるんだったら、いっそのこと、全部ワープロで初めからすんなり読めるように、シナリオを書いたほうが。。。(^^;)

 っていうことになります。

 まあ、ケースバイケースではあるわけなんですが。。




 でも、ここではちゃんと、シートからシナリオを作る方法を考えたいと思います
 (といっても、次回のこのシリーズで、なんですけどね)




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

開発部門、プロジェクトの損益を、セグメント別損益計算で考える

2007-01-16 01:53:17 | Weblog

■セグメント別損益計算書のしくみ

 事業部別損益計算書

1.売上高
2.変動売上原価
------------------
 変動製造マージン
3.変動販売費
-------------------
  貢献利益
4.個別固定費
-------------------
 セグメントマージン
5.共通固定費(合計から引く)
-------------------
  営業利益

これを、各事業(セグメント)ごとに求める。

ここで、個別固定費と共通固定費の違いは、

個別固定費;各事業に直接結びついた固定費
共通固定費;全体の固定費




■事業部の評価

・貢献利益率:収益力を示す

・セグメントマージン:共通固定費を回収して、利益を生み出す貢献額
 貢献利益率が高い(収益力がある)のに、セグメントマージンが低いと、問題がある。
 セグメントマージンがマイナスにならない限り、存続する価値がある。
 
・管理可能営業利益
 事業部売上高-変動費-マネジド・コスト

 マネジドコスト:個別固定費を以下の2つに分ける
  マネジドコスト(管理可能個別固定費)
   経営方針を変えれば、変更可能(広告費、接待費など)
  コミテッドコスト(管理不可能個別固定費)
   一度決めると、ある一定期間にわたって、変更不可能で発生する
   (機材の減価償却など)

・ROI
 管理可能営業利益を管理可能投資額で割る




■開発プロジェクトで考えると

 変動費の部分は、人件費、外注費になってくる。

 個別固定費は、そのプロジェクトで発生した、そのほかの製造間接費
(教育費用なども配賦したほうがいいと思われる。求人はそのプロジェクトとヒモ付けできれば。。)

 共通固定費は、それ以外の製造間接費

 変動費の評価(貢献利益が良いか悪いかの評価)は、
 EVM(アーンドバリューマネージメント)のほうが、しやすいと思う。

 なお、教育などを、社内でやっている場合、その時間によって、費用を決めてしまうような、内部振替価格と同じような処理をしたほうがいいかも。。

参考文献:大原簿記学校 ALFA 1級過程 工業簿記・原価計算 B


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