  |
はてなキーワード: システム開発とは
もう誰も覚えていないと思うけど、3年ほど前、ここに、"Hello world!"というタイトルのエントリを投稿した。あの話の続きをしようと思う。
※このお話はたぶんフィクションです。実在の人物や団体とはあんまり関係ありません。
※前回のあらすじ：高校中退→工場派遣→プログラマ→ホームレス→自立支援施設→プログラマ→海外放浪→職業訓練→世界一周アプリを作る
あれから3年、いろんなことがあった。またプログラマとして働いたり、またホームレスになったり、福島で除染作業員をしたり、本当にいろいろあったけど、 今回の主題にはあんまり関係ないのでざっくりはしょる。今回の主題は世界一周についてである。
僕はいつか世界を巡る旅をする。10年くらいかけて。わりと本気で。その計画を立てるためのアプリケーションも作った。でもそのアプリは正式リリース以降、開発が頓挫している。開発を進めるにあたって、致命的な問題があることがわかったからだ。それは、開発者である僕自身が、この世界について何も知らないに等しい、という問題だ。
開発者は、システム化する対象に関して、誰よりも精通していなければならない。業務用アプリケーションの開発なら、 その会社の業務フローについて、社内の誰よりも詳しくなくてはいけない。システム開発とはそういうものだ。そして今度の対象は世界だ。すべての国だ。それを僕自身が知らなくてはならないのだ。
しかし世界は巨大で、そして複雑だ。
国連加盟国は現時点で193か国。それぞれの国の下に州や省や県があり、その下に市区町村があり、そういった階層的な行政単位以外にも、歴史的背景から自治区になっているところや特別行政区、連邦直轄領もあり……。
そういや連邦ってなんだろう。なんとなく知っているようでいて、詳しくはわからない。王国と共和国ってどう違うんだろう。国の形ってなんでこんなにいろいろあるんだろう。いやそもそも国ってなんなんだ。どうすれば「国」になるんだ。
国連に加盟していればいいのか。いや国連非加盟の国もあるじゃないか。国家の三要素（領域、人民、主権）を満たしていればいいのか。しかしそれを満たしていることを誰が認定するんだ。他国からの承認があればいいのか。その他国は誰が国だと承認したんだ。政治的問題から国なのか国じゃないのかはっきりしない地域だってたくさんある。国とか国じゃないとか最初に言い出したのは誰なのかしら。
それは世界一周アプリの開発中に国データをちまちま作っていたときにも思ったことだ。もしかして「国」というのは、僕が思っていたほど絶対的で、はっきりしたものではなく、相対的で、曖昧なものなんだろうか。
わからない。わからないことだらけだ。こんなもの本当にシステム化できるのか。複雑ってレベルじゃねーぞ。これが仕事だったら「うんこー☆」とかいいながら全力で投げ出しているところだ。しかしこれは仕事ではない。これは仕事ではないので、真剣に取り組まなければならないし、投げ出すわけにはいかないのである。
だけど、 どうしたらいいんだろう。世界はあまりに巨大で、複雑で、茫洋としている。何かとっかかりが必要だと思った。基点が必要だと思った。人でも物でも事柄でもいい。それをとっかかりにして、基点にして、少しずつ裾野を広げていけばいいのではないか。そう思って、自分の記憶を探ってみる。僕の基点、時間軸と空間軸の原点、それは子供のころ、ブラウン管の向こうに見た、落書きだらけの大きな壁だった。
1989年11月、ベルリンの壁が崩壊した。僕が9歳のときだった。ニュースは連日連夜、この話題で持ちきりだった。興奮気味に壁を壊す人たち、全身で喜びを表現する人たち、泣きながら抱き合う人たちもいた。世界中が大騒ぎになっているようだった。僕はその映像を、意味もわからずただぼんやりと見ていた。
それからしばらくして、社会科の教科書の世界地図が大きく書き換わった。ソ連という国がなくなり、新しい国がたくさんできたのだという。国がなくなる？ 国が新しくできる？ その意味もまたよくわからなかった。
時間軸は一気に飛び、ベルリンの壁崩壊から20年以上たったころ、僕は生まれて初めて日本を出た。半年かけて海外を放浪した。特に目的もない旅だった。だからその場所に行ったのも、ほんの気まぐれだった。
ベトナムのホーチミン市にある戦争証跡博物館。ベトナム戦争の記憶を後世に伝える博物館だ。旅の途中にふらりと立ち寄ったそこで見たものを、僕はいまでもフラッシュバックのようにありありと思い出せる。
銃器、対戦車地雷、その他さまざまな武器弾薬が「こうやって使われていたんだ」といわんばかりに、実際に使用している場面の写真と並べて展示されている。銃を突きつけられて悲壮な顔をしている男性、道ばたで血まみれになって死んでいる子供、虫の死骸のように雑多に並べられた人の死骸、そんな凄惨な写真がこれでもかと並ぶ。
何か、自分の中で価値観が急速に書き換わっていくのを感じた。頭の中がぐちゃぐちゃになって、いろんな言葉が浮かんでは消えていく。
「資本主義」
「共産主義」
「イデオロギーとは何だ？」
そのとき同時に頭の中に浮かびあがってきたのが、子供のころに見たベルリンの壁崩壊のニュース映像だった。あれから20年以上たってようやく僕は、あの人たちがどうしてあんなに泣いたり喜んだりしていたのか、少しだけ理解できたのだ。
あの博物館で僕がもっとも強く感じたのは、「戦争は悲惨だ」という事実ではなく、「どうしてここまでのことになったのか？」という疑問だった。人が人を虫けらのように殺す、その理由が知りたい。そこには絶対にそれなりの経緯があるはずである。東西冷戦とは何だったのか、僕はまずそれを知らなければならない。
しかしこうなるともう最初から世界史をやり直したほうが早いんじゃないかと思った。よし、時間軸を一気に人類の歴史の始まりまで巻き戻そう。
まずは大河流域で文明がおこる。チグリス・ユーフラテス川、ナイル川、インダス川、黄河。うわー、すげー懐かしい。そして農耕が発達する。食料を安定して収穫・保存できるようになると権力が生まれる。そこからは世界各地で似たような権力闘争が延々と繰り返される。
特に印象深いのが「カノッサの屈辱」だ。十代のころ、学校でこれを習ったときは意味がわからなかった。この人たちは何をそんなに必死になっているんだろうと思っていた。いまならわかる。目的は、権力そのものなのだ。人の頭を踏みつけること、人を思い通りに動かすこと、それ自体が目的であって、権力によって得られる富や名声は二の次なのだ。それは自分の経験を振り返ってみてもわかる。ヤンキーの世界でもエリートの世界でも、どんな場所でもどんな階層でも、人間が集まれば、始まるのはいつも頭の踏みつけあいである。それが直接的か間接的か、下品か上品かという違いはあれど、やっていることは同じだった。だから世界史に記されたこのくだらない争いの数々も、いまは実感を持って理解できる。
そして絶対的な権力者である神によって凍結されていた歴史が、ルネサンス以降、急速に動き始める。宗教改革、名誉革命、フランス革命。それまで聖職者や王侯貴族が持っていた権力が少しずつ引き剥がされていく。そしてフランス王国はフランス共和国に。ああそうか、王国と共和国の違いって「王様」がいるかいないかなのか。さらに現代の「国」という概念、国民国家というのも、このころに生まれてきたもののようだ。人類の歴史から俯瞰すれば、ここ200年くらいの「流行」にすぎないのだ。
しかしフランス革命って華々しいイメージだったけど、こうして改めて調べてみると、革命政権の恐怖政治によって何万もの人間が処刑されていたり、何度も王政に戻っていたり、混沌としすぎていて、華々しいなんてとてもいえない血まみれの革命だったのだと気づかされる。
そんな混沌の中、産業革命を経て、歴史はさらに加速する。権力のあり方も変わる。聖職者や王侯貴族に変わって資本家が台頭してくる。資本主義が加速する。貧富の差が拡大していく。賃金労働者は悲惨な労働環境で搾取され続ける。暗澹とした空気の中、社会主義・共産主義という思想が台頭し始める。ロシア革命が起こる。世界初の社会主義国、ソビエト連邦が誕生する。
いままで社会主義ってあまりいいイメージはなかったけど、こうして順序立てて成立の経緯を追っていくと、歴史の中での必然性がわかる。みんな、もう誰も頭を踏みつけあわずにすむ世界が欲しかったのだ。だから既存の権力や富や労働のあり方を強制的に変える。そしてそれが国の形を変える。そうか、国の形ってこういうふうに決まるのか。
しかし計画経済ってなんだろう。どうしてそんなものが必要になったんだろう。と思って、初心者向けの経済学の本を何冊か読んでみた。めちゃくちゃおもしろかった。経済ってこういうものなのかと思った。市場経済では必ず景気は好況と不況を繰り返し、いつかどこかで恐慌を引き起こす。そんな繰り返しをさせないために、計画経済では政府の計画にしたがって商品を生産する。そうか、そんな経済の形もあるのかと思った。ずっと現代日本で生きてきた僕にとっては、市場経済があたりまえすぎて、市場の自由がどうの規制がどうのといわれても、これまでピンとこなかった。「あたりまえ」のことは、対比されるものがないと、それを知覚することさえできないものなのだと知った。
その市場経済へのアンチテーゼとしての計画経済は、しかし破綻する。いつ、どこで、誰が、何を、どのくらい欲するか、なんてことを計算し尽くすには、リソースが足りなさすぎたのだ。結果が出ているいまだからいえることなのかもしれないけど、少数の頭のいい集団の演算能力よりも、多数の平凡な人間の無意識的な分散コンピューティング（見えざる手）のほうが演算能力は遥かに高いのである。
そして社会主義自体も破綻する。ソ連型の社会主義では一党独裁を必要とする。しかし絶対的な権力は絶対的に腐敗する。それは歴史が証明している。独裁政権は必然的に暴走していく。これも僕は経験として知っている。「いじり」がいつも「いじめ」に発展するのと同じだ。他人をおもちゃにできる、自分の思い通りにできる、これは権力である。そして「いじり」は場の空気によって正当化されるので抑制がない。抑制のない絶対的な権力は暴走する。だから 「いじり」はいつも「いじめ」に発展する。企業内のハラスメントや家庭内の虐待も同様だ。人間は好き勝手にできる状況に立たされたとき、好き勝手に振る舞うものなのだ。そうか、チェックアンドバランスってそのために必要なのか。絶対的な権力は絶対に生み出してはならない。権力は絶対的に抑制されなければならないのだ。三権分立を唱えたモンテスキューさんマジパネェすわ。
こうして自由主義・資本主義の矛盾への疑問から生まれた社会主義・共産主義は、自身に内包していた矛盾によって自壊していく。そして時間軸と空間軸はまた原点に戻る。冷戦の象徴であり、永遠に世界を二分し続けるかのように思われていたベルリンの壁が、ささいな行き違いからあっけなく崩壊する。ほどなくしてソビエト連邦から次々に構成国が離脱し（国が新しくできる）、連邦は解体される（国がなくなる）。
天秤の片方から社会主義・共産主義が脱落したことにより、その後、世界はまた自由主義・資本主義へと大きく傾いていく。混合経済の社会主義的な部分が次々と取り払われていく。その結果が、派遣法改正だったり、リーマンショックだったりするのだ。そしてそれらは僕の人生にも多大な影響を与えている。そうだ、これはひとごとではない。遠い昔にあった「歴史」でもない。僕がいま生きている「現代」の話なのだ。
そうか、世界ってこういうふうに動いていたのか。少しずついろんなことがわかってきた。国とは何か。イデオロギーとは何か。なぜ法の支配が必要なのか。なぜ憲法が必要なのか。しかしそれよりも何よりも、ひとつ重大な事実を確信した。それは、世界のすべてを知ることは絶対にできない、ということだ。
ミクロの領域――個人の感情や行動、これはわかる。マクロの領域――世界の市場や情勢、これもわかる。しかし両者がどのように関連しているのか、個人の感情や行動が、どのように影響しあい、どのような力学が働いて、世界の市場や情勢を動かすのか、逆に、世界の市場や情勢が、個人の感情や行動にどのような影響を与えるのか、それを計算し尽くすことは、誰にもできない。それは人間の演算能力の限界を遥かに超えているからだ。
「俺は世の中の仕組みをわかってる」「裏の論理まで知ってる」と嘯く人にはたまに出会うけど、そういう人が本当に世界の仕組みを知っていたことは一度もない。本当にただの一度もなかった。陰謀論はマクロとミクロの間にある巨大で複雑な回路をショートさせただけの反知性主義にすぎない。僕はそんなチートに興味はない。僕は真正面から、正攻法で、その回路を解析したいのだ。そうでなければ意味がない。
ああ、そうか、経済学とは、それを解き明かそうとする学問なのだ。マクロとミクロの間にある巨大で複雑な回路。それを解析するのが、経済学や、その他の社会科学なのだ。僕はそれを、もっと深く学ばなければならない。
進むベき方向性は見えてきた。しかしここからどうするか。独学ではもうこのへんが限界のような気がする。つぎはぎだらけの学習じゃなく、もっと体系的に学びたい。でもどうやって学べばいいのかがわからない。僕はまず、学び方を学ぶ必要があるのだ。それには、どうしたらいいのか。
大学に行く。どうしてそんな選択肢が浮かんできたんだろう。これまで僕の中にそんな選択肢は存在していなかった。そのはずだった。これまでずっと金も時間もなく、ただ日々の生活に追われるばかりで、そんなことを考える余裕は一切なかった。そんなことを考えるくらいなら明日の飯の心配をしたほうがいい。ずっとそう思って生きてきた。
何より僕には自信がなかった。自分みたいな中卒の人間が高等教育を受けたところで何の意味もないと思っていた。そんなの僕にはまったく関わりのない知識階級の人間の世界だと、大学なんて僕にはまったく何の関係もない、別の世界に存在するものだと思っていた。
でも思い返してみれば、その認識は少しずつ変化していた。いろんな仕事をしたり、あとさき考えず旅に出たり、プログラムを組んだり、文章を書いたり、そしてそれを不特定多数の人の目に晒したり、ずっと何かに追われるようにそんなことを繰り返してきたけど、その過程で、僕は何か大切なものを拾い集めてきた気がする。それはたぶん、自尊心と呼ばれるものだ。幼いころに失い、ずっと欠けたままだったそれを、僕はこの歳になって、ようやく取り戻すことができたのだ。
だからいまは自分が高等教育を受けることに意味がないだなんて思わない。大学が別の世界に存在するものだなんて思わない。ああそうか、だからいま、このタイミングで、「大学に行く」という選択肢が、僕の前にあらわれたのか。
あとはこの選択肢を選び取るかどうかだ。
いまの時代、大学に行くなんてそんなにたいしたことじゃないのかもしれない。だけど少なくとも僕にとってそれは、とてつもなく勇気とエネルギーが必要なことだ。ホームレスになることよりも、右も左もわからないまま海外に飛び出すことよりも。
現実的な問題もたくさんある。資金、学力、人生の残り時間。いろいろと考え始めると、解決しなければならない問題が多すぎて、わけがわからなくなってくる。もうどうでもいいじゃないかと投げ出したくなってくる。でも僕の中の何かが、そうさせてくれない。僕の中の何かが、そうじゃないだろうと責め立てる。
これには覚えがある。この熱には覚えがある。これは、あの旅の途中、自分の中に発見した、マグマのような熱量だ。感情になる前の感情。行動になる前の行動。名前なんてつけようもないほどプリミティブな衝動。僕はいままさに、それに直面している。そしてその熱量からは、どうあがいても逃げられない。それだけは確信できる。
だったらもう、覚悟を決めるしかない。本当にもう、そうするほかどうしようもない。
僕は大学へ行く。
そうやって覚悟を決めてみると、ものすごく気が楽になった。気分が軽くなった。
ああどうしていままでこんな簡単なことに気づかなかったんだろう。その想いはずっと自分の中にあったのに。
閣議決定された「日本再興戦略」改訂2015を流し読みしてたら、国が本気で多重下請け構造を無くしてITドカタを解放(または追放)しようとしてたので取り急ぎ転載
IT 産業は、もともと、業務プロセスをコンピュータプログラミングで書き下していく労働集約的な産業であったが、近年、汎用的なパッケージソフトやクラウドサービスの登場等もあり、作業の効率化が図れるようになったことや、IT の役割がコスト削減から付加価値創造にシフトしつつあることから、欧米諸国においては、創造的なシステムの提供・提案による知識・能力集約的な産業に転換が進んでいる。
また、ビジネス変革のスピードに対応した、アジャイルと呼ばれる機動的なシステム開発手法の登場やセキュリティリスクの高まりは、システム開発・運用に高度なマネジメント能力を要求するようになってきている。
しかし、日本の IT 産業では、未だに、決められた要件に従ってプログラミング作業を行い納品するビジネスモデルが根強く残り、このため、労働コスト削減のための丸投げ下請け慣行・多重下請構造から抜け出せず、低生産性でかつセキュリティリスクの高い構造に陥っている。
この状況を脱却するためには、丸投げ下請を防止し、能力・成果・リスク等を適切に評価した取引を推進していくことが必要であり、この観点から、下請代金支払遅延等防止法（下請法）等の法令の適用及びその他の取引適正化の取組についての考え方を示した「下請適正取引等の推進のためのガイドライン」の IT産業分野についての見直しを本年度中に行うとともに、下請法に違反する取引については、厳正に対処していく。
さらに、本年度中に策定するサイバーセキュリティ確保に係るガイドラインにおいても、情報システムの発注者のセキュリティマネジメント上の責任を明確化し、あわせて丸投げ下請の防止を図る。
特定派遣も無くなるし(三年猶予あるけど)、ちゃんとしたプログラマの単価が上がる？
なお今のPG首都圏人月単価528,000 http://www.nearshore.or.jp/engineer-charge/
客からすれば安いほうがイイわけだけど、安くすれば時間も短くなり、できることも少なくなる。
なれた客だと、見積もり時には要件はミニマムで、安く見積もらせておいて、後出しであれこれ要件やタスクを増やしていくといった手法をとる。もちろん、見積もり金額が決定した後では、追加工数は認められないの一点張り。
逆に、いい客は文句言いつつもカネを出してくれる。スケジュールも長くとってくれる。多くは無いがそういう客も存在する。
そういう客にはディスカウントしたいと思うんだよね。タスクのボリュームに対して長いスケジュールを組んでくれれば、作業は余裕が出るし、品質も向上するし、何か問題が起きてもリカバリしやすい。
営業や会社はイヤだろうけど、開発の現場からすればカネより時間が重要じゃん？。
タスクのボリュームに対してスケジュールが長いと判断できればディスカウントする。そういう仕組みがあれば、客も長めにスケジュールを組むモチベーションになるので、客と現場は ウィィィーーーーン/ウィィィーーーーンじゃないですか。
カネ的には一見ベンダ不利だけど、現場が疲弊しにくい状況になれば、人材補充/教育のコストも減るので、中長期的にはそんなに不利でも無いとか言う可能性もあるし。トラブルによる炎上なんかも、時間さえあればボヤで済むケースも多いしね。
どっかにそういう取り組みの実例ないかね。
みんな大好きPostgreSQL。
複数DBマルチテナントシステムを構築するなら忘れてはいけないコネクションプーリング。
大量コネクションを扱うなら都度forkやpre-fork式ではちょっと辛い、イベントベースが好ましい。
もうお分かりですね。pgbouncer1.6の話題です。
PostgreSQL界隈では有名なコネクションプーリングの実装が2つあります。 pgpool-II と pgbouncer。
ざっくり言うと高機能の pgpool-II に対して、軽量・大規模向けの pgbouncer という棲み分けがあると言えるでしょう。
pgpool-II は最近は日本の トレジャーデータ社の Prestogres ( https://github.com/treasure-data/prestogres ) という痺れるようなプロジェクトのベースとして採用されていることで名前を聞いたことのある方もいるのではないでしょうか。
pgbouncer は少し古いですが LastFM( http://www.lastfm.jp/user/Russ/journal/2008/02/21/zd_postgres_connection_pools:_pgpool_vs._pgbouncer )の事例が有名でしょう。Instagram も使ってますネ。
pgbouncerは現行のバージョンは1.5系で、最新は1.5.5です。1.6系は8月1日にリリースされ、複数DBマルチテナントシステムに向けた大規模な機能強化が行われています。
この1.6系では複数DBマルチテナントシステム開発者にとって嬉しい機能がたくさん搭載される予定です。本番運用に投入する前に一足お先にリリースノートを読んで夢を感じましょう。
本バージョン、2013年ぐらいからリリースノートは準備されているのにさっぱりリリースされなくて関係者をやきもきさせていました。（想像）
本記事では以下のリリースノートをもとにザックリ読み解いたものです。
http://pgbouncer.github.io/2015/08/pgbouncer-1-6/
・接続ユーザーやパスワードハッシュをDBからロードできるようになった
・プーリングモードの設定をデータベース毎、ユーザー毎に設定できるようになった
・データベース毎、ユーザー毎にコネクションの最大接続数を制御できるようになった
・新しいコネクション確立を避けるための DISABLE/ENABLE コマンドが追加された
・新しい推奨のDNSバックエンド c-ares が追加された
・設定ファイルに include ディレクティブを追加した
新しく以下のパラメータが追加された
1.5までのpgbouncerは userlist.txt というテキストに静的に接続ユーザを書かなければいけませんでした。
これは動的に接続先ユーザーが増えるようなマルチテナントシステムを構築するのに不向きという事です。
タイトルがすべてを物語ってます。柔軟にできますねぇ('∀`)
ただ、私にはちょっと有用な利用シーンが思いつかなかったです。
たとえば分析用ユーザーではトランザクションなんて使わないので statement モードにしてコネクションの消費を抑えたりできるという事でしょうか。
max_db_connections と max_user_connections という設定が追加されます。
テナント毎にユーザーを分けているような複数DBマルチテナントシステムにとって必須といえる機能です。
特定のユーザーのリクエストにコネクションをすべて占有されてしまい、他のユーザーにサービスできないという事態を避けることができるようになるでしょう。
特定のデータベースの新しいコネクション確立を抑止・再開することができます。
c-ares は名前解決の非同期化を行うためのライブラリです。c-aresは名前解決をブロックしないし、いろいろな方式の名前解決に対応している唯一のプロダクトとのこと。
名前解決をブロッキングしてしまうようではpgbouncerのような大規模向けシステムでは役に立たないのだというpgbouncerの強い意志を感じる。
というか、ドキュメントを見る限り pgbouncer は名前解決にかなりこだわりを持っているらしい。それだけそこが重要ということでしょう
（個人的には困ったことがないのでそこまでだわる理由はよくわからない。）。
UNIXドメインソケットで接続しているクライアントと、TCPまたはUNIXドメインソケットで接続しているサーバーでremote_pidを取得できるようになりました。
tcp serverの場合、pid はキャンセルキーから取得できる。（？ドキュメントから意味が読み取れず）
キャンセルキーとは何でしょうね。ちょっとリリースノートからは判断できませんでした。
pg_cancel_backend とかに使えるPIDだよという事なのでしょうか。
DBの数なんてもはや何台あるかわからない。ホスト名の解決はもはやDNSで行っておるよという皆様にとって必須の機能。
…なのでしょうが、ちょっとこの機能が必要となるようなシステムとはどんなものなのか、私も未経験なのでよくわからないです。
この設定は application_name_add_host=on にすることで有効となる。
今や接続元アプリケーション名がWebだとかBatchだとか区別できるだけで問題が解決するような時代ではない。
どのホスト(ポート)レベルで区別しないと。という事なんだろう。
「おお、Webサーバーから死ぬほど重いクエリが飛んでる、今すぐ調べないと！で、どのWebサーバーよ？100台あるんだぜ」みたいなときに助かりますね。
設定ファイルが大規模化してくると、切り出して整理したいという要望はどうしてもでてくるもの。
データベース毎、ユーザー毎に設定できる項目が増えてきたので必要になったという事でしょう。
以降はバグフィックスとかクリーンアップだとかで自分はあまり興味がないので各自読むように。
本番運用に突撃するPostgreSQL界の猛者の報告待ってます。
30代半ばの男。
起業直後はモチベーションの塊だった。サラリーマン時代から仕事大好き人間だったけど、会社を作ってからは更にやる気がみなぎっていた。
自分でパワポに描いたとある商材の購入サイトの概要図（落書き）を持って、上場企業へ電話アポ→会ってくれた人に「こんなん作りたいんで、広告出してください」とお願いした。
営業の経験なんかなかった。元々事務職で口ベタ、さらに人付き合い苦手で内気な性格だが、やらなきゃならんという覚悟と異常なモチベーションがあれば突っ込んでいけるもんだ。
会ってくれた人から「パワポだけじゃわかりません。今、デモサイト見せてください。」と言われ、「システムはこれから作ります。デモはそれまで待ってください。」とカミカミで返答したときの呆れられた顔。静まる室内。緊張感。でもひるまなかった。大きな問題なんかないんだ、あっても何とかする！前に進むことしか考えられないバーサーカーのような状態だった。
こうして勢いだけでなんとか最初の難関「営業」が終わった。
何社か回ったうち、数社から好感触を得たのでサイトの開発に着手した。といっても開発の経験なんかない。調べたところ、WordPressとRuby on Railsというのを使えば求めているサイトが作れるようだ。お客さんには開発に数ヶ月かかると伝え、WPとRailsについて最低限の勉強をした。そしてWordPress、Rails、それぞれの開発で有名な人に少しだけ時間をもらって話を聞きに行き、判断に迷う部分の方針を確定させた。そこからガリガリ開発して、必要最小限のシステムが完成した。サイトが流行るかわからんのだから、最初は最低限でいいんだ、という考え。お客さんには予定どおり開発が終わりましたと伝えたが、スケジュール的にはギリギリだった。というかRailsがわからなくて開発自体できないんじゃないかと思う瞬間が何度かあった。しかしバーサクがかかって喰う寝るタレる以外はずーっと仕事に打ち込んだ結果、なんとか開発はできた。これで第２の関門「システム開発」が終わった。
そしてめでたくシステム運用開始＆サイトオープン（サイトはWordPress、連携して動くシステムがRails）。
一日のアクセス数が○件で、そのうち○パーセントがコンバージョンして...と皮算用していたが、実際には全然コンバージョンがなかった。
そこから色々とWebマーケ的な工夫をしたが、結局「そもそも需要が少ない」という根本的な問題の前では、枝葉の工夫など無意味に等しかった。
商材のサイトは失敗した。だが会社の売上を上げなければならない。そこから最初のサイト＋システムのビジネスモデルとは全然無関係な仕事を探し、やれそうなことはやってみた。そうしているうちに、当初考えていたビジネスではなく、注文を受けて何かをやる、代行業のような商売がメインになった。
そのうち、商売では何が必要なのか？どうしたらお金を出してまでやってほしいと思われるのか？ということが見えてくるようになった。同時に、先のサイトでのビジネスが失敗した理由と、成功させるために必要なステップを飛ばしていたことに気付いた。また、新たにビジネスをつくるには、"事前に"人を巻き込むことと、そして...ここぞというときにギャンブル（まとまった投資）をしなければ次の段階にいけないことに気付いた。人を巻き込むこととギャンブル。どちらか一方じゃなく、両方必須。だがどっちも本来の自分の性格には合わない。ここでふと自分の限界が見えてしまった。
起業当初は無知ゆえに、小さいサイトを金かけずに一人で作ってコツコツやればいつか認められ拡大していけるような気がしていた。そんな可能性を夢見て、様々なビジネスアイディアを手帳に書いてはモチベーションが上がっていたが、今じゃアイディアを見ても自分にはできないと無意識的に判断してしまう。そのアイディアをビジネス化するのに必要な人間関係の構築。取るべきリスク。この２つが頭に浮かぶと、（自分には）できない、という結論になってしまう。
いつのまにか"できること"から発想するようになり、平々凡々とした仕事だけするようになってしまった。
そんな日々を送っていたら、起業当初のモチベーションが消えていた。変に知識がついたせいか、期待感・高揚感より、実現するためのステップやリスクが頭をもたげてくる。今じゃアイディア勝負なんかやる気がしない。現実的に売上が上がることしかやる気がしない。
何のためにわざわざ会社つくったんだろ。この先どうしようか。
多人数でシステム開発をする場合「統一性があったほうが読みやすい」なんて理由で、言語別・組織別・プロジェクト別にコーディング規約があるものだけど、そんなに乱立しているなら個人別の規約があっても何も問題はないはず。
これは詭弁だろうか？ でも個人的な開発や、開発中に読むサンプルコードも含めて、自分がいくつのコーディング規約に関わっているか考えてみると、個人から見た統一性は失われているわけだ。
「整理」と「整頓」という言葉がある。前者は秩序立てること、後者は見た目を揃えること。本を分野別・用途別に並べれば整理、大きさ別に並べれば整頓となる。
コーディング規約は専ら整頓のルール。読めない人にとって「きれい」に見せるルール。
コードの意味に関わらないからこそ、実装後に修正ができる。さもなければ、正しいコードは自然とコーディング規約に適うものになるはず。コードの正しさと無関係だから、正しいコードでもコーディング規約違反だったり、コードを理解していない人でも指摘できたりする。
コーディング規約を作って発表する人もいる。でもそれがどれだけ生産性を上げるかについては考えていない。作りっぱなし。そんなルールに「あとで読む」タグを付ける人たちは、プログラミング言語に表現の幅があることを欠点と捉えているのだろうか。本来そういったルールを作っていいのは言語の考案者だけのはずなのに。
あるにはあるけど、言語に組み込まれているライブラリと同じ規則がベストなので、やっぱり規約は要らない。
あとは自己満足。
・ニトリのシステムコンサル（経歴だけやたらすごいことを主張し横文字ばかり使う）がGoogleのパンダアップデートを機にニトリネットのリニューアルを提案
・その際に、自分の懇意にしているシステム営業を連れてきて提案させる（CTC)
・CTCのMAMSを導入することを決定し、基幹システム等のつなぎ込みプロジェクトが開始
CTCでの受注額はおそらく数億〜十数億レベル（３年保守契約含む）→コンサルには５％キックバック
・この時点で、以前にニトリネットを依頼してた会社（０社）の足切りを決定。
・０社は引き継ぎは１ヶ月しか行いませんと明言、ニトリ担当者了解する。
・CTC下請けへ開発を投げる。そこそこ中堅規模の開発会社（A社）が５０００万で受注。
・B社、コンペで募った会社（C社、D社、E社）の中から、一番デザインが良さそうだったD社に３００万で発注。
・D社、デザインはできるがシステム開発ができないので、よく外注依頼しているF君に１００万で依頼。
・D社が上に上げたデザインが、ニトリ側で何度もリジェクトがかかり、作り直しを余儀なくされる。
・それに伴い、F君の作業もいきつ戻りつ、リニューアル１ヶ月前の状態でトップページもまで完成していない状況に。
・不眠不休の１ヶ月を過ごし、ベータ版を完成させるが、ニトリ本社でのレビューで、これでは
リニューアルができないという決断になり、リニューアルを延期させる（この時点で５月）
・６月１日リニューアルということになり、さらなる不眠不休の作業が続くF君。
・しかも遅れたんだからということで、追加仕様がバンバン舞い込む。
・なんとか見せれる形のものになったので、これ以上伸ばせないという決断になり、リニューアルを向かえる。
・リニューアルは、新インフラ環境で行われたため、前の環境は残っていない。（会員データも登録しなおし）
・リニューアルを行うが、高負荷対策が全く行われていないため、すぐにサイトがみれないようになりサーバーCPUは振り切る状態に。
・もう辛くてこの先かけない。
夢のあるシステムに関わりたい。
いわゆるプログラマをしているが「屑システム」にかかわりたくない。
「屑システム」とは以下だと思ってる。
なお、一応言っておくと、私がかかわっているシステムすべてが以下に当てはまるとは言ってない。
自分が開発にかかわってるが、開発が進んでも自分の利益にならない。他人の懐具合がよくなるだけ。
安月給はもらってるから、それで満足しろということになるわけだが。
その安月給は当然あがることはない。私から見れば立派な「屑システム」だ。
枯れた技術だけが使われ、そのシステムにかかわったことが何の宣伝にもならない。
例えばいまさらsyslogが使えます、とかsnmpが分かります、とか意味なす。
細かいとNoSQLとかクライアントサイドJavascriptとか。
次につながるようなシステム開発がしたい。そういう意味で「屑システム」
「システム」とは、プログラムそのものだけを意味するわけではない。
プログラムを開発する、開発プロセスそのものも「システム」である。
例えば、ある作業をやったら、諸事情で無駄になるようなのが「屑」な開発プロセスだ。
責任者に、リーダシップがないせいだ。あるいは、プログラマに何の権限もないと起こる。
人間だから、全部有効な作業というわけにはいかないが、そんなんばっかりだとやる気にならない。
なお、リーダーシップというのは権限とセットだ。責任とセットなわけではない。
プログラムを作る責任だけあっても、その責任を全うできる権限がない以上
上と被るかも知れないが、一週間に一回も会議を行わないようなのも「屑システム」だ。
確かに会議だけしても意味ないが、しなくても全く情報共有ができず、プログラマは何していいかさっぱりわからない。
また、各作業員の間で信頼関係がないのも、なかなかに屑システムだ。
どうもスーツです。
http://b.hatena.ne.jp/entry/d.hatena.ne.jp/NOV1975/20150512/p1
これのはてブと元記事見て血圧上がったので、チマチマ反論するよ。
記録を軽視するな。
業績が個人について回ったら、誰も保守しないだろ。
金を生むのかそのドキュメントレビュー。リファクタリングでいくら稼げますか？
ロボットアニメの博士みたいにな、空中から予算が湧いて出たりしないんですよ。
誤解があるみたいだから言っとくが、評価には減点も加点もある。
ただ、スケジュール前倒しで予算が浮くようなシステム作ったりしてないだろ。
何故ならばスケジュールは常にキチキチで、間に合わなきゃ減点されて当たり前だ。
そこは同情する。
見積は常に過少で、調整は過小評価され、日程だけが評価軸になりがちだ。
オマエらが椅子を滑らせて隣の同僚と１分会話して実施した内容は、キサマが風邪引くと誰にも共用されない。
コードレビューした。仕様書レビューした。まあギークが言うなら内容に間違いはないんだろう。
だが、その部分は三年前に転職した同僚がやったはずです？それじゃダメなのは判るよな？
オマエ独りで完結するプロダクトをオマエがケツもって仕事するなら文句は言わないが、違うよな？
本来は「指摘事項ゼロ」「問題がないか再精査しろ」「再精査したが無い」「一筆書け」「書いたから通せ」をやるのが正しいというのは判る。
やって欲しいのか。
ギークが不要だと思ってるレビューに、さらにチェックリストが加わったり、書類が増えたりするぞ。
正しい数字で出せ。
恐らく上から順番に怒られた上にいらん書類を書かされた上に再発防止策を延々と書いた挙句、本業であるコードを書く仕事が遅延して、さらに同じことがループするが。
政治的に正しいんじゃ無いんだよ。
そうした方が、ギークの遅延が少なくなると思うから、スーツが知恵絞ってんだ。
ギークが一度遅延したが最後、遅延が無くなるまで延々と再発防止策（しかも一度着手しているのでスケジュール見積もりについて以外でだ）書かされるぞ。
その「どんなに正しくても」は、どこの誰が担保してるんだ。
ギークの勘か？
オマエが言えよ。
言えないならその立場に無いってことだ。
「常識で考えればこうする」というのは、何時の時点の誰の判断だ。
たった30年前までメインフレーム全盛だったが、常識的に今後はオープンシステムだと断言できたか？
違うだろ。
オマエの書いたソースが間違ってて、コンピュータはソース通りに正しく動くんだよ。
バッドノウハウなのは認めるが、誰も幸せにならない正しさを貫くことはギークとしての職責の一部か？
もしそう思うならそうしろ。
責任は取られてるんだよ。
はんこの数だけな。
機械学習の重み付けと同じでな、それがスーツの出世パラメータに影響してんだよ。
記録を軽視するな。
証拠を残せ。
「なんでバグが無いのが判ってるのに単体テストするんだよ」とか言って、テスターがサボったら困るのは誰だ。
ただ、監視システムにタイムレコード追加するより、カメラ範囲内に時計を置くのがハックなんだろ？
コードスニペットは溜め込むくせに、口頭で言った内容をメールで送れないのは何故だ？
ギークなら可読性を上げろコメントを残せソースを引き継げるようにしておけ。
JavaコンパイラにC++のソース突っ込んだってエラー吐くだけだ。
まあ、見通しが悪いと思うなら、オマエが新言語作ってくれても良いんだぜ？
もうこれは転職できるなら転職すべき。直近の転職は厳しくても視野を広げるような活動をすべきだと思う。
技術的なスキルを身につけることは、選択肢を増やすことであって、常に良いことだと信じてきたが、そうではないんだと気付き始めた。
新たなスキルを身につけるための投資が収入リターンに必ずしも結びつくわけではないが、新たなスキルを身につけたことによってエンジニアとして得られるものはあっても失うもなどまぁない。
もしスキルを身につけることが常に良いことだと思えないならば、もうそれはエンジニアとしてやっていくつもりがないか、自身がエンジニアとしてやっていけないと思っているか、所属している組織が新たな技術を得ることに対して明確にメリットがないか、のどれかだろう。新たな技術がその所属組織で生きないとしても、スキルの選択肢の広さは転職という自身の選択肢の広さにもつながるはずである。
とはいえ実務上の課題をクリアするために新しい技術や高度なテクニックを取り入れる必要性はそんなに珍しくないし、そういったステップを踏まずに会社は成長できないはずだと思う。 だけど、実際問題それをやると属人化は着実に進む。
属人化が絶対悪のように語られるが、そもそもシステム開発の利益の源泉はエンジニアであり人である。どうあっても属人化は避けられない。属人化をどうコントロールしていくかが問題なのだ。もちろん属人化をコントロールする1つの手法として新たな技術を導入しないという選択肢はあるし、状況によってはそれは決して悪い選択肢でも無いのだが、それは属人化を避ける数ある選択肢の1つでしかない。属人化を恐れるがために技術の歩を止めるという決断は、新たな技術の導入とともにある程度の属人化を受け入れるという決断よりも、一般的に慎重に検討がなされるべきである。属人化という言葉の前に思考停止に陥ってはならない。
それらを解決するには技術力が必要なんだけど、それは自分ひとりが身につけるだけではダメで、その必要性を他のメンバーにも理解してもらい、実際に身につけてもらう必要がある。
せいぜいできるのは草の根的な勉強会を開いたり、業務に使った技術の詳細を休日に個人のブログに書いて社内チャットに貼ったり、マネージャーに許しを得た範囲で別の誰かに引き継いだりといった程度。
エンジニアとしてこういうマインドを持った人がいるのは現場としてはありがたい。そういう人がいる現場といない現場では、技術に対する姿勢に差が出ることもある。しかし一緒に働いているメンバーがそれを理解しているか、マネジメントがその意味を分かっているかは完全に別問題だ。もし自分がやっていることが理解されていないと思うのならば、その現場においてそれが本質的に必要でないか、現場が燃えていてそれどころではないか、他の人から見て意図が理解できていないかのいずれかの可能性が高い。
自身にとってその組織にいることについてメリットがあるのかどうか再考すべきだろう。もしメリットがないなら転職を考えるべきだし、メリットがあるのなら「今の自分がその組織でできると思っていること」の枠を超え、あらゆる手段を用いて「職場全体のスキルを上げる」という目的を完遂すべく行動すべきだ。マネジメント権などクソくらえだ。（とはいえ、できるならば他人の権利を侵害しない範囲でうまく遂行する方がいいのだけれど。）
いっそすべて忘れて辞めてしまえば楽になれるんだろうとは思う。
辞めて楽になれると思えるのならば、いっそ辞めてしまったほうがいい。幸いにして新卒入社5年目という人生において転職にはいちばん最適な時期だし、エンジニアでもあるようなので転職には困ることはまずないだろう。エンジニアの転職市場も絶賛売り手市場であるし、スキルがあって手が動かせて、現場にも目が配れるエンジニアなんて欲しいところはいくらでもある。いいエンジニアは現場にも転職市場にもガッツリ不足している。というか、エンジニアそのものが不足している。今いるところに不満があるくらいならば、そうでない環境を探すには絶好のチャンスである。加えて、転職は自身のスキルにも仕事のしかたにも視野や人間性といったものですら広げるいい手段であり、チャンスだ。
もちろん転職に踏ん切りがつかないということもあるだろう。気持ちは分かる。なのでいきなり転職じゃなく、外部でやっている勉強会に参加するというのがやりやすいわりに得るものが多い方法だろう。
外部の人間と触れることで自身の置かれている位置が今までよりも客観的に分かるし、もしかしたらいまの所属組織のいい面を見つけるという機会になるかもしれない。もしもう勉強会に足繁く通っているようならば、「勉強会で発表してみる」とか1つステップを上げてみるのもいいだろう。
転職することがあったら、自分が真ん中以下のレベルになれるところに入りたい。
本当にこう思うならばベンチャーとかオススメ。エンジニアが自分しかいなくて「自分が真ん中以下のレベルになれるところ」どころの話ではないというケースも往々にしてあるし、他にエンジニアがいたとしても「自分が上か下か」なんていっていられる余裕がなかったするケースもある。少人数だと、スキルの上下の判断ではなく「エンジニア個人の芸風の違いが、ベンチャーという組織に対して影響を与える」という体験もできたりする。そういう中で自分の芸風を作っていくのは大変だけれども…存外これが楽しかったりする。
元々は化学科の大学を卒業して、ゴム部品製造をしている会社で図面を書いていた。
ある時、設計から管理に移動して、CADのアドインを自前で作るようになり、プログラミングっておもしろいじゃん！と思い
転職を考えるようになったが、そんなアクティブに転職をすすめるようなことはしなかった。
結婚し、子供が生まれ、家を買い、まぁこのまま製造業していくんだろうなと思っていた矢先、会社の経営が傾き希望退職者の募集が始まった。
会社からは残ってほしいと言われたが、千載一遇のチャンスだと思い、割増退職金と無償の就職支援会社斡旋をもって会社を辞めた。
これが２０１３年の５月（３２歳）。
就職支援を得ていくつかのIT企業を紹介され、業界未経験であるにも関わらず前職とほぼ同じ給料で雇ってくれた会社が今の会社で
入社したのが２０１３年の７月。
この会社は、大手SIerの２次請を主な生業としており、細々と自社パッケージを取り扱う感じの従業員１００名前後の会社。
まず驚いたのは、求人票に「残業手当あり」と書いてあったので当然残業代全額支給だと思っていたが
内定書には「裁量労働制適用」とありみなし残業代が毎月１０時間分つくだけだということ。
「これがIT業界というやつなのですね！」と、前職の製造業では考えられない条件を簡単に受け入れられたのは今でも不思議。
入社してからおおよそ１年半、携わったのは１人から３人程度の小プロジェクトのみで、官公庁向けシステムの改造がほとんど。
しかも、言語はすべてVB系（6.0、.NEt、VBA）、データベースはアクセスとスーパーマイナーなみたこともないもののみ。
それでも、知らないことを初めてやるのは新鮮で楽しかったし、勉強にもなったが、最近なんか違う、このままじゃだめかも、って不安になってきた。
このまま、VBで小さいシステムの改造だけやってて、将来大丈夫？
最近SIerの未来は暗いっていう記事たくさんみるけど、今の会社はクラウドとかの今風の技術はまったくやらないし、大丈夫かなって感じてきた。
つい最近、掲示板に「SVNってすごくいいツールがあるから、みんなVSSから乗り換えてみない？」って書いてあって、とても不安になった。
二番に、ちゃんとソースレビューとかしてもらって、もっと色々学びたいって思ってること。
「自分で勉強しろ！！」って思うかもしれないが、社内にソースの内容について語れる人がほとんどいないし、既存ソースはとても古臭く
オブジェクト指向すらあやしいものばっかりで、とりあえず動けばいいやって感じが読んでて伝わってくるし、プロジェクトでも実際にそう言われてる。
残業代でないって普通だと思ってたけど、出るとこも普通にあるんですね。
昨年末、別プロジェクトで納期３カ月おくれてるとこにヘルプで行った人達は、平日は毎日泊まり込みで休日出勤も当然して
総労働時間は私の倍はいってるはずなのに、たぶん給料は私と同じくらいしかもらえない。
自分のことじゃないけど、これはやってられないなと思った。
てなことで会社を変えたいなって思ってるんですが、私の経歴で他に雇ってくれる会社ありますかね？
もうシステム開発とかVBとかじゃなくて、パイソンとかルビーとかでWebとかやりたいなぁ。
無理かなぁ。
マルチタスクの核は、それぞれのタスクを可能な限り細切りにし、何か一個細切りタスクを片付けるたびに意識を切り替えて別の・・・という手法に尽きる。
しかし世の中には、このやり方でマルチタスク化できない仕事がいくつかある。
ちなみに同じITでも構築・保守・運用といった業務は、案件によっては確かにやることは山ほどあったりするのだが、上述の「細切り化」が十二分に効くため、担当がADHDとかでもない限り、大して泥沼化せずに済む。
開発はこうは行かない。
いざ取り掛かったら、一度に一つのことしか考えられないのは当たり前、更にまとまった時間を確保して取り組まないと、効率やアウトプットの品質が著しく低下する。
しかも「まとまった時間」というのは必ずしも数十分とか数時間程度で終わることを意味せず、数日に及ぶことも珍しくない。
これは開発者の有能・無能関係なく、全てのスタッフに当てはまる。
なまじ難しいことをやっているせいでメンバーの替えも中々利かない。
お陰でその他のIT系業務と比較して、システムの規模や複雑さの度合いに応じたコストの上昇具合がハンパない。
じゃあその分金額で納得すればいいかと思いきや、仕様とコストを妥当に紐付ける定性的・定量的手法が未だに存在しないため、掛かったコストの分だけ客からキッチリお金を貰うことも難しいと来ている。
というわけで、一言で言い表すなら全く以て「割に合わない」のだ。
気がつけば十数年、ITの世界で開発を中心にその他の仕事も時々含めつつやってきたけど、年々この開発の「シングルタスク強要」を余儀なくされる性質に、怒りと苛立ちを感じるようになってきた。
個人的には開発は、欠点だらけの自分の中でも「そんなに好きじゃないけど得意(家では殆どコードをいじらない程度だけど、大した手間をかけずに作ったものが想像以上に驚かれ、喜ばれることが今まで多々あった)」な数少ない能力だったりする。
だから出来れば今後も何らかの形でコードに関係する仕事を続けたいのだが、現実には開発に入った途端、帰る時間が有意に遅くなるし、やってる内容が込み入りすぎて誰かに相談に乗ってもらうのも一苦労だし、何より生産性という観点だけで「落第」扱いの評価になってしまう。
最も得意なことをやっている時のほうが、そうじゃないことをやっている時よりキツい上に評価が落ちるとか、何もかもバカバカしくなってくる話である。
どうして開発だけが、こうも突出して面倒なんだろう。
結構長い間この仕事やってるけど、未だに何とかなりそうな気がしない。
うん。分かる分かる。
過去に掠っただけの経験を盛って何とか面談相手のニーズに合致してますアピールをしなきゃならないこの苦しさ。
日本のシステム開発の現場って無駄にギョームケイケンを求めすぎなんだよな。
どの現場も作ってるもんは画面の入力内容をRDBMSに保存して、画面やら帳票やらファイルに出力するだけ。
オンラインとバッチ、汎用機とオープン系、この位の粒度で経験がかぶってて、オブジェクト指向の言語どれか一つ使いこなせりゃ別に現場に入ってから学習で全然事足りるし、業務知識なんて販売管理やら在庫管理やらの一般的な業務システムの知識を本とかで仕込んでおいて後は現場で覚えりゃ十分。
まるで、専門知識がなければ戦力にならないかのようにみんな面接してくるけど、どうせお前外部の人間にそこまで深くコミットした仕事させねーだろって思うわ。
Matzが凄いという話はわかるんだけど、古来から島根発信の宝があり現代にはRubyという宝があると島根県推しな紹介で、Matzが現在島根在住なだけで島根にそんなに必然性はないと思うし、確かRubyが生まれたのMatzが島根いるときじゃなかったと記憶していてwikipedia見たら静岡県って書いてあった。番組でもプログラミングは地理的な制約を受けないとか言っててなんかモヤモヤする。島根でRubyが盛んなのは知ってるけど、それもMatzを軸に県とかが支援して広がりを見せてるからで、結局Matz様様。まあ細かい話はいいんだけど、番組の意図がいまいちわからなくて、森永卓郎氏がゲストな点や人口流出阻止や県の産業はRubyを使ったシステム開発だ（プログラミング言語ありきでの開発もどうかと思うけど）みたいな意図で県とかが支援して作られた番組なのかな～と勘ぐりながら最後まで見た。森永卓郎氏の例え話は分かりやすいなと思った。
追記
日本のIT業界の多重下請け構造が悪だ、Slerがクソだ、みたいな話あるけど、論点混ざってることが多い。
どっちかというと「仕事を出す側」として、多重下請け構造の問題点とポイント書いとくよ。
必要とされる多重請負と、ブラックな多重請負があって、分けて考えないとイカン。
ハナキンなのにやっと終わって一人酒だよ！
発注者から直接仕事を請け負った元請け担当者（大抵の場合、安請け合いする部長）が、
請けた仕事を切り出して、課長、各チーム主任、ヒラと仕事を下ろしていく。
ピラミッド構造で上意下達で、力関係も対等ではないが、こういうのは多重下請け構造とは呼ばれない。
そして、仕事の報酬が会社に対して支払われ、各員には会社から給与が支払われる。
「オレの言う多重下請け構造と違う」と言われても何なので、定義はそのまま引っ張ってこよう。
発注者から直接仕事を請け負った元請（たいていの場合が大手SIer）が、
請けた仕事を切り出して2次請け、3次請け、4次請けと仕事を下ろしていくピラミッド構造の事を言います。
良くある例で言うと、元請は要件定義や概要設計等の上流工程を請負い、開発・実装などの下流工程は2次請けに委託する、というような構造です。
これ、多重下請け構造の問題点じゃなくて、受注価格交渉の話なんだよね。個別。
例えば、一社のみなら給与体系の話になるわけで「部長が中間搾取してる！」とは言わない。
さらに「部長が安請け合いするから、現場のエンジニア給与が低い」というのは、一社のみでも起こる。
つまり、「中間搾取」によって「給与が低くなる」というのは、飛躍がある。飛ばしてはイカン。
（以後、n次請け, n+1次請けは、全て元請け, 下請けと表現するな）
1番と2番とは分けて考える必要がある。
まず、エンジニアの給与が低くなるのは、会社の給与体系の問題だ。
ということは、「エンジニアの給与が不当なほど低い」のであれば、それは多重下請け構造の問題ではない。
不当なほど低い賃金で働かせている「本来潰れていなければならない会社」の問題を、多重下請け構造問題で誤魔化してはイカン。
で、元請けと下請けとの報酬差だが「要件定義や概要設計等の上流工程」をやった対価を取って「中間搾取」とは言われたくないだろ。
答えから書くと、さっきの式は以下の形で使われてる。
一目瞭然で、下請け報酬が少ないから、「中間搾取」と呼ばれる「元請け仕事の対価以上の報酬」が生まれる。
つまり、「マージンを抜くから適正単価にならない」ではなく「適正単価でないからマージンを抜く余裕がある」だ。
「要件定義や概要設計等の上流工程」が2000万で、実装やテストの下流工程が1000万で、という区分けをしていない。
仕事の中身で値段を決めずに、人月計算をするから、常に下請けは元請けよりも単価が低く設定される。
なぜならば、元請けは儲けるために下請けに仕事を流すわけで、損するためにじゃない。
というわけで、潰れずに責任とってくれるような大企業しかクライアントは選ばないので、Slerが繁栄する。
一軒家立てるときに工務店を選ぶ人もいるけど、ハウスメーカーも大人気だよね、というのが酷くなった感じ。
これは構造的な問題で、既得権益って言うとそうだね、という話。
じゃあ、なんで請けるの？という話。
まあ、最近はインドとか中国とか、単価低いしアッチで、みたいになってるけど。
請けないと会社潰れるから激安で請けますどうせエンジニアは使い潰せば良いし、みたいな会社が多い。
で、ブラック会社は人が足りないとさらにブラックな会社を呼んで……みたいな泥沼状態。
エンジニア雇ってる会社がブラックなので、結果的に多重請負になってる。逆じゃない。
プロジェクトマネージャがプログラマを鬱で辞めさせました。ボーナスが減ります、となってない。
元請けA、2次請けB、3次請けC…みたいになると、Bが指示してEが無茶苦茶な残業で体壊して、AはExcelしか観てない、みたいな。
クライアントにIT知識がないとか言っても無駄。信頼関係も効率性もある。
ハウスメーカーがお客さん呼び込んで、指定した建材で地元工務店と契約して、さらに左官屋雇って家を建てたりするだろう。
そういう時に、「客が直接知識を持って、左官屋と大工と設計家と交渉すれば安く付く」とか左官屋が言ったりしない。
出版社から直接本を買って、取次とか本屋のことを「中間搾取め！」とか言わないだろ。
IT業界は、そういう「効率のための多重構造」とは違う「果てのないダンピング会社の多重構造」がある。コッチが問題。
さらに多重請負って、普通に偽装請負で命令系統と責任系統が乖離してる。
人壊しても責任とらなくて良くて、補充がいくらでもきくなら、そりゃ無茶苦茶するわな。
まあ、ITエンジニアが育たないとか言ってないで、勉強して転職しようぜ！
「My Job Went To India」の日本語翻訳版がオーム社から発行されたのは2006年だよ！
結局は幹部社員の話のネタか今後の活動指針を決めるに当たってのネタ集めに過ぎない。
新入社員の頃から両方読めと言われてきたが、現場だと本当に役に立たない。
一般的なシステム開発をするに当たって、現行のシステムの流行だとかどこどこが買収してシェアトップだとか知っててもリソースの無駄だから。
現行システムのマニュアル＝お客様の業務を知る為の資料＞読みやすい資料を作る為の技術書＞オライリー＞＞＞(超えられない壁)＞＞＞＞日経新聞、日経コンピュータ
まぁ幹部社員から話を振られて「書いてましたね、今朝の日経に(今月の日経コンピュータに)」と言ってドヤ顔したい人とか、
