いくらなんでも、ソフトウェア工学話で引っ張るのは、無理が出てきたし、
アジャイルをダメにしないためにすべきこと
http://arclamp.hatenablog.com/entry/2013/03/28/000000
で、大体話がまとまってきたので、もうそろそろ、ソフトウェア工学ネタ
はうちも、終わりにしていいかな・・・
と思って、話をまとめる方向に行ってみたいと思う。
上記の「アジャイルをダメにしないためにすべきこと」は
結局、「アジャイルだけではない」という話だと思います。
現実は、その通りだと思います。
アジャイルで向いているプロジェクトもあるし、
アジャイルに向いていないプロジェクトもある。
だから、アジャイルで有名な永和システムさんも、
１００％アジャイル案件なわけではないし
（と、この前聞いた。聞き間違い出なければ）
日本のプロジェクトのかなり多くがウォーターフォールであるのは、
「ソフトウェア開発データ白書 2012-2013」
（http://sec.ipa.go.jp/publish/tn12-002.html
にいき、アンケートに答えるとＰＤＦ版が無料で手に入る）
の４２ページ「図表４－５－１ 開発ライフサイクルモデル」
でウォーターフォールが９６．５％なことからもわかる。
アジャイルは現状、Ｗｅｂの開発では多く利用されているみたいだけど、
「図表４－４－１１ 開発言語」にあるように、Ｊａｖａの
次に多いのはＣＯＢＯＬっていうぐらい、Ｗｅｂ以外の開発も
現存していて、そんなＣＯＢＯＬを利用する開発では
アジャイルって、なじみにくいかもしれない。
（ＣＯＢＯＬは、入出力が「カチッ」としていたほうが書きやすい
あんまり、変わるとやりにくい）
脱線：
でも、この調査すごいよな。ＡＢＡＰがあって、Ｒｕｂｙがない（＾＾；）
Rubyより、InputManのほうが、有名なのか（＾＾；）
ってなことで、実際は、ネットで議論されているよりも、
ウォーターフォールは存在するし、たぶんだからこそ、
ウォーターフォールでうまく行かない部分を、
アジャイルに期待している部分があって
自分の今やっている仕事の否定として、アジャイルが存在している可能性がある。
ウォーターフォールは、属人性の排除を目指し、
ソフトウェアファクトリー化
できるんじゃないかとの期待をもった。
これが、ソフトウェア工学となじみやすく、
自動化の話や品質管理の分野が進んだ。
今も進んでいて、ウォーターフォールでできる、
カチッとた大規模開発は、自動化を目指していくだろう。
そして、ソフトウェア工学も、この分野では進んでいく。
要求工学の一部とＭＤＡ、品質管理の一部は、この分野かな
一方、Ｗｅｂの世界は、アジャイル開発に向いている。
そんな世界は、ユーザーのＵＸ要望は高いし、他社の出方によって、ビジネスモデル
が大きく変わる。
でも、アジャイルは、人が変わると同じことをやっても、
うまく行くとは限らない。人の部分が結構ある。
この手の話は、日本のソフトウェア工学では、
現状、パターンランゲージとか、事例研究以外の分野では
論文になりにくく、学会では、フルペーパーを通している人は少ないと思う。
情報学広場（情報処理学会の論文が検索できる）で
アジャイルで検索すると、１３２件
ＵＭＬで検索すると８４１件だから、
ＵＭＬほどには、アジャイルはぜんぜん広まっていない。
日本のソフトウェア工学の教科書もこんな感じなので、
アジャイルとかは、あまり出ていない。
この現状は、
ソフトウェア工学は失敗している
http://d.hatena.ne.jp/nowokay/20130322#1363969460
で指摘されている。
ただ、だからソフトウェア工学は「だめ」なんだという話には、実は、ならない。
博士号をとるために論文を書くのであれば、たしかに、
情報処理学会、信学会、ソフトウェア科学会の中から考えるが、
そうじゃなく、著名な先生であれば、ＩＥＥＥに自分の論文を
出すことを考えるだろうし、まあ、普通の大学院生なら、関連研究に
国内だけでなく、ＩＥＥＥやＡＣＭを調べるのは必須だ。
IEEE Xploreで
agileを引くと４４８５
UMLを引くと4224
アジャイルのほうが、出ている論文が多いのだ
そして、さっき
PressmanのSoftware Engineeringを超訳ななめ読み その３－各種アジャイル
http://blog.goo.ne.jp/xmldtp/e/6c4fb02e21f0c2c267d77431ed845e12
に書いたように、アメリカなどでの教科書的に読まれる
Pressmanの本では、日本で紹介されていないようなアジャイル手法が、
ガンガン出ている。
日本では、リーンやScrumが話題だが、それは日本ではそうなだけで、
（たぶん、日本の風土に合っているんでしょうね）海外では違う。
そして、海外では、（のちのち紹介していくけど）ウォーターフォールも
スパイラルもアジャイルも形式手法もアスペクト指向も
ちゃーんとソフトウェア工学の範囲になっている。
つまりで書かれているのは、日本の現状の「情報処理学会、信学会、ソフトウェア科学会」で出ているソフトウェア工学の話であり、IEEEとかで扱うソフトウェア工学は、「ソフトウェア工学は失敗している」で挙げている分野、さらにそれより広い広い領域を扱っている。
つまり、日本のソフトウェア工学は、問題あるかもしれないけど、
世界的に見ると、「ソフトウェア工学」は実務の分野も含んでいる。
そして困ったことに、日本でソフトウェア工学を専攻する普通の？大学院生であれば、
IEEEとかACMを中心に調べ、テキストとしては、今取り上げているPostmanの本か、
Pfleegerさんの最新版の原著
Software Engineering: Theory and Practice
http://www.amazon.co.jp/dp/0136061699
とかで勉強しちゃう
（これは、「ソフトウェア工学は失敗している」で挙げている
「ソフトウェア工学―理論と実践」の原著の最新版）
Pfleegerさんの本も、アジャイルを最近足しているらしい。
そして、さらに困ったことに、まあ、そこそこの大学院生や大学の先生は英語読めちゃうので
ＩＥＥＥの論文とか、さっき挙げたテキストを読んで、あんまり日本の本や論文を気にしない。
訳してもらいたいとも思わないし、訳す暇もない。なんだったら、英文で論文を書く気も満々！
つまり、研究者の目は海外、特に国際的なＩＥＥＥとかに向いている
（ＩＥＥＥは、アメリカの団体だけど、学界的には世界に開かれている、国際的な場となっている）
結果、日本のソフトウェア工学が遅れているように見えて、
それを一般の開発者がみると、
「なにやってんだ！日本のソフトウェア工学は！！」
という論調になってしまう。
なんで、本当にアジャイル、さらにソフトウェア工学全般を
勉強したいのなら、世界を相手にして、
英語の本や論文を読まないと、はじまらない・・・
・・・っていうのが、現状なのよ・・・
でもね、えいご、にがてなんです・・・
だれかやくしてほしい・・・
Ｐ．Ｓ Ｇｏｏｇｌｅ翻訳をかけると、
なおさら判らない訳になる・・・
アジャイルをダメにしないためにすべきこと
http://arclamp.hatenablog.com/entry/2013/03/28/000000
で、大体話がまとまってきたので、もうそろそろ、ソフトウェア工学ネタ
はうちも、終わりにしていいかな・・・
と思って、話をまとめる方向に行ってみたいと思う。
上記の「アジャイルをダメにしないためにすべきこと」は
結局、「アジャイルだけではない」という話だと思います。
現実は、その通りだと思います。
アジャイルで向いているプロジェクトもあるし、
アジャイルに向いていないプロジェクトもある。
だから、アジャイルで有名な永和システムさんも、
１００％アジャイル案件なわけではないし
（と、この前聞いた。聞き間違い出なければ）
日本のプロジェクトのかなり多くがウォーターフォールであるのは、
「ソフトウェア開発データ白書 2012-2013」
（http://sec.ipa.go.jp/publish/tn12-002.html
にいき、アンケートに答えるとＰＤＦ版が無料で手に入る）
の４２ページ「図表４－５－１ 開発ライフサイクルモデル」
でウォーターフォールが９６．５％なことからもわかる。
アジャイルは現状、Ｗｅｂの開発では多く利用されているみたいだけど、
「図表４－４－１１ 開発言語」にあるように、Ｊａｖａの
次に多いのはＣＯＢＯＬっていうぐらい、Ｗｅｂ以外の開発も
現存していて、そんなＣＯＢＯＬを利用する開発では
アジャイルって、なじみにくいかもしれない。
（ＣＯＢＯＬは、入出力が「カチッ」としていたほうが書きやすい
あんまり、変わるとやりにくい）
脱線：
でも、この調査すごいよな。ＡＢＡＰがあって、Ｒｕｂｙがない（＾＾；）
Rubyより、InputManのほうが、有名なのか（＾＾；）
ってなことで、実際は、ネットで議論されているよりも、
ウォーターフォールは存在するし、たぶんだからこそ、
ウォーターフォールでうまく行かない部分を、
アジャイルに期待している部分があって
自分の今やっている仕事の否定として、アジャイルが存在している可能性がある。
ウォーターフォールは、属人性の排除を目指し、
ソフトウェアファクトリー化
できるんじゃないかとの期待をもった。
これが、ソフトウェア工学となじみやすく、
自動化の話や品質管理の分野が進んだ。
今も進んでいて、ウォーターフォールでできる、
カチッとた大規模開発は、自動化を目指していくだろう。
そして、ソフトウェア工学も、この分野では進んでいく。
要求工学の一部とＭＤＡ、品質管理の一部は、この分野かな
一方、Ｗｅｂの世界は、アジャイル開発に向いている。
そんな世界は、ユーザーのＵＸ要望は高いし、他社の出方によって、ビジネスモデル
が大きく変わる。
でも、アジャイルは、人が変わると同じことをやっても、
うまく行くとは限らない。人の部分が結構ある。
この手の話は、日本のソフトウェア工学では、
現状、パターンランゲージとか、事例研究以外の分野では
論文になりにくく、学会では、フルペーパーを通している人は少ないと思う。
情報学広場（情報処理学会の論文が検索できる）で
アジャイルで検索すると、１３２件
ＵＭＬで検索すると８４１件だから、
ＵＭＬほどには、アジャイルはぜんぜん広まっていない。
日本のソフトウェア工学の教科書もこんな感じなので、
アジャイルとかは、あまり出ていない。
この現状は、
ソフトウェア工学は失敗している
http://d.hatena.ne.jp/nowokay/20130322#1363969460
で指摘されている。
ただ、だからソフトウェア工学は「だめ」なんだという話には、実は、ならない。
博士号をとるために論文を書くのであれば、たしかに、
情報処理学会、信学会、ソフトウェア科学会の中から考えるが、
そうじゃなく、著名な先生であれば、ＩＥＥＥに自分の論文を
出すことを考えるだろうし、まあ、普通の大学院生なら、関連研究に
国内だけでなく、ＩＥＥＥやＡＣＭを調べるのは必須だ。
IEEE Xploreで
agileを引くと４４８５
UMLを引くと4224
アジャイルのほうが、出ている論文が多いのだ
そして、さっき
PressmanのSoftware Engineeringを超訳ななめ読み その３－各種アジャイル
http://blog.goo.ne.jp/xmldtp/e/6c4fb02e21f0c2c267d77431ed845e12
に書いたように、アメリカなどでの教科書的に読まれる
Pressmanの本では、日本で紹介されていないようなアジャイル手法が、
ガンガン出ている。
日本では、リーンやScrumが話題だが、それは日本ではそうなだけで、
（たぶん、日本の風土に合っているんでしょうね）海外では違う。
そして、海外では、（のちのち紹介していくけど）ウォーターフォールも
スパイラルもアジャイルも形式手法もアスペクト指向も
ちゃーんとソフトウェア工学の範囲になっている。
つまりで書かれているのは、日本の現状の「情報処理学会、信学会、ソフトウェア科学会」で出ているソフトウェア工学の話であり、IEEEとかで扱うソフトウェア工学は、「ソフトウェア工学は失敗している」で挙げている分野、さらにそれより広い広い領域を扱っている。
つまり、日本のソフトウェア工学は、問題あるかもしれないけど、
世界的に見ると、「ソフトウェア工学」は実務の分野も含んでいる。
そして困ったことに、日本でソフトウェア工学を専攻する普通の？大学院生であれば、
IEEEとかACMを中心に調べ、テキストとしては、今取り上げているPostmanの本か、
Pfleegerさんの最新版の原著
Software Engineering: Theory and Practice
http://www.amazon.co.jp/dp/0136061699
とかで勉強しちゃう
（これは、「ソフトウェア工学は失敗している」で挙げている
「ソフトウェア工学―理論と実践」の原著の最新版）
Pfleegerさんの本も、アジャイルを最近足しているらしい。
そして、さらに困ったことに、まあ、そこそこの大学院生や大学の先生は英語読めちゃうので
ＩＥＥＥの論文とか、さっき挙げたテキストを読んで、あんまり日本の本や論文を気にしない。
訳してもらいたいとも思わないし、訳す暇もない。なんだったら、英文で論文を書く気も満々！
つまり、研究者の目は海外、特に国際的なＩＥＥＥとかに向いている
（ＩＥＥＥは、アメリカの団体だけど、学界的には世界に開かれている、国際的な場となっている）
結果、日本のソフトウェア工学が遅れているように見えて、
それを一般の開発者がみると、
「なにやってんだ！日本のソフトウェア工学は！！」
という論調になってしまう。
なんで、本当にアジャイル、さらにソフトウェア工学全般を
勉強したいのなら、世界を相手にして、
英語の本や論文を読まないと、はじまらない・・・
・・・っていうのが、現状なのよ・・・
でもね、えいご、にがてなんです・・・
だれかやくしてほしい・・・
Ｐ．Ｓ Ｇｏｏｇｌｅ翻訳をかけると、
なおさら判らない訳になる・・・
アクセス
トータル
ランキング
