インプットのすゝめ | 外道父の匠
絶賛成長期にあるだろう若手エンジニアは、どういう流れで自身の成長を促したら良いのだろうか、とふと思いつつ口頭で説明してみたけどよくわからんくなったので整理してみたいお気持ちです。 当ブログではアウトプットの効用みたいなものは書いてきましたが、インプットそのものについてはお初なので、自身を振り返る良い機会にもなりそうです。 はじめに これは私が二十数年間、プログラマー・インフラ・SRE といったエンジニアとして通ってきた中で、どのようにインプットをしてきたかを整理してみるチラ裏です。 自分は一般(?)と比べれば少々特殊な経歴で、情報学を学んだことも、新卒研修を受けたことも、IT系資格も、転職したこともない…… ほぼ独学による野良エンジニアとして生息してきましたので、あまり参考にはならないかもしれません。 それでも一応長く生き抜いてきたエンジニアの経験として、インターネットに数多くある参考例の
この記事は "What We’ve Learned From A Year of Building with LLMs" という記事を著者の一人である Eugene Yan さんから許可を得て翻訳したものです。 https://applied-llms.org/ Thank you for giving me a permission to translate this wonderful article! 著者の方々 Eugene Yan Bryan Bischof Charles Frye Hamel Husain Jason Liu Shreya Shankar 原文の公開日 2024/６/8 今は大規模言語モデル（LLM）を使った開発がとってもエキサイティングな時期です。この1年間で、LLMは実世界のアプリケーションに対して「十分に良い」ものになりました。そして、年々良くなり、安く
![[翻訳]LLMで1年間開発して学んだこと〜LLMプロダクト開発を成功に導くための実践的ガイド〜](https://cdn-ak-scissors.b.st-hatena.com/image/square/3636c7c8e7c838018a6e006d55b3f4b8d18f34cc/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--7VM-vHg9--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255B%2525E7%2525BF%2525BB%2525E8%2525A8%2525B3%25255DLLM%2525E3%252581%2525A71%2525E5%2525B9%2525B4%2525E9%252596%252593%2525E9%252596%25258B%2525E7%252599%2525BA%2525E3%252581%252597%2525E3%252581%2525A6%2525E5%2525AD%2525A6%2525E3%252582%252593%2525E3%252581%2525A0%2525E3%252581%252593%2525E3%252581%2525A8%2525E3%252580%25259CLLM%2525E3%252583%252597%2525E3%252583%2525AD%2525E3%252583%252580%2525E3%252582%2525AF%2525E3%252583%252588%2525E9%252596%25258B%2525E7%252599%2525BA%2525E3%252582%252592%2525E6%252588%252590%2525E5%25258A%25259F%2525E3%252581%2525AB%2525E5%2525B0%25258E%2525E3%252581%25258F%2525E3%252581%25259F%2525E3%252582%252581%2525E3%252581%2525AE%2525E5%2525AE%25259F%2525E8%2525B7%2525B5%2525E7%25259A%252584%2525E3%252582%2525AC%2525E3%252582%2525A4%2525E3%252583%252589%2525E3%252580%25259C%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3Aseya%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyL2QzODg4YjM0MzEuanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
個人的技術書大賞2024 - Qiita
O'Reillyサブスクリプションで読むことができる今年発行された書籍の中から、これは良いんじゃないかな、と感じたものを紹介します。 Balancing Coupling in Software Design 『[ドメイン駆動設計をはじめよう』原著者のVlad Khononovさんの最新作で、ソフトウェアにおいて結合とは何かを一冊まるまる使って掘り下げた本です。 ソフトウェアにおける結合というと、その指標として50年以上前に提唱された構造化設計時代の結合強度が用いられがちです。本書ではこれについて解説をしつつも、新たな現代における結合強度の基準を提案しています。(元ネタはMichael NygardのUncouplingを統合したものでもあるのですが…) それから開発の辛みは結合強度だけでなく、「距離」「変動性」も影響してくるため、これらのバランスをとるのが重要であるといい、以下公式を導き
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに だれしも自身のITエンジニアのキャリアについて悩んだことがあると思います。 所属する会社の評価軸だけではなく、世の中のITエンジニアのキャリアについても意識することで、より市場価値の高いキャリアを歩むことができると考えています。 今回の記事では世の中で一般的に知られているITエンジニアのキャリア、ポジションについて紹介します。 この中で自分はどこのポジションを目指したいのかをより具体的にして、自分に足りない能力は何かを定義し、今後のキャリア戦略に活かして頂ければと思います。 本記事では、以下の図のポジションについて説明します。
「Tailwind CSSめっちゃ負債になりそう」はそうでもないのでは、と思っている Tailwind CSS 1 を一目見た人、特にCSS初学者のうちけっこうな割合が「これエグい負債になりそう」と思う気がする。なぜなら実際にそのような意見をちらほら見るからなんだけども、自分はあんまりそうは思っていないし、微妙に今のCSSについて誤解があるような空気も感じるのでその理由を説明したい2。JSXと同じで嬉しさを理解して使い慣れればなんてことはないのだけど、一方でその背景にある話はJSXより複雑なので単純に使って慣れればいいという話でもなさそう。 なお、この記事は私の以下の2ツイートを膨らませたものです。 Tailwind CSS、剥がすのは大変そうだけどそれをもって重大な負債になると評せるかは微妙に思っている https://x.com/aumy_f/status/18220941478532
2024年7月25日紙版発売 2024年7月25日電子版発売 柴田芳樹 著 A5判／208ページ 定価2,860円（本体2,600円＋税10%） ISBN 978-4-297-14293-3 Gihyo Direct Amazon 楽天ブックス 丸善ジュンク堂書店 ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle ブックライブ 楽天kobo honto この本の概要 本書は，著者が1993年から約30年間経験してきたAPI仕様の作成，2003年から20年間経験してきたテストファースト開発／テスト駆動開発の知見をまとめたものであり，一般的なソフトウェア開発者が習得することが容易ではない事柄を，本書を通して学び，実践してもらうことを目的としています。 本書が提唱する「API仕様ファースト開発」はWebサービスにおける大域的なテスト駆動開発の
これはなに？ こんにちは、DMM.comのミノ駆動です。 プラットフォーム開発本部 Developer Productivity Group 横断チームにて、 プラットフォームの設計品質向上に取り組んでいます。 さて、ネット上ではソフトウェア開発における「良いコードとは何か」をめぐって、 いろんな意見が交錯したり、 ときには激論を呼んだりします。 収拾がつかないこともしばしばです。 この記事は、良いコードを考えるうえでの要素を整理し、 建設的な議論を助けることを目的とします。 これはなに？ この記事の理解目標 良いコードをめぐる議論 議論1: 何をもって良いコードなのか 議論2: 良いコードはどうやったら書けるのか 議論3: 「綺麗なコード（良いコード） vs 動くコード」問題 議論改善のために提案します 提案1: ソフトウェア品質特性の観点でコードの良し悪しを判断しよう 提案2: 原理原
ルールは現場で死にました - The Rules of Programming の読書感想文 - じゃあ、おうちで学べる
本日は人生の数ある選択肢のなかから、こちらのブログを読むという行動を選んでくださいまして、まことにありがとうございます。 はじめに プログラミングの世界には多くの指針や原則が存在します。Chris Zimmerman氏の「The Rules of Programming」（邦題：ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール）は、不変の知恵を凝縮した一冊です。これらの原則は、多くの開発現場で活用できる有益な内容となっていると思いました。 The Rules of Programming: How to Write Better Code (English Edition) 作者:Zimmerman, ChrisO'Reilly MediaAmazon 本書は、大ヒットゲーム『Ghost of Tsushima』などで知られるゲーム制作スタジオ、Sucker Pun
ソフトウェアアーキテクトのための意思決定術 リーダーシップ／技術／プロダクトマネジメントの活用 作者:Srinath Perera,島田 浩二インプレスAmazon 私は現在、会社でアーキテクト[*1]という職位についています。実際のところは、自分の半分くらいの時間でチームのテックリードを務めつつ、半分くらいの時間でアーキテクトをしているという時間配分です。アーキテクトというのは、勤務先ではテックリードの上位に置かれているようなイメージで、テックリードがチーム単位での技術的なリードを司る職位だとすると、アーキテクトはチームの上位概念である事業領域単位での技術的なリードを司る職位、ということになります。 アーキテクトの主な仕事は、基本的にはテックリードと変わらず技術的な意思決定です。さまざまなトレードオフを掻い潜りながら、その時点での最適な結論を出すのがお仕事といったところでしょうか。ただ、
この記事は、3-shake Advent Calendar 2024 24日目のエントリ記事です。 はじめに こんにちは、nwiizoです。2024年も残りわずかとなりました。年の瀬に差し掛かるこの時期、1年の歩みを振り返り、時の流れを見つめ直すことは、私にとって特別な意味を持っています。今年は特に、技術書との関わり方に大きな変化がありました。本を紹介する投稿する中で、技術書のみならず、さまざまな分野の書籍を読む機会が大幅に増えました。 私の書斎は、いつの間にか技術書のデータセンターと化しました。サーバーラックの代わりに本棚が整然と並び、それぞれの棚には未読の本という名のサーバーがぎっしりと配置されています。これらの「サーバー」は、24時間365日、知識というバックグラウンドプロセスを静かに実行し続けています。既にメモリの使用率は常に100%ですが、まだ、クラッシュすることはありません。ク
“選定してすぐにダメになった”を防ぐには？特定の言語にフルベットしない、一休の技術戦略 | レバテックラボ（レバテックLAB）
“選定してすぐにダメになった”を防ぐには？特定の言語にフルベットしない、一休の技術戦略 2025年3月4日 株式会社一休 執行役員CTO 伊藤直也 新卒でニフティ株式会社に入社。ブログサービス「ココログ」を立ち上げる。2004年、株式会社はてなに入社し、CTOに就任。「はてなブックマーク」などの開発を主導。2010年から、グリー株式会社でソーシャルメディア統括部長を務める。その後フリーランスとなり、技術顧問を務めていた株式会社一休に2016年4月入社。執行役員CTOに就任し、現職。 エンジニアの仕事の中でも、「技術選定」は特に難易度が高く、責任が重いものです。ひとたび特定技術の採用を決めると、容易にリプレイスできず、長期間にわたって開発や運用に影響を及ぼします。さらに、使用する技術によって採用活動や組織戦略にも大きな影響が出ます。読者の中にも、「技術選定で失敗したくない」「将来にわたって持
モデリングとアーキテクチャの知見を積み上げて基幹システムに可変性を注入する - MonotaRO Tech Blog
こんにちは。 この記事では、2024/5/22に開催された「アーキテクチャを突き詰める Online Conference」で弊社CTOの普川がお話しした内容（ビジネスの構造をアーキテクチャに落とし込みソフトウェアに可変性を注入する〜モノタロウ基幹システム刷新の実践例）を、現場目線から改めてご紹介します。 なお、本稿の執筆は頼と尾髙が分担しておりまして、途中で急に文体が変わったな？と違和感を持たれることもあろうかと思われますが、ご容赦いただけますと幸いです。 本稿をさらに深掘りするイベントを10/4(金)に開催いたします。 ご興味ある方はぜひご登録ください。 https://connpass.com/event/328360/ 問題領域は関連システムの密結合点 分割を試みる 最初のモデルを手に入れる レイヤードアーキテクチャに沿って実装 レイヤードアーキテクチャのメリット モデルを洗練させ
プログラマ、テスト駆動開発者 和田卓人 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『SQLアンチパターン』（オライリージャパン、2013）監訳。『テスト駆動開発』（オーム社、2017）翻訳。『事業をエンジニアリングする技術者たち』（ラムダノート、2022）編者。テストライブラリ power-assert-js 作者。 日本におけるテスト駆動開発（以下、TDD）のエバンジェリストとして知られる和田卓人さん。TDDが世に出て20年あまりが経ち、開発者の間でその名が広がっています。その一方で、和田さんは「TDDの本来の意味を知らなかったり誤解したりしている人たちもかなり増えている」といいます。 今回は、TDDは本質
グローバルなレストラン予約サービス、AutoReserveの開発をしているjavascripterです。 今回は、ハローでのautoreserve.comのアーキテクチャの変遷についてお話しします。 概要 AutoReserveは最初Next.jsで構築され、その後SPAに移行し、最終的に再びNext.jsに戻るという珍しい技術選択をしています。 この記事では、各アーキテクチャの移行の背景と、大規模アプリケーションの段階的移行の実践について解説します。 AutoReserveについて AutoReserveは世界中のレストランの予約が可能なグローバルサービスです。iOS・Android・Webの3プラットフォームで展開しており、各アプリ100ページ近くある大規模なアプリケーションです。 モバイルアプリはReact Native (Expo)で開発しており、当初のWeb版はNext.jsで構
この世の中に溢れているので自分が発言する必要はないが「ソフトウェアは認知の限界まで複雑になる」を自分なりに再考する - じゃあ、おうちで学べる
人間が何もしないと病気になるのと同じように、ソフトウェアも何もしないと複雑になる。 はじめに ソフトウェア開発の世界に飛び込んでから、「ソフトウェアは認知の限界まで複雑になる」という言葉を耳にしたとき、正直なところ、「ほへー」って思いながら何も理解していませんでした。しかし、大規模なシステムに携わるようになって、その言葉の重みを身をもって感じるようになりました。内部構造や相互作用が複雑化し、全体を把握するのが難しくなっていく。それは挑戦であると同時に、私たち開発者の存在意義を問いかけるものでもあります。 A Philosophy of Software Design, 2nd Edition (English Edition) 作者:Ousterhout, John K. Amazon この複雑性との闘いは、時に苦しいものです。でも、それを乗り越えたときの喜びは何物にも代えがたい。私たちの
TypeScript開発にモジュラーモノリスを持ち込む - Sansan Tech Blog
Bill One Entry*1の秋山です。 本題へ入る前にお知らせです。12/23、TypeScript を活用した型安全なチーム開発をテーマにイベントを開催します。弊社社員のうち、TypeScript を日々の開発で活用しているメンバーが登壇します。ぜひお気軽にご参加ください。 sansan.connpass.com はじめに モジュラーモノリスとは 保守性が低いとビジネスに悪影響を与える 技術的負債と開発生産性 コード品質とビジネス影響 モジュール分割の方針 方針１：モジュールにDBテーブルを専有させる 補遺：モジュラーモノリスとNoSQL 方針２：モジュール内をレイヤードアーキテクチャとして構成する 方針３：ESLint ルールによって実現する TypeScript 開発にモジュラーモノリスを持ち込む ステップ１：単一のエイリアスを設定する ステップ２：ESLint ルールを設定す
「リファクタリングの時間」を確保する技術
はじめに ソフトウェア開発において、リファクタリング、つまりコードの保守性を高める活動は、ソフトウェアの価値を高める上でとても大切ですよね。 しかし、「リファクタリングの時間が確保できない」「リファクタリング実施のための同意が得られない」という話を耳にすることがあります。 リファクタリングは「絶対やった方がいいのは感覚としてはわかっている、でもその必要性ををうまく伝えられない」となりがちな性質があるのです。 この記事では、リファクタリングの時間を確保するために、どんなことを考え、何をステークホルダーに伝え、具体的にどのようなタイミングで実施していくといいのか、について解説します。 ポイントまとめ リファクタリング時間確保のポイントを端的に説明すると、以下の通りになります。 リターンとコストを明らかにする 複数の実施パターンを選択肢として持ち、柔軟に選べるようにする。 その中でも、日頃の小さ
パフォーマンス改善の始め方と、APIレスポンスタイムを67%短縮した話 - YOUTRUST Tech Blog
こんにちは、YOUTRUST Webエンジニアの寺井(YOUTRUST/X)です。 私はYOUTRUSTに入社してからこれまでプロダクト開発部に所属しており、主に機能開発を担当していました。 2024年8月からは技術開発室に異動し、この1ヶ月はパフォーマンス改善に取り組んできました。 そこで、今回はこの1ヶ月間パフォーマンス改善に取り組んだ過程とその結果を記事にしたいと思います。 1. することの方針の決定 技術開発室に異動と言っても、既存のチームに加入する形ではなく、私の異動とともに新たに品質チームというチームができた形でした。 そのため、着手可能な状態の具体的なタスクがあるわけではなく、何をするか、どんな優先順位で進めていくかから決めていく必要がありました。 チームができた背景としては、品質面の問題は開発組織として把握しつつも、これまでどうしても対応が後回しになってしまっており、特にY
日々何気なくお世話になっている VPC 含むネットワークは、ちゃんと理解しようとすると思ったより多い情報量と、それに対するパターンの経験が必要になります。 私自身、正直ネットワークのお話は好きじゃないのですが、現行の事情を踏まえてこの辺の基本と雑学を振り返っておくと、技術力のベースが整ってよろしいのではと思って整理することにしました。 はじめに 新年度なので、学習教材シリーズです。今回はネットワーク周りで、基礎に味付けするような内容です。もしかしたらお嫌いなジャンルでしょうか、でも少しだけやりましょうそうしましょう。 関連情報としては、このあたり。 公式 ENOG81: AWSのIPv6とPublic IPv4のおはなし – Speaker Deck Amazon VPC とは? – Amazon Virtual Private Cloud 外道父の匠 AWS VPCルーティングの基本から
はじめに エンジニアとして就職する前に読んだ「なれる!SE 2週間でわかる?SE入門」の内容があまりにも厳しく、業界に就職するのが怖くなったことを覚えています。本の中に登場する中学生の少女にしか見えない凄腕のSE、室見立華さんのような人物は現実には存在しないでしょうが、実際の業界には彼女のような凄腕エンジニアや年齢不相応な技術力を持つ人間も確かに存在します。 なれる！SE ２週間でわかる？ＳＥ入門 (電撃文庫) 作者:夏海 公司,IxyKADOKAWAAmazon SREの探求『Becoming SRE』の内容紹介 私は「なれる!SE」が好きすぎるあまり、「なれる!SRE」というタイトルのクソみたいな文章を吐き出したこともありましたが、そのクオリティがあまりにも低かったため、外には公開せずに留めておきました。そんな中、SREの探求の原著者であるDavid Blank-Edelman(ott
はじめに Eight Androidチームのチームリーダーの山本です。 私たちのチームでは2024年6月から新たにテックリードのポジションを設け、2024年4月入社のメンバーにその役割を担ってもらっています。 それまでEight Androidチームに明確なテックリードのポジションはなく、チームリーダーである自身が暗黙のうちにその役割を兼務している状態でした。今回、新たにテックリードのポジションを設けるに当たり、考えたことをまとめます。 背景 これまでチームでは2つの取り組みでアーキテクチャの検討と、新技術導入や技術的負債の改善を行ってきました。 技術基盤改善 新技術導入や技術的負債の改善を行う 週に1回2時間の時間をかける チーム全員が作業する アーキテクチャ検討会 レビューなどで発生した汎用的な技術的な論点や、大きなアーキテクチャ変更の話題を扱う 週に1回2時間の時間をかける チーム全
はじめに 本書『Observability Engineering』は、複雑化の一途をたどる現代のソフトウェアシステムに立ち向かうための、強力な武器となる一冊であり本稿はその読書感想文です。Observability Engineering を今から知りたい方はもちろん、Observability Engineering の基礎を改めて学びたい方もぜひお読みください。この記事もかなりの長さになるので普通に書籍を読んだほうがいいかもです learning.oreilly.com 「Observability:可観測性」という言葉は、近年ソフトウェアエンジニアリングの世界で大きな注目を集めています。しかし、その概念の本質を理解し、実践に移すことは容易ではありません。 本書は、そのオブザーバビリティについて、その基本的な考え方から、具体的な実装方法、そして組織への適用まで、幅広くかつ深く解説して
理想のUIをめざして！Webでハーフモーダルを作って磨き上げた話 - Tabelog Tech Blog
こんにちは！飲食店システム開発部オーダーチームの開発エンジニアを担当している堀口です。 食べログオーダーは、レストランでの飲食体験をより快適にするためのモバイルオーダーシステムです。飲食店に来店したお客様が自身のスマートフォンを使用してQRコードを読み取り、Web上でメニューをカートに追加し注文することができます。メニュー選択や注文操作はWebでありながら、ハーフモーダルを使用したネイティブアプリのような注文体験ができます。 この記事では、モバイルオーダーシステムのUI改善に焦点を当てます。ハーフモーダルの採用がどのようにして決定されたのか、その開発プロセス、そして実際に達成された改善点について詳しく掘り下げていきます。Reactを使用したフロントエンド開発で遭遇した課題と、それらをどのように解決したかの具体例を紹介します。 目次 なぜ「ハーフモーダル」を採用したか ハーフモーダルの導入と
形状認識処理のディレクターを務めている寺田です。昨年10月よりDTダイナミクス（ミスミグループ出資の戦略的IT子会社）のお世話になっています。 私が入社した時点では meviy の形状認識はすべて C++ で書かれていましたが、そこに Rust を導入したというお話です。 Rust で何作ったの？ ゴチャゴチャと御託を並べる前に、まずは Rust で何を作ったのかを簡単に紹介しましょう。 大きく分けて下記の3領域に Rust を導入しました。 溶接リモデル機能 平板展開機能 自動テストツール ここでは先頭の「溶接リモデル」について簡単に紹介します。 この機能の内部実装を C++ から Rust に置き換えて、またロジックも大きく変更することによって、溜まっていた不具合を大幅に解消しました。 溶接リモデルとは 溶接リモデル 上図の左がリモデル前、右がリモデル後です。 板金製品は、平らな板金材
こんにちは。エンジニアリンググループの武井です。 私は現在、デジカルチームに所属し、クラウド電子カルテ、エムスリーデジカルの開発に携わっています。 昨年夏にエムスリーに入社し、早くも半年が経過しました。 digikar.co.jp この記事では、私が入社してから4ヶ月目に取り組んだ、バッチ処理の運用改善について振り返ります。 特に、新しくチームに加わったメンバーとして意識した点に焦点を当ててみたいと思います。 これから新しいチームに参加する方の参考になれば幸いです。 改善したバッチ 現状の正確な理解 現状に馴染む技術選定 自分なりの+αを加える 改善の結果 We're hiring 改善したバッチ 今回の改善対象は、特定の医療機関に紐づく全患者の全カルテをPDFファイルとして出力する、というバッチです。 デジカルのデータを医療機関側にエクスポートする用途で使われています。 移行前のアーキテ
『アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明』は不明瞭 ~書籍「Impact Engineering」を読んでみた感想 ~ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 「アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明」 という記事が話題になっています。 言及している著書がCEOを務めているイギリスの調査・コンサル会社であるEngpraxが挙げている元の記事はこちら（その調査自体を行なったのもEngprax社） 記事に書かれていることの考察や要約は下記で分かりやすく纏めて下さっています。 記事への反応 記事への感想・反応はだいたい下記のパターンのどれかに該当すると思います。 失敗の定義は？ そもそもアジャイルできてなくね？ 下記が失敗するのはアジャイル
アジャイル開発やスクラムにもマネジメントは必要だ
Photo by Pixabay on Pexels.com 最近、よくお客さま向けに「アジャイル開発やスクラムにも、マネジメントやプロジェクトマネジメントは必要だ」と話すことが多い。事の背景はこんな感じ。 背景 よくあるのが「アジャイルチームは自律して動くからマネージャはいらない」という意見だ。この意見はおおむね正しいと思う。「おおむね」の理由は、マネージャという役割は自律型組織にとって必要なくなってくるだろうけど、マネジメントという仕事はなくならないからだ。 会社全体が自律型であれば、もしかしたらマネジメントすらいらなくなるのかもしれない。ただ、ほとんどの組織がそうではないのが現状だろう。よって、四半期ごとに目標設定と評価が発生するし、人材を採用したり育成する計画は必要だし、予算管理や体制変更も検討しなければならない。 こんな状況から「マネージャとマネジメント」を引っこ抜いてもうまくい
マイクロサービス化するならリビルドで！ビジネスロジックをGoで書き直してわかったこと - MonotaRO Tech Blog
この記事では モノタロウがGoとprotobufで進める爆速マイクロサービス開発とそれを支えるプロセス - MonotaRO Tech Blog のうち、主にアーキテクチャにおける詳細について紹介します。 自己紹介 マイクロサービス化について 課題を認識する スコープと技術選定 ゴールイメージを共有する 既存コードから分かった問題点 曖昧なデータ構造 処理フローの混在 アドホックなデータ取得 効果的な改善を行う 処理フローを分割する N+1問題とロジックの独立性を考慮した設計 安全に移行する 実行時のデータを取る 新旧比較による検証 まとめ 自己紹介 藤本 洋一 プラットフォームエンジニアリング部門 CTO-Officeグループ AVLチーム 楽天、SaaSベンチャーを経て、モノタロウに入社してマイクロサービス化にとりくむエンジニアの話 2019年5月入社。商品検索基盤のマイクロサービスと
2017年12月に大学院を退学し、当時1期目のHERPというスタートアップにソフトウェアエンジニアとして入社した。当時はだいたい3〜4年働いて転職するのかな〜と考えていたナメた若者だったが、気付いたらもう7年も働いている。 1期目のスタートアップに新卒入社した事例は（自分で言うのもなんだが）珍しいと思うので、現時点での自分や組織の振り返りや思いを記してみる。あくまで僕視点での振り返りであり会社公式のものではない。また、そもそもスタートアップは千差万別だし運の要素もかなり多いので生存バイアスも多分に含まれていて再現性は多分ない。それでも、スタートアップという生き方の楽しさと苦しさには何らか共通するところはあると思うので、それを記録しておきたい。 入社してから何をしてきたのか入社にいたるまでの思いの変遷については、最近会社のインタビューを受けた際に色々恥ずかしいことを十分語っているので割愛する
開発生産性の現在地を開発生産性の歴史と開発生産性Conference2024から振り返る - Tabelog Tech Blog
目次 目次 はじめに 開発生産性の歴史 工業製品のコスト管理 (1950~1970年代) 工業製品とサービス業の収益増加 (1980~2000年代) ITサービスの開発生産性 (2010年代~) 2024年現在の開発生産性 開発生産性の経営視点での構造化 B-1 プロセス改善 B-2 ソフトウェア化 B-3 技術的負債 B-4 開発者体験 2024年時点での開発生産性の現在地 まとめ 【採用】開発生産性の歴史を一緒に作りませんか？ 参考文献 はじめに 食べログ開発本部、品質管理室で室長をしている荻野です。近年ITサービス業界では、ビジネスを取り巻く変化に迅速に対応するため、アジャイル開発やDevOpsなどの開発プラクティスが普及し、開発生産性に関する議論が活発化しています1。 このブログ記事では、開発生産性の歴史をアジャイル開発の源流である日本の製造業まで遡って振り返った上で、開発生産性C
こんにちは。食べログでAndroidアプリのテックリードをしているsadaです。 今回は食べログAndroidアプリの自動テスト戦略についてご紹介したいと思います。 目次 そもそもテストコードはなぜ必要なのか テストコードにおいて大事なこと 自動テストの信頼性 できるだけ早い段階で検出する 継続的な保守 食べログAndroidアプリの自動テスト戦略 テストコードを書く文化を根付かせる 一番欲しいフィードバックを考える バランスよく積み上げられる 実際進めてどうなったか まずはSmallテスト主軸に 次にMediumテストでカバー範囲を広げる 今後の展望 Largeテストを作り、手動テストを減らしていく フィードバックを早める テストの信頼性をより高める まとめ そもそもテストコードはなぜ必要なのか まず自動テスト戦略のお話をする前に、テストコードがなぜ必要なのかについて考えてみましょう。
食べログの実践事例に学ぶ：プロジェクト進行におけるスピードと品質を保つ段取り - Tabelog Tech Blog
はじめに こんにちは。食べログ開発本部 ウェブ開発1部の大橋と中村です。 私たちは食べログのサーバーサイドの開発を担当しており、今回食べログで利用している決済システムの機能拡張に伴うリプレイスを行いました。 今回のプロジェクトを進めていて特に感じたのが「ステークホルダーが多いプロジェクトほどスピードと品質が手を動かす前の段取りの良さによって決まる」ということです。 本記事では実際に行った決済システムのリプレイスを事例に段取りがプロジェクトの品質および開発スピードにいかに寄与するのかを紹介します。 段取りの重要性 この章からは段取りの内容についてお話しします。 段取りができているとは下記3つの状態だと考えています。 業務や要件、実際の利用シーンが決まっている アサインするチーム・ステークホルダーが決まっている チームの間でシステムやデータの責務が明確になっている 段取りは序章でお話しした通り
後回しにしない組織はどう作る？論文『銀の弾丸』から紐解く「あの時やっておけば」と決別する方法【ログラスVPoE伊藤】 | レバテックラボ（レバテックLAB）
TOPインタビュー後回しにしない組織はどう作る？論文『銀の弾丸』から紐解く「あの時やっておけば」と決別する方法【ログラスVPoE伊藤】 株式会社ログラス 開発本部長／事業執行役員VPoE 伊藤 博志 ゴールドマン・サックスのテクノロジー部に新卒入社後、同社の機関システム開発に従事。その後、VP/Senior Engineerとしてプラットフォーム開発に携わり、同社発のJavaのOSSであるEclipse Collectionsのコミッター兼プロジェクトリードやOpenJDKへのコントリビュートを行うなど、OSS戦略を牽引。スタートアップ2社を経て、READYFORに入社し執行役員VPoEに就任。同社のエンジニア組織の10名から30名規模への成長、決済基盤の刷新や、技術的負債の返済、新規プロダクト開発を牽引。2022年10月に株式会社ログラスの開発部へエンジニアとして入社。エンジニアリングマ
この文書についてこの文書は、ソフトウェアエンジニアの生産性（アウトプット）を、複式簿記のような仕組みで表現・管理できないだろうか、というアイディアを発散させているものである。 発散はさせているけど、まとまっていないし課題も山積みな感じである😑 概要複式簿記のような仕組みで、ソフトウェアエンジニアの活動を表せないだろうか。 背景 社会人9年目にして、クラウド会計システムの開発に関わるようになって初めて複式簿記を学んで、シンプルながらよくできているなぁとその仕組にとても感動した。 一方で、ソフトウェアエンジニアとして、時にはチームリーダーやマネージャーとして働いていて、ソフトウェアエンジニアの生産性をうまいこと表したり管理したりできないだろうかとずっと考えていた。 そこでふと思いついた。複式簿記のような形でソフトウェアエンジニアの仕事（アウトプット）を表したり管理したりできないだろうか、と。
「顧客志向」を中心とした開発戦略と取り組み 【ラクス イベントレポートまとめ】 - RAKUS Developers Blog | ラクス エンジニアブログ
8/7(水)にRAKUS TechConference（以下TechCon）が開催され、盛況のうちに閉会しました。本記事ではその様子を、TechConを開催する目的や背景、当日発表資料なども交えながらご紹介します！ TechConとは？ TechConの開催目的 今年のテーマは「顧客志向」 ラクスの開発組織にとって「顧客志向」とは なぜ「顧客志向」をテーマに選んだのか？ イベント概要 発表の紹介 「顧客志向」の開発組織 マルチプロダクトでのプロダクトマネージャーのリアル 拡大するマルチプロダクトSaaSの顧客理解にデザイン組織はどう取り組んでいるか 急成長する大規模プロダクト開発のマネジメント課題とアプローチ パフォーマンス向上とリソース管理のためのアプローチ 急成長するサービスを支えるためのインフラ戦略 楽楽精算のQA改革～楽楽精算でのQA専門組織の実践と成功事例 新たな顧客課題に挑む1
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 不確実性の多いソフトウェアプロジェクトでは、単純な「いつ終わる？」ではなく、「どの確率でいつ終わる？」という問いが鍵になります。この記事では、確率分布を用いて納期予測の難しさや不確実性を捉え直し、スコープクリープやベロシティ安定化の重要性を考察します。 また、スクラムのようなフレームワークを採用したチームにおいて、モンテカルロシミュレーションを用いて終了確率を予想するWeb上で使えるツールを開発し、誰もが使える形で公開しました。 これらを用いて、単なる点の見積もりから一歩進んだ、現実的かつリスクを見据えたビジネス上のコミュニケ
こんにちは、DevRelブロックのikkouです。2024年5月15日から17日の3日間にわたり沖縄県は那覇市で「RubyKaigi 2024」が開催されました。ZOZOは例年同様プラチナスポンサーとして協賛し、スポンサーブースを出展しました。 technote.zozo.com ZOZOとWEARとRubyKaigi エンジニアによるセッション紹介 Generating a custom SDK for your web service or Rails API Namespace, What and Why YJIT Makes Rails 1.7x Faster Using Ruby in the browser is wonderful. An adventure of Happy Eyeballs Embedding it into Ruby code Unlocking Pot
このアップデートは開発組織全体に影響を及ぼすため、QAスケジュールやリリーススケジュールをあらかじめ調整していました。 またアルダグラムではユニットテストやE2E、VRTなどを整備してはいるものの、フロントエンドの根幹となるライブラリをアップデートするため、全体的にQAした方が良いのでは？という考えに至り、QAチームとも連携し、アップデートに関する品質保証体制を固めました。 なぜ一気に上げることなったのか？ 嬉しいことに目標としていたライブラリのアップデートが想定よりも早く終わりました。 そのため全体QAまでに一定の期間が開くことになりました。 （さてこの期間で何をするか・・・） （通常のSRE業務に戻ろうか・・・） （なんか他のライブラリも最新版バージョンと乖離があるものがかなり多いな・・・） （この後、全体のQAを行うし、他のライブラリもバージョンアップして技術的負債を一気に解消しよう
事業と技術のバイリンガル集団を目指して - DX事業本部が描くエンジニアの事業貢献モデル - - Speee DEVELOPER BLOG
どうも。デジタルトランスフォーメーション事業本部 (以下、DX事業本部)エンジニアリングマネージャーの石井です。 前回、エンジニアとして事業に貢献するとは「Why-What-Howの一貫性を保ちながら、技術意思決定を積み重ねること」である という記事を書かせていただきました。 この当時は主に1つの事業に軸足を置いて活動をしていたのですが、現在は関わる事業も増え、DX事業本部横断の開発基盤チームと4つの事業の開発責任者を務めております。 今回は2年弱経ち、私自身の役割も変化した中で、改めて「SpeeeのDXエンジニアに求められる事業貢献や成果とは何か、またその魅力とは何か」について言語化したいと思います。 DXエンジニアに求められる事業貢献と成果について 成果とは何ぞや まず前提として、我々は一人ひとりが大きな成果 (事業にとって必要かつその人にとって大きな成果)を出すことにこだわっています
「空振りをし続ける」技術広報活動の環境整備
「ビットキー知ってます！〇〇カンファレンスにスポンサーされてましたよね！」 「この前ビットキーの方が登壇してるのみました！」 「あー、あのスマートロックのとこ！」 初めまして！株式会社ビットキーで技術広報活動を担当しているパウリです！ 一昨年あたりからビットキーは技術広報活動に力を入れており、私が参画した2023年5月からさらにその活動量は増加しました。 その結果として、ありがたいことにスカウト返信や面談の際に、冒頭のような反応をいただけるようになってきました😊 本記事では事業会社において、技術広報活動の中で重要だと思った 「空振りをし続けること」 についてまとめてみました。 はじめに いかに自社の技術力が優れていても、適切な広報が伴わなければその価値を知ってもらうことは難しいでしょう。 ここで重要な役割を果たすのが 技術広報活動 です。 技術広報は、ただ製品を宣伝するだけではなく、エン
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[翻訳]LLMで1年間開発して学んだこと〜LLMプロダクト開発を成功に導くための実践的ガイド〜
俺が考える最強のITエンジニアキャリア戦略 - Qiita
「Tailwind CSSめっちゃ負債になりそう」はそうでもないのでは、と思っている
Web API設計実践入門 ――API仕様ファーストによるテスト駆動開発
「良いコードとは何か」で消耗するのはもうやめよう - DMM Developers Blog
『ソフトウェアアーキテクトのための意思決定術』を読んだ - Don't Repeat Yourself
2024年 俺が愛した本たち 技術書編 - じゃあ、おうちで学べる
TDDは「開発者テストのTips集」t-wada氏が改めてひも解く“本質” レバテックラボ（レバテックLAB）
Next.jsからSPAに移行し、Next.jsに戻した話 - Hello Tech
AWS VPC のネットワーク小話～Public/PrivateとIPv4/6～ | 外道父の匠
なれる!SRE - Becoming SREで学んだこと - じゃあ、おうちで学べる
テックリードのポジションを設ける際に考えたこと - Sansan Tech Blog
もう一度読むObservability Engineering - じゃあ、おうちで学べる
meviy に Rust が入りました - DTダイナミクス テックブログ
入社4ヶ月目で73時間かかるバッチ処理を7倍以上高速化した話 - エムスリーテックブログ
スタートアップに新卒で入社して7年が経ったがまだ全然楽しいし苦しいしですごい｜まざっち
食べログAndroidアプリの自動テスト戦略 - Tabelog Tech Blog
ソフトウェアエンジニアの複式生産性管理｜pandineer
「いつ終わる？」から「何パーセントで終わる？」でコミュニケーションするアジャイルプロジェクトマネジメント - Qiita
RubyKaigi 2024 参加レポート - ZOZO TECH BLOG
フロントエンドのライブラリ134個を一気にアップデートしてリリースした話