Findy転職フロントエンドの開発生産性を向上させるためにやったこと - Findy Tech Blog
こんにちは、ファインディ株式会社でフロントエンドのリードをしております 新福(@puku0x)です。 この記事では、転職サービス Findy の開発チームにおける開発生産性の向上に対する取り組みをご紹介します。 以前の状況 モノリスの解体 開発基盤の刷新 コンポーネント設計の刷新 テストの拡充 CI の高速化 改善の効果 まとめ 以前の状況 2020年頃の Findy は Ruby on Rails と React のモノリス構成で作られていました。 機能の増加に従いコードが複雑化し、しだいに開発スピードが伸び悩むようになりました。 ここで Findy Team+ で算出した当時のリードタイムを見てみましょう。 2020年のFindyのリードタイム 上記のグラフから次のことがわかります。 改修が本番に適用されるまで 約1週間 かかる プルリクエストがレビューされるまで 約5日 放置される
うまくいっていても、組織にはスクラップアンドビルドが必要。タイミーが「短期的な非合理」を選び続ける理由【kameike×赤澤】
TOPインタビューうまくいっていても、組織にはスクラップアンドビルドが必要。タイミーが「短期的な非合理」を選び続ける理由【kameike×赤澤】 うまくいっていても、組織にはスクラップアンドビルドが必要。タイミーが「短期的な非合理」を選び続ける理由【kameike×赤澤】 2024年3月18日 株式会社タイミー VPoE 赤澤剛（Go Akazawa） 2009年に株式会社ワークスアプリケーションズに入社、ERPパッケージソフトウェアの開発とプロダクトマネジメントに従事。2015年よりシンガポール及びインドにてR＆D組織の強化、海外企業向け機能開発をリード。その後LINE株式会社での新銀行設立プロジェクト、株式会社アルファドライブ及び株式会社ニューズピックスでの法人向けSaaSの開発に携わった後、2021年1月にアルファドライブ執行役員CTO、2023年4月に株式会社NewsPicks f
生産性が低いチームを強くするには？ うまく成長するための「順番」がある
これらの数値は、数多くの開発チームを分析しクラスタリングした上で、ハイパフォーマーの特徴として抽出されたものです。ここでの重要な問いとして、「Four Keysといった数値を高めたら、自分たちが目指す強い開発組織の状態になるのか？」というと答えは、NOです。 特に開発生産性の可視化は、管理や監視のために測定するのはアンチパターンで自分たちのケイパビリティー向上のために使わなければ、逆効果になるケースもあります。よくあるケースとしては、開発生産性の指標をハックして無理やり数値をよく見せる行為です。自分たちのために計測していれば極端にハックする意味がないことは明白ですが、開発生産性を存在価値のために数値を提供すると、ある事象が起きやすいので気をつけたいところです。 こういった事象を「グッドハートの法則」と言います。または「キャンベルの法則」という類似の法則もあります。どちらの法則も、組織や制度
「属人性を高める行為は知的謙虚さにかける」という考え方を知り、プロジェクト推進の標語にすぐにしたいと思った話。
最近読み終えた本の中でこれはアタリだったなと思う本がある。 GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ、というものだ。 この本は昨年、私がプロジェクト伴走支援をしている会社の代表の方からオススメしてもらった。 タイトルどおりGitLab（ギットラボ）社とは世界最大のリモート組織である。 ・世界67カ国以上に従業員2,000名以上 ・自社オフィスを持たない世界最大のオールリモートカンパニー ・リモートワークのための方法論やカルチャーを「GitLab Handbook」として公開 ・リモートワークの方法だけでなく評価、給料の決め方、部門ごとの仕事の進め方など、社員として必要な知識をすべて支える「ドキュメント文化」が浸透 GitLab社のマニュアル原本は大変情報が膨大らしく、いきなりこれらすべてを読み解くの
ヘルプデスク業務を楽にするためにSlackとGitHub Projectを同期するヘルプデスクツールを自作した - MNTSQ Techブログ
こんにちは。MNTSQの下村です。 コーポレートエンジニアとして、MNTSQ従業員の生産系向上施策等を実施していたりします。 ( Twitterもやっている のでフォローしてもらえると嬉しいです！ ) 本日は社員からの問い合わせ業務 いわゆる ヘルプデスク業務について効率化するためのツールを自作した 話を書いてみます。 この記事の要約 一人目コーポレートエンジニアとして参画したがヘルプデスク業務が非効率だったので効率化した。 質問に対して特定のemojiを押すとGitHub ProjectsのItemを作成するようにした。 SlackスレッドのコメントとGitHub ProjectsのItemを双方向同期するようにした。 Azure OpenAIも利用して効率化した。 きっかけ 2023年5月からMNTSQの一人目コーポレートエンジニアとして参画しています。 情報システムを色々と整備してい
開発生産性を改善するためにやったこと
こんにちは、株式会社スマートショッピングでエンジニアリングマネージャーを担当しているleafです 先日開催された Findy Team+ Award 2023 にて組織別部門(50人未満の組織規模)とチーム別部門(レビューリードタイムが早い)を受賞することができましたので、Findy Team+ 導入から今までに取り組んだこと、今後の取り組みについてご紹介させていただきます 初めにやったこと 初期に取り組んだことは2点で、正確な現状把握と目標設定です 運用中のリポジトリに計測を導入したため、放置されたPRなどが残っており、開発状況に関係なく数値が上下することがありました そのため、対象リポジトリの放置PRなどを全て棚卸しし、どうしても制御できないPR(自動生成されるものや隣接チームの依存が大きいもの)に関してはタグを設定し除外することでようやく現状が把握できる状態となりました 目標設定に関
不確実性や心理的安全性に向き合い自己組織化するチームを作る実践プラクティス
こんにちは。Gaudiyでソフトウェアエンジニア兼スクラムマスターをしている Namiki ( @ruwatana ) です。 「チームが向き合う不確実性が大きいと手戻りが増えて価値提供のリードタイムが遅くなる」 「チーム内の心理的安全性の低さや認知負荷の高さによってエンゲージメントが低下して従業員がオンボード・定着しにくい」 ... などなど、昨今のチーム開発はこうした課題で溢れかえっていることかと思います。 結局のところ、我々は具体的にどんなプラクティスを行うことで、こうした課題を解決できていくのでしょうか？ 本稿では、筆者と筆者が4ヶ月ほど前に配属することになったチームがこうした問題に対して執ったアプローチおよびその効果をより具体的に示すことができればと考えています。 プロダクトチーム開発を行う皆様に何かしらの参考になれば幸いです。 1. チーム構成と特性 2. 特性が生み出しうるリ
「システム運用アンチパターン」を一読したので、その要点（特に薦めたい感想5点） - Qiita
システム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション | Jeffery D. Smith, 田中 裕一 |本 | 通販 | Amazon エンジニアがDevOpsで解決する組織・自動化・コミュニケーション。早速お薦めしたく書いています。読書感想文です。 感想5点 良いぞ。周りに薦めたい 百聞一見。目次だけでも: https://www.oreilly.co.jp/books/9784873119847/#toc 特に自分にとって良かったのは以下 9章 せっかくのインシデントを無駄にする 10章 情報のため込み：ブレントだけが知っている だが、一番スゴイのは11章かもしれない 「文化を変えようと思うのであれば、文化がどのように共有されているかを理解すること」 コロナ以前は 議事録 会議 机横での雑談 飲み会 タバコなどなどあったが コロナ以降、リ
CIで Androidアプリのライブラリ更新を楽にする - pixiv inside
こんにちは。ピクシブ株式会社でpixiv Androidアプリの開発を担当しているverno3632です。 今回は弊チームで導入しているライブラリ更新の仕組みについてお話します。 ライブラリ更新の流れ まずpixiv Androidアプリの開発で利用しているツールを紹介します。基本的にGitHub上で開発を行い、CIにはBitrise、コミュニケーションツールにはSlackを利用しています。 GitHubへの更新をフックにしてBitriseでCIが走り、結果がSlackに投稿されるようになっています。 ライブラリ更新の流れはおおまかに以下のようになっています。 PR作成 影響調査 マージ PR作成 アプリ開発にはライブラリの更新作業がつきものですが、以前までは温もりのある手作業で運用されていました。 ライブラリの更新があるかの差分を出す Gradle Versions Plugin を週1
「技術的負債」への処方箋と「２つのDX」 - Qiita
はじめに 本稿は、日経クロステックにて筆者が昨年連載していた3回分の記事一部変更して1つにまとめたものです。 https://xtech.nikkei.com/atcl/nxt/column/18/01394/ 有料記事として配信されておりますが、無料でも閲覧できるようにということで日経クロステック様に許可を得てQiitaにも掲載しています。 第1回：技術的負債はなぜ生じるか。 第2回：ソフトウエア開発を「制御」する意外な処方箋 第3回：技術的負債への取り組みはなぜ「２つのDX」につながるのか。 第1回：技術的負債はなぜ生じるか。 年間12兆円ものマイナスの影響をもたらす技術的負債（あるいはレガシーシステム）はどのように生まれるのでしょうか。それを防ぐ方法はあるのでしょうか。第1回は、技術的負債をとりまく歴史をたどりながら、ソフトウェアエンジニアではない人にも理解できるようにその正体に迫り
チームに浸透させるのが近年では難しくなっている - id:onk のはてなブログ
昨日「動いたけどチームメンバーを説得するのが面倒で、秘蔵のブランチになってしまう」って言ったけど、この気持ちはどこから出てくるのか。 分かりやすい Cons があると、反発が予想できて、その反発を解決するところまで労力を割くほどの気持ちが無いので困る。「直ちに問題になるわけじゃないが、どちらかというとやった方がいい、でもリスクもある」という選択肢を選べずにズルズルと現状維持に向かう圧力は、ある。チームの同質性が高いうちはほとんど困らないんだが、人数が増えたり、別の職種が増えたりするごとに「面倒」さはどうしても増していく。 我々の信念として以下を持ってはいるが、現状維持に向かう圧力がある中で変化を加えるのはそこそこ労力が要り、閾値を超えると変化が発生しなくなってしまう。 業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。 素早く変えてもし仮にダメだったら素早く
Software Design連載 2021年9月号 「テストが無い」からの脱却 - MonotaRO Tech Blog
こんにちは、鈴木です。 「テストが無い」状態を脱却しました。 「いつの時代かよ！」と突っ込まれるかもしれませんが、モノタロウは創業から 20 年ほど EC をやっています。昨日書いたコードも、15 年前に書いたコードも、元気にビジネスを支えています。 本記事ではモノタロウの EC を支える API の話をします。「テストが無い」状態がスタートラインでした。そこから、CI を導入して、ローカル開発環境の整備して、テストコードを書いて、リリースマネジメントを導入しました。 目新しいことは書きません。長寿の大規模システムであっても、愚直に数年取り組むことで、「前進できる！」「変えられる！」という実例を書きます。 ※本記事の初出は、 Software Design2021年9月号「Pythonモダン化計画（第2回）」になります。第1回の記事は「Software Design連載 2021年8月号
既存の機能から設計を学び、調査力を向上させて、知見を共有しよう - Hatena Developer Blog
はてなブックマークチームの id:itchyny です。 チームのメンバー間で知見を共有することは、とても大事なことです。 特に開発エンジニア同士のコミュニケーションを増やし、お互いに足りていない知見を共有し合うことでチームの生産性を向上することは、プロダクトの成長につながります。 プロダクトの実装や設計の知見を共有するためによく取られる方法として、詳しい人が講義形式で教えるというスタイルがあります。 特に、チームに新しいメンバーが入ったときには、プロダクトの概要やコードのアーキテクチャについて説明することは一般的に行われています。 講義形式で教えるというスタイルはよく行われる方法でありながら、いくつかの課題があると感じています。 まずは説明会に参加するメンバーが、どうしても受け身になってしまいます。 説明された瞬間は分かったような気になっていても、次の週には忘れてしまうことはよくあること
すべての社会人に知ってほしい仕事の基礎としてのアジャイル/スクラムの話 / Agile as a work foundation
アジャイルやスクラムについて学び始め、実際に取り組むと、その原則や考え方がソフトウェア開発の領域に閉じないことを日々実感します。原則を日々の仕事・生活に活かすことは重要ですが、「アジャイル」という言葉は抽象度が高く、開発のイメージも強いため、一般化してエッセンスを伝えるのに苦労している方も多いのではないでしょうか。 スクラムマスターとして、開発に限らず組織の全員が、アジャイル/スクラムの原則を理解して、実践できるよう支援することは重要な活動です。サイボウズでは、数年前から新卒の全社員（＋希望者は誰でも）向けの基礎研修としてアジャイル/スクラムの話をインプットしています。 こちらのセッションでは、サイボウズ社内で実施している研修（講義）を社外向けに再編成したものをお届けします。アジャイルやスクラムの考え方をベースに、エンジニアに限らず、チームワークを高め、成果を届ける仕事の進め方の基礎となる
「DevOps」を全く知らない人のために「DevOps」の魅力を伝えるための「DevOps」入門 - Qiita
2018年現在において、「DevOps」という言葉を耳にしたことがない人は少ないかもしれませんが、本稿では以前に書き記したメモをベースとして「DevOps」の概要を紹介したいと思います。 「DevOps」とは 「DevOpsがあるとき、DevOpsがないとき」にみるDevOps導入のメリット DevOpsを実現するためには 「DevOps」とは 「DevOps（デブオプス）」とは、 開発手法やツールを使って 開発者（Development）と運用者（Operations）が密接に連携することで、 より柔軟かつスピーディーに システムを開発することです。 DevOpsが登場したのは2009年 「DevOps」という言葉は2009年に行われたFlickrのエンジニアによるセッション、「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」
「言った方が早い」は早くない｜石倉秀明
こんばんは。リモートワークを当たり前にしたい、石倉です。 いきなり本題ですが、仕事においてみなさん自身やみなさんの周囲で「言った方が早い」「直接話した方が早い」と思っている方はいますか？ 何を隠そう、僕もずっとそう思ってました。 もちろん議事録は大事なのはわかっているし、ドキュメントに残す、ツールに履歴を残す、タスクを見える化する、、、大事なのはわかっています。でも、ぶっちゃけめんどくさい。。 そして思ってました「言った方が早い」「直接話した方が早い」と。 ここ5年はずっとリモートワークで働いていますが、確かになかなかテキストで表現したり図で示せないことも多く、口頭でのコミュニケーションを行なった方が理解できることもあるし、早い場面はたくさんあります。 でもこれって本当に「早い」んでしょうか？ 確かにAさんと2人で話しているだけであれば直接話した方が早い、言った方が早いこともたくさんありま
アジャイルな開発とチームづくり - Mitsuyuki.Shiiba
社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて
老舗ITサービスのモダナイズに取り組みはじめたLINEエンジニアたちの挑戦！ 出前館の改善について和田卓人さんが聞いた - はてなニュース
新型コロナウイルスの影響下で、食の宅配などO2O（Online to Offline）サービスが好調です。なかでも有名漫才師を起用したテレビCMも話題となった出前館は、2020年8月期の連結決算で利用者数が前期比で31％増、売上高も前期比で54.6％増となりました（ただし広告展開やシステム投資などの先行投資により営業利益は赤字となっています）。 この背景に、株式会社出前館とLINE株式会社が2020年3月に締結した資本業務提携があります。LINEが出前館の経営に参画し、広告だけでなくサービスの提携も進んでいます。2020年11月には「出前館」アプリがLINEアカウントと連携し、出前館のOEMだったLINEデリマは12月にサービス統合されました。 ただしLINEでは、出前館を「LINE」アプリの関連サービスではなく、独立したO2O事業として継続的に成長させたい。そのためLINEのエンジニアを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発生産性の現在地点～エンジニアリングが及ぼす多角的視点 / Current status of development productivity
【IMO】コードレビューって難しいよね.pdf
