はてなブックマーク

ごきげんよう🙋‍♀️あっきー（@kuronekopunk）です。 この記事は Engineering Manager Advent Calendar 2023の9日目の記事です！ 自分がEMという肩書をつけたのは2023/1からなのでちょうど1年くらいになります。この1年、EMとして開発組織を見たり、他社のマネージャーの方とお話させていただく中で組織のオブザーバビリティを上げることの大事さを感じたのでそれについて書きます。 オブザーバビリティとはオブザーバビリティとは、『可観測性』や『観測する能力』などと訳されます。システム運用の観点では、取得したデータを元に、システムの状態を把握する能力やそれを実現する手法などのことを指します。 オブザーバビリティを上げることで、複雑なシステムの状況を適切に把握し運用をしやすくる狙いがあります。 組織は複雑なシステムオブザーバビリティ向上が複雑なシステ

ごきげんよう🙋‍♀️ツクリンクでエンジニアリングマネージャーをしている、あっきー（@kuronekopunk）です。 この記事はツクリンク プロダクト部 Advent Calendar 2023 9日目の記事です。 今回はエンジニア向けの記事やイベント情報を共有するSlackの#dev-inputチャンネルについて書きます。 いい記事見つけたらSlackで共有したりしますよね。分報や部署のチャンネルを使っているところもあると思います。エンジニアチームでは情報シェア専用のinputチャンネルを作ってそこに流すようにしています。 inputチャンネルのキャプチャ専用チャンネルを作る意味偶然の出会いを増やす入っていない分報やその他チャンネルに投稿された場合には出会えない可能性があるため、専用のチャンネルを作り情報の一元化をしています。 また、人は興味のある事柄しか目に入りません。SNSで知らな

ごきげんよう🙋‍♀️ツクリンクでエンジニアリングマネージャーをしているあっきー（@kuronekopunk）です。 この記事はツクリンク プロダクト部 Advent Calendar 2023 4日目の記事です。 前日はSRE泉田さんの「ECS スケジュールされたタスクが起動しなかったことを監視する」でした。 自社サービスのツクリンクは最初は自分がPHPで作っていましたが、エンジニアの参画と合わせて2014年からRuby on Railsにリプレースしています。 リプレースから10年弱経った今、とりあえずで作ったけどサービス成長で運用が辛く負債に感じる部分を紹介していきます。（2021年に書いたRails以降時のnote） メール、通知の設計管理者のアドレスをBCCに入れた0→1のサービス開発当初、「ユーザーさんに送ったメールの内容を知りたい」という動機からユーザーさん宛のメールのBCC

ごきげんよう。ツクリンクでエンジニアをしているあっきーです。 去年から採用を強化しエンジニアメンバーが倍以上に増えました。 エンジニアチーム全体で良いプロダクトを作っていくため、実装やコードレビュー時に気をつけている点をまとめました。 ※コードに関する話は定番ですがプリンシプル オブ プログラミングやリーダブルコードを意識しています。 プロダクトの品質を高める大前提、プロダクトはユーザーさんに利用してもらい初めて価値が出ます。 まずは適切に価値が届けられるコードであることを大事にしています。 パフォーマンス第一早さは正義です。 重くなるような実装になっていないか、キャッシュは適切に利用されているか、発行されるSQLでは適切なインデックスが利用されるか、N+1が発生しないか、件数が多くなった時に壊れないかなど考慮します。 可変部分の考慮、UIスタックを意識する基本的なWebサービスはユーザー

＊＊＊ ごきげんよう。ツクリンクでエンジニアをしているあっきーです。 Railsでサービス開発をして7年、サービスも大きくなり、エンジニアも増え開発体制が整ってきているなかで技術的な課題も増えてきました。 現在の課題から、個人的に今後やっていきたいと思っていることや所感を書いていきます。 ※サービス開発の年数やその他、数字的な状況はこちらの記事にあります 🤖対象読者Railsエンジニア 特にRailsでモノリスなWebアプリを開発している方 ツクリンクに興味のあるエンジニア フロントエンドやモバイルアプリなどの課題を見て挑戦したい方 🏃‍♂️忙しい方向けまとめ開発の課題めちゃくちゃあるよ！助けて！ フロントはTS導入からコンポーネント設計やバックエンドとの分離検討 スタイルガイドやデザインシステムの設計、整備 モバイルアプリは書き直しや環境整備から バックエンドはどこまでRailsを信

自社サービス『ツクリンク』はリリースから7年が経ちました。 直近でAtomic Designをベースにしたデザインシステムの作成と、CSS設計の変更をしたので紹介します📛 CSSの変遷現在の設計の話をする前にこれまでのCSSを紹介。 Ver１　初回リリース時 昔懐かしいCSSです。Sassも使わずベタ書き。 #main .articles p { } #main .articles .header { }実は今でも一部で生きています。反省してます。探さないでください。 Ver２　リニューアル リニューアルをしたタイミングでCSS設計にはMindBEMdingを採用、SCSSを使い格段に書きやすくなりました。ファイルはBlockごとに分け、クラスの衝突を防いでいました。 # _block.scss .block { &__element { &--modifier {} } } # ディレ

リリース前のちょっとしたUI修正をエンジニアがデザイナーとペアで修正したら、早くていい感じに進んだのでUI改善でも取り入れてみた話です。 UI改善する箇所は長くサイトを運営していると溜まってくる微妙な崩れや、いつか直したい案件のやつ。「なんか気になるを一掃するぞ！」とやってみました。 『ペアUI改善』の目的目的は以下のとおり。デザイナー・エンジニアの相互理解と、負債の解消がメインです。 ・チケットに上がりづらい余白・文字サイズ等のUI修正 ・数字に上がりづらいUXの向上 ・デザイナーがUIの修正方法を知る ・プログラマーが細部のデザイン意図を理解する『ペアUI改善』の流れ基本的にはペアプロと同じ流れを想定。 準備 ・対象のページを決める（今回は複数ページ） ・『気になるリスト』作成。なんか気になる箇所をまとめる ※気になるリストは日々上がるUI修正チケットとまとめておくと良さそう手順 １．

ハンズシェアでは２週間のスプリントを切りスクラムを組んで開発をし、スプリントの終わりにふりかえりをしています。『アジャイルレトロスペクティブ』を読んでふりかえり手法を改善した取り組みを紹介します。 これまでの『ふりかえり』これまでスプリントレトロスペクティブ（ふりかえり）をKPTのフレームワークを使い改善を行ってました。 KPTとは、Keep/Problem/Tryの頭文字を取ったもの １．Keep（良かったこと、続けたいこと）を出す ２．Problem（問題、開発の妨げになったこと）を出す ３．Try（Keepを更に良くする案、Problemを改善する案）を出す ４．Tryに投票し改善していくことを決めるKPTでのふりかえりをしている中で下記のような問題を感じていました。 ・KPTが形骸化 ・スプリントでやったことをそんなに覚えてない ・チームの問題発見・改善に対してクリティカルなものが