あの人じゃないと無理。と言われるレベルの人いる? [転載禁止]©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

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