改訂版『事業をエンジニアリングする技術者たち』を読んだ - 余白
先日読んだ『Engineers in VOYAGE - 事業をエンジニアリングする技術者たち』の改訂改題版である 『事業をエンジニアリングする技術者たち』 が8月8日に発売された。 事業をエンジニアリングする技術者たち ― フルサイクル開発者がつくるCARTAの現場 作者:株式会社CARTA HOLDINGS 監修,和田卓人ラムダノートAmazon lacolaco.hatenablog.com 初版から2年が経ち、各章の後日譚が加筆され、さらに新たに2つの章も増えた贅沢な増補版となっている。 初版は興味があって自分で買って読んだのだけど、本書にも登場するZucks CTOの@r_kawaiimuraさんとの縁で改訂版の献本を頂いた。そのお礼を兼ねて、改訂版の見どころを少し紹介できたらと思う。 端的に言えば、初版を読んでない人には変わらずおすすめしたいし、初版を読んだ人にも重ねておすすめで
エンジニアの劣等感との付き合い方 - Qiita
はじめに 私は、不完全な人間です。 人より劣っているところ、弱みもたくさんあります。 しかしながら、なんとか、今日までエンジニアとして生きていくことができました。 私がこれまで、劣等感とどう折り合いをつけてエンジニアとして生きてきたか、説明したいと思います。 この記事で最も言いたいことは「不完全な自分を認めながら、でも、自分の成長の可能性を失わない」ということを伝えたいです。 劣等感にまみれたエンジニア人生 ふりかえると、劣等感にまみれたエンジニア人生でした。 「自分はダメなエンジニアなんだ…」 という想いが、思考の隅につきまといながら、なんとか生きています。 思い返せば、この想いの最初のきっかけは、新人時代に先輩社員にコードレビューの指摘で、叱咤された事でした。 「こんなことも知らないの」 「コードを書く才能がないんじゃない」 「…あぁ、もう、いいから、こっちで修正しとく。いいよ。さわら
VPoE handbook | エンジニア組織のマネジメントに悩んでいた三年前に戻れるなら渡したい。VPoE handbookを書き終えました (目次&サマリ付)｜Takayuki Shimizu
（この記事はVPoE handbookの目次＆サマリパートです） 以下で書き始めを宣言してから進捗が悪思わしくなかったhandbookですが、ようやく書き終わりました。 数えるといつの間にか合計30,000字ほどになり、意外とボリュームが増えてしまったので、少しずつ読みやすいように章ごとに記事にしています。 目次はこの記事の目次部分、もしくはこちらのマガジンの一覧からご覧ください。 この記事自体ではその目次と簡単な解説をつけ、ざっくりと全体像を知り、詳しく読みたい気になる記事を見つけやすくするような構成で書いていきたいと思います。 （この7月からは開発マネジメントのキャリアとはまた違った方向に進みだしたので、賞味期限切れギリギリ?!になりましたがなんとか整理も終わりました。） VPoE handbookを書こうと思った理由まずはなぜ書こうと思った？の問題意識から。 この記事にあるように、三
#RSGT2020 テックリードは未来の話をしよう / Tech Lead in Scrum
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11890/tech-lead-in-scrum
プログラミングできる人とできない人との間の深い溝 - masatoi’s blog
どうしてプログラマに・・・プログラムが書けないのか?を読んでいて出てきたので出展の一つを訳してみた。Separating Programming Sheep from Non-Programming Goatsの和訳。 プログラミングというものには向き不向きが強く出るということはわりと知られていると思うが、このエントリではプログラミングができるかできないかは比較的簡単なテストによって、プログラミングの訓練を始める前の段階で分かると主張している。どうしてプログラマに・・・プログラムが書けないのか?では、そもそもこの事前テストをパスしていないような人達までプログラマとして応募してくると言っており、その判定法として有名なFizzBuzz問題を挙げている。 追記（2019/2/28) 注意： なおこの論文はしばらく前に著者の一人によって撤回されたようです Camels and humps: a r
デザインとエンジニアリングの狭間で/ design-engineering - Speaker Deck
サイバーエージェントの技術者（エンジニア・クリエイター）向けカンファレンス『CA BASE CAMP 2019』 デザインとエンジニアリングの狭間で 谷拓樹
第2回 JavaScriptの呪いから解き放たれて | gihyo.jp
第2回目のゲストとしてお迎えしたのはamachangこと天野仁史さん。これまでのこと、これからのこと、熱く語ってくださいました。 天野 仁史 さん2012年にプログラマーとして起業。その後、スマートニュースにバイアウトし、エンジニアリングマネージャーとして開発チームを作る仕事に携わる。 Twitter：@amachang URL：https://amachang.hatena blog.com/ JavaScriptのスターからベンチャーの立ち上げへ 天野：天野仁史です。amachangのハンドルネームで活動しています。2007年ぐらいにインターネットで活躍していました。サイボウズ・ラボでJavaScriptをがんばっていた時期があって、そこで技評さんにお世話になったり、いろんな勉強会に顔を出したりしていました。2010年以降はベンチャーを立ち上げたり手伝ったり。 経歴を言うと、高専でコン
日々の進捗の出し方
私は「何かを習慣化してやり続けてそこそこのレベルまで持っていく」のがわりと得意な方だと思っています。本記事はその辺りのことを言語化してみようという試みです。 大体いつも二つのことを意識しています。一つは「毎日前に進む」、もう一つは「当たり前のレベルを上げる」です。 毎日前に進む 身も蓋もない話ですが、やらないと進捗は出ません。一方、少しでもやり続けていればいつか絶対にゴールに到達できるはずです。眠くても疲れていても毎日ちょっとずつ前に進むべきです1。ここで大事なのは「量はどうでもいい」ということです。「毎日やり続ける」ことが重要で「毎日 15 ページ本を読む」のように決まった分量をこなすことをルールにしてはいけません。破綻します。 さて「いつか絶対にゴールに到達できるはず」と言いましたが、ゴールがあやふやだといつまでも到達できません。ゴールは到達判定可能で少しずつ近づけるものにし、進捗もざ
ソフトウェアエンジニアとして成長するために自分を見据えること - Kentaro Kuribayashi's blog
先日、鹿児島で行われたq-tech Meeting X #1というイベントのパネルディスカッションに参加させていただきました。テーマは、アウトプットを通じていかにエンジニアとして成長していくかということについて。その中で様々な論点とやり取りがあったのですが、このエントリでは、時間の関係もあって話せなかった内容について、簡単に紹介したいと思います。 #qtech トークセッション聞いてる pic.twitter.com/zfhgw2Rd1n— Yuta Kurotaki (@kurotaky) January 29, 2019 上記のツイートは、当日のパネルディスカッションの様子。左から、わたくし、株式会社W・I・Zの松岡さん、SYNAPSEの中野さん、リモート参加のさくらインターネットの松本さん（が映るMacをかかえるペパボのpyamaさん）。 そもそもなぜ鹿児島で話しているのかというと、
技術的負債への後悔と返済｜Seiji Takahashi@ベースマキナ
反省文。 tl;dr・「後から改善すれば良い」のスタンスは、返済コストを甘く見積もっている結果 ・負債の返済にはコーディング以外の工数が大きくかかってくる ・技術的負債を"徐々に"返済することは様々な面で良い 出社即リファクタリング最近出社した直後に、こっそりリファクタリングの時間を一定程度取るようにしている。朝のウォーミングアップがてら改善作業をしていると、瞑想みたいな効果があって大変気分がよくなるし、その後のコーディングも生産性が上がる。大体こういう気分。 具体的な作業は、アーキテクチャの方針が固まってなかった時代のコードの１つのエンドポイントだけ、適切なレイヤ化を施したり、単体テストが可能なメソッドとして切り出しつつ実際にテストを書いたり、テストに必要な共通処理を定義したり、だ。 初期から機能追加を重点的に行ってきたプロダクトでは、スピード優先の名目で多くの負債が生まれる。こうした負
「良いエンジニア」を言語化してみました
「VOYAGE GROUP エンジニアの公開ガチ評価会」に参加して、最近考えていた「良いエンジニア」像がかなり良い感じだと思うようになりました。 「ガチ評価会」自体の内容は他の方のブログに譲るとして、「ガチ評価会」で聞けなかった部分、つまり「普段だったら『ビジネス的側面からの技術投資判断』とかも聞くんだけど」と言っていたところが、まさに聞きたいところだったのでニヤッとしました。聞けなくて残念♪ 妥協ない挑戦元々ピクシブの技術力評価においては、「最近やった妥協ない挑戦は何ですか？」というのをキーワードにやってました。 解決すべき課題に対して、どういう背景があって、どういう事前調査をして、どういう実装をして、どう考察するか、というところまでをきちんと考えて仕事することに成長があるんだよ、というメッセージ性です。 そんなこと言っても普段は妥協ばっかりですって？いえいえ、相反する選択肢の中で、何を
チームの症状と処方の考察｜Megumi Kaneko
はじめに自己紹介を少しさせてください。 私はクライアントワークで約30名規模の開発チームに1年間ほどジョインしていました。役割は5〜10名のエンジニアで構成されるチームのプロダクトオーナーとしてだったり、UIデザイナーとPMのチームのスクラムマスターとしてだったり、色んな形でチームに接してきました。 その中で経験したことが、広木大地さんの著書である「エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング」を読んで色々整理されたので、チームが陥りがちな問題について稚拙ながら考察を書きたいと思います。 チームの健康状態とはチームの状態を表す指標として心理的安全性はよく聞きますよね。 広木大地さんの著書である「エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング」には心理的安全性について下記のように書かれていました。 「問題点の指摘」や「自分の弱
１人でweb, iOS, Androidアプリを作ったので、ついでに世界を目指そうと思う｜__shinji__｜note
仕事での1対1の日程調整を楽にしてくれるアプリです。Web、iOS、Androidの各プラットホームに対応したアプリがあるのでサクサク使えるはずかと。 ありがたい事にライフハッカーにも掲載された。 実はリリースしたのは去年の10月なんだけど、しばらくAndroidアプリでログインできない不具合があった。この不具合のせいで複数のレビュー1をつけられてしまったのは痛かった。。。内部テスト大事。 2. なぜ作ったか？仕事の面接やミーティングの日程調整がとても面倒だったから。特に、スマホのチャットでの日程調整は地獄的に辛い。 こういった問題を解決する日程調整ツールは国内外にいろいろあるのだけれど、下記をすべて満たすものがなかった。 ・webだけでなくスマホアプリも存在する ・Googleカレンダーと連携する ・予定の候補をいくつかこちらで指定して送ることができる ・予定の候補を選ばなくてもカレンダ
文系でプログラマーになったけど色々失敗して３年半で会社を辞めた話｜denkigai
このnoteをすべてのインターネット探索者(Internet Explorer)達に捧げる。 2018年12月31日、新卒入社して３年半勤めた会社を辞めた。東京の八重洲にある、フリーペーパーやWebサービスを作る会社で働いていた。いわゆる「文系プログラマー」というやつで、文系学部を卒業後、会社に入ってからプログラミングを覚えた。現在は退職してフリーランスになり、個人で開発しつつ、ずっと漫画を描いている。 3年半のあいだ、大きく分けて2つの失敗をした。 1. プログラミング入門の仕方に失敗した 2. プログラミングを覚えてから何をすればいいかわからなかった 前者の失敗の結果、プログラミングを投げ出して京都に逃亡した。後者の失敗では精神を病み、3ヶ月休職をすることになった。前者は笑い話だが、後者は人生に暗い影しか落とさない。これからプログラミングを始めようと考えている人には同じような失敗を避け
2018年の段階で私が知らないこと
Originally written in: English • Русский (авторский перевод) Translated by readers into: Deutsch • Español • Français • Português do Brasil • Svenska • Tiếng Việt • తెలుగు • 日本語 • 简体中文 • 繁體中文 • 한국어 Read the original • Improve this translation • View all translated posts 多くの人は、私が実際に持っている知識量より遥かに多くのことを知っていると思い込んでいる。それは悪い事ではないので文句を言っているわけではない。(世の少数派の人達は、努力して資格を得ているにもかかわらず、逆の偏見に苦しめられている。それはイケてない。) この記
「技術を極める仕事にシフトしたい」というメンバーへのフィードバック
「自分は○○技術に強みがあって、それを活かせる仕事をしていきたい」というメンバーがいました。自社ではまだ○○技術はあまり採用されていなかったのですが、筋は良いと思っていて、このメンバーにも期待していましたので次のようなフィードバックをしました。 フィードバック内容技術を極めて仕事にするというのは、実は「自分の好きな特定の技術にめっちゃ特化したらそれが仕事になる」というものではないのです。 技術がビジネスに繋がるまでには、 コア技術アプリケーション運用パッケージングブランディングセールスマーケティングなどなど、様々な要素が組み合わさってできています。 むしろ、ビジネスのほうから逆算してこそコア技術に価値があります。 特定の技術分野に対して、応用事例や運用まで考えてある程度広く浅く日頃からインプットをしておいて、ビジネス的価値が見えたときに「ここぞ」とばかりに自分から提案してコア技術を学べる力
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
事業をスケールさせるエンジニアリング〜技術のコモディティ化にエンジニアは敗北する〜 - DMM inside
Redirecting...
企業に所属するエンジニアとしての社内と社外の実績の重ね方
about_mizchi_job.md
