Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは。 普段、エンジニア向けの研修講師をしている都合上、「おすすめの本を教えてください」といつも聞かれるので、2025年中に全て読破したい本をピックアップしました。2025年、あと11ヶ月くらいあるので、1ヶ月に1冊読めば読破できるはず！！ ①マスタリングTCP/IP ネットワークエンジニアのバイブルといえばこれでしょう。逆をいえば、これ以上は読まなくてもいいし、これ以下では足りない。そんな一冊です。OSI参照モデルにおいて、ほとんどの人が「3層：ネットワーク層」しか理解していない中で、この本を読めば7層全てが明らかになります。
s99e209のブックマーク (6,290)
-
s99e209 2025/01/31
-
ソフトウェア開発現代史：製造業とソフトウェアは本当に共存できていたのか？品質とスピードを問い直す
【ヤマハ発動機×SUBARU×三菱電機】今こそ考えたい「開発プロセスの品質視点」登壇資料です。 https://techplay.jp/event/967093
-
ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making
ソフトウェアアーキテクトのための意思決定術 - Forkwell Library #80 での発表資料です https://forkwell.connpass.com/event/342258/
-
なぜ石井食品は「日本一のアジャイルな食品工場」を目指すのか？ ソフトウェア開発の経験を社長業に生かす石井智康さんインタビュー - Agile Journey
お弁当の定番『イシイのおべんとクン ミートボール』などの商品作りを無添加調理で進める石井食品株式会社*1では、まだ40代の石井智康さんが代表取締役を務めています。石井さんは創業家の出身ながら、大学卒業後はIT業界に入り、フリーのスクラムマスターとして活躍するなど、石井食品とは距離を置いていました。 しかし、フリーランスとして働くなかで、改めて社会にどのような貢献ができるかを考えた結果、食の課題に取り組むため家業を継ぐことを決意。2018年に代表取締役社長に就任すると、それまで培ったソフトウェア開発やアジャイルの知見を生かして、さまざまな業務プロセスやコミュニケーションの改革に取り組んでいます。 企業を取り巻く環境が変化するなか、アジャイルに対する理解と知見を持つソフトウェアエンジニアが企業経営に取り組むことで、どのような変革をもたらすことができるのでしょうか。アジャイルとの出会いや石井食品
-
Webサービスぶっ壊れ地獄、行きやすぜ！
はじめに なあジョージさんよ……あんた、いつもこう言ってたよな？ 「便利さとシンプルさ、それがユーザーも開発者も幸せにする秘訣だ」ってよ。 あたしゃな、その言葉に乗っかっちまった。ユーザーのため？ 開発を効率化するため？ そりゃあ立派なもんだ。でもな、それが「命取り」になることがあるんだぜ。 シンプルに作ったはずのサービスが、悪意ある奴らに好き勝手利用されて、時には「あたしの知らなかった地獄」を見せてくれる。越えたらいけない一線がある。そんな話を、今日はしようじゃねえか。 さあ、これがあたしらの舞台だ。 セキュリティの教科書には載らない、バグバウンティでも指摘されない、ニュースにもならない、「 現場のWebサービスぶっ壊れ地獄 」 ……教えてやりますぜ！！ 1. サインアップし放題からのクレカ決済し放題地獄 この地獄、知ってやがるかい？ 聞いてくれよ。ユーザーを簡単にサインアップさせる……
-
ソフトウェア開発の “見積り” と “計画” を混同するから話が噛み合わない｜mtx2s
“見積り” を作成した開発チームと、それを確認したビジネス担当者や経営者が、その内容を巡って対立することがあります。「見積りが大き過ぎる」「いや、これぐらいはかかりますよ」といったあのやり取りです。 これはおそらく、両者がともに “見積り” と “計画” を区別せず、混同しているから発生しています。見積り依頼を受けた時、開発チームが提出するものは、おそらく “見積り” です。しかし、ビジネス担当者や経営者が期待するアウトプットは “計画” なのです。 こうして “見積り依頼” という名のもとに、ソフトウェア組織に対立が日々生じているのではないでしょうか。 “見積り” と “計画” は別物見積り結果の「30人月」という数字（①）は、計画ではなく見積り工数です。そんなことは当たり前ですよね。 工数が明らかになれば計画なのか？それでは、30人月の開発を5人でこなすから「6か月」かかる（②）、とい
-
ECSとRDSをやめて、AWSコストを9割削減しました
はじめに こんにちは。BEENOSのがれっとです。 AWS上にアプリケーションを構築する際、一般的なのはECS + RDSという組み合わせです。私も社内システムをそのような形で構築しました。 しかし、使わないときにもインスタンスが動き続けてしまうため、大量のトラフィックを捌かないアプリケーションにおいてはコストが見合わないものとなってしまいます。 そこで、ECS + RDSという構成からLambda + EFSの構成に社内システムを移行して、コスト削減した話を紹介します。 前提 以下の構成のアプリケーションを移行しました。 Blitz.js 内部に下記を使用 Prisma Next.js PostgreSQL テーブル数は12 (_prisma_migrationsテーブルを含めて13) AWS 構成図 移行前 移行後 リレーショナルデータベースを用いることが必須のアプリケーションを構築す
-
とある大企業の部長に教わった、「鬱で休職した社員を復職させる」神対応。 #ポエム - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 何かと話題の「鬱」という病気。近年、社会全体にも「誰でもかかる病気」「いつ自分がかかるか分からない」と認識されているように思います。 言うまでもないことかもしれませんが、鬱は決して他人事ではありません。ある日突然、自分が、あるいは家族が、友人が、同僚が、部下が鬱になってしまうことがあります。 特に、我々のいる IT 企業では、プレッシャーや責任感に耐えられず鬱になる人が多いように感じます。弊社も例外ではなく、昨日まで現場で元気に活動し、メンタルが強そうと思われていたメンバーが、次の日には鬱になってしまうこともありました。 ───さて、そ
-
-
テックリードの役割を定義しました - Gunosy Tech Blog
こんにちは。 id:skozawa です。 こちらの記事は Gunosy Advent Calendar 2024 の 24 日目の記事です。 昨日は上村さんの 「LLM で Web 検索を効率化！- Web 検索エージェントとブラウザ拡張によるアプローチ」 でした。 背景 エンジニアのマネジメント領域 TL の見直し EM と TL の役割定義 キャリアパスの見直し まとめ 背景 Gunosy にはエンジニアマネージャー（EM）とテックリード（TL）、リードエンジニア（LE）という役職があります。 LE については以前に定義しましたが、EM と TL については役割分担が明確化されておらず、EM に負荷が集中しがちになるという課題があったため、役割を見直すことにしました。 EM と TL の役割を再定義し、TL は役職から役割に変更しました。 また、それに伴いキャリアパスを見直すことにし
-
ChromeからFirefoxに乗り換えて便利だった機能いろいろ
Google Chromeはブラウザ、特にPCブラウザでは非常に大きなシェアを誇っていますが、「Manifest V3」への移行や負荷の高さなど、ユーザーからは不満の声も上がってます。ニュースサイト・How-To Geekのライターであるファイサル・ラスール氏が、「ChromeからMozilla Firefoxに乗り換えて後悔しなかった理由」をまとめました。 Why I Switched to Firefox and Never Looked Back https://www.howtogeek.com/why-i-switched-to-firefox-and-never-looked-back/ ラスール氏がブラウザを乗り換えることにしたのは、仕事用PCが古くなってしまい、タブを多く開くとファンがうるさく鳴るようになったことがきっかけです。そこで、Firefoxに移行してみたところ、以
-
ソフトウェアアーキテクトが知るべき 97 のこと
【01】システムの要件よりも履歴書の見栄えを優先させてはならない by ニティン・ボーワンカー 【02】本質的な複雑さは単純に、付随的な複雑さは取り除け by ニール・フォード 【03】最大の問題は、たぶん技術的なことではない by マーク・ラム 【04】まずコミュニケーション、そのための明快さとリーダーシップ by マーク・リチャーズ 【05】パフォーマンスの決め手はアーキテクチャー by ランディ・スタッフォード 【06】要求仕様の本当の意味を探れ by アイナー・ランドル 【07】立ち上がろう！ by ウディ・ダーハン 【08】すべてのものは、かならずエラーを起こす by マイケル・ナイガード 【09】それは交渉だということに気付け by マイケル・ナイガード 【10】定量化を求めよ by キース・ブレイウェスト 【11】500 行の仕様書より 1 行のコード by アリソン・ランダ
-
Tidy First?のススメ - 日々常々
薄い本なので軽い気持ちで読みましょう。 先に読むべき？→Yes！ 私は初詣の列に並んでいる1時間で読みました。寒かった。 Tidy First? ―個人で実践する経験主義的ソフトウェア設計 作者:Kent Beckオーム社Amazon 力を失ってしまった「リファクタリング」を復活させる本です。私の中のサブタイトルは「Make Refactoring Great Again」です。 第一部の冒頭から引用します。 整頓はリファクタリングのサブセットだ。整頓は可愛くてふわふわした小さなリファクタリングなので、誰も嫌いになれないはずだ。 「リファクタリング」という言葉は、機能開発の長い中断を指す言葉として使われ始めたとき、致命傷を負った。 「致命傷を負った」に「だよねー」と思ってしまう昨今。「それリファクタリングじゃねーしなー」とか思いながら「リファクタリング」という言葉が使われているのを眺めつつ
-
エンジニアは事業を理解すべきか？｜naro143
最近、エンジニアは事業を理解すべきか？という話題をよく目にします。様々な経験や背景がある中での議論なため、多くの意見があり難しい話題だと思います。 エンジニアの主戦場は技術私は技術も事業も好きです。でもエンジニアです。 能力を表すのも求められるのも技術です。 まずは頭の中にあるアイデアを実現できる技術力は大前提で、その上で「エンジニアは事業を理解すべきか？」を考えるべきだと思っています。 事業への理解があることは、技術力がないことの免罪符ではありません。 むしろ事業への理解は技術力の一部です。 そもそも良いエンジニアに事業の理解は必要技術の意思決定において、前提や課題や目的の理解は大切です。仕事においては、事業や市場や顧客のドメインの理解がないと意思決定はできません。 エンジニアが事業をできる必要はありませんが、知識として事業を理解する必要はあります。 ちょっと不思議ですが、良いエンジニア
-
コミュニケーション能力を評価してはいけない理由 - An Epicurean
この記事はジンジニアアドベントカレンダー2024 25日目の記事です。 人事選考で安易に使われがちで、避けたほうが良い判断軸の項目に「コミュニケーション能力」や「地頭」があることが良く知られています(要出展)。ここではなぜコミュニケーション能力を問わないほうが良いかについて論じます。 コミュニケーション能力4象限 コミュニケーション能力を同質か多様か、能動か受動かという2つの軸で以下の4象限に分けてみます。 コミュニケーションスキル4象限 内訳をざっと細分化すると以下のようになるでしょうか。 同質な人に共感する シンパシー 共感力 親和性 同質な人に共感してもらう 共鳴力 信頼構築力 受容力 多様な人を理解する エンパシー 寛容力 異文化理解力 多様な人に理解してもらう 説明能力 発信力 橋渡し能力 一言でコミュニケーション能力といってもこのように様々な要素が含まれており、個々人の認識のズ
-
アジャイル開発の推進において、必ずしも"すごい人"は必要ない──現場のエンジニアがDevOps推進で実現する組織改革
安全最優先ゆえの新技術導入に慎重な体質 関電システムズは関西電力100％出資の子会社として、関西電力向けシステム開発を専門とする機能子会社だ。2019年4月より関西電力と関電システムズの合同でDevOps推進が始まったが、当時の関電システムズと関西電力の関係は、IT部門再編に伴い役割分担が大きく見直された直後であったこともあり、西内氏が「完全なる親子関係」と振り返るほど強い上下関係だったという。 株式会社関電システムズ テクニカルラボ DevOps推進グループ テクノロジスト（プロフェッショナル）西内 慶子氏 そのため関電システムズの開発体制は決められたことを計画どおり進めていくウォーターフォール型が基本方針であり、技術面では「枯れた技術」の使用が推奨されているなど、新技術の導入にあまり積極的ではなかった。 こうした体質は以前から課題認識されており、関電システムズではDevOpsの推進前に
-
午前中に読み始めたら午後には設計が上達してしまった！ - 『Tidy First?』を読んだ - Mitsuyuki.Shiiba
私の目標は、読者が午前中に本書を読み始めたら、午後には設計が上達していることだ。 本当にそのとおりだった。読んでる途中で既に自分の設計に対する考えが良い方向に変わってると感じた。とても良かった。おすすめです。 『Tidy First?』 をいただいて読んだ。昨日（2024年12月25日）発売。英語版が2023年11月28日発売だから、たった1年で日本語版が出たということだな。うれしい！はやい！ありがたい！ ソフトウェア設計に焦点を当てたシリーズの最初の1冊ということで、サブタイトルに「個人で実践する経験主義的ソフトウェア設計」とあるように、1人でできる種類のソフトウェア設計について書かれている。続刊ではチームについての話になる予定のようで、それも今から楽しみ。 2周読んだ なんとなく2周読もうと思ってそうした。 1周目は細かい部分は気にせずにざーっと1,2時間くらいで読んだ。全体的にどうい
-
巨大企業でのDXの本質は「剥がす」ということ
メリークリスマス。今年もアドベントカレンダを寄稿させていただきます イオン株式会社CTO ／ イオンスマートテクノロジーCTOのやまけん（ 山﨑賢 )です。 この記事は、AEON Advent Calendar 2024 最終日の記事です。 今日はCTO的なというよりも、経営の端っことしてイオンのDXをどのように捉えているか、何が大事なトリガーなのかを記載していきたいと思います 過去の私のAdvent Caledar投稿記事はこちら。 DX革新を宣言して動いてきた1年間 AEON TECH HUBの立ち上げから現在まで とにかく既存を変えたくて、JTCというブランディングを変えて会社と社会を変えたくて変えたくて。 AEON TECH HUBの活動を通して、特に外部に積極的に発信してきました 登壇の依頼は日程が調整出来ないなどの理由や、公益性が低いなどの理由が無い限り、ほぼ全てお受けしてオフ
-
技術者教育について | さにあらず
これはpyspa アドベントカレンダー 2024の12日目の記事です。11日目は@aodagの走るということについてでした。 はじめに この15年くらいは、おおむね平均すると毎年2，3人程度の技術者をOn the Job Training（OJT）で教育する機会に恵まれており、その中で蓄積した知見や私の考えを散発的に説明していきます。 私自身は受託開発を主たるビジネスとするシステムインテグレータ（SIer）と呼ばれる企業で働いており、足掛け25年程度のキャリアがありますがソフトウェアについて専門的な教育を受けたことはありません。また、教育についても同様です。 このエントリに記載された内容について何らかのエネルギーを注いでくれる方がいるなら、XあたりのSNSでURL付きで指摘して頂ければ非常にありがたいです。 教育によって形成される技術者像 まずは、どのような技術者なら育てられるのでしょ
-
無自覚にメンバーの心理的安全性を奪っていた経験から得た学び
2024.12.11 エンジニア組織のリアルな失敗経験から学ぶ！ 生産性向上＆チーム強化Tips
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました