エンジニア転職のリアル
ツイッターで「ソフトウェアエンジニアとしてキャリアを歩むなら、SIer はおすすめできない」と発言している方に対して、現役 SIer 社員が反論していて、ちょっとした騒ぎになっていた。 10 年間 SIer で働いた経験がある人間として、SIer で「ソフトウェアエンジニア」のキャリアを積めるかどうかについて見解を示したい。 頼むからプログラミング好きな高学歴の人は下手なネームバリューを気にしてSIerに行かないでくれ。まずSIerの研修が簡単すぎてつまらんと思うし、自分の方がプログラミングや技術分かるのに年収同じなのかって絶望するわけで。ほぼ転職する未来が待ってるんだから、最初から候補にも入れない方が良い。 — サカモト@エンジニアキャリア論 (@sakamoto_582) December 15, 2022 やはり何故かSIer叩きをしていると勘違いしてる人が大勢いるけど “SIerに
アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く（前編）。Agile Japan 2021
アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く（前編）。Agile Japan 2021 アジャイル開発において開発担当者を外部のベンダに依頼した場合、必然的に発注側の企業とベンダ側の開発者が1つのチームとなり密なコミュニケーションを行います。 すると、発注側の企業がベンダの開発者の業務遂行に対して具体的な指示を行う、いわゆる「偽装請負」とみなされる可能性があるのではないか？ という疑義が以前から呈されていました。 この疑義に対して、どのように対処すれば偽装請負と見なされないか、その指針が今年9月に厚生労働省から「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）関係疑義応答集」として公表されています。 オンラインで11月8日に開催されたイベント「Agile Japan 2021 Day 0」では、この疑義応
優秀さについて
Twitter で医師を拾ってきて Google のソフトウェアエンジニアにするだけの簡単なお仕事 - 白のカピバラの逆極限 S.144-3 はじめに 「【転職エントリ】Googleに入社します｜Lillian｜note」という、医師から未経験で Google のソフトウェアエンジニアになった記事があります。 note.com 私は、この記事に出てくる「とある元 Google のソフトウェアエンジニア」で、面接の対策を立てました。 記事が出た当初から大反響で、私もそれなりの反応を見まして、いろいろと誤解されているなあ、と思う一方、アドバイザーはあくまでもアドバイザーだから、アドバイザーとして知りえた情報については、口をつぐむべきだと思っていました。 ただ、あまりにも誤解されており、悪影響が大きく、犠牲者も多くなってきたと思ったので、… 同僚からこれについてどう思うか、と聞かれた。元の文章が
5年いた富士通を退職した理由
5年エンジニアとして務めた富士通を一昨年退職した。そろそろほとぼりも冷めたと思うので、書く。 真面目に書いている増田もいるが、僕は自分の半径5m以内で起こった幼稚な理由にフォーカスを当てる。 開発環境がだめまずこれがトップにくる。 本当にだめだった。多分開発させる気なんてなかったんだろうなあ。ニートでももうちょっといい環境を使っていると思う。 メモリ4GBのセレロン使ってた。もちろんSSDじゃなくてHDD。PCは富士通製のミドルクラスのノートPCしか支給されなかった。 Macなんか認めん！iOSアプリも富士通PCで作れ！（本当にあった話）。 机上環境もだめいろんな環境にいたが、その中でもひどかったのは、もともと生産ラインがあった場所に机を置いて事務所として使っていた場所だ。机もせまかったし、気温も暑いか寒いかのどちらかだった。 そこに協力会社を大量に押し込んで、ソフトウェアの生産ラインを作
客先常駐について - 急がば回れ、選ぶなら近道
客先常駐は増加傾向に見える。 別に統計資料はないので、どちらかというと体感的なものだけど、ベンダーからユーザーへの常駐は増加している気がする。これはまぁスタイルはいろいろで、完全に委任契約のものから、継続SIを仕事として請負契約の形になっているが作業的には客先にずっといるというスタイルのものをある。ベンダーの人員というよりも、ベンダーの下請け・孫請けが常駐していることが多い。さらに、多くの場合、戦力になっているのは、フロントの一次受けではなくて、下請け・孫請けの部隊だったりする。そんなこともあるので、地方の中小企業の場合は、さすがにフロントのサヤ抜きが、馬鹿馬鹿しいので、直接に契約に切り替えることも多い。 いずれしても、SIという位置づけのものまで含めると、この種の「派遣の一種」のような常駐モードの人員は相当いて、SEから運用・コンサルまでITに関わる分野では、非常に幅広くかつ大きなビジネ
プロダクトマネージャーに必要な資質って何ですか？ 元グーグルのPM対談 | HRナビ by リクルート
プロダクトマネージャー（PM）ってどんな仕事？ プロジェクトマネージャーと何が違って、普段どんなことを考えながら仕事してるの？——日本でも徐々に認知度が高まってきた「プロダクトマネージャー」にフォーカスし、そんな疑問に答える「Japan Product Manager Conference 2016」が10月24日、25日の2日間にわたって都内で開催された。内外のさまざまな企業で活躍しているPMが壇上に立ち、自らの試行錯誤や経験、時には失敗を踏まえ、PMという仕事の難しさと醍醐味を紹介した。 そのセッションの一つ「グローバル企業におけるプロダクトマネージメント」では、ナイアンティックの河合敬一氏と、カンファレンスの実行委員でIncrementsでQiitaのPMを務める及川卓也氏が登場。「僕がPMとしてグーグルに入ったときの面接を担当したのが及川さん」（河合氏）という関係にある二人が、会場
続・拝啓『変わらない開発現場』を嘆く皆様へ ～ ウォータフォール ＆ アジャイル編～ – とあるコンサルタントのつぶやき
とあるコンサルタントのつぶやき とあるコンサルタントのつぶやき MCS （Microsoft Consulting Services） の某コンサルタントがまったり語るテクノロジのお話です。 ご存知の方も多いと思いますが、ここ最近、うちの会社の歌って踊れる DevOps エバの牛尾さんが、こんなエントリを書かれていました。 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い http://simplearchitect.hatenablog.com/entry/2016/06/20/080807 「自分で人生を決めない」ことが、決定的に業界の進化を遅らせているのかもしれない http://simplearchitect.hatenablog.com/entry/2016/06/24/080049 特に前者は炎上気味でしたが；、二回分のエントリを通して読めば、牛尾さんが言いたい
生涯「エンジニア」として食っていくには何が必要？及川卓也氏×田中邦裕氏の答え - エンジニアtype | 転職type
各所でプログラマー不足が叫ばれる昨今。にもかかわらず、企業で働くエンジニアの中には、勤め先の要請によって「開発業務（コーディング業務）」から身を引かねばならない人も少なくない。なぜ、このような矛盾が生まれるのか。エンジニアが「好きな開発」と「キャリア形成」をうまく両立させる方法はないのか？データ分析と著名人対談を通じて考える。 「約4割のエンジニアが、ある時期を境に開発業務（コーディング業務）から完全に足抜けしなければならないと回答」 「マネジャー以上の年収分布では、技術専門職より一般管理職の方が年収が高い傾向に」 弊誌が今年3月に行った【IT・Webエンジニア300人調査】では、勤務先のキャリアパスについてこのような現実が浮き彫りになった。 >> 「コードで食っていく」は何歳まで可能か？エンジニア300人調査で見えた理想と現実 エンジニアという職業を選んだ以上、何かを作る仕事をし続けたい
ソフトウェア開発の生産性を阻害する「気軽に聞けない」ことの考察と対策 - メソッド屋のブログ
マイクロソフトの DevOps テクニカルエバンジェリストになる前から、ずっと不思議だったことがあります。 それは、「アメリカのエンジニアの生産性の高さ」です。素晴らしいサービスは大抵彼らから生まれていますし、彼らを見ているとアウトカムも生産性も非常に高く感じます。 私は個人的にこの秘密を解く旅の途中にいます。私はインターナショナルチームに所属しているのですが、同僚と一緒に働いたり、ハッカソンをしたりして気づいた１つの仮説について共有したいと思います。 気軽に「聞けないこと」が生産性を阻害しているのでは？ 以前私は「米国のエンジニアはコンピュータサイエンスを専攻している人が多くすごく優秀で、さらに英語が出来るので、技術収集するのも楽だから相当アドバンテージがある」と思っていました。 英語に関してはそうだと思いますが、彼らの個々の人がそんなに優秀かというとそうでもないことに気づきました。それ
アジャイルを無責任に広めるのはもうやめよう
（画像：wikimedia commons） こんな記事を見かけました。 記者の眼 – 「アジャイル嫌い」はもうやめよう：ITpro http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/082400357/?ST=system&P=1 開発の経験が長い人からすると、「あーはいはい」と昏い目をしてしまうような記事なのですが、実際のところアジャイルを宣伝する本やブログなどは多く、「プロジェクトを始めよう！」となったときに、候補に上がることが多い開発手法ではあります。 しかし、現場の現実から言うと、安易にアジャイルを導入して失敗するケースは非常に多いです。 私は20件以上のアジャイルプロジェクトを見てきましたが、そのうちちゃんと成功していたプロジェクトはたったの3件だけです（ウォーターフォールは100件以上見ていますが、成功率はそんなに低くはあり
成長の場を求めないソフトウェアエンジニア？：柴田 芳樹 (Yoshiki Shibata)：So-netブログ
「ソフトウェア開発組織が持つべきカルチャー」と題して、過去に以下の記事を書いています。 継続した学習習慣 コンピュータの基礎を教える 共に学ぶ マネージャが勉強会を主催する プロセス中心ではなく、スキル中心 スキル向上に真剣に長期的に取り組む カンファレンスへ積極的に参加させる コードをレビューする Source Code Controlへ最低でも毎日コミットする ビッグバン・インテグレーションを避ける テストを自動化する ソースコードを調べる 自分で書いたコードを自分で見直す 知識教育だけではなく、良い行動パターンを促進する また、「コードレビューの視点」として、以下の記事を書いていいます。 Copyrightを書く 必要なエラー情報を付加する マルチスレッドプログラミングに注意する 言語仕様を確認する 独り言コメントは書かない 説明とコードが違っていないか注意する 知識の伝達の場 エン
ソフトウェアエンジニアの成長カーブ（再掲載）：柴田 芳樹 (Yoshiki Shibata)：So-netブログ
「ソフトウェアエンジニアの成長カーブ」 最近良く話していることなのですが、社会人として働き始めた新卒の技術者は、最初の数年は成長していきます。与えられた業務を遂行しながら、そのための学習もしていくからです。しかし、2、3年すると開発業務をこなせるようになり、特に新たな勉強をしなくても、日々、会社に行って開発業務が遂行できるようになります。 この状態、つまり、継続した学習をしなくなった状態で、10年とか経過すると、ソフトウェアの世界は大きく変化している可能性があり、新たな技術が登場し、その人の技量は相対的に今度は低下しはじめます。しかし、この時点で、新たなことを学習するのは困難だったりします。学習する習慣が無いわけですから、勉強しろと言っても、「なぜ、休みの日に勉強しなければならないのですか」ということになります。 そのような人に対して、マネジメントは、その人ができる仕事を与えて、何とか仕事
弊社エンジニア職の求人に、日本から一向に応募が無い件 - Tous Les Jours 攻防記
先日、弊社CareerLink Vietnamにて、エンジニア職の新規求人を始めました。勤務地はベトナム・ホーチミン市。 東南アジア各国を飛び回るウェブ系エンジニアWanted!! [5/9 03:10 追記] WantedlyのURLが古く応募ができなかったようです。新URLに置き換えました。 日本人にターゲットを絞り、満を持してWantedlyに掲載したのだけれど、応募がない。 個人的には、南国ベトナムで開発に従事するというのは、なかなか魅力的な労働環境だと思うのだけれど、どういうわけか、日本から一向に応募がない。 なぜ応募が振るわないのか、理由を考えてみたが、労働環境に魅力が無いわけではないと思う。ただ、いきなり東南アジア勤務というのが若干ハードルが高く感じられるのかもしれない。 そこで、気を取り直して、現地ベトナムの雰囲気が伝わるよう、採用に関する補足事項等を、本エントリにまとめて
銀行SEの現在 - novtan別館
もう2007年といえば5年前のことになってしまう。時のたつのは早いものです。 当時の増田のエントリが何故か今頃盛り上がっていて、その結果それに言及した僕のエントリも盛り上がっているようなのですが、5年前の状況というのはさすがに古かろう、ということでちょっとアップデートしてみたいと思います。 参考： IT業界で無事にいたいなら銀行に関わるな 銀行SE…かわいそうです… - novtan別館 ここ最近の銀行システムの大きなトピックというのは三菱統合UFJ銀行のDAY2（システム完全統合）と、みずほ銀行の3.11後の大障害とそれに伴う銀行の統合・システム刷新でしょう。 特に後者は銀行システムの停止が社会に与える影響が如何に大きいものかということを体現してくれました。 なんどかリークもされているからここだけの話をすると、みずほ銀行はいわゆる第三次オンラインをちゃんとやらなかった建て増しシステムであ
ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
開発手法とコミュ力は捨てろ――SIエンジニアに告げる、Web企業への転職戦略
開発手法とコミュ力は捨てろ――SIエンジニアに告げる、Web企業への転職戦略：きのこる先生のエンジニア転職指南（6）（1/2 ページ） 元プログラマ、現Web系企業の人事担当者による、エンジニア転職指南。「応募書類の書き方」や「自己PRの仕方」について、エンジニアの視点を持ちながらアドバイス。エンジニアの幸せな転職のために、菌類が奮闘する。 皆さん、こんにちは。2011年も残すところあとわずか。忙しい日々をお過ごしでしょうか。 師走ということで、師に負けず菌類も走り回っています。新卒採用のエントリが始まり、やるべきことは増えるばかり。冬眠したい気持ちをぐっとこらえてフル稼働中です。 繰り返す、ここはSIerではない さて今回は、かつて私が所属していた「システム・インテグレータ（SIer）」、そしていま所属している「Web系企業」についてお話します。 SIerは、長引く不況とIT業界の構造変
プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指して
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してのコメントで 熟練者も居ることは理解しているが、開発をする上で熟練者ばかりを集めることはできない。このため初心者側にレベルを合わせざるを得ない。 というコメントをいただきましたけれど、これは実に典型的なSIer（の上司）の考え方ですね。SIerの仮説と呼んでもよいくらいですね。とにかく、この仮説の前提となっているのは プログラマーのスキルレベルは一定で成長しない プログラマーは容易に交換可能なリソースである プログラマーは単純労働者である というモデルです。とにかく、この仮説がはびこっているから、いまだにSIerのフレームワークは「初心者側にレベルを合わせざるを得ない」という思い込みで作られていることが多いのでしょう。 COBOL（の初期の）時代ならまだしも、少なくとも現在の開発環境にお
プログラマーの誇りを見せ付けろ - レベルエンター山本大のブログ
僕は今回の案件で、システムのレスポンスに徹底的にこだわってる。 それには理由がある。 それは、プログラマの誇りを見せたいからだ。 この案件は、既存機能をコピーして似た機能を作るというものだ。 既存機能は、Webシステムなのに1アクションで 1分や2分以上のレスポンスタイムはザラで、 悪いときには数分後にタイムアウトして、 さらに悪いときには、アプリケーション全体をロックしてしまっていた。 顧客はそれでも我慢して使っていてくれたそうだ。 今回の改修に際して、顧客がパフォーマンスを要求するのは当然だった。 それにしても酷いアリサマだとコードを見てみると 酷い。 確かにパフォーマンスは出ないのも無理はない。 いや、それどころか僕は、このSI業界の問題を感じざるを得なかった。 この機能はそこそこ難しく、業務的にも重要だ。 しかし、そのコードは、新人〜3年目ぐらいのプログラマが書いたとしか思えないコ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
（採用担当者向け）エンジニア採用をする上での基礎知識 / recruting_engineer_basic
ふつうの受託開発チームのつくりかた