  |
はてなキーワード: 人月とは
俺はまさに弱小ベンチャーで働く「何でも屋」のエンジニアだが、普段感じていたモヤッとした気持ちをこの記事はドンピシャ突いている。
【スタートアップベンチャーはスーパーエンジニアを求めるけどエンジニア界隈と起業家界隈で想像しているスーパーエンジニアの定義が違う件】
http://htanaka0828.hateblo.jp/entry/2017/07/11/220141
IT系のベンチャー経営者またはこれから起業しようとしているやつはこの記事を1000000回読めと言いたい。
愚痴りたいことは山ほどあるが、特に言いたいことは次のことだ。
俺はサーバ構築もする、サーバ側アプリも作る、クライアント側も作る、簡単なものならデザインも作る。
でもそれは俺がたまたまそうなだけであって、大抵のエンジニアはそうじゃないわけ。
それを理解せず、フリーランスに開発を依頼しては「この人はAndroid開発しか出来ないから駄目だね〜」とか、何を言っているんだと。
その人が駄目なんじゃなくて、俺がすごいの！！！！
いや、ごめん、うそ。
本当は俺はそんなにすごくない。
何かに特化している人の方が、その分野においては優れていることが多い。
どちらがすごいとかじゃなくて、スキルセットが活きるシーンが違うだけ。
ただ、傍から見たらiOSだけの人は「駄目」に見えるらしいね。
専門外の人はそう思っていても当たり前だが、でもITベンチャーの経営者はプロ側の人間だからな？
なんでも屋じゃない人の方が多いんだから、チームを組んで開発しないといけないわけで、そこら辺のヒト・モノ・カネを何とかするのが経営者の役目だからな？
SIの人月の話に近い感じもするが、ここで言いたいのはそういうことじゃない。
言いたいことは「エンジニアは1人でなんでも出来ること前提」に話を進めるな、ということだ。
そうだな、俺がこれから起業するやつの脳内をエスパーしてやる。
夢追い人の脳内：
「画期的なアプリをリリースするためにエンジニアを1人雇おう！まずはスモールスタート！でもスケジュールによっては2〜3人必要だな！」
どうだ？大体こんな感じだろう？
アプリは1人では作れない。
（正確には1人でも作れるが、それは小規模なアプリだ。きっと夢追い人の妄想の15%くらいしか満たせないだろう。）
iOS開発者、Android開発者、サーバ側アプリ開発者、インフラ担当、最低でもこれだけ必要だ。
1人で何役か出来たとしても、全て出来る人は少ない。
それでも1人目エンジニアは専門外の技術も勉強しながら頑張るだろう。
するとどうなるか？
進捗が思うように進まず、リリース延期、またはひどい品質のアプリが誕生するのだ。
一般的な開発案件でもそうだが、素人が言う「ちょっとしたアプリ」はちょっとしていない。
夢追い人の発言：
・ブラウザでアクセスできる管理系機能（言っていないけどry）
そもそも開発者でもない者がなぜ「ちょっとしているかどうか」を判断できると思っているのか。本当に不思議だ。
しかし、もし理解していない場合、それはリリースの延期、またはリリースできずにコケることになるだろう。
そもそも1人で全てできるわけではないということは前述の通りだ。
つまり開発には役割分担があり、全ての役割が網羅されるように人員を配置しなければならない。
そのために2〜3人必要、ということならば、正しい考え方だろう。
建たないだろう。
設計する人、建材を用意する人、監督する人、その他諸々がチームとして必要だ。
じゃあチームを5セットに増員したら、工期は1/5になるか？
ならないだろう。
作りたいものを早く作りたいのであれば、そのために適切な人員配置が必要なのであって、大工だけ雇っても完成しないし、人を増やせば良いということではないのだ。
すでに出ているけど貴方のところの理解のなさで一番被害を被っているのは
まぁこんなんは発註側の企業の方は関係ない業界自体の問題だからあなたとは関係ないが
ただ
>>・要求する機能に対して短い納期を設定しているが、「なんとかします」って言ってくれてありがとう。無理をねじ込んでごめん。<<
この「なんとかします」で困るのはそんな無責任な言葉をホイホイ言えるバカじゃないのは確かだし
>>今年度の保守契約を結ぶためにギリギリ値下げしてくれた某社の営業担当には本当に頭が下がる。<<
これについても実際に下がってるのはほぼ保守担当の給料だよ。まぁどうせ非正規にでも投げているんだろうが。
あなたが優しいのはわかったが割を食うのはあなたが接している調子のいい連中じゃないのは確か。
自分より優れたるものを自分の周りに置きし者ここに眠る。カーネギー
できる人ばかり辞めていく会社が研修費用を出すようになったら、さらに退職が加速したというお話「人事に聞かせたい」 - Togetterまとめ
「従業員にトレーニングをして、よそへ行ってしまったらどうするのか」という疑問に対するStanger氏の答えは、「従業員にトレーニングをしないで、彼らが会社にとどまってしまったらどうするのか」ということになる。
従業員の才能を爆発させるには「会社に人を長く留める」戦略を捨てる必要がある
ttps://b.hatena.ne.jp/entry/s/gigazine.net/news/20171005-superboss/
「弱いつながり」理論でいうと、SNSでつながる友だちは、それこそFacebookの友だちが3,000人規模で、国内のスタートアップの経営者なら、たいていの人に直接または1hopでつながることができる。
ttps://s.nikkei.com/2vJsvYx
優れたマネージャーは自分より高い給与をもらう可能性のあるポテンシャルの高い部下を喜んで雇う
ttp://b.hatena.ne.jp/entry/www.masafumiotsuka.com/2015/11/the_peter_principle.html
人材は会社の資産として残らないが仕組みは会社の資産として永遠に残る
ttps://www.amazon.co.jp/dp/B010JM64M6/
ttps://employment.en-japan.com/engineerhub/entry/2019/11/07/103000
ttps://www.slideshare.net/yattom/ss-79372905
ttps://tinyurl.com/y8tkhuhz
ttps://bit.ly/2MylBjs
"競争優位につながるような戦略的なソフトを開発しようとするなら内製しかない。"
ttps://www.amazon.co.jp/dp/4822273784
ttps://medium.com/@kuranuki/aac6062adfb2
どの部分を汎用的につくり、どの部分をやっつけで作るか、そして、どの部分をパフォーマンス優先でつくり、どの部分を可読性優先でつくるか
（中略）
ソフトウェア開発とは、経営的意思決定の集積なのだから、経営的意思決定を外部の会社に委託するというのは、「経営を外部の会社にやってもらうようなもの」だからだ。
もっと言うなら、自分の会社の今後のビジネス的ポジションを、他社に決めてもらうようなものだからだ。
外注を出された会社は、そのソフトウェアが未来に実現するであろうビジネス的価値を犠牲にして、できるだけ少ないコストで作ろうとする。
ttp://fromdusktildawn.hatenadiary.jp/entry/20061003/1159869683
ttps://bit.ly/2JzCggZ
「ソフトウェア業界（特に受託開発業界）は、基本的に正直者が馬鹿を見る世界である。顧客が、保守性というソフトウェアの最も重要な品質を正しく評価できないという、情報の非対称性が存在するからだ」/分かるなぁ
「モダンな開発環境×技術顧問×内製化」Sansan×日経電子版 アプリ開発の最前線を語る夜
ボタンを1つ追加するだけで2週間。内製化によるスピードアップは必須だった。
「アプリ内にボタンを1つ追加するだけで、2週間の開発期間と、数十万円のコストが発生していました。それでは急な仕様変更に対応できないし、技術ノウハウも貯まらない。」
ネットサービスの肝は、開発にかける額の多寡というよりは、内製化するかどうかにあると思っています。
ローンチした後、そこからの追加・改善はものすごいスピードでやらなくちゃいけない。これは、内製体制でないと絶対に不可能です。
2017年1月、ネット証券大手のマネックス証券は証券基幹システムを刷新した。
お客様へ提供するサービスの開発スピード向上と、ノウハウの社内蓄積、開発コストの適正化を目的に、
（中略）
サービスの改善や新サービスの開発時に、ASPサービスの提供会社との会議に費やしていた時間を削減し開発のスピードアップを図ることで、競合他社への競争力を強化したいと考えました。
ttp://b.hatena.ne.jp/entry/s/quality-start.in/it-strategy/467
ttps://twitter.com/kanayang2009/status/129677947572465666
ttps://amzn.to/2ncDXrO
だから育てるんだ。
ABテスト デザイン OR ボタン OR 文言 - Twitter検索
外注でもA/Bテストでユーザの反応を計測してトライ・アンド・エラーでシステム開発ってできるもんなんだろうか。
できるとして、それって内製化した方がずっとクオリティ高くなるんじゃないの？
ttps://twitter.com/fromdusktildawn/status/874796380522336256
「外部委託すると細かい継続的な機能の改善が遅くなるので、自社採用でかなり優秀な人材をケチらずに採るべきだね。なかなか見つからなくても妥協せずに」ホリエモン
ttps://bit.ly/2QWMsoJ
外注はPDCAを回せないという致命的な欠点がある。ITスタートアップの感覚だと外注と内製には天と地ほどの差がある
ttps://bit.ly/2J5UCWQ
銀の弾丸ではないがリーンな開発は競争力の源泉。そのためにはPMFをコントロールできる開発チームが必須でそれは内製でしか達成困難。
ttps://bit.ly/2vkDd8E
正解に当たるまで回し続ける！3ヶ月で200回のA/Bテストから得た「意外な結果」とは
弊社のイベント一覧のページなのですが、単なるテキストの羅列のパターンと、リッチなレイアウトのものでテストすると、いつも必ずテキストの方が勝ちます。
海外テック情報局：eBayではダサいデザインのほうがコンバージョン率が高かった｜gihyo.jp … 技術評論社
デザイナと口論したいのではなく，見たいのは数字とお客さんの利用例。
そして何がうまくいっているのか突き止めたい。
選択の科学 ２４種類のジャムを売り場に並べたときと、６種類のジャムを売り場に並べたときでは、前者は、後者の売り上げの１０分の1しかなかったのです。
ttps://amzn.to/2I2V1O4
エンジニアでないファウンダーは最大一人まででお願いします | On Off and Beyond
理由１：変更につぐ変更を重ねられるようにする
最近 lean startup なる考え方がはやってますが、これはどういうことかというと、
東大合格者ランキングは正しいのか？――常に分母は何かを考えよ
何事にも閾値はある。そこに至らなければ、意味がないという数字だ。
「頭のいい人が成功しない理由」という本に、閾値の話があった。
だれもが中途半端にやめてしまう。それでは足りない。閾値を越えない。
ttps://ameblo.jp/chimu841/entry-10036171360.html
ttps://amzn.to/2Odv25b
①内製
②外注
フラクタルなレモン市場問題｜建築不動産クラスタ交流会の件その１
ttp://realtor-readyabooks.hatenablog.com/entry/20100515/1273919457
ttp://ledsun.hatenablog.com/entry/2016/02/28/014851
ttps://ja.wikipedia.org/wiki/情報の非対称性
ttps://ja.wikipedia.org/wiki/逆選抜
ttps://ja.wikipedia.org/wiki/取引コスト
「探索コスト」
時給制（時間を売る）が生産効率低いのって自明だよなぁ・・相当ボランティア精神ないと時給制で効率よくやろうって気持ちにならないよね
でも拘束時間で金額を決めてしまっては効率化を目指さなくなるんじゃないか
ttp://b.hatena.ne.jp/entry/b.hatena.ne.jp/entry/194800390/comment/redhornet96
ttp://b.hatena.ne.jp/entry/twitter.com/etomiho/status/872820182883762176
ttp://b.hatena.ne.jp/entry/twitter.com/etomiho/status/872822997106565120
ttp://getlife.hateblo.jp/entry/2013/09/10/015011
見積もりが人日で工数を計算していると、実際にはそれよりも短期間で実装できても見積もり日数になるまで納品を待ったりすることはある。
納期よりもかなり早い段階で実際には完成しているにも関わらず、
エージェントが利益相反行動をしていないかどうか監視するためのコスト。
自身の行動がプリンシバルの利益追求にかなっていることを証明するために
ttps://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1212240292
ttps://twitter.com/search?q=rails%E3%80%80%E9%A1%A7%E5%95%8F
「顧問プログラマ」再考 - Rails 雑感 - Ruby on Rails with OIAX
ttps://www.oiax.jp/rails/zakkan/rethinking_of_adviser_programmer.html
ITエンジニア採用に欠かせない原則とは (1/5)：IT人材ラボ
ttp://b.hatena.ne.jp/entry/s/itjinzai-lab.jp/article/detail/856
ttps://www.slideshare.net/fukumura1/fukuokarubykaigi-medpeer-ver1
【256人がリモートワークで回る仕組みを考える】後編
ttps://www.remotework-labo.jp/2015/10/interview_10/
・大学での専攻は情報系ではない。パソコンは趣味でいじってきた。
1. SIerへの思い
・毎回、見積もりの度に「何人月ですか？」と聞くが、聞いてる私だって無意味な質問だと思ってるよ。
すまん、私の説明が悪すぎるのか、こっちの決裁権者は上から下まで人月でしか理解できないんだよ。
妥当かどうかはわからんけど、例えばソースの行数単価とか、プログラムの容量単価とかで説明したこともある。「訳がわからないから、やっぱり人月で表現してくれ」と言われたがな。
・要求する機能に対して短い納期を設定しているが、「なんとかします」って言ってくれてありがとう。無理をねじ込んでごめん。
私にはお金関係を決裁する権限もなければ給料も安いから、ありがとう、ごめんと言うしかできない。
・毎年「保守費、下がりませんか？」とお願いしているが、これも申し訳ないと思ってる。今年度の保守契約を結ぶためにギリギリ値下げしてくれた某社の営業担当には本当に頭が下がる。
保守費の計算根拠は毎年説明している。あれやこれやを努力してもらって、実質的には安くなっていることも説明した。しかし、今年はダメだった。実際に払う金額を下げろと言われた。
・必ずしも全員が、というわけではないが発注側の現場担当者の中には、SIerに対する無理なお願いを悔やんでいる者がいることは知ってほしい。
2. 偉い人への思い
・日頃から従業員の稼働率という基準で考えているようだから、人月計算がわかりやすいのかもしれないけど、世の中にはそういうのでは測れない世界がある。
うちでは誰が作っても同じ品質のものができるように設備を設計しているから「従業員何人で、何日でなんぼ稼げる」ってイメージが染み付いてるだろうけど、システムの開発はそんなもんじゃない。
・システム開発における工数単価の比較は、多くの場合バカにしか見えないからやめてほしい。システムの規模の大小、メーカの違いで単価は異なるに決まってるじゃないか。
更には全く別の業種と比較して単価が高い安いとか言われても困る。電気工事業者にプログラミングさせるのか？ SIerに配線工事させるのか？
・システムの機能追加や保守ができるのは、そのメーカだけだよ。
そりゃあ確かにソースやシステム設計書を受け取っているから他社にもできる「かも」しれない。でも契約書に書いてあったでしょう、「成果物を勝手に他のメーカに流さない」って。
それに、機能追加や保守をしてもらうには、そのシステムの全てを理解してもらう必要があるんだよ。
他人が書いたソースを何ヶ月もかけて読み解いて理解して、見積もりしても発注してもらえるかはわからない、安い方にお願いする……そんな案件、誰も手を挙げないよ。
実際そういうやり口で、うちの仕事を受けてくれなくなった業者があったと聞くぞ。又それを繰り返すのか？
・事前に説明して了解を得たから稟議をあげているのだが、説明済みの内容に納得が行かないからという理由で稟議を引き戻させるのはどういう意味があるの？
納得してもらえなかったのは主に金銭面。そこは何度も説明した。（意味のない）人月計算もしたし、工数単価も出した。スライド3枚で表とグラフを見せて「わかった、それでいい」と言った内容を「納得できないからもう一度考えなおせ」とか、こっちが納得できない。
・納期は「開発、検証、納入設置、動作確認」に必要な日数だよ。短くするにも限度があるし、言われたとおりのスピードでやってもらうようにSIerに無理をねじ込んだんだから、決裁もそれに合わせてはやくほしい。
・設備投資の妥当性が必要なのはわかるが、上記の通り自社にはない考え方で動いている世界もある。そこをご理解いただき、「それなら何を出せば納得できるか」を教えてほしい。
例えば最初から予算を示してくれれば、それに合わせて何ができるかを考えられる。作業者の運用面や端末のコスト削減などの工夫はしているのだから、そこを評価してほしい。
システムの開発、改造、保守の話が出てくるたびに私は悩んでいる。
評価もされない、新しい技術も身につかない。ユーザからは「使いにくい」と文句を言われて、上からは「よく考えたのか」と怒られる。誰がそんな仕事に喜びを感じる？
これよくわからないので教えて欲しい。
具体的には１月遅れるとどれくらいの損害になるのかと言う事と総額の費用が知りたい。
そしてそれに関わる人たちのインセンティブが知りたい。
自分なりに試算してみた。
三菱を参考にする。
プロジェクトに参加した技術者は、銀行とシステム関連会社の要員、IT企業の社員を含めピーク時には6000人に達する。投資額は2500億円、開発期間は3年弱、総工数は11万人月に及んだ
規模に誤差があるとしてみずほも3000億現状かかってると言う事だから、だいたい参考にできると思う。
調べた情報によるとみずほの首脳は派閥争いを繰り返し、現状できているシステムはゴミという事なので
3000億はパア。そして最初から作り直しを開始するまで毎月定額の費用が発生することになるとしよう。
したがって総額コストCは下記の式で表される。
C＝3000億＋Xt＋Y
誰かが責任とって最初から作り直そうぜというまでだいたい大まかにXのコストが毎月発生する。
期間t（月）は派閥争いが終了、もしくは政府が介入してシステムをスクラッチから作り直すまでの期間。
Xの計算だが三菱を参考にすると11万月/３６ヶ月＝３０００人 となり
月あたりだいたい３０００人の労働者が駆り出されることになる。
みずほ案件はやばいという認識が広がっており、技術者っぽい人しか集まらないということなので
みずほの支払う一人当たりの費用を４０万円とすると１２億になる。
C＝３０００億＋Xt＋３０００億＝６０００億＋１２億t
ここでtを月から年のTに直すと
C＝６０００億＋１４４億T
年間あたり１４４億円の損失が発生することになる。
１４４億円は一般感覚でいうととんでもなく高額だがみずほの２０１６年の純利益は６０００億なので
実は大した損失ではなく、このまま数十年にわたって損失出し続けても問題はなく。
この認識で合ってる？
SIerのヤバい現場は「何をしているのか理解してない」というレベルで分かってない気がします。
この方々に
「このシステムはどんなプログラミング言語で作られているの？」
「この値はどうやって算出しているの？」
と聞くと
「わからない」「担当者に聞いてくれ」「ユーザーに聞いてくれ」
と言います。
確かにプログラミング技術やクライアントの業務に詳しくない人なのかもしれません。
でもシステムってプログラミングって自分で理解していないと作れないものなんですよ。
「プログラミングは俺の仕事じゃない」「ユーザーの業務はユーザが一番詳しい」
そうかもしれませんが、システムを作るあなた方が理解してないものはコントロールもチェックもできないんですよ。当り前じゃないですか。
確認もテストも協力会社の方にお願いするんですか？では協力会社に仕様を伝えるのは誰ですか？
ユーザーからの質問を「担当者に確認します」と言って自分からは答えられない状況が続いているのにおかしいとは思いませんか？
プログラミングも仕様も分からない、呼ぶ協力会社は単金だけを見て決めるんですか？優秀かどうかはどうやって判断するんですか？
スケジュール管理は数字だけを見てできると思っていませんか？その根拠はなんですか？
Git知らないDocker知らないm9(^Д^)ﾌﾟｷﾞｬｰと
でもそんなことは些末なことで、導入してすぐ解決みたいな話ではないように思えます。
それに毎日遅くまで働いて、休日は妻子のために家族サービスとなれば自己研鑽の時間なんてなかなか取れないでしょう。
でも作ろうとしてるものが何なのか理解する時間は会社の中でできると思うんです。
忙しいのは理解しています。稼働調整、スケジュール調整も大事な仕事です。
お客さんと雑談で
「ちなみに現場の人ってこのシステムどうやって使ってるんですかねー？」
とか
プログラミングしている方に
「この処理はJavaScriptで書くのが良いのはどうして？」
とかなんでも良いんです。
「そんなことをしても仕事が増えるだけで、得にはならない」
という意見もわかります。でも自分が理解しないといつまで経ってもコントロールできる立場にはなりませんよ。
ラダー効果が云々という話も聞き飽きたかと思いますが、もうちょっと視野が広がると糞な職場がほんの少し変わる気がしませんか？
というわけでお父さんたちお仕事頑張って！
私は、プログラマとしては小さな会社でしかやってませんので、かなりの物は一から作っています。
まあ、何人もの人間がプログラマとして作っているプロジェクトも噛む程度は見てきましたが、プログラミングという作業は、ある一定の人数を越えると、明らかに品質が落ちます。
そこそこの人数でやっている物を横でで見ていて、「あれ、私一人でやった方が早くいいもんが作れるよなぁ」と思った事がしばしばあります。
＃てか、そうなってしまったこともあります。ほとんどの物で、一部のドライバとかをのぞき全部作り直し。
多分、世のプログラマはほとんどそう感じているんだと思うんですが、なぜ、未だ労働集約的なんでしょう？
『人月の神話 - Wikipedia』って本はもう30年以上も前にかかれたのですが、未だに日本では「神話」が生きてる。
http://anond.hatelabo.jp/20161222124531
やってみたぜ。
諸々引かれて手取りは16万円
家は、郊外に敷地1000平米、住居部分は250平米の5LDKでプール付き
車で通勤30分で、毎日10時に出て19時には帰ってくる感じ。
帰って子供の面倒とか家事をやって、22時から26時くらいまでプログラム書いたり
アラフォーで、フロントからバックエンド、iOSアプリ、Androidアプリまで一通りやってる感じ
マネージメントはやらないって言ってるからこれ以上給料は上がらないかなぁ。
# 以下24日に追記
確かに貯金はしてないね。リアルに月末に貯金額0になる生活だわ。
ただ、医療費用はほとんど無料、学費は日本で言う小中高は無料、幼稚園は二人で5千円位
車とかまとまった金が必要な時は、toptalって言うまぁクラウドワークスみたいなサービス使って
副業で金を調達してるわ。その時は人月6千ドルで請ける上に、毎月末に請求、支払サイト10日みたいな感じだから
一ヶ月半以内に６0万円くらいは調達できる。実質一日2,3時間しか働かないけどまぁコード書くのは速いから
今まで文句言われたこと無い。
ただガンガン働いてガンガン稼ぐスタイルは嫌いだから、余りやらないけどね。
そろそろ４０で失業したら人生詰むけど、英語と現地語と日本語喋れて、プログラミングも大体最近の流行追ってるし、
githubにはスターが1000くらい付いたライブラリ公開してるし、まぁこれで食いっぱぐれる事は無いっしょ。
家の掃除は、オープンな感じで家具をぐちゃぐちゃ置いていないから楽だなぁ。
庭の落ち葉は超大変だった。
まぁシリコンバレーとか憧れるけど、プログラマーならこういう人生もありまっせ！
１２、３年前まで東京で働いてたけど、最近は大分改善されたことを祈るわ。まじであの始発の電車みて
一歩踏み出せば楽になれるかなぁってぼんやり思ってた時期は辛かった。
あとまぁ美人は多いね。うちの会社はオタクばっかりだから縁はないけどな。
プログラマーは多分外国で美女と知り合うとかそういう期待は諦めたほうが良い
この会社に来てから2年と8ヶ月の間、一つのデスマーチプロジェクトに関わってきた。
プロジェクト全体がどれくらいなのかわかんないけど多分1万人月は超えてると思う。それでもこのプロジェクトはシステム全体ではないのだということを考えると全貌はどういうものなのか。ケーキ工場で、全体が見えない場所で特定の工程を長く担当していると自分とその周辺の工程だけがケーキを作るための全てだと思いこんでしまうというような話があるが自分がそうならないようにいつも注意していた。他のところでは他の苦労をしている人たちがいっぱい居るのだ。
特に去年4月からはデスマーチが本格化した。そもそもちゃんと設計できていないとかそんな話もあったし、いろんなところの単体でのテストができていないまま結合試験に突入したりしたせいで混乱が拡大した。GWも土日だけ休む、夏は(土日に加えて)1日、年末年始は4日間休み、職場に居る時間は9:00〜23:00、というような生活が毎日続いた。
まあいろいろ大変だったけど納入前の最後のテストが今週終わり、一方で納入後のテストは年明けから、ということだ。とにかく終わったんだ。
だが油断してはいけない。今回乗り切った奴はこのプロジェクトの納入イベント四天王の中で最弱。次なる納入イベントが4ヶ月後に待ち構えているのだ。
今年の1月から4月は休日出勤多かったし終電がデフォルトになって、月の残業時間は100時間を平気で超えてて、その頃はいろいろ健康管理がどうとか会社に言われてたんだけど、7月頃から体調がおかしくなって朝の出社を遅くせざるを得なくなった(というか憂鬱で出社できなくなってた)。それでも結構無理してたんだけど、数字上の残業時間が減ったので全く何も言われなくなった。どっちかというと100時間超えてたときのほうが元気だったのにおかしいよなあ。
エンジニアから見たSIerがクソな理由 - 負け犬プログラマーの歩み
↑の記事を読んでいて、SIerってそんなにヤバいのかなぁと思い、衝動的に書き連ねている。
SIerと出版社中心で就活していて、それぞれ1社ずつから内定をもらい、出版社のほうを選んだ。
SIerはSE職で内定をもらっていて、出版社では入社以来編集者をしている。
SIerの方（仮にA社とする）は社員数4ケタの元請けSIerで、毎年新卒が100人ほど入るらしい。
一方、弊社はA社の数十分の1の社員しかいない専門出版社で、新卒が入らない年すらある。
はてなにいるとSIerの話がよく出るので、就職した後もA社を気にかけることがあるのだが、果たして自分がA社に入っていたら、どんな人生が待っていただろうか。
◎給料
大手SIerの給与ランキング。平均年収は800万円前後か : IT速報
ここのランキングに載ってるのが正しければ、あまり変わらなさそう。
ちなみに出版社と言えば三大（小集講）の給料がバカ高いことで有名だが、弊社含むそれ以外の中小出版社は大したことないことが多い。
出版社は、一般に刊行周期が短いほど激務になる傾向がある。週刊誌編集部はそれこそ過労死レベルの激務と聞くが、弊社のような書籍メインのところはそこまででもない。
所定労働時間はA社は7時間半、弊社は7時間なので、時給換算だと弊社のが若干有利かもしれない（出版社は実働7時間のところが多い）。
あと、A社だと夏休みを有休で取ることになってるらしいから、有休消化率は高くなったかも。
弊社は有休とは別に夏休み（＝ひと夏で消える有休）があるので、本来の有休までなかなか消化し切れない。
◎仕事内容
期間はA社のほうが長そう。さすがに2年目の今頃には現場にいるだろうが。
A社だと多少コーディングに携わって、その後は進捗管理とクライアント折衝が中心だろうか。
いきなりということは無いだろうが、やがて何十人以上のプロジェクト管理やることになりそう。多数の協力会社（はてな用語では下請け）の人と共に……。
出版社で現場に入って最初にやったのは、校正・校閲（本の誤字脱字・内容チェック）。
そこから先輩の指導で本を1冊担当し、編集プロダクション（編プロ）の人と共に本を完成させた。今は、何冊かを同時並行で制作しているところ。
編プロはうちの業界の場合ライター兼編集者が集まった会社で、編プロに書いてもらった原稿を自分ら出版社の人間がチェックする。
まとめると、↓に書いてあるのと近いが、編プロが筆者を兼ねている場合がままある。
http://anond.hatelabo.jp/20150212124233
SIerと違うっぽいのは、SIerは人月で仕事を投げているのに対し、出版社は1ページいくらで編プロに原稿料を払っていること。
なので、出版社の編集者が、編プロから出てきた原稿に何度ボツを出しても、出版社が払う原稿料は変わらない。
優秀な編プロならボツも少なく、彼らにとっても割がいい仕事となる。
一方、そうでない編プロだと「今回のボツで、先方の時給が最賃以下になったな」と同情することもしばしば。
でもボツ原稿を出版するわけにはいかないので、頑張ってもらうしかない。それを応援するのも仕事のひとつ。
あまりにひどい原稿が出てきて、かつ時間がない場合は、自分らで原稿に手を加えざるを得ない。たまに「自分は赤ペン先生かな？」と思う時がある。
裏を返すと、技術力（文章力や専門知識など）は日常的に磨かれるので、フリーのライター＆編集者として独立する元同業者は割と珍しくない。
◎やりがい
動くカネの量や成果物を使う人の多さは、A社のほうが大きいと思う。実際「大規模プロジェクトを動かすプロマネ志望！」と言いまくって内定をもらった。
自分のプログラミング能力は皆無に等しいが、技術力を活かすより多くの人に影響を及ぼせる仕事がしたい気持ちの方が強かったので、A社でもそれなりに楽しめるのかもしれない。
弊社は専門出版社なので、想定読者数がそもそも少なく、動くカネも少ない。ただ、読者にとっては確実にニーズがあって、人様の役に立っているという実感は味わいやすい。
専門の人らのブログとかで、自分らが携わった本を褒めてくれていると素直に嬉しい。
◎会社の将来性
A社はじめSIerは受注産業なので、仕事していれば食いっぱぐれることはないが、逆に言うと仕事し続けないと儲けられない。
一方、弊社はじめ出版社はメーカーの側面があり、成果物の著作権は自社にあるので、当たれば労なく稼ぐことができる。
（逆に言うと、どんなに頑張って商品を作っても、売れなければ儲からないということだが）
それなりに続いている専門出版社の場合、その道の人が必ず買ってくれる本というのがあって、そういうのが利益を下支えしている。
◎自分の将来性
A社のほうが業界的に転職が多そうだが、プログラミング能力がないまま転職できるのかという不安がありそう。
弊社はフリーになる道もあり得るが、原稿料商売では弊社にいるより稼げないのは目に見えている。
起業して編プロの社長になれば儲かるかもしれないが、社員をこき使うことによる良心の呵責で死にそう。
元請けSIerも出版社もプロマネがメインという点では共通しているし、磨けば他社でも通用する汎用的なスキルだと思うが……業界知識の壁があるか。
出版社に入って「自分らが権利を持ってるって強いなぁ」と実感しているので、将来独立するならば、自前のコンテンツでご飯が食べたいと思う次第。
今日SIerについての話題が目について、実情について書いてみたくなったので書いてみる。初めて増田に投稿するので少し緊張している。
自分は誰かというと、金融系ユーザー子会社に勤めているSEだ。いわゆる１次受け。社員は数千人おり、2chのユー子ランキングではやや上の方に属している。
SIerとひとくくりにして主語を広げたくないので、あくまで私の目で見える範囲の話で、サンプルの１つにすぎないものとして読んでほしいと思う。
【私の仕事について】
まず初めに、自分の仕事はなんだと言われると、それは「システムに関わるプロジェクトマネジメントをする人」ということしか出来ない。エンジニアとしてプログラミングをしたり、ハードの専門的な知識を持っているわけでもない。一日出社から退社まで何をしているかというと、
2.エクセルで作ったスケジュールやWBS(タスクリストみたいなもの)を広げて眺めている
3.問題が発生したら関係者を集めて対策を話し合う。あるいは進捗会議を開く
4.上司やユーザー宛へ説明する資料を作成する。そして実際に説明する
これくらいだ。コーディングという作業が入る余地は一切ない。ひたすら溜まっていくユーザーからの問い合わせや開発側からの問い合わせへのメールを返信する作業を続けている。この仕事で専門性をつけることができるとすれば、プロジェクトマネジメントしかない。プロジェクトマネジメントに関する体系的な考え方、大小に合わせたルールの作成、ユーザーと開発側の折衝ごと。これを突き詰めていくしかない。
同期や周りの先輩、後輩を見る限り、新卒で入ってきたうちの３割が情報系、３割が情報系以外の理系、残りが文系といった印象を受ける。
はてなを見ていてWeb業界やアプリ業界をさらーっとIT系の用語を知ることができたが、おそらく同期の半分以上の人はWordpressという存在を知らないだろう。
会社の中のほとんどの人がGit、GitHubを知らないだろうし、DockerやJavaScript系のライブラリ名を知っている人など皆無だと思う。それだけ、技術に貪欲でないし、それを使える環境はないし、ユーザーも投資しない。
新しい技術は基本的に入れることができない。ユーザー側の経営層がまず理解していないというのと、もしも万一障害が起きたら？という問いに回答できないケースばかりだからだ。だから、今動いているシステムにスパゲッティーをどばどば追加して、秘伝のソースで味付けし、もはや誰にも全容はわかりませーんと言ったことを10年、20年というスパンで行う。
誰も、どうしていいか分からない、どこから手をつけたらいいか分からないのだ。
じゃあ、1次請けだし、ユーザー要件定義が出来るかというとそうでもない。ユーザー業務に精通できないで、ユーザーテスト工程で決めきれていなかったものがバラバラ出てくるなんてザラだ。
ユーザーもユーザーで融通がきかない。個人的に、パッケージシステムを使うと決めたのであれば、どうやってもユーザー業務を変えていく必要があって、それができないのであればフルスクラッチでもっと金かけてやれよと思うのだが、ユーザーはパッケージ入れて安くしたい(金融系のパッケージなんてどれもべらぼうに高価だが)、かつ、業務は変えたくないのでがっつりカスタマイズしてと言ってくる。
また、業務内容によってはミスった時のリスクがでかい。特に法律に絡む案件は、ミスったら数百億の罰金をくらう可能性が常につきまとう。失敗が許されない。金融系のシステムはそういったリスクと常に向き合っていくので、楽しむことは難しい。うまくいくのが当たり前でなければならない。
【やりがいについて】
毎日メールとエクセルとパワポとにらめっこして、ユーザーとベンダーとおしゃべりして、何かやりがいはありますか？と問われると、少しだけあるにはある。
案件規模が億越え、10億とか普通な世界なので、官公庁と連携したりと大きな仕事が多い。勝手にゼネコンの人も同じ気分を味わっているんじゃないのかなーという気になっている(ごめんなさい)のだけど、
例えば「スカイツリー建設のプロジェクトマネジメントをしてました」と言えたら、自分少しは世のためになったかな？と思えると思う。そんな気分に少しだけなれる。自分が作ったわけじゃないけど、大きな仕事に少しだけ関わっているから。
だからエンジニアとして技術で飯を食べていこうとしてSIerに入ってしまった人には酷な会社である。そうやって間違えた同期は早々に転職していった。FBで多くの同期とつながっているが、技術よりのカンファレンスに行きましたとか、勉強会に行きましたといった話は、転職していった人からしか聞かない。会社に残っている同期から流れてくるのはリア充っぽい、旅行や飲み会の写真ばかりだ。
一方で、プロジェクトマネジメントに楽しみや喜びを得られる人には向いていると思う。多くの案件を見てきて、プロジェクトマネージャーが変わった瞬間に物事がうまく行きだしたとか、逆にうまくいかなくなったといった状況をたくさん見てきたので、スキルの必要な仕事であることは間違い無いと思う。それはエンジニアが求めるスキルと異なるだけで、割と専門性を突き詰めることが出来る職業だと思う。その会社特有のやり方に慣れずに、案件をこなしていく中で普遍的なスキルを身に付けることができれば、どこでも通用する可能性もある。(多くの人は会社特有のスキルを身につけてしまって、他社に転職できない状態になるのだが。)
私のやっているSE業と、世間のいわゆるエンジニア業というのは、かけ離れた職業であって、それぞれやりたい方をやればいいと思う。
ただ、私にはミスの許されない超絶大規模プロジェクトに精神をヒリヒリさせながら、数百人月のプロジェクトマネジメントを楽しむなんてことは全く出来ないので、どこか遠くに消え去りたいと日々思っている。
エンジニア立ち居振舞い: 技術的な暴力を振るわない - futoase
http://futoase.hatenablog.com/entry/2016/11/19/155427
例示されている暴力はだいたい頭の悪い暴力なので反論できます。
では今あるシステム全部PHPでリプレイスするとして、○人月の工数が必要ですがそのような予算はありません。
Go言語そのものの表現力が低い。そんなものを利用するならJava、Scalaで書くべきだ。ライブラリが豊富にあるだろう。Googleに縛られた環境での開発は恐ろしい。
ところでどうしてWindowsPCを開いてExcelで文書作ってるのか教えてください。
Serverlessそのものはサーバがなくなるわけではない。自身でチューニングなど細かなリソース管理ができないPaaSを使って自身のサービスの命運を預けるなんて馬鹿げている。
理屈の上ではオンプレミスやIaaSの方が細かな管理できるかもしれませんが、サーバ管理にそこまでコストかけるつもりが無いのに適当なこと言わないでください。
iOSアプリそのもの、プラットフォームがいつまであるかもわからないし、今後広がるかわからない。Objective Cを覚えたり、そんなものに技術をかけてどうするのか。
Nintendo Switchが大流行するかわからない。コントローラー使いづらいし。あんなものはチンケなものだ。そもそもUnityをインフラエンジニアが覚えて意味があるのか。
流行前は流行らないと言い、流行った後は将来性が無いと言う、じゃあ一生何も始めないつもりですか？
でも安心してください。すべてはUnityが解決してくれます。そう、Unityならね。
例示された人たちに暴力ふるいたい。
windowsとmacとフロントエンドとインフラと組み込みいう線引きからはみ出してはいけないと思うな。むしろ全部やれ全部だ！誰もお前がカバーしてない部分をサポートなんぞしねえからな！
ECサイト作りたい人 → ヤフオクでやれ(CMSを使うことの大切さ）
iosアプリ作りたいwindows開発者 → くだらないことにこだわってないでmacとiphone買え(ios開発は何もかもmacとxcodeが大前提）
フロントエンドプログラマがgo → goだけ使われても微妙。当然DBとの連携もあるんだよな？ん？(サーバサイドスクリプトはDB連携のためにあるようなもの）
サーバレスに興味あり組み込みエンジニア → どうでもいいからさっさと作れ。そこ悩むとこじゃねーから！(悩むなら一度サーバ立ち上げから自分でやってみてイメージをつかんだ方がいいかも）
NintendoとUnityとインフラエンジニア → やればいいと思うがハードルが高すぎて頓挫する可能性が高い。まずはUnityのエディタ上で動くくらいを目標にすべきだ。
小さいプロジェクト 1人で複数掛け持ちするくらいの大きさ 2人月以下
中くらいのプロジェクト 数人で行うくらいの大きさ 3〜25人月くらい
大きいプロジェクト 数十人で行う大きさ 25〜100人月くらい もしくは数十人のエンハンス、継続改修とか
巨大なプロジェクト 組織をまたぐような大きさ 100人月〜 もしくは数百人以上のエンハンス、継続改修とか
利点：すぐ仕事に慣れることができる、繰り返し試せる、効率化できればすごく儲かる
欠点：やり方がオレオレになる、タコツボ化する、そればっかりな人になる、色々抱えて抜け出せない、引き継げない、値崩れリスク
利点：適度な責任を負うことができる、リーダーや要件定義など上流に食い込みやすい、上流〜下流までやろうと思えばできる、スピード感を持てる、チームビルディングなども経験できる
欠点：人材の換えが効かなくていっぱいいっぱになる、意外とテンプレ化できなくて非効率なことが多い、人依存が強くチームに不出来なものが1人居るだけで割りと詰む、会社の規模が小さい場合が多い
利点：キャリアパスを描きやすい、給料も高め、人材の替えが効くくらいの規模になりやすい、頑張ればそのプロジェクトの中で大分成長できる
欠点：スピード感は無い、デスマ化しやすい、PM力に依る、上流に食い込みづらい
利点：職としては安定する、詳しい人が組織内に居ることが多い、有名なプロジェクトでやりがいがある事が多い
欠点：プロジェクトが長すぎて浦島太郎化する、全体を見通す力が失われる、世の中のスタンダードがわからなくなる、仕様書・伝言ゲーム・政治問題、頑張っても成果物の良し悪しには影響度が低い
規模を跨ぐだけで文化がガラッと変わるが、その文化がIT業界全体での常識だと思いこんでいる人が多い
一生同じ規模帯に居るならいいが、規模を跨ぐことがあるとカルチャーショックする場合もある
会社内に色んな規模のプロジェクトがなくて、行き来しづらいこと
同じプロジェクトや、同じようなプロジェクトに5年とか捕まると人材として凝り固まりそう
小〜大まで揃ってると心配はそれほどない
一人で黙々とやりたい人 → 小さい規模
職を安定させたい人 → 巨大な規模
技術を磨きたい人 → 中くらいの規模、大きい規模
ものづくりをやりたい人 → 小さい規模、中くらいの規模
上流〜下流まで磨きたい人 → 中くらいの規模、大きい規模
という感じだと思うが、何もわからずに規模を選択してしまい、それが常識だと絶望している人をたまーに見かける
巨大な規模のプロジェクトをやってる会社に正社員で入ってしまい
人を回すことが仕事になり、将来が不安になって出ていくのだが、そこで中くらいの規模帯の会社に入って今度は待遇の悪さに絶望する
巨大 → 大 ◯ よりプロジェクトに関われる
巨大 → 中小 × 待遇の悪さに驚く 30代くらいで世の中見えてきた頃ならいいかも？
大 → 巨大 ◯ より職は安定する、リーダー的なポジションに付けば技術力も別の方向に伸びるのでは
大 → 中 ◯ リーダー職ならあり？
大 → 小 △ どん判
中 → 小 △ フリーランスとかなら有りかも
小 → 巨大、大 × 死にたくなると思う
小 → 中 ◯ 歓迎されると思う
大に新卒
30代で再び大に転職
フリーランスになり小〜巨大を行き来する
30代後半で中〜巨大の会社に潜り込む
もちろんこんな順調に行ってないけど？
