タグ

エンジニアに関するkootaroのブックマーク (38)

  • 抽象度の高い仕事の進め方 - Konifar's ZATSU

    仕事をしていると、だんだんと抽象度の高いことを任されるようになる。 たとえば、方針も明確な小さな修正タスク => 修正方法がいくつか考えられるタスク => そもそも何をやるかから明確にしないといけないタスク といった感じで次第にふわっとした依頼になってくる。いわゆるグレード制を採用している会社において、"どれだけ抽象度の高い仕事を任せられるか" がグレードの違いの要素のひとつと言ってもいい。 抽象度の高い仕事を安心して任せられる人は何が違うのか自分もよくわからないので、自分のまわりの人がどういう動きをしているかを雑にまとめてみる。 1. なぜやるかを明確にしている わからないときはドキュメントやチャットのやりとりを探し、直接聞いたほうがよい人には自分でコミュニケーションを取っている やる理由がないと判断したら依頼者に話をして、実際にやらないこともある あとで「自分はこう言われただけなので」

    抽象度の高い仕事の進め方 - Konifar's ZATSU
  • 無邪気なエンジニアリングができなくなってきた

    タイトルの通り。好きでやっているエンジニアがだんだん好きではなくなってきたような気がして、改めて何が起きているのか、思考はまとまらないから箇条書きする。 無邪気なエンジニアリングとはコードを読む、書くのIOがとにかくたくさん気になったOSSやサービスはすぐさわる記事や登壇で書く以外のアウトプットもたくさん無邪気なエンジニアリングをして、これになりたかったインターネットで一発当てる著名なOSSのコミッターカンファレンスのプロポーザルをたくさん通すをたくさん書いているたくさん質の良い記事を書いて凄い PV 数なりたかったのその行く末生活を全てエンジニアリングに捧げようとする無理あらゆる技術イベントに顔をだそうとする私生活や仕事でしばしば予定がつかずキャンセル帰りが遅くなるのが良くないので、家から近いイベント以外いかなくなった(規模の比較的おおきい)コミュニティを主催するスポンサー探しで苦労こ

    無邪気なエンジニアリングができなくなってきた
    kootaro
    kootaro 2024/07/05
    とにかくエンジニアリングが好き!って人はあんまり評価されないよね。日本。ビジネスとエンジニアリングを上手くつなげる人が居れば良いのだけれど...
  • とある高専生にソフトウェアエンジニアについて話した - tenntenn.dev

    昨日は1日休みをとって、親戚の高専の情報科に通う学生にソフトウェアエンジニアについて以下のようなことを話をしました。 自分の将来について考える大切さ 情報を得ることの重要性 ソフトウェアエンジニアとはどういう職業か プログラミングの楽しさ 大学への進学について 私が経験したことや知ってることをなるべくバイアスが掛からないように伝えるよう心がけたつもりです。どのくらい上手く伝えられたかは分かりませんが、熱心に聞いてくれました。 当日用いた資料は一部を覗いて一般的な内容なので以下のURLから公開しています。内容で間違ってる部分があったらDMなどで教えていただけると嬉しいです。また、親戚のおじさんから親戚の学生へのアドバイスのための資料だという視点で暖かく見てもらえると助かります。 https://tenn.in/forstudents もし、高校や高専、大学などで似たような話をしてほしいという

    kootaro
    kootaro 2022/03/29
    親身過ぎる。素晴らしい!
  • 及川卓也の『ソフトウェア・ファースト』というアンチパターン|ソフトウェア・ファースト制作委員会

    2019年10月10日に発売した、及川卓也の著書『ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略』。このnoteでは、出版の経緯や書籍づくりの裏話、発刊時に削った原稿の公開など、制作にまつわるさまざまな情報を発信していきます。 こんにちは、及川卓也のマネージャーの酒井と申します。今でこそ多くの方にご愛読いただいている『ソフトウェア・ファースト』ですが、制作中はプロダクト開発におけるアンチパターンをいろいろやってしまいました。この経験は、その後の私たちの仕事で「これ、進研ゼミでやったやつだ!」的な効力を発揮し、立ち止まって考える機会を与えてくれています。どれもあるあるで、皆さまのお仕事を振り返る際にもお役に立てるのではないかと思い、整理してみました。 ここからは、酒井真弓著『ルポ 日DX最前線』(集英社インターナショナル)を再構成してお届けます。 筆者(酒井)は独立を機に

    及川卓也の『ソフトウェア・ファースト』というアンチパターン|ソフトウェア・ファースト制作委員会
    kootaro
    kootaro 2022/02/11
    fukabori.fmでの話は熱かった!
  • Flutterに出会ったことで脳汁プシャーになった話 - GoTheDistance

    Flutterに出会ってしまったせいで、Flutterを中心に生きていこうと考えている私のポエムでございます。 エンジニアとしての頭打ち感 2016年に35で独立した時はエンジニアとして頭打ちを感じていて、エンジニアとして独立することはあまり考えていなかった。初心者ではないけど、上級者になれないなと感じていた。 エンジニアじゃ難しいと考えた時、その隙間を埋める役割はありかなと思った。業務系のシステム導入なら、コンサル〜要件定義の上流工程をやり、開発系なら開発寄りのディレクター。その時々で研修講師。この辺を組み合わせて、今までやってきた。 コードは細々と書いていた。JavaPython、メンテナンスしてるシステム(WPF)やアプリ(iOS / Android)なり、kintoneでjs書いたりWordPressのプラグイン開発みたいなやつをチラホラやってた。小規模な受託なら受けていた。

    Flutterに出会ったことで脳汁プシャーになった話 - GoTheDistance
    kootaro
    kootaro 2021/12/21
    知見の一つとしてブクマ。/いつまでもコード書いて、新しい技術にふれる姿勢は見習うべき。いや、そうでありたいなのかも。。。
  • ネットワークエンジニアとして

    ネットワークエンジニアとしての Network Studyでは、これからネットワーク エンジニアになりたいと考えている方や、CCIEレベルのネットワークエンジニア になりたいと考えている方に役立つよう基礎から上級レベルまでNW技術を解説。 Network Studyの内容は、国家資格であるネットワークスペシャリストの取得や CCNA/CCNP/CCIE取得に役立つ内容に仕上げているだけではなく仕事で役立つ ようにCisco、Juniper、F5の製品にフォーカスして実際の設定コマンドも解説。 今後もネットワークエンジニアの皆さんの役に立てるように、最新の幅広い技術 解説を行っていきます。内容に誤字や記載ミスがあればご指摘頂けると幸いです。 ネットワークエンジニアとは、その将来:ネットワークエンジニアがどのような仕事内容であるのかを紹介、ネットワークエンジニアの将来性について ネットワークエ

  • 日本で働くソフトウェアエンジニアの給与:東京で働く外国人エンジニアによる究極のガイド

    Latest Tech Jobs 🇯🇵Explore the top developer jobs in Japan for foreigners

    日本で働くソフトウェアエンジニアの給与:東京で働く外国人エンジニアによる究極のガイド
    kootaro
    kootaro 2020/03/10
    冒頭読んでおもしろそう、後で読んでみよう。
  • 突然のエンジニアリングマネージャー転身。イチ技術者がGMOペパボ・取締役CTOに就くまでに学んだこと - Findy Engineer Lab

    マネジメント職に就くまで マネジメント職に就いてから 最初に取り組んだマネジメント施策 エンジニア評価制度の制定 全社規模の技術投資計画の策定 計画を実行する組織の新設 「選択」後に感じたギャップ 抽象的な理解のギャップ やりたいこととスキルのギャップ ギャップにどう処したのか マネジメント職の「選択」に必要となるスキルとは おわりに ─ 「やらない」という選択肢はなかった こんにちは、栗林健太郎です。人々からは「あんちぽくん」と呼ばれています。皆様も是非、そのようにお声がけくださると幸いです。 わたくしは現在、GMOペパボ株式会社(以下、GMOペパボ)で取締役CTOを務めています。会社全体としてこれから実現するべきビジョンや方向性を示し、その実行を中心的に担うエンジニアリングおよびデザイン組織を管掌しています。また、セキュリティ事業や鹿児島拠点の立ち上げなど、新しい取り組みを行うチームを

    突然のエンジニアリングマネージャー転身。イチ技術者がGMOペパボ・取締役CTOに就くまでに学んだこと - Findy Engineer Lab
    kootaro
    kootaro 2020/02/22
    参考資料
  • 【Webエンジニアど素人から3年生ぐらいになるまでに読むと良い本】を段階的にまとめた - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? #これってなんなの? 【ど素人状態=社会人になって初めてプログラミングを勉強したぜ!(特に新卒)】〜【Webエンジニアの3年生ぐらい】になるまでに読むと良いまとめです。「どんな目的で学ぶか?」*「いつぐらいまでに読むといいか?」を段階的にまとめました。「これだけ読めばいい!」と、そんな簡単な話ではありませんが、「今いるレベルより少し上の人がどんなジャンルのことを学んでんだろ?」という方の参考になれば嬉しいです。過去の自分に向けてでもあります、自戒。これからWebエンジニアになる人、なって間もない人の参考になれば幸いですm(__)m ※

    【Webエンジニアど素人から3年生ぐらいになるまでに読むと良い本】を段階的にまとめた - Qiita
  • 「成長できる環境に身を置く」ことが本当のスタート。就活に失敗したニートからCTOになったエンジニアの話 - Findy Engineer Lab

    id:Songmuです。現在は、Nature Remoというスマートリモコンや、Nature Remo Eというスマートエネルギーハブなど、電力系のIoT製品を開発しているNature株式会社で取締役CTOを務めています。 サーバーサイドからインフラにかけてのソフトウェアエンジニアリングが得意領域で、ISUCONというコンテストで3回優勝したり、Mackerelというクラウド監視SaaSのプロダクトマネージャーを務めたりもしていました。PerlGoを中心に、多くのツールやライブラリをGitHubに上げています。 今でこそCTOという立場にありますが、私はあまり、他人のお手になるような人生を送ってきていません。「将来こうなりたい」といったしっかりとした長期目標を立てることもなく、その場その場で適当に、時には真面目に生きてきた結果が現在です。うまくいったこととて、多分に生存バイアスがあり、

    「成長できる環境に身を置く」ことが本当のスタート。就活に失敗したニートからCTOになったエンジニアの話 - Findy Engineer Lab
  • エンジニア行動指針を作った話

    株式会社フィードフォース社員がお届けする、フィードフォースにまつわる色々を書いていくアドベントカレンダーです!(੭ु ›ω‹ )੭ु⁾⁾ 遂に5回目。 去年までのカレンダーも是非。 – [2018年](https://adventar.org/calendars/3235) – [2017年](https://adventar.org/calendars/2155…

    エンジニア行動指針を作った話
  • データサイエンス・機械学習をやるためのエンジニアな本まとめ - 2019年版 - Lean Baseball

    ここ1〜2年くらいで、業務やプライベートのデータ分析・データサイエンスで参考にした(と一部じゃないもの)をまとめてみました(注:もちろん全部読んでいます).*1. なお, あくまでワタシ個人(@shinyorke)の見解に基づいた独自解釈であり、所属組織・チームの意向とは関係ありません(とだけ最初に断っておきます). サクッとまとめると 「レベル感(はじめて・経験者)」だけででなく,「エンジニア面を鍛える or 理論を固める」の軸で考えると良い書籍・学び方に出会える確率上がる エンジニアでも理論でもどっちから初めても良い, がどちらかが得意な方が絶対幸せ(≒片方だけじゃお話にならない可能性) 個人的なオススメは「機械学習図鑑」「前処理大全」「機械学習のための特徴量エンジニアリング」そして「試して学ぶ機械学習」です. おしながき サクッとまとめると おしながき 対象読者&執筆者について

    データサイエンス・機械学習をやるためのエンジニアな本まとめ - 2019年版 - Lean Baseball
  • 仕事を任せられるエンジニアになるために意識してほしいこと - 食べチョク開発者ブログ

    皆さんこんにちは。エンジニアの西尾です。 今日は仕事を任せられるようなエンジニアになるために意識してほしいことをまとめましたので、ここに公開いたします。 もともとは社内向けに公開したものです。 この文章は私がビビッドガーデンに入社する前の、前職での経験を踏まえて書いています。 今のべチョクエンジニアが意識できていない、という話ではありませんのでご注意ください。 意識面 作業の見積もりができる 技術力が低い(コーディングができないなど)よりも敬遠されるエンジニアは、作業の見積もりができない方です。 第一線で活躍している方は、作業見積もりが他の方に比べて正確です。 見積もりをするためには、どういう設計をして、どういう機能を作り、どういう影響範囲があるのかを正しく理解する必要があります。 見積もりができないということは、作業内容を正しく理解できていない、技術的な困難性を理解していない、不確定要

    仕事を任せられるエンジニアになるために意識してほしいこと - 食べチョク開発者ブログ
    kootaro
    kootaro 2019/05/03
    良いまとめ。この中から出来る事を少しずつ出来るようになれば良い。見積もりは必要。とりあえず見積もる事である程度精度は出る。そこからずれる時は、なる早に報告出来れば良い。
  • 技術顧問ブームの流れを汲んだエンジニアリングマネージャーブーム、という考察 - @kyanny's blog

    というか、(かなり偏見を含む)空想。 blog.kyanny.me 「技術力が衰えつつあるおじさんエンジニアのキャリアパスをどうするか」という命題に対して業界は「経営がわかるCTO」「技術顧問」などの回答を示してきた しかしCTOも技術顧問も椅子に限りがあるため、業界は新たな受け皿を必要としていた 業界の平均年齢が上がり、他の業種と同様におじさんエンジニアたちは「管理職」になることを受け入れなければならなくなったが、この業界は「マネージャー(管理職) = 悪」という価値観が根強いため、業界人たちの意識変革が必要だった そういうもろもろの問題意識やら個々人の思惑やらが交錯した結果、どこかの誰かが「エンジニアのマネージャーは無能な管理職なんかじゃない!『髪の尖った上司』なんかじゃないんだよ!」といいだし、キャリアに不安を抱えていたおじさんエンジニアたち(と、そんなおじさんの背中をみてぼんやりと

    技術顧問ブームの流れを汲んだエンジニアリングマネージャーブーム、という考察 - @kyanny's blog
  • 全然わからない。俺たちは雰囲気でマネージャーをやっている。 - アルパカログ

    自分は今、コード書かずにマネジメントしかしてなくて、そんなポジションの人にそれほど価値ないでしょ、とか思ってしまうけれど、こういうポジションの人がいないチームの話とか聞くと、やっぱりいたほうがいいんじゃないか、と思うし、ほとぼりが冷めるとまた自分は無価値のように思えてしまう。 こんな心境の吐露を「エンジニアリングマネージャのキャリアについての悩み」で拝見して、私も何か発信しなければと思ったのがこの記事のきっかけである。筆者のdaiksyさんは、 エンジニアマネージャってなんか実績を示しづらいので、世の中の数多のマネージャ職に埋もれて、自分にスポットが当たりづらい、結果、キャリアに不安が拭えない、みたいなとこないです? とも述べていて、これら2つのメッセージに込められた心の葛藤は、全てのエンジニアリングマネージャー(以下EM)が感じていることではないかと私は思う。少なくともEMの一人として私

    全然わからない。俺たちは雰囲気でマネージャーをやっている。 - アルパカログ
  • 2019年版:データサイエンティスト・機械学習エンジニアのスキル要件、そして期待されるバックグラウンドについて - 渋谷駅前で働くデータサイエンティストのブログ

    (Image by Pixabay) この記事は、以前の同様のスキル要件記事のアップデートです。 正直言って内容的には大差ないと思いますが、今回は2つ新たな軸を加えることにしました。一つは「ジュニアレベル(駆け出し)」と「シニアレベル(熟練職人)」とで分けるということ、もう一つは「データ分析以外の業界知識(ドメイン知識)」にも重きを置く、ということです。 というのも、空前の人工知能ブームが予想よりも長く続いていることで、人材マーケットを観察する限りではデータサイエンティスト・機械学習エンジニアとも求人数が高止まりしているように見えるのですが、その結果としてこのブログの過去のスキル要件記事で挙げたような「完成されたデータ分析人材(熟練職人)」に限らず「駆け出し」でも良いからデータ分析人材が欲しいという企業が増えているように感じられるからです。 その一方で、かつては主にwebマーケティング業界

    2019年版:データサイエンティスト・機械学習エンジニアのスキル要件、そして期待されるバックグラウンドについて - 渋谷駅前で働くデータサイエンティストのブログ
  • エンジニアと1on1をするときの事前面談シートテンプレート - $shibayu36->blog;

    はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1Google Docsに追記していってもらっています。1on1Google Docs

    エンジニアと1on1をするときの事前面談シートテンプレート - $shibayu36->blog;
    kootaro
    kootaro 2018/12/17
    じっくりと読んでみよう
  • NTTの株価総額が世界一だった時に、Microsoftに転職した理由

    「6年勤めたNTT退職しました」という記事が、注目を浴びているようですが、この筆者が NTT を辞めた理由が、私が32年前(1986年)に NTT を辞めた理由とあまり変わらないのに、少々驚きました。 私が NTT を辞めた件に関しては、これまで色々なところで話しては来たのですが、まとまって文章にしたことがなかったので、これを機会に書くことにしました。普段ならメルマガ(週刊 Life is beautiful)の読者限定で書くところですが、今回だけは、出来るだけ多くの人に読んで欲しいので、ブログ記事として公開します。 当時、NTTは電電公社から民営化したばかりで、1985年に入社した私は、NTTとしては第1期生でした。大学は、早稲田の理工学部電子通信学科で、修士課程まで行きました(当時は、情報学科はまだ独立しておらず、電子通信学科がソフトウェアとハードウェアの両方をカバーしていました)。

    kootaro
    kootaro 2018/11/27
    凄い!エンジニアの価値を評価出来るからこそ、その後のGAFAのような世界的企業が産まれるのかな?
  • 勉強するとこんな人になりますよ - megamouthの葬列

    axia.co.jp どこかのエントリで呼ばれた気がした。 必要もないのに他人のエントリに乗っかるのは好きではないのだが、たまにはブログっぽいことを書かないと、と思ったので、軽く書く。 ある勉強したプログラマの末路 まず自分の話をしたい。 私は趣味で多数の求人サイトに登録している。 転職エージェントはうるさいので使っていない。 サイトに登録して、経験言語と年数にチェックを入れ、職務経歴書をサニタイズして(なんとこの用語は顧客を特定できないように「無毒化する」という意味で一般的に使われ始めている)掲載しているぐらいである。 ちなみにpaizaでもSランクを持っている。自慢にもならないし、求職活動に役立つわけでもないが、持っている。 こうして、現年収を正直に「200万」と書いておくと、スカウトメールがけっこうやって来るので、それらを暇つぶしに眺めるのである。 Webで年収400万超えるとこって

    勉強するとこんな人になりますよ - megamouthの葬列
    kootaro
    kootaro 2018/09/08
    相変わらず読ませる文章だ。これからも楽しみにしています。
  • なぜモダンなプロダクトチームによるリーンなプロダクト開発が必要なのか|川嶋一矢@メルペイPM

    はじめにメルカリUK版の立ち上げを終え2018年3月に帰国しました@tsumujikazeです。今は東京でメルペイのProduct Managerをしています。 イギリスではいわゆるモダンなプロダクトチームでのLeanなプロダクト開発を経験しました。得るものが多かったので、なるべく多くの人に知ってもらいたいと思いこのポストを書きました。 PMF →リーンプロダクトのプロセス →モダンなプロダクトチーム(組織論)という流れになっています。 はじめに 編 ・何のためにプロダクトを作るのか ・プロダクトマーケットフィット ・PMFピラミッド ・要件定義フェーズのリーン化 ・モダンなプロダクトチームでのリーン開発とは おまけ ・Problem Space vs. Solution Space ・Problem Solution Fitとは ・エンジニア組織とPM組織の特性について ・バリュープロ

    なぜモダンなプロダクトチームによるリーンなプロダクト開発が必要なのか|川嶋一矢@メルペイPM