上司猫「技術を継承してほしいんだ」→ベテラン猫「じゃあマニュアル作成の時間と残業代と若手を...」→「うーん無理...！」からあげのるつぼ @karaage_rutsubo 現場猫コラを2019.8.25から毎日投稿し、2023.10.2に1500日達成しました。いつネタが尽きるかお楽しみに！ 【注意】当アカウントは公式や原作ではなく二次創作です。仕事猫&電話猫のくまみね先生(@kumamine)や仕事猫ガチャのトイズキャビン様(@TOYSCABIN)の方をフォローヨシ！天安門事件 min.togetter.com/XPa5oEt
炎上プロジェクトでスキルを会得する前にお前は死ぬ - GoTheDistance
最短でイッセンマンITエンジニアを目指すなら大炎上プロジェクトがオススメ！！経験浅でも採用の可能性が上がるし、週最大7日間1日15時間以上、プロに揉まれながらスキルを磨けるので面倒な家での積み上げは不要！やり遂げた際の経験値はヤバいし、活躍によってはPMが次のPJに引っ張ってくれるよ！— 代表取締役 岩元仁＠株式会社ロックシステム (@iwa3nen) 2021年8月28日 経験の浅いエンジニアが1千万の年収を得る最短ルートが、炎上案件に飛び込んですげぇ修行して界王拳をマスターしろなのか... 社員にそれを言えるのがすごいな。(いわもと様から社員向けではないとコメントを頂いたので、打ち消します) 炎上プロジェクトで心を病んだ人を多かれ少なかれ見てきて、人づてに色んな哀しみを聞いている身としては、危険としか言いようがない。 僕が若い頃にやった、月稼働400時間が2ヶ月続いたプロジェクトは炎上
マーソ株式会社を退職します - ikasama over technology
6 月 30 日付けで退職、昨日 28 日が最終出社日でした。 2018 年 2 月から、約 1 年半お世話になりました。 マーソ株式会社 is 何 ( 2019 年 6 月末時点の情報です ) www.mrso.jp MRSO という Web サービスを運営している会社です。 MRSO は、人間ドックや検診を全国の医療施設から検索・予約できるポータルサイトです。 登録されている医療施設数は、国内の類似サービスの中ではトップクラスの規模です。 他にもこんな事業をやっています。 MRSO で利用できるギフト券、マーソギフト券の販売 健康をプレゼントするとう考え方 ご両親に人間ドックを受けてほしい！ というユースケースが多いようです 企業向けの健診結果管理システムの開発・運用 ( toB ) 何をしていたのか MRSO の開発・運営に必要なほとんどの領域を担当していました。 具体的には、 新機
値付けできないエンジニアは搾取される｜門屋 亮
もう20年以上前になりますが、わたしの就職して初めての仕事はAccessで動く簡単なプログラムを書くことでした。Accessってもう知らない人もいると思いますが Excel がもうちょっと高機能になったようなものです。わたしはそのプログラムを２週間くらいで書き上げて、上司にこれいくらで売るんですかと尋ねました。上司は100万だと答えました。わたしは素人みたいな新人が作ったプログラムがそんな値段で売れるということにびっくりしましたし、そもそもアクセスで作ったただのファイルを売っていいということも知りませんでした。なんてボロい商売だと思いました。 わたしが当時務めていたのはシステムを開発して納品する会社でした。システムの開発では、作る前にお客様にだいたいいくらかかりますよという見積もりを出します。金額を納得していただけるように、その根拠としてこの機能に何日くらいの作業が必要ですと、細かくタスク
"エンジニアが使うべき便利な windows アプリ一覧" がほしい - うさぎ組
誰かが書き始めると、他の人も書いてくれることを祈ってこのエントリを書いている。できるだけ、組織全体で使うツール（チャットツールとか）は選ばないようにした。 エンジニアが使うべき便利な windows アプリ一覧、みたいなのってどっかにまとめないの?— 徳永広夢 (@tokuhirom) October 2, 2018 RapidEE cmder 7-zip clibor Chrome, Firefox Mate Translate WinMerge そしてこれジオシティーズなので、大丈夫なのかが不安です。 Git Everything Process Explorer などsysinternals系 Crystal Disk Info ここで触れていないけど、実質必須になりそうなもの RapidEE www.rapidee.com Windowsの“環境変数”をGUIで編集できるソフト。各
弊社から社員が退職しました - megamouthの葬列
5月末付で、弊社のエンジニアが退職することになりました。 彼は私がこの会社の社長を勤めて、初めての新卒採用の社員の一人だっただけに、思い入れも強く、彼の人生が輝かしいものになることを祈念せずにはおれません。 弊社は大手企業様との直接取引の案件が多く、業務系システムからWeb系システムまで、幅広く開発業務を行っております。 弊社は、彼のようなスペシャリストの他、営業、マネージャー、PM、PLなど多彩な人材を抱えており、それぞれの文化が異なっているのを面白く見ておりました。 特に、エンジニアの世界では退職した時にブログ・エントリを書く文化があるそうです。 私はエンジニアではなく経営者ですが、退職エントリを書いてみようと思います。 何をやってもらっていたか Web系システムの開発をお任せしていました。 将来的にはフルスタックエンジニアを目指してもらう為、新卒入社時より、Web系システムの制作チー
システムエンジニアと話していて困ったこと
システム開発でエンジニアとのコミュニケーションで困るのは良くある話。 今まで色々な開発に携わってきましたが、社内SEとのコミュニケーションで困ったことと対策を書いてみました。 私自身が現役エンジニアでもありますが、どちらかというとディレクションの方が経験が多いので、両方の目線で考えてみました。 何を言ってるか分からない 「マスターにマージしたらコンフリクトしてデプロイできません」 とか 「オンプレ環境でデータベース構築したのでクラウド環境からリプレイスします」 とか、聞く人が聞いたら 「パルスのファルシのルシがパージでコクーン」と同じレベルですよね。 意味不明すぎて「日本語でOK」って言いたくなりますがそこは我慢です。本人は普段から当たり前に使っている言葉なので、伝わらないことに気付いていないだけなんです。 ただ、これの対策はあんまりなくて、、、 「可能な限り覚える」しかないと思ってます。
良いテックリード、悪いテックリード - 小さなごちそう
本記事は、下記の記事の翻訳です。著者の許可を得て翻訳しました。 この記事はフォースクエアの技術的リーダーシップを簡潔に説明したガイドだ。 ベン・ホロウィッツの「良いプロダクトマージャー、悪いプロダクトマージャー」からインスピレーションを得ている。 チームワーク / Teamwork 良いテックリードはチームの一員として振る舞い、自分の成功とはチームが成功することだと考える。面倒で退屈な仕事の一部を担って障害物を取り除き、チームが100%のパフォーマンスで稼働できるようにする。チームの技術的能力を拡大し、システムの重要な知識が属人化しないように務める。 悪いテックリードは注目の集まる仕事で自分の成果を示すことを好む。その成果は部分最適に留まり、開発チームのアウトプットを増やすにはエンジニアの人数を増やすしかない、という状況から脱することができない。 技術的ビジョン / Technical v
社内横断の技術組織を終わらせました - nottegra’s blog
内容がネガティブに取られそうで、公式なところに書くべきではないので個人ブログで書きます。 この記事は、公式なブログで僕が書いた「社内横断の技術組織をはじめました」という記事へのアンサーブログになります。 ※元の記事は探せば出てきそうだし、個人的なブログと紐付けるべきではないのであえて出しません。 特定の誰かを陥れる目的ではなく、完全に個人の責任として、始めたものを終わらせてしまったことへの事の顛末を記録する目的で書きます。 はじめに 始めた理由 CTOの不在 品質面に対するレビュー不足 技術広報の不足 それぞれの施策の結果 時間がかかってみんなストレスが溜まる新規レビュー 当たり障りの無いことしか表現できない運用レビュー 兼任状態が続き、進まない新規技術検証 やる必要の薄い「全社」広報 終わった理由 成果が出せなくて、そもそも証明出来ないかもしれない 問題解決は組織じゃなくても出来ると気が
「すごいエンジニア」が目指すもの - megamouthの葬列
crapp.hatenablog.com を読んだ。id:Cedilleさんは、数少ない私の同好の士（一緒にされても困るだろうし、文章も怨念も私のレベルを遥かに凌駕していると思うが）だと感じている方で、 いつも楽しく読ませていただいている。 で、このエントリを読んだ感想としては、いい経験だと思うし、別にその中で生きていけばそのうち良い事あるよ、としか思わなかったんだけども、そもそも「すごいエンジニア」とはどういう存在なのか、ということを書いておきたくなったので、書く。 すごいエンジニアのイメージ だいたい前述のエントリに書いてある通りなのだが、この業界で「すごいエンジニア」として見なされる人のイメージを要約すると、こんな感じだと思う。 技術書を自分の給料で買いあさり、勤務時間外に読み漁ったりして、とにかくあらゆる事に詳しい。 アンテナを極バリして、githubでstarが100ぐらいしかつ
私のロールモデル: エンジニア立ち居振舞い番外編 - ローファイ日記
お題「エンジニア立ち居振舞い」 pepabo Advent Calendar 2016 24日目の記事です。 割と飲みの席とか、某ポエムサービスでは語ってはいるんですが、そういえばブログで書いたことがないような気がしたので父の話をします。 実は今年の福岡での新卒研修で同じような話を若者にしていて、でもまあ、あまりに個人の話なのでとスライドも公開していなかったのですが、せっかくなので内容を加えて書き下します。 僕の父は欄間職人をやっていて、6X歳を超えるいまも自営で東三河の片隅に店を持ってやっていってるわけだけど、僕は子どもの頃からそういう背中を見て育ってきたからか、今の自分を振り返ってみると随分自分の仕事ぶりが影響を受けているなと思ったりする。 今日は、6X歳のいまも職人の父を見ていて思ったこと、あるいは直接言われたことなどいくつかをしたためてみる。 生涯、勉強すること これは僕の父の仕事
【境界が無くなる】デザイナーとエンジニアの仕事内容 デザイン会社 ビートラックス: ブログ
アメリカ、特にサンフランシスコ周辺の会社を見てみると、エンジニアに加えてデザイナーの需要が高まっている。これは見た目やUXが優れたプロダクトへの人気が上がっており、企業としてもよりユーザー目線で使いやすくニーズにあった製品を作る為に、企画段階からデザイナーを参加させる事が増えていているからであろう。 それに伴いデザイナーの役割が、これまでの”見た目を美しくする”事から”ユーザー視点で最適な問題解決方法を見つけ出す”へと広がりを見せている。 このビジネスに対するデザインの重要性の高まり-デザインシフト-でデザイナーやエンジニアに求められるその役割と仕事の範囲に変化がおき始めている。恐らく10年程前と比べてみると、それぞれの仕事の範囲が多種多様に広がっているのに加えて、オーバーラップする領域も増えているだろう。 デザインの未来を示す15の変化で下記のような項目があった。 “デザイナーとエンジニ
CodeIQについてのお知らせ
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
焼きそばから逃げずにむしろ突っ込めば焼きそばが逃げる - 山下泰平の趣味の方法
エンジニアの人が祭で屋台焼きそばを作らされそうになったから、仕事を辞めたという話があって、これは妥当な判断だと思う。しかしながら焼きそばを作らされそうになるたびに転職していたら、かなりダルい。だから覚えておいて欲しいんだけど、逃げるから焼きそばが追ってくるわけで、こっちから焼きそばに突っ込んでいったら焼きそばは逃げる。これを焼きそばのパラドックスと言います。 今日の午後、君が偉い人に焼きそばを焼いてくれって言われたら『生麺を蒸して下味を付けなきゃいけないので前日から仕込みが必要ですね』などと返答する。そしたらウヮーこいつ張り切っちゃってるよウゼーって思われる。さらに豚肉に下味付けはじめたり、海老を片栗粉ふりかけて洗ったりしながら『ワイの洗った海老は宝石より輝やくでッ!!』などと絶叫した時点で、誰も君に焼きそばのことを話さなくなると思うんだけど『水の質の悪い中国だからこそ油通しの技法が登場し
エンジニアと仕事するときにデザイナーができること
エンジニアの視点を学ぶデザイナーとエンジニアは仕事の仕方も考え方も異なります。しかし、良い製品をつくるためにはお互いの協力が欠かせません。考え方が違うからといってそのままにしておくと、品質の低下に繋がることがあります。 「デザイナーはユーザー（人）の声や行動に耳を傾けるべき」「彼らのニーズに合わせた提案や設計をすべき」といった論調を見かけることがありますが、これはユーザーだけでなく、一緒に仕事するエンジニアにも適応できます。すぐ側にいるエンジニアを考慮した提案ができないのであれば、ユーザー相手はもっと難しいと思います。 今でも仕事でビジュアルデザインを担当することがありますが、エンジニアと仕事をする際に以下の 6 点に気をつけています。 1. どういうタイプのエンジニアか知るすべてのエンジニアがデザインに興味があるとは限りません。中には仕様を指示してもらえればそれで良いといった方もいます。
キャリアって何だろうね【連載:村上福之】 - エンジニアtype | 転職type
日々流れてゆく膨大な情報量の中からおいしいネタを敏感に察知し、ネット界隈を賑わせてくれるWeb業界の異端児・村上福之氏。同氏独自の経験と価値観から、「キャラ立ちエンジニア」の思考回路を紐解いていく。 株式会社クレイジーワークス 代表取締役 総裁 村上福之（@fukuyuki） ケータイを中心としたソリューションとシステム開発会社を運営。歯に衣着せぬ物言いで、インターネットというバーチャル空間で注目を集める。時々、マジなのかネタなのかが紙一重な発言でネットの住民たちを驚かせてくれるプログラマーだ なんか、新入社員が辞める理由の一番が、「キャリア成長が望めそうにないからだ」だそうだ。自分もそう思って、組込み業界を10年前に足を洗ったので思うことは多い。 >> 平成生まれの退職理由ランキング 「キャリア」とか「成長」って、本当にすごい難しい問題だ。 正直に言おう。「このキャリアがダメっぽい」とい
今まで経験したプロジェクトでありがちな展開と、エンジニアとしてアウトプットしていくパターン - mizchi's blog
なんか最近、(比較的)アウトプットしてないな、とふと気づいたんだけど、よく考えたらプロジェクトの進捗のフェーズによってアウトプットの分量が偏るのはいつものことだなー、とも思った。 それらのフェーズを前期、中期、後期、運営期で考えみる。 初期段階 おそらくライブラリの選定段階から始まる。この時期のアウトプットは、いわゆる「やってみた系」の記事が増える。ウェブに出る記事だと、これが大多数をしめる。汎用性が高く、技術的に挑戦的なものが多い。(立場的な話をするとQiitaはそういう記事がたくさん共有されると助かる) 選定が終わった段階で、アーキテクト的な役割の人は、たぶんこうあるべきだ、みたいな思想を形成する。それをクラス図やコード規約や役割に応じたドメイン特化基底クラスとして表現したりする。DDD的なアレならこれをユビキタス言語の構築としてプロジェクトを通してやるべきなんだろう。 使う予定のフレ
生存戦略としてITエンジニアが35歳までに考えておくべき3つの事 - paiza開発日誌
Photo by Financial Times 今回のpaiza開発日誌は片山がお送りします。 仕事柄色々なITエンジニアの方と話す機会があるのですが、全般的にエンジニアは技術面についての探求は強いけれど、自分のキャリアについての探求はわりとのんびりしている方が多いのだなと思う事が良く有ります。また、そのあたりで働き方の面で少し損しているかも、と感じる事があります。 エンジニアは、どうしたら自分のスキルを生かして自分のやりたい開発を続けることができるのか、夢を叶えられるのか、そのためにはどのようにキャリアに向き合ったらいいのかについてまとめてみました。 ■キャリアは自分で考える時代 少し損をしているなと思った例で言うと、、、 とりあえず開発できればいい⇒常駐や保守メインの仕事 30代半ばで初めての転職、かつSI、組み込み⇒Webなどの業界チェンジ それぞれ結構レベルの高い方です。１のタイ
エンジニアは一生下積み | F's Garage
いくつかの記事に、言語化できない微妙な違和感を抱いていたんだけど、なんとなく理解できたかも。 WEBデザイナーが死ぬ時 – 日めくりブログ ホリエモンが指摘する「下積み原理主義」に大変共感する件 あと、35歳定年説について書いている多くのブログ これらは「エンジニアやデザイナーは一生下積み」という言葉を受容できるかどうかで変わると思う。 「下積み」とは、イケダ氏が書いてるような事務的な単純労働のことを指すのではなく、 「自身の成長に繋がる時間を過ごせるかどうか？！」 で判断する時間のこと。それが伴わないなら下積みとは言わないと思う。 もし、それを下積みと正当化する上司が本当に存在するなら、それは上司の詭弁でしかない。（それが故に、イケダ氏の会社員時代ってそんなに辛かったのかなぁ？！と、ついつい思ってしまう） そして技術について、自分は○○ができれば安泰、もしくは安泰であって欲しい、と思った
ウェブエンジニアの生存戦略 - mizchi's blog
最近、この話題について経営者目線の話が多かったので、エンジニアのスキル獲得戦略とその最大化という観点から話をする。 まず目下のウェブエンジニアとして一番の課題は、「35歳定年説をどう乗り切るか」、ということだろう。もちろん、みんな35歳定年説なんてのが、まやかしであるとはわかっている。若い業界だったウェブ業界も成立してからだいぶ経ち、結果として平均年齢が押し上げられ、自然と35歳以上のエンジニアも増えてきた。 問題は、人月という概念によって、できる人間とそうでない人間の区別がされていないことだ。ウェブエンジニアとしての悲哀や業界の歪みはここにあると思う。下手に謙遜したりして話をややこしくする前に言ってしまうと、自分をできる側の人間として話をする。 生産性を測る確固としたメトリクスがないのも事実だと思うが、すくなくとも熟達した人間と未経験者がおなじ1人月というのは、到底ありえない話だと思う。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
