Mash up Award 2nd って、応募作品、全部公開すればいいのにね！

　Ｓｕｎがやっている、Mash up Award 2nd。

　ひょんなことから、（ただし、正当な理由。。あえて書かないけど、情報漏えいとかではなく、Ｓｕｎの側から公式に）応募者のタイトルが、ほぼ全部（全部とは言い切れない）わかってしまったわけだが（ウィリアムのいたずらだけでなく、応募しようとした人みんなにわかってしまったわけだが）、それをみると、みんな結構おもしろそうだよねえ。。

　これって、結局、賞をとった人しか、公開されないのかなあ。。
　そしたら、ほんのごくわずかしか、世の中に紹介されないわけで。。。

　もったいなーい！！

　ですよねえ。。
　きっと、これだけあれば、賞はとれなくても、見る人によっては、興味がありそうなものとかも、出てきそうだし。。

　これって、応募者がＯＫだしたら、賞を取るとらないに関係なく、公開するとかしたら、いいのになあ。。

。。。って思うのはウィリアムのいたずらだけ？？

グーグルの表計算ソフトは、株価をとってくる関数があるんだねえ！

ただし、当然アメリカの株価のみ、みたい。。。
ここのニュース
「Google Docs & Spreadsheets」のインターフェイスが日本語化
http://internet.watch.impress.co.jp/cda/news/2007/03/14/15088.html
によると（以下斜体は上記サイトより引用）、


　Googleが提供しているWebベースのワープロ・表計算アプリケーション「Google Docs & Spreadsheets」のインターフェイスが日本語化された。

　Google Docs & Spreadsheetsではこれまでも日本語の文書を扱うことは可能だったが、インターフェイスは英語などしか選択できなかった。今回、日本語のインターフェイスも選択できるようになった。


ってことなので、ためしてみました。

Google Docs & Spreadsheets
http://docs.google.com/

にいって、右側のところから、ログインして（すでに、アカウントは持っています）、
中に入ったら。。。この時点では英語、
で、右上のほうにあるsettingsを日本語にしたら。。

　ほんとーだー。。日本語になるう。。。

っていうので、いろいろあそんでいたら、こんな関数があるのをはっけん

=GoogleFinance("記号", "属性")、

記号に、"GOOG"のようなティッカーコード（アメリカの銘柄コード）、また属性に"price"のやつをいれるとGOOG（グーグルの意味です）の株価を表示するようです。

おお、Google、株価も表示するのね。。

これ・・・・・でも、あめりかの銘柄だけみたい。
日本の証券コードをいれてもだめだった。。ってあたりまえか（＾＾；）

日本のでも、やってくれると、うれしかったりするっていうか、
利用者増えるよねえ（＾＾）

開発の初めから順番に書いていってみる その９：立ち上げ（３）WBS

シリーズ「開発の初めから順番に書いていってみる」の続きです。
　前回、プロジェクトを立ち上げについて、契約書とプロジェクト憲章の話を書きました。
　で、前々回の順番でいくと、次は、計画プロセス群に入り、その中の、コアプロセスで考えると、以下の作業


（１）スコープ計画（スコープ）
　　　スコープ計画書として、プロジェクトの成果物と目標をきめて書く
　　　スコープマネジメント計画書として、どのようにプロジェクトを管理し、
　　　　　変更があったらどうするかをきめる

（２）スコープ定義（スコープ）
　　　ＷＢＳ（ワークブレークダウンストラクチャ）っていうものをつくり、
　　　システムを要素分解して、「何を」しなくちゃいけないかを決める


が次の作業となるので、それについて説明します。

---

■プロジェクトの範囲→ゴールをきめる

　はじめに、スコープ計画となります。

　スコープ計画のスコープというのは、やるべきものの範囲ということになります。
　したがって、ここで初めにやることは、プロジェクトの範囲を決めることとなります。範囲を決めるときは、出力＝成果物で決めていったほうがいいです。

　てなかんじで、成果物をきめます。

　目標とかもあります。
　で、これが決まると、プロジェクトのゴールが決まることになります。

　で、その次、プロジェクトについての決まりごと、どのように進め、どのように変更するかについて決めます。変更手順っていうのを決めておかないと（誰の承認をとり、ドキュメントをどう残し、それを、関係者にどう通知するか）、後々困ったりするのですが、たいてい決めないで、後々困ります（＾＾；）

---

■ゴールに向かって、何をするのか？というのをきめる。

　次のスコープ定義の段階では、そのゴールに向かって、「何を」するのかというのを決めます（「どうやって」ではありません。どうやっては、アクティビティ定義という、この後の段階で行います）。

　このとき、たとえば、ゴール＝システム開発に向かって
　　　・要求仕様をきめる
　　　・外部設計する
　　　・詳細設計する
　　　・プログラムする
　　　・テストする
　　　・引渡しの準備をする
　ってわけたとすると、さらに、
　「要求仕様をきめる」には、
　　　・ヒアリング前の準備をする
　　　・ヒアリングする
　　　・ヒアリング内容をまとめる
　　　・アクティビティ図を作成する
　　　・ユースケース図を作成する
　　　・ユースケースシナリオを作成する
　　　・ER図を作成する
　　　・制約条件をまとめ、非機能要件とする
　　　・要求仕様書を作成する

　　というふうにわけられ、さらに、じゃあ、「ヒアリング前の準備をする」とは
　　　・対象となるシステムの出力を確認する
　　　・出力の帳票をもらってくる
　　　・帳票分析する
　　　・入力項目を推測する
　　　・業務手順を推測する
　　　・必要なヒアリング内容をまとめる
　　　・そこからヒアリングする人を割り出す、
　　　　あるいはヒアリングする人が適切か確認する
　　　・ヒアリングシートを作成し、場合によっては質問前に相手に渡す
　　　　（事前に埋めておいてもらう）
　　　・ヒアリングのアポをとる
　　　・口説きのテクニックに気合を入れる（うそです　＾＾；）

　　みたいなかんじで、どんどんこまかくなっていく。

　　このように、”「何を」するのか”をきめて、
　　　　さらにその中から１つづつ取り出して、「何を」するのかをきめて、
　　　　　　さらにさらにその中から１つづつ取り出して、「何を」するのかをきめて、
　　　　　　　　　：
　　　　　　　　　：
　　と、どんどんどんどん、作業をブレークダウンして行き、それを図にしたのが、
　WBSです。

　WBSの書き方には大きく２種類あります。１つは、
　ここ　https://www.microsoft.com/japan/office/business/pm/solution/key04.html
　にある図のように、まさに、ブレークダウンの「図」にしてしまうもの。

　もう１つは、
　ここ　http://pmos.jp/honpo/method/WBS.htm
　の下のほうの図にあるように、表っぽくかくやつです。

　後者のほうは、ガントチャートを書いたとき、左側にはいってくるやつと似たような構造になります。

---

■WBSの項目のとりかたに大きく２種類ある。

　で、問題は、そのWBSをかくときに、どのようにブレークダウンするかなのですが、
　・構成要素によって分類する方法
　・作業要素によって分類する方法
　の２つがあります。

　普通考えると、「構成要素によって分類する方法」で書くものであるとおもいますが、PMBOK（２０００年度版）の例には２つとも載ってます。

　たとえば、後者の「作業要素によって分類する方法」は、上記の方法になります。

　一方、前者の構成要素によって分けていくとすると、
　今回の会社のシステムは、「受注」「発注」「マスタ管理」であり
　　「受注」は「受注入力」、「受注訂正」、「受注票出力」、「キャンセル」であり、
　　　「受注入力」は。。。。
　などというふうに、機能を構成する要素に分解して、それでブレークダウンして行くいき方です。

---

■ただし、要求定義においては、構成要素によって分類できないことが多い

　しかし、機能について、よくわかんないので、これからヒアリングに行くわけです。その状態で、機能に分けろといわれてもねえ（＾＾；）ってなわけで、しかたないから、要求分析の段階では、作業要素で分類しておいて、それ以降内容が分かったところで、構成要素に展開するということなると、思います。

　ただし、要求仕様ができた段階で、構成要素に分けられないとしたら、それは、要求仕様に問題があります（が、実際には、そういうことは、よくありますけどね）。

　なお、作業の要素にわけることは、開発方法論を決めてしまえば、要求段階を同進めるのかという手順はたいてい決まっているので、できます。
　つまり、ここで、開発方法論を決めてしまう必要があります。

---

　ということで、今回のところで、開発の成果物をきめ、WBSを、作業要素でとりあえずつくり、要求仕様作成のためのWBSがとりあえずできたと仮にします。
　で、話を先に進めたいと思います。