サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
Google I/O
agilejourney.uzabase.com
年度末の予算成立に向けて仕様書を固め、入札を経て、要件に合わせたシステムをウォーターフォール方式で開発していく──そんな進め方が一般的だった自治体のシステム開発のあり方が、近年変わりつつあります。 中でも大きな反響を呼んだのが、2022年から2023年にかけての東京都の取り組みです。社会情勢の急速な変化に対応し、限られたリソースで現場のニーズにマッチしたシステムを迅速に実現するため、アジャイル方式を採用して4つのプロジェクトを遂行。さらに、そこで得られた知見をクローズドにせず、「アジャイル型開発プレイブック」として広く公開するまでが、都にとって初となる挑戦の全容でした。 ただ、いくらアジャイルやスクラムといった手法や考え方を採っても、内製体制が整っていない組織の場合、発注する側だけでは完結しません。 一連の東京都のプロジェクトの委託を受け、前例のない取り組みを一体となって並走したスパイスフ
developers.gnavi.co.jp
こんにちは。ネット予約システムの開発担当チームに所属しているたかいです。 私たちの開発チームは、現在完全リモートワーク体制で開発を行っています。通勤時間がなくなり、個人の集中時間を確保しやすいというメリットがある反面、チーム内のコミュニケーションにおいては「オフィス時代と同じようにはいかない」という課題に直面しました。 今回は、私たちがリモートワーク下で直面した課題と、それを解決するために「意図的に」設計したコミュニケーション施策について紹介します。 目次 目次 リモートワークにおける「自然なコミュニケーション」の限界 私たちのチームが実践した施策 1. バーチャルオフィスとGoogle Meetの臨機応変な使い分け 2. 隔週30分の「プライベートメインの振り返り」 3. 毎日15時の「集合タイム」 4. 双方向に気づきがある、新メンバー向けの「なんでも会」 5. 雑談用Slackチャン
speakerdeck.com/ryuichi1208
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
speakerdeck.com/nihonbuson
Scrum Fest Niigata 2026での登壇資料です。 【発表資料中のURL】 ◆P4 ・B-Testing
speakerdeck.com/twada
2026年のソフトウェア開発を考える（2026/05版） Scrum Fest Niigata 2026 2026年5月8日（金） https://www.scrumfestniigata.org/
www.ryuzee.com
みなさんこんにちは。@ryuzeeです。 2026年3月4日に新刊の訳書『Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方』がオライリー・ジャパンから発売になりましたのでよろしくお願いします。 本記事は、先日Xに書いた記事の転載です。 プロダクトの開発に生成AIを使うようになって、新機能の追加が以前と比べて素早く簡単になりました。 目先はそれでよいこともありますが、新機能の追加をずっと続けると、コードベースの劣化、認知負荷の増大、サポートコストの増加、テスト工数の増大、UI/UXの一貫性の欠如、新しいメンバーのオンボーディングの長期化など、さまざまな問題が起きるようになります。 生成AIを使うようになって、破綻までの時間が短くなった、なんて言われたりもしていますよね。 このような問題を防ぐ唯一の方法は、不要な機能を削除することです。 拍子抜けするくらい当たり前の話
みなさんこんにちは。@ryuzeeです。 2026年3月4日に新刊の訳書『Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方』がオライリー・ジャパンから発売になりましたのでよろしくお願いします。 本記事は、先日Xに書いた記事の転載です。 先日Xで「スクラムマスターが何もしない。ふざけんな（意訳）」という話を見かけました。 確かに、何もしていないのであれば不要なんじゃないか、という気もします。 ただ、この話はいくつか論点が混ざっていそうなので、分けて見ていきましょう。 役割と責任は違うスクラムマスターの話なので、見るべきはスクラムガイドです。とりあえず擦り切れるくらい読んでください。 スクラムガイド2020年版では、今回の話に関係がある大きな改訂が行われました。 それが「責任（Accountability）」です。 スクラムガイド2017まではプロダクトオーナー、開発
ボトルネックを見つけて解消する。それで問題は解決するはずでした。 しかし実際には、別の場所にボトルネックが現れ続けます。その繰り返しの中で、問題はやがてコードや工程ではなく、「人と人の間」に移っていく。 TOC（制約理論）の考え方から出発し、複雑な組織における問題の捉え方と、「視点を動かす」という立ち振る舞いを掘り下げます。 ボトルネックを見つけたい ボトルネックが移動する 問題の種類が違う──工場から熱帯雨林へ 複雑な現場でどうするか──着眼大局、着手小局 分解した瞬間に壊れるもの 信頼貯金を育てる おわりに──視点を動かす 信頼貯金で変化に対応する ボトルネックを見つけたい 予算が足りない。時間がない。その割にやることが多過ぎる。 開発の現場で日々直面するこうした問題には、ある共通点があります。問題が「見えている」ということです。誰が見ても「ここが詰まっている」と分かる。テストが手作業
qiita.com
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 先に結論 AIを導入すると、実装スピードは確実に上がります。 ただ、チーム開発で本当に問題になるのは、コードを書く速さではなくコードを理解し、判断を共有する速さです。 今回読んだ2本の記事から得た学びを一言でまとめると、次の3つでした。 仕様書は「ずっと保守する正本」ではなく、「認識を揃えるための起点」として使う AI時代のレビューは、「細かい指摘」より「なぜその実装なのか」を確認する場になる AIが書いたコードをチームの資産にするには、「説明できる状態」を作ることが必要 「AIで実装は速くなったのに、レビューや設計はむしろしんどくなっ
speakerdeck.com/yuukiyo
AI-DLCへの段階的移行の実践 ― AI時代のスクラムイベントを再定義する ― https://levtechlab.connpass.com/event/388937/
gihyo.jp
週間アクティブユーザー300万人にのぼるCodex、OpenAI Japanの瀬良氏に聞く「開発スタイル」の変化 OpenAIが提供するコーディングエージェント「Codex」は、2026年4月7日に週間アクティブユーザー数が300万人に達したことが発表されました。この記事では、2026年4月8日に行われたOpenAI JapanのDeveloper Experience Engineer、瀬良和弘氏への取材をベースに、OpenAIの公式ブログなどの情報を交えて構成を整え、Codexが変えつつある開発スタイルを紹介します。 OpenAI Japanの瀬良氏 Codexの利用拡大 冒頭で言及したとおり、OpenAIが提供するコーディングエージェント「Codex」の利用が広がっています。2026年4月7日（US現地時間）、OpenAI CEOのSam Altman氏が、Codexの週間ア
www.youtube.com
チャンネル登録、高評価、コメントよろしくお願いします🙇 ▼ゲスト ・和田卓人 | プログラマ、テスト駆動開発者 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。 『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『テスト駆動開発』（オーム社、2017）翻訳。『事業をエンジニアリングする技術者たち』（ラムダノート、2022）編者。『SQLアンチパターン第2版』（オライリージャパン、2025）監訳。テストライブラリ power-assert-js 作者。 X： https://x.com/t_wada GitHub: @twada Bluesky: @twada ▼MC 蜂須賀 大貴 | テクノロジーメディア「Newbee」代表 メディア・エンタメにずっ
tech.smarthr.jp
こんにちは、SmartHRでアジャイルコーチをしている@wassanです。 AI時代、多くのチームでプロセスにAIを統合する試行錯誤が行われています。成果につなげられるチームが出てきている一方で、活用がごく一部にとどまっているチームもあるのではないでしょうか。Qodo AIの調査では78%の組織がAIを活用しているにもかかわらず、そのうち80%が期待する成果を出せていないというデータがあるそうです（出典：Qodo AI, 2025, State of AI code quality in 2025）。 この「生成AIパラドックス」にどう向き合うか。そのヒントとなるのが、スクラムの生みの親であるジェフ・サザーランド博士とスクラムトレーナーのラルフ・ヨッハムが、2026年1月に公開した「AIとスクラム」 です。スクラムガイドをプロダクト開発の視点で補足する「拡張版シリーズ（Scrum Guid
zenn.dev/pdfractal
はじめに ウォーターフォール開発は、要件定義書、基本設計書、詳細設計書、テスト仕様書、受入条件といった文書体系によって語られがちです。たしかにそれらは必要です。しかし、実際の大型案件が前へ進んだ理由を観察すると、中心にあったのは紙そのものではなく、紙に書き切れない判断、政治調整、優先順位づけ、そして誰かが引き受ける非文書の責任でした。ロイス の 1970 年論文も、分析とコーディングだけでは不十分で、多くの追加工程が必要になり、それらは顧客も開発側も進んで負担したがらないため、管理はそれを売り込み、順守させる役割を持つと述べています。ここには、工程や文書だけでは回らないという事実が最初から表れています。 問題は、文書が不要だったことではありません。問題は、文書が担えるものと担えないものが混同されたことです。文書は、承認、境界、納期、受入条件、変更履歴を残すには向いています。しかし、何を捨て
zenn.dev/yuichi_dev
学べること スクラム開発の PBI を 「背景・目的・対応内容」 の3点で整理するフレームワーク エピック・PBI・タスクの階層ごとに 何を書いて何を省くか の使い分け はじめに AI（Gemini）と壁打ちしながら考えを整理した備忘録。あとで見返す用。 スクラム開発で PBI を書くとき、「＜ユーザー＞として、＜何か＞したい。それは＜価値＞のためだ。」というユーザーストーリー形式を使うのが定番とされている。 ただ、正直かったるい。 「この設定をこう変える」とだけ書けば済む話に、わざわざ「〇〇として〜」と前置きを付ける必要があるのか。プロ同士ならそれで通じるのではないか。 この疑問から壁打ちしていたら、「背景・目的・対応内容」 という3点セットに辿り着いた。 ユーザーストーリーの語源 そもそもユーザーストーリーは、ケント・ベックが1990年代のクライスラー C3 プロジェクトで導入した考え
kakehashi-dev.hatenablog.com
はじめに 今年は変化した一年だったなぁ。一番の変化というと個人の課題からチームの課題へと視座感が変わったところで、それまでは個人のスキルアップが目標のほとんどだったけど、チーム状況の変化を目の当たりにして今のままだとダメだなと感じ、チームの課題を自分の課題と思って取り組めるようになったのが大きな変化だった。 それによって主体的に動き・提案したり既存フローを変えたりして、これまでマネージャー層が現場の意見を聞きながら少しずつ調整かけていたものを現場の目線でいい感じに変えられるようになったし、実際手応えも感じることができた（あとは、変化したやり方がまだ浸透しきっていない感じはするので、文化として当たり前の状況にしていけるといいのだけれど） これは2025年末に、私がSlackに残したつぶやきです。 カケハシでAI在庫管理プロダクトの開発に携わっている清水（@_smzst）と申します。この記事で
よりよいプロダクトを作り、高い価値を届けようと、アジャイル開発のアプローチで真剣に取り組んできたのに、「なんか違うよね」「それより、もっと早くリリースできないの」といった予想外のフィードバックに直面し、立ち止まってしまう──そんな現場は珍しくないのではないでしょうか。 20年以上にわたり現場と組織の両面からアジャイルを実践し、さまざまな現場を支援してきた市谷聡啓さんは、そんな行き詰まりの原因を、個々のスキルやプロダクトではなく、チームを取り巻く「構造」にあると分析しています。 こうした「構造」を捉えながらアジャイル開発を進めていくには、どんな取り組みが必要なのでしょうか。具体的なポイントを市谷さんに伺いました。 アジャイルが成熟してきたがゆえに直面する「構造」の問題 互いの「正義」が衝突し、「正す」ことができなくなる それぞれの立ち位置を整理し、方向性を可視化する 意見が衝突したら「アクシ
tech.mirrativ.stream
こんにちは。バックエンドエンジニアのshirakawaxです。 ミラティブでは施策開発フローとしてスクラムを採用しています。 スクラム導入から数年が経ち、フローは安定してきました。その一方で「もっと良くできるはずなのに、どこから手をつければいいんだろう」という感覚がチームの中にありました。チーム内外でスクラムへの前提知識にばらつきがあり、共通の文脈を持って議論できる場を作りたい——そんな思いから、2025年2月に「スクラム勉強会」をスタートしました。 ちょうど1年が経った今、この記事では取り上げた5冊の本と、そこから生まれたチームの気づき・変化を紹介します。 なお、スクラム導入に関するテックブログもあるので、あわせてご覧ください。 tech.mirrativ.stream tech.mirrativ.stream 勉強会の形式 頻度: 週1回、30〜60分 形式: 事前に指定された箇所まで
bliki-ja.github.io
アーキテクチャデシジョンレコード（Architecture Decision Record: ADR）とは、プロダクトやエコシステムに関する重要なひとつの決定を記録および説明する簡潔な文書である。文書は短く、数ページ程度に収め、内容には決定事項、決定の背景、重要な影響を含めなければならない。決定を変更した場合は、文書を修正するのではなく、置き換えた決定にリンクしておく。 ほとんどの文書がそうであるように、ADRの作成にも2つの目的がある。まず、決定の記録である。数か月後あるいは数年後でもシステムが現在のように構築された理由を理解できる。だが、それよりも重要なのが、文書を書くことで考えが明確になる点である。グループの場合は特にそうだ。重要な文書を書くことで、異なる見解が浮かび上がってくる。こうした意見の違いについて議論し、できれば解消することが望ましい。 一般的なルールとして「逆ピラミッド」
はじめに 社内でどのようにClaude Codeを使っているのかを紹介する機会があり、その時に利用している設定をメモ程度にまとめたので、Qiitaにも残そうと思いました。 基本的に複数人で開発するのではなく、ひとりで開発することが多いため、AIに多くを任せたいと思い、設定しています。 Claude Codeの基本設定 AIに任せるスタイルで開発するにあたって、いくつか設定を調整しています。 Auto Compact OFF Auto Compactはコンテキストウィンドウが逼迫したときに自動で要約・圧縮してくれる機能ですが、OFFにしています。 長い実装セッションの途中でコンテキストが圧縮されると、それまでの設計判断や経緯が消えてしまいます。手動でコンパクトするタイミングは自分で制御したいので、OFFにしてStatuslineで残量を監視する運用にしています。 (そもそもコンテキスト長が1
zenn.dev/dp_techblog
ビジネスにおいて、何よりも重要なのは間違いなく後者の方でしょう。ゴミをいくらエレガントに作ったところでゴミなことには変わりありません。 したがって、前提としてそもそもスプリントレビューを行わない=成果の検査を行わないスクラムなどありえません。スクラムガイドにも、 スクラムフレームワークは不変である。スクラムの⼀部だけを導⼊することも可能だが、それはスクラムとは⾔えない。 このようにあるので、スプリントレビューを行わないスクラムはいわゆるScrumButと言えます。 「レビュー」では本当の意味で成果を検査できない 請負開発であれば、クライアントが「それが欲しかった!」と言ってくれればそれで成果の検査としては十分で、それ以上はないかもしれません。あるいは、「思ってたのと違う」という反応が得られることも、貴重なフィードバックとして次の計画に反映することができるでしょう。 でも、事業会社の成果は違
engineers.ntt.com
NTTドコモビジネス イノベーションセンター テクノロジー部門 MetemcyberPJでの経験を通じ、私は「自分でやり切ること」と「チームとして成果を出すこと」のバランスの重要性を学びました。若手社員でも幅広い業務に挑戦できる環境の中で、責任感を持ちながらも周囲と協力することで、個人の成長とチーム成果の両立が可能であると実感しています。この記事では、その経験から得た学びと実践のポイントを紹介します。 はじめに 若手でも幅広く挑戦できる環境 スクラムという前提 私が経験した「抱え込み」 タスクの優先順位のつけ方 最後に はじめに こんにちは。イノベーションセンター テクノロジー部門 MetemcyberPJの2年目社員、千坂知也です。 私は1年目の8月からMetemcyberPJに参画し、OSSコントリビューターとして開発業務に携わってきました。 はじめのころは主に開発コードを書くことに注
この記事のまとめ: GitHub Copilotのカスタムエージェント機能を使い、5体のAIにスクラムチームを組ませて実際にアプリを開発させた実験の全容と、やってみて感じた可能性・課題をまとめています。 AIの賢さとツールが洗練されてきました Opus4.6やGPT-5.3-Codexといった最先端のモデルが、かなり良い感じに動くようになりました。曖昧な指示でも行間を読み取ってくれるようになったと感じています。また、GitHub Copilot CLIなどツール側も改善を続けており、AIエージェント間の連携を自然言語で表現することもできるようになりました。 ここまでくると、昔から人間がやってきた手法を再現できるのではないかと思い至ります。 そう、スクラム開発プロセスです。 今回は賢くなったAIたちと洗練されたツール(GitHub Copilot CLI)でスクラム開発プロセスを実践していき
findy.co.jp
プロダクトマネジメント分野の第一人者がAI時代の顧客価値を生み続けるための実践事例や試行錯誤を解説 エンジニアプラットフォームを提供するファインディ株式会社（東京都品川区、代表取締役：山田 裕一朗、以下「当社」）は、2026年4月28日（火）に丸の内で開催する「Product Management Summit」について、参加申込者数が800名を突破したことをお知らせします。 本サミットは、PdM（プロダクトマネージャー）やCPO（最高製品責任者）、プロダクトエンジニアなど、プロダクト開発に携わる方を対象に、AI時代に顧客価値を継続的に生み出すための実践知を共有するカンファレンスです。現在も参加申し込みを受け付けています。 ◆ 申込者アンケート：課題の上位は「ユーザー理解・体験設計」と「AI・データを戦略に組み込む整理」 本サミットの申込者を対象に、「プロダクトマネジメントにおいて現在課題
こんにちは、SmartHRでアジャイルコーチをしている@wassanです。 2026年2月18日、製薬アジャイル勉強会でSmartHRにおける組織アジャイルの実践についてお話ししました。前半はスクラムのスケーリングをテーマに語りながら、後半では「感情知性」（EQ）という一見アジャイルから遠いテーマを取り上げました。会場ではこの組み合わせに違和感を覚えた方もいたかもしれません。 なぜ、スクラムのスケーリングとEQがつながるのか。当日の内容をふりかえりながら、あらためて自分の考えを整理してお伝えします。 SmartHRで起きていたこと SmartHRの労務ドメインでは2025年、急成長する組織の中で「チームの判断は正しいのに、全体がうまく機能しない」という問題が顕在化していました。各チームがそれぞれ最適な判断をしていても、全体の方向性とのズレ、チーム間依存の増大、技術的負債の蓄積が起きていたの
speakerdeck.com/takaking22
Scrum Fest Fukuoka 2026で登壇したときのスライドです。 https://confengine.com/conferences/scrum-fest-fukuoka-2026/proposal/49698/ai ■セッション概要 本セッションは、これからモブプログラミングを…
levtech.jp
株式会社アトラクタ Founder兼CTO/アジャイルコーチ 吉羽 龍太郎 アジャイル開発、DevOps、プロダクトマネジメント、組織開発を中心としたコーチングやコンサルティング、トレーニングが専門。Scrum Alliance認定スクラムトレーナー（CST）/ 認定チームコーチ(CTC)。Microsoft MVP for Azure。 野村総合研究所、Amazon Web Servicesなどを経て現職。 著書に『SCRUM BOOT CAMP THE BOOK』など、訳書に『チームトポロジー』『Tidy First?』『プロダクトマネジメント』『レガシーコードからの脱却』など多数。 AIのおかげでコーディングなどの速度が大きく向上した。では、このブーストをどう活かすべきか――。 AIが急速な進化を遂げるなか、ソフトウェア開発の領域では「AIの力を活かせる組織づくり」「AIネイティブな
zenn.dev/imudak
「Cursorで動かすのは情弱」——Xでそんな投稿を見かけました。煽り気味の物言いですが、言いたいことはわかります。Claude CodeはCLIツールなので、VS CodeやCursorを間に挟む意味がないのでは、ということです。 見かけた時、自分はそもそもVS Codeを開いていなかったので「まあそうだよな」という感想でした。ターミナルだけで開発を回している現状と、なぜそうなったかを書きます。 現在の開発環境 WSL2（Ubuntu） └── tmux ├── ウィンドウ0: claude（メインセッション） ├── ウィンドウ1: claude（サブエージェント用） ├── ウィンドウ2: claude（並列実行用） └── ウィンドウ3: ログ確認・監視 VS Codeは起動していません。外側にWindows Terminalがあるだけで、作業はすべてtmux内で完結しています。
次のページ
チーム開発の新着エントリー
ITの新着エントリー
最新ガジェットの新着エントリー
自然科学の新着エントリー
経済・金融の新着エントリー
おもしろの新着エントリー
マンガの新着エントリー
ゲームの新着エントリー
はてなブログ（総合）の新着エントリー
www.e-aidem.com
「仕事ができるビジネスパーソンになりたい」と願って努力していても、思うようにいかず、「仕事ができない自分」に自己嫌悪を抱いてしまうことはありませんか？ 今回お話を伺った編集者の井上慎平さんは、理想と現実のギャップに悩んだ経験を著書『強いビジネスパーソンを目指して鬱になった僕の 弱さ考』につづっています。 “弱さ”を持つ自分と上手に付き合いながら働くためのヒントを聞きました。 「できるふり」は命取り。挫折を認められず追い詰められた過去 周りと比べるのは当たり前。大事なのは「そんな自分も認める」こと 仕事と家庭・育児との両立も「開き直り」や「諦め」が肝心 「できるふり」は命取り。挫折を認められず追い詰められた過去 💡POINT 「特定のスキルの高さ」と「ビジネス全般の優秀さ」は別物 周囲は「できる」ことが自分にはできず、追いつこうと背伸びしていた やりがいがある環境ほど、つらい気持ちを「わが
tech.findy.co.jp
こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらっている戸田です。 生成AIが開発現場に入り込んでから1年あまり。Claude CodeやGitHub Copilotなどのエージェント型ツールも一般的になってきました。 その一方で、「AIを導入したのに、思ったほど速くなっていない」「むしろレビューが大変になった」という声を、社内外でよく聞くようになりました。 そんな中で先日、弊社主催の「AI Engineering Summit Tokyo 2026」にて 「速く作る」から「正しく作る」へ ─ 生成AI時代の開発フロー改革のロードマップと実行 ─ と題して登壇してきました。 ファインディ社内で1年強かけて見えてきた「AI導入の落とし穴」と、そこから組み立てた3段階のロードマップを共有する内容です。 ai-engineering-summit-tokyo.findy
shin-fedor.hatenablog.com
高市さんも木下さんも悪くない、が ブログ全削除案件 統一教会文書全否定案件 総務省文書全否定案件 収支報告書挿し替え疑惑案件 絶対無謬であることについて 追記：「面識」の定義について 高市さんも木下さんも悪くない、が また小泉氏や林氏への中傷（批評？ネガキャン？）動画*1がどうとかいう問題がぐだぐだになりつつも一部で燃え続けてますな～。 最初に確認すると、仮に「中傷動画」とやらが実在したとして、それは松井氏が自発的に、勝手に作ったものであり、木下秘書官は「中傷動画を作ってくれ」などとオーダーしていない。 それは当の松井氏自身が言っていることであり、つまり木下秘書官も高市さんも特に悪くないことが最初から確定している。うさんくさい・怪しい人物にプロモーションを相談した迂闊さは責められるかもしれないが、MAXでそこ止まりである。*2 が、なんでこんなに意味不明にこじれているかというと、俺たちの高
takoratta.hatenablog.com
COBOLの母と呼ばれるグレース・ホッパーが、いま生きていたら、何と言うだろう。 生成AIに曖昧な指示を投げれば、それらしく動くコードが返ってくる。いわゆるバイブコーディング、あるいはエージェンティックコーディングの様子を眺めていると、ふと、そんなことを考えてしまう。というのも、これがまさに、彼女が60年以上前に望んでいたことなのではないか、と思うからだ。 COBOLという最初の民主化 なぜそう思うのか。それを説明するには、時計を1950年代まで巻き戻す必要がある。 当時のコンピューターは、部屋を丸ごと占有するほど巨大で、しかも非常に高価だった。持てるのは軍や政府、ごく一部の大企業だけ。軍は弾道計算に、政府は国勢調査の集計に、そして企業も給与計算や在庫管理にと、この巨大な機械を使い始めていた。ただし、どの会社でも、というわけではない。プログラムを書けるのは、数学と電気工学を修めた一握りの専
はてなブログ（総合）の人気エントリーをもっと読む
このページを最初にブックマークしてみませんか？
『チーム開発』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
防衛装備庁、自爆型ドローンに対抗する「迎撃ドローン」を公募 8月下旬にも量産契約へ
光で情報を書き換える新しい磁気メモリ材料 「従来に比べ1000倍高速」 QST、兵庫県立大などが共同開発
音楽AI「Suno」3分で作曲 アバター歌手はSpotifyで300万人視聴 - 日本経済新聞
iOS 27でようやく搭載された、Androidではもはや当たり前の音量調整に関する機能とは【やじうまWatch】
【特集】 有機ELテレビをPCモニターに5年使った結果。避けられなかった焼き付きとその顛末
握って直感操作、5,680円のペン型ワイヤレスマウス。サンワサプライから
文科省、優秀な博士学生に年500万円 助教並み待遇で減少に歯止め - 日本経済新聞
数学で読み解くHaskell——入門編
慢性期の脳性まひ、乳歯幹細胞投与で改善 名大で臨床試験が進行 | Science Portal - 科学技術の最新情報サイト「サイエンスポータル」
任天堂の株価、一時8%安 「新作ソフトが期待下回る」との見方 - 日本経済新聞
高市首相はもう詰んでいる…"国会答弁でのウソ"で露呈した｢中傷動画疑惑｣よりも深刻な問題 (6ページ目)
知らなかったでは許されないぞ… 隣の家から除草剤が流れ出して、田んぼの稲が枯れ始めた話「これはさすがにひどすぎて草も生えない…」「普通に損害賠償請求案件」
パイの奪い合いといいつつ皆ピザを想像している オタク
アスパラデーモン
ゴミ箱って箱ではなくない？
TVアニメ『チー付与』ティザーPV
漫画家が、単行本を買って当選した人だけを対象としたサイン会の翌日に、ゲリラサイン会を行ったことに賛否両論「落選した地方民が報われなさすぎる」「せっかくの好意なのに」
ウリッコ - 殺野高菜/大森かなた / 第２４話 終わってる世の中で | コミックDAYS
「朧村正怪奇譚」（おぼろむらまさかいきたん）が2027年初頭に発売。Switch 2/ Switch / PS5 / PC（Steam）で展開予定
『ファイアーエムブレム 万紫千紅』9月17日発売へ。『風花雪月』路線の新作 - AUTOMATON
仕事ができる人を諦め、仕事ができない自分を受け入れる 井上慎平さんが見つけた「弱いまま」生きる方法 - りっすん by イーアイデム
「速く作る」から「正しく作る」へ ─ AI活用レベル3段階のロードマップ｜AI Engineering Summit Tokyo 2026 登壇レポート - Findy Tech Blog
グレース・ホッパーならどう言うだろう ─ COBOLの歴史から見る、民主化された後に残る仕事 - Nothing ventured, nothing gained.
