サービスを軌道に乗せるまで一人でやったすべてのこと個人開発エンジニア集まれ！~個人開発LT会~ #3 ( https://individual-development.connpass.com/event/303818/ ) で発表した内容です。
いつも間違っている人への対処法 - 超ウィザード級ハッカーのたのしみ
間違いを減らす方法を考えていて、ある程度以上はどうしようもないという役に立たない結論を得たのだったのだが、過激だったのか、意図せずアクセスが増えてしまった。単に苦労していますだけの内容を多く読まれても困るなと、一回取り下げて書き足しました。 間違いの減らし方を こちら に書きました。 仕事をしていると、必ず間違いを提出してくる人に出会ったことはないでしょうか？私は何度も悲しい思いをしており、そういう人にはもう仕事は頼めないと、非情ですが早々に判断するようにしています。 少なくともソフトウェア開発の世界では、正確さに大きな価値が置かれています。この業界だけでなく、一般的に、間違いは欠陥か事故であり、基本的に許されないものです。仕事は、紙の試験ではないため、百点満点が当たり前です。タクシーに乗ったら、事故せずに必ずつくことを期待する。手術で手が滑ることや、車を運転して信号を見間違えることは許さ
普通はプロジェクトマネージメントなんてできない
しんざき氏の記事を読んだ。 https://blog.tinect.jp/?p=81116 要は家庭運営は「プロジェクト」であるのだから適切なプロジェクト運営を行う必要がある、という趣旨で内容については概ね同意ではあるのだが、これを実践しようとするには大きな問題がある。 普通の人は「プロジェクトマネージメント」なんてできないのだ。 私はいろいろな会社の小さめのプロジェクトに参加して開発を請け負うエンジニアなのだが、まともなプロジェクト責任者に当たるのは20%もない。 ここでいう「まともな」というのは、 ・タスクを適切な粒度に分解できる ・タスク同士の前後関係を把握してスケジュールを組める ・品質、コスト、納期を考慮とした優先度付けができる という、プロジェクトマネージメントを行うにあたっての最低限のスキルがある人である。 もちろん優秀な人が集まる大企業であれば多くの人が簡単にこなせるだろう
【第1回・前編】 エンジニア和田卓人の今を形作る技術 | GeeklyMedia(ギークリーメディア) | Geekly（ギークリー） IT・Web・ゲーム業界専門の人材紹介会社
『テスト駆動開発』や『SQLアンチパターン』をはじめとする技術書の翻訳者、さまざまなIT企業をわたり歩く技術顧問、さらに最近ではエンジニアリング文化を伝える講演者としても活躍されている和田卓人さん(https://twitter.com/t_wada)。 そのソフトウェアエンジニアとしての素顔を株式会社一休CTOの伊藤直也さん(https://twitter.com/naoya_ito)が聞き出す対談の前編では、一線を画すエンジニアであり続けるために自らのプロジェクトで意識的にコードを書いているという和田さんの姿勢に始まり、ベテランとして「技術のらせん」を読み解くケーススタディとしてDDD（Domain-Driven Design）を題材に話を伺います。 ・伊藤 直也さん / 株式会社 一休 執行役員 CTO 新卒入社したニフティ株式会社でブログサービス「ココログ」を立ち上げ、CTOを務め
仕事力と技術力と不安に関する雑文
先日「育児など家庭の色々があって自分の時間が確保できなくなった。技術力を高めるための勉強ができなくて不安。」みたいな話を聞いた この悩みの直接的な解決方法としては先人の様々な体験談および対策みたいなものが世に出回っているからご家庭の状況に応じて参照すればいい思う 子育てと開発を両立するコツは「無理をしないこと」。パパ／ママエンジニアの働き方とは 子育てを支える技術 ─ フルスタックお父さんとエンジニアとしての成長を両立させるには ITエンジニアと子育てと勉強と それよりも「技術力を高めるための勉強ができなくて不安」という点が個人的には気になった 技術力とは何か？技術力が高くないとなぜ不安なのか？みたいな話 技術力は特に明確な定義があるわけではない 例えば著名なOSSにコミットしているとか低レイヤーのプロトコルやインフラをバリバリ実装してるとか競プロで上位勢だとか、挙げ始めたらキリがなく、そ
エンジニア一人しかいないとか言わないでほしいって言われた
そこそこの規模の業務用webシステムを一人で開発して運用してるんだけど、 問い合わせ対応とか要望対応が一人でやるには多すぎてさばききれないので （当システムは一人で開発運用しているのでお問い合わせはできる限りメールでお願いします、電話はクリティカルな用件だけにしてください） ってことを周知しようとしたら会社上層部からストップがかかった。 そんな事を言ったらシステムの信頼性を損なう 開発者が少ないのがわかったら足元を見られる バックにたくさんいるように見えたほうが印象いい という理由らしい。 そういうもん？ （追記） ブックマークがたくさんついてびびった。 ってことは、いろんな会社でこういうの結構あるんだね。 「これ書いたの君でしょ」って言われて困惑する人があっちこっちにいたら申し訳ないわ。。
今回Twitterから大量リストラされたエンジニアでもなんでもないスキルなし資格なしイシキだけ高い「ルンペンブルジョワジー」と呼ばれる人たちの話
tarafuku10 @tarafuku10 米国のジャーナリストであるレイトン・ウッドハウス氏のSubstackから「ザ・ルンペンブルジョワジー」という記事を訳してみた。IT企業をはじめとして、アメリカ社会はなぜこれほどまでにウォーク(左傾)化してしまったのか。今回のTwitter社の大量レイオフにもつながる話。tarafuku10working.hatenablog.com/entry/2022/11/… 2022-11-07 09:01:45 リンク tarafuku10 の作業場 「ザ・ルンペンブルジョワジー」 - tarafuku10 の作業場 米国のジャーナリストであるレイトン・ウッドハウス氏のSubstackから「ザ・ルンペンブルジョワジー」という記事を訳してみた。IT企業をはじめとして、アメリカ社会はなぜこれほどまでにウォーク(左傾)化してしまったのか。今回のTwitter
100名以上のメンターをやって見えた「めちゃくちゃ伸びる人」の共通点
どうも、株式会社プラハCEO兼エンジニアの松原です。 弊社では中級エンジニアを育成するプログラミングブートキャンプ「PrAha Challenge」を2年近く運営しています。累計100名近くの方々が参加して、日々実践的な技術課題に取り組みながら、メンターと技術的な質疑応答を繰り返しています。 実はプラハチャレンジの第1期から第5期までのメンターセッションは全て私が担当しているため、累計100名近くのエンジニアの成長を間近に見てきた経験から「めちゃくちゃ伸びるエンジニアの共通点」を見つけた気がしたので、何かの役に立てばと思い、Zennにも書き残そうと考えた次第です。 ちなみに弊社が運営しているpodcastでも同じテーマについて話しているので、耳で聞く方がお好みの方がいたらぜひ以下のpodcastへ！ TL;DR めっちゃ伸びる人は 分からないことを言葉にするのが上手 情報を鵜呑みにしない
未経験エンジニアを採用して失敗した
採用が困難な時期に妥協して未経験エンジニアを採用したけど、それが失敗だった。なぜ失敗なのかを話していきたい。 ただし未経験エンジニアといってもいろいろあって、子どものころからずっと学習してきたような人はただ実務が未経験なだけというように考えている。こういう人はあまり未経験と考えない。 自分への戒めもこめて。 失敗点 リターンがほぼ回収できないエンジニアの生産性の違いが10倍、100倍になることは別におかしいことではない。 そのため、未経験エンジニアに費やした時間がリターンを産むまでにとてつもない時間がかかる。 たとえば、生産性100/営業日の人が10営業日かけて教えるのなら、教えられた人は、1000の生産をしなければ当然マイナスになる。これは泣こうが喚こうが世界の理なのでここは変えられない。 1000の生産は、生産性1/営業日であれば4年2ヶ月かかる。つまり生産性100倍の人を用いる場合は
リファクタリングはエンジニアの福利厚生であり管理指標への影響はほとんどないんでは - きしだのHatena
おそらくリファクタリングの工数を確保する説得力のある材料がほしくて、リファクタリングの効果をどう示すか悩んでる人がいたのですが、リファクタリングって非開発者に示せるような数字だすのは難しいよねという結論になったので、そのまとめ。 工数としてはコード管理費みたいな感じで乗せるのがよさそう。 まず、リファクタリングはそれ自体では価値を示せません。人工衛星に搭載するプログラムで、動きだしたらメンテナンスできないようなコードを最後にリファクタリングしたとして、どのような価値を示せるかと考えると想像できるのではないかと思います。 なのでリファクタリングの価値というのは、その後で新しいコードを追加したり既存のコードを変更したりといった作業がどれだけ作業時間短く品質高くなったかという間接的な指標で測ることになります。 ここでまず、最初のコードを書いた人とリファクタリングする人が同じなら、そこまで保守性か
プログラマの心の健康
目次 はじめに 情報不安について 人の話を聞くこと 寝てから考えよう わ・ざ・と、ゆ・っ・く・り・、や・っ・て・み・よ・う ロビンソン式悩み解決法 驚き、最小の法則 むしょうに腹が立つあいつのこと あなたは、そのままでいいんです はじめからやり直したい症候群 人から信頼されるためにはどうしたらよいか トラブルがチャンス あなたはひとりではありません あなたのための聖書の言葉 ぜひ、感想をお送りください リンク集 更新履歴 はじめに 私はプログラマです。 プログラムを書いて生活の糧を得ています。 プログラマというのは精神的にも肉体的にも過酷な仕事だと思われています。 夜遅くまでディスプレイに向かい、 キーボードを叩き、ジャンクフードを食べながらバグをとる…そんな職業だと思われています。 確かにそういうところもありますが、プログラマも人間です。 不健康な生活を長いこと続けることはできません。
家族手当・住宅手当(計4万)を廃止し基本給一律減額したら世帯持ちの優秀なITエンジニアが全員辞めた、管理職は「天変地異がおきた」と言ってる
えび＠プログラマー @ebiebi_pg 某社「家族手当」「住宅手当」（計4万）を廃止し、基本給を一律減額したら数か月後に世帯持ちの優秀なITエンジニアさんがほぼ全員辞めたｗ 管理職の人が「天変地異がおきた」って言ってたけどどうやら理由に気付いていないらしい 2022-06-18 08:33:04 えび＠プログラマー @ebiebi_pg 一人残った優秀なITエンジニアさんに久々に電話したら 「僕も辞めましたw」って言ってたので 🦐「じゃぁ、✕✕君か○○君がトップかなぁ？」 って言ったら 「その二人は僕の前に辞めました…」って言ってた 次の仕事に困らない人は給料下がると辞めていくんですよね 2022-06-18 08:54:32
コードを書いていてマネジメントもやるようになっちゃった人へ 背中で語っていた僕が、プロダクトとピープルに向き合うまで
「Day One - CTO/VPoE Conference 2022 Spring -」は、日本CTO協会が主催するイベントです。パネルディスカッションでは、政財界、テクノロジー分野の第一人者をパネリストにお迎えし、日本CTO協会理事のモデレートにより、“Day One”をテーマにご講演いただきます。ここで登壇したのは、株式会社Lighthouse Studio CTOの海老原昂輔氏。これまでの経験から導き出した、“ソフトウェアエンジニア的思考をマネジメントに活用するアプローチ”について発表しました。全2回。前半は、最初期のマネジメントとプログラマーとして犯してしまった禁忌について。 エンジニアにありがちなキャリアの変遷 海老原昂輔氏：「コードを書いていたいけど、マネジメントもやるようになっちゃった人のための生存戦略」というタイトルでトークをします。株式会社Lighthouse Stud
GAFAで5年エンジニアしてて気づいたこと
思いついた順に書いてるからまとまりなくてすまん 給料がいい。転職前に比べて3倍超えた。GAFAと一括りにされるけど転職してきた人から聞くと割と風土は違うっぽいけど行ったことないから分かんない。エンジニアが全員頭いい。採用面接がマトモから。 コード書けてアルゴリズム分かってシステムデザインできる人しか取らない上司のことをマネージャーと呼ぶだけあって対等感は強い マネージャーはRPGのプレイヤーみたいにパーティの人数枠だけもらってるから、人が見つかるか、残ってくれるかはマネージャーの扱い次第 社内の転属は基本社内転職サイトを見て応募して他の候補者と競る。もちろんこちらも複数応募して気に入ったとこで内定して他は断る。 社内のコンパイラやコア言語チームのcoding practiceが神レベル。 社内アンケートで常に技術的負債が多いっていう不満が上がってるけど、前職の経験から言うと「お前らこの程度
エンジニアはもっと図を書こう - 生涯未熟
たまには軽い話題をば。 自分の中で信頼できるエンジニアかどうか？を見極めるひとつの指標で「込み入った議論の時に図を書くかどうか」というのがあります。 今までの経験上、図を書く派のエンジニアは割と良い感じの人が多かったので採用している指標なのですが、何故これが機能しているかというのを改めて考えてみた。 他者の認知負荷を理解している コンテクストを合わせることにコストをかけられる意識がある 自分の思考の整理するツールとして図を扱えている ザッと挙げましたが、この３つが機能している要因なのかなという気がしています. 他者の認知負荷を理解している あれやこれやエンジニア間で技術議論している中で、「Aさんはこの領域に詳しいけどBさんはこの領域にはほどほど詳しいくらいだな」という個々のレベル差に応じて認知の負荷がかかります。ただでさえ議論していると結構なスピードで話が展開されていくので、認知負荷が更に
30代後半になって初めて発信活動を始めたら人生が変わった話 - Qiita
はじめに 2年半前の私は、IT系の会社に勤めている30代後半の平凡なサラリーマンでした。 その時点では、社外での発表経験なし、社外での勉強会の参加経験なし、技術記事の投稿経験なしでした。 そんな私が発信活動を始めたことで人生が変わりました。 今は凄く楽しいエンジニアライフになり、以下のような事が起きました。 複数のITエンジニア向けコミュニティに所属して楽しく交流 「Serverless LT初心者向け」というコミュニティを立ち上げて運営 Developers Summit 2020 KANSAI でベストスピーカー賞1位を受賞 ITエンジニア向けの月刊誌「Software Design」で連載記事を執筆 すべては発信活動を始めた事がきっかけでした。 発信活動を始めると素敵な事がいっぱいあると知ってもらう事で、発信活動を始めるきっかけになれば幸いです。 (長いので要点を知りたい人は太字のみ
コミュ力重視の人が見ている世界
あるメーカーで技術職をしてるオッサンなんだけどけど聞いてくれ。 先日会社のマーケティング主導の製品企画のキックオフミーティングに呼ばれたんだけど、非エンジニアの文化にはじめて接していろいろ面食らっている。 なんていうか、普段馴染みのあるエンジニアだけで動いている会議って論点が割と明確なのよ。工業デザイナーの製品イメージがあって、筐体サイズや電力の制約があって、納期やコスト、開発リソースから実現可能性を考えてという具合に、製品の要素を実装可能な状態に落とし込むために要件を絞り込んでいく的な感じ。 一方、この前初めて参加したマーケ主体のミーティングはソフトバンクの決算で孫正義がやってるような感じのポエミーなプレゼン資料がポンポン飛んできて頭がくらくらした。「プロジェクトに対する私の思い」だとか、「製品のコードネームを決めよう！(提案者は製品コンセプトが抽象画なのでピカソ推し)」とかエンジニア目
某国立病院ITエンジニアから民間へ転職し、感じたこと
自分は以前に以下のエントリを書いた。 「某国立病院のITエンジニア職を辞めることにした」 https://anond.hatelabo.jp/20210228121158 あれから約1年。久々に見ると、それなりに反響があったようだ。 記載の通り、自分は某国立と名の付く病院を辞め、現在は民間企業の情報システム部門のエンジニア職だ。 辞したことは後悔していない。待遇も収入も向上し、環境が良くなり、第一、今の職場は同僚が良い人だ。 上場企業であり、海外の売上が高く、企業名は誰でも知ってると思う。 公的な機関での医療情報の世界から飛び出て、客観的に前職を見つめることができる今、はやり前職は特殊（というか閉鎖的）だったと思わざるを得ない。 転職後、何が良くなったかまず、モラルのない職員がいない。 前職で目を疑った出来事の１つが、アルバイトの非常勤職員に物理的・精神的暴力を振るう医療情報技師がいたこと
超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話（1） Regional Scrum Gathering Tokyo 2022
超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話（1） Regional Scrum Gathering Tokyo 2022 代表的なアジャイル開発手法であるスクラムをテーマにしたイベント「Regional Scrum Gathering Tokyo 2022」が、1月5日から7日までの3日間、都内およびオンラインのハイブリッドで開催されました。 そのクロージングセッションとして行われたのが、現在シアトル在住でMicrosoft Azureの開発を担当している牛尾剛氏による「アメリカの超巨大クラウドの中の人に転生したガチ三流プログラマが米国システム開発の現実をリークする話」です。 本記事ではほぼ90分におよぶセッションの内容を、前編、後編（1）、後編（2）の3本に分けて紹介します（この記事は後編（1）です）。 前編では、子供の頃からプロ
エンジニアの"有害な振る舞い"への対処法 - Qiita
本記事の続編として、自分が有害な振る舞いをしないようにする改善の取り組みを扱った記事も書いてます。 エンジニアや上司が"有害な振る舞い"を改善する方法 ※「難しい人」は概念として用い説明するのに便利な言葉でしたが、誤解を生じたり、本記事のポリシーに沿わない使用（難しい人というラベリングを特定個人に適用する使い方）が容易にされてしまいそうだと分かりました。そのような誤用を防ぐことを最優先とするため、代わりに「有害な振る舞い」という表現を使用し、人ではなく振る舞いに着目するタイトル及び文章に変更致しました。 はじめに 以下の記事を読んだ際に「難しい人」という表現が何となく面白い響きで印象に残ったので、これを機に自分の考えを今までの経験をもとに書きたいと思います。 “難しい人”が1人入ると、チームの生産性は30〜40％低下する 対抗せずに、場の「安心感」を作るための3つの条件 - ログミーBiz
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
