背景 開発チームが抱えるよくある課題として システムが変化する一方でドキュメントは更新されず腐る メンバーの流入出によって口伝でかろうじて継承された知見も失われる 検索性が良くないと過去のドキュメントが気づかれず、同じような内容のドキュメントが新規量産される 後から参加したメンバーはどちらが正のドキュメントか分からず混乱する といったことが良くあります。 解決方法としては以下のように、GitHub＆ルールベースで管理するといった例があります。 future-architect.github.io また組織・システムが大きくなってくると認知負荷を低減するためにドメインで区切るような形でチームの分割が始まりますが、 異なるチームによってシステムが管理され、システムの依存関係を全て知っている人がいなくなる CxOレイヤが大規模イベント前に現状を把握したいときに都度時間がかかってしまう チームごと

症状検索エンジン「ユビー」 では、ローンチ当初から Firebase Auth (GCP Identity Platform) を使っていましたが、OIDCに準拠した内製の認証認可基盤に移行しました。 認証認可基盤そのものは m_mizutani と nerocrux と toshi0607(退職済) が作ってくれたため、僕は移行のみを担当しました。 結果として、強制ログアウトなし・無停止でビジネス影響を出さずに、年間1000万円以上のコスト削減に成功しました[1]。その移行プロセスについて紹介します。認証認可基盤そのものの紹介はあまりしません。 移行した理由 大量の匿名アカウント ユビーでは、アクセスした全ユーザーに対して自動的に匿名アカウントを発行しています。これにより、ユーザーがアカウント登録しているかどうかに関わらず、同じID体系で透過的に履歴情報等を扱うことができます。アカウント

全ての開発あるあるだと思うんですが、常にリソースがないですよね。やりたいことに対して使える開発期間が短いし、人も少ない。なので普通はやりたいことに優先順位をつけて、なくてもまあ大丈夫かなという部分は、泣く泣く落としていくことになるかと思います。今回はその優先順位を見誤った話をします。 ちなみに見誤った箇所は、エラーの表示です。Excel/CSVファイルをインポートすることで情報を登録するという機能のエラー表示だったのですが、リリース直後に改善の必要があるとわかり、再検討して実装＆リリースしました。（関わった皆さんありがとうございました🙏） これについて最近、開発チームやプロダクトマネージャー、他のデザイナー等いろいろな人と話していたのですが、そのときに出てきたことや自分の中で思った反省点について書きます。 同じような機能でも、扱う情報の内容や数が変わると状況が変わる該当の機能のエラー表示

このエントリは SmartHR Advent Calendar 2023の21日目の記事です。 Railsのバージョンを上げる作業は、単に新しいバージョンのgemをインストールするだけでは終わりません。Railsの新しいバージョンに沿った設定項目を確認し、適宜適用していく必要があります。もちろん必ずしもすべての設定を最新にしなければならないわけではありませんが、Railsの新しい設定というのは基本的にそうすることにメリットがあるから作られているわけで、特別な理由がなければ最新の状態にしておきたいものです。 みなさんのRailsアプリケーションのconfig/application.rb には次のような設定があるはずです。 config.load_defaults 6.1 このコードサンプルは引数が6.1なので、Rails6.1デフォルトの設定を適用していることを示しています。これを7.0に

こんにちは、SmartHRのVPoHR薮田（@yabucccchi）です。 これまで、SmartHRの給与制度についてnoteに書くことはあまり多くありませんでした。 会社の魅力は給与だけでなく、働きやすさ、賞賛のされ方、今後の会社の成長など、いろんな魅力で構成されていると考えています。 給与の話だけをnote等で打ち出しすぎてしまうと、どうしても給与情報が目立ってしまい、「給与が高い会社」と、組織のイメージが誤った形で独り歩きしていしまう。そういう誤解を避けたいと考えていました。 とはいえ、SmartHRにご応募いただく皆さまにとっても、従業員にとっても給与は会社で働く上での重要な要素の一つです。誤解を避けるだけでなく、SmartHRの給与の考え方や現状制度について正しくご理解いただくことで、SmartHRのことを深く知っていただくきっかけになると考え、今回noteを書くことにいたしまし

序章　リーダーシップと意思決定の重要性僕は、コロナ禍から、それが明けるこの2年くらいの間、社会人向けのリーダーシップ研修で講師をさせていただいている。次のような趣旨のリーダーシップ研修だ。 自身のパーパスを打ち出し、周囲を巻き込む。課題を発見し、ソリューションを発散する。バイアスを外し、自己を変革し、意思決定する。 https://www.kokkaraxminerva.com/人一倍「ゆるい」僕がリーダーシップ研修の講師になっているのは何かの間違いかもしれない。だけど、僕の体内には第三者からリーダーシップと呼ばれても可笑しくないものが僅かながら存在するのだから仕方がない。 リーダーシップとは何か意思決定をする力だ。もちろん、企業や部署、チームなどの組織のトップにおいてはリーダーシップを持っておくことが必須だ。しかし、リーダーシップは組織のトップだけが持つものではなく、組織の全メンバーが持

GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる GitHubが提供するGitHub.comは、世界最大のソースコード管理システムを始めとするソフトウェア開発者向け支援サービスを提供しています。 そのGitHub.comはRuby on Railsで構築されており、同社はつねにRubyとRuby on Railsをアップデートし続けていることを今年（2023年）4月に明らかにしています。 参考：GitHubは200万行規模のRailsアプリケーションであり、毎週RailsとRubyを最新版にアップデートし続けている そして同社はこのGitHub.comを支える1200台以上のMySQL 5.7を、GitHub.comのサービスレベルを維持したまま1年以上かけてMySQL 8.0にアップグレードしたことをブログで明らかにしました。 Up

この記事は 株式会社ログラス Productチーム Advent Calendar 2023 13日目の記事です。 はじめに 〇〇を削除できるかどうかのビジネス処理、皆さんはどう実装していますか？ 同僚の話題になった記事でも削除の認可処理をどこに記述すべきか？は難しいと説明されています。今回はお題は認可っぽいもので書きますが広範に「削除ができるかどうか？」のビジネスロジックをドメイン層にどう閉じ込めるかの便利な実装パターンを紹介します。 削除処理のビジネスロジックの取り扱いは難しい 削除処理のビジネスロジックの実装はシンプルだけど更新処理や作成処理と比べて意外と難しいです。 それはなぜかというとドメインオブジェクト内の実装に削除処理を書くことができないからです。 例えば権限に管理者と一般ユーザーの二つの権限があるとします。

最近は、Laravelで開発されたアプリケーションのテストコードをphpunitで書いています。 今回は、テストをするときに使いまわせる部分だけ抜き出してまとめてみました。 1.リクエストクラスのバリデーションをテストしたい キーワード：request, rules(), dataProvider, データプロバイダ ■ポイント ・データプロバイダを使うと複数のパラメータパターンのテストが書きやすい＆見やすい ・テストを実行するメソッドのアノテーションに@dataProvider を記載する。 ・テストケース名は「どのような値か 型 成功(success)or失敗(error)」でつけると分かりやすい。 ... use App\Http\Requests\MyProfile\UserRegisterRequest; use Illuminate\Support\Facades\Valida

GitHub Actionsで或るworkflowが終わったら別のworkflowを動かす、みたいなことをやりたくなった時にちまちまハマったのでメモとして残します。 workflow_run で呼び出されたworkflowで前workflowのステータスを取る これはハマったことというか「こうやれば良い」という話なんですが、 on: workflow_run: workflows: - check types: - completed jobs: ... みたいに書いておくと check workflowが完了した時にこのworkflowが呼び出されるのですが、この時 check の成否は関係無く呼び出されます。 従って、check が完了した時にのみ実行したい時には以下のようにステータスチェックを入れる必要があります。 on: workflow_run: workflows: - che

この記事は 株式会社エス・エム・エス Advent Calendar 2023 の11日目の記事です。 無いに越した事はありませんが、サービスを長い間運用しているとどうしてもシステム障害対応をやらなければいけないタイミングがあります。この記事では、小規模なアラート対応から数日間に渡るチーム横断での大規模障害までいくつのシステム障害対応に関わる中で実際に私が行ってきた事を 11 個紹介してみようと思います。 前置きとして、現在私が所属するチームはほぼ100%フルリモートで開発を行っており、それを前提とした内容になっています。 1. 専用のコミュニケーションスペースを作る 2. 役割分担をする 3. 積極的に音声通話でやりとりする 4. 情報整理用のダッシュボードを作る 5. 専用のカンバンを作る 6. 情報同期のための定時ミーティングを設ける 7. 通常業務を進めるメンバーを残す 8. メト

ばぶ@マウス🖱愛なIT系ライター @kikukaku_yki ガジェット・IT系書いてる。今年から3年ほどの人生目標は「10年後にかっこいいババアになる」です。 「おたばぶ」のばぶの方。相棒のおたよりさん（ @otayori_otbb ） 飯テロがライフワーク。ネトゲもする。 Amazonのリンクは全部アソシエイト。 sampo-note.net ばぶ@マウス🖱愛なIT系ライター @kikukaku_yki ネトゲで50人ほどの小規模コミュニティを運用してたときの話。メンバーは大体5つに分類できて。 1）挨拶や呼び掛け、提案を積極的にしてくれる人 2）上記に割と乗ってくれ、発言も多い人 3）名指しで声掛けしたりお膳立てしないと乗らない人 4）とりあえずラジオにしてる人 5）空気 3～5はどう働きかけても、なにをしても、コミュニティに対して積極性を持ってはくれなかった。 ただ、4～5は別

ISUCON 13 に初参加しました。 終わってから少し時間が空いてしまったので、ISUCONを経て感じたエンジニアとしての心境の変化を3つほど書き残します。 知識だけで止めずに手を動かすようになった これは悔いが残る反省なのですが、原因が明確であと治すだけ！という状態でも普段から手を動かしていないと全然うまくいかなかったです。 例えば今回の問題だと N＋1 がたくさんあり、これを直せばいい！ということがわかっていたのですが、意外と手が動かなくてすごく時間がかかりました。 最近はドキュメントを読んでなんとなく理解した気にならずに、サンプルコードを手元で動かしたり、人に自分の理解をぶつけて思考を深めたりなど、アウトプットすることを意識的に行うように心がけています。 技術の関心の幅が広がった 普段の業務では安定稼働しているサービスで運用・開発を行っているので、ログ周りを最初から設定したり、sl

面白法人カヤック技術部の谷脇です。私は元気です。 この記事は面白法人グループ Advent Calendar 2023の5日目のエントリーです。 というわけでこの記事では、現環境(私が取り組んでいる業務のこと)ベストの管理画面の技術選択について考えたことを書き連ねていきます。 前提知識 管理画面の定義 ここで読者と私の目線を合わせるため、この記事上での管理画面の定義をしておきます。 管理画面はサービスの運営上必要な操作やデータの閲覧をまとめたWebアプリケーションです。また、このWebアプリケーションは一般ユーザーには開放されておらず、サービス運営者側のみ閲覧と操作が可能となっている、とします。 管理画面を作る動機 ここではTonamelの管理画面について、考えて導入したことを書きます。 tonamel.com Tonamelはゲーム大会やイベントを開催するためのプラットフォームです。We

1. はじめに ソフトウェア開発のチームに、新しいメンバーが入ってくることはよくあります。 以前に新卒社員がチーム入ってきた場合の育成方法を紹介しました(こちら)。 今回は、新卒社員ではなく、他の会社から中途入社か同じ会社の部署異動で来る新メンバーの話です。 (エンジニアが数百人などで規模が大きい会社の場合、部署が違うと仕事のやり方が全く変わる場合があるので、今回は中途入社と他の部署からの異動を同じように「新メンバー」として扱います) 会社や部署が変わると仕事のやり方が大きく変わるため、仕事のやり方に戸惑うことが多いと思います。 本稿では、そのような「新メンバー」を活躍しづらくしてしまうアンチパターンとその対策を紹介します。 2. 中途入社や部署異動で来た新メンバーが適応することの困難さを理解する 中途入社や部署異動で来た新メンバーが組織に適応することは、新卒社員のそれとは別の難しさがあり

この記事は カオナビ Advent Calendar 2023 4日目の記事です。 はじめに 皆さんはコードを消していますか？？ 不要なコードが残っていると後から技術的負債となって重くのしかかってきます。 そこで今回はコードを書くより、消す方が好きな私が不要なコードを削除することについて 日頃から行っている削除対象の見極めるポイントを書いていこうと思います。 どんなコードが不要なのか まずはどんなコードが不要なのかを知らないと消せないですね。 一応、私が考えでは不要なコードは次の通りかと思っています。 未使用な変数、定数、メソッド、関数、クラス わかりやすいですね。 使っていないコードは不要なコードと判断できます。 コメントアウトしたコード 極端な例ですが、次のようなコメントアウトしたコードは不要ですね。

組織で物事を進めるのが早い人は、"提案"のコミュニケーションを取っていることが多い気がする。 "指摘"で止まるのではなく課題の解決に向けた"提案"までやる方がいいんだけれど、そもそも提案って一言で言ってもまあ難しいよね。とある1on1で雑談していて、"提案"のスキルを上げていくにあたってはいくつかのレベルに分けて考えてみるといいかもしれないと思ったので、声かけのワード別に自分の考えを雑にまとめてみる。洗練されていないので意見がほしい。 レベル0: 「どうすればいいですか」 何か問題があった時の「どうすればいいですか」という聞き方は提案ではなく指摘で止まっている。 指摘してくれるということは気づいているということだし、それを伝えてくれること自体も素晴らしいことなのだけれど、そこからどうしていくかを決めるのが大変な部分なので次のレベルにも染み出していきたい。 レベル1: 「どれにしましょうか」

こんいす～。 @ikura-hamuです。チーム「リアクティブ二子玉川～♪」でISUCON13に出ました。チームブログはこちら（まだ） 最近の若者はsshしないらしいですよ。 僕は最近のノリに乗っている若者なので、ISUCONでsshせずに作業するツール群「isu-isu-h」（いすいすえいち）を整えました。最近の若者はsshじゃなくて いすいすえいち するらしいですよ。 リポジトリ https://github.com/reactive-futakotamagawa/isu-isu-h-13 (本当のリポジトリはIPアドレスとかいろいろ上がってるのでコピーです) 名前は競技が終わってから考えました。ISUCONで自分たちの代わりにsshしてくれるのでこの名前です。 構成大きく分けて、手元の１コマンドで全サーバーでデプロイを行うansibleと、ブラウザで必要な情報を見るobserver(