なぜ雑談が重要か - stmn tech blog
これはなに？ こんにちは、リファクタリング大好きなミノ駆動です。2023年7月より株式会社スタメンにジョインしました。 コミュニケーションには会議体やテキストベースなど様々な手段があります。 その中で雑談がなぜ重要であるかについて、私の考えを記したものです。 大事な前提 〜目的と手段の関係〜 人々の活動には目的があります。そして目的を満たすための手段を追い求めています（ここでいう手段とはシステムであったり情報であったり、「目的の役に立つもの」と考えてください）。 目的と手段の関係性を次の図で表現します。目的と手段それぞれの円の重なりが大きいほど、目的に対して相応しい手段である、ということをここでは表します。 この図を使った例を出します。 今の時期、だんだん暑くなってきましたね。「暑さを解消したい」という目的に対して、「扇風機を点ける」「エアコンを点ける」「かき氷を食べる」「南極に送り込む」
社内ドキュメントはなぜ更新されないのか？情報の鮮度を最小限の運用負荷で維持する「イミュータブルドキュメントモデル」のススメ - KAKEHASHI Tech Blog
はじめに こんにちは。カケハシの各プロダクトを支えるプラットフォームシステムの開発チームでテックリードを担当しているkosui(@kosui_me)です。 プロダクト開発の世界では、明瞭な社内向けドキュメントを書くための方法が数多く提案されてきました。読者の中には、製品要求を明瞭にするためにPRD (Product Requirements Document、製品要求仕様書) を書き、プロジェクトの背景から全体の設計やその代案について明瞭にするためにDesign Docsを書き、アーキテクチャに関する意思決定の記録を明瞭にするためにADR(Architecture Decision Record) を書いてきた方も数多くいらっしゃると思います。 しかし、どんな素晴らしいドキュメントも、何故か更新されなくなります。新メンバーへのオンボーディングのためにインフラ構成図を検索したあなたが見つけた
言葉の定義 モバファクの 1on1 の目的 1on1 で自分が大事にしていること 1on1 はメンティーの時間である 1on1 はメンターの時間でもある 1on1 初回 今使っている 1on1 のフォーマット 体調 半期目標の進捗振り返り ネクストアクションの振り返り うまくいかなかったこと・もっとよくなりそうなところ・うまくいったこと・その他に話したいこと ネクストアクション 1on1 の中でのやりとり お休みの取り方がわからない 最近見積もりの精度が高くなっている 朝会の議事録をとるようにしたい 最近チームの動きがぎこちないと感じている 1on1 定期的な振り返り まとめ こんにちは。駅メモエンジニアの id:dorapon2000 です。 今回は自分自身がメンター側として実施している 1on1 について、どのように実施しているのかご紹介しようと思います。 1on1 のやり方はメンター
はじめに こんにちは、CTO/DevRelブロックの堀江（@Horie1024）です。ZOZOではGitHub Copilotを全社へ導入しました。本投稿では、GitHub Copilotの導入に際して検討した課題とその課題の解決策としてどのようなアプローチを取ったのかを紹介します。 目次 はじめに 目次 GitHub Copilotとは何か？ GitHub Copilot導入の背景と目的 導入する上での課題 セキュリティ上の懸念 ライセンス侵害のリスク GitHub Copilot for Businessの利用 導入による費用対効果 試験導入による費用対効果の見積もり 試験導入の実施 対象者の選出 アンケートの設計 試験導入の実施 アンケート結果の集計 アンケート結果の考察 費用対効果の見積もり 全社導入の判断 導入決定後のGitHub Copilot利用環境の整備 社内LT会 おまけ
本エントリはカケハシ Advent Calendar 2023 の 11日目の記事です。 今年はPart2もあるのでぜひそちらもご覧ください！ カケハシのVP of Engineeringの湯前（@yunon_phys）です。皆さん、目標設定と評価は順調ですか？私はこれまで何年にも渡って、様々なメンバーの目標設定や評価をしてきました。残念ながら、こうすれば良い目標設定や評価が出来る！という銀の弾丸は無さそうです。でも、こう考えたら目標設定はやりやすいかも、こうすると評価はより納得感のあるものになるかも、というのはあります。 そこで今回は制度を施行・運用していく立場の人間として、目標管理と評価制度の考え方について、私の意見を述べていきます。 目標管理 目標はそもそも変わるものである みなさんこんなことありませんか？ やる気満々であんなことやこんなことを色々考えて、壮大な目標を期初にがんばって
新しいプロジェクトに参加してローカル環境を作り始めると、何かとエラーに遭遇します。 また、設計や実装について開発者に相談したり、コードレビューを依頼することもありますね。 開発者が近くにいれば、（それなりに、程よいタイミングを見計らって）話しかけて、エラーの原因を調べてもらったり、設計方法をホワイトボードにスケッチしながら相談できますが、リモート開発ではそうはいきません。 リモート開発で成果を上げるためには、このブログのように何の装飾もインタラクティブ性もない文章で、自分の状況や相談したい事柄を正確に伝える必要があります。 とはいえ私は昔、「文章がわかりにくい」と毎日、毎日上司にフィードバックをもらうくらいには文章を書くのが下手くそでした。今もわかりやすい文章が書けている自信はありません。 それでも、これまでに何度か、議論が好転したり、プロジェクトが前に進むきっかけとなる文章を書けたことが
リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog
どうも、レコメンド商品のシステム開発をしている野川と申します。 私は、2021年にモノタロウに新卒入社し、2022年5月からレコメンド商品の開発に関わり始めました。 モノタロウのレコメンド商品は、下の図の①～④の流れでクライアントサイドで表示しています。大部分の処理はJavaScriptで構成しており、UIもそのHTML部分をjQuery(JavaScript)で作成しています。 図：レコメンド商品表の流れ 入社当時私は、ソフトウェアエンジニアとして、「可読性の低いコードは駆逐するべきだ」「読みやすいコードだけが正義である」「理解しやすいシステムだけが皆を幸せにする」と心の底から考えていました。加えて、「なぜ先輩たちは可読性の低いコードを放置して平気なのか？」と疑問を持つこともしばしばありました。 レコメンド商品周りのコードはまさに可読性の低いコードベースとなっていたため、当事者となった私
雰囲気でDocker Composeを触っている状態から脱するために調べたこと（2023） - Activ8 Tech Blog
エンジニアの岡村です。 自分はサーバーがメインではなく、あまり業務でガッツリ触るわけでもないのですが、最近それなりに活用するようになってきました。しかし、ネット上の日本語情報を読んでいるだけではこれの書き方が正しいのかよく分からない、と悩むことが結構あったため、色々情報を漁ってみました。 この記事は、特に自分が気になった部分の調べた結果を記事に纏めてみたものです。対象読者はdocker-composeを雰囲気でupやdownは叩けるけどComposeファイルの書き方がよく分からんとなってる人です。 Docker Composeの概要とcompose.yaml、Compose Specの関係 compose.yamlの書き方は Compose Specに準拠すればOK Compose Specの場所 推奨のファイル名はcompose.yaml compose.yaml内にバージョンを記述する
はじめに こんにちは、株式会社カケハシでエンジニアリングマネージャーをやっている小田中（ @dora_e_m ）です。 今回は、タイトルの通り「日報を書くといいよ！」、とくに「組織のニューカマーにはオススメだよ！」という話を書きます。 日報って何? まず、日報とは何でしょうか。一般には、日々の業務内容や進捗などを報告する文書を指します。 この定義に従えば、受益者は報告される立場の上長であり、日報を作成する当の本人にはあまりメリットがありません。 私自身、ただ進捗を共有するだけの日報にはあまり意味を感じません。たとえばJiraなりTrelloなりで進捗管理している現場であれば、そのうえで進捗報告のための日報を作成することは作業の重複、情報の二重管理の発生を意味します。 ですが、日報を以下の目的で作成するようにすると、それは作成者本人にとって役立つものにできます。 毎日のふりかえり 思考プロセ
100人以上の資料を読んで見つけた伝わりやすい成果報告書の書き方 - CARTA TECH BLOG
TL;DR 自身の成果をアピールするために、1)Before/After、2)自分の寄与度、3)数字的インパクトを過不足なく伝えることが重要 説明の冒頭では、課題と解法の全体感と成果を述べ、詳細は後に肉付けすると伝わりやすい 課題を伝える際は"誰から見た課題か"を明確にする。課題は解法の前提であるためブレないように はじめに 技術広報のしゅーぞーです。この記事では、過去100人分程度の成果報告書を読み、気付いた "自分の成果をわかりやすく伝える書き方"をまとめています。 仕事をしていると自身の成果を的確に伝える機会は数多くありますよね。 評価期、転職面接、昇格面談など 評価者に自分の成果をどう分かりやすく伝えるか は自分のキャリアを伸ばす上でとても大事なスキルです。 しかし、自分の頑張りや成果を上手く言語化し、相手に正しく理解してもらうのは簡単ではありません。 特に、経験の浅い若手にとって
30代からプログラミングを本格的に始めたエンジニアが生産性について思うこと - Sansan Tech Blog
最近キーボードで文字を打つのが面倒になってきている技術本部 Eight Engineering Unitの斉藤です。 キーボードは既に100年以上使われ続けているみたいですね。そろそろ新しい入力の方法ができてもよさそうです。 例えば、頭で考えていることが文字に起こせたら、AIに任せるよりももっと便利だと思います。 前置きはさておき、Sansanではちょっと前にエンジニアの生産性と生産量の最大 化が話題になっていました。このブログをご覧の方ならご存知の方も多いのではないでしょうか。 私はこれまで何度か転職をしていますが、どの職場でも例外なくこの話題が挙がりました。 チームとして、あるいは事業としてどう最大化するかが基本前提となるのですが、私が今回話したいのは個人としての生産性の最大化についてです。 私は個人の生産性を上げることもチームの生産性を上げるのと同じくらい非常に大事なことだと考えてい
型キャストの場所のせいで、秒で終わっていたクエリに1時間超かかるようになってしまった話 - SmartHR Tech Blog
SmartHRで届出書類という機能を担当しているプロダクトエンジニアのsato-sと申します。 今日は、以前私が調査にとても苦労したパフォーマンス上の問題の話を紹介したいと思います。 TL;DR PostgreSQLのアップグレードを実施した アップグレード後、今までは問題のなかった特定のクエリの実行に1時間超かかり、DBのCPU使用率がピッタリ100%に張り付くようになった 色々調査した結果、PostgreSQL上の型キャストの場所のせいで、良くないクエリプランが選択されることが原因だった 型キャストの場所には気をつけよう PostgreSQLのアップグレードと挫折 SmartHRでは基本的にWebアプリケーションのデータベースとしてGoogle CloudのCloudSQLによって提供されるPostgreSQLを利用しています。 私の担当している届出書類機能では、利用中のPostgre
はじめに こんにちは、生産プラットフォーム開発本部のstakmeです。 本稿では、スプレッドシートの作業に「手続き的なアプローチ」と「宣言的なアプローチ」という観点を持ち込み、ふたつを対比しながら紹介します。Google Sheetsの多彩な関数を駆使して、日常的な問題に効率的に対応するための具体的なテクニックやヒントを提供します。また注意点やリスクを指摘し、スプレッドシートをより強力に活用するための知識を提供します。 目次 はじめに 目次 背景・課題 本稿の目的 規則的な処理を繰り返すケース 手続き的に構築された例 宣言的に記述された例 SEQUENCE ARRAYFORMULA 関数の組み合わせ なぜ「宣言的」なのか データが徐々に増えるケース 手続き的に構築された例 宣言的に記述された例 別の見せ方でデータを表示したいケース 手続き的に構築された例 宣言的に記述された例 やりすぎのケ
Reactを使ってプロダクト開発している開発者だけでなく、マネージャにも読んでほしい「Fluent React」 - ROUTE06 Tech Blog
チームでReactを使って開発していると、コードレビューをする際に、「この書き方はしない方がいいが、それを説明するには800文字くらい必要。図も描きたい。でもそれらを準備する時間はない。」ということが度々ありました。 また、フレームワークやライブラリの技術選定をする際、マネージャに「どうして技術選定が必要なのか」を説明する必要がありました。ROUTE06のマネージャはエンジニアリングへの造詣が深い方が多いので、対立構造になることはありませんが、説明するためには1000文字くらい必要で、やはり図も描きたい。時間はない。と同じ気持ちになることがありました。 参考情報として紹介できる情報がないか探してみると、「とりあえずこうすればOK」というベストプラクティスについては検索エンジンやSNSですぐに見つかります。ただ、どうしてその方法がベストプラクティスなのか、仕組みや原理を説明している情報は少な
はじめに こんにちは。SmartHR プロダクトマネージャーの山根（@sayama）です。 この記事は 「SmartHRのプロダクトマネージャー全員でブログ書く2024」 への参加記事です。 25人が持ち回りで毎週記事を投稿します。ぜひご覧ください！ 今回は自分がなぜSmartHRに入社したのか、その気持ちの変遷を振り返ってみようと思います。 自分の市場価値ってなに？ SmartHRに入社するまでは、製造業での機械設計を経て、技術者向け情報管理システムの構築以降、自然言語系AIの黎明期からプロジェクトマネージャー・プロダクトマネージャーを経験してきました。業務DXのためのシステム導入や既存プロダクトへのAI機能の付加価値を考えたり、それをグローバルに展開するのも非常に刺激的で、ワクワクしながら推進してきたことをよく覚えています。 キャリアの変遷 改めて自分のキャリアを振り返ると、客観的には
こんにちは、リファクタリング大好きなミノ駆動です。 株式会社スタメンでは、企業エンゲージメント構築サービスTUNAG（ツナグ）の技術的負債解消と今後の持続的成長のため、ドメイン駆動設計(DDD)の導入を検討しています。 ところでDDDはとかく理解しづらく、何のためのDDDなんだという議論になりがちです。この記事では、DDDの真の主人公コアドメインを中心に、DDDが何を解決するものなのか、全体像を改めて整理します。 この記事で扱う内容 DDDが解決したい課題と解決方法の全体像。 この記事では扱わない内容 設計パターンの実例などの実装詳細。 大事な前提 〜利益を得るためのサービス開発 会社でのサービス開発は、趣味や道楽でやるものでしょうか。違いますね。ビジネスとして、企業活動としてサービス開発しています。当たり前の話ですが、利益を得られるように開発しなければなりません。 ドメイン駆動設計は、継
社内ChatGPTを使ったGASアプリ開発の完全解説！業務改善の高速化を実現 - MonotaRO Tech Blog
こんにちは。エンタープライズソリューショングループの石川です。大企業連携システムの基盤の開発や運用を担当していて、日々発生するエラーの監視や調査も行っています。今回は手間と時間がかかりがちだったエラー調査を、ChatGPTを使って改善した話をします。 エラー調査の背景 カタログサイトの概要とエラー発生時の影響 注文受付が影響を受ける理由とエラーの具体例 エラー発生時の調査手順 1. 注文受付へのリクエストがないか確認 2. 購買システムに注文情報を再送信する仕組みがあるか確認 3. 再送信の仕組みがない購買システムの場合は、社内の担当グループに対応依頼 MonoChatに聞きながらGASアプリケーションを作成 実現したかったこと 改善のためのアプリケーションを作成 改善の費用対効果 振り返り エラー調査の背景 カタログサイトの概要とエラー発生時の影響 大企業連携は、各企業様が持つ購買システ
インフラチームの西川です。 当社ではGitHubを利用しています。いろいろ便利な機能があるのですが社内でコマテクを募集してみたところ意外と知らないものがあったので共有してみます。 行動の見える化 特定コミットのリンク取得 通知 行動規範 ガイドライン .github リポジトリ テンプレートリポジトリ タグをたくさんプッシュさせない ドラフトプルリクエスト チケットの自動リンク化 ベースブランチの更新を取り込む まだレビューが終わってないプルリクエストの一覧化 レビュアーの自動割り当て コードの所有者 ファイル単位でレビュー済みをチェックする レビュー中のファイルを全部閉じる 具体的な修正を提案する レビューコメントをラベル化 デプロイ管理 リリースノートを自動作成 行動の見える化 以下の設定をすることで、GitHub上の行動を見える化することができます。 docs.github.com
Development Division/Platform Team/Sys-Infra Unitの伊豆です。Sys-Infra Unitはインフラエンジニア・SRE 的な役割を担っています。 今回は、ある日突然SSHログインが遅くなったときに調査した内容を共有します。 SSHログインに数分かかる ある日、AWS EC2上で動いている開発環境のSSHゲートウェイにSSHログインすると30秒以上かかると報告がありました。-vvvオプションを指定してSSHログインしてみるとpledge: filesystemというログが出力された後、数十秒から数分程度かかってSSHログインが成功する状況でした。 pledge: filesystemやssh slowなどで検索してみると、主に以下のような対処法が挙げられていましたがどれを試しても状況は改善されませんでした。 systemd-logindを再起動
こんにちは、カート決済部カート決済サービスブロックの林です。普段はZOZOTOWN内のカートや決済の機能開発、保守運用、リプレイスを担当しています。 弊社ではカートや決済機能のリプレイスを進めており、これまでにカート投入のキャパシティコントロールや在庫データのクラウドリフトを実現しています。 techblog.zozo.com techblog.zozo.com 本記事では新たにクレジットカード決済処理を非同期化したリプレイス事例を紹介します。 はじめに 背景・課題 非同期化のシステム構成 パターン1 - 完全非同期化パターン パターン2 - 非同期・同期切り替えパターン パターン3 - ポーリングパターン システム構成の決定 メッセージングサービスの選定 効果 今後の展望 まとめ さいごに はじめに 本章では、非同期化前のZOZOTOWNのクレジットカード決済を用いた注文処理の流れを説明
はじめに こんにちは、CARTA HOLDINGSでエンジニアをしているこんちゃん(@konchanSS)です。 この記事は筆者が新しく発足したプロジェクトのシステムを外部委託で作った経験をチームで振り返った際に得た学びを『システムを作らせる技術』によって補強したものです。 この記事を読んでくれた方は是非『システムを作らせる技術』を一読して欲しいです。 システムを知らないあなたにこそ読んでほしい この記事はビジネスサイドや、PdMだったりマネージャーといったいわゆるシステムの開発を依頼する側の人たちに向けて書いています。 意図した通りのシステムを作ってもらうための術を知ることはあなたにとって以下のメリットがあります。 意図した通りにシステムが動くことで業務の効率的になる 貴方がやろうとしているビジネスを促進させる システムを作ってもらうための術を知ることがなぜそのようなメリットを享受できる
フロントエンドの新規開発でNext.jsの採用を見送った話 - バイセル Tech Blog
※こちらはバイセルテクノロジーズ Advent Calendar 2023の10日目の記事です。 前回の記事は、金澤さんのAuth0とEntra IDを扱うプロダクト同士を繋げるためのIstio設定あれこれでした。 はじめに こんにちは、開発3部の神保です。 バイセルでは、お客様宅への出張訪問による買取が買取チャネルの主力となっています。現在開発3部の弊チームでは、この出張訪問買取で使用されるWebアプリケーション「Visit」の新規開発を進めています。 VisitのフロントエンドにはReactを採用しましたが、Next.js等のフレームワークは使用せず、Vite + ReactによるSPA (Single Page Application)構成を選択しました。 技術選定の過程では、社内での採用事例などからNext.jsも検討の対象となりましたが、最終的にはその採用を見送る結論に至りました
MySQLのSQLクエリチューニングの要所を掴む勉強会を開催しました！ - ANDPAD Tech Blog
こんにちは！DBREの福間（fkm_y）です。先月、弊社でデータベースの技術顧問をして頂いてる三谷（mita2）さんに開発本部向けの「MySQL SQLチューニング」勉強会を実施していただきました。 今回はMySQLの得意不得意なことの説明やSQLチューニングの流れ、具体的な事例を元にした対応例、また最近話題のHTAPな製品も紹介していただきとても参考になったのでポイントをおさえてレポートをお伝えします！ 開催背景 本編 MySQL の得意なこと、苦手なこと データベースのチューニング手段と特徴 SQLチューニングの流れ インデックス SQLチューニング例 インデックスフルスキャンとカバーリングインデックス ソート まとめ 当日の資料 さいごに 過去開催されたデータベース勉強会レポート 開催背景 弊社では三谷さんによるデータベース勉強会を定期的に開催しています。数年前にも同じテーマで勉強会
2022年6月に、Androidテックリードになった いわたん です。最近、某モンスターを育てたり図鑑を埋めたりするゲームで社内大会をやったらフルボッコにされて涙目でした。悔しくて最近は不思議な力でクラフトしたり空飛んだりして王国を救うゲームやってます。 今回はAndroidテックリードとして1年間やってみた施策の紹介と、それぞれの成果や反省点を紹介したいと思います。これからテックリードになろうとしている方やテックリードをしている方の参考になったり、こんな施策もいいよというアドバイスをもらえたら幸いです。 ZOZOのテックリードの役割と責任 実施した施策 テックリード1on1 読書会 歴史的経緯があるアプリのアーキテクチャ整理へのアプローチ ネーミングセンスを鍛える会の取り組み 案件への関わり方 横断的なコードレビュー 横断的に使う機能の実装 まとめ 最後に ZOZOのテックリードの役割と
ついに最強のCI/CDが完成した 〜巨大リポジトリで各チームが独立して・安全に・高速にリリースする〜 - ZOZO TECH BLOG
こんにちは。SRE部の巣立（@ksudate）です。 我々のチームでは、AWS上で多数のマイクロサービスを構築・運用しています。マイクロサービスが増えるにつれて、CI/CDの長期化やリリース手法の分散など様々な課題に直面しました。 本記事では、それらの課題をどのように解決したのかを紹介します。 目次 目次 はじめに CI/CDのこれまで Release PRによるリリース CI/CD実行時間の長期化 マイクロサービスごとのリリースが難しい リリーサーの制限ができない ドメイン単位の並行リリース リリース手法が分散する ブランチ間の同期が必要 パイプラインの増加 CI/CD実行時間の長期化 リリーサーを制限できない CI/CDの刷新 高速かつシンプルなCIパイプライン 変更差分を利用したCIパイプラインの実行 承認機能付きのCDパイプライン GitHub Environmentsによるリリー
チームにポジティブなコミュニケーションを増やす スキルマップの使い方 - MonotaRO Tech Blog
こんにちは、モノタロウのUIUXグループの澤井です。 主にサービス開発や商品開発のためのリサーチ・体験設計、これらのための仕組みづくり・運用に携わっています。 この記事では、チームにポジティブなコミュニケーションを増やすために、メンバー同士の自己開示のためのツールとしてスキルマップを利用したこと、利用にあたって工夫したことについてお話していきます。 目次 スキルマップってどんなツール？ スキルマップを利用しようと思った背景 スキルマップの利用にあたって工夫したこと スキルマップを利用してどうだったか おわりに スキルマップってどんなツール？ そもそもスキルマップはどんなものかといいますと、縦軸と横軸を中心で交差させて分けた4つのセグメントにスキルをマッピングして傾向や状態を可視化するものです。自己紹介や自己分析に使ったり、目的によって様々に利用できる便利なツールです。 詳しくは、宇野さんの
こんにちは！ブロックチェーンチームでエンジニアをしている id:dorapon2000 です。最近買ってよかったものは「潮の華 あおさといわしふりかけ」です。 今回は Git の Squash マージについての知見を共有したいと思います。端的に言うと、 チーム開発で Non Fast-Forward マージをやめて Squash マージを採用し、再び Non Fast-Forward マージに戻した経緯の説明です。Squash マージを運用に導入するか考えたことがある方の参考になればと思います。 Squash マージとは マージには 3 種類ありますね。みなさんはトピックブランチを main へマージする際にどのマージ方法を利用していますか？ Fast-Forward マージ git merge --ff-only Non Fast-Forward マージ git merge --no-f
開発要望タスクの優先度が「高」ばかりで悩んでませんか？ - CARTA TECH BLOG
CTO室 相談室でCARTAの各部署の技術メンター・コーチをしている前田@brtriver です。 自分の仕事内容を説明するのが難しいですが、スタッフエンジニアでいう右腕です！ いろんな部署のサポートをしていると開発要望タスクのリストを確認する場面がよくあります。 そして、その中の「優先度」という項目で正しく優先度をつけることができていない現場が多いと感じます。 そこで、今回はどのように「優先度」を考えればよいかについて私自身が意識していることをまとめてみるので、ぜひ一緒に考えてみましょう。 優先度が「高」だらけになってしまう チケット管理において優先度が「高」だらけになってしまう現象を目にしたことはありませんか？ チケットは困ってる本人が書くため、基本とその優先度は「高」が多くなります。 チケットに残すために書いたとしても、優先度低いタスクはそもそもやらないという判断されることが多く、そ
こんにちは。Findy Freelanceの開発チームでエンジニアをしている2boです。 この記事では私が開発生産性を上げるために開発をする前に考えていることについて書きます。 ここで「開発をする前」というのは次のようなタイミングを指します。 PdMなどから新規施策の仕様について相談を受けたとき 起票された開発Issueを最初に確認するとき 自分がIssueを作成するとき なぜこのタイミングで考えるかというと、開発を進める上での方向性を間違える可能性を減らし後から軌道修正をしやすくするためです。 なおこの記事においては、開発生産性を「開発成果物の提供価値を投入リソースで割ったもの」とします。 いくら頑張って開発をしても、そもそもやるべきことの方向性を大きく間違えると提供価値が0に近づくため開発生産性が低下します。 特に開発が高速なチームで方向性を誤ると高速に間違った方向へ進んでしまうことに
内製オブジェクトストレージサーバ「b3」でコスト最適化を目指した話 - Mirrativ Tech Blog
インフラストリーミングチームの近藤 (@udzura) です。今回は、ミラティブで内製しているオブジェクトストレージサーバ「b3」の紹介記事を書きたいと思います。 今回の記事は、6月にGopher Talkというイベントで発表した「Go製ミドルウェアを実践投入するにあたりやったこと」をベースに、内容を詳細にしたり直近の開発状況に合わせて更新したものです。一部内容はこの発表と重複していますがご了承ください。 オブジェクトストレージサーバを内製した背景 1. 大量オブジェクトの操作や増え続ける転送量に対応したい 2. 一定期間しかファイルの保持をしない 3. オンメモリ/SSD/HDDを組み合わせたチューニングがしたい オブジェクトストレージb3の特徴 S3 互換の基本的なAPIを実装 LSM-Tree index＋WALなDB/マージ操作に対応 I/O 帯域を制限可能 非同期レプリケーション
みなさんこんにちは。ジメジメとした日が続きますがいかがお過ごしでしょうか。SmartHRのプロダクトマネージャーryopenguinです。 今回は、私が複数のプロダクトチームを経験して学んだ「兼務のコツと反省」をお届けします。 「プロダクトに対してPMが少ない」「PMの採用に苦労している」といったみなさまの参考になれば幸いです。 なぜ兼務をはじめたか 2022年9月から、私はタレントマネジメントプロダクト「従業員サーベイ」と、現在未公開の新しいプロダクトのPMを兼務しています。 弊社では、単一のプロダクトに注力するのではなく、連携を前提に複数のプロダクトを提供する「マルチプロダクト」化を進めています。昨年の夏ごろ、とある新規プロダクトが必要と判断され、開発チームを組成することになりました。 弊社の新規プロダクトはSmartHR基本機能との連携が前提であり、その基礎的な知識が必要です。さらに
いろんなやり方の読書会をやってみたら当日音読その場でまとめ方式が最高だった話 - Gunosy Tech Blog
こんにちは、SRE チーム マネージャーの TksYamaguchi です。 こちらの記事はGunosy Advent Calendar 2023の3日目の記事です。 前回の記事は森田さんの LLM 論文の探し方でした。 概要 SRE チームは、シニアエンジニアとジュニアエンジニアで構成されているチームで、チーム内の技術的な知識の偏りの解消や、知識のタコツボ化の解消を目的として読書会をしてきました。 その過程でいろいろな読書会のパターンを行ってきましたので、その結果を共有します。 概要 読書会開始前の SRE チームの課題感 読書会 のやり方の整理と評価の観点 やり方 評価の観点 当日音読・Slack に投下する方式 実際のまとめ 方式詳細 評価 メリット デメリット 事前に読んで Miro*1 に付箋・当日議論する方式 実際のまとめ 方式詳細 評価 メリット デメリット 当日黙読・その場
会計システムのアーキテクチャとモデリング ~会計というドメインを Rust で表現している話~ - CADDi Tech Blog
はじめに こんにちは。 バックエンドエンジニアの松本です。今回は、会計システムの開発を通じて、 CADDi におけるプロダクト開発の様子を紹介します。 2024年3月現在、CADDiでは2つのサービスを提供しています。1つは図面データ活用クラウド「CADDi Drawer」で、もう1つは加工品製造サービス「CADDi Manufacturing」です。 今回、後者の加工品製造サービス「CADDi Manufacturing」向けに、 会計システムを構築しました。これは、生産管理システムや拠点管理システムから取得した各種情報を基にして、会計仕訳データを生成し、経理部門に公開する役割を持ちます。 はじめに 会計システムのアーキテクチャとその狙い 計算処理を少しずつ進める 会計数値の妥当性をダッシュボードに表示する 会計システムのモデリングと最初の開発 仕訳の流れを整理して、ドメインモデル、デー
アンチウイルスソフト Antivirus for Amazon S3 を本番環境に導入してみてわかったメリット・デメリット - ANDPAD Tech Blog
こんにちは。SREチームの吉澤です。 アンドパッドでは最近、AWSのS3バケット上のファイルをスキャンするために、アンチウイルスソフト Antivirus for Amazon S3 を本番環境に導入しました。その結果、私たちの要件はほぼ全て満たされたうえに、従来比で大幅なコスト削減を実現できました。 Antivirus for Amazon S3について日本語で書かれた記事はまだ少ないですが、S3に対するウイルススキャンが求められるケースでは、導入を検討する価値があるソフトです。 そこで、今回はこのAntivirus for Amazon S3の概要、私たちが本番環境に導入してみてわかったメリットやデメリット、そしてこのソフトが適した状況をご紹介します。 背景 S3に対するウイルススキャンが必要な理由 Antivirus for Amazon S3の導入前に利用していたソフト Antiv
構想半日、実装一日、全社活用される ChatGPTのSlackbotを作りました！ - MonotaRO Tech Blog
はじめに こんにちは、新卒2年目の佐藤です。 MonotaROでは先日、ChatGPTを簡単に利用できるSlackbot「MonoChat (β)」を全社員を対象にリリースし、大勢の方に利用されるようになりました。 私は、ChatGPTが社内全体で活用されることで一人一人の身の回りの業務がもっと楽になったり、生産性を上げられる良い機会に必ずなると思いMonoChat (β) を開発しました。 本記事では社内の大勢の方に利用してもらうために考えたこと、設計/開発/運用してみて得た結果や知見、またMonotaROでのChatGPT利用についても紹介します。 特に、開発部分だけでなく設計部分や結果も紹介しているのでChatGPTを社内に普及させたい方にとって何か気づきになれば幸いです！ はじめに MonotaROでは全社員がChatGPTを利用可能です 社内でのChatGPT利用 MonoCha
こんにちは、CPOのadachiです。 この記事は「SmartHRのプロダクトマネージャー全員でブログ書く2024」への参加記事です。25人が持ち回りで毎週記事を投稿しています。 この企画にも関連するのですが、最近社外の方から「SmartHR、PM多！」という感想をいただくことが増えてきました。もしPMが多い ＝ 裁量が小さくてつまらない環境、と思われていたら心外すぎる……許せねぇ…… そこで本稿では、なぜSmartHRには25人もPMがいるのか、一体なにを作っているのか、仲はいいのか、今後どういったオポチュニティがあるのか、といったことについて説明していきたいと思います。オポチュニティは言いたいだけです。 25人は多い？ 結論、そんなに多くないと思っています。 先日「SmartHRがARR150億円を突破、前年比150％で成長」というプレスリリースも出ましたが、私たちは現在ARR 150
アーキテクチャの進化はドメインイベントが起点になる - KAKEHASHI Tech Blog
こちらの記事はカケハシ Advent Calendar 2023 Part2の24日目の記事になります。 adventar.org はじめに 反復的な開発は、変更容易性の高いソフトウェアが不可欠です。ソフトウェア開発の経験がある方なら、デリバリ後の洞察や市場環境の変化から、新しい機能の追加やアーキテクチャの進化の必要性に直面したことが一度はあるでしょう。 私自身、要求分析手法やSOLID原則等の技法を取り入れ、変更容易性に対応する多くのプロジェクトに参加しました。しかし、どれだけ優れた手法や技法を持っていても、変更が難しい要求が出てくることは避けられません。その際、「過去の出来事」を正確に記録していれば、後から見返して問題解決が容易だったと感じることがよくあります。 ドメイン駆動設計（DDD）では、「過去に起こった出来事」を表現するドメインモデルを「ドメインイベント」と呼びます。変更容易性
SmartHRでは開発にRuby on Railsを広く採用しています。 今日は負債解消のために、開発しているサービスでRailsのモデル名をすべて変更した話を紹介します。 既存のモデル構造のつらみ 私達が開発しているサービスでは、モデルの親子構造が分かりやすいということで、モデルをネストした構造にしていました。 例えば、 User に紐づくプロフィール画像 User::ProfileImage は、 app/models/user/profile_image.rb に配置する具合です。 パッと見の構造が分かりやすいのですが、時が経つにつれて次のようなつらさが顕在化してきました。 Railsの規約(推奨ルールのようなもの)に則っていないので、関連定義が冗長になる テーブル名が長くなる。 外部キーや関連名が長くなる。 関連名と外部キー名が一致せず、カラムを呼び出したいときにDB定義を見ないと
業務システム SPA のフロントエンド技術選定（2023年版） - KAKEHASHI Tech Blog
本エントリはカケハシ Part 2 Advent Calendar 2023の13日目の記事です。 （Part 1もおもしろい記事がいっぱいあるので、ぜひご覧ください。） はじめに こんにちは。カケハシでソフトウェアエンジニアをしている平松です。 今年、新規プロダクト立ち上げの機会があり、その際に行ったフロントエンドの技術選定について紹介したいと思います。 フロントエンドの領域は選択肢が豊富で、変化のスピードも速いため、プロダクトの要件に適した技術を選ぶことはひとつの挑戦です。 実際、フロントエンド技術選定のヒント 【令和五年度版】のアドベントカレンダー記事を読んで、その難しさを改めて感じました。 今回の新規プロダクトは、ユーザがログインして利用するtoBの業務システムです。 私はカケハシでは2度目の新規プロダクト立ち上げですが、前回の経験を活かしつつ、新しいアプローチにも挑戦しています。
Figma for VS Codeを使ってCSS実装する時のおすすめポイント - Goodpatch Tech Blog
Goodpatchエンジニアの池澤です。デザインツール「Figma」のスタイルや値を、テキストエディタ「VS Code」上で閲覧できる「Figma for VS Code」機能拡張が2023年6月よりFigma公式から提供されています。 この記事ではその「Figma for VS Code」について、実際に試して感じたことをまとめてみました。 ※ Figma Dev ModeやFigma for VS Codeはまだベータ版で動作保証されておりません。また本記事の内容は個人が趣味で検証したことをご理解の上、自己責任にてご利用ください。 Figma for VS Codeとは 主な使い方 使用時のワンポイント Point1： Figmaのトークンの名前と値が確認できる Point2： FigmaのSectionやReady for devマークの有無はあまり気にしなくて良い Point3：
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
私が 1on1 でしていること - Mobile Factory Tech Blog
GitHub Copilotの全社導入とその効果 - ZOZO TECH BLOG
目標管理と評価制度の考え方 - KAKEHASHI Tech Blog
リモート開発を助ける「思いやりのある文章」の書き方 - ROUTE06 Tech Blog
日報を自分のために書いてみよう - KAKEHASHI Tech Blog
宣言的でメンテナンスしやすいGoogle Sheetsという考え方 - ZOZO TECH BLOG
40歳を超えてからあたらしい領域にチャレンジすることの意味 - SmartHR Tech Blog
ドメイン駆動設計は何を解決する手法なのか - stmn tech blog
GitHubコマテク集 - OpenWork Tech Blog
SSHログインの失敗が大量に記録されているとSSHログインが極端に遅くなる - Repro Tech Blog
SQSを用いたクレジットカード決済の非同期化 - ZOZO TECH BLOG
失敗から学ぶシステム開発委託 - CARTA TECH BLOG
テックリードがどんな活動したらよいのか考えて行動してみた話 - ZOZO TECH BLOG
Git の Squash マージをやめた話 - Mobile Factory Tech Blog
開発生産性を上げるために開発をする前に考えていること - Findy Tech Blog
プロダクトオーナーを兼務する技術、あるいはその反省 - SmartHR Tech Blog
なぜPMが25人も必要なのか - SmartHR Tech Blog
Railsのモデル名をすべて変更した話 - SmartHR Tech Blog