アカウント名:
パスワード:
大学は職業訓練施設じゃないんだから、教える側だって即業務に使えるになるスキルの伝授なんて考えてないでしょ。プログラマになれればよいのなら大学で学位を取得することは最短コースでは無いと思います。
ただ、コンピューターサイエンスをほとんど勉強していないプログラマってアルゴリズムの評価もできなかったりするので、恐ろしいコードを書いてしまう人もしばしば。よいソースコードをたくさん読むのが大事なのは言うまでも無いことだけど、背景となる知識が無いと、なぜそのアルゴリズムが選択されたのか、なぜほかの方法ではだめなのかがわからないと思うんだよね。
アメリカだと事情違ったりするんでしょうかね?
#OSの授業、学生時代は役に立たないだろと思って馬鹿にしてました。ごめんなさい、結構役に立ってます。
元の話を建築で考えると、構造計算を含めて設計からできる設計士と、現場で腕をふるう職人を一緒くたにするくらい乱暴な混同をしているように思うのだが。
建物建てるのに設計士と職人、ともに必要だし、各々の教育方法は異なる。
ソフトウェアも本来同じで求められる職能が異なるはずなのに、なぜか「プログラマーだけいればいい」と思われている。
同じ「アーキテクチャ」を作る仕事なのに。
時代の変化に追いつけてないんですよね。
最初に、コンピュータを使うためには、まず、コンピュータかプログラムを作るところから始めないといけない時代があって、その時代に大活躍した大学の先生らが作ったカリキュラムがそのまま続いている感じで。当時は、コンピュータを作れるような人でなければ、コンピュータ関係の仕事はできない状態だったので間違ってはいなかったんですが。
作らなくても使える時代へ突入して、「コンピュータシステムを支える仕事」と言っても多岐に渡るようになる一方、必要とされる知識も、ネットワークやらセキュリティやらとジャンルが増えていますし。昔ながらの画一的な教育から始めて、増えた分まで全部盛り込むのは時間が足りるはずもありません。
2015年問題の昨今、時代の変化こそが問題なの。
「作らなくても使える時代」と言っていた頃はまだ使う側もディシプリンが有り、使う側と作る側が拮抗していて何とかなったでしょうけど、
その使う側の人が育てた次世代の人間はもう「今までとはさらに違う新しいやり方として、作る側に完パケを要求するだけ」にまでなっていて、だれも下に付けなくなって(いくら献身的な人間でも)いて、しかも2015年問題なんで、お手上げもいいとこ。
建築士と職人なら拮抗するでしょうけど、大家(気取りの新人)と職人だと、本当にお仕舞い。
「作らなくても使える時代」は正しいですが、社会現象としてみた際には、別の言い方を考えないと、次に進めない様に思います。
コンピュータサイエンスに関しては、大学の先生が制御系の出身が多く、二十年前から同じことを教えている状況ですよね。組み込み系なんかで実務家教員を入れているところもあるけど、従来型の教員は「あんなものは職人芸であって学問として昇華できるものではない」と見下す風潮があって何だかなという感じ。
設計と実装で必要な職能が違うという考え方については、建築と違ってソフトウェアの設計と実装は明確に分離できない、分離する意味がないという問題があるのだけど、ITを建築業界に例える悪習は、多重下請構造とか、SE単価○○円、PG単価○○円とかの世界を成立させるために存在しているだけですよね。大手SIerにはコードをろくに書いたことのない設計者はよくいるけど、COBOL全盛の時代とはもう違うんで無理がある
プログラムコードのコピー容易性を取り上げているのであれば、たしかにソフトウェアは特殊。
しかし、いかに優れたプログラマーでも、プログラム言語とかコンパイラや基本ライブラリ(=釘レベル)から作ったりしない。今時はさらに、高度なライブラリをいろいろ寄せ集めてくるのが普通。
また、建築でも、ログハウスや1軒屋であれば、優秀な大工だけでできる。そのレベルの小さいもので、少数でよいソフトウェアがあるのは確かだが、それは腕の良い大工が粋な一軒家を建てるようなもの。
分業が必要なのは、ビルのような巨大なものを作るとき。ソフトウェアでも、そのレベルになれば、全体の計算量やリソース管理、メンテナンス性考えたレイヤー構成やAPI設計が必要になる。
もちろん、設計者レベルと職人レベルの両方出きる奴もいるだろうが、プログラミングだけあるいはコンピュータサイエンスだけ学んできたものが必ずしも両方できるわけではない。ましてや、広く使われるものであれば有るほど多数の例外処理対策が必要で、分業化出来ないと、どうしようもない。
ソフトウェアの特殊な点は、やっぱテストでしょ。
建築なら円筒状のコンクリートに上から力をかけておしまいで、後は安全係数を金次第でいくらでもかけられる(知らないので想像)のに対し、ソフトウェアは正しく賽の河原で、設計者が困難すぎ、容易に燃え尽き、それを職人のせいに転嫁する結末ばっか。
後、建築(土木)だとバンスとバンスの差は施工後には致命的でも、ソフトウェアでは(比較的ではありますが)許容出来る場合もあります。(当然、手戻り費用は掛かりますが)
分業だと職人は嬉しいですが、設計者はいいのですかね。
建築だと構造計算を行い、コストと安全性のバランスを事前に見積もりします。そして最低限の安全性を確保しておくことを、法律で決めています。ソフトウェアでそういう計算をすることって、よほどの大規模プロジェクトだけだよね。
建物全体として、台風に耐えられるか、地震に耐えられるか、それに相当する物をソフトウェア開発前に見積もりする人がいない。もしくは、そこを軽視している。建物では完成品を地震に耐えられるかテストすることは難しいけど、ソフトウェアではテストできてしまう。だから、部品を作った後に何とかしようとしてしまい、結果、賽の河原になってしまうんでしょうね。
本来であれば、そもそもお金や工数がかかることを発注者にわかってもらった上で取り組まないといけないはずなのに、目に見えないものだから、「ちゃちゃっと作っちゃってよ」になっている案件が多いのだと思う。
また、目に見えないものだから設計変更もお手軽と思われているのか、既に設計終わったりある程度作ってしまっているものに対して、大幅な設計変更を要求してきたり。
建築でいえば、すでに設計図もできて基礎も完成している段階で、建物の形変えるような要求出してくる施主がまかり通っているのでは?
法律に基づき、見積もりのソフトを選定してもらえれば、率先して使うつもりです。
でも無いじゃないですが。
その言い方だと、なんもかんも政治が悪いとなってしまう。
分業するにしても、(建築で言う)設計と(建築で言う)製造をきれいに分けるやり方はソフトウェア分野ではそぐわないのでは。
完全な見積もりは難しいでしょうけど、「大幅か小幅か」を施主さんにも分かり易く示せるメトリックだけでも有るといいんですよね。
星形16芒星の建物を17芒星にするのは大変だが18芒星なら小幅だとか。
#逆に言うとそれが出来れば、完全な見積もりも出来るという支配的な問題なのかも知れませんが。
#まったく。
意味が分からない。見積もりのソフトとか、政治って何ですか?
その一端は、ソフトウェアの開発側にもあるとおもいます。電子機器設計の会社でハードもソフトも付き合いありますが、ソフトウェアの会社って会社の規模によらず信じられないぐらい安請け合いしちゃうんだよね。自分たちが何を売ってるのか、契約とは何なのか知らないんじゃ無いかと心配になる。
買う側は相手がソフトだろうと、ハードだろうと、半分演技ではありますが知らないふりして無理難題を言う物です。それがまかり通ってるのは、要求をのむソフトウェアの開発側のせいでしょ。自業自得としか言いようが無い。受け入れられないと知っていれば、無理な要求はしません。時間の無駄だから。
コードを書く人が設計者で、コンパイラが製造or現場。そういう認識が構造的な問題につながってると思う。本来必要なはずの、建設で言うところの設計者の仕事を放棄してる。
私の認識では、以下の方が近いと思う。コードを書く人=建築で言う現場の作業者コンパイラ=建築で言う、クレーンとか、ミキサー車、重機の類
設計者と呼べるのは、以下のことをする人。どのような言語やライブラリを使って開発するのがいいか検討するどれだけの機能を実装すれば十分か検討するどれだけの検証をすれば十分か検討するどれだけの性能を発揮するか見積もるそして、それを顧客に説明して納得してもらう役割を担う。
ソフトウェア分野って、こういう仕事を営業担当とか顧客側に期待して、逃げてないか?
SEという人たちがそういう仕事をすることになってることが多いですが、彼らからは画面イメージとDB設計しか出てこないことが多いです。そして、SEが設計をしているのでPGはコーディングの仕方さえ知ってればよいということで、設計手法も学んでない新人が割り当てられることが多いですね。つまり、だれも設計をしない状態で行き当たりばったりの作業を行って最終的には精神論で残業・休日出勤をしているのが現実です。
そう言う考え方なら、プログラミングは原木を建築資材に加工する仕事なんじゃないかと思う。職人の腕次第で曲がった柱ができてしまったり。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
大学は職業訓練施設じゃないから (スコア:4, すばらしい洞察)
大学は職業訓練施設じゃないんだから、教える側だって即業務に使えるになるスキルの伝授なんて考えてないでしょ。
プログラマになれればよいのなら大学で学位を取得することは最短コースでは無いと思います。
ただ、コンピューターサイエンスをほとんど勉強していないプログラマってアルゴリズムの評価もできなかったりするので、
恐ろしいコードを書いてしまう人もしばしば。
よいソースコードをたくさん読むのが大事なのは言うまでも無いことだけど、背景となる知識が無いと、なぜその
アルゴリズムが選択されたのか、なぜほかの方法ではだめなのかがわからないと思うんだよね。
アメリカだと事情違ったりするんでしょうかね?
#OSの授業、学生時代は役に立たないだろと思って馬鹿にしてました。ごめんなさい、結構役に立ってます。
Re:大学は職業訓練施設じゃないから (スコア:5, すばらしい洞察)
元の話を建築で考えると、構造計算を含めて設計からできる設計士と、現場で腕をふるう職人を一緒くたにするくらい乱暴な混同をしているように思うのだが。
建物建てるのに設計士と職人、ともに必要だし、各々の教育方法は異なる。
ソフトウェアも本来同じで求められる職能が異なるはずなのに、なぜか「プログラマーだけいればいい」と思われている。
同じ「アーキテクチャ」を作る仕事なのに。
Re: (スコア:0)
時代の変化に追いつけてないんですよね。
最初に、コンピュータを使うためには、まず、コンピュータかプログラムを作るところから始めないといけない時代があって、
その時代に大活躍した大学の先生らが作ったカリキュラムがそのまま続いている感じで。
当時は、コンピュータを作れるような人でなければ、コンピュータ関係の仕事はできない状態だったので間違ってはいなかったんですが。
作らなくても使える時代へ突入して、「コンピュータシステムを支える仕事」と言っても多岐に渡るようになる一方、
必要とされる知識も、ネットワークやらセキュリティやらとジャンルが増えていますし。
昔ながらの画一的な教育から始めて、増えた分まで全部盛り込むのは時間が足りるはずもありません。
Re:大学は職業訓練施設じゃないから (スコア:1)
2015年問題の昨今、時代の変化こそが問題なの。
「作らなくても使える時代」と言っていた頃はまだ使う側もディシプリンが有り、
使う側と作る側が拮抗していて何とかなったでしょうけど、
その使う側の人が育てた次世代の人間はもう「今までとはさらに違う新しいやり方と
して、作る側に完パケを要求するだけ」にまでなっていて、だれも下に付けなく
なって(いくら献身的な人間でも)いて、しかも2015年問題なんで、お手上げも
いいとこ。
建築士と職人なら拮抗するでしょうけど、大家(気取りの新人)と職人だと、
本当にお仕舞い。
「作らなくても使える時代」は正しいですが、社会現象としてみた際には、
別の言い方を考えないと、次に進めない様に思います。
Re:大学は職業訓練施設じゃないから (スコア:1)
コンピュータサイエンスに関しては、大学の先生が制御系の出身が多く、二十年前から同じことを教えている状況ですよね。組み込み系なんかで実務家教員を入れているところもあるけど、従来型の教員は「あんなものは職人芸であって学問として昇華できるものではない」と見下す風潮があって何だかなという感じ。
設計と実装で必要な職能が違うという考え方については、建築と違ってソフトウェアの設計と実装は明確に分離できない、分離する意味がないという問題があるのだけど、ITを建築業界に例える悪習は、多重下請構造とか、SE単価○○円、PG単価○○円とかの世界を成立させるために存在しているだけですよね。大手SIerにはコードをろくに書いたことのない設計者はよくいるけど、COBOL全盛の時代とはもう違うんで無理がある
Re: (スコア:0)
それはソフトウェアの特殊性を全く無視している。
どんな優秀な大工でも家建てるのに鉄融かして釘や金槌作るところから始めるヤツはいないが、優秀なプログラマーは処理系の一つや二つ自作した経験があるのはあたり前。優れた建物ほど多数の人間が建設に関わっていることが多いが、優れたソフトウェアはほとんどの場合ごく少ない人数(1人とか)で作られている。
Re:大学は職業訓練施設じゃないから (スコア:1)
プログラムコードのコピー容易性を取り上げているのであれば、たしかにソフトウェアは特殊。
しかし、いかに優れたプログラマーでも、プログラム言語とかコンパイラや基本ライブラリ(=釘レベル)から作ったりしない。今時はさらに、高度なライブラリをいろいろ寄せ集めてくるのが普通。
また、建築でも、ログハウスや1軒屋であれば、優秀な大工だけでできる。そのレベルの小さいもので、少数でよいソフトウェアがあるのは確かだが、それは腕の良い大工が粋な一軒家を建てるようなもの。
分業が必要なのは、ビルのような巨大なものを作るとき。ソフトウェアでも、そのレベルになれば、全体の計算量やリソース管理、メンテナンス性考えたレイヤー構成やAPI設計が必要になる。
もちろん、設計者レベルと職人レベルの両方出きる奴もいるだろうが、プログラミングだけあるいはコンピュータサイエンスだけ学んできたものが必ずしも両方できるわけではない。ましてや、広く使われるものであれば有るほど多数の例外処理対策が必要で、分業化出来ないと、どうしようもない。
Re: (スコア:0)
ソフトウェアの特殊な点は、やっぱテストでしょ。
建築なら円筒状のコンクリートに上から力をかけておしまいで、
後は安全係数を金次第でいくらでもかけられる(知らないので想像)
のに対し、ソフトウェアは正しく賽の河原で、設計者が困難すぎ、
容易に燃え尽き、それを職人のせいに転嫁する結末ばっか。
後、建築(土木)だとバンスとバンスの差は施工後には致命的でも、
ソフトウェアでは(比較的ではありますが)許容出来る場合もあります。
(当然、手戻り費用は掛かりますが)
分業だと職人は嬉しいですが、設計者はいいのですかね。
Re: (スコア:0)
建築だと構造計算を行い、コストと安全性のバランスを事前に見積もりします。
そして最低限の安全性を確保しておくことを、法律で決めています。
ソフトウェアでそういう計算をすることって、よほどの大規模プロジェクトだけだよね。
建物全体として、台風に耐えられるか、地震に耐えられるか、それに相当する物をソフトウェア開発前に見積もりする人がいない。
もしくは、そこを軽視している。
建物では完成品を地震に耐えられるかテストすることは難しいけど、ソフトウェアではテストできてしまう。
だから、部品を作った後に何とかしようとしてしまい、結果、賽の河原になってしまうんでしょうね。
Re:大学は職業訓練施設じゃないから (スコア:1)
本来であれば、そもそもお金や工数がかかることを発注者にわかってもらった上で取り組まないといけないはずなのに、目に見えないものだから、「ちゃちゃっと作っちゃってよ」になっている案件が多いのだと思う。
また、目に見えないものだから設計変更もお手軽と思われているのか、既に設計終わったりある程度作ってしまっているものに対して、大幅な設計変更を要求してきたり。
建築でいえば、すでに設計図もできて基礎も完成している段階で、建物の形変えるような要求出してくる施主がまかり通っているのでは?
Re: (スコア:0)
法律に基づき、見積もりのソフトを選定してもらえれば、率先して使うつもりです。
でも無いじゃないですが。
その言い方だと、なんもかんも政治が悪いとなってしまう。
分業するにしても、(建築で言う)設計と(建築で言う)製造をきれいに分けるやり方は
ソフトウェア分野ではそぐわないのでは。
Re: (スコア:0)
完全な見積もりは難しいでしょうけど、「大幅か小幅か」を施主さんにも分かり易く示せる
メトリックだけでも有るといいんですよね。
星形16芒星の建物を17芒星にするのは大変だが18芒星なら小幅だとか。
#逆に言うとそれが出来れば、完全な見積もりも出来るという支配的な問題なのかも知れませんが。
#まったく。
Re: (スコア:0)
意味が分からない。
見積もりのソフトとか、政治って何ですか?
Re: (スコア:0)
人間がするのはすべて前者で、後者はエンターキーを押せばコンパイラとかリンカとかCOPYコマンドとかが全部自動でやってくれる。
Re: (スコア:0)
その一端は、ソフトウェアの開発側にもあるとおもいます。
電子機器設計の会社でハードもソフトも付き合いありますが、ソフトウェアの会社って会社の規模によらず信じられないぐらい安請け合いしちゃうんだよね。
自分たちが何を売ってるのか、契約とは何なのか知らないんじゃ無いかと心配になる。
買う側は相手がソフトだろうと、ハードだろうと、半分演技ではありますが知らないふりして無理難題を言う物です。
それがまかり通ってるのは、要求をのむソフトウェアの開発側のせいでしょ。自業自得としか言いようが無い。
受け入れられないと知っていれば、無理な要求はしません。時間の無駄だから。
Re: (スコア:0)
コードを書く人が設計者で、コンパイラが製造or現場。そういう認識が構造的な問題につながってると思う。
本来必要なはずの、建設で言うところの設計者の仕事を放棄してる。
私の認識では、以下の方が近いと思う。
コードを書く人=建築で言う現場の作業者
コンパイラ=建築で言う、クレーンとか、ミキサー車、重機の類
設計者と呼べるのは、以下のことをする人。
どのような言語やライブラリを使って開発するのがいいか検討する
どれだけの機能を実装すれば十分か検討する
どれだけの検証をすれば十分か検討する
どれだけの性能を発揮するか見積もる
そして、それを顧客に説明して納得してもらう役割を担う。
ソフトウェア分野って、こういう仕事を営業担当とか顧客側に期待して、逃げてないか?
Re: (スコア:0)
SEという人たちがそういう仕事をすることになってることが多いですが、彼らからは画面イメージとDB設計しか出てこないことが多いです。そして、SEが設計をしているのでPGはコーディングの仕方さえ知ってればよいということで、設計手法も学んでない新人が割り当てられることが多いですね。
つまり、だれも設計をしない状態で行き当たりばったりの作業を行って最終的には精神論で残業・休日出勤をしているのが現実です。
Re: (スコア:0)
そう言う考え方なら、プログラミングは原木を建築資材に加工する仕事なんじゃないかと思う。
職人の腕次第で曲がった柱ができてしまったり。