コンピューターサイエンスの学位を取るよりも、コードを学ぶことの方が重要? 56
ストーリー by headless
学習 部門より
学習 部門より
本家/.「Does Learning To Code Outweigh a Degree In Computer Science?」より
大学で学位を取得することは、プログラミングを仕事にするために最良の道ではない。数多くの求人がコンピューターサイエンスを専攻した人を対象としているものの、大学を卒業したからといって必要なスキルが身についているとは限らないことに雇用者が(求職者も)すぐに気づくことも多い。Cody Scholberg氏はEpoch Timesの記事で、「実質的にすべてのコンピューターサイエンスカリキュラムが理論を重視し、実用的なプログラミング技術はおまけ程度に教えているためだ」と述べている。このことはプログラマーの世界でよく聞かれる話と結びつく。米国では半分近くのソフトウェア開発者は大学を卒業しておらず、高校を卒業していない人も多い。その代わりにプログラマーになろうとする人の多くがオープンソースのコードを教材にして学習するか、米国中に出現している短期集中プログラミング講座で学習しているといったものだ。理論が有益な場面もあるが、仕事の現場で必要とされているスキルを大学で教えているかどうか、オープンソースによる学習が増える中で大学の位置付けはどのようなものか、といった問題をこの状況は提起している。
大学は職業訓練施設じゃないから (スコア: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)
「即業務に使えるになる」→「即業務に使える」
お恥ずかしい・・・
Re: (スコア:0)
「学位を取る」ってタイトルが非常に釣り臭いと感じるのだけど、
このタレコミは多分、「プログラミングを仕事にする」を最終目標とした場合に、
自分が学んだ事とは無関係の「学位」という肩書が就職で有利に働くかどうかってレベルの
問いかけなんだろうね。
この文脈での「重要」ってのはその人の就職の瞬間のみに掛かっているのだろう。
Re: (スコア:0)
> この文脈での「重要」ってのはその人の就職の瞬間のみに掛かっているのだろう。
就職の瞬間に有利に働くかどうかと、1年後5年後10年後まで有利(でいられる可能性があるかどう)かどうかというのは別の話だしね。
Re: (スコア:0)
職人でない人を雇うには、専門のレフェリーを呼んで
タイトルに相応しいか再度査読してもらうとかが致命的に
重要になるとしか思えません。
レフェリーなら海外から招聘すれば居るのでは
ないでしょうか?
Re: (スコア:0)
実際には成績優秀なコンピュータサイエンスの学生って、
プログラミング言語の1つや2つ自主的にマスターしてますよね。
即戦力とはいかなくとも現場のお作法を1ヶ月くらい先輩に質問してれば、
そこそこの戦力に成長するはず。
問題は、コンピュータサイエンスを修めたと言いながら、
得意なプログラミング言語の1つも無いような落ちこぼれではないかと。
まあ、海外の事情は分かりませんが。
Re: (スコア:0)
アメリカの大学でコンピュータサイエンスを専攻していました。
> アメリカだと事情違ったりするんでしょうかね?
たぶん同じです。
アメリカでもコンピュータサイエンスはあくまでも「サイエンス」です。
実学的なことはインターンシップの現場体験から学びます。
その前段階の学生は開発なんて全く経験しませんし、
「Aを取ってもMacの電源の点け方は知らない」などと言われます。
つまり、学位を持っていても即戦力にはなりませんし、企業側もそう扱いません。
ただし最近では、学生側からも企業側からも、実学への需要が高まっていて、
それに対応して学科や学部を新設・増設する大学が
仕事と趣味は違うし、学問とも違うんじゃない (スコア:2, 興味深い)
もう、だいぶ前のことになるが、はじめて仕事でプログラミングしたときに、戸惑ったのは仕様書の書き方だった。
プログラムそのものは、趣味でやってたときのほうがはるかに難しかった。
Re:仕事と趣味は違うし、学問とも違うんじゃない (スコア:2, 興味深い)
自分の場合は見積もりだったなぁ。
実績ない人間が、どれくらいでできるか数字を出せって無理な話しだと思った。
Re: (スコア:0)
既知の課題を解決するのにかかる時間なら経験を積めば正確に算出することもできるだろうけど、こと計算機の世界においてそんなのは究極にはボタン1つ押すだけで済むはずなんだから、わざわざ見つもるほどのものではない。
Re: (スコア:0)
実は、決定しなきゃいけないモノのボリュームで見積もりはだいたい決まりますね。
実際の作業なんて、仕様策定と設計からすればどうとでも成るものですから。
若者には最先端の技術を見せてやれよ (スコア:1)
そもそも職務に必要なスキルだったら会社の教育でどうにかするべきなのだが
それが無いのが派遣社員の時代なのかね。「即戦力」とやらが要求される。
中途採用だと「即戦力」かどうかを問題にしても構わないだろう。
実務経験ないから自腹で短期集中講座を受けてウリにするという話ならまだ分かる。
短期集中プログラミング講座が流行しているのなら、そこに任せておけばいい。
大学なんだからアカデミックな勉強をさせるべきだ。
若者には最先端の技術を見せてやれよ。
そうしないと社会全体の損失になる。
Re: (スコア:0)
アメリカあたりではずーっと前から会社は教育なんかしなくて、能力にカネ払うだけだよ。
新卒だとか中途だとかの区別もない。
思うに、質問者はCSが求人の要件になっていることについて問題提起してるだけなのでは。
そんなもん気にせずレジュメ送ったらいいじゃんか。としか言えない。
Re: (スコア:0)
×アメリカあたりではずーっと前から会社は教育なんかしなくて、能力にカネ払うだけだよ。
○アメリカあたりでは会社は教育なんかしなくて、能力にカネ払うだけだよ。
教育なんかしてた時期あんのか?
確かにトレーニングとか称して教えてくれることはあるけど、それとて業務の一環だしね。出来ない奴を出来るようにするなんてことはないもんね。
Re: (スコア:0)
業務であっても教育ですよ。そして、アメリカの会社は従業員を普通に教育してます。
あと、出来ない奴を出来るようにする努力もしてましてます。
州や会社によるのかもしれませんが、解雇するには要件を満たす必要があって、
そこには会社側が教育の機会を与えて、本人の成長を促すことが求められています。
それをやった上で能力不足を解消できなければ解雇が認められます。
# リストラの場合は別です。部門毎、人の区別を一切することなく解雇。
オープンソースのコードを教材にして学習 (スコア:0)
プログラミングを商売にするつもりの人の学習の教材としては、オープンソースのコードは最悪の教材ですね。もちろん私見ですけれど。
内部品質やテスト性とかを完璧無視している/その重要性を理解出来ない人を育ててしまう結果に終わる事が多かったり。
# 日本の業界だとそれが普通だから、問題ではないのかな?
Re:オープンソースのコードを教材にして学習 (スコア:1)
学習用の「お手本」としてはたしかにそうかも。
良いコードも悪いコードも玉石混交なので、初心者が
マネすべき良い部分だけをより分けるのは至難の業。
Re: (スコア:0)
あなたのオープンソースは世界が狭すぎでは?私の知ってるところだと、パッチを書くときは必ずユニットテストとセットですし、さらには実際に採用されたらドキュメントの更新もやらされますよ。
Re: (スコア:0)
まさに学習中なので、よろしければそのプロジェクトを紹介してください。
Re:オープンソースのコードを教材にして学習 (スコア:2, 興味深い)
メジャーどころはたいていそうですよ。そうしないと、製品の質を保てるはずがありません。
Android https://source.android.com/source/submit-patches.html [android.com]
Apache https://cwiki.apache.org/confluence/display/Hive/HowToContribute [apache.org]
Mozilla https://developer.mozilla.org/en-US/Add-ons/SDK/Tutorials/Unit_testing [mozilla.org]
逆に、メジャーどころでわかりづらいのはLinux Kernelくらいかな。
http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging [linuxjournal.com]
http://stackoverflow.com/questions/3177338/how-is-linux-kernel-tested [stackoverflow.com]
の記事を読んでも、パッチ書いてる奴がテストしている(レビューで求められる)とは読めませんでした。実際にやってる人に聞けば早いんでしょうけど。というか、カーネルくらい複雑になればテストは何重にもされているわけですが、カーネルにコードを出すことがシステマティックなテストを書く勉強になるか、というと疑問かもしれません。逆に言うと、他のメジャーどころにパッチを出すのは、確実にテストの勉強になると思いますよ。
今は、travis-ci.orgみたいにgithubと連動させるだけで、ビルドエラー(ビルドエラーを吐かせる単体テスト)の結果報告をしてくれるところがあるので、お一人様な小規模なオープンソースプロジェクトでもすぐに始められる土台は十分すぎるほど整っています。
http://docs.travis-ci.com/user/getting-started/ [travis-ci.com]
だから、勉強になるかどうかは規模ではなく、プロジェクト自体の質や、あるいは方向性が占める部分が大きいのではないかと思います。でもそこは、最初のコメが日本云々を言ってるようにオープンか否かは関係ないわけですから……
Re: (スコア:0)
Linux kernelへのパッチは形式的にテストやドキュメントが求められることはないです
メンテナーが入れるのが妥当かどうか判断してますね
基本はソースコードレビューで品質を担保しているということになるでしょうか
Re: (スコア:0)
それって、IISやIEの方がApacheやMoizllaよりまともなテストをやってるって意味ですよね。本気ですか?qmailはなんとも擁護のしようがないですけれど。
Re: (スコア:0)
> それって、IISやIEの方がApacheやMoizllaよりまともなテストをやってるって意味ですよね。本気ですか?
はて?
IISやIEがどんなテストをやっているか存知ないので、その様にと詰め寄られても困惑するだけですが。どっからそういう思考が出て来たんでしょう。なんかあぶないクスリとかやってませんよね?
それとも、外品と内品の違いを全く理解していないのが原因ですか?そうだとすれば、まずそいつを完全把握してから、何かを言う様にしましょうね。
> qmailはなんとも擁護のしようがないですけれど。
これも、はて?ですね。
どう擁護できないんでしょう?qmailの外品は立派なものだと思いますがね。no defectじゃなかったでしたっけ?
まあ、qmailのコードを触りたいとは思いませんけどね。単なる凡人がDJBみたいな天才のマネをしたって、高転びに転ぶだけです。その位の事はボクだって分かりますがね。(笑)
Re: (スコア:0)
単純な疑問なんですが、あなたの考える内品だけでシステム構築する事って現実的なんでしょうか?
Re: (スコア:0)
現実オープンソースの恩恵で成り立っているとおもうので、多分この人は「信用に値しない(気持ち悪い?品質に問題ある?)製品を使って仕事している」って事なんでしょうね・・・きっと。
外部的にはまあ使えるので、中身は空恐ろしくてみれたもんじゃないパンドラの箱なのかもしれませんね。
Unix系プロジェクトですら、最近はオープンですから、今時のサーバーなんて・・・きっと・・・僕がその立場なら毎日気が気で無くて発狂しそうですけどね。
Re: (スコア:0)
> 外品的はまあまあだけど、内品的にはボロボロですよ。先に出たqmailもね。
Apache のコードでお前が言う「ボロボロ」な部分を具体的に示してみな。さもなくば、プログラムも読むことも書くこともできない輩が適当なことを言っているだけということだ。
Re: (スコア:0)
> そういうヌルい世界の基準を持って来られても困ると言っているんです。オープンソース・マンセイは単純過ぎます。
オープンソースが歓迎されるのはそれが品質が高いからではありません。あなたが linux kernel に悪いところを見つけたのは、ソースコードが公開されているからなのです。それがオープンソースの良いところだということを理解していないのでは。
Internet Explorer はソースコードが公開されていなくても中がボロボロなんだろうなと推し量ることができます。でも部外者は手が出せない絶望感に襲われるわけです。
Re: (スコア:0)
DJBが主宰している/していたプロジェクトは如何っすか。qmailとか。(笑)
Re: (スコア:0)
狭すぎって言ってるんだから、狭い方を紹介してもらった方が早い
Re: (スコア:0)
rails
バグに気づいたのでプルリク。なぜか放置。アドバイスを求めたら、テストを書くといいよと言われる。テストを書いたら、コメントがいくつかついた
Re: (スコア:0)
Blenderとかはオプソになってからも大層なスパゲッティで解析が大変だったらしいが。
アクティブなオープンソースプロジェクトは殆どの場合、
大勢がコミットしうる形になってて読みやすく理解しやすいんじゃねーかな?
Re: (スコア:0)
オープンソースだからどうこうということはないと思うけどね。
しかし、ソフトハウス(!死語w)なんかに就職して、そこの社員としてどこかのプロジェクトに参画するとなると、
”このプロジェクトのコードはクソなのでプロジェクト抜けます”とはなかなか言えないわけで、(言ってもいいけど、たぶん社員の立場もなくなる)
何年もクソなコードに付き合わされることはあるよ。あるいは、クソコードが当たり前だと思ってしまったり。
それを考えれば最初はOSSのコード読む方がいいよ。
CS と分けて考えるべき (スコア:0)
プログラマになって分かったことは、プログラミングは上手な人と下手な人がいるということです。上手な人が書いたコードは読んでいて、ため息がでるような記述の美しさ、秩序の一貫性、処理の合理性があります。良い散文、詩を読んだ時のような感動を覚えます。これは、計算機科学の知見とは別に訓練が必要な要素です。
仕様通りに動作し、コード規約に反していなければ仕事として形になるわけですから、プログラムの記述に上手い下手があるということ、この世に美しいプログラムコードがあるということを知らずに一生を終える技術者は多いのではなかと推測します。
計算機科学を土台とするプログラミングに文学的な美意識を求める学際領域があっても良いと思うのですが、そういう研究はほとんど聞いたことがないです (Ref. "Literate programming", Donald Ervin Knuth) もししくは、美しいコードとは何なのかを、生産性の観点から追及することも研究として成立するのではないかと思います。
「実装は職業訓練としてやるべき」という決めつけは乱暴で、実際は良いプログラムを書く方法を教える術を誰も知らないのが実情なのではないでしょうか。
せっかく学位をとっても (スコア:0)
せっかく学位をとっても、プログラムが出来ないのでは、「目を使わず耳だけで自動車の運転をしよう」
とする様なもので、なかなかうまく行かないと思います。
プログラムはプログラム世界を認識する感覚器の一種で、それを断つのは単なる願掛けにしか
ならないでしょう。