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

久々に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

マイナンバー、運賃１円単位、消費税増税 － ＩＴ業界はぼろもうけ？

マイナンバーで儲け話

「共通番号」特需狙うＩＴ企業　整備費用は１兆円規模に
http://headlines.yahoo.co.jp/hl?a=20130509-00000006-fsi-bus_all


電車料金１円単位になれば、システム変えないといけませんよね

１円単位の運賃、今夏にも申請　ＪＲ東、ＩＣ利用時に
http://www.asahi.com/business/update/0508/TKY201305080490.html


そして、消費税増税

第74回　消費税の増税が、ITシステムに与える影響範囲を考える
http://jibun.atmarkit.co.jp/lskill01/rensai/teakaikei/74/01.html


ＩＴ業界は、ぼろもうけ？

アダプティブ オブジェクト モデル（ＡＯＭ）

この前、アダプティブ　オブジェクト　モデル（適応オブジェクトモデル：ＡＯＭ）というのと、ＤＳＬが関係あると聞いた。

アダプティブ　オブジェクト　モデル？？

しらべてみた。


Welcome to Adaptive Object Models!
http://adaptiveobjectmodel.com/


DSLとの関係って言うのは、これかな・・

適応モデルと意味モデル
http://d.hatena.ne.jp/GOLEM-XIV/20100801/1280674771

あとでよむ・・・

マインドマップ＋ＵＭＬでレガシー開発のドキュメントを（ほぼ）置き換えられる

もしかするとここ30年ぐらい基本的な部分はあまり進化してないんじゃねーか？
https://twitter.com/ibucho/status/332482504680419328

確かにそうかも・・・

８０年代から起こった構造化手法の設計方法は、ＥＡにおいて、一旦完成すると見て良いと思う。

ＥＡの開発手法は

EAポータル
http://warp.ndl.go.jp/info:ndljp/pid/286890/www.meti.go.jp/policy/it_policy/ea/

に出ている通り、
機能構成図（DMM)

（http://warp.ndl.go.jp/info:ndljp/pid/286890/www.meti.go.jp/policy/it_policy/ea/gainen/product/dmm/1.htmlより引用）
で全社から、各機能に分解し、それを
ＤＦＤに展開

（https://warp.ndl.go.jp/info:ndljp/pid/286890/www.meti.go.jp/policy/it_policy/ea/gainen/product/dfd/images/2-22f.gifより引用）

ＤＦＤを詳細化していき、そのプロセスの手順を
業務流れ図

（https://warp.ndl.go.jp/info:ndljp/pid/286890/www.meti.go.jp/policy/it_policy/ea/gainen/product/wfa/images/2-34f.gifより引用）
で示す

ここで示された業務流れ図のファイル(データ）を正規化し、
テーブルを作成。その内容をＥＲ図で記述する。

そして、業務流れ図の
　　画面に対し、画面定義書（＝画面レイアウト＋画面遷移図）
　　帳票に対し、帳票定義（＝帳票レイアウト）
を作成する。

この
　　画面定義、
　　帳票定義、
　　業務流れ図、
　　ＤＦＤから最終的に作られるミニスペック（自体はＤＦＤではないけど）
出プログラムは作れる（ここから、流れ図などに落としてもいいけど、落とさなくても、フレームワークが決まると作れる）

---

これと、「ほぼ」等価なものが、マインドマップ＋ＵＭＬで作れる。

●ＤＭＭ→マインドマップ
　マインドマップで、全社から分解していく。最終的に、ユースケース図のユースケースまで落とす

●ＤＦＤ→ユースケース
　マインドマップからユースケース図に落としたところが、
　構造化手法の世界で言う、コンテキストダイアグラム（レベル０のＤＦＤ）となる。
　ここから詳細化していく。
　この詳細化は、ユースケースの詳細化となる。

　ただし、ここでＤＦＤは、データフローダイアグラムの略称なので、データがはいってくるが
　ユースケース図は、データが抜ける。これを、補完するのが、次の工程

●業務流れ図→アクティビティ図
　ユースケース図の各ユースケースに対応するアクティビティ図を書き、これをユースケース記述の
基本処理系、例外処理系にしていく。
　このとき、アクティビティ図は、業務流れ図に相当する。
　ただし、業務流れ図に出てくる画面、帳票などは、すべてアクティビティ図のオブジェクトノード
になってしまうので、色を変えるなどの工夫がいる。

　ＤＦＤのデータは、業務流れ図のファイルにマッピングされるはずである。
　そして、業務流れ図のファイルは、アクティビティ図のオブジェクトノードとなる
　ということは、ユースケースでデータが抜けても、アクティビティ図のオブジェクトノードで補完できる

●ＥＲ図→クラス図
　ファイル、テーブルの内容はクラス図でも表現できる
　ということは、ＥＲ図は、クラス図に相当することになるが、
　ＥＲ図は、主キーなどのキー情報が書ける点っで、クラス図と異なる。これを何らかの形で補う必要がある。

●画面定義、帳票定義、ミニスペックに対応するものはない。
　ソースコード＆コメントで直接書くことになる
　　→これが「みずほ証券」の裁判で問題になっている、ドキュメントは必要か？の本質と思う。
　　　今の開発方法論では、この部分の情報がない。

---

ということで、３０年前のレガシーな設計書の情報は、ほぼ、
マインドマップ＋ＵＭＬで置き換えられる。

でも、最後の部分、「ソースコード＆コメントで直接書く」ということは、ＵＭＬと実装との対応が付くということになるが、それについては・・・

・・・それについては・・・
・・・それについては・・・


・・あ、（＠＿＠！）、書きかけだった。
こんど、つづきやる。

Springが、画面作るの簡単になったといわれて・・・

？？？Springって、そもそも、画面書いたっけ？
Strutsとかと、組み合わせなかったっけ？
と思って、その人が見ている本をみたら、Spring3。

あ、Spring3になって、かわったのか・・・

と思って、ちょっと見たら、

Spring3になって、Strutsが非推奨となり

概説 Springプロダクト(5) - Spring 3.0時代のSpring MVCを知る
http://news.mynavi.jp/articles/2010/04/09/spring5/index.html


SpringMVCを使うようになったようなんだけど、それがStrutsより易しい
という意味みたいですね。

やばい、時代に取り残されている。
お勉強しないと・・・

ってことで、メモメモ

第4回 SpringMVCの基本を知る
http://itpro.nikkeibp.co.jp/article/COLUMN/20070822/280072/

あ、ＳＥＭＡＴって、パターン使うんだ・・

最近話題のＳＥＭＡＴ

http://blogs.itmedia.co.jp/hiranabe/files/SEMAT-vision-ja.pdf

を見ると、図１にパターンとある。
あ、ＳＥＭＡＴって、パターン使うんだ・・
だから、鷲崎先生が関係するのね・・・

って、昔から、書いてあったね（＾＾；）

でも、山本先生のＳＥＭＡＴの説明

http://www.bcm.co.jp/site/youkyu/youkyu103.html

だと、パターンとかは出てこないで、
なんだかしらないけど、他のソフトウェア工学の方法論と
おなじように、いろんな図がでてきて・・・

・・・それが、わけもわからなく、アイテムがいっぱいあるので
むずかしそう・・・

カーネル・アルファってなに？７つもあるの・・・

あ～むずかしそうだ・・・

ついていけるのか・・・俺（＾＾；）

PHPで、SimpleXMLを使ったXMLデータの操作

■御題

以下のＸＭＬファイルpersons.xmlがある

これを
１．インドのマンモハン・シン首相を追加
２．中国のNameを習から馬に
３．韓国を削除
して、newpersons.xmlして、画面表示する
すなわち、画面表示結果は、以下のとおり

■ソースコード

<?php

$xml =simplexml_load_file('persons.xml');

//　インドを追加
$node = $xml->addChild("person");
$node->addChild("Name","マンモハン・シン");
$node->addChild("From","インド");
$node['id']="010";

//　中国の名前を習から馬に
for($i=0;$i < count($xml->person); $i++)
{
	if ( $xml->person[$i]->From == "中国")
	{
		$xml->person[$i]->Name="馬";
	}
}

// 韓国を削除
for($i=0;$i < count($xml->person); $i++)
{
	if ( $xml->person[$i]->From == "韓国")
	{
		unset($xml->person[$i]);
	}
}

//ファイル書き出し
$fp = fopen("C:\xampp\htdocs\newperson.xml", "w");
fwrite($fp,$xml->asXML());
fclose($fp);

//　画面に出力
echo $xml->asXML();


?>

※政治的意図は、ないです。

ミクシィのスマホ社内教育資料が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トレーニングとか、いろいろですね！

年内「ウィンドウズ８」改良版(Windows Blue)発売へ、6月末パブリックプレビュー

問題は、ユーザーインターフェースがどうなるのかですよね・・・
Metroから、元の形にもどったりして・・・
さすがに、そりゃないか（＾＾；）

いやいや・・・

年内発売より、

開発者向けパブリックプレビュー版を6月末の開発者向けイベント「BUILD 2013」でリリースする

ことのほうが、注目かも・・・

＜＜参考＞＞
米マイクロソフト、年内「ウィンドウズ８」改良版発売へ＝幹部
http://headlines.yahoo.co.jp/hl?a=20130507-00000105-reut-bus_all

Windows 8の改良版「Blue」、年内リリース予定
http://slashdot.jp/story/13/05/08/0828252
(太字は上記スラッシュドットの記事から引用）

フュージョン・アイオーで経営トップが大脱走 株価は暴落

なにがおこったんだろう？
フラッシュ・ストレージって、どうなんでしょうね？
それとも、フラッシュ・ストレージの問題でなく、社内的な話？


フュージョン・アイオーで経営トップが大脱走　株価は暴落
http://markethack.net/archives/51874630.html

YouTubeが課金制サービスを導入

課金制の動画をアップするやつとか、出てきたりして（＾＾；）
あ、それは、動画版電子透かしみたいなので、対応できるのかな？

それはさておき、これで、途中までは無料版、ＩＤを入れると、課金部分が見れるようになる
とかいうと、このブログでやっていた
「コピーされるほど儲かるシステム！」
のシステムになりますね（＾＾；）


YouTubeが課金制サービスを導入
http://headlines.yahoo.co.jp/hl?a=20130509-00000005-eiga-movi

日本Amazon史に確実に名を刻んだ名コメント－「色彩を持たない多崎つくると、彼の巡礼の年」

「色彩を持たない多崎つくると、彼の巡礼の年」には、
今までまったく興味がなかったんだけど、

「色彩を持たない多崎つくると、彼の巡礼の年」に対する、ドリーさんのコメント


孤独なサラリーマンのイカ臭い妄想小説, 2013/5/3
http://www.amazon.co.jp/review/R9F23X7FKJEE2/


が面白すぎる！

もう、ドリーさんに興味津々で


他のコメント
http://www.amazon.co.jp/gp/pdp/profile/A3LC3T2046SMQB

や、

ドリーさんのブログ

埋没地蔵の館
http://yaplog.jp/akita0106/


まで見に行ってしまいました・・・

そこに

一万人きたでこれ・・・。もう日本アマゾン史にかくじつに名を刻んだろ・・・。http://t.co/4w7QlRj55a

(上記ブログより引用）
ってあったけど、
確かに、１万４千人を超えているなんて、
日本Amazon史に確実に名を刻んだ名コメントですね！

マインドマップは、パターンを使うといいかも！

マインドマップは、自由に考えられるところが、
確かにいいんだけど、

UMLに持っていったり、開発に持って生きたいのであれば、
ある程度、パターン化したほうがいいのかもしれない。
と思った。

astahを使って、マインドマップからユーザーストーリーを作るwebinarメモメモ

Webinar: Using Astah to Explore User Stories through Mindmapping in Agile projects
http://changevision.wordpress.com/2013/05/04/webinar-using-astah-to-explore-user-stories-through-mindmapping-in-agile-projects/

をみた。内容をメモメモ（英語だったので、間違えて理解してるかも・・そしたらごめん）

---

・チェンジビジョンの話
　　東京の浅草と、福井の２拠点。福井はとうじんぼうで有名

・イントロダクション
　　平鍋さんの翻訳した本、書いた本
　　astahの話
　　Innovation Sprint 2011の野中先生→野中先生がScrumを作った
　　AgileとLeanの関係

・マインドマップとは
　　ノートをとるテクニック。トニーブザンが提唱
　　ぱわふる、イメージできる、グラフィカル以上
　　本：Mind Map Book, Mind Map For Kids

・ダビンチは絵と言葉を同時に使ってた
　　右脳、左脳の話。並行処理
　　マインドマップは、ブレインフレンドリー：右脳、左脳同時に使う

・TedのJill Bolte TaylorのStroke（脳溢血だったっけ？）の話
　　　→右脳と左脳の話

・「NoteTakingにマインドマップを使うとよいことについて」の
　マインドマップの説明

・マインドマップは、本のノートをとるのにいいという話
　　→マインドマップは、脳のインデックスになる

・マインドマップの例
　　ケントベックがXPのコンセプトを書いたもの
　　プロジェクトチーム（リリース）についてかいたもの
　　トヨタのカイゼン
　　ウェディングスピーチ？？

・ここでしつもん！
　　マインドマップは、ほかの人に説明するには、どうなの？
　　　→体験を、理解をシェアできる

・astahを使った例
　　クリスマスのマインドマップ
　　　５W+1R（Result)　：BOI（ベーシック　オーダリング　アイデア）を書く
　　Jazzのギターコード

　　セミナーの例：使い方デモ　
　　　　マインドマップがExcelに貼れる、
　　　　Excelからマインドマップに貼りこめる

　　図書館のマネージャーとして
　　　　ユースケースにマインドマップで書いたものが、持ってこれる
　　　　ユーザーストーリーにも使える→Excel、PowerPointに貼れる

・まとめ
　しつもん

ソフトウェア工学は、違った方向に行っているのかもしれませんね？

　昨日の、

UMLからNoUMLというのは、青い鳥な図を探していると思う
http://blog.goo.ne.jp/xmldtp/e/8ee5111962a4e2067bf00dbc9a9234d6

の続きみたいな話。

　ソフトウェア工学の傾向として、はじめの志はいいかもしれない。
　でも、ある方法、理論ができてしまうと、今度、「その理論を守ればいいのね」というカタチになりがちだと思う。

ＥＲ図など
　エンティティを作って、属性を埋めて、線（リレーション）でつなげばいいのよね

ＵＭＬだと、
　ＵＭＬで書いて、図を埋めればいいのよね。

ＴＤＤだと
　JUintで緑にすればいいのよね

　しかし、これらは、本質的に違ってきてしまう。

　たとえば、ＥＲ図をかくにしても、ＵＭＬをつくるにしても、お客さんの要望を聞いて、ステークホルダーが理解しやすくするためのモノだったけど、お客さんの要望を聞くことや、みんなの理解はさておき、図を書くことに集中してしまう。

　この結果として、本質的な、「要望を聞く能力」や「理解してもらうために必要な能力」とかは、あまり研究されず、整理術、整理法とでも言うべき図の書き方などが発展し、いろいろな概念が出てくるが、肝心な部分が発展しにくくなってきていると思います。

う～ん、ソフトウェア工学は、違った方向に行っているのかもしれませんね？