タグ

workとengineerに関するmuddydixonのブックマーク (25)

  • 登大遊、落合陽一を生んだ、未踏の父・竹内郁雄に聞く「優れたエンジニア」に必要なこと - エンジニアtype | 転職type

    NEW! 2024.04.12 スキル 未踏落合陽一登大遊プログラマー 登大遊、落合陽一など数々のスーパークリエータを輩出してきた、独立行政法人情報処理推進機構(IPA)の「未踏IT人材発掘・育成事業」(以下、未踏IT)。その立ち上げから現在までを知るのが、統括プロジェクトマネージャーの竹内郁雄さんだ。 2017年には、ビジネスや社会課題解決につながる人材を発掘する「未踏アドバンスト事業」にも統括プロジェクトマネージャーとして参画。国際的なデファクトスタンダードとなるソフトウェアを日から生み出すべく、人材育成に心血を注いでいる。 前身の未踏ソフトウェア創造事業から数えて24年。のべ2000人を超える修了生を見てきた竹内さんだから言える、優れたエンジニアに共通して求められる素養を聞いた。 未踏事業統括プロジェクトマネージャー(PM) 一般社団法人未踏 代表理事 竹内郁雄さん 1946年、富

    登大遊、落合陽一を生んだ、未踏の父・竹内郁雄に聞く「優れたエンジニア」に必要なこと - エンジニアtype | 転職type
  • スティーブ・ジョブズが考える「最高の管理職」とは

    Sawdah Bhaimiya [原文] (翻訳:仲田文子、編集:井上俊彦) Mar. 07, 2024, 09:00 AM 働き方 51,513 スティーブ・ジョブズは、かつてアップルで雇ったマネージャーは「愚か」だったと語った。 Justin Sullivan/Getty Images スティーブ・ジョブズは1985年のインタビューで、最高のマネージャーの雇い方についてアドバイスした。 彼によると、最高のマネージャーとは管理することを望んでいるわけではない「偉大な個人的貢献者だ」だという。 伝説的な共同創業者であるジョブズは2011年に亡くなった。存命であれば2月24日に69歳を迎えるはずだった。 アップル(Apple)の伝説的な共同創業者であるスティーブ・ジョブズ(Steve Jobs)はかつて、最高のマネージャーについてアドバイスしたことがある。それは、実際にはマネージャーになりた

    スティーブ・ジョブズが考える「最高の管理職」とは
  • 開発マシンの人権スペックについては俺にも語らせろ | anopara

    Twitterで開発マシンの「最低限の人権」とされるスペックについての話題が広がっています。 発端はこれです。 対GAFAで研究者の処遇改善 NTT、流出に危機感 NTTでは優秀な人材はGAFAGoogle, Apple, Facebook, Amazon)に引き抜かれるので処遇を改善しよう(具体的には給料をあげよう)という話です。 そこで、「いや、給料だけの問題じゃない。意思決定が遅い組織的な問題やITエンジニア仕事そのものへの無理解に起因する開発環境のチープさに嫌気が差して止めていくエンジニアは多い」という話がぶり返されます。この問題はITエンジニア業を営む人にとっては当によく見る問題であります。 そんな中、ネットで有名なエンジニアの一人がタイムリーにNTT(研究所)を退社しGoogleに入るというエントリを書きました。 6年勤めたNTT退職しました これでこの開発環境周りの論

    開発マシンの人権スペックについては俺にも語らせろ | anopara
    muddydixon
    muddydixon 2018/12/01
    なんというか深み・・・
  • エンジニアチーム全員がフルリモートで働く際に役立つ便利ツールと組織のルール | 働き方・カルチャー

    こんにちは、株式会社キャスターでCTOを担当しています、福田です。 株式会社キャスターはオンライン秘書サービスを主な事業として展開しており、100名以上の従業員全員がフルリモートで働いています。 エンジニアチームもその例外ではなく、当然全員がリモートワーカーで、各自が自分の好きな場所に住み、集中できる環境でコーディングに勤しみ、必要に応じてオンラインで活発に議論しながらモノづくりをしています。 このブログで伝えたいことそんな我々エンジニアチームは、自分たちにとって働きやすい環境は何かを追求するため、日々新しい取り組みを実験として試しながら、リモートエンジニアリングに最適なツールやルール作りに取り組んでいます。 今回のこのブログでは、そんな我々が、日々愛用しているツールや、リモートワークをする上で気をつけていることや組織のルールの一部をここで紹介させていただこうと思っています。 この記事を読

    エンジニアチーム全員がフルリモートで働く際に役立つ便利ツールと組織のルール | 働き方・カルチャー
  • エンジニアのベンチャー企業の選び方/働き方/やめ方 - mizchi's blog

    この記事は退職者アドベントカレンダーの12日目です。 adventar.org 経歴としては、新卒で設立してすぐのゲーム会社 => 小規模教育系ベンチャー => Incements(Qiita) => フリーランス。 今年で29歳、20代で3回退職しました。20代のうちは冒険してベンチャー企業で働いてみよう、と思ってたのですが、結局29を目前にフリーランスになってしまいました。 ベンチャーで働くこと ベンチャーで働くのはリスクを取るということ。一番言いたいのは、ストックオプションもたずにベンチャーやるな、ストックオプションも確実に換金できるわけじゃない、ということ。上場するときに行使するか、バイアウト時に買い取ってもらわないといけません。 また、ストックオプションの期待だけ給与は下がるので、他の会社で同じことをやるのに比べて、 -100~-150万ぐらいの相場です。少数精鋭志向で最初からじ

    エンジニアのベンチャー企業の選び方/働き方/やめ方 - mizchi's blog
  • 第8回 教育におけるエンジニア出身社長の得手不得手 | gihyo.jp

    今回は前回の続きで、教育について、エンジニア出身社長の得手不得手を考えてみます。 技術を教えるのが得意でも、自分の今の技術力を見誤ると迷惑になってしまう まず技術力ですが、これは正直ピンキリでしょう。技術力の高い社長、低い社長、教えるのが得意な社長、不得手な社長などさまざまです。ただ、技術力の高低はあっても、教えるのが不得手な社長というのはあまりいないような気もします。技術力が高くても、インフラとプログラミングなどジャンルが違うとハードルが上がりますが、エンジニア出身であれば、技術力そのものの教育に向いている可能性は、エンジニア以外の職種出身の社長よりは断然有利なのはまちがいありません。ほかの職種に比べて、傾向としては一番アドバンテージがある部分の1つだといえるでしょう。 だからといって、謙虚さを失うとけっこう厄介なのも事実なので、そこは気をつける必要があります。「⁠自身の技術は今でも通用

    第8回 教育におけるエンジニア出身社長の得手不得手 | gihyo.jp
  • フリーエンジニアのIT案件ならレバテックフリーランス

    毎年11月に開催されるスタートアップ企業の祭典「TechCrunch Tokyo」では、数々のトークセッションや話題のVRに関する展示のほか、技術によるビジネス貢献度が最も高い企業のCTOを選出する表彰イベント「CTO・オブ・ザ・イヤー」を行っています。2016年度に同賞を受賞したのが、モバイルアプリ向けマーケティングツールを開発・運営するRepro株式会社のCTO・橋立友宏氏です。 新卒では大手SIerに入社し、その後小規模な受託会社の正社員を経て、フリーランスとして参画したReproでCTOに就任するという変わった経歴を持つ橋立氏。これまでの経歴やRubyプログラマーとして活動してきた経験から考えるRubyの強み、プログラマーに求めるマインドなど幅広くお話を伺いました。 <この記事の要約> 1.新卒で入社した大手SIerは、プログラマーとして成長できないと感じ転職した。 2.“フリーラ

    フリーエンジニアのIT案件ならレバテックフリーランス
  • long_time_work_cannot_finish_tasks

    先日、会社のチームリーダーと面談を行った。 リーダーから「この会社で働いていて楽しい? 困ったことはない?」と尋ねられ、 僕は即座に「すごく楽しいですよ。日で働いていた会社とは大違いです」と答えた。 「日では毎日2時間から3時間残業するのが当たり前でした。 ときには週末を潰したり、徹夜でバグ修正を行ったりすることもありました。 それに比べてこの会社では残業が全然ないし、毎日適度な作業量を与えられて集中して仕事ができるから最高ですよ」 彼女はこれを聞いて、驚いたような呆れたような表情を見せこう語った。 「その日の会社、マネジメントがひどい。 いくら長時間仕事をしたところで仕事が終わるなんてありえないのに」 いくら働いても問題は無くならない 「それは生産性が落ちるからってことですか?」と尋ねる僕に、彼女はこう続けた。 「例えば、いま未解決のバグが10個ある。 すべて直すのに80時間かかる

    long_time_work_cannot_finish_tasks
    muddydixon
    muddydixon 2016/08/16
    マジそうだと思うし、残業して業務量が増えてるのは当たり前だし、その結果が増えるのも当たり前だけど、それがいいのかどうかはヒトによるし、全般に当てはめるのはどうかと思う。
  • 7年働いた時点での私の仕事の極意 - Kengo's blog

    最重要 実行に重きを置く やらないで後悔するよりも、やって反省する。 反省は成長を産み生産的だが、後悔は精神の無駄な消費。 時間は有限で貴重な資源だが、たぶん今の段階では行動する前に得るものや結果を予測するのは難しい。 正しい反省の方法とは何か、考え続けること。 「正しく反省するために、何を記録しておくべきか」実行前に明らかにしておくこと。 反省の結果は組織的な何かに落としこむ。組織構造、戦略、静的解析、自動テスト、教育など。意識しないでも巨人の肩に乗れる状況を作ることが、組織の成長につながる。 Done is Better Than Perfect ただし、思考停止の言い訳にしないこと。詰めの甘さを擁護する言葉ではない。詰めの甘さは立場や考え方が違うひと3人くらいに意見を求めればだいたい炙り出せる。 長期的視野を持ちつつ、それに引っ張られない。進展を作ること、現状を少しずつ変えることを意

    7年働いた時点での私の仕事の極意 - Kengo's blog
  • エンジニア専門職のグレードについて詳細な役割定義は必要か? - Kentaro Kuribayashi's blog

    様々な人々から、エンジニアに関する制度についてインタビューされる機会が増えてきた。その中で考えが整理されてきたパーツもあるので、せっかくなのでまとめておこうと思う。 ペバボのエンジニア職位制度のアップデートについてなどで書いている通り、ペパボはエンジニア専門職制度を制定し運用している。その前提として、専門職制度がどのような位置付けかというと、簡単に示すと以下の図の通りである。 この構造自体は特になんの変哲もない、わりと一般的な制度だといえるが、我々はこの中にひとひねり加えている。以下に説明する。 前提知識 ただし、その前に人事制度における前提的知識について述べておかないとならない。 社員格付け 昨今は「フラットな組織」「ネットワーク型組織」などというものも出てきているが、それはそれとして、一般に企業組織は、その構成員をなんらかの方法を用いて格付けしている。すぐに思い浮かぶのは、部長とか係長

    エンジニア専門職のグレードについて詳細な役割定義は必要か? - Kentaro Kuribayashi's blog
  • サービス開発エンジニアからマネージャになった話 - クックパッド開発者ブログ

    はじめに こんにちは、レシピ投稿推進室の勝間(@ryo_katsuma)です。 techlifeでの執筆は5年ぶり(!)になります。 さて、そんな私も今年2014年の5月にエンジニアからサービス開発の部署のマネージャに転身しました。 そこで今回のtechlifeブログは、いつもの技術ネタとは少し異なるテーマとして、「クックパッドにおいて、エンジニアからマネージャに転身する」ことが、どういうことなのかを自分自身で振り返り、まとめたいと思います。 エンジニアが自身のキャリアを考える上で、少しでも参考になれば幸いです。 現状 私は、2009年5月に中途入社し、今年で6年目になります。この年数は、エンジニア全体はもちろん、社内全体で見ても古い方になります。 これまで、技術部、HappyAuthor部(現在、私が所属している前身になった部)、新規事業部、プレミアム会員事業部...など、いろんな部署で

    サービス開発エンジニアからマネージャになった話 - クックパッド開発者ブログ
  • ペバボのエンジニア職位制度のアップデートについて - Kentaro Kuribayashi's blog

    ペパボで行っているエンジニア職位制度について、最新情報を共有します。 エントリの背景 ペパボで行っているエンジニア職位制度(シニアエンジニア、アドバンスドシニアエンジニアの選考)については、制度の運用当初に、当時の責任者であるmizzyさんがPaperboy's engineer evaluation system - Gosuke Miyashitaというエントリで紹介しています。その頃から2年半ほどが経過し、また、責任者が変わったこともあるので、あらためていまはどういう感じなのかお知らせしたいと思います。ちなみに、一般のエンジニア評価制度については、新たに運用開始した内容を、既にペパボのエンジニア評価制度をパワーアップしたでお知らせしています。 エントリの目的 そのような、いってみれば内輪の話の共有を、ある意味わざわざ行う目的は、エンジニアとしての将来をあれこれと検討している社外の

    ペバボのエンジニア職位制度のアップデートについて - Kentaro Kuribayashi's blog
  • ペパボのエンジニア評価制度をパワーアップした - Kentaro Kuribayashi's blog

    mizzyさんのエントリ(paperboy is hiring - Gosuke Miyashita)にある通り、ペパボでは、エンジニアに関しては一般のラインとは別に、専門職としてのキャリアアップをしていくラインがあって、ここ2年ほど運用され、よく機能しているところです。そんな折、技術基盤チームも陣容が充実し、社内にもその存在や成果が充分に浸透してきただろうというわけで、半年ほど前からあたためてきた新しい制度を、先日から運用開始しました。 今回の制度は、上述の専門職としての評価制度はそのままに、既存の半期ごとの目標設定 → 評価サイクルの中に、エンジニア的観点をより盛り込んでいこうというものです。エンジニアであろうがなかろうが、一般に、事業目標をブレークダウンしたものが個々人の目標 → 成果になっていくわけですが、そうしたプロセスにおいて、より多様な観点からアウトプットの生産性を向上させて

    ペパボのエンジニア評価制度をパワーアップした - Kentaro Kuribayashi's blog
  • 技術の進歩は「螺旋」である。 @ t_wada さん社内講演 - >& STDOUT

    先週、新卒技術研修の一環として @t_wadaさん にご講演を頂きました。 題して「この先生きのこるためには」*1。 第一線のエンジニアとして素晴らしい薫陶の数々を授けて下さいましたので、渋谷や六木の会社さんもオファーしてみたほうがいいですよ。ホント。 エンジニアはアーティストとしての側面も持つので、ファーストクラスの方の考え方に早いうちから触れておくことは、数年先の彼らの在り方に少なからず良い影響を与えるはずだ、という考え*2に基づくおふたりめの社外講師です。おひとりめは当時非公開でしたが、時効になってましたら教えてください。 新卒研修とはいうものの、社のカフェテリアを全開放した形で既存社員にも受講してもらいました。正直、私も含めた既存社員のほうがよっぽど直接の教育効果は高かったんじゃないかと思いましたが、それはそれとして。ご講演の中でのいくつかの気づきを共有します。 技術の進歩は「

    技術の進歩は「螺旋」である。 @ t_wada さん社内講演 - >& STDOUT
  • ウェブエンジニアの生存戦略 - mizchi's blog

    最近、この話題について経営者目線の話が多かったので、エンジニアのスキル獲得戦略とその最大化という観点から話をする。 まず目下のウェブエンジニアとして一番の課題は、「35歳定年説をどう乗り切るか」、ということだろう。もちろん、みんな35歳定年説なんてのが、まやかしであるとはわかっている。若い業界だったウェブ業界も成立してからだいぶ経ち、結果として平均年齢が押し上げられ、自然と35歳以上のエンジニアも増えてきた。 問題は、人月という概念によって、できる人間とそうでない人間の区別がされていないことだ。ウェブエンジニアとしての悲哀や業界の歪みはここにあると思う。下手に謙遜したりして話をややこしくする前に言ってしまうと、自分をできる側の人間として話をする。 生産性を測る確固としたメトリクスがないのも事実だと思うが、すくなくとも熟達した人間と未経験者がおなじ1人月というのは、到底ありえない話だと思う。

    ウェブエンジニアの生存戦略 - mizchi's blog
  • ベンチャーで働くエンジニアに必要な「勇気」 | Nekoya press

    「恐怖」を知ること 35歳が目前に迫りつつある中、ぼちぼちスピリチュアルなことも書いていこうかと思う今日この頃です。 これまで十数年、小さな会社やフリーランス、大企業(はすぐ辞めたけど)を渡り歩いてきて改めてベンチャーの面白さを実感しています。 様々な要素がありますが、その最たる物は「エンジニアが会社の命運を握っている」という紛れもない事実です。自社でプロダクトを開発しているベンチャーにおいて、どんなに立派な経営理念やビジネスモデルも動かないシステムの前ではクソの役にも立ちません。 そして、それはそのままエンジニアの過ちが会社を危機に陥れるリスクを意味します。言ってしまえば「ワンクリックデプロイ」が「ワンクリック倒産」へと直結するかもしれないのです。省力化そのものは目指すべきですが、自分の行為が内包するリスクは忘れてはならないのです。 「何か」が起きてしまった時に上長の責任だ、確認ミスだと

    muddydixon
    muddydixon 2013/04/12
    「いくら強くてもこいつら屍生人は『テスト』を書かん! ノミと同類よォーッ!」 Luck そして Pluck
  • 新人がコラム始めました。:文系新人SEの思っちゃったんだからしょうがない:エンジニアライフ

    はじめまして。 今春、大学を卒業してSEとして働き出しました後輩と申します。 1年ぐらい前から他の方のコラムを読ませていただいておりましたが、最近「自分も書きたい」という衝動が抑えられなくなりました(笑)。ですので、まだ社会人になって8カ月(そのうち半分以上は研修)のひよっこSEですが、コラムニスト登録させていただきました。もしよろしければ、当コラムを読んでくださった業界の先輩方にアドバイス、ご指摘などをいただけたら幸いです。 では、まず自己紹介がてら「なぜ文系の自分がSEになったか?」を書きたいと思います。 結論からいうと「絶対にSEになりたかった」という訳じゃありません(笑)。文系でプログラミングなんてやったことなかった自分は、SEなんてどんな仕事かわかりませんでした(今でも研修以外でPGやったことないですし、ソースコードを見るのが大変です😅)。 ですので、就活当初はメーカーや金融な

    新人がコラム始めました。:文系新人SEの思っちゃったんだからしょうがない:エンジニアライフ
    muddydixon
    muddydixon 2013/03/22
    こいつ・・・やばい・・・「ということは、年をとるごとに給料が上がります。年功序列です。こういう業界・会社で働きたいと思ってしました。」
  • なぜエンジニアは勉強会で会社名を出せないのか:雲(クラウド)の隙間から青空が見えた:エンジニアライフ

    ■勉強会で自社名を隠す人々 今年の2月に転職して以降、勉強会やカンファレンスでの発表資料に僕は会社名を書くようになった。 2010年9月にコミュニティで初めてのライトニングトークをして以降、今年の2月に転職するまで、僕は合計9回、ライトニングトークや、セッションで登壇している。そしてそのいずれも、会社名はあえて伏せていた。 そういった場面で名刺交換をする機会はあっても、僕は個人で作成した名刺を使い、会社の名刺を出すこともしていない。その当時、僕がなんという会社に勤務しているのか、おそらくほとんどの人は知らなかったはずだ。 転職以降も、こういった活動は続けているが、今は自己紹介で、どこの会社で、どういった仕事をしているか名乗るようになった。名刺交換でも、会社の名刺を出している。 勉強会やカンファレンスに行くと、様々な人と出会う。登壇者と仲良くなることもある。そういった人たちと話をしていると、

    なぜエンジニアは勉強会で会社名を出せないのか:雲(クラウド)の隙間から青空が見えた:エンジニアライフ
  • 業務系SEの末路的なお話でして

    Statistics Favorites 4 Downloads 0 Comments 0 Embed Views 0 Views on SlideShare 0 Total Views 0 業務系SEの末路的なお話でして — Presentation Transcript 業務系SEの今後について 消費税増税と年金問題が与える影響 2012// 株式会社ノーチラス・テクノロジーズ http://www.nautilus-technologies.com/ mailto:contact@nautilus-technologies.com Tel: 03-6712-0636 Fax: 03-6712-0664 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved.NAUTILUS Proprietary &

  • 良いエンジニアの育て方 - ひがやすを技術ブログ

    人を育てるというのは、とても難しい。 なぜなら、育てる方も未完成な人間だから。 ちょっと経験値のある未完成な人が、経験値の少ない未完成な人と、ともに冒険をし、ともにレベルをあげていくことが、人を育てるってことだと思う。 人を育てようと思うと、どうしても上から目線になってしまう。上から目線だと気持ちも相手に伝わりにくい。気持ちが伝わらないと相手もうまく成長してくれない。 だから、人を育てる機会があったら、ともに冒険をする仲間を持ったと考えよう。きっとその方がうまくいく。 それでは、自分の話をしよう。自分というよりは自分たちの話かな。 2010年、自分は、昼間、ブラ三をやりながら、新規ビジネスの企画を考えたり、プロトタイプを作っていたりしていた。ブラ三をやっていたのは、当然ソーシャルアプリというものを学ぶためだ。ブラ三の能力はかなり向上したけど、仕事ではたいした結果が出せなかった。特に企画考え

    良いエンジニアの育て方 - ひがやすを技術ブログ