  |
はてなキーワード: ソフトウェア工学とは
よく「プログラマは勉強し続けなければいけない」といいますが、嘘です。
それは、レベルの低いプログラマの話です。そういう人たちが想定しているのは、たとえば流行りのフレームワークが出てきたらそれを勉強するとか、仕事で特定のプラットフォームの知識が必要になったのでそれを勉強するとかです。
こういうことを一所懸命勉強している内は、プログラマとしての実質的な成長は見込めません。それらを勉強しても、特定のフレームワークなどの使い方が分かる人になるだけです。ほとんどの場合、5年も経てばその知識は役に立たなくなります。
実は、ソフトウェアの技術などは、コンピュータの黎明期から本質的な進歩はほとんどありません。だから、本質部分が分かっている人は、流行り廃りのある技術の習得に余計な労力を割く必要がありません。
プログラマが勉強すべきはこの本質部分、つまりコンピュータサイエンスの基礎です。フレームワークの使い方は知らなくてもリファレンスを見れば良いのに対し、コンピュータサイエンスの基礎はググっても決して身に付きません。
プログラマが身につけるべきコンピュータサイエンスの基礎は、多くの大学の計算機科学・情報工学の2〜3年生で学ぶような内容、
などです。逆に、こういう素養がないのにプログラミングスクールでRailsとかCakePHPみたいなのを触って、プログラミングできる気になっている人に5年後10年後の市場価値はありません。
会議名をちゃんと書けば良いと思うんだけど、やっぱりコミュニティが狭いから大変なんだろうな。
"ソフトウェア工学"は "工学"って名前に入ってるし、工学のフリをしているけど、成り立ちは社会学に近い。
その上で、議論しているので厳密な話なんて出来るはずもなく...
とりあえず適当に学問の特徴的な所を述べておく。社会学だなぁと思っていただければ。
他にもいろいろあるけど、長くなるのでいったんこれで留めとく。
昔のプロセス管理(図と人の管理)時代からの習慣として、再現性が無くても真実っぽい考察のある知見ならOKってのがある。
プロセス管理は方法論が社会学由来なので、ソフトウェア工学ではベースになっている。
プロセスを完全に再現なんて、どうやってもやりようがないのだから。
これは実践的ソフトウェア工学なんて名前を付けても変わってない。
汎用的な提案をして、評価対象だけに特殊化したりしても問題ない。
評価のための実装ですと書いていた場合、評価対象毎にチューニングしてても良いのだ。
コンピュータを使う研究者なのであって、プログラミングが出来る必要がない。
学問自体には、現代的なプログラムを書く/ソフトウェア開発をするモチベーションが無い。
某エントリのようなソフトウェア関連の研究してるのに oo が使えないなんて...ってはなしになる。
システマティックレビューやサーベイは検証ではなく現状追認にしかならない。検証しようがないのだから。
理工学の延長線上として見るからダメなのであって、社会学としてみれば問題はない。
実際とかけ離れてて、役に立たちにくいのは社会学だからでいい。
実際のソフトウェア開発と "ソフトウェア工学" を繋げたい(適用したい)と考えるのは時間の無駄なので
http://anond.hatelabo.jp/20161017031727
老婆心ながら，おそらくSIer関係を目指しているだろう情報系？学生へのアドバイス
どの大学でも学生課は糞対応なので，カウンセラー通して学生課に学費免除なり，奨学金なり，対応を仰げ．
このままいくと研究室・ゼミ配属で積みそうなにおいするから，中退・途中就職（大学頼らない就職）の選択肢も考えておけ．
- http://dotinstall.com/ title: dotinstall]
- http://gacco.org/ title: gacco]
- https://schoo.jp/ title: schoo]
SIerに関係ないと思われるが，Web系への選択肢も拡がるしな．騙されたとおもってやっておけ．
最近だと技術文書をMarkdown で書く場合も多いし知っておいて損ないで．
ドットインストールにも授業がある．
基本情報持ってるなら知ってると思うが，
慣れておくといいで．ついでに言語はC++でもいいが，SIerならJava8勉強しておけ．
多分授業だけだと，実際のコード使わないと思うので，自分でインストールして使ってみるとええで．
MySQLインストールして使えるようにしておけ．基本コマンドだけええで．
後々データベースの資格（シルバー，ゴールド）にもつながるしな．
基本情報持ってるならある程度知ってると思うが，低レイヤのIP/TCP, UDPのソケット通信をCでもJavaでも書けるようにしておくとええで．
開発の話あるしね
ドットインストールにもある．
今までやったこと忘れるのもったいないし，他人に見せる意味でも技術ブログやっておけ．毎日更新とかいらんで．
Linuxインストールしたレベルで，やったことならなんでもええで．
技術者の就職面接で，（関係ない）バイトしてました，サークルやってましたじゃあんま意味ないからな．
録画して好きな時間観て見ておけ．
情報系の授業もある．
コード書くようになったら騙されたと思って読んどけ．
自分の中の名著にしておけ．
スカウト来たら，入らないにしても会ってみるとええで．
バイト大事なのはわかるが，大学の目的は，知識で選択肢拡げるというのもあるので，頑張って生きるんやで．
じゃあの．
そろいもそろってクズ
能力が低いくせに自信だけは一人前で自分の言い分が通るまでは喧嘩腰。
たとえば「私はプログラムのソースコードは読まないよ！だから全行にコメントいれて！コメント入れるのは当たり前の事だよ。私はソースコードを読むときにコメントを英文よ読むように読んで理解から全行にコメントいれて！」
みたいなよくわからん要求を押し通してくる。(ソース読めない人がプログラマか？あほかと)
これやらないとそれを言い訳に文句をいってそもそも仕事してくれない。
SingletonもしらないMVCもしらないJenkinsもしらないコマンドラインもろくに使えない、そんな状態で私はソフトウェア工学を学んだプロみたいな言い方をしてくる。
その自信のせいか人の意見は聞かない。
仕事は終わらせないで帰る、昼飯は二時間戻ってこない、そもそも会社でYoutubeばっかり、ミーティングはずっとスマホいじってて話を聞けと言っても「きいてるよー。私はマルチタスクだから両方できる」などといってミーティングが終わったらさっきは何の話だったの？と聞いてくる始末。
そして浮気！仕事には関係ないからどうでもいいけど、結婚してるのに出会い系サイトで出会った女の子に片っ端からあって遊んでる。そして写真にとってそれをいつも自慢してくる
私はチームにいる誰よりも女の子を抱いた事あるよ！なんて自慢してくる
しるか、しね
二人目、
企画者がもってきた仕事にめっちゃ切れて文句いって仕事しない。
ミーティングしても「いつまでこんなミーティングつづけるんですか！！！！」みたいに
ソースコードの問題をみんなで指摘しても「これはこうじゃないとダメなんです！！！」みたいに
基本自分が正義で自分の意見に反論してくる奴はみとめないのがフランス人
しね
三人目、
四人目、
社員旅行にいったのに飽きたのか途中で誰も言わずに一人で帰ってくる
みんないなくなって大慌て
旅行が終わっていきなり新幹線の切符もってきて開口一番「先に帰ってきたからこれ清算して！」
しね
五人目、
昼頃会社に出社してくる、PCをたちあげるなりおもむろにゲームを開く
夕方までそのまま
そして帰る
あとのフランス人はしらない
ただでさえ働かないのに本当赤ちゃんをあやすかのごとく機嫌を取ってあげないとダメ
フランスはこんな奴らばかりでどうやって経済なりたたせてるんだ？
クズすぎだろ
まぁそんなやつらを見抜けず採用してるうちの会社がダメなだけか。フランス人以外は外れ少ないんだけどなー
言いたい事はやまほどあるが面倒になってきたのでこれくらいで
手持ちのプログラムをちょっと手を加えれば作れそうだったので作ってみた（総工数0.5MH)。最下位２つが404になってたおかげでちょっと変なことになってるけど、だいたいこんなもんかな。いわゆるホッテントリーに上がる記事を大雑把に分けると、
に分かれる（勿論ミックスもあるけど）。諸君が『くだらねー』と思っている、エクセルだの英語だの簿記だのは後者だな。ただ、はてブはSNSとして機能している側面もあるけど、SBMが本来の目的である以上、インフォメーション系の記事も当然上位に上がってくる。まあ、ブコメが盛り上がっている何か？を表示出来るようにしたいんだったら、日曜プログラミングでちょろっと書けば？と思う今日このごろ。
ブログに書くほどの話じゃないので、スペースお借りしますm(_ _)m
Web開発などをやっており，文系で修士を出てから就職，最近放送大学に在籍しています．
実際その状況で学位が役に立つのかはわからないので，実践面でコメントします．
基本的には，各技術を支えるメカニズムや，根本にある理論，数学などが大学で学べる特有の内容だと思います．
例えば，離散数学，計算論，アルゴリズムとデータ構造，プログラミング言語論，オペレーティング・システム，リレーショナル・データベースなど．
これらは，具体的に役に立つかというと，例えば深いレベルのチューニングなどでは必要になると思います．内部の構造が影響してくるので．
また，技術，特に新しく出てきたものを素早く理解するためには，体系的に例えば「データベース技術とはこういうものだ」という概念があると非常に役に立ちます．
なので
＞トレンド技術を習得しにくくなることは、デメリットが大きいのではと感じる。
また，ソフトウェア工学に関する科目は，意外に大学特有の知識が多いです．
具体的に何が学べるかは，カリキュラムやシラバスが参考になります．逆に見ないと何もわかりません．
基本的には通信制の大学では，時間割はありません．スクーリングは別ですが．
なので，「毎週時間を作って〜〜する」というのは，最終的にはかなりモチベーションを減らしてしまうと思います．
いわゆる一流大学を出た人でも，大学では試験前のみ勉強するなど，気を抜いています．
ちゃんと勉強したいものはいくら勉強しても足りませんが(だから研究というものがあります)，
下手に気負いしないで楽にやれば，そんなに大きな負担にはならないと思います．
例えば仕事で半年忙しいことが確定したなら，履修をしなければ良い話です．
基本的には「論理的にものを考えられる」ようにとられがちですが，
専門分野以外のことについては一気に瓦解する人も多いです．
敢えて言うなら，大学を出た後の環境の違いも大きいと思います．
大学を出てストレートに上場企業に入った方は，ずっと頭をつかう立場に配属される場合があります．
そのため，頭を使うこと自体に経験があり，慣れています．そうでない場合ももちろん多いのですが．
今の状況を活かして頭を使っていけば，大学を出なくても十分知性のある人間として尊敬されると思います．
恐らく，私の見立てでは大学を出てもあまり変わらないと思います．
しかし，今そういう思いがあるなら，やってみてはいかがでしょうか．
若く無いと大学に入れないということはないので．
http://d.hatena.ne.jp/nowokay/20130322
＞ ソフトウェア開発がある限り、ソフトウェア工学は必要なので、
＞ XP・アジャイルを織り込んで再構築して、認知度を高めていってほしいなーと思います。
XP、アジャイル、スクラム、IBM Rationalなどの開発手法はソフトウェア工学にすでに
織り込まれていて、主流ではないですが一部のソフトウェア工学の授業では教えられていますよ。
http://www.eecs.berkeley.edu/Courses/Data/209.html
http://mse.isri.cmu.edu/software-engineering/Courses/17-626%20agile-methods1.html
http://classes.engr.oregonstate.edu/eecs/summer2011/cs361/
http://www.cs.iit.edu/~virgil/cs487/mail.fall2012/syllabus.html
http://www.bu.edu/csmet/cs893/
上の授業で使われてるシラバス・教科書の目次をなぞると、@nowokayさんの理想とするソフトウェア工学の再構築に役立つのでは。
http://d.hatena.ne.jp/nowokay/20130322#1363969460
以下の記述のまとめ：
お前の言っているソフトウェア工学は今のソフトウェア工学じゃねえよ．
端的に言うとそんだけ．
で，本題．
まず，書いてる内容が古すぎて救いがたい．iPS細胞の研究がノーベル賞取った現状で，「実験材料に受精卵を使う万能細胞の研究なんて許されませんよ！」と主張されても，その何だ，困る，とかそういうの．
1999年、なにがあったかというと、XPエクストリーム・プログラミング入門という本が発行されたのです。リンク先は2版ですが、日本語版でも初版は2000年12月になっています。
で，何？2000年以降ソフトウェア工学が何も進んでないと主張したいの？
って最初に書いてあんのに，そこから崩れて何も出てきてないって主張はどっから出てきたの？自分が知らないことが分かってるのにドヤ顔で提言とか大丈夫か？
しかし、結局統一設計手法は完成せず、UMLだけが残りました。実際に使われているのはその一部です。CORBAも普及せず、WebプロトコルにあわせてSOAPが出てきたものの、結局単純なRESTが定着しました。XMLはいまは毛嫌いされています。大成功したはずのオブジェクト指向も、Webアプリではうまく適用できませんでした。
だから何だ．提案されても使いにくかったり，状況自体が変化したら無用になるに決まってる．まさか「ソフトウェア工学分野で提案された手法はどれだけ開発環境が変わっても生き延びていなければならない」とかいう寝言じみた主張でもしたいのか？言語に流行廃りがあるように，手法にも流行廃りはあるに決まってるだろ．
あとSOAPとXMLに関しては，その衰退過程自体がよくある話すぎて話にならん．一番最初に厳格な重量級の様式が定められて，それをベースに運用レベルを考慮した軽量級の様式が定義されて駆動するってのはよくある話．言い換えると，学術から出てきた理論的に正しい手法が，産業界で必要なところだけつまみ食いされる形で運用されるとか，サンプルは死ぬほどそこらじゅうに転がってねえか？
ああ，CORBAはまあ，うん，そのなんだ．アレはフォローできない．
実際のところ，UMLが残っただけで十分じゃねえの？最初に提案された時の理念さえブレてなければ，つまみ食いしたモノがはやってても提案者的には本望だろ．
今はCMMIだ．CMMは2000年にCMMIに統合されてる．今更XPの本出してくるところといい，真面目に2000年より前で知識止まってんだな．
はぁ？動的型付言語が普及したらなんでソフトウェア工学と離れんのよ？静的型付言語で使えて，動的型付で使えなくなる研究分野なんぞ，完全にソースコードに寄り添った研究だけじゃねえか．
「この手法はC言語を対象としている」って書いてある研究は他の全ての言語には一切適用できないと主張してんのと一緒だ．はじめてのCあたりからやり直せ．
ここで、やはりCMMの失敗がソフトウェア工学にとっての痛手だったように見えます。
もちろん、プロセスを規定することが難しいということは当時からも言われていました。それであるから、CMMはプロセスそのものを規定するのではなく、プロセスの規定方法を規定するというメタプロセスになっていたのです。
そして、すべての組織で同じプロセスを採用することはできないということから、５段階のレベルを設けました。また、プロセスは変化し続けなければいけないということから、CMM成熟度レベル５では「最適化している」という成熟度になっていました。
これはなかなかいいかもしれないということで、期待は大きかったと思います。
でも、とにかく運用が大変だとか、CMM成熟度レベル5でも品質がいいわけじゃないとか、そういう話がきこえてくるようになりました。
まず失敗を定義しろ．で，失敗したってんなら，CMMIで未だに新たな認定がなされてる（http://cmmiinstitute.com/assets/presentations/2012SepCMMI.pdf）理由を説明しろ．
で，運用が大変？当たり前だ．品質確保すんのに運用が楽とかあり得んだろ．従業員に好きにやらせてもアウトプットが高品質ならそもそもCMMIなんぞ必要無い．順序が逆だ．「CMM成熟度レベル5でも品質がいいわけじゃない」ってのも当然だ．アレは組織の成熟度を評価する指標であって，中で働く人間の能力を評価してるわけじゃない．というか流動すんのに評価なんぞできねえけど．
そもそも，CMMIレベル5ってのはおおむね高品質なものが出てくるだけで，人間が関わっている以上ある程度のばらつきは存在する．つーかさー，CMMIレベル5なら必ず高品質のモノが出てくるとか思ってんの？まさかまだ銀の弾丸の存在を信じてんの？「ISO9001に準拠してればリコールなんて発生しない！」と思い込むくらい残念すぎねえか，その思考回路．
ああ，「CMMI」じゃなくて本気で「CMM」の話をしてるんなら申し訳ない．もう無いんだから，CMMの話を最近全く聞かないのは当然で，勘違いしても仕方ない．悪いもしくは古いのはアンタの頭だ．
もともとソフトウェア工学に対しては「がっこーで現場しらない人が研究してる手法なんて使えない」のような声があったのですが、XPやアジャイルによって「現場から生まれた手法のほうが使えるよねー」というのが決定的になりました。
前半は正しい．ソフトウェア工学の最初期からずっとその手の意見はあって，未だに言われてる．が，後半は話にならん．
真面目に聞くんだけど，アジャイルソフトウェア開発宣言に名前が入ってる17人のうち，何人知ってる？何人が開発寄りで，何人が研究寄りか分かる？まさかKent Beck1人を見て「アジャイルは現場から！」とか寝言垂れて無いよな？そもそもKent Beckはコンピュータサイエンスで博士号持ってるし，開発寄りと主張していいのかどうかすら微妙なんだけど．
あとアジャイルも突発的に出てきたわけじゃなくて，プロトタイピングとかあの辺（とそれ以前）からの流れがあると思うんだけどなあ．
ソフトウェア工学が何を失敗しているかというと、その学問自体の認知度が低すぎることです。
ソフトウェア工学がどのような問題を扱う学問かが知られていない。どのような問題を扱う学問か知られていないので、その問題に直面している人がソフトウェア工学の成果を積極的には利用できない。
問題に直面してる人がソフトウェア工学の成果を積極的に利用できないうんぬんについては，最近の国際会議でもその辺を扱った研究が出てきてたりする．ICSE2012のDistingished paperのうちの1本がそんなん．Eclipseの検索ツール使わずに，テキストエディタにコピペしてCtrl+F使ってる人の話とか出てきてた覚えが．
ただ，ソフトウェア工学の認知度なんぞどうでもいいと思うんだけどなあ，別に．そっから出てきたモノが使われさえしてりゃあ．ソフトウェア工学研究の成果が，それと分からずに使われてるんならそれ以上に望むべきモノは無いだろうに．「これがソフトウェア工学様の研究成果でござーい」と大上段に振りかぶって，「ありがたや」の言葉と共に使われることを望んでる研究者なんぞいねえだろ．
就職活動で「半年でプログラムは覚えれるし専門は必要ない」のようなことを言われるという話があります。たしかにアルゴリズムなど実装技術の研究をしていた人をSIの開発現場で生かすのは難しいと思います。でも、ソフトウェア工学の専門知識は、半年で覚えれるものではないし、SIでの開発現場に必要になるはずです。
うん，そうですね．だがそれを学術側を知ろうともしてない人間が言うな．
ソフトウェア開発がある限り、ソフトウェア工学は必要なので、XP・アジャイルを織り込んで再構築して、認知度を高めていってほしいなーと思います。再構築とかは他力本願になってしまうけど。
ソフトウェア工学を再構築しよう，という動きとしては http://semat.org/ あたりがあるのでそっち参照．
あとさー，そもそも論として，ソフトウェア工学の研究内容を「現場」と「学術」に2分することが不可能だって分かってる？工学ってそういうもんだろ？その2分は「工学」と「理学」というレベルでは可能なのであって，既に工学にカテゴライズされてるソフトウェア工学を分けるのは不可能だ．それくらいは語の定義レベルの話なんで，分かっててくれ，頼む．
まあ暇ならトップ会議であるところのICSEのプログラム（https://files.ifi.uzh.ch/icseweb/fileadmin/downloads/ICSE2012_conference_program.pdf）でも眺めてみて，ソフトウェア工学の定義について悩んでみるのもいいかと思います．
実際のところトピックは割と流動的．最近はOSS周りが流行．gitのおかげで開発者の行動とか取りやすくなってる関係もあって．
つまりさー，なんでか知らんけど，この人の頭ん中では「ソフトウェア工学は静的型付言語を利用したウォーターフォール型開発でしか使えない」てことになってんだよな．
あと，なんか無理矢理にでもソフトウェア工学をdisりたくてしょうがないってことは分かった．
今のシステムエンジニアの仕事に求められている水準というのは、人間に達成できる内容なのだろうか？
それも専門的教育を受けていない、働き出してから怪我をしながら学んだ人に達成できる水準なのだろうか。
とはいえソフトウェア工学やらプロジェクト管理工学やらを持ち出すと「机上の空論」「現場は違う」とか言い出すのだろう。そりゃそうだ。自分が現場育ちなのだから、そこを尊重したい気持ちが何より先立つ。理論を持ちだされても素直になれない。今現場でSEをしている自分に理解できないことをもってこられても恥ずかしい。
ソフトウェアやら構築やらSIやらには免許が要らない。そのための国家試験もない。認定の国家試験はあるけど、前述の理由で価値が認められていない。現場優先とは聞こえがいいけど、それは単に自分の価値を最大限にしたいだけだ。
もう無理なんだよ、知識のない人間には。現場の人間は手足であって、頭になれない。ちゃんとした頭が必要で、無理なことを解決するのに無茶を投入する知恵のない人は要らないんだよ。下請けが給料が安いのは当たり前なんだよ。交換が効く手足なんだから。頭のほうが価値があるに決まってるだろ。頭の足りない元請けがいる、なんていうなよ？ 元請けの時点で覚悟しろって意味なんだから。
製造工程で、ソフトウェア工学に明るい優秀なプログラマからのフィードバックで、
今のまずい設計のまま製造を進めればカットオーヴァーまでの工数は100人月＋保守費用10人月/年、
前工程に戻って良い設計で作り直せば50人月＋保守費用5人月/年になるので設計からやり直しません？
って提案があっても絶対に後者が選択されることは無い。
例えそれがROIやTCOの数値で合理的な選択であることが明白な場合であってもね。
前工程の失敗がきっかけとなり、今の良い設計を発見することが出来たって発想にはならず、
最初からその良い設計で作ればもっと工数削減出来たじゃないかっていう後出しじゃんけん的な文句だったり、
前工程に関わった人間の責任問題、顧客への説明…etc、そういう各人の思惑やしがらみが絡んで後戻りは出来ない状態になり、
「デスマーチ→破綻→仕切り直し」というサイクルになって、妥協の産物みたいなクソシステムが出来るんだよな。
顧客は低品質の金食い虫を使う羽目になり、元請SIerは赤字になり、現場の技術者は心身を病む、
不可逆なプロジェクトの進め方に何も良いことなんてないんだから、最良の結果を出すためには
出戻りが発生する事も大いに有り得るって認識を上流工程の人間で共有すべきだと思うんだ。
あと、早期発見早期治療のために、技術的に優れた人間をもっと上流工程に絡ませるべき。
元請SIerは業務知識や折衝能力が重要って馬鹿の一つ覚えみたいに言ってるけど、
そこばっか重要視して技術を軽んじてきた結果、今の体たらくなんじゃねーの？
確かに業務システムなら個々のプログラム作るのに大した技術はいらんかもしれんが、
プログラムの集合体としてのシステムを作るのには技術力は必要だろ。
ま、こんな所で吠えても何も変わらないし、10年後20年後も変わらないだろうね。
だから俺は辞める。みんなも辞めようぜ。
中に残り続ける人は死なない程度にせいぜい頑張って下さい。
[居酒屋。サラリーマン風の男がグラスを片手にくだを巻いている。]
こんな複雑で難しい仕事、ロクにソフトウェア工学も修めてないトーシロがやろうってのが間違いなのよ。いやおれも含めての話よ？
何か開発でポカやるじゃん。
ポカやったら、レビューが足りなかったとかさ、チェックが甘いとかさ、なるじゃん。
でもって、誰でもできるようにチェックリスト作ろうとか、手順書作ろうとかって話になるじゃんね。
違うんだよ。
例えばさ、医者の診察考えてみ？あれってチェックリストがあれば誰でもできるの？違うでしょ？
6年間も大学通ってさ、人のからだの仕組みを隅から隅まで全部勉強して、国家試験パスして、研修医として経験積んで、それでようやく診察できるようになるわけでしょ。
今のIT業界、それもほんとに能力ある人が集まらない、底辺のIT業界って、
「未経験でも医者になれる！」とかわけわっかんない宣伝打って、
「まじでー医者とかカッケー憧れるしなんかおもしろそうだし」ってホイホイ集まってきた若者使ってさ、
3ヶ月くらい『家庭の医学』でも読ませただけで現場放り込んで、
完全に推測でしゃべってるから間違ってたらごめんよ。
でもうちはそんな感じだわ。まじでね。
せっかく優秀なプログラマがいるのに、クソみたいな上流設計のせいでパフォーマンスの半分も引き出せてないわけよ。悲しくなってくるよ。
給料だって元請けの方が断然いいし。元請けってだけでだよ。わけわかんねぇよ。
自分たちだけで開発もできない、まして設計もろくにできない上流エンジニアなんてお笑いだよ。
なにが上流だよ偉そうにしやがって。死ねって思うね。今すぐ死ね。
え、おれ？そうだよ。えぇその通りですとも。死にましょうか今ここで。わはは。死んじまえ。みんなみんな、死んじまえ。
[男、グラスを机に叩きつけて割り、破片で喉をずばと掻き切る。ぴーっと音がして飛び散る血しぶき。]
いや、まぁ、仕事の仕方とかは、普通に大学で習うぞ。もちろん 名刺交換とかそういう事ではなく。
俺の場合はソフトウェア工学だったが、業界的には こういう傾向があるから 工学的には対処するシステムを作る。
みたいなことで 人災はかならずある から 人災は起きるものと思って システムを作れ。ってのは 習ったよ。
まぁ、理学と工学の差であるかもしれないけど 工学は ヒューマンエラーは立派な学問だしなぁ、どうだろう。
究極的には 下請け会社との付き合いは、ヒューマニックなものだから、１００件中９９件は受け入れて恩を売って、どうしても許容できない１件だけは絶対に押し通せみたいな、業界通年みたいなものも習ったぞ。
というわけで、人災に関することは少なくとも大学で教えるべきことではあると思うよ。
まぁ、教育論をしているときに そもそも学問だけ教えればいい というのは一意見だけど。実際 MBAなんかがそうだけど
学問以外の人的交流も教えるし。 大学教育は 必ずしも工卒が受けるものではなく 海外のMBAみたいに
起業後に受けるものだったりもするし その辺も含めて 見直しだし、再生なんじゃないのか？というのは
あくまでも一意見として あると思うよ。
何が不満なのか、ちょっと良く分からなかった。仕事なら期待されるラインまではきっちり仕上げるってのは、学歴に関わらず当然のことだよね。もちろん、それが出来る人間をそういう職責のあるポジションに置いておく、ということは組織作りをする人の責任だけど。
想像するに、自分のスキルと、配置されたポジションの職責が合ってない、そのことを理解してもらえない、って不満が大きそうだと感じたんだけど。上司が何やってるかわからないとか、大卒は固くないのがいいとか、それは二次的なことなんじゃない? 派生した問題の方に気を取られてぐるぐるしてるような印象を受けた。
もうひとつ気になったのはここ。単に言葉が足らないだけかもしれないけど。
その知識で周りがもっとうまく回るようになれば・・・って感じ。
これは逆立ちしてるんじゃないかな。現場にいるなら、知識は道具だろ。まず現場をうまく回すのに何が必要なのかを見極めて、もし必要なものがソフトウェア工学の最新の知見なら、それを使えばいい。そうでない可能性も、たくさんある。
ソフトウェア工学の知見の応用が足りてないんだ、使えばもっとうまく回るはずだ、とあなたは思っているかもしれないが、そう言えるのはあなたが既にソフトウェア工学の知見を使ってきちんとした成果を出した経験がある場合だけだ。実績が無いのなら、残念ながら、具体的な成果をまず積み上げて、「こいつが言うなら良いものなんだろう」という信頼を得てゆくしかない。もしかすると前職でそういう経験があるのかもしれないけど、技術ってのは誰が何のために使うかも重要だから。チームが違えば最適な工学的手法も違ってくるんで、「今のチームに、これが必要」と説得出来なりゃ意味がない。
これが意味を持つかどうかわからんけど、自分は博士卒で、開発系の会社やってる。部下がこういうことを言ってきたら、とりあえず問題を切り分けるようにアドバイスするかな、と思ったんで書いてみた。
あー、あと、会社を回すには実にいろいろと面倒でどうでもいいような雑事があって、でもそれを誰かがやらないと回らなくなるんだな。あなたから見てどうでもいいような仕事をしている人がいるかもしれないけれど、その人がいなかったら、あなたがどうでもいい面倒な雑事をしなくちゃならなくなる。まあわかってるかもしれないけど、一応頭に置いといて。
周りは9割方専門学校卒で、残りは大卒と高卒という会社に勤めて10年になる。
資格は大昔に取ったソフトウェア開発技術者だけ。
しかしその頃の俺は今以上に世間知らずだったので、学歴なんて関係なくね？と素朴にというか迂闊に考えていた。
結局仕事というのは何をやるか以上に誰とやるかが大事だということを痛感させられている。
そしてこの「誰とやるか」を考えたとき、学歴の違いというのは全く以て抜きに出来ないと思うことしきりだ。
ぶっちゃけ専門卒とはどこまで合っても噛み合わない。上司や先輩だったら最悪だ。
実際、過去に当たった専門卒の上司とはうまく行ったためしがない。
そんな専門卒の上司の一番の特徴、それは「プロの仕事というのはまず非の打ち所があってはならない」と本気で考えていること。
つまり通信簿に例えたらオール3以上取れて初めて一人前であって、そうじゃない奴はどこまで行っても半人前の半端者なのだ。
個々人の強みを伸ばすなんてのはその先の話で、全てが平均水準をクリアしていない状態では、順番が違うのだ。
そしてプロである以上、一度任せたら上司は最初と最後に関わるだけでOKというのが理想であり、「デキる」部下ということらしい。
間違っても「部下の良いところを使って立派な仕事をしてもらうために、悪いところを補う仕組みが作れないか」なんてことは絶対に考えない。
そんなんで今もこれからも業務が回るほど簡単な仕事じゃねーだろと思うし、そもそも一体この人らは何の仕事をして給料もらっているのか不思議で仕方ないのだが。
何よりこの人ら、いざというときに部下のヘマのために頭を下げてくれるのだろうか。それすら怪しい。
ちなみに俺は能力にとんでもなくバラつきのある人間なので、当然ながらこういう上司の前では今でも半人前扱いだ。
そんな人たちが会社の中枢にいる限り、俺の昇進昇級なんて永遠にないだろう。
まあこんな所でリーダーとして仕事したってストレスが増えるだけだろうから、ヒラで気楽にやってるのが一番な気もするけど。
そういえば昔、人事考課で「今の上手くやれている能力を伸ばして会社に貢献したい、可能性に賭けたい」みたいなことを訴えたこともあったっけ。
もちろん無視され、ダメなところに対する説教タイムとなったが。
挙句、目標による管理という仕組みそのものがなくなり、管理職の密室会議で評価が決まる仕組みに逆戻りした。
大卒クラスの人は「これくらいの規模の会社で人事評価の仕組みが確立していないのはおかしい」と今頃言っているけど、
あの説教タイムが復活するだけだったらいらねーよと思う。制度だけ作ったってまともに使いこなせないわけだし。
一応、今は大卒の上司や営業と働けているので何とかなっているが、それが永遠に続くわけがない。
もし今の体制が今以上に悪くなるのなら、それがもう潮時だと思っている。
一つ反省があるとすれば、もし俺がもっと評価されるよう立ち回れていれば、俺に続いて修士の人が入ってくる可能性もあったのだろうから、その流れを俺の仕事ぶりで潰したのだとすれば、それは修士に対する偏見を増やしたことに他ならないので、世の修士の皆さんにとても申し訳ないと思う。
ちなみに協力会社の人への指導も含めて考えると、専門卒の良いところとして挙げられるのは「やれ」と言ったことは完璧にこなしてくることだろうか。
大卒や修士はこの辺ちょっと詰めが甘い。でもそれ以上に、こちらが良い意味で驚くアウトプットを出してくるので、俺としてはそこが楽しい。
固くないところがいいのだ。
高卒になると、今の事業部長がそうなのだが、他の学歴の人間から「頼りない」「暴投ばかり」と完全にバカにされている。
実際いつも社長のところに話に行くばかりで、過去の直属の上司以上に何をやっているのか見えないし。
あと中卒の元カノは最悪だったけど、短大卒の今カノとは結婚を考えるくらいに相性はいい。
それから博士の人の下で動いた経験もあるが、その人は盆暮れ正月関係なく会社にいて、こちらが夜中の1:00にメールしたら1:30に「夜遅くまでご苦労様です」と平然と返信してきたし、でも全く憔悴したそぶりなく、いつもにこやかな人だった。ついていくの大変だったけど。
まあそれくらいじゃないと、3年も4年もかけて学術誌に載るレベルの論文書くなんて無理なのだろう。
この人に肩を並べるには自分も博士になるしかないんだろうけど、そんな対抗意識(?)だけで博士を目指すのもどうかと思う。
でも昔は開発の仕事をやっていて、今でも人生の半分くらいコードの読み書きでも構わない程度にプログラミングが好きな関係上、ソフトウェア工学の最新の知見に精通したいという思いはある。
その知識で周りがもっとうまく回るようになれば・・・って感じ。
それは幻想かも知れないし、今の会社にいる限り無理だろうけど。
以上、住む世界の違いについてダラダラ書いてみたけど、実にくだらない。
こんな些細なことに気を揉まず、もっと気持ちよく生きたいとつくづく思う。
そんなことないだろ。教育現場で人気があるのってまさに「上位レイヤで数学っぽい分野」じゃね？
私はプログラマーだ。プログラマーにもプログラムをプロデュースする能力というものが必要である。ここで味わう事と絵や漫画や小説をプロデュースするのは実は全く同じ事である。
「美しいプログラム」「面白いプログラム」皆さん想像出来ますか？
ITで食ってる奴等の中でもこれを理解出来るのはそんなにいない。一般人なら「プログラムが美しいだの汚いだの、気が狂ってるとしか思えない」と言う事だろう。
「美しいプログラム」「面白いプログラム」ってのは変更にも強く、バグも少なく、スピードも速い。
しかし、周りの人からみればそんな事はどうでもいい事だったりするわけだ。美しかろうが汚かろうが【結果が同じ】だからだ。何が違うのかというと、アニメーターとか漫画家だったら分かるかも知れない。
「完全にフレーム外の作画」と言えばアニメーターや漫画家にも分かってくれるはずだ。【PANしない限り】フレーム外に時間と技術と手間を割いても結果が変わらない。しかしフレーム外を描く事によってその先の作業が効率よく出来るかも知れないし、奥行きも出るかも知れない。
実は「美しいプログラム」や「面白いプログラム」をプロデュース出来る人ってのは、とんでもない量のInputを持っている。そしてそのほとんどが「完全にフレーム外」だったりする。
それに関しては、プログラマーの養成に気に食わない点がある。情報系の専門学校で講師をした経験から言うのだけれど。学校はプログラムが動く事を教えてはくれるが、「プログラムが動かない理由を教えてくれない」点だ。プログラムが動かない理由を知らないままプログラマーとして働くと、一人前の【糞】プログラマーが出来上がる。
その辺はともかく、プログラムのプロデュースと、小説・漫画のプロデュースが同じと書いた理由は、とんでもない量のInputが必要である、という事。しかもそのほとんどが完成作品を読んだだけでは「完全にフレーム外」である事。
あ、誤解無きようお願いしますが、私の専門はX線物理学であって、プログラムは専門外ですんで。前述の事はソフトウェア工学的には間違ってるかも知れません。情報系のエライ人にでも「美しいプログラム」と「汚いプログラム」を見せてもらうといいと思います。見たほとんどの人が「分からない」と答えると思うよ。
基礎体力を養う意味ではここら辺がいいと思うんですがどうでしょう。
これがわかるとCLRやJVMのインフラ部分もわかりますし、組み込み方面にも強くなります。
C++はマルチパラダイム言語であり、これをひとつやれば構造化プログラミングとオブジェクト指向プログラミングの両方がわかります。
C++はCのほぼ上位互換言語ですので（正しくはC99が制定されるまでは）、プレーンなCしかやらない理由はありません。
嫌なとこも多くある言語で（どうしてEffective C++シリーズやExceptional C++シリーズみたいな書籍が多くでてるか考えるといいよ）、メモリ管理も手動ですが（これは半分嘘。RAIIがあるから半分自動。GCがないから半分手動）、逆に細かいとこに気を配る態度を養うには最適です。
Erlangで並列プログラミングをやるのもいいかもしれません。
Common LispかSchemeで怪しい（でも美しい）世界を爆走するのもいいかもしれません。
これだけやっとけばC#やJava、軽量言語の類はあっさりと料理できるでしょう。
あくまでもプログラミング言語についてはですからね。
そんな事言ったら、ソフトウェア工学は、作業員への効率的指示の所に心理学を含んでるし、アルゴリズムは理学だし。
だけど、基本的に、ソフトウェア工学だよ。
スピーカーを設計するのは理学だが、製造するのは工学。そういう話。だが、製造するのに理学が不要かといえば、そらいるだろ。
学問を学問として発展させるのが基本的な理学のスタンスで ＝ 研究
学問を使って工業製品を作る（ための技術の学問）が基本的な工学のスタンス。 ＝ 製造
ただ、あくまでも、工学というからには、物づくりであって、自分の手を汚せない、学問だけの工学を工学と呼ぶのか？というは、微妙だと言いたい。官僚的すぎる。
http://anond.hatelabo.jp/20071105113746
けど、最近は匿名の意味が違う気がする。そもそもブログのユーザID、mixiのID、2chのID、ハンドルネーム等々。
結局個人を識別する「名前」が存在するなら匿名ではないきがする。Webの自分と現実の自分を区別してるだけじゃん。
なんでWebと現実で自分を区別するのかよくわからない。mixiまでいけば何となく理解できる。mixiはもうメールとおんなじレベルのツールだ。
でもブログは違うよなー。ソフトウェア工学的にいうとアスペクトってところか。
ブログは結局現実の友達に存在を知られてるから、現実の名前とブログのIDってのはゆるーくつながってる。
完全に切る事もできるけど、どこか繋がっていたくなる。
増田の中での個人はそのエントリ１つでしかない。ソフトウェア工学的に言うと、副作用がない関数型言語みたなかんじ。
みんな「名無し」ってのがいい。
なんで「名無し」のコミュイティの居心地がいいんだろう。ちょっと考えてみよ。
I Love Lambda.
