ソフトウェア工学＝ソフトウェアの工「学」 or ソフトウェアで「工」学

ちょっと日にちたっちゃったけど、前の

「アジャイルがダメだと思う7つの理由」と「ソフトウェア工学は失敗している」は同じ次元の釣り？
http://blog.goo.ne.jp/xmldtp/e/2896922420cd01406a25f75606265c2a

に対して



きしだ　@kis

いや、同じ次元じゃないと思う。アジャイルのほうが経験が盛り込まれてるので、読んで得るものがあるｗ 「「アジャイルがダメだと思う7つの理由」と「ソフトウェア工学は失敗している」は同じ次元の釣り？ - ウィリアムのいたずらの開発日記」 blog.goo.ne.jp/xmldtp/e/28969…
https://mobile.twitter.com/kis/status/316845583648321537


たしかに。そのとおり。

最近の大学・研究者の「ソフトウェア工学」は、実証的な経験から離れていき、現場と乖離している。

それは、大学・研究者にとっての「ソフトウェア工学」は、

　　ソフトウェアの工「学」

つまり、ソフトウェアを作る（工）という観点から見た「学問」
なのに対し、

現場の人の「ソフトウェア工学」のイメージは、

　　ソフトウェアで「工」学

つまり、ソフトウェアを使って、システムを作っていく（工）ために必要な学び

なのだ。この差が大きくなり、今の大学・研究所のソフトウェア工学が、
現場で使えないようになってきている。

ちょっと具体的に話そう。

---

■大学・研究者にとってのソフトウェア工学

　ソフトウェア工学は大学・研究者においては、学問である。

　つまり、「ソフトウェア工学」といわれたときに、それが示す範囲
（学問領域）があり、学として成立している。つまり、理論的に議論が
できるものと思われている。

　たとえば、物理学を考えよう。この場合、理論的に議論が可能である。
　その背景として、物理法則は、誰が、どこで、いつやっても同じ
結果になる。もし、そうならなければ、理論が成立しないので議論ができない。

　りんごを落としたら、必ず地面に落ちるから、
　　　万有引力の法則というのを考え議論できる
　りんごをかじったら、歯茎から血が出るかどうかは、人によって違うので
　　　　デンターライオンの法則というのは物理学にはない
　　　　（古！通じないよ　＾＾；）

　だから、大学のソフトウェア工学は、属人性の排除が重要で、技術として、
再利用可能であり、同じ結果が期待できるものとされている。
　あるレベルの経験者しか持ち得ない暗黙知の技能に基づいた秘伝の技などは、
形式知にしない限り、研究対象からはずれる。
　暗黙知の結晶である経験は、形式知にしないかぎり、学問対象から
外れてしまうのだ。

---

■結果として、アーキテクトでない人も大学でソフトウェア工学を教える

　この結論として、大学・研究者にとってのソフトウェア工学とは

　　・ソフトウェア工学のドメインで
　　　　　（プログラミングを除く、ソフトウェア開発過程で）
　　・適切なリサーチクエッションを提示し
　　・新たな方法で（形式知化できる手法で）
　　・数字により、優位性を明示できるもの

　が対象となる。そして、論文を出さない限り博士になれず、博士にならない限り、
どんなにアーキテクトとして有能でも、現状では大学で教えることは難しい。

　一方、ソフトウェアのアーキテクトの能力として疑問があり、
　システム開発の経験が乏しい人でも、大学のソフトウェア工学の講義をうけもち、
　アジャイルやウォーターフォールの批判を思う存分できることが
　理論上（ということにしておきます・・）可能だ。

　つまり、大学・大学院の間、システム設計をしないで、
　論文を書き、博士をとる（この間、社会人経験なし）。
　　→これは可能。要求工学、ソフトウェアメトリクスの分野は、直接設計をしない
　　　でも、論文は書ける。

　そうすると、専門分野：ソフトウェア工学ということになる。
　その後、大学の助教となり、ソフトウェア工学を教え、偉くなってしまうと・・・
　ソフトウェア工学の権威として、まったく現場は知らないし、アーキテクトとしての
　能力に疑問がある人でも、ソフトウェア工学の時間で、アジャイルやウォーターフォールの
批判はできる。

---

■現場の知識は、経験なので、暗黙知や属人性がはいりやすい

　アジャイルでの実践にしろ、ウォーターフォールの実践にしろ、そこで得た知識は
経験にもとづく知識である。
　このような知識は、暗黙知や属人性がはいりやすい。

　アジャイルコーチを置くと、アジャイルが成功しやすいという経験を得たとしても、
すべてのアジャイルコーチでうまくいく・・・というわけでもないだろう（属人性）し、
　それでは、どういうアジャイルコーチがいいのか・・・といわれたとき、その
特徴を列挙しずらいだろう（暗黙知）

　ってことで、暗黙知や属人性がはいりやすく、このままでは、大学などの学問
にはなりにくい。

　しかし、一般的には、現場では、このような知識のほうが、求められる。


　たとえば

　　　　「プログラムを何本も写経すると、見えてくるものがある」

　このことばは、現場の知識としては大事だし、何の違和感もない言葉だし、
私も経験したし、たぶん多くの人が経験することだし、新人に言う言葉だと思う。

　だが、大学のソフトウェア工学の立場からみれば、何一つ説明していない無意味な言葉だ。

　　「見えてくるものってなに？」
　　「なぜ、写経すると・・？」
　　「どのプログラムでもそうなの？」
　　「なぜ、そんなことがいえるの？」

　まず、こんな言葉が研究者から浴びせられるだろう。

　現場の人はめんどくさいから無視し、研究者を避けるようになるだろう。
　そして、暗黙知や経験に基づいた知識が現場に蓄積されるが、大学からはアプローチできず、差はどんどん広がっていく←イマココ

---

■現場と大学の知識の融合

　では、この架け橋になる手法はないかというと、いくつかある。

　１つは、パターン。
　パターンなら、いくつかの事例から、パターン化を試みられる。


「アジャイル型開発におけるプラクティス活用事例調査」の報告書とリファレンスガイドを公開
http://sec.ipa.go.jp/reports/20130319.html


では、パターン・ランゲージに基づいて整理されているが、それは偶然というよりは、
必然なのかもしれない・・

　また、海外であれば、「グラウンデッド・セオリー」がありえる。
　グラウンデッド・セオリーは、データに基づき（グラウンデッド　オン　データ）現場の生の声のような
質的データから、仮説を構築していく手法であり、この手法であれば、経験者の言葉から、
経験上、有効な知見を見出し、仮説構築できる。

　しかし、これは、海外の情報処理関係の学会では認められているし、
　日本の教育・医療など、情報処理関係以外の学会では認められているが、
　日本の情報処理学会で、グラウンデッド・セオリーを利用した、実務からの論文というのは、ほとんどない。


　IEEE XploreでGrounded Theoryとひくと、8,555の検索結果が返ってくるが
　日本の「情報学広場」で「グラウンデッド・セオリー」とひくと、１２件しかない。

　ただ、グラウンデッド・セオリーでまとめられないとき、エスノメソドロジーとして逃げる手がある。このエスノメソドロジーは、要求工学では認められているので、その線でいく？っていう手はあるかもしれない・・

---

ちょっとまとまりのない文になってしまったが、今のかんじは、こんなふうかな・・・

ローソンのビッグデータは、なぜ山本一郎氏に叩かれるほどの成果しか出なかったのか？

昨日、

ビッグデータは、そうやって使うもんじゃないんじゃない？そもそも・・・
http://blog.goo.ne.jp/xmldtp/e/cd13de092ea5ab00023e18539234078f

というエントリを書いたけど、あの補足

なぜ、ローソンのビックデータは、

ビッグデータという、99％の事業者には効果の無い話
http://bylines.news.yahoo.co.jp/yamamotoichiro/20130328-00024117/

に指摘されるような結果になってしまったか、
つまり、昨日のエントリのような解析はできなかったのかについて、
技術的な話を書いていなかったので、ちょっとつけたし。

---

昨日のエントリを敷衍していうと、ビッグデータをビジネスに生かすには

・まず、調査したい対象に、あたりをつける
　　→仮説はあってもなくてもいい

。その探索空間の中で、調べたいことを調べる
　　→仮説がある場合は仮説検証
　　→ないときは、潜在因子をしらべる

このとき、技術的に言うと、

・あたりを調べるのは、ＢＩツールをつかって、
　ドリリング 、スライシング、ダイシングをして、
　おもしろい（儲かりそうな？興味深い？）データ空間をみつける
　　→ＯＬＡＰ

・その空間を、データ解析テクニックを使って調べる。
　　→バッチ的に大量データで調べる

ローソンの使っている、Ｈａｄｏｏｐは、後者の、検証データをマイニングするのには
むいているが、ＢＩツールで可視化しながら、ぐるぐる見ていくには、向かない手法
なのだ。

Ｈａｄｏｏｐというのは、バッチで、大量データを処理するには向いている。
しかし、それなりの時間はかかる。
ＢＩツールみたいに、データと対話しながら、いろいろ変えながら見る
のは、Ｂｉｇ　Ｑｕｅｒｙというまた別の技術を使う。

これなしに、Ｈａｄｏｏｐだけでマイニングすると、ビッグデータをそのまま
扱うから、平均的な当たり前のことしか見えないとなる。

---

実際にはＢｉｇＱｕｅｒｙだけでは、可視化できないし、カバーしきれない
ところもある。そこで、いろいろな技術を適宜使っていくんだけど、
Ｈａｄｏｏｐで何でもできると考えてしまうと（こう考えている人多いかも？）
たいしたデータは上がってこない。

これが、失敗した原因だと思う。

世界トップクラスのセキュリティアーキテクトが語るSDNの魅力と課題

あとでよむ。

世界トップクラスのセキュリティアーキテクトが語るSDNの魅力と課題─RSA Conference 2013から
http://gihyo.jp/news/report/2013/03/2901

実務と論文のギャップ

ソフトウェア工学ネタで珍しく、ものすごいアクセスがあるようだ。
ソフトウェア工学ネタなら困らないので、今日も書いてみる。
そのうちアクセス減ったら、また止めるけど・・・


実はastahを使って要求から画面作成までを一気通貫（＆自動生成）する方法の論文が無料で見れる
http://blog.goo.ne.jp/xmldtp/e/c065809180323d35203281c33cf2be68


に書いた、その先・・・なんだけど、２つの方向がある

１つは、入出力項目から、ＤＢに行く方向、
もう一つは、要求文から一気に自動生成する方向。

上記の入出力項目からＤＢを生成する方法は、


佐藤正美,論理データベース論考―データ設計の方法:数学の基礎とT字形ER手法
ソフトリサーチセンター (2000)


に、確か出ていたかな・・・この本、はじめの数学は読み飛ばしていい。
あとのＴ字型ＥＲ図の作成手順からよみはじめる。
最近の佐藤氏の本は読んでいないのでわかんないけど、書いてあるのだろうか・・

ただ、ペーパーになると、はっきり書いてある論文は・・・みてないなあ・・
（ごめん、不勉強なだけかも）

---

実は、コンサルや実務家が本を書くのと、研究者が論文にするのには、
かなりギャップがある。

この前のastah使って・・で紹介した、小形先生、松浦先生の論文が出たのは、
２０１０年。

実務家の人が、それらしきことを言ったのは、

テクノロジックアート , C&R研究所 , 橋本 大輔, 長瀬 嘉秀,アッと驚く達人の技　UMLシステム設計実践技大全
ナツメ社(2003)

で、２００４年ごろ（本が出たのが２００３年１２月）
この本を見れば、ＵＭＬでどうすれば開発できるか、一通りわかる
（つまり、今なら１円＋送料で、ＵＭＬの開発の流れがわかる）

でもその本が出た後、日本人はヤコブソン大好きなので
（ヤコブソンも日本好きなんだよね）、ＩＣＯＮＩＸに行った。

　また、実務では、ＲＵＰなんかの方法論も出たけど、

　ＲＵＰは重くて、ＩＣＯＮＩＸには無駄もあって、

「UMLシステム設計実践技大全」の手法が圧倒的にわかりやすかったので、
この手法に落ち着いたのかな・・・

ただ、実務的には、論文に耐えうるものは出てなくて、
２０１０年のあの論文まで、待ったっていう感じかな・・
ここまで、数年の歳月が流れてる。

---

つまり、コンサルや実務家は、ラフな議論でいいので、
本が早くでる。

一方、論文、とくにフルペーパーになるのには、
ある程度厳密な議論と実証がいるので、時間がかかる。
この間、かなりギャップがある。

クラス図からＤＢ化の手法は、
現在、この時間のギャップのハザマにあるかんじかしらね。

---

一方、要求文から、直接プログラムを自動生成していく手法は、
研究者中心に活動してるけど、道半ば。

言語的に制限を加えたり、自然言語を構文解析したり。
ただ、構文解析の場合、形態素までに分けてしまうと、
文章の関連(係りうけ）とかが見えてこない。
さらに、複文・重文が作れちゃうと困る。

ってなってくると、係り受けが重要で、南瓜の出番なんだけど、
そこまでの話を、あんまり見ないんだよねえ・・
もうちょっと時間がかかるのかなあ・・・

---

実務では、マインドマップからＵＭＬという考えが、
今、勢いありますよね・・


マインド・マップとUMLを使った要求分析支援（前編）
マインド・マップの基本と応用
http://www.atmarkit.co.jp/farc/rensai/mm01/mm01a.html


実務的には、マインドマップを使って要求分析を行い、
それを、ユースケースに落としていき、
そのユースケースを元に、さらにマインドマップを使って、
アクティビティ図に発展させていくという流れが
出てくるに違いない。

　要求からユースケースを出す方法は、アカデミックな世界では、
ゴール指向分析のＫＡＯＳで議論されているので、それを
そのまま持ってきてもいい・・・

---

ただ、これを、アカデミックな世界にもっていくのには、
無理がある。

マインドマップは、恣意性がありすぎるのだ。

なんたって、はっきりした決まりがないからね。

これが、反証可能性があるか・・・とかいう問題に引っかかってくる。

素直にもって行きにくい。

---

と・こ・ろ・が・・・

ここに、ちょうど手ごろな自由度を持ったものがある。
ＲＤＦ。

これは、主語－動詞－目的語という３つ組みを表現する。
目的語を主語に入れ替えると、どんどんレゴブロックのようにつなげて、
リンクできる（Ｌｉｎｋｅｄ　Ｄａｔａ）

形態素解析で、なんかしようという流派に対しても、
主語、動詞、目的語の分類は受け入れられるものだし、

マインドマップの場合、線の上に描かれた言葉が、
主語、動詞、目的語のどれかにあたる
とすると、まあ、形になる。

ＲＤＦなら、検索とか加工もしやすい。

なので、業務体系をＲＤＦで表現するっていう話もありだ。

---

まあ、こんな感じなので、当分、実務ではマインドマップを使ったものが
先行し、アカデミックな分野では、その後を追いかけるということになるのかな
と思っている。

PressmanのSoftware Engineeringを超訳ななめ読みする その２－デートの進化

みんなから、無慈悲な稲妻を受けないために、
大事そうなところを、超訳＆ななめ読みしている

PressmanのSoftware Engineeringを超訳ななめ読みする

前回は、第一章のはじめだったので、
今日は、そのつづきから。

---

（「第一章　ソフトウェアとソフトウェア工学」つづき）

　ソフトウェアは死んだのか？もしそうなら、この本は読んでいないだろう

　コンピューターソフトウェアは、世界的に見て、唯一の最も重要な技術であり続けている。そして、「意図せざる結果の法則」の一番の例でもある。
　５年前、誰が、ソフトウェアが、ビジネス、科学、エンジニアリングに欠くことのできない技術になると予想できたであろうか。（いや、５年前には、予想できただろう・・というツッコミは無視します：このことばは原文にない）ソフトウェアは新しい技術を創出した（例えば、遺伝子工学やナノテク）。そして既存の技術を拡張した（例えば、テレコミュニケーション）。さらに古い技術を革新的に変えた（例えば印刷業）。これらのソフトウェアは、ＰＣの変革を背景として、突き動かされたものである。
　パッケージ化された（訳注：シュリンクラップ→パッケージソフトにビニールがかかっている。あのビニールをかける工程をシュリンクラップという。工場でやるのが普通だが、同人などで少ない量の場合、東急ハンズでキットが売っているらしく、それをドライヤーでほにゃほにゃすると、シュリンクされる。原文はシュリンクラップだが、パッケージ化に変えた）ソフトウェアが、近くの商店街でお客に買われたが、それが、Ｗｅｂブラウザから、ジャスト・イン・タイムで運び、オンデマンドで提供するソフト会社のサービスとして、製品が提供されるという、緩やかな進化が起きている。

　ソフトウェア会社は、もっと大きくなり、より影響力を持っている。インターネットという、ソフトが動かすネットワークは、図書の検索から、ショッピング、政治談話、若い人（やそんなに若くない人の）デートの習慣までも進化させ、変えさせた。
　誰も、ソフトウェアがあらゆる種類のシステムに組み込まれることを予見できなかった。交通、医療、テレコミュニケーション、軍事、産業、エンターテイメント、オフィス機器・・・リストを挙げれば、きりがない。
　「意図せざる結果の法則」を受け入れるなら、予見できなかった多くの結果を挙げられる。

　誰も何百万ものコンピュータープログラムが、正しく、調整されて、時間経過と共に拡張されるなんて、予見できなかった。この保守活動という負担が、新しいソフトを開発する全作業より、多くの人、多くの資源を飲み込んでいった(太字は訳者が勝手につけた）。
　ソフトウェアの重要性が増大するにつれ、ソフトウェアのコミュニティも、プログラムを構築し、保守するのに、早く、速く、高くない開発技術を継続的に試みるようになった。これらの技術のいくつかは、特定のアプリケーションのドメインを狙ったもの（例えば、Ｗｅｂデザインと実装）だったり、またある技術ドメインにフォーカスしたり（例えばオブジェクト指向のシステムや、アスペクト指向プログラミング）、さらに幅広い分野のモノもある（例えばＬｉｎｕｘなどのＯＳ）。しかし、私たちはまだ、ソフトウェア技術を開発している。人々は、仕事、快適さ、安全、エンターテイメント、意思決定、まさに生活をコンピューターのソフトウェアに期待している。それは良くなる。

　この本は、コンピューターソフトウェアを構築する人、つまりそれらを良くするに違いない人に使ってもらえるフレームワークを提供する。そのフレームワークは、プロセス、一連の方法論やツール群、つまり私たちがソフトウェア工学というものにまで広がっている。

---

　このあとから、１．１章「ソフトウェアの特徴」に入っていくけど、
　その前に、アジャイルを先にかいていこうと思う。

ビッグデータは、そうやって使うもんじゃないんじゃない？そもそも・・・

ビッグデータという、99％の事業者には効果の無い話
http://bylines.news.yahoo.co.jp/yamamotoichiro/20130328-00024117/

だけど、（以下太字は上記サイトより引用）


ローソンのCRM戦略に関する内容が界隈でバズっており、にわかに盛り上がっておりますが、あまりにも馬鹿馬鹿しいので言及しておきます。


(中略）


現実で起きていることは「あれだけのデータを活用しておきながら、たいしたことが分かっていない。あるいは発表できるレベルに達していない」という話なんですよね。なんですか、その微妙すぎるリサーチ結果は。約5,200万人の会員データを駆使して「1割の客が6割の売り上げを上げる」とか「徒歩5分以内、距離にして半径354メートルの客層にリーチする作戦だ」など、そんなもの当たり前じゃないですか。これでどうやって商品開発に繋げているんです？　

ビッグデータだhadoopだ関係なく、パネル使ってサンプル調査するだけで分かる話でしょう。


あ～、山本一郎氏がおっしゃっていることはもっともだ。
そもそも、全体論を述べるなら、ビッグデータを用いないほうがいい。

テレビの視聴率は、全国民データを集めれば、正しく集計できる（理論上）けど、
実際には、極少数のサンプルしかとってないらしい。
理由は、それで足りるから・・・

それどころか、いっぱい取ってしまうと、雑音が入ってしまう。
たとえば、２０代の男性のデータを集めて、髪型を論じることはできるかもしれない。
しかし、全国民の男性のデータを集めて、髪型を論じると、おかしなことになる。

「日本では、スキンヘッドが流行っているそうです！！」
「それ、年配の人は、ハゲが多いだけですやん　＾＾；」

みたいな・・・


さっきのテレビの視聴率でいうと、ある時間にＴｗｉｔｔｅｒやＦａｃｅｂｏｏｋで、
「この番組を見てください」というと、そこだけ、視聴率が上がる可能性がある。

現状は、視聴率のサンプルになっている世帯はみんなから知らされていないし、
リサーチ会社が管理統制できているので、おかしなことは起こらない。

たしかに大数の法則があるから、大量のデータを集めると、いろんな策略お構いなしに
真実に近くなる。しかし、そこまで大量のデータをあつめると、みんなに共通している
ことしか、言えなくなるので、当たり前の結果となる

---

　よく、ヘビーユーザーの動向を調べるが、もし、ヘビーユーザーが、
単価の安いものしか買わないと、ヘビーユーザーをいくら調べても、
安いものしか買われず、もうからなくなる。

　そうではなく、企業側が買って欲しい(儲かる)商品を、買ってもらう
ために、データを使う。そのために、ビッグデータが必要になることがある。

　たとえば、先ほどの視聴率の例で言うと、ＮＨＫが視聴率を上げるのに、
紅白歌合戦を解析しても、たいして大きな利益をもたらさない。
　今の視聴率の３倍は理論上、無理だろう（視聴率１００％を超えるので）

　それより、毎日やっているけど視聴率の少ない、ＮＨＫ高校講座の視聴率を
上げたほうが、大きく寄与する。たぶん、アノ番組、視聴率が１％もないので、
理論上は、何十倍の視聴率にすることも可能だ！

　で、高校講座を考えた場合、仮に視聴率が０．１％だとすると、これは、
１０００人集めても、１人しか見ないことになるので、これじゃ、標本にならない。
まあ、最低１００人ってことになると、１０万人？
　ところが、ＮＨＫの高校講座は、ＮＨＫ学園の人は必ず見る。この人たちを
しらべても、(必ず見る人なので）視聴率アップにならない。
　ＮＨＫ学園の人を引くと・・・１００人集めるのに、もっともっと人を集めない
といけない。さらに、その人たちをクラスタリング分析するとなると・・・
もう、１０００万人くらいあつめないと・・・

　で、その人たちが、どういう行動をとって、何を考えているか・・
　というと、まず、クラスタリングして、それぞれのペルソナをつくり、行動パターン
を推測するんだけど、そのためには、テレビの番組以外の情報も必要だし、
ＮＨＫ以外で何を見ているかが必要になる。

　ただ、あらかじめＮＨＫの高校講座を見ている人はわからないので、１０００万人の
いろいろなデータをあつめないといけなくなる。
　これで、ビッグデータになるわけ。

　ＮＨＫの紅白みたいに、多くの人が見ているデータなら、ビッグデータにしなくても
分析はできることが多い。

---

　PONTAの場合でいうと、ある特定の売りたい商品を購入した人の分析とか、
　流行っていない個店をみつけ、そのお店のお客が、
　　　他のローソン、ローソン１００に行っているか？
　　　何かっているか？
を調べるのであれば、ビッグデータは生きてくると思う。

PHP、5.3 系のサポート終了が迫るも移行進まず

ってかさあ、この前、５．２から、５．３に上げましょうとか、
いってなかったっけ？
今度は、５．４なの・・・


PHP、5.3 系のサポート終了が迫るも移行進まず
http://developers.slashdot.jp/story/13/03/26/0247229/

3月28日(木)のつぶやき

　ウィリアムのいたずら　@xmldtp　11:07

「実はastahを使って要求から画面作成までを一気通貫（＆自動生成）する方法の論文が無料で見れる」 blog.goo.ne.jp/xmldtp/e/c0658…

2 件 リツイートされました

from gooBlog production

返信 リツイート お気に入り

---

Follow @xmldtp

2012年のタブレット出荷、前年比91.3%増の462万台に

もうちょっと待てば、もっと安くなるかな・・・


2012年のタブレット出荷、前年比91.3%増の462万台に - IDC Japan
http://headlines.yahoo.co.jp/hl?a=20130328-00000020-mycomj-sci

PressmanのSoftware Engineeringを超訳ななめ読みする その１－ソフトウェアは死んだ

「アジャイルがダメだと思う7つの理由」と「ソフトウェア工学は失敗している」は同じ次元の釣り？
http://blog.goo.ne.jp/xmldtp/e/2896922420cd01406a25f75606265c2a

に関する話題、第二段。

その中で、


Software Engineering: A Practitioner's Approach, 7th International edition
http://www.amazon.com/Software-Engineering-Practitioners-Approach-International/dp/0071267824

を挙げているけど・・・はい。この本、英語で、前書きいれると900ページ以上あります。

ってことで、こんな本を挙げていると、みんなから、無慈悲な稲妻を受けそうなので、
大事そうなところを、超訳＆ななめ読みしてみたいと思います。

今日は、ＣＨＡＰＴＥＲ１、第一章、１ページ目（この前に前書きがあるけど、そこはローマ数字なので、
アラビア数字の１ページは、ここから）ＳＯＦＴＷＡＲＥ　ＡＮＤ　ＳＯＦＴＷＡＲＥ　ＥＮＧＩＮＥＥＲＩＮＧから、超訳＆ななめ読み

---

第一章　ソフトウェアとソフトウェア工学

彼は、古めかしい格好をした、大手ソフトウェア会社の上級管理職。歳は４０半ば、ちょっと白髪まじりだが整っていて、目は、話している間、聞き手（＝私）に注がれている。

だが、彼の言ったことは、私にとって衝撃的だった。

「ソフトウエアは死んだ」

私は驚いて、目をぱちくりさせた。そして、微笑んだ

「冗談だろ！
　世界はソフトウェアで回っていて、あんたの会社も、ソフトウェアのおかげで、そこそこ儲けている。
　それが、死んだだって！生きてるし、成長しているだろ！！」

彼は、強調するように、頭を振った

「いや、死んだ・・・少なくとも、私がかつて知っていた、ソフトウェアは・・・」

私は、身を乗り出した。

「つづけて・・」

彼はテーブルをたたき、強調していった

「保守的な観点からみたソフトウェア、つまり、買って、所有し、保守する、こんなソフトウェアは、終わるだろう。
今日、Ｗｅｂ２．０や拡張・強化されている情報処理は、まったく違った世代のソフトウェアだ。それは、インターネットを通じて届けられ、コンピューターデバイスに常駐している・・・んだけど、離れたサーバーにある」

私は、同意した。

「そう、人生はもっと単純になった。人々は、数千、数万のユーザーが、同じアプリなのに、違う５つのバージョンを持っているなんていう心配をする必要は、なくなった」

彼は言った

「まったくだ。たった１つの最新のバージョンがサーバーにあって、修正すると、機能的にアップデートされて、全ユーザーに届けられる。即座にね！」

私は、しかめっ面をした

「でも、もし間違えたらどうする。すべての人は、即座に同じように間違えるぞ（－＿－；）」

彼は、含み笑いをした

「たしかに。だからこそ、ソフトウェア工学がよくなるように、より一層努力しなきゃいけないわけだ。
　問題は、マーケットが加速しているため、私たちは速くやらなきゃいけないってことだ。
　すべてのアプリの分野において」

私は、もたれかかり、彼のまえに手を広げた

「なんつーか、本中華（って、知っている人少ないよね～）

　早くする、正しくする、安くする、この中から２つえらべ、

　ちゅーこったな」

彼は、起き上がって言った

「速さと、正確さを選ぶ」
（そりゃそーさな。メーカーだから、お金は多くもらいたい。安いというのは選ばんよ）

わたしも立ち上がった

「つーことは、おまえさんも、ソフトウェア工学が必要なわけだ」

彼は、動きながら言った

「わかってるよ」

「問題は・・・だ、他の世代の技術者に、納得させることだ」

---

ここで、第1章の、はじまりの第１段落がおわり。
次に、第二段落もこのぐらいのレベルで訳して、
そのあと、本当に超訳（見出し＋コメントくらい）にしていきたいと思う。

アジャイルは３章なので、順番にやると、もっと先になってしまう。
そこで、順番関係なしに、アジャイルだけ先にやる。

ＣａｋｅＰＨＰの１．Ｘ系と、２．Ｘ系で何が違うのか－その４

ＰＨＰの１．Ｘ系と、２．Ｘ系で何が違うのか
同じものを作って比較してみる。

前回モデルを使って、１．Ｘ系でのお話をしたので、
今回はモデルを使って、２．Ｘ系でのお話をする

---

■御題

ＣａｋｅＰＨＰの１．Ｘ系と、２．Ｘ系で何が違うのか－その３
http://blog.goo.ne.jp/xmldtp/e/7cb8c389e19edc5e694cf720abf4580b

と同じ御題。

---

■追加・修正部分

ファイル構造は、

その１
http://blog.goo.ne.jp/xmldtp/e/493d369c8d635b3a269d4e02dcc7ae95

の２．ＸにModelが加わったかんじ。つまり、こんな感じ

app
　｜
　｜-Controller
　｜　｜
　｜　＊－MyTestController.php
　｜
　｜-Model
　｜　｜
　｜　＊－User.php
　｜
　＊－View
　　　｜
　　　＊－MyTest
　　　　　　｜
　　　　　　｜－hello.ctp
　　　　　　｜
　　　　　　＊－index.ctp

（赤字が追加修正箇所）
Modelが追加され、コントローラーが修正される

---

■追加部分に関して

　追加するUser.phpの中身は、１．Ｘのときと一緒。
　つまり、その３のuser.phpのファイルの中身と、まったく同じでよい。

---

■修正部分に関して
　修正するMyTestController.phpは、はじめの引数を渡す部分だけは違うが（これは、その１のときに書いた）、あとは基本的にその３のuser.phpのファイルの中身と、同じでよい。以下のような感じ。

<?php
class MyTestController extends AppController {
	public $uses = 'User'; 

	public function index() {

	}

	public function hello() {
		$yourname =$this->data['yourname'];

		//	DBアクセスして値取得
		$condition = array("user_name" => $yourname);
		$records = $this->User->find("first",array("conditions" => $condition));
		if ( count($records['User']) > 0 )
		{
			$kaisu = $records['User']['kaisu'] + 1;

			//	DBアクセスして更新
			$data['User'] = array('id' => $records['User']['id'], 'kaisu' => $kaisu);
			$fields = array('kaisu');
			$this->User->save($data, false, $fields);
		}
		else
		{
			$kaisu = 1;

			//	DBアクセスして追加
			$data['User'] = array('user_name' => $yourname, 'kaisu' => 1);
			$this->User->save($data);
		}

		//	Viewに設定
		$this->set('yourname',$yourname);
		$this->set('kaisu',$kaisu);
	}
}

なかんじかな・・・

実はastahを使って要求から画面作成までを一気通貫（＆自動生成）する方法の論文が無料で見れる

なんか、

「アジャイルがダメだと思う7つの理由」と「ソフトウェア工学は失敗している」は同じ次元の釣り？
http://blog.goo.ne.jp/xmldtp/e/2896922420cd01406a25f75606265c2a

の反響が大きいらしい・・・？

なので、ちょっと、これに関して、何点か、付け足しておく。

まず、第一点。

現在の日本のソフトウェア工学を論じるうえで、


「実は、astahを使って、要求から画面のソース作成までを一気通貫
　（＆自動生成）する方法は、論文が出ていて、無料で見られる」


っていう事実は知っておいたほうがいい。
そして、その手法の使い方を変えるだけで、ウォーターフォールから、
インクリメンタル、スパイラル、アジャイルが全部、導き出せる。

まず、その論文は、これ

UML要求分析モデルからの段階的なWeb UIプロトタイプ自動生成手法
コンピュータ ソフトウェアVol. 27 No. 2,日本ソフトウェア科学会(2010)
https://www.jstage.jst.go.jp/article/jssst/27/2/27_2_2_14/_pdf


ここで、示されている手法は以下のとおり

（上記の図は、上記論文より引用）

上流部分の一部は、この論文の対象外となっているようなので、そこを
付け加えて、全部書くと、こんな手順になる。

（ここは付け足した）
・なにをやりたいかをきめ、そのやりたいことに関する人を挙げる
　人とやりたいことを結ぶと、ユースケース図になる。
　ここで、やりたいことを、以下、「サービス」という
　また、人は何でもしてよいわけではない。
　何ができるかを決めたものを以下「権限」とよぶ

　　　　↓

（ここから、論文の内容）
・サービスの実行手順と、そのサービスの入出力をまとめ、
　アクティビティ図に描く
　　→この論文で言っているアクティビティ図は、普通のアクティビティ図
　　　と同じではないが、astahのアクティビティ図で書ける


　　　　↓

・その入出力項目の項目名と関連をしらべて、クラス図にまとめる


　　　　↓

・具体的にどんな値を入れるかを例を出して考え、オブジェクト図にまとめる
　　→ここで、検証する
　　→シナリオ単位の入出力にまとめる→テスト内容が確定する

　　　　↓

・サービスの実行手順をきめて（画面遷移→ナビゲーションが決まる）
　　アクティビティ図にまとめる
（論文には書いてないけど）
　　普通は画面遷移図だろうけど、
　　astahに画面遷移図はないからなあ～

　　　　↓
　その画面をもとに、自動生成

---

　この手法は、画面からデータ構造を決めている。
　したがって、最近の画面→クエリ→ＤＢ作成の手法には向いているんだけど、
　「ＤＢは、正規化したもの」にする、従来の手法を用いる場合には、
　クラス図にした入出力項目を元に、ＤＢのテーブル（ないしＥＲ図）
　を作ることになる。

　この手法は、佐藤正美氏の本などに出ている。
　ただ、この手の論文はでていないかな・・・

　しかし、最近は正規化をしないので（ＣａｋｅＰＨＰでbakeでつくるときなど）
　これでもいいわけだ。

---

　松浦先生のところで、小形先生（論文発表当時は、芝浦工大のたしかＤ？現在、信州大）がこの論文を出したので、ここから先、単にCakePHPとかで、全自動生成したとしても、卒論レベルならＯＫだけど、フルペーパーでは、ちょっとね・・・っていうレベルになった・・気がする。

ちょっと、脳内で妄想してみてね。

ある修士の院生が来て・・・

（院生）ＣａｋｅＰＨＰで、要求から全自動でプログラミングを作るという「リサーチ・クエスチョン」で修士論文を書きたいと思います。

（先生）ほお、どう、アプローチするんだい。

（院生）まず、関連研究で、 「UML要求分析モデルからの段階的なWeb UIプロトタイプ自動生成手法」を挙げます

（先生）うん

（院生）そこで出てくるクラス図をastahでつくり、プラグインを作って、項目名を抽出、ＳＱＬを作成して、ＤＢを自動生成します。

（先生）なるほど、ＤＢは自動生成できるね。そこから・・・

（院生）はい、bakeをたたいて、ＤＢからモデルを作ります。

（先生）・・・

（院生）そして、bakeをたたいて、モデルからコントローラーを作り、
　　　　最後に、bakeをたたいて、コントローラーからビューを作ります。
　　　　従来、手作業でやっていたことを、プログラムで自動化して行うので、
　　　　とてもはやく仕上がります！

（先生）それ、２年間で・・・

（院生）はい！（＾＾）ｖ（満面の笑み）

（先生）・・・それって、３ヶ月ぐらいでできないか（＾＾；）・・・
　　　　bakeもいいけど、zfとか、symfonyとかもたたいてみて、
　　　比較する気は、ないかね（＾＾；；；；・・・・・


　卒論や研究会発表なら、ある方法論、まあcakePHPでもいいや、ＣＯＲＢＡでもいいや、ＳＯＡＰ使っても、ＲＥＳＴでも


ソフトウェア工学は失敗している
http://d.hatena.ne.jp/nowokay/20130322#1363969460


に出てくる技術を一つ挙げて自動化っていうのも、アリだと思う。

　ただ、修士論文以上、博士論文、フルペーパーになると、
　それでは、スコープ小さすぎで、

・クラス図から項目名に基づき自動的に正規化し、ＤＢの論理構造と
　画面の物理構造を連結するコントローラー等を自動生成する手法

・cake,Zend,symfonyなど、いろいろな手法を切り替えて、自動生成できる
　フレームワーク

　ぐらいにならないと・・・


　ただし、経験論文ならありだと思う。上記の手順で、実際に仕事を請けてやった場合の論文を、経験論文を受け付けている研究会で発表するのは、大アリだと思う。
　だけど、そのとき、机上の空論をしてるんじゃ、もうだめぽで、そのとき、どういう問題があって、どう解決したかまでが、求められる。ただ、ここまでいくと、大学の先生や研究所ではできない
（そんなソフト開発のお仕事は請けないからね。大学は・・
　・・・ただし産学連携ＩＴ授業として論文にするのはありかな）

---

　次の話題。その手法の使い方を変えるだけで、ウォーターフォールから、
インクリメンタル、スパイラル、アジャイルが全部、導き出せるということだけど、

上記で自動生成は、要求→設計→コーディング（のはじめ：自動生成）まで行っている。
このまま、コーディングののこり（カスタマイズ部分）と、テストをやるとして、

のように、まず、設計対象となる、全ての部分について、

・サービスの実行手順と、そのサービスの入出力をまとめ、

それが、全システム終わったら、設計段階ということで

・その入出力項目の項目名と関連をしらべて、クラス図にまとめる

さらにそれが全システム終わったらＵＩ設計ということで、

・サービスの実行手順をきめて（画面遷移→ナビゲーションが決まる）

というように、全体が終わってから、次の工程にいくと、ウォーターフォールになる。

一方

のように、全サービスをいくつかのサービスに分割し、その中で、
上記の要求、設計、ＵＩ、実装って入っていくと、
これは、インクリメンタルモデル。


スパイラルは、ベームが提唱した理論の場合、各フェーズでプロトタイプを
つくる。ってことは、一番初めに挙げている図１のカタチで、ＷＦをやるに
過ぎない。

アジャイルは、基本的に、どの順番でやるかは、まかされている。
まあ、１つのサービスを一気に作っちゃったほうが、はやいかな？

Ｗ字開発は、オブジェクト図を作って、具体的データを考える（ＣＳＶとかつくる）
際に、テスト項目も考えると、設計時にテスト仕様書をつくることができる。

ってことで、この論文をベースに、いろんな開発プロセスにもっていけるわけよ。

---

で、この論文の先を、今、みんな考えているわけなんだけど、
まあ、それについては、このエントリ、いくらなんでも長くなりすぎたので、
このへんで切って、別の機会に。

「世界一即戦力な男」は、「砂に埋まった社長」の会社に就職したらしい・・・

ベストマッチング！

世界一即戦力な男、菊池良が株式会社LIGに入社する事になりました。
http://liginc.co.jp/omoshiro/other-omoshiro/15829

ＣａｋｅＰＨＰの１．Ｘ系と、２．Ｘ系で何が違うのか－その３

ＰＨＰの１．Ｘ系と、２．Ｘ系で何が違うのか
同じものを作って比較してみる。

前回までで、１．Ｘと２．Ｘで、モデルを使わない形での話だったので、
今回は、モデルを使って、１．Ｘ系でのお話をする

---

■お題


その１
http://blog.goo.ne.jp/xmldtp/e/493d369c8d635b3a269d4e02dcc7ae95

と同じお題なのだが、
ＲＤＢのＭｙＳＱＬ内（データベース名test）に、
usersというテーブルがあって、
こんな感じ

で、項目（id,user_name,kaisuの３項目）とデータが入っている。
これを検索し、
　　入力された名前がDBのuser_nameと一致したら、
　　　　そのデータのkaisuに１を足して表示
　　入力された名前がDBのuser_nameになかったら
　　　　１回目と表示して
　データをＤＢに保存する。

---

■追加・修正部分

今回は、モデル部分を追加する（基本的にcakePHPの命名規約[2]に準拠）。
また、コントローラー部分(my_test_controller.php）を修正することになる。
とくに、コントローラー名とモデル名が違うケースとなる。

ファイル構造は、以下のとおり
app
　｜
　｜-controllers
　｜　｜
　｜　＊－my_test_controller.php
　｜
　｜-models
　｜　｜
　｜　＊－user.php
　｜
　＊- views
　　　　｜
　　　　＊－my_test
　　　　　　　　｜
　　　　　　　　｜－hello.ctp
　　　　　　　　｜
　　　　　　　　＊－index.ctp

赤字が変更・追加部分

---

■追加・修正ファイル

変更・追加したファイル(上記の赤字）のみ掲載する。変わらないViewについては、
その１を参照

●コントローラー部分の修正my_test_controller.php

<?php
class MyTestController extends AppController {

	var $name = 'MyTest';
	public $uses = 'User'; 

	public function index() {
	}

	public function hello() {
		//	画面引数の取得
		$yourname =$this->params['form']['yourname'];

		//	DBアクセスして値取得
		$condition = array("user_name" => $yourname);
		$records = $this->User->find("first",array("conditions" => $condition));
		if ( count($records['User']) > 0 )
		{
			$kaisu = $records['User']['kaisu'] + 1;

			//	DBアクセスして更新
			$data['User'] = array('id' => $records['User']['id'], 'kaisu' => $kaisu);
			$fields = array('kaisu');
			$this->User->save($data, false, $fields);
		}
		else
		{
			$kaisu = 1;

			//	DBアクセスして追加
			$data['User'] = array('user_name' => $yourname, 'kaisu' => 1);
			$this->User->save($data);
		}

		//	Viewに設定
		$this->set('yourname',$yourname);
		$this->set('kaisu',$kaisu);

	}
}

●モデル部分の追加user.php

<?php

class User extends AppModel{



var $name = 'User';



}

参考文献[1][3]を参考に作成

---

■参考文献

[1]CakePHPのModelを使う データベース関連処理をシンプルに解決
http://puyo2.upper.jp/cake/files/cakephp4.pdf

[2]cakePHP クラス名、モデル名の命名ルール
http://www.wakatta-blog.com/cakephp_2.html

[3]CakePHPのfind, findAll, findCount, delete, deleteAll
http://techracho.bpsinc.jp/piichan1031/2009_01_21/132

堀江貴文元社長が仮釈放

だそうな。
Lineの今の状況を見ると、堀江氏が旧ライブドアをで築きあげた
ＩＣＴに貢献した部分は大きかったと思うが、
今後はどうか・・


堀江貴文元社長が仮釈放　旧ライブドア粉飾決算事件
http://news.goo.ne.jp/article/asahi/nation/TKY201303270067.html