|
|
|
|
コメント(23)
始めまして。→ EDO13th さん。
EDO13thさん>今さっき気がついたら200人超えてましたね
EDO13thさん>すごいすごい。結構盛り上がって来ているので楽しみです。
おおっ・・・、本当だ。いつの間に 200名を超えてしまってますね。
ｵﾒﾃﾞﾄﾊﾞｸﾀﾞﾝ ｴｲｯ (ﾉ^-^)ﾉ ⌒ ●~*
ありがとうございます。→ ALL。この調子で、少しづつメンバーが増えていくと嬉しい物です。
EDO13thさん>私自身は理系から文系(組織学)をメインに切り替えてきているので、そういった視点から皆さんと話していけたらな。と思います。
ソフトウェア工学ですから、プロセス絡みでその辺も大切なトピックだと思います。そう言った観点からご意見を頂ければありがたいです。出来ればバザールのようにメンバーが各々の得意分野を持ち寄って、意見・情報の交換ができればと思っています。
トピックも自由に立てて頂いて結構なので、ふるってご活用ください。
∃ □ =ﾉ 勹_〆(･･ )
EDO13thさん>今さっき気がついたら200人超えてましたね
EDO13thさん>すごいすごい。結構盛り上がって来ているので楽しみです。
おおっ・・・、本当だ。いつの間に 200名を超えてしまってますね。
ｵﾒﾃﾞﾄﾊﾞｸﾀﾞﾝ ｴｲｯ (ﾉ^-^)ﾉ ⌒ ●~*
ありがとうございます。→ ALL。この調子で、少しづつメンバーが増えていくと嬉しい物です。
EDO13thさん>私自身は理系から文系(組織学)をメインに切り替えてきているので、そういった視点から皆さんと話していけたらな。と思います。
ソフトウェア工学ですから、プロセス絡みでその辺も大切なトピックだと思います。そう言った観点からご意見を頂ければありがたいです。出来ればバザールのようにメンバーが各々の得意分野を持ち寄って、意見・情報の交換ができればと思っています。
トピックも自由に立てて頂いて結構なので、ふるってご活用ください。
∃ □ =ﾉ 勹_〆(･･ )
> このコミュのメンバ−にはソフトウェア工学に従事していて、現場の生の状況なり問題を知りたいと思っている人も多いと思います。
え〜只今ハムレットさんから紹介に預かりました…訳じゃないのですが…現場の生の状況なり問題を知りたいと思っている人間の一人であります。
とある問題（ちょっとマイナー系）に関しまして、色々な論文に書かれている「解決方法」を実際のプログラムに適用できるかなあ、とつらつら思いながら10万行くらいのソースコードの（ごく一部）をしこしこ手で解析したことがあります。（実は今もやっていますし、これからも続けていくつもりですが）
結果は「現実的には絶対無理」あるいは「それは現実的な解決ではない」というものでした。私の研究の場合、そういう結論に至った理由が研究ネタっぽくなりました。
ここで言うところの「現実的」とは何？
みたいな話を（ちょっとだけですけど）しなければならなくなったからです。単に量が多いとかそういう話だけじゃなくて「現場の人間はそういう考え方をしない、何故ならば」みたいな議論も含みます。
大学に篭って頭の中だけで考えていると問題の一部しか見られなくて現実的にはありえないような「解決策」を考えてしまいがちです。
例えば「プログラムのセキュリティーを静的に検証する」という問題。
「自分の書いたプログラムが見せてはいけないものを見せていないかどうか」を静的に検証するのは有りでしょうが、
「サーバーに他所からアクセスしてくるコードなんかで、他人の書いたもの」だと基本的には静的な検証なんて不可能ですよね。少なくともアクセスされたときに初めて検証が可能になるわけで。
「一度コードの静的なチェックを済ませておけば動的なチェックが要らなくなるから実行が早くなる云々」という理屈は前者の場合には正しいのでしょうが、後者に関しては成り立たないのです。
まあ、分かり易いように極端な例を挙げてしまいましたが…
> 「すれ違い、勘違いから始まる、ソフトウェア工学。」
上の場合には始まるのではなくて終わってしまいかねない危険性があるのですがまあそれはともかく、ソフトウェアの研究は具体例が命だと思う次第です。
研究と現場の双方で例や手法や流行の技術などの交換が出来れば幸いです。私も色々公にできるようになったら具体例の話とかしたいです。
え〜只今ハムレットさんから紹介に預かりました…訳じゃないのですが…現場の生の状況なり問題を知りたいと思っている人間の一人であります。
とある問題（ちょっとマイナー系）に関しまして、色々な論文に書かれている「解決方法」を実際のプログラムに適用できるかなあ、とつらつら思いながら10万行くらいのソースコードの（ごく一部）をしこしこ手で解析したことがあります。（実は今もやっていますし、これからも続けていくつもりですが）
結果は「現実的には絶対無理」あるいは「それは現実的な解決ではない」というものでした。私の研究の場合、そういう結論に至った理由が研究ネタっぽくなりました。
ここで言うところの「現実的」とは何？
みたいな話を（ちょっとだけですけど）しなければならなくなったからです。単に量が多いとかそういう話だけじゃなくて「現場の人間はそういう考え方をしない、何故ならば」みたいな議論も含みます。
大学に篭って頭の中だけで考えていると問題の一部しか見られなくて現実的にはありえないような「解決策」を考えてしまいがちです。
例えば「プログラムのセキュリティーを静的に検証する」という問題。
「自分の書いたプログラムが見せてはいけないものを見せていないかどうか」を静的に検証するのは有りでしょうが、
「サーバーに他所からアクセスしてくるコードなんかで、他人の書いたもの」だと基本的には静的な検証なんて不可能ですよね。少なくともアクセスされたときに初めて検証が可能になるわけで。
「一度コードの静的なチェックを済ませておけば動的なチェックが要らなくなるから実行が早くなる云々」という理屈は前者の場合には正しいのでしょうが、後者に関しては成り立たないのです。
まあ、分かり易いように極端な例を挙げてしまいましたが…
> 「すれ違い、勘違いから始まる、ソフトウェア工学。」
上の場合には始まるのではなくて終わってしまいかねない危険性があるのですがまあそれはともかく、ソフトウェアの研究は具体例が命だと思う次第です。
研究と現場の双方で例や手法や流行の技術などの交換が出来れば幸いです。私も色々公にできるようになったら具体例の話とかしたいです。
どうも、フォローコメントありがとうございます。→ hei, Izu-ruさん。
hei, Izu-ruさん>ソフトウェアの研究は具体例が命だと思う次第です。
うーん、確かにそうですね。ちょっと見方が違うと思いますが、例えば、RDBMS に使われる SQL ですが、最新のバージョンの仕様書には、まだ実装されていない項目がたくさんあるそうですね。仕様策定者の知的好奇心、研究的関心が先走ってと言えばそれまでですが、理論と現実のギャップってこの世界多いですし、現実に使ってみてはじめて見えてくる現象や問題も多いと思います。
hei, Izu-ruさん>大学に篭って頭の中だけで考えていると問題の一部しか見られなくて現実的にはありえないような「解決策」を考えてしまいがちです。
ただ、これは現場の方にも課題はあると思います。案外とソフトウェアって業界は３文字略語で新規性を尊ぶような振りをして、実は本質的には保守性の強いところかもしれないと思う今日この頃です。車輪の再発明を、トレンドだと言って持て囃したりと言いながら、本当に新しい概念には、意外とそっぽを向いてしまう。業界特有のデスマを誘発するような労働事情もあるかもしれないですが、自分の知識の範囲でしか現実を知らないし、それ以上、知ろうとも思わないような現実もあります。
前に外注さんに一度、「次の仕事はちょっと XP テイストにやりませんか」と提案したら、「個人的にやってみたいけど、業務としては会社の方針もあるし、難しい。」とか返事が返ってきました。新しい技術について、熱心に覚えようとする技術者に限って、実は転職準備中だったりとかしますしね。(ノд・。) ｸﾞｽﾝ
そんな感じで、仕事にソフトウェア工学的なアプローチで改善を図ろうと試みても、それをどう説明しようか、よく悩むケースが多いです。と言うわけ、
hei, Izu-ruさん>研究と現場の双方で例や手法や流行の技術などの交換が出来れば幸いです。私も色々公にできるようになったら具体例の話とかしたいです。
よろしくお願いします。↑ m(._.)m
hei, Izu-ruさん>ソフトウェアの研究は具体例が命だと思う次第です。
うーん、確かにそうですね。ちょっと見方が違うと思いますが、例えば、RDBMS に使われる SQL ですが、最新のバージョンの仕様書には、まだ実装されていない項目がたくさんあるそうですね。仕様策定者の知的好奇心、研究的関心が先走ってと言えばそれまでですが、理論と現実のギャップってこの世界多いですし、現実に使ってみてはじめて見えてくる現象や問題も多いと思います。
hei, Izu-ruさん>大学に篭って頭の中だけで考えていると問題の一部しか見られなくて現実的にはありえないような「解決策」を考えてしまいがちです。
ただ、これは現場の方にも課題はあると思います。案外とソフトウェアって業界は３文字略語で新規性を尊ぶような振りをして、実は本質的には保守性の強いところかもしれないと思う今日この頃です。車輪の再発明を、トレンドだと言って持て囃したりと言いながら、本当に新しい概念には、意外とそっぽを向いてしまう。業界特有のデスマを誘発するような労働事情もあるかもしれないですが、自分の知識の範囲でしか現実を知らないし、それ以上、知ろうとも思わないような現実もあります。
前に外注さんに一度、「次の仕事はちょっと XP テイストにやりませんか」と提案したら、「個人的にやってみたいけど、業務としては会社の方針もあるし、難しい。」とか返事が返ってきました。新しい技術について、熱心に覚えようとする技術者に限って、実は転職準備中だったりとかしますしね。(ノд・。) ｸﾞｽﾝ
そんな感じで、仕事にソフトウェア工学的なアプローチで改善を図ろうと試みても、それをどう説明しようか、よく悩むケースが多いです。と言うわけ、
hei, Izu-ruさん>研究と現場の双方で例や手法や流行の技術などの交換が出来れば幸いです。私も色々公にできるようになったら具体例の話とかしたいです。
よろしくお願いします。↑ m(._.)m
はじめまして、ひやま（檜山）と申します。まずは参加のごあいさつです。が、このトピック内に興味を感じた発言があります。それはhei, Izu-ruさんの：
> 大学に篭って頭の中だけで考えていると問題の一部しか見られなくて現実的にはありえないような「解決策」を考えてしまいがちです。
と、それに対するハムレットさんのコメント：
> ただ、これは現場の方にも課題はあると思います。[snip]
です。
アカデミズムが現場から遊離する問題よりむしろ、僕は逆のケースに懸念をいだいています。つまり、現場が、ソフトウェア工学や計算科学を配慮しない（ありていに言って無知である／無視している）ために、（広い意味における）損失を被っているような状況の存在です。
そう感じるのは僕の単なる偏見なのか、ある程度は普遍的な現象なのか、よくはわかりませんけど。
> 大学に篭って頭の中だけで考えていると問題の一部しか見られなくて現実的にはありえないような「解決策」を考えてしまいがちです。
と、それに対するハムレットさんのコメント：
> ただ、これは現場の方にも課題はあると思います。[snip]
です。
アカデミズムが現場から遊離する問題よりむしろ、僕は逆のケースに懸念をいだいています。つまり、現場が、ソフトウェア工学や計算科学を配慮しない（ありていに言って無知である／無視している）ために、（広い意味における）損失を被っているような状況の存在です。
そう感じるのは僕の単なる偏見なのか、ある程度は普遍的な現象なのか、よくはわかりませんけど。
hei, Izu-ru さん:
> 例えば「プログラムのセキュリティーを静的に検証する」という問題。 --- 以下略 ---
はい，プログラムのセキュリティーを静的に検証する研究をやっている者です．(笑)
と言っても，決して噛み付きにきたわけではありませんので，どうぞご安心を．hei, Izu-ru さんとは研究仲間でもありここらへんの認識では，ズレはないはずですので...
実際に私の周囲を見ていると，ソフトウェア開発の何が難しいのかわかっていないし，わかろうともしない研究者が多いです．あるいは，わかっていても研究しやすい問題に流れていく傾向が強いですね．かつて開発現場に居た者としては，歯がゆいばかりです．
ハムレットさん:
> 案外とソフトウェアって業界は３文字略語で新規性を尊ぶような振りをして、実は本質的には保守性の強いところかもしれないと思う今日この頃です。
ひやまさん:
> つまり、現場が、ソフトウェア工学や計算科学を配慮しない（ありていに言って無知である／無視している）ために、（広い意味における）損失を被っているような状況の存在です。
関係するかどうかわかりませんが，僕は以前からなぜ悪名高いウォーターフォールモデルが日本のソフトウェア業界でいつまでもはびこっているのかが不思議でなりませんでした．
日本のソフトウェア開発はパッケージ開発型より受託開発型が多いからじゃないかと勝手に憶測していたのですが，今読んでいる以下の書籍に面白い指摘がありました．
前川 徹:「ソフトウェア最前線」，アスペクト
この書籍の分析によると，日本の多くの企業がウォーターフォールモデルをいつまでも使っている理由は，上流から下流に向かう工程の流れが，大企業から下請けに発注(丸投げ)する業界の階層構造にうまく一致しているからだということです．私は独立系のソフトウェアハウスで勤務していたので，そこらへんの事情に明るくないのですが，私の居た大学院の卒業生(彼らは大企業の側)の意識を聞いてると，まんざらはずれてもいないような気がします．実際のところどうなんでしょう?
長くなってしまってすいません．トピを変えた方が良かったでしょうか．
> 例えば「プログラムのセキュリティーを静的に検証する」という問題。 --- 以下略 ---
はい，プログラムのセキュリティーを静的に検証する研究をやっている者です．(笑)
と言っても，決して噛み付きにきたわけではありませんので，どうぞご安心を．hei, Izu-ru さんとは研究仲間でもありここらへんの認識では，ズレはないはずですので...
実際に私の周囲を見ていると，ソフトウェア開発の何が難しいのかわかっていないし，わかろうともしない研究者が多いです．あるいは，わかっていても研究しやすい問題に流れていく傾向が強いですね．かつて開発現場に居た者としては，歯がゆいばかりです．
ハムレットさん:
> 案外とソフトウェアって業界は３文字略語で新規性を尊ぶような振りをして、実は本質的には保守性の強いところかもしれないと思う今日この頃です。
ひやまさん:
> つまり、現場が、ソフトウェア工学や計算科学を配慮しない（ありていに言って無知である／無視している）ために、（広い意味における）損失を被っているような状況の存在です。
関係するかどうかわかりませんが，僕は以前からなぜ悪名高いウォーターフォールモデルが日本のソフトウェア業界でいつまでもはびこっているのかが不思議でなりませんでした．
日本のソフトウェア開発はパッケージ開発型より受託開発型が多いからじゃないかと勝手に憶測していたのですが，今読んでいる以下の書籍に面白い指摘がありました．
前川 徹:「ソフトウェア最前線」，アスペクト
この書籍の分析によると，日本の多くの企業がウォーターフォールモデルをいつまでも使っている理由は，上流から下流に向かう工程の流れが，大企業から下請けに発注(丸投げ)する業界の階層構造にうまく一致しているからだということです．私は独立系のソフトウェアハウスで勤務していたので，そこらへんの事情に明るくないのですが，私の居た大学院の卒業生(彼らは大企業の側)の意識を聞いてると，まんざらはずれてもいないような気がします．実際のところどうなんでしょう?
長くなってしまってすいません．トピを変えた方が良かったでしょうか．
どうも、管理人です。
コメントありがとうございます。→ ひやまさん、おとんさん。
ひやまさんのサイトを覗かせていただきましたが、なかなか渋い文章をお書きになるんですね。例えば、ソフトウェア工学に関する以下の文章は中々書ける物じゃないと思います。
http://www.symmetric.co.jp/hiyama/SoftwareEngineering.htm
特に以下の文面には笑った後、深く納得させられました。
ひやまさん>アジャイルの人々は、ウォーターフォールに代表されるような、今となってはどうでもいいような（というか弊害が多い）方法を批判するために、（おそらくは戦略的に）「ソフトウェア工学」をスケープゴートに選んだのでしょう (*注2)。現場の人々から好まれてないソフトウェア工学を叩けば、アピーリングだし、現場の人からウケそうですから。
別にアジャイルな手法を否定するつもりは全然ないのですが、アジャイル手法の動向・ムーブメントに何がしか違和感を感じていました。その辺に適切な言葉を与え、見事に表現していただいた感じです。「歴史を学ばないものは、未来を閉ざす事になるだろう。」って言ったところでしょうか。
コメントありがとうございます。→ ひやまさん、おとんさん。
ひやまさんのサイトを覗かせていただきましたが、なかなか渋い文章をお書きになるんですね。例えば、ソフトウェア工学に関する以下の文章は中々書ける物じゃないと思います。
http://www.symmetric.co.jp/hiyama/SoftwareEngineering.htm
特に以下の文面には笑った後、深く納得させられました。
ひやまさん>アジャイルの人々は、ウォーターフォールに代表されるような、今となってはどうでもいいような（というか弊害が多い）方法を批判するために、（おそらくは戦略的に）「ソフトウェア工学」をスケープゴートに選んだのでしょう (*注2)。現場の人々から好まれてないソフトウェア工学を叩けば、アピーリングだし、現場の人からウケそうですから。
別にアジャイルな手法を否定するつもりは全然ないのですが、アジャイル手法の動向・ムーブメントに何がしか違和感を感じていました。その辺に適切な言葉を与え、見事に表現していただいた感じです。「歴史を学ばないものは、未来を閉ざす事になるだろう。」って言ったところでしょうか。
おとんさん＞この書籍の分析によると，日本の多くの企業がウォーターフォールモデルをいつまでも使っている理由は，上流から下流に向かう工程の流れが，大企業から下請けに発注(丸投げ)する業界の階層構造にうまく一致しているからだということです．
この辺は確かにそう言う傾向は強いですね。別のコミュ（http://mixi.jp/view_community.pl?id=8128）で「 ウォーターフォール型以外の開発手法で開発って行われてるんでしょうか？」ってトピ（http://mixi.jp/view_bbs.pl?id=717731）がありましたが、トピの提供者の方は金融系の人でしたね。金融系って結構、規模の大きなシステム開発が多い、仕様定義が明確である事が建前の固い世界な分、大企業が元受けとなるゼネコンちっくに分業化が進んでいる分野だと思います。多分に IT 分野の需要の多くの割合をしめているでしょうし。
おとんさん＞長くなってしまってすいません．トピを変えた方が良かったでしょうか．
長くなるのはやぶさかではありませんが、新規にトピを立てて頂くのはありがたいです。歓迎します。
この辺は確かにそう言う傾向は強いですね。別のコミュ（http://mixi.jp/view_community.pl?id=8128）で「 ウォーターフォール型以外の開発手法で開発って行われてるんでしょうか？」ってトピ（http://mixi.jp/view_bbs.pl?id=717731）がありましたが、トピの提供者の方は金融系の人でしたね。金融系って結構、規模の大きなシステム開発が多い、仕様定義が明確である事が建前の固い世界な分、大企業が元受けとなるゼネコンちっくに分業化が進んでいる分野だと思います。多分に IT 分野の需要の多くの割合をしめているでしょうし。
おとんさん＞長くなってしまってすいません．トピを変えた方が良かったでしょうか．
長くなるのはやぶさかではありませんが、新規にトピを立てて頂くのはありがたいです。歓迎します。
初めまして。元は画像処理の研究、その後は組み込みや通信のSEやってました。今は事情あってWeb管理に従事してます。
ソフトウェア工学には一貫して関心があります。上の方でウォーターフォールモデルが何故未だに用いられているのかの説明で業界の構造で説明しているのを読んで、なるほど、と思いました。
最近「ビューティフルアーキテクチャ」読みましたが、設計されたシステムの構造がチームの構造を反映する経験則をコンウェイの法則と呼ぶのだそうですね。これでいくと業界がITゼネコン状態になっているかぎりウォーターフォールモデルは不滅、てことになりかねません。
やはり組織論の様なものも併せて議論する必要がありそうです。
よろしくお願いします。
ソフトウェア工学には一貫して関心があります。上の方でウォーターフォールモデルが何故未だに用いられているのかの説明で業界の構造で説明しているのを読んで、なるほど、と思いました。
最近「ビューティフルアーキテクチャ」読みましたが、設計されたシステムの構造がチームの構造を反映する経験則をコンウェイの法則と呼ぶのだそうですね。これでいくと業界がITゼネコン状態になっているかぎりウォーターフォールモデルは不滅、てことになりかねません。
やはり組織論の様なものも併せて議論する必要がありそうです。
よろしくお願いします。
- mixiユーザー
- ログインしてコメントしよう！
|
|
|
|
ソフトウェア工学 更新情報
-
最新のアンケート
-
まだ何もありません
-
