スレッドを立てるまでもない質問雑談スレ14

>>950 gcc

>>948-949
ＣＯＢＯＬの位置付けが微妙ながら体感できました。
少し凹んでます。Ｃは来年にならないとカリキュラムに出てきません…。
とりあえず、独学でもします。レスどうもありがとう。

>947

どういった経路に進みたいかによると思うよ。

金融機関等であれば、ＣＯＢＯＬは現役で生きているし、
これからも生き残るんじゃないかな。
ＣＯＢＯＬもＷＥＢ化して生き残る術を模索してるし、
実際、それに成功して、今までのＣＯＢＯＬ資産を
そのまま運用できている会社もあるよ。
処理という点に関しては文句なくＣＯＢＯＬは強いよ。

ただ、あなたが進みたいプログラマとしてのジャンルが、
最初からＷＥＢ関連であれば、まったく必要ないでしょう。
（まぁ、知識として勉強しておいても損はないが。）

こういった業界の情勢は、日進月歩で変わっていくから、
人から話を聞くばかりではなく、ＣＮＥＴ、＠ＩＴといった
ＩＴニュースのページから常に情報を搾取するといいと思うよ。
（上記ページは、検索かければ必ず引っかかる。）

ちなみにこの板（2ch）はあくまで予備情報として活用するべき。
知識を蓄えてから読まないと、混乱するだけだから(^^;
(意地の悪いおにーさんとかも多いしね）

まずは情報を仕入れて、調べてもわからないようなことであれば
ここで聞くって使い方のほうがいいのでは？

>>951
よく見かけるのはＣとかjavaですよね。
もしかしたらＣＯＢＯＬはとっても基本的で当たり前に習得すべき
言語だから求人情報には載らないって可能性もあるかなーと思ったので
質問したのです。

>>954
なるほど。すごく判りやすくてどうもありがとう！
さっそく検索してみるっス！

笑いが止まらない仕事に転職したいのですが
例えばどんな職種がオススメでしょうか？

>957
マ

精神が狂って笑いが止まらなくなるって意味だけどな。

>>957
日本笑い学会
http://www.age.ne.jp/x/warai/

>955
ちょっとまて。一回でいいから、ローカルの求人情報誌眺めてみな。
君の住んでる地方にも、\0の求人情報誌があるだろ？
一回ぼーっと技術職系のところ眺めてみてみな。
そーゆーのも見て、これからどうゆう進路を進みたいのか具体的なビジョンを作ってみ？
そしてそのためには、どんな情報を、どんな言語を学べばいいか、決めていったほうがイイと思うよ。
それが少々間違っていたとしても、ある程度の目標みたいのを作っておかないと絶対後悔するよ。
なんで、プログラマになんてなったんだろう・・って。

＃COBOL が別に就職先がないわけではないよ。
＃実際うちのローカルの求人情報誌にはそこそこオイシイ条件でCOBOLer求むってのがあるよ
＃COBOLer居ないのかしらんけど、ずっと載ってるみたい（ｗ

あと、言語はコレ、と決めつけてひとつに絞るのはやめたほうがよろし。
もちろん、最初はひとつどれかをある程度使えるようになるのが目標だが、
複数扱えた方がメリットが多い。もちろん就職対策として幅を持たせるというのもあるけど、
TPOで言語を使い分けるタイプの案件もあったりするし、
別の言語での思考が参考になってバグが解けることだってあるし。

＃あの言語ならこんなのもっと行数少なくなるのに・・とか、ストレスが溜まることもあるけど（ｗ

まぁ、あれだ。ｶﾞﾝｶﾞﾚ。

>>960
うちは田舎だからかどうか、職安の求人では上記の２言語以外は
見かけなかったような…？ＶＢとかあったかも？

やっぱ、ビジョンを描いておくのって大切ですかね？
具体的に将来のこと考えようって思いつつも、なにぶんまだチンプンカンプンで…。
でもプログラムの分野って幅広くて、目的はっきりさせてないと
ホント、途中で迷子になっちゃいそう。
なるべくしっかりビジョン作るようにします。

アドバイス、ありがとう！

>>960
そうそう。言語は道具。
「金槌しか使えない大工」なんて、潰しも利かない。単価も安い。客も相談もできない。

「技術者」っていっても、所詮は平均的社会人ならできるプログラミングを
期待されてるだけだしね。

道具を使いながらも「こういう間取りの方が使いやすいよ」とか、
「ここは急ぎだから協力しよう」とか、業務や設計やチームワークの方が大事。

>>962
じゃあ、幅広くいろんな言語を知ってたほうがいいですか？
>>960さんのレスをみて、なるべく色々習得しようって考えてはいますが。
ところで言語は勉強すれば身につくだろうけど、「業務や設計やチームワーク」
ってのはどうやって身につければいいんかな…？
実を言うとチームワークとかぜんぜん自信なかったりします。
プログラマしてる人は普通にそういうの、身についてるものなんかな？
普段からチームワーク身につけるために気をつけてることか、
してること（ママさんバレーとか）ありますか？

…ママさん？？(@o@;;)

え？ママさんバレーはみんな普通にやってるでしょ？

>963
あまり深く考えなくてもイイと思うんだけどね。
基本的に相手のことも考えることが出来ればOK。超マイペースなのはダメ。
無理矢理自分の考えを押しつけたり、相手の意見に耳を貸さないなんてのは言語道断。
もちろん間違ってることを指摘するとか、出来ないことを拒否するとかは大切だけど、
子供の我が侭みたいなのは絶対にダメ。指定された環境に自分を適応させていきましょう。
あと、相手のペース、思考法もある程度配慮して、ウマく誘導(説得)出来るようになっておくと便利だよ。
流れ(雰囲気)を読むことも覚えた方がいいね。シリアスな場面で大ボケかますとかは、ちょっとね。
ま、社会に出れば自然に身に付くと思いますよ。
それと、設計については、ある程度処理内容の設計図みたいなのを思い浮かべて(なるべく実際に書き残す)から
コードを書き始めていくようにすればOK。設計法とかを専門にやり始めるとまた変わってくるんだけど。

＃もちろん自分のペースを守ることも大切。周囲に流されすぎて自分を見失ってしまうとかなりマズい。

＞普段からチームワーク身につけるために（ｒｙ
特にないね。
チャット(IRC)には参加してた(してる、か。)けど。そのchには友人も居たし、顔も知らない人も居た。
文字だけで流れ(その場の雰囲気)を読むにはよかったかも。技術情報の交換もしてたし。
球技は苦手です。見る方が好きです。
高校時は文化部在籍で、同人誌みたいの作ってました。
今思えば、締め切りに強引に間に合わすテクはあの頃に既に習得していたのかも(;´Д`)

>965
なんですとー！？

>963
(追記)
＞幅広くいろんな言語を知ってたほうがいいですか？
ぶっちゃけ、就職していざ仕事が来てみたら、
その案件は、自分が今まで専門にとしてやってきた言語ではなかった、なんてのは結構あるようで。
それなりにどんな言語も、書けないまでも読める(処理内容の概要がわかる)ぐらいの知識はあったほうがイイ。
もちろん、広く浅くだけでなく、どれかひとつの言語は、ある程度習得しておくべきだろうけどね。
ふたつめ以降の言語については、最初に習得した言語の知識が元になって習得が早いことも多々あるし。

＃あまり使わない言語で、特殊な関数なんかが良く出てくる場合は、リファレンスを片手にやることは結構あるような。

あと、一人でコード書いてると、ついコメントを付けるのがおろそかになりがちなんだが、これだけは避けるように。
後で誰か（その言語の記法や基本的な関数がわかっているひと)が見ても、
大体の処理内容は把握出来るのを目標に、最低限のコメントは付けるように。
もちろん、コメントの付け方なんてのは、案件ごとに変わったりもするので、流動的に処理できるようにしておこう。

＃最初は、あとで自分が読めばわかる程度に。多すぎるかな、ぐらいでイイと思う。自然と減っていくから。
＃最低限、自分で定義した関数の大まかな処理内容は、簡単に纏めてコメント化する練習をしておこう。
＃特殊な変数を設定した場合は、その変数がどう用いられるかとか、変数名の由来とか、
＃そのサイズで定義した理由なんかも付記しておくと、読みやすく＆バグを見つけやすくなる。

あと、自分で今「必要な知識を探すテク」だけは必須技能。必ず習得しておくこと。
長文ｺﾞﾒｿsage

>>966
基本的なコミュニケーションできれば大丈夫ですか？
相手がなにを要求してるのかを読み取る努力と、自分のやり方を
押しつけない、とりあえずそこら辺から気を付けよっかなって思ってます。

今、自分が所属してるコミュニティって、学校と２ちゃんくらいなんですよね…（汗
もっといろんなところへ出て視野を広げる努力とかしたほうがいいのかな〜、なんて。

>>964
アハ、みんな普通にやってるらしいすよｗ

>>967
エクセルのＶＢＡをしたことがあって、その時にコメントの大切さは実感しました。
自分の作ったプログラムでも時間が経つと何がなんだったのかわからなくなっちゃったりして…
独り善がりで特定の人にしか理解できないプログラムより
多くの人に使いやすくて判りやすいのが優秀なプログラムだと考えてます。
だからコメントも大切。。って間違ってないかな？

いろいろ丁寧にありがとう！
現場での経験が長い方なんですね。すごく勉強になります。
っていろいろ聞いておいて更にって感じなんですが
「必要な知識を探すテク」というと…？具体的なことが思いつかなくて…。
自分はまだ白紙にも近いくらい、何も知らないんで
このまえ>>954さん教えていただいたＣＮＥＴとかに目を通すことから始めようかなって
感じなんですよね。初心者以下の初心者って言えるかもｗ

>968
同じような目標や目的を持つ知り合いと、情報交換＆意見交換することは結構重要だよ。手段はなんでもイイけど。
ぶつかることもあるだろうけど、それからどのように和解(譲歩等)していくかとか、基本テク習得にオススメ。
知り合いとすら意志疎通出来ない人が、仕事場で初対面の人とまともな意志疎通が出来るわけないからね。

>969
＞コメント
間違ってないと思います。
同じ処理内容でも、コメントがあると無いとでは可読性が全然違う、そーゆーことです。

＞「必要な知識を探すテク」
簡単なことですよ。
わからないことがあれば、すぐになんでも人に聞くのはやめましょう(むしろ、やめてくれ)、ということです。
どうやったら、今わからないところの答えが見つけられるか、その方法を知っておけ、ということ。
例えば、わからない英単語があれば、あなたならまずどうしますか？
まず、教師に聞きに行きますか？　それとも、英和辞典で調べますか？
この場合、まず後者を選択してください、ということ。
それでもわからなければ、調べたらこうだったんですが違いますか？等を
付け加えた質問をしたほうが、教師も躓いているところがわかって教えやすいよね。
もし、それがあってればあっさり終わる話だし、それに辿り着く推論は無駄にならないはずだし。
これからすぐできることとしては、Web上でわかんない単語があれば、まずぐぐる(googleで検索)。
開発の際には、付属のヘルプや設計関連の文書を自分で読み直す。
（もちろん、必要な知識を見つけるための手段ってのは多いに越したことはない。上記以外にも無数にある。）
たったこれだけのことです。すぐに人に頼らず、まず自分で解決する努力をしましょー、ってことね。
例えば・・・、あなたがこれから何をすべきかは、自分で調べて考えて決める、とか、ね？

＃これが出来ない(ひとに聞くしか出来ない)後輩にあたって質問攻めにされると刺したくなります（まぢで
＃同じ質問でも、今まで調べるのに用いた手段＆調べた内容＆自分なりの推測等があるのと、
＃単純にわかりません、とでは対処が変わる。教え方も、教える側の気分もね（ｗ

まぁ、あれだ。ｶﾞﾝｶﾞﾚ。
またまた長文ｺﾞﾒｿsage

>>970
了解。キモに銘じます！ｶﾞﾝｶﾞﾙぞ〜ｗ

ウォーターフォールモデルは使えないと言う人が多いですが、
では、実際実務で使用されている開発モデルはどのようなものですか？

仕変スパイラル

要するに作っている最中に仕様を直す。
それを繰り返す。

いきあたりばったり

>>973,974
回答ありがとう。

>>972
ウォータフォール

現在いろいろモデルが乱立しているが、
全部ウォータフォールの応用にすぎない。

ウォータフォールもできない奴は何のモデルを使っても駄目

>973-974
やっぱどこもそうなのか（ｗ
安心したよ。

>>976
回答ありがとう。

安心するな
新しい開発モデルはWFの応用ではない。
WFに対するアンチテーゼだ。パラダイムシフトだ。
それゆえ、その導入には多大な抵抗が発生するのが常態だ
「いままでこうやって来たんだから」という感情論が主たる反対理由だが
WFで何もかもうまくいっているなら「新しい開発モデル」など生まれるはずが無いのだが

何だかんだ言って、テストケース駆動の開発は多くなってきているようだ。
それを指してXPとは呼べないが、XPもどきを採用するプロジェクトは増えてきているのではないか。

仕変スパイラル

これが多いんだろうけど。要するに駄目な奴の言い訳でしか
ないんだよな。後付けでお客様の要望だからとかいうけど、
根本の仕様を覆すようなことがあると現場もなえるだろ。

本当に天才なPJならWFでいいはずだ。

んで、天才なPJなど存在しえない以上はWFはダメであると。

>>979
> 新しい開発モデルはWFの応用ではない。
> WFに対するアンチテーゼだ。パラダイムシフトだ。
工数を見積もれない奴にはどんな開発モデルを使っても駄目

>>972
マジレス

ウォーターフォール（局面化）：開発をフェーズに分けて確認して進める
ベンダーにもよるが、RD、ED、ID、CD/ITa、ITb、ST
大きいシステムでは、サブシステム化と併用する。手間がかかるが確実。

イタラティブ（繰り返し）：プロトタイピングを繰り返して開発
オブジェクト指向やツールを持ち込んだ開発と言われる。
大規模開発では手戻りが激増して、必ず破綻する。

現実には両者を併用する。
ユーザー要件はプロトタイプで細部までつめる。
大きな局面は、やっぱり分ける（そうでないと開発量が見えない）

RD：要件定義
ED：外部設計(ベンダーによっては概要設計とも言う)
ID：内部設計(ベンダーによっては詳細設計とも言う)
CD/UT：開発・単体テスト
ITa：統合テストa(サブシステム内)
ITb：統合テストb(サブシステム間)
ST：システムテスト(負荷テスト、障害テスト、ユーザー業務検収テストも含める)

>>984
レスありがとう。

開発手法を併用するが故に、その併用のバランス自体が問題になる。
開発手法の効果はPLやSEの人的能力に依存してしまい、
開発手法単体ではプロジェクトを成功させる手法足り得ない。
真の解決策は未だ闇の中、というわけさ。

>>985
そういう略語はどこで決まってるの？
RD, FD, SD, DD, MK, UT, IT, STってのも見たことがある。
MK以降が、MK0, MK1, MK2, MK3, STってのもあったな。

>>988
所詮社内用語だろw
ここで晒す奴がどうかしてるんじゃない？

> そういう略語はどこで決まってるの？
各大手開発会社が勝手に決めてる。
標準は昔策定されたはずだが、誰も守ってない。

数バイトの節約のために見やすさを犠牲にする愚行。
所詮社内略語なんぞCOBOL時代の負の遺産。

http://www.sham.jp/studio/sound/denki/

他板で発見。

>>992
アニソン風味でちょっと引いた。20秒で再生止めた。

>>988,989
各ベンダー(IBM、富士通、NEC、日立、NTTデータ等)が決めた。
社内用語というより、ユーザーや関連会社をまきこんだ業界用語だね。

http://it.jeita.or.jp/infosys/jeitakouza/kyouzai/toudai/09t_pm.pdf
これはIBM出身のPM学会で有名な岡村氏の作成資料

ウーターフォールとスパイラルの比較記事
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20030516/1/

>>995
その記事の中、

…要件をきっちり定義しない反復型の方がむしろ，日本のコミュニケー
ション・スタイルに合っていてやりやすいのではないか」（30代後半の
ベテラン・プロジェクトマネジャー）

こいつの下には死体が転がってるのではないか？
(悲観的に考えすぎかな…)

そうか、「反復型」＝「要件をまともに定義しない開発」
という意味だったのか

　　　　　　　　まもなくここは　乂1000取り合戦場乂　となります。


　 　 　 ＼∧＿ﾍ　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　,,､,､,,,　/ ＼〇ノゝ∩ ＜　1000取り合戦、いくぞｺﾞﾙｧ！！　　　　　　　,,､,､,,,
　　　　/三√ ﾟДﾟ)　/　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿　　,,､,､,,,
　　 　　/三/| ﾟＵﾟ|＼　　　　　　,,､,､,,,　　　　　　　　　　　　　　　　　　　　　　　,,､,､,,,
　,,､,､,,,　Ｕ （:::::::::::）　　,,､,､,,,　　　　　　　　　＼オーーーーーーーッ！！／
　　 　 　//三/|三|＼　　　　　∧＿∧∧＿∧ ∧＿∧∧＿∧∧＿∧∧＿∧
　　　　　　∪　 ∪　　　　　　 （　　　　）　　　 （　　　　 ）　　　（　　　　）　　　 ）
　,,､,､,,,　　　　　　　,,､,､,,,　　∧＿∧∧＿∧∧＿∧ ∧＿∧∧＿∧∧＿∧∧＿∧
　　　　　　,,､,､,,,　　　　　　 （　　　　）　　　 （　　　　）　　　 （　　　　）　　　 （　　　　）

スレッドを立てるまでもない質問雑談スレ15
ttp://pc3.2ch.net/test/read.cgi/prog/1083226349/

１０００いただきます

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。