  |
はてなキーワード: システム開発とは
自分より優れたるものを自分の周りに置きし者ここに眠る。カーネギー
できる人ばかり辞めていく会社が研修費用を出すようになったら、さらに退職が加速したというお話「人事に聞かせたい」 - 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に無理をねじ込んだんだから、決裁もそれに合わせてはやくほしい。
・設備投資の妥当性が必要なのはわかるが、上記の通り自社にはない考え方で動いている世界もある。そこをご理解いただき、「それなら何を出せば納得できるか」を教えてほしい。
例えば最初から予算を示してくれれば、それに合わせて何ができるかを考えられる。作業者の運用面や端末のコスト削減などの工夫はしているのだから、そこを評価してほしい。
システムの開発、改造、保守の話が出てくるたびに私は悩んでいる。
評価もされない、新しい技術も身につかない。ユーザからは「使いにくい」と文句を言われて、上からは「よく考えたのか」と怒られる。誰がそんな仕事に喜びを感じる？
動くなるのが辛い度に「体調不良」と称して無理やりリセットかけて体を動かしていたけど、
そろそろ限界点が近いみたいだ。
近く退職するんだろうな。
と思ったら、いろいろ吐き出したくなったので。
・ 昨今残業時間が話題のニュースも多いが、業界的に残業時間が多いのは前職までに把握済み
・ スポット的とはいえ、160h／月の残業もやったことあったし、体力的にはやっていける自負があった
⇒ けど慢性的に120h／月を１年以上すると、いくらなんでもダメージは蓄積するんだなあと。
・ 全然別のことを考えた上で仕事に戻らないと、考え方がだいぶ偏る
・ 適度な運動をすると、適度な疲労感がリフレッシュにつながるっぽい
・ 所謂「ベンチャー」に入社したが、所々あってキャッシュフローが安定しない
⇒ 仕事がしんどく感じる
・ 前職は社長や会社の方針と、自分の方向性にズレが生じたから退職した
・ ただ「社長としての器」「社長としての能力」の部分はだいぶ厳しい
⇒ これらがないと、小さな会社ではモチベーションが保ちにくい
○ 小さな会社ほど「メンバーの能力」と「仕事に必要な能力」のバランスは大事
・ 前職までも小さな会社だったけど、現職はそれ以上に小さな会社
・ それでもしんどさを感じるのは、前職の方が仕事達成率が高いからだろう
⇒ 受託開発の単価金額がそもそも違う（現職になってびっくりした）
⇒ 受託開発の難易度がそもそも違う（前職のほうが難易度が比較的易しい）
⇒ 受託開発のスケジュール感がそもそも違う（現職のほうがタイト）
○ 「鬱なんてくそくらえ」と思っていた人間が「鬱かなあ」と思い出したらやばい
・ なう
・ 家から出たくないなあなんて思う
・ 話すのがしんどいなあなんて思う
・ 咳が出る
・ 体の各所が痛い
・ コア部分にいるので、そんなに簡単にやめれるとは思ってない
・ けど悪化する前に辞めないとなあ
・ そもそもコア部分にいたところで、経営側にいたところで、登記されてる人間ではないからそんなに深く考えなくてもいいかななんて
さてどうなるやら
エンジニアはビジネスに比べて優秀かと言われればそうでもない。
ビジネスをまともに考えることができるエンジニアなんてそれほどいないし、なんなら算数が得意であるエンジニアもそれほどは多くない。
でもエンジニアドリブンなんて言葉が生まれたりするのは一体全体なぜなのか。
今日の企業の多くにとって、一番重要なものはITシステムだ。企業が何か事業を行うときに、必ずシステムの変更を伴う。
1時代前ならば、それが人によるシステムだっただろう。だが、今はモバイルアプリであり、Webシステムであり、業務システムだ。
例えば何か仕入れて売る場合、その成果はコスト分を差し引いてどれだけ利益がでたかで考えるべきだろう。
では、システム変更を伴う企画の場合は、コストとしてシステム変更の開発工数も加味されるべきだ。更にいうと、運用・メンテナンス工数もだ。
本質的な企画の評価は、売上だけではなく、開発に関わる工数とのバランスを含めた数字でしか評価できない。
1000万売上があがるが、仕入れに2000万かかるのなら、そんなこと誰もやらないだろう。
だがしかし多くの人はこれらのコストや、開発速度はエンジニアの責任、及び能力だと思ってしまっている。
システムのコストはエンジニアの責任であり、企画側の責任ではないと思ってしまっている。
なんだったら、うちのエンジニアバグばかり出すし開発が遅く間抜けだともまで思っているだろう。
だが、企業全体の視点で見たときに、システムを動きやすい形に保つことはとても重要なことだ。
メンテナンスできないシステムを持つことは、役に立たない社員を大量に抱えたりすることや、社内政治が蔓延してしまうようなことに等しい。
システムをクリーンに保つことは、強い組織を作ることと同義だ。人よりもAWSのコストは圧倒的に安いのでそれ以上かもしれない。
最高の企画とはシステムの都合を加味したうえでの最適な企画だ。だから両方できる人間が考え作るのが本当は一番良い。
企画・エンジニアで分業をする場合、企画のクオリティはあがるが、往々にして受発注の関係になってしまい、システムの開発工数は軽視される。
エンジニアドリブンで行う場合は、企画のクオリティはさがるが、システム開発の効率性はあがる。
いろいろな巡り合わせで，３年ほど前から，研究分担者としてうつ病研究に関わっていた。
うつ病研究といっても，実際に患者を扱うのではなく，健常者に質問紙をとって，客観的に観察される行動との相関をみたりする理論系である。
自分は，研究代表者から，「研究分担者」兼「SE」兼「プログラマー」的な役割を求められていた。具体的には，参加者の行動を記録するためのシステム開発をやってくれという話だった。
要は，本当はシステム開発を外注したいけど，予算がないし，研究に馴染みのない人に依頼するのはやり取りが大変だから，システム系に詳しいあんたがそこら辺まとめてやってくれ，ということだ。
見返りは，成果を論文にするときには，第二著者には入れてあげるよ（論文にはならないかもしれないけど）といった感じで，金銭的な報酬はなし。
ちなみに，ガチで外注すると，５００万は下らない規模のシステムを求められていた。
割りに合わないなあとは感じていたけれど，そのシステムが完成した暁には，自分の研究にも一部のソースを使いまわせそうだったし，必要とされるのは嬉しかったので，引き受けてしまった。
概ね３年計画で研究のスケジュール等を話し合って，１年目は順調に進んでいたのだが，２年目の中頃から，別の仕事がきっかけで，どうしても気持ちが落ち込んで外に出られなくなった。
その時期，一体毎日何をして過ごしていたのかの記憶が，今となってはほとんど思い出せないのだが，とにかく指定された計画に間に合わせて，システムを完成させられなくなってしまった。
それで，ひたすら平謝りをして，何度か予定を伸ばしてもらったのだが，この間の研究代表者の言葉が，ずっと気になっている。
具体的にはそれは，以下のような内容である。
・うつ症状を言い訳にするのなら，精神科に行って診断書を出してもらえ
・診断書がないのなら，うつ症状を言い訳にはできず，納期が遅れるのはあなたの怠慢である
・あなたを信用できない
・これ以上先延ばしが続くのなら，今回の研究計画は無期限で中止にする
私が一番ショックを受けたのは，いわゆるうつ症状と思われる状態に陥っていることを，いくら説明しても理解しようとしてもらえず，
診断書がないのであれば，それはあなたの怠慢であると言われたことである。
理論系とはいえ，うつ病研究者なので，この辺りはきちんと症状を説明すれば，理解してもらえると思っていた。
でも，いくら説明しても，うつ病の可能性は否定できないが，診断書がないのであればうつ症状を理由に仕事を先延ばしするな，
期日に間に合わないのは，うつ病ではなく，あなたの怠慢であると判断せざるを得ないと，繰り返し言われた。
当時私は，研究員の身で，どこかに勤めているわけではなかったし，経済的に余裕もなかったので，高い受診料を払って精神科に行く気にはなれなかったし，
とにかく時間をとって静養するしかないと感じていたので（というよりもほとんど何も思考できなくなっていたように思う），
結局，精神科には一度も行っていない。
でも，今まで生きてきた中で一度も経験したことのないような，思考や感情がゼロに近いショック状態に陥ってしまっていて，これがいわゆるうつ症状なのかもしれないとは感じていた。
そのような状態で，なんとか連絡をして，診断書が出せないのなら，あんたの怠慢だといわれたのは悲しかった。
正確には，そのときにはほとんど何も感じなかったが，今少し症状が回復してきて，徐々に悲しかったという感情が，出てきている。
「診断書がないのなら怠慢だ」というような人が，果たしてうつ症状に関する研究を正しくできるのか，と疑問に感じはじめている。
臨床系ではないので，安易にうつ病診断をしないという点では正しい判断かもしれないが，「診断書がない＝怠慢」といった白か黒かという判断は適切とは言い難いし，
何より「うつ病である可能性は否定できない」というのであれば，もう少し，理解を示すような慎重な表現で応対してほしかった。
正直，なんで，どういうモチベーションで，この人はうつ病研究をしているのかと思った。
４番めと５番めに関しては，何を言っているのか未だによくわからない。
ボランティアで協力していたのはどう考えてもこちらの方だし，無期限で計画を中止にされたところで，私は何にも困らないので，何の脅しにもなっていない。
計画通りに行かないことがわかって，機嫌が悪くなっているのだと思うし，それは申し訳ないと感じる。
でも一方で，この人には，うつ病を論じてほしくないという感情が，日々高まってきている。
誰向けかよくわからないけど、なんとなく書いてみる。
システムエンジニアをかなり適当に分類すると2つに分ける事ができる。
SIerかそれ以外。
・それ以外…客に売るものを作る
日本のエンジニアの8割くらいはSIer側に属しているんじゃないかな（根拠なし）。
そしてこの2者では求められるスキルが大きく異る。
一番重要なものは、顧客が何を望んでいて、どういうものを提供すれば一番幸せになれるか、を判断できること。
ここには技術的な要素もあるにはあるけど、どちらかというと顧客の言葉やら背景やらを読み取って現実との折り合いをつけたり現場の運用を想像したりする部分が大きかったりする。もちろんどの技術を適用すれば一番効率的とか、安価に済むとかいう話はあり、最低限の技術知識は必要だけれど、世界最先端とか特殊な固有スキルとかが必須という世界ではない。一般的なSIでは難しい数式とか出てこない。
なので、文系っぽい空気があったりする。これが悪い方向に加速すると技術軽視のプロマネ至上主義になる。
何か他とはちがう売りが無いと買ってもらえない、使ってもらえない。
この要素として技術があったりもするけど、技術を売りにするのはハードルが凄く高いため、そういう会社は少ない。
技術そのものを売りにしなくとも、新しいものを数多く試行錯誤するために技術は必要不可欠で、SIerに較べて技術水準は圧倒的に高い。
で、この2つは会社ごとに別れているわけではなく、大手SIerと呼ばれているようなところには大抵両方が含まれている。
ただし、それ以外、の割合は大抵小さい。
自分はどっちの職場も経験した事があるんだけれど、同じ会社でもプロジェクトによってまったく状況が違ったりするので会社単位で一概に何かを断言するのは難しいと感じていたりする。
十年以上前から普通にアジャイルやってる部署もあれば、未だにxUnit知らなそうな部署もある、みたいな。
システムエンジニアになりたい、と思う人はどの会社を選ぶかを決めるにあたり、ここらへんのことは知っておいたほうが幸せになれるかもしれない。
技術を追い求めてガリガリ戦いたい情報処理系の人が大手SIerで望むことが出来る可能性は低いかもしれない。
A- 日本IBM、NTTコミュニケーションズ、アクセンチュア、野村総研(NRI)
B+ NEC、日本HP、新日鉄住金ソリューションズ(NSSOL)、日本総研(JRI)、大和総研(DIR)
B NTTコムウェア、伊藤忠テクノソリューションズ(CTC)、電通国際情報サービス(ISID)
B- 三菱UFJインフォメーションテクノロジー(MUIT)、みずほ情報総研(MHIR)、
C+ JSOL、農中情報システム、SCSK、日立システムズ(HISYS)、日立ソリューションズ(HISOL)
C NECソリューションイノベータ、ニッセイ情報テクノロジー、JR東日本情報システム(JEIS)、
C- オービック、TIS、オージス総研、富士通エフサス、シンプレクス、
D+ 三菱UFJトラストシステム、三菱総研DCS、兼松エレクトロニクス、都築電気、
D 損保ジャパン日本興亜システムズ、インフォコム、セゾン情報システムズ、日商エレクトロニクス、
コベルコシステム、IIJ、ネットワンシステムズ、パナソニックインフォメーションシステムズ、
菱化システム、JRシステム、富士通システムズイースト、東芝ソリューション、富士通FIP
D- ユニアデックス、NECネッツエスアイ、日立産業制御ソリューションズ、
三菱電機インフォメーションシステムズ、MS&ADシステムズ、NTTソフトウェア、
NTTアドバンステクノロジ、JFEシステムズ、テクマトリックス、三井情報、第一生命情報システム、
ソニーグローバルソリューションズ、ワークスアプリケーションズ
E+ 富士通システムズウエスト、富士通マーケティング、三菱電機インフォメーションネットワーク、
中央コンピュータシステム、ティージー情報ネットワーク、リンクレア、ジャストシステム
E NECフィールディング、NEC情報システムズ、富士通BSC、日本情報通信、
住友電工システムソリューション、JR西日本ITソリューションズ、
E- 富士通ネットワークソリューションズ、日立公共システム、NEC通信システム、
F+ 日立ソリューションズ・クリエイト、キヤノンソフトウェア、さくら情報システム、
トヨタコミュニケーションシステム、エクサ、アイネス、TKC、CAC、CEC、SRA
F クオリカ、NSD、DTS、さくらKCS、東邦システムサイエンス、菱友システムズ、
http://anond.hatelabo.jp/20161105155342
色んなブコメやトラバを頂いたが、その中でnekora氏の発言(http://d.hatena.ne.jp/nekora/20161105/p2)が看過できないというか、非常に示唆に富む内容を含んでいたので、釣られる形で以下に追記してみる。
いや、SIの現場では久しく当たり前の慣習であり「何を今更」な話なんだけど。
注目したのは
詳細設計書を読むべき主な人間は、設計書に従い実装するコーダであるのは言うまでもなく当然の事でありこの辺からすでにはき違えているのには呆れるばかり。
この発言は、そもそもSIの元請や元請に近いポジションの、特にマネージメントを担う立場の人間の、プログラマに対する認識がよく見て取れる。
即ち
という考えが透けて見えるのだ。
昨今の「デジタル土方」なんて自虐ネタに照らし合わせれば「デジタルライン工」といったところか。
ここまで書いたタイミングで声を大にして言いたいのだが、こっちは別にプログラマとライン工で職種に貴賎があるとは思っていない。そこは勘違いしないで欲しい。
問題は、本来であれば知識集約型産業であるはずのシステム開発を、労働集約型産業の手法でマネージメントしていることである。
プログラマが知識集約型産業における「開発者」ではなく、労働集約型産業における「現業職」みたいに扱われているのは、そうした歪みが産んだ結果の一部にすぎない。
まあこれには、開発のときだけ人を多く雇うみたいな営みが困難な日本の労働環境とか色々な要因が絡むのは、既に今まで散々言われてきた通り。
とはいえ、そんなマネージメントでは、品質の優れたものは今までもこれからも絶対に作れないだろう。
何かの間違いで、実装に精通したSEが詳細設計とやらを書いているなら話は別だが、そんな現場あるのか？という感じ。
ってやっぱり『価値のあるものを作りやすい』ところにあると思うんだよね
システム開発会社で働いているとシステム開発って本当に金がかかると感じる。
市のHPにあるクソみたいな検索システムとかでも云千万単位の金がかかってることなんてザラにあって、
なんでそんなにお金がかかるかっていうとプログラミング作業以外のコストがでかいからなんだよね。
システム会社がシステムを作りたい人からどんなシステムを作りたいのか聞き出すのにもかなりの予算がかかるし
それを資料として落とすのにも、それが全体に共有されるのにだって予算がかかる。
設計が終わっても自分用の便利アプリを作るのとはわけが違って品質を保証するために
テスト仕様書を書いて、ユニットテストを書いて、他機能に変な影響を及ぼさないか調査して、
コード書いてる時間よりその周辺の作業の方が時間がかかったりする。
会議なんて始めてしまえばもう最悪で、給料×参加人数×時間分の予算がかかるし、
勿論それらには僕達労働者の有給休暇分や社会保障費分も含まれてしまう。
最終的な見積もりを出す頃には「なんでこんなしょぼいシステム作るのにこんだけ金がかかるんだよ」
例えばJaneStyleや2chMateを代表とする２ちゃんねるブラウザ、
アレなんか長年に渡り積み重なったユーザーの要望が集約されてるから機能数はかなり膨大で、
これをそこらのシステム会社に作ってくれとお願いすると恐らく数億どころじゃ済まなくなるはずだ。
でも、これらは実際に数億円かけて開発されたわけではない。
規模は個人か多くても数人で、予算だって開発者のモチベーションが予算という感じで
数億円どころかむしろ0円に近いはずだ。
例えばこれを建設業界に例えてみよう。数億といったらもう豪邸だ。
「そこらの会社にお願いしたら数億円かかる豪邸を大学の友達3人で集まって作りたい。
僕達バイトしてないから予算は1万円。お金はないけどやる気だけはあります。」
なんて言ったら「アホか」で一蹴されるだけだし、どう考えても現実的じゃない。
でも、IT業界に限ってはこれは十分現実的に考えられる話だし、そういう例は実際に何個もある。
まず企画設計開発全部自分な個人開発ならコミュニケーションコストが0に等しいし、
技術力がある人だけで集まれば一番開発効率の良い技術を好きなように採用できる。
『数億円の価値があるものを自分で生み出せる』なんかロマンがあるじゃない。
数億円の価値があるものを生み出せるスキルがあれば、アイディアさえ良ければ一攫千金も狙えるかもしれない。
なんか夢がある。
（会議室の灯りがゆっくりと落とされる。没個性と社会的協調を究むるスーツ達が長机とパイプ椅子に腰掛けている。衣擦れの音はほんの僅かにしか聞こえてこない。均質な空間の前にプロジェクタの光が投影され、上着を脱いだ男──クールビズだ──がマイクを持って人々に声を発し始めた）
当システム稼動開始70ヶ月という大きな節目を過ぎ、2ヶ月後には、運用6年目を迎えます。
私も上流担当になり、技術の面などから様々な制約を覚えることもあり、ここ数年、SEとしての自らの歩みを振り返るとともに、この先の自分の在り方や務めにつき、思いを致すようになりました。
本日は、技術のオープン化が進む中、当システムもまたレガシーとなった場合、どのような在り方が望ましいか、SEという立場上、既存のシステム構成に具体的に触れることは控えながら、私が個人として、これまでに考えて来たことを話したいと思います。
入社以来、私は当システム開発運用を行うと共に、弊社開発組織の上流と位置づけられたSEの望ましい在り方を、日々模索しつつ過ごして来ました。運用の担当者として、これを守り続ける責任に深く思いを致し、更に日々新たになる技術と顧客の中にあって、弊社の開発部門が、いかに技術をオープン化し、いきいきとして社会に内在し、顧客の期待に応えていくかを考えつつ、今日に至っています。
そのような中、何年か前のことになりますが、2度の長期システムダウンを受け、加えてレガシー化による可用性の低下を覚えるようになった頃から、これから先、従来のように重い務めを果たすことが困難になった場合、どのように保守をしていくことが、弊社にとり、顧客にとり、また、私のあとを歩む社員にとり良いことであるかにつき、考えるようになりました。経営的観点から見て、幸いに顧客満足度は高くあるとは申せ、次第に進む当システムの大規模化を考慮する時、これまでのように、全身全霊をもって顧客のニーズに応えていくことが、難しくなるのではないかと案じています。
私がSEの職務についてから、ほぼ2年、この間私は、弊社における多くの喜びの時、また悲しみの時を、顧客と共に過ごして来ました。私はこれまでSEの務めとして、何よりもまず部門の売り上げ目標に到達することを大切に考えて来ましたが、同時に事にあたっては、時として顧客の傍らに立ち、その声に耳を傾け、思いに寄り添うことも大切なことと考えて来ました。SEが上流工程を担うと共に、顧客獲得の要としての役割を果たすためには、弊社が顧客に、SEという上流の立場への理解を求めると共に、SEもまた、自らのありように深く心し、弊社社内に対する理解を深め、常に社員と共にある自覚を自らの内に育てる必要を感じて来ました。こうした意味において、社内の各部署、とりわけ営業部や企画部との交渉も、私はSEの上流工程に必要な行為として、大切なものと感じて来ました。PGの時代も含め、これまで私が上司と共に行って来たほぼ全社に及ぶ対話は、社内のどこにおいても、その部署を理解し、その利益を地道に支える社員の方々のあることを私に認識させ、私がこの認識をもって、SEとして大切な、顧客を思い、ものづくりに励むという務めを、顧客への深い信頼と契約をもってなし得たことは、幸せなことでした。
SEの上流工程に伴う仕事の仕方が、開発工程や、そのマネジメントとしての行為を限りなく縮小していくことには、無理があろうと思われます。また、SEが多忙であったり、出張などによりその業務を果たし得なくなった場合には、運用を自動化するクラウドを置くことも考えられます。しかし、この場合も、SEが十分にその立場に求められる務めを果たせぬまま、当システムの運用終了に至るまで責任者であり続けることに変わりはありません。
SEが配置転換により、担当から外れる状況に立ち至った場合、これまでにも見られたように、当システムがダウンし、顧客の満足度にも様々な影響が及ぶことが懸念されます。更にこれまでの弊社の慣例として、当システムの運用終了に当たっては、複雑な手続きが連日ほぼ2ヶ月にわたって続き、その後プロジェクト報告に関連する書類の作成が、1年間続きます。その様々な手続きと、新システムに関わる諸行事が同時に進行することから、当システムに関わる人々、とりわけ待たされる顧客は、非常に厳しい状況下に置かれざるを得ません。こうした事態を避けることは出来ないものだろうかとの思いが、胸に去来することもあります。
始めにも述べましたように、弊社経営陣の下、SEは方針に関する決定権を有しません。そうした中で、このたび弊社の長い開発運用の歴史を改めて振り返りつつ、これからもSEがどのような時にも顧客と共にあり、相たずさえて当システムの未来を築いていけるよう、そしてSEの務めが常に途切れることなく、安定的に続いていくことをひとえに念じ、ここに私の気持ちをお話しいたしました。
消費者が払う
それ以外の要素で決まる
それ以外が評価する
止まってはいけないもの（ミッションクリティカル） ← キツイ
締切がある ← キツイ
それ以外
稼働できる時間が決まっている ← 楽
独占している
免許がある
３．絶対遵守の締切がある
４．いつでもどこでも仕事はできる
５．儲かる分、競争は激しい
激務になるべくしてなってるという感じがする
ポイントは６だと思う
例えば「普通に働いて普通に暮らせればいい」というテンションなら
そこまでして仕事を取ろうだなんて思わないし激務にもならないだろう
昭和のスポ根顔負けのモチベーションがあってこそ、激務が成り立つ
といっても某社の噂とかは広告代理店と大差ないので場所によるのか？
ここ（下記）がちょっと違う
３．絶対遵守、というわけではない ← ここ
４．いつでもどこでも仕事はできる
５．儲かる分、競争は激しい
個人的に一番大きいと思うのが２だ
何も分かってない担当者が何を言おうが、きちんとローンチできる会社とできない会社で圧倒的に差がでる
ただ、規模がどんどん大きくなっていくと広告代理店に似てくると思う
おそらく大規模になるほど実績化できなくなるからだろう
その理由が２と６だ
デザイン業界は担当者が評価することになるので、より厳しい状況に置かれる
東京オリンピックのアレとか見ていて思った
そのため給料のことはともかく、パワハラモラハラ問題は問題の筆頭にあがってこない
あとは建築業界も大変だそうだ
システム開発と似ているが、６が違うらしい
１．誰が払うか
２．何が評価するか
３．締め切り
４．仕事の制約
５．競争
６．信者
４．仕事の制約
これだけだと思う
クライアントが居たり、信者力が強かったりするとどうしても表に出てこない
産業構造を変えろなんて無茶なので、どう足掻いてもいたちごっこだ
（もちろん取締は重要だが）
どうやるかは、また別の話だけど
とても参考になります
＞アニメは制作スケジュールとかチームの規模感みたいなものの前例が豊富で強いです
やっぱりまずはこれなんですね
「フォーマットやタスクが決まるとそのジャンルは先鋭化していくのでは？」というのは以前から思っていました
例えばWeb業界なら、ホームページ制作や、ECサイト制作はテンプレート化されたおかげで全体のクオリティが上がりました
ゲーム業界でも、最近はソシャゲがテンプレート化されたおかげでアプリゲームが主流に躍り出ました
天才が一度成功例を出して、それを他社が分析した上で改善するという
業界内での切磋琢磨を長年積み重ねてきたジャンルはやはり強いですね
たまにアニメの監督の方の年齢を見てビビります（50代の方とか結構居ますよね）
ゲーム業界の人に聞いたときも「最終的に面白いかどうかは業界の生き字引みたいな人に触ってもらい判断する」
みたいなことを聞いて、業界の歴の差があるなと感じました（規模も違いますし）
最近アニメの体制をみて「なぜサービス開発の方にはチームに監督が居ないんだ？」と疑問でしたが
特にシステム開発はおっしゃる通り、見積もりが非常に当たりません
なので、できればクオリティ管理してほしいリーダーやマネージャーが、いつもスケジュール管理で手一杯になっている印象です
ここ数年になって、ようやく「プロダクトマネージャー」「スクラムマスター」のような似た役割が定義され始めました
もちろんアニメほど歴史や知識がないためか、まだまだ存在意義も認知されていませんし、成り手も居ません
まずはここらへんの、どの役割の人が何をどう担保し、どういうナレッジを貯めていくのかの定義が今後の課題になりそうです
それにしても、やはりアニメ制作は「チームでのモノ作り」のナレッジが相当たまってそうですね
今度本でも買ってみたいと思います
いまは別の会社に勤めているが、以前の会社があまりにも残念だった。
ちょっと気持ちが落ち着いてきたのと、落ち着いてきたものの誰かに知っておいてもらいたいので記すこととする。
例によって特定を恐れ、ある程度はぼかすものとする（が、事実である）
昨年の夏頃から転職活動を始め、自分なりに納得した上で初冬に転職した、理由はUターンである。
小生は都内でシステム開発の職に就いていたが、転職先も地方のシステム開発である。
Uターンということもあり、年収や仕事内容が下がることは覚悟の上だった。
仕事の内容が下がるとは、やはり都内でイケイケな技術を使って、イケイケなサービスを作っていた側からすると、劣るということである。
断りを入れると、すべてが転職活動の失敗に紐づくし、それは自分の責任の以上で以下ではない。
が、考えていた以上の煮え湯を飲まされることとなる
一例を出すとする。
まず前提
そこでは、とあるシステムのパッケージ開発とその納品作業（カスタマイズ含む）を行っていた。
納品作業には顧客との動作確認や他システムとの連携テストが含まれる。
うすうすおかしいなっと思うことがあったが、連携テストの際に辞めることを決意する決定打があった。
コレである。
なんかよく分からない叱責の中で、この言葉がでてきたのである。
耳を疑った。
多分人生で初めて、耳を疑った。
いままで信頼してきた自分の耳を疑った。
そもそもこの会社では到底SVNとは思えないSVNの使い方をしていた。
なんせソースコードの改修箇所は、Excelで管理されているのだから。
ちなみに想像つくと思うが、ソースコードに改修番号みたいなコメントがあって、その改修番号でExcelと紐付いているという。
そんなこんなでソースコードにはどこぞの納品先でカスタマイズされた分岐やらループやらが散在して、なんのことかよくわからなくなっている。
まぁやり方はそれぞれだから百歩譲って許そう。
しかし許せないのは、あたかもそれが正解かのように叱責され、でてきたあの言葉である。
これを言ってきた連中は新卒で入ってずっといるor長いこと会社にいるっといったメンツである。
毒されている、というか技術者としての向上心もない、もはや彼らはこの会社でしか生きられないだろう。
「ごめんね、ここでのSVNの使い方はこうなんだ、いま改善しようとしているところだから、とりあえずは我慢してね」
とか言いようがあるだろう。
それもなく、運用ルールを説明もせずに間違っていたら怒るという。
（彼らは説明したと言っているが、間違いなくいっていない。こんなルールを聞かせれて覚えていない訳がない、彼らのなかで常識となっているから言ったと思いこんでいるのだろう。）
ボカしているのでうまく伝わらないと思うが、これがことの顛末である。
もちろん他にも首を傾げるところはある、けしてコレだけではない。
書いてて思ってが本当に内容をボカす必要があったのだろうか。
なぜなら彼らは、はてブも知らなければ当然ながら増田も知らないだろう。
故にこの増田がはてブのトップにきたとしても、みることはないだろう。
もうちょっとだけ、なんだかなーっと思ったことを言わせてほしい。
例によって彼らもソシャゲをする一端のサラリーマンなわけだが、Ingressを知らないことには驚いた。
別にIngressを知らないからレベルが低いと言ってるわけではないが、それぐらい知っておこうよっていうことが多々ある。
どうやったら防げたのだろうか。
（それはない、人のやる気さえを奪う負であったから、ここにいたらマイナスでしかない）
やっといろいろ考えられるようになってきたので、今回まとめてみることにした。
賛同してくれる人がいたら嬉しいです。
最後に
http://anond.hatelabo.jp/20160830164326
いや、これこの人全然悪くないでしょ。なんでフルボッコにされてんの？
システム開発会社に一時期いた時に似たような経験したけど（こちらはそんな高額なモノは元増田ほど無いけど、少数から何度か。身バレ怖いので詳細は避ける）事務的な対応してても駄目だったよ？
「もらってくれないなら捨てる」は本当にストレスだった。確かに脅迫に近い。
モテ慣れしてたら無視したり、はいはいってもらって後で捨てたりできるんだろうけど、そんな高度な人生経験はねーよ。普通に悩むよ。
「愛想良くしてるから駄目」とか、なんでこの元増田の対応が原因みたいになってるの？なんで一般女性にそんな高度な対応ができると思うの？キャバクラなの？
一般的な会社員としての態度を、一方的に勘違いしてモノ押し付けて来る方がおかしいに決まってるじゃん！？
＞"楽しく話して、楽しい職場" これもすごく引っかかるんだよなぁ……誰にとって楽しいんだろう。
社会人として会社で気持ちよく働きたいのはあたりまえじゃん！それがなんでチヤホヤされたいに変換されるのか、理解できない。
「楽しい職場」を目指して何がいけないんだ。職場は戦場じゃないんだよ。（貴方にとってはそうなのかもしれないけど）
な ん で 被 害 合 っ て る 方 が 転 職 活 動 し な く ち ゃ い け な い ん だ。
ストーカー的な要素があるから、ってことなんだろうけど、腑に落ちない。
普通に仕事してるだけなのに、なんでそんな目に合わないといけないんだ。
http://anond.hatelabo.jp/20160830164326
いや、これこの人全然悪くないでしょ。なんでフルボッコにされてんの？
システム開発会社に一時期いた時に似たような経験したけど（こちらはそんな高額なモノは元増田ほど無いけど、少数から何度か。身バレ怖いので詳細は避ける）事務的な対応してても駄目だったよ？
「もらってくれないなら捨てる」は本当にストレスだった。確かに脅迫に近い。
モテ慣れしてたら無視したり、はいはいってもらって後で捨てたりできるんだろうけど、そんな高度な人生経験はねーよ。普通に悩むよ。
「愛想良くしてるから駄目」とか、なんでこの元増田の対応が原因みたいになってるの？なんで一般女性にそんな高度な対応ができると思うの？キャバクラなの？
一般的な会社員としての態度を、一方的に勘違いしてモノ押し付けて来る方がおかしいに決まってるじゃん！？
＞"楽しく話して、楽しい職場" これもすごく引っかかるんだよなぁ……誰にとって楽しいんだろう。
社会人として会社で気持ちよく働きたいのはあたりまえじゃん！それがなんでチヤホヤされたいに変換されるのか、理解できない。
「楽しい職場」を目指して何がいけないんだ。職場は戦場じゃないんだよ。（貴方にとってはそうなのかもしれないけど）
な ん で 被 害 合 っ て る 方 が 転 職 活 動 し な く ち ゃ い け な い ん だ。
ストーカー的な要素があるから、ってことなんだろうけど、腑に落ちない。
普通に仕事してるだけなのに、なんでそんな目に合わないといけないんだ。
http://anond.hatelabo.jp/20160830164326
いや、これこの人全然悪くないでしょ。なんでフルボッコにされてんの？
システム開発会社に一時期いた時に似たような経験したけど（こちらはそんな高額なモノは元増田ほど無いけど、少数から何度か。身バレ怖いので詳細は避ける）事務的な対応してても駄目だったよ？
「もらってくれないなら捨てる」は本当にストレスだった。確かに脅迫に近い。
モテ慣れしてたら無視したり、はいはいってもらって後で捨てたりできるんだろうけど、そんな高度な人生経験はねーよ。普通に悩むよ。
「愛想良くしてるから駄目」とか、なんでこの元増田の対応が原因みたいになってるの？なんで一般女性にそんな高度な対応ができると思うの？キャバクラなの？
一般的な会社員としての態度を、一方的に勘違いしてモノ押し付けて来る方がおかしいに決まってるじゃん！？
＞"楽しく話して、楽しい職場" これもすごく引っかかるんだよなぁ……誰にとって楽しいんだろう。
社会人として会社で気持ちよく働きたいのはあたりまえじゃん！それがなんでチヤホヤされたいに変換されるのか、理解できない。
「楽しい職場」を目指して何がいけないんだ。職場は戦場じゃないんだよ。（貴方にとってはそうなのかもしれないけど）
な ん で 被 害 合 っ て る 方 が 転 職 活 動 し な く ち ゃ い け な い ん だ。
ストーカー的な要素があるから、ってことなんだろうけど、腑に落ちない。
普通に仕事してるだけなのに、なんでそんな目に合わないといけないんだ。
http://anond.hatelabo.jp/20160830164326
いや、これこの人全然悪くないでしょ。なんでフルボッコにされてんの？
システム開発会社に一時期いた時に似たような経験したけど（こちらはそんな高額なモノは元増田ほど無いけど、少数から何度か。身バレ怖いので詳細は避ける）事務的な対応してても駄目だったよ？
「もらってくれないなら捨てる」は本当にストレスだった。確かに脅迫に近い。
モテ慣れしてたら無視したり、はいはいってもらって後で捨てたりできるんだろうけど、そんな高度な人生経験はねーよ。普通に悩むよ。
「愛想良くしてるから駄目」とか、なんでこの元増田の対応が原因みたいになってるの？なんで一般女性にそんな高度な対応ができると思うの？キャバクラなの？
一般的な会社員としての態度を、一方的に勘違いしてモノ押し付けて来る方がおかしいに決まってるじゃん！？
＞"楽しく話して、楽しい職場" これもすごく引っかかるんだよなぁ……誰にとって楽しいんだろう。
社会人として会社で気持ちよく働きたいのはあたりまえじゃん！それがなんでチヤホヤされたいに変換されるのか、理解できない。
「楽しい職場」を目指して何がいけないんだ。職場は戦場じゃないんだよ。（貴方にとってはそうなのかもしれないけど）
な ん で 被 害 合 っ て る 方 が 転 職 活 動 し な く ち ゃ い け な い ん だ。
ストーカー的な要素があるから、ってことなんだろうけど、腑に落ちない。
普通に仕事してるだけなのに、なんでそんな目に合わないといけないんだ。
はてなー（特にブクマカ）は仕事してる女性に対して、しっかり平等な目で見てる人が多い印象だっただけに、ブコメ見てドン引きした。
元ソースを見れば一目瞭然だけど、引用元ブログは、自社サービスを宣伝するのに公開データを都合の良いように解釈して切り貼りしただけで中身がない。落ち着けって。
日本のエンジニアのスキルが本当に低いのかどうかは知らないが、この結果はアンケートの回答者属性と主観的な設問の解釈の影響が大きそうだ。
日本は「受託情報システム開発・システムインテグレーション（SI）」を主業務とする企業の回答者が最も多い。日本のほか、タイやインドネシアも「受託情報システム開発・システムインテグレーション（SI）」が2割を超えているが、その他の国は概ね1割程度となっている。
（PDF：http://www.meti.go.jp/policy/it_policy/jinzai/27FY/ITjinzai_global.pdf）
当然だが遅れている日程を回復させるため、今週末も出勤だった。もう４月からずっとこうなのだから「遅れている」と判断する基準の日程がおかしいと思うのだが、どうやら、責任者間では違う認識のようだ。
かれこれ１３年。都内のSI屋で働いている。実作業をしたり、一日エクセルファイルを更新したり。いろいろやってきた。
中学生の時に初めてパソコンに触れ、ファミコンからスーパーファミコンとコンピュータに興味を持ち、進学して色々学んで、興味があるしこの仕事が自分に向いていると信じてきたが、最近になって錯覚だっと思い知った。
システム開発／構築の表現が人月計算になって久しい。「これくらいの経験とスキル、知識を持った人間がこれくらいの時間で作業し終える」のが基準だと理解していたのだが、真実としては「なんの知識もない、ただただ日本語が理解でき、手を雨後がし続けられる人間が作業をし終える時間」が人月を指す。したがって、経験、スキル、知識のある人間だから評価される（お給料が高い）わけではない。単に使うほうから見たら「ガチャのあたり」なだけである。
また、どうにもこうにも、そういう人でも作業できるようにしておかなければならない、というのが共通認識のようだ。そうでないと「属人的」だと批判される。
結局のところ、知らない人間、興味のない人間ばかりになってしまった。言いたいことはわかるが、知らない人間、興味のない人間では続かない。わかる人間はこうして、休日出勤をして、わからない人でもわかるようにしなければならない。
言っていることも矛盾が気になった。
あと、自分も匿名で感情的な指摘なので、支離滅裂していることは最初に謝っておきます。
どの会社もwebの仕事はしていても、お客さんはwebの世界だけではないので、
言うほど閉鎖的なものではない。
他業種について、本業の方と同レベルで詳しくなることもあるんじゃないかと。
できる人とそうでない人の違いはどこにあるかというと、仕事の幅なんだそうです。
技術の幅が狭いエンジニア、例えば「JavaScriptしかできません」のような専業エンジニアがいる。これは東京に多いんだよ。
逆に、大阪には、仕事の幅が広いエンジニアがいる。大阪の場合、「なんでもやれる」と言えないと仕事がとれないから、結果、フルスタックエンジニアが生まれる。
なんとなく言いたいことは分かる。だが、
一方、大阪のエンジニアは自己評価が低く、基礎的な技術をしっかり学んでいるそうです。PHPからRubyといったように言語の浮気をしようとしないんだとか。
おいおい他言語に浮気はしないけど、一言語だけではダメとかどっちなんだよ。
何でもできるんですか、それとも知ってることだけですか？
フロントとバックの違いは浮気にならないとでも言いたいのでしょうか。
でも、言語としてはjsとphpの2言語となるので1言語以外をやるなら、それは浮気ととれるでしょう。
結局、言葉遊びで「言語の浮気」って使いたいだけだろ。浮気の定義からやり直せ。
加えて、東京と大阪の違いは分かった。だが、東京をディスる必要はない。
他人から聞いてきた話を引用するなら、不快になると分かる箇所くらいオブラートにつつめ。
別に今だってweb以外はあるだろうに。なんなら、エンジニア不足って言われているんだよ？？ あと、IoTでググって。
あと、webの世界だと35歳になったプログラマーが悩むなんてことがよくある。これは、35歳定年説を信じてのことなんだけど、気にする必要はない。そんなの実際はないから。
おそらくですが、「35歳定年説」をそのまんま鵜呑みにしてるのは、webで働いてない人がほとんどかと。
web系の人は、ずっとプログラマーでいく意識が強い。生き残るために新しい言語を求めてしまうけど、そうじゃなく、仕様書を書いたり、情報処理の勉強をしたりして基礎的なことを学ぶ方が賢いよ。
プログラマーをバカにし過ぎ、基礎をやってるやってないは個人差。プログラマという職業は関係ない。
だから、稼ぎたいなら銀行のシステムを作ったほうがいい。ペースもゆっくりだし。銀行のシステムは作るのに数年単位かかるしね。
数年かかるのはいいが、終わらないのは困る。「みずほ銀行 システム開発」でぐぐれ。
特に、webの世界はまだ単価が低く、紙の方がギャラが高いというのが現状。なので、割のいい仕事をしたいなら、やはりwebを出ないといけないんですよね。
また、手を動かす仕事から離れる話でも、最近思うところがあるんです。先日、界隈の人と話した時に「目立ってる人より、影に隠れている人の方が稼げてる」なんて話を聞いたんですよね。
これって、ライターの世界にも当てはまっていて、注目を浴びているライターよりも、その人に仕事を振る人、編集をする人の方が効率的に稼げてるなんてことがあるんですよ。
単価の話関係ないじゃん！！
なので、この記事を読んで、その重要性に気づいたエンジニア、デザイナー、ライターなどの専門職の方は、ぜひ将来のキャリアについて考えてみてください。
その重要性ってなに？
フルスタックになること？ 情報処理の資格をとること？ 管理職を目指すってこと？
それとも、Webをでること？
締めで使う「その」という指示語の範囲が広すぎる。記事の内容をまとめた後に使ってください。
それと、年収をあげるのは、別にプログラマのままでもできるんじゃない？
そこそこ給料はよくなりそうだが？？（そんな職種があるかは知らんが）
（提供：らふらく（@TwinTKchan））
お前が聞いてきたはなしじゃねえのかよーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー。
89世代の意識高い「系」だったら、平成生まれの視点での言葉を言ってほしいわ。
この増田を読んで、煽りの重要性に気づいたブロガーは意味のある煽りについて考えてみてください。
エロサイトか。
