  |
はてなキーワード: SiERとは
これまでいくつもの帳票ツールがExcelに戦いを挑んでは破れてきた。
なぜことごとくExcelに敗れてきたのか？
簡単に言うと、オフィス用のPCにはすでにExcelがインストールされているからだ。
Excelの最大の利点は、発注元だろうが下請けだろうが、ほとんどのオフィス用PCにインストールされていて、だれでも使えるということにある。
わざわざ書類を作って、上役を説得して、申請を通して、購入するといった面倒事が全く必要ない。
なので、企業やら役所やらのデータのやりとりに頻繁に利用される。
また第二、第三の帳票ツールが出てきては、
Excelの前に屍の山を築くことになる。
forguncyは企業内のExcel方眼紙の置き換えには向いてるかもしれないけど、
日本の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年だよ！
俺はSIerにいて、あーがんばってるなーって思ってた。
その矢先 その会社の社長が、技術は買ってくればいい公言してたのを聞いた。
何十億もかけてシステム開発するって豪語してた＝技術者なんて雇う必要性はない。＝俺の会社にはお前らなんか要らない。
って喧嘩売られたことは、もう１５年ぐらい前で、今ではその会社、自社で大量の技術者抱えているけど
忘れられない。なんで、喧嘩売ってくるんだろうって思った。悔しかった。
確かに、レベル高くないけどさ。
2008年から201X年まで携わりました。若干のフェイクを入れてます。
・売上：10億～15億
積み上げるとどう考えても会社として真っ赤なはず。
＜やったこと＞
・取引先にプロジェクト開始時に着手金の支払を依頼
→ もちろん「着手金」は難しい会社もあるのでそこは色々と
・プロジェクト毎の採算性を厳しくチェック
→ カラ残業が発覚＆激減し、採算が向上した
・地方拠点の閉鎖 → 地方の低採算案件から撤退。もともと地方拠点なんて不要な規模だし
・下請先の開拓 → 割安な下請けを探すことで、固定費の変動費化を進める
・給与体系の変更
（たぶんコメントでは「どうせ仕事量が多いんだろ」と批判されると思いますが、否定はしません。
上限付き残業代とどちらが良いのか従業員と話し合った上で、こちらを選択しました。
もともとの給与水準が高かったので、彼らも「現状のままはヤバい。でも転職は面倒なので仕方ない」という認識だと思います）
→ うちもTKCのデータを出して、他社と比べていかに採算が悪いか、給与が高いかを説明しました
＜やろうとしたこと＞
・役員報酬のカット → 親族の名ばかり役員がゴネたため実施せず
・自社ビルの売却 → 市場感最悪。証券化も考えたけど、手間暇考えても割が悪いため見送り
＜んで、現在＞
拠点は1箇所、売上と社員数は半分になったけど、利益率はリーマンショック前の10倍まで改善（前が悪すぎた…）。
自分の手が離れた後も借金を返し続けて、ついに昨年度に債務超過も解消したみたい。
のどもと過ぎれば何とやらで、またやりかしそうな気がする…。
＜追記＞
・悪質なカラ残業を除いて指名解雇はしてません。でも地方拠点閉鎖＝実質解雇とは思われてるだろうなぁ。
こういう記事が上がって
それへの反応
記事の最初のカッコの省略だけど、世界的に評価されて広く使われてるようなプロジェクトのコードを見ると、案外{}が省略されていたりしてそんなことは気にしてない。(たとえばlinux, apache, postgresql, mysql, chromium, netbeeans, eclipse, llvm, jruby, android)
で「こんなコードを書くヤツは夜道に気をつけろ」「八つ裂き」みたいな大げさな反応してるのって、どういうコードを書いてるかよく分からないような人たち。
自転車置き場の議論的な、素人でも分かりやすいポイントだからこのツッコミって人気あるのかね。
―――――↓見てないかもしれないけどブクマとかへの返信を追加―――――
2chあたりでコーディングスタイルの議論になったときは、俺様基準じゃなくて実際に成果を出してる人たちが採用してるコーディングスタイルを基準にしようぜってことで、誰もが認める成果を出しててソースを見れるオープンソースのコードを引き合いに出すことが多いんだけど、そうするとよくある反論が二つある。
みたいなの。
さすがにはてなやツイッターじゃ、前者のような「お前は20年前からタイムスリップしてきたのか」みたいな認識の人はいないみたいだけど後者のような人は何人もいるね。
高度なコードを書いてる人とITドカタのコーディングルールは違うってなんなんだろうね。
「高度なコードを書いてる人は低レベルなケアレスミスなんてしない、だからカッコを省略しても平気なんだ、レベルの低い連中はケアレスミスをするからカッコが必要なんだ」って認識なのかね。
まあたしかに「viは一晩で書かれた」みたいにハッカーが複雑なコードを一気に書きあげてバグがなかったみたいな伝説ってあるけど、素人じゃないんだからそういうハッカーのイメージで高度な人たちをとらえるのはやめよう。
集中力が高度でケアレスミスをしないとか、今どきのソフト開発の「高度」はそういう意味じゃありません。
高度なソフトを開発している人たちは、おおむね読みやすさや保守性にセンシティブです。そのらのSIerなんかに比べたらはるかに。
で、そういう人たちが、カッコを書くか書かないかなんてどうでもいいって認識だからカッコを省くコードが書かれてるんです。
昔ハンガリアン記法がコードの質を高めると信じられてたときとか、if (100 == n) のように比較で定数を左にもってくるのが流行ったときも、そういう流儀の人たちは自分らは安全側に倒してるから正義だって信じて主張を全然曲げなかったですね。
慰安婦問題はIT土方の偽装請負多重派遣問題にたとえるとわかりやすい。
問題:
IT土方本人が納得していないどころか説明さえうけていない詐欺同然の契約内容・労働条件で
元請けSIerに売り飛ばされ、何の付加価値も提供していない自称派遣業者が何重にも中間搾取していた場合、
さあ、一番悪いのは誰なんですか？考えてみてください。
「吉田証言は捏造だった！日本軍が直接慰安婦の強制連行に関与した証拠なんてないんだから何の責任もない！」
という考え方は適切なのでしょうか？
なんか、変に話が大きくなってますが、元SIerとしては単なるあるある系のクソ仕事話の一つって感じの、Excelスクショエビデンスについて話をしておこうと思います。
最初に結論を言っておくと、
「意味があるのは分かっているが、そもそも責任回避のための資料作りなんて出来るだけやりたくないし、そんなのが大量に必要であること自体が気に入らねえ！」
ってことです。
参考:
Excelスクショ問題について周りの方へのお願いと、今職人となっている方への励ましの言葉（元職人より） | 羽根帽子の太公望
まあ、意味があるのは分かる。やってた事もある。
とは言え、何の意味かというと発注元の企業とゴタゴタが起こった時の責任回避の資料作りという意味で。
後になって問題が起きた時に原因究明の資料になるとかいう話もありましたが、それはかなり怪しい。
適切な粒度で切られたテストケースと更新がある度に正確にメンテされ続けるドキュメント管理力が必要ですが、そんな信用度の高い文書あんまり見たことない。
結局、動いてるシステムとソースコード見るしかない。その時の参考資料になるドキュメントは必要だと思いますが、それがExcelスクリーンショットかというと……。
どうしても再現環境を用意できず、机上で推論するしかない場合は役に立つかもしれませんが、そもそもそんな重要なシステムで何でそんなところケチってるのか意味が分かりません。
後、ソースコード読めない上流のSEがバグ原因を推定してお客様に説明する、という不毛な作業をする時にも役に立ちますね。
やはり、責任回避のための言い訳資料を作る、という名目が強いように思えます。
大半の人にとって、そもそもこういう資料作成自体が不毛でやりたくないと思います。
テスト工程とか余計なこと言わずに、訴えられて損害賠償請求されたくねーからやってんだ！と新人に説明すべきだと思う。
(こういう事ネットには色々書いてあるんだけど、会社は教えてくれないんよね、何故か)
大体、なんでこんな事やってるかっていうと発注元の受け入れ作業をベンダーが肩代わりしてるからです。
自分が注文したものがちゃんと動いてるのかの確認までベンダーに投げるので、「やった」「やらない」を過剰に説明する資料が必要になる。
専門知識を持った人材を抱えておくことをコストだと考えてるから、もっと無駄な事が世の中に発生してしまう。
そして、これのせいで付随して更なる問題が発生する。
顧客提出する資料に専門用語を含めた説明文を書くと、言葉が理解できない、という理由でリテイクをくらう場合があります。
説明資料じゃなくて、開発者や運用担当者が参照するための技術資料なのに、技術的に正しい、とかはどうでも良くて顧客が理解できる言葉で書け、ってことですね。
向こうのレベル感を探り探りしつつ文言を選んで説明分を付与する不毛な仕事が求められるのです。
これが顧客に対する誠意だと言うんですからお笑い種なんですが、まあ向こうがそれに金払う、って言ってんだから作るんでしょう。
既に十分不毛なんですが、これに輪をかけるのが体裁というやつです。
スクリーンショットの位置や文頭が微妙にズレてたりすると怒られるやつです。
それが、そんなに重要なのかどうかについては、最後まで分かりませんでした。
項目幅を調整して印刷可能なページに適切に収めるのに消費される時間が辛い。
後、カーソルをA1に戻しとけ、とかも全く意味が分からないし、納品前に数時間かけて印刷して判子を押して回るのも意味が分からない。
こんな単純作業を人間が手動でやっててミスらん訳が無いだろうに。
気を付ける、とか真剣にやる、とかで解消できると思ってるなら、お花畑過ぎるだろと言わざるを得ない。
しかも、自動化するために諸々やってると、最悪サボってると見做されるし、ひどい場合は、作業用PCに使えるソフトが限定されてて、スクショ取るツールさえ入れられない事があるらしい。
そこまで行かなくても、社内プロキシの穴を付いて開発環境を落としてきたりして、最悪セキュリティ担当の人に怒られる場合がありますね。
なんでこんな面倒なことしなきゃならんのだとソウルジェムがガンガン濁っていきます。
(メモ帳でもありゃいいだろ、という話もあるかもしれませんが、俺のような凡人はそれはそれでソウルジェムが濁ります)
まあ、それを回避して何とか自動化して省力化できるようになったら、他の人の作業時間と同じぐらいの見積り出して、本当にサボるんですけどね。
ダラダラと色々書きましたが、まとめるとこういう事です。
企業活動として意味があるのは分かるが、その根本的な目的は誰かが手抜きしたコストを肩代わりしてるだけに思える。
ただ資料を作るだけじゃなくてすげー細かい注意が必要になるのだが、そこに合理的な意味があるのか分からない。
作業自体がめっちゃ面倒くさいのだがその面倒くささを解消する方法に何故か制限がかけられている。
そして、世の中のプログラマーがどうであるかは知らんけど、俺はそんな作業が大嫌いだ。
むしろ、Excelにスクリーンショットを取って張るなんてのはどうにでもなるんだけど、それに付随している業務慣習の大半が意味分からなくてクソ喰らえである。
というわけで、意味があるとかそういう主張はどうでも良くて、そんな仕事やりたくない。
まあ、それしか金を得る方法が無いんだったら、嫌々でもやりますが……。
しかし、そもそもの話、実際冒頭で挙げた参考エントリの人も心病んでるし、他にも病院送りにされてる例が多数あるわけで、
仮にこれが本当に必要だと認めるにしても、人間の心をすり潰してまでやらなきゃならないような工程が、
当然のものだと受け入れられてる業界は最悪じゃねえのかと思う。
従業員の精神を壊してまでやらなきゃいけないような事なのか、これは。
必要とか必要でないとか以前に、こういう事やると人間の心が病むんだよ。そんなものが仕事なんだったら、そりゃ人間働かなくなるだろうよ。
そんなすぐに世の中変えようもないしどうしても作らなきゃいけないんだ、という場合は、せめて自動化に対する障壁を外して欲しい。
見た目の凝り具合とかは本当に必要な最小限度の体裁にして欲しい。
