SES 企業のソフトウェアエンジニア -> ソシャゲ会社のテックリード兼スクラムマスター -> 日系 SIer の社内アジャイルコミュニティオーナー 発言や記載した内容は個人のものであり、所属団体とは関係ございません
アジャイル開発の浸透?なんだそれは。 アジャイル開発という概念が世に出て二十余年(2001年「アジャイルソフトウェア開発宣言」による)、最早、この技術も最新とは言えない、成熟したものとなりました。あなたの職場でも「アジャイルに進めよう」的な、凝り固まらず柔軟なプロジェクト体制にして行こうという流れ、プロダクト開発の長大化を防ぎアウトプットを細かく出していこうという意識変革が内外から求められているかと思います。 しかしプレイヤーとしての皆様は、とはいえ作るものは変わっておらず納期が決まっているので大変になるだけ、だとか、現場ボトムアップな提案は通らずトップダウンにやることが降ってくるからやる意味なくね、だとか、果ては作るもの・仕様が決まってないけど予算がついたからいい感じにアウトプット出してね、の意味だとか、都合よく「アジャイル」を使われて疲弊することもあるでしょう。多くは会社の通例や予算検
サイボウズにおいてプロダクト開発を担当する開発本部では、2016年頃からスクラムを開発現場に導入してきました。チームにスクラムマスターがいない状況も続いていましたが、2022年にはエンジニアやデザイナーなどと同様の「職能」としてスクラムマスターをバックアップする組織改編に踏み切っています。 ▶ 組織のチームワークを最大化するためにスクラムマスター職能を作りました - Cybozu Inside Out これまでもサイボウズの開発本部ではマネージャー職をいったん撤廃するなど、組織のあり方に野心的な取り組みをしてきました。そういった組織改編の狙いや、スクラムマスター職能化から約1年でどのような効果があったのかを、開発本部副本部長の岡田勇樹さんと、シニアスクラムマスターの天野祐介さん、スクラムマスター職能化にともなって専任となったToshinariさんの3人に伺いました。 スクラムマスターがチー
GraphQL Tokyo #18 Lightning Talks https://www.meetup.com/ja-JP/graphql-tokyo/events/286913987/ Links: [GraphQL を活用したスキーマ駆動開発の実践](https://speakerdeck.com/qsona/schema-driven-development-with-graphql) [GraphQL を利用したアーキテクチャの勘所 / Architecture practices with GraphQL - Speaker Deck](https://speakerdeck.com/qsona/architecture-practices-with-graphql) [Quramy/gql-study-workshop](https://github.com/Quramy/g
近年のアジャイルムーブメントにおいて「職能横断チーム」は当たり前の概念になっています。ユーザーに価値を届けるのに必要なあらゆる機能をチームが備え自律的にコントロールすることで、リードタイムを短縮するとともに、イノベーションが起こりやすい環境を作ることができます。しかしながら、7〜8人を超える大きめの集団になってくると、開発の効率を著しく下げるアンチパターンを踏んでしまうことがあります。 「職能横断チーム」の実践におけるアンチパターン そのアンチパターンとは「いつも全員一緒」です。バックエンドエンジニアだろうとアプリエンジニアだろうと、デザイナーだろうとプランナーだろうと関係なくとにかく全員です。サイロ化のカウンターとしての「職能横断チーム」に囚われ過ぎてしまって、チーム内に部分集合を作ることを極端に避けてしまっている状態です。その結果、10人もいる会を開いて細かい相談で時間が伸びたり、そも
プロダクトバックログDeep Dive。スクラムのプロダクトバックログをどう作成し、手入れし、スプリントに投入するべきか(前編)。Regional Scrum Gathering Tokyo 2022 代表的なアジャイル開発手法の1つであるスクラムを構成する要素として「プロダクトバックログ」はもっとも重要なものの1つです。 プロダクトバックログは、プロダクトが目指す「プロダクトゴール」を含み、「スクラムチームが行う作業の唯一の情報源」とされています。 このプロダクトバックログとはどのようなもので、どう作成し、手入れをし、どのようにスプリントへ投入していくべきなのかを詳しく解説した、株式会社アトラクタ 吉羽龍太郎氏のセッション「プロダクトバックログDeep Dive」が、1月5日から7日まで行われたイベント「Regional Scrum Gathering Tokyo 2022」で行われまし
「Agile Tech EXPO(あじゃてく)」は、社会をちょっと良くするテクノロジーを学び、ちょっと先の未来の話をする無料オンラインコミュニティです。Keynote Speakerとして登壇したのは、ビル・ゲイツ氏、ジェフ・ベゾス氏、イーロン・マスク氏の下で働いた経験があるジョー・ジャスティス氏。テスラ社の急成長を支える、アジャイルハードウェア開発について話しました。全2回。前半は、イノベーションの加速のポイントとなる「スプリントの長さ」と「プロジェクトの同時進行」について。 テスラのアジャイル文化を12のステップで紹介 ジョー・ジャスティス氏:本日はありがとうございます。アジャイルハードウェアディロップメントとして、アジャイルをいかにハードウェア開発に適用していくかということを、今回お話しします。 私の経験ですが、マイクロソフトのビル・ゲイツや、スペースカンパニーやAmazonをやって
Agile Japanは、日本中にアジャイルの価値を浸透させ、日本の変革を促進することを目指しています。あらゆる業界や職種の方が集まり、実践者も初学者もともに建設的な意見交換ができる場です。「Agile Japan 2022」に登壇したのは、株式会社セブン銀行・スクラムマスターの小林公洋氏。LeSSにおける1on1の取り組みの工夫と結果について発表しました。 セブン銀行・スクラムマスターの小林公洋氏 小林公洋氏:それでは「LeSSではじめる1on1」を始めたいと思います。 まず簡単に、自己紹介をさせてもらえればと思います。セブン銀行の小林と申します。主な経歴としてはシステム開発をずっとやってきています。約3年ほど前にセブン銀行に転職をしています。セブン銀行は4、5年ぐらい前から内製開発に取り組んでいるのですが、内製開発を行っているグループが「プロダクト開発グループ」というところになっており
関連キーワード IT部門 | ネットワーク | ネットワーク管理 | ネットワーク監視 ネットワーク内のデバイスを管理するには、単にIPアドレスを割り当てるだけでは不十分だ。クラウドサービスやIoT(モノのインターネット)の利用が増加傾向にある中で、企業のネットワークは複雑化している。そのネットワークと、ネットワーク内のデバイスを管理する仕組みが重要になってきた。 IPアドレスベースのネットワーク管理を合理化するためには、「DNS」(Domain Name System:ドメインネームシステム)、「DHCP」(Dynamic Host Configuration Protocol:動的ホスト構成プロトコル)、「IPAM」(IP Address Management:IPアドレス管理)といったネットワークのプロトコルやシステムが欠かせない。以上3つを総称した用語が「DDI」だ。 DDIのそれ
アジャイル環境で必須 ビジネス要件定義書(BRD)を作成する際のポイント:どう作るか、どう活用するか アジャイルソフトウェアチームが仕事を行う際には、厳密なプロセスや厳格な監理委員会を設けるべきではない。それでも、ビジネス要件定義書は、チームの中心に据える必要がある。本稿では、そのビジネス要件定義書について考える。 ソフトウェアチームは、顧客に提供予定の具体的な製品または価値をビジネス用語を使って要約する明確かつ包括的なドキュメントを作成して、管理しなければならない。このビジネス要件定義書(BRD:Business Requirements Document)を用意すれば、顧客のニーズを満たすことが可能になる。 アジャイルソフトウェアチームは、顧客用か社内業務関係者用かを問わず、アプリケーションを作成する前に、BRDの作成方法を理解する必要がある。本稿では、BRDが果たす役割、アジャイルプ
「Scrum Fest Osaka」はスクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。KEYNOTEで登壇したのは、楽天グループ株式会社の椎葉氏。「誰も嫌な思いをしない変化」をタイトルに、自身が開発グループのサポートをしたときの取り組みについて話しました。全3回。3回目は、1年間をかけて変化したチームの結果について。前回はこちらから。 チームを変えるために「並行プロジェクトをやめる」ことを提案 椎葉光行氏:意識していることはわかった。それをどう実践しているのということで、具体的に自分がどういう選択をしてきたかを、さっきのチームのサポートの中からいくつか紹介したいなと思います。 サポートの始まりは、エンジニアのスキルアップをしたいので力を貸してほしいという依頼でした。それを考えながら、ぼーっと見ていたんですが、スキルアップができていない
こんにちは、計測プラットフォーム開発本部システム部SREブロックの市橋です。2021年4月に新たに発足したチームで未経験ながらリーダーを任され、気づけば約2年が経過していました。これまでを振り返ってみると、まっさらな状態から安定したチームができてきたと感じています。今回は新米リーダーとして試行錯誤する中で、チーム状態を可視化して健全なチーム運営を目指した話を紹介します。 チーム状態の可視化を考えたきっかけ リーダーを任された当初、チーム運営上の課題が色々あるのは認識していましたが、どこから手をつけるべきかが自分の中で判然としませんでした。メンバーの時に一個人として感じていた課題も、チーム全体を俯瞰して見た時にどれから優先的に取り組むべきか自信を持って判断できませんでした。まるで大海原のど真ん中にいきなり放り出された感覚でした。 そんな悩みを抱えていた時、全社に導入されているWevoxのアン
比較的小さなチームで小回りのきくプロジェクトを進める場合には、アジャイル開発やスクラムの利点をすぐに感じられる場面も多いでしょう。しかし、より多くのステークホルダーが関わってくる大規模な開発プロジェクトとなるとどうなるでしょうか。 いくつかのチームで2010年代前半からアジャイル開発に取り組んできたヤフー株式会社の開発組織ですが、現在では新規にスクラムを導入したいプロジェクトを支援する組織があり、たくさんのステークホルダーが関わる世界的なスポーツイベントの特設メディアサイトの構築においても効果を発揮しています。 スクラムマスターとして2021年にスポーツナビの総合メディアサイト開発を推進した田原慎也さんと、その田原さんたちをアジャイルコーチとして支援した荒瀬中人さんに、複数チームをまとめたスクラムでの工夫や課題を聞きました。 後出しの追加要望や市場変化への対応が容易なスクラム 経験者が多く
自分がニッチだと思っているテーマについて発表する「Qiita Engineer Festa 2023〜私しか得しないニッチな技術でLT〜」。ここで株式会社ノーススターの古谷氏が登壇。個人開発の“つらみ”を解消するアジャイル開発・スクラム開発のエッセンスについて話します。 古谷氏の自己紹介 古谷聡希氏:「個人開発のつらみを経営計画とスクラムの手法で乗り切る技術」です。よろしくお願いします。 今日のテーマはニッチな技術ですが、私は(ニッチな技術と言いつつも)どちらかというと王道技術のニッチな活かし方なのかなと思って発表します。なので、そのように念頭に置いて聞いてもらえたらうれしいです。 あらためまして、古谷と申します。中小企業診断士で、いわゆる経営コンサルの国家資格と認定スクラムマスターを持って活動しています。 会社員としては三井物産株式会社のIT医療の領域の関連会社の株式会社ノーススターでエ
先日、現場の人から質問を受けました。 「スクラムで進めているプロダクトに、大きめの問題(バグっぽい挙動)が見つかった。POは最優先で対応したいと思っているが、まず状況把握や原因調査だけでも時間がかかりそうで、ましてや対応までどのくらいかかるかわからず、1スプリントに収まる気がしない。どう対応していくのがいいか」 バグ対応とスプリントについては、いろいろな人が言っています。自分の中ではそういう話と自分の経験がまぜこぜになってしまっていますが、それを思いつくままに書き出して回答を送りました。なんとなく、自分にとっても整理された感があったので、こちらにも置いておきます。 問題を特別扱いしない。問題も、機能追加も、どちらも「理想と現実のギャップ」であり別々に扱う必要はない。どちらも同じように、調査や準備をし、見積もり、プロダクトバックログに入れ、優先順位を検討し、スプリントで開発する。 POが優先
▲ 2020年1月に開催された「Regional Scrum Gathering℠ Tokyo 2020」に登壇(撮影:藤村新 @aratafuji さん) こんにちは、椎葉光行(@bufferings)です。CircleCIでIC(Individual Contributor)としてシニアソフトウェアエンジニアをやってます。20代に小さな開発会社や派遣でプログラミングを覚え、30代をまるっと楽天で過ごし、2021年に41歳で転職しました。現在は大阪の自宅からフルリモートで仕事をしています。 この20年、ずっといろいろなことを学びながら過ごしてきました。その中でも特に楽天で過ごした30代は「密度の濃い10年間だったなぁ」と思います。エンジニアとして技術的な成長はもちろん、チーム作りや組織作りにも取り組み、人と一緒に仕事をすることについて考え続けた10年でもありました。 この記事では私の30
システム構築にかかるコスト・期間は20年単位で倍々に増加している。これは「2025年の崖」で示されているレガシーシステムの問題も大きいが、ウォーターフォールモデルで専門家による分業制をとっているシステム開発生産ラインのありようも看過できない。一方、アジャイル開発によるコスト削減や開発期間短縮の効果について、大規模な金融系システムでの実例はまだ少ない。さらに、昨今のマイクロサービスを実現するための設計手法も確立できてはいないと考える。 今回、筆者らチームは「ドメイン駆動設計」を活用し、システム構築コスト・期間を大幅に削減し、かつマイクロサービスに適合するシステム開発の可能性についてのPoCを実施した。
前書き🤔これは何RIZさんという一見AIイラストレーターを装った風来のシレン廃人にそそのかされて作ったちちぷいチャレンジが多数の愉快犯たちにおもちゃにされた結果書かないといけなくなった記事です。 Stable DiffusionやMidjourney、Nijijourney、NovelAIの使い方を詳しく解説した文書は数あれど、ふだんパソコンを使わない一般の人向けまで踏み込んで網羅している解説記事って案外ないかもな?と思ったのもきっかけではある! 書く前からわかってたんだけどボリュームがヤバいので稚拙な表現や抜け漏れ多数だ。公開後もちょくちょく手を加える可能性大だから、もし更新が気になるようであれば筆者のX, Blueskyアカウントをフォローするなり、気が向いた時にこのnoteに戻ってきてくれよな!! しばらく前提条件を書いておくので、とっとと中身を読みたい人は飛ばしちゃってください。
我々は1990年代初頭にスクラムを開発した。世界中の人たちがスクラムを理解できるように、スクラムガイドの最初のバージョンを2010年に執筆した。それ以来、機能的に小さな更新を加えながらスクラムガイドを進化させてきた。我々は共にスクラムガイドを支援している。 スクラムガイドにはスクラムの定義が含まれている。フレームワークの各要素には特定の目的があり、スクラムで実現される全体的な価値や結果に欠かせないものとなっている。スクラムの核となるデザインやアイデアを変更したり、要素を省略したり、スクラムのルールに従わなかったりすると、問題が隠蔽され、スクラムの利点が制限される。場合によっては、スクラムが役に立たなくなることさえある。 成長を続ける複雑な世界において、スクラムの利用は増加しており、我々はそれを見守っている。スクラムが誕生したソフトウェアプロダクト開発の領域を超えて、本質的に複雑な作業を必要
みなさんこんにちは。@ryuzeeです。 2023年1月11日-13日に開催のイベント「Regional Scrum Gathering Tokyo 2023」の登壇資料を公開します。 スプリントレビューは非常に重要なイベントです。 5つのイベントのなかでいちばん重要なイベントを選べと言われたら、僕はスプリントレビューを選びます。 スクラムはプロダクトを届けるためのものであり、プロダクトを成功させるにはプロダクト自体の検査と適応が必須だと思うからです。 一方で、スプリントプランニングの精度を上げようと頑張る割にスプリントレビューが雑に扱われる例が多くて懸念していました。 ということで、本セッションでは、スプリントレビューの目的や参加者、進め方、コツなどを深掘りしてみました。 みなさんの参考になれば幸いです。 忙しい方向けのまとめ スクラムチーム全員が参加しろスクラムチームの外側のステークホ
こんにちは ohayoukenchan です! 4月と言えば新生活。コネヒト株式会社も4月から、経営体制を一新し新たなスタートを切りました。 今期も心機一転して頑張っていきたいと思います。 この記事では先月末に開催した下期(6ヶ月)のチームふりかえりで行ってとても良かったなと思ったことについてお伝えできればと思います。 中長期(数ヶ月間隔)のふりかえり会の意義 スプリントでのふりかえりは、スプリントごとにレトロスペクティブの時間を設けています。 KPT法に似たような方法ですが、例えば下図のような感じでチームで起こったできごとに「ありがとう」や「happy-bad」と書かれた領域に付箋を貼って、特に関心の高いものに対して次のスプリントへのtryを決めていきます。 スプリントごとのふりかえり また、弊社の別のチームでも、Win Sessionで元気に目標を達成するチームづくりの記事にあるように
Agile Journeyをご覧のみなさん、はじめまして。川口恭伸(@kawaguti)と申します。 私はアジャイル開発やスクラムに関する知識を提供し、モダンなソフトウェア開発の要素の研究、プロダクト開発の進め方やチームの目標設定など、さまざまな領域でのコンサルティングを手掛けています。 また、アギレルゴコンサルティング株式会社においてシニアアジャイルコーチとして活動しており、一般社団法人スクラムギャザリング東京実行委員会と一般社団法人DevOpsDays Tokyoの代表理事も務めています。さらに、コミュニティ活動としては、毎週水曜日に品川アジャイルに参加しており、RSGT、スクラムフェス、DevOpsDaysといったカンファレンスでのスタッフワークも担当しています。 このように、ほぼ公私の境なくアジャイルやスクラムを基にした活動を長く行っていますが、本稿では、私がスクラムを始めるまでの
こんにちは。BASE BANK 株式会社 Dev Division にて Manager をしている東口(@hgsgtk)です。 昨年 2020 年は本ブログにて個人の足し算ではなく掛け算で成果が出せるようなチームを目指したアジャイル開発の取り組みを継続して紹介してきました。 チーム開発の潜在的課題が見つかる振り返りワーク「Mad Glad Sad(喜、怒、哀)」 少人数でのアジャイル開発への取り組み実例 (一歩目の踏みだし方) | 詳説 | July Tech Festa 2020 登壇レポート アジャイル開発におけるユーザーストーリー分割実践 〜画面リニューアルの裏側〜 これらの考え方やプラクティスは全体の一部で、開発チームとしての組織ローカルなプラクティスを『BANK DEV 白書』として整理しています。『BANK DEV 白書』では次のような内容を整理しています。 一般的なアジャイ
突然ですが、あなたはRailsのissueとプルリクがいくつあるかご存知でしょうか? 2019年10月17日現在、それぞれ issue 384 / PR 803 になります。 多いですよね...。 個人的に、最近このissueを減らすのを少しでも手伝えないものかとissueにコメントしてみたり、パッチを書いたりしてるけど、 なかなか大変なので、コントリビューターの敷居を下げるためにブログ記事を書いてみました。 コントリビュータが増えれば、きっとissueも減るはず!! Rails への貢献について Railsガイドに丁寧な説明が記載されているので、読んだ事がない方は一読するのをオススメします。 railsguides.jp この記事で紹介すること Rails への貢献方法は色々なものがあります。 新機能の追加 バグの報告 バグを修正するプルリク作成 ドキュメントの追加や修正 ...etc
IPA(独立行政法人情報処理推進機構、理事長:富田 達夫)は本日、アジャイル開発を外部委託で行うケースを想定したアジャイル開発版「情報システム・モデル取引・契約書」を公開しました。 URL: https://www.ipa.go.jp/ikc/reports/20200331_1.html 経済産業省が推進するデジタルトランスフォーメーション(DX)の時代では、その中核となる情報システムの開発にも、ビジネス環境の変化への俊敏な対応が求められます。そのため、技術的な実現性やビジネス成否が不確実な状況でも迅速に開発を行い、顧客の反応に基づいて素早く改善を繰り返すという、仮説検証型のアジャイル開発が有効となります。このような観点から、同省が2018年9月に公開した「DXレポート」では、DXの進展によるユーザー企業とITベンダー(ベンダー企業)の役割変化などを踏まえたモデル契約見直しの必要性が指摘
マネーフォワードビジネスカンパニー クラウドERP本部 会計Plus開発部の西村です。 エンジニアリングマネジャーとして クラウド会計Plus の開発に携わっています。(執筆時) 本記事では ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方 を何度も読んだ私が toB 向けのプロダクト開発において経験し、考えたことを紹介します。 私は2021年1月にソフトウェアエンジニアとして入社し、グループリーダーを経て、エンジニアリングマネジャーとしてマネジメントに従事しているという立ち位置です。 もちろん1人でなしとげたことではなく、チームで考えて、学んで、成長してきた記録です。 https://www.oreilly.co.jp/books/9784873119465/ この本はインセプションデッキなどを紹介した アジャイルサムライ のジョナサン・ラスマセンの新作。著者が
「自分ができるタスクもうないので次のスプリントのPBIに着手します」問題をなるべくわかりやすく説明したい。良い例え話あるかな。— ama-ch (@ama_ch) August 6, 2021 を見ていて、うちのチームのデイリースクラムを紹介したくなったのでかいてみます。こういうのを書くのははじめてかもしれない。 全体デイリースクラム まず、決まった時間になったら一つの部屋に集まって、全体のデイリースクラムをする。今は3チームくらいあるので、全体でやりとりしたいことも多い。 全体のゴールとかあるわけでもないので、ただの朝会って感じ。(「朝会」でいいのかも) チャットで報告でおしまいでもいいのだが、「知らなかったー」とかはあるので、共有したい勤怠の連絡事項とか、今日はリリースがありますねーとか、この前の障害についてですがー、などなど、全体で知っておきたい情報はここで共有する。 現状、品証チー
スクラムではチームの成果にフォーカスする。 そのためには、個人で仕事をする形から、チームで仕事をする考え方にシフトしないとけない。 いわゆる Swarming という考え方で、チームが寄ってたかって一つの開発アイテムを進めることを意味している。 逆に、チームでバラバラと仕事を進めるわけではない。 イメージしにくい人は、アメフトの試合で、ボールがフィールド上にいくつあるのか(1つに決まっている)、チームはどのボールに向かっているのか(1つに決まっている)を想像してみるといいと思う。あっちもこっちもボールが転がってたら大変だ。面白そうだけど。 なぜチームで仕事をするのか 5つの機能がスプリントのスコープに入っているとする。 5人でこれらに取り組むとする。 効率を重視したこれまでのやり方で言えば、各自が分担してそれぞれの機能の開発を進める。 この場合、それぞれが進める中で、 レビューが必要になる
こんにちは。BASE BANK 株式会社 Dev Division にて、 Software Developer をしている東口(@hgsgtk)です。 TL;DR バーティカルスライスでのデリバリーを可能な限り保つユーザーストーリーの分割はどうすればいいか ユーザーストーリーが 1 回のイテレーションで収まらないような場合に分割する 3つの分割軸「データ境界に沿って分割する」・「パフォーマンス制約をストーリーにする」・「アクターのモチベーションで分割する」をもって、ユーザーストーリーを分割する ビジネス価値の内訳要素に基づいて優先順位を考える 当記事の背景 BASE BANK Dev Division での開発プロジェクトでは、アジャイル開発の考え方・取り組みを取り入れています。その導入については、「少人数でのアジャイル開発への取り組み実例 (一歩目の踏みだし方) | 詳説 | July
🐳この記事は「ログラスサマーアドベントカレンダー2023」の28日目の記事です。 次はデザイナーチームの高瀬さんです。 こんにちは、ログラスの松岡です。 ログラスのプロダクトチームでは、ドメイン駆動設計とアジャイルプラクティス(スクラム、エクストリームプログラミング等)を併用していました。 その中で、「アジャイル・フルーエンシーモデル」(以下、省略時には「フルーエンシーモデル」と表記)という概念が多くのプラクティスを取りまとめ、全体感を把握してチームの成長余地を考えるのに役立つものなので、この記事で紹介したいと思います。 アジャイル・フルーエンシーモデルの面白いポイント 面白いポイントはいくつもあるのですが、この記事で紹介するポイントは二つあります。 ポイント①: 技術的負債への対策が組み込まれている 一つは、「技術的卓越性によってアジャイルの持続可能性(サステナビリティ)を高めるという
スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する WEB+DB PRESS plus 作者:粕谷 大輔技術評論社Amazon だいくしーさんこと、粕谷大輔さんの『スクラムの拡張による組織づくり』を読みました。 複数のスクラムチームを協業させていく手法として「Scrum@Scale」を軸に、スクラムという概念自体のおさらいから始まり、コミュニケーションを軸とした組織の作り方、運用の仕方を解説していく構成になっています。 第3章で出てくる「毎日45分で問題が解決する」というのはなかなかキャッチーな表現で、Daily Scrum -> Scaled Daily Scrum -> Executive Action Teamのそれぞれに15分という目安を作ることで、議論ではなく問題の確認と決定の場としてショートに実行するものである、という定義が明確で分かりやす
背景SRE という概念が生まれてから数多くの開発チームで「ソフトウェアエンジニアリングの手法で運用を改善する営み」が行われてきた。 同時に、技術的負債が経営レベルで認知されるようになり、日常の会話の中でも長期・短期のトレードオフを念頭に置いたプロジェクト推進がやりやすくなったのは言うまでもない。 しかし、スタートアップでは Dev と Ops が別れていることは稀で、「全員が全てに対応する」ような状況になってしまうことがしばしばある。これは小さい組織だけの問題ではなく、例えば大企業の中の新しいプロダクト開発チームでも同じことが言える。 SRE を念頭に置き、技術的負債の主導権を握るために必要なチーム体制とはどういうものなのだろうか? タスクの分解小さな組織のソフトウェアエンジニアは日々数多くのタスクを与えられている。場合によっては数名のメンバーで新規機能開発から日々の不具合修正、そして S
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く