サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
この記事は「本番環境などでやらかしちゃった人 Advent Calendar 2025」の1日目です。 はじめに 「慣れてきた頃が一番危ない」 あれ、ほんとです。 当時の私は作業にも環境にも慣れてきて、油断が出始めていました。 「いつもの作業だし、サクッと終わらせよう」 完全にそんな気持ちでした。 何が起きたのか ECサイトの保守運用をしていた頃のことです。本番／検証（STG）／ローカルの3環境でphpMyAdminを使っており、 なぜか3つとも同じテーマ・同じ色・同じUI。 ローカル 検証 仮に言えばこんな状況。 「URLをよく見ないと、どこで作業してるかわからない」 そんな、今思えば事故るためのレールはピカピカに敷かれた状態でした。本来やる予定だった作業＆何を間違えたのか やりたいことは単純です。STGのDBをエクスポートしてそれをローカルに流し込む。 こんなものは、お腹が空い
はじめにアジャイルという言葉は広く普及していますが、その本質を正確に理解している人は多くありません。表面的には「変化に強い開発手法」「小さく作って早く回す」という説明が一般的ですが、実際のアジャイルははるかに本質的で、人間の認知能力と組織構造に強く依存した哲学的な方式です。本レポートでは、アジャイルの本質を掘り下げ、なぜ特定の条件を満たすチームでのみ成立するのかを論理的に整理します。そのうえで、アジャイルが成功するために必要な“人の条件”と組織の前提について考察します。アジャイルとは「真実 × 目的 × 推論」が揃う方式であるアジャイルが他の開発方式と決定的に異なるのは、根幹に「真実を操作しない」という前提が置かれている点です。嘘や政治的配慮を最小化し、現実をありのまま扱います。これにより、チーム内の各メンバーが事実を基点として矛盾なく行動できます。しかし、事実の共有だけでは組織は前
こんにちは。クラウド&ネットワークサービス部で SDPF のベアメタルサーバの開発をしている山中です。 先日、Google Workspace で利用できる GeminiAPI を活用して、日々の業務ログから日報を自動生成し、Slackに自動投稿する仕組みを構築しました。 その具体的な方法と、実際に導入してわかった想像以上の効果をご紹介します。 デイリースクラムの悩み、AIで解決しませんか？ やったこと：情報を集めて Gemini に日報を書かせる 1. 各種ツールから活動ログを収集 2. イベント情報を時系列で整理 3. プロンプトを作成し GeminiAPI を実行 4.Slack への自動投稿 想像以上の効果！情報共有が劇的に改善 シンプルに楽！「昨日何してたっけ？」からの解放 口頭の問題点を解決 完璧を求めない柔軟な運用 完璧じゃないからこそ面白いAIの活用法 テキスト文化と
7月15日、John Whilesが「AI slows down open source developers. Peter Naur can teach us why.」と題した記事を公開した。この記事では、AIコーディングツールが熟練オープンソース開発者の生産性を19％低下させた理由を、「メンタルモデル」という視点から解き明かしている。以下に、その内容を紹介する。 研究結果――「速くなる」と信じた開発者ほど遅くなる現実 Metrの論文によれば、被験者となった経験豊富なOSS開発者は、AIツールの使用を許可された課題で平均19％長く作業時間を要した。開発者は事前に「24％高速化する」と予測し、実験後も「20％は速くなった」と誤認したままだった。 When developers are allowed to useAI tools, they take 19% longer to com
あるゲーム会社に、新卒の若者が入社しました。 彼は高学歴ということもあって、とても頭の回転が速く、仕事を指示されると業務の本質をすぐに理解し、先輩顔負けのクオリティで成果物を出してくれました。 さらに人柄も良く、コミュニケーション能力も高かったので、将来を有望視されました。 そして彼はその期待に応え、入社わずか3年でディレクターに抜擢されました。 とても順風満帆といった感じでしたが、しかし、いかに優秀な彼でも、ディレクターに就任するには、3年という期間は短すぎたようです。 正しい下積みを経験していなかった為、非常に不幸な事件が起こり、ゲーム開発チームが苦労をしてしまいました。 ■有望株を育てるという抜擢「彼をディレクターに抜擢しよう」という方針は上層部が決めました。「彼を育てたい」という思いがあったからです。 筆者はその考えに賛成でした。 能力のある若者は、慣例にとらわれず、どんどんチャン
ソフトウェア開発の現場でも、日々、苦労が絶えない。知らず知らずのうちに、エンジニアを消耗させる問題が潜んでいる。 苦労は、日常の風景に溶け込みやすい。それが当たり前の状態であり、疑問すら抱かれない。「そういうものだ」と思い込む。いや、苦労することに、そもそも違和感を持てないのだ。 日常化した苦労は、改善されることがない。違和感がないからこそ、問題として扱われない。そして、原因に目が向けられることもなく、風景に溶け込んだまま、空気のようにあり続ける。 つまり、苦労を軽減するには、日常風景の中から問題を見つけ出す必要がある。そのための第一歩が、「気づく」ことだ。問題というのは、気づかなければ解決のしようがない。学校の試験のように、誰かに出題されるものではないのだから。本記事では、「気づく」ための視点を言語化し、手がかりとして整理している。 ソフトウェアエンジニアリング業務でありがちな苦労を、
昔DeNAの新人が入社後半年だかの振り返りのプレゼンの中で「うまくモチベーションが上がらなくて」ということを言った時に、南場社長が「社会人がモチベーションで仕事をするな」とすごく怒ったという話*1があって、とても印象に残っている。 また、これは実体験だが、その当時所属していた会社のけっこう中心的な人物が退職する送別会で、その人が受け持っていた客の話になった時、「あれもこれも大変なお客さんですね。私たちに引き継ぎできるものですかね」と残された側が不安をこぼすと、その人は「仕事やろ」とピシャリと言った、という場面をよく覚えている。 どちらも胸に氷を刺されたような、うすら寒い気持ちになったからだった。 私は、社会人だが、どうにも好き嫌いで仕事をしている節があった。やるべきことを淡々とこなすのではなく、やらなくてはならないことの中に何とか自分の興味が持てるようなテーマを見いだして、努力の為のエネル
優れたアイデアやデザインがあっても、それだけではソフトウェアプロジェクトを成功させることはできません。プロジェクトを円滑に進めるためには、ステークホルダーの理解と支持を得て、チームが協力できる環境を作ることが重要です。本書では、そのために不可欠で効果的なコミュニケーションの方法を解説します。具体的な例やパターンを通じて、適切にメッセージを伝えるためのドキュメントや図の作成方法を紹介します。 まず、ソフトウェアアーキテクチャの視覚表現を活用し、受け手にわかりやすくメッセージを伝える方法を解説します。次に、書面・口頭・非言語コミュニケーションの技法を用いて、相手に意図が正しく伝わるように工夫する方法を紹介します。また、ナレッジマネジメントを強化し、チームや組織の集合的な知識を最適化することで、生産性と革新性を向上させる手法についても解説します。さらに、アーキテクチャに関する重要な意思決定を的確
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
