ウィリアムのいたずら @xmldtpドコモ、Tizen OS搭載スマホの導入を当面見送り headlines.yahoo.co.jp/hl?a=20140116-…
GlassFishの商用乗り換え先について(補足)
http://www.mushagaeshi.com/2013/12/08/from-glassfish-to-other-commercial/
に、（以下太字は上記サイトより引用）
※念のため更に補足しておきますが、Interstageが将来GlassFish 4.x系をそもそも採用するかどうか、また仮に採用したとしてもそれはいつなのか、というのは全く不明なので、もし気になる方は富士通の営業さんに実際に問い合わせてみましょう。
とあるが、これは、実は富士通のWebソリューションの生死を決め、
答えようによっては、天国と地獄の差があるのだが、
みんな、気づいていないかもしれないので、ちょっと、そのへん
を書いてみる。
富士通のWebソリューションの場合、アプリケーションサーバー
には、Interstage Application Serverが使われる。
現在、Interstage Application Serverには、以下のWebサーバー
が構築できる
・Apache 2.2
・Tomcat 5.5
・GlassFish 2.X(JavaEE5)
・GlassFish 3.X(JavaEE6)
ここで、JavaEE6以外は、現状JRE6しか選べない。
新規でシステム構築をする場合、わざわざ、世間でEOLになっている
ものを選ばない（セキュリティパッチが出ないので、富士通が対応
してくれないと、こまるから）。
Tomcat5.5は、EOLになっている。最新版は８
JRE6の無償版の公式アップデート終了は、2013年2月商用版 Premier Support
の終了は2013年12月でどちらも終了している。
もっとも、Oracleも商用版は、Extended Support、Sustaining Supportは続いているし、そもそもInterstageのJREは、富士通が修正を加えていませんでしたっけ？（FUJITSU_MODIFIED）なので、富士通サポートになるけど、わざわざ、新規開発でEOLのものを選ばない。開発環境がベンダーロックインされるから
(具体的にいうと、開発するとき、Tomcat5.5,JRE6を入れないと、Interstageと同じ環境にならないとしたら、それで開発する・・・って、EOLだからだめじゃん！Interstage、開発時にも入れるの？ってこと・・・）
とすると、EOLになっていないものを選択する場合、Interstageでは、「GlassFish 3.X(JavaEE6) JRE7」の組み合わせしかない。
で、これで開発するのなら、問題はない。
問題になるのは、将来だ・・・
すでに、GlassFishは４、JavaEEは7になっている。
ここで、GlassFishの４なのだが、
GlassFish Community便り
http://www.coppermine.jp/docs/programming/2013/12/from-glassfish-community.html
によると、（以下斜体は上記サイトより引用）
GlassFishにとっての地獄は、当初GlassFish 4.1から予定していたOracleによる商用サポートが打ち切りとなったことと、それによって引き起こされたといっても過言ではない混乱でしょう。GlassFish 3.1.xの商用サポートは継続するものの、商用サーバーとしてのGlassFishはその将来を絶たれたことになります。
ということだ。
Oracleでは商用サポートが必要な場合はGlassFishからWebLogicへ移行するようアナウンスしていますが、GlassFishとWebLogicのデプロイメント・デスクリプターの互換性は（Oracleのアナウンスに反して）完全ではなく、移行に関しては十分な検討とテストが必要となります。
とのこと。
ここで、Interstageに話を戻すと、Interstageは、GlassFishの商用乗り換え先について(補足)の「何を基準に決めればいいのか」の図にあるように、GlassFishのコピー（デプロイ先など一部修正）の形になっている。したがって、
もし、Interstageが、GlassFish4,JavaEE 7をサポートするのであれば、
Oracleはサポートしないので、
GlassFishを商用サポートする、唯一のメーカーになる。
これ、天国！
しかし、Interstageが、Oracle同様、GlassFish4をサポートしないので
あれば、今後の製品構成は、全く見えない。
GlassFish 3.X(JavaEE6) JRE7を続けるのか？
JavaEE7に対応するサーバーを新たに作るのか？
その判断が聞けないまで、InterstageのJavaEEを採用するのは怖い
・・・となると、いまのところは
「GlassFish 3.X(JavaEE6) JRE7」
だけど、今後はわからない・・・さすがにそれは・・・・
となってしまう（これが地獄）
Oracleが、GlassFish4.0を商用サポートしなくなった以上、
「富士通はGlassFish4.0をサポート（します／しません）」
の一言が、今後のWebソリューションの生死を決めることとなり、
その一言がはっきりするまで・・・様子見となってしまう。
P.S あ～ここまででかなり長くなってしまったので、
ここで切る。本来は、この後に、これでさらに複雑になる
Interstage Application Server WSEの話を書きたかった
んだけど、それは次回！
一橋の延岡先生に、意味的価値のお話をしていただく
講義をこの前とったので、その内容をメモメモ
（たぶん、このブログでも、今後、意味的価値の話を
すると思うので・・・）
価値づくり経営：意味的価値のマネジメント
すべての商品が１割高く売れれば
→価値作りがしっかりできれば・・・
消費財は難しい・・・
→生産財
価値：お客さんの使い方
キーエンス
９０％を９５％にするのが価値？
お客さんの価値：材料によって違う
電話の価値は人によって違う
お客さんが儲かれば→お金をくれる→そこ提案
消費財も生産財も同じ
ブランド品
価値作りの重要性
価値作り＝付加価値
ここをちゃんとやる→福祉に役立つ
付加価値＝総利益みたいなもん
キーエンスは４００億円の法人・所得税
→ってことは、１人あたり２０００万国に寄付してるってこと
→その一部は、東北に行ってるんだよねえ・・
→みんな、いくら寄付した？
付加価値
コーヒーは付加価値が高い（原価に比べ、売価は・・・）
→でも、付加価値高いとは言わない？？
薄型テレビ：４０インチ４万円とか・・・
→テレビ：ものづくりはすばらしい！
シャープがなければ、世界の人はまだブラウン管を見ていただろう
でも、社会貢献していない→必要ないことしてる
やらなくていいことしてる：
ヤマダ電機の品揃えに貢献してるだけ
競争が激しい
１００点満点が５社も６社も
→なら６０点なことを、できることをしたほうがいい。
アップル：前の晩から人が並ぶ
機能的価値だけではX
安く作って、高く売る
ジェネリック：２０年前の薬でもいい
→オープンイノベーション
DVDプレーヤー：ものすごく売れても、儲からない
→利益は増えた：販売管理費を減らした
消費税：１％で２兆円、１兆円→トヨタ一発がんばれば・・・
電機：優秀な人が集まっているのに、儲かってない・・
価値作りがイノベーション
電機が苦しい
・モジュール化して簡単になった
・戦略が難しい
ダイキン
・エアコン世界一
→M&A
ジョブスはiphoneとipadだけ考えられる。
スマホメーカーの社長は？→それでジョブスに勝てるのか？
富士通と全産業の営業利益率が同じ
昔；ものづくりで顧客価値決まってた
今：なんにもできないiphoneを買う
競争が一番きびしい
→大きな、成長している市場；成功している確率ひくい
→市場分析して、絶対儲からない市場にいっている
パナソニックがもうかっているところ：アビオニクス
小さいところで、ちゃんと儲けるところがないと
→競争なんかない市場
→小さい市場のほうが安定する
５０億くらいの事業をちゃんと立ち上げられるか
立ち上がったところ＝短くなった
亀山工場フル稼働２００６年→VIZIO２００７年
Apple：最近はかなりガラパゴス的？
APPLEの設備投資６０００億
WII
商品コンセプト
メディアテック
困ったらアプリケーションエンジニア
村田製作所
キーエンス
カシオ
商品コンセプトで負けないように力をいれている
生産財：もうちょっとまじめに価値作りしよう！
ヒートテック
→ユニクロの技術は東レ
東レでは同じものが売れなかった。ユニクロがうった
プリウス：意味的価値
→ほかにもハイブリッドあるのに・・・・
シスメックス
コマツ
使い方：お客さんの価値
中国：稼働率３倍、人件費安い、燃料費のほうが重要
→燃費いいほうが重要
お客さんが儲かること大事！
トヨタ：部品メーカーを教える
→海外では全然できてない！
ipad：サルでも使える
量販店で
４０インチ薄型テレビが４万円で、
炊飯器が６万円？
アルフレッドが自動車の文化を作った
差別化・競争力の源泉になりえる領域
第一段階
深層の顧客ニーズの理解
→顧客の現場を知る仕組み
第二段階
意味的価値を持った商品の開発
→商品企画力
→才能依存的：才能がある人を選ぶ仕組み
→任せる人を選ぶ
→優秀なやつは、意外と普通
マツダ：走り重視
集中して狙ったものが、意外とマスにいってしまう
生産財の意味的価値（一橋ビジネスレビュー３月）
・お客さんが気づいていない経済的価値が上がる
気づかれてしまっている→ルネサス
気づかれていない→ディスコ
・顧客以上に知る
顧客起点→お客の中に入って
市場起点→マーケティング
昔の顧客起点：ある特定の顧客→それじゃだめ
営業の評価：情報を集める
ニーズカード、お役立ちデータベース
・情報を集める
・商品企画を作る
講義をこの前とったので、その内容をメモメモ
（たぶん、このブログでも、今後、意味的価値の話を
すると思うので・・・）
価値づくり経営：意味的価値のマネジメント
すべての商品が１割高く売れれば
→価値作りがしっかりできれば・・・
消費財は難しい・・・
→生産財
価値：お客さんの使い方
キーエンス
９０％を９５％にするのが価値？
お客さんの価値：材料によって違う
電話の価値は人によって違う
お客さんが儲かれば→お金をくれる→そこ提案
消費財も生産財も同じ
ブランド品
価値作りの重要性
価値作り＝付加価値
ここをちゃんとやる→福祉に役立つ
付加価値＝総利益みたいなもん
キーエンスは４００億円の法人・所得税
→ってことは、１人あたり２０００万国に寄付してるってこと
→その一部は、東北に行ってるんだよねえ・・
→みんな、いくら寄付した？
付加価値
コーヒーは付加価値が高い（原価に比べ、売価は・・・）
→でも、付加価値高いとは言わない？？
薄型テレビ：４０インチ４万円とか・・・
→テレビ：ものづくりはすばらしい！
シャープがなければ、世界の人はまだブラウン管を見ていただろう
でも、社会貢献していない→必要ないことしてる
やらなくていいことしてる：
ヤマダ電機の品揃えに貢献してるだけ
競争が激しい
１００点満点が５社も６社も
→なら６０点なことを、できることをしたほうがいい。
アップル：前の晩から人が並ぶ
機能的価値だけではX
安く作って、高く売る
ジェネリック：２０年前の薬でもいい
→オープンイノベーション
DVDプレーヤー：ものすごく売れても、儲からない
→利益は増えた：販売管理費を減らした
消費税：１％で２兆円、１兆円→トヨタ一発がんばれば・・・
電機：優秀な人が集まっているのに、儲かってない・・
価値作りがイノベーション
電機が苦しい
・モジュール化して簡単になった
・戦略が難しい
ダイキン
・エアコン世界一
→M&A
ジョブスはiphoneとipadだけ考えられる。
スマホメーカーの社長は？→それでジョブスに勝てるのか？
富士通と全産業の営業利益率が同じ
昔；ものづくりで顧客価値決まってた
今：なんにもできないiphoneを買う
競争が一番きびしい
→大きな、成長している市場；成功している確率ひくい
→市場分析して、絶対儲からない市場にいっている
パナソニックがもうかっているところ：アビオニクス
小さいところで、ちゃんと儲けるところがないと
→競争なんかない市場
→小さい市場のほうが安定する
５０億くらいの事業をちゃんと立ち上げられるか
立ち上がったところ＝短くなった
亀山工場フル稼働２００６年→VIZIO２００７年
Apple：最近はかなりガラパゴス的？
APPLEの設備投資６０００億
WII
商品コンセプト
メディアテック
困ったらアプリケーションエンジニア
村田製作所
キーエンス
カシオ
商品コンセプトで負けないように力をいれている
生産財：もうちょっとまじめに価値作りしよう！
ヒートテック
→ユニクロの技術は東レ
東レでは同じものが売れなかった。ユニクロがうった
プリウス：意味的価値
→ほかにもハイブリッドあるのに・・・・
シスメックス
コマツ
使い方：お客さんの価値
中国：稼働率３倍、人件費安い、燃料費のほうが重要
→燃費いいほうが重要
お客さんが儲かること大事！
トヨタ：部品メーカーを教える
→海外では全然できてない！
ipad：サルでも使える
量販店で
４０インチ薄型テレビが４万円で、
炊飯器が６万円？
アルフレッドが自動車の文化を作った
差別化・競争力の源泉になりえる領域
第一段階
深層の顧客ニーズの理解
→顧客の現場を知る仕組み
第二段階
意味的価値を持った商品の開発
→商品企画力
→才能依存的：才能がある人を選ぶ仕組み
→任せる人を選ぶ
→優秀なやつは、意外と普通
マツダ：走り重視
集中して狙ったものが、意外とマスにいってしまう
生産財の意味的価値（一橋ビジネスレビュー３月）
・お客さんが気づいていない経済的価値が上がる
気づかれてしまっている→ルネサス
気づかれていない→ディスコ
・顧客以上に知る
顧客起点→お客の中に入って
市場起点→マーケティング
昔の顧客起点：ある特定の顧客→それじゃだめ
営業の評価：情報を集める
ニーズカード、お役立ちデータベース
・情報を集める
・商品企画を作る
放送大学は、現在修士が取れる大学院を設置してますけど、
今度、博士課程もおくようになったみたい。
で、興味しんしんなのは、情報系があるかどうか・・・
だと思うけど、
放送大学大学院博士後期課程の設置について
http://www.ouj.ac.jp/hp/o_itiran/2013/251031.html
(以下太字は、上記サイトより引用）
・プログラム：生活健康科学、人間科学、社会経営科学、人文学、自然科学
・募集人員：博士全科生 １０名 （科目生・選科生は募集しません）
うん？？情報としては無いんだねえ～
社会経営科学か自然科学か・・・
ってか、１０人しか募集しないの？全国で１０人？
今後増やすのかなあ・・・
ちなみに、スケジュールは、こんな感じらしい
学生募集に関するスケジュール
・学生募集要項公表： 2014年1月中旬
・出願受付期間： 2014年4月中旬 ～ 4月下旬
・入学者選考
第１次選考（筆記試験）： 2014年6月初旬
第１次選考合否通知： 2014年7月初旬
第２次選考（面接試問）： 2014年7月中旬
第２次選考合否通知： 2014年8月初旬
・2014年度入学者の入学時期： 2014年10月1日
つまり、今年１０月募集の人のはなし・・
来年からは
（2015年度以降の入学者の入学時期： 4月1日）
らしい・・・
ってことで、情報系・無線系が無いので、ここで報告終わり！
今度、博士課程もおくようになったみたい。
で、興味しんしんなのは、情報系があるかどうか・・・
だと思うけど、
放送大学大学院博士後期課程の設置について
http://www.ouj.ac.jp/hp/o_itiran/2013/251031.html
(以下太字は、上記サイトより引用）
・プログラム：生活健康科学、人間科学、社会経営科学、人文学、自然科学
・募集人員：博士全科生 １０名 （科目生・選科生は募集しません）
うん？？情報としては無いんだねえ～
社会経営科学か自然科学か・・・
ってか、１０人しか募集しないの？全国で１０人？
今後増やすのかなあ・・・
ちなみに、スケジュールは、こんな感じらしい
学生募集に関するスケジュール
・学生募集要項公表： 2014年1月中旬
・出願受付期間： 2014年4月中旬 ～ 4月下旬
・入学者選考
第１次選考（筆記試験）： 2014年6月初旬
第１次選考合否通知： 2014年7月初旬
第２次選考（面接試問）： 2014年7月中旬
第２次選考合否通知： 2014年8月初旬
・2014年度入学者の入学時期： 2014年10月1日
つまり、今年１０月募集の人のはなし・・
来年からは
（2015年度以降の入学者の入学時期： 4月1日）
らしい・・・
ってことで、情報系・無線系が無いので、ここで報告終わり！
日経コンピューター２０１４年１月９日（特集が機械学習関係）の
「消費税対応、６つの落とし穴」だけど、４９ページに
「これから特需が来るかは未知数」とある。
来るかどうかは、パラメータを変えたあとに、
どこまでチェックするかだよね！
変えただけで終了したら、たぶん、特需はこない。
変えた後、一応全部リグレッションテストをすれば、
ある程度の工数になるので・・・
ただ、人命に関わることではないので、
そこまで厳しくは障害を問い詰められないとなると、
まあ、テストもそこまでやる必要は無く・・・
「消費税特需は、こない」
と考えるのが、妥当なんですかね・・・
「消費税対応、６つの落とし穴」だけど、４９ページに
「これから特需が来るかは未知数」とある。
来るかどうかは、パラメータを変えたあとに、
どこまでチェックするかだよね！
変えただけで終了したら、たぶん、特需はこない。
変えた後、一応全部リグレッションテストをすれば、
ある程度の工数になるので・・・
ただ、人命に関わることではないので、
そこまで厳しくは障害を問い詰められないとなると、
まあ、テストもそこまでやる必要は無く・・・
「消費税特需は、こない」
と考えるのが、妥当なんですかね・・・
「ジェネリック家電」 消費増税後も存在感 機能絞り割安…人気ジワリ
http://news.goo.ne.jp/article/sankei/business/snk20140114070.html
機能を絞り込んだり、旧世代の技術を使う家電を「ジェネリック家電」と
いうらしい。
実は、コンピューターでも、MS-Accessをレポートジェネレーター
（帳票作成用につかう。データは、他のところで加工し、それを受け取る）
として使い、Excelでデータ加工するという、旧世代の技術を使うと、
結構、システム開発しないで済むはず。
これも情報処理２０１４年１月号から（P52～）
リスクベースの「品質向上施策上、重要な原則」
原則１：運用で重要な品質の達成を重視する
１．リスク緩和性
２．有効性・効率性
３．満足性・利用状況網羅性
原則２：リワークによって開発に大きな影響を与える欠陥を
早期に検出する
原則３：対象範囲が狭いところで網羅性を上げる
リスクベース品質向上施策の立案
STEP１．主要シナリオ／機能を列挙
STEP２．重要な品質特性を選択し、品質要求を記述
STEP３．品質要求が満たされない場合のリスクを評価
原則１→重大さ
原則２→影響度
STEP４．対策の基本方針を決定
重大さが大
（１）設計品質の向上
（２）検査網羅性の向上
影響度が大
（３）早めのV＆V
STEP５．対策を選択
（１）設計品質の向上
設計をしっかり→設計モデル、技法、パターン等
（２）検査網羅性の向上
レビュー密度、テスト網羅性
（３）早めのV＆V
検証と妥当性を早めに
STEP６．開発プロセスの施策として具体化
（１）設計品質の向上
欠陥の混入プロセスに
（２）検査網羅性の向上
どのプロセスで除去すれば効率的か考え
（３）早めのV＆V
早いプロセスで
品質要求を実現するアーキテクチャデザインのプロセス
・入力の確認と整理
・開発範囲の明確化
・設計方針の明確化
・分解と実現
・インターフェースの設計
・詳細設計以降への方針展開
＊品質要求の４つの展開方法
・構造(ソフトウェアアーキテクチャ）で実現
・詳細設計以降の設計方針として展開
・機能に展開
・分解して要素に割り当て
リスクベースの「品質向上施策上、重要な原則」
原則１：運用で重要な品質の達成を重視する
１．リスク緩和性
２．有効性・効率性
３．満足性・利用状況網羅性
原則２：リワークによって開発に大きな影響を与える欠陥を
早期に検出する
原則３：対象範囲が狭いところで網羅性を上げる
リスクベース品質向上施策の立案
STEP１．主要シナリオ／機能を列挙
STEP２．重要な品質特性を選択し、品質要求を記述
STEP３．品質要求が満たされない場合のリスクを評価
原則１→重大さ
原則２→影響度
STEP４．対策の基本方針を決定
重大さが大
（１）設計品質の向上
（２）検査網羅性の向上
影響度が大
（３）早めのV＆V
STEP５．対策を選択
（１）設計品質の向上
設計をしっかり→設計モデル、技法、パターン等
（２）検査網羅性の向上
レビュー密度、テスト網羅性
（３）早めのV＆V
検証と妥当性を早めに
STEP６．開発プロセスの施策として具体化
（１）設計品質の向上
欠陥の混入プロセスに
（２）検査網羅性の向上
どのプロセスで除去すれば効率的か考え
（３）早めのV＆V
早いプロセスで
品質要求を実現するアーキテクチャデザインのプロセス
・入力の確認と整理
・開発範囲の明確化
・設計方針の明確化
・分解と実現
・インターフェースの設計
・詳細設計以降への方針展開
＊品質要求の４つの展開方法
・構造(ソフトウェアアーキテクチャ）で実現
・詳細設計以降の設計方針として展開
・機能に展開
・分解して要素に割り当て
これも情報処理２０１４年１月号で知ったこと
あとでみる
電子政府ユーザビリティガイドライン
http://www.kantei.go.jp/jp/singi/it2/guide/index_before090916.html
（ここに、電子政府ユーザビリティガイドラインのPDFへのリンクが有る）
あとでみる
電子政府ユーザビリティガイドライン
http://www.kantei.go.jp/jp/singi/it2/guide/index_before090916.html
（ここに、電子政府ユーザビリティガイドラインのPDFへのリンクが有る）
聞いてないんだけど（＾＾；）・・・
（私に知らせる義務も、知っている権利もないんだけど・・・^^;）
場所は、１３２？、きりんさん広場？
いずれにせよ、最近、セキュリティ厳しいので、
ホームレスみたいな格好をして、こないように（＾＾！）・・
PBL Summit 2014
http://pblsummit.jp/
（私に知らせる義務も、知っている権利もないんだけど・・・^^;）
場所は、１３２？、きりんさん広場？
いずれにせよ、最近、セキュリティ厳しいので、
ホームレスみたいな格好をして、こないように（＾＾！）・・
PBL Summit 2014
http://pblsummit.jp/
gooブログ @goo_blog@xmldtp 突然失礼します。gooブログスタッフです。 goo.gl/wQ93xt こちらのブログ記事での不具合報告ありがとうございました！ 早速、不具合修正を行いましたので お知らせします。 引き続きgooブログを宜しくお願いいたします。
ウィリアムのいたずらさんがリツイート | RT
「品質要求を定義するには」というのが、
情報処理学会の会誌、情報処理 ２０１４年１月号（P33～)に載っていたので
そのまとめをメモメモ
「品質要求を定義するには」
（１）制約条件やステークホルダーを把握する
（２）品質モデルを用いて要求事項を識別する
→ISO/IEC 25010が有用なモデルとして利用できる
（３）ボトムアップ的に要求事項を識別する
→アジャイル、Wモデル
（４）要求水準を定める
（５）要求事項の達成度を評価する
（６）品質要求定義・評価プロセスを改善する
情報処理学会の会誌、情報処理 ２０１４年１月号（P33～)に載っていたので
そのまとめをメモメモ
「品質要求を定義するには」
（１）制約条件やステークホルダーを把握する
（２）品質モデルを用いて要求事項を識別する
→ISO/IEC 25010が有用なモデルとして利用できる
（３）ボトムアップ的に要求事項を識別する
→アジャイル、Wモデル
（４）要求水準を定める
（５）要求事項の達成度を評価する
（６）品質要求定義・評価プロセスを改善する
ゴール指向分析の「考え方は」WBSに使える
http://blog.goo.ne.jp/xmldtp/e/2efd32b1f9b8911882f6b8ddf988febe
を聞かれたときに、一緒に話題になった話なんだけど、
「要求仕様書にクラス図を入れるか？入るとしたら、どこにどうやって？？」
という件について、個人的見解。
まず、入れるべきかどうかの議論の前に、
入るとしたら・・・
●どこか？→入れるところは、
要求仕様書の「用語説明」の章の前ないし後
用語説明で説明している用語がクラス図になっていること。
（ないしは、何かを定義するところ）
●どうやって？→書き方
用語説明のところで、「クラス名」にかかれている用語を、
クラス図の関連、属性、メソッドで説明することになる。
たとえば、
Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（６）
http://blog.goo.ne.jp/xmldtp/e/209a97872693596c7fa43f77cdb93d86
のクラス図
の「アンケート画面」について説明すると、
用語見出し：「アンケート画面」 説明： アンケート画面は、問１，２，３，４，５から成り、 画面表示後、ユーザーに問の回答を入力してもらった 後に、回答実行をクリックすることで表示が終了する 画面である |
どう考えても、これは要件定義で話すことではない。
ということには、このクラス図は、要件定義レベルの
図ではないということが分かるのだが、まあ、説明
の仕方としては、こんなかんじ。
ここで示したように、
「クラス名」は、「属性」、「関連クラス」から成り
「メソッド」を行う
という形に、基本的にはなる。ただし、これだと
日本語がおかしいので、日本語を併せる必要がある。
ただ、上記の「説明」の例で”ユーザーに問の回答を
入力してもらった後”って書いてあるのに、クラス図
にないように、クラス図は、用語説明のすべての情報を
書き表すわけではない。制約や順番、条件や他メソッド
との関連はクラス図にはない。そこで、説明で補う。
ということは、クラス図より多い情報が説明に書かれる
ことになる。二重にものが書かれている場合、更新漏れ
の危険がある。なので、私は、「書かなくてもいいと思う」
（書くことを積極的に、否定はしないけど・・・）
人間破った人工知能、事業化へ＝「ワトソン」に１０００億円投資―米ＩＢＭ
http://news.goo.ne.jp/article/jiji/business/jiji-140110X617.html
ってか、機械学習の分野は、金になるよ！まじで・・・
日本も、ガンガン投資すればいいんだよ、機械学習に・・
今回の日経コンピューター２０１４年１月９日号
（あ、そうそう、新装丁になったね）
「機械学習」革命 的中したビルゲイツの予言
で、「嘆く天才プログラマー」として、アルゴリズムから
データによる機械学習の話が書いてあって、そこで、
あたかも、「ビッグデータ」によってそういう流れができた
蚊のように書いてあるけど、
「情報処理 ２０１４年１月号」の８８ページ
長尾先生の「捨てる技術」を見てもらえばわかるように、
翻訳の世界では、アルゴリズムより、用例(データ）を
あつめたほうが、いいことはビッグデータ以前から、
よく知られていたよね。
長尾先生のそのコラムは、むしろ、そういう翻訳での
経験を踏まえて、ビッグデータの先に何が必要かが書いてある
（それが「捨てる技術」）
んだけど、それはさておき、機械学習への投資は、翻訳だけで
なく、もっとあっていいと思う。
そう、「大江アナがWBSのメインキャスターになっている」というゴールを元に・・・違！
昨日、「ゴール指向分析は実務に使えますか？」という質問に対し、
「ゴール指向分析の（KAOSにおけるAND分析は）ロジカルシンキングと同じでMECEをつくるように分割する考え方なので、この考え方を、複数の人との話し合いの中で使えるよ！」
といったら、「だめだこいつ、わかってね～な！」という顔をされ・・・
（へなちょこで、ごめん・・・ｍ（＿＿）ｍ）
その後、ある人に、「実は具体的には・・・」という話をしたら、
「やっと納得しました！！！」といわれたので、その話をメモメモ！
■そもそも、ゴール指向分析とは
ゴールの状態を決め、そのゴールを達成するには、どうしたらよいか？
とゴールを詳細化していくことにより、最終的に実行可能なゴールを
導き出す手法。
i*,KAOSなどがある。KAOSの例を以下に示す。
上記例で、「Aシステムが完成している」と、「ウォーターフォールで開発されている」、「アジャイルで開発している」は、２つわかれている（途中の○で交わっていない）これは、最低でもどちらか１個をやればよいという意味。つまり、どれかを選択すればいいというもので、OR分解と呼ばれる。
一方、「ウォーターフォールで開発されている」のほうは、「Aシステムの要求分析が完了している」・・・と４つに分かれているけど、上とは違い、○のところで分岐している。このように○で分岐するのは「すべてを行わなければいけない」ということで、AND分解と呼ばれる。
本当は、要求分析でも、設計のところでも、もっともっと細かく分解されるけど、今回は省略。最後は、担当者（エージェント。A社とかB社とかの６角形）がでてきて、そいつと結び付ける。
これがKAOS、i*は、ゴールを扱うけど、似ても似つかない図。
■KAOSのAND分解の考え方
KAOSのAND分解は、上位ゴールを達成するために、もれなく下位ゴールを挙げる
・・・ってことは、これはロジカルシンキングのMECEだよね。
そして図は、ピラミッド構造になっている（事実どちらもwhy,whatの関係で考える）。
ということは、ゴール指向は、基本的に、AND分解はロジカルシンキングと同じ考え方ででき、そこに応用できるということ。
■具体的な応用例 WBS
で、そこで止めちゃったから、つかえねえ～ということになったんだよね。
実はこれ、WBSと同じ形になっている。
ウォーターフォールで開発されたとすると、上記の左側は
WBSを表形式にして書いた場合、
って書くのと、同じだよね。
なので、WBSで作業割していくときに、ロジカルシンキングやKAOSのAND分解というのが使える（作業割をするときは、みんなで話している段階ではKAOSの図のような形で書いてもよい。またMECEはそのとおりだし、Whｙ、Whatの関係で考えられる）
■KAOSの限界－実務で使われないわけ
しかし、ゴール指向分析の「考え方は」使われても、
KAOSですら、実務上では使われない（i*はもっと使いにくい）
その理由は、「爆発するから」
たとえば、「１ヶ月の献立表をつくる」を考える
「１日の献立を考える」
「２日の献立を考える」
：
：
「２９日の献立を考える」
「３０日の献立を考える」
約３０個。
それぞれに、
「和食にする」
「洋食にする」
「中華にする」
の３つのOR
さらにそれぞれに、ご飯・パン、おかず、おみそしる、副菜とあって、
さらに、おかずには、ステーキ、カレー、・・・などのOR分解が有る。
おかずは、洋食和食中華４種類ずつあるとすると
３０＊３＊４＝３６０個
さらに、お味噌汁の具が何種類もあって・・・・
というと、献立を作るゴールが１０００種類以上・・・
も考えるわけない。
しかし、単純にゴール分解してしまうと、このように爆発してしまう。
（本当は、もっと簡単な方法で、献立表を作れるはずなのに）
ということで、ゴール指向分析で、このようなものを考えるのは向かない
（上記のWBSのような、有る程度の大きさに分解できることが、あらかじめ分かっているものに使う）
■ちなみに・・・OR分解は
ちなみに、OR分解と、その選択手法は、AHPと同じにできる。
話が複雑になるので、今回は省略。
昨日、「ゴール指向分析は実務に使えますか？」という質問に対し、
「ゴール指向分析の（KAOSにおけるAND分析は）ロジカルシンキングと同じでMECEをつくるように分割する考え方なので、この考え方を、複数の人との話し合いの中で使えるよ！」
といったら、「だめだこいつ、わかってね～な！」という顔をされ・・・
（へなちょこで、ごめん・・・ｍ（＿＿）ｍ）
その後、ある人に、「実は具体的には・・・」という話をしたら、
「やっと納得しました！！！」といわれたので、その話をメモメモ！
■そもそも、ゴール指向分析とは
ゴールの状態を決め、そのゴールを達成するには、どうしたらよいか？
とゴールを詳細化していくことにより、最終的に実行可能なゴールを
導き出す手法。
i*,KAOSなどがある。KAOSの例を以下に示す。
上記例で、「Aシステムが完成している」と、「ウォーターフォールで開発されている」、「アジャイルで開発している」は、２つわかれている（途中の○で交わっていない）これは、最低でもどちらか１個をやればよいという意味。つまり、どれかを選択すればいいというもので、OR分解と呼ばれる。
一方、「ウォーターフォールで開発されている」のほうは、「Aシステムの要求分析が完了している」・・・と４つに分かれているけど、上とは違い、○のところで分岐している。このように○で分岐するのは「すべてを行わなければいけない」ということで、AND分解と呼ばれる。
本当は、要求分析でも、設計のところでも、もっともっと細かく分解されるけど、今回は省略。最後は、担当者（エージェント。A社とかB社とかの６角形）がでてきて、そいつと結び付ける。
これがKAOS、i*は、ゴールを扱うけど、似ても似つかない図。
■KAOSのAND分解の考え方
KAOSのAND分解は、上位ゴールを達成するために、もれなく下位ゴールを挙げる
・・・ってことは、これはロジカルシンキングのMECEだよね。
そして図は、ピラミッド構造になっている（事実どちらもwhy,whatの関係で考える）。
ということは、ゴール指向は、基本的に、AND分解はロジカルシンキングと同じ考え方ででき、そこに応用できるということ。
■具体的な応用例 WBS
で、そこで止めちゃったから、つかえねえ～ということになったんだよね。
実はこれ、WBSと同じ形になっている。
ウォーターフォールで開発されたとすると、上記の左側は
WBSを表形式にして書いた場合、
って書くのと、同じだよね。
なので、WBSで作業割していくときに、ロジカルシンキングやKAOSのAND分解というのが使える（作業割をするときは、みんなで話している段階ではKAOSの図のような形で書いてもよい。またMECEはそのとおりだし、Whｙ、Whatの関係で考えられる）
■KAOSの限界－実務で使われないわけ
しかし、ゴール指向分析の「考え方は」使われても、
KAOSですら、実務上では使われない（i*はもっと使いにくい）
その理由は、「爆発するから」
たとえば、「１ヶ月の献立表をつくる」を考える
「１日の献立を考える」
「２日の献立を考える」
：
：
「２９日の献立を考える」
「３０日の献立を考える」
約３０個。
それぞれに、
「和食にする」
「洋食にする」
「中華にする」
の３つのOR
さらにそれぞれに、ご飯・パン、おかず、おみそしる、副菜とあって、
さらに、おかずには、ステーキ、カレー、・・・などのOR分解が有る。
おかずは、洋食和食中華４種類ずつあるとすると
３０＊３＊４＝３６０個
さらに、お味噌汁の具が何種類もあって・・・・
というと、献立を作るゴールが１０００種類以上・・・
も考えるわけない。
しかし、単純にゴール分解してしまうと、このように爆発してしまう。
（本当は、もっと簡単な方法で、献立表を作れるはずなのに）
ということで、ゴール指向分析で、このようなものを考えるのは向かない
（上記のWBSのような、有る程度の大きさに分解できることが、あらかじめ分かっているものに使う）
■ちなみに・・・OR分解は
ちなみに、OR分解と、その選択手法は、AHPと同じにできる。
話が複雑になるので、今回は省略。
前にも
うちにも来た！おかしな三菱東京UFJメール（＾＾）
http://blog.goo.ne.jp/xmldtp/e/da72afc0fc0fbb4a706b693e18035573
を書いたけど、また新手のが着た！
でも、何度言ったら・・・
日本の銀行は、「こんにちは！」ではじめるメールは送らないし
（どんだけ、フレンドリーなんだ・・（＾＾；
ってかビジネス文書で「こんにちは」の後に「！」とか付けたら、
上司がチェックするとき直すだろ、普通・・俺は直す）
三十円０９なんていうユーザー名で、YAHOOのフリーメールを
使って送ることは、ないのだよ。。。！！ゼッタイに・・・
ちなみに、このメールに関しては、
インターネットバンキングのパスワード等を騙し取る不審な電子メールにご注意ください（平成26年1月6日更新）。
http://www.bk.mufg.jp/info/phishing/20131118.html
を見てください！まったく同じメールが、不審なメールとして「追加されて！」います。
ちなみに、今回来たメール
うちにも来た！おかしな三菱東京UFJメール（＾＾）
http://blog.goo.ne.jp/xmldtp/e/da72afc0fc0fbb4a706b693e18035573
を書いたけど、また新手のが着た！
でも、何度言ったら・・・
日本の銀行は、「こんにちは！」ではじめるメールは送らないし
（どんだけ、フレンドリーなんだ・・（＾＾；
ってかビジネス文書で「こんにちは」の後に「！」とか付けたら、
上司がチェックするとき直すだろ、普通・・俺は直す）
三十円０９なんていうユーザー名で、YAHOOのフリーメールを
使って送ることは、ないのだよ。。。！！ゼッタイに・・・
ちなみに、このメールに関しては、
インターネットバンキングのパスワード等を騙し取る不審な電子メールにご注意ください（平成26年1月6日更新）。
http://www.bk.mufg.jp/info/phishing/20131118.html
を見てください！まったく同じメールが、不審なメールとして「追加されて！」います。
ちなみに、今回来たメール
アクセス
トータル
ランキング
