この記事は SmartHR Advent Calendar 2023 2nd の12日目の記事です。 こんにちは、SmartHRでプロダクトエンジニアをしているytakaです。 この記事では、チーム間のコミュニケーションにおける、シンプルかつ強力な手法をご紹介します。 それが「ただ話す」です。 ただ話す 「ただ話す」は、チームの輪読会で読んだ『大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法』にて紹介されていたメソッドです。本書には以下のように記載されています。 大規模なグループで何年も働き、複数チームにまたがる調整テクニックを数多く観察した結果、最も上手くいきそうなテクニックを発見しました。手順は次の通りです。 (1) あなたは、チームBとの”調整が必要”なことに気づきます。 (2) 立ち上がって、 (3) チームBのところに歩い
ちょっとだけ読んでから積む「積⭐️読タイムアタック」で、タワーと化した購入書籍の未読圧のプレッシャーから解放されました
【資料公開】ステークホルダーとの付き合い方を考える
みなさんこんにちは。@ryuzeeです。 2024年6月3日に行われたソニー主催、Forkwell共催の勉強会「TechLovers #2」の登壇資料を公開します。 プロダクト開発には、さまざまなステークホルダーが登場します。 プロダクトのフェーズや開発の状況によってステークホルダーの重要度は変わります。そしてステークホルダーごとに持っている権限の強さや権限が及ぶ範囲も違います。 これらを無視して開発を進めると、プロダクトに大きな影響を及ぼすようなことが起こりかねません（メテオフォールなるものもその1例です）。 つまり、戦略的にステークホルダーと付き合っていかなければいけません。 この資料では、フレームワークを活用してステークホルダーを分類し、分類に応じた接し方を紹介しています。 プロダクト開発においては、常にやりたいことややらなければいけないことがたくさんあり、時間や人は足りません。 そ
リファクタリングを文化にする 〜組織が技術的負債と向き合うワークショップ〜 - MonotaRO Tech Blog
皆さんこんにちは。 CTO-Office の香川とEC開発-Bグループの竹原です。 11/28に 和田卓人氏(id:t-wada)を講師としてお招きしてテストとリファクタリングのためのワークショップを開催いたしました。 技術者正社員のうちプログラミングをすることの多いメンバー全体の約1/3にあたる総勢53名が参加しての開催となりました。 本記事ではまず第一弾としてワークショップの概要や目的、全体の流れについて簡単にご紹介いたします。 また第二弾(2024年1月公開予定)では、運営とワークショップの問題の作問に関わったメンバーにそこでの学びや実践について紹介いただきます。 開催に至った経緯とMonotaRO DOJO MonotaRO DOJO とは 社内の課題とワークショップの目的 開催経緯 ワークショップの全体像と開催までの段取り ワークショップの全体像 概要 タイムテーブル 開催までの
【資料公開】ベロシティ Deep Dive
みなさんこんにちは。@ryuzeeです。 2024年1月10日〜12日開催のRegional Scrum Gathering Tokyo 2024の登壇資料を公開します。 「ベロシティ Deep Dive」ということで過去のDeep Diveシリーズの続きになっています。 過去のDeep Diveシリーズはこちらからご覧ください。 プロダクトバックログ Deep Dive スプリントプランニング Deep Dive スプリントレビュー Deep Dive セッション資料は以下になります。 結論から言うと、「ベロシティなんかにDeep Diveせず、もっと重要なところに集中しろ」です。 スクラムチームの状況を何らかの数値で表したいという考え自体は尊重しますし、それが役に立つこともあります。 ただし、数字遊びをしたところでプロダクトの価値を生み出せるわけではないので、ほどほどにしましょう。 ス
mikanデザイナーの"スクラムで回す1週間"を覗いて行きませんか？｜Ayaka Nagataki
はじめにこんにちは！株式会社mikanでデザイナーをしているayataki（@ag_ayakan）です。 主に英語アプリ「mikan」の体験設計やUIデザインの作成を行なっています。 カジュアル面談などで話す際に、「mikanのデザイナーさんてどんなことをやってるんでしょうか？」という質問をよくいただくようになりました。 社外への発信が少ないこともあり、イメージを持ってもらいづらい状況にあるのではないかなと感じています。 そこで今日は、mikanのデザイナーとして働くわたしの1週間のスケジュールについてご紹介します！実際にあった直近のスケジュールを具体例に出していきます。 mikanのデザイナーに少しでも興味のある方に、具体的なイメージを持ってもらえたら幸いです🍊 それでは行ってみましょう！ [前提] 仕事の環境ほぼリモートワーク mikanのメンバーは基本的にフルリモートワークで働いて
スクラムマスターの役割はスクラムを回すだけではない ─ Be Agileを志向するサイボウズの組織改編 - Agile Journey
サイボウズにおいてプロダクト開発を担当する開発本部では、2016年頃からスクラムを開発現場に導入してきました。チームにスクラムマスターがいない状況も続いていましたが、2022年にはエンジニアやデザイナーなどと同様の「職能」としてスクラムマスターをバックアップする組織改編に踏み切っています。 ▶ 組織のチームワークを最大化するためにスクラムマスター職能を作りました - Cybozu Inside Out これまでもサイボウズの開発本部ではマネージャー職をいったん撤廃するなど、組織のあり方に野心的な取り組みをしてきました。そういった組織改編の狙いや、スクラムマスター職能化から約1年でどのような効果があったのかを、開発本部副本部長の岡田勇樹さんと、シニアスクラムマスターの天野祐介さん、スクラムマスター職能化にともなって専任となったToshinariさんの3人に伺いました。 スクラムマスターがチー
概要 スタースキーマからスノーフレーク、ギャラクシー、そしてデータボールトやアンカーモデリングまで、各スキーマの特徴、利点、そして適用シナリオを掘り下げます。 スタースキーマ スタースキーマを元に整理します。 スタースキーマ または 星型スキーマ はデータウェアハウスに利用される最も単純なスキーマである。スタースキーマには唯1つもしくは少数のファクト表と複数のディメンション表が含まれる。スタースキーマはスノーフレークスキーマの一種であるが、多くの用途で利用されている。 DWHに利用される最も単純なスキーマ 唯一または少数のファクトテーブルと、複数のディメンションテーブルが含まれる スノーフレークスキーマの一種 モデル ファクト表はデータウェアハウスでの解析で利用され、複数の異なるディメンションに区分される。ファクト表は主要なデータを持つ一方、ディメンション表は相対的にサイズが小さくディメン
デザイナーの帽子をかぶったわたしが、プロダクト開発するうえでスクラムチームに提供したいこと / what I want to provide to Scrum teams when developing products
Scrum Fest Fukuoka 2024の登壇資料です。 プロポーザル：https://confengine.com/conferences/scrum-fest-fukuoka-2024/proposal/19575
関連キーワード IT部門 | ネットワーク | ネットワーク管理 | ネットワーク監視 ネットワーク内のデバイスを管理するには、単にIPアドレスを割り当てるだけでは不十分だ。クラウドサービスやIoT（モノのインターネット）の利用が増加傾向にある中で、企業のネットワークは複雑化している。そのネットワークと、ネットワーク内のデバイスを管理する仕組みが重要になってきた。 IPアドレスベースのネットワーク管理を合理化するためには、「DNS」（Domain Name System：ドメインネームシステム）、「DHCP」（Dynamic Host Configuration Protocol：動的ホスト構成プロトコル）、「IPAM」（IP Address Management：IPアドレス管理）といったネットワークのプロトコルやシステムが欠かせない。以上3つを総称した用語が「DDI」だ。 DDIのそれ
NTTデータは法人向けシステム構築に生成AI（人工知能）を本格導入する。生成AIを利用したシステム開発手法やツール群を社内で整備し、2024年度から国内外の開発部門に展開する。 NTTデータは業務システム開発に携わるエンジニアが国内と海外を合わせて約10万人在籍する。生成AIを使う開発手法を全エンジニアに習得させ、営業など関係する職種も含めて全社員19万5000人が利用できる体制を目指す。 既に実証では開発工数を7割削減できたなど大きな成果事例が出ているという。システム構築の生産性が大幅に向上すると、受注できる案件を増やせる一方で、案件の単価や顧客単価が下がりかねない矛盾も抱える。システム構築の受注金額は、必要な工数を積算して算定根拠にする「人月型」の契約が主流だからだ。NTTデータは「課題を整理して、成果報酬型など顧客と新たな契約形態も検討を進める」（担当する技術革新統括本部システム技術
アジャイル環境で必須 ビジネス要件定義書（BRD）を作成する際のポイント：どう作るか、どう活用するか アジャイルソフトウェアチームが仕事を行う際には、厳密なプロセスや厳格な監理委員会を設けるべきではない。それでも、ビジネス要件定義書は、チームの中心に据える必要がある。本稿では、そのビジネス要件定義書について考える。 ソフトウェアチームは、顧客に提供予定の具体的な製品または価値をビジネス用語を使って要約する明確かつ包括的なドキュメントを作成して、管理しなければならない。このビジネス要件定義書（BRD：Business Requirements Document）を用意すれば、顧客のニーズを満たすことが可能になる。 アジャイルソフトウェアチームは、顧客用か社内業務関係者用かを問わず、アプリケーションを作成する前に、BRDの作成方法を理解する必要がある。本稿では、BRDが果たす役割、アジャイルプ
こんにちは。エンジニアリンググループ プロダクト支援チームでプロダクトマネージャーをしている中村です。 2019年5月にエムスリーに入社してから、早4年が経ちました（うち1年半の出産・育児のための休業期間を挟んでいます）。 ちなみにエムスリー入社前の経歴としては、大手メガベンチャーの事業企画からキャリアをスタートし、企画職、プロジェクトマネージャー等を経てプロダクトマネージャーを3年ほどやっていました。 私がエムスリーに入社してから半年後の2019年11月に、以下の記事を書いていました。 www.m3tech.blog 当時の記事に書いた通り、私がエムスリーへ入社を決めた理由は下記4点でした。 エムスリーは新規事業の立ち上げサイクルが速く、プロダクトマネージャーとして「製品を見つける」フェーズにチャレンジできる環境であること 尊敬できるプロダクトマネージャーだと感じたVPoE山崎の直轄チー
エンジニアリングマネージャーの4領域はEM以外のメンバーでも濃淡はあれど意識する必要がある - stefafafan の fa は3つです
株式会社はてなでテックリードとして仕事をしている id:stefafafan です。今回は自分が個人的に考えてきたことを記事としてまとめてみます。 エンジニアリングマネージャーの4領域とは EMでなくとも4領域を意識する必要がある テックリードの場合 スクラムマスターの場合 Individual Contributor (IC) の場合 ロールを持たないソフトウェアエンジニアの場合 結局エンジニアリングマネージャーの役割とは 終わりに エンジニアリングマネージャーの4領域とは ここで私がEMの4領域と呼んでいるのは以下の4つの領域のことです。 テクノロジーマネジメント アーキテクチャやテストなど プロジェクトマネジメント 見積もりやアジャイル開発など プロダクトマネジメント ビジョンや仮説検証など ピープルマネジメント メンバーの成長やメンタリングなど これらの4つの領域は @hiroki
自分がニッチだと思っているテーマについて発表する「Qiita Engineer Festa 2023〜私しか得しないニッチな技術でLT〜」。ここで株式会社ノーススターの古谷氏が登壇。個人開発の“つらみ”を解消するアジャイル開発・スクラム開発のエッセンスについて話します。 古谷氏の自己紹介 古谷聡希氏：「個人開発のつらみを経営計画とスクラムの手法で乗り切る技術」です。よろしくお願いします。 今日のテーマはニッチな技術ですが、私は（ニッチな技術と言いつつも）どちらかというと王道技術のニッチな活かし方なのかなと思って発表します。なので、そのように念頭に置いて聞いてもらえたらうれしいです。 あらためまして、古谷と申します。中小企業診断士で、いわゆる経営コンサルの国家資格と認定スクラムマスターを持って活動しています。 会社員としては三井物産株式会社のIT医療の領域の関連会社の株式会社ノーススターでエ
前書き🤔これは何RIZさんという一見AIイラストレーターを装った風来のシレン廃人にそそのかされて作ったちちぷいチャレンジが多数の愉快犯たちにおもちゃにされた結果書かないといけなくなった記事です。 Stable DiffusionやMidjourney、Nijijourney、NovelAIの使い方を詳しく解説した文書は数あれど、ふだんパソコンを使わない一般の人向けまで踏み込んで網羅している解説記事って案外ないかもな？と思ったのもきっかけではある！ 書く前からわかってたんだけどボリュームがヤバいので稚拙な表現や抜け漏れ多数だ。公開後もちょくちょく手を加える可能性大だから、もし更新が気になるようであれば筆者のX, Blueskyアカウントをフォローするなり、気が向いた時にこのnoteに戻ってきてくれよな！！ しばらく前提条件を書いておくので、とっとと中身を読みたい人は飛ばしちゃってください。
VPoEの湯前（@yunon_phys）です。3月にカケハシにジョインし、あっという間に4ヶ月。ゼロイチの事業立ち上げに寄与するエンジニアリングチームのマネージャとして、おかげさまで（本当に）楽しい日々を過ごすことができています。 今回は社内外の方々への自己紹介にかえて、エンジニアのキャリアや仕事観について、カケハシ入社前後に考えていたことをまとめてみることにしました。カケハシの技術組織を、どのような方向に成長させていきたいのか。自分自身のミッションにもつながる内容になると思います。エンジニアはもちろんですが、職種を問わずぜひいろいろな方にご一読いただけると嬉しいです。 カケハシの湯前としては、先日開催された日本CTO協会のイベントでもお話ししていますので、あわせてご覧ください。 技術や待遇、職場環境だけじゃない、もっと大事なことさて、「働きたくなる会社」についてです。組織マネジメントにお
世界で評価された製品が受けた国内での逆風世界で最も革新的な電子楽器を表彰するアワード「MIDI Innovation Award」（ミディ イノベーションアワード）で、ファイナリストの3製品に選ばれた日本生まれの電子楽器「インスタコード」は、楽器に挫折した人でも弾ける画期的なユーザーインターフェイスが評判になり、ネット通販や楽器店で人気を博しています。 インスタコードを持つ開発者ゆーいち 起業したばかりのベンチャーが、構想から３年で製品を発売し、２年後には世界規模のアワードで評価されるまでに成長したものの、この成長の逆風となったのは、日本のものづくりベンチャーが、適切な支援を受けられない、構造的な問題でした。 本稿では、インスタコードの開発者が、投資家、行政、銀行などの支援を受けられず、それでもユーザーの支持を得ながらギリギリの状況で製品化を達成したストーリーをご紹介します。 たった１人で
さて、米国連邦政府のクラウド戦略についてのレポートその2である。その1はこちらを参照。その1を読んでいなくても支障はないが、歴史的な話をしているので先に読んでいただくと理解が捗ると思う。 前回は、どちらかというと連邦政府の取り組みがうまくいかなかった、というトーンで話をしたが、公平を期して言うならば、成功している部分もあるし、うまくいかなくても諦めず粘り強く進行している取り組みもある。こういうとき米国人というのは強くて、失敗を教訓にどんどん再トライを繰りかえし、大きなブレイクスルーに繋げてしまう。 本稿では、そのようなダイナミズムを持った取り組みとして連邦政府のクラウドセキュリティ戦略を取り上げたいと思う。今後日本政府がクラウドシフトを進めていくうえでの参考にもなれば幸いである。 連邦政府のクラウドセキュリティ政策は、大きく三つの柱から成り立っている。一つ目が「FedRAMP」と呼ばれるク
Here are the 25 most viewed decks of 2023: わかりやすい説明のための 10 の鉄則 / 10 golden rules for easy-to-understand explanations by @e869120 私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法/product management rsgt2023 by @moriyuya 解像度を上げる 🔬/ Increase resolution by @tumada セキュリティ研修【MIXI 23新卒技術研修】/ Security training [MIXI 23 new graduate technical training] by @mixi_engineers ソフトウェアの内部品質に生じる様々な問題は組織設計に
はじめにこんにちは！つむです🐈 8月より社内で実施するchatGPTをフル活用したUI勉強会を実施しています📚 開催までの背景や内容決定までのプロセス、プログラムをご紹介します🚩 使用するペルソナ・ユーザーストーリー・情報アーキテクチャ図を生成するプロンプトも公開しますのでぜひご覧ください✨ 自己紹介2022年KDDIにUXデザインコースで新卒入社（KDDIアジャイル開発センターに兼務出向中） auショップ向けDX施策やワーケーション施設検索サービス「タビトシゴト」などでUIUXを担当 背景UI業務多いのにUIデザイナーが少ないKAGデザイナーは基本的に上流を主戦場に置くUXデザイナーやサービスデザイナーとして業務をしている方が多いです。 しかし私は学生の頃からUIが得意たっだため最初はUIデザイナーからスタートし、徐々に上流へ足を広げる方針にしていただきました🙌 配属直後はUIデ
『スクラムの拡張による組織づくり』を読んで、そもそも”組織をつくる”ってなんだろうなって考えた - Magnolia Tech
スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する WEB+DB PRESS plus 作者:粕谷 大輔技術評論社Amazon だいくしーさんこと、粕谷大輔さんの『スクラムの拡張による組織づくり』を読みました。 複数のスクラムチームを協業させていく手法として「Scrum@Scale」を軸に、スクラムという概念自体のおさらいから始まり、コミュニケーションを軸とした組織の作り方、運用の仕方を解説していく構成になっています。 第3章で出てくる「毎日45分で問題が解決する」というのはなかなかキャッチーな表現で、Daily Scrum -> Scaled Daily Scrum -> Executive Action Teamのそれぞれに15分という目安を作ることで、議論ではなく問題の確認と決定の場としてショートに実行するものである、という定義が明確で分かりやす
「引き継ぎできない！」から始まった私のスクラム - 川口恭伸の「はじめてのアジャイル」 - Agile Journey
Agile Journeyをご覧のみなさん、はじめまして。川口恭伸（@kawaguti）と申します。 私はアジャイル開発やスクラムに関する知識を提供し、モダンなソフトウェア開発の要素の研究、プロダクト開発の進め方やチームの目標設定など、さまざまな領域でのコンサルティングを手掛けています。 また、アギレルゴコンサルティング株式会社においてシニアアジャイルコーチとして活動しており、一般社団法人スクラムギャザリング東京実行委員会と一般社団法人DevOpsDays Tokyoの代表理事も務めています。さらに、コミュニティ活動としては、毎週水曜日に品川アジャイルに参加しており、RSGT、スクラムフェス、DevOpsDaysといったカンファレンスでのスタッフワークも担当しています。 このように、ほぼ公私の境なくアジャイルやスクラムを基にした活動を長く行っていますが、本稿では、私がスクラムを始めるまでの
🐳この記事は「ログラスサマーアドベントカレンダー2023」の28日目の記事です。 次はデザイナーチームの高瀬さんです。 こんにちは、ログラスの松岡です。 ログラスのプロダクトチームでは、ドメイン駆動設計とアジャイルプラクティス（スクラム、エクストリームプログラミング等）を併用していました。 その中で、「アジャイル・フルーエンシーモデル」(以下、省略時には「フルーエンシーモデル」と表記)という概念が多くのプラクティスを取りまとめ、全体感を把握してチームの成長余地を考えるのに役立つものなので、この記事で紹介したいと思います。 アジャイル・フルーエンシーモデルの面白いポイント 面白いポイントはいくつもあるのですが、この記事で紹介するポイントは二つあります。 ポイント①: 技術的負債への対策が組み込まれている 一つは、「技術的卓越性によってアジャイルの持続可能性(サステナビリティ)を高めるという
SaaS型Webサービス｢カオナビ｣のチーム開発でPackage by Featureを取り入れた話/Implementing Package by Feature in kaonavi
「DevOps」とは？〜超基本から実践のポイントを解説〜|インシデント管理プラットフォーム│PagerDuty
変化の激しい市場に対応するための開発手法として、アジャイル開発を導入する企業が増えるとともに、「DevOps」への注目が高まっています。しかし一方で「DevOpsという言葉は聞いたことはあるけれど、実際にはよくわからない」という方もいらっしゃるのではないでしょうか。DevOpsは「開発担当者と運用担当者が密に連携することで、柔軟でスピーディーな開発を実現する」というソフトウェア開発手法の一つです。DevOpsは単なるトレンドではなく、現代のソフトウェア開発において非常に重要な考え方でもあります。本記事では、DevOpsを一から理解したいという方にもわかるように、DevOps誕生の歴史を簡単に紐解きながら、DevOpsの考え方をご紹介します。また、アジャイル開発との違いやDevOps導入のメリット、実践のポイントなどをDevOpsを実践する3社の事例を交えて解説します。 「DevOps」とは
初めに 本記事 『ゼロから始めるシステム障害対応フロー』 の内容について タイトルの「ゼロから始める」には二つの意味があります。プロダクトのリリースを間近に迎える中、チーム内での障害対応体制の枠組みがなかったこと。そして体制づくりを担当することとなった私の知識・知見が（ほぼ）ゼロだったこと。この二つです。 この状態から、リリース前〜リリース後の約2月間でなんとか形にすることができました。本記事ではその過程でぶつかった問題とそれに対する課題、それらにどう対応したのか、何を学んだのか、の紹介。 そして、障害対応体制の策定・構築や改善の流れの中で私が起こした失敗から、人としてリーダーとして何を心がけなければいけなかったのかの反省を共有させてもらいたいと思います。 本記事は以下の構成です。 0. 始まり ※ スクラムチームでの話。スクラムチームの登場人物は以下の三つ PO：プロダクトオーナー（Pd
最近にわかに話題のLLMツール「Dify」を僕も使ってみた。 いいところと「?」となったところがあったので纏めておく Difyとは、GUIでワークフローを組むことができるLLM-OPSツールだ。 ComfyUIのようにワークフローが組めたり、GPTsのように自分専用のアシスタントを作れたりできる。 特に、OpenAIのGPTシリーズとAnthropicのClaude-3、そしてCohereのCommand-R+なんかを組み合わせて色々できるところは良いところだと思う。また、ローカルLLMにも対応しているので、企業内でのチャットボットを作るんだったらGPTsよりこっちの方がいいだろう。 元々色々なテンプレートが用意されているが、テンプレだけ使うとGPTsっぽいものを作れる(それだってすごいことだが)。テンプレを改造するだけでも欲しいものが作れる人はいるし、ここはノーコード環境と言える テンプ
【資料公開】プロダクトオーナーアンチパターン
みなさんこんにちは。@ryuzeeです。 技術顧問先からの依頼でプロダクトオーナーのアンチパターンについて話をしたので、そのときの資料を公開します。 今回紹介するのは以下の6つのアンチパターンです。アンチパターンに陥っている可能性を示す兆候もあわせて示しています。 顧客やユーザーの軽視 兆候 社内のミーティングでスケジュールが埋まっている 機能の必要性の根拠はユーザーからのフィードバックではなく仮説（というか妄想）にもとづいているものが多い ユーザーがプロダクトを触っているところを見たことがほとんどない 不十分なステークホルダーマネジメント 兆候 ステークホルダーをスプリントレビューに招待していない ステークホルダーと個別にコミュニケーションしていない ステークホルダーに何か言われるとすぐに対応している 「◯◯さんの指示なのでやらないといけない」のような口癖 不在がちなプロダクトオーナー
「アジャイルテストの4象限」はアジャイル開発を補完するソフトウェア開発手法である - mtx2s’s blog
従来のプロジェクトにおける「テスト」は、リリースや納品前の最終工程として行われるものだ。多くのケースでそれは、前工程までの遅れと、それでも固定されたままのリリース日に挟まれ、予定された期間を食いつぶされた中で実施される。その上、時間に追われる中で実装されたソフトウェアは、動作確認も十分にされない状態でテストフェーズをむかえることになる。こうして品質の保証は、テスターに丸投げにされるというのが実態ではないだろうか。もちろんここでテスターに丸投げされているのは外部品質、特に機能面での品質の保証のみだ。非機能面での品質の保証は手薄になり、内部品質は顧みられることはない。 これは、ウォーターフォール開発を採用するプロジェクトで私が頻繁に経験した失敗パターンであるが、アジャイル開発でも遭遇する。その理由は、そのままのテストモデルがアジャイル開発の中でも用いられるために、同様の失敗パターンに陥りやすく
さくらインターネットで活躍中の id:y_uukiを訪問 | はてな卒業生訪問企画 [#9] - Hatena Developer Blog
こんにちは、エンジニアリングマネージャーの id:onk です。 Hatena Developer Blogの連載企画「卒業生訪問インタビュー」では、創業からはてなの開発に関わってきた取締役の id:onishi、CTOの id:motemen、エンジニアリングマネージャーの id:onkが、いま会いたい元はてなスタッフを訪問してお話を伺っていきます。 id:onkが担当する第9回のゲストは、さくらインターネット株式会社の組織内研究所であるさくらインターネット研究所の上級研究員で、SRE （Site Reliability Engineering）の研究者としても活躍する id:y_uuki さんこと、坪内佑樹さんです。 2013年にはてなに新卒でWebオペレーションエンジニアとして入社後、サーバー監視サービス「Mackerel」をはじめとするサービス開発やはてなのインフラ開発・運用にSR
![さくらインターネットで活躍中の id:y_uukiを訪問 | はてな卒業生訪問企画 [#9] - Hatena Developer Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/5b5961cfe7e9736ef0e88bc0290b1599481d2626/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fh%2Fhatenatech%2F20240319%2F20240319125826.jpg)
【ryuzee｜吉羽龍太郎】アジャイル開発のエキスパートが語る「エンジニアはビジネス視点を持て」の裏に隠れた本当の問題 2023年9月11日 株式会社アトラクタ Founder兼CTO アジャイルコーチ 吉羽 龍太郎 1973年生まれ。野村総合研究所、Amazon Web Servicesなどを経て、2016年1月から現職。アジャイル開発、DevOps、クラウドコンピューティング、組織開発を中心としたコンサルティングやトレーニングを専門とする。著書に『SCRUM BOOT CAMP THE BOOK』（翔泳社）、訳書に『チームトポロジー』（日本能率協会マネジメントセンター）、『エンジニアリングマネージャーのしごと』『スクラム実践者が知るべき97のこと』『プロダクトマネジメント』『みんなでアジャイル』『レガシーコードからの脱却』『カンバン仕事術』（オライリー・ジャパン）、『ジョイ・インク』（
「テストを書こうとしたけど、どう（いつ）書いたらいいかわからない」初心者向けガイドライン！ - HIKKYフロントエンドガイドラインより
本稿では、自動テストについての「ちょうど一歩くらい」進んだ内容について、述べていきます。 「テストを実施したいけど、どう書けばいいかわからない」という全人類は、これを読んでください。 損はさせませんよ！ これを読めば、「一歩目の知識」「初めてのテスト作成」「テストの初歩概念」を得ることができ、「次になにをすればよいか」がわかるようになります！！ 対象読者: 実際にテストを実装してみようと思ったけど、とっかかりがつかめなかった テストの概要はわかった（単体テストと結合テストガイドラインを読んだ） テストのTipsに興味がある なお本稿は株式会社HIKKYフロントエンドチーム向けのガイドラインであるものの、内容については筆者に一任されており、株式会社HIKKY及びその意向等とは無関係です。 テストってどういうフローで開発していくの？ どのタイミングでテストコードを書くの？ おおまかには以下の、
開発プロジェクトにおいて、開発スピードを測る尺度としてよく使われるのが「ベロシティ」です。このベロシティによって示される数字を適切に扱い、開発に活かしていくにはどうすればよいのでしょうか。 そのことを詳しく株式会社アトラクタ 吉羽龍太郎氏のセッション「ベロシティ Deep Dive」が、1月に都内で開催されたアジャイル開発の代表的な方法論であるスクラムをテーマにしたイベント「Regional Scrum Gathering Tokyo 2024」で行われました。 吉羽氏のセッションの内容をダイジェストで紹介しましょう。 本記事は前編、中編、後編の3つに分かれています。いまお読みの記事は前編です。 これから「ベロシティ Deep Dive」ということで「ベロシティ」についてお話をしていきたいと思います。 ベロシティを使っているっていう方、会場にどれぐらいいますか？ （手が挙がる） 結構多いで
本エントリはカケハシ Advent Calendar 2023 Part 2の 25 日目の記事です。ぜひ Part1 と合わせて見て頂けたらと思います。 本日はMusubi AI在庫管理プロダクト開発チームでエンジニアリングマネージャーをしている僕が、開発ディレクターとして入社した当時に進めた組織変更への取り組みについて、現状の組織の状態も踏まえて振り返ってみようと思います。 組織変更の方針 入社した当時、Musubi AI在庫管理はフロントエンドチームとバックエンドチームに分かれて活動していました。 同じプロダクトを開発しているにもかかわらず、それぞれのチームは別々に活動している状態で同じ開発テーマも異なる時期に開発していることもありました。 それをフロントエンド、バックエンド混合のフィーチャーチーム化するというのが組織変更の方針でした。 組織変更の背景 実は組織変更の方向性は僕が入社
はじめに エンジニアとして就職する前に読んだ「なれる!SE 2週間でわかる?SE入門」の内容があまりにも厳しく、業界に就職するのが怖くなったことを覚えています。本の中に登場する中学生の少女にしか見えない凄腕のSE、室見立華さんのような人物は現実には存在しないでしょうが、実際の業界には彼女のような凄腕エンジニアや年齢不相応な技術力を持つ人間も確かに存在します。 なれる！SE ２週間でわかる？ＳＥ入門 (電撃文庫) 作者:夏海 公司,IxyKADOKAWAAmazon SREの探求『Becoming SRE』の内容紹介 私は「なれる!SE」が好きすぎるあまり、「なれる!SRE」というタイトルのクソみたいな文章を吐き出したこともありましたが、そのクオリティがあまりにも低かったため、外には公開せずに留めておきました。そんな中、SREの探求の原著者であるDavid Blank-Edelman(ott
「全ては会社の競争力を生み出すために」アーキテクチャを刷新し、ドメインモデリングも組織再編もエンジニア教育も一つ一つ丁寧に積み上げてモダナイズを進めた話｜CTOロングインタビュー - MonotaRO Tech Blog
独自のビジネスモデルを持ち、競争優位を獲得しているモノタロウ。事業拡大に合わせて、モノタロウの成長をテクノロジーで支えるTech組織も進化してきました。現在Tech組織は、より高度なビジネス価値を生み出せるようにするため、サプライチェーンの高度化、パーソナライゼーションでの商品検索に着目し、アーキテクチャの再構築とシステムのモダナイズに取り組んでいます。また、そこに向けて組織体制のアップデートやカルチャーの醸成にも力を入れています。 今回は、MonotaRO CTO 普川泰如氏のインタビューから、その実態に迫っていきます。まず第1章ではモノタロウが会社として掲げるビジョンとビジネスの特徴について説明します。それを踏まえて第2章では、そのビジョンやビジネスを実現するためのシステムとその課題、モダナイゼーションについて、第3章ではその技術的な取り組みを実行するためのTech組織の体制について紹
【研修資料公開】24新卒エンジニア研修「エンジニア基礎」を実施しました！ - WILLGATE TECH BLOG
こんにちは！ウィルゲート SREチーム 4年目エンジニアのことみん(@kotomin_m)です ウィルゲートでは24新卒エンジニア 内定者向けに新卒研修を実施しました！ この記事では、新卒研修の内容と、研修の中でも私が担当した「エンジニア基礎」の作成の裏側や資料を公開したいと思います！ 作成した資料は、私の3年間の学びを凝縮したものであり、そのためかなりボリュームがあります。 しかし、今日から新卒エンジニアの皆さんだけでなく、先輩エンジニアの皆さんにも見て頂き、是非後輩エンジニアの教育の際に使ってもらえると嬉しいです！（頑張って作ったので何卒……！！） 新卒研修の内容 エンジニア基礎 資料公開 エンジニア基礎 作成の裏側 研修作成の背景 研修作成で苦労したところ おわりに 新卒研修の内容 今回は講師11名、全12項目の研修が実施されました！ 過去の研修資料をブラッシュアップしたものもありま
リリースした新機能がビジネス指標に何の影響も与えていない。ユーザーからの評判も芳しくない。いや、そもそも反応すらない無風状態。我々が費やした努力と時間はなんだったのか。 このような失敗は、ソフトウェアプロダクト開発に携わっていると何度でも経験します。むしろ、期待通りの成果を得られることの方が少ないでしょう。 失敗から得られる知見もありますが、それと引き換えに費やしたコストと時間は戻せません。それが繰り返されると、組織全体の士気が落ち、学習性無力感に支配されていきます。ソフトウェアプロダクトは、そのマネジメントにおいて、常にこれらのリスクを抱えています。 本記事では、機能リリースに伴うこのようなリスクを制御する方法について考えます。 期待する成果が得られないことを前提に計画する機能リリースが期待どおりのインパクトをビジネスにもたらすかどうか。それを事前に予測し、世の中に送り出すべきアイデアを
経済産業省が中小企業のデジタル化の遅れを指摘する中、中堅・中小企業やスタートアップがデジタルを経営に活用するための道しるべを提供するイベント「中堅中小企業・スタートアップ DXカンファレンス 2023 夏」が開催されました。今回は、現場のDXを推進するモバイルアプリ作成ツール「Platio」を提供する、アステリア株式会社の大野晶子氏が登壇したセッションの模様をお届けします。アナログで人手に頼る業務が多い「現場」のDXを、IT人材なしで実現するポイントなどが語られました。 DX推進の3つのフェーズ 大野晶子氏（以下、大野）：セミナーにご参加いただきありがとうございます。アステリアの大野と申します。本日は、「成功事例に学ぶアナログ業務をアプリで効率化！ 2万円からはじめる『現場のDX』とは」についてお話しします。どうぞよろしくお願いいたします。 はじめに、当社アステリアについて紹介します。 1
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チーム間コミュニケーションにおける「ただ話す」のすすめ - SmartHR Tech Blog
QAエンジニアがSMに憧れてしくじった話
データウェアハウスのデータモデリングを整理してみた - Qiita
「DNS」「DHCP」「IPAM」をまとめた「DDI」とは何か？ なぜ必要なのか
NTTデータが生成AI使うシステム開発手法を全技術者に展開、人月型契約が見直しに
アジャイル環境で必須 ビジネス要件定義書（BRD）を作成する際のポイント
超一流のプロダクトマネージャーへの道 - エムスリーテックブログ
個人開発が続かない理由は「時間」「戦略」「気力」「孤独」 4つの“つらみ”を解消するアジャイル開発・スクラム開発のエッセンス
AIイラスト始め方の網羅的案内 2024年版 / だいたい未経験者向け｜かいりん
今、エンジニアが「働きたくなる会社」ってどんな場所なんだろう｜カケハシ公式note
世界のベスト3に選ばれた製品が、行政や銀行の支援を受けられなかった理由とは
米国連邦政府におけるクラウド戦略 - クラウドセキュリティをどう担保するか｜ミック
2023 - Most Viewed Decks
ChatGPTをフル活用したUI勉強会！プロンプトも大公開｜つむら
アジャイル・フルーエンシーモデルでアジャイルに技術的負債対策を組み込む
アジャイル開発と時代の流れに伴うサーバレスアーキテクチャの変化
ゼロから始めるシステム障害対応フロー - Qiita
噂のノーコードAIシステム開発環境Difyを使ってツールを作ってみた。使った感想｜shi3z
【ryuzee｜吉羽龍太郎】「エンジニアはビジネス視点を持て」の裏に隠れた本当の問題
ベロシティ Deep Dive。スクラムにおけるベロシティのアンチパターンと適切な使い方とは（前編）
入社1ヶ月で組織変更を任されて中止した話 - KAKEHASHI Tech Blog
なれる!SRE - Becoming SREで学んだこと - じゃあ、おうちで学べる
ビジネスインパクトのない新機能に費やす時間とコストを低減する｜mtx2s
3日で作った業務アプリで「毎月最大550時間」の工数削減 非効率なアナログ作業が多い「現場」のDX成功事例