プロのプログラマのプログラム教えて

大学でC/C++/Javaを教えています。
内容は30行から長くて100行くらいのサンプルです。
プロのプログラマっていう人たちは、どういうプログラムを
書いているのでせう。教えて下さい。

>>1
フリーなUNIX（Linux , *BSD etc)やGNUプロダクツのソースコードを読め。
死ぬほどあるから堪能するよろし。

＝＝＝＝＝＝＝＝＝＝終了＝＝＝＝＝＝＝＝＝＝＝＝＝

>>2
やつらはプロのプログラマじゃねーぞ

#include <stdio.h>

void saiki(void);

void main(void)
{
saiki();
}
void saiki(void)
{
printf("1は逝ってよし！\n");
saiki();
}

>>3
無論学生さんもいるがプロもいるぞ？

>>4
ANSI Cの規格では、main関数はint型でなければならないはず。
（そんなことは百も承知で書いているのだとは思いますが・・・）

>>6
いいかげん、そのつっこみ、うざい。

>>7
間違った煽りコードの方がウザクないか？
つーか、なんで間違ったコードが次から次へと出てくるんだろう？

>>8
「こんな奴でもプロです」という自己顕示なんだろ（ｗ

>>8
最終的に動けばよかろうってこと。

というか、コードは間違っていない。
コードが間違っていればコンパイラはエラーを吐く。

>>8
どうせならもっと高度なつっこみをしてほしい。
初心者でもできるつっこみなんていらん。

>>10
void main だとWarningを吐かないか？

>>12
ワーニングは吐くかも。

まあ、エラーとワーニングは違うしね。
やれANSIが良いだ悪いだってのはもう飽きたし。

Warningの意味が分かって無視してるのならいいんだけど、
何も考えず無視してるﾔｼ多いからな。
特に、
＞まあ、エラーとワーニングは違うしね。
と言うﾔｼにその傾向が多い。

業務の場合、一人で全部作るのってレアなケースの気もするが。
モジュール単位でしか作業が与えられないし。

>>14
プログラムなんて動きゃーいいんだよ。
きちんと設計して動いて試験してバグ検出して潰して
ドキュメント整備して保守にきっちり引き継ぎかけてれば
だれもなにも文句いわねーんだよ。

>>14
あとついでにゆーと、ワーニング潰しは食後のデザートっていうか
やる気のおきないときに暇つぶしにぷちぷち消すものなんだよ。

ドキュソだ・・・

マジレス（って言うんですか）ありがとうございます。（とくに15番さん）
「モジュール単位」ということは、なんとなくわかるのですが、たとえば、
「君はこの関数（orクラス）、そこの君はこの関数（orクラス）」という
具合なのでしょうか。たとえば、「どんな関数」とか「一人で書くのは一日
何行くらい」とか、具体的に教えていただけるとうれしいです。もちろん、
微妙な問題だとは思いますので、「こんな感じ」というだけでも参考になり
ます。m(__)m

>>2
GNUのコードなどあまり見ていないのですが、たぶん、かなりレベルが高いような
気がします。Linux自身とか。それに、全世界に向けて発信するようなものであれ
ば、技術レベルか内容かにおいて、「抜群のもの」ではないでしょうか。
そういうものを書けなければプロになれないのでしょうか。

＞＞19
>「君はこの関数（orクラス）、そこの君はこの関数（orクラス）」という
>具合なのでしょうか。

そだよ。場合によりけりさ。
exeが複数のプロジェクトの場合exe単位で人を割り振る場合も
あったりする。

＞たとえば、「どんな関数」とか「一人で書くのは一日
＞何行くらい」とか、具体的に教えていただけるとうれしいです。

例えば、今、Excelで書かれた似非仕様書から
ソースを自動生成するソフトを作っています。

Excelから仕様書の書式にしたがってデータを抽出でexeひとつに一人
その抽出されたデータからソースを自動生成するexeでひとつに一人
ソースを自動生成するためのキーワードと
自動生成ソースから呼び出される関数を記述する仕事で一人

こんな幹事

仕事を与える部下のスキルにもよるかな。

EXEひとつ任せられる程度の実力があればEXEそのものを
まだちょっと・・・・かな？という程度の若造には画面一枚、帳票一枚といった単位で
入社一年目のぺーぺーにはまず共通関数を一つ

一日何行、ってのは考えたことないなあ。処理内容によっては、たかが
１００行にも満たない関数一つ作るのに一日以上かかったりするし、その
逆に一日で１０００行の処理を量産したりもする。業務内容によって千差万別だよね。

そういやソートロジックとか全然使わないなぁ。

>>20
全部が全部じゃないけど、やっぱり他人の目にさらされる
方がコードは洗練されるね。非常に参考になる、という意味で
薦めた。

が、プロの書くコードがどうかというと、それこそ千差万別。
社内でしか通用しないローカルルール盛り沢山だったり
するので、参考になるようなならないような。

あ、単なる実態調査のつもりだったらスマソ。当方の勘違いなり。

補足。

いいソースをかけなきゃプロじゃないのか？と聞かれたら、いいやそんなわけ
ない、と答えます。最初から書けるほうがおかしいよね。

どんな奴でも業種を選べばプロにはなれる。いいプロかどうかは別として。

というのは、他のスレを観察してればなんとなくわかると思うぞ。

ＯＪＴという名のもとにおいて。。。

レス、いろいろありがとうございます。
>>21
なるほど、そういうものなのですか。内容もかなり具体的なので参考になり
ました。小さい（？）exeに分割するのはUNIX流なのかと思っていたのです
が、Winでそんな風に開発するのですね。それから、Excelから読み出しとい
うとOLEでしょうか。OLEはできて当然なのかなーと思いました。
>>22
100行一日は私にはすでに限界の数字です。1000行はすごいですね。ものに
よると言われましても、なんにしても、です。
>>23
短いけれど気になるコメントです。ソート．．．というと、qsortとかsort
とか（すみません、私はC/C++屋）ですよね。
>>24 >>25
いろいろ参考になります。確かに「公開」はすばらしいですね。
「社内でしか通用しないローカルルール盛り沢山」、なるほど、そうなのですか。
「いいソースをかけなきゃプロじゃないのか？」失礼な響きがあったらすみませ
ん。私には書けないということです。

今年私がゼミを持った学生たちが、来年巣立ちます。プログラマになる学生も多
いのです。私のゼミがプログラムゼミなので当然といえば当然なのですが。学生
に何を教えるかは、重大なテーマなのです。（匿名ということで言わせていただ
くと、偏差値のよい大学ではありません。ゼミの学生のやる気はありますが。）
「会社で教育する」と言われればそれまでですが、私もいろいろ知っておきたい
のです。

やっぱり何年かは社会経験が必要だね。

>>27
ソース云々よりも、実務の場合、設計、仕様の概念の方が重要視
されると思うが。
大学の授業だからそんなに実務を意識することもないと思うけど。

そうね、漏れも同意。
あるいは大学内で開発プロジェクトを立ち上げて、発注する立場、
受注する立場(こっちは模擬的かもね)の両方を経験できるでしょ。
あ、これは学生がじゃなくて教える立場のあなたがよ>>1

プログラミングは結局は実作業しながら覚えるものであって、
それに必要な基礎能力が備わっていれば、大抵の言語はOKになる。
要は本人の問題解決能力。言語だけ覚えて分かった気になって、
入社直後に痛い目を見るｸｿ共が多すぎる。

あと当面はPCが端末の主流だから、PCのインストールはおそらく
ほぼ全員が後で役立ったと思えるはず。これだけで飯食えるし。
特に周辺機器のインストールにはコツがいる場合があるから、
それを実体験できるといい。IRQやASPIのバッティングとかかな。
OSはPC付属ではなく、MS純正をね。
苦労しながら10回位やっとけば人並みにはなる。
ちなみに漏れは1000回ｵｰﾊﾞｰ。1日に50台超もままあったからね。

>>27

> Excelから読み出しとい
> うとOLEでしょうか。OLEはできて当然なのかなーと思いました。

Excelといえば、VBAじゃよ。まあVBじゃけど。
OLEなんかしらにゃーい。

プロ＝すごい技術餅、と思っているようですが
そこらのフリー＆シェアウェア作者や
プログラム系ML＆BBSにいる人の方が遥かレベル上ですぜ

一応プロは朝から晩までプログラム見てるので
小中学生でもそれだけ時間かけたら100行以上は余裕でソ。

某旧帝大の情報科の授業では
モジュール＝関数と「固定観念化」して仕様書とコードを書かせている。
ちなみに言語は旧仕様のＣ。使っている教科書の中身がめちゃ古い。
一方、同大学の非情報科の授業ではJavaやSchemeを教えている。
しかもハードウェアの基本構造などから分かりやすく解説。
日本の将来は暗いと思った。ちなみに自分は非情報科の学生でバイトPG。

情報科は
教授が一度覚えたものに固執して教育しようとするからね。

日本の情報産業教育は最低レベルだから相手にしないほうがいいよ。

俺、卒業してからプログラム始めたけど
3ヶ月フルで勉強したら大学の情報科4年分には
十分匹敵すると思う。

>>32
基本をしらねー人間が書いたプろグラムなんて
読めたモンじゃねーんだよ
古い教科書を使っているのはわざとだよ。
講義受けもしねーでハッタリこくな

>>34
中身知らずに罵倒せんでくれ。
将来PGになりたいから情報科の授業にもぐりこんでいたが
あまりに酷くて話にならなかった。
古典と言われるような名著を使うのであれば古さ関係ないが
>>33 が言うように講義担当教授もしくはその師匠が
書いた国産の非常に分かりにくく内容の薄い本を使ってる。
教授の授業下手もあいまって、情報科の４年生でも
「アセンブラって何？」とか言い出す奴が五割超だ。
情報科というのは「情報関係は自分で勉強する科」というのが実体に近い。

>>34
OOPなんか全くない教育する所もあるのよ。
そんなので基礎やっても仕方ないだろが。

>>35
情報科=
プログラム知らずに仕様書かいてればいいと思ってる
なんちゃって似非技術者Sヨになるためにあるんじゃないか？

mean while(1 in !(){"dead"}){
for (p<<1) registerd(UnderF){0};
print.over.ridden("逝け");
mean;
}

間違い。registerd > registered

function2(){
shutdownthisthread();
}

大学の教科書といえば、帝京大の講師が書いたJavaの教科書を
読んだことがあるよ。
全ページ逝ってよしなシロモノだった。
あれがこの世に存在する理由はただひとつ、学生に買わせて印税を
稼ぐためだ。
そういう教科書でドキュソ講師が教えてるんだ。専門学校で
腐れコボラー講師と仲良くなって昔話を聞くほうが、役に立つかも
しれん。

僕は情報科の学生ですけど
情報科の出であるということを
恥じない自称プログラマは
見捨てた方がいいと思います……。
たとえその当人が有能であっても
同級生はドキュンばかりですから……。

授業から帰ってきて、すごいことになっているので、驚きました。
だんだん、大学教育批判になってきたような。一応、思ったことを
書きますと、一般的に「エライ情報の先生」は、エラサゆえ新しい
方にいけないようです。文部科学省（旧文部省）の「教育に関する
委託研究」で、「オブジェクト指向は高度な内容なので、学部より、
大学院で教えるべき」という意見書が出ていたのにあぜんとしまし
た。２年前ですが。「情報系の学科より、他学科の方がよい」とい
うことも一般論としてはありそうです。もちろん、例外も十分ある
と思いますが。私はいわゆる「情報科」ではありません。^^)

まあ、それはそれなんですが、ある種の大学教員も「実務」を知る
べきだと思います。そして自分はその「ある種」と思うので、質問
させていただいたのです。「教員が発注・受注」というのはよいア
イデアだと思いますが、どなたか、私に「発注」していただるでし
ょうか。実際には、難しいものです。

しかし、「学生アルバイトPG」というのはときどき聞きますが、
「学生でもできちゃう仕事」があるのでしょうか。それとも、
「例外的に優秀な学生さん」なんでしょうか。やや失礼気味の質問
ですみません。純粋に知りたいのです。

１は東京工科大学の助教授。

>>42
32,35 を書いたものです。
自分が優秀かどうかは知りませんが
C/C++/VB/perl を使う仕事をもらっています。
作るものはデータベースのフロントエンド、CGI、などです。
知り合いにはドライバ作りで仕事をもらってる学生や
在宅でアプリケーション丸々一本単位で仕事をもらっている学生もいます。
就業経験が短いので業界がどうという話は分かりませんが、
学生でもできる仕事は沢山ある、というのは事実だと思います。

>>42
オブジェクト指向が高度な内容とは痛すぎるな。
せめて君の研究室だけはちゃんと教育してあげてな。

学生にもできる仕事って当然あるぞ。ただ、何の脈も持たない
学生には無理だが。会社にもよると思うが、学生にかなりの
やる気があって会社にそれなりの余裕があるところならば
教育がてら仕事を与えることもあるぞ。つーか、漏れがそう
だったし。

一応、漏れは全くもって優秀じゃないぞ。勤務時間中に
こんなところうろついているくらいだからな（藁。
ただ、他の学生よりはコンピュータに関して興味を示して
いたので、漏れをバイトとして雇った会社はその辺を買って
くれたんだと思う。

>しかし、「学生アルバイトPG」というのはときどき聞きますが、
「学生でもできちゃう仕事」があるのでしょうか。

モジュールの大きさにもよるのですが、テクニカルなことが殆ど要求されない
場合もありますしね。
フローチャートを単に翻訳するだけの仕事とか。

>>44
１０年生です。
学生に仕事を依頼することができるのはとても小さな会社でしょ。
普通は、個人に発注書だせないもんね。
ひ孫受けとか？
おもいっきり中間搾取されてそ。

>>47
メーカー→直請会社→下請会社→学生

実務的なものが欲しいのなら、
仕様書（外部、内部）きっちり書いて、機能を分けて、学生それぞれ
に振って、デバッグもテスト表作ってきちんと書いて、勿論
スケジュールも引いて…。

>>47
業界の標準がどうなってるのかは
よく分からないんで案外安くで働かされてるのかもしれません。
自分の場合はデータベースにクエリー投げて
結果表示する CGI を HTML 込みで作って、一回３〜６万円です。
VBでフロントエンド作る時でも大体同じ。
コメント込みのソースコード１行あたり単価で２０円ぐらいです。
知り合いの中ではさっきも挙げた在宅の奴が一番あがりがよくて、
行単価30円程度の一件45万で Excel もどきとか作ってました。
数式コンパイルを自前処理してグラフまで作図できるぐらいのものです。
これって安いんでしょうか？それとも高い？

>>50
Ｗｅｂ系はページ単価の安さに引きずられてＣＧＩ単品だと安いよ。
これが「ＤＢ構築」とか入ると、途端に値段が上がるんだろうけど…。

行単価ねぇ…、人月じゃないの？

>>26
すみません、OJTってわかりません。（ついでに、MLって何でしょう。）
>>31
>Excelといえば、VBAじゃよ。まあVBじゃけど。
>OLEなんかしらにゃーい。

なるほどVBAですか。他のスレ（スレッドですよね？）で、かなり反VBの
意見がありますが、やはりWinでは重要なんですね。
OLEは一生懸命勉強したけど、もしかしてムダだったのかなー。涙。

>プロ＝すごい技術餅、と思っているようですが
うーん何とお答えすれば良いやら、やはりプロはプロだと思いますが。

>>51
行幾らで給料いただいてるわけじゃないです。
一度仲間内でヨタ話程度に計算したことがあったんで
参考として書いてみました。
自分の場合は給料は一件あたりいくらで決めています。
最初は時給制で事務所まで作業しに行ってました。
最近は信用してもらえるようになったんで
家に持ってかえって作業してます。

>>50
行単価って、パンチャーさんみたい。
最近の人月単価っていくらぐらいなんでしょうか？
１年生で５０〜６０ってとこ？

>>52
On the job training.です。
名前はカッコいいけど、ど素人を現場にほっぽり出すこと。

>>54
＞１年生で５０〜６０ってとこ？

そんなんもんじゃないの？

みんなストレスたまりまくって粗い反応っすね。
ｵﾚもだけど。
まじに聞いてるんだから、もうちっと丁寧に教えてあげようぜ

>>52
MLはメーリングリスト、プログラム系MLなら
いろんなものが世の中には転がってますYO

OJTってのはまともな教育を放棄して
現場で作業させながら教育するという
非常にいいかげんな教育方法。

OJTで実務に則して勉強するという名目は、ウソ8000億で
>>54さんの言うとおり。

>うーん何とお答えすれば良いやら、やはりプロはプロだと思いますが。
それは気のせい。
素直な中学生の方がまだコイツよりマシと思う連中が
ごろごろしてます。この業界。

修正

＞OJTで実務に則して勉強するという名目は、ウソ8000億で
実際は
＞>>54さんの言うとおり。

あえてプロとそうでないものの境界を作るならば、それは
結局仕事の流れを把握しているか否かだと思うけど。

>>58
それも一つあるね。漏れは、「８０％の力で１００％間に合わせる」事が
できるかどうかだと思ってる。一緒の事なんだけどね。

>>56
あんがと。

>>1
ところで新人さんのいう、「プログラマー」ってどの範囲までを
言うのでしょうか？
一般的に大卒のＰＧってＳＥへの過渡期ですよね？
コードを書くＳＥってのも有りだけど。
大手のＩＳＶは、コードに多くの感心は寄せないんじゃない？
最近はコードレビューなんてもの聞かないよね。

>>44
>作るものはデータベースのフロントエンド、CGI、などです。
>知り合いにはドライバ作りで仕事をもらってる学生や
>在宅でアプリケーション丸々一本単位で仕事をもらっている学生も
どう考えても優秀だと思います。これができる大学教授はほとんど
いないでしょう。参考になりました。
どこかのスレで、「楽に在宅プログラマになる方法はない」という
ような書き込みがあったと思うのですが、なっている人もいるんで
すね。しかも学生さんで。
>>46
44番さんの話とはまた趣きが違いますが、なるほどと思いました。
>>47 >>48
「学生さんにアルバイトがいく」ということはよいことだと思い
ます。ただ、「下請け−孫請け−ひ孫請け」の構造は、とても問題
だと思います。これは、プログラマ全体の給料を落とすことになり
ますよね。決してよいことにはならないと思います。
大手メーカーの人たちが「ソフトはウチでは作ってないよ。買う
んだ」というのを聞くと、暗い気持ちになります。
>>49
それはその通りです。でも、授業がわからないと言っている学生に、
「じゃ、もっと勉強しなさい」と言うような。;;)
>>52 >>54 >>56
OJTわかりました。^^)最近、大学では、「学生を企業に行かせて、
実地の勉強をさせる」ということが流行っています。ちょっと、
雰囲気が似ていますね。
MLもわかりました。56番さん。

これから、出かけて、アクセスできなくなります。
いろいろありがとうございます。
もっといろいろ教えていただければと思います。

> ただ、「下請け−孫請け−ひ孫請け」の構造は、とても問題
> だと思います。これは、プログラマ全体の給料を落とすことになり
> ますよね。決してよいことにはならないと思います。
> 大手メーカーの人たちが「ソフトはウチでは作ってないよ。買う
> んだ」というのを聞くと、暗い気持ちになります。

そうなんだよね〜、この構造は最悪だよ。
中に身を置いているものとしても憂慮してるし
みんな考えません？と思ってる。

一昔前に「プログラマの地位向上」とかいうスレたてたのは
俺だったりします。

でも、大手メーカーだと
ソフトを自社で作っても全然ダメダメなんですよ
金が割りに合わない＆製造工程のノウハウ蓄積は
普通の工業製品のようにはいっていない業界なので
いいものが作れない。というシステム。
まだまだ未成熟な世界。
永遠に未成熟な業界かも。

>>62
大手メーカーってある意味、広告代理店にしか過ぎない気がする。

>>63
なるほど。

でも大学の授業なんだから、実務からは離れて、他大学の学生と
連動して、画期的なＷｅｂ検索システム作るとか、もっと自由に
やってほしいなぁ。
例えば、google みたいにさぁ。

>>1
フリーソフトウェアにも、プロの品質のコードがあるからみてみるといい。

けど、もともとドキュメント書くのが好きでない人が、趣味で作った
ものだとプロの品質でないものも多いから注意した方がいい。
こういう場合は大体作者だけがメンテしてる。

たとえば、プロの品質のコードを上げると、Vimのコードなんか
まさに最高品質のコード。

http://www.vim.org/

>>65
内容はいいと思うけど、かなりズレテル。
「検索エンジン」は、ネットワーク上で最も実用的で、
競争が激しかった（今でも厳しい！）奴の一つね！

>>62, >>63
広告代理店ってたとえもよいけど、一般的なたとえはゼネコンだと思われ。
下請け、孫請け、当たり前。

>>1
シンプルに書くのが第一。

#include "/dev/tty"

>>60
>ところで新人さんのいう、「プログラマー」ってどの範囲までを
これは「プログラマ全般」です。

ただ、このスレの質問と違うテーマですが、PGとSEの実際的な意味
はよくわかっていません。「一般的に大卒のPGってSEへの過渡期」
なんでしょうか。これは「大卒＝SE候補＝エリート」という図式な
のでしょうか。うちの学生は残念ですが、大学名で出世することは
ないと思います。（実力で出世してもらいたいものです。）しかし、
お話から「コードを書かないSE」というのが、普通のようですが、
それは「SE＝出世」なのでしょうか？よくわかりません。

>>62
>一昔前に「プログラマの地位向上」とかいうスレたてたのは
まったく同感です。
私は本気で、日本の生き残りはプログラマの給料と地位の向上にか
かっていると信じています。生産者にお金と尊敬を払わない国の未
来が明るいとは思えません。

>>63
なるほどと思います。下請けくらいはいいと思います。ただ、何重
請けはやはりよくないのではと思います。それに、聞くと「丸なげ」
のような．．．。

>>65
それは私もそう思います。ただ、それは私の「興味」ではないのです。

私に現在興味あるのは「中小のソフトハウスが日常的に生産している
普通のソフト」であって、「ライバルのあまりないスーパーソフト」
ではないのです。そして、できれば、「中小のソフトハウスが日常的
に生産しているソフト」を「効率よく開発する方法」を研究し、また、
そういうところで誇りを持って働くプログラマの卵をゼミから出した
いのです。

本末転倒かもしれませんが、そういう事情で、ソフトハウス（もちろ
ん大ソフトハウスでもよいのですが^^）等で実際に作られているソフ
トやその手法を知りたいのです。大学の教員はある意味「ヒマ」です。
考えるのが仕事で、採算や納期がありません。（すみません。）それ
ゆえ、問題を与えてもらえれば、答えを考える時間がありますし、考
えてみたいのです。それが仕事ですので。（もちろん、企業へのフィ
ードバックというものにならなければいけないと思います。ただ、こ
の掲示板では、教えていただく一方ですが。m(__)m）

異様に長くなってすみません。
一例としてですが、私は同僚の先生方（の何人か）から「もうプロ
グラムを教えるのはやめたらどうか」と言われています。「Excelや
Oracleでできないことをするソフトをあなたは開発できるんですか」
というのです。あるいは「あなたの学生はバークレーの学生のよう
に、すばらしいものを開発できるのですか」と。この先生方は、
日本を代表するハイテク企業の研究員だった方々です。
実は、これには、ちゃんと反論できません。しかし、たしかに、超有
名ソフトや有名（？）フリーソフト開発者のようなことができればす
ばらしいと思います。ただ、ソフト開発とはそれだけなのでしょうか。
ヒーローになれればおおいに結構ですが、普通に働いて産業を支えて
いるプログラマだってたくさんいるわけですよね。私自身、プログラ
マではありませんが、「そっちの方」なわけです。

お休みなさい。

>>69
で言われている通り。

>>71
情熱は伝わるが何に対してレスすりゃいいかね？

うまい具合に逝くといいね。

と、いいつつ気分でレスしてまおう。

確かにス＾パ＾プログラマにはなれないかもしれないが
プログラマト言うのは非常に貴重ぞよ。
プログラムを教えることは非常に良いこと。

例えば、Excelの話になるが、VBAというのは
一般ユーザーが軽く使えるものだけど
プログラマが真剣に取り組むとすごいいろんなことが出来る。
普通の人よりExcelでより効率よく物事を処理することができるわけだ。
全自動で数千行のデータを思い通りに処理できたりする。

あと、
スーパープログラマじゃなくても
スーパープログラマの恩恵(ライブラリ)にあずかって
http://www.kitware.com/
こーんなデータ処理をするソフトが作れたりするわさ。
技術はあんまり入らないYO

あとね、最近、プログラムを教えられていないSEというものが
増えているんだけどそういう奴らは
かなりいろんなことがわかっていないから
システムを作るのに非常に効率が悪い。
そいつらがいないほうがましという話も出るくらい。

>>71
プログラマの生産性の格差をよく調べていただきたいところ。
できる奴とできない奴の格差って実装量で見ても百倍から一万倍ぐらいある。
その格差が何に起因するのかを調べたら色々分かるかもしれません。

>>73
こういうのの論文読めないのかなぁ？
ここにくるプログラマには必読だと思う。

医学、情報工学、心理学、言語学、数学
多岐にわたる調査だと思うが。

>>74
ワインバーグの本とかマネジメントの本とか読んでると
参考文献として生産性測定の論文が紹介されてるから
そこからチェックすれば分かると思う。
ただ、生産性の定量的な測定って難しいからね。
さっきは実装量って書いたけど
ゴミコードを大量に書く馬鹿もいるわけだし。
と言ってコードの質を定量するのも難しく。

>>71
現実問題、出来るに越したことはないですが、個々人のプログラミング能力って
業務全体から考えると、それほど重要視はされていないのではないのか？って
思います。
殆どの業務においては、集団作業が前提となっているわけですし、「割り振り」
さえきちんと出来れば何とかなることですから。
…って書いてて悲しくなっちゃったよ。

どちらかと言うとプログラマ個人に求められるのは、「どこまでその仕様に精通しているか？」
ってことになるのですが。

>>73
仕様書をＳＥから受け取る→コーディング→デバッグ→客先でお披露目（ここまでは予定通り）→
仕様変更→コーディング→デバッグ（早くリリースしろとせかされテストが疎かに・・）→
（この後６〜７回仕様変更とデバッグを繰り返す）→リリース→バグ発生→プログラマ死亡

俺が実際に陥ったケース。
プログラマより客又は仕様を考えるＳＥに問題がある
ケースも多々あると思われ。

>77

をを・・・典型的なプログラム→バグ　スパイラル・・・。
こわっ！

>>72
>情熱は伝わるが何に対してレスすりゃいいかね？
ごちゃごちゃ書いてすみません。私がみなさまにうかがいたい
ことは、1番にあるように、「プロのプログラマのプログラム」
の実際を、できましたら具体的に、教えてくださいということ
です。最初の方にレスをくださった方の、Excelからデータを
取る話、データベースのフロントエンドを作る話など、とても
参考になりました。また、開発の仕組み、学生アルバイトの話
など、なんとなくわかってきて、とてもうれしいです。

情熱はありません。^^;)これが私の「仕事」なんです。（たぶ
ん）一応、私関連で意見や説明を求められているのかなと思っ
た場合に、レスを書いているつもりなのですが、なんだかフォ
ーカスがしっかりしなくなったかもしれません。すみません。

で、一応、私へのご意見と思われることへのレスです。

>>72
実は72番さんのおっしゃることは、「プログラム教育反対派」
の意見と「似ている」のです。彼らは71で書いたようなことを
言ったあと、「まあ、せめてExcel+マクロでいいじゃないです
か。Cなんて要りませんよ（VB？C++？Java?何それ？）」「だ
いたい、最近はいいライブラリがあるから、技術はいらないは
ずです（必要なら外注すればいいんだし）」もちろん（？）彼
らは、VBAもライブラリも使えはしないのですが。

>>73
75で自己レス（？）をしているように、実際には難しい話です
よね。それに、ソフトハウスやプログラマの人は、ほとんど
内部事情を話してくれません。実際問題としても難しいのです。

>>76 >>77
とても参考になるコメントをありがとうございます。不思議な
のは、76番さんは、「チームの一部」という認識で働いている
のに対し、77番さんは、かなり独立部隊的な雰囲気があります。
これは、会社のカラーの違いなのか、どうなのかと思ってしま
います。
個人的な意見（現場を知らないものの妄想？）では、チーム開
発はしかたがないのではと思います。その中で、有能なリーダ
ーがチームを引っ張って行き、各人が個性を発揮できければ．
．．と思います。
76番さん、77番さん、陰ながら、応援しています。

少し個人で書きすぎな気がしますので、控えます。

>>76
> どちらかと言うとプログラマ個人に求められるのは、「どこまでその仕様に精通しているか？」
> ってことになるのですが。
それはそうなのですが
おおよそ業務アプリというものは
仕様さえはっきりしていれば並のプログラマなら
技術的にはなんら問題がないです。頭の中で全モジュールのイメージは可能です。

問題は、並みのプログラマになれないヨタＳヨが
プログラムイメージがないままに仕様を決めて
出来ない事を出来ると思い込む所・
プログラマとのズレがあり、伝達もうまく出来ない場合
非常に非効率的だと思います。

>>79
>もちろん（？）彼 らは、VBAもライブラリも使えはしないのですが。
でしょ？しっかりと地に足つけた技術がないと
頭の中で「Excelマクロでいいんだろ」と言う事がわかっても
実践すら出来ないですよ。

プログラマの生産性については
私はこう思います。

�@出来る人は超できる人<<一部精鋭極少数
�Aまあまあ並の技術を持っている人<<結構、数いる。
�Bわかっているふりしてわかっていない人<<ここが一番多い
�C思い違いをしている人<<少数だがいる。存在自体が迷惑

ここで�@と�Aくらいの組み合わせだと
�Aも己の実力を把握しているから�@に美味く使われる
ように働けるので、生産性の高い仕事が成り立つのですが
絶対数の多い�Bが紛れ込むと
�@と�Aの生産性が下がるのです。

�@が3人
�Aが10人
�Bが30人
のプロジェクトチームがあったとして

恐らく
�@と�Aと�Bの43人チームでプロジェクトを勧めるより
�@と�Aの13人チームで一つのシステムを組むほうが
より質の高いものが仕上がると思います。

私のイメージだとこんな感じです。

>>81
>�@出来る人は超できる人<<一部精鋭極少数
>�Aまあまあ並の技術を持っている人<<結構、数いる。
>�Bわかっているふりしてわかっていない人<<ここが一番多い
>�C思い違いをしている人<<少数だがいる。存在自体が迷惑

自分のイメージですと、
１．その業務に精通している人。
２．業務への精通はまあまあ、技術的には問題なし。
３．業務知識が足りない。技術的にもやや不安。
４．問題外。

１がプロジェクトリーダークラス、
２が使える人員で、３だと業務経験１年ぐらいの新人レベル。
メインのプログラムは２が行い、３はそれの補佐的なことを任せる。

４はプログラミング作業には出来れば入れたくない。
もし入れるとしたら、ドキュメント生成、テストなど、プログラミング以外の
作業に回す。

＞�@と�Aと�Bの43人チームでプロジェクトを勧めるより
＞�@と�Aの13人チームで一つのシステムを組むほうが

�Aに�Bを３人つけるというのはひどい（笑）。

>>77
仕様変更の難解度とプログラマの能力を把握できずに、仕様変更のスケジュールの
線を引いたアホＳＥですな。

機種依存文字使うのやめてよ。

> 　が3人
> 　が10人
> 　が30人
> のプロジェクトチームがあったとして
>
> 恐らく
> 　と　と　の43人チームでプロジェクトを勧めるより
> 　と　の13人チームで一つのシステムを組むほうが
> より質の高いものが仕上がると思います。

何のことだかさっぱりわかりません。

>>84
>機種依存文字使うのやめてよ。

2ch初心者には返す言葉がないので無視

>>84
2CHくんなよ。

プログラミングって、アカデミックな部分よりテクニカルな部分が多いよね。
沢山のコードを読んで、本を読んで、沢山のコードを書いて身についてくる。
もちろん、センスもあるけど。
で、こうして苦労して身についたテクニックは、
「ほらよ。」
って人に教えるのが惜しくなる人が多いようです。
�@->�A->�B
という伝搬がスムーズに行かないことがありますよね。
「おれから盗め！」
みたいな職人気質です。

>>87
おれはむしろ逆だな。まわりにバンバン教えてる。

だって、まわりのレベルが上がれば
フォローに回ったりケツ拭いたりする手間が省けるじゃん。
優越感に浸るのももう飽きた。

技術指導っていうよりはむしろ調べ方を教えます。
人に聞く前にＨＥＬＰとか参照させるクセをつけとかさせないと、
後が大変。
（こっちだってずっと余裕があるってわけじゃない）

自分が「たまたま」見つけたいい方法って割と教えるようにしてますが。

後輩の教育か、または全体の進捗を優先するか。。。
難しい問題ですよね。
新人の頃に、
「３０分調べてわからなかったら聞け！」
って先輩に言われた。

>>90
それ日本で最初に言ったのは俺だ。間違いない

あ〜、俺もここ２、３年は教え魔と化してるな。

つーか、俺はもっと別の事がやりたいし。

>>77
遅レススマソ。当たり前の話ではあるけど
何が生産性のキー要因であるかは環境によって違うよね。
俺んところは社長込みで５人程度のソフトハウスなんで
一人一人のプログラマの能力が影響が一番大きい。
規模が大きくなってくるとコミュニケーションや
進捗管理の影響がでかくなる。
利用するツールやライブラリを改善したらいきなり状況が
よくなる場合があるかもしれないし、客がドキュソの場合もある。
生産性に関係しうる要因をリストアップして
色々な実例におけるキー要因と
それが何故キー要因になるのかの理由を整理するといいかも。

まずは「人月の神話」って本を読んで欲しい。
このスレにも似たような話がいくつか出てるからな。

bk1 http://www.bk1.co.jp/ でも買えるようだぞ

みなさんのお話を興味深く読ませていただいています。

一般論として、プログラムのできない（センスのない）SEさんが、「困ったちゃん」であることは、みなさん一致してい
るようですね。

>>81
>A 出来る人は超できる人<<一部精鋭極少数
>B まあまあ並の技術を持っている人<<結構、数いる。
>C わかっているふりしてわかっていない人<<ここが一番多い
>D 思い違いをしている人<<少数だがいる。存在自体が迷惑
なるほどです。（文字をちょっと変えましたがお許しください。m(__)m）とてもイメージのわく解説でした。
素人判断をすると、上の布陣で効率化を図るなら、Dの方には職種変更をお願いし、なるべく多くのCの方にBへグレードアップし
ていただくというものではないでしょうか。それを阻むものは、Cの方々の個々の性格というより、どこかにシステム的な問題
（81番さんの会社のシステムではなく、この国全体のシステムです）のような気がします。

>>82
これもイメージがわくお話でした。82番さんの4分類と少し違いますが、わかるような気がします。81番さんのC（原文ではマル3）
と82番さんの分類3が、現実には同じ集団で、81番さんと82番さんで評価が異なるのか、もともと異なる集団なのか、興味深いです。

>>87
>A->B->C
（原文ではマル1->マル2->マル3、勝手に変えてすみません。m(__)m）
>という伝搬がスムーズに行かないことがありますよね。
私に「社会経験」はありませんが、なんかわかるような気がしました。私自身、ちょっとつらい思ひ出もあります。

おもしろいのは、続く、88番さんから93番さんまでのところでは、（比較的？）うまく行っているご様子だということですね。「30
分調べてわからなかったら聞け！」は名言です。 ただ、これらの場合でも、「先輩から後輩への技術の伝播」は先輩の人柄に任されて
いるように見えます。「全体の技術力アップ」がシステムとして存在していないということでしょうか。たとえば、全プログラマのス
キルアップを担当する係はいないのでしょうか。また、お話から、個々人のスキルアップがその人の給料アップなどに直に結びついて
はいないような気がします。「君はＸだけスキルアップしたから、給料をＹ円上げよう」などというのは、難しいのでしょうか。
（前に生産性のお話がありましたが、たぶん、まじめに生産性を考えるということは、生産性に応じた賃金格差を認めることになるの
ではないでしょうか。そうでなければ、忙しい合間をぬって、勉強したりしないのではないでしょうか。とはいえ、前に書いたように、
まずプログラマ全体の社会的地位向上があるべきだと思いますが。）

>>94
「人月の神話」秋までには読みたいです。
ところで、今は「達人プログラマー」という本を読んでいます。
まだ100ページほどですが、おもしろいです。しかし、内容のおもしろさもさることながら、この本がこの手の本としてはベストセラ
ーになっているという事実が、とてもおもしろいのです。つまり、
１．誰が買うんだろう？　管理者？SE？PG？
　　（失礼ながら、プログラムを書けないSEさんが読んでもわから
　　ないのでは？しかし、PGさんは仕様変更に追いまくられ（？）
　　こんな本を読んでいる時間はないのでは？などと思うのです。）
２．この本を読んだ人／会社は、その内容を本当に実行するのだろ
　　うか？会社やチーム全体の同意がなければ、絵に描いた餅では？
　　それとも、単なる「読み物」として売れているのだろうか？
ということが疑問になってくるのです。どなたか、ご意見があれば教えてください。

プロのプログラマとは
１．お客の話には笑顔で聞ける人
２．その上でできることできないことをはっきり言える人
３．自分が公言した期限までに仕事をあげることができるひと。
４．作業一切の記録をとり、整理保存のできる人
５．情報を確実につたえることができるひと。

これらがすべてできたうえで、実力があるひと。それがプロ。
募集中だけど、いねーよー

>>96
> １．お客の話には笑顔で聞ける人
> ２．その上でできることできないことをはっきり言える人
> ３．自分が公言した期限までに仕事をあげることができるひと。
> ４．作業一切の記録をとり、整理保存のできる人
> ５．情報を確実につたえることができるひと。

４．５．は心がけているから出来ると思ってる
進捗状況は社内でもメールでガンガン送るといい。証拠も残るし
互いの都合のよい時間にコミュニケーションが取れる。
３．はかなり長めに納期もらうけどいいのかな？
「もっと早くできるだろ」的な嫌な顔されるのは嫌だな
「もうちょっとスケジュールを検討してみよう」と助けてくれるならヨシ
２．は慎重派だからはっきり言える。
１．無理（藁

>95
「達人プログラマー」は、現場のPGが読むと、ためになると思う。
SEはまず読んでも面白くないだろうし、
管理者に読んで欲しいけど「チーズは何処に消えた」を優先的に読んでそう。
※折れは「バターはどこへ溶けた?」の方が好きだが。

これをみればみなさんも儲かりますよ！！
ttp://members.tripod.co.jp/casinoA1/

sage

ナレッジマネジメント、文書管理等がもてはやされていますよね。
「個人のノウハウを会社のノウハウにしましょう。」
ってやつ。
これはプログラミングの生産現場では、古くから幾度となくチャレンジしている
けど、どれもこれも上手くいってないんじゃないかな。

それから、
「〜自動プログラミングソフト完成！」「プログラマの存在危機！」なんて言葉
が何度も工業新聞を賑わしたけど、これで職を追われた人っているのかな。

画期的な生産現場の改革って起きないのかな？

81です。私のイメージは実際の業務と離れた所の視点でしたね。
純技術的側面かな。
現場では82さんの方がピッタリかも。
ただ、俺、業務内容の把握がいまひとつ苦手なのだ。
業務内容が把握できた時には頭の中でプログラムコードにすべて置き換われる
から、抜け目なく業務内容を把握しなきゃ気がすまないからかな。

仕様を把握しているという割に抜け目だらけの人も多いけど
どっちが効率いいのかは自分でもわからないなあ。

> ただ、これらの場合でも、「先輩から後輩への技術の伝播」は先輩の人柄に任されて
> いるように見えます。「全体の技術力アップ」がシステムとして存在していないということでしょうか。
> たとえば、全プログラマのス キルアップを担当する係はいないのでしょうか。

実際問題としてスキルアップ担当人間を配置するほうが効率がいいのか、
それともその担当人間がさっさとプログラムを作った方が効率いいのか
その二者択一ですら誰にも把握できてないと思います。

生産性の高いシステムというのが未成熟な業界なんですよ。
個々の会社や部署では努力しているのかもしれませんが
それも小規模レベル個人レベルでの所にとどまっているでしょう。

効率のよい何らかのやり方が広まればいいと思います。
日進月歩な業界だからそのやり方すら変えていかなければいけないというジレンマもありです。

余談ですがその点、
個人的にはＸＰ(エクストリームプログラミング)のペアプログラミングは
すばらしいものを持っていると思う。広まってくれることを願ってます。
調べてみると面白いです。現場のプログラマには支持者は多いと思う。

＞まじめに生産性を考えるということは、
＞生産性に応じた賃金格差を認めることになるのではないでしょうか。
＞そうでなければ、忙しい合間をぬって、勉強したりしないのではないでしょうか。
そうですねー。
勉強好きで、どんどん勉強したとしても全く賃金アップにはつながらないですよね。
技術アップが賃金アップにつながっているという
人も見たことがないです。(藁

>>96 >>97
私がプロになれないのは、
> ４．作業一切の記録をとり、整理保存のできる人
ができないせいですね。^^;)
>>98
>「達人プログラマー」は、現場のPGが読むと、ためになると思う。
ずばりのご意見ありがとうございます。参考になります。
>>101
ありがとうございます。
>「個人のノウハウを会社のノウハウにしましょう。」
という観点で見ていなかったので、なるほどと思いました。
それから、「古くから幾度となく」ということも、言われてみれば
なのですが、説得力がありました。
>>102
詳細なレスありがとうございます。とても参考になりました。
>業務内容が把握できた時には頭の中でプログラムコードにすべて置き換
>われるから、抜け目なく業務内容を把握しなきゃ気がすまないからかな。
すばらしいことだと思います。
>実際問題としてスキルアップ担当人間を配置するほうが効率がいいのか、
>それともその担当人間がさっさとプログラムを作った方が効率いいのか
>その二者択一ですら誰にも把握できてないと思います。
単純に考えると、大会社なら専属を置き、そうでなければ、開発リーダー
等が教育係もやる、ということにならないでしょうか。その場合、「教育
係」の仕事がどう評価されるかが難しそうですよね。ボランティアではな
く、きちんと、賃金として支払われるべきものだと思うのですが。
>生産性の高いシステムというのが未成熟な業界なんですよ。
>個々の会社や部署では努力しているのかもしれませんが
>それも小規模レベル個人レベルでの所にとどまっているでしょう。
いろいろ聞いていると、本来期待できるはずの大手メーカーがまったく
頼りにならない、と言うか、逆噴射をしているように思えます。小規模レ
ベル、個人レベルからの「革命」の方が、現実味があるような気がします。
いわゆるベンチャーってやつですね。（もちろん、簡単だと思って書いて
いるわけではありません。）「自分ではソフトを作っていない元請けを通
さずに、実際にソフトを作っている会社が受注する仕組み」は現実味がな
いのでしょうか。
たとえば、93番さんの会社は、「社長さんを含めて5人程度」というお話
でした。たぶん、そういう社長さんは、プログラマとしても優秀なのでは
ないかと想像します。そういう会社が大成功をすることが、世の中を変え
るのではないでしょうか。もちろん、大ソフトハウス（？）であっても、
（なくても）自分で開発しているところに成功してほしいということです
が。
>個人的にはＸＰ(エクストリームプログラミング)のペアプログラミングは
>すばらしいものを持っていると思う。広まってくれることを願ってます。
>調べてみると面白いです。現場のプログラマには支持者は多いと思う。
そうなのですか。今度読んでみます。
>勉強好きで、どんどん勉強したとしても全く賃金アップにはつながらない
>ですよね。 技術アップが賃金アップにつながっているという人も見たこと
>がないです。(藁
うーん、そうなのですか。どうも、技術を持っている人（＝プログラマ）の
上に、技術がわからない人が乗っかっているのが根本原因．．．でしょうか。

ベンチャーなら、CEO兼開発技術者なんてしょっちゅうあるだろう。
少数で一般的な大企業以上の市場価値を生み出している会社もな。

>「個人のノウハウを会社のノウハウにしましょう。」

社内イントラでの技術ＤＢとか作りたいなぁ、って以前は考えていたけど、
あんまりノッテこないっすね、皆。
１．メンドくさい。忙しい。
２．技術自体にそれほど興味がない。
というところか。

「自分ではソフトを作っていない元請けを通さずに、実際にソフトを作っている
会社が受注する仕組み」

コネがないから？
直請けの業務にも幾つか関わったことありますが、大概コネがあったとか、
そんな感じでした。
協力社員体制（派遣方式）とっているところも多いかな？
内省できるのがベストなんだろうけど、常時そんなに仕事があるわけじゃないしねぇ。

＞うーん、そうなのですか。どうも、技術を持っている人（＝プログラマ）の
＞上に、技術がわからない人が乗っかっているのが根本原因．．．でしょうか。

ＰＧというのは自分のスキルに応じて仕事をあてがわれるってこともあると
思うが、ＳＥって実は管理者としてのスキルばかり重要視されるから、
「詳細に関して知らなくとも仕方のないこと」って不文律ってあるんじゃないかな。
いや、現場でバリバリやる人もいるんだけど、そういう人間に限って、人付き合いが
下手というか。

すごい優秀だと感じるSEと仕事をしているのだが
その人はプログラムのことはさっぱりわからないが
理論的な話はすごく通じるし、企画書や仕様書は非常に
すっきりと作っている(必要のない仕様書なんかは作らない)

たとえば、DBのテーブルの中身について
こちらが説明した事に関して、しっかりと理解してくれて
(もちろん、こちらの説明が下手なら疑問点は残さないように質問してくれる。)
対策も提案してくるし、こちらからも対策のための選択肢を掲示する

バグが発生したときの諸問題の切り分けもよく出来ており

システム全体について、何の優先度が高いのかを
しっかり把握できていた。

俺には、ああいうことは出来ないと感じた。

SEには理論的考えの構築というものが非常に重要だと思う。
それが出来ない奴はSEとして逝ってよしかも。

でも、プログラム組んだこともない＆ソフトウェアの仕組みすら知らない
新卒SEでそういう事が出来る奴、出来るようになる奴なんて非常に少ないだろうな。

＞１０６
確かに少ないですね。
私はプロジェクトマネージャーという肩書きで幾人かのＳＥやプログラマーの方々と
作業をしていますが、仕様書無しさんのおっしゃるような人材は非常に少ないです。
逆に何処の会社組織もそのような人材に巡り合いたいと常々切実に考えているハズ
です。

>>107
巡り合いたいとは思っていても、のんびり待っているのが現状？
ていうか、まともな教育制度ってどこにあるんだろ..

# 「仕様書無しさん」はここのデフォルト名ですよ

私は言語ならまあそこそこつかえるつもりなのですが

SQLすら知らないそのSEさんと業務知識や総合的なものを比べると
私自身がSEとしては逝ってよしだろうなと、思ってしまいます。
(でも、私より遥かに逝ってよしなSEさんは掃いて捨てるほどいるだろうが)

教育は言語と同じく殆ど実施されていないと思いますが
IBMあたりの新人研修では、徹底的にやらされるとか聞いた事があります。

あまり外部には出てこない教育でしょうね。
(教師の厳しさも必要ですし

テスト

まぁ、優秀なリーダーは、
1.「獅子は我が子をセンジンの谷から突き落とし、そこから
這い上がってきた者だけを認める」みたいな教育？か
2.軍隊式の教育のどちらかでしょう。

まぁ、自分の意見や、自分で開発した研究をしなければ
ならないと強制されている所と、自分の意見や独自開発の
研究をしてはならない、と言う教育を受けた人とでは全てが
違うでしょう。

まぁ、リーダーシップや研究開発（既存の研究の習得ではない）
と言うのは、教えて身につくものでもないでしょう。
そう言ったものは、実践で揉まれて身につくし、そういった
優秀な専門書も、実際に自分が実践で揉まれた人が読んで初めて
理解できるようなもんで、
机上の上だけでは身につかないだろうな〜

新人です。いろいろありがとうございます。m(__)m
必ずしも自分宛てでないものにコメント・反応するのは僭越かもしれませんが、
思ったことを書かせてください。
>>104
なるほど。考えてみれば、（考えるまでもなく？）そうですね。
>>105
>社内イントラでの技術ＤＢとか作りたいなぁ、って以前は考えていたけど、
>あんまりノッテこないっすね、皆。
そうなのですか。実は、大学（の情報教育部門）で私も同じようなことを
試みて、挫折しました。理由は、105番さんのものに加えて、「人に教えら
れるような技術を持っている人は少ない」があったような気がします。
しかし、これはなんとかならないものかなぁと思っています。
>コネがないから？
>直請けの業務にも幾つか関わったことありますが、大概コネがあったとか、
>そんな感じでした。
なるほど。これは少し「研究」してみたいと思っています。^^)
>思うが、ＳＥって実は管理者としてのスキルばかり重要視されるから、
>「詳細に関して知らなくとも仕方のないこと」って不文律ってあるんじゃないかな。
一般論としては、そういうことなのでしょうね。
>>106
これまで、ほとんど一方的に評判の悪かったSEさんたちでしたが、「プログラムは
さっぱりでも、企画書・仕様書をすっきり作れる」SEさんがいるというお話ですね。
そういう場合もあるのですね。特別な教育を受けていない人がDBを理解するのは不
可能ではないかと思っていたくらいなので驚きました。
こういう人がリーダーならプログラムができなくても問題ないようですね。
>でも、プログラム組んだこともない＆ソフトウェアの仕組みすら知らない
>新卒SEでそういう事が出来る奴、出来るようになる奴なんて非常に少ないだろうな。
この割合は、実際どのくらいなのでしょう。
>>107
プロジェクトマネージャーさんからのコメントですね。
>確かに少ないですね。
やはり、そういうものなのですね。
>>108
>ていうか、まともな教育制度ってどこにあるんだろ..
怒られてしまうかもしれませんが、私にはこれが「興味深い」です。もちろん、
一般的な大学の教育方法なんかダメダメ（だと思います）なわけですが。
>>109
>私自身がSEとしては逝ってよしだろうなと、思ってしまいます。
それは、なんとも^^;)。
>IBMあたりの新人研修では、徹底的にやらされるとか聞いた事があります。
そうなのですか。コネをたどって聞いてみたいです。外資系は厳しそうですよね。
（「アメリカ人に聞く」というのは案外近道かもしれませんね。でも、IBMの方、
いらっしゃったら、コメントください。^^）

>>111
別の視点からもコメントですね。
>1.「獅子は我が子をセンジンの谷から突き落とし、そこから
>這い上がってきた者だけを認める」みたいな教育？か
>2.軍隊式の教育のどちらかでしょう。
企業で1方式は可能なのでしょうか。でも、2は2でちょっとつらそうですね。
>まぁ、自分の意見や、自分で開発した研究をしなければ
>ならないと強制されている所と、自分の意見や独自開発の
>研究をしてはならない、と言う教育を受けた人とでは全てが
>違うでしょう。
私のイメージでは、PGは、技術者であると同時に、よい意味での「匠」だと
思っています。（厨房っすか？）たとえば、昔の職人さんは、親方の指示を守る
ことと自分のオリジナリティを出すことのバランスをどう取っていたのでしょ
うね。
>>112
>机上の上だけでは身につかないだろうな〜
たしかに、その通りだと思います。しかし、一方で、個人の力を超えたよいシ
ステムというものがあってもよいと思うのです。たとえば、自動車の生産にお
いてトヨタのシステムはアメリカでとても高い評価を得ているようです。これ
は、日本人の得意分野と言えると思うのですが、ソフトウエアについても、
何かあるのではないでしょうか。というか、ないと困ると思うのです。もちろ
ん、自動車の生産とは違いますし、大量生産を真似た「ソフトウエア工場」と
いう意味ではありません。私のイメージは、「ソフトウエア技術者＝情報の
匠の協働と競争」なのですが．．．
開発の方法論の本の内容を、アメリカのベンチャーさんたちは、（賛成なら）
本気で実行しているのではないかと思うのです。

>私のイメージでは、PGは、技術者であると同時に、よい意味での「匠」だと
>思っています。（厨房っすか？）たとえば、昔の職人さんは、親方の指示を守る
>ことと自分のオリジナリティを出すことのバランスをどう取っていたのでしょ
>うね。

「これはこうすべきです」なんて言ってくれる新人にはそうそう巡り合えない
なぁ。放っておいても勝手に色々としてくれる新人はマレ。
最初のうちは色々と興味を持ってくれて、JavaでもC＋＋でも勝手に勉強して
くれるとありがたいのだが…。

>>113
えぇと。そもそも良いプログラマの必要条件として向上心とか内面的な部分が大きい以上、
制度が良ければ良いプログラマが育つのか？という疑問もありますが、
それでも、かなりの部分をプログラマの向上心だけに頼っている現状よりはましな方法があるんじゃないかとか思います。

プロのプログラマーは財産を持っていますね。

財産とは、自作・他作を問わずツールや知識です。
あれを作るのは、この雛型を修正しようとか、データ解析したり発生させたり
たくさんの財産をフルに活用します。

共通仕様やサブルーチンを先に作ってから本作業にかかります。

そりゃ、経験やノウハウの無い方面の仕事は
怖くて受けられないっしょ、普通。

<<118
そんなことはないですよ。同じ職種や業種を専門化して
開発しているのは、大手の会社　中小企業はなんでもする
わたしは、民間・公共合わせて１０以上のシステムの
プログラムを作りました。本数は１０００本以上あります。

>>119
意味わからない。

とりあえず、よむべし

◇給与・処遇で「成果主義」を強めるITベンダー
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20010716/1/
---
　コンピュータ・メーカーやシステム・インテグレータといったITベンダーのあい
だで，技術者など社員の昇給や昇格・昇進を決める際の判断基準として「仕事の成
果」を重視する動きが広がっている。特に今年4月には，注目すべき出来事がいく
つもあった。
---

>>119
職人ですね

>103
あなたがプロになれないのは、その一歩引いた分析的な
姿勢だと思います。
なれないというよりなるつもりがないのでしょう。
けして悪い意味ではなくて、現場の人間というよりは研究者タイプぽいかなと。
頭のよさそうな方だから、
私が社長ならナレジマネジメントの任のために雇いたいですね。

105>
CとかVBとかDBとか、あまり特殊じゃない技術なら、
Webにリソースがあるし。

ただ、社内の掲示板にプロジェクトに必要な情報への
リンク集とかあると便利かも

http://www.kinet.or.jp/kamiyabe/pictures/age.jpg

東京に行って帰ってきました。人多ーい。ビル高ーい。
しんどーい。でした。
最近、このページを読むのが生きがいになってきました。

>>115 >>116
いずれにしても、本人の向上心が大事ということですよね。
あとは、「向上＝お金」というシステムがあってもよいか
な．．．と。うーん、くどくてすみません。
（120さんがそういう指摘をしているのですね。）

>>117
>プロのプログラマーは財産を持っていますね。
すばらしいですね。（ほんとに。）このプロの方々の財産
を見たい．．．と言ったら、怒られるのでしょうね。
私が、本当に、求めて止まないのは、この「財宝」なんです。
（盗もうってわけではないのですが。でも、本当に見たら、
盗んだことになるのですね。情報ですから。）

>>118 >>119 >>120 >>121
プロ同士の会話ですので、固唾を飲んで、静観させていただ
きます。m(__)m
（ちなみに、117さんと118さんの言いたいことは、同じです
よね。）
120さんの言う「仕事の成果を重視する動き」は、見せかけだ
けでなく、いずれ本当に来ること（もう来ている？）のよう
に思います。サバイバルのために。

>>122
>頭のよさそうな
女房に聞かせたい．．．
>私が社長ならナレジマネジメントの任のために雇いたい
学長に聞かせたい．．．光栄です。^^)
私は教員ですが、IT産業の中で、メシを食いたいという気持ち
は本当です。（学生が「授業はやく終われ」としか思っていない
なか、誰にも聞かれずに、フローチャートの書き方をつぶやい
ている人たちの「仲間」でいるのは、きついのです。）

>>123
横からすみません。2chって、案外すごい情報源ですよね。

ちょっと、前からお聞きしたかったことを書きます。
普通の企業がオーダーメイドのソフトを発注するとすると、
顧客情報や在庫管理等が絡むと思われます。すると、DBが必要か
と。この場合、自分でDBソフト（DBMS）を書くより、有名所の
ものを使うことになるのではないかと。すると、オーダーメイド
の主要部分は、DBのインターフェース部分（あるいはDBと対話す
る部分）かと思われます。ということで、「DBと連携する」仕事
は多いのではないでしょうか。厳しいお叱りでもかまいません。
どなたか教えてください。私は現在これがアナかと思って勉強中
なのです。「これまでに作ってきたソフト」を、おいそれとは公
開できないと思いますが、雰囲気だけでも、どなたか言ってただ
けると、感激なのですが。

>>126

はい、DBと連携する仕事は多いです。
それにネットを絡める仕事がほとんどかな、うちの場合。

DBはクライアントが金持っていればOracle入れますが、
そうでもない場合はMySQLとかが多いです。
もちろん、Accessの場合も当然ありますけど。

>>126
いまのWebアプリの仕事はjほとんどそれ系じゃないかな
ブラウザだけで使えるようにしておけば、
クライアントにソフトをインストールする必要が無くなるから
保守、運用の手間もはぶけるだろうし

DBインターフェース部分を、DBMS側が提供する埋め込みSQLのライブラリを使って
書くことは、非常にリスキーで、かつ工数高になりますよね。
大規模なシステムでは4GL等を使用して効率をアップしていますが、これらの開発
ツールは非常に高価で、ちょっとしたシステムでは手が出せませんよね。
新人さんのいう、「顧客情報や在庫管理等」って規模にもよりますが、どのような
インターフェースを採用しているのが一般的なんでしょうかね。

とりあえず、このスレを生き甲斐にはしない方がヨかれ（ｗ

業務仕事はＤＢ関係ばかりですよ。
恐らく新人さんが想定するような仕事は
それがメインなのかな。

近頃の流行りはWeb系のもので画面はブラウザですが

私のメインはWindowsの普通のアプリでＤＢを見る仕事です。

客観的なお仕事の傾向は以下のリンクで調査してくれい。

某の宣伝みたいだけどそれは見なかった事にしてくれ
このサイトぐらいしかしらんのだ。
http://www.borland.co.jp/jbuilder/cases/
http://www.borland.co.jp/delphi/cases/
http://www.borland.co.jp/cppbuilder/cases/
こっちは某じゃない
http://www.layer-8.com/eanken/

あ、新人さんに念のため言うと某=Borland社の事です

>>131
ＰＧの仕事って系列に分けるとどんなもんなのかなぁ。
汎用機系、ゲーム系、ファーム系、Ｗｅｂ系、アプリ系…。
よく分からんけど、ＤＢの絡まない方がむしろ少ない気が。

自分はシステム→Ｗｅｂ屋の転職組ですが、パターンとして多いのが、
会員制サイトをPostgreSQL+Perl で組むってところです。
Ｗｅｂ系業務ってまだ予算あんまし組めないらしいからね…。

ひどく叱られるかと思ったのですが、暖かいレスありがとうございました。
>>127
具体的なDBMSまで書いていただき、ありがとうございます。参考になりました。
>>128
なるほどそうなのですか。
>>129
私も同じ事を聞いてみたいと思いました。
>>130
生きがいです。^^)
>>131
ありがとうございます。「Windowsの普通のアプリでＤＢを見る」、なるほど、
Webだけではないのですね。それから、リンクもありがとうございました。
こういうサイトを探していたのですが、なぜか見つけられないでいました。こ
れらを見て、自分はやっぱりアマチュアなんだなーと、ちょっとしみじみして
しまいましたが、本当に参考になりました。ちなみに、eAnkenでは、「外注不
可」というのが目に付きました。おもしろいですね。
（某=Borland社。お気遣いありがとうございます。知りませんでした。
　私はTurboC育ちです。^^）
>>132
131さんへのレスですが、参考になりました。

どうやら、Windows（スタンドアロン？）アプリもありますが、DB+WEBというの
が流行ということですね。あまり考えがないのですが、UNIX系ならPerl（CGI）
とか、Win系ならASPとかなんでしょうか。この辺でちょっと気になるのは、（ま
たまた素人考えですが）.NETですね。この間のMSのコンファレンスを見てきた人
の話では、やっぱり、「すごい勢い（MSさんが）」のようですね。私は、ASP
（.NETの前の）あたりで、「もうかんべんして」と一度泣きが入ったのですが、
進歩（？）に終わりはないのですね。

新人さんは106で言っているSEの資質を持っていると思われる。
良いSEになりそうですね。いつか一緒に仕事したいな。

DB+WEBが流行りというより、確かにニーズは多いけど、
できる人が限られてるわけね。
で、結局、大半の人がアクセスってわけYO！

>>135
まぁ、両方の知識がいるし。
予算もないから、一人で全部やる必要もあるし。

まぁ、DB+WEBやるのに、Javaをばかにしたり、
オープンソースコードは糞だ、と言ってる奴には
絶対に無理でしょうね。
だから、ここで言われただろう、お前は他に仕事する
場所なんかないんだYO!

>>134同意
>>137夏だから頭沸騰してるのか？

DB+Webだと
ASPも多いだろうけど
最近はJavaサーブレットが主ではないかな。
.NETはASPと一緒にこれを乗っ取る気でしょう。

Perlは使わないと思う。
最新だとPHP&PostageSQLだっけ？
そういうのもありうる。

>>135-136
ベンチャー請負仕事だけを想定してない？
もうちょっと広範囲で想定してみるのも
よくないかな。

>>134 （138さんも）
ありがとうございます。光栄の極みです。
しかし誉めていただくと、後でボロが出たときにがっかりされると
思うので、ちょっとおそろしいです。^^)私は、基本的にヘタレです。
>>135 >>136
なるほど、そうなのですか。それから、「業務レベルの信頼性」は
プロなら当たり前なのでしょうし、DBに限ったことではないと思い
ますが、やはりかなりシビアになるのでしょうね。それを一人でやる、
というとかなりつらそうです。
>>137
残念ながら、意味がよくわかりません。
>>138
Javaサーブレットですか。勉強してみます。
少しだけならJavaを使うのですが、実は「遅い」と感じます。（勘違
いならすみません。）それをサーバーサイドに使うというのは、とても
信じられなかったのです。でも、138さんの言うように、最近は主流な
のですね。
「PHP&PostageSQL」も、勉強してみます。私はDOS/Win育ちなのですが、
Linuxで仕事ができるなら、それもいいなーと思っています。ただ、こち
らは、本格的な素人です。

>ベンチャー請負仕事だけを想定してない？
>もうちょっと広範囲で想定してみるのも
>よくないかな。
と言うと、たとえば、他にどのようなものがあるのでしょう。
ヒントだけでも挙げていただけると、うれしいです。m(__)m

ともかく、.NETも見てみようと思っています。ただ、ちょっとMSさんき
ついなーと思うのは、MSさんが（ほぼ）全世界の認証を一手に引き受け
ようという構想です。（ヘイルストームでしたっけ？？？）
非Winなら、範囲外なのでしょうが。
それからWinXPがデフォルトでJavaサポートをしないとかで、ちょっと
波紋が広がっている様子ですね。

他のスレもよく見ているのですが、2chの人はあまり顔文字を使わ
ないのでしょうか？（ものすごく大きな顔文字には、しきりに感心
していますが。）もし、文化を乱していたらすみません。ご指摘
ください。

>>139
Javaのどういうところが遅いのかをよく考えてみた方が良いよ。
Javaが遅いのはVMの起動とメモリ使用量の大きいオブジェクトの生成。
コードの実行速度はJITやHotSpotという技術が確立した現在、
そんなに遅くない。
それに、サーブレット・エンジンはVMを起動したままマルチ
スレッドで動くので、むしろリクエスト毎にプロセスをfork
するCGIよりも速い。また、セッション管理はサーブレット・
エンジンがよきに計らってくれるのもお手軽で良い。

商用の開発環境がかなり整っていて、開発期間を短縮できる
というのもサーバサイドJavaが最近よく使われる大きな要因
の一つだと思うが、開発環境が整っている背景にはJava に
Beans があり、JSP があるからということは言えるだろう。

Javaは SolarisでもLinuxでもWindowsでも動き、Webサーバ
もあれこれ選べるが、一方ASPは事実上WindowsのIISでしか
動かない。大規模ECサイトを IIS で構築するなんて悪夢で
しかない。

ここにレス書いてる人に、マイコン組み込み系の人っている？
やっぱり、マイコン組み込み系の人って少ないの？

サーブレットは遅くありません。
いわゆるJavaの遅いちう固定観念とは別な所にあります。

>>140氏が答えてくれてるとおり。

>大規模ECサイトを IIS で構築するなんて悪夢でしかない。
そうなん？
最近はちょくちょくあるような気がするが....

＠ITというサイトを見つけて読んでくれい。

> >ベンチャー請負仕事だけを想定してない？
> >もうちょっと広範囲で想定してみるのも
> と言うと、たとえば、他にどのようなものがあるのでしょう。

135-136さんがいわゆる業務単発web仕事の
事しか頭になかったみたいだから言っただけよ。
あんまり全部が全部にレスせんでくれ。初心者の悪い癖だ。

>>141
しらないけど、それはソフト屋さんじゃなくて
ハード屋さんになるからなあ。
あまりプログラムーとかプログラマーというこだわりが
2chに常駐するほどにはないんじゃないかな。

142が寒いことを書いたのでこのスレは終了しました
みなさん、ごくろうさまでした。
------------------しゅうりょう-------------------

Java遅くないです〜

http://cm.bell-labs.com/cm/cs/who/bwk/interps/pap.html

プロ＝仕事、のソース＝ぐちゃ、ぐちゃ　じゃないの？
納期に追われるから。。。

経験のある人が、趣味で作ったソースの方が、結構よかったりして。。。

>>141
お呼び？

>>142
> ハード屋さんになるからなあ。

ぉぃぉぃ…

>>140（>>142）
>Javaのどういうところが遅いのかをよく考えてみた方が良いよ。
なるほど、よくわかりました。
>>142
>あんまり全部が全部にレスせんでくれ。初心者の悪い癖だ。
わかりました。気を付けます。m(__)m
>>144
本当に面白い資料ありがとうございました。読んでみます。
（私は、決して「Javaは遅い」と断言したのではありません。
言われてみると、140さん、142さんの言うようにVMの起動時間
が少し気になっていたようです。そんなことも知らんのかと
言われればその通りなのですが。）
>>145
藤原博文さんの「Ｃプログラミング診断室」でしたっけ？プロ
の人のすごいコードというのも聞いたことはあります。でも、
例外なのでは？^^;)

Javaサーブレットは本腰を入れて勉強しようと思います。

>>148
サーブレットで何かサイトを立ち上げるとか

作りたいものが具体的じゃないなら
勉強できないと思うよ。

趣味じゃつらいんじゃないかな。
作れるものがものだけに。

>>145
ソースがぐちゃぐちゃ？
しっかりとスケジュールの線を引けば、んなことにはなりません。
つーか、業務によるだろうけど、大体期間におけるコーディングの割合って
３割ぐらいじゃねぇか？
テスト期間に比較したらまるで短いと思うのだが。

>>149
わかりました。何かよい例題を考えます。
>>150
なるほど。コーディングの割合が3割くらいというのは、おもしろい
お話でした。

>>150
テスト期間の名の元、設計からコーディングをこなさなければならないのは
日常ちゃメシごとなので、もう逝きます。

>>150
>しっかりとスケジュールの線を引けば、んなことにはなりません。
いい会社にお勤めですね。

私の記憶では
全体の75%はそんなスケジュール管理できない仕事でした。

>>152 >>153
3割という数字が出たときにも「なるほど」と思いましたが、また、
なるほどです。私自身の仕事は152さん153さんのものに近いかも
しれません。今は、学生に渡す課題用プログラムの期限が刻々と近
づいていてパニック寸前です。

>>150
確かに「製造」として線表上に割り振られている期間って２〜３割ぐらいでだね。
ただ、プロジェクトにもよるけど実際その後の試験工程に入った後、
振って沸いてくる仕様変更とともに、修正を加えまたテストをし・・・
で、気が付けば試験しながら仕様書を書いていたりとか順序が変になってたり。

>しっかりとスケジュールの線を引けば、んなことにはなりません。

だとしたら、プロジェクト管理ってもっと気楽な仕事なはず。

っていうか、ソースがグチャグチャであることと、
スケジュールの線表は関係無いんじゃないの？

仕変が発生した場合、納期を延ばす為に営業なりプロジェクトリーダーなりが
客先と交渉するのが重要だと思うのですが、それが出来ないのはまぁ不幸と
言いますか…（ここらへんは相手との関係にもよるでしょうけど）。

>>155
>っていうか、ソースがグチャグチャであることと、
>スケジュールの線表は関係無いんじゃないの？
なるほど、確かにそうですね。^^)

スケジュールの話が出ましたので、ちょっと、いかにもサンデープログラマな
質問を一つ。時間を決めてプログラムを書いていると、時間切れ（大抵は就寝
時刻）になっても終わらず、あと30分やればメドが付くけれど、今止めると
明日かなりの部分をやり直しだ．．．ということがよくあります。この場合、
あと30分やってメドが付くことはまれで、普通はドロヌマにはまります。この
ようなことは、プロの方では起こらないのでしょうか。プロである以上、時間
管理（というか健康管理？）は重要だと思うのですが、どのように管理してい
るものなのでしょう。何か気持ちをコントロールする方法とかあるのでしょう
か。それとも、そのような事態に陥らない工夫などがあるのでしょうか。まぬ
けな質問ですみません。

>>1
は、すでに誰からも相手にされてないことに気づいているのだろうか？

>>157

プログラムを書くことで、迷いは無いですよ。さっさと書いちゃって
単体デバッグまでは、迷うことなくできちゃいますよ。
プログラムコーディング時点で問題を発見することもありますが
そういうことは、まれで
　問題は、サブシステム間での結合テストを、した時に
いろいろと問題が発生する場合が多いです。

>>157

159とかぶっちゃいますが、あまり時間で考える
ってのはしないです（納期は別として）。
むしろ時間なんか気にせず書くだけ書くって
感じです。まさに、さっさって感じで。

恐いのはその段階ではなく、コーディング
終わってからの問題（↑かぶってます）と、
仕様変更です。おそらく、急な仕様変更が
一番プログラマ泣かせでは。

>>160

自己スレ。160がちょこっと元スレからずれた感じだったので補足。
一応、

>プロである以上、時間
>管理（というか健康管理？）は重要だと思うのですが、どのように管理してい
>るものなのでしょう。何か気持ちをコントロールする方法とかあるのでしょう
>か。それとも、そのような事態に陥らない工夫などがあるのでしょうか

に絡めた部分ではあるんですが。やはり金貰ってる以上、
クライアントの言い分はある程度は聞いてやらなければ
いけない訳ですし、かなり無茶苦茶な言い分の場合でも
どこがどう無茶苦茶か文書にして出す必要があったりと、
プログラマーの悩み要素はコーディング以外の部分に
集中してたりします。

さらに元スレからずれてきたか・・・

>>157
眠いときに無理にやってもロクな結果にならない。
納期に余裕がある時は当然明日。

＞あと30分やればメドが付くけれど、今止めると
＞明日かなりの部分をやり直しだ．．．

それはメドとは言わない気が。

一番怖いのは一見「再現性のないバグ」ってやつですね。

> 時間切れ（大抵は就寝
> 時刻）になっても終わらず、あと30分やればメドが付くけれど、今止めると
> 明日かなりの部分をやり直しだ．．．ということがよくあります。この場合、
> あと30分やってメドが付くことはまれで、普通はドロヌマにはまります。この
> ようなことは、プロの方では起こらないのでしょうか。プロ

起きます。だから思わず用も無いのに残業してしまいます。
本当はきっちり定時で切り上げる方が効率いい仕事のやり方なんだけどね。
(忙しくない場合)
下手に残業していると、上が仕様変更&仕様追加を口頭で逝ってくるし
非常にｳｻﾞインんだな、これが。

>>157
> あと30分やってメドが付くことはまれで、普通はドロヌマにはまります。この
> ようなことは、プロの方では起こらないのでしょうか。
多分、「あと30分やればメドが付く」というのは
「全てが上手くいった場合」30分ぐらいでメドが付くのではないでしょうか？

現実には全てが上手くいくことなどありえません。
小さなサンプルプログラムならば別ですが、
普通のプログラムならばコンパイルエラーは出ますし、
コンパイルエラーを取って実行してみると１回で思った通りに動くことなどまずないです。

> プロの方では起こらないのでしょうか。
起こります。が、経験を積むにつれて起こる確率は減ります。

> そのような事態に陥らない工夫などがあるのでしょうか。
基本ですが解りやすいプログラムを書くことです。
そうすればバグが発生しにくく、バグを発見しやすくなります。
次にバグが発生している箇所を絞り込むことです。
大抵のバグはある変数が自分の予想と違っていたり、
自分の予想していた処理を行わないことなので
トレース文やデバッガで追いかければ大抵は取れます。

プログラムは〜
「保守性」を考慮したつくりであることを念頭につくっておりますですじゃ。
もちろんほかならぬ現在作業中の自分のために。
ついでにいつか自分の後を引き継ぐ人のために。

ついでにプログラマの
117さんの言われている
「共通仕様やサブルーチンを先に作ってから本作業にかかります」
を実践するしないが、81さん言われるマル１とマル２を選別するのに
一役買うな〜と読んでて思いました。
論理と処理の分離は言語はなんであれ、プログラムを作るときにゃ必須だと思われるがゆえに。

>>165
サブルーチンは後回しじゃねーの？
負荷の軽い分は人に回せるし。

>>157
新人の頃はよくその「ドロヌマ」にハマリまくってました。
いま思い返すと、
・異常に長い関数
・深いネスト
・その他のテクニック不足
が原因だった思います。オブジェクト指向を取り入れてからは、随分
と改善したと記憶しております。

ちなみに私の周りでは、
「そんなの２、３日で出きるよ。」
と言ってのける人ほどはまっています（笑）。

大体が工数の見積もりっていいかげんですよね。
経験則以外の見積もり方法ってあるんですかね。
あれば、毎日定時に帰れるかも（笑）。

>>167
コーディングに入る前にどれだけまとめられるか、が全て。
資料を作らない、ではなく作れない、という人が多いのが悩み。

>>167
[経験則工数]＊１．５〜２で見積もる。
力量が分からない人間の場合はそれを２倍して割り当てる。

＞ちなみに私の周りでは、
＞「そんなの２、３日で出きるよ。」
＞と言ってのける人ほどはまっています（笑）。

よっぽどじゃないとそんなこと言わない。
１、２時間でできそうなことを２、３日というのは多々あるが。

>>169
そうそう、上の人がリスク管理と称して１．５とかする。
しかし、やっぱり破綻する。（笑）
上の人は考えた。納期がＰＧに見えてるからか？
で、納期を前倒しにスケジュールを引く。
でも、どーしても破綻する。

しょうもない質問にたくさんのレスありがとうございました。
>>159
実は、「結合テスト」なんて言葉は授業で教えているのですが、自分
で実感はありませんでした。こういう話をしていただくと（わずかで
も）「実感」というものが出てきます。ありがとうございます。「単
体デバッグまでは迷わない」とのこと、やはりさすがですね。
>>160 >>161
159さんと同様「さっさって感じ」はさすがですね。
>いけない訳ですし、かなり無茶苦茶な言い分の場合でも
>どこがどう無茶苦茶か文書にして出す必要があったりと、
>プログラマーの悩み要素はコーディング以外の部分に
>集中してたりします。
これも「実感」のこもった話です。何かの本に「好まなくても、プログ
ラマは文書作成のエキスパートにならざるを得ない」という言葉があり
ましたが、こういうことなのですね。
>>162
>それはメドとは言わない気が。
そうなんです。やってみたら、行数が3倍に増えていたりして。;;)
大馬鹿な話をすみません。
>一番怖いのは一見「再現性のないバグ」ってやつですね。
なるほど。これが出ると、スケジュールの予想が立たなくなりそうです
ね。

>>163
>起きます。だから思わず用も無いのに残業してしまいます。
力強いお言葉です。ありがとうございます。^^;)
「残業していると、仕様変更や仕様追加がある」というのも、実にリアル
な話ですね。（私の場合、残業していると、同僚がグチを言いに来ます。）
>>164
>多分、「あと30分やればメドが付く」というのは
>「全てが上手くいった場合」30分ぐらいでメドが付くのではないでしょうか？
まったくその通りです。;;)
>起こります。が、経験を積むにつれて起こる確率は減ります。
なるほど。何かわかったような気がしました。
>大抵のバグはある変数が自分の予想と違っていたり、
>自分の予想していた処理を行わないことなので
>トレース文やデバッガで追いかければ大抵は取れます。
具体的で参考になりました。ありがとうございます。
>>165
>プログラムは〜
>「保守性」を考慮したつくりであることを念頭につくっておりますですじゃ。
これも参考になるご意見です。
>117さんの言われている
>「共通仕様やサブルーチンを先に作ってから本作業にかかります」
>を実践するしないが、81さん言われるマル１とマル２を選別するのに
>一役買うな〜と読んでて思いました。
なるほどです。
>>166
>サブルーチンは後回しじゃねーの？
これもなるほどです。たぶん「サブルーチン」の意味にもよると思うので
すが、プログラムの部分を書く順番は、どうするのがよいのだろうと考え
させられました。
>>167
>新人の頃はよくその「ドロヌマ」にハマリまくってました。
164さんと同趣旨ですね。
（ちなみに私のハンドル名は「新人」ですね。年齢はいってますが。）
「オブジェクト指向で改善」という話も参考になりました。
>大体が工数の見積もりっていいかげんですよね。
>経験則以外の見積もり方法ってあるんですかね。
>あれば、毎日定時に帰れるかも（笑）。
うーん。なるほど。
>>168
>資料を作らない、ではなく作れない、という人が多いのが悩み。
自分のことのようです。^^;)
>>169
>[経験則工数]＊１．５〜２で見積もる。
>力量が分からない人間の場合はそれを２倍して割り当てる。
これも実践的なお話ですね。
>>170
169さんへのレスですので、私が何か言うべきではないのでしょう。
ただ、「納期前倒しのスケジュールで破綻」という意味はわかりませ
でした。何か意味深な話のようで、気になりました。
みなさま、ありがとうございます。

「教えて君」になるのはいけないと思っていますが、自己レス的な
意味合いも含めて．．．

実は、この2、3日「ドロヌマ」です。はまっている大きな理由は私が大馬
鹿ものだからなのですが、一つの理由には、発注元（教授）の意向で、あ
まり詳しくないVBを使っているせいもあると思っています。（もちろん、
VBが悪いのではなく、慣れていない私のせいです。）世の中には「VBでお
手軽GUIプログラミング」のような本は多数あって、それはそれで参考に
なるのですが、VBでちゃんと構造化プログラミングする方法論・指針など
が書いてあるものってあるのでしょうか。自分の経験でそれを割り出すの
にはかなり時間がかかりそうです。
それから、プロの方のお仕事では、「あまり詳しくない言語」で作る場合
もあるのでしょうか。

>>173
お前さ、VBのお手軽GUIモンは、入門書OR完全な遊び、だろ。
そんなんでプロとは言えないな。
もしか、そんな低レベルでYO、VBは使えないってう、知ったか
やってるんじゃないよな。
それは最低だぜ！

VB使い = 高卒並み
死んでください（わら

┐(´ー｀)┌

★☆★☆★★☆★☆★☆★☆★
☆　shige　　　　　　　　　　　　　 ☆
★ http://www.ruby-lang.org/　★
☆★☆★★☆★☆★☆★☆★☆

YO君は無視でお願いします

>>176
と言うより、お前が、シカトORからかわれてるんだよな。

>>167
ぶっちゃけて言えば経験則で見積もるしかない。
大切なのは「経験」をいかに正確に記録しておけるか。
勘だけだと、印象の強い部分しか覚えてないから失敗する。
体系的な見積もり方法としてはファンクションポイント法とその
拡張(フィーチャーポイント法など)が主流ではなかろうか。

>>新人氏
全部にレスつけなくてもいいってば。
変な煽りは虫しておきなね。

>プロの方のお仕事では、「あまり詳しくない言語」で作る場合
>もあるのでしょうか。
ある。でないと新しい言語なんて覚える事できないです。

生産効率は最初はすごく悪いんだけど
毎日くどくどコーディングしているから
1ヶ月くらいで、十分自在に使いこなせるようになるよ。

あと、見積もりの事なんだけど
最近は、見積もりはあくまでも見積もりとして

納期設定は、自分がおよそ出来るなーと思う時間の
倍は考えて報告します。(経験則は一応必要だけど)

上司は「もっと短く出来るだろう」と
不満そうですが、結局、何かの不具合を発見したり
仕様の修正がたびたびはいる事を思えば
必要以上な工数を見積もることは絶対に必要。

>>178
おれはなるべく上司やプロジェクト関係者に
毎日進捗をメールで報告するようにしている。
そうすると問題点があらわになって
作業効率もよいし、見積もり工数が不可能な事態に
なることも全員と意思疎通が出来るから
自分で納期を抱えこまずに
適切な対応が取れるようになりますね。

で、そのメールが証拠になったりもしたりする。
(自分だけの覚書は当然自分だけの保存メールにしたりもする)

>>165
方法のひとつとしてただしぃと思います。

>>173
VBもCもJAVAも言語ゆえに、表現特性があれども所詮は言葉。
「表現者しだいでなんとでもなる」
っちゅう事実があります。
これをふまえて。
プログラム作業は「何をどうしてどうするか？」を言語で翻訳する作業みたいもんですから、言語に向かう前にやらなきゃいけないことがありんす。
まず「自分の知ってる言葉(日本語でも英語でもスワヒリ語でも)で、作業手順を詳細にまとめとく」ざんす。
この際「フローチャート」でも「クラス図」でも「１から順に紙に書き出す」でもなんでもかまいまへん。
それつくったら、できたものみながらVBで翻訳していくよろし。

もし。
「わかんないからサンプルこぴって作り変えてみた〜」とかするのなら。
あとででもいいから上記の手続きやりましょう。練習です。(^-^)/

>>180
毎日文章を書いておくとあとでとりあえず役に立つよね。
ただ、量が多くなると目を通すのが大変になるのでアレだが。
進捗を書くと同時に、週一回は今後の見通しを書くようにすると
どのぐらいアレな状況になってるか把握できていい。

でも、毎日メールが書けるっていうことは、いい環境で働いて
るってことだよな。
「そんな報告するひまがあったらコード書かんかい、ｳﾞｫｹ」
っていうような勘違い上司だったらつづかないよね。

>>179
>上司は「もっと短く出来るだろう」と
>不満そうですが、結局、何かの不具合を発見したり
>仕様の修正がたびたびはいる事を思えば
>必要以上な工数を見積もることは絶対に必要。

アホ上司だな。
あとから工数が伸びることを考えたらよっぽどいいだろうに。

あげあしとりだが
>>179
>仕様の修正がたびたびはいる事を思えば
>必要以上な工数を見積もることは絶対に必要。
そういうのも踏まえて必要な工数というのでは。
どんな場合でも必要以上の工数は不要。

正確な見積もりを作るための手法はいろいろ提案されていて
それによって誤差の少ない見積もりを出せているところもある
わけだから。
もちろん、組織のレベルが低いうちは、実際に必要な見積もり
よりはるかに低い見積もりしか出せないことが多いから、割増
することが必要だということは身にしみてわかってるが。

いまはそれでいいと思うが、その考え方のままのし上がってい
くと、結局2chでネタにされる上司になるよ。

>>184
当然、ＦＰ法とかは勉強するに値すると思うが。

ただ、仕様変更に対して、更に発注元に追加工数
を請求できれば問題ないのだが、そうはならない場合も多いだろうし。

>>184
最初に仕様を聞いて
自分だけである程度「できるなー」と思う工数があるじゃない。
相手側のあいまいな仕様を全部こちらが勝手に変更可能として
考える工数。

で、それを作っていく段階で
仕様が不明瞭のものをあらわにして作っていくわけだけど
それでどんどん遅れるのね。
こっちが仕様をつっこんだら
相手(上司)が適当な返事しかしないし…
私に言われてから、ようやくあいまいな仕様を検討しだすし､､､
客の事を本当に考えてから仕様を決定しているとは思えないことも言い出す始末。

当然､そんな感じだから朝、実装したものを夕方から手直すなんて事
ザラなんだわ。あ、仕事のやり方が厨房だってのは自分でもわかってるよ。

でも、基本的にどうにもならないわな。

＞いまはそれでいいと思うが、その考え方のままのし上がってい
いや、やり方があるのなら思い立った時
今、直さないとダメだと思うので方法論を
少し教えてもらえないかな。

つーか。組織として変な所にいるので
もう転職するから、転職トークに利用させてもらいたいのだ。

見積もりを正確に見積もれる方法なんて確立してないと思う
少なくとも、私の周りや2chでもあまり聞いたことがないです。
FP法とかあるんですか？

言葉足らずですみませんでした。で、補足。

>で、納期を前倒しにスケジュールを引く。

一部のプログラマーは、ケツに火がつくまで「のほほぉ〜ん。」と仕事をしてい
ることが多いのです。まぁ、自分なりに進捗を管理しているつもりなのでしょう。
虚偽の進捗を報告されていた上司はたまったものではありません。開けてビックリ
玉手箱！！
で、上司は考えました。本当の納期は隠しておいて、早めのスケジュールを納期と
偽って仕事をさせよう。これなら火がついてもなんとかなるでしょ、と。

>>186
仕様から作業者が見積もりをださないといけないのがいろいろ問題ある。
話聞くと、見積もりがどうのより仕様を作れてないだけだよね。
仕様をちゃんと作るのにコストがかかるからどこまでちゃんと作るか
という以前の話のようだし。

見積もりの方法としては、FP(ファンクションポイント)法で落ち着いて
いると思う。学問的にはね。
現場に浸透してないというのはオブジェクト指向と一緒だけど。
どんな見積もり手法をやるにしてもFPを知っておいて損は無い。

ただ、結局見積もり手法以前に組織的にレベルが低いところが
多いので、ほんとに見積もりの誤差を減らすためには見積もり
手法より、組織改善、というかプロセス改善という考え方をと
り入れる必要がある。こっちも、定番としてはCMMという手法が
あるので、「プロセス改善」「CMM」というキーワードで資料を
探せばいいと思う。

とくにCMMは来年日本版CMMが取り入れられて、公共団体がソフト
ウェアを発注するときの指標にするということだから、転職トーク
にとりいれると吉。ただし、相手がなにも知らないかもしれないか
ら、その反応を見てこっちもそこに入るかどうかの判断材料に。

プロセス技法に関しては、「設計がうまくできない」「見積もりが
うまくできない」「バグが多い」というソフトウェアのいろいろな
問題を根本的に解決するためには、さまざまな要素が絡むので組織
としての能力を改善する必要があるということが大切。

>>188
ＣＭＭねぇ…、そういう観点でいくと日本の企業はまるでダメ（笑）。
海外だとレベル３以上が３００以上あるのに（インドと米軍向け
開発組織が大半）、日本だと僅か３つ。

組織のレベルを上げるというが、とりあえずＰＧの待遇を改善しな
ければムリでしょう。
出来る人間は「フリーの方が儲かる」と悟ってどんどん組織を抜けて
いくしね。

FP法
http://www.nesma.nl/japanese/earlyfpa.htm

FP法も精度を上げようとすると、まるで基本設計になってしまう。
あんまり規模がでかいと、FP法による見積りのための見積りが必
要になります（笑）。
まぁ、キングファイルに数＋冊の提案書よりはマシかな。

>>190
どこまでやるかだよね。
ただ、FP法を考慮しないでいい見積もりを作れることは少ないと。
画面単位でみつもりとかね。「３画面だからいくら」とか。
それよりは手抜きFP法のほうがはるかにいい。

ソフトウェアの見積もりの問題点のひとつは、見積もりの段階で
すでに知的生産物になることだね。
そんで、見積もりからコーディングの直前までは、作業の明確な
区別はないし。

VB等に関して、いろいろご助言ありがとうございました。本当に参考にな
りました。しかし、スレの本題はプロのみなさんの本格的議論になって
いる様子ですので、個別のレスは差し控えます。（というか、もうほとん
どはるか上空の話になっていますね。とても勉強になります。）

素人ながら思ったことは、191さんが言うように「見積もり自体が知的生産
物」でありながら、おそらくそれがコーディングの様な「はっきりした知的
労働」であることがうまく評価されていないのかなーということです。

数少ない尊敬できる上司の一人（元or現役Fortranプログラマ）は、ときど
き、遠い目をして、「見積もりが一番難しいんですよ」と言います。（「一
番」ということには異論があるかもしれませんが。）みなさんのお話を聞い
て、こういうことなのかと思いました。

>>188-189
どうもありがとう。調べてみる。

>>189
＞出来る人間は「フリーの方が儲かる」と悟ってどんどん組織を抜けて
＞いくしね。
確かに。
私も独立した方がいいかもとか考えて
手始めに派遣で給料上げようかなとか少し考えています。
派遣だと、スキルあれば給料アップ交渉がやりやすそうだ。
正社員だと買い殺されそうで…<<今の会社がたまたまそうなだけかもしれないが

>>157
>明日かなりの部分をやり直しだ．．．ということがよくあります。この場合、
あの時やらなければ良かった．．．という方が多々あります。

教訓：明日できる事なら今やってはいけない。

はっきり言おう、スキルや交渉能力がなければ、
独立しても失敗するから、正社員でいとこうね。

皆さぁ、大企業とかいうと、みんな凄い！と思っているようだけどね、
それは、間違いなんだよね。
大企業で優良な所でも、優秀な人は限られてるわけなんだよね、
ただ、その人たちがメチャメチャできて、一般社員もそこそこ
だから優良なんだよね。
そして、案外、メチャメチャできる優秀な人って高額なんだけど、
変わった経歴の人が多いんだよね。
まぁ、普通の人はめったに会わないだろうけど・・・

>>196
思ってないよ。

>>196
優秀なプログラマーが揃ってればサービスパックも少なくて済むんだけどね

>>198
アホが一人いた。
まぁ、これはプログラミングの問題じゃないけど。

>>196

むしろ、大企業の人より独立した方が優秀って見られがち。
まぁ、その例が多数ではあるんだろうが、実際には >>195
の書くように交渉力（あと人脈）が全てみたいなところ
あるんで、そうでも無い人が豊富な人脈と口八丁手八丁で
のさばってるってのも多いね。

>>193=186
いまは出先で手元に無いが、戻ったら参考文献あげとく。
スレがのこってたらね。

組織であることの特性は社員じゃないと体験できないから、勉強して
実感した後でやめるのがおすすめ。
いまの状況を考慮してないけどね。我慢できないなら、もうすこしがまん
しな。勉強して具体的な欠点がわかるまでね。

>>194
砂漠民族イスラム系のことわざだね。
「今日やるべきことをやりなさい」
ということを続けないとさぼるためのいいわけにする人がおおいね。
そもそも、「どんなに準備しても砂嵐で台無し」という文化で有効なことわざ。
気候温暖な農耕国日本では理解しにくいことわざでもあるね。

中小企業の場合、正社員としての給料と大体似たようなスキルでフリーの
人間が稼ぐ額を聞くと、失意に陥ることが多い。
大体、額面で月給２６万だとしても、２６＊（１２＋４）で４１６万。
６００〜７００は欲しいよなぁ。。。（一人月６０万で７２０万）
仕事がなくなればアウトだけど。

>>201
>「どんなに準備しても砂嵐で台無し」という文化で有効なことわざ。
じゃあ「どんなに準備しても仕様変更で台無し」という文化なら有効だね？

>>203
同意。
流した涙の分だけ強くなれ。

>教訓：明日できる事なら今やってはいけない。
私は狐狸庵先生のお言葉だと信じてきました。
「今日やるべきことをやりなさい」と続けるとトヨタかJITの思想か
と思いましたが、「仕様変更で台無し」の話の迫力に吹き飛ばされました。

そもそも、「仕様変更」はなぜ起こるのでしょうか。「SEがアホだから」
と言ってしまえばそれまでですが、これだけ話題になるのなら、やはり構
造的な問題があるのではないでしょうか。
たとえば．．．私がプログラミングでつまった話をアップしたときに「は
じめに、作業手順を詳細にまとめとく」という話をいただきました。まっ
たくその通りのお話で反論ではないのですが、私の場合、ある程度コーデ
ィングをしてからの方が、「細部のイメージがはっきりしてくる」という
ことがあるのです。（細部のイメージが湧いたところで、「詳細」をすべ
て考え直せばよいと思うのですが、それは私個人の問題なので、ここでは
置いておいて．．．）たとえば、PGに仕様書を出すSE自身が、PGの進捗を
見ながら、細部がわかってくる、その結果が仕様変更になる．．．という
ようなことが起こるのではないでしょうか？それとも、本当に、脈絡のな
い仕様変更なのでしょうか。どなたか教えていただければ幸いです。

それから、201さん、私も参考文献期待してます。
転職・独立を考えているみなさま、やっぱり思いとどまったみなさま、
いろいろ教えていただいたものとして、応援しています。

>>205
＞たとえば、PGに仕様書を出すSE自身が、PGの進捗を
＞見ながら、細部がわかってくる、その結果が仕様変更になる

案件の規模にもよるのでしょうが、むしろ客先からの注文に答える
＝＞追加仕様＝＞仕様変更のパターンが多いような。

>>203
はげしくﾜﾗﾀ。
そうか、仕様変更はアラーのおぼしめしか。
インシュ・アラー by きんたろ

>>193
>>205
見積もりの参考書
「ソフトウェア機能性の計測」トッパン
。。。ファンクションポイントの本。出版社がなくなったから、手に入らないかも
「ソフトウェア開発の定量化手法」共立出版
。。。ソフトウェアにおける計測に関しての本。ぶあつい。重い。内容も重い。

CMM・プロセス改善の参考書
下に行くほど公式な感じで読みにくい。
「ソフトウェアテクノロジー８ ソフトウェアプロセス」共立出版
プロセス技術について簡単に網羅してある。
「ソフトウェアプロセスのトレンド」海文堂
。。。日本の実例(オムロン)がのってる。
「CMMによるプロセス改善入門」共立出版
。。。へんなたとえが多いのが萎えるが、実用的な尺度がおおい。
「成功するソフトウェア開発-CMMによるガイドライン」オーム社
。。。CMMの和訳。公式ではないので用語が変わっているかも。
。。。公式の和訳はソフトウェア技術者協会からでてるが入手しづらい。
「ソフトウェアプロセス成熟度の改善」日科技連
。。。CMMの基になった文献。

読んどけ
「デスマーチ」トッパン(ほかから復刻してるはず)
読み物としておもしろい。プロセスの章もあり、よみやすい。
「人月の神話」アジソン・ウェスレイ
人月という単位の問題点について書かれた、こういう話するときの必読書。

>>205
仕様変更は、仕様を「やりたいこと」の形式化と考えるなら、「やりたいこと」
自体が変わってしまった場合と「やりたいこと」を正確に形式化できてなかった
場合がある。
多くの場合は後者。

また、前者でも、作ったものを見せたらお客さんの気が変わったというものは、
正確に言うと後者。「やりたいこと」を正確に掘り起こせず、「やりたいと言っ
てること」を仕様にしてしまった場合。
お客さんはシステムに関して素人で「やりたいこと」を正確に把握できることは
少ないので、「やりたいと言ってること」から「やりたいこと」を導き出す必要
がある。

前者の例としては、当初ひとつしかない事務所で使う予定だったが事業拡大で事
務所がふえて、各テーブルに「事務所ID」フィールドが増えたなど。
現実世界に変化が無いのに仕様が変わるのは、基本的に仕様作成のミス。

仕様作成に関与できないプログラマの場合は、やっぱりアラーのおぼしめしか。

人月の神話は>>94でガイシュツだった。
逝ってくる。

>>209
「運用で補ってください」と言い含めるのもＳＥの仕事（ｗ

>>211
運用も含めてソフトウェアだしね。

>>205
あなたが言う「仕様変更」とは？
文面を見る限り、プログラムの組み方や実装方法の変更を
言われていて実際の SE や PG がいう「仕様変更」と
ずれているように思います。

> PGに仕様書を出すSE自身が、PGの進捗を
> 見ながら、細部がわかってくる、その結果が仕様変更になる
この人は SE と呼べない気がしますし、もし居たら PG からの
突き上げが激しそう。
その結果が仕様変更。。。にならないでしょう。
なんらかのコード最適化のための変更はあるかもしれません。

>>209 が言われる「やりたいこと」をすべて導き出すというのは
理想ですが、現実的に大規模になればなるほど限られた時間内では
ほとんどの場合無理だと考えています。
XP にもありますが 「仕様変更は発生するもの」 として
受け止め、設計／開発しています。

>>213
もちろん「やりたいこと」をすてべ導き出すのは理想でしかありません。
時間的・人的・コスト的制約で、それが不可能な場合の方が多くあると思い
ます。
ただ、不特定多数への提言としては、まず理想を掲げて、「実際はね」とい
う流れにしないと「勘違い君」を生んでしまうことが多くあると思います。
仕様を完全に作成するのは無理だから、完全に作ろうとしても無駄だと。
実際にはどこまで仕様が決まってて、どこから決まってないのか決めるとい
うことも大切になります。

もちろん、「やりたいこと」が時々刻々かわっていくことや、「やりたいこ
と」を導き出す時間が無いことが多くあります。
XPでは個々の提案は参考にできるのですが、XP自体の適用範囲がせまいので
一般的には、仕様決定→設計→実装→テストなどの一通りの工程を少しずつ
数サイクル繰り返す「スパイラルモデル」というプロセスを適用することに
なると思います。
>>213さんのような前提で開発できるということは、良いプロセスで開発でき
ているということなので、うらやましいです。

ちなみにスパイラルモデルの参考文献は
「ソフトウェアプロセスの改善」共立出版
で、表紙がそのままスパイラルモデルな感じですが、難しい(少なくとも漏れ
にとっては)ので、>>208の「ソフトウェアプロセス」という本をお勧めしま
す。プロセス技法の本では大概簡単な説明があると思います。

なるべく、私のレスでこのスレを汚さないように、書き込みは
控えているのですが、前回書き込みの訂正（補足）です。
>>213
>あなたが言う「仕様変更」とは？
>文面を見る限り、プログラムの組み方や実装方法の変更を
>言われていて実際の SE や PG がいう「仕様変更」と
>ずれているように思います。
コーディングの話を例にしたので、確かにずれていたと思います。
（私の場合、作って動かし、動かして考え、作り直し．．．で
作業が進むのです。そのため、コーディングと「仕様決定」に
明確な区別がないわけです。本当にサンデーで、すみません。）
213さん、ご指摘ありがとうございます。

私が書いた「SEが途中でわかってくる細部」とは、コーディング
の中身ではなく、インターフェース（たぶん、GUI？）や動作速度
など、外から見た「細部」というつもりでした。
質問の趣旨は、SEも最初は完成品のイメージ（SEにとっては主に
外観、PGにとっては主に中身）がはっきりつかめておらず、PGの
進捗にともなって、PGとのやり取りで「イメージ」が現れ、それ
が「仕様変更」に．．．というパターンなのでしょうかというこ
とでした。
ただ、206さん、209さんのお話を読むと、イメージがはっきりし
ていないのは、お客さんのような気がしてきました。
まだ、文献を読んでいないので、申し訳ないのですが、お客さん
に関しては、「お客からSEへ要求」->「PGがそれらしく動くGUI部
分（電脳紙芝居？）を作成」->「それを見せてSEとお客の相談」
->「仕様の決定」などというプロセスで進むことはないのでしょ
うか。その後、お客さんが仕様変更をしたら、「責任」はお客さん
にあると思うのですが。（もちろん、よいお客ばかりではないの
でしょうが。）まだ、ずれている．．．なら、すみません。

208さん、214さん、文献紹介ありがとうございます。

>>213-215
簡潔に文章をまとめなさい。
そんな長文だれもよまない。

>>216
激しく同意。

それ以上に（場合にもよるが）、クライアント側に
専門用語ばかり使う奴はあほ！
SEは無理、一生プログラマやっとけ！

そうそう、やたらユーザーの前で
わけのわからない専門用語もどき使ってる会社はヤバイんだよね。
組織内部では別だけど。

>>217
>>218
そうなんだよね、そう言えば少し前、「ハーバード　ビジネス　レビュー」
誌の「リスク管理特集」で、そう言った論文あったんだよね。
俺は、読む前から知ってたけどね！

俺も株式投資をするとき、そう言った部分をかなり参考にしました。
おかげで大勝だったな。
>>218

生意気で中途半端な知識しかもっていないﾊﾞｶ若造が、専門用語を
並べて上司を説得。
↓
上司は、分からない事が恥ずかしくていえないので、とりあえずOK
をだす。

上司は、「お前の話は分からん！分かるようにいえないのか！」
というべきだが、普段から専門知識の不足に負い目を感じている
ので隠そうとする。
若造は、「相手が理解できるレベルで、簡潔に話す」という基本
を抑えていない糞ﾊﾞｶ。

いま派遣で働いているITベンチャー会社の会話は殆どこんな感じ
で進む。いい加減にして欲しいよ。聞いていてサブイボ出まくり。

>>215
案件が小規模（例えば一人で開発）ならば、

＞まだ、文献を読んでいないので、申し訳ないのですが、お客さん
＞に関しては、「お客からSEへ要求」->「PGがそれらしく動くGUI部
＞分（電脳紙芝居？）を作成」->「それを見せてSEとお客の相談」
＞->「仕様の決定」などというプロセスで進むことはないのでしょ
＞うか。

っていう手段もあり。機能制限のベータ版作って客に投げて、その
意見を反映させる。いわゆる、プロトタイプモデル。

>>216
＞生意気で中途半端な知識しかもっていないﾊﾞｶ若造が、専門用語を
＞並べて上司を説得。

ああ、俺やってるかも。
嫌いな上司とかの場合は特に（笑）。

>>221
(ﾟДﾟ)ﾊｧ?
だったら、あんたの知識でその若造を言い負かしてやればぁ？

>>215
「ちょっとずつ開発」とかスパイラルモデルとかも。
とりあえず、仕様を最初に一度だけ決めて開発を進めるプロセスはあまりよく
ないということになってる。

スパイラルモデルやプロトタイプモデルの欠点は、最初の段階で全体のコスト
がわかりにくいこと。

長文ですみません。m(__)m
私は一生プログラマでいたいと思います。（今はサンデープログラマですが。^^)
>>221
とてもおもしろいお話でした。
>上司は、分からない事が恥ずかしくていえないので、とりあえずOKをだす。
まず思うことは「本当に、それで企業が成り立つのでしょうか？」です。その上
司さんのわからないということを具体的に言っていただけると大変参考になるの
ですが。できましたらお願いします。
>>222 >>224
222さん、224さん、コメントありがとうございました。
これまでのお話をうかがっていると、PGさんの作業効率を著しく落としているの
は、「仕様変更」というものではないかと思いました。そこで、どうしてアラビ
アの砂嵐のような仕様変更が発生するのかがぜひ知りたいです。たとえば、
222さん224さんの言うプロトタイプモデルとかスパイラルモデルであるならば、
お客・SE・PGの間で了解があれば、本当の意味での「仕様変更」以外では問
題がほとんどなくなるように思うのですが、どうでしょうか。もしかすると「了
解」がうまく取れないということが問題なのでしょうか。（意志の疎通の問題？）
あるいは、問題が起こっているのは全然別の開発モデルを使っている場合でしょ
うか。222さんのご指摘（？）のように「規模が大きい」とか、224さんのご指摘
のように「全体コストの評価が難しい」などの理由で。
プロの方には、つまらない（自明？）話かもしれませんが、ぜひどなたか雰囲気
だけでも教えていただけると幸いです。
また、こう書くとしかられそうですが、PGにとってはとんでもない「仕様変更」
が、SEにとっては「変更」というほどの変更のつもりはないということや、PGさ
んの側に仕様の誤解があってそれを正されるということが「仕様変更」に見える
などということはないのでしょうか。（本当に失礼な質問で、すみません。すべ
ての可能性を考えてみたいので．．．）

>>225
仕様変更＝スケジュールが伸びる、ってわけじゃないので。
納期も延びて、工数でお金もとれたら、それこそ最善なのでしょうが。
（でもこっちのいい値だなぁ）

>>225
プロトタイピングとかスパイラルモデルとかは、規模が大きいほど有効です。
なぜなら、たとえば５年かかるようなプロジェクトの場合、どんなに仕様を
はっきり決めても、開発期間中に社会情勢が変わってしまうことがざらです。
というわけで、大規模開発ほど、途中で仕様の確認ができるような開発モデ
ルが求められるわけです。

じゃあなんで仕様変更の嵐がやってくるかということなんですが、多くのソ
フトウェア開発組織が、「開発モデル」という考え方があること自体を知ら
ないので、「仕様決めて設計してコーディングして納品」という流れでしか
作業できないです。
また、そういう組織は「仕様の決め方」「設計のしかた」なども知らないこ
とが多いからさらに「だめだめ」になるということがあります。

なぜか「コーディング」についてはみんなマニアックな知識を駆使するんで
すが。

>>225

要するに、クライアント（金出す側）も人間って事です。
専門の仕事は専門家に任せようと、こちらの仕様書にOKを
一度は出したものの、実際に出来あがった途中版を見ているうちに、
「ここは、こうの方が良いんじゃないかな？」
「これは、こうじゃないのが変だよね？」
と、自分の主観で物事を見てしまうため、急遽
それに対応しなければいけないってのが多いです。
もちろん、その主観が正しいときもあれば、明らかに
間違ってるときもある訳ですが。

しかも、この主観が見る人々で変わることが以上に多く、
その仕事のクライアント側の担当者の要望によって
仕様変更したにも関わらず、リリース間近になって
そこの社長が「こんなん駄目だろ？」っていったことに
よって初期の仕様に戻したりなんてのもあります。

もちろん、こっちとしては「でも、御社担当の○○さんの
要望ですが？」なんて反論しても、当の担当はしらばっくれるし、
社長は社長で「自分の会社のミスをうちの社員のせいにすうのか？」
なんていきまくし、こんな状況じゃ証拠の仕様書なんか
糞の役にもたたないです。

>>228
その会社ってかなりDQNなんじゃ。。。

>>228
とりあえず通話記録でも取ったら？

Cool:Plexで全て解決（藁

営業が客先に押しきられちゃうんだろうなぁ。
ってことで営業と開発の仲が悪いと。

>>232
今月売上伸びてないからこんな仕事取ってきたYO
っていわれるんだろうね。
売上にはなるが、利益にはならんぞ！

>>228
議事録取ってないの？
言質とってハンコ押してもらうのは基本だと思うな。
方法はともかく客が仕様変更を発生させた場合、責任の所在を
逐一はっきりさせておかないと話がぐちゃぐちゃになるよ。
特に納期前とか。

日経コンピュータ7/30の坂本さんのCMMについての記事age！

少し「プロのプログラム」からずれたかもしれませんが、とても面白いの
で．．．もう少し、お話を聞かせていただきたいです。
>>226 >>228
お客の事情で仕様変更があった場合、すでに書いていて捨てることになる
コードにもお金を払ってもらい、さらに、納期を延期するのは当然だと思
っていたのですが、そうでもないようですね。228さんの話では、その前に、
誰の責任かもはっきりしないようですね。後の書き込みで、「信じられな
い」というような意味の反応が多いですが、私にはリアルな感じがしまし
た。ソフト開発ではないのですが、うちの大学で組んでいるLANには、本学
職員（他社から引き抜いてきた技術者で教員ではない）であるLAN管理者と
納入業者（ハード・ソフトの納入と設定をする業者）がいるのですが、よ
く「言った言わない」でもめているような気がします。にもかかわらず、
どちらも、正式な文書を作ることはまれなのです。（お互いのメモが頼り。）
LAN管理者も業者をどなれば気が済むようで、業者（営業の人だと思います）
も10のうち9くらいは謝罪と言い訳で対応し、残り1で「たしかそれは契約内
容ではないのでは」と言うだけです。どちらも、本気で「契約内容」を争う
気はないように見えます。（228さんの話とは違うかもしれませんが。）
契約（これも砂漠の民の発明？）をしっかりしないのが、ある意味、これ
までの日本の強みであったように思うのですが、砂嵐吹きすさぶ業界では、
はっきり弱みになっているのではないでしょうか。それとも、他のみなさん
のところは、しっかりされているのでしょうか。

>>227
>プロトタイピングとかスパイラルモデルとかは、規模が大きいほど有効です。
なるほど。ありがとうございます。
>「開発モデル」という考え方があること自体を知らない
これもすごい話ですね。しかし、とても興味があります。

CMMおもしろそうですね。

もしかしたらうちの会社が特別なのかも知れません・・・

通話記録、相手側認証ハンコなどは当然のように貰ってはいます。
ただ、それを証拠として出しても、「あんたとこはデジタルのプロだから、
そんなんも改変してるんちゃうの？」とのお言葉を頂きます。

裁判になったら勝てるのかも知れませんが、裁判で勝つまでの
労力で人件費つかうより、相手の無理な要望を聞いて仕様を
直すほうが、会社的にも儲かることが多いため、泣き寝入りみたいな
状態になってる可能性はあります。

でも、正直仕事なんです。はっきりいって、クライントに
対して訴えを起こす（それがいくら正当であったとしても）、
ソフト会社に、誰が仕事を頼むでしょうか？

次はうちが訴えられるんじゃないかと、二の足を踏むのが
オチです。だったら、無茶な言い分でも聞いて、作らざるを負えません。

はっきりって、クライアントの無茶な言い分をきかずすごせるのは
物凄い有難い環境にいるのではって気もします。

>>237
>「あんたとこはデジタルのプロだから、そんなんも改変してるんちゃうの？」とのお言葉を頂きます。

228=237の会社じゃなくて、「相手側」が相当DQNなんじゃないでしょうか？

>でも、正直仕事なんです。はっきりいって、クライントに
>対して訴えを起こす（それがいくら正当であったとしても）、
>ソフト会社に、誰が仕事を頼むでしょうか？

ソフト会社に大きな問題がなければ、むしろしっかりした仕事をするという評価を得られるかもしれません。
とりあえず、「改変してるんちゃうの？」っていうところと仕事する必要はないと思います。
ビジネスの付き合いもなにもできないでしょう。あと、そういうこというところは、自分でできる改変をやっているともとれます。

>>236
CMMはそろそろ普通の雑誌に出てきて、これからどんどん日本で話題になりそうなので、とても素人目におもしろいネタです。
ソフトウェアシンポジウムとかで、「プロセス技法」はよく見るけど「オブジェクト指向」のセッションはなくなってたりするのは興味深い。
とりあえず、いろいろなソフトウェア会社をみて、「ソフトウェア」に関する興味がないというのが率直な感想。
プログラムのレベルの話はいろいろ聞くんだけどね。

sage

>>237
>「あんたとこはデジタルのプロだから、そんなんも改変してるんちゃうの？」
これで泣き寝入ったら、「改変してます」って認めてることになる
どう考えてもデメリットの方が多きいぞ

そのクライアントと心中する気ならなにも言わんけどね

>>237
>>238
>>241
うーん。私も237さんの相手の会社はひどいと思います。ただ、「訴訟」な
どが難しいというのもわかるような気がします。（私自身、この年になると
裁判でギタギタにしてやりたい相手が何人かいますが、やはりこちらのコス
トを考えると．．．というのはあります。）しかし、これはもうPGの問題と
いうより、237さんの会社の社長さんの判断ですよね。できるだけ、けんか
にならずに、実を取る方法を考えたいですが。昨日から、グルグル考えてい
ますが、あまりよいアイデアは浮かびません（素人に浮かぶようなものでは
ないのでしょうが）。もちろん、基本的には238さん、241さんのおっしゃる
ように、毅然とした態度を取れればそれがよいと思うのですが。業界のため
にも。
業界全体で、そういう非道すぎるお客はなんとかできないものでしょうかね。
ブラックリストとか。（もしかしてそれは違法？）
背景としては、「ソフト開発の社会的な評価が不当に低い」ということが問
題のように感じます。
>>239
おもしろい話題提供ありがとうございます。めちゃくちゃなお客とのやり取
りではなく、純粋に「プロセス技法」を駆使して開発できると楽しいでしょ
うね。（それとも、めちゃくちゃなお客を想定しても有効な「技法」？）
ちょっと古いネタで、そういう「技法」かどうかわかりません（これから勉
強します）が、180さんの「毎日メール」は単純ですが、よい方法のひとつだ
と思います。182さんの言うように「いい環境」でないと実現できないかもし
れませんが。（それと毎日メールを書ける180さんもかなりのパワー持ち？）
ちなみに、本屋で見つけたXPの本はとても薄い本でした。（ピアソン？）
みなさんの言っているのはあれなのでしょうか。

まったく誰も気にしていないと思いますが、私のVBプログラム、ひっそり完
成しました。（バグはありそうですが。）ありがとうございます。

>>242
>ちなみに、本屋で見つけたXPの本はとても薄い本でした。（ピアソン？）
>みなさんの言っているのはあれなのでしょうか。
あれです。
白いのとみどりっちいのの２冊あります。

たぶん180を書いたのは俺です。
良い環境を自分で生み出そうとして「毎日メール」して
相手(上司とか客とか)にも責任をとってもらおうとしたんです。
口約束では、仕様変更の責任があいまいになってしまいます。
そうすると無駄なパワー使いますよ。

他の余計な事で頭を悩ますことが嫌なので
パワーを「毎日メールに」配分しただけですよ。

あと、2chに連日書き込むのとそう大差無いパワーでしょ（ｗ

>>243
ありがとうございます。前回見つけたのは「みどりっちい」のでした。^^)
今日、別の本屋で白いのも見つけました。薄くても評判のよい本という
のは、何か期待できますね。
>>244
レスありがとうございます。
>相手(上司とか客とか)にも責任をとってもらおうとしたんです。
お客にも進捗メールを出しているのですか。驚きました。
これはとてもよい方法だと思いました。（自分の進捗に対してしっか
り「責任」を持つことと上司・お客の「理解」の両方が必要ですね。）
>あと、2chに連日書き込むのとそう大差無いパワーでしょ（ｗ
これは私？（それとも他の方？）私には2chは、もう「生きがい」です。
でも、age続けてよいものかどうか、悩むこともあります。

>>245
ねたふりがうまければ誰も文句ないです。

ここで聞くのもいいけど
他のスレ見て面白いことを吸収していくのもいいんじゃないのかな。

>>245
「起動戦士」スレより全然まとも。
XPの書籍、もし図書館に「ジャバワールド」があれば、2001年1月号に特集があります。
これでXP知った人も多いんじゃないかな。

>>246
そうですね。いろいろおもしろいスレがあるので、勉強させてもらいます。
>>247
たしか「ジャバワールド」は、図書館にはないのですが、探してみます。

>>248
都会にすんでれば、バックナンバーがある本屋さんがあるかも

>>246
ここのやり口を下手に吸収して、使ったが為に「廃人」
になった奴も多いがな。

>>1
LSI-C86 作者の森様のソースを見たことある？
確か、フリーのやつにも cpp のソースがついてたハズ。

>>249
都会．．．それは「市」と呼ばれるところ。「字」を「あざ」と読むこと
なんか知らない人々の住処．．．ですね。;;)私はそんな都会に住んでい
ないのですが、バックナンバーは、なんとか探してみます。
（せめて電車が1時間に2本来ますように。ナムナム。モナー地蔵様。）
>>250
1日3時間以上2ch（の仕事に関係無いところ）を見ていると、さすがに自
己嫌悪になります。

>>252
きちんと働きなさい。

とは言っても他モジュールのテスト待ちのＰＧは似たような状況
だったりする。

トップページがサイト転送時、転送なれないんだけど、わかる人いたら教えてください.ホームページビルダーです.

>>254
板違い。web制作板にもマルチポストしてるみたいだからそっちで聞いてくれ。

>>253
テスト待ちは１時間なのに２時間以上2ch見たりするわけだ。

下がってしまいましたが、また、仕様変更について、質問させてください。
あれから、「お客からくる突然の仕様変更」とはどのようなものか考え続け
ています。まず、考えられるのは、「アルゴリズムの変更」などではなく、
「インターフェース（それもたぶんGUI）の変更」ではないかと思います。
そうだとすると、
　１．ボタンなどコントロールの位置の変更
　２．コントロールの削除や追加
が考えられます。プログラミング初心者が要求してくる「変更」というと、
私にはこのようなものが思い浮かんでしまうのです。実際こういうものなの
でしょうか。これらは、アルゴリズムとインターフェースを分けるようにプ
ログラムを書くことで、ある程度は対処できるでしょうか。（もちろん、楽
だということではありませんが。）あるいは「DBのインターフェース」のよ
うに、仕事の大部分がそもそも「インターフェース作成」なら、やはり「仕
様変更」は「全面書き直し」を意味することになりそうですが、そういうこ
となのでしょうか。あるいは
　３．「設計」そのものが変更
のようなことがあるのでしょうか。例は思いつかないのですが、当てずっぽ
うで、たとえば、「変数Aと変数Bの相関をグラフ表示し、変数Cは単独で表
示せよ」という仕様だったのが、「変数Aと変数Cの相関をグラフ表示し．．
．」になるとか。
あまり外に出せる話ではないと思いますが、どなたか教えていただけない
でしょうか。くだらんこと聞くな、という反応が大多数なら下げます。

>>257
そんな明確なもんだったら苦労しないよ。
もうちっと大規模でかつ曖昧なの。

>>257
たとえば、研修所の講師・受講者管理システムなんかだと、こういう事
例があります。

ギャランティ制度を導入し、最初の数回の研修で受講者が「イマイチ」
と思ったらキャンセルできるようにしたい。このとき、受講者には事前
に支払っていた研修料金を返金すること。

→返金処理を実現するため、会計のフローを見直し。仮受注やら入金確
　定やらの処理を追加するため、データベースの設計から手を入れた。

お客様からの仕様変更というのは、あくまで「ユーザ」の観点から出さ
れます。変数ＡとかＢといった「プログラム内部」の情報を前提に考え
るのでは、順番が逆。

>>257
やっぱりいろんな営業所で使いたいから、選択するボタン置いといて。
すぐ終わるでしょ？

みたいなの。
確かにインターフェイスとしてはそこだけ変わる。
でも、データに「営業所フィールド」追加して、*すべての処理に*営業所判断の
処理が追加になる。

>>260
>やっぱりいろんな営業所で使いたいから、選択するボタン置いといて。
>すぐ終わるでしょ？

それが終わった後に
あ、選択するボタンが必要な営業所と必要のない営業所があるから
Iniファイルの設定で表示非表示を切り替えれるようにしておいて。
営業所の規模によっても必要なデータが変わるから
その処理もいれておいてね。

となり、データそのものについて
営業所規模フィールドも増える事になったりして。

みなさま、レスありがとうございます。（もう何もないかと思っていました。）
>>258
なるほど。なんとなく雰囲気は伝わりました。^^)
>>259
とても参考になりました。「会計のフローを見直し」というのは、PGの問題ではなく、
お客の会社のシステムの問題のような気がします。PGにコーディングさせながらこれ
を変更する．．．というのであれば、たまりませんね。
>変数ＡとかＢといった「プログラム内部」の情報を前提に
書き方が変でしたが、「変数AとかB」とかは、「○○営業所の売り上げ」とか「8月
の気温」などといった、ユーザーに意味のある「値」というつもりでした。m(__)m
>>260
なんかとてもわかったような気がしました。（早飲み込みはいけないと思いますが。）
むしろGUIの変更はわずかで、処理内容が大幅に拡張されているのですね。この場合、
実質的には、「仕様変更（その厳密な意味は知りませんが）」というより、「アプリ
の拡張」だと思います。お客さんに「営業所の数だけアプリを開発するようなものな
の（もちろん言い過ぎですが）で、料金は営業所数を掛けたもの．．．とまでいかな
くても、かなり上乗せしていただかいないと．．．」なんて言えないものでしょうか。

結局、（当然と言えば当然なのですが、）インターフェース部分のクリアな仕様変更
などではなく、アプリケーションの中身の変更や拡張を言い渡されることが多いとい
うことなのですね。私は実は、プログラマがある程度「変更」を予想し、それに対処
できるようなコーディングをするのがよいのだろうかと思っていたのですが、上のよ
うな話なら、（PG-SE制度がうまく行っているなら、）SEさんがきちんとお客さんと
話し合うべきことであって、コーディングレベルで対応するのはかなりきついですね。
（「大きな書き直しや大きな拡張をなしに済ませるのはきつい」という意味です。）
みなさま、ありがとうございます。勉強になりました。

>>262
みんな、それは仕様変更だ金払えやｺﾞﾙｧということが腹にたまってただけ
と思われ。

>>261
私のレスと入れ違いのようでした。とてもリアルで（261さん、文章の才が
あると思います^^）、雰囲気までわかりました。ありがとうございます。
お客は意図的に「小出し」にするのだろうか、と思ってしまいました。
>>263
と、言うことは、「変更」に対して、お金はとれない（とりにくい）ものな
のですね。そもそも「変更」に対して、損料まで含めて払ってもらえれば、
「仕事をいただき、ありがとうございます」とも言えるわけですよね。（楽
しい仕事かどうかは別にして。）

>>264
「とれない」というより「くれない」の方が近いかな。
そう、お金払ってくれるなら、というか、それだけの労力を認めてくれるなら
仕様変更で文句は言わない。

>>1

俺が実際に、学生連中に講義してやろうか？
俺（高卒）

PGやSE志望の学生に読ませたいスレだね〜
とくにSE志望って言ってる学生かな。

>>264
> お客は意図的に「小出し」にするのだろうか
必ずしも、最初から明確にゴールが見えているとは限りませんから。システム
が組みあがってくるにつれて、自分が本当に必要としていることが見えてきた
り、既存の業務と連携できそうだと気づくこともあります。

構築するシステムは、あくまでお客様の目的を達成するための道具に過ぎませ
ん。どんなに堅牢で高機能なシステムが出来ても、それでお客様の目標が達成
できなければ無意味です。昔は、最初の段階で仕様を決めて設計→実装と一直
線でいくウォーターフォールモデルと言われる開発手法が主流でしたが、今は
上のような理由で、徐々にシステムを拡張できる仕様変更の可能性を織り込ん
だ開発モデルが流行っています。

というわけで仕様を切る SE は、プログラミングだけでなく業務に詳しくない
と勤まりません。技術力はあっても業務知識が足りない SE が切った仕様は、
後で大きな変更が入ったりします。（技術力のない SE は論外です、多いけど）

>>268
ＳＥに必要なのは技術力よりむしろ業務知識かもしれん。
いいこと言った！

>>265
そうなのですか。その辺に、大きな問題があるようですね。
>>266
専門卒や短大卒の非常勤講師はかなりいます。学歴に関係無く、話していただける
ことがあるなら、お願いしたいところです。（私の素性は書けませんが。^^;）
>>268
おもしろい話をありがとうございます。268さん（たぶん261さんや265さんとは別
の方ですよね）のところでは、開発プロセスがうまく行っているようですね。スパ
イラルモデルのようなものかと思います。ここで、少し疑問なのは、スパイラルに
なって、いろいろな「変更」が起こった場合、料金はどうなるのだろうということ
です。最初から数回の「変更」（実際には、スパイラルの場合、「変更」ではなく
作業の一つだと思えますが）が、料金に折り込み済みなのでしょうか？
>必ずしも、最初から明確にゴールが見えているとは限りませんから。システム
>が組みあがってくるにつれて、自分が本当に必要としていることが見えてきた
>り、既存の業務と連携できそうだと気づくこともあります。
このこと自身は大変もっともな話だと思うのですが、PGさんもこのプロセスに巻き
込まれるとしたら、「納得できる開発の全体像の説明／尊敬／報酬」が必要かと思
います。268さんの会社ではうまく行っているのでしょうか？265さんのレスなどに
ついてはどう思われるでしょうか？（265さんにも268さんにも）とても失礼な質問
かもしれず、申し訳ありません。しかし、もし、よろしければコメントをいただけ
ないでしょうか。
また、（あまり詮索するのはよくないと思いますが、）268さんはもしかしてSEさん
ではないかと思うのですが、いかがでしょうか？もし、そうならSEさんの立場から、
「PGさんたちに言いたいこと」とかあるでしょうか。質問ばかりですみません。

PG達に一言:
葉っぱだけ見るな! (森を見てくれ!)

>>271
ＳＥ達に一言
森の出口だけ見るな！(森全体をみてくれ！）

クライアント達に一言
こんな葉っぱが欲しいっていう要求するな！（こんな森が欲しいって言ってくれ！）

>>271 >>272
うーん。
　A．業務の全体を把握していないPGがいる。
　B．業務の全体を把握していないSEがいる。
　C．PGとSEのそれぞれが考える「業務の全体」が、実は、本当の「全体」ではない。
の3つの可能性がありますが、これまでの議論から考えると、ケースバイケースで、
この3つがまぜこぜになっている．．．ということでしょうか。とてもややこしいで
すが、論点は見えてきたような気がします。
>>267
私という素人相手によくプロの方が付き合ってくれていると思います。素人の恥知ら
ずでさらに言うと、開発会社の「偉いさん」やそのお客さん達に読んでいただきたい
ように思います。アホウと言われると思いますが、ソフトウエアの開発は、今後の日
本全体の（物質的）裕福度に大きくかかわると思っています。「みんなそろって貧乏
になりたくなければ、IT産業をちゃんと育てようよ」というのが私の主張です。

このスレの「見出し」とずれてきたかもしれませんが、感想です。
2chを見ていると、ときどきPGを「デジタル土方」と言っているのが目に付きます。
たとえば、以前に学生のバイトの話で出てきたように、「（精密な）フローチャート
をコードに翻訳するだけ」なら、そのような仕事と言えるかもしれません。そういう
仕事もあるでしょうし、それを悪く言うつもりもないのですが、それだけがPGの仕事
とは思えません。実際、現実にいつも、そういうフローチャートが存在するとは思え
ませんし、存在するなら、それを書く人もPGであって、その仕事は単純作業ではない
わけですよね。（そもそも、すべてがフローチャートで書けるかという問題もあると
思います。）
私は、前にも書きましたが、PGはより「匠」に近いものだと思っています。ただ、伝
統技術の場合、あまり変化がなく、年を取るにつれ「名人」になっていく人が多い（？）
のに対し、PGの場合、新しい技術がいつも開発され続け、その流れの中に身を置かな
ければならないという意味で、本当の「匠」とはかなり違うわけですよね。（PGの人
間国宝なんかがいると楽しいですが、ちょっと考えられないですよね。）今までの話
から推測される（非PGの）SEの仕事は、PGのものとはかなり異なっていて、そもそも
メンタリティが大きく違うように思えます。個人的には「SEが上司でPGが部下」とい
うこと自身に賛成できないのですが、それは制度として認めるとするならば、上司で
あるSEの側にPG（プログラムではなくプログラマ）を理解する責任があるような気が
します。もちろん、そういう優秀なSEさんが多数（このスレにも）いらっしゃること
は見て取れます。一般論として、です。なんか意味不明の話ですみません。

>「（精密な）フローチャートをコードに翻訳するだけ」
コボラー＝コーダーと言い、PGではありません。

>優秀なSEさんが多数
請負ソフトという未来が無い業種にSEが居るだけです。
SEは不用です。仕様を理解せずPGは出来ません。理解してないのはコーダー。

SEの実態
http://mentai.2ch.net/prog/kako/970/970681608.html

>>274
プログラムの処理にフローチャートを使うのは、現状に合わないので使われてません。
コーディング不可能な矢印が書けてしまうからです。

あと、そのレベルの図を書くならコーディングした方が速いというのもあります。
レベルの話で言えば、フローチャートは、左官にたとえるなら、ここから塗り始めて
ここまで塗ったら「こて板」に土とって、ここはへこんでるから多めに土盛ってという程
度の指示になります。

要するに、プログラマの仕事は、壁の広さとでこぼこ具合が違う程度の繰り返し作業が
実は多いのです。
もちろん姫路城の白壁を塗るような左官職人がいるように、「匠」のようなPGもいます。
実行環境に制限の多い分野では、そんなPGも必要です。

また、新しい技術といっても、うわべが変わっただけで本質的な変化はあまりありません。
C++とJavaとDelphi(PASCAL)ができる人は、C#が出てきてもすぐに対応できます。
それぞれメソッドなどの名前がかわっただけで、できることもあまり変わりません。
コンピュータの仕組みが大きく変わらない限り、本質的に新しい技術というのはそんなに
現れないと思います。

左官とプログラマの大きな違いとして、仕事の成果が見えにくいというのがあります。
その結果、動いてい(るように見え)ればいいという認識になってしまいます。

左官の場合、土で壁がおおわれていればいいということはまずなく、塗りムラがあれば
親方に怒られます。それがなくても、自分でうまくいってないことは実感できます。
また、塗りそこないや土の混ぜそこないで、後で壁がはげたときにも、自分のミスである
という認識がしやすいです。

プログラムの場合、動いているように見えることしか成果の自己評価がしにくく、また、
欠陥が出たときに自分のミスであることがわかりにくいです。
その結果、動いていればいいという、意識の低下が起きやすいです。

というわけで、デジタル土方は土方以下なのです。

>>277
横から失礼
そのレベルって言うのは1ステップずつって事だよね
フローチャートって箱1個に1ステップって言う厳密な定義があるの？
おれは図は箱1個にブロック単位でフローチャートを書いたりしてたんだけど
UMLのアクティビティ図みたいな使い方ね

>>279
>フローチャートって箱1個に1ステップって言う厳密な定義があるの？

ないよ。
今回は文脈からそう思っただけ。

>>279
たぶん、あーたはフローチャートの意味を取り違えている。
旧時代のフローチャートはほんとうにIF分岐を箱で書いているわけで
あれほど効率の悪いものは無いでしょう。
[この業界のなんとか]という藤原某のサイトに載ってたでしょ。

>>274
すばらしい分析です。

>>277-278
賛成。
だけど、うわべだけが変わっただけで本質変化はない
というのはいいすぎ。

Perl系スクリプト言語を覚えるのはやはり大変だし

WindowsGUIやWebの登場からまだ数年、
と考えると新しい技術はどんどん生まれているので
技術に追いつくのは並大抵ではないな。

>>281
>だけど、うわべだけが変わっただけで本質変化はない
>というのはいいすぎ。

もちろんいいすぎ。
最近ではWeb技術というのはかなり本質的な変化ではある。

でも、プログラムの分野は変化が速いとか言われる部分では、本質的な
変化が実はないといいたかった。
変化の激しさは、他の分野と同様か少し速いくらいだと。

技術に追いつくのが並大抵ではないのは他の分野も同じではないかな。

なるほど。しっかりわかっていらっしゃる方ですね。(偉そうでスマソ

＞技術に追いつくのが並大抵ではないのは他の分野も同じではないかな。
伝統工芸と比べたらというのがそもそもおかしいな。

半導体業界や自動車業界(ちょっと広範囲すぎるか)、
蓄電池業界そのたモロモロと比べたら
同じ程度に並大抵じゃないかもね。

プログラム分野はあくまでも人間の脳主体だから
生産性があがらないんだよね。
変な技術がうわさだけで持ち上げられたりもするし
>>278で出ているように
能力の無い人間が成果評価されないから
淘汰されずに生き残って周りの生産性の
足をひっぱりまくるし。

そういう意味で本質的変化はあまりないと言う意味になるのかな。
C++/Java/Del全部、オブジェクト指向言語だし
web系言語は生産性の面からみると、逆に後退していて面白みがない。

私らが現役の間に
劇的な生産性の向上するような
パラダイムシフトが見れたらたのしいのにな。

>>283
>私らが現役の間に
>劇的な生産性の向上するような
>パラダイムシフトが見れたらたのしいのにな。

とりあえず、

>プログラム分野はあくまでも人間の脳主体だから
>生産性があがらないんだよね。

が成り立つ限り、ないっす。（藁

>>284
それを超えるのが人間じゃろて。

XPのペアプログラミングがあり
ネットで情報を検索して得ることが出来る現在。

>人間の脳主体だから
>生産性があがらない

どうにかならないか？

一人の人間の脳ではなく、複数の人間の脳を
有効活用できないかな？

>>285
>一人の人間の脳ではなく、複数の人間の脳を
>有効活用できないかな？

ほとんどの脳使用率がコミュニケーションにあてられます。
参考文献：にんげつのしんわ。

>>286
反例は BSD の開発モデルということで。

FreeBSD だと committer (ソースファイルに変更を施す権利を持ってる人間）
が数百、開発者は数千だけど、そこそこ機能してる。オープンソース万歳と力
説する気は更々ないが、開発モデルには仕事でも参考になる点があると思うよ。

……とりあえず、バージョン管理ツールは使ってくれ。毎回数百ページの仕様
書を「改定版です」といって送られても、どこがどう変わったのか、何で変わっ
たのか追えないと辛いんだよ。

>劇的な生産性の向上するようなパラダイムシフトが見れたらたのしいのにな。

>C++/Java/Del全部、オブジェクト指向言語だし
>web系言語は生産性の面からみると、逆に後退していて面白みがない。

オブジェクト指向に至るまで、第三世代言語、構造化、コードジェネレータと、
パラダイムシフトがあったろーが。
「web系言語は生産性が悪い」というのは、パラダイムシフトが起こる必要条件だろうが。
問題点が分かったなら自分がパラダイムシフトを起こすチャンスだよ。

>>288
>問題点が分かったなら自分がパラダイムシフトを起こすチャンスだよ。
厳しいこというなあ。
俺ごとき凡プログラマにはなかなか難しいさ。

オブジェクト指向(OO)や構造化はわかるけど
ダイさんとかコドジェネとかは知らないや。
OOがパラダイムシフトだったのはわかる。あれはすごいことだ。
OO前からOO後のシフトのような現象が
今後も見れたらうれしいのだ。俺は

JSPは小規模のパラダイムシフトだと思っているけど
もっともっと先をみたいな。

いずれにせよ、サーバーサイドプログラムを
趣味で作ってアップする場所がないというのは悲しい。
・・・・・・・それこそパラダイムシフトがどこかで起きるチャンスかな（ｗ

>>新人さん
わけのわからない話題をしてしまってスマソ

>>287
ただ、そのモデルはOSとかWebサーバーとかの、みんなが同じような物
を必要とする分野でしか適用できないのが、事例により半ば証明されて
しまった。
あと、BSDやLinuxに多くの開発者が関わっているといっても、核となる
コードを書く人はやはり数人だし。
OSは独立したモジュールが多いから多人数でかかわりやすい。
納期やら機能やら「成功の約束」やら、なにか制限があると適用でき
ないし。

改訂版の変更点って書いてないの？

いろいろおもしろい話になっていて、興味深く読ませていただいています。
場違いかと思いますが、思ったことをまとめてみます。
（報告調で偉そうですみません。）
//////
戦後日本の繁栄を支えてきたのは大量生産の現場における「工員」という労働者だった。
「工員」の日本式管理方法はうまくいっていた様である。（人間性のファクタは知らな
い。）
これからの日本の繁栄を支えるのはPGだと思う。しかし、PGの世界は、大変、非PGには
理解しにくい。一方、世人（上司や顧客）の大部分はPGでないため、PGと非PGの間に、
うまいインターフェースが必要になる。PGと非PGとのインターフェースがうまくとれな
いと、当事者全員が不幸であるが、たぶん社会全体にも大きなマイナスになるだろう。
特におろかな間違いは、PGを従来の「工員」のように扱うことである。

（「天才」でなく「普通に優良」な）PGには、

　1．その仕事は、基本的に毎回一回限りの「創作」であり、同じものを鋳型で作るの
　　　ではない。
　2．また、常に技術の進歩／変化の影響と無縁ではなく、常に「勉強／研究」が必要
　　　というプレッシャーを感じている（と思う）。
　3．上記のような条件にあっても、個人的に「資産」を持っている。
　　この「資産」は、実際に書いてきたコードの蓄積もあるが、ノウハウや経験、アル
　　ゴリズムの理解など、文書化／明示化が難しいものも多い。　

などの特徴がある。項目3の「資産」は、一般には目にみえず（コードであっても、普
通のプロは公開していないはず。公開しても非PGには理解できない）、仕事そのものも
理解しにくい。また、PGの実力（仕事ぶり）は「成果物」を見て判断せざるを得ないが、
非PGには、その評価は（たぶん）難しいということになる。それゆえ、PGの評価がPGに
とって納得の行かないものになりがちとなる。
しかし、生産性を上げるためには、「優良なPG」を正しく評価し、よりよい環境で仕事
をしてもらう方法を考えなければならない。
で、どうするか．．．

>>291
機能を細分化すれば、単純なアルゴリズムは理解しているという注釈こそつきすれ、
「工員」扱いするのは可能だよ。
事実、全体のどの部分を担当しているかを知らずに、モジュールだけを作り上げて
いくという職場もあるわけですし。

既出かもしれないが、業務によるが、アルゴリズムはあまり重要視されていない。
（ある程度の理解はあって当然だから）

優良なＰＧがいるとすれば…、それは優良なＳＥとも言い換えられると思います。

>>292
>2．また、常に技術の進歩／変化の影響と無縁ではなく、常に「勉強／研究」が必要
>　　　というプレッシャーを感じている（と思う）。

個人的には、このような人はプログラマにはむいてないと思う。
デキる人は、好きで勉強・情報収集してるんじゃないかなぁ。
「ねばならない」と思う人は、いつか燃え尽きてしまうんじゃ
ないだろうか。

s/292/291/

このスレでは、いろんな人の経験談が出てるけど、
プロジェクトの種類と規模もあわせて考えなければ、
大切なことをみのがすかもしれない。

10人月のWebシステムと、1万人月の業務システム、
ゲーム、パッケージでは、まったく要求されるものが
違うと思う。

>>295
大人数になればなるほど、下っ端ＰＧの地位は低くなる…。
当たり前か。

>>295
うーん、おそらく1万人月の業務システムというもの自体が
すべて無駄の集まりだとか、
大分前に言わなかったかな。
あまり、1万人月の業務システムというものに
何か考え深いものがあると思わない方がいいよ。
手広く人を集めるほど互いに引っ張り合って生産性は落ちる落ちる。
むしろ、大規模な人間を集めて何かをやろうと
することが間違いかもしれない。

優秀な10人が1-2年程度で作るプログラムで
世の中のほとんどのシステムはうまく動くはず。

まれな蝶々大規模プログラムとして
Win2000は末端あわすと2000人だっけ。
だけど実質数百人が数年というところでしょ

Linuxなんかも、人月自体は
それほどでもないようだし。

勝手なことをごちゃごちゃ書いて、盛り下げてしまったかと反省しています。
>>275
遅レスですみません。
>請負ソフトという未来が無い業種にSEが居るだけです。
これは、私には実は衝撃的でした。「請負ソフト」ってオーダーメイドってことで
すよね。本当に未来がないのでしょうか。私はむしろ栄えるのではないかと思って
いたので、ショックです。どうなのでしょう。
>>297
>機能を細分化すれば、単純なアルゴリズムは理解しているという注釈こそつきすれ、
>「工員」扱いするのは可能だよ。
「工員」のようなPG（コーダー？）もいるとは思います。しかし、機能を細分化する
のもPGではないかと思うわけです。
>優良なＰＧがいるとすれば…、それは優良なＳＥとも言い換えられると思います。
もちろん、SEをそのように定義するなら、私の「PG」は「SE/PG」としてもかまい
ません。（単に言葉の定義の問題だと思います。もちろん、「名称」に「誇り」が
あれば、単に「定義の問題」とは言えないのでしょうが。）
>>293
私もそう思います。ただ、人間、好きでない仕事をするのは無理だと思いますし、
一方で、好きなことだけやっていても、仕事ならある程度のプレッシャーもあるので
は？（これも言葉の問題？）
>>295 >>296 >>297
ここで発言される方が、最初に「私の参加するプロジェクトは大抵○人月だが．．
．」と断ってくれるとより参考になるかもしれませんね。（いえ、ほんの冗談です。
すみません。）プロジェクトの規模により参加するPG（そのスペクトル）が違うとい
うことは事実かもしれません。また、297さんのご指摘のようなこともあるのかなー
とも思います。

293さんへの反論ではなく、「好きで勉強」に関連しての感想です。
2chを見ると、みなさん「鬱だ。鬱だ」（本当に鬱なら大変ですが。）と言いながら、
プログラミング好きなんだなーと思える話も多いように思います。私は、サンデー野郎
ですが、読んでいてなんかうれしいです。しかし、一方で、非PGの人の「好きでやって
るんだろ（だから報酬なんかなくったっていいだろ）」という声も聞こえてくるような
気がします。プロなら報酬を貰うのは当然で、サンデーの私なんかに言われるまでもな
いと思うのですが。
別のスレで「会社に本を買ってもらうかどうか」の議論がありますが、これなんかも、
好きで勉強していても、転職のために勉強していても、「会社のために勉強しているん
だ」と主張してよいような気がします。（これは完全なウソではないはず。）
PGさんは、正直すぎるのでは？勉強して、（会社への見返りを何か出せば）勉強したこ
とに対して、報酬を貰ってもよいのではと思います。現場を知らなすぎると言われそう
ですが。あと、スレとずれすぎでしょうか？「寝たふり」がへたなんでしょうか？

>>298-299
「請負ソフト」はネタです。気にする必要はないと思われ。

本は、概念系の本になるほど「見かえり」が示しにくいです。
本よりも大きいレベルですが、CMMも「見かえり」が数字として見えにくい
ので、経営層に理解しにくいです。
これには
　形式的なプロセスが無い → 生産性・品質を数値化できない
　　　↓
　CMMのレベルが上がってプロセスが確立する → 数値化できるようになる
というのがあるのですが、これで数値比較を求められると「ｳﾂ」なわけです。
CMMのレベルがあがったおかげで数値比較ができるようになったんじゃｳﾞｫｹって
感じです。

2chにそれなりにかきこんでるってことは「寝たふり」してるんじゃ。

>>300
なるほど。わかるような気がします。
>2chにそれなりにかきこんでるってことは「寝たふり」してるんじゃ。
えっ？？？「寝たふりしてろ」とは、「黙って読んでろ」という意味なんじゃ？
あれ？間違えました？

あ、ちゃんとスレ読んでないかも。< 漏れ

>>「請負ソフト」はネタです。

おいおい何で請負ソフトに未来が無いがネタなんだ？

>>請負ソフトという未来が無い業種にSEが居るだけです。
>これは、私には実は衝撃的でした。「請負ソフト」ってオーダーメイドってことですよね。
>私はむしろ栄えるのではないかと思っていたので

パッケージソフト中心って、雑誌に書いてあるだろうが。
オーダーメイドは手作業でしょう。手作業を否定するのがソフトウェア。

>>303
いや、請負ソフトにはSEがいるから未来が無いと読めたからネタだと思った。

>>303
>パッケージソフト中心って、雑誌に書いてあるだろうが。
>オーダーメイドは手作業でしょう。手作業を否定するのがソフトウェア。
もう少し詳しく聞かせてもらえないでしょうか。
ソフトがパッケージソフトだけになると、最終的には、MSのような大ソフト会
社の出すパッケージソフトだけになってしまうということはないのでしょうか？
（もちろん、UNIXやLinuxでは別の会社かグループで。）いつも大企業が勝つと
は限りませんが、いずれにせよ、ひとつひとつの分野で勝ったところ1、2社の
寡占になるのがソフト産業の未来なのでしょうか。

すると、天才でないPGの仕事は、勝ち組企業に就職して（あるいはその下請けで）、
そのソフトの一部分を担当することになるか、ユーザーサイドで有名ソフトのカ
スタマイズのお手伝いをするくらいになってしまうような気がします。前に書き
ましたが、私に特に興味があるのは、中小規模のソフト開発です。もちろん、採
算を考えないグループは残るでしょうが、中小企業の大部分淘汰されてしまう．
．．ということなのでしょうか。

請負ソフトがなくなるとして、そういう時代のパッケージソフトとしては、どう
いうものが考えられるのでしょう？前にこのスレで「DB関連の仕事が多いのでは」
と質問したところ、肯定的なレスが多かったような気がします。このようなも
のはなくなっていくということですよね。（これで、やっと本題の「プロのプロ
グラム教えて」ですが．．．。^^;）
それとも、パッケージの種類が非常に増えていくのでしょうか？

私は、何か勘違いしているでしょうか？この件は、私の死活問題とも言えます。
303さん、また他の方、コメントをお願いできないでしょうか。

>>303
とりあえず、手作業を否定するのがソフトウェアだって言うのは始めて聞いた。

自動ソフト生成だとか、「設定だけで」どんな用途もカバーするパッケージだとか
非現実的なことはソフトウェア工学ではやってないと思うけど。

で、もしかして、ソフトウェアだけをシステムと思ってないですか？
そしたらSEが不要だとかが通じるのですが。

エンドユーザー・コンピューティングってのが一時期騒がれて、
これからはプログラマー要らずだと言われた時期があった。

実際には今でもプログラマーは必要です。

>>307
エンドユーザーになるはずの人がプログラマになってる。
10年前にはこんなにプログラマいなかったと思う。

>>303
>パッケージソフト中心って、雑誌に書いてあるだろうが。

とりあえず、そんなマヌケな分析をしている雑誌名をさらすこと。
誤読じゃないの？

「素人の考えで、間違っているかもしれません。その場合は訂正していただきたい
のですが．．．」を毎回文頭に書くのはスペースの無駄なので、今後は省略します。
しかし、いつも私の発言の文頭にあるとお考えください。（そういう意味で決めた
ハンドル名です。）

で、ちょっと夢がない言い方に聞こえるかもしれませんが、私は、全国にたくさん
あるソフト会社の多くが、やはり全国にたくさんある工務店のようなものかと思っ
ています。もちろん、新しいタイプのものですし、「頭脳労働」であって、「デジ
タル土方」とかいうのとは違います。コンピュータ／ネット上の「もの」を作り出
す建設業という意味です。実際の工務店と違うのは、技術さえあれば（そして、世
の中の仕組みがもう少し、ソフト技術者重視になれば）、地方の一工務店が「超高
層ビル」（「規模」の話ではなく、「すごさ」「経済価値」の意味で）も作れると
いうことです。（もちろん、「天才」なら、工務店も世の中も関係無いわけですが、
とりあえず、そういう人の話はしません。）また「お客様に喜ばれる住みよい小さ
な家」を作っていく（これも決してつまらないこととは思っていません）こともで
きるわけです。
こういう工務店的なソフト会社は、（パッケージソフト開発会社と並んで）栄えて
いくのではないかと思っているのです。
一度建てたら動かせない建物と、比較的簡単にコピーや移植ができるソフトを同一
視することはできません。あくまで、ある程度のイメージの話です。また、私はパ
ッケージソフトというと、超メジャーなものを考えてしまうのですが、そこでイメ
ージが間違っているかもしれません。いかがでしょうか。おかしければ、バシバシ
言ってください。お願いいたします。

>>310
>一度建てたら動かせない建物と、比較的簡単にコピーや移植ができるソフトを同一
>視することはできません。

いい認識だと思うのですが、実は微妙にずれてます。
工務店は施工屋さんです。
建物の場合、一軒建てたら、まったく同じ建物はかなり低コストで作れます。
しかし、ソフトウェアは、まったく同じソフトウェアを作ることはありません。
いままでのソフトウェアをそのまま使えばいいからです。

一方で、建築の場合でもまったく同じ設計をする仕事はありません。
いままでの設計をそのまま使えばいいからです。
ソフトウェアの場合でも、同じCD-ROMを何枚も作って配布することはあります。

要するに何がいいたいかというと、ソフトウェア作成を建築にたとえると
設計の工程に対応するということです。建築設計の現場ではソフトウェアと
同じ問題が発生します。

建築とソフトウェアの違いは、ソフトウェアには施工の工程がほとんど存在
しないことです。建築設計での問題点は、コストの桁が違う施工の段階で
吸収することができます。

ほかの分野に比べたソフトウェアの特殊性は、単純作業・反復作業を多く含む
施工の工程がほとんどないことに起因することが多いです。
教育の問題や見積もり・スケジュールの問題は特に。

しかし、こんやヤツに教育される学生も可哀想だな…
ただでさえ卒業してマトモに使えるヤツは数％なのにそれがさらに1/10くらいに
なってしまう。
日本の未来のために職を変えてくれ。

>>312
FORTRANをわけわからない授業で教えられるよりよっぽどマシ。

1がどんな立場の人なのか知らないけど

>>312
おまえ、バカじゃない？、つーかスーパー馬鹿だね。
どうせ、OJTで新人を教えたことくらいしかないんだろ。

教育する立場の人間が社会の現状を知るなんてこと
どの教育者が出来ていると思う？
誰もできてないよ。

それをやろうとしている、1は俺には賞賛に値する
1みたいな奴が少ないから日本の未来のだめになるの。

あらためて>>312
屑。氏ね、逝ってよし。

>>314
激しく同意。

>>314
社会の現状を知る/知らない以前の話なんだがな。
レベル低すぎだろ…

どこがだよ。あと、何に対してレベルが低いとか逝ってる？

この業界のことなんて
全体を把握している奴いないだろ。
所詮は、自分の目に入る範囲だけだ。

1はぶっちゃけた話
この業界にすらいないのだから
世間のことがわかるわけねーだろ。

1だって、この業界を知ることが本職に≒だったとしても
教育者として他にやる事はあるだろうし

まともな教育受けたのか？
まともな教育受けたのなら
その教育がこの業界の事何も伝えていないことくらい
わかると思うが名。

>>317
オマエもレベル低そーだな。

>>311
コメント無しさん、いつも詳しいレスをありがとうございます。私の中で（実際の）
工務店と設計事務所の区別を付けていなかったのですが、なるほどと思いました。
もともと、「請負ソフトはほろびる」に対して、「そうではないのでは」という意
味のレスだったのですが、請負ソフトハウス＝設計事務所としても、滅びることは
なさそうです．．．よね。

>>312 - >>318
すごいことになりましたね。自分に対する評価なので、詳細なレスは控えさせてい
ただきますが．．．
>>312
>しかし、こんやヤツに教育される学生も可哀想だな…
私のような教員はあまりいませんので、大丈夫なのでは、と。^^)
>>314 >>315
314さん、315さん、ありがとうございます。「賞賛」は、買い被りではと思います
が。^^;)
>>317
ありがとうございます。
>まともな教育受けたのなら
>その教育がこの業界の事何も伝えていないことくらい
実は、これがするどいご指摘にもなっているのですね。^^;)
これについても（もちろん、皮肉とかでなく）ありがとうございます。

ずいぶん前にレスで書きましたが、大学教育・教員にもいろいろあってよいと思い
ます。私は、できるかぎり業界のことを知りたい教員なのです。その点、多くの方
のお話にいつも感謝しています。また、私を（レベル等の理由で）お嫌いでもかま
いません。どこがどう嫌いか等、話していただければ幸いです。（本気です。）

>>319
業界のことなんて知る必要ないんだよ。今瞬間の業界に迎合しても全く意味無し、逝って良しってやつだ。
そんなことより、物事をちゃんと思考できる能力をしっかり身につけさせてやってくれ。
最近は根拠無しに思い込んでるＤＱＮばかりなんだが、この業界以外なら中学レベルの学力でもやって
いけるだろうが、大学以上の学力をもって根拠ありに思い込むようにさせてやってくれ。

random!

プロのソースならMFCの実際のソースとかVCについて来るサンプルが
ためになるのでは？
とはいってもWindowsAPIの使い方のソースだけどね。
CならK&Rを1冊買って渡せば絶対間違いないと思うけどね。

プロのプログラムはいかに手抜きをするかがカギです。
学生の参考にはならないでしょう。

>>13-14
ワーニングとか言う人久しぶりに見たよ。
それとも、ここの板では「がいしゅつ」とかと同じ意味合いなのかな。

>>14の方は分かって相手しているみたいだな。
スマソ

ワーニングは発音間違ってないよ。
アイロンのことアイアンってわざわざ言わないのといっしょ。

そうだね。awardはアワード、walkmanはワークマンでも全然ＯＫさ。

ほぼ「日本語」に取り入れられている英単語の読み方に
こだわる奴って本当に莫迦だと思う

>>328
同意。
ここに来る奴は、知識はあっても枝葉にこだわって本質を
捉えられない馬鹿ばっかり。

>>328 >>329
こだわってんのはテメーらじゃねーか（稿

>>330
あほ？

>>331
バカ？

>>330 みたいなアホは放置でいきましょう

まあまあ落ち着いて。
のんびり生きましょう。

それにしても、「ワーニング」やら「ヌル」やらは、ほぼどころか、
全然「日本語」に取り入れられていないと思う。

語彙の少ないヤツ相手にするのは疲れるね

#include <stdio.h>

void saiki(void);

void main(void)
{
saiki();
}
void saiki(void)
{
printf("1は逝ってよし！\n");
saiki();
}

>>337
終了条件忘れるなよ
たのむから・・・
それで、再帰なんて恥ズすぎるだろう？
なあ・・・

>>320
>今瞬間の業界に迎合しても全く意味無し、逝って良しってやつだ。
ただ、「迎合」するつもりではないのです。（最低と思う方が多いようですが）大学にも
長所はあります。教育問題とは別に、ある意味での産学協同を考えているのです。
>そんなことより、物事をちゃんと思考できる能力をしっかり身につけさせてやってくれ。
私も賛成です。しかし、（教育の話に戻ると）私が教えているのはプログラミングなの
で、やはり、プログラミングで「思考能力」を教えるしかないのです。そのためには、具
体的な例や指標がほしいと思うのです。たとえば、ソートを例にとると、プロのPG予備軍
に必要な「能力」としては、
　A　ソート関数を（簡単な説明を聞いて）自分で書ける
　B　ソート関数のコードをどこかから取ってこれる
　C　標準ライブラリのソート関数を知っている
　D　中身は知らなくても、いろいろな使い方を考えられる
などで、どれだと思われるでしょう？
>>322
ちょっと本題と離れるかもしれませんが、MFCのサンプルコードは、MFCの簡単な使い方の例と
してはよいのですが、情報隠蔽とか、比較的いい加減な気がしてしまうのですが？そう思いま
せんか？
>CならK&Rを1冊買って渡せば絶対間違いないと思うけどね。
これは、本当に重要な点なのですが、PG予備軍の基礎知識として、「K&Rをざっと読んだ程度」
というのはよいのでしょうか。（「K&Rを極めろ」と言われると、授業ではちょっと苦しいの
ですが。Win系では使わない話もありますし。）あるいは、最近よくある「Cの参考書でこの辺
までできればOK」というのがあれば教えてください。（もちろん、参考書スレもありますが、
「初心者でかつPGになりたい学生用」という限定付きです。）

一部の方の書き込みは、どちらかというと、スレを中止させたいのではないかと思えます。
（直接的なものや、どこか論点がずれているのに短時間でレスポンスしあっているものなど。）
これらの多くには、「面白半分のアオリ」というより、「怒り」のようなものが感じられるの
ですが、思い過ごしでしょうか？もしそうなら、それが何に対するものなのか、興味深く感じ
られます。（変な言い方ですみません。）できればご本人から、無理ならどなたか、コメント
をいただけないでしょうか。
勘違いならすみません。ご容赦のほどを。

>>338
終了しないでスタックを食い尽くすまで逝って良し
という意味なのでは？

>>339
だからさ、小手先のプログラミングよりKnuthの本とか、もっとやることいくらでもあんでしょ。
計算機科学を教えてやれよ。

末尾再帰をループに展開するコンパイラ使うんでは?

>>340
に関して・・・

２ちゃんでは煽りや叩きはあって当たり前ですから
必要以上に気にすることはないと思われます。
もちろんそれらの書き込みに対しても、ご自身が何かを得られるのであれば
それはそれで良いことであるとも思います。

要は受け手次第。本物の批評とただの煽りを見分けられるようになれば
一番良いのですが、なかなか難しいですね・・・。

少なくともこのスレは良スレだと思いますよ。

本筋と関係ないのでsageで。

>>344
ネタだろ。

http://157.110.50.64:8080/~g96307/html/Ronbun.pdf

>>339
◎　C　標準ライブラリのソート関数を知っている
○　D　中身は知らなくても、いろいろな使い方を考えられる
ひとつの言語とクラスライブラリを使いこなせるようになれば
他の言語でも同様の実装がおそらく存在することを体で感じるので
どんな仕事で言語がきてもOK(業務系で優秀なSE/PGになるならな)

K&Rは難しすぎるからやめとけ。

>>344
激しく同意

http://mentai.2ch.net/test/read.cgi?bbs=infosys&key=997407948

>>347
カニ炒飯を難しいと思っているうちはまだまだ。

成長の余地があるのでむしろ喜ばしいことか。

まだまだ、たくさんのレスありがとうございます。
>>342
「計算機科学」というのは、文脈から判断して、アルゴリズムということでしょうか。
すると、「A　ソート関数を（簡単な説明を聞いて）自分で書ける」を推奨ということで
すよね。（342さんを怒らせているものは何なんでしょう？業界をかぎまわる教員でしょ
うか？ろくなコードも書けないのに「この会社の開発プロセスには問題があるのでは？」
なんて口を聞く新入社員でしょうか？）
>>344
ありがとうございます。2chは初心者ですが、掲示板関係のごたごたはいろいろ体験して
いますので、大丈夫だと思います。それに、344さんも（おそらく）お気づきのように、
実は、煽りや叩きも私にはとても参考になるのです。（それに、本当は、338さん、341
さん、343さんのような反応は好きで、自分でも書きたくなる位です。アマでもPGなので。
「逝って良し」という言葉も、簡潔でかなり好きです。ただ、「良スレ」と思ってくださ
る方々を失望させるような反応は控えているのです。もう失望していたらすみません。^^）

一つコメントすると、このスレで「プロのPG」らしく振る舞っている方でも、本物かどう
かわからないわけですよね。（本物の方、すみません。）その点も一応注意するようにし
ています。読んだ感じで想像が付くような気がしますが。
>>347
ありがとうございます。想像ですが、347さんの意見が多数派のような気がしています。

Knuth本は、すばらしいと思うのですが、何%位の方が読んでいるのでしょう？私はほんの
一部しか見ていません。アルゴリズム一般が好きでいつも研究しているというのでなけれ
ば、業務に必要になって見てみるとか、その業務特有のアルゴリズム（の実装）があって
それに習熟する方が重要とかではないかと思うのですが。たしか、場合によっては（基
本は別にすると）アルゴリズムに詳しくなくてよい、という意味のレスもあったような。
もちろん、「アルゴリズムの基礎」は必要だと思いますが。いかがでしょう。

すみません。明日から1週間ほどお盆休み（という名の家族サービス、
という名の労働）に行ってきます。
そんなわけで、少し書き込みはお休みします。（読むつもりですが。）
それでは、また。　新人

>>350
長い文章は嫌いだな。
アルゴリズムもプログラミング技術も本見て盗め。
世の中に役に立たない知識なんてひとつだって存在しないんだから。
つかえないものも「これはつかえないものだ」という知識になる、くらいの
心構えを持ちやがれ。

確かに、新人氏は少し文が長いな。

1週間あけるなら下がりまくると思うが、
ｶｷｺみやすいテーマをひっさげて戻ってくるといいんじゃない。

俺は趣味メインでいい加減な仕事してる"プロ"グラマだけど
アルゴリズムなんてろくすっぽ覚えてないよ。
どんな言語でもそこそこ使えるけどね。

>その業務特有のアルゴリズム（の実装）があって
>それに習熟する方が重要とかではないかと思うのですが。

だよね。3D屋さんの技術なんか、3D屋でしか通じないし
有限要素法の高速化屋さんだとそれしか意味ないだろうしな。

俺も文章長居な。（ｗ

>>350
おいおい、計算機科学も知らんのか･･･ やはり予想どーりじゃねーか。
よくそれで大学でモノを教えてるね。

>>354
いや >>342 が舌足らずな書き方だから、確認しただけだと思うな。こ
こは 2ch だから口が悪いことは非難しないが、せめて的確に意図の
汲める文章を書いて欲しい。

文章がきつく罵倒調で、文意が曖昧では、ただの出来の悪い煽り。

そうか、世間はお盆休みなんだよなぁ･･･。

話しそれるかもだけど
昔:とにかく少ないバイトに芸術的に詰め込んで短く構築
今:メモリ大消費するかもだけどすばやく実行orできるだけ後で再利用可能な美しさ
が、プロのプログラムかな?
個人的には"しんぷる伊豆べすと"で耐えられる速度なら簡潔さ重視してる。
→理由:仕事で人のソースを見ることが多いけど、"芸術"は読めんよってメンテ不可能...

>>357

だね。
こんだけマシンスペック上がってんだから
多少の無茶は出来るよね。
それを理解せずに、やたらと10年前の方式に囚われたり
する上司いると、本当に疲れる。

>>357
i=i+1 は i++ と書け! って．．．やれやれ。

>>359
ちなみにその文脈なら ++i とするな俺わ

i+=1とi++ってコンバイルした結果は同じにならない?
最適化の結果。

最近はそんな細かいところにこだわってる場合じゃないよね。

>>361
結構マジで理解してないヤツがいるぞ。

if(v==0) 〜
は
if(! v) 〜
の方がより早いコードとなるぞ、とか．．．

>>357-362
ファーム系はそうでもない
新しいチップが出るたびに、それようの開発環境、コンパイラなんかもできるので
当然枯れていない
最適化がうまくいくとは限らないし、最適化オプションつけたばっかりに
動かなくなる、バグコードはくなんてこともある
極端な話、i=i+1 と i++ で違うコードかもしれない

>>361
C なら気にしないが、C++ だと演算子オーバーロードがあるので i + 1
は避けたいな。ついでに i が iterator だと i + 1 とは書けないし。

それと C ではインクリメントには ++i が普通だから i + 1 が出てき
たら、それは何か意図があると受け取る。文法的にはどっちでも良くて
も、慣用句ってあるじゃない？

--iはフツー、i++もフツー。
i--とか++iはﾊﾞｶまるだし。

>>364
で、i + 1っつー慣用句って何だよ。

('Д')

>>365
ばかが。
if( --i==0 ){

}
と
if( i--==0 ){

}
じゃ動き違うだろ。

コンパイラの最適化なんて関係無いね。

問題は読みやすいかどうかだろ！？

i=i+1; は激しく逝ってよし。

>コンパイラの最適化なんて関係無いね。
デバックオプション付でしか動くものを作れない能無しﾊｯｹｿ!

>>365
More Effective C++ の項目 6 を読んでから出直せ。

>>368 >>371
通りすがりの者だけど、一言。
そんな低レベルのことじゃないと思うぞ。

>>372
高レベルな解説を希望。

教えてくれくれ言うだけじゃなくて、
現実的なコードの中で、どういうインクリメントorデクリメントが
実際に必要になるか、自分で考えてみろ。
そして、もっと謙虚に発言しろ。

>>374
現実のコードで、前置も後置も使ってるけどな。自分のコードだと説得
力がなさそうなんで、ATL のソースコードを検索してみた結果。

> egrep '[a-zA-Z]\+\+' * | wc -l
280
> egrep '\+\+[a-zA-Z]' * | wc -l
5

圧倒的に後置 ++ が多いものの、前置 ++ も使われてるね。

C++ の演算子オーバーロードに関しては、また別の話で、メソッドの
プロトタイプは次のようになる。T は適当な型。

T& T::operator++() // 前置
const T operator++(T) // 後置

後者だとコピーコンストラクタが必要になりますが、それは理解してま
す？

>>375
ATLとは…
STLにしとけよ。

>>376
期待にこたえて STLport 4.0 を調べてみようか。stlport/stl にある
STL のヘッダファイルがサンプルね。

> egrep -- '[a-zA-Z]--' * | wc -l
41

> egrep -- '--[a-zA-Z]' * | wc -l
10

> egrep -- '\+\+[a-zA-Z]' * | wc -l
15

> egrep -- '[a-zA-Z]\+\+' * | wc -l
308

>>377
おいおい、[A-Za-z_][0-9A-Za-z_]*[ \t]+ くらいじゃないのか？

>>378
ついでに >>377 だと、コメント中の文字列も拾ってるし。STLport だとコメント
中に C++ という文字列が頻出。

>>378-379
確かに。パターンを変えて、精度を上げてみました。

> egrep -- '--[ \t]*[A-Za-z_][0-9A-Za-z_]*' * | egrep -v 'C\+\+' | wc -l
146

> egrep -- '[A-Za-z_][0-9A-Za-z_]*[ \t]*\-\-' * | egrep -v 'C\+\+' | wc -l
42

> egrep '\+\+[ \t]*[A-Za-z_][0-9A-Za-z_]*' * | egrep -v 'C\+\+' | wc -l
663

> egrep '[A-Za-z_][0-9A-Za-z_]*[ \t]*\+\+' * | egrep -v 'C\+\+' | wc -l
167

で、あらためて >>365 の意図を聞きたいんだけど。特に反論がないようなら、いい
加減スレ違いなんで、これで終わりにしましょう。

出たな！レア言語で自己満足に浸る負け犬が。

>>381
どこにマイナーな言語の話題が出てるの？

>>381
全然レアなもんはねーが。ひょっとして正規表現のことか？（笑

>>383
コマンドラインを全く知らないに一票。grep, wc というコマンドの存在はおろか
パイプも知らないため、egrep 云々がレア言語で書いたプログラムに見えたので
しょう。

まぁ >>381 が一般ユーザや学生さんなら許しますが、プログラマやＳＥを名乗っ
ていたら首を吊ってもらいましょう。

>>380
PDPの頃からやってる人間にとってはどうも++iとかi--とか見ると鳥肌が立つんじゃがのー。

>>385
PDP-11 の autoincrement mode, autodecrement mode では

mov (r1)+,r2
mov -(r1),r2

は許されているが +(r1), (r1)- は許されていないって話？　懐かしい話だけど、
さすがに古すぎでしょ。

UNIX V6 のソースも手元にあるから、これで前置・後置の出現回数をカウントして
みようか？

int i=1900

endsub

(void)
{
}

subるーちん

あまりの低レベルさに思わずリンクしてしまった。
スゲーよ。

http://mentai.2ch.net/test/read.cgi?bbs=infosys&key=997147804&to=100

>>388
面白すぎて怖い・・・

割り込み失礼
スレ立てるまでもねぇ
くだらねぇ質問させてもらうぜ

if( A == B && C == D && E == F ){
}
↑例えばこれ
あんたならどうする？

if(A == B &&
C == D &&
E == F ){
演算子はけつに付けるぜ
}

if(A == B
&& C == D
&& E == F
){
演算子は頭だｺﾞﾙｧ
おまけに閉じカッコも改行だﾎﾞｹﾞｪ
}

if( A == B &&
C == D &&
E == F ){
インデントはカッコに合わせるんだよ！
}

お前らの流派を教えろ

インデントがうまく表示されてない
鬱だ・・・

>>390
ソースコード内で統一されてれば、何でも良いです。

仕事でプログラムを書く場合には、コーディング規約があれば従うだけ。
自由に書けといわれた場合には、私は条件文が短ければ一行で書く、長
くなったら演算子を行頭につけて

if (A == B
　　&& C == D
　　&& E == F) {
　　// do some work
}

と書いてます。

改行位置よりも重要なのは、条件文が複雑になったら、そこだけ別の関
数なりマクロに括り出すことでしょう。長々と条件文を列挙するよりは

if (is_granted(&db_info, &user_info)) {
　　// go ahead
}

と書いてある方が読むときに分かりやすいし、保守も楽ですから。

>>392

で、

int eval(inr A, int B, int C, int D, int E, int F)
{
　return (A==B && C==D && E==F);
}

:

if(eval(A,B,C,D)){
　...
}

ってありなんですか？オレは嫌だな。

if (A == B
　　&& C == D
　　&& E == F) {
　　// do some work
}

はOKだけど。

あ、ぷろ３すれからズレてませんか？

>>393
いや、さすがに構造体に入っていないような int を 6 つ比較するなら、直接書き
ます。そもそも int を 6 つ比較する時点で、まずはデータ構造を疑ってみますけ
ど。

> あ、ぷろ３すれからズレてませんか？
主役がお盆休みですから、いたしかたないかと。

>>388
バイトの営業しときました（藁

一応、１の責任を感じてはいたのですが、私がいない方が活発だったりしますね。
海水浴の旅館で息子に踏まれながら楽しくROMをさせていただきました。
（主役．．．とか言われると、びびりまくりますですが。別の方のこと？）
一応、明日より復帰いたします。特にネタはありませんが。m(__)m

毎朝日曜日には息子とデジモン（デジタルモンスター）という番組を見ています。
デジモンは過去に作られた人工生命（ソフト）がネット内で野性化し進化したとい
う設定のようですが、若い技術者が「老人の使う人工言語しかわからんくせに！」
という発言をしていて、笑い転げてしまいました。設定的に「老人」は私の世代
です。この人工言語はCかなJavaかな、と思いました。
復帰ご挨拶を兼ねた近況報告です。　　新人
地雷ネタかもしれませんが、引用されていたLANのスレ、私には面白かったです。
「レベルが低い」というのは、どの辺なんでしょう？

>>396
むこうでおいらが一緒に仕事してもいいかな〜っておもったのは92と95です。
32は時にまともなことゆーてたりもしますが全体的にはばらんばらんなので×です。
レベル云々は提案の仕方とその内容と推し進め方などなどでしょう。
っとおいらは感じました。

>>396
何勘違いしてんだよ… 自己顕示欲MAXだね。

>>397 ありがとうございます。ものすごく興味があるのですが、他スレなので、深入りはやめます。
>>398 すみません。もうしません。

実は、お盆休みの前に、ご近所の企業さんに営業をかけてみました。ホームページ作成の仕事をも
らいました。（いずれサーバーを持っていただいて、将来はCGIか何かを書かせてもらいたいな、と
思ってます。）
もともとあまり興味のなかった所での新規開拓なので、プロのみなさんお許しを。ホームページ
プロジェクトの総予算は、100万円だそうです。（もちろん、ハード、ソフトの代金すべてを含めて
の話で、私への謝礼は千円単位でしょうが。）それで思ったのですが、「素人さん」は、何ができ
るかわからない／自分でも何がしたいかわからない状態ではないかと。こちらが明確なモデルを示
してあげれば、お金を出してくれるのかなーと思いました。
ただ、総予算100万円程度では、プロの利益にはならないのでしょうね。

>>399
つーことは、私立大学なんだな？効率だとバイトは犯罪だもんな。

>>399
ＨＰ製作なんてそんなもんだよ。
まだいいほうじゃないの？

>>400
そんな馬鹿な

本日、お盆休みの最後に、東京まで行って、本を買い出してきました。デスマーチ、人月な
ど。で、最初にデスマーチを読み出したのですが、「面白い」ですね。アメリカでも、ソフ
ト開発は2chの書き込みと同じような状態なのですね。とても感心しました。ただ、ちょっと
どうなのだろうと思ったのは、「プロジェクトの失敗」の話がずいぶん出ていたことです。
「デスマーチ＝つらい開発」（本にはもっと細かい定義あり）ならわかるのですが、日本で
もそんなにプロジェクトが失敗するものなのでしょうか。失敗したら、普通、大変な騒ぎで
すよね。それとも「失敗」の定義が違うのでしょうか。
それから、プロジェクトマネージャというのは、日本のSEのような、上級PGのような、対応
するのはどういう人だろうか、対応職はないのだろうかと思いました。いかがでしょう。
本を読んでない方、すみません。でも、多くのPGが読んでおいてよい本のように思いました。
208さん、みなさん、あらためてありがとうございます。

>>400 「教員も社会体験せよ」にお応えして．．．

デスマーチは常態である
デスマーチであっても奇跡的に成功を収めるものもある

みたいなこと書いてなかったかい？

>>403
失敗つーか、ヘルプが入るのは日常茶飯事だったりする。
あと、納期を延ばしてもらうとか。

プロジェクトマネージャーを役職としてもっている会社は割と
多いんじゃないのか？

>>403
「デスマーチ」はうろ覚えだけど、
「失敗」の定義が違うのだと思います。

>>405のいう、ヘルプが入ると、工数が膨らみ、バジェットをオーバーして失敗。
納期を延ばしてもらうのも、、スケジュールが遅れているので失敗。

スケジュール・予算・品質のいずれかが、計画のどおりにいかないのをプロジェクト
の失敗と呼んでいる以上、失敗はしょっちゅう発生すると思われ。

>>402
国家公務員法くらい読んどけよ。

そう言えば納期が一年半延びてたプロジェクトを見たことがあったな。
今どうなってるんだろう。

>>407
条文に直接当たったわけではないが、教員が自分の研究活動に関連する副業を
するのはOKだった気がする。国公立大学教員が印税なしで本を書くとも
思えないしな。この場合は抵触するかどうか。

>>409
当然、しかるべき手続きをすればヨロシ。してない場合はお縄です。

デスマーチ読み終わりました。本当におもしろかったです。
ただ、「事実・解釈・個別の対応策」の読み物としてはとても参考にな
るのですが、著者の本心（人が取るべき基本的戦略）がいまいちわから
ないという印象もあります。
A デスマーチは常態であって例外ではない px（まえがき）
B デスマーチ＝「通常12ヶ月かかるのに6ヶ月以内に出荷しろ」など p3
C デスマーチ＝失敗する確率が50%を超えるもの p4
D 「デスマーチを異常な状態にしないように効果的に支援するためには、
現在の伝統的な組織の文化をどう変えたらよいか」 p190
E デスマーチ文化の確立 p194
これらは、必ずしも矛盾する事柄ではないのでしょうが、論理的にはあい
まいです。「通常でないことが常態」は、おサムライ的ですが、私のよう
な職人希望者は戸惑います。（やっぱり、「デスマーチはやめよう」が
よいと思うのですが。^^;）
405さん、406さん、失敗の定義ありがとうございます。

>>411
「デスマーチはソフトウェア業界に限って言えば、常態である。」
ということでしょう。たぶん。
で、原因としては変化や競争が激しい業界であるってのが、挙げられます。
競争が激しいのが一番大きいかな。

>>412
真のプログラマは寝ないものである
なんて幻想がはびこっているのも要因のひとつだろうな。

大工さんだったら日没後には仕事できないだろうけど
プログラマには関係ないし

>>412 >>413 ありがとうございます。なるほどです。
個人的には、個別のデスマーチはなくならなくても、業界全体は落ち着いていかなけれ
ばいけないように思います。
本の「デスマーチ」で面白かった話のひとつは、PGとプロジェクトマネージャの立場の
違いでした。（405さん、ありがとうございます。するとプロマネ＝SE？）
PG：転職先がなくしかたなしにデスマーチに参加する場合もあるが、プロジェクトマネ
　　ージャより転職（＝ここでは逃亡）が楽そう。
プロマネ：高級取り（PGにピザやビールをおごれるくらい？）だがデスマーチが失敗す
　　ればクビの可能性大。逃亡はほぼ不可能。クビになったあとはたぶん大変。
2chを読むと、「PGの世界が一番アメリカに近いのでは」と思うのですが、「デスマーチ
に参加したくないので会社辞めます」（「デスマーチ」にあったPGの一つのチョイス）
と言い切れるPGさんは、やはりそんなにいないのではないでしょうか。転職関係のスレを
見ていると、事務職サラリーマンよりかなり多そうですが。一方、サラリーマンプロマネ
の場合、日本では（失職などという重大な形では）責任を取らないのでは？それが問題の
ような気がします。間違っているでしょうか。相変わらずの長文すみません。

申し遅れましたが、私は私大教員です。大手メーカー出身の教授が多い、と書いた段階
で明らかだと思っていたのですが。（別スレを見て、わかっちゃったような気がしたのです
が、この教授方は、うちにこなければ下請けの（たぶん困ったちゃんの）SEになったのだ
と思います。）

>>415
私大といってもフツー兼業禁止だよ。ちゃんと上司の許可とってんの？
禁止事項になってて取ってないとまぁ悪くても懲戒免職だけど、いいの？

>>414
責任をとって辞めるっていってもなぁ。
そこまでの失敗ってそうそうはないと思うけど。

ＰＭってＰＧほど人材の流動化してるかね？
ＰＧとは違い、皆自分給料に満足してるんじゃないのかなぁ。
年齢の問題もあるだろうし。

>>417
アメリカだと動いてそうだね。
日本では俺の周りでは聞いたことないな。
いわゆるSEの中途入社ですら、あまり聞かない。

大体、「プロジェクト失敗の責任で　クビを切ったor辞められた」となれば、
むしろ「大きな失敗」ととられて、PMの上司の評価も無傷ではすまないからねえ。

プロジェクト失敗を大ごとにしないために慰留した、ってのが多いのでは？

>>417
「デスマーチ」にあるのは、「PMが責任をとって辞める」ではなく、「責任を取らされて、辞
めさせられる」という話でした。もちろん、アメリカでもPM（って言うんですね）は、給料に
は満足しているようです。「高齢で家族があったら転職（クビも）が大変」も同様のようです。
「そこまでの失敗がない」というならわかります。「PGが責任を取って、サービス残業」なら、
納得行かないなーと思ったのです。勘違いならすみません。
>>418 なるほど、そうなのですか。

>>419 （なぜか、入れ違いでした。）
ものすごく説得力がありました。なるほど。この辺は、日本の文化が
強烈に残っているのですね。
（寝ます。）

>>421
ねぇ君、いちいち私生活報告しなくていいよ。（藁

>>422
ねぇ君、いちいち君の心情を吐露しなくてもいいよ。（藁

もしかすると、422さん、423さん以外からは見捨てられたのでは．．．という
気配を感じます。でもまた、「私生活報告」かもしれませんが、もう一つ。
「デスマーチ」は非常に実際的な本だと思いますが、いろいろあるデスマーチ
の対応策には、「社内の有力者に助けてもらう」（p53）とか「若くて、未婚で、
非社会的（たぶん非社交的ですね）で、仕事一途の技術屋を多く雇う」（p194）
などとあって、ちょっと暗くなりました。それで今XPを読みはじめたのですが、
こちらは、「PGにとってのソフト開発」のようで、希望が出てきた気がします。
「デスマーチ」では「1週の労働時間は60から80時間が適正」（p104）として
いますがXPでは「60時間も働いてはいけない」とありますし。XPの言う40時間
は日本では難しい気もしますが。（勘違いならすみません。）
「デスマーチ」に関連して、もう一つ質問をさせていただけるでしょうか。
この本では、デスマーチの（おそらく）最大の解決策として、「お客と相談し
ての仕様を縮小（もっとも重要な機能に絞る）」ということを繰り返していま
す。これは本当なのでしょうか。「6ヶ月で終わらせる」と言っておいて、
「終わりそうもないので、機能を減らして下さい」などと言えるのでしょうか？
アメリカの特殊事情でしょうか？嫌な質問かもしれません、まだ見捨てていない
方がおられましたらお願いします。

>>424
特殊事情とかじゃなく、口八丁手八丁で乗り切れ！ ってことでしょ。

>>424
もう少し読みやすく！！

他のスレ見てきなよ。
そんなギッチりつまった文章入れているの
あなたくらいだって。

そろそろ文章読むのも疲れるよ。

質問は小分けにして一回一つにしてみたら？

XPのペアプログラミングはね。
普通に業務するより疲れるのよ。

こっそり休憩とったり出来ないから
それを日8時間以上連続でしたら
本当に倒れちゃうよ。
だから、XPで40っていうのはある意味正しい。

というか週80時間、通常労働者の二人分なんだけど
そんなの適正なわけないっしょ。
給料、倍出してくれるんですかねえ。

デスマーチってそんなことばっか書いてるの？
読む気なくなるなあ。

>>426
「デスマーチ」にはンなこと書いてないと思う

.>>424
客に
　「期限までに仕様決めてくれませんでしたよね」
とか
　「仕様変更がこれだけあったから、何日分ロスしたんですよ」
とかを、やんわりと説明するとかだな

>>424
オレのところでは原因がある方が責任を取るなんて道徳はない。
開発手法なんてのは参加者の同意がなければ役にたたない。
頭を使う気のない客に無理に使わせようとしてもロクなことないぞ。

>>424
>「終わりそうもないので、機能を減らして下さい」などと言えるのでしょうか？

言えます。
リリース時期が最重要項目の場合はそうするのがベストだと思います。
減らした機能を段階リリースにするのか、やらないのか、
有料なのか、無料でやるのかは、それぞれの状況で変わると思います。

>>424 >>426 >>427
「1週の労働時間は60から80時間が適正」は、「適正」という言葉が正しい
要約ではなかったようです。すみません。そもそも「デスマーチ」の主題か
らして「適正」という言葉は出てこないはずでした（たぶん）。
ただ、図4.1近辺では、やはり「若くてやる気のあるPGは60-80時間働くのが
よい」というように読めます。書き方が微妙ですが。この辺を読んだ管理者
はそう思うのでは。p104-p105
でもおもしろいし、参考になる本です。対策が必ずしもPG寄りではないと
思うのですが、それがより参考になるような気がします。
>>425 >>427 >>429
「機能の縮小はある」という回答ですね。ありがとうございました。
>>428 そうですか。わかるような気もします。
なるべく長文にならないようにしているのですが、すみません。

2chはすごいことになっていたのですね。リアルタイムでソースが変更され
テストされていたなんて、気がつかずにおしいことをしました。

>>430
「デスマーチ」p104-p105を読み返したのですが、「60時間+アルファ
がよい」と言っているのですね。そしてアルファの許容範囲が20時間
まで。不正確なことを書いてすみません。

>>424
そもそも基本的に週40時間しか働いちゃいかんと法律に書いてあると思われ。

>>432
それ本当ですか？
地方だと、週休２日でない会社なんて珍しくないんですけど。

>>433

労働基準法 第32条(労働時間)
(1) 使用者は、労働者に、休憩時間を除き１週間について40時間を超えて、
労働させてはならない。
(2) 使用者は、１週間の各日については、労働者に、休憩時間を除き１日に
ついて８時間を超えて、労働させてはならない。

まぁ、この後にいろいろ抜け道が書いてあるので絶対ではないけど。
だから「基本的に」と書いたんだけどな。

> 「終わりそうもないので、機能を減らして下さい」などと言えるのでしょうか？
終わりそうもない場合、いつかは言わなければならないことです。
ちなみに機能を削るだけではなく
「終わりそうもないので、全機能を実装するのにあと○ヶ月かかります」
と納期を延ばしてもらう場合もあります。

＞＞４３５
ここらへんは結構、開発側の言い分が通るというか。
・本当に終わることか終わらないことか（知識がないため）客には判断できない。
・他の発注先を探すことが予算諸々の関係から事実上不可能。

>>425 >>427 >>429 >>435 >>436 ありがとうございます。
「受注」に基づく仕事の場合、重要な点は、「同じお客さんから再度（以上）
仕事を取りたい」ということではないかと思います。「機能を縮小したい」
「納期を延長したい」と言うときのリスクは、その件は済んでも、それ以後
仕事が来なくなるかもしれないということですよね。これは、ケースバイケ
ースだと思うのですが、案外大丈夫なものなのでしょうか。それとも、もう
「打ち切り」のつもりで申し込むのでしょうか。あるいは、一度ソフトを納
入すると、メンテがあるので、結局続けられるのでしょうか？
書いていて、本当に嫌な質問だと思います。答えてもよかろうと思う方だけ、
お願いします。叩かれても、無視されても仕方ないとは思います。

>>434 なるほど。労働基準法って不思議な法律ですね。（法律全般？）

>>437
一度転職してみたらいんじゃないかな。

>>437
失敗の程度や人間関係によると思われ。
ただ、それほどドライではないんじゃないのかな？
新規に仕事を受けて、失敗しても「まあ新規業務だから」と
大目に見られ、その業務を長く続けていけば、新規に
発注元を探すデメリットも向こうは知ってるから、こっちを
打ち切って他を探すということもないし。

割りと気の長いお客が多いような。

>>437
> 仕事を取りたい」ということではないかと思います。「機能を縮小したい」
> 「納期を延長したい」と言うときのリスクは、その件は済んでも、それ以後
> 仕事が来なくなるかもしれないということですよね。
まぁ、残業／徹夜をしまくり、納期直前になって「駄目でした」と言う方法もあります。
この方法は上手くいった場合、問題はありませんが
上手く行かなかった場合、大幅な信用低下を引き起こします。

「機能を縮小したい」と言っておく方法はうまくいく確率も高いですが
信用も低下します。

ハイリスク・ハイリターンを取るか、ローリスク・ローリターンを取るか？
私は後者を取ります。

>>437
> 仕事を取りたい」ということではないかと思います。「機能を縮小したい」
> 「納期を延長したい」と言うときのリスクは、その件は済んでも、それ以後
> 仕事が来なくなるかもしれないということですよね。
まぁ、残業／徹夜をしまくり、納期直前になって「駄目でした」と言う方法もあります。
この方法は上手くいった場合、問題はありませんが
上手く行かなかった場合、大幅な信用低下を引き起こします。

「機能を縮小したい」と言っておく方法はうまくいく確率も高いですが
信用も低下します。

ハイリスク・ハイリターンを取るか、ローリスク・ローリターンを取るか？
私は後者を取ります。

>>439
なるほどそうなのですか。435さんと同趣旨とも言えますね。
>>440 （>>441）
納期直前になって「駄目でした」と言うのがハイリスクですよね。
やはりこれは相当厳しいですよね。

嫌われ者ついでに言ってしまうと「少々無理をしてでも仕事を取って、あと
は人間関係を作る」というやり方が結構有効ということなのでしょうか。
失礼ですみません。（すると、営業さんの力が大きいですよね。）

（ばれればクビかものアルバイト？）私のHP作りは、まず「受注」が大変で
した。コネです。それで、行ってみると「PCの調子が悪いのでまずそれを見
てください」というHPとは全然関係ない話になってしまいました。もちろん、
本当のプロの仕事と比べるつもりはありませんが。

>>442
ＯＳがらみのクレームは多いっす。
つーか知らんちゅーに

割り込み失礼

プロってのはもらったお金に見合う仕事に責任もつ人と思ってます。
結局、そうしていかないと飯食っていけないことを知ってる人。
どんな職種でもだいたい同じじゃ？（プロじゃない給料泥棒がいっぱいいるのも同じ。）

プログラム言語の知識なんて、ようはABCじゃないかな。
学校では、プロとしての経験を積んでいくための基本の道具としてしっかりと
基礎を教えてあげれば良いと思いますがね。。。
（１の趣旨じゃないようですが）

「初めて出会う困難を解決できる能力」というのを学校で教えるのは
難しいと思いますよ。
簡潔なプログラムを書くのは重要ですが、なぜそれが重要なのかを
「教えて」られて知識として持っていてもたぶん意味がない。
怒られて、あやまって、後悔して、覚えるんじゃないか？みんな。

あと、重要なのはプログラムじゃなくて、仕様、ドキュメント、
客の満足、金、飯、睡眠時間、、

追加、

基礎がなくて応用はできないですよね。
あたりまえですが、学校は基礎を教える場所としてはピッタリですよね。
下手に「実践ぽい」ことをやる時間があったら、基礎でしょ。

広く浅くしっかりと基礎を教えてあげるのが、
もっとも学生のためだと思いますよ。。。

いろんな常識がベースにあるってのは、重要です。

>>444
「基礎」が何かを明記した方が良いと思うよ。今の書き方だと、解釈
の余地が広すぎてなんとも。

あと、なんとなく学生さんの書き込みって感じがしたんですが、気の
せいでしょうか？

>>443
Winの再インストールをやらされました。
当然客先にCDはあったのですが、CDキーが記録されておらず、それを探すところから。
>>445
「学校教育はいかにあるべきか」というのは、やはり別スレ（板？）の方がよいかも
しれませんね。
>>446
同感です。m(__)m

前に請負ソフトとパッケージソフトの話が出ました。私は「中小が好き」という理由
で「請負ソフトに興味がある」と書いたのですが、いわゆる中小（ごめんなさい）で
もパッケージソフトの開発というのはあるのでしょうか。そのようなスレを見かけた
ので。
開発はできるかと思うのですが、流通に乗せるのが大変なのではと思うのですが。
（私聞いてばかりですね。こんなんでよいのか．．．と思うこともあります。）

>>447
まず「中小」てのを定義しろよ。

>>448
細かすぎると話が進まないと思われ。
「中小」が中企業でも弱小でも零細でも構わないよな話題やし。

#include<stdio.h>
void real(int ike);
int main(void){
int a;
int b;
printf("歳いくつだｺﾞﾙｧ\n");
　　scanf("%d",&a);
if(a<7)b=0;
elseif(a<13)b=1;
elseif(a<16)b=2;
elseif(a<19)b=3;
elseif(a>18)b=4
real(b);
return b;
}
void real(int ike){
if(ike=0)printf("幼房ﾊｱﾊｱ");
elseif(ike=1)printf("小房ウザし");
elseif(ike=2)printf("厨房逝ってよし");
elseif(ike=3)printf("工房寝テロ");
elseif(ike=4)printf("マルチでヌイテロ");
}

>>450
１．real関数内のifが代入になってます。
２．main関数,real関数の最後のelse if (..)は、単にelseで良いです。
３．main関数のb=4のあとセミコロンが抜けてます。
４．elseifはelse ifでないと正しくparsingされません。

☆　総評：納品する前にチェックする習慣をつけましょう。

>>450
テーブル使えよ、学生ウゼ

>>450

>>451の批評は「プロ以前」の問題点を列挙したに過ぎません
あとの問題点としては
・scanf()のチェックをしていない
　数値以外の入力をされた場合、エラーとすべき
・main()で使われている変数名がa, bと意味不明の変数を使用している
・即値をつかうな。#defineかenumでを使ってわかりやすい名前にすべき

ソースレビュー結果：作り直し

>>450
行単位で稼ぐヤツウゼェ
#include<stdio.h>
void real(int ike);
int main(void){
int a;
int b;
printf("歳いくつだｺﾞﾙｧ\n");
　　scanf("%d",&a);
b = a / 3 -2;
if(b < 0)
b = 0;
else if(b > 4)
b = 4;
real(b);
return 0;
}
void real(int ike){
char *msg[] ={"幼房ﾊｱﾊｱ","小房ウザし","厨房逝ってよし","工房寝テロ","マルチでヌイテロ"};
printf("%s",msg[ike]);
}
>>452
一行レスで口だけのage厨は450の3億倍ウゼェェェェェェェェェェ！！

>>447
うちは基本的に請負の会社だが、今俺はパッケージソフトを作ってる。
つーか、納期明日。
ヤバイけど、２ｃｈに書きこんでる。
逝った方がよさそうだな…
ちなみに流通に関しては上司が全部やってて俺は知らん（意味ねぇ）
でも雑誌社とかに持っていって掲載してもらうとかってやってたぞ。

void 鬱だ(){
printf("鬱だ");
氏のう();
}
void 氏のう(){
printf("氏のう");
鬱だ();
}

>>454

int getNenrei(void);
int dispMsgString(int v_id);

int main(void){

int num1 = 0;
int num2 = 0;

// 数字の取得
num1 = getNenrei();

// 判定
num2 = num1 / 3 - 2;

if(( num2 < 0 ) && ( num2 > 4)){
return 0;
}

// 表示
dispMsgString(num2);

return 1;
}


getNenreiとdispMsgString は誰かに作ってもらおう…。

>>475
１．
> if(( num2 < 0 ) && ( num2 > 4)){
ここは&&ではなく、||です。
２．num1,num2は、あとで再代入されることが明確であり、=0の
　初期化は不要です。
３．dispMsgStringの引数の変域が仕様化されていないので
　このあと引き継ぐ人は、このソースを読んで解析しなければ
　なりません。

☆　総評：上記の２．３．はともかく、自分が請け負ったのが、
　プログラムの一部だからと言ってテストもしていないものを
　納品するのはやめましょう。

>>458

はずい…。

変数の初期化って意味なくやってしまうけどそれじゃあダメなのかなぁ

>> 459
> 変数の初期化って意味なくやってしまうけどそれじゃあダメなのかなぁ

初期化を忘れずに行なう習慣は非常に大切です。ただし、０を
無造作に放り込むことが初期化であるわけではありません。

int num1 = getNenrei();
int num2 = num1 / 3 - 2;

これも初期化です。

>>447
情報システム板でやってみない？
http://mentai.2ch.net/infosys/index2.html

プログラム談義も楽しいですね。いろいろ参考になりました。
>>454
char *msg[] =...
を
static const char* const msg[] = ．．．
とはしませんか。（constはうざすぎ？）

>>455
ありがとうございます。なるほど雑誌広告ですか。広告の値段って知りませんが、実は、
目が飛び出るほど高い．．．のでもないそうですね。納期がんばってください。

>>461
情報システム板の存在を知ったの最近です。そちらの方が適しているでしょうか？
（うざいからあっちへ行け．．．だったりして。（涙））話題がよくなければ、考えます。
もし、本気のご提案でしたら、新スレを立ててもよいですが、一人で2つも立てたら、ひん
しゅくですよね。

ところで、情報システム板の住人はSEさんが多いのでしょうか。こちらの住人とだぶって
いるのでしょうか。案外ここが気に入っているのですが。

>>459

最近のコンパイラは「変数を初期化する前に使用している」ミスを検出
する機能がついてますが、変数を意味なく 0 で初期化すると、その機能
を殺してしまいます。

>462
んにゃ
こっち来ない？って意味
開発プロセスについてとか、デスマーチ・プロジェクトをどうやって管理していくかなんて話題は
情シス板のほうが良いかなとは思う。

情シス板には現役SEが結構いると思うよ。
それを目当てに、就職活動中の学生がスレたてまくるぐらいに。

ただ、このスレもなんだかんだで結構レスついてるしねえ。
無理に移動することないけど、いいネタがあったら向こうにも来て下さいな。

>>462
> static const char* const msg[] = ．．．
> とはしませんか。

しますね。あとは、UNICODEや多言語化のことも考えたりすると
もっと良いです。（e.g.表示文字列をプログラム上に埋め込まない）

☆　総評：基礎はできていますが、実践経験が不足しているようです。

しかし誰もscanf()には突っ込まんな。

>>466
> しかし誰もscanf()には突っ込まんな

１．scanf()で直接、int型の変数にデータを受ける危険性について言っている。
（つまり、scanfで文字列bufferにいったん格納して、そこから変換すべき）
２．scanf()の返し値をチェックしていないことを言っている。
３．エラーリカバリのことを考え、scanf()自体使うべきでないと言っている。

☆　総評：気がついた人が自ら突っ込みましょう。

>>454
関数の頭でchar[]は素直に毎回スタックに確保かな?
staticがいいかどうかはともかく。
b = a / 3 -2; も嫌い。なんで演算に？
あとはdispXXXよりは、getXXX + printfが好きだな。

プロ初級　　寝ながらキーボードを叩くがデタラメの文字列を打ちこんでいる
プロ中級　　寝ながらちゃんとしたプログラムを書いてしまう。
プロ上級　　寝ながらデバッグまでしてしまう。

2chを見ながらコード書きながら頭の中で同時にデバッグすれ

ITASK

プロ最上級　寝ているとコビトさんがデバッグまでしてくれる

>>468
> b = a / 3 -2; も嫌い。なんで演算に？

正論ですね。この手の処理で、計算式を使い、一見シンプルになったと思うのは、
単なる錯覚にすぎません。if〜else if〜elseを並べてあるほうが、仕様変更に
対してはるかに柔軟でしょうし、それが正常な感性というものです。

☆　総評：短いコメントのなかに、豊富な実戦経験を感じさせます。
　私は、出来ることなら、あなたのような人と一緒に仕事がしたいです。

　　∧∧?
　¶( ﾟДﾟ) =3 　>>473 文系卒？
　ゝ| つ日~~
　（,|/　 ）
　　U U

　　　∧∧　　　／￣￣￣￣￣￣￣￣
〜''~（,,ﾟДﾟ）　＜　もう、新米ちゃうでｱｰﾀ
　 UU'UU　　　　＼＿＿＿＿＿＿＿＿

>>454のｺｰﾄﾞは可読性ﾜﾙｼ

>>464
そうでしたか。ありがとうございます。やはりスレを2つたてるのは、ちょっと
考えてしまいますので、当面はこちらに書き込みします。もちろん、情シス板も
見させていただきます。こちらもときどき見にきてください。
今はXPを一生懸命読んでいます。（ちょっと難しいのですが。）

>>465
ご指摘ありがとうございました。

最近「名前」の書き込み欄に自動で前のハンドル名が入らなくなりましたね。
本名を書いてしまいそうでびびります。（やはり学校に知れるとちょっと。）

>>474
>文系卒？

残念ながら私は、理系です。私はプログラマに本当に必要なのは、自分の
プログラムの仕様を他人に明確に伝えるドキュメンテーション能力だと
考えています。もちろん、基礎となるプログラミング能力が無ければ話に
すらならないかも知れませんが、ひとりの生産性というのは、せいぜい、
300KB〜1MB/月ですから、どうしても分業制になってくるのです。

よって、自分の設計したクラスの仕様、階層関係、依存関係、責任関係、
プログラムフローについて明確に書けない人間は多人数のプロジェクト
に参加する資格はありません。そうは思いませんか？

XPよりCMMのほうが受け入れられやすくない？

>>477
どうみても理系じゃないよね。
300KB〜1MBってなんだよそれ。あんまり意味ないけどフツー行数だろ。
バイナリサイズか？そんなもん見てどーすんだよ。

>>478
CMMやるためにはしゃれにならんくらい費用と期間と人材と知識が必要。
だから受け入れられにくい。
XPは、とりあえずやってみることができる。
ペアプログラミングとかは置いといても、「まずテスト」とかは
いつでもできるし。っていうかJUnit楽しい。

gnuだとバイナリサイズ∝仕事量じゃない？
ＶＣだとｂｍｐファイルが含まれるから　いくらでも水増し可能。

>>481
バイナリサイズだと、関数部分の展開とかループの展開とかで
水増しできてしまうからgzipとかで圧縮したので比較するのが
良いかも。

>>481
これだから文系は…
これコンパイルしてみろよ。
int x[1000000] = {0};
main() {}

そうかｗ　忘れてたｗ

でも、この前面接した会社の採用担当が、作ったプログラムの
バイナリサイズ聞いてきたのには面食らったぞ。
「小さいですねえ」とかほざいてた。　爆

　　　∧∧　　　／￣￣￣￣￣￣￣￣
〜''~（,,ﾟДﾟ）　＜　ソースコードのテキストサイズじゃねえ？
　 UU'UU　　　　＼＿＿＿＿＿＿＿＿

つまらんところで煽るなよ。

>>473>>477のｶｷｺ

生産性をKBとかMBとかで図るのはどうかと思うが
ま、前前からこのスレで語られているように
定量的に生産性を図る手段が無いので仕方あるまい。

他はまちがてないYO

XPはいいね。WindowsXPも思わず購入してしまいそうだ。(w

>>479
>300KB〜1MBってなんだよそれ。あんまり意味ないけどフツー行数だろ。

そんなことはありません。ステップ数(処理単位≒行数)で計るところもあれば
ソースコードのサイズで計るところもあります。ソースコードのサイズのほ
うが、ステップ数よりは正確に生産量を反映しますので、私はそちらを採用
しています。あくまで目安にすぎませんが。

☆　総評：ろくに業界経験の無い人間が知ったかぶりをするのは、見苦しいです。

>>486
> 生産性をKBとかMBとかで図るのはどうかと思うが
> ま、前前からこのスレで語られているように
> 定量的に生産性を図る手段が無いので仕方あるまい。

暖かいフォローありがとうございます。その通りです。

>>477
おもしろい話をありがとうございます。それで、もしよろしければ、「歳いくつだ
ゴルァ」プログラムの改良版（の一部でも）に関して、「仕様、依存関係、責任関係、
プログラムフロー」（の一部？）などのドキュメンテーション例をお見せしていただ
けないでしょうか？2chでは「叩き」があってやりにくいかもしれませんが、たぶん、
こういうものについて、「プロの例」を見たいと思う人は（他のプロの方も含めて）
案外多いのではと思うのです。ぜひ。m(__)mもちろん、他の方でも。

>>478 >>480 >>486
個人的にはXPの次にCMMも見てみたいと思っています。
XPはとても面白そうなのですが、何度読んでもよく意味の取れないところがいくつか
あります。たとえば、「第15章計画戦略」はぜひ理解して、実験してみたいのですが、
どうもはっきりわかりません。こんな感じでしょうか。

１．ストーリー（外部仕様？）をカードに書く他（探検フェーズ）
２．ストーリー・リスクを分類他（コミットフェーズ）
３．イテレーション他（運転フェーズ）

3のイテレーションとは（主に）次のフェーズからなるもの
　　A．タスク（ストーリーより細かいもの）をカードに書く他（探検フェーズ）
　　B．タスクを受け入れる他（コミットフェーズ）
　　C．タスクを実装他（運転フェーズ）

ここで1、2、3を繰り返してコードを書いていくが、１度の繰り返し内で3内のA、B、C
も繰り返す（つまり2重ループのような構造）．．．というような意味でしょうか？
（各「繰り返し」の最後には、計画の再検討もあるわけですが、上では省略しました。）
わかっている方がいたら教えて下さい。

私、バカ丸出しでしょうか。

>>487
おいおい、300KB〜1MBっていうソースの量分かって言ってんのかよ。
やっぱりどーみても文系だな。

>>488
>もしよろしければ、「歳いくつだゴルァ」プログラムの改良版に関して、
>(snip) ドキュメンテーション例をお見せしていただけないでしょうか？

具体例を示せなくて申し訳ないですが、あのレベルのプログラムならば、
関数単位での処理内容・入出力関係・使用上の注意点を明確にしておけば
それで十分だと思いますよ。

>>489
>おいおい、300KB〜1MBっていうソースの量分かって言ってんのかよ。

当然、わかっています。

☆　総評：自分が出来ないから他の人も出来ないと考えるのはやめましょう。

>>491
なんだWordのファイルとか含んでんだな。それじゃ>>481のとーりだな…

>>492
>なんだWordのファイルとか含んでんだな。それじゃ>>481のとーりだな…

含んでいません。ソース中のコメントは含みますが。

☆　総評：頭の悪い邪推をしている暇があったら、どうやれば自分がそれだけの
　スピードで開発できるようになるのか考えてみましょう。

>>493
うーん、俺は1日に2000行書けば多い方だなぁ。ソースばかり書いてるわけじゃ
ないから月に20000行以下くらいしか書いたことないが。ちょっとみたら1行平
均30byteほどで600KBだな。ま、あながちウソじゃなかったってわけか。

目安は目安だからな。新規/流用いろいろあるし。
Get/Set書くのも、アルゴリズム/データ構造組むも仕事のウチだ。
>>1
クラスの仕様/階層関係/依存関係もろもろ、専門用語っぽく聞こえるが
要は、客が何をつくって欲しいのか/自分が何を作ってるのか理解して
それを言葉なり、文書なり、ソースに表現するということだ。

学校では、開発手法やツールの表面的なところでなく、自分の頭で考えて
そいつらをうまく選んでつかい分けていく感性を磨いて欲しい。
ありあまる時間にまかせて、なるだけ着実な方法で。

要は、教師が全てを教えてやれなくても環境を作ってやる、ということだ。
どうせ現場のやつだって一から十まで知ってるわけじゃないからな。
プログラミングのプロでなくプログラミング教育のプロになることだ。
そしたら漏れが教えを請いにいきたいね。

>>494
頭使わずにコード打ち込んでればいいだけの人はいいね。

それなりのプログラム組んでると１日100行とかがやっとだ。
調べものとかで１行も組めない日もあるし。

>>496
コーダーってやつ？そんな職種が未だにあるのかは知らんが、漏れは仕様書
書くのが苦手で考えながらしかコードが書けないんだな。ただ打ち込むだけ
なら2000行って分けはないだろ。タイプはあまり早くなくて７文字/秒くらい
しか打てないんだが、それでも1日打てば5000行は楽にいくだろ。ただの打ち
込みなど頼まれてもやるつもりはないがな。

>>496
>それなりのプログラム組んでると１日100行とかがやっとだ。
>調べものとかで１行も組めない日もあるし。

これは、その通りです。分野によっては、１ヶ月ずっと調べものということ
もあります。そういうのも大切なプログラミングの過程だと思います。
（これは新人君が、うんうんうなって、手が進まないのとは意味が違います）

>>497
漏れは日に12000行入力したことがあるな。
もう二度とあんな仕事はしないと思うが。

まともなプログラミングで常に月20000行っつーペースを維持してたら
それこそスーパープログラマだろ（ｗ
ちょっと古い数字かもしれんが、Ｃで単体試験込みの一般的月産は
3000ステップという目安があるな。このデータにもいろいろ思うところ
はあるが。

　∧ ∧　 　／
　(,,ﾟДﾟ)　＜　ソースのバイト数で測る方法結構いいかも
　 |つ つ　　＼ 行数よりかは。だが。
〜 　　|
　∪ ∪

今、VBで1・２日で急ぎで作ったファイルを確認すると
22KB,700行程度だった(ソースコピペも5KBくらいはあるが)
月に1MBはいかんが300KBならギリギリなんとかなりそうだ。

ﾃﾞﾊﾞｯｸﾞ工程ではソース増加はないから実際は絶対いかないだろうが。

それに人の引継ぎ仕事だと
ソースがざくざく減ることは多々あるし。

月の製造物量をふやそうと思ったら設計者（顧客直を含む）
からひたすら目標物像ききちぎり、意識すり合わせてからでないと
行で5000も10000もつくられへん。
どーしても聞き込み調査の時間が発生するし。
以前に共通部品化するもんがあるから頭打ちがあるし。

http://www2.csc.ne.jp/~rei_tricks/deai.htm
ここ見ろよ。かなりたくさんの情報が載ってるぞ！

　　　　　　　　　　　　∧ ∧
　　　　　　〜′￣￣(ﾒﾟДﾟ)つ
　　　　　　　 UU￣￣U
＿＿＿＿＿＿∧＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　>>502　ブラ蔵　逝ってよし

見たな・・・・ニヤリ

無限JavaScript警報
だって

　　∧ ∧　　ｶﾀ　　　　　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣
　　(,,ﾟДﾟ),＿＿ｶﾀ＿　_＜　>>502　ブラ蔵　逝ってよし,,,と。
　 ./ つ＿||￣￣￣￣￣|　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　（,　　|＼||　 BIBLO 　 |
　 　 　'＼,,|==========|

>>501
あ〜あ〜、そんな仕事したくねーな。自分の思い通りの作れないなんて悲しいね。

>>507

プログラマは悲しいまでに仕様書に忠実にプログラムするのが仕事です。
それが出来ないのなら、企画業や、経営者になって、プログラムは趣味で
やることです。

☆総評：自分の好きなプログラムだけしていたいというのは、いつまでも
　大人にはなりたくない、というピーターパンシンドロームにも似ています。
　青臭い夢からは、早く抜け出すことです。

>>508
そんな程度が夢なの？
漏れは自分の思い通りに月20000行なんだが。かわいそうに。

>>509
発注丸請けの仕事を一人でやってるのですか？
うらやましーね。

>>508
仕様に問題があってもこっそり直されたりしてプログラマの責任になる。
修正を求めたら侮辱されたと思って憤慨するバカ。
何も言わなかったら指摘しなかったことで結局責任をなすりつけられる。

それはそうと、どんな処理系でプログラム書いてるかによってコード行数全然
違うよね。

VC++だとウィンドウ開いたりボタン置いたりでコードが増えるのにC++Builder
だと１行もコード書かなくていいし。
MFCも使わずにSDKでぐりぐりやると素のウィンドウいっこ作るのに30行くらい
書くよね。

>>509はアセンブラで20000行/月？

>>507
業務プログラマとして至極当たり前のことをﾔﾃｰﾙつもりだが？
仕様通りを踏まえてりゃ好き勝手作るの（・∀・）ﾏﾝｾｰ!!
あと>>508の前半とＳヨと対峙した時の>>511も同感

口出しすることはないのでおとなしくしてます。
ただ、みなさん、話し合ってみれば、それほど違わない事を言っているのでは？
私は、一度20000行のプログラムを書いてみたいものです。

>>511 雰囲気が伝わります。

>>508
外部仕様が明確に規定されている場合でも、内部の実装は一通りではないよね。
そこにプログラマが労力をつぎ込む余地がある。

もしかして >>508 の仕様書には private な関数や利用するデータ構造・アル
ゴリズムレベルまで詳細に書いてあるの？　私は、そんな仕様書は見たことない
けどなぁ。

>>515
>外部仕様が明確に規定されている場合でも、内部の実装は一通りではないよね。

もちろんその通りです。誰が書いても同じ、ということは決してありませんし、
そこに能力差や個性は常に反映します。

しかし、外部interfaceが規定されている限り、その自由度は非常に低いと思
います。データベースのプログラミングを、MIDIサウンドのプログラミングで
代替することは出来ません。当たり前のことのようですが、そのもどかしさに
耐える覚悟が無いのなら、仕事でプログラムをするな！と言いたいのです。

☆　総評：To be a programmer or not to be...That is the question.

>>516
やっぱり文系だね。
データベースの実現なんてそれこそいくらでも方法があるのにね。
あ、アクセスとかありモノのGUIつくるだけか。悲しいね。

>>517 漏れ最近このスレ退屈なんだけど。できれば >>488 くらいまで戻りたい。

>>488 より前のレスはあまり覚えてないけど、とりあえず今確認した。
｢第15章計画戦略｣は｢XP エクストリームプログラミング入門｣の15章だよね。
このシリーズは訳本3冊でてるけど、個人的には前の2冊はあまり文書の構成
とか、日本語の表現とかよくないと思うのだ。訳者には悪いけどな。

なんで、3冊目｢導入編｣から読むことを激しくお勧めします。

あと、、
イテレーションのイメージをわかせるには｢エクストリームプログラミングFAQ｣
とか本家extremeprogramming.orgにある図を見たほうが早いと思うなぁ。
外出ならスマソが。

>>516
> しかし、外部interfaceが規定されている限り、その自由度は非常に低いと思
> います。
「思う」って、もしかして実際に設計工程に携わったことないのでしょ
うか？

>>519
>「思う」って、もしかして実際に設計工程に携わったことないのでしょうか？

もちろんあります。しかし、「自由度が低い」と思うかどうかは、本人の
自覚の問題でしょう。517のように、「データベースの実現なんてそれこそ
いくらでも方法があるのにね。」と自由度の低さを感じない人もいます。

実際のところ、OracelやSQL ServerにSybaseやInforminxにDB2、
何で実装しようがデータベースに対するプログラミングには違いないです。
いろんな実装方法があって、それを取捨選択できるから「俺は自由に
プログラミングをやっているぜ！」と思うのは錯覚にすぎません。
私はそう“思い”ます。

しかし、そう思わない人もいるのも事実です。そう思わない人のほうが、
仕事でやらされているという精神的な負担が無い分だけ楽なのかも知れません。

☆　総評：４畳半の部屋を広いと感じるか狭いと感じるかは、人それぞれだ。

>>520
「実装者の裁量＝使用する RDBMS の選定」なんて思ってるのは、あなただけ。

>>521
>「実装者の裁量＝使用する RDBMS の選定」なんて思ってるのは、あなただけ

それは実装者に与えられるかも知れない裁量の一例にすぎません。
「Ａ⊂Ｂかも知れない」と「Ａ＝Ｂ」は全然意味が違います。

☆総評：もう少し日本語を勉強しましょう。

>>522
書き方がまずかったかな。

実装段階でプログラマが使用する RDBMS を選定することは、まずありません。
プラットホームや RDBMS に関しては、設計段階で確定します（新規開発でなけ
れば、ほとんど選択の余地はありません）。

まぁ何にせよ、スレッドの趣旨から外れきってるので、このあたりで幕にしま
しょう。

方向転換の方向で。

DBを使った参照系プログラム(画面あり)限定でDQN判定。
１：SQL発行→データ取得＆表示
２：SQL発行→データ取得＆格納→格納データから表示

これで２を踏まえないやつは実践配備されなくていい。（いやまぢで

>524
>DBを使った参照系プログラム(画面あり)限定でDQN判定。
>１：SQL発行→データ取得＆表示
>２：SQL発行→データ取得＆格納→格納データから表示

うーん、問題提起がおおざっぱすぎる気がする。
2は、単に問題を複雑にしているだけとも言えるし、そもそも表示画面で
SQLを発行するなという考えもあるし。

2が圧倒的に優位である理由は何？

>>525
Web+DBだったら２の方がよかったりして。

>>518
情報ありがとうございました。3冊目読んでみます。HPも。
（ただ現在は2冊目です。それで少しわかってきました。488で書いたことは
「当たらずとも遠からず」「遠からずとも当たっていない」というところで
しょうか。3冊もあるなら、もう少し安い本だといいのですが。^^;)

>>524 >>525 >>526
個人的にはDB関係とても興味があります。DBスレもROMしてますし。
できればオバカにもわかるよう、具体的に書いていただければ、感謝感激です。
（DQNってドキュンってことですよね。）

>>527
2400yenで2倍の厚さ。(-_- )
ここに一部日本語訳みたいのあるよ。訳者のレベルは知らんけど。
まぁ、とりあえず図でも見てくんなさい。
ttp://product.uis-inf.co.jp/playground/yyamano/www.extremeprogramming.org/

わりと断片的に。>>525＆>>527
＜前提＞
>DBを使った参照系プログラム(画面あり)限定でDQN判定。
>１：SQL発行→データ取得＆表示
>２：SQL発行→データ取得＆格納→格納データから表示
に
「これで２を踏まえないやつは」がある。

＜大事なコト＞
「仕様変更が来ても大丈夫か？」っていう点。
（スパゲティにならずにすむか？っという意）

＜普遍的な現実論＞
データ表示プログラム　→　見栄えが第一　→　表示形式の若干変更なんてのはザラ
えらいことになると、「表示レイアウト変更」なんてのも想定しとかなあかん。
これを「SEがアホー」って言って責任転嫁はできるが、できたからといって
現実の時間が融通されることはまずない。（経験者は語る）

＜作業面からの理由＞
「取得」と「表示」を明示的に分けることによって責任の分化ができるためバグ対処しやすい。
　↓
ソース自体がシンプルになれるので記述ミスも見つけやすい。
　↓
後発部隊がソースをおっかけまわす作業の短縮に繋がる。

こんなんを想像できるかどうか。単純なことだけど大した差になるのですよ。

＜余談＞
以上を踏まえている人間なら「取得＆表示」の方法を選択する際にも
利点も欠点も知っているから、「なぜ？」に対しての返答が明確なのだ。
だから技術試験用の捨てプログラムだったらおいらも「取得＆表示」を選択します。

MS-ACCESSだとこうかなぁ
１．パススルークエリーを直接レコードソースにしてレポートを作成。
２．パススルークエリーから select * into temp from パススルークエリー
で一時テーブルを作成し、一時テーブルよりレポートを作成。

一時テーブルを作るとテーブル名が増える為、管理がちょっと面倒。
MDBを共有して使う場合は、テーブル名に考慮が必要。
パススルーを直接レコードソースにすると、レポートデザイン画面を開く時
パススルークエリーが実行されるので、時間のかかるSQLの時は使いにくい。
まぁケースバイケースですな。

>>529
>＜作業面からの理由＞
>「取得」と「表示」を明示的に分けることによって責任の分化ができるためバグ対処しやすい。
>　↓
>ソース自体がシンプルになれるので記述ミスも見つけやすい。
>　↓
>後発部隊がソースをおっかけまわす作業の短縮に繋がる。
>
>こんなんを想像できるかどうか。単純なことだけど大した差になるのですよ。

何か俺と大きな認識の差があるような気がする。
例えばこんな擬似コードを考えてみる。（言語もオブジェクトも適当）

sql = "SELECT Name, Address From User ORDER BY Id";
rs = db.exec(sql);
while (row = rs.fetch()) {
printf("%s %s\n", row["Name"], row["Address"]);
}

これは、パターン１だと思うんだけど、十分シンプルで変更にも強いと思うんだけどなぁ。
この処理をパターン２で書くとどうなる？

>>531
私はデータの取得と格納を分離するかどうかはケースバイケースだけど、
「SQL 文・データの取得ロジック」と「表示系」は分離しておくな。

たとえば、そのコードなら

EnumUserInfoByID(void (*fn)(const char *, int))
{
　　static const char sql[] = "SELECT Name, Address From User ORDER BY Id;";
　　RecordSet rs;
　　RecordRow row;

　　rs = db.exec(sql);
　　while (row = rs.fetch())
　　　　(*fn)(rs["Name"], rs["Address"]);
}

という感じ。

あと上のコードだとテーブル名とか列名を文字列で書いてるけど、実際
には全て定数を定義して使います（定数定義はデータベースのテーブル
作成用の SQL スクリプトから抽出）。でないと、コンパイル時にスペ
ルミスの検出できないから。

〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

ありゃ？

>>531
＞この処理をパターン２で書くとどうなる？
階層管理が非常にややこしく見える。Σ(ﾟдﾟlll)ｶﾞｰﾝ

defineも関数定義もSQLもループもみぃ〜んな囲った所でこんなかんじ
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
// ------------------------
//　データ取得
// ------------------------
bln_Rtn = FncBln_Get_DBData_XX( obj_GetRec ) ;　// obj_GetRecにデータいれて〜
if( bln_Rtn != DefRTN_True )
{
　　// エラー処理 @今回なし
}

// ------------------------
//　取得データ表示
// ------------------------
bln_Rtn = FncBln_Display_XX( obj_GetRec ) ;　　// obj_GetRecを利用して表示。
if( bln_Rtn != DefRTN_True )
{
　　// エラー処理 @今回なし
}
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

Document-Viewアーキテクチャー

>>531
＞何か俺と大きな認識の差があるような気がする。
おいらが「なにわともあれ大きくいうとそーざんしょ」
あんさんが「この場合はどぅよ？」の違いもあるかと思われ。
一般論はあくまで一般論。現実対処になると特化されるのは当然っちゅうのが
伝われば意識もあいやすくなるでしょう。

（>>534のオブジェクト渡す際のこまかいところミスは忘れてけれ・・・）

俺もデータの取得と表示は分けるなー
そうするとメモリ上に持つデータ構造を最適になるように
考えて、結局、処理速度もソースの見易さもよくなると
思うんだよねー
まあ、本当に捨てプログラムなら別にいいけどさー

例えば>>531のコードと>>534のコードを比較してみる。

>「取得」と「表示」を明示的に分けることによって責任の分化ができるためバグ対処しやすい。

責任の分化ができるのは同意するが、バグ対処しやすいかどうかは別問題では？
>>531のコードはバグ対処しづらい？俺はそうは思わない。

>ソース自体がシンプルになれるので記述ミスも見つけやすい。

俺は534のコードより、531のコードの方がシンプルだと思う。
別に534のコードを否定しているわけではなく、複雑化するにはそれなりの理由が
あるから、という主張の方が納得しやすい。
534のようなコードにするのは、それなりの理由があるはず。しかし、その理由は
「シンプルにするため」でも「記述ミスを見つけやすくするため」でもないと思う。

>後発部隊がソースをおっかけまわす作業の短縮に繋がる。

そうだろうか？
>>531のコードより、>>534のコードの方がおっかけやすい？
結果として表示された内容にあやまりがある場合、534のコードは、2つの関数の
どちらかに誤りがある。調べる個所が複数になってしまうでしょ？

さらに言うなら、結果をレコードセットオブジェクトで返すような処理系の場合は、
それを基に、独自のオブジェクトを構築する場合は、そこにバグが発生する確率も
増える。

管理を複雑にするには、それなりの理由があるはずであり、

>＜作業面からの理由＞
>「取得」と「表示」を明示的に分けることによって責任の分化ができるためバグ対処しやすい。
>　↓
>ソース自体がシンプルになれるので記述ミスも見つけやすい。
>　↓
>後発部隊がソースをおっかけまわす作業の短縮に繋がる。
>
>こんなんを想像できるかどうか。単純なことだけど大した差になるのですよ。

という理由は納得できないというのが俺の主張。

そして、管理を複雑にする場合、

・レイヤーを分ける（３階層モデルなど）
・データベース層を抽象化する（永続化オブジェクトモデルなど）

が一般的だと思う。
しかし、それは、メリットがあるから管理を複雑にすると思うんだけど。
で、それは見方によれば「シンプルなモデル」になるかもしれないけど、
>>531のコードに比べて、シンプルか、バグ対処しやすいか、記述ミスを
みつけやすいか、ソースをおっかけやすいか、と言えば、「一般的」に
言っても、一概には言えないでしょ。

だから、問題提起がおおざっぱすぎる気がするし、

>>524
>これで２を踏まえないやつは実践配備されなくていい。（いやまぢで

とは思わない。

>>531にあるような単純なコードは実際には少ないような気がするな。

>>540
そう？
業務アプリは究極的には>>531のコードのような感じのものが多いし、
データ取得にビジネスロジックが入ってるがゆえに複雑なのだ、という
のであれば、「画面でやるな」と主張したいなぁ。

取得と表示を分けておけば、後で３階層にするのも楽だよね。

>>534
データ構造が単純な配列に収まる程度ならなら良いけど、ちょっと複雑
になると、その書き方だと厳しいな。無駄にデータのコピーが発生する
点も、階層を重ねる場合に問題となる可能性アリ。

いずれにせよ、ケースバイケースだと思うぞ。

- その程度の簡単なループでデータが取得できて、しかも他で同じよう
　な取得処理をしない場合なら、表示系のコードに埋めても害はない。
- 数箇所で同じ取得処理を行うような場合には、取得処理だけ切り出し
　ておく。
- 複雑なビジネスロジックを構成する一部分なら、最低でも >>532 に
　書いたような手続きを抽象化するパーツを用意した上で、必要なパー
　ツを組み合わせる上位層を作る（簡単なインタプリタ書くとか）。

簡単な処理しか必要ないのに「汎用的」なコードを書くのは労力の無駄
だと思うよ。最初は必要最小限のコードを書いておいて、汎用的な処理
が必要になった時点で、リファクタリングする、に一票。

>>542
>後で３階層にするのも楽だよね。

後で３階層にするなんて、ほとんどあり得ないと思うけど。
ほとんどあり得ないことを心配する必要はないのでは？
YAGNIで行こう。

>>543
はーい、一票

>>543
俺も弟子にしてくれ。

>>543みたいな無難な意見には、マイナス一票

>>544
サーバー側書く間にクライアント側も書けるしー

>>547
社会人５年氏は一般論がしたいみたいだから、いいんじゃない？
俺は素直に、543の記述能力に羨望を覚えたんだけどなぁ。
弟子にしてくれよー、マジで。

>>549
俺が弟子にしてやるYO!

>>538-539
局所展開されると返答に困る。
なぜなら局所論に対して最初に言い放った汎用論ではズレが多すぎるから。
局所論なら局所論なりの対処がある。
のまえに。

>>541よ。そんなプログラムを実際使う業務アプリなんざみたこたねぇぞ。(;´д｀)
いやprintfのことなんだがな。sprintfなら多少はみかけたが。
あとSQLの煩雑化は作り手のせい。でなくばDB設計者のせい。プログラマはそんなとき戦っておくものだ。
はなしがズレたな。あんま気にしないでくれィ。

>>542 まったくもって同感。
けど実際問題３階層にすると、新人さんは３階層も潜れないという事実に直面したことがあるぞぃ。
「え〜深くて見にくいです〜」って感じでΣ(ﾟдﾟlll)ｶﾞｰﾝ なんのための接頭詞なんだか。

>>543
オブジェクトに全部いれる。それくらいの手間隙はかける。
構造体配列ならもっと安心。（加工という作業が加わるが）
製造時の方法として語られるのには賛成。
汎用的なコード云々の話題の返信として
[あなたの視点に「デバッグ時の工期短縮には何をしておけば役立つか？」を加えとくことをお勧めする。]
っていうのをあてたい。
汎用的な部品テンプレートと作っておいてコピペすりゃ労力問題は回避できるから。
リファクタリング自体極論すれば無駄な作業なのだ。（自己内完結ソース作りにおいてだけど）

肝心の531氏は次。

もういいよ。終了。

>>549
弟子は取っておりませんので、ご了承ください。

それと、私は基本的に一匹狼でやってきたので、人を育てる方法が身に付いてませ
ん。たとえ弟子になっても、得ることはないと思うよ。

>>551
> 「デバッグ時の工期短縮には何をしておけば役立つか？」
徹底的な UnitTest。

>>551
つーか、俺は、無根拠に、

>＜作業面からの理由＞
>「取得」と「表示」を明示的に分けることによって責任の分化ができるためバグ対処しやすい。
>　↓
>ソース自体がシンプルになれるので記述ミスも見つけやすい。
>　↓
>後発部隊がソースをおっかけまわす作業の短縮に繋がる。

てなことを言われても誰も評価できないでしょ？

>>>541よ。そんなプログラムを実際使う業務アプリなんざみたこたねぇぞ。(;´д｀)
>いやprintfのことなんだがな。sprintfなら多少はみかけたが。

究極的には、って書いたんだけど、見落とした？
もちろん、取得するカラムが増えれば行数は長くなるし、
「何か」に設定するのに手順が必要なら、さらに行数は長くなる。

・業務アプリ
・データの取得を画面でする

というのであれば、>>531のようなコードは良く見かけると思うんだけど、
見たことないのであれば、やっぱり何か俺と大きな認識の差があるような気がするなぁ。