「レガシーコード改善ガイド」を頼りに、3つの絶望から這い上がる:技術的負債が焦げ付いている(1/2 ページ) 4人家族の家事育児をワンオペで担っているエンジニアリングマネジャーの陽太郎さん。仕事の繁忙期も相まって地獄絵図と化した自宅の様子に、つい叫んでしまいました。もうウンザリです、何も改善できません!
こんにちは。スタディサプリ小中高 / Quipper SREの@kyontanです。 この記事は Recruit Engineers Advent Calendar 2022 の1日目の記事です。 開発チームが事実に基づいて(= fact-basedな)意思決定をできるようにするための一助として、SREチームではSLO (Service Level Objective)が設定されていることをサービス公開時の要件としています。 スタディサプリ小中高におけるSLOの運用については、以前弊チームの@chaspyが SRE NEXT 2020 で「SLO Review」というタイトルで登壇しました #srenext という記事を書いているので、こちらもご参照ください。 本記事では、これまでしきい値によるアラートを設定していたSLOについて、Burn Rateによるモニタリングを試してみたので、ざっ
13分33秒からのパートで、「正直優秀とはいえないメンバーが集まり、テクニカルスキルもチームワークもビジネスドメインも理解せずスクラムを実践したら、毎回のスプリントで『ゴミ』ができる」と話して会場の笑いを誘っています。その上で、「でもそれは良いことだ。現在地がはっきり分かっていること、これこそが透明性なのだ」と説きます。 このように、良しあしの判断は抜きにして、起きていることをあるがままにまずは見えるようにすることは、ポイントです。 他者とのコラボレーションにおける透明性 ここまで書いてきた透明性は、主に仕事の内容や成果物を対象にしました。しかし透明性は、より広範囲な具象を対象にでき、実際には表には出てこない内容についても必要になります。 具体的には、他者とコラボレーションやコミュニケーションする場合です。 これを分かりやすくあぶり出したものが、Agile2016でのBecky Winan
はじめまして、高橋陽太郎です。リクルートでエンジニアリングマネージャーをしています。 わが家は、小学校4年生と小学校2年生の子ども2人と、トイプードルの娘と、妻1人がいる5人家族です。先日まで妻が渡米しており、1年弱子どもたちと4人暮らしをしていました。 最初は文字通り地獄のような日々でしたが、カイゼンを繰り返すうちに、日々のソフトウェア開発の知識が、家事育児の多くの場面で応用できることに気が付きました。ご縁あってこの取り組みを、@IT自分戦略研究所で連載することになりました。 本連載は、仕事と家事の両立が当たり前のトピックとなってきた昨今、エンジニアが普段持っていて使っている知識や経験を生かして、家事育児を楽しみながらカイゼンするコツをお伝えしていきます。どうぞよろしくお願いします。 ワンオペストーリーは突然に 「ねぇ、1年間米国に行ってきていい?」 妻からこの一言を聞いたのは、渡米の4
本ブログは Recruit Advent Calendar 2021 - Adventarの25日の記事になります。 ITビジネスやサービスにおけるプロダクト開発で良くある、作りすぎ。やりすぎ。 無駄なく、効率的にと思っても、ついつい発生しちゃう。 こういうの、オーバーエンジニアリングって言うらしいよ!? でも、どこからオーバーで、どこまではオーバーじゃないんだ!! ということで、勝手にオーバーエンジニアリングを定義してみようと思います。 作り過ぎて、時間や金を無駄にすること???? とっかかりとして・・・まずは一般用語としてのオーバーエンジニアリングの意味をwikiで調べてみると以下のように記述されています。 wikipedia(英語版) Overengineering - Wikipedia 一部抜粋。 Overengineering (or over-engineering,[1]
A-5 12/11 15:10 ~ 15:35 制約が多い大きなプロダクトに新卒で飛び込み、バリバリ案件開発に貢献するようになるまでの道のり。 タウンワークには、歳月を重ねることで複雑化した組織とシステムがあり、ソースコードに目を向けても継ぎ接ぎしてきたエンハンスの形跡、改修の歴史があります。 開発に従事するエンジニアはこれら全てを把握して初めて大きな障害のないリリースを積み重ねることができ、事業価値に貢献できます。 右も左もわからない新卒エンジニアだった私がフルリモートの環境で技術だけでなく、これらの制約を高速でキャッチアップし、配属から1年を経て案件開発を牽引するまでに至った取り組みの数々を紹介します。技術と既存コードの理解、品質担保、事業理解という3軸で試してみたことの良し悪しも含め赤裸々にお話します。 河内 友佑[リクルート] 株式会社リクルート 2020年 株式会社リクルートに新
スクフェス札幌2021のスライドまとめです。(2021/11/9現在) もし自分がスライド見つけ切れていないものがあれば、教えていただけるとありがたいです。 confengineの上から順に貼っていきます。 https://confengine.com/conferences/scrum-fest-sapporo-2021/schedule Toshiharu Akimoto / Shigeo Konno - コーチズクリニック活用のススメ Tatsuya Sato - ふらっと立ち寄れる廊下のある風景 -- フラットでオープンネスがもたらす魅力 平鍋健児 - アジャイルの旅支度 ー ここではじめる、自分ではじめる izumi ito - チームが前に進むために、私が取り組んできたいくつかのこと Junki Kosaka - 自分が変わること。アジャイルやスクラムで自分が変わったこと。 C
スクフェス三河の動画をぼちぼち見ていこうと思い、とりあえずスライドまとめをまずは見ようと考えた所、スライドまとめがないことに気が付いたので、まとめておきます。 Yasunobu Kawaguchi - 「10分でスクラム」スクラムをほかの人に伝えたくなったときに、私は何をしたか。 Hiroki Hachisuka - 「これがティール色?」~会社も歳もスキルも違う仲間で、プライベート開発を始めたら見えてきた世界~ Tomonari Nakamura ( ikikko ) / Shinnosuke Yata - えっ、まだユニットテスト書いてない現場があるんですか?~ ボトムアップでもっといけてるチームになるために、たった一つの大事なこと ~ eroccowaruico - 一期一会(弱虫がつむぐ点と線) Yotaro Takahashi - 狙いはボトルネックだ。小さい課題には目もくれるな
『プロダクトオーナーマニアックス! POとSMの原点の原点をさかのぼって学ぶ初代主査 中村健也の働き方』 スクラムのPOとSMはジェフ・サザーランドによればトヨタのチーフエンジニア制度から着想を得ましたが、和田明広によればチーフエンジニア制度は他社では積極的に導入を試みるもうまく機能しておらず、まして現在のトヨタでも機能しているか疑わしいと厳しい評価をしています。 このセッションでは、私たちがプロダクトオーナーという役割をより効果的に果たしていくために「そもそもチーフエンジニア(主査)とはなんだったのか」を「中村健也」という人物を中心に、POとSMの原点(チーフエンジニア制度)の原点(中村健也)を70年ほどさかのぼり、プロダクトオーナーが効果的に力を発揮するための知恵を探ります。 https://confengine.com/conferences/scrum-fest-osaka-202
この記事は「全enPiT Advent Calendar 2020!!」クリスマスイブの記事だよ。メリクリ。 adventar.org 2013年から続く文科省事業であるenPiTでは、わたしは主にビジネスアプリケーション分野、ビジネスシステムデザイン分野でいろいろと教えてきた。*1 master.enpit.jp bizsysd.enpit.jp この分野はそれぞれ「進化を続ける先端情報技術や情報インフラを有機的に活用し、潜在的なビジネスニーズや社会ニーズに対する実践的な問題解決ができる人材を育成」「実践的な問題解決を自発的に行えるイノベーティブな人材を育成」するプログラムとのことだ。 ちなみに事業としては他に、組み込み分野、クラウド分野、セキュリティ分野、とあるところから、ビジネスシステムデザイン分野は特化する要素技術のない総合的な分野だと思っている。 ところがビジネスとはなんぞやとい
はじめに これは Recruit Engineers Advent Calendar 2020 - Adventar および テスト駆動開発 Advent Calendar 2020 - Qiita の10日のエントリーです。 コミュニティでの活動としてTDDBCのお手伝いをしてるのですが、twadaさんの基調講演&ライブコーディングはすごいですよね。何度聞いても日々バージョンアップがあって新鮮。 で、先日 TDD Boot Camp 2020 Online #1 - connpass が実施された時1に、YoutubeLiveで公開された基調講演&ライブコーディングのコメントでの質問回答を YASUI Tsutomu (@yattom) | Twitter さんとさせていただいたのですが、その時に、これまで何度も基調講演聞かせてもらったおかげか、twadaさんが喋ってる内容がある程度予知
この記事は Recruit Engineers Advent Calendar 2020 の 9日目の記事です。 自分はAndroidエンジニアとして6年ほど開発に携わっています。 6年ほど開発をしていると、昔よく使っていたデファクトスタンダードなライブラリやコーディング記法が、今は非推奨になっていたり、新しい便利なライブラリが増えたりするので、必要に応じて保守しているコードに取り込む必要があります。 「古い書き方のコードでも動いているからいいじゃん」って方もいらっしゃるかもしれないです。短期的な目線で考えた場合は悪くはないと思いますが、非推奨になったものが突然動かなくなるリスクもありますし、チーム開発しているコードだと、もしかしたら新しいエンジニアの方は古い書き方を知らない(使わないから学習していない)からコードの保守ができない、など発生するかもしれないので、個人的には早く対応していきた
職務を明確に定義する「ジョブ型」雇用の欠点は、特集1話目でも指摘した通り、自分のジョブを超えて業務を拡大するのが難しいこと、職務が明確な半面、硬直化しやすく、時代の要請に対応しづらいこと、ジョブローテーションにより、本人さえ気づかなかったような適職に巡り会うキッカケを得にくいことなどだ。 雇用の支援を祖業とし、人材輩出会社として知られるリクルートグループは、ジョブ型のこうしたネガティブな面を認め、60年前の創業以来、メンバーシップ型でもジョブ型でもない独自の「ロール(役割)型」人事を貫く。
こんにちは! リクルートテクノロジーズでセキュリティエンジニアとして活動している、藤原 巧です。 毎年恒例となっており、大きな反響をいただいている、エンジニアコースの新人研修の内容を紹介させていただきます。 研修の概要 リクルートテクノロジーズでは、新卒採用の新人向けに3ヶ月間の技術研修を行っています。この技術研修では大きく分けて2つのコースが設けられています。 1. プログラミングやWebサービスの構造の基礎を体系的に学び、その後一人につき、ひとつのスマホサイトを企画からリリースまで行うコース 2. 一定以上のプログラミングスキルと開発系経験がある新人に向けた、実際の開発で必要となる様々な技術要素をより深く学び、その後実際のサービスでチーム開発にてOJTを行うコース 今回公開するのは 2. で使用した資料です。 この技術研修は、そのほとんどの部分を内製で実施しています。 この研修の最大の
TDDBCオンライン#01 よかったですね! 関わっていただいたみなさんありがとうございました。 運営のコアメンバーの1人として、とてもうれしく思います。 TDDBC初のオンライン開催としては成功と呼んで良いのではないでしょうか。 運営としての残りのお仕事 さて、運営のお仕事はまだ残っています。それは今回開催のふりかえりです。うーむ、どうしたものか。 いきなり集まって「ふりかえりしようぜ!」と宣言するのはカンタンなのですが、話題が散らかってしまったり、共感が集まるだけで、結局モノゴトが前に進まない予感がすごいです(それはそれで楽しいのだけど)。 じゃあ、何をふりかえりましょうか? そこで考えたのは「次のTDDBCオンライン開催に役立つ情報を残すこと」です。 これは、運営のコアメンバーがやるべきことの1つだと思います。コアメンバーは運営に関する意思決定を行ったり、意思決定の場に同席する回数が
7. リソース効率性とフロー効率性 A A A A A A A A A A A A A A A B C B C B C B C B C B C B C B C B C B C B C B C B C B C B C A A A A A A A A A A A A A A A B B B B B B B B B B B B C C C C C C C C C 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 1w リリースまでのリードタイム 約2w リリースまでのリードタイム 3w リリースまでのリードタイム 3w リリースまでのリードタイム 3w A機能、B機能、C機能の実装それぞれ15人日かかる場合 A A A B B B B B B
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く