ざっくり理解するSRE - Qiita
昨今では自社のプロダクトやシステムのエンゲージメント向上のために、「DevOps」や「アジャイル」といったキーワードのもと、大小さまざまな企業がシステムやアプリの開発手法の改善を試みています。その中において、最近だと「SRE」というキーワードを聞く頻度も多くなってきたかと思います。 しかしアジャイルやCICDなどと比べ、SREについては「言葉は知ってるけど具体的になんなのかはよくわからない」という方もいるのではないでしょうか？ここではそんな方々向けに、SREの最初の一歩となる概要について、独自の解釈を交えつつまとめていきます。 ここで話すこと SREって何？ なぜSREが必要？ SREってどんなことするの？ ここで話さないこと SREの技術の具体的なところ（k8sやAPMの導入手順、設定方法など） プラクティスの実践例・具体例（アーキテクチャ、各種設定値、モニタリング指標など） TL;DR
スケジュールにバッファを設けるのは悪か？ - ユニファ開発者ブログ
こんにちは、プロダクトマネージャーの田嶋です。 はじめにお断りしておきますが、本記事は、2021年7月にリリースした開発プロジェクト（以降「Rプロジェクト」）において、遅延なく開発を進められたことのプチ自慢です🎉 笑 週次で滞りなくバーンダウンが落ちていく様子を、チームで安心して見ることができました。スケジュールのストレスなく開発を進めることができたのは、チームの頑張りのほか、見積もりとスケジュール管理が良かったからだとも思っています！ 開発プロジェクトにスケジュールが求められる理由は様々ですが、キャンペーン施策や営業資料の準備計画を立てるため、あるいは利用顧客へも告知責任があるから、などです。そのいずれの場合も、計画やそのための作業見積もりは欠かせません。 しかし多くの開発プロジェクトにおいて、実績は見積もりよりも上振れし、遅延してしまうことが多いのではないでしょうか。 本記事では、R
プログラマーがドキュメントを書かない理由
この記事は、著者の許可を得て配信しています。 Why programmers don’t write documentation 最近ではずっとコードのドキュメンテーションに関連した記事を書いていたので、当然、私のMediumのおすすめ記事には「開発者がドキュメントを書かない本当の理由」という記事が表示されるようになりました。この記事では、ドキュメントを書くための優れたツールがないことが、ソフトウェアエンジニアが自分の作業や判断をドキュメンテーションする意欲を失わせる最大の原因について書いています。 私は普段、特定の記事を批判したりはしませんが、この記事には怒りを覚えました。このライターは図解ツールについていくつかメリットに関して述べてはいますが、全体的に誤解を招くような内容になっており、この重要な問題をより分かりにくくさせています。2つの図解ツールを比較して、どちらも不十分なツールである
VS Code の画面を共有するときはキー入力が見える「スクリーンキャストモード」を有効にしてみよう | DevelopersIO
VS Code の「スクリーンキャストモード」使ってますか？ スクリーンキャストモードとは 百聞は一見に如かず。 お分かりでしょうか。どのキーを入力したのかが一目瞭然です。マウスもクリック時には赤丸が表示されるのでどこをクリックしたかが分かりやすくなっています。（マウス押下時の黄色はスクリーンキャプチャソフトが付与したものです） スクリーンキャストモードは VS Code 1.31 January 2019 で搭載された機能ですが、意外と知らない人も多く、私自身この機能の名前がパッと出てこないこともあったので今回改めて紹介してみました。 https://code.visualstudio.com/updates/v1_31#_screencast-mode スクリーンキャストモードを有効にする デフォルトではショートカットキーは割り当てられていません。コマンドパレットから Develope
KPTのKがいまいち膨らまないチームに贈るパワフルな質問 - yigarashiのブログ
ふりかえりでKPTのようなポジティブ/ネガティブな話題を出すような手法を使っていると、悪いところの掘り下げはサクサクできる一方で、良いところをうまく膨らませるのが意外と難しいように思います。書いた本人に話してもらって、ファシリテーターが「いいですね」とコメントして終わりとか、「コメントないですか」と聞いて誰も話さなくて終わりとか、そういった場面を見たことがある人は多いんじゃないかと思います。悪いところを解決するのは慣れていても、良いところを伸ばすための道具箱が空っぽという状態ですね。 そんなチームの最初の道具として次の質問を贈ります。 それがうまくいった要因は何かありますか？ これです。なんとかのひとつ覚えで良いので、ちょっとでも話が広がらないなと感じたら、まずはこれを聞いてみると良いです。この質問が優れているのは、出来事や本人の経験から単刀直入にプラクティスを抽出できることです。何か聞き
なぜスクラムチームをスケールしたくなるのか - だいくしー(@daiksy)のはてなブログ
Nexus, Scrum@Scale, LeSS, SAFeなど、スクラムチームをスケーリングする手法はたくさん存在する。 しかし、アジャイルコーチなどに、「スクラムをスケールするにはどうすればいいですか？」と聞くと「そもそもスケールをするな」と言われることもある。ぼくも基本的にはこれに同意する。 コンパクトな職能横断型のチームで、短いサイクルで高速に、安定したペースで開発をする。これをずっと続けることができるのならばそれが一番良い。 なのになぜ、人々はスクラムチームをスケールしたくなるのか。なぜこんなにたくさんのスケーリング手法が存在するのだろうか？ そういうことを考えてみた。 最初から人がたくさん必要な場合 そもそも最初からスケールされたチームでやりたいパターンがある。大規模な開発などはそうだろう。 小さくローンチして、インクリメンタルにユーザーフィードバックを受けながら開発できれば理
「AWS Well-Architected フレームワーク」の「レビュープロセス」資料がとても良かったので紹介したい - Qiita
はじめに 仕事の品質を高める上で、知見のある方にレビューをしてもらうプロセスは欠かせません。 ただこのレビュー、やり方や意見の伝え方によっては、期待した効果が得られなかったり、ネガティブな効果を生み出しかねません。そうした結果、レビューという行為自体が開催されにくくなることは、チームにとって非常にマイナスです。 全員のレビューへの期待を整えておくために、レビューの心構えや望ましい運営方法などを、レビューに関わる全ての人が共通認識化しておくことは、非常に重要だと考えています。 今回、このレビューを効果的に進めるポイントをまとめた、とても良い資料を見つけたのでご紹介します。 レビュープロセス - AWS Well-Architected フレームワーク この資料をおすすめしたい方 エンジニアに限らず、仕事で他者の成果物をレビューをする人、および他者からレビューを受ける人（そう考えると、仕事をす
エンジニアとしての境界を超えることについて - まっしろけっけ
はじめに web service というものを開発するエンジニアには サーバサイド/インフラ/フロントエンド/iOS/Android などのそれぞれの専門(強み)を持ったエンジニアが存在していると思います。その専門性を境界として見た際に越境する/しないエンジニアではどのような違いがあるのかというのを自身の経験などから僕自身が考えている事をまとめていきます。 自身について 10 年以上お金を貰ってソフトウェアエンジニアをやっていて、その過程でサーバサイド/インフラ/フロントエンド/Android に関しての実務を一定期間行ってきたという経歴があります。現在は主にサーバサイド/インフラを中心として minne というサービスのシニアエンジニアリングリードというものをやっている。 書いたような領域以外でも DevOps みたいな領域の違いみたいなものもあると思いますが、僕自身 Dev と Ops
スクラムを個人戦にしてしまう方法 - 海と山が好き
スクラムではチームの成果にフォーカスする。 そのためには、個人で仕事をする形から、チームで仕事をする考え方にシフトしないとけない。 いわゆる Swarming という考え方で、チームが寄ってたかって一つの開発アイテムを進めることを意味している。 逆に、チームでバラバラと仕事を進めるわけではない。 イメージしにくい人は、アメフトの試合で、ボールがフィールド上にいくつあるのか（１つに決まっている）、チームはどのボールに向かっているのか（１つに決まっている）を想像してみるといいと思う。あっちもこっちもボールが転がってたら大変だ。面白そうだけど。 なぜチームで仕事をするのか 5つの機能がスプリントのスコープに入っているとする。 5人でこれらに取り組むとする。 効率を重視したこれまでのやり方で言えば、各自が分担してそれぞれの機能の開発を進める。 この場合、それぞれが進める中で、 レビューが必要になる
エンジニアリングスキルで捉えるチームマネジメント - mtx2s’s blog
チームのマネージャーが、自らの責務をジョブディスクリプションとして明文化することは難しい。職務内容や権限を、断片的にしか書けないかもしれない。もしそうなるなら、実務も断片的になっている可能性がある。 チームマネジメント（組織マネジメント）という活動は、個々のマネージャーの経験や関心によって、断片的になりやすいように感じている。断片的とは、マネジメント活動が、責務の一部の領域に偏ってしまっていたり、問題を検知してはじめてその領域がマネジメント範囲であることを知る、といった様子を指している。 このような状態になる背景は、マネージャーにとって、マネジメントが、日々の実務を通して蓄積された経験に基づく活動になっているからではないか。マネージャーは孤独だ。ひとりでその責務を担う。エンジニアとは違い、チームで協働するわけではない。だから、形式知として言語化されず、個人の経験として暗黙知にとどまる。その
本戦敗退から学ぶISUCONの正しい歩き方 - そーだいなるらくがき帳
様々なことがあり、繰り上げで本戦出場になり、結果32チーム中の12でした。 これが僕らの全盛期。 実質優勝 最終結果。 isucon.net id:kamipo さんが素早くINDEXを対応してくれたおかげで初動は早かった。 けど伸び悩み、結果12位でフィニッシュ。id:sugyan さんのコーディング力をチームとして引き出す判断が最初に出来なかったのが大きな課題だった。 時系列で知りたい人はこちら。 memo.sugyan.com 大きな課題になった理由 帰りの電車の中で @mirakui さんが 「ISUCONってユーザのシナリオを知って、それに合わせてチューニングすることが大事でそういうところが好きなんですよね」って言ってて、だからこんな準備をしたって話を聞いてて、僕はSQLとDBの点でしか見てなかったなぁと思う。— そーだい@初代ALF (@soudai1025) October
こんなスクラムには気をつけろ!?
こんにちは。@ryuzeeです。 支援をしている際に、こういう兆候があったら注意して見る、というポイントがいくつかあるので共有します。 あくまで課題発見用のツールなので、マルバツ表を作ってどうこうする、という類のものでもないですし、そうすべきでもありません。 スクラムマスターの人、外部から支援する人は、自分用の確認ポイントを整理しておくと良いと思います。 なお、スクラムを実践すること自体は目的足り得ないので改めて言っておきます。 全体なんでもアジャイルでやろうとするそもそもアジャイルを採用することが目的化しているプロジェクト初期にマイルストーンやスケジュールを決めていない十分にトレーニングを受けていない認定資格をとればそれで十分だと思っている全体の要件やアーキテクチャを考えずいきなりコードを書く予定できることなのに、「アジャイルだから」と予定しないドキュメントを書かない文化や考え方を変える
「きょん、やっとむ、Ryuzeeらと語るアジャイル開発の本質」参加レポート #densohack - Qakink blog
イベント概要 先日、アジャイルの本質について語るイベントが日本橋で開催された イベントのテーマは「本質を理解しないままのアジャイル開発に挑む危うさ」 アジャイル3怪獣 と呼び声の高い (?!) お三方がアジャイル開発の本質を激辛トークで深掘り 会の後半では、参加者を交えたディスカッション（フィッシュボール形式）も行われた イベント詳細はこちら：https://connpass.com/event/96750/ 登壇者 やっとむさん「アジャイルってなにが美味しいの？」 きょんさん「目的論からのアジャイル～手段を目的化すること～」 ryuzeeさん「アジャイル開発でコールド負けしないための5つのポイント」 感想を一言で言うと タイトル通り、内容が本質すぎて辛かった 終始「ぐぬぬ…」となる胸熱展開のオンパレードでした 「アジャイルってなにが美味しいの？」 by やっとむさん 登壇資料 そもそもア
プロトタイプを使って要件をまとめるときに気をつけるべきこと
JoeはUX/CXコンサルタントとして長年のキャリアがあり、現在はUXに関する書籍、講演などを多数手がけるUXの伝道師です。 「要件を決めた時に想像していた仕様と違う」 開発チームのほとんどが、プロジェクトの中でも最悪のタイミングで、このような発言を聞くはめになります。大抵、このようなことが起きると、開発者は自分を正当化しようと怒り出します。正確に要件を定義していなかったとステークホルダーを叱責するのです。 これはもっともな怒りではあります。しかし、同時にこの状況の責任は私たち開発側にもあることも事実です。 私たちは認識のズレを埋めるため、要件に必要なことをステークホルダーに伝えてきれていません。この記事では、開発の現場で起きがちなことについて話していきます。 要件をまとめることの背景にある厳しい事実 要件が決められるのは、大抵ステークホルダーとのミーティングのときです。ステークホルダーは
天才でなくていい！『Team Geek』訳者・角 征典と考える、チームに貢献するエンジニアの気配り力 - エンジニアHub｜Webエンジニアのキャリアを考える！
天才でなくていい！『Team Geek』訳者・角 征典と考える、チームに貢献するエンジニアの気配り力 「チーム開発を進めるために、エンジニアはどう振る舞えばいいのか」に迫る、名著『Team Geek』。その勘どころを、訳者である角 征典さんと読み解きます。 数多くの開発者から支持を受け、読み継がれてきた名著。そこには読み継がれる理由があります。 名著には、内容・ボリュームともに充実した書籍が多く、概要に目を通しただけで本を読んだつもりになっていたり、腰を据えて読む時間がなく「積ん読」してしまいがち。「エンジニアが絶対読むべき書籍●選」といった記事をブックマークするだけで読んだつもりになっていないでしょうか。 ポイントを押さえつつ内容を深掘りし、名著の根底に流れるエッセンスを開発に活かしましょう。 エンジニア向け名著を読み解いていく当企画。第4回に取り上げるのは『Team Geek—Goog
1on1を始めて1年ぐらい経った - 個人的なまとめ
フロントエンドチームの取りまとめをすることになったので、元々サーバサイドエンジニアである自分とみんなが考えていることとズレが無いようにしたくて始めた。あと実際にサービスを開発してるメンバーと会社が考えていることの期待値合わせという意味もある。なお、会社のエンジニア全員とやってるわけではなく自分のチームでやってるだけである。また、対象は業務委託の人も含んでいる。業務委託の人を含めてよいか？という話はあるが、自分は評価者ではないということと、これによって契約が左右されることはほぼないということは念を押してる。 始める前によんだもの この辺 d.hatena.ne.jp ofsilvers.hatenablog.com ヤフーの1on1―――部下を成長させるコミュニケーションの技法 作者: 本間浩輔出版社/メーカー: ダイヤモンド社発売日: 2017/03/25メディア: 単行本（ソフトカバー）
アジャイルFAQ | ワイクル株式会社
コンサルや研修しているときに聞かれた質疑応答の一覧です。ひとまず2017年にいただいたものをまとめました。 Q. 1人でスクラムを始めたいと思いますができますか？ 「スクラム」はできないですが、スクラムのなかの特定の手法は可能です。たとえば、バックログを作って上から順番にやっていくとか、定期的にふりかえるとか。 Q. 遠隔チームでのスクラムはデジタルツールを使えば可能？ 「最初のうちは同じ場所で、慣れてきたら離れて」が基本 チームの成熟度次第なので、最初からうまくできるチームもあります Q. チームの相乗効果を上げるにはどうすれば？ チームの数だけやり方がある。 チームだけの文化や言語を作っていくことが重要かも。「一緒にご飯を食べる」というのは鉄板です。 『Team Geek』オススメです！！！！！（宣伝） Q. 開発チームがステークホルダーに直接アクセスするのはNG？ あとでPOに情報共
開発運用チームを立て直した話 - 下町柚子黄昏記 by @yuzutas0
SPI Japan 2017というカンファレンスで発表をしました。 グロースフェーズの痛みの中で、いかに開発・運用チームを立て直したかという内容になります。 発表スライド 「Rebuild Team - 急成長プロダクトのDev&Opsで生じる悪循環とその解決策」 ここ最近の発表の集大成です。 急成長フェーズを体験した人は多くないはずなので、有用な知見ではないかと自負しています。 参加した感想 運営が非常に丁寧でした。選考通過時にはレビュアーから「こういう点が素晴らしい」とコメントいただき、また当日には司会者からフォローをいただき、非常に話しやすい場作りがなされていました。 一方で内容面については全体的に違和感を覚えました。もやもやです。 内容 思ったこと 補足事項 「改善施策が現場に受け入れられない」という意見が多かった 改善施策は現場の人が現場のために生み出すものではないか。 現場にメ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ペアプロの心得
「開発チーム」で本当に大丈夫か考える - Speaker Deck
