進捗確認をやめると上手くいく｜きゅーい / koyo
プロジェクトマネジメントといえば「進捗確認」と思っている人も沢山いると思いますが、私は進捗確認という行為そのものに否定的です。 このエントリでは、進捗確認という行為がいかに無意味であるかという話および、進捗管理として行うべきことを書いていきます。 誰かのプロジェクトマネジメントの参考になればと思います。 ※ 進捗管理が不要という話ではありません 進捗確認の定義このエントリでの進捗確認は下記の定義とします。 複数人が関わるプロジェクト等において、プロジェクト等をマネジメントするべき立場にある人間が、プロジェクトの所属メンバーに対してタスクの進捗状況を口頭・テキスト等で直接確認する行為 少し難しい言葉で書きましたが「進捗どう？」といった質問およびその回答からなる一連の流れだと思ってください。 なぜ進捗を確認したくなるのかプロジェクトマネージャー（PM）の仕事のひとつに納期の管理というものがあり
はじめに 仕事に追われる日々から解放され快適に楽しく働くことができる環境を実現するためには、自己管理が重要です。ここでいう「仕事に追われず快適に楽しく働ける状態」とは、自分自身で意思決定を行い、仕事の進行を自らコントロールする能力を身につけることを意味します。 多くのエンジニアは仕事の量や複雑さに圧倒され、自分のペースで仕事を進めることができないという状況に直面しています。しかし、自己管理スキルを身につけることでこれらの課題を乗り越え、より自分起点な働き方が可能になります。 この記事では、よく起きがちな問題とあわせて自己管理を強化するための具体的な方法を示します。 1. 他の人から見て何をやっているかわからない問題 主要なポイント 「あれってどうなってます？」って聞かれていませんか？ これを頻繁に聞かれる場合、確実に何やっているかわからない人だと思われています タスクの状態は、必ず聞かれる
会社の振り返りで「エンジニアリングの作業タスクがうまく分割できていそうだったが、その知見を共有してほしい」と言われたので、自分がどう考えてタスク分割をしているかをこの記事で共有したい。 この記事のスコープとすること・しないこと タスク分割をするときの工夫点 少なくとも1スプリント以内で終わるタスクになっている 完了条件が明確である 開始から終了まで他タスクによる待ち時間がない 他タスクが待ち状態になる時間を最小限にする 自分にとって難易度の高いものが1タスクの中で1つである 初めから完璧なタスク分割を目指さない 工夫を考慮した分割例 まとめ この記事のスコープとすること・しないこと 今回の記事では、あるユーザーストーリーが存在するとして、その設計・実装・テストなどをスムーズに進行するための工夫について書く。 逆に次のようなタスク分割については取り扱わない。 ユーザーに提供すべき価値があると
Create React Appは役割を終えました
長らくReactの入門キットとして使われてきたCreact React App（CRA） 2023年春に正式版になった新しいReactの公式ドキュメントでは、選択肢として紹介されていません。 標準から外れたとは言え、まだ一定の役割は担えるのだろうかと思い様子を見てみました。 とりあえず試してみる まずは現状確認のために実際にプロジェクトを作ってみます。 $ npx create-react-app cra --template typescript Creating a new React app in /Users/nekoya/src/github.com/nekoya/ggg/cra. Installing packages. This might take a couple of minutes. Installing react, react-dom, and react-scr
この記事は クラウドワークス Advent Calendar 2023 シリーズ1 の 4日目の記事です。 はじめに 「父さんな、Terraform職人やめてお豆腐職人で食っていこうと思うんだ」と言いたいだけの @minamijoyo です。 2023年8月HashiCorpはこれまでMPL2のOSSライセンスで公開していた主要製品をBSL(Business Source License)に変更することを発表し、Terraformはv1.6.0からOSSではなくなりました。 このライセンス変更を受けて、OSS版のTerraformを求める人たちで、MPL2時点のコードベースからforkしたOpenTofuの開発が進められています。 HashiCorpのBSLは、実質的に競合他社の商用利用に制限をかけたもので、ほとんどの一般的なユーザに直接的な追加の制限はありませんが、間接的にTerrafo
事前知識編 システム開発するプログラマも読んでおいたほうがいい資料とか。 今時のシステムならまず仕様や運用に反映される。されてなかったらむしろこっちから確認取りに行った方がいい。 JOGAガイドライン 昔ガチャとかが問題になったときに出てきた協会のガイドライン。 オンラインゲーム安心安全宣言 オンラインゲームにおけるビジネスモデルの企画設計および運用ガイドライン ランダム型アイテム提供方式を利用したアイテム販売における表示および運営ガイドライン オンラインゲームガイドライン 開発環境編 GitHubみたいなPullRequestを出せる環境 GitだけじゃなくてGitHub。必然的に規模が大きくなるのでプルリク出して進めることになります。 CIまで設定をする 最初のうちにCircleCIのようなテストの自動実行する仕組みまで揃えてしまっておいたほうが良いです。後からだとそもそも対応できなく
[2024年4月25日 追記] Safariの動作について考慮漏れがありましたので、一部追記・編集しました。 新宿にオフィスのあるClassiは、岡山在住の私のような地方在住者だけでなく、いわゆる通勤圏内に在住していてもリモートワークで働いている人が多い会社です。必然的にミーティングはいわゆるオンラインミーティングとなり、主にGoogle Meetが利用されています。 そのGoogle Meetのチャット機能、ここ1週間ぐらい「IMEで日本語に変換のために押すエンターキーで送信されてしまう」という現象が発生しています。このエントリーを読まれている時点では対応しているかも知れませんが、2024年4月22日17時時点ではその現象は続いています（Windowsでは再現しないという情報もあります）。 入力開始 変換して確定のエンターキーを押すと 送信される エンターキーに頼らない日本語入力を頑張り
![IME変換中のエンターキーで送信される！への対処法[追記あり] - Classi開発者ブログ](https://cdn-ak-scissors.b.st-hatena.com/image/square/0afc6ee0863caae4e576ca7dfc69f2761a288290/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F26006613504214060%2F6801883189100834220%2F1714006878)
コードレビューの思想や心構え - Qiita
株式会社ブレインパッドでデータサイエンティストをしているasanoです。 この記事はBrainPad Advent Calender 2023 1日目の記事シリーズ2です。 ※シリーズ1は@fuyu_quantさんの入力プロンプトを復元する技術 #ChatGPTです！ 今日はコードレビューの思想や心構えについて書きます。 はじめに コードレビューをより生産的に進めるには単にコーディングのスキルだけでなく、そもそものコードレビューに対する思想や心構えについても一定のリテラシーを求められると考えています。 コードレビューはどうしてもロジカルな話になるため伝え方にも気を付けないとモチベーションの低下に繋がりやすいと考えています。 そうなると当然パフォーマンスも下がってしまいます。 これを防ぐために自分は「コードレビューの思想・心構え」をまとめてチームのガイドラインとして使っています。 あくまで主
あれこれ 備忘録的な書き殴りな文書です。あしからず。 オシャンティーな技術スタックで、大きな組織でやるのも面白いと思うけど、小さな会社でレガシーなシステムやメンバーと向き合うのも悪く無いよ！ってことを伝えたいのだけど、これが楽しめる人いるかな？私は楽しいよ！ ジョインした時点の状況 開発体制 開発エンジニア（入社半年） インフラエンジニア（５年前後、QA兼ねる） 主力サービスの協力会社 0.5人月程度 会社の屋台骨の 主力事業のSaaSサービスがあるが、業務委託の0.5人月程度の工数の範囲でできる改修を行っていた。 開発エンジニアは新規機能を開発していた。 課題感 一度作られたシステムは、表(UI/UX)も、裏(システム)もレガシーな状況であった。 限られたエンジニアのリソースは、営業視点で、あったら売りやすい機能開発に費やされており、負債返却や、使い心地の改善には充てられていなかった。
本記事は 【プルリクウィーク】 4日目の記事です。 💻 3日目 ▶▶ 本記事 ▶▶ 5日目 📚 こんにちは越川です。 GitHubはアプリケーションの開発に携わる人がメインで使う、という印象が強かったのですが現在、クラウドエンジニアの私もほぼ毎日GitHubを触っています。 私の場合、業務上、IaCを使うのでプログラミングをする機会が多く、その分プルリクエスト（以降PR）を見ることも出すことも多くあります。今回は自分自身がPRを見る時、または出す時にどんなことを意識しているのかを書いてみようと思います。 ※PRとは新規開発や改修などの内容を関係者に通知する仕組みです。このPRをトリガーに関係者はコードのレビューを実施し、問題なければマージを行います。 ※IaCとはInfrastructure as Codeの略称で、サーバーやネットワークなどあらゆるインフラリソースをコード化し、構築を
本記事は 【プルリクウィーク】 2日目の記事です。 💻 1日目 ▶▶ 本記事 ▶▶ 3日目 📚 はじめに Git と インフラ屋 と IaC そもそもインフラ屋が管理するコードとは？ IaC インフラ関連の設定ファイル CI/CD周りの設定ファイル PRレビューで難しいと思うこと 何を持ってOKとするか そもそも検証が難しい 網羅性が判断つかない PRレビューで意識していること 静的チェックの導入 コメントには意向を示す略語を付ける コメントがFixすればリアクションしてクローズする 対面レビューの時間を設ける リリースとの親和性が高い さいごに はじめに こんにちは、加藤です。 普段、私はインフラエンジニア（以下インフラ屋）としてシステム運用に携わっています。 最近はIaCの普及もあり、インフラチームでもプルリクエスト(以下PR)レビューを実施しているチームが多いのではないでしょうか
はじめに 「自身のコードを振り返り、実装内容を言語化する習慣はありますか？」 「開発をするとき、動いたからOKと思い、急いでPRを出していませんか？」 また、「コードを書いて要件を満たしているからと、そのまま先輩エンジニアに丸投げレビューを依頼してませんか？」 それは、チーム内の開発コミュニュケーションとして良くないよーーーー 個人開発や、なんちゃってチーム開発（ハッカソン）しかしてきていない私は、セルフレビューの存在や大切さを全く知りませんでした。🥹 この記事では、Draft Pull Requestと、セルフレビューはどういうものかやその大切さを教えます！！！ 以下では、Pull RequestをPRと省略します。 対象読者 長期インターン前に急いでGitHubの復習をしているエンジニア チームに入る前や入りたての駆け出しエンジニア セルフレビューが苦手な若手エンジニア まずは自分の
仕事をしていると PR のレビュー依頼に一瞬で気づきたいので、メールや slack 連携などの通知を設定することになると思う。ただ、それだけだと一瞬で気づいたけど今は手が離せないので10分後くらいに見よう...と思ったまま忘れてしまうということが起こるのでなんらかの工夫が必要で、自分はメニューバーに関係する PR 一覧を表示している。 具体的には、以下のように、 自分がレビューするべき PR の数 自分が出していてマージされていない PR の数 をメニューバーに常に表示し、それをクリックすると PR へのリンクのリストが登場するようになっている（仕事の様子を公開するわけにはいかないのでダミーデータにしています）。 リストは３つのセクションに分けていて、 自分がレビューするべき PR すべて 自分が出してマージされていない PR すべて 自分が出してマージされた PR 直近３件 をそれぞれ表
こんにちは！エンジニアリングマネージャの 吉成 です。 この記事は SmartHR Advent Calendar 2023 4日目の記事なのですが、実は ANDPAD さんの Advent Calendar 2023 1日目 とまさかのネタ被りです。 この日のために 後回しにしていた 寝かせていたネタだったので、二番煎じとなりますがこのまま出させていただくことにしました 😌 背景 さて、弊社では今年の5月から、各プロダクトチームが週ごとに持ち回りでテックブログを執筆する取り組みを開始しました。 元々は執筆のためのフローは特に整備しておらず、公開までの壁打ちやレビューといったものは有志の方にすべておまかせしておりました。 今年の8月に DevRel の1人目として inao san が入社され 1、テックブログの担当チームやレビューなど諸々の業務を引き継いでいる中で、組織でのはてなブログ
あるファイルが最近どの程度の頻度で更新されたのか、マージコミット単位(≒PullRequest単位)で調べたいことがあった。git logのコマンドを使ったら簡単に調べられたのでメモ。 たとえば1年以内に https://github.com/x-motemen/ghq のレポジトリで .github/ 以下に変更を加えたマージコミットを取得したい場合はこんな感じ。 $ git log --merges -m --first-parent --pretty=format:"%cd - %an: %s(%H)" --since="1 year ago" .github/ Sun Apr 16 23:27:26 2023 +0900 - Masayuki Matsuki: Merge pull request #359 from x-motemen/coverage(e7f736f22376d
2023年4月までの私の資格はAWS Certified Solutions Architect - Associate (SAA 2022年4月取得)のみでした。 ただ、これだけでは弱いと感じX (旧Twitter)やYoutubeなどから情報収集し、どうしたら実務未経験でも企業にアピールできるか？を考え、インフラの分野はポートフォリオよりも資格を評価する企業が多いことを聞き、まずは見た目でもわかりやすい資格でアピールする方針としました。 LinuCについて AWSを学習する上で必須となる知識としてサーバの知識は必須になってきます。 Linuxの基本的なコマンドは一通り触れます、とアピールできるようにLinuC Lv1を取得して網羅的にLinuxを学ぶことにしました。 学習コンテンツ Ping-t Linux教科書 LinuC レベル1 スピードマスター問題集 Version10.0対応
はじめに こんにちは、クラスター株式会社でソフトウェアエンジニアをやっているid:shiba_yu36です。 クラスターではGoの自動テストをCircleCIで実行しています。入社して以降、この自動テストの実行時間が少し長いと感じたため、調査と改善を進めてきました。結果として速度を改善できたので、この記事でGoの自動テスト高速化のための調査と改善手法について共有したいと思います。 はじめに Goの自動テストで課題だったこと 最終的な結果 自動テスト高速化の流れ テスト実行時間のボトルネックを調査する CircleCIのTIMINGタブで大まかなボトルネックを調査する make testのボトルネックを調査する 高速化でやるべきことを決定する 1つずつ改善し結果を計測する go generateの成果物をレポジトリにcommitし自動テスト上では実行しない: 2分短縮 ビルドキャッシュを用い
マネーフォワード MEのモバイル開発の生産性を爆上げした事ランキング - Money Forward Developers Blog
マネーフォワード ME（以降ME）のモバイルエンジニアの椎名です 今回、MEのモバイル開発のコストを大きく削減し、生産性を向上させた話をします どれくらいかというと、体感値ですが少なく見積もって 1/5くらい にはなったかな、とは思います(2018年頃と比較) この事は何か1つの取り組みによって達成されたのではなく、いくつもの取り組みによって数年かけて達成されました ここでは数々の取り組みの中から、"これは効果があった!"というものを独断と偏見でランキング形式にして紹介します 少しでも皆様のサービスに役立てていただければ幸いです 1位 リファクタリング 1位がありきたりな事で恐縮ですが、今のMEのモバイル開発を支えているのは間違いなく過去に行った大規模なリファクタリングです 2018年頃iOS版MEは、複雑化したアーキテクチャとコードに悩まされていて 当時、行き詰まりを打開するためにフルリ
パイプとGitHub CLIでIssueもPullRequestsもこれ一本！ISUCONハック後編 - CARTA TECH BLOG
「MakeとGitHub CLIで初回Pushまでを最速に。ISUCONハック前編」の続きです。 techblog.cartaholdings.co.jp 前編では、初回Pushまでの流れを説明してきました。 後編では一歩進んで、Issue管理やその他Tipsについて紹介していきます。 この記事を読むと学べること Shellのパイプを使って、CLIからGitHub Issueにコメント PRマージ後のmainを手元で動かす方法 競技中のログをGitHub CLIで楽する さて、ここまでで初動のPushをGitHub CLIで行う方法を紹介しました。 次はGitHub CLIで楽に競技中のログをIssue追記する方法を紹介します。 ISUCONの競技中、ログを取ることは非常に重要です。 またそのログをチームと上手く共有し、次なる一手を考える必要があります、 その際にGitHubのIssueが
こんにちは。エンジニアのすずまさです。 去年の夏頃にリードタイムの計測を始めてから、振り返りで良い気づきを得られるようになったりリードタイムを減らすアクションが生まれたりと良いことがたくさんあったので、今回はその紹介をしようと思います。 リードタイムの定義 『LeanとDevOpsの科学』では、リードタイムを「コードのコミットから本番稼働までの所要時間」として定義しています。 私たちのチームのリポジトリではブランチ戦略としてGitHub Flowを採用しており、mainへのマージと本番稼働のタイミングが近しいため「PRをopenしてからマージするまでの期間」をリードタイムとして定めて計測しました。 リードタイム計測を始めた動機 私たちのチームでは「チームのスピードがあまり出ていない気がする」という漠然とした課題感がありました。しかし、課題感はありつつも、ではどうするかと言われると具体的なア
Dependabot alertをSlackに通知して、トリアージ運用に役立てる仕組みを作ってみた - freee Developers Hub
こんにちは、PSIRTのWaTTsonです。 去年の12月にAdvent CalendartでAWS SecurityHubの結果をSIEM on Amazon OpenSearch Serviceに取り込んだ話を書きました： developers.freee.co.jp 今回は、同じくSIEM on OpenSearchを使った話で、GitHubのDependabotの運用に関することを書きたいと思います。 Dependabotの運用上の課題点 Dependabotはプロジェクトで使われているライブラリの依存関係をチェックし、古いものやセキュリティ上の問題があるものをアラートするサービスです。元々は独立したサービスでしたが、2019年にGitHubに買収されて、今はGitHubの公式機能として提供されています。 freeeでは、依存ライブラリの脆弱性管理に長らくyamoryを使っていまし
GitHubのEventAPIとChatGPTを使って「この人最近何しているの?」が分かるコマンドを作った - notebook
ChatGPTを使って何か作ってみようということで掲題のコマンドを作ってみた swfz/what_recent github.com こんな感じの結果が返ってくる $ what_recent swfz 28件のサマリー対象Activityがありました 26件の未対応Activityがありました 46件のbotによるActivityがありました assistant: 最近の活動を見ると、swfz氏はNode.jsやDenoに興味があることがわかります。また、GitHub APIやその他のツールを使って自動化やデータの取得を行っていることから開発効率化にも関心があると考え られます。 具体的には、`swfz/sandbox`リポジトリでslackの投稿を取得したりマージする機能を開発したりしています。この取り組みの難易度は中程度と見られます。 また、`swfz/swfz`と`swfz/tool
tfupdateで複数の.terraform.lock.hclを高速に一括更新する - クラウドワークス エンジニアブログ
はじめに Terraform職人の@minamijoyoです。先日、tfupdateが.terraform.lock.hclの更新に対応しました。v0.7.0から tfupdate lock というコマンドが追加されています。 github.com 例えば、あるディレクトリ配下のすべてのAWSプロバイダを指定バージョンに更新しつつ、複数プラットフォーム混在で使う.terraform.lock.hclもまとめて一括更新するには、以下のようなコマンドで簡単にできるようになりました。 $ tfupdate provider aws -v 5.7.0 -r ./ $ tfupdate lock --platform=linux_amd64 \ --platform=darwin_amd64 \ --platform=darwin_arm64 \ -r ./ 内部的にterraformコマンドには依
どうもみゅーとんです. 最近パフォーマンス周りで問題をおこしかけてしまったので, パフォーマンスの劣化を抑制する方法を調べてみました. 概要 3 行でまとめ public repository であれば, CodSpeed を無料で利用できる main ブランチでのパフォーマンスを計測しておき, Pull Request で劣化したら警告してくれる CodSpeed から, 内部処理を詳細に追うことができる 前提知識 vitest でパフォーマンステストを行う構成ができていることが条件になります. 導入方法についてはこの記事を確認してください. techblog.hacomono.jp CodSpeed とは docs.codspeed.io なんて読むんでしょうか・・？私はコードスピードと呼んでいますが, コッドスピードのほうが正しそう・・？ GitHub Actions で実行した P
ai-pr-reviewer(旧openai-pr-reviewer) でAIにレビューを手伝ってもらう - 機能を試してみた
前回のあらすじ 前回の記事はこちら GitHubでChatGPTがPullRequestをレビューしてくれるopenai-pr-reviewerを動かしました。 本記事では前回の記事にて紹介しきれなかった各機能を紹介します。 各機能紹介 修正行ごとの変更提案 変更提案はsuggestion形式なのですぐにコミットとして取り込めます。 使用するChatGPTのModelを選択可能 ワークフローファイルに記載することで変更可能です。 要約用のopenai_light_modelとレビュー用のopenai_heavy_modelをそれぞれ指定できます。 jobs: review: runs-on: ubuntu-latest steps: - uses: fluxninja/openai-pr-reviewer@latest env: GITHUB_TOKEN: ${{ secrets.GITH
前提として Pull Requestの運用方法など、各プロジェクトによって方針が定められているところもあるかと思います。 その上、この記事ではあくまで筆者の考えを殴り書きしているだけのものですので、基本的にはプロジェクトの方針に沿った運用を行い、この記事は参考程度にしていただくのが良いかと思います。 概要 昨今の開発では、GitHubを利用される方が大半だと思われます。 その中でも、ほとんどの人が利用している機能として「Pull Request」が挙げられます。 Pull Requestは「実装者が実装した機能・コードの品質をレビュワーがチェックする工程」であり、「実装者とレビュワーのコミュニケーションを取る場」となります。 Pull Requestも万能ではなく、そもそもレビューも実装も人間が行う（2023年時点だとまだ人間がやってる）ので、確認漏れや認識のずれが発生してしまうこともチラ
こんにちは！ぬこすけです！ 個人開発をしていると「データベースはどこで立てようか...」というのは悩みの種です。 「無料でデータベース使いたい」「あんまりデータベースの構築に時間をかけたくない」などアレコレ考えてしまいます。 そんなあなたに、無料かつ楽にRDBを作れる「PlanetScale」をお勧めしたい！と言いたいところですが、 なんと2024年4月8日に無料枠が廃止されてしまいます 。 かくいう私も技術書をランキング形式で紹介するサイトを昔作っていたのですが、データベースはPlanetScaleを使っていたため打撃をくらってしまいました...。 このような事態を受け、私のサイトではPlanetScaleの代替として Neon というサーバーレスなデータベースを提供しているサービスに乗り換えてみました。 みなさんの参考になるように、PlanetScaleと比較しながら体験談を共有できれ
name: Code Review permissions: contents: read pull-requests: write on: pull_request: pull_request_review_comment: types: [created] concurrency: group: ${{ github.repository }}-${{ github.event.number || github.head_ref || github.sha }}-${{ github.workflow }}-${{ github.event_name == 'pull_request_review_comment' && 'pr_comment' || 'pr' }} cancel-in-progress: ${{ github.event_name != 'pull_request_
State of CSS 2023 の結果公開など : Cybozu Frontend Weekly (2023-08-29号)
State of CSS 2023 の結果公開など : Cybozu Frontend Weekly (2023-08-29号) こんにちは！サイボウズ株式会社 フロントエンドエキスパートチームの @mugi_uno です。 はじめに サイボウズ社内では毎週火曜日に Frontend Weekly と題し「一週間の間にあったフロントエンドニュースを共有する会」を開催しています。 今回は、2023/08/29 の Frontend Weekly で取り上げた記事や話題を紹介します。 取り上げた記事・話題 <search> が Chrome118 で実装予定 検索や絞り込み要素に関するコンテナ要素である <search> が Chrome 118 で実装予定とのことです。Firefox や Safari にはすでに実装済みのため、メジャーブラウザの多くで利用可能になります。 Fresh 1.4
こんにちは。 FindyでTech Leadをやらせてもらってる戸田です。 昨年(2023年)、Findy Team+ にて、4名で3ヶ月ほどかけて大規模なフロントエンドの設計刷新を行いました。 Findy Team+はエンジニア組織のパフォーマンス向上を支援するSaaSサービスで、2020年から開発がスタートしました。 3年以上の間、機能開発を行ってサービスを伸ばしてきましたが、同時に様々な課題も生じていました。 今回はそこに至るまでの経緯と、実際に行ったことを紹介します。 なぜフロントエンドの設計刷新を決断したのか 当時、自分は他のプロダクトの開発チームでコードを書いていたのですが、ある日Findy Team+の開発チームへ異動することになりました。 異動後に2週間ほどFindy Team+のフロントエンドの開発をしたのですが、あることに気づきます。 コード設計が思ったより複雑かもしれ
コードレビューで個人的に意識していること
こんにちは。 PharmaX でエンジニアをしている諸岡（@hakoten）です。 この記事の概要 この記事では、私が普段コードレビューで意識していることを紹介しています。 コードレビューのルールというより、個人としてのルーティンや意識していることについて書いています。 ※ チーム自体の「レビュールール」は別で存在していますので、ルールに沿った上でのルーティーンや心構えという認識で読んでいただければと思います！ レビュールールの運用やルール自体については触れていませんので、ご了承ください。 自身のキャリア どのような経歴のエンジニアからの話なのかを知っていただくと、内容を想像しやすいかと思いますので、私のエンジニアとしての経歴を簡単に紹介します。 ソフトウェアエンジニア 14年 主な領域、モバイル、ウェブ、APIサーバーなどのアプリケーションメインのエンジニア 機能リード、テックリードあた
はじめに タスクに取り掛かる前に、タスクの細分化はできていますか？ タスクの工数見積もりをし、スケジューリングしていますか？ また、細分化したタスクを、どのように取り組んでいますか？ 私は、タスクの細分化やタスクの工数見積もりができておらず、タスクの期限をすぎてしまい、チームに迷惑をかけた経験があります。 （期限ギリギリになって「間に合いそうにないです」と報告することがありました。😞） そこで、振り返りをし、タスクの工数見積もり方法や細分化について考え直したので、記事にしようと思いました。🙆 この記事では、タスクの細分化と工数見積もりについて教えます! 以下では、Pull RequestをPRと省略します。 対象読者 細分化や工数見積もりを知らないエンジニア タスク細分化が苦手な駆け出しエンジニア タスクを期限内にこなせず上司を困らせた経験がある駆け出しエンジニア まずは自分の体験から
こんにちは、クラシルリワードのSRE担当のjoooee0000です。 私はクラシルリワードのサービスローンチの約3ヶ月後にサーバー兼インフラエンジニアとしてjoinし、サービスの成長と共に、開発速度とシステムの信頼性の向上を目指してシステムの改善を行ってきました。 その中で、特に開発速度と信頼性向上に寄与したと思う3つの改善を紹介したいと思います。 改善を行う際に「コスト(金額、導入共に)と効果のバランス」「運用しやすいシンプルな設計」に特に気をつけたので、参考なると幸いです。 (話すこと: 取り組んだ施策の概要紹介、 話さないこと: 細かいhow to) やってよかったこと3選 ブランチ戦略の見直しとシンプルな検証環境の維持 ログの構造化とNewRelicログUIの導入 インシデント管理ツールの導入 それぞれ、改善前にどのような課題があったか、改善後のメリットなどを紹介していきます。 1
LS/LM がRuby 2.7 -> 3.2 にアップグレードするまでの軌跡 - Linkers Tech Blog
こんにちは、情報システム部の大河原です。 徐々に暑さが増してきて、夏本番が近づいているのを肌で感じます。先日、お気に入りの夏限定ドリンク1をコンビニで初めて見かけて、テンションが上がりました。 さて、遡って春先の話になりますが、Linkers Sourcing / Marketing（LS/LM）では3月にRubyバージョンのアップグレードを行いました。 これまで2.7.2だったのを3.2.1に上げたため、多数の非互換の変更を含む大幅なジャンプアップとなりました。 Ruby 2.7は3月末にサポート終了済み LS/LMは3月中にアップグレードを完了させたためなんとか間に合いましたが、Ruby 2.7系は今年の3月末にてEOLとなっているため、まだ運用しているシステムでは早急なアップグレードが必要です。 しかし、JetBrains社の調査によると、2022年5-7月時点では2.7を使っている
dbtCloudから作成したPullRequestにコンパイル済みSQLをコメントする仕組みを作成した話 - Timee Product Team Blog
こんにちは☀️ タイミーでアナリストとアナリティクスエンジニアしてますokodoonです 今回の記事はdbt CloudでPull Requestを作るときに、レビュー負荷が高くなってしまっていた問題を解消できるように、コンパイル済みのSQLをPR上にコメントするような仕組みを作成したことについての紹介です。 もし同じような課題感を抱えている方がいらっしゃれば、参考にしていただければ幸いです 課題感 今回選択した解決策 背景/前提 実装概要 各ステップの説明 PRの情報をもとにprofiles.ymlの動的生成 コンパイル処理の実施 PR上にコメント どんなふうに動くかみてみる 結果 We’re Hiring! 課題感 弊社のデータ基盤ではDWH層DataMart層は「分析用に加工されたデータを扱う層」として定義しています。 各種ドメインに依存した集計や変換のロジックが含まれるため、この層
この記事は食べログアドベントカレンダー2023の16日目の記事です🎅🎄 食べログシステム本部の品質管理室のSET(Software Engineer in Test)チームで自動テストの仕事をしている@shibu_shibuです。 私はSETチームの「仲良しリーダー」という謎の役割を担っており、みんなで仲良く働くために日々頑張っています。(仲良し至上主義ではないので仲良くないこともいいことだと思ってます) 今回はSETチームが仲良く働けるようになったきっかけであるモブワークについてお話しします。 はじめに エンジニアの皆さんは、オンボーディングの際や作業に詰まった時、問題解決が必要な時以外にも勉強のためにペアプログラミングやモブプログラミングをすることがあると思います。 同じようにSETチームでは、要件を固めたり方針を決めたりスケジュールをひいたり設計のために図を書いたりする際に、担当
Using Dhall To Manage GitHub Actions Workflows
In my previous post, I talked about how we use Github Actions to automate our workflows. As promised, I will show how we use Dhall to manage our GitHub Actions files. Don’t Repeat Yourself “Don’t Repeat Yourself” (DRY) is a programming principle that reduces repetition in code. As we created more actions in a growing number of repositories, we noticed that there were a lot of repeating steps, jobs
gotesplitにAdd -race to list when it is specified for test optionsというPullRequestを投げたのだが、この背景を書いておこうと思う。 まずGoでは-raceオプションについて、以下のような挙動を起こす。 -raceフラグをつけるとruntime/raceがおそらく一番依存の深いところに追加されてコンパイルされるっぽい？ https://github.com/golang/go/blob/go1.21.2/src/cmd/go/internal/load/pkg.go#L2573-L2576 あたり？ そのため、go testとgo test -raceはビルドキャッシュが全く異なる。つまりgo testのビルドキャッシュはgo test -raceのビルドに全く使われないし、その逆も同じである gotesplitの以前
ai-pr-reviewer(旧openai-pr-reviewer) を使ってAIにレビューを手伝ってもらう - とりあえず動かしてみた
openai-pr-reviewer とは？ GitHubでChatGPTがPullRequestをレビューしてくれます。 以下の機能が備わっています。次回の記事で機能単位で掘り下げて紹介したいと思います。 修正行ごとの変更提案 使用するChatGPTのModelを選択可能 ボットとのチャット レビューが不要な場合はスキップ可能 プロンプトはカスタマイズ可能 2023-07-31 追記 次の記事を公開しました。 設定 リポジトリへの設定 .github/workflowsにopenai-review.ymlを追加 name: OpenAI Reviewer permissions: contents: read pull-requests: write on: pull_request: pull_request_review_comment: types: [created] concu
この記事は、Merpay Tech Openness Month 2023 の11日目の記事です。 こんにちは。メルペイのデータマネージャー@katsukitです。 本日は、現在メルペイで取り組んでいる非エンジニアのためのデータ集計環境についてご紹介します。 はじめに データ活用には可視化、分析、調査、ML、CRMなど、さまざまな場面があると思います。エンジニアはもとよりデータアナリスト、マーケター、プロジェクトマネージャーなどと利用するユーザーもさまざまです。 これらの利用シーンで使用するデータにはお客さまのデータを取り扱うこともあり、データの管理をしっかりとやる必要があります。 一方で、お客さまへのアプローチまでスピード感が求められるマーケティングやCRM配信など、現場にデータ抽出・作成を委ねているデータ活用では、データガバナンスの維持が難しく、現場全体に統制されたデータ管理体制を構築
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
もう仕事に追われたくない！自分起点で楽しく働くための自己管理術 - Qiita
スムーズに進行するためのエンジニアリングタスク分割の工夫 - $shibayu36->blog;
Terraform職人のためのOpenTofu入門 - Qiita
ソシャゲサーバー開発するとき始めに考慮しておかないと死ぬポイント備忘録
IME変換中のエンターキーで送信される！への対処法[追記あり] - Classi開発者ブログ
開発責任者として、事業会社にジョインして半年の振り返り
プルリクエストを見る時、出す時に重要なマインドセット - NRIネットコムBlog
とあるインフラ屋のプルリクエストレビュー奮闘記 - NRIネットコムBlog
コードをセルフレビューしてる？〜いまから実務を始める君へ〜 - Qiita
Mac のメニューバーで PR の状況を把握する - maiyama4's blog
テックブログを GitHub で管理できるようにしました - SmartHR Tech Blog
特定ファイルを更新したマージコミットを探す - $shibayu36->blog;
実務未経験でAWS設計構築案件にアサインされるためにやってきたこと - Qiita
Goの自動テスト高速化のための調査と改善手法 - Cluster Tech Blog
リードタイムを測るシェルスクリプトを作ってチームの振り返り会を活発にした話 - Classi開発者ブログ
(小ネタ) Vitest でパフォーマンス劣化を検知する - hacomono TECH BLOG
みんなが幸せになれるPullRequestの作り方を考えてみた - Qiita
【個人開発】無料DBを求めてPlanetScaleからNeonに移行したら快適だった話 - Qiita
CodeRabbit openai-pr-reviewer を調整する
Findy Team+のフロントエンドの設計刷新 ~決断から効果検証まで~ - Findy Tech Blog
タスクの期限をすぎてしまった話 〜駆け出しエンジニアがタスクの細分化と見積もりを知る〜 - Qiita
小さいチームで実践する!開発速度・信頼性向上のためにやってよかったシステム改善3選 - dely Tech Blog
チームにモブワークを取り入れてみた話 - Tabelog Tech Blog
Goでは-race付きでテストするとビルドキャッシュが完全に別になる - $shibayu36->blog;
非エンジニアのためのデータ集計環境について | メルカリエンジニアリング