2026/7/16に、Developers Summit 2026 Summerで発表した黒田の資料になります。
2026/7/16に、Developers Summit 2026 Summerで発表した黒田の資料になります。
はじめに：問いに追い詰められる「問い疲れ」が起きている「しんどいから、もう二度と私に何がしたいのか聞かないで欲しい。そんなもの無いんですよ。過去に好きだったものとか、今ハマっていることとかをみんな聞いてくるけど、またそれ？ってうんざりします」 「人事部の施策で、ゲーム形式で理想の状態を描く研修があったんですけど、ああいうの本当に無理で、自分を深掘りする質問とかキツくて、早く終わらないかと思って過ごしていました」 キャリア相談の中で、こういった声を何度も聞いてきた。 そのたびに私は内心ひやりとしていた。 というのも、私は10年以上、問いを立てる側にいた人間だからだ。 デザイナーとして、私は新規事業の開発から組織の立ち上げ、未来洞察まで、多くのプロジェクトを通じて、さまざまな問いを立ててきた。 チーム全員の創造性を最大化するために、適切な問いを立て、効果的なアプローチを検討し、実行する。それが
自分は2020年に初めてマネージャーという役割になってしばらくの間、メンバーに寄り添う意識が強くてあまり職責を果たせていなかったと思う。「今思うと」という話で当時はそう思っていなかったのが黒歴史と言える。過去の自分のことを思い出しながら、この「メンバー思い"風"マネージャー」だった自分に向けたフィードバックを雑に書いてみる。 お前は"メンバーを守ること"が目的になっていて、経営や他部署との対立構造を自ら作ってしまっている。 たとえば、ビジネス上満たしたいリリースターゲットを共有された時、メンバーの負荷を勝手に想像して初手で噛みついてしまっているな。マネージャーとしてきちんと"断る"ことも仕事といった感じで、どこか使命感に近い感覚を持っていないか。お前がやっていることは、結果として経営との接続どころかむしろ最初のブロッカーのような立ち振る舞いにしかなっていない。 人事制度の変更アナウンスに対
可観測性ガイダンスというタイトルで登壇してきました。 イベント名: オブザーバビリティ再入門 - 大切さと高め方を知ろう！ イベントURL: https://mackerelio.connpass.com/event/316449/ # ブログでいくつかの可観測性に関する書籍のまと…
日本の大手メーカー、いわゆるJTCで課長になって4ヶ月が過ぎた。世の中でよく言われる中間管理職みは確かにあるって実感と、それを生じさせる要素や機序も少しは見えてきて面白いなって気持ちもあり、忘れないようにメモしておこうと思って。 基本情報 新卒で入社（22歳）→品質管理系の部署で係長クラス（33歳）→別の生産管理系の部署で係長クラス（37歳）→前の部署に戻って課長（39歳）、という流れ。 課の人数は自分を含めず20名いる。課には機能別ではなく、担当製品で分けた2つのグループがある。 巷間で言われる中間管理職み よく世の中で語られる中間管理職のつらさは以下のようなものがあるだろうか。 板挟みの立場：経営層と現場の間での板挟み、裁量が小さい割に責任が大きい。 心身への負担：労働時間の長さや業務負荷の高さ、プレッシャーの大きさ。 報酬面での不満：残業代のなさ、業務量や責任に対する報酬の低さ。 人
日本の古い大企業（いわゆるJTC）で課長になって1年強が経った。課長としての業務の中で一番「中間管理職み」があるのが、課員の成績評価だなと感じている。矛盾を吸収するバッファというかアブソーバーみたいな機能を明示的でない形で要求されている、この感じ。 評価ルールと、そのルールによって生じる心理やムーブについて、当事者としては苦労しつつも、こういう光景になるのは面白いなと感じていて、忘れないうちに記録しておきたい。（具体的な数値や名称は少し変えたりぼかしたりしている。） 一般社員の業績評価の方法 目標シートの作成 社員は半期ごと（4、10月）に、取り組む業務を書いた目標シートを作成。 各項目には達成基準と重み付けを設定。 達成基準は、その人の職務のレベル（後述）と照合して、「少しチャレンジング」な程度で設定。 期初に上司と面談し、内容と重み付けの妥当性をチェック。 3ヶ月（1四半期）後に再度面
2026年4月3日以降にお知らせしております「GitHubアカウントへの不正アクセス発生に関するお知らせとお詫び」に関連し、その後の詳細調査の結果、顧客情報を管理するシステムの一部において、お客様の個人情報が漏えいした可能性があることが判明いたしました。現在、当該システムにおける情報の安全確保のための措置を完了しております。 多大なるご迷惑とご心配をおかけしておりますことを、深くお詫び申し上げます。現時点で判明している事実は以下の通りです。 1. 漏えいした可能性のある個人情報について弊社は、本事案検知後、直接の不正アクセス先であるデータベースに存在した情報をもとに、弊社システムの安全性確認を網羅的に実施して参りました。その後の調査にて、2026年4月21日、弊社データベースへのアクセス並びに、内部処理の形跡が確認されました。現在のところ、お客様に関するデータファイルのダウンロードは現時点
設計書・コード・テストを全部AIに書かせて半年間開発してみたよ 1. はじめに 本記事は、私のチームが半年間AIネイティブ開発を行った経験とその感想をまとめたものです。 AIネイティブ開発とは、AI技術を活用してソフトウェア開発を行うことを指します。2025/10～2026/3の期間中、私たちはお客様に納品するシステムをAIネイティブで開発しました。その経験と私なりに感じたことをまとめてみました。 ※ なお、私の取組は全社的な取組とは関係ありません。 ※ あくまで、私のチームが独自に行っている取組ですので、その点はご留意ください。 2. 自己紹介 初めてテックブログに記事を書くので、簡単な自己紹介を。 名前：茂呂範（もろすすむ） 所属：株式会社NTTデータ 第三公共事業本部 デジタルソサエティ事業部 プロジェクト推進担当（参照） 立場：様々なシステムの基盤構築、基盤維持運用を担当している組
2024年7月20日に発売された『ドメイン駆動設計をはじめよう』の概要説明と、ソフトウェア開発現場での活用方法。 ①何が書いてあるか？ ②事業活動の分析（１章）⇒設計判断 ５章、6章、7章、８章、10章 ③業務知識の発見（２章） ④事業活動の複雑さに立ち向かう（３章） ⑤区切られた文脈どう…
手を動かす仕事が減っている いまソフトウェアエンジニア業界ではAI（主にClaude Code）のおかげで仕事が効率化されていっている。簡単なコードを書く業務はかなり減っていて、誰が書いても同じになるよね？というコードはAIにプロンプトを投げるだけで思っていたとおりのものが出てくる。とても便利だ。もちろん何も考えずにすべてをAIに任せられるということはなくて、良い結果を得るためにはプロンプトをよく練る必要がある。また、何度もダメ出しをして細かいフィードバックを重ねるのも大事だ。便利ではあるが、良くも悪くもAIを操縦する人の腕前で成果が大きく変わる。 意思決定の連続 なにがしんどいのか。頭をフル回転させなければならない時間が増えてしまったところ。これまでのソフトウェア開発では、最初の設計や方針検討のタイミングで深く考え、そのあとは手を動かしながらゆる〜く頭を使うことが多かった。設計ミスやバグ
San Franciscoで開催されたThe Pragmatic Summit に参加してきた． Pragmatic Engineeringは元UberのEMのGergely Oroszによるエンジニアでは最も有名なニュースレターの一つ．毎週業界の流れやテクノロジー関連のニュース，各社のリーダーや開発者たちへのインタビューが配信されている．今回のSummitはこのニュースレターでこれまで扱われてきたトピック，登場した人らを中心とした初のカンファレンス． Open AIやLinear，Cloudflare, DX, Ramp, TemporalのCTO/VP，Martin FowlerやKent Beck，そしてEntire/ex-GitHubのThomas DohmkeといったAI Nativeの先端にいる・これまで業界を率いてき人らによるセッションを聞くことができとても刺激的だった．自分
メイカームーブメントは「終わった」と言われる。2017年のTechShop破産、2019年のMaker Media事業停止。象徴的な組織が次々と消えた。だが実態は逆だ。 かつて「特別な人々の特別な活動」だった個人によるモノづくりは、もはや誰でも手にできるインフラとなった。ムーブメントは死んだのではない。インフラにシフトしているのだ。本記事では、2005年の誕生から約20年の歴史をたどりながら、個人のモノづくり環境がどのように変化し、何がどう変わったのかを検証する。 メイカームーブメントとは何か まず前提として、メイカームーブメントとは何かを整理しておきたい。 一言で言えば、「3Dプリンターやレーザーカッターといったデジタル工作機械の民主化、マイコンボードの充実化と低価格化、そしてインターネットの普及によって、個人がモノを作り、設計データを共有し、製品を世に出せるようになった社会的潮流」のこ
https://2026.emconf.jp/
最近AIをやりすぎている。自分でもわかるくらい頭がおかしくなっている。 まともな状態ではないから、本来は人に見える場所に文章を書いたりするべきではない。ただ、自分の状態を精神状態を記録するために書いておきたい。 初めに書いておくが、この文章では一切AIを使っていない。というのもAI使うと、さらにおかしくなりそうだからだ。調査にも構成にも使っていない。100%生身、ピュアで粗雑な状態で僕が言葉を選んで書いている。 これまでもテクノロジー全般は好きで、これまでもChatGPTなどを使って仕事の調査をしたり引っ越しをしたり英語学習に活用したりしてきた。今年のAIは、昨年までとは一味違う人間の気を狂わせる何かがあると感じている。 仕事でのソフトウェア開発の話を最初にする。多少技術的になってしまうけど、これが入り口で僕はおかしくなったし、最も急激に変化している部分なので話さないといけない。 AIコー
はじめに 不具合調査やパフォーマンス改善をするとき、どのくらい "手札" を持っていますか？ 私はよく、細部に入り込みすぎて全体を見失うこともあれば、逆に全体に意識を向けすぎて手が止まることもあります。そんなとき、先輩エンジニアの問いかけで状況の見え方が変わります。 同じ情報を見ているはずなのに、切り分けの速さがまるで違う...！ この記事では、日々のやり取りの中で学んだ思考パターンを整理してみました。 調査 / 切り分けの思考パターン 1. まず全体を見る いきなり一点を疑わない まずは全体像を把握する → 局所ではなく構造を見る 2. 見る前に予測する ログやコードを開く前に「おそらくここだろう」を言語化する 仮説なしに掘り始めると、異常を見逃しやすい → 観測は仮説とセットで行う 3. 外から内へ絞る 全体 → サービス境界 → コンポーネント → コード の順に見る いきなりコード
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
