「Anthropic（Claudeを作っている会社）、開発が速すぎる」 最近、周りのエンジニアと話していると、この話題がよく出ます。僕も同じことを思っていて、いろいろ調べているうちに、単に「AIを使っているから速い」という一言では説明できない構造があることが見えてきました。 例えば、下記になります。 2026年Q1の3ヶ月で120以上の機能をリリース（18時間に1機能） エンジニア1人あたり1日約5PR（Pull Request、コードの変更を提出する単位） 社内では毎日60〜100回のリリース Claude Coworkは約10日で構築 Claude DesignはOpus 4.7のリリース翌日に公開 普通のソフトウェア開発企業の感覚からすると、明らかに異次元です。この記事では、公開されているインタビューや内部研究、関係者の発言をもとに、「なぜこんなことが可能なのか」というのを調べた限り
スクラムガイドに新たに追加された「プロダクトゴール」とは？ あるいはプロダクトゴールの設定には何が必要か？（前編） Regional Scrum Gathering Tokyo 2022 代表的なソフトウェア開発手法として知られる「スクラム」を開発したケン・シュウェイバー氏とジェフ・サザーランド氏によるスクラムの公式ガイド「スクラムガイド」。2020年11月付けの最新版には新たに「プロダクトゴール」と呼ばれる概念が導入されました。 スクラムガイドによると、プロダクトゴールはプロダクトの将来の状態を表しており、スクラムチームの⻑期的な⽬標である、と説明されています。スクラムチームにとって非常に重要なものだと位置付けられているのです。 この重要なプロダクトゴールをどのように考え、どう設定すべきなのでしょうか。 1月5日から7日までの3日間、都内およびオンラインのハイブリッドで開催されたイベント
The Patternsハイパープロダクティブチームを体系的に生み出すため9つのパタンはこちらになります。 1. Stable Teams 2. Yesterday's Weather 3. Swarming: One Piece Continuous Flow 4. Interrupt Pattern: Illigitimus Non Interruptus 5. Daily Clean Code 6. Emergency Procedure 7. Scrumming the Scrum 8. Happiness Metric 9. Teams that Finish Early Accelerate Faster https://www.scruminc.com/wp-content/uploads/2014/05/teamsthatfinishearlyacceleratefaste
みなさんこんにちは。@ryuzeeです。 昨年12月に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 アジャイルコーチや技術顧問の仕事は多岐にわたりますが、その1つに社内での講演やセミナーがあります。 今回、技術顧問先のイベントで登壇しましたので、その際の資料を公開します。 アジャイルとは直接関係ないものも多々含まれていますが、ネタということでご了承ください。 アジャイル全般QCDSを同時にすべて固定することはできない要件の決まったものを早く・安く作る方法ではない開発だけをアジャイルにしても意味がないアジャイルで請負契約は無理だと心得ようすべてがアジャイルに適しているわけではない大規模アジャイルは小さなアジャイルの成功後アジャイル導入を支援しようアジャイル推進での組織的な課題に取り組もう無駄な社内プロセスを廃止するよう働きかけよう効率ではなく成果に着目した組織設計をし
本件は実装に漏れがあった状態で放置してしまっていました。お客様に多大な迷惑をかける前に防ぐことができず、申し訳ございませんでした。 今回の事象が発覚してすぐに総点検・改修プロジェクトが開始され、調査と改修を行っていきました。 こういったことが起こった時にすぐに調査できるようにBigQueryの導入を進めていたり、リファクタリングデーの設定により古いソースコードにも目を触れる機会を作っていこうとしていたのですが、いずれも間に合わず、かなり悔しい思いをしました。 しかしそんな中でも各メンバーが頑張り、1つずつ問題を解消していき、何とか終わらせることができました。こんな大変な状況でも対応をし続けてくれた人には本当に感謝の気持ちでいっぱいです。 セキュリティ対策で唯一間に合ったと言えるのはKENROの導入でした。 KENROは新卒＋希望者の人に受けてもらいましたが、KENROで得た知識を今回のプロ
LINEのクライアントアプリ開発チームの効率化事例竹下秀則氏：みなさん、こんにちは。今日は「大規模クライアントアプリ開発チームの生産性を改善した仕組み化の数々」というタイトルでお話しします。LINE福岡開発1室所属のエンジニアリングマネージャー、竹下と申します。よろしくお願いいたします。 さっそくですが、本日のアジェンダはこちらになります。まずは私がマネージャーとして所属している、今日お話しする改善の舞台となったチームについて紹介します。 次にそこで直面した課題の数々について赤裸々にお話しいたします。それから、その課題に対してどのような改善策を、どうやってチームに適用したかについて、そして最後にまとめと今後の課題についてお話しいたします。 ではチームについてご紹介します。私たちチームが開発に携わっているLINEクライアントアプリはグローバル5拠点で開発しており、iOS、Android合わせ
みなさんこんにちは。@ryuzeeです。 12月1日に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 スクラムの認定コースでも基礎的なコースでも、よく聞かれるのが大規模の場合の対応についてです。 そこで、今日は大規模の場合の選択肢になりそうな大規模アジャイルフレームワークを紹介します。 紹介しますが、最初に大事なことをお伝えしてから紹介します。 そんなにたくさん作っても使わない2019年にプロダクトマネジメント関連のSaaS企業であるPendoが行った調査によると、ソフトウェアプロダクトにおいて平均的な機能の利用状況は次のようになったそうです。 まったく使わない: 24%ほとんど使わない: 56%よく使う: 8%いつも使う: 12%つまり80%の機能はほとんど、もしくは、まったく使われないということになります。 たくさんの人を集めて、たくさんの機能を作るのは、ムダであ
ということです。 ※約1万字あり、また各章について深く掘り下げる項目は別記事を添付しています。そのため、モバイルで通読するにはすこし骨が折れるかもしれません。気になる章をピックアップしてお読みいただければと思います。 目次 1. はじめに 2. 要件定義とはなにか 2.1. ソフトウェア開発ライフサイクルの全体像 2.2. 要件定義の役割 2.3. 要件定義が肝である 3. 完璧な要件定義など幻想である 4. なぜ要件定義は不完全なのか 4.1. 要求は変化し続ける 4.2. 時間軸を考慮する必要がある 4.3. 一人の力には限界がある 5. 良い要件定義とは 5.1. UXから逆算する 5.2. 削ぎ落とす 5.3. 個ではなく、チームで作る 5.4. レビューを徹底する 5.5. 3つのシナリオを想定する 6. おわりに 1. はじめに 株式会社じげんの廣瀬です。 企画マーケティングユ
フロントエンドエンジニアの仕事内容や業務事例、働く環境などについて紹介する「LINEフロントエンドエンジニア採用説明会」。そこでフロントエンド開発センターUIT1室の佐藤氏が、「LIFF」の開発について共有しました。 自己紹介佐藤信吾氏：それでは「LIFFのJavaScript SDK開発チームの紹介」ということでお話しします。どうぞよろしくお願いします。 まずは自己紹介させてください。佐藤信吾と言います。ソフトウェア開発者です。2020年にLINEに入社し、フロントエンド開発センターのDev7というチームに所属しており、現在は「LIFF」というデベロッパープロダクトのJavaScript SDK（Software Development Kit）の開発周りを担当しています。 LIFFについてでは、さっそくLIFFについて簡単に紹介します。LIFFは、LINEが提供するLINEのクライアン
スクワッド体制における留意点として、**「Spotifyは "Spotifyモデル "を使っていない [3]」**で以下のように述べられているように、単に方法論を真似るのではく、自分の組織と向き合い、学習して、進化し続けることが大切であると思います。READYFORにおいても日々、組織体制について議論し、改善を進めています。 ビジネスユニット、部門、チーム、マネージャーは、Spotifyの失敗した方法論に固執してはいけません。彼らはSptifyのモノマネよりも効果的に組織構造の役割と責任を伝えることができるのです。 あなたがSpotify Modelを見つけたのは、自分のチームをどのように構成するかをいつも考えていたからでしょう。でもここで止まってはいけません。学習を続けてください。 1-2. READYFORのスクワッド体制 READYFORの場合、どのようなスクワッド体制を敷いているか
Talked at Cloud Native Lounge #2「クラウドネイティブなシステムの継続的改善と企業文化」. https://forkwell.connpass.com/event/215798/
この記事について CaSEというPodcastを時々聴いているのだけど、その最新話がTeam Topologiesの著者であるManuel Pais氏のゲスト回だった。すごく学びが多く、同じ悩みをもつ人も多いと思ったので内容や思考を整理してみたものを記事化してみた。ちなみに書籍のTeam Topologiesは読んでいません。 “two pizza” チームの挑戦 話はAmazon CTOのVerner Vogelのインタビューから始まる。2006年頃にジェフベゾスがTwo pizzaチームの話をしたのは有名だが、面白いのはAWSはまさにプラットフォームチームをX as a Serviceモードにした結果になっていて、意図的ではないにしろトポロジーを体現していたのだと思った。これは後半のプラットフォームチームの話にも繋がってくる 本題に戻ると、Two pizzaサイズで自己組織化に向かった
2015年10月入社でコアエンジンチームの@kompiroと申します。普段は下記の３つの業務に従事しています。 お客様が自社の情報を把握するためのデータアグリゲーション機能の開発 マイクロサービスに切り出したデータアグリゲーション機能をEKSに移行 チーム横断で開発者のみんなが開発しやすい環境の構築 そんな私ですが、最近しくじり開拓者のつどいという社内イベントを開催しています。これは障害対応の一環として始めたイベントです。今日はしくじり開拓者のつどいというイベントをみなさまに紹介するとともに、背景となる障害に対する考え方と障害対応の流れを解説します！ freeeの開発文化と障害対応 freeeの開発文化 こちら弊社の紹介スライドからの引用です。 freeeのエンジニアチームが大切にする開発文化が言語化されたものが 失敗して攻めよう 何でもやれる、何でもやる 必殺技 カッとしてシュッとやる
はじめにフューチャー夏の自由研究2021の9回目です。こんにちは、TIG DXユニットの西田と申します。 業務で GCP のインフラの設計/構築/運用を担当しております。私が感じている『GCP の特徴』というと、Gartner の Magic Quadrant などでも毎回紹介されているデータ分析領域だと思っています。 そのため今回は、 Google社が買収したLookerという技術の簡単な紹介 そして、それを使うとなった場合、何が必要になるか？ Looker を採用するメリットに関しては本記事では特に触れません。 経営層から、使う事が決定された前提での話になっています。 という事を考察してみます。 本記事はあくまでも自由研究であり、私自身は Looker の運用経験はない中での私の主観がメインです。そこは最初に申し上げておきますが、ご容赦ください🙇 Looker とは？概略Gartne
背景SRE という概念が生まれてから数多くの開発チームで「ソフトウェアエンジニアリングの手法で運用を改善する営み」が行われてきた。 同時に、技術的負債が経営レベルで認知されるようになり、日常の会話の中でも長期・短期のトレードオフを念頭に置いたプロジェクト推進がやりやすくなったのは言うまでもない。 しかし、スタートアップでは Dev と Ops が別れていることは稀で、「全員が全てに対応する」ような状況になってしまうことがしばしばある。これは小さい組織だけの問題ではなく、例えば大企業の中の新しいプロダクト開発チームでも同じことが言える。 SRE を念頭に置き、技術的負債の主導権を握るために必要なチーム体制とはどういうものなのだろうか？ タスクの分解小さな組織のソフトウェアエンジニアは日々数多くのタスクを与えられている。場合によっては数名のメンバーで新規機能開発から日々の不具合修正、そして S
すごい開発チーム育成ハンドブック プロダクト開発の｢やること｣リストはTrelloで順序立てておくとうまくいく ビジネス上の要求が変化しやすいときは、タスクの優先順位を2週間変えないようにする ビデオ会議で遠方チームに「伝わらない」と思ったら、一度「顔合わせ会」を開催する 「これは使えない」と言われたら、機能の意思決定を「担当者」に委ねる エンジニアに期間が「わからない」と言われたらタスクを細分化して具体的に 仕様を考えるときはエンジニアと対話する 開発チームの開発速度がわからないときは、短い期間で速度を計測する 開発状況を把握できないときはスクラムで開発する 「Scrum for Trello」でストーリーポイントをチームで共有する やってみないと分からないタスクは調査する スクラムが定着しないときは、2日のスプリントで慣らす ストーリーポイントの見積もりは「比べる」が基本 ストーリーポ
クラウドネイティブ技術を日本にも浸透させることを目的に開催された「CLOUDNATIVE DAYS Spring 2021 ONLINE」。ここでGMOペイメントゲートウェイ株式会社の駒井氏が登壇。「計画と統制の文化にクラウドネイティブの種をまく」をテーマに、レジェンドのジレンマを脱出し、クラウドネイティブの芽が出た体験談について紹介します。 セッションの概要駒井直氏（以下、駒井）：「計画と統制の文化にクラウドネイティブの種をまく」というタイトルで、この時間はお送りしたいと思います。 ちょっと想像してください。あなたはこう言われます。「現状の決済システムには、キャパシティの硬直化や、密結合なモノリスのアプリなど、アーキテクチャに起因して、将来のスケールを阻害しそうな要因がある。これを、クラウドネイティブアーキテクチャのアプローチで解決できないか」と。「あなたが、そういうエンジニアリングをリ
ソフトウェアエンジニアとしての働き方を探求してきた経験と、駐在員として文化の狭間でうろちょろしてきた経験、OSSエンジニアとして多数の多様な人材と交流してきた経験をもとに、果敢にも内製化に挑戦する知人へのアドバイスを気持ちまとめます。 前提 主な利用技術にはJava（Spring Framework）やTypeScriptを想定 FaaSを始めとしたManaged Serviceは（いまのところ）積極採用しない構え Digital Transformationを推し進める一環としての内製化に、エンジニアリングの観点から挑む方を読み手として想定 内製化のターゲットは決まっているか心当たりがある状態 既存の開発チームはほぼ無い想定 1. チームビルディング 1.1. スーツとギークの対立を避ける 我々が若かった頃は"スーツ"と"ギーク"の対立を煽る風潮にありました。Rockstar Engin
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
