画面遷移図だけの判断は、危険

画面遷移図を書けといわれると、こんなかんじになる

あるデータについて、表示範囲を設定し、
　　「グラフ」ボタンがクリックされるとグラフが、
　　「表」ボタンがクリックされると表の一覧が
　　「ＣＳＶ」ボタンがクリックされるとＣＳＶ形式でデータが
表示される状況を表した。

お客さんと合意をとるだけならこれでいいが、実際に実装まで考えるんなら、
ここで止めるとまずい。というのも、これには、３つの実装方法が考えられるが、
それにより開発コストとリスクが大幅に異なり、従って、プロジェクトの進め方も
変えたほうがよいからだ。

---

【その１】

サーバーで、
１．サーバー側でデータをまず取得する。
２．その後、おされたボタンにより、サーバー側で
　　　　２－１．グラフ用に加工
　　　　２－２．表用に加工
　　　　２－３．ＣＳＶ用に加工
のいずれかを行い、クライアント側は、サーバーで加工されたデータを表示する

これは、プログラム数は増えるが、他メディアの仕様が影響しないため
（グラフ用データは２項目全データ、
　　　表用は全項目だが一部データ、
　ＣＳＶ用は全項目全データが必要など）
比較的、簡単に作れる。
プロジェクトはそのまま詳細化、分担割して問題はない。

---

【その２】

１．サーバー側でデータを取得し、クライアントに全データを送る。
２．おされたボタンにより、クライアント側で
　　　　２－１．グラフ用にJavascriptで頑張る
　　　　２－２．表用にJavascriptで整形する
　　　　２－３．データはＣＳＶで送られることにしておけば、そのまま出す
　　のように、javascriptで加工する

これは、Javascriptの生産性に影響してくる
他メディアの仕様が影響することも気がかり
プロジェクトはそのまま詳細化しつつ、Javascriptでの実現性を確認、
詳細化が煮詰まったところで、サーバー側の処理に問題ないか確認し
すすめる。

---

【その３】

１．サーバー側でデータを取得し、クライアントに全データを送る。
２．おされたボタンにより、クライアント側でグラフ／表／ＣＳＶ部品を切り替えて表示

これは、要望どおりの思った部品を作るのが結構難しい。
→単にグラフを出す、表を出すことは簡単に出来る。
　グラフの操作や表の切り替えなどを、要求に合わせるのが難しい。

仮に作れても、他メディアの仕様の影響をもろに受ける。
　グラフ操作のバグが、表に影響することも・・・

プロジェクトは、まず、部品が出来るかどうかを確認する必要がある。

---

その１とその３では、開発リスクが異なり、その３の場合は、そういう
部品が作れるかどうかで決まってしまう。

なので、画面遷移図を考えるとき、

遷移図から実装を考えるのが、ウォーターフォールでは、決まりなんだけど、
先に、実装を考えて（つまり、その１、その２、その３の図を作って）、その上で、
（その図からサーバー部分を除くことにより）画面遷移図を考えてったほうが、
のちのち、安全・・・

アジャイルを支える品質概念になるかもしれない「しなやか品質」

久々にTwitterのまとめ。
昨日から、西先生が、「しなやか品質」（柔品質）というのについてつぶやいている。
たぶん、この概念は、アジャイルで求められる品質を考える上で重要なキーワードになりそうな気がするので、一連のついーとをまとめてみる
（ただし、途中、抜いている。青字がついーと内容、黒字がURL）

---

1)ユーザが求めている品質に合っているかどうかと、
2)その品質を的確に作り込み保証できている能力を備えているか、そして
3)その両者を混同する組織は前者を言い訳にして後者をないがしろにする、
というのは別々に議論しないといけません。
https://twitter.com/YasuharuNishi/status/333370740277669888

日本の品質管理関係者は、3)のスタンスを取ることで、2)を備え1)を備えない組織を作ってきてしまいました。いつまでもそのスタンスでは、世界に勝てません。
https://twitter.com/YasuharuNishi/status/333371132239568896

なぜなら、世界には様々なユーザがいて、様々な品質が求められるからです。大事なことは、1)と2)を両立する考え方をまとめ、両立するプラクティスを確立し実践することです。そして1)が2)を駆逐するのを防ぐことです。
https://twitter.com/YasuharuNishi/status/333371946957950976

だから、重品質に対するアンチテーゼとしての軽品質という対立議論をすべきではありません。あくまで両方とも重要で、組織がその重さや軽さに応じて的確に見合ったコストで品質を作り込む能力を備えるにはどうするか、という議論をすべきです。
https://twitter.com/YasuharuNishi/status/333372759184900096

言ってみれば、柔品質。ユーザに求められる品質が柔軟に変化する状況に合わせて見合ったコストで的確に品質を作り込むこと、とかね。
https://twitter.com/YasuharuNishi/status/333373301109964800

もちろん自分の組織が重品質（おもひんしつ）パラダイムにまみれている時に、柔品質（やわひんしつ）パラダイムに近づけるためにあえて軽品質パラダイムを提示するという戦術はありでしょう。組織が軽品質パラダイムにまみれている時にそこそこ品質論を提示するのも戦術としては同様にありです。
https://twitter.com/YasuharuNishi/status/333373826303926272


柔品質だと読みがカブるから、「しなやか品質」の方が直感的かもしれないな。やわらか戦車みたいで癒やされるかもしれないし。
https://twitter.com/YasuharuNishi/status/333601424292323328

1)ユーザの要求品質が絶対的に低いこと
2)結果の品質がユーザの要求より相対的に高いこと
3)結果の品質がどうなるかよく分からないからムダに取り組みを重くすること
4)軽い取り組みで十分なこと
5)結果の品質がどうなるかよく分からずに適当に手を抜いて取り組むこと

「軽品質」という言葉に救いを感じる人は、1)を知っていて2)を憂い、3)の被害を受けて4)を目指し、ところが5)になっちゃってる人じゃないかな。その結果、1)なのに結果の品質がユーザの要求よりさらに低くなっちゃってデスマる、みたいな。

https://twitter.com/YasuharuNishi/status/333603910893846529
https://twitter.com/YasuharuNishi/status/333603936332283904
https://twitter.com/YasuharuNishi/status/333603958604046337
https://twitter.com/YasuharuNishi/status/333604001713102848
https://twitter.com/YasuharuNishi/status/333604026069422080
https://twitter.com/YasuharuNishi/status/333604507097374720


だから大事なのは、すごく当たり前なんだけど、何のためにどんな取り組みをして、どういうメカニズムでどんな品質がどう上がるのか、というのをきちんと把握して品質向上/品質保証活動をすることだ
https://twitter.com/YasuharuNishi/status/333605007528177664

それに「軽品質マンセー」的な人だって、「でもクリティカルなところはバグ無しじゃないと困る」とか言うからね。品質が高いか低いか、取り組みが重いか軽いか、に気を取られると、本質が見えなくなると思う。
https://twitter.com/YasuharuNishi/status/333606136907444226

この指摘は鋭い。 QT @Tachi_4423: 例えば車内灯（の制御）なんて，バグっても人は死なない．ユーザも普段はそう思ってる．でも一旦不具合が発生すると，何百万もする装置でこの品質ってどういうことよって思う．問題発生によってユーザの要求品質が変動する．
https://twitter.com/YasuharuNishi/status/333611035359596547

うん、わかる。でもスライムは弱っちそう。何かいい名前ないかな。 (^_^) QT @s_banban: …もうちょっと形状を変えて上手くフィットするみたいなイメージがあります…スライム品質・・・うーんなんか嬉しくないぞorz　って思いました。
https://twitter.com/YasuharuNishi/status/333606344898777089

ミクシィのスマホ社内教育資料がGitHubで公開！太っ腹！

ミクシィのスマホ社内教育資料がGitHubで公開！太っ腹！
https://github.com/mixi-inc http://fb.me/1pEFLdhpO


https://twitter.com/Ryo_mats/status/332333311483596800


ですって！

見てみましょう。


https://github.com/mixi-inc


iosトレーニングとか
Androidトレーニングとか、いろいろですね！

警視庁、「振り込め詐欺」の新名称を募集……Twitterでつぶやくだけで応募可能

応募は郵送またはTwitterで可能。Twitterで応募する場合は「新名称」「簡単な趣旨」「ハッシュタグ【＃振り込め詐欺新名称】」をつけてツイートすればよい。


そうです。ちなみに、なぜ募集かというと、


「振り込め詐欺」という名称は一般的になったが、最近の手口としては、銀行口座を経由しない、手渡しによる犯行も多く、実態を的確に表現できていないという。また“被害者を不安にしパニックに陥らせることで犯人のコントロール下に置く”ことが、そのカギとなっていることから、「パニックに陥れることを直感的に理解できる新たな名称案」を公募するとのこと。


だそうです。


警視庁、「振り込め詐欺」の新名称を募集……Twitterでつぶやくだけで応募可能
http://headlines.yahoo.co.jp/hl?a=20130321-00000024-rbb-sci

(太字は、上記記事より引用）

企業で流行るのは３年～５年か？でもキャズムがあるから、全て流行るわけではない

チャコさんのこのツイート


チャコ @Chakopetit

5年前くらいに同じセリフを聞いた気が…w アジャイル同様、企業レベルになるのに5年かかるのね。“@nikkeibpITpro: ［関数型言語のトレンド］国内でも採用企業が増加（Javaはもう古い！次の主流は「関数型」） nkbp.jp/Uikrc2 #itprojp”


あ～たしかに、なんか先端技術と話題になってから、普及し「はじめるまで」（＝ハイプサイクルの反動期（幻滅期）を超えて、普及しはじめる直前のとき）は、黎明期から数えて３～５年の気がしますね。今、２００７～２００８年のものが、復活してくるときかも知れません。でもキャズムがあるから、全て流行るわけではない。

ただ、scalaのような関数型言語に関しては、今が流行期直前の気がします。
もうちょっとたったら、雑誌がいっせいに叩いてきますよ。きっと。
まだ、叩くには、早すぎる。

一方、Rubyやアジャイルは、もう幻滅期からは脱出して、キャズムを超えたと
考えて良いか・・・微妙かなあ・・・まあ、超えたな。超えたことにしよう（＾＾）

ちなみに、ビッグデータがたぶんこれから「まっさかさまに落ちてDESIRE」の幻滅期
で、これから雑誌が本格的にたたき出すと見ています。
・・・ビッグデータは、叩きやすいんだよね・・ワキが甘いから・・

アジャイルにとって、情報システムを内省化できる環境が整ったってことも大きいと思う

結局、米企業では、「情報システムは内製する方が良い」　という判断が多いようですね…　モジュール化した製造業とは異なり、垂直統合的な傾向が表れている（？）　と仮にみなせるのならば　さらに興味深い　◆　アジャイルの取り組みが大きく遅れている itpro.nikkeibp.co.jp/article/COLUMN


というツイートについて

アメリカは、
「情報システムは内製する方が良い」
　　　↓
　内省化率が高い
　　　↓
契約とか考えないでいいし、
情報システムは、プロジェクトごとというよりは改善なので、
アジャイルのほうが向いている
　　　↓
アメリカはアジャイルが広まった

という議論に関しては、激しく同意するし
たぶん送なんだと思う。

ただし、１点、付け加えさせてほしい。
ユーザー企業が、内製可能なほど、技術的な環境が整ったことも大きいと思う。

つまり、今の開発は

・画面作製はＨＴＭＬ（ＨＴＭＬ５）
・ＤＢは、ＭｙＳＱＬなど→phpmyadmin等で、管理が簡単
・あとはCakePHPのBakeなどで、ある程度自動化してくれる

その結果、ＰＨＰと、JQuery,JQueryMobileを組み合わせれば、
プログラムは、そこそこできるようになった。
これは、情報システム部の人に勉強してもらえば対応可能

というように、ツール・技術がそろってきたので、アジャイルが
可能になって来たといえる。
オブジェクト指向へのこだわりがなければ、
（継承して抽象化させるこだわりがなければ）
これらのツールで、　ボトムアップで開発したほうが、
現場の要望がタイムリーに取り込みやすいので、
アジャイルが広まる要因になったといえる

今、SysML教えてる学校って、慶応ＳＤＭの西村先生のところぐらい？

Kenji Hiranabe　@hiranabe
日本でSysML使ってるとこないかなぁ。評価版絶賛提供中です。

https://mobile.twitter.com/hiranabe/status/281510526893293568


ＳｙｓＭＬを使っている会社は、いろいろあるかもしれないし、
Astah*使って教えている学校はいくつかある（芝浦工大、早稲田など）けど、
今、SysML教えてる学校って、慶応ＳＤＭの西村先生のところぐらい？
って認識でＯＫかしら？？


INCOSE Japan Chapterのご紹介とSysML教育への期待
http://www.umlcert.org/news/pdf/100128_sysml_02.pdf


なかんじ・・・

8月18日(土)のつぶやき

20:34 from gooBlog production
「HBaseの本、あたったよ（＾＾）ｖ　ＮＨＮテクノロジーカンファレンスで！」 #nhntech blog.goo.ne.jp/xmldtp/e/ac158…

by xmldtp on Twitter

8月11日(土)のつぶやき

09:34 from gooBlog production
「米国では大型カンファレンスに一律規制がかかって大変だそうです」 goo.gl/cBUjM

by xmldtp on Twitter

米国では大型カンファレンスに一律規制がかかって大変だそうです

連邦政府の省庁の職員が参加する全てのカンファレンスの費用に対し、10万ドルないしは50万ドルのキャップがかけられ、それを超える場合は長官レベルの稟議が必要になった。問題はそれにSCのような学術的会議も含まれてしまったことだ！

これによって大学は影響はないが、DoEやNASA参加の国立研究所もその対象になってしまい、かつキャップは研究所でなく省庁単位なので、数百人単位で会議の運営側でも参加側でも深くかかわっているDoEは大騒ぎである。しかも、悪いことに大統領選の真っただ中なので、政治的に誰も動けない。

状況は刻々と変化し、SCもACM, IEEE等を通じて長官レベルまで働きかけているが、少なくとも今年は予算キャップを超えることはほぼ不可能である。これによってDoE等傘下の国研はSCでの研究展示を全てキャンセルした。参加者も数百人だったのが半減以下となると悲観的な予想をしている。


だそうです。上記太字部分は、以下のまとめより引用


松岡先生によるGSAスキャンダルのまとめ
http://togetter.com/li/352808


（上記のサイトは、もっと長く、いきさつまで書いてある）

7月20日(金)のつぶやき

22:36 from gooBlog production
SysMLとＭＢＳＥ blog.goo.ne.jp/xmldtp/e/8efbc…

by xmldtp on Twitter

Twitterで"123.456.***.789 lang:ja"と検索すると・・・

こんなTweetが（＾＾；）

You Wata ‏@youyou1976
見事に間違っておる！ RT @ixixi: ええええ、NHKでIPv4アドレスの例として「123.456.●●●.789」って… ＃nhk

お、おい・・・NHK（＾＾）

5月30日(水)のつぶやき

23:04 from web
”「x=3ならばy=5、あるいは、y=5ならばz=8」が言える”をブログった。 plaza.rakuten.co.jp/struts/diary/2…

by xmldtp on Twitter

5月27日(日)のつぶやき

02:49 from web
しまった！か、よかった！かわかんないけど、NHK技研公開、今日までなことに、今気づいた！ nhk.or.jp/strl/open2012/…

by xmldtp on Twitter

スマートシティ・スマートコミニュティへの取り組み

富士通フォーラム２０１２　５月１７日のセッション

スマートシティ・スマートコミニュティへの取り組み

で聞いて来た内容のメモメモ

---

スマートグリッド・スマートシティ
　　当初、海外中心？と思われた
　　　　日本は、スマートメーター
　　震災後、むしと、日本がスマートグリッド・スマートシティに注目
　　　　エネルギー系ソリューション

世界が直面している問題
　　貧困・格差拡大
　　食料、水不足
　　世界人口の増加・・・
　　　　：
　　都市への人口集中
　　都市化によるインフラ逼迫・環境負荷増大
　　　　エネルギー資源不足、価格高騰
対応
　　→グリーンニューディール

日本の状況
　　従来の課題
　　　　地球温暖化、低炭素
　　　　経済成長戦略
　　　　少子高齢化、地域活性化
　　東日本大震災後
　　　　それにくわえ、安心安全・持続可能な街づくり


ＩＣＴ環境の変化
　　ネット端末多様化
　　ネット広域化・無線化
　　クラウド化

　　モノからサービスへ

　→スマートシティを支える社会インフラへと期待

スマートシティの要件
　　エネルギー
　　環境保全
　　経済成長
　　住民生活の質の向上


スマートシティの定義
　　経産省
　　　　エネルギーへフォーカス
　　スマートシティＷｅｅｋ２０１１ステアリングコミッティ
　　　　やわらかく定義

スマートシティ案件分析
　　特性１
　　　　ほぼ１００％が再生可能エネルギー活用
　　特性２
　　　　太陽光、バイオマス、水力に注目
　　　　温泉・ごみ再利用など地域環境にあった発電も
　　特性３
　　　地域特性、地域課題解決とあわせ、スマートシティを

国の政策に基づく事業の場合
　　持続可能性を求められる

富士通スマートシティコンセプト
　　ＩＣＴにより自足的に社会価値の循環と変革を創出するドライバーとなること

地域密着プロジェクトの推進
　　豊田市
　　会津若松市
　　浦安市
　　薩摩川内市
　さらに、国内・海外２０地域調査


豊田市のケース
　　ＥＤＭＳ（エネルギー情報マネジメントシステム）
　　　→生活圏全体のデータ収集：スマートハウス

　　　　予測
　　　　　↓
　　　　需給調整
　　　　　↓
　　　　行動誘発
　　　　　↓
　　　　モニタリング

会津若松
　　再生可能エネルギーの飛躍的推進
　　時代をリードする産業創出と雇用拡大
　　　　　↓
　　再生可能エネルギー
　　ＩＣＴ新都市基盤→新たなブランド

　　フィージビリティスタディ
　　　　再生可能エネルギー
　　　　　　地産地消・電力網の安定化
　　　　結果
　　　　　　１５万ＫＷ供給（需要は５０万ＫＷ）
　　　　エネルギーコントロールセンター
　　　　マスタープランづくり


価値循環モデル発展のアプローチ
　　フィールドにイノベーション
　　　フィールドイノベーターが、現場観察：ＩＣＴを駆使
　　　　　→地域ことにフィールドイノベーター派遣


　　
（１）地域活性ソリューション
　業種・業務を切り口に
　　　スマートネットワーク
　　　　　　　ＢＥＭＳ
　　　　　　　ＨＥＭＳ
　　　　　　　ＣＥＭＳ：配電エリア内で

（２）エネルギーソリューション
　　クラウドでＢＥＭＳ，ＨＥＭＳを管理
　　スマートネットワークソリューション
　　　　　（２０００万台超、１０年間連続運用が必要）
　　　　アドホック通信技術
　　　　ミドルウェア技術

　　アジアパシフィックへの取り組み：中国

　　地域エネルギーマネジメントシステム：ＣＥＭＳ
　　　　配電線
　　　　高速大量データ
　　　　高精度予測アルゴリズム
　　　　配電業務ノウハウ

　　ＨＥＭＳ関係：ＳＳＰＦ（スマートセンシングプラットフォーム）
　　　　スマートハウスやスマートコミュニティ市場における
　　　　業務システムの開発効率を飛躍的向上

　　クラウド型ＥＭＳサービス　Ｅｎｅｔｕｎｅ（えねちゅーん）
　　　　一元管理、全体最適
　　　　経産省：ＢＥＭＳアグリゲーター

　　地域ソリューションの更なる拡充
　　　　→エネルギーはインフラ