あの人じゃないと無理。と言われるレベルの人いる? [転載禁止]©2ch.net

**仕様書無しさん** · 2014/12/27(土) 13:41:19.10

所詮お前らはその他大勢ｗ

**仕様書無しさん** · 2014/12/27(土) 13:52:49.11

ブーメラン

**仕様書無しさん** · 2014/12/27(土) 14:04:38.81

属している組織のレベルの低いところに居て、そんなこと言われて
ドヤ顔しているほうが、かえって恥ずかしい。

**仕様書無しさん** · 2014/12/27(土) 14:57:49.24

>>1

何が無理なのかで答えが変わる。

1. あの人じゃなくて作れないという意味の無理なのか
2. あのひとじゃないと修正できないという意味の無理なのか

1であればレベルは高いってことになるが、
2であればレベルは低いってことになる。

なぜなら2の状態になるのは、コードが複雑でわけがわからない
他人には手がつけられない状態になっているということだから。

**仕様書無しさん** · 2014/12/28(日) 08:59:48.95

学生生活で惨め
社会人になってようやく派遣の底辺の中でデキルやつになってオレは出来る！と思えるようになった人たちが大半なのに>>1はむごい

**仕様書無しさん** · 2014/12/28(日) 09:21:32.15

>>5
俺はむしろ逆だけど。
学生の時、俺はデキルと思っていたけど、社会人になってもっと
デキルやつがいっぱいいるのを知った。

**仕様書無しさん** · 2014/12/28(日) 09:34:44.43

>>6
それは、お前がそれなりに有能だから。有能じゃないと有能な連中がいるところには行けないし、相手が有能であると判断できない。

**仕様書無しさん** · 2014/12/28(日) 10:30:49.12

>>7
なんで、わざわざ「それなり」ってつけるの？
有能だって認めるのが悔しいから？

**仕様書無しさん** · 2014/12/28(日) 14:56:21.34

>>8
お前が無能なのはよくわかる。
もう一度一連の流れをよく読め。

**仕様書無しさん** · 2014/12/28(日) 15:51:48.93

>>8
ばかだね
>>6は自分より有能な人を知っているから>>6に対して単純に有能と表現しても「いやいや・・・」と謙遜する。
だから「それなり」ってくっつけて>>6に有能だよって言葉を受け取らせるやり取り
そんなもんが読み取れないかｗ馬鹿だねｗ

**仕様書無しさん** · 2014/12/28(日) 17:46:38.92

>>8
バカ杉

**仕様書無しさん** · 2014/12/28(日) 18:13:06.28

>>1
「あの人じゃ無理」って言われたことならあるぞ

**仕様書無しさん** · 2014/12/28(日) 18:15:25.24

>>12
・・・どんまい

**仕様書無しさん** · 2014/12/28(日) 19:31:04.18

現実には、
「この仕事は、やっぱり◯◯さんじゃないと！」
なんて言われて依頼される仕事というのは、そういう言葉でこちらを
気分良くさせ断りにくくさせて、責任を押し付けようとしている、
というシロモノのことが多い。
「あの人じゃないと無理」なんて言葉はフワフワしたもので、
それに踊らされるのは、ちょっとバカっていうか、
イノセントすぎるというか、社会人としてワキが甘いというか。
PMなり、リーダー格の人が、こういう言葉を言って、プログラマーに
仕事をさせたいときを考えると、その仕事はたいてい誰にでもできる、
でもメンドクサくて地味であまり評価されない、というか、チームで
脚光を浴びない仕事（誰かが目立つための踏み台みたいな）だったり
するんだよ。
でもそういう仕事を引き受けてやってくれる人も絶対に必要だから、
俺はむしろ、
「この仕事は◯◯さんじゃないと無理だから～」
と言って◯◯さんに気持ちよく仕事をさせて、うまく全体を回すリーダーは
有能だと思う。

**仕様書無しさん** · 2014/12/28(日) 19:54:23.47

○○君すごいんだからっ！
ちょちょっ！ってやったらできちゃうんだから！！

なら年２００回は言われるけど？（ＴｏＴ）

**仕様書無しさん** · 2014/12/28(日) 20:18:26.94

>「この仕事は◯◯さんじゃないと無理だから～」
>と言って◯◯さんに気持ちよく仕事をさせて、うまく全体を回すリーダー

に対してこそ、
「ああいう仕切りは、□□さん（＝そのリーダー）じゃないと出来ないよな」
とみんな、口には出さなくても思ってるものだ。

**仕様書無しさん** · 2014/12/28(日) 20:20:03.13

ニュー即でもでてるゲームプログラマはどっちなんだろうな？ｗ

ゲームプログラムって汚そうｗｗ
腕はいいはずだけどね　相当条件分岐するからね
でもブラゲプログラマはどうだろ？

**仕様書無しさん** · 2014/12/28(日) 22:45:59.24

>>14
周りにいい人材が全くいないんだな・・・
もう少しまともな環境に移ることも考えていいんじゃないか？

**仕様書無しさん** · 2014/12/28(日) 23:11:22.18

>>18
Thanks. but no thanks.

今とても良い環境で働いているので

**仕様書無しさん** · 2014/12/29(月) 01:52:56.58

>>19
「○○はこの人じゃないと無理」と言われるような人がいない職場なんだよな？
かなり技術力の低い職場だと推察できるんだけど
本当にいい職場なのか？

**仕様書無しさん** · 2014/12/29(月) 08:06:57.83

仕様書がなく

あいつ以外コードの中味わからん的な
人なら俺だ

**仕様書無しさん** · 2014/12/29(月) 08:07:19.73

>>20
金とかでしょ
それはそれで仕事だもの　本人が納得してるならかまわないでしょ

**仕様書無しさん** · 2014/12/29(月) 08:08:10.32

>>20
cmmi的にはレベルが低いのでは？

**仕様書無しさん** · 2014/12/29(月) 08:09:01.61

>>21
でも、そーゆーケースでも

担当代わりして、「これできる？」って聞かれて即答できない。
「うーん。あの人じゃないと即答はできないないあ。」とかいうと、その「あの人のレベルが高い」と勝手に相手が思い込む現実ｗｗｗ

いや・・・・・・・レベルが高いのではない。むしろ、とんでもねー引き継ぎ方して逃げていったんだ・・・・・・・・・・。とｗｗｗ

**仕様書無しさん** · 2014/12/29(月) 08:10:48.91

あるあるあ… 傷口を擦らないでくれ

**仕様書無しさん** · 2014/12/29(月) 09:40:51.67

>>20
「○○はこの人じゃないと無理」という状況を作ったらいけないんだよ。

「○○はこの人じゃないと無理」という人がいたとしたら、
その人は、自分以外でも対応できるようにしておかないといけない。
メンテナンスしやすいソースコードにして、技術の底上げをする。

「この人じゃないと無理」という人がいきなり死んだらどうする？
死ぬよりも、病気や転職のほうが確率高いだろうけど
そんなことになったらその会社終わりだよね？

**仕様書無しさん** · 2014/12/29(月) 10:01:06.28

>>20　はちょっと誤読しているかもと思う。

>>19氏は自分の職場が

>「○○はこの人じゃないと無理」と言われるような人がいない職場

とは一言も書いてないし、どこにもそう読める記述は見当たらない。

**仕様書無しさん** · 2014/12/29(月) 10:42:05.40

>>26
もう俺周りに合わせるの嫌だよ。

**仕様書無しさん** · 2014/12/29(月) 10:44:21.24

会社的には誰でも触れるように作るのが正解なのは判る。
でもそういうのを意識して、あれも使えない、これも使えない
てなると何のためにプログラム学んでるんだか判らなくなる。

そういうプログラム出来る人ばかりでチーム組んで
先進的な仕事させたほうが良いと思うんだよな。

**仕様書無しさん** · 2014/12/29(月) 10:46:23.68

トリッキーな書き方をしないというのは、意識して出来るけど
馬鹿にも判らせる技術は誰も持ってないよ。

**仕様書無しさん** · 2014/12/29(月) 11:19:48.63

>>29
> 会社的には誰でも触れるように作るのが正解なのは判る。
> でもそういうのを意識して、あれも使えない、これも使えない
> てなると何のためにプログラム学んでるんだか判らなくなる。

誰でも触れるの「誰でも」が間違ってない？
（技術者なら）誰でも触れるっていう意味なんだけど？

技術者じゃない素人でも触れるようになんて作れないし、
新入社員でも触れるように作るとかありえない。

なんで、そんな新人を甘やかすんだよ？新人様が入ってきました。
新人様でもわかるように作らさせていただきます。へへぇー。じゃないんだからさｗ

誰でもっていうのは、一人前の技術者であれば誰でも触れるようにするって話で
一人前の技術者が苦しむようなコードを書くなってこと。つまりコピペだらけだったり
コードが適切な場所にないようなもの。

一人前の技術者でないのなら、それはそいつを育てるという話であって、まったくの別問題だよ。
開発でとある言語を使っているのであれば、その言語で使える技術は全て使って良い。
それが使えない人は、単に半人前というだけの話。半人前を甘やかすなや。

**仕様書無しさん** · 2014/12/29(月) 11:20:00.95

うちにも客から個人指名受ける奴が一人いるなぁ。
ソースが汚いわ、ドキュメントはないわ、コメントは嘘だらけだわで、
そいつしか理解してないという。

**仕様書無しさん** · 2014/12/29(月) 11:25:13.09

>>31
現実問題良かれと思って仕込んだ仕組みが訳分からんて言われるんだぜ。
やる気なくすわ。

**仕様書無しさん** · 2014/12/29(月) 11:27:50.90

あるプログラミング言語で一人前てのは
その言語の仕様をひと通り抑えて言える事だと思うけど
そういう意味では半人前ばっかりだよな。

**仕様書無しさん** · 2014/12/29(月) 11:52:42.41

>>33
>やる気なくすわ。

厳しいかもしれないが、お前が甘いと思う。
そこまで言うなら、
>良かれと思って仕込んだ仕組み
を実装したのは本当だろう。

でも、それを書いた本人である貴兄が、周囲にプレゼンをするときは
細心の注意を払って知らせないといけない。

世の中の人々というのは、「ソレいいね！」と言いながら、腹の中で
「これは確かに本当に良い仕組みだ　⇒　だから賛成しないで、
こいつ（＝あんたのこと）の株が上がるのを邪魔しよう」
とこっそり思うものなんだよ。
少なくとも思われる可能性をゼロに見積るのは、あまりにもリスキーだ。

俺だったら、何かチームの仕事を画期的に効率化するとか、そういう
実装を思いついて、実際に書いてうまくいったら、それをツブされないように
直属の上司の手柄にするにはどうしたらいいか、チームの功績にするには
どうしたらいいか、誰にどういう順番でプレゼンするか、かなり真剣に考える。

俺のいまいる職場は、そういうことをマジで考えさせられるから
とても勉強になるんだけど、そういう意味でも、さっき書いたように
良い環境で働いていると思っていて転職する気にはならない。
（金もいいしね）

**仕様書無しさん** · 2014/12/29(月) 11:58:45.46

>>35
俺の駄文に長いレスありがとう。

小さい会社だから、最初は良かれと思って技術支援してたけど
俺のやることは全部裏目に出て、周りを困らせてしまう。
だから俺は黙ってタッチしないことにした。

**仕様書無しさん** · 2014/12/29(月) 12:02:43.17

>>33
> 現実問題良かれと思って仕込んだ仕組みが訳分からんて言われるんだぜ。

そいつが無知であるのが原因であることをどうやって説明するかだよね。
オープンソースのライブラリでも見せて、あなたにこれが読めますか？とか

**仕様書無しさん** · 2014/12/29(月) 12:05:18.44

>>37
現実問題さ、そういうの読めない人が大半なわけよ。
会社としては、そういう人間がメンテできるように作るのが正解なのよね。
俺はうんざりなんだ。

**仕様書無しさん** · 2014/12/29(月) 12:07:49.92

>>38
> 現実問題さ、そういうの読めない人が大半なわけよ。

教育すればいいだけだよ。

一人あたり数分あれば、言語の機能を一つ理解させられる。
そうすれば、その後で何時間も何日も元をとれる。

> 会社としては、そういう人間がメンテできるように作るのが正解なのよね。

人間を育てたほうが正解だよ。そっちのほうが圧倒的に時間を減らせる。
なんで間違った方を正解だと思ってるの？

**仕様書無しさん** · 2014/12/29(月) 12:09:19.81

>>37
そういう詰め方をしたら、言われた方は
「こいつの言うことを認めたら、俺が無知だということを、こいつに納得
させられてしまって、俺はメンツを失う」
ってなって、ますます過剰防衛にさせてしまわないだろうか？

**仕様書無しさん** · 2014/12/29(月) 12:10:58.25

>>39
何年もやってきた人間を再教育する？
しかもそれで通用するんだよ。この業界は。

だいたい俺が人を教育するのにあんまり興味が無いしな。

要は自分がそこまでコミットする気持ちが無いなら、現状は変わらないって事なんだろうけど。

**仕様書無しさん** · 2014/12/29(月) 12:13:00.22

優秀なプログラマーって、ほっといても自分で育つじゃない。
教育でプログラミングへの興味を植え付けられるのかね？

**仕様書無しさん** · 2014/12/29(月) 12:13:12.10

>>38
>俺はうんざりなんだ。

なら、転職するしかないよ。
俺はさっき厳しいことを書いたけど、アンタのうんざりはよく分かるし。
（分かるからこそ、厳しく書いたのだが）

**仕様書無しさん** · 2014/12/29(月) 12:17:30.71

>>41
> 何年もやってきた人間を再教育する？

教えてるよ。教育っていうもののことでもない。
その人のところに行って、こうした方がいいというだけ。

まあ、俺が三十代で、趣味も含めて20年近くやってきたから
説得力あるんだろうけどね。

現場ではちゃんと見せればどちらが技術力が高いかわかる。
無能なプログラマのほとんどは自分が無能であることに気づいてるよ
だって読めないんだもの。

**仕様書無しさん** · 2014/12/29(月) 12:18:27.66

>>44
嫌味にならずに接することが出来るんだろうね。羨ましい。

**仕様書無しさん** · 2014/12/29(月) 12:46:57.28

>>39
> 一人あたり数分あれば、言語の機能を一つ理解させられる。
無理無理。
理解したつもりになって後で大バグのしっぺ返しを喰らうだけ。

**仕様書無しさん** · 2014/12/29(月) 12:55:08.01

>>46
そこで、正しく直してやって、
さらに実力差をみせつけるんだよ。

**仕様書無しさん** · 2014/12/29(月) 12:57:59.39

>>46 と>>47　両方の言い分が理解できる。

つまり、俺もそのどっちも経験したことがあるから。難しいよね、人に教えるってさ。

**仕様書無しさん** · 2014/12/29(月) 13:19:34.56

マネジメントの立場になると違う。
属人性は排除すべき最大のリスクの一つ。
○○さんじゃなきゃダメなんていう客は馬鹿の典型。
○○さんが死んだらどうすんの？
また、○○さんみたいなオンリーワンの技術者を目指せ！
ていう会社も馬鹿の典型。
死ぬってのは極端かもしれないが、
○○さん依存の結果、○○さんを超えるレベルのシステムは絶対に作れない

**仕様書無しさん** · 2014/12/29(月) 13:24:50.47

開発速度で言われたことはあるけど、それって単にスケジュールが間に合わないってだけなんだよなぁ
技術の一つではあるが、たいしてうれすくもない

**仕様書無しさん** · 2014/12/29(月) 13:28:53.86

>>49
「属人性を排して」というのは確かに、マネジメントの視点から
すると正論なんだろう。正論というか、マネジメント側としては
こうあって欲しい、こうありたい、そうじゃないと会社としてマズい
ってことなんだろうと思う。
ところが、えてしてデキるプログラマーはそれを嫌がる。
なぜなら、どうしても、属人性を排除するというのは、現場レベル
だと、スキルの低い人に合わせるってことになり、スキルの高い人が
その合わせる役目を押し付けられがちなので、上の誰かが
言ってた「もう勘弁」って話になる。

「属人性」の話で私見として思うのは、
IT会社のマネジメント側の人はみんな「属人性は排除すべき」と
思っていて、それを口にする人は多いが、さらに踏み込んで、
「プログラマの個性を伸ばし、かつ、属人性を排除するには
どうしたらいいか？」
という真に困難で意味のある課題に取り組んでいるIT経営陣の人は
あまりお目にかかれない。

私の知っているところだと、この課題に自分なりの解決策を
もっていて、それでちゃんと現場もついていっている人としては
任天堂の岩田聡氏かな。

**仕様書無しさん** · 2014/12/29(月) 13:40:21.95

有能な社員　と　平凡な社員
スペシャリストを求めるのに、誰でもできる状態に・・・・・・・。これは完全な矛盾。

経営学等々がタダの後付で語っている証拠だよ

**仕様書無しさん** · 2014/12/29(月) 13:44:48.63

「属人性を排して」か。
うちでは、スキルの無い人間でも同じように出来る仕組み作り、って意味合いで使われるな。
スキル無い人間がスキル無すぎて如何ともし難いのが現実。

**仕様書無しさん** · 2014/12/29(月) 13:47:05.20

>>52
>有能な社員　と　平凡な社員
>スペシャリストを求めるのに、誰でもできる状態に・・・・・・・。これは完全な矛盾。

経営側って得てしてそういうもの。その時々で、都合の良い大義名分を
掲げて、とりあえず形だけでも、社員をひとつのベクトルに向かわせる。
僕らがコードを書くのが仕事なら、彼らの仕事はそういう大義名分を
作り出して社員に、うまく飲ませること。

そういう矛盾を押し付けられるのが嫌なら、押し付ける側に行くか、
もしくは、押し付けることも、押し付けられることも嫌なら、
納得できないことはやらないでいいような働き方ができるように、
自分で模索するしかない。

**仕様書無しさん** · 2014/12/29(月) 13:56:04.98

会社なんて、もう矛盾と理不尽の塊でしょ。
人間という、欲望と感情の生き物が操縦しているんだから。
エンロン倒産のノンフィクションなんか読むと、それがよく分かる。

僕らは、会社で働いている間のほとんどの時間を、
矛盾も理不尽もないプログラミングという世界で働いているから、
人間社会に、そういったほころびがあると、どう対処していいか
分からなくなることがあるが、CPUの外の世界は、魑魅魍魎がうごめく
ドロドロの人間喜劇だと思ったほうがよい。

正論は通じない。でも正論が使われることはある。
誰かの欲望を満たすためにね。
そういった社内の政治屋が作る流れに、うまく乗っかりたいもの。

それは、プログラマーとしての仕事を、彼らに邪魔させないためにだ。
プログラミングを愛すればこそ、彼らに迎合するフリをするのだ。

**仕様書無しさん** · 2014/12/29(月) 13:58:46.22

スキル低い連中に合わせるフリってどうやるんだw

**仕様書無しさん** · 2014/12/29(月) 14:12:26.75

>>56
違うよ。
迎合する、というか合わせてやる相手は、スキルの低い連中じゃない。

俺が言っているのは、プログラマーも、会社の権力を持っている人たち
（金を動かせる人や、人事権のある人、あるいは、それらの人の懐刀と
言われている人）のパワーゲームに、少しはつきあいましょうよ、
っていう話。

スキルの低い連中に合わせる仕事をやらされそうになったら、
俺は全力で逃げるぞ。

全力で逃げるって意味は、日ごろから、さっき言った会社の権力の
ある人と懇意にしておいて、そういう仕事を押し付けられそうに
なったら、相談してどうにかしてもらうってこと。

俺はそういうコネを作るために、社長の愛人だと分かっている
会社の受付の女に、デートしてくれと申し込んだことがある。
男と女の話っていうのは、組織のお約束を超えるからな。
そうやって、経営層とある種の感情的なもつれをわざと作って
コネを作った。

そのぐらいやりますよ。
自分の書いたコードを守るためなら女だって社長だって騙すよ。

だって、自分が「これはイイ！」と思った実装なりプロトなりを
潰されたくないでしょ？

**KAC** · 2014/12/29(月) 14:32:23.88

>>51
そう悲観的になるもんでもない。
「属人性を排して」⇒「スキルの低い人に合わせる」
というのは、会社側の観点からも間違ってるから。

誰でも出来るような内容の仕事しかしないのであれば、
その会社に発注する意味すらなくなるんだから、
結果として仕事を失うことになってしまうのは会社も理解してる。

「属人性を排して」というのは、
チームや会社の参加者のベクトルを合わせて育てるってこと。
まともな会社なら、教育に力を入れるってのが常道。
チーム内教育の講師とか買って出てみ？上司は結構喜ぶぞ。

**仕様書無しさん** · 2014/12/29(月) 14:43:53.28

>>57
そこまでして会社に居る意味って何？

**仕様書無しさん** · 2014/12/29(月) 14:49:34.06

>>59
意味？
うーんとね、
出来るプログラマーがたくさんいるんだよ。
そいつらに、「◯◯も、けっこう書けるよね」って言われたいっていう、
それだけ。

俺も今の会社にくるまでは、会社なんて自分の技術的なスキルアップの場
としか考えていなかったけど、今の会社は
そこまでして居場所を作る価値があると思えるところにようやく
到着したって感じ。（外資ですよ）

**仕様書無しさん** · 2014/12/29(月) 14:50:33.50

>>58
レスありがとう。もういい年なので、基本、人を信じる路線で仕事したい
と思っていたところだ。

**仕様書無しさん** · 2014/12/29(月) 14:50:54.51

そもそも出来る人間だけ集めれば
属人性（笑）で悩むことなんか無いんだけどなあ。
プログラマに階級付けして
上位プログラマの言うことには絶対服従とかどうだろう

**仕様書無しさん** · 2014/12/29(月) 14:54:53.10

>>60
良い職場ですね。
それなら労力を払う価値もあるのかもしれない。

**仕様書無しさん** · 2014/12/29(月) 14:59:02.83

>>58
「属人性を排して」の意味するところが、そういうものなら良いと思います。
そもそも、
>チームや会社の参加者のベクトルを合わせて育てるってこと。
>まともな会社なら、教育に力を入れる
ようなトップの人は、それらを称して「属人性を排する」とは
言わないだろう。

もっと、良い言葉でそれらの施策をまとめ上げると思われる。

**仕様書無しさん** · 2014/12/29(月) 15:30:25.22

>俺はそういうコネを作るために、社長の愛人だと分かっている
>会社の受付の女に、デートしてくれと申し込んだことがある。

お前バカだなw

そこまでバカなことをやれるほど熱くなれるのは、
ある意味羨ましい。（微笑ましい、のほうが近いか）

でも俺はやらないけどねw

**仕様書無しさん** · 2014/12/29(月) 15:31:02.70

属人性の話は、同レベルかそれに近い代わりの人間が何人か居る状態であれば良いので
最底辺に合わせる必要は無いと思う

底辺に合わせろというような人は、馬鹿でなければ裏に別の意図を持っていると思われる

属人性を言うなら、それよりも、コストや納期か目先の効率の問題か、
案件に対する情報の意味でのプログラムやコード、仕様以外の面での情報に対してされないことが少なくないか？
担当が居ないと、ろくに答えられない状況

プログラム等の面ではペアプロに近い状況でスキルやスタイルの継承や情報共有、OJTとか
小さな案件でもチームで分担・協力するとかは、あまりされないように思う
書き物があるだけで十分ということは中々無いと思うのだが。

**KAC** · 2014/12/29(月) 15:58:12.47

この業界、「あの人じゃないと無理」ってセリフは試験・デバッグの時に多いよな。
できない奴は、そもそも設計や製造で良いものと悪いものの区別をつけられないから
それなりにできた気になって突き進んでしまうことが多い。

デバッグは結果が全てで「直るまで終わらない」から、
技術や経験の違いが誰の目にも明らかになりやすい。

設計や製造でもう少し技術の視覚化できないもんだろうか・・・

**仕様書無しさん** · 2014/12/29(月) 16:06:37.17

思うに、今の業界の風潮だと、誰にでも分かる、つまり、自分が
所属する組織の標準的なスキルレベルに合わせたコードばかり
書いても、プログラマー本人にとっては何のメリットも
インセンティブも無いと思うんですよ。

それよりは、あるプロダクトの大部分はそういうポリシーに
したがったとしてもコアな部分は自分にしか読めないような
コードを書くほうが、自分の立場を築きやすい。

自分に聞かなきゃ解決しないコードが、会社の生命線のプロダクト
として出荷されたら、そのプログラマーにとっては有利だからね。

組織で働く以上は、経営方針に従うのはもちろん基本として
守らなきゃいけないが、自分をこだわりを押し出すときも時に
必要だと思う。それが失敗したら、そのプログラマーが
詰められるというリスクを負うんだから、プログラマーにとっても
勝負に出てるわけで。
（もちろん、だから分かりにくいコード書いてもオッケーっていう話ではないよ。）

なんていうか、そんなような、経営陣とプログラマーの、いい意味での
綱引きのある職場が楽しいです。

**仕様書無しさん** · 2014/12/29(月) 16:08:52.09

>>67
今のプログラミングは、製造と言うより、小説とか絵画制作の文芸みたいなやり方だもんなあ。

**仕様書無しさん** · 2014/12/29(月) 17:35:00.24

俺が本気出したコードは低スキルのやつらには理解出来ない

ありえんわ

その低スキルのやつらが同じ機能を実装出来ないのなら話は分かるが
実際はそれなりに出来てるんだろ？

そりゃ単に、周りの人間を無能だと思いこみたいか、あんたのコードがひどすぎるだけだわ

**仕様書無しさん** · 2014/12/29(月) 17:43:31.29

相対的に>>1みたいな状況に陥る場合はあるかもな

自分は平均的なスキルなのに、周りが最低ランクのスキルばかりで、
自分がコード書くと周りの人は「？」って状況

**仕様書無しさん** · 2014/12/29(月) 17:50:30.28

だからね、俺も、以前は周り人たちが、自分よりも少しだけ
プログラミングスキルはじめ、いろんなところでのレベルの低い集団で
働くように、そういうところとばっかり仕事してたけど、それだと
精神衛生上よろしくないと気がついた。
その集団の知的レベルが、今の自分よりちょっと上っていうところに
入って、必死に、こいつらに「使えねーやつw」と思われたくない！と
思ってやっていたほうが、気分がいいんだよ。

ある職場にジョインするときに、
「この集団なら俺のほうが知的レベル上で、楽できるわ」
なんて思って入ると、だいたいダメだね。精神が病む。荒廃する。

**仕様書無しさん** · 2014/12/29(月) 20:35:45.88

問題が起きる前に問題を起きないように対処しているとどう転んでも自分の評価が
上がりようがない。特に分業が進んでいるところだと。問題が起きた後に対処
するとそれなりに評価されることもあるが、延焼することやその他諸々のことを
考えると起きないように自己防衛するほうが良かったりするジレンマ。

**仕様書無しさん** · 2014/12/29(月) 20:42:45.94

>>66
＞底辺に合わせろというような人は、馬鹿でなければ裏に別の意図を持っていると思われる

コミュ力（）が必要なんて言っている割に裏の意図とか言わないと伝わらないだろう
ってのを無視する人が多いよね。

**仕様書無しさん** · 2014/12/29(月) 21:45:05.50

裏の意図が伝わらない人はコミュ力がない人だろう

**KAC** · 2014/12/29(月) 22:16:06.15

自分の書いたコードに対して周りから

「こんなコード俺には思いつかない」
って言われるなら、褒められてると思っていいけど

「こんなコード俺には理解できない」
って言われるなら、どう考えても反省するべきだろ

**仕様書無しさん** · 2014/12/30(火) 03:00:24.99

>>72
とんでもなく傲慢な人間だな

会社辞めて独立したら良いよ

**KAC** · 2014/12/30(火) 03:25:32.82

>>73
自分の問題は出さずに、
他人の出した問題をどんどん解決していけ。
そんで次のプロジェクトにその予防策をぶち込め。

これだけで評価は上がるもんだ。

**仕様書無しさん** · 2014/12/30(火) 07:51:22.58

>>76
そうかな・・・？

俺の経験上、「分からない」「読めない」「難しい」って文句を言う人は

・基本的な知識を持っていない
(デザインパターン、構文やシンタックス、フレームワークを理解していない)

・英語力が低すぎて、ステートメントごとの日本語コメントがないと全く理解できない
(プログラムそのものをダイレクトに読むスキルがない)

・IDEの使い方が下手過ぎて、コードを追うテクニックを知らない
(上から下に流れるような従来型のコードしか追えない。
インターフェースから実装クラスにジャンプする方法が分からない。
「ハリウッドの原則」を知らないから、どこから呼ばれるのか分からないコードが出てくると降参状態)

こんな、ありえんくらい低レベルな事がネックになって、読めない読めない！って大騒ぎしてたよ

**仕様書無しさん** · 2014/12/30(火) 07:55:48.73

>>79の続き

たいていのケースで、反省すべきは
コードを書いた本人ではなくて、プログラマなのに、
極端にレベルの低すぎる人たちだと思う

一方「出来る」けどたまたま、そのスキルが足りないだけの人は、
「こんなコード俺には理解できない」
とは言わずに、
「ここが分からないので、教えてほしい」
って質問してくるよ

**仕様書無しさん** · 2014/12/30(火) 09:08:57.78

>>76
> 「こんなコード俺には理解できない」

実際には

こんな"コード" 俺には理解できないではなくて、
こんなコードに使われている、"言語の機能" 俺には理解できない

だったりするけどな。
その場合は、コードではなく、言語の機能を知らないほうが悪い。

分かりやすく言うならば、「いつも使っている道具に
こんな機能があったなんて知らなかった。」といってるようなもの

自分が使ってる道具を使いこなせないのは反省した方がいい。

**仕様書無しさん** · 2014/12/30(火) 09:16:48.02

この間、ループで数行使ってぐだぐだかいているのを
mapを使えば一行で書きなおせるよっと見せてやったことがある。

そしたら「でも可読性の点ではどうなんですかね？」って言われてびっくりした。
明らかに一行で書いたほうが可読性が高い。

で、気づいたのが、自分の技術力不足による問題を
可読性の話にすり替えんな馬鹿ってこと。

その時は俺のほうが上の立場だったからあっさり終わったが
これが逆だと大変だろうな。

可読性の話をする時に、言語の標準的な機能を知っている人、
つまりプログラマを前提にするのは当たり前。

プログラマとして仕事をするのなら、プログラマとしての技術を上げるべきだし上がるもの。
素人基準にしてどうする？プロのプログラマとして素晴らしい働きを出来るのに
その力を制限して、素人のやり方でやったら、何もできなくなる。

**仕様書無しさん** · 2014/12/30(火) 09:23:36.24

技術力が低いならば、技術力を上げれば解決できる問題でしかない。

高い技術力を持っていても苦しむ質の悪いコードは
技術力をあげたって解決できない問題。

解決できない問題を増やしてどうする？

**仕様書無しさん** · 2014/12/30(火) 09:36:53.62

増やした？

**仕様書無しさん** · 2014/12/30(火) 10:05:28.11

他人のプログラムを解読できない。解読するのに異常に時間がかかる。
こーゆー人って
情報処理試験の基本の午後試験やらせれば簡単に判明する。
どーせ理由つけて受験しないから試験直後の月曜日に試験冊子を渡して業務として解かせれば嫌と言えない。
それで無能がハッキリする。午前は暗記だから多少準備は必要だけど午後は業務でやってれば不要だから。

**仕様書無しさん** · 2014/12/30(火) 10:32:09.34

>>85
でもなぁ、情報処理試験の午後って
コーディング的には汚いぞ。

変数名は変な略だし、コードは冗長だし、
実際の開発ではお目にかからないようなコード。

Javaは単なる文法知ってるかどうかで
別の意味で役に立たない。

まあ量は少ないし、基本的なことしかやってないから
あの程度がわからないのなら無能確定でいいが。

**仕様書無しさん** · 2014/12/30(火) 11:14:07.86

例えばプロの物書きが文章を書くとき。
その目的、それを読む人、読まれるシチュエーションなどさまざまな要素を考慮した上で、
時には伝えたい内容と読みさすさを天秤にかけたりしながら、最終的な決定稿に向かって推敲を重ねる。
まあ当たり前の事だね。

ところが一部のプロと自称する人々は次のように主張する。
俺はバラを漢字で書ける。漢字で書けるんだから薔薇と書くべきである。これが文章力だ。
そう、>>82のような単細胞な人々だ。

彼らは解決できない問題を増やしつづける。

**仕様書無しさん** · 2014/12/30(火) 11:24:41.00

>>87
お前、例え下手だなぁｗ

例えるなら、

俺はバラを知っているからバラとかける。
バラを知っていない奴は「花の一種で赤、ピンク、白などがあり茎には刺がある」と
"冗長"に書かないといいけない

こういう風に例えろや。

冗長に書くことがいかに問題があるかわかるだろう？
バラという花の知識を手に入れたら（それは大変なことではない）
あとはずっと、"バラ"だけで通じる。

冗長に書いた場合、バラを知っている人であっても、冗長なものを読んで
理解しないといけない。

これが知識をつければ解決出来る問題であり、
冗長は知識をつけても解決できない問題。

解決できない問題を増やすなよ。ドアホ。

**仕様書無しさん** · 2014/12/30(火) 11:27:49.27

>>86
汚いコード＝なおさら現実的だよｗ
あの程度の規模なら汚くても頭に入れるのに時間はかからない
これが普通レベルの人
ところが全体の７割８割は、あの程度の規模のプログラムすら頭で把握できない
基本午後はホント最低限の能力（頭）を持っているかを測るにはちょうどいいよ

**仕様書無しさん** · 2014/12/30(火) 11:31:45.33

>>88
例えが下手なんじゃないんだ。お前の問題意識が決定的にずれてるんだよ。
この例えで本当に分からないのだとしたら、あまり言いたくないが、
お前はやっぱりバカなんだ。

**仕様書無しさん** · 2014/12/30(火) 11:34:59.95

>>90
問題意識がずれてるのはお前じゃね？

お前、単に、バラと薔薇。どちらも文字数は変わらない。
どちらの書き方にも差がない物の話をしてるよね？

俺が話してるのは、冗長なコードを言語やライブラリの機能で
短く単純にかける物の話をしているの。

もし、この話とお前の話が違うならば、それはお前が
ずれてるだけの話。

短く単純に書けば多くのメリットが有る。
冗長に書いたらデメリットしか無い。

**仕様書無しさん** · 2014/12/30(火) 11:40:33.09

>>90って、お前が間違ってるんだ、ばーかばーか
としか言ってないことに注意なｗ

**KAC** · 2014/12/30(火) 11:43:24.71

>>79-80
最終的にはケースバイケースなので、
具体的なソースが無い限り話は平行線になるとは思うんだけど・・・

プログラムは「ビジネス文書」だと捉えたほうが良い。

過不足無く簡潔に記載することが大前提で、
あとはどれだけ読み手に誤解させること無く読ませるかが大事。

例えば日本語でも「読めないことはないけど難解な文章」ってのはある。
どうやったらこんな難解な文書になるんだと思えるようなの見たこと無い？
言い回しが難しかったり故事成語などをやたらと織り交ぜたり。
"同じ意味なら短い方が可読性が高い"と主張されても賛同しづらい。

プログラムも同じで、読みづらいものは相当読みづらいものになる。
例えば、ちょっとした機能のはずなのにオブジェクト指向の多態性がたくさん出てきて
追っていると一体なんのために処理を始めたのか見失ってしまうような量のものとか。
(こういう場合は、たいてい設計で失敗してる)
書いた本人に可読性が悪いことを伝えると「それはオブジェクト指向を理解していないから」
と主張する奴も確かにいるけど、技術の問題じゃなくて物量の問題だと理解して欲しい。

なにが言いたいかというと「こんなコード俺には理解できない」と言われた場合は
本当に自分の書いたコードが"わかりやすいのか"を見直すきっかけにしたほうが良いよ。ってこと。

**仕様書無しさん** · 2014/12/30(火) 11:44:51.10

>>91
> お前、単に、バラと薔薇。どちらも文字数は変わらない。
> どちらの書き方にも差がない物の話をしてるよね？
違うな。
そんな話はしてない。

> 俺が話してるのは、冗長なコードを言語やライブラリの機能で
> 短く単純にかける物の話をしているの。
その通り。
それはお前の同僚を含めても、お前だけがその話「だけ」をしているね。

他の人はもっと幅広く物事を考えているんだよ。

**仕様書無しさん** · 2014/12/30(火) 11:46:34.07

分かりにくいと言われた時にまず考えないといけないのは

コードが分かりにくいのか
分かりにくいと言っている奴の知識不足なのか。

それを見極める一つの方法が、
○○という機能をあなた（分からないといった人）は知っていますか？
っていうこと。○○は文章ではなくて単語ね。

知らないのであれば、知識不足が原因だし
知っているのであれば、コードが分かりにくいってことになる。

**仕様書無しさん** · 2014/12/30(火) 11:47:00.36

確かにマップくらい分かれよ馬鹿とは思う。

**仕様書無しさん** · 2014/12/30(火) 11:48:14.54

>>94
> そんな話はしてない。
してるじゃねーか。

>>87
> 俺はバラを漢字で書ける。漢字で書けるんだから薔薇と書くべきである。これが文章力だ。

恥ずかしいよ。自分で言った言葉を言ってないなんて言うなよｗ

もうそれだけでお前の信用度は劇下がりだよ。

**仕様書無しさん** · 2014/12/30(火) 11:48:41.96

>>94
> 他の人はもっと幅広く物事を考えているんだよ。

それはお前の妄想でしか無い。

**仕様書無しさん** · 2014/12/30(火) 11:51:16.06

知識不足が原因の問題は、知識をつければ解決できる問題。

それは未経験者が、経験を積めば解決できる問題と同じで、
経験者のほうが、うまく仕事ができるのと同じこと。
仕事では当たり前に発生する現象でしか無い。

**仕様書無しさん** · 2014/12/30(火) 11:52:25.57

仕事ができないやつを甘やかすからいけないんだよね。

**KAC** · 2014/12/30(火) 11:54:26.58

>>96
たぶん>>82のことを言ってるんだとは思うけど、
あまりにも本人の言うことを真に受けすぎてはいないか？

　「mapを使えば一行で書きなおせる」

と主張しているけど、そんなことは"ありえない"点にも注目しよう。

それは置いておくにしても、もともと"数行"しか無い処理を
「明らかに一行で書いたほうが」と言う理由で
mapに置き換えることが本当に可読性が高いのかも疑問。

本来mapを使うべきところだったのなら別に良いけど、
そうでないならmapを使うことによって可読性は下がってる。

ケースバイケースだからなんとも言えないけど、
可読性が高い理由を行数だけに求めている時点で内容を疑うべき。

**仕様書無しさん** · 2014/12/30(火) 11:54:28.81

>>99
それだけなら大した問題ではないが、ある特定の人々はあらゆる問題を
知識不足に起因する問題だと断定したがる。
これが実は大きな問題。

**仕様書無しさん** · 2014/12/30(火) 11:56:04.00

確かに未経験入社1ヶ月のやつが
俺はmapがわからないです。これからfor使って書くようにしましょうって
言い出したら、素人は黙ってろっていうさｗ

**仕様書無しさん** · 2014/12/30(火) 11:56:55.88

ソシャゲのコアプログラマが抜けてサービス終了とか最近あった気がする

**仕様書無しさん** · 2014/12/30(火) 11:58:48.05

>>101

> 　「mapを使えば一行で書きなおせる」
>
> と主張しているけど、そんなことは"ありえない"点にも注目しよう。

ありえないというのなら、あり得ることを証明すればいいんだよな？

my @b = map { $_ * 2 } @a;

配列の中のすべての値を2倍するコード。
1行で書き直せました。

はい論破

もしかして、どんな問題でも一行で書き直せると言っていると勘違いしちゃった？
それはアホだね。でも正直に言っていいよ？勘違いしちゃったテヘペロってｗ

**仕様書無しさん** · 2014/12/30(火) 12:00:55.31

>>102
> 知識不足に起因する問題だと断定したがる。

だから、見極めろって言ってるわけ。

知識不足が原因なのか、
コードが複雑なのが原因なのか。

その時、知識があるかどうかを聞けば、
知識がある人が複雑と言ってるならコードの問題であり
知識がない人が複雑と言ってるなら知識がないのが原因だと
わかる。　例外はあるだろうけどだいたいこれで判断できるよ。

**仕様書無しさん** · 2014/12/30(火) 12:01:01.44

スクエニのスマートフォンゲーム、「開発コアメンバーの脱退」の影響でサービス終了へ
http://developers.slashdot.jp/story/14/12/29/0638200/

**仕様書無しさん** · 2014/12/30(火) 12:04:17.10

>>107
これが原因か

メンバーが抜けた時期はゲーム配信の前後 (2012年4月) (スコア:4, 参考になる)
by Anonymous Coward on 2014年12月29日 16時35分 (#2735994)
ゲームをプレイしていた人間からすると的外れの言い訳です。
2013年2月に「騎士団システム」というゲーム性を根本から変える酷いシステムを導入したせいで大半のプレイヤーが辞めていったのが本当の原因です。
それまではパズドラよりも人気のあったソシャゲでした。
先日、「乖離性ミリオンアーサー」という続編同様のゲームを出したところ大ヒットしたので本作に見切りを付けただけです。
このプロデューサーたちはインタビューを受ける度にいい加減なことを言って物議を醸しているのでまともに受け取らないほうがいいです。

**仕様書無しさん** · 2014/12/30(火) 12:04:31.59

>>105
どこでmapを定義してるの？

**72=14=16=19=35=43=48=51=54=55=57=60** · 2014/12/30(火) 12:04:56.33

>>77
>とんでもなく傲慢な人間だな

ありがとう。
それは（あなたにとってはどうか分からないが、）
俺にとっては、とんでもなく最高の褒め言葉だ。

>会社辞めて独立したら良いよ

えっと。
もうとっくに会社員ではく、個人事業主から法人化しています。社員は数名ですがw

俺を含めて会社のメンバーは、いろんな会社でCTO的なことやったり、
コード書いたり、あと、生意気な若者を涙目になるまで説教して、
その後キャバクラ（六本木のけっこういいとこ。もちろん俺のっていうか
会社の経費のオゴリで）連れってやって懐柔したりとか、そんな日々を送っている。

**仕様書無しさん** · 2014/12/30(火) 12:06:24.88

>>109
> どこでmapを定義してるの？

びっくりしたｗｗｗ

言語の標準機能
今どきmapがない言語なんてないからｗ

ったく、こーいうやつがコードが読めないって
騒いでるんだろうなー。

圧倒的知識不足。

**ピラフ** · 2014/12/30(火) 12:07:16.99

>>111
VBScriptにはmapないんよ・・・ピラフどうしたらええの？

**仕様書無しさん** · 2014/12/30(火) 12:08:42.36

>>111
アホ？

**仕様書無しさん** · 2014/12/30(火) 12:10:49.22

>>112
mapがあれば簡単にかけるのになー
っていいながら開発しかないね。

そういう愚痴を言わない人（意味がわからない人）は、
VBScript以外を使ったことがないんだろうなってわかる。
知識が不足していると、効率が悪いことも認識しないから
困ったもんだ。

これもまた知識不足による大きな問題だね。

**仕様書無しさん** · 2014/12/30(火) 12:11:18.76

>>113
言い返せるのはそれだけかよｗ

**仕様書無しさん** · 2014/12/30(火) 12:11:22.26

よーし、パパも一行でmap書き直し張り切っちゃうぞおー

#include <map>

＼(^o^)／ｵﾜﾀ

**仕様書無しさん** · 2014/12/30(火) 12:12:35.73

>>105
動作確認したいんだけど、言語は何？

**ピラフ** · 2014/12/30(火) 12:13:50.43

>>114
ピラフ根性見せるしかないってことね。

**仕様書無しさん** · 2014/12/30(火) 12:14:08.76

>>117
Perl

なお、なぜPerlの話かというと
>>82で書いたように（実際にあった話）

> この間、ループで数行使ってぐだぐだかいているのを
という話でぐだぐだ書いていた人が使っていた言語がPerlだから。

**仕様書無しさん** · 2014/12/30(火) 12:16:23.27

>>111
> 今どきmapがない言語なんてないからｗ

これだから単一言語しか知らない奴は・・・

**仕様書無しさん** · 2014/12/30(火) 12:17:18.17

とりあえず、お前らは「あのお方でないと技術的に無理」というレベルではないな

**仕様書無しさん** · 2014/12/30(火) 12:17:53.21

>>119
perl使っててmapを知らないやつがいるわけないだろ
お前どんだけバカなんだよ…

**仕様書無しさん** · 2014/12/30(火) 12:18:17.04

なお、Python、Ruby、JavaScriptでも同等の機能はmapであるから
ループの話でmapといわれてわからない人は
知識不足といって良いだろう。

>>120
で君、何の言知ってる？ｗ

**仕様書無しさん** · 2014/12/30(火) 12:18:48.73

すべての言語にmap(辞書)の実装が標準であるとは限らない
あれはPerlだね、独特の汚さがPerlだ

なければ作ればいいだけの話
リストと辞書は利用頻度の高いデータ構造
これくらい自分で作れないようじゃ、プログラマとして才能が無いといえる
そして既にあるものを使わない(使えない)奴は、もっとプログラマとして才能が無いといえる

**仕様書無しさん** · 2014/12/30(火) 12:19:47.48

>>122
> お前どんだけバカなんだよ…

俺じゃねーよｗ

俺はループでぐだぐだやっていたコードを
mapで1行に書きなおしてやったんだよｗ
そう書いてあるだろｗ

なお、ぐだぐだかていた知識がないやつの前職はCOBOL
（COBOLにmap相当のものがあるかどうかはしらん）

**仕様書無しさん** · 2014/12/30(火) 12:20:47.39

JavaScriptの場合は同等の機能っつーか、ほぼすべてがmapだな。

**仕様書無しさん** · 2014/12/30(火) 12:20:48.78

>>124
> すべての言語にmap(辞書)の実装が標準であるとは限らない

これだから単一言語しか知らん奴は・・・。

配列のすべての要素に対して処理をするという意味の
mapがあるだろ。文脈で分かれよｗ

**仕様書無しさん** · 2014/12/30(火) 12:20:51.72

>>125
いやだから、そいつもmap知ってるって。
本当に可読性に問題があったんだよ。

**仕様書無しさん** · 2014/12/30(火) 12:21:32.79

>>128
> いやだから、そいつもmap知ってるって。

お前誰だよｗ

実際に話して、そいつがmapを知らなかったんだよ。

**KAC** · 2014/12/30(火) 12:26:21.46

>>105
あぁ、map関数か。。。

話の流れからして一般的なmapオブジェクトの話かと勘違いしちゃったテヘペロ

**仕様書無しさん** · 2014/12/30(火) 12:30:37.07

話の流れならmap関数の方だろ・・・

> 82 名前：仕様書無しさん[sage] 投稿日：2014/12/30(火) 09:16:48.02
> この間、ループで数行使ってぐだぐだかいているのを
> mapを使えば一行で書きなおせるよっと見せてやったことがある。

これで関数の方を思いつかない人は、
Python、Ruby、JavaScript、Perl、
Haskel、Lisp、（他にどんな言語がある？）
などの言語を知らないってことだから
反省した方がいいよ。

**仕様書無しさん** · 2014/12/30(火) 13:40:40.95

言語機能であれ知ってるとかこれ知らないとかの話はレベルが低すぎ。

**仕様書無しさん** · 2014/12/30(火) 13:45:38.72

mapの可読性って、括弧を付けるときに
map {} ($x, $y, $z); とか map({} $x, $y, $z); とか
こうなるってことだよな？ｗ

**仕様書無しさん** · 2014/12/30(火) 13:48:35.35

>>131
連想配列って意味でのmapも考えられるしなあ。
思いつかないから知らないと言うのはちょいと強引かと。

**仕様書無しさん** · 2014/12/30(火) 13:50:04.60

「mapを知ってる」とドヤる人はあの人じゃないと無理と呼ばれるレベルだろうか？

**仕様書無しさん** · 2014/12/30(火) 13:53:54.33

>>135
それはない。
活きのいいPGならたくさんいるから。

**仕様書無しさん** · 2014/12/30(火) 13:58:36.06

map関数と明言したり言語を明記したりできるない人が
可読性について語っても説得力無いの

**仕様書無しさん** · 2014/12/30(火) 14:00:13.45

>>137
そういう問題じゃないと思う
どんな関数だろうがどんな言語だろうが同じような問題はあるだろ
そんな程度の想像力も働かないような奴に設計なんて無理

**仕様書無しさん** · 2014/12/30(火) 14:01:53.90

設計の話だったのか・・・実装の話だとばかり思ってた

**仕様書無しさん** · 2014/12/30(火) 14:03:23.45

その「あの人」っていうのが営業部長の思い込みだったりするものだから
現場が振り回されて混乱することがしばしば。

**仕様書無しさん** · 2014/12/30(火) 14:09:46.14

文脈から分かったけどね

**仕様書無しさん** · 2014/12/30(火) 14:34:02.48

少なくとも、お前らは視点が狭すぎるから、ダメだろうなｗｗｗｗ

**110** · 2014/12/30(火) 14:53:08.18

最新のスレのいくつか読むと、実装とか設計についてネット上で
質問をする場合に、
(1)質問される人間が、気持ちよく答えたくなる質問（日本人が相手の場合、正しい敬語の使い方も含めて）
　になっているか？
(2)質問に答えてもらえれば、自分の問題は解決するのか？
(3)(1)(2)が満たされた質問の中で、最も文字数が少ない質問になっているのか？
をよく吟味しないと何ら発展的な議論にならない
ということがよくわかる。
(1)(2)(3)のような質問を発せられることも、必ずしも開発者のスキルについて
ではなくても、何らかの役割について
「ある人じゃないと」
と言われるポジションに自然となっている場合が多い。

なぜかというと、たいていの人は(1)(2)(3)を考えていないからだ。
考えて質問すれば、当然、考えていない人間より差がつく。

**仕様書無しさん** · 2014/12/30(火) 15:09:49.22

あ、この人無能だｗ

**110** · 2014/12/30(火) 15:26:58.45

おの仕事に関わっていて気がついたことがある。
プログラマーだけじゃなく、WEBデザイナーも、設計者もインフラエンジニアも
WEBディレクターも、SEO担当者も、PMにも当てはまる。

みんな自分は知的で（そこそこ）有能な人間だと思っている。
扱うものが、コンピューターだったり、プログラムだったり、最新のWEB
マーケティング手法だったり。
とにかく、最先端分野の仕事をしているので、何か自分が知的な人間になった
かのように錯覚する。

この錯覚が、けっこう穴なんだよね。
自分に有利な居場所を獲得するためのね。

**110** · 2014/12/30(火) 15:38:59.44

それと、特に注意しているのが自分のチーム内に、高学歴者と低学歴者が
いる場合。これは気をつかいますね。

**仕様書無しさん** · 2014/12/30(火) 15:53:04.83

>>133
なんか問題あるの？

**仕様書無しさん** · 2014/12/30(火) 16:28:10.02

>>147
大アリ

**仕様書無しさん** · 2014/12/30(火) 16:34:59.87

>>148
でもその理由は書かないんだねｗ
書けないと判断することにするよ。

**仕様書無しさん** · 2014/12/30(火) 16:37:14.60

括弧がどうとか、そういう可読性はどうでもいい。
っていうか、それは可読性じゃなくて書き方の違いなだけ。
カタカタか漢字みたいなそんなくだらないレベルの話はしなくていい。

可読性と言ったら、可"読"性。つまり読む時の量の話。
読まなければいけない物を、シンプルかつ無駄なく書くことが可読性

**仕様書無しさん** · 2014/12/30(火) 16:56:56.40

量の話に限定すんなよｗ

**仕様書無しさん** · 2014/12/30(火) 16:58:13.43

質でもいいけど？

どちらにしろ、括弧をどうするかとかは
可読性とは関係ない話。

**仕様書無しさん** · 2014/12/30(火) 18:55:38.13

ちょっとスレとは違うかもだけど、

mapとかreduceとかを使ったロジックを可読性が高いと思う人、思わない人の対比って
SQL文の結合やグループ化を直感的に理解できる人と、できない人のそれに
似てる気がする

「dataのvisualization」って言うのかな
脳内でグリグリとデータを自在に変形させる事が
出来る能力っていうのかな

俺だけかもしれんけど、そういうロジックを人に説明するときは、
手でジェスチャーしたり、簡易図をお絵かきしながら、
「ここをグチャっと潰して」「こっちとガッチャンコして」
とかの、擬態語ばかり言ってるわｗ

**仕様書無しさん** · 2014/12/30(火) 20:15:18.90

抽象化して考えられないんだろ。

mapとかそういうのって、
秘密の機械に、材料入れたら、完成品が出てくる
といった処理をしてるだけ。

A + B → C と何ら変わらない。
A に何か処理 → C たったこれだけの単純なこと

**KAC** · 2014/12/30(火) 20:27:40.02

>>154
流石にそこまでいったら抽象化とは呼べんだろ・・・

**仕様書無しさん** · 2014/12/30(火) 20:49:44.35

>>155
いや、抽象化だって。

mapとかさ数式で書けばこれのこと

Y = F(X)

Xという塊に、Fという処理を行ってYを作る。
たったそれだけのこと。

難しく考えることなんて何もないのさ。

**仕様書無しさん** · 2014/12/30(火) 20:51:27.74

集合論って話をしてもいいんだけどね。

一つの値の代わりに、塊になっただけ。
塊があって、そこに何か処理をして、塊を作るだけ
もー、単純。

**仕様書無しさん** · 2014/12/31(水) 09:47:18.77

>>153
そういう風に思い始めると、あるコードについて
「自分と同じビジュアライゼーションをイメージできないヤツは無能。できる俺は天才」
みたいに思いがち。

で、単に周りからは意味不明な人になっている場合もあるから気をつけてね。

何かについて、それをどういう風に理解しているかは千差万別なので。

**仕様書無しさん** · 2014/12/31(水) 09:53:00.42

単純に、ループ使わずに集合に対して処理をするという記述が少なかったから、
慣れてないだけだと思うよ。
抽象論とかそういう大層な話ではない。

**仕様書無しさん** · 2014/12/31(水) 09:55:23.45

説明や思考に絵を使う人は「大雑把で細かいことが苦手」だと思ってる。

**仕様書無しさん** · 2014/12/31(水) 10:03:59.43

思うだけならだれでも出来る

**仕様書無しさん** · 2014/12/31(水) 10:09:17.42

>>160
右脳で直感的に物事を捉えて、左脳で論理的に理解している。
両方の脳みそを使っているんだ。

**仕様書無しさん** · 2014/12/31(水) 10:10:04.84

論理的に理解できてる人は、論理的に説明できるから。

**仕様書無しさん** · 2014/12/31(水) 10:11:25.19

>>162
頭悪そうｗ

**仕様書無しさん** · 2014/12/31(水) 10:19:24.49

>>163
そうでもないよ。

例えば、スポーツがうまいからといって教えるのがうまいわけじゃないのと一緒で
自分の動きを論理的に説明できるわけじゃない。体で理解しているから速い。

そういう人は説明するとき、自分がどうやっているか（何を考えているか）を
思い出さないといけないから面倒なんだよ。

実際、説明はできなくても技術力は高いだろ？そういうこと。

**仕様書無しさん** · 2014/12/31(水) 10:23:44.71

結局、論理的には理解できてないじゃん。

**仕様書無しさん** · 2014/12/31(水) 10:27:01.44

>>166
論理的に理解してるよ。説明するのが面倒なだけで。
直感で反応しているから、問題が出た時に間を端折ってすぐ答えがでてる。

説明するときは、その間を語らないといけないから面倒なんだよ。
だから、あーすればこうなるだろって言いたくなる。

**仕様書無しさん** · 2014/12/31(水) 10:28:48.56

端折ったものが正しいかどうかは論理的に検証したのかな？

**仕様書無しさん** · 2014/12/31(水) 10:30:42.67

別に、直感でやるのが悪いとは言ってないよ。
がーっとやって、だーってやれば速いからね。

**仕様書無しさん** · 2014/12/31(水) 10:35:57.58

>>168
過去に。
例えばブール代数の定義が正しいことはずっと過去に検証済み。

そしてそれ完全に体で覚えているから、
複雑なコード（ifがネストされているようなもの）をみた時に、
シンプルしたコードがすっと見えてくる。

**仕様書無しさん** · 2014/12/31(水) 10:49:33.89

理屈って体で覚えられるもんなのか？

**仕様書無しさん** · 2014/12/31(水) 10:53:36.33

コードは手で覚えるもんだな。

**仕様書無しさん** · 2014/12/31(水) 20:26:41.67

>>157
馬鹿はだまってろキチガイ

**仕様書無しさん** · 2015/01/01(木) 04:14:35.31

>>171
英語喋れない人が、英語喋れるようになるようなものかな。
最初は文法とか理屈で考えていても、
それが自然と出てくるようになる。

そうなると、最初よりも早い速度で正確に使えるようになるが、
最初よりも労力は使わなくなる。何も考えないぐらいに。

そうなると、今度は何故そうなるのかが説明するのが難しくなる。
昔はちゃんと理屈が言えていたが、今は理屈抜きでそう出来てしまうから
いちいち理屈を思い出さないといけなくなる。

**仕様書無しさん** · 2015/01/01(木) 10:33:21.76

要するに九九を暗記するのと同じことじゃねーか。説明下手だな。

**仕様書無しさん** · 2015/01/01(木) 12:46:34.78

>>175
お前に伝わってるんだから
問題ないだろｗ

**仕様書無しさん** · 2015/01/01(木) 13:03:18.56

他人を下げないと自分が上であることを確認できないだろ

**仕様書無しさん** · 2015/01/01(木) 14:13:34.17

>>175
お前は九九を説明できないのか？

**仕様書無しさん** · 2015/01/02(金) 11:56:06.53

要求が特殊な設計の場合なら言われるぞ。おれ。
戦略的なプロダクトの基礎設計とか。

**仕様書無しさん** · 2015/01/02(金) 14:22:29.84

雑用だったら俺が引っ張りだこ
共通基盤グループのリーダーとして指名される

その実は提案・基盤設計時点から参画し
・システムハードウェア／ソフトウェアの選定
・単体結合テスト環境の構築
・本番サーバ構築
・総合テスト環境の構築
・運用設計/環境構築
・顧客への運用指導
・運用後のフォロー
・運用に入った後のバグ修正等々

までは良いが
・SE/PG/テスタへの環境使用のご指導
・請負/派遣奴隷の使用するPCの調達
・開発PCの環境構築
・テスト用プリンタの調達
・用紙等の消耗品の調達
・各種配線（テスト環境用）
・電源が足りない時にはビル管理との交渉
・緊急時のホテルの手配

これはいい加減にしろと言いたいのが
・設計から漏れたプログラムの追加設計
・設計から漏れた機能に対する害虫の手配（選定/発注）とそのプログラムの詳細～単体テスト管理

【蝶】 **!dama** · 2015/01/02(金) 15:19:35.47

>>180
お疲れさまです

**仕様書無しさん** · 2015/01/02(金) 23:36:01.03

あの人とは生理的に無理

**仕様書無しさん** · 2015/01/03(土) 08:54:28.03

まだmapやってんのかよｗｗｗｗ
だから、ここは「あの人じゃないと無理と言われるレベルの人」がくるところで、おまえら雑魚がくるとこじゃねーよｗ

**仕様書無しさん** · 2015/01/03(土) 11:14:36.22

>>182 ふええ

**仕様書無しさん** · 2015/01/03(土) 11:15:11.71

>>183 頭大丈夫？

**仕様書無しさん** · 2015/01/03(土) 12:12:04.02

事実の指摘だろｗ

**仕様書無しさん** · 2015/01/03(土) 12:12:22.41

何が？

**仕様書無しさん** · 2015/01/03(土) 17:14:37.00

>>1
基本、そう言われる人じゃないと仕事来ないだろ今の時代

誰が担当でもいい仕事が来るほど甘くないよ

**仕様書無しさん** · 2015/01/03(土) 17:18:52.02

>>188
SIerはエクセルに画像を貼り付けられるレベルで十分なんよ

**仕様書無しさん** · 2015/01/03(土) 17:36:19.15

>>188
どこがだよ
人海戦術しかやってねー業界が

**仕様書無しさん** · 2015/01/03(土) 18:23:50.74

>>190
だからその他大勢と言われる人じゃないと仕事出来ないって事だろ

**仕様書無しさん** · 2015/01/03(土) 18:27:05.80

その他大勢とは、例えば工場で働く
ライン工みたいなもの？

**仕様書無しさん** · 2015/01/03(土) 18:34:01.09

>>192
そういうこと。体力があって同じ作業を繰り返せる人しか生き残れない。

**仕様書無しさん** · 2015/01/03(土) 18:35:57.84

>>193
そっか。あなたの会社はライン工みたいなのしか
生き残れない会社で、あなたはその会社で生き残ってる
同じ作業を繰り返せる人なんですね。

羨ましくないなぁｗ

**仕様書無しさん** · 2015/01/03(土) 18:36:22.57

ライン工として働くからライン工にしかなれないんだ。
職人として働けば職人になれる。
ITはそれが可能。

**仕様書無しさん** · 2015/01/03(土) 18:38:43.94

ルーチンワークを馬鹿にする人間にいい仕事が出来るわけないけどね

**仕様書無しさん** · 2015/01/03(土) 18:38:54.60

>>194
ライン工がいなければ作れないものもあるんですよ。
設計者がいれば車が作れるわけじゃないでしょうが。
規模が大きいものになれば手に職のある人間を多く集めて共同作業で
役割分担して作らなきゃならない。組織化ってそういうこと。

**仕様書無しさん** · 2015/01/03(土) 18:40:54.69

>>195
ライン工ってけっこう大変だよ。そんじょそこらのひ弱なやつじゃ
そっこうで音を上げる。

**仕様書無しさん** · 2015/01/03(土) 18:42:55.27

>>198
ライン工大変だろうね。
IT土方見りゃ判る。

**仕様書無しさん** · 2015/01/03(土) 18:45:20.11

>>197
規模が大きい事＝良い事じゃないだろ？
そういう仕事は世の中に必要だろうけど
進んでやるような仕事じゃないね。