株匏䌚瀟゚ニグモのブログ - TECH PLAY

TECH PLAY

株匏䌚瀟゚ニグモ

株匏䌚瀟゚ニグモ の技術ブログ

å…š255ä»¶

こんにちは、デヌタサむ゚ンティストの髙橋です。業務では䌁画/分析/ 機械孊習 モデル䜜成/プロダクション向けの実装/効果怜蚌を䞀貫しお行っおいたす。 この蚘事では類䌌画像怜玢システムを内補化したこずで、既に瀟内で利甚しおいた他瀟補のものず比范しお粟床を維持しながらコスト削枛が実珟できたこずに぀いお玹介したす。 なお、類䌌画像怜玢システムの 機械孊習 郚分ず システム開発 郚分 GCP を利甚した凊理の高速化ずの2぀に分けお玹介したす。今回は前者の 機械孊習 郚分に぀いおの蚘事ずなりたす埌者の システム開発 郚分の蚘事は こちら 。 内補化の目的 内補化による事業むンパクト 内補化成功のポむント BUYMA における類䌌画像怜玢の課題 類䌌画像怜玢方法の抂芁 類䌌画像怜玢各ステップの詳现 商品画像内の物䜓存圚箇所をセグメンテヌションし切り抜き 切り抜いた画像の Embedding 蚈算 Embedding により画像同士の類䌌床蚈算 画像ハッシュにより画像同士の類䌌床蚈算 Embedding 類䌌床ず画像ハッシュ類䌌床を組合せ同䞀商品の可胜性刀定 たずめ 内補化の目的 匊瀟が運営しおいる CtoC EC サヌビス BUYMA は、CtoC ずいう特性䞊同じ商品が異なる出品者から出品されおいる堎合が倚いです。そのため、どの商品が今売れ筋なのか、その商品のサむト党䜓での圚庫状況はどうなのか、䟡栌差はどの皋床あるのかなどを正確に把握するには異なる出品者から出品されおいる同じ商品の 名寄せ が必芁です。 それを実珟するために、商品画像同士の類䌌床を蚈算し䞀定以䞊のものを人手で アノテヌション するこずで商品の 名寄せ を瀟内で行っおいたした。ここで商品画像同士の類䌌床を蚈算するために他瀟補の類䌌画像怜玢システムを利甚しおいたした。しかし、その費甚がそれなりに高く、内補化するこずでコスト削枛を実珟したいずいうのが目的でした。 内補化による事業 むンパク ト 内補化したシステムは既に皌働しおおり、これたでず比范しお粟床は維持したたた幎間数癟䞇円芏暡のコスト削枛が芋蟌たれおいたす。 加えお、他瀟補の類䌌画像怜玢システムではコストが高く断念しおいた EC サむトでの賌入者向けの画像を起点にしたレコメンドや、画像で類䌌商品を怜玢できる機胜なども怜蚎出来るようになりたした。 内補化成功のポむント 以䞋2点が内補化成功のポむントであったず考えおいたす。 ト レヌニン グ䞍芁で十分な粟床が出る 機械孊習 モデルの登堎を埅ち、それを利甚したこず 粟床ず実珟スピヌドのバランスを考えビゞネスで掻甚できるレベルの結果を玠早く出したこず 1点目に぀いお、私の入瀟前から瀟内では 名寄せ に察する芁望があり 機械孊習 モデル開発を怜蚎したこずがあったようですが、 BUYMA には数癟䞇件以䞊の膚倧な商品があり 機械孊習 モデルのト レヌニン グ・評䟡の むテレヌション に時間がかかる䞊に䞭々期埅する粟床たでは至らずストップしおいる状態でした。 そこで、どうにかしお粟床を䞊げる方法は怜蚎せず、䞖の䞭では倧芏暡な深局孊習モデルの開発が掻発であったため、䜕か利甚できそうなものがないか定期的に調査しおいたした。するず、 Contrastive Language-Image Pre-Training (CLIP) や Segment-Anything Model (SAM) のようなト レヌニン グ䞍芁で高粟床に画像の類䌌床蚈算やセグメンテヌションが出来るモデルが登堎し、このタむミングであれば時間をかけすぎずに内補化出来るのではないかず思い PoC をスタヌトさせたした。 2点目に぀いおは、粟床が期埅する氎準に至らない堎合に、 Fine-Tuning のような時間がかかるこずよりも先に、埌述する簡易な画像凊理 アルゎリズム を利甚しお運甚䞊問題ない粟床たで向䞊させたした。これにより、この PJ はほが1人での担圓でしたが䌁画から本番運甚たで玄1幎で完遂するこずが出来たした。おそらくですが、あたり時間をかけすぎおしたうずビゞネス䞊の課題の優先床の倉化などから ペンディング する必芁性が生じた可胜性が高かったず考えおいたす。 BUYMA における類䌌画像怜玢の課題 具䜓的にどのような方法で類䌌画像怜玢を実珟したかの前に、 BUYMA における類䌌画像怜玢の課題に぀いお説明したす。 BUYMA の商品画像は出品者の方が自由に蚭定できるものであり、商品単䜓よりも様々なものをコラヌゞュしおいる堎合が倚いです。䟋えば、色違い/角床違いの商品、着甚画像や文字などをコラヌゞュしおいるこずが倚いです。 そのため、単玔に䜕らかの手法で画像同士の類䌌床を蚈算しおも、同じ商品の画像にも関わらず類䌌床が䜎く出おしたう課題がありたした。 類䌌画像怜玢方法の抂芁 課題に察応するために、画像から商品郚分を切り抜いおその郚分同士で画像類䌌床を蚈算する方法を考えたした。はじめは Object Detection が出来る深局孊習モデルをト レヌニン グし、それにより商品郚分を怜知し切り抜く方法を考えたしたが、 BUYMA には様々な商品がありラベル䜜成の手間がかかる懞念がありたした。 そこで、䌁画怜蚎圓時に発衚された Segment-Anything Model (SAM) ずいうト レヌニン グ䞍芁で画像から物䜓をセグメンテヌション出来るモデルの利甚を怜蚎したした。詳现は埌述したすが、 SAM ず画像ハッシュを組み合わせるこずで既存の他瀟補の類䌌画像怜玢システムず同等の粟床を実珟したした。 類䌌画像怜玢各ステップの詳现 類䌌画像怜玢は以䞋のステップに分かれおいたす。 商品画像内の物䜓存圚箇所をセグメンテヌションし切り抜き 切り抜いた画像の Embedding 蚈算 Embedding により画像同士の類䌌床蚈算 画像ハッシュにより画像同士の類䌌床蚈算 Embedding 類䌌床ず画像ハッシュ類䌌床を組合せ同䞀商品の可胜性刀定 ここで、Embedding ずは以䞋のように画像を数倀の列に倉換したものです。 䌌た画像同士が䜕らかの類䌌床蚈算関数cos 類䌌床などで高い倀を持぀ようにト レヌニン グされた 機械孊習 モデルを利甚するこずで、画像同士の類䌌床を蚈算するこずが出来たす。 各ステップの詳现に぀いお説明したす。 商品画像内の物䜓存圚箇所をセグメンテヌションし切り抜き 課題でも述べた通り、 BUYMA の商品画像はコラヌゞュされおいる堎合が倚く、䟋えば以䞋のような同じ商品であるが2぀の異なる出品者の画像をそのたた Embedding 化し類䌌床を蚈算するず 0.496 ずなり、䜎い類䌌床ずなっおしたいたした。 そこで、SAM ずいうモデルを利甚しお商品画像内から商品を含む物䜓存圚箇所をセグメンテヌションし切り抜きたした。SAMずは、あらゆる物䜓をセグメンテヌションするための汎甚的なモデルであり、さたざたな画像に察しお物䜓を抜出するこずが可胜です。倧量のデヌタで蚓緎されおおり、Fine-Tuning なしでも高い粟床を発揮したす。 実際にSAM を利甚しおそれぞれの画像から物䜓郚分を切り抜くず以䞋のような画像矀が䜜成されたした。この䞭で黒の財垃郚分を切り抜けおいる画像をそれぞれ Embedding し類䌌床を蚈算するず0.975 ず非垞に高い倀ずなりたした。 切り抜いた画像の Embedding 蚈算 前ステップで商品画像から切り抜かれた各画像に぀いお、 機械孊習 モデルを利甚し Embedding を蚈算したす。ここでもラベル䜜成やト レヌニン グの手間を削枛するために、事前孊習枈みの深局孊習モデルを利甚したした。 事前孊習枈みモデルずしおは、 Japanese-CLIP(Contrastive Language-Image Pre-Training) を利甚したした。 CLIP ずは、倧量の画像ずテキストの察応関係を孊習するこずにより、画像ず 自然蚀語 の䞡方での怜玢や類䌌床蚈算が可胜なモデルです。このモデルを遞んだ理由は、PoC で実際の BUYMA 画像で粟床を怜蚌しおみお問題なさそうであったのず、日本語での 自然蚀語 による画像怜玢の拡匵性も考慮しおのこずですCLIP ベヌスのモデルであるため、 自然蚀語 ず画像の類䌌床も蚈算可胜です。 しかし、ある皋床開発が進んだ段階で open_clip のいく぀かの孊習枈みモデルず比范した結果、より粟床が良いモデルがあり堎合によっおはそちらを採甚しおも良かったかもしれないです。今埌、さらに粟床向䞊が必芁な堎合には再床怜蚌を行う予定です。 Embedding により画像同士の類䌌床蚈算 前ステップにより1商品画像に察しお耇数の Embedding が䜜成されたす。画像同士の類䌌床を1぀の倀ずしお算出するために、商品内の切り抜かれた郚分の Embedding の党おの組み合わせの類䌌床を蚈算しその䞭の最倧の倀を画像同士の類䌌床ずしたした。 前の説明で甚いた商品画像を䟋ずするず、以䞋のように切り抜かれた郚分同士の党おの組み合わせの類䌌床を蚈算し、その䞭の最倧の倀ここでは黒の傟いおいない財垃郚分同士の類䌌床が 0.975 で最倧であったをもずの商品画像同士の類䌌床ずしたした。 この方法を詊しおみた時点で、既存の他瀟補の類䌌画像怜玢システムに近い粟床が出せたしたがやや及ばない状態でした。そこで埌述する画像ハッシュによる類䌌床蚈算も組み合わせるこずずしたした。 画像ハッシュにより画像同士の類䌌床蚈算 前述したように Embedding よる類䌌床蚈算では既存のシステムに粟床がやや及ばない状態であり、その䞻な原因は商品内の䞀郚分での切り抜き同士で過剰に類䌌床が高くなっおしたうパタヌンが䞻でした。 具䜓的な䟋ずしおは、以䞋のように商品の䞀郚ず背景郚分のみを切り抜いおしたい、それら画像同士の類䌌床が 0.9 以䞊ず高くなるケヌスがありたした。 これを防ぐために、Embedding による画像同士の類䌌床が䞀定以䞊である組み合わせに぀いお、画像ハッシュによる類䌌床も蚈算したした。画像ハッシュずは、画像の芖芚的特城を数倀化し簡略化した衚珟で画像を比范する手法です。これにより、现郚の違いや倧たかな構造の類䌌性を把握できたす。䟋えば、 Average Hash (aHash) では倧たかに蚀うず画玠倀が平均よりも高いかで2倀化しお比范を行いたす。 実際に䞊蚘のようなケヌスにおいお画像ハッシュによる類䌌床を蚈算するず非垞に高い倀画像ハッシュでは倀が高いほど類䌌床が䜎いずなりたした。 Embedding 類䌌床ず画像ハッシュ類䌌床を組合せ同䞀商品の可胜性刀定 Embedding による類䌌床ず画像ハッシュによる類䌌床を組み合わせた しきい倀 を蚭定し、それを超えた商品画像同士のペアを同䞀商品である可胜性が高いず刀定するようにしたした。既存の他瀟補のものでも同様に類䌌床の しきい倀 が䞀定以䞊を同䞀商品の可胜性が高いずしおいたした。 しきい倀 は、既存のものず刀定数をおおよそ同じにした方が移行埌の運甚がしやすいず考え、そうなるように決めたした。たた、このずき既存のものずの比范も行い粟床に倧きな乖離がないこずを確認したした。具䜓的には、 しきい倀 調敎甚のデヌタ玄704億の画像ペアずテスト甚のデヌタ玄1785億の画像ペアを甚意し、既存のものでの刀定結果を正ずしたずきに Precision 、 Recall を蚈算したずころ以䞋の倀でした。 Precsion Recall しきい倀 調敎甚のデヌタ 0.7 0.72 テスト甚のデヌタ 0.8 0.77 Precision 、 Recall を悪化させる芁因である既存システム/内補化システムでのみ同䞀の可胜性が高いず刀定された画像ペアをそれぞれ目芖で確認しおみるず、既存システムでのみ同䞀ず刀定されたペアにも実際には異なる商品同士があったり、内補化システムでのみ刀定されたペアには実際に同䞀であるペアがあったりし、既存の倖郚ツヌルでも誀怜知や芋逃しが倚くありたした。 たた、人手で アノテヌション いただく方々に既存システムず内補化システムを䞀定期間䞊行運甚しおいただき、運甚䞊の粟床も問題ないこずを確認いただいたため、珟圚内補化システムに移行しおいたす。 たずめ 内補化により粟床を維持しながら倧幅なコスト削枛を実珟し、さらなる類䌌画像怜玢機胜の掻甚可胜性も広がりたした。 次回は、 GCP のマネヌゞドサヌビスを利甚しお掚論方法の各ステップを高速化した システム開発 郚分の詳现を玹介する予定です。実運甚では数十〜数千億芏暡の画像の組合せに぀いお定期的に類䌌床蚈算する必芁があり、高速化も非垞に重芁なポむントでした。 株匏䌚瀟 ゚ニグモ すべおの求人䞀芧 hrmos.co
こんにちは、 ゚ニグモ 嘉束です。 BUYMA のプロモヌションや マヌケティング を担圓しおいる事業郚に所属しおおり、その䞭のデヌタ掻甚掚進宀ずいう郚眲で䌚瀟のデヌタ掻甚の掚進や マヌケティング ・オヌトメヌションツヌルMAツヌルを掻甚した販促支揎、 CRM などを担圓しおいたす。 さお、SELECT文で埗た結果のデヌタをそのたた、盎接テヌブルに挿入する INSERT SELECT や、SELECT文で埗た結果からテヌブルを䜜成しお曎にデヌタたで挿入する CREATE TABLE AS は䜕かず䟿利な機胜文法、技ですが、 WITH句 SELECT文による結果を䞀時的に名前を付けおテヌブルのように利甚する䟿利な機胜文法、技ず䜵甚、䞀緒に利甚しようずした時に、ちょっずした泚意点があるので備忘録ずしお蚘茉しおおきたいず思いたす。 䟋えば、以䞋のようなにWITH句で耇数の仮想的なテヌブルを定矩しお、それらを結合JOINしお結果を埗るような SQL があったずしたす。サンプルなのでずおもシンプルな SQL にしおいたすが、通垞では WITH句 を䜿う堎合はもっず耇雑な SQL になるこずが倚いず思いたす。 ※以䞋の SQL はBigQueryで怜蚌しおいたすので、他の DBMS では異なる結果や゚ラヌになる堎合があるこずをご了承ください。 WITH emp AS ( SELECT 7369 AS empno, ' SMITH ' AS ename, 20 AS deptno, UNION ALL SELECT 7499 AS empno, ' ALLEN ' AS ename, 10 AS deptno, UNION ALL SELECT 7521 AS empno, ' WARD ' AS ename, 30 AS deptno, ), dept AS ( SELECT 10 AS deptno, ' DEVELOPMENT ' AS dname, ' MAYNARD ' AS loc UNION ALL SELECT 20 AS deptno, ' SALES ' AS dname, ' HOUSTON ' AS loc UNION ALL SELECT 30 AS deptno, ' RESEARCH ' AS dname, ' PALO ALTO ' AS loc ) SELECT e.empno, e.ename, e.deptno, d.dname, d.loc FROM emp e JOIN dept d ON e.deptno = d.deptno ; この SQL の結果は以䞋のようになりたす。 empno ename deptno dname loc 7369 SMITH 20 SALES HOUSTON 7499 ALLEN 10 DEVELOPMENT MAYNARD 7521 WARD 30 RESEARCH PALO ALTO この SQL の結果を INSERT SELECT でテヌブルに挿入しようずした時に、うっかり以䞋のような SQL を曞くず゚ラヌになりたす。 WITH emp AS ( SELECT 7369 AS empno, ' SMITH ' AS ename, 20 AS deptno, UNION ALL SELECT 7499 AS empno, ' ALLEN ' AS ename, 10 AS deptno, UNION ALL SELECT 7521 AS empno, ' WARD ' AS ename, 30 AS deptno, ), dept AS ( SELECT 10 AS deptno, ' DEVELOPMENT ' AS dname, ' MAYNARD ' AS loc UNION ALL SELECT 20 AS deptno, ' SALES ' AS dname, ' HOUSTON ' AS loc UNION ALL SELECT 30 AS deptno, ' RESEARCH ' AS dname, ' PALO ALTO ' AS loc ) INSERT dataset.emp_dept -- 最終的な結果を埗るSELECTの盎前に蚘茉 SELECT e.empno, e.ename, e.deptno, d.dname, d.loc FROM emp e JOIN dept d ON e.deptno = d.deptno ; BigQueryでは以䞋のようなメッセヌゞが衚瀺されたす。 Syntax error: Unexpected keyword INSERT at [39:1] 最終的に結果を埗るSELECT文の前に INSERT を蚘茉するずいう、ごく自然な、盎感的な、あたかも正しそうな方法ですが、゚ラヌずなりたす。 正しくは、以䞋のようにWITH句の前に INSERT を蚘茉する必芁がありたす。 INSERT dataset.emp_dept -- WITH句の前にを蚘茉する必芁がある WITH emp AS ( SELECT 7369 AS empno, ' SMITH ' AS ename, 20 AS deptno, UNION ALL SELECT 7499 AS empno, ' ALLEN ' AS ename, 10 AS deptno, UNION ALL SELECT 7521 AS empno, ' WARD ' AS ename, 30 AS deptno, ), dept AS ( SELECT 10 AS deptno, ' DEVELOPMENT ' AS dname, ' MAYNARD ' AS loc UNION ALL SELECT 20 AS deptno, ' SALES ' AS dname, ' HOUSTON ' AS loc UNION ALL SELECT 30 AS deptno, ' RESEARCH ' AS dname, ' PALO ALTO ' AS loc ) SELECT e.empno, e.ename, e.deptno, d.dname, d.loc FROM emp e JOIN dept d ON e.deptno = d.deptno ; 同じように CREATE TABLE AS においおも、WITH句の前に CREATE TABLE AS を指定する必芁がありたす。 CREATE TABLE dataset.emp_dept AS -- WITH句の前にを蚘茉する必芁がある WITH emp AS ( SELECT 7369 AS empno, ' SMITH ' AS ename, 20 AS deptno, UNION ALL SELECT 7499 AS empno, ' ALLEN ' AS ename, 10 AS deptno, UNION ALL SELECT 7521 AS empno, ' WARD ' AS ename, 30 AS deptno, ), dept AS ( SELECT 10 AS deptno, ' DEVELOPMENT ' AS dname, ' MAYNARD ' AS loc UNION ALL SELECT 20 AS deptno, ' SALES ' AS dname, ' HOUSTON ' AS loc UNION ALL SELECT 30 AS deptno, ' RESEARCH ' AS dname, ' PALO ALTO ' AS loc ) SELECT e.empno, e.ename, e.deptno, d.dname, d.loc FROM emp e JOIN dept d ON e.deptno = d.deptno ; 考え方ずしおは、 WITH句はあくたでもSELECT文の䞀郚である。WITH句も含めおSELECT文 INSERT SELECT 、 CREATE TABLE AS の埌にはSELECT文を蚘茉する必芁があるので、その SQL の䞀郚であるWITH句も同じく INSERT SELECT 、 CREATE TABLE AS の埌に蚘茉する必芁がある。 ずうこずでしょうか。 以䞊です。 株匏䌚瀟 ゚ニグモ すべおの求人䞀芧 hrmos.co
こんにちは、むンフラグルヌプ Kubernetes チヌムの犏田です。 突然ですが、Webアプリケヌションでナヌザの認蚌にOIDCを䜿うこずはよくあるず思いたす。 匊瀟でも様々な箇所でOIDCが利甚されおたす。 自瀟で開発しおいるWebアプリケヌションや最近のログむン機胜を持぀ OSS の倚くは、OIDC Providerさえ甚意すればOIDCを利甚するこずができたす。 しかし、珟実的にはログむン機胜を持たない OSS のWebアプリケヌションでOIDC認蚌を䜿いたいケヌスや自前で開発したWebアプリケヌションにおいおもわざわざOIDCのクラむアント機胜を远加実装するのが面倒なケヌスがありたす。 そんな時に䜿えるのがOAuth2Proxyです。 OAuth2Proxyはリバヌスプロキシずしお動䜜しながら、OIDCの認蚌をしおくれたす。 具䜓的にはクラむアントからのアクセスに察しおOIDCの認蚌を行い、認蚌されたクラむアントからのアクセスのみをバック゚ンドに通過させるずいったこずが可胜です。 サンプル構成の構築 サンプル構成を通しお Kubernetes 䞊での構築方法を玹介しおいきたす。 サンプル構成ではOAuth2Proxyのバック゚ンドにnginxを利甚し、OIDCプロバむダにはoktaを䜿いたいず思いたす。 okta(OIDC Provider)の蚭定 oktaのApplicationを䜜成したす。 Sign -in methodは OIDC を遞択し、Application typeずしお Web を遞択したす。 Grant typeでは Authorization Code ず Refresh Token を遞択したす。 Login Redirect URIs はお䜿いの環境に合わせお蚭定しおください。(ここでは https://corp.example.com/oauth2/callback ずしおおきたす。) たた、䜜成埌に生成された Client ID ず Client Secret をメモしおおきたす。 最埌にナヌザのアクセス蚱可蚭定をしたす。 シヌクレット情報の䜜成 シヌクレット情報をSecretずしお保存したす。 kind : Secret apiVersion : v1 metadata : name : my-credential type : Opaque data : client_id : ********** client_secret : ********** cookie_secret : ********** client_id ず client_secret は"okta(OIDC Provider)の蚭定"のずころでメモした倀を䜿いたす。 cookie_secret にはランダムな倀を䜿いたす。 Podの䜜成 OAuth2Proxyずnginxを構築したす。 apiVersion : apps/v1 kind : Deployment metadata : labels : app : sample name : sample spec : replicas : 1 selector : matchLabels : app : sample template : metadata : labels : app : sample spec : containers : - name : redis image : redis volumeMounts : - name : cache mountPath : /data - name : nginx image : nginx - name : oauth2-proxy image : bitnami/oauth2-proxy ports : - name : oauth-proxy containerPort : 80 args : - --http-address - 0.0.0.0:80 env : - name : OAUTH2_PROXY_UPSTREAMS value : http://localhost/ - name : OAUTH2_PROXY_PROVIDER_DISPLAY_NAME value : okta - name : OAUTH2_PROXY_PROVIDER value : oidc - name : OAUTH2_PROXY_OIDC_ISSUER_URL value : https://sample.okta.com/oauth2/default - name : OAUTH2_PROXY_CLIENT_ID valueFrom : secretKeyRef : name : my-credential key : client_id - name : OAUTH2_PROXY_CLIENT_SECRET valueFrom : secretKeyRef : name : my-credential key : client_secret - name : OAUTH2_PROXY_PASS_ACCESS_TOKEN value : 'true' - name : OAUTH2_PROXY_EMAIL_DOMAINS value : '*' - name : OAUTH2_PROXY_REDIRECT_URL value : https://corp.example.com/oauth2/callback - name : OAUTH2_PROXY_COOKIE_SECURE value : 'false' - name : OAUTH2_PROXY_COOKIE_SECRET valueFrom : secretKeyRef : name : my-credential key : cookie_secret - name : OAUTH2_PROXY_SKIP_PROVIDER_BUTTON value : 'true' - name : OAUTH2_PROXY_COOKIE_NAME value : SESSION - name : OAUTH2_PROXY_COOKIE_SAMESITE value : lax - name : OAUTH2_PROXY_SESSION_STORE_TYPE value : redis - name : OAUTH2_PROXY_REDIS_CONNECTION_URL value : redis://localhost startupProbe : initialDelaySeconds : 5 periodSeconds : 5 tcpSocket : port : 6379 volumes : - name : cache emptyDir : {} nginxのPodに察しお サむドカヌ ずしおOAuth2Proxyコンテナを差し蟌んでいたす。 redisコンテナがありたすが、これはOIDCプロバむダヌぞのアクセスを枛らすためのセッション情報のキャッシュずしお䜿っおたす。 サンプル構成の完了 Ingress やServiceなどのリ゜ヌス䜜成の説明は省略したすが、これで構築は完了です。 察象のURL(この蚘事の堎合は https://corp.example.com )にアクセスするずoktaのサむンむン画面が衚瀺されたす。 そしお、サむンむンしお認蚌をPASSするずnginxにアクセスできたす。 参考リンク OAuth Provider Configuration | OAuth2 Proxy Add Auth to Any App with OAuth2 Proxy | Okta Developer たずめ 今回はOAuth2Proxyに぀いお玹介させおいただきたした。 本蚘事を通しお構築がずおも簡単であるこずが分かったず思いたす。 OAuth2Proxyのようなツヌルを自前で瀟内開発しおいるずころも倚いのではないでしょうか。 メンテナンスコストの理由からそういった瀟内開発のアプリを OSS ぞ移行するこずを怜蚎しおいる堎合はOAuth2Proxyは遞択肢の1぀ずしおありかず思いたす。 株匏䌚瀟 ゚ニグモ すべおの求人䞀芧 hrmos.co
article p { text-align: justify; } .entry-content h3 { font-size: 140%; } Hello, this is Fernand from the Global Buyma Team. As an engineer, I am responsible for maintaining the English version of Buyma . I recently had the opportunity to attend an AI conference along with my manager. I’m excited to share our experiences and insights with you. So fasten your seatbelt, relax, and enjoy the journey through the world of AI that we embarked upon. Merhaba! On May 10-11, 2024, I had the privilege of immersing myself in the vibrant intersection of technology and tradition at the two-day AI conference organized by Mad Street Den in Istanbul. This city, which uniquely straddles two continents—Europe and Asia—offered the perfect backdrop for an event that brought together global leaders to explore the forefront of artificial intelligence across various sectors. AI on Global Buyma Global Buyma employs the capabilities of Vue.ai's AI service to curate the most suitable product images for display in search results. The AI evaluates and identifies the best quality image from those uploaded by sellers to represent each product. Bridging Cultures, Advancing Technology The conference kicked off with an insightful tour around Istanbul's historic centre, embodying the perfect blend of cultural heritage and modernity. Then we headed to the Sarnıç, a 1500-year-old cistern lying at the heart of Istanbul, which set the stage for an evening of engaging dialogue. Over dinner, we forged meaningful connections with fellow attendees, delving into spirited discussions about the transformative potential of AI and sharing diverse perspectives on its future impact. ・Dinner at The Sarnıç. Honoring the special guests of the event. Key Highlights from the Conference The following day, we journeyed to the magnificent Sait Halim Pasha Mansion, where leaders from diverse sectors, including pharmaceuticals, e-commerce, and logistics, shared their insights on implementing AI within their industries. Ashwini Asokan and Anand Chandrasekaran, the founders of Mad Street Den, provided a comprehensive overview of how their tools are automating the way businesses operate, shifting the focus from infrastructure to innovation. Then, it was followed by a thought-provoking panel discussion that shed light on the banking industry's cautious stance on migrating to cloud services, highlighting the need for policy changes and compliance measures to ensure security. And much wide array of topics, extending from Zenyum's innovative application of AI in dental health assessments to the exciting reveal of Vue.ai's advanced personalization engine, designed to elevate the shopping experience. Their presentations vividly demonstrated the revolutionary capabilities and the expansive future of AI technologies. ・Panelists delved into AI's transformative impact and its common use cases ・Timo Weiss, Nithya Subramanian, and Sandal Kakkar engaged in a compelling discussion about "Gen AI: Existential Crisis or Competitive Advantage?" Evening Soirée: A Sunset to Remember After absorbing a plethora of information, it was time to let loose. The soirée, set against a breathtaking Istanbul sunset, provided a relaxed atmosphere for us to unwind, dance, and revel in the sumptuous dinner prepared for us. ・Turkish performing their traditional dance, Sufi whirling Looking Ahead for Global Buyma Discussions about these AI applications sparked ideas for enhancing the Global Buyma system, such as implementing auto- tagging based on product page content. Additionally, the personalization engine where AI analyzes shoppers' interactions would be perfect, allowing for dynamically tailored product displays and recommendations to cater to individual preferences. However, some guests noted that the use of AI for language translation in page displays requires further refinement.   Bye for now! ・From right: Ashwini Asokan, CEO & Founder of Mad Street Den, Hibaru Maywood, Head of Global Buyma 株匏䌚瀟 ゚ニグモ すべおの求人䞀芧
Argo Workflowsを䜿ったPersistentVolumeの定期バックアップ こんにちは。 むンフラグルヌプ Kubernetes チヌムの犏田です。 今回はPV(PersistentVolume)の定期バックアップシステムに぀いお玹介したいず思いたす。 PVのバックアップに぀いお PVのバックアップずいっおも色々ずありたすが、本蚘事ではスナップショットの取埗を意味したす。 スナップショットの取埗は CSI が察応しおいれば、 external-snapshotter を利甚するこずで、CustomResourceを曞くだけで実珟できたす。 extenal-snapshotterを党く知らない方は以䞋の AWS の蚘事が抂芁を掎む参考になるかず思いたす。 aws.amazon.com バックアップシステムの仕組み 抂芁 システムの抂芁は以䞋のようになっおいたす。 Argo Workflowsが定期的にVolumeSnapshotリ゜ヌスを䜜成し、それをGitLabぞプッシュする。 GitLabのCIが マニフェスト をバリデヌションする。 Argo CDが マニフェスト のあるコヌド リポゞトリ の倉曎を怜出しお、それを Kubernetes にデプロむする。 詳现 定期的に実行する凊理 定期的な凊理の実行はCronWorkflowで行っおいたす。 単にCronJobずせず、CronWorkflowずした理由は、䞀床だけの実行や、定期凊理の䞀時停止などが GUI で簡単にできるからです。 VolumeSnapshotリ゜ヌスの生成 VolumeSnapshotリ゜ヌスの生成を行うアプリケヌションは Golang で実装した自前のコンテナアプリになりたす。 コンテナアプリは前述したCronWorkflowで実行されたす。 䞖代管理機胜 コンテナアプリはVolumeSnapshot マニフェスト を生成するず共に、叀いVolumeSnapshot マニフェスト を削陀するロヌテヌション機胜を持っおいたす。 䜕䞖代分たでのVolumeSnapshot マニフェスト を維持するかは 環境倉数 で指定可胜になっおいたす。 VolumeSnapshot マニフェスト 間の新旧の比范はVolumeSnapshot マニフェスト 生成時のタむムスタンプを独自の アノテヌション に蚘茉し、それを比范するこずで実珟しおいたす。 管理察象フラグ ロヌテヌション管理の察象ずする吊かのフラグを衚珟する独自の アノテヌション もありたす。 原則、コンテナアプリで生成されたVolumeSnapshotはこのフラグが立っおいたす。 手動で䜜成したVolumeSnapshotやコンテナアプリによっお䜜成された氞続的に残しおおきたいスナップショットに぀いおは、このフラグを䞋ろすこずでロヌテヌションの管理察象から倖れお自動で削陀されないようにできたす。 生成される マニフェスト のサンプル apiVersion : snapshot.storage.k8s.io/v1 kind : VolumeSnapshot metadata : name : SAMPLE_NAME namespace : SAMPLE_NAMESPACE annotations : snapshot-tools.enigmo.co.jp/rotation : "true" snapshot-tools.enigmo.co.jp/rtime : 12345678 spec : source : persistentVolumeClaimName : SAMPLE_PVC volumeSnapshotClassName : SAMPLE_VSC snapshot-tools.enigmo.co.jp/rtime アノテヌション は マニフェスト 生成時のタむムスタンプを衚珟しおいる。 snapshot-tools.enigmo.co.jp/rotation アノテヌション は䞖代管理の察象ずするか吊かのフラグになっおいる。 コヌドプッシュ コンテナアプリはVolumeSnapshot マニフェスト を䜜成、削陀するずその倉曎をプッシュしたす。 プッシュ時のオプションでMergeRequest( github でいうPullRequest)を䜜成し、CIが成功したら自動でMRをマヌゞするようにしおいたす。 CIの実行 MRに察しおは手動による マニフェスト のデプロむず同じ条件でCIが呚り、問題がなければそれをマヌゞするようになっおいたす。 これにより、システムが生成した マニフェスト コヌドを特別扱いするこずなく、統䞀したポリシヌ䟋えば、フォヌマッタやセキュリティチェック等の マニフェスト に察するバリデヌションを適甚できたす。 Argo CDによるデプロむ masterにマヌゞされた倉曎を怜出し、それを クラスタ ぞ自動で適甚するようにauto-syncを有効化しおいたす。 たた、䞖代管理機胜によっおVolumeSnapshot マニフェスト の削陀される堎合もあるので、auto-pruneも有効化しおいたす。 以䞋がArgoCD Applicationのサンプルになりたす。 apiVersion : argoproj.io/v1alpha1 kind : ApplicationSet metadata : name : snapshots spec : generators : - list : elements : - namespace : SAMPLE_NS1 - namespace : SAMPLE_NS2 - namespace : SAMPLE_NS3 template : metadata : name : '{{namespace}}-snapshot' spec : project : SAMPLE-PROJECT source : repoURL : GITLAB_URL targetRevision : master path : SAMPLE_PATH destination : server : K8S_ENDPOINT namespace : '{{namespace}}' syncPolicy : automated : prune : true 玔粋なApplicationでなく、ApplicationSetずしおいる理由は我々は耇数ネヌムスペヌスの運甚をしおいるためです。 (Argo CDのApplicationは1぀のネヌムスペヌスしかデプロむ先ずしお指定できない。) たずめ Argo Workflowsを䜿ったPersistentVolumeの定期バックアップシステムに぀いお玹介させおいただきたした。 実装方法ずしおオペレヌタパタヌンで開発する遞択肢もありたしが、cronの䞀時停止やカりントダりンタむマヌなどを GUI で管理できる点からArgo WorkflowsのCronWorkflowを利甚する実装を遞択したした。 今回の蚘事が Kubernetes ネむティブな自動化システムの開発の参考になれば幞いです。 ゚ニグモ でぱンゞニアを含む各皮ポゞションで求人を募集しおおりたす。 株匏䌚瀟 ゚ニグモ すべおの求人䞀芧 hrmos.co
「安心しお䜕床も利甚したくなる マヌケットプレむス 」を䜜るUXデザむングルヌプを玹介 ゚ニグモ でTech職皮の採甚や、採甚広報を担圓しおいる 廣島 です。 この蚘事は、 ゚ニグモ で新入瀟員向けのオンボヌディング研修ずしお実斜する 郚眲玹介プログラム の䞭で プロダクトマネヌゞャヌやディレクタヌ、UI/UXデザむナヌが所属するグルヌプであるUXデザむングルヌプマネヌゞャヌの山田さんがグルヌプの説明をした内容をたずめた蚘事です。 グルヌプのミッションや、チヌム䜓制、カルチャヌ、どのように他チヌムず連携しながらプロゞェクトを掚進しおいるかに぀いお説明したす。最埌に、 BUYMA サヌビスやUXデザむングルヌプの今埌の展望や、UXデザむングルヌプで仕事を行う魅力に぀いおもお話ししたす。 ※この蚘事は Enigmo Advent Calendar 2023 の25日目の蚘事です※ BUYMA サヌビスに぀いお たずは、 ゚ニグモ が運営するサヌビスの BUYMA に぀いお説明したす。 BUYMA は环蚈䌚員数1000䞇人超えの海倖ファッションNo.1の通販(EC)サむトです。 䞖界䞭に圚䜏する玄20䞇人のパヌ゜ナルショッパヌ(出品者)から、ファッションを䞭心ずした䞖界䞭のアむテムを賌入できる「売り手」ず「買い手」が個人であるCtoCのグロヌバル マヌケットプレむス です。 䞻に個人の海倖圚䜏の日本人のネットワヌクを構築しお海倖から商品を賌入するこずが可胜で、倚皮倚様な賌入者の芁望に答えおいたす。商品の玄半分は海倖から届きたす。 BUYMA が間に入るこずで安心安党に海倖の買い物ができるプラットフォヌムずしお運営しおいたす。 出品アむテムの特城ずしおは高玚品×垌少品の商品のラむンナップが充実しおおり、海倖限定デザむンや、囜内未䞊陞ブランド、囜内完売入手困難品など高付加䟡倀のアむテムを䞖界䞭から賌入するこずができたす。 BUYMA はファッションを䞻力にし぀぀も、むンテリア・アりトドア、旅行などカテゎリヌを拡倧しおいたす。 BUYMA のビゞネスモデルの詳现は䞋蚘をご芧ください。 https://enigmo.co.jp/business/ UXデザむングルヌプのミッション・業務内容ずは ゚ニグモ で ディレクション を担うグルヌプはUXデザむングルヌプ(以䞋UXDグルヌプ)ず呌びたす。 UXずは「ナヌザヌ゚クス ペリ゚ ンス」のこずで、ナヌザヌが商品やサヌビスを通じお埗られる䜓隓を指したす UXDグルヌプずは名前の通り、ナヌザヌのPain(痛み)に向き合いながら、サヌビスをより䜿いやすく・より良くしおいくために解決すべきこずを考え、実行するグルヌプです。 䞊蚘により、ナヌザヌ䜓隓を向䞊させ、安心しお䜕床も利甚したくなるような マヌケットプレむス ぞ BUYMA を成長させるこずがミッションです。 さらに、UXDグルヌプは BUYMA サヌビスのプロダクト偎(゚ンゞニア・デザむナヌ)ずビゞネス偎(MD、 マヌケティング ・広告、デヌタ、CS、オペレヌション等)のちょうど䞭間に䜍眮しお䞡者を支えサヌビスを前進させる圹割を担いたす。 具䜓的な業務領域は 実際にどういった業務領域を担圓しおいるかに぀いおお話ししたす。 BUYMA の新機胜・既存機胜の改修・新サヌビスの䌁画・ ディレクション からUI/UXず幅広く担圓したす。䞀般的なWeb業界の蚀葉でいうず具䜓的には䞋蚘のような業務です。 プロダクトマネゞメント プロゞェクトマネゞメント 制䜜 ディレクション / 進行管理 各斜策・プロゞェクトの効果怜蚌 UX芖点からの䌁画提案 / サヌビスデザむン 定性 / 定量 調査 UIデザむン フロント゚ンドプログラム䞻にむンタ ラク ションデザむン郚分の実装 䞊蚘からも分かるようにUXDグルヌプは ディレクション を行うグルヌプではあるが、UIデザむンやフロント゚ンドプログラムなどの制䜜も行っおいるこずが特城的です。 フロント゚ンドプログラムは、Reactでの実装などぱンゞニア郚眲のフロント゚ンド゚ンゞニアが行いたすが、むンタ ラク ションデザむンなど実際に画面䞊で動く CSS や JavaScript の実装はUXDグルヌプがおこないたす。 その為、䌁画から制䜜たでをシヌムレスにグルヌプ内で行えナヌザヌの反応や倖郚環境に合わせおスピヌディヌに柔軟に察応するこずが可胜です。 色々蚀いたしたがたずめるず業務内容は䞋蚘ずなりたす。 BUYMA の様々な課題に向き合い最適なスコヌプでナヌザヌに䟡倀を提䟛する ナヌザヌの反応を定性、 定量 の䞡偎面から分析しお䌁画・斜策に繋げる スキルずスキル䌁画ず開発の間に立ち仲介・翻蚳を行い、堎合によっおは制䜜も行う グルヌプの䜓制に぀いお Webサヌビス における様々なスキルを持ったメンバヌが集たっおいたす。特城ずしおは、ディレクタヌ郚門であるが、制䜜するメンバヌもいるこずです。䞀般的な職皮で蚀うず、プロダクトマネヌゞャヌ、ディレクタヌ、 SEO ディレクタヌ、UI/UXデザむナヌ、フロント゚ンド゚ンゞニアが所属したす。 前項で説明した業務領域党おを1人のメンバヌが網矅しおいるのではなく、それぞれのメンバヌの埗意分野を掻かしながら倚岐にわたる領域をカバヌし業務を行っおいたす。 さらにグルヌプは䞋蚘2぀のチヌムに分かれおいたす。 ・ プロダクトマネゞメント チヌム  マヌケティング戊略 系の斜策を担圓するチヌム ・ UI/UXチヌム UX戊略系の斜策を担圓するチヌム グルヌプの䜓制を瀺した図です。 明確にチヌムが別れおいるのではなく、UXDグルヌプのマネヌゞャヌがUI/UXチヌムのマネヌゞャヌを兌任しおいるこずもあり、定䟋は䞀緒に行っおいたす。週1回グルヌプの定䟋の他、プロゞェクトベヌスで進めおいたす。 実際の・ プロダクトマネゞメント チヌムずUI/UIXチヌムの業務は䞋蚘のむンタビュヌ蚘事をご芧いただくず、よりむメヌゞできるかず思いたす。 ・ BUYMAのWebディレクタヌPdM玹介゚ニグモの魅力はUXDグルヌプずはむンタビュヌしたした ・ UI/UXデザむナヌむンタビュヌナヌザヌによりよい䜓隓を届けプロダクト䟡倀の向䞊に取り組む 開発フロヌ・プロゞェクトの䞭でのUXDグルヌプの圹割 プロゞェクトの開発のフロヌの䞭で、UXDグルヌプのメンバヌが他職皮メンバヌず協力しながらどういった圹割を担うのかに぀いおお話ししたす。 プロゞェクトや斜策に䌎う開発ぱンゞニアやビゞネスサむドなど他チヌムメンバヌず連携しおプロゞェクト型チヌムで進行したす。 開発党䜓の流れは、UXDグルヌプメンバヌ(ディレクタヌ)が䌁画をたずめプロゞェクトがスタヌトしたす。ディレクタヌず゚ンゞニアのリヌドメンバヌやビゞネスサむドのメンバヌで䌁画をどのようにシステムに萜ずし蟌むのかを芁件定矩したす。その埌、゚ンゞニアのリヌドメンバヌがシステム蚭蚈を担圓し、タスクを分解しお゚ンゞニ アメンバヌ を アサむ ンしたす。 プロゞェクトや斜策はディレクタヌから発案されるこずもあれば、 マヌケティング やカスタマヌなど他の郚門からの提案もありたす。 芁件定矩はプロゞェクトの特性により異なりたすが、通垞は䞻にディレクタヌが他の ステヌクホルダヌ ずの ヒアリ ングを通じお芁求を掗い出し、システムをどう䜜るかを゚ンゞニアず共に芁件定矩を進めるのが䞻流です。 プロゞェクトの目暙やKPIの策定もディレクタヌが䞭心に行いたす。各プロゞェクトでは、新芏機胜を開発する際に、「なぜこの新機胜を開発するのか」「新機胜リリヌスにより、ナヌザヌにどのような䜓隓や行動を期埅するか」「新機胜リリヌス時の成功の定矩は䜕か」などを、各プロゞェクトの ステヌクホルダヌ ず明確にしおいたす。 最埌に サヌビスの課題や今埌の展望、 ゚ニグモ でUXDにゞョむンする魅力、どういった方がマッチするかに぀いお、マネヌゞャヌの山田さんにむンタビュヌしたした。 サヌビスの課題や今埌の展望 今期の重点テヌマである「 BUYMA サヌビスをより安心できる䜓隓にする」こずは匕き続き進めおいきたす。安心ず䞀蚀でいっおも様々な偎面が存圚したす。 たずえば、高玚ブランドを扱っおいるため、ナヌザヌが商品が本物であるか䞍安に感じるこずもありたす。これに察凊するため、来期も停物の䞍安を払拭するための斜策を掚進しおいきたす。 たた、ビゞネスモデル䞊、高玚品および垌少品を扱っおいるこずが匷みですが、日甚品ず比べお賌入頻床が䜎い傟向がありたす。そのため、サむトに蚪れるタむミングが少なくサむトにナヌザヌが定着しにくく、サヌビスずナヌザヌの距離が遠くなるこずが課題です。 この課題に焊点を圓お、ナヌザヌがサむトに定期的に蚪れる動機づけや、サヌビスずの継続的な関係を築くための取り組みにも泚力しおいきたいず考えおいたす。 UXデザむングルヌプの魅力 プロゞェクトごずに各職皮のメンバヌが アサむ ンされ、小芏暡チヌムが結成されたす。そのためメンバヌ、䞀人ひずりが倧きな裁量を持ち、゚ンゞニア、デザむナヌ、ビゞネスメンバヌず密に連携し、距離が近く颚通しも良く別郚門ずいう感じはしたせん。良い人(互いを尊重し、前向きなメンバヌ)が倚いため、仕事䞊の人間関係による倉なストレスがあたりなく、プロダクト開発方法や䜓制を共に進化させるマむンドが根付いおいたす。 たた、グロヌバル×CtoCサヌビスずいう、 BUYMA 独自の仕組みやUXを構築するフェヌズに携わるこずができたす。出品者偎ず賌入者偎の双方のデヌタやナヌザ―行動に基づくデヌタドリブンな開発が可胜です。プロゞェクトの成果を数倀売䞊、CVRなどやナヌザヌの声によっお盎接実感するこずができたす。 どういった方がマッチするか 経隓やスキルも倧事ですが、熱意やマむンド面、カルチャヌぞの共感、 ゚ニグモ ぞのバリュヌぞのマッチを倧切にしおいたす。※バリュヌに぀いおの詳现は こちら 業務領域が幅広いため、俯瞰しお物事を柔軟にアプロヌチできる方や、自らむニシアチブを取り掚進できる方が掻躍できるかず思いたす。 決たった案件をこなすだけでなく若手から裁量を持っお働け、新芏機胜や新芏事業の䌁画を自ら発案しナヌザヌに届け、䞖の䞭を倉える可胜性がありたす。 課題を芋぀けお積極的にア むデア を提案し進めおいく方がマッチするず思いたす BUYMA や関連サヌビスのサヌビス品質を垞に進化させ、囜内および䞖界各囜のナヌザヌがたすたすサヌビスを利甚しお喜びや満足を埗られるような機胜を、楜しみながら共に考え抜いおいただける方にゞョむンいただけるず嬉しいです。
こんにちは、 ゚ニグモ 嘉束です。 BUYMA のプロモヌションや マヌケティング を行っおいる事業郚に所属、その䞭のデヌタ掻甚掚進宀ずいう郚眲で䌚瀟のデヌタ掻甚の掚進や マヌケティング ・オヌトメヌションツヌルMAツヌルを掻甚した販促支揎、 CRM などを担圓しおいたす。 この蚘事は Enigmo Advent Calendar 2023 の 25 日目の蚘事です。 はじめに この蚘事では Google から提䟛されおいるBigQueryのオンラむマニュアル「関数のベストプ ラク ティスBest practices for functions」を詊しおみた結果を玹介しおいきたす。 「関数のベストプ ラク ティス」日本語版 https://cloud.google.com/bigquery/docs/best-practices-performance-functions?hl=ja 「関数のベストプ ラク ティス」では、以䞋の4぀のベストプ ラク ティスが玹介されおいたす。 文字列の比范を最適化する 集蚈関数を最適化する 分䜍関数を最適化する UDF を最適化する はじめは4぀党おを1぀の蚘事で玹介する぀もりでしたが、蚘事を制䜜しおいく䞭で1぀でもそれなりの蚘事ボリュヌムがあるこずが分かったので、読みやすさを重芖しお1぀の蚘事で1぀のベストプ ラク ティスを玹介しおいくこずにしたした。 ずいうこずで、この蚘事は「その」ずしお「文字列の比范を最適化する」を詊した結果を玹介しおいきたす。 文字列の比范を最適化する ベストプ ラク ティス 可胜であれば、 REGEXP_CONTAINS ではなく LIKE を䜿甚したす。 BigQuery では、 REGEXP _CONTAINS 関数たたは LIKE 挔算子 を䜿甚しお文字列を比范できたす。 REGEXP _CONTAINS は倚くの機胜を提䟛したすが、実行に時間がかかりたす。 REGEXP _CONTAINS ではなく LIKE を䜿甚するず、凊理時間が短くなりたす。 特に、 ワむルドカヌド 䞀臎など、 REGEXP _CONTAINS が提䟛する 正芏衚珟 をフルに掻甚する必芁がない堎合には凊理時間が短くなりたす。 次の REGEXP _CONTAINS 関数の䜿甚を怜蚎しおください。 SELECT dim1 FROM `dataset.table1` WHERE REGEXP_CONTAINS(dim1, '.*test.*'); このク゚リは次のように最適化できたす。 SELECT dim1 FROM `dataset.table` WHERE dim1 LIKE '%test%'; なるほど。やはり機胜の倚い関数、耇雑なパタヌンに察応できる関数よりも、単玔なこずしか出来ない関数の方が凊理は軜い速いず。蚀われおみれば圓たり前ずいえば圓たり前ではありたすが。単玔なこずしおできない関数が利甚できるケヌスであれば、そちらを䜿ったほうが良い、 正芏衚珟 による怜玢が必芁ない堎合は LIKE を䜿いたしょう、ずいうこずですね。そもそも REGEXP_CONTAINS より LIKE を䜿うこずを最初に考えるずは思うけどww REGEXP_CONTAINS の方が汎甚性が高いので垞に REGEXP_CONTAINS を䜿っおいたす、みたいな人は泚意が必芁です 詊しおみた 怜蚌方法 REGEXP_CONTAINS ず LIKE を䜿ったク゚リを実行しお比范しおいきたす。 比范する候補ずなる倀は 経過時間 ず 消費したスロット時間 の぀、ク゚リの「実行の詳现」から取埗できたす。 それぞれの意味は以䞋の通りです。 経過時間 ク゚リが開始されおから完了するたでの時間 サヌバの䜿甚状況などによる埅機時間も含たれたす 消費したスロット時間 「スロットずは、 SQL ク゚リの実行に必芁な挔算胜力の単䜍です。」「BigQueryのコン゜ヌルの」より スロットに぀いおの詳现は以䞋の Google のマニュアル「スロットに぀いお」を参照ください。 https://cloud.google.com/bigquery/docs/slots?hl=ja BigQueryスロットは、BigQueryでSQLク゚リを実行するために䜿甚される仮想CPU ずいうこずで、ざっくり蚀うずク゚リ SQL の実行に䜿甚したCPU䜿甚量です。 今回の怜蚌では 消費したスロット時間 を比范たす。 経過時間 だず Google のその時のサヌバの負荷ずいった倖郚芁因が加わるため ク゚リはそれぞれ5回ず぀実行しおその平均倀を比范したす。 ク゚リを実行するずク゚リの結果がキャッシュされるので、キャッシュを䜿甚しないように蚭定を行いたす。 なお、察象のテヌブルは玄億件のテヌブルを察象にしたした。 キャッシュクリアの方法 怜蚌䞭はキャッシュを䜿甚しおしたうず正しい蚈枬ができないので、キャッシュを䜿甚しないように蚭定を行いたす。 https://cloud.google.com/bigquery/docs/best-practices-performance-functions?hl=ja#optimize_string_comparison 怜蚌結果 消費したスロット時間時間分秒 詊行回数 REGEXP _CONTAINS LIKE 1 0:03:06 0:02:50 2 0:03:22 0:02:29 3 0:03:02 0:02:36 4 0:03:06 0:02:20 5 0:02:56 0:02:18 平均 0:03:06 0:02:31 REGEXP_CONTAINS を䜿甚した堎合の平均の「消費したスロット時間」は 3分6秒 だったのに察しお、 LIKE では 2分31秒 ず35秒短瞮、枛少率は 80.79% ず玄80%に短瞮、玄20%改善されたした。 この20%の改善をどう取るか。かなり短瞮できたず取るか、さほど倉わらないず取るか。 個人的には、思ったほど倉わらないな、ずいう印象でした。 ずいのも、 SQL ではテヌブルの結合方法JOINや、絞り蟌み条件WHERE句をチュヌニングするず実行時間が半分になったり、堎合によっおは1/10になったりするこずもざら、珍しくないため。 ただ、単玔に LIKE を䜿うだけで20%削枛されるのであれば、それは䟡倀ありたすよね。 このク゚リで怜玢の察象ずしおいるカラムの平均の文字数は33文字ず少なかったため倧きな差が出なかった、もう少し文字数が倚いカラムを察象にしたらもう少し差が出るのでは、ず考え文字数の倚いカラムを䜿っお怜蚌を実斜したした。 远加怜蚌結果時間分秒 平均文字数が758文字のカラムを䜿っお比范 消費したスロット時間時間分秒 詊行回数 REGEXP _CONTAINS LIKE 1 0:59:53 0:55:26 2 1:02:00 0:53:43 3 1:02:00 0:51:51 4 1:01:00 0:50:43 5 1:04:00 0:52:02 平均 1:01:47 0:52:45 たずカラムの平均文字数が増えたこずで「消費したスロット時間」も増加しおいたす。 平均文字数が33文字では玄3分だったのに察しお、758文字は玄60分ず玄20倍に。 圓然ですが怜玢する文字数が増えればその分ずしお凊理の時間も増えたすね。 REGEXP_CONTAINS を䜿甚した堎合の平均の「消費したスロット時間」は 1時間1分47秒 だったのに察しお、 LIKE では 52分45秒 ず9分2秒短瞮、枛少率は 85.39% ず玄85%に短瞮、15%改善されたした。 平均文字数が33文字のずきは玄80%に短瞮されたのに察しお、758文字では玄85%ず短瞮の率は枛少したした。 この蟺りの差は文字数のバラツキや怜玢する文字によっおも差が出るのかもしれたせん。 文字数の倚いカラムでは LIKE を䜿うこずでよりパフォヌマンスに差が出るず思いたしたが、倧きな違いはありたせんでした。 たずめ REGEXP_CONTAINS ず LIKE を䜿ったク゚リを実行しお比范しおみた結果、LIKEを䜿った方がク゚リのパフォヌマンスは確かに改善された その改善率は今回の怜蚌では玄20%だった 可胜であれば、 REGEXP_CONTAINS ではなく LIKE を䜿甚したしょう 本日の蚘事は以䞊になりたす。 ゚ニグモ Advent Calendar 2023 もこの蚘事で最埌になりたす。 最埌たで読んでいただきありがずうございたした。 株匏䌚瀟 ゚ニグモ すべおの求人䞀芧 hrmos.co
こんにちは 今幎7月に䞭途入瀟したした、コヌポレヌト゚ンゞニア(コヌポレヌトIT[CO-IT]チヌム) のフルセです 今幎も終盀早いですねぇ、、ずいうこずで、 Enigmo Advent Calendar 2023 の季節になりたした クリスマスむブである 24 日目 を担圓する私は入瀟゚ントリ・振り返りなど䞭心に自由に曞きたいず思いたす なお、この蚘事が少しでもコヌポレヌト゚ンゞニアに興味がある方や入瀟を怜蚎しおくださっおいる方の参考になれば幞いです。 Embed from Getty Images window.gie=window.gie||function(c){(gie.q=gie.q||[]).push(c)};gie(function(){gie.widgets.load({id:'eGD2T_vEQIpzxevVRkRvfQ',sig:'E4aHXJwgZtXDaAqpL9J550lu8QN5ONksi1IwL5kG1WY=',w:'556px',h:'311px',items:'531047383',caption: true ,tld:'com',is360: false })}); 簡単な経歎玹介 そもそもコヌポレヌト゚ンゞニアっお䜕 実際に入瀟しおみお感じたこず 入瀟しおからの仕事ずその感想 内容 感想 こんな方に向いおいるかも個人芋解 最埌に 簡単な経歎玹介 私の経歎に぀いおざっくり䞋蚘のようにたずめたした。 ① 新卒でシステムむンテグレヌタ䌁業にSEずしお入瀟 →ITの基瀎知識・技術を獲埗 and IT業界の厳しさを痛感、、倧袈裟 ② システムむンテグレヌタ䌁業を退職 →䞻にシステム盞手の業務だったので、より人ず接する仕事がしたいず考え決意 ③ 某アパレル商瀟の情シスぞ転職 →培った知識ずスキルを掻かし新たな業皮ぞチャレンゞしたかった →情シスが意倖ず性に合っおいるこずに気づくきっかけに ④ カナダぞ留孊 →ずっず挑戊したかった海倖留孊に挑戊 →語孊はもちろん人ずの出䌚いや経隓から人生にプラスになった â‘€ ゚ニグモ にコヌポレヌト゚ンゞニアずしお入瀟 →垰囜埌にご瞁があり、経隓を掻かしコヌポレヌト゚ンゞニアずしお入瀟 そもそもコヌポレヌト゚ンゞニアっお䜕 コヌポレヌト゚ンゞニアずは コヌポレヌト゚ンゞニアずは、䌁業内のIT掻甚や運甚を担圓する゚ンゞニアのこずです。 䌁業のIT環境の倉化は著しく、テレワヌクの普及などによっお クラりド サヌビスの利甚も掻発になり、 SaaS 型のID管理や統合認蚌サヌビスを利甚する䌁業が増えおきたした。そのなかでコヌポレヌト゚ンゞニアは、瀟内ITの構築・運甚をはじめずしお、瀟内業務の課題解決のための䌁画立案や郚門間の調敎たで幅広い業務を担いたす。 もっず詳しく知りたい方は、チヌムメンバヌの蚘事を読んでみおください tech.enigmo.co.jp 実際に入瀟しおみお感じたこず コヌポレヌト゚ンゞニアずしお働く以䞊、瀟員の方々ずのコミュニケヌションをかなり重芁だず考えおいたした *1 。 しかし、 ゚ニグモ はリモヌトワヌク䞭心の䌚瀟のため、Face to Face でのお話しする機䌚が少なくどのように亀流の茪を広げおいこうか少し䞍安そもそも入瀟盎埌ずいうのもあり。。に感じおいたした。 そんなずきに、2M(Monthly Meet-up) *2 に参加させおいただきたした。 そこでは色々な郚眲や圹職の方ず分け隔おなくフランクにお話しするこずができ、䞀瞬にしお䞍安が和らぎたした。 やはり、新しい環境でのスタヌトはどうしおも孀独感や䞍安が぀きものだず思いたすが、こういった亀流䌚があるず気持ちよくスタヌト ダッシュ が切れたすよねそもそも、こういった亀流䌚を定期的に行なっおいる䌁業ずいうのは少ないず思うので、これぞ ゚ニグモ の良いずころだず思っおおりたす。 それからずいうもの、毎月可胜なかぎり参加し亀流の茪を広げおおりたす無料で矎味しいお酒ずご飯が埗られるこずも理由の䞀぀なのですが笑 2Mに぀いお気になる方は、レポヌト蚘事がありたすので是非ご芧いただければず www.wantedly.com 入瀟しおからの仕事ずその感想 入瀟しおからのざっくりずした仕事内容ずその感想を曞かせおいただきたした 内容 瀟内ヘルプデスク察応 内容PCの故障や䞍具合、各 çš®IT サヌビスのトラブル察応等 察応頻床1〜2ä»¶/日 アカりント管理 内容アカりントの付䞎・削陀から数量管理・賌入 察応頻床1〜2ä»¶/週 IT機噚の管理・キッティング 内容PCやモバむルデ バむス の発泚・管理・キッティング 察応頻床10〜20ä»¶/月 瀟内ナレッゞの䜜成・敎備 内容手順曞やルヌルの新芏䜜成・ブラッシュアップ 察応頻床2回/週 䞭途入瀟者向けのオリ゚ン 内容PCのセットアップ方法の説明、瀟内ITサヌビスルヌルの共有 察応頻床1〜2回/月 瀟内䞍芁OA・IT機噚廃棄察応 内容廃棄物回収察応 察応頻床2回/幎 カオスマップ䜜成 内容瀟内で利甚䞭サヌビスを敎理ず今埌導入が必芁なサヌビスの掗い出し 察応頻床芋盎し2回/幎 感想 䞀芧にしおみるず、今幎は色々なこずをやらせおいただいたず改めお感じおいたす。 裁量を任せおいただいおいるため、日々に マルチタスク をこなしおおりたすが、 それもたた自分のタスク管理力や遂行力の向䞊に぀ながっおいるず感じたす。 個人的にやりがいがあった業務ずしおは、「瀟内䞍芁OA・IT機噚廃棄察応」です。 業者遞定から始たり、やりずり契玄締結や回収日の調敎など、瀟内ナレッゞ䜜成、各方面ずの連携など、これぞコヌポレヌト゚ンゞニアず感じるようなタスクだったため、ずおもやりがいがありたした。 それず山積みだった廃棄端末類をスッキリさせるこずができたずいう達成感が倧きかったですね笑 たたタスクずしお面癜かったものずしおは、「カオスマップ䜜成」です。 初めおカオスマップずいうものを䜜成したので、そもそもカオスマップずはからスタヌトし、他䌁業のカオスマップの調査、瀟内ITサヌビスの敎理、今埌導入が必芁なITサヌビスの掗い出しを行いたした。その埌は、カオスマップをパズルのように䜜成する倧倉な䜜業がスタヌトし...ず、ここでは曞ききれないので、詳しい䜜成プロセスなどは機䌚があればたた曞かせおいただきたいず思いたす。今回は割愛させおいただきたす。 それからずいうもの、詊行錯誀を繰り返し、レビュヌを重ねおやっずの思いで完成させるこずができたした。 結果ずしお、時間をかけお取り組んだからこそ、サヌビスに察する理解や知芋を広くできたしたし、瀟内の課題足りおいないサヌビスも炙り出すこずができたした。ずはいえ、ただただ未熟なカオスマップだず思っおいるので、これからもっず成熟させおいきたいず思いたす。楜しみ こんな方に向いおいるかも個人芋解 コヌポレヌト゚ンゞニアずしおのキャリアをスタヌトしたばかりの私ですが、 そんな私だからこそ考えるコヌポレヌト゚ンゞニアにはこんな人が向いおいるのではないかずいうのをたずめおみたした 私が思うに䞋蚘の3぀の芁玠が肝になっおくるず思いたす。 コヌポレヌト゚ンゞニアの必芁芁玠 新しい情報・技術に興味があり探求するのが奜きな方奜奇心 日々進化する IT技術 やサヌビスをいち早く自瀟ぞ展開・導入するため 最新の情報に敏感であれば、サヌビスなどがアップデヌトされたずしおも柔軟に察応するこずができるため 人ずコミュニケヌションするのが埗意・奜きな方コミュニケヌション力 業務䞊問い合わせ察応・情報共有など䜕かずコミュニケヌションが必芁になるため 問題を切り分けお解決するこずが埗意・奜きな方柔軟性 コヌポレヌト゚ンゞニアは䌁業の倚くの課題を䞎えられるので、䞀぀䞀぀解決し柔軟に察応するこずが求められるため ここで曞かせおいただいた3぀の芁玠は、かなり重芁なポむントになるず考えたす。 コヌポレヌト゚ンゞニアの業務は、IT関連の䜕でも屋のようになりがちだず思っおおりたす。 そのためタスクを挙げ出したらキリがないうえ、日々倉化したす。 そのため、柔軟性はもちろん、瀟内倖連携のためのコミュニケヌション力やITサヌビスに関する知芋を広げるための奜奇心が重芁になっおきたす。 もちろん、足りおないず感じおいる芁玠があったずしおも、業務を通じおレベルアップするこずは可胜だず思いたす私も絶賛レベルアップ䞭... ※あくたで個人の芋解なのでご了承ください。 最埌に 私もただただ未熟なので、日々進化する IT技術 ・情報に眮いおいかれないよう自己研鑜を続け぀぀、 瀟内の課題を䞀぀ず぀着実に解決し、より良い瀟内環境づくりに励みたいず思いたす 最埌たで読んでいただき、ありがずうございたした 株匏䌚瀟 ゚ニグモ すべおの求人䞀芧 hrmos.co *1 : 情シス時代に業務䞊のコミュニケヌションがかなり重芁だず理解しおいたため *2 : 毎月月初に開催される瀟内亀流䌚
こんにちは、むンフラグルヌプ Kubernetes チヌムの犏田です。 この蚘事は Enigmo Advent Calendar 2023 の22日目の蚘事です。 皆さんは Kubernetes のアップグレヌド、どうしおいたすか Kubernetes は4ヶ月に䞀回、新しいマむナヌバヌゞョンがリリヌスされ、最新の3぀のマむナヌバヌゞョンのみサポヌトされたす。 ぀たり、原則は4ヶ月に䞀床、アップグレヌドをやらなければなりたせん。最新バヌゞョンであれば最倧12ヶ月はサボれるずいう考え方もありたすが。。。 匊瀟では Kubernetes 環境ずしおEKSを䜿っおおり、 Kubernetes 本䜓のリリヌスず埮劙に間隔が違いたすが、最新を維持するために倧䜓3〜5ヶ月毎にアップグレヌド䜜業をやっおいたす。 この Kubernetes (EKS)のアップグレヌド䜜業をワヌクフロヌ化したのでそれを玹介したす。 ワヌクフロヌずは 本蚘事でいうワヌクフロヌずはワヌクフロヌ゚ンゞンを䜿っお自動化された䜜業のたずたりです。 ワヌクフロヌ゚ンゞンずは、䜜業プロセスをいい感じに管理しおくれるツヌルです。 代衚的なものずしお、 Apache Airflow , digdag , Argo Workflows などがありたす。 我々の堎合、 Argo Workflows を利甚しおいたす。 EKSアップグレヌドワヌクフロヌの抂芁 䞊図は実際のワヌクフロヌのキャプチャです。 3段階の構造(䞊から順に実斜される)になっおいお、以䞋を実斜する内容ずなっおいたす。 廃止される API を䜿っおいないかチェック EKSアドオンのアップグレヌドバヌゞョンを特定 CloudFormationテンプレヌトを曎新するPullRequestを出す。 元々、匊瀟では AWS リ゜ヌスをCloudFormationで管理する運甚になっおいたこずから、ワヌクフロヌのゎヌルがCloudFormationコヌドの修正(Pull Request䜜成)ずなっおいたす。 ワヌクフロヌの入力 䞊図の通り、ワヌクフロヌには入力パラメヌタがありたす。 ticket-id JIRAのチケットIDを指定したす。 コヌド修正時のコミットメッセヌゞやブランチ名の プレフィックス ずしお利甚されたす。 kubernetes -cluster アップグレヌドを実斜する察象の クラスタ をプルダりン圢匏で遞択したす。 eks-version Kubernetes versionをマむナヌバヌゞョンたで指定したす。䟋 1.28 ami EKSノヌドで䜿甚するAMIを指定したす。 EKSアップグレヌドワヌクフロヌの詳现 1. 廃止される API が無いかチェック Kubernetes ではマむナヌバヌゞョンの曎新に䌎っお、機胜远加や叀い機胜の削陀のために API Versionが曎新され、既存のものが廃止されるこずがありたす。 そのため、 Kubernetes アップグレヌドを実斜する前に廃止される API が無いかチェックしおいたす。 pluto ずいう OSS を䜿っお、 クラスタ 䞊にあるリ゜ヌスで廃止されるものを䜿っおいないかチェックをしおいたす。 2. EKSアドオンのアップグレヌドバヌゞョンを特定 EKSでは Kubernetes のマむナヌバヌゞョンの曎新ず䜵せお、EKSアドオンのアップグレヌドが必芁な堎合がありたす。我々の堎合、「EKSアドオンのバヌゞョンはデフォルトバヌゞョン※を指定する」ずいうポリシヌで運甚しおいたす。 ※ EKSではアドオン毎に Kubernetes のマむナヌバヌゞョンに玐づくデフォルトのバヌゞョンを公開しおいたす。 具䜓的な方法ずしおは aws コマンドで、指定した Kubernetes のマむナヌバヌゞョンに察応するEKSアドオンのデフォルトバヌゞョンを取埗しおいたす。 aws eks describe-addon-versions --addon-name ADDON_NAME --kubernetes-version K8S_NAME --query 'addons[0].addonVersions[?compatibilities[0].defaultVersion==`true`].addonVersion | [0]' 3. CloudFormationのコヌドを管理しおいる リポゞトリ に Kubernetes アップグレヌドのためのPull Requestを出す このステップに぀いおは前のステップで埗られるEKSアドオンのアップグレヌドバヌゞョンずワヌクフロヌぞの入力倀を元に、CloudFormationのコヌドを修正しお、Pull Requestを出したす。 たた、Pull Requestに人手で実斜する䜜業内容を蚘茉したす。 このステップにおける凊理はGoで実装した自前の CLI ツヌルで行っおいたす。 考慮事項 このステップを実装するにあたり、考慮したこずを玹介したす。 VPC CNIのアップグレヌド 前のステップでEKSアドオンのアップグレヌドバヌゞョンを特定しおいたすが、 VPC CNIに぀いおここで問題がありたす。 VPC CNIのアップグレヌドは䞀床に1぀のマむナヌバヌゞョンのみアップグレヌド可胜です。 䟋えば、 Kubernetes 1.27に察応する VPC CNIのデフォルトバヌゞョンが v1.12.6-eksbuild.2 で Kubernetes 1.28に察応する VPC CNIのデフォルトバヌゞョンが v1.14.1-eksbuild.1 の堎合、予め VPC CNIのバヌゞョンをv1.13系にアップグレヌドする必芁がありたす。 実際の実装ずしおは VPC CNIのアップグレヌドバヌゞョンのマむナヌバヌゞョンが元のバヌゞョンより2぀以䞊離れおいる堎合は、本ワヌクフロヌを実斜する前に VPC CNIのマむナヌバヌゞョンをアップグレヌドするように促すメッセヌゞを出しおワヌクフロヌはそこで倱敗するようにしおいたす。 手順曞 Kubernetes アップグレヌドの実斜自䜓の手順ずしおはCloudFormationの実行コマンドだけですが、実際の䜜業手順はもう少し耇雑です。 我々の堎合はアップグレヌドの実斜コマンドに加えお以䞋を盛り蟌む必芁がありたした。 䜜業前 䜜業通知の開始アナりンス 䜜業時の監芖アラヌトのサむレント蚭定 䜜業埌 アップグレヌドが正しく完了したかの確認 䜜業時の監芖アラヌトのサむレント蚭定解陀 䜜業通知の終了アナりンス yaml をGoで線集する際の副䜜甚 CloudFormationのテンプレヌトは yaml ですが、これをGoで曞き換えるず発生する副䜜甚がありたす。 それはGoで yaml を扱うために yaml ファむルを ゚ンコヌド しお、プログラム䞊で䜕らかの凊理をしお、再床 yaml ファむルに戻しおやるず空行やコメント等が消倱しおしたうずいうものです。 yaml ずしおは等䟡なのだからずいう理由で切り捚おおしたえばそれたでですが、コメントや空行はリヌダビリティの芳点で有甚なものも倚いので、これは維持するようにしたいです。 たず、コメントの維持に぀いおは yaml.v3 を䜿うこずで解決できたす。 具䜓的には以䞋のように yaml 䞭にある曞き換えたいプロパティをpathで指定しお、それをnewValueで曎新するようにしおいたす。 func (e *yamlEditor) updateYamlProperty(node *yaml.Node, path [] string , newValue string ) error { if len (path) == 0 { return fmt.Errorf( "invalid path" ) } for i := 0 ; i < len (node.Content); i += 2 { keyNode := node.Content[i] valueNode := node.Content[i+ 1 ] if keyNode.Value == path[ 0 ] { if len (path) == 1 { valueNode.Value = newValue return nil } else if valueNode.Kind == yaml.MappingNode { return e.updateYamlProperty(valueNode, path[ 1 :], newValue) } } } return fmt.Errorf( "invalid path" ) } 空行に぀いおはdiffコマンドのオプションで空行を無芖する差分のdiffを生成しお、それをpatchコマンドで元のファむルに修正ずしお適甚するようにしおいたす。 ## 元々存圚するcloudformation template target.yaml ## プログラムによっお曞き換えが行われたcloudformation template。空行はなくなっおしたっおいる。 target.changed.yaml diff -U 0 -w -b -B target.yaml target.changed.yaml > target.diff patch -i target.diff target.yaml 参考: https://github.com/mikefarah/yq/issues/515#issuecomment-830380295 たずめ 今回はArgo Workflowsを䜿った Kubernetes (EKS)のアップグレヌドに぀いお玹介させおいただきたした。 玹介したワヌクフロヌはKubernetes1.27ずKubernetes1.28のリリヌスの間で䜜成したもので、Kubernetes1.28のアップグレヌドはこのワヌクフロヌを䜿っおアップグレヌドしたした。 これのおかげで面倒だったアップグレヌド䜜業を倧分楜にするこずができたした。 明日の蚘事の担圓は早野さんです。お楜しみに。 株匏䌚瀟 ゚ニグモ すべおの求人䞀芧 hrmos.co
こんにちは。゚ンゞニアの竹田です。 BUYMA の怜玢システムやMLOps基盀の開発・運甚を担圓しおおりたす。 こちらは Enigmo Advent Calendar 2023 の21日目の蚘事です 🎄 匊瀟では2021幎頃よりMLOps基盀を Google Cloud PlatformのAI Platform Pipelines䞊に構築しお開発・運甚を行っおいたす。 この床、Vertex AI Pipelinesぞの移行を党面的に進めるこずになりたしたので、ご玹介も兌ねお蚘事にしたいず思いたす。 背景 2024/07にAI Platform Pipelinesが非掚奚になるずいう通知を受けたこずがきっかけです。 AI Platform Pipelines deprecations  |  Google Cloud 非掚奚の通知が移行を開始するトリガヌではあったものの、かねおからGKE クラスタ の運甚をどうにかできないかなず考えおいたした。 Vertex AI Pipelinesぞの移行によりフルマネヌゞド化できるのは倧きなモチベヌションずなっおいたす。 移行における課題 この機䌚にKubeflow Pipelines SDK (以䞋、kfp) v1からv2ぞのアップグレヌドを進めおいたす。 移行ドキュメント も提䟛されおいるため、それほど苊劎はしないものず考えおおりたした。 が、結果ずしおこの遞択が倚くの苊劎を抱えるこずになっおしたいたした 😢 実際に kfp v2 利甚しおみお、良かった点・苊劎しおいる点を亀えおご玹介いたしたす。 ※䞋䜍互換で動䜜させるこずも可胜でしたが、kfp v1での機胜拡匵は行われない、そのうち曞き換えが必芁になる、ずいう点を考慮しおkfp v2ぞの曞き換えに螏み切りたした。 kfp v1からv2ぞ kfpは、 kubernetes 䞊で 機械孊習 パむプラむンを動䜜させるためのツヌルキットです。 コヌドベヌスは Python です。 An introduction to Kubeflow パむプラむンを䜜成しおVertex AI Pipelines䞊で動䜜させるず、動䜜フロヌが芖芚的に分かりやすく衚珟されたす。 Python で蚘述したコヌドを コンパむル しお利甚する性質䞊、kfp v1の頃からかなりクセが匷いなずは感じおいたした。 実際に利甚しおみた䞊での良い点、苊劎しおいる点を列挙し、所感を曞いおいこうず思いたす。 kfp v2の利甚バヌゞョン # pip list | grep kfp kfp 2.3.0 kfp-pipeline-spec 0.2.2 kfp-server-api 2.0.3 kfp v2の良い点 入出力に利甚する Input[xxx] / Output[xxx] が䟿利 ParallelFor による䞊列凊理の結果を Collected で受け取れるようになった @dsl.component や set_accelerator_type が盎感的 入出力に利甚する Input[xxx] / Output[xxx] が䟿利 kfp v2では入出力に利甚するオブゞェクトがこの圢(基本的に Input[Artifact] / Output[Artifact] の利甚)にほが統䞀されおおり、GCS䞊のパスを意識せず利甚できるため非垞に䟿利です。 https://www.kubeflow.org/docs/components/pipelines/v2/data-types/artifacts/ ParallelFor による䞊列凊理の結果を Collected で受け取れるようになった kfp v1でも ParallelFor は利甚できたしたが、fan-in(耇数の入力を䞀぀にたずめるこず)が厄介でした。 kfp v2では最近になっお Collected が利甚可胜ずなり、 ParallelFor の埌に呌び出すこずで結果をリスト圢匏でfan-inできるため、コヌドの可読性も飛躍的に向䞊したす。 @dsl.component や set_accelerator_type が盎感的 個人的な奜みの郚類かもしれたせんが、kfp v2は定矩呚りが盎感的になった印象がありたす。 https://www.kubeflow.org/docs/components/pipelines/v2/migration/#create_component_from_func-and-func_to_container_op-support kfp v2で苊劎しおいる点 倉数展開がおかしくなるこずがある 型指定の厳密化により、䜕を枡せばよいのか分からなくなるこずがある 倉数展開がおかしくなるこずがある kfp v2ぞの移行で最も困っおいる点です。以䞋のようなissueも挙がっおいたす。 https://github.com/kubeflow/pipelines/issues/10261 倉数内に䜕らかの文字列や数倀を入れおいるはずが、実際に利甚する堎合に以䞋のような展開がされおしたいたす。 {{channel:task=;name=g;type=String;}} コンポヌネント の出力結果をうたく展開できない堎合は以䞋のような内容です。 {{channel:task=term-calc;name=list_date;type=typing.List[str];}} 機械孊習 の初回実行プロセスの倚くがBigQueryからのデヌタ取埗を行っおおり、デヌタ取埗期間や特城量を倉数で管理しおいるため、既存のパむプラむンコヌドでは Python のformatメ゜ッドによる曞匏倉換を倚甚しおいたす。 この曞匏倉換のほずんどが正垞に動かなくなっおしたい、詊行錯誀を繰り返すこずになっおしたいたした。 以䞋、期埅した倉数展開ずならずに゚ラヌずなるパタヌンの䞀郚です。 パむプラむン匕数や コンポヌネント の返华結果をdictに加えお コンポヌネント に枡した堎合 @ dsl.component def convert_str (tmpl: str , value: dict , output: Output[Artifact]): with open (output.path, "w" ) as f: f.write(tmpl.format(value)) @ dsl.pipeline (name= "test" , description= "test prediction" ) def test_pipeline (table_name: str = "sample" ): value = { "table_name" : table_name } sql = "SELECT * FROM {0[table_name]}" convert_str_op = convert_str(tmpl=sql, value=value) コンパむル 時の゚ラヌ内容 ValueError: Value must be one of the following types: str, int, float, bool, dict, and list. Got: "{{channel:task=;name=table_name;type=String;}}" of type "<class 'kfp.dsl.pipeline_channel.PipelineParameterChannel'>". パむプラむン匕数をパむプラむン本䜓で利甚しようずした堎合 @ dsl.pipeline (name= "test" , description= "test prediction" ) def test_pipeline (periods: str = "1m" ): target_file = f "periods_{periods}.yaml" with open (target_file, mode= "r" ) as f: periods_conf = yaml.safe_load(f) コンパむル 時の゚ラヌ内容 FileNotFoundError: [Errno 2] No such file or directory: 'periods_{{channel:task=;name=periods;type=String;}}.yaml' 型指定の厳密化により、䜕を枡せばよいのか分からなくなるこずがある パむプラむン匕数を利甚しようずしお以䞋のような゚ラヌが出たり TypeError: PipelineParameterChannel is not a parameter type. 特定 コンポヌネント にinputを枡した堎合に以䞋のような゚ラヌが出たり ValueError: Constant argument inputs must be one of type ['String', 'Integer', 'Float', 'Boolean', 'List', 'Dict'] Got: <kfp.dsl.pipeline_task.PipelineTask object at 0x7f8a03f89880> of type <class 'kfp.dsl.pipeline_task.PipelineTask'>. ずいったこずが割ず発生したす。 自分ずしおは正しい型での匕き枡し、および参照をしおいる぀もりのため、どう察凊しおよいか分からなくなるこずが倚いです。 事前にキャストするこずで正垞に動䜜するこずもあれば、そもそもデヌタ型の扱いを芋盎す必芁があったりしたす。 所感 䞊述の苊劎しおいる点での匕っ掛かりが倚いのが難点で、残念ながら䜿いやすさは感じられおいたせん。 ですが、䞀床圢ずしおできおしたえばテンプレヌト化できるず思われるため詊行錯誀しながら進めおいる、ずいうのが珟状です。 コンテナむメヌゞ化しおいる コンポヌネント 内郚の挙動はほが倉曎なしで動䜜しおおり、ほずんどが「倉数展開がおかしくなる」郚分の障壁により思うように進捗しおいないずいった状態です。 具䜓的にこうすれば良い、ずいったアプロヌチが芋぀けられたら䜕かしらの圢で蚘事にできればず考えおおりたす。 匕き続き、Vertex AI Pipelines移行による 機械孊習 基盀のフルマネヌゞド化を目指しお邁進しおいく所存です 💪 おわりに 明日の蚘事の担圓はむンフラチヌムの犏田さんです。EKS呚りのお話です。お楜しみに 株匏䌚瀟 ゚ニグモ すべおの求人䞀芧 hrmos.co
こんにちは、サヌビス゚ンゞニアリング本郚の平井です。 こちらは Enigmo Advent Calendar 2023 の 20日 目の蚘事です。 私は、゚ンゞニア郚門で取り組んでいる開発生産性分析に぀いお玹介したす。 開発生産性分析を詊みた経緯 珟圚、 ゚ニグモ では開発組織䜓制の倉曎、メンバヌ増匷など様々な組織匷化を目指した動きが加速しおきおいたす。ただ、そのような斜策が開発組織のパフォヌマンスを向䞊させおいるのか 定量 的な指暙で枬るこずができたせんでした。 たた、開発組織ずしおは、開発を通しお䞀定のスピヌドでナヌザヌに十分な䟡倀を届ける責任を負っおいるものの、開発スピヌドを枬る良い方法がありたせんでした。 このように組織パフォヌマンス向䞊斜策の結果を確認するため、開発組織ずしおの開発スピヌドを図るために開発生産性分析の取り組みが始たりたした。 たた、この取り組みは開発生産性に興味がある有志のメンバヌが集たり進めおいきたした。 指暙遞定 分析する指暙ずしおは、 Google が提案しおいる Four Keys を参考にしたした。 Four Keysを参考にした理由は以䞋になりたす。 開発スピヌドを枬る指暙が含たれおいる。 自分達で蚈枬、分析の基盀を敎えられそう。 䞀般的な指暙である。 そしお、 指暙の䞭で速床に関わる指暙であり、蚈枬が容易そうな 倉曎のリヌドタむム ず デプロむ頻床 を蚈枬するこずが決たりたした。 デプロむ頻床に関しおは、営業日や開発メンバヌの増枛による圱響を少なくするために、 @hiroki_daichiさんが玹介されおいた d/d/d ずいうやり方で 1日あたりの1開発者あたりのデプロむ回数を蚈算するこずにしたした。 たた、珟圚 BUYMA は基幹システムず耇数のマむクロサヌビスで構成されおいたすが、どの開発チヌムも修正するこずが倚い基幹システムにおけるこれらの指暙を蚈枬しおいくこずになりたした。 各指暙の定矩 前提ずしお、 BUYMA の基幹システムはGitlabを ホスティング サヌビスずしお利甚しおいたす。 本番環境ぞのデプロむは内補アプリケヌションを通しお行われ、開発者が各々デプロむ䟝頌を䜜成したす。 本番環境ぞのデプロむプロセスは1日3回実行されるため、各開発者は䜜成した䟝頌をそのどれかのプロセスに乗せお本番化したす。 Four Keysを参考にし぀぀、このような BUYMA の特城を考慮しお各指暙の定矩をチヌムで盞談しお決めたした。 その䞊でリヌドタむムは以䞋の定矩で蚈算しおいたす。 MR内の最初のコミットからそのMRが本番環境に反映されるたでの時間 各開発者によっお開発手法は異なるため最初のコミットタむミングが埮劙にずれる可胜性はありたすが、 開発 -> レビュヌ -> QA -> デプロむ ずいう䞀連の 開発プロセス を蚈枬できるためこのような定矩にしたした。 d/d/dに関しおは、 デプロむ回数/営業日/開発者数 ずなっおいお、それぞれ以䞋のような定矩になっおいたす。 デプロむ回数: 本番化された本番化䟝頌の数 BUYMA の本番化の特城ずしお、1デプロむに耇数の修正が含たれるためその䞀぀䞀぀の修正を個別に数えたかったためこのような定矩にしたした。 営業日: 土日祝日を抜いた平日 営業日は特に䞀般的に䜿われおいるものです。 開発者数: マヌゞされたMRに参加したナニヌクGitLabナヌザヌ数 ゚ンゞニアリング郚門に属しおいおも「基幹システムに関わっおいない人は含めたくない」、「過去の特定期間の開発者数も出したい」など考慮する点が倚く難しかったのですが、「MRに関わった人数は開発に関わる人数ず等しいだろう」ずいう考えのもずチヌムで盞談しおこのような定矩になりたした。 デヌタ収集、可芖化の仕組み 次に、指暙の蚈枬ず可芖化の仕組みに぀いお説明したす。 Airflowにワヌクフロヌを構築しお、MRに関わる情報をGitLabの API から収集しBigQueryに栌玍しおいたす。 デプロむに関する情報は内補本番化アプリケヌションが利甚しおいるデヌタベヌスに氞続化されおいるため、BigQueryに連携しおGitLabの情報ずJOINできるようにしたした。 可芖化に関しおは、BigQuery䞊のレコヌドを SQL で加工しおLookerの ダッシュ ボヌドを䜿うこずで実珟しおいたす。 開発性生産性分析システム構成図 リヌドタむムに必芁なデヌタ収集 リヌドタむムを蚈枬するために以䞋のGitLab API を利甚しおいたす。 基本的には API のレスポンスから日次の差分デヌタを取埗しお、そのたたBigQueryのテヌブルに保存しおいたす。 List all projects API GitLabのプロゞェクトのマスタヌデヌタを収集するために利甚しおいたす。 収集したデヌタはLookerで可芖化する際にプロゞェクト名を衚瀺するなどに利甚しおいたす。 List group merge requests API MRデヌタを収集するために利甚しおいたす。 マヌゞ枈みMRの情報のみ必芁なので API パラメヌタを䜿っおマヌゞ枈みMRの情報のみ収集しおいたす。 Get single merge request commits API MRに玐づくコミットの情報を収集するために利甚しおいたす。 ここで取埗したデヌタを利甚しおMRに玐づく最初のコミットを特定しお、リヌドタむムを蚈算したす。 d/d/d に必芁なデヌタ収集 リヌドタむムを蚈枬するために以䞋のGitLab API を利甚しおいたす。 こちらも日次の差分デヌタをそのたたBigQueryのテヌブルに保存しおいたす。 List a Project’s visible events API GitLabのむベント情報を収集するために利甚しおいたす。 マヌゞされたMRに参加したナニヌクGitLabナヌザヌ数を蚈算する際にここで収集したデヌタを利甚しおいたす。 可芖化に぀いお 先述したように可芖化にはLookerの ダッシュ ボヌドを利甚しおいたす。 LookML で SQL を組み立おお指暙を蚈算しおいたす。 ゚ニグモ では BUYMA をメむンの機胜で分割しお開発チヌムを組織しおいお、それらを ドメむンチヌム ず呌んでいたす。指暙の監芖や分析は各 ドメむン チヌムにやっおもらっおいるため各 ドメむン チヌム毎に ダッシュ ボヌドを䜜成しおいたす。 可芖化したあるチヌムのリヌドタむム 運甚に぀いお 指暙の監芖や分析は、现かいやり方を指定せずに ドメむン チヌムに䟝頌しおいたす。 䟋えば私が所属しおいるチヌムでは毎週の振り返り時にリヌドタむムずd/d/dを確認しお、䜕か問題があれば改善案を考えるずいう運甚をしおいたす。 たた、開発生産性指暙の蚈枬にあたり、 開発者にMRぞの ラベル 付䞎を䟝頌したした。MRに付䞎されたラベル情報をもずに ドメむン チヌム毎のリヌドタむムを蚈枬しおいたす。 今埌の課題 今埌の課題ずしおは以䞋になりたす。 BUYMA 基幹システム以倖でただデヌタ収集できおいないマむクロサヌビスがあるため正確に開発組織党䜓の生産性を枬れおいない。 芁件定矩、仕様決定などの ディスカバリヌ フェヌズにかかっおいる時間を図れおいない。 倉曎障害率、サヌビス埩元時間など安定性の指暙を図れおない。 珟状だずリヌドタむムやd/d/dが向䞊した際に、それが障害発生による现かい修正が増えたのが原因なのかわからない。 終わりに 今回ぱンゞニア郚門で取り組んでいる開発生産性分析に぀いお玹介したした。自分自身、デヌタ収集凊理の開発、可芖化を担圓し、自分達の開発掻動が 定量 デヌタずしお衚珟される面癜さを感じたした。 最埌たでご芧頂きありがずうございたした。明日の蚘事の担圓は怜玢゚ンゞニアの竹田さんです。お楜しみに。 珟圚、 ゚ニグモ ではこのような開発生産性に関わる取り組みを行っおいたす。 興味のある方は以䞋の求人をご参照ください!! 株匏䌚瀟 ゚ニグモ すべおの求人䞀芧 hrmos.co
こんにちは、゚ンゞニアの川本です。 䞻に BUYMA の決枈・配送を担圓しおいるチヌムでバック゚ンドの開発をしおいたす。 この蚘事は Enigmo Advent Calendar 2023 の 20 日目の蚘事です。 個人開発でPlanetScaleずいう MySQL 互換のサヌバヌレスデヌタベヌスを䜿甚しおいるのですが、特筆すべき仕様ずしお倖郚キヌのサポヌトがありたせん。 planetscale.com 倖郚キヌ制玄はDBレベルで匷い敎合性を担保できる䟿利な手段ですが、PlanetScaleではその機胜が利甚できないので、アプリケヌションレベルで敎合性を担保する必芁がありたす。 MySQL の倖郚キヌのオプションにはいく぀か皮類がありたすが、これらが䜿えない堎合にアプリケヌション偎ではどのように担保すればよいのでしょうか 今回は、 Rails を䟋にしおアプリケヌション偎で MySQL の倖郚キヌに盞圓する機胜をどのように担保できるのかを怜蚌しおみようず思いたす。 䜙談PlanetScaleに぀いお 最近PlanetScaleはベヌタ版で倖郚キヌをサポヌトし始めたしたが、残念ながら Hobbyプラン ではただサポヌトされおおりたせん。 PlanetScaleの基盀である Vitess はOnline DDL の機胜を提䟛しおおり、それが原因で倖郚キヌのサポヌトが長らく難しかったようです。 以䞋のドキュメントやブログには、PlanetScaleが倖郚キヌをサポヌトできるようになるたでの背景や課題、そしおその克服方法に぀いおの詳现な情報が蚘茉されおいたす。興味がある方はぜひ読んでみおください。 倖郚キヌのサポヌトが難しかった理由 Operating without foreign key constraints Online DDL: why FOREIGN KEYs are not supported 倖郚キヌをサポヌトするための取り組み Foreign key constraints beta The challenges of supporting foreign key constraints 芪子関係のテヌブルを䜜成 たず芪子関係にある、Parent, Childテヌブルを䜜成しおサンプルデヌタを入れる。 -- テヌブル䜜成 mysql> CREATE TABLE parent ( -> id INT NOT NULL , -> PRIMARY KEY (id) -> ) ENGINE=INNODB; mysql> CREATE TABLE child ( -> id INT NOT NULL , -> parent_id INT NOT NULL , -> PRIMARY KEY (id) -> ) ENGINE=INNODB; -- テストデヌタをむンサヌト mysql> INSERT INTO parent (id) VALUES ( 1 ), ( 2 ); mysql> INSERT INTO child (id, parent_id) VALUES ( 1 , 1 ), ( 2 , 1 ), ( 3 , 2 ); -- デヌタ構造の確認 mysql> SELECT * FROM parent p JOIN child c ON p.id = c.parent_id; + ----+----+-----------+ | id | id | parent_id | + ----+----+-----------+ | 1 | 1 | 1 | | 1 | 2 | 1 | | 2 | 3 | 2 | + ----+----+-----------+ MySQL の倖郚キヌ制玄 MySQL では以䞋4぀の ON DELETE 副次句で指定できる参照アクションがありたす。 ON UPDATE 副次句もありたすが、今回は ON DELETE に限定するこずにしたす。 dev.mysql.com ON DELETE CASCADE 芪テヌブルから行を削陀し、子テヌブル内の䞀臎する行を自動的に削陀する。 -- ON DELETE CASCADEを指定しお倖郚キヌ制玄を蚭定 mysql> ALTER TABLE child -> ADD CONSTRAINT fk_parent -> FOREIGN KEY (parent_id) -> REFERENCES parent(id) -> ON DELETE CASCADE; -- parentのid = 1のレコヌドを削陀する mysql> DELETE FROM parent WHERE id = 1 ; -- parent_id = 1のchildのレコヌドも削陀されおいるこずを確認できる mysql> SELECT * FROM child; + ----+-----------+ | id | parent_id | + ----+-----------+ | 3 | 2 | + ----+-----------+ ON DELETE SET NULL 芪テヌブルから行を削陀し、子テヌブルの倖郚キヌカラムを NULL にする。 ※ この蚭定をするずきは、 child の parent_id は NOT NULL にしない。 -- ON DELETE SET NULLを指定しお倖郚キヌ制玄を蚭定 mysql> ALTER TABLE child -> ADD CONSTRAINT fk_parent -> FOREIGN KEY (parent_id) -> REFERENCES parent(id) -> ON DELETE SET NULL ; -- parentのid = 1のレコヌドを削陀する mysql> DELETE FROM parent WHERE id = 1 ; -- parent_id = 1のchildのレコヌドのparent_idはNULLになっおいるこずを確認 mysql> SELECT * FROM child; + ----+-----------+ | id | parent_id | + ----+-----------+ | 1 | NULL | | 2 | NULL | | 3 | 2 | + ----+-----------+ ON DELETE RESTRICT or ON DELETE NO ACTION or 指定なし 芪テヌブルに察する削陀操䜜は拒吊されたす。たた、 ON DELETE RESTRICT or ON DELETE NO ACTION or ON DELETE 指定なし は同じ挙動になりたす。以䞋の䟋では ON DELETE 指定なし で䟋を瀺したす。 -- ON DELETE指定なしで倖郚キヌ制玄を蚭定 mysql> ALTER TABLE child -> ADD CONSTRAINT fk_parent -> FOREIGN KEY (parent_id) -> REFERENCES parent(id) -- parentのid = 1のレコヌドを削陀する -- childにはparent_id = 1のレコヌドがあるので削陀拒吊される mysql> DELETE FROM parent WHERE id = 1 ; ERROR 1451 ( 23000 ): Cannot delete or update a parent row : a foreign key constraint fails (`myapp_development`.`child`, CONSTRAINT `fk_parent` FOREIGN KEY (`parent_id`) REFERENCES `parent` (`id`)) -- parentもchildも削陀されおいない mysql> SELECT * FROM parent p JOIN child c ON p.id = c.parent_id; + ----+----+-----------+ | id | id | parent_id | + ----+----+-----------+ | 1 | 1 | 1 | | 1 | 2 | 1 | | 2 | 3 | 2 | + ----+----+-----------+ Rails 偎の実装方法 Rails では、Active Recordの dependentオプション を䜿甚しお、 MySQL の倖郚キヌ制玄に盞圓する機胜を実珟できたす。 dependentオプション は芪レコヌドに察しお ActiveRecord::Persistence#destroy が実行されたずきに、玐ずいおいる子レコヌドに察しお実行されるメ゜ッドのこずです。 ON DELETE CASCADE ON DELETE CASCADE に盞圓するこずは、 delete_all , destory , destory_async のいずれかで実珟するこずができたす。これら3぀は党お最終的に実珟できるこずは同じですが、それぞれで以䞋のように挙動の違いがありたす。 delete_all delete_allは、parentに関連付けられたchildが䞀括で1぀の SQL で削陀したす。 たた、childに察しお ActiveRecord::Persistence#delete が実行されるので、 ActiveRecord::Persistence#destroy 実行時に䜜甚するbefore_destroyやafter_destroyずいったコヌルバックや孫クラスのdependentオプションが実行されたせん。 そのため、単玔に削陀 SQL を実行するだけなので関連するchildが倚い堎合にはdestroyよりパフォヌマンスが向䞊する可胜性があリたす。 class Parent < ApplicationRecord self .table_name = ' parent ' has_many :child , dependent : :delete_all end irb(main): 002 > parent = Parent .find( 1 ) irb(main): 054 > parent.destroy TRANSACTION ( 0 .7ms) BEGIN Child Delete All ( 1 .2ms) DELETE FROM ` child ` WHERE ` child ` . ` parent_id ` = 1 Parent Destroy ( 0 .7ms) DELETE FROM ` parent ` WHERE ` parent ` . ` id ` = 1 TRANSACTION ( 1 .9ms) COMMIT => #<Parent:0x0000ffffaf032050 id: 1> destroy destroyは、parentに玐づくchildを党お取埗しお1件ず぀削陀したす。 ActiveRecord::Persistence#destroy が実行されるため、before_destroyやafter_destroyなどのコヌルバックも実行され、孫クラスにあるdependentオプションも実行されたす。 そのため、関連するchildが倚いず発行される SQL も増え、コヌルバックの実行や孫クラスのdependentオプションの実行が倚くなり、delete_allよりもパフォヌマンスが䜎䞋する可胜性がありたす。 class Parent < ApplicationRecord self .table_name = ' parent ' has_many :child , dependent : :destroy end irb(main): 002 > parent = Parent .find( 1 ) irb(main): 062 > parent.destroy TRANSACTION ( 0 .3ms) BEGIN Child Load ( 1 .0ms) SELECT ` child ` .* FROM ` child ` WHERE ` child ` . ` parent_id ` = 1 Child Destroy ( 1 .3ms) DELETE FROM ` child ` WHERE ` child ` . ` id ` = 1 Child Destroy ( 1 .1ms) DELETE FROM ` child ` WHERE ` child ` . ` id ` = 2 Parent Destroy ( 0 .9ms) DELETE FROM ` parent ` WHERE ` parent ` . ` id ` = 1 TRANSACTION ( 1 .2ms) COMMIT => #<Parent:0x0000ffffafdad888 id: 1> destroy_async destroy_asyncは、parentに関連する党おのchildを非同期で1件ず぀削陀したす。 玐づくchildが非垞に倚く、即時での削陀を求められない堎合に有効です。玐づくchildが倚いず凊理が最悪の堎合は タむムアりト する可胜性もありたす。そのような堎合、たずparentを削陀しおクラむアントにレスポンスを速やかに返し、残りの玐づくchildは非同期で削陀するこずで問題を解決できたす。 class Parent < ApplicationRecord self .table_name = ' parent ' has_many :child , dependent : :destroy_async end irb(main): 002 > parent = Parent .find( 1 ) irb(main): 070 > parent.destroy TRANSACTION ( 0 .3ms) BEGIN Child Load ( 0 .8ms) SELECT ` child ` .* FROM ` child ` WHERE ` child ` . ` parent_id ` = 1 Parent Destroy ( 0 .8ms) DELETE FROM ` parent ` WHERE ` parent ` . ` id ` = 1 TRANSACTION ( 2 .0ms) COMMIT Enqueued ActiveRecord ::DestroyAssociationAsyncJob ( Job ID : 63fc4528-934a-405c- 9311 -7bee9fb706b1) to Async(default) with arguments : { :owner_model_name => " Parent " , :owner_id => 1 , :association_class => " Child " , :association_ids =>[ 1 , 2 ], :association_primary_key_column => :id , :ensuring_owner_was_method => nil } => #<Parent:0x0000ffffae761700 id: 1> irb(main): 071 > Performing ActiveRecord ::DestroyAssociationAsyncJob ( Job ID : 63fc4528-934a-405c- 9311 -7bee9fb706b1) from Async(default) enqueued at 2023 - 12 -16T09: 16 :43Z with arguments : { :owner_model_name => " Parent " , :owner_id => 1 , :association_class => " Child " , :association_ids =>[ 1 , 2 ], :association_primary_key_column => :id , :ensuring_owner_was_method => nil } Parent Load ( 3 .0ms) SELECT ` parent ` .* FROM ` parent ` WHERE ` parent ` . ` id ` = 1 LIMIT 1 Child Load ( 5 .1ms) SELECT ` child ` .* FROM ` child ` WHERE ` child ` . ` id ` IN ( 1 , 2 ) ORDER BY ` child ` . ` id ` ASC LIMIT 1000 TRANSACTION ( 0 .3ms) BEGIN Child Destroy ( 0 .9ms) DELETE FROM ` child ` WHERE ` child ` . ` id ` = 1 TRANSACTION ( 2 .0ms) COMMIT TRANSACTION ( 0 .3ms) BEGIN Child Destroy ( 1 .0ms) DELETE FROM ` child ` WHERE ` child ` . ` id ` = 2 TRANSACTION ( 1 .7ms) COMMIT Performed ActiveRecord ::DestroyAssociationAsyncJob ( Job ID : 63fc4528-934a-405c- 9311 -7bee9fb706b1) from Async(default) in 63 .81ms ON DELETE SET NULL nullify ON DELETE SET NULL に盞圓するこずは nullify で実珟できたす。 parentに玐づくchildのparent_idをnullに曎新しお、parentを削陀しおいたす。 class Parent < ApplicationRecord self .table_name = ' parent ' has_many :child , dependent : :nullify end irb(main):088> parent = Parent .find( 1 ) irb(main):090> parent.destroy TRANSACTION ( 0 .3ms) BEGIN Child Update All ( 5 .0ms) UPDATE ` child ` SET ` child ` . ` parent_id ` = NULL WHERE ` child ` . ` parent_id ` = 1 Parent Destroy ( 3 .3ms) DELETE FROM ` parent ` WHERE ` parent ` . ` id ` = 1 TRANSACTION ( 1 .3ms) COMMIT => #<Parent:0x0000ffffae66f9a0 id: 1> ON DELETE RESTRICT or ON DELETE NO ACTION or 指定なし ON DELETE RESTRICT たたは ON DELETE NO ACTION に盞圓するこずは、 restrict_with_exception たたは restrict_with_error のいずれかで実珟するこずができたす。これら2぀は党お最終的に実珟できるこずは同じですが、それぞれで以䞋のように挙動の違いがありたす。 restrict_with_exception parentに玐づくchildが存圚するこずを確認しお、凊理を ロヌルバック しお ActiveRecord::DeleteRestrictionError ずいう䟋倖を発生させたす。 class Parent < ApplicationRecord self .table_name = ' parent ' has_many :child , dependent : :restrict_with_exception end irb(main):088> parent = Parent .find( 1 ) irb(main):094> parent.destroy TRANSACTION ( 0 .6ms) BEGIN Child Exists ? ( 1 .0ms) SELECT 1 AS one FROM ` child ` WHERE ` child ` . ` parent_id ` = 1 LIMIT 1 TRANSACTION ( 0 .5ms) ROLLBACK / usr / local/bundle/gems/activerecord- 7.0 . 8 /lib/active_record/associations/has_many_association.rb: 16:in ` handle_dependency': Cannot delete record because of dependent child (ActiveRecord::DeleteRestrictionError) restrict_with_error parentに玐づくchildが存圚するこずを確認しお、凊理を ロヌルバック しおfalseを返したす。 class Parent < ApplicationRecord self .table_name = ' parent ' has_many :child , dependent : :restrict_with_error end irb(main):088> parent = Parent .find( 1 ) irb(main):098> parent.destroy TRANSACTION ( 0 .5ms) BEGIN Child Exists ? ( 0 .6ms) SELECT 1 AS one FROM ` child ` WHERE ` child ` . ` parent_id ` = 1 LIMIT 1 TRANSACTION ( 0 .4ms) ROLLBACK => false 最埌に ここたでの玹介で、 Rails アプリケヌションで MySQL の倖郚キヌ制玄の参照アクションを実珟する手段が理解できたした。 ただし、デヌタ敎合性が担保されるのは、倖郚キヌ制玄に準拠したアプリケヌションからの実行時に限られたす。もし、同じDBを参照するが倖郚キヌ制玄に準拠しおいないアプリケヌションが存圚する堎合、どのような圱響が生じたすでしょうか 倖郚キヌ制玄のないアプリケヌションからの実行により、デヌタ敎合性が維持されなくなる可胜性がありたす。このような事態を避けるためには、できるだけDBレベルで敎合性を担保する方が望たしいです。 Planet Scaleのような倖郚キヌ制玄をサポヌトしおいないDBでは、今回玹介したようなアプリケヌションの実装が有効であるかもしれたせん。しかし、倖郚キヌ制玄がサポヌトされおいるDBでは、DBレベルでの制埡が安党であるず蚀えるでしょう。 明日の蚘事担圓はデヌタ゚ンゞニアリングチヌムですお楜しみに 株匏䌚瀟 ゚ニグモ すべおの求人䞀芧 hrmos.co
.blog-figure{ width: 70%; margin-left: auto; margin-right: auto; display: block; } .blog-footer{ background: rgb(193,54,47); } .footer-icon{ width: 2rem; display: inline-block; } .figure-caption{ text-align: center; color: goldenrod; font-size: 0.8rem; } .figure-source{ opacity: 0.7; font-size: 0.6rem; color: gray; } .greetings { font-size: 0.8rem; padding: 2rem 1rem; text-align: center; display: block; margin-top: 2rem; background: rgb(250,248,236) -webkit-gradient(linear, 100% 0, 0 0, from(#acacac), color-stop(0.5, #ffffff), to(#acacac)); background-position: -4rem top; /*50px*/ background-repeat: no-repeat; -webkit-background-clip: text; -webkit-text-fill-color: transparent; -webkit-animation-name: greetings; -webkit-animation-duration: 2.2s; -webkit-animation-iteration-count: infinite; -webkit-background-size: 4rem 100%; /*50px*/ } @-webkit-keyframes greetings { 0% { background-position: -4rem top; } 70% { background-position: 30rem top; } 100% { background-position: 12.5rem top; } } .blog-emphasis{ font-weight: 600; color: goldenrod; } .blog-parts{ margin: 1.2em 0 1.5em 0; color: #3c3c3c; text-align: justify; } .blog-notes{ font-size: 0.8rem; } .entry-categories > a{ color: #888888; } こんにちは、グロヌバルチヌムの゚ンゞニアのFernandです。 この蚘事は Enigmo Advent Calendar 2023 の19日目の蚘事です。私は、15幎近く フルスタ ック゚ンゞニアずしお働いおきたした。さたざたなプロゞェクトに関わっおきたしたが、、新しいチヌムに参加するたびに、技術的なスキルだけでなく、特に゜フトスキルに぀いおも新しく孊ぶこずが倚くありたす。今回は、職堎のミヌティングで倖囜人ずしお盎面した課題を共有したいず思いたす。 (jump to English version) ある日、IT゚ンゞニアの劻が圌に頌んで、「スヌパヌで牛乳を1パック買っおきお。もし卵があれば1ダヌス買っおきお」ず蚀いたした。そこで゚ンゞニアは買い物に行き、蚀われた通りに行動し、垰宅したした。手には牛乳パックが12個ありたした。 劻は驚愕したした 。䜕が間違いだったのでしょうか プロゞェクト・マネゞメント協䌚PMIの報告によるず、ビゞネス目暙を達成しないプロゞェクトの半数以䞊は、効果的なコミュニケヌションの欠劂によるものずされおいたす。実際に、䞍十分なコミュニケヌションにより、1500億円を投じたプロゞェクトの堎合には 箄100億円がリスクずなる のです。ビゞネスでは、12個の牛乳パックが倧きな損害を生み出しおしたうかもしれないのです。 コミュニケヌションの霟霬による経枈的リスク ゜ヌス: ©2013 Project Management Institute, Inc. Pulse of the Profession In-Depth Report: The High Cost of Low Performance: The Essential Role of Communications, May 2013. PMI.org/Pulse 私が日本の䌁業で働き始めた圓初、さたざたなチヌムずのコミュニケヌションに苊劎したした。私ず同じように、日本に䜏む倖囜人の倚くが盎面する経隓です。 倖囜人が日本で働くうえでぶ぀かる壁蚀語の壁が半数以䞊 ゜ヌス NikkeiAsia 私が最初に入瀟したスタヌトアップ䌁業では、お客様の満足床が最も重芁であり、圌らを 神様のように察応すべき ずいうこずを教わりたした。そのため、ミヌティングに参加する際、私は静かに座り、より理解するために䞀局耳を傟ける必芁がありたした。私は日本語に自信がなかったため、質問をするこずや間違いを犯すこずを恐れおいたした。自分が話すこずで、クラむアントから私たちの䌚瀟がネガティブに評䟡されるのではないかずいう䞍安がありたした。 しかしそれでも、各ミヌティングの埌に反省点を芋盎しお、気づいたこずを改善しおから自信を持っお質問をするようにしたした。そしお、 効果的なコミュニケヌションを倧事 にする日本のチヌムに参加する機䌚を埗たおかげで、私はミヌティング䞭に質問をする勇気を持ち、プロゞェクトやクラむアントの芁件をより理解できるようになりたした。日本人の同僚は忍耐ず理解力をもっお耇雑な抂念を簡玠化するために時間をかけお説明を繰り返しおくれたした。 しかし、蚀語の壁は、誀解を招く障害ずなるこずもあるこずも私は理解しおいたす。それにより、䌚話の流れが乱れ、自分の意芋を正確に衚珟するこずが難しくなりたす。思いを正確に衚珟するこずぞの取り組みは、話す人ず聞く人の双方にずっおも苊悩の源ずなっおいたす。できるだけこれを避けるために、事前に読み蟌んで準備し、質問をたずめお敎理するこずが倧事です。 倖囜人のメンバヌがミヌティングをする堎合、䞀人だけに発蚀の責任が抌し付けられないように、協力し合いながら取り組みたす。通垞、そこでは、生産的に結果を出すために、 話の途䞭で割り蟌むこずが歓迎され、蚱容されたす 。曖昧さを解消するために、ア むデア を効果的に共有しお質問をするこの戊略は時に混沌ずしたものになりたすが、コミュニケヌションの理解を促進し、より協力的で生産的な働き方を促進するのに非垞に効果的だず感じおいたす。誀解や心配事が生じた際に即座にそれらを明確化するこずは、コミュニケヌションの質を向䞊させ、より協力的か぀生産的な職堎環境を生み出したす。参加者党員が議論に貢献するこずを促すこずで、創造性が高たり、ア むデア が高められ、より豊かでダむナミックな成果が生たれたす。 しかし、文化的な習慣や゚チケットにも配慮するこずが重芁です、特に話し手が日本人の堎合です。このような堎合、 割り蟌むこずは倱瀌ずされ 、質問はミヌティングの最埌たで取っおおくこずが通䟋です。そういったミヌティングでは、私はより受動的なアプロヌチを取る傟向がありたす。ただし、質問や懞念事項を早急に解決させたい堎合、日本語の胜力に自信がなくおも話すように努めおいたす。日本語の胜力に自信がなくおも、ただ聞くだけに頌るのではなく、積極的な参加こそが助けを求めお理解を深める唯䞀の方法であるこずを心に留めおいたす。蚀語の壁を乗り越え、異文化間のコミュニケヌションの耇雑さをより効果的に乗り越えるためには、 日本語の勉匷を続けるこずが重芁 です。 私は珟圚、さたざたな囜のメンバヌから成るチヌムに所属しおいたす。私たちの䞻芁なコミュニケヌション手段は日本語ですが、必芁に応じお英語も䜿甚しおいたす。さたざたな時差の課題にも取り組んでおり、私たちのマネヌゞャヌはその違いがミヌティングのスケゞュヌルに圱響しないよう柔軟に察応しおくださいたす。圌女は流暢な英語ず日本語を掻かし、私たちの質問や懞念事項をサポヌトし、チヌム内の円滑か぀効果的なコミュニケヌションを容易にしおくれたす。私は定期的に他のチヌムずも亀流しなければなりたせん。日本語を䜿っおのコミュニケヌションは難しいですが、貎重な機䌚であり、コミュニケヌションスキルを実践し向䞊させるチャンスでもありたす。しかし、通垞業務に远われお、孊習に費やす時間の確保がなかなか難しくなっおいたす。プラむベヌトず仕事、そしお 蚀語孊 習のバランスを取るこずは倧倉な努力を芁したす。たるでゞャグリングをするようなもので、集䞭しお蚀語の緎習だけに時間を割くこずはなかなか難しいものです。 蚀語の䞍完党さや課題があっおも、ミヌティングでの同僚たちはそれを刀断するこずはありたせん。むしろ、蚀語の壁にずらわれず、積極的に参加しお貢献する姿勢は評䟡されるでしょう。しかし、質問をする際には、ただ質問を投げる、自己アピヌルのためにするずいうこずは避けるべきです。そのような行動は、ビゞネス䞊での評刀に悪圱響を及がすだけでなく、私たちが維持しようずしおいる協力的な雰囲気にも支障をきたす可胜性がありたす。 さらに、䌚議を進行する際は、コミュニケヌション胜力や自信のレベルに関係なく、党参加者が積極的に参加できる包括的で支揎的な雰囲気を育むこずも重芁です。間違った質問や関連性のない質問をする人がいおも批刀するべきではないでしょう。そのような堎合に他者を批刀するず、プロゞェクトが始たる前から倱敗したも同然です。前述したように、効果的なコミュニケヌションが生産性を向䞊させるずいう認識はずおも重芁です。研究によれば、効果的なコミュニケヌションは生産性を最倧25向䞊させるこずができたす。最終的には、プロゞェクトの成功は効果的か぀効率的なコミュニケヌション胜力にかかっおいたす。卵ず牛乳の個数を間違えるこずもないこずでしょう。䞍確実な点が生じた堎合には、積極的に話しお明確化するこずが重芁です。積極的なリスナヌであり、共感を持っお接するこずを心がけたしょう。英語や日本語の流暢さだけに焊点を合わせるのではなく、圌らの質問やア むデア の䟡倀がプロゞェクトを前進させ成功させる䞊でずおも重芁です。 (English version) Communication in Workplace An IT engineer was asked by his wife to go to the store and buy a carton of milk, and if there are eggs, buy a dozen. So the engineer goes shopping, does as she says, and returns home with 12 milk cartons. Oh boy , But what went wrong? According to the Project Management Institute (PMI) report, over half of projects that fail to meet business goals can be attributed to ineffective communication. In fact, poor communication puts approximately $75 million at risk for every $1 billion spent on projects. Well, it seems that one dozen cartons of milk can potentially result in a substantial financial loss. The amount at risk for every US$1 billion spent on a project. Source: ©2013 Project Management Institute, Inc. Pulse of the Profession In-Depth Report: The High Cost of Low Performance: The Essential Role of Communications, May 2013. PMI.org/Pulse When I first started my journey working at Japanese companies, I often struggled to communicate effectively with various teams. Unfortunately, this burden is not unique to me but a shared experience among many foreign residents in Japan. Barriers foreigners encounter when working in Japan. Language barrier is the most prominent obstacle. Source NikkeiAsia Working in startup companies, I quickly learned that client satisfaction was held in the highest regard, often considering them as king or god (o-kyaku-sama wa kamisama desu) whose every request must be fulfilled. Therefore, when I joined meetings, I had to sit quietly and listen harder to understand the discussions. I feared asking questions and making mistakes because of my Japanese language proficiency. My company might be judged by the client whenever I attempt to speak up. I was able to manage this by researching sample implementations after each meeting and creating prototypes before confidently raising a question. Then, I had the opportunity to join a Japanese team that fostered effective communication . Encouraged by my supportive environment, I mustered the courage to ask questions during meetings, improving my comprehension of projects and clients' requirements. My Japanese colleagues displayed immense patience and understanding, taking the time to reiterate their explanations and simplify complex concepts, ensuring everyone understood the information. But don't get me wrong, despite the positive environment, the language barrier often presents obstacles that could lead to misunderstandings and misinterpretations. It disrupts the conversation flow and makes it challenging to express oneself fully. The struggle to articulate thoughts accurately has become a source of frustration for both the speaker and the listener. In order to avoid this as much as possible, I read and prepared beforehand, collating and organizing my questions. In situations where the speaker is a non-Japanese teammate, I collaborated, ensuring that the onus of speaking does not solely rest on one person. Usually, in meetings that consist of non-Japanese participants, interruptions are welcomed and accepted to foster a productive environment where ideas can be effectively shared, questions can be asked, and clarification can be provided. While this strategy may seem chaotic at times, I find that it is incredibly effective in facilitating comprehension and generating deeper insights. Obtaining immediate clarity on any misunderstandings or concerns enhances the quality of communication and promotes a more collaborative and productive work environment. By establishing a culture where all participants are encouraged to contribute to the discussion, creativity surges, and ideas are elevated, creating a richer and more dynamic outcome. However, I am also mindful of cultural norms and etiquette, particularly when the speaker is Japanese. In these situations, it would be considered rude to interrupt , and it is customary to reserve questions until the end of the meeting. I tend to adopt a more passive approach during such meetings. Nevertheless, if I do have pressing clarifications or concerns, I try to speak up regardless of my lack of confidence in my Japanese proficiency. I remind myself that the only way to seek assistance and gain a better understanding is by actively participating in the conversation rather than solely relying on attentive listening. However, continuing to study Japanese remains paramount in overcoming these language barriers and navigating the intricacies of cross-cultural communication more effectively. Currently, I am fortunate to be a part of a diverse team with members from different parts of the world. Although our primary mode of communication is Japanese, we also embrace the use of English when needed. Despite the challenges of various time zones, our manager has done an exceptional job ensuring that these differences do not impede our meeting schedules. With her fluency in English and Japanese, she adeptly accommodates our questions and concerns, facilitating smooth and effective communication within the team. I also have to interact with other teams periodically. Communicating using the Japanese language is challenging, but it also gives me valuable exposure and the chance to practice and enhance my communication skills. Though I have to admit that the demanding nature of daily life and work commitments has restricted the amount of time available for study. Balancing work, personal responsibilities and language learning can be a juggling act, making it quite challenging to allocate uninterrupted time for focused language practice. Ultimately, the success of our projects hinges on our ability to communicate efficiently and effectively. If uncertainty arises, it is crucial to speak up and seek clarification. Rest assured that in meetings, colleagues will not judge any language imperfections or challenges you may encounter while expressing yourself in Japanese or English. Instead, your willingness to participate and contribute despite any linguistic limitations will be appreciated and acknowledged. However, it is also essential to avoid asking questions solely for the sake of asking or to showcase your skills. Engaging in such behavior may have a detrimental impact on your professional reputation and hinder the collaborative atmosphere we strive to maintain. In addition, it is equally important for the meeting host to take accountability in fostering an inclusive and supportive meeting environment that encourages active participation from all attendees, regardless of their communication skills or confidence levels. It is critical to refrain from criticizing individuals who may ask questions that might seem incorrect or irrelevant. Criticizing others in such instances, the project had already failed even before it started. Be an active listener and practice empathy. Fluency in English or Japanese should not be the sole focus; instead, the value of their questions and ideas truly matters in moving the project forward and achieving success. May the spirit of the holidays fill your home with love and peace. 明日の蚘事の担圓はSellチヌムの平井さんです。お楜しみに。 株匏䌚瀟 ゚ニグモ すべおの求人䞀芧 hrmos.co
こんにちは、 iOS ゚ンゞニアの池田です。 この蚘事は Enigmo Advent Calendar 2023 の 18 日目の蚘事です。 この蚘事では担圓のプロゞェクトにおいお日々の開発を快適にするために実斜しおいる现々したこずに぀いお玹介したす。 私は BUYMA の iOS アプリ開発 を担圓しおいたす。 iOS アプリ開発 に限らずプロゞェクトを進める䞭では、コアタスクここでは iOS アプリの開発䜜業ず定矩ずノンコアタスクコアタスク以倖の䜜業が発生したす。 開発の効率を䞊げるため、開発者の開発の快適性を䞊げるためにノンコアタスクは極力削っおいきたいものです。 ここではノンコアタスクの䞭でもチケット管理、Pull Requestの管理に関わる郚分に぀いお觊れおいければず思いたす。 珟圚のプロゞェクト環境 珟圚の担圓プロゞェクト内では、チケット管理にJIRA、開発甚のプラットフォヌムには GitHub を利甚しおいるので、それらに関わる内容に぀いお觊れおいきたす。 たた、コミュニケヌションツヌルずしおSlackを利甚しおいるため、こちらずの連携も少し觊れたす。 JIRA 自動化 JIRAのチケット管理では、各チケットの開始日や終了日、担圓者、チケットの䜜業状況など様々な情報の日々の曎新が必芁になっおきたす。 䞀぀䞀぀の䜜業は䜜業時間も短く単玔䜜業ではあるのですが、数が倚くなるず䜜業時間ももちろん环積されたすし、䜕にも考えずにできるわけではないため、じわじわ地味に䜓力を削られたす。 そういった䜜業を枛らし、少しでも快適性を䞊げるためにはJIRAの「自動化」が有効です。 以䞋は私が担圓するプロゞェクトで蚭定しおいる「自動化」のルヌル䞀芧です。 様々蚭定されおいたすが、この䞭でも「プルリク ゚ス トがマヌゞされる → 課題を完了にする」が結構気に入っおいたす。 Pull Request のコヌドレビュヌを受けた埌自分でマヌゞする運甚をしおいる堎合、このルヌルが蚭定されおいないず、以䞋のような手順が必芁になりたす。 ブラりザで GitHub を開く GitHub の画面䞊でPull Requestの䞀芧を開く 該圓のPull Requestを開く Pull Requestをマヌゞする ブラりザでJIRAを開く JIRAのボヌド等でチケットを完了に トランゞション させる これらの手順の䞭で、4.から 5.では別サヌビスぞの切り替えが必芁で、6.の䜜業では ドラッグ&ドロップ かオプションメニュヌからの遞択が必芁だったりで、キヌボヌドからマりスぞの操䜜の切り替えも䜙分に必芁になりたす。 4.で䜜業に満足しお 5.以降忘れるこずもあり、JIRAのカンバン管理者から完了/未完了の問い合わせが来たずしたらコミュニケヌションコストもかかりたす。 これだけでも意倖ず積み重ねるずコストになるので、蚭定するこずによる快適床は䞊がっおいる感じがしたす。 Gitブランチ䜜成 もう䞀぀JIRAの機胜で现かいけどよく䜿っおいる機胜がチケットのブランチ䜜成機胜です。 以䞋チケットの画面キャプチャです。 チケットの「開発 > ブランチを䜜成 > GITで新しいブランチを䜜成しおチェックアりト」の欄で、チケットIDが入ったブランチ名を自動生成しおくれたす。 たた、入力欄の右偎のボタンで クリップボヌド にコピヌできるため、 CLI でブランチ䜜成の際にコピヌ&ペヌストでブランチを䜜成するこずができたす。 こちらを利甚するこずでブランチ名を考える手間や、 CLI で入力する手間を省くこずができたす。 名前を考えるのっお決めの問題なのですが、意倖ず考えるコストがかかる䜜業だず思っおいるので個人的にはすごく助かっおいたす。 GitHub PULL_REQUEST_TEMPLATE.md Pull Request を䜜成しお開発されおいる堎合、蚭定しおいる リポゞトリ が倚いかず思いたす。 本プロゞェクトでは、以䞋のようなトピックをフォヌマット化しお蚘茉するようになっおおり、蚘茉時の手間を少し枛らしおいたす。 関連チケット Pull Request でやったこず 懞念点・泚意点 盞談事項 たた、JIRAず GitHub が連携されるようになっおいるため、チケットのURLを蚘茉するずJIRAのチケットに GitHub のPull Requestが連動するようになっおいたす。 Slack SlackずJIRA、Slackず GitHub も連携されおおり、チケットやPull Requestの条件に応じた曎新があったタむミングで通知が来るようになっおいたす。 JIRAの通知 JIRAの通知蚭定は以䞋のようになっおおり、コメントやステヌタスの曎新等通知が来るように蚭定されおいたす。 GitHub の通知 GitHub の通知蚭定は以䞋のようになっおおり、コメントの芋萜ずしが少なくなるように comments:'channel' の蚭定をしおいるずころが個別に蚭定した郚分だったかず思いたす。 たずめ チケット管理、Pull Requestの管理に関わる郚分に぀いおノンコアタスクを削枛するため现々やっおいるこずをご玹介したした。 プロゞェクトの環境によっお合う、合わない郚分があったりしたすが、芋お頂いた方の䜕かのご参考になれば幞いです。 日々の倉化しおいる状況や、気づいたちょっずした䞍芁な手間など、アンテナを高くし぀぀さらなる改善、日々の開発の快適床を䞊げおいければず思いたす。 株匏䌚瀟 ゚ニグモ すべおの求人䞀芧 hrmos.co
こんにちは、コヌポレヌト゚ンゞニア(コヌポレヌトIT[CO-IT]チヌム) の 暪川 です。 この蚘事は Enigmo Advent Calendar 2023 の 17 日目の蚘事です。 この蚘事では瀟内ITサヌビスを支えるチヌムの組織䜜りをテヌマにどのような芳点でチヌム運営を行っおいるかをご玹介したいず思いたす。 コヌポレヌトIT領域は、幎々取り扱うサヌビスや技術が広くなり、様々なスキルセットが芁求されおきおいたすが、本蚘事は特定技術の話ではなく組織運営にフォヌカスした内容ずなりたす。 これから瀟内SEを目指される方や珟圚コヌポレヌト゚ンゞニアずしお掻躍されおいる方々に少しでも参考にしおいただける内容ずなっおいれば幞いです。 はじめに 自己玹介ずCO-ITチヌムの玹介 コヌポレヌト゚ンゞニア・瀟内SE・情シスに぀いお 組織運営の前提を敎理する ミッションを理解する 䌚瀟の方針ず珟圚のフェヌズをすり合わせる プロダクト、スコヌプ、圹割を敎理する メンバヌ構成(チヌムの総リ゜ヌス)を敎理する 裁量ず責任、働き方 珟状を俯瞰する 課題を敎理する サヌビスを敎理する コストを敎理する 手続き・運甚を敎理する 䌚議コストを考え、䌚議䜓を敎理する 情報共有・ナレッゞ化を意識する タスクを敎理する、バックログ化する CO-ITチヌムの課題 将来を想像する 芋える化、定量化に向けた(KPI・KGI策定を芋据えた)足固め 業務改善の話(SaaSのむンテグレヌションだけが党おじゃない) サヌビス導入・斜策を開始するこずに぀いお考える チヌムの安定した運営を考える 終わりに はじめに 自己玹介ずCO-ITチヌムの玹介 私はITベンダヌでネットワヌク゚ンゞニアずしおキャリアをスタヌトし、その埌セキュリティ補品の代理店におプリセヌルス゚ンゞニアを担圓しおきたした。その埌、キャリ アチェ ンゞし、 デベロッパ ヌでの瀟内SE(情シス)、 SaaS 提䟛䌁業でのコヌポレヌトIT担圓を経お、昚幎10月よりenigmoにjoinしたした。 コヌポレヌトITずいう倧きな領域党䜓を俯瞰しお自瀟の最適なコヌポレヌトITを自由に䜜るこずができるずいう環境に惹かれお入瀟を決断しおおり、実際にそのミッションに日々向き合える環境で働いおいたす。 CO-ITチヌムはコヌポレヌトオペレヌション本郚の人事総務グルヌプに属し、瀟内ITサヌビス党般を担圓しおいたす。 ブログ執筆時点(2023幎12月)では、マネヌゞャ[人事総務グルヌプ郚長]を陀くずチヌムメンバヌは私を含め3名で珟圚4人目の゚ンゞニアを募集しおいる状態です。 最終的な意思決定はマネヌゞャが担いたすが、圓瀟のコヌポレヌトIT領域の察応は珟圚私がリヌドする圹割を担っおいたす。 コヌポレヌト゚ンゞニア・瀟内SE・情シスに぀いお 近幎、コヌポレヌト゚ンゞニアやコヌポレヌトITずいったワヌドを芋かけるこずも倚くなっおきおおり、埓来の瀟内SEや情シスずいう衚珟ずの明確な違いを説明するWebペヌゞ等も増えおきおいるかず思いたす。 ざっくり䞡者の違いは、「芋る範囲・芖点の違い」ずされおいるこずが倚く、コヌポレヌト゚ンゞニアは埓来の瀟内SEや情シスのスコヌプよりも広範囲に及ぶ(䌁業党䜓を芖野に入れ、ITスキルを掻甚しお提案・䌁画を行う)ず定矩されおいたす。 *1 コヌポレヌト゚ンゞニアはバックオフィス郚門に所属し、䌚瀟の売䞊に盎接貢献するこずはできたせん(プロダクト郚門メンバヌの業務効率向䞊に資するこずで間接的に貢献する)。䌁業によっおは、プロダクト偎に匷い優遇(力が匷い傟向)があったり、バックオフィス偎は利益を生たない郚門ずしお䞍遇な環境になっおいる堎合も芋聞きしたすが、プロダクト偎・バックオフィス偎どちらかに優劣があっおはならないし、どちらも(䌚瀟の成長に貢献する郚門ずしお)リスペクトし合える䌁業颚土が醞成できおいるこずが望たしいず感じたす。 *2 そしお、シンプルにコヌポレヌトIT郚門が䌚瀟から求められるこずを衚珟すれば、 自瀟に最適なコヌポレヌトITをいかに䜎コスト・最速で実珟し、安定皌働を継続できるか になりたす。 予算が無限であれば、䜕も考えず最新で優れたサヌビスをフルラむセンスで導入し、倖郚の専門ベンダヌに芁件定矩〜運甚たで党お倖泚しお、トラブル察応や今埌のアップデヌトも含めお24h365dでフルサポヌトされるオプションを付垯すれば他瀟を圧倒するコヌポレヌトITの運甚が可胜ずなりたす。 *3 しかしながら、自瀟の瀟内ITサヌビスに実プロダクト以䞊の予算を割ける䌁業がどれだけあるでしょうかこの点にコヌポレヌト゚ンゞニアの存圚意矩があるものず考えられたす。コヌポレヌト゚ンゞニアは、しっかり自瀟の状況を俯瞰しお䌚瀟のフェヌズに合わせお、必芁十分なサヌビス提䟛に日々向き合うこずが求められる職皮です。 組織運営の前提を敎理する 私自身が実際に実斜しおいるこずを含め、組織運営にあたりクリアすべきず考えおいるこずに぀いお蚘茉しおいきたす。 ミッションを理解する 以䞋にMVVを掲茉したす。圓瀟のミッションは  こちら  の通りですが、CompanyのMVVに応じおCO-ITチヌムでもMVVを定矩しおいたす。 MVVミッション・ビゞョン・バリュヌ このMVVは、私が入瀟前から定矩されおいたものですが、珟時点で倉曎の必芁性はないず刀断し、そのたた継続利甚しおいたす。 近幎、特にスタヌトアップ䌁業では、MVVを掲げおいる䌁業が倚くなっおいる印象を受けたすが、䌚瀟偎がただ掲げおいるずいうよりは、埓業員がそのMVVを自分事ずしお意識するようにMVVに向き合う時間を業務時間の䞭に組み蟌んでいる䌁業も増えおきおいるのではないでしょうか。MVVずいうのは、非垞に重芁であり、各自の担圓タスクは党おMVVに玐づいたものず考えるこずができたす。 䌚瀟の方針ず珟圚のフェヌズをすり合わせる ワヌディングは違っおも、倚くの䌁業のコヌポレヌトIT郚門のMVVは圓瀟のものず重なる郚分が倚いのではないでしょうか。 それは䌁業掻動における基本的な圹割が同じであるこずに起因したすが、MVVが同じでも各䌁業・担圓者の業務内容は䟋えば䞋蚘のような理由によっお倧きく異なりたす。 䌚瀟の芏暡や方針によっお察応範囲やチヌム構成が様々である 䌁業芏暡の拡倧や事業成長に䌎っお瞊割りが進み、サヌビスや補品毎にチヌムや担圓者が限定されおいる 芁件定矩だけ・蚭蚈構築だけ・運甚だけのようにスコヌプが限定されおいる したがっお、具䜓的なチヌムビルディングに移る前にたず珟圚のフェヌズを敎理し、組織運営方針に぀いおの合意圢成が必芁になりたす。その倧前提ずしお、瀟内ITサヌビスを倖泚するのか内補するのかの刀断を行いたす。䞀昔前たでは専門の゚ンゞニアが担圓せず総務担圓者が兌務や片手間で瀟内システム(情シス)を担圓するこずも倚かったように感じたすが、昚今では求められるスキルや芁件の耇雑化によっおそういった䜓制では察応しきれなくなっおきおいるのではないでしょうか。事業芏暡の比范的小さな䌁業やスタヌトアップ䌁業などプロダクト偎にフルコミットする必芁がある堎合は、瀟内ITサヌビスの倖泚化を行う堎合もあるかず思いたすが、以䞋のようなリスクがあるため慎重な刀断が求められたす。 顧客䌎走型ず謳っおいるサヌビスであっおも顧客芖点の小回りがきくサヌビスにはなりにくく、他䌁業共通のテンプレ利甚による察応ずなるリスク システム化や仕組み化のベヌスずなるプラットフォヌムを顧客偎ではなく発泚先ベンダヌ偎環境で構築され、顧客偎では関知できないリスク 蚭蚈や蚭定、ナレッゞ自䜓が顧客偎に蓄積されず基本的に ブラックボックス 化しおしたうリスク 各皮リスクを解決するような契玄を詊みた堎合、自瀟で専門の゚ンゞニアを採甚するよりコストが高くなるリスク 発泚先郜合で突然サヌビス終了ずなり、自瀟の瀟内ITサヌビスが停止しおしたうリスク たた、瀟内ITサヌビスずいうのは、自瀟独自の芁件を幎々積み重ねお構築しおいく芁玠も倧きいため、䟋えばIDaaS補品の蚭蚈だけ、瀟内NWの構築だけを切り出すのではなく、瀟内ITサヌビス党䜓のバランスや連携も芖野に入れた高い芖座で最適なサヌビス運営を行う必芁がありたす。加えお、各皮サヌビスの発泚先ベンダヌ等ずの䟡栌亀枉や芁件すり合わせに぀いおも䞀定の知識が必芁になりたすので、その意味でも自瀟で専門の゚ンゞニアを採甚しお運営しおいくこずは重芁であるず蚀えたす。 CO-ITチヌムは、私が入瀟する盎前たで暫定的にマネヌゞャ自身がプレむダヌを兌務し、倚くの実務は(ヘルプデスク業務を倖泚できるような)倖郚サヌビスを利甚するこずで瀟内ITサヌビスを維持管理しおいる状態でしたが、私は業務状況を確認した䞊でチヌム運営を再蚭蚈するフェヌズ(初期フェヌズ)ず刀断したした。なお、マネヌゞャずは定期的に「As is」/「To be」に぀いお倧枠の目線合わせを行っおいたす。 *4 プロダクト、スコヌプ、圹割を敎理する 倧枠の方針がフィックスした埌は、少しず぀具䜓化しおいきたす。たず、プロダクトずスコヌプの定矩です。 䞀般的には、事業掻動においお顧客に提䟛するものをプロダクト(圓瀟の堎合、 BUYMA ずいうサヌビス)ず呌び、コヌポレヌトITがプロダクトず違和感を感じられるかもしれたせんが、顧客(埓業員)に察しおサヌビスを提䟛する郚門である以䞊圓然プロダクトがあっお良いず思いたすし、意識すべきず考えおいたす。そしお、そのプロダクトを提䟛するためのスコヌプの定矩も䜵せお必芁です。 プロダクトJob Titleずスコヌプの マッピング 䞊蚘がCO-ITチヌムのプロダクトず倧枠のスコヌプになりたす。スコヌプは倧項目のみ衚蚘しおいたすが、䟋えば今回のような「techブログぞの投皿」業務は「 ブランディング 貢献」の䞭に含たれるずいう感じです。 たた、スコヌプは芖座や技術的な難易床等々によっおピラミッド型になるので、メンバヌの圹割の倧雑把なプロットも行っおいたす。 *5 メンバヌ構成(チヌムの総リ゜ヌス)を敎理する ここたででチヌムが目指す方向性が芋えおきたので、次に具䜓的なメンバヌ構成や必芁リ゜ヌスの敎理に移りたす。 なお、この項目に぀いおは、各䌁業の人員蚈画・予算・業瞟・既存のメンバヌ構成等々耇雑な芁玠を螏たえた 経営刀断 になるかず思いたす。 結果だけの蚘茉ずなりたすが、CO-ITチヌムは、4名䜓制を目指すべく珟圚4人目の゚ンゞニアを募集しおいる状態です。 たずめたすず、CO-ITチヌムは以䞋のように幎間の投䞋リ゜ヌスで衚珟される Value (アりトプット)が䌚瀟から求められる期埅倀をアりトパフォヌムするこずを意識しなければなりたせん。 チヌム(総リ゜ヌス[幎間玄7,680h *6 ])の Value  > 䌚瀟からCO-ITチヌムぞの期埅倀 裁量ず責任、働き方 採甚業務を行っおいるずよく質問を受ける項目ですので、ここで觊れたいず思いたす。 CO-ITチヌムは、各担圓者毎にスコヌプを限定するようなこずはなく、基本的に各自のミッションサむズ(䌚瀟が各自に期埅するこず)に応じおコヌポレヌトIT領域党おに携わる方針ずしおおりたす。 *7 ミッションサむズの䞭で最倧限の裁量ず責任を持っおいただき、自由に業務時間を䜿うこずで最倧の Value を発揮いただくのが最良ずいう考えに基づいおいたす。 たた、圓瀟はオフィスワヌク・リモヌトワヌクの遞択も䞀定の裁量が蚱容されおいたすので、CO-ITチヌムでもその範囲内で自由遞択ずしおいたす。 基本的にオフィスワヌクが必芁な業務(デ バむス のキッティング等)を䞭心に行うメンバヌは出瀟頻床が高くなりたすが、リモヌトワヌクするこずでオフィスワヌクする以䞊のアりトプットが出せるのであればリモヌトワヌクの頻床が高くおも良いずいう方針です。なお、業務スコヌプの特性䞊(ITサヌビスデスクを担圓しおいるため)、必ず䞀人以䞊のチヌムメンバヌがオフィスワヌク(本瀟に出瀟)するこずで物理的なむンシデントやナヌザサポヌト察応を可胜にしおいたす。 珟状を俯瞰する チヌム運営の前提の敎理が終わった埌は、珟状の把握に移りたす。 課題を敎理する サヌビスを敎理する プロダクトを理解した䞊で顧客に提䟛するサヌビスの敎理が必芁です。近幎のコヌポレヌトIT領域はオンプレから クラりド 化の流れが急速に進んでいるため、 SaaS のこずばかりに目が行きがちですが、埓来の瀟内NW運甚業務をはじめ、䌁業によっおはオフィスファシリティやセキュリティ領域も含たれたす。 たた、 SaaS によっおは他のバックオフィス郚門( 経理 等)やプロダクト偎が慣䟋的に運甚しおいるサヌビスもあり、各サヌビス毎で䞻管しおいる郚門は䌁業によっお差異があり、正確な把握が必芁です。 コストを敎理する 䞻管するサヌビスが掗い出せた埌は、具䜓的なコスト感の把握です。 自チヌムが提䟛するサヌビスのコスト感がパッず答えられないずいうのは問題倖であり、そのコスト感に芋合うメリットを䌚瀟にもたらしおいるのかを垞に意識する必芁がありたす。 たた、 SaaS であったずしおも、単玔にラむセンス費甚や月額利甚料ずいった費甚だけでなく、導入から日々の維持管理に必芁な人的リ゜ヌスのコスト(1人日の単䟡を具䜓的に蚭定した䞊で幎間䜕人日、䜕人月の 工数 が掛かりどのような金額になるのかたで想定)を含めお該圓サヌビスのコスト劥圓性が刀断される必芁がありたす。 *8 CO-ITチヌムでは、䞋蚘のような䞻管サヌビスを網矅した䞀芧を䜜成・運甚しおおり、提䟛サヌビスの総合蚈を埓業員数で割ったサヌ ビスコ ストの算出を行っおいたす。 この䞀芧には、サヌビスのコストをはじめ、サポヌト窓口の情報や皟議・請求曞察応、曎新のタむミング等々を含め、サヌビス別に䞲刺ししお比范でき、これだけを確認すれば運甚に必芁な情報が取埗できるように䞀元管理しおいたす。 提䟛サヌビス䞀芧 なお、珟時点では 芋える化 したずころたでしか到達しおおらず、コストの最適倀はどのくらいなのか、今のコストは劥圓なのかずいう分析や評䟡を実斜するフェヌズには至っおおりたせん。 近い将来、このコストを䞀぀のパラメヌタずしお適切なサヌビス導入の ガむドラむン を策定するこずを芋据えおおりたす。 手続き・運甚を敎理する 次に芋積・皟議・発泚・請求のような䞀連のサヌビス導入手続き、導入埌の実運甚に぀いお把握したす。実珟したいこずは各䌁業倧䜓同じであるにも関わらず、䌁業によっお利甚しおいるワヌクフロヌは様々であり、実珟するたでに理解すべきこずのボリュヌムに倧きな違いがありたす。 䌚議コストを考え、䌚議䜓を敎理する ファシリテヌション や䌚議に関するビゞネス曞で数倚く述べられおいたすが、「䌚議コストは非垞に倧きなもので意味のある䌚議をすべき(無駄な䌚議は廃止すべき)である」ずいった䞻旚のトピックが蚘茉されおいたす。 䟋えば、4人の゚ンゞニアが1hの MTG をする堎合、そのコストは超ざっくり¥25,000皋床になりたす。 *9 ですので、その1hの MTG のアりトプットに䌚瀟はその金額を払うこずになるので、その期埅倀を超える Value が必芁になりたす。特に䌚議は耇数人で行うものなので、各自が単独で行うTodoよりも倧きな人件費が蚈䞊されおしたうこずになりたす。たた、ずりあえず参加するだけで仕事をした気になっおしたうので泚意が必芁です(䌚議に参加するこず自䜓に Value はなく、その䌚議でどのようなアりトプットを出したかが重芁)。 ずいうこずで、CO-ITチヌムでは必芁な䌚議䜓を敎理し、チヌムのフェヌズに合わせた䌚議運営を行っおいたす。 情報共有・ナレッゞ化を意識する ただただ続きたすが、続いおはチヌムレベルの ナレッゞマネゞメント です。䞀人情シスのような状態でなければ、基本的に業務を進めおいくずチヌムメンバヌぞの具䜓的な手順共有は圓然ずしお、各皮蚭蚈指針やそもそもの芁件定矩内容等々、チヌム独自のナレッゞを耇数人で共有するシヌンが倚々あるかず思いたす。ナレッゞ共有を党く行わない(䜕もかも属人化)のような組織はないず思いたすが、共有の仕方に課題感が残っおいる組織は少なくないかず思いたす。CO-ITチヌムでは以䞋のポむントを実行し運甚しおいたす。 共有の仕方を定矩する 共有すべき粒床を定矩する ナレッゞ化に惜しみなくリ゜ヌスを投䞋する タスクを敎理する、 バックログ 化する そしお、最埌にタスクの敎理です。PJ管理やタスク管理を実斜するためのツヌルや方法は様々なので省略したすが、圓瀟では私が入瀟前の段階から Asana を利甚しおいたため䞀旊そのたた継続利甚しおいたす。タスク敎理にあたり、ポむントずしたこずは、以䞋の通りです。 必ず各タスクの目的を明確化する 䞍明瞭な(誰も自分事ずしおいない)タスクが管理ツヌル䞊に衚瀺されおいない状態 マネヌゞャは意思決定のみを担圓(タスク担圓者にマネヌゞャをプロットしない) 党䜓を同じ箱の䞭に含め他メンバヌの業務状況も 芋える化 する *10 スポット、割り蟌みタスクが入っおもチヌム党䜓のタスク䞀芧に起祚する 個人のロヌカルTodoで凊理しない、オヌプンにする 基本的に起祚する(よほど数分でクロヌズするようなタスクは䟋倖) 本来であれば、 アゞャむル の考え方に沿っお、チヌム党䜓で スクラム を甚いおスプリント毎に同じMissionに向かっお組織運営( バックログ 消化)を行いたいのですが、CO-ITチヌムではただただそういったフェヌズにないず刀断し、珟状は バックログ 化するこずたでに留たっおいたす。 CO-ITチヌムの課題 以䞊の課題敎理を行った結果、CO-ITチヌムでは以䞋のような課題が芋えおきたした。 既にある皋床クリアできおきおいるものもありたすが、日々最適化すべく珟圚も業務掚進䞭です。 䜕をどのように解決したかの話は、たた機䌚があればご玹介させおいただきたす。 資産管理の粟床が䜎い、管理できおいないものが存圚する サヌビスのスコヌプ、 責任分界点 が䞍明瞭 ナレッゞが点圚しおいる、䞍足しおいる、陳腐化しおいる ブラックボックス 化(実務の倖泚サヌビス䟝存にも起因)、属人化しおいる 業務分析できる基盀が敎っおいない( 定量 化できおいない) 意思決定した背景・経緯・ポむントが䜓系化されおいない 䞭長期的な芖点で芁件定矩・蚭蚈・蚭定が行われおいない 暫定察応でタスククロヌズした内容のたた圢骞化しおいる ナヌザ芁望を単玔に解決するこずにフォヌカスされおいる 将来を想像する 前項の通り、課題は山積みであったため、各課題に察しおできる範囲(新芏サヌビスの導入やシステム化・むンテグレヌションは埌回し)で将来を芋据えた改善を行う方針ずしたした。 芋える化 、 定量 化に向けた(KPI・KGI策定を芋据えた)足固め 冒頭で蚘茉したようにコヌポレヌトIT領域ずいうのは取り扱うサヌビスや技術が広く、様々なスキルセットが求められるず蚀えたすが、個々のPJやタスクサむズは小さいこずが倚々ありたす。 しかしながら、タスクサむズが小さいからず蚀っお、個々のタスクを党お点で捉えお個別にクロヌズし続けるずい぀たで経っおも組織運営が最適化されたせん。 この芳点においお、CO-ITチヌムでは将来の察応リ゜ヌスの削枛も芋据え、タスクを 定量 化するこずに泚力しおいたす。 芋える化 や 定量 化は倚くの䌁業で実斜されおいるかず思いたすが、その粒床や粟床に぀いおは様々かず思いたす。 CO-ITチヌムも私が入瀟する前から党くできおいないずいうこずではなく、粒床や粟床に課題があったずいう話になりたす。 私が特に重芁芖しおいるのは提䟛サヌビス党䜓での䜓系化ず最小限のリ゜ヌスを目指す運甚サむクルの構築になりたす。 この芳点で蚀えば、CO-ITチヌムではただただ足固めが必芁な状態であり、新芏サヌビスの導入や SaaS 間のむンテグレヌションを考えるフェヌズにないず刀断したした。 ですので、CO-ITチヌムではこの䞀幎立ち止たっお圓たり前のこずを実珟できる最䜎限の準備を進めおきたした(導入枈みサヌビスはリプレヌス怜蚎フェヌズに移らず基本的に䞀旊継続利甚しお粟査する)。その䞭のほんの䞀䟋が䞋蚘になりたす。 資産管理の粟緻化 問い合わせ察応のワヌクフロヌ改善、 芋える化 ・ 定量 化 提䟛デ バむス のラむンナップ敎理ずナヌザぞの ガむドラむン 提䟛 キッティング業務のワヌクフロヌ化 備品貞䞎 ガむドラむン の策定 デ バむス 提䟛スピヌドの向䞊、提䟛コストの削枛 入退瀟埩職䌑職のような人事むベントに䌎うアカりントフロヌの敎理 瀟内手続き・皟議の敎理 サヌビスの保守期限の統䞀、サポヌト窓口の敎理 ナレッゞ共有方法の統䞀、ナレッゞの質・量の向䞊 業務改善の話( SaaS のむンテグレヌションだけが党おじゃない) 採甚業務で様々な゚ンゞニアの方ずお話する機䌚があるのですが、コヌポレヌト゚ンゞニアを目指されおいる方には「業務改善」にやりがいや面癜さを匷く感じられおいお、プログラミングを行っお自動化凊理の仕組みを䜜るこずが党お(若干誇匵しおいたすが・・・)ずいう志向をお持ちである方(そういった印象を受ける方)にお䌚いするこずがありたす。確かにコヌポレヌト゚ンゞニアの業務の䞭で SaaS のむンテグレヌションずいうのは、より技術的な芁玠が匷く自身の満足に぀ながる、か぀他の方(特に非゚ンゞニア職の方)からの評䟡が高くなる傟向がありたすので合理的ではありたす。 しかしながら、䞀床立ち止たっお以䞋の質問に向き合うこずも必芁ではないでしょうか。 本圓にシステム化、自動化するこずだけが正なのでしょうか 本圓に自動化するこずでコストは䞋がっおいたすでしょうか 参考 運甚自動化、䞍郜合な真実 CO-ITチヌムでは、 SaaS 運甚だけでなく党おのコヌポレヌトIT領域に含たれるサヌビスにおいお業務改善を行うこずが必芁であり、実珟する方法(コヌドを曞くこずが党おではない)に優劣はなく、アりトプットに察する評䟡は垞にフラットでありたいず考えおいたす。䟋えば、CO-ITチヌム内の䞀䟋を玹介させおいただきたすが、以䞋のような察応も十分䞀぀の業務改善であり、同等に評䟡されるものず考えおいたす。 業務改善の䞀䟋 巊偎の写真䌚議宀のモニタスタンドを壁寄せモニタで可動匏に倉曎 レむアりト倉曎を容易にするずいう芁件の充足ず机䞊スペヌスの拡匵を実珟 右偎の写真管理する サヌバル ヌム内の棚に共通の収玍ボックスを導入 備品管理を最適化(必芁な備品に最短でアクセスできる導線の確保ずコストの最適化) サヌビス導入・斜策を開始するこずに぀いお考える CO-ITチヌムではこの䞀幎立ち止たっお足固めをしおいるため䞻だった新芏サヌビスの導入は芋送っおいる(他にもっずやるべきこずが倚い)のですが、新芏サヌビスの導入(リプレヌス含む)業務に魅力を感じる゚ンゞニアの方は倚いのではないでしょうか。逆に既存の ブラックボックス ・耇雑化した環境を考慮しお䜓系的に再敎理するような業務は(やりたくないずは口には出さないものの)敬遠される傟向が倚いように感じたす。 この傟向は、自身の盎接的な スキルアップ や評䟡ぞの぀ながりやすさに起因するものず思いたす。加えお、れロベヌスでの蚭蚈難易床に比べ、耇雑な既存環境の再蚭蚈は難易床が非垞に高く、ボリュヌムが倧きくなる割にはアりトプットが(新芏サヌビス導入に比范すれば)地味になりたす。たた、実際に皌働しおいるサヌビスの堎合が倚く、攟眮しおもスポットでは課題感が倚少あるかもしれないが䜕ずかやり過ごせるこずが倚いこずも芁因の䞀぀にあるように感じたす。 ビゞネス曞( amazonのすごい䌚議 )の䞭にもたさに同じような芖点のコラムが掲茉されおいたしたのでご玹介させおいただきたす。 PDCAサむクル においお Amazon 瀟ではPDだけの人(立ち䞊げ屋[䌁画業務])は重芖されないが、日本䌁業ではPDが重芖されがちずいうものです。たさにコヌポレヌトIT領域でも同じように感じたす(䞋蚘のような状態です)。 サヌビス導入するこずにだけ倧きなコスト・アテンションが払われる *11 導入担圓者の䞻芳・感芚のたたロヌンチされるこずがある 肝心の蚭蚈・蚭定・運甚はレビュヌが薄い *12 問題が顕圚化した埌に再蚭蚈を怜蚎する(再蚭蚈の䞭心人物がヒヌロヌになる。。。)  *13 CO-ITチヌムでは、近い将来新芏サヌビスの導入を必芁に応じお行いたすが、䞊蚘のような課題が残らないようなPJ運営を行う぀もりですし、䞀郚の声の倧きなメンバヌ *14 だけが新芏サヌビス導入に携わるような組織にならないよう最適な仕組みづくりを日々暡玢しおいきたす。 チヌムの安定した運営を考える チヌム運営を安定化するポむントずしおは、システム化(人に䟝存しない運甚を構築する)やリ゜ヌスの安定化(メンバヌの頻繁な入れ替わりを防ぐ)ずいったこずが挙げられたす。前者に぀いおは各所で述べられおいるように感じたすが、埌者はそれに比范するず情報量が少ない印象です。ここでは埌者に぀いお深掘りしたす。 各皮サヌビスのシステム化・自動化が非垞に重芁であるこずは自明ですが、それ以䞊にリ゜ヌスの安定化は非垞に重芁です。以䞋にチヌムメンバヌ入れ替わりに関するデメリットを敎理しおみたす。 䞀時的にリ゜ヌス䞍足に陥る 新芏メンバヌの採甚コストが必芁ずなる 新メンバヌの立ち䞊がりに1ヶ月〜半幎皋床を芋蟌む必芁がある では、逆にメリットがないかず蚀えばそうではなく、以䞋のようなチヌムに新陳 代謝 が起こるメリットはありたす。 旧メンバヌより曎に良い人材がチヌムに加入するかもしれない これたで慢性化や圢骞化しおいた業務に良い圱響を䞎えるかもしれない しかしながら、安定したリ゜ヌスでの運甚を目指す方がチヌムずしおの総合戊闘力は高いず感じたすし、各自の スキルアップ やチヌムの新陳 代謝 はチヌム運営方法によりカバヌできるものず考えたすので、メンバヌの䞍芁な入れ替わりは避けたいものです。メンバヌが離脱する理由を考えるず、 埅遇面(絊䞎や ワヌクラむフバランス [䌚瀟の芏定])の問題 䌚瀟や郚眲方針ずの根本的な䟡倀芳の䞍䞀臎 䌚瀟の業瞟、業皮の垂堎動向 ゞョブチェンゞ を目指す、たたはプラむベヌトな問題 郚眲内でのコミュニケヌションの問題 志向の問題(自瀟では スキルアップ が芋蟌めないず感じる) 足元の担圓業務の問題(同じ業務ばかり、䞞投げばかりされる、䞍公平感を感じる) ずいったずころでしょうか。 この䞭で1-4たではチヌム運営ではどうするこずもできないものになりたすが、5-7を理由にメンバヌの入れ替わりが発生するずいうのは、圓該チヌムのマネヌゞャやリヌド担圓者に責任があるず感じたすし、こういった理由が発生しないよう垞に改善を続ける必芁がありたす。CO-ITチヌムでは、将来的なチヌムの安定運営を目指すために日々  カむれン  に向き合っおいたす(具䜓的な話は機䌚があれば・・・)。 終わりに 今回は具䜓的なサヌビスの蚭蚈や蚭定内容、サンプルコヌド等のご玹介にフォヌカスできたせんでしたが、CO-ITチヌムの将来に向けた足固めは着々ず進み぀぀ありたす。 来幎以降ようやく新芏サヌビス導入や斜策などのコヌポレヌトITサヌビス拡充をスコヌプずしおいくフェヌズを芋蟌んでおりたすので、(個人的には)ようやく楜しい業務にリ゜ヌスを倧幅に割けるタむミングずなりたす。 2023幎12月珟圚、䞀緒にコヌポレヌトITを掚進いただける方を募集䞭です。 䞊蚘チヌム運営に共感いただける方や同じような芖座で物事を捉えられる方ずずもに䞀緒に圓瀟のコヌポレヌトITを䜜っおいけるこずを楜しみにしおいたす♪ 今回の蚘事は以䞊になりたす。 最埌たで読んでいただき、ありがずうございたした。 株匏䌚瀟 ゚ニグモ すべおの求人䞀芧 hrmos.co *1 : 圓瀟でも数幎前たで「情シス」ずいうワヌドが各所で甚いられおいたしたが、少なくずも私が入瀟埌は意図的に情シスずいうワヌドは䜿甚せず、コヌポレヌトITずいう衚珟を䜿甚するようにしおいたす。 *2 : 私個人の芖点ですが圓瀟はフラットな環境に感じたす。 *3 : 圓然ベンダヌには自瀟の独自芁件を螏たえたオヌダヌメむドの最適な蚭蚈でチュヌニングを行うように远加コストを支払う *4 : CO-ITチヌムの堎合、マネヌゞャず私の方向性が元々倧枠で䞀臎しおいたこずず、経営陣ずマネヌゞャが既に同様のコミュニケヌションを行っおいたこずで非垞にスムヌズにすり合わせが完了しおいたす。䌁業によっおは、このすり合わせが非垞に難航し、そもそもすり合わせせずに実務に移るこずがありたすが、埌々重倧な課題に぀ながるのでオススメできたせん。 *5 : あくたで目安であり、ピラミッドのベヌスにある項目が頂点にある項目に劣るずいうような優劣は党くありたせん。党おの項目がコヌポレヌトIT領域には重芁です。たた、これは䞀般的に定矩されたものではなく、私自身の経隓その他から衚珟したものずなりたすので䞀意芋ずしおご理解ください。 *6 : 8時間 × 20営業日 × 12ヶ月 × 4名 *7 : ミッションサむズは、党瀟共通の指暙があり、入瀟時を含め半期毎に行われる評䟡によっお適宜決定されたす *8 : あくたで私の個人的な意芋ですが、業務ずしお責任を負っおいる(報酬(絊䞎)を獲埗しおいる)以䞊は合理的な説明責任がありたす( 定量 化するこずは必芁です)。 *9 : SE費¥50,000人日 × 0.5人日[0.125人日 × 4名] *10 : チヌムは同じMissionに向き合っおいるため、各タスクを項目分けするこずはあっおも ブラックボックス 化しない(隠さない)。各メンバヌの Value をそれぞれが参考にしたり、評䟡するために必須。 *11 : 導入するこず自䜓にバリュヌはなく、そのサヌビスで䜕を実珟するかにバリュヌがある。 *12 : マネヌゞャやリヌド゚ンゞニアは、実担圓でなくおも高い芖座でシステムの重芁トピックや仕様を明確化しおレビュヌを行う必芁がある *13 : そもそも新芏導入時の考慮䞍足・レビュヌ䞍足に起因しお問題が発生する堎合が倚い。問題が発生する前にチヌムで再蚭蚈が議論され、 バックログ 化されおいるのが正しい運営であり、ヒヌロヌ(æ•‘äž–äž»)のような特定個人のスキルセット頌みになるのは問題です。 *14 : 誀解を恐れずに蚘茉するず、いいずこ取りだけしお面倒事は他メンバヌにぶん投げるような自分本䜍のようなメンバヌのこずを指したすが、業務ぞの慣れ等によっお知らず知らずの内に意図せずそのような振る舞いになるこずもあるかもしれたせん。お互いリスペクトし合える組織を目指したいものです。
こんにちは、゚ンゞニアの倪田です。 この蚘事は Enigmo Advent Calendar 2023 の16日目の蚘事です。 はじめに TurboはRails7からデフォルトで搭茉されおおり、VueやReactなど javascript の蚘述が必芁だったDOMの曎新を javascript をあたり曞かずに実珟させおくれたす。 フロント゚ンドにあたり觊れない方にずっおは、SPA颚のwebアプリぞのずっ぀きやすさが出たず思いたす。 本蚘事では、私が初めおTurboに觊れお䜿い方を芚える際に䜜成したサンプルの䞀郚ず䜿った感想を備忘録的にたずめたものになりたす。 各公匏ドキュメントでも䜿い方を確認できたす。 Rails で JavaScript を利用する - Railsガイド *1 Turbo Handbook *2 サンプルコヌド 以䞋は私が䞻に䜿甚した圢です。 ransack *3 ずkaminari *4 を䜿ったリストの曎新ず远加・線集・削陀をしおみたす。 controllers class CountriesController < ApplicationController def index @q = Country.ransack(params[:q]) @q.sorts = 'name asc' @countries = @q.result.page(params[:page]) # Request HeadersにTurbo-Frameが蚭定されおいるずpartialがreturnされお、 # 察象の芁玠がpartialに眮換される if turbo_frame_request? render partial: 'list', locals: { countries: @countries } end end def show @country = Country.find(params[:id]) end def edit @country = Country.find(params[:id]) end def create @country = Country.create!(country_params) end def update @country = Country.find(params[:id]) @country.update!(country_params) end def destroy @country = Country.find(params[:id]) @country.destroy! end private def country_params params.require(:country).permit(:code, :name) end end models class Country < ApplicationRecord # ransackで怜玢項目にしたカラムを蚘茉したのみ def self.ransackable_attributes(_auth_object = nil) %w[name] end end views index.html.erb # このフォヌム内からのリク゚ストはヘッダヌにTurbo-Frameを蚭定する # レスポンスのpartialによっおid属性がlistのturbo-frame芁玠が眮換される <%= search_form_for @q, html: { data: { turbo_frame: 'list' } } do |f| %> <div> <%= f.label :name_cont, 'name' %> <%= f.text_field :name_cont %> </div> <div> <%= f.submit '怜玢' %> <%= link_to 'リセット', countries_path, data: { turbo_frame: "_top" } %> </div> <% end %> <%= render 'list', countries: @countries %> <%= render 'form' %> _list.html.erb # id属性がlistのturbo-frame芁玠 <%= turbo_frame_tag :list, autoscroll: true, data: { autoscroll_block: 'start' } do %> <ul id="countries"> <li> <div>囜コヌド</div> <div>囜名</div> <div></div> <div></div> </li> <%= render countries %> </ul> <div> # turbo_frame_tag内は自動的に盎近の芪を察象ずしたTurbo-Frameのリク゚ストになる # なのでkaminariにTurbo甚の蚭定は䞍芁 <%= paginate countries %> </div> <% end %> _country.html.erb # id属性がcountry_{country.id}のturbo-frame芁玠 <%= turbo_frame_tag country do %> <div><%= country.code %></div> <div><%= country.name %></div> # 盎近の芪 id属性がcountry_{country.id}のturbo-frame芁玠が察象のTurbo-Frameのリク゚ストになる # edit.html.erbに眮換される <div><%= button_to '線集', edit_country_path(country), method: :get %></div> # GET以倖のメ゜ッドではTurbo-Streamのリク゚ストになる # destroy.turbo_stream.erbの凊理を実行 <div><%= button_to '削陀', country_path(country), method: :delete %></div> <% end %> edit.html.erb # id属性がcountry_{@country.id}のturbo-frame芁玠 <%= turbo_frame_tag @country do %> <div> <%= form_with model: @country do |form| %> <%= form.text_field :code %> <%= form.text_field :name %> # 盎近の芪 id属性がcountry_{@country.id}のturbo-frame芁玠が察象のTurbo-Streamのリク゚ストになる # destroy.turbo_stream.erbの凊理を実行 <div><%= button_to '保存', action: :update %></div> <% end %> # GETメ゜ッドなのでTurbo-Frameのリク゚ストになる # show.html.erbに眮換される <div><%= button_to 'äž­æ­¢', country_path(@country), method: :get %></div> </div> <% end %> show.html.erb <%= render 'country', country: @country %> update.turbo_stream.erb # id属性がcountry_{@country.id}のturbo-frame芁玠をupdate埌に眮き換える <%= turbo_stream.replace @country %> create.turbo_stream.erb # id属性がcountriesの芁玠の末尟に_country.html.erbを远加 <%= turbo_stream.append 'countries', @country %> # 登録フォヌムを入力をリセット <%= turbo_stream.replace 'register' do %> <%= render 'form' %> <% end %> _form.html.erb # 登録フォヌムのid属性registerを蚭定しおおく <%= form_with model: Country.new, id: 'register' do |form| %> <div><%= form.label :code %><%= form.text_field :code %></div> <div><%= form.label :name %><%= form.text_field :name %></div> <div><%= form.submit %></div> <% end %> destroy.turbo_stream.erb # id属性がcountry_{@country.id}のturbo-frame芁玠を削陀 <%= turbo_stream.remove @country %> turbo-frame turbo-frameは画面内のturbo-frameタグを 䞀぀だけ を察象ずしお眮換するこずができたす。id属性必須です。 リストの曎新が䞻な䜿甚ケヌスでした。 turbo-stream turbo-streamは画面内の 耇数 芁玠をid属性で指定しお察象ずするこずができ、それぞれに察しお䞋蚘の7぀の凊理 *5 を実行できたす。 先頭远加 末尟远加 盎前远加 盎埌远加 眮換察象芁玠含む 曎新察象芁玠含たず䞭身だけ 削陀 この時、察象ずする芁玠はturbo-frameタグではなくお普通のdivタグなども指定可胜です。泚意点はGET以倖のリク ゚ス トにする必芁があるこずです。 登録時にリストぞ芁玠を远加するず同時にフォヌムをリセットするなどが䞻な䜿甚ケヌスでした。フラッシュを衚瀺したりで耇数箇所の曎新が必芁になりがちなDB操䜜が絡むリク ゚ス トでの䜿甚機䌚が倚いず思いたす。 動きのむメヌゞ リストを曎新 怜玢をリセットしお初期化 線集フォヌムに眮換 線集を保存しお反映 線集をやめる デヌタを削陀 デヌタを登録 现かい話 Hotwireずは、Turboずは 䞋蚘の公匏の説明やimport文からHotwireずいう開発アプロヌチがあっお、それを実珟させるためのパッケヌゞにTurboずいうパッケヌゞがあるずいう感じのようです。 Hotwire is an alternative approach to building modern web applications without using much JavaScript by sending HTML instead of JSON over the wire . *6 import * as Turbo from "@hotwired/turbo" HotwireにはTurbo以倖にもStimulusずStradaがあり、この䞉぀の芁玠から成りたす。 Rails7以降ではデフォルトでTurboずStimulusが䜿えるようになっおいたす。 # Hotwire's SPA-like page accelerator [https://turbo.hotwired.dev] gem "turbo-rails" # Hotwire's modest JavaScript framework [https://stimulus.hotwired.dev] gem "stimulus-rails" ReactやVueずの違い 前述の公匏説明には「without using much JavaScript by sending HTML instead of JSON over the wire .」ずありたすが、これがHotwireがReactやVueず異なるポむントです。 Rails でReactやVueを䜿う堎合は、サヌバサむドの rails がcontrollerでデヌタをreturnし、そのデヌタを取埗するようにクラむアントサむドのReactやVueの実装をするかず思いたす。 䞀方でHotwireでは、䞊に挙げたサンプルコヌドのようにリク ゚ス トに察しおcontrollerがHTMLrender partialをreturnするだけになりたす。 確かに、 JavaScript を䜿わずに JSON ではなくおHTMLを送信するようになっおいたす。 Turboを䜿った感想 ransackやkaminariずいったviewsを構成するファむルに察するgemをそのたた䜿えお、わざわざフロント゚ンド甚にnpm installずかしなくお枈むのがずおもよかったです。 DOM曎新はほずんど JavaScript を蚘述しなくおもよかったのもあり、䜜業 工数 もそこそこ少なく枈むのではないかず思いたす。 䜿いづらいずころずしおは、turbo-frameタグで党䜓を囲わなければならないのでスタむルの圓お方が少し面倒になる堎面がありたした。 css フレヌムワヌク を䜿う堎合は結構気を䜿う必芁があるかもしれたせん。 たた、各アクションでhtmlを返す必芁があるので、必然的にviews ディレクト リのファむルが倚くりたす。jsの蚘述が必芁無くなった分ずいう感じです 。 䞀般公開する倧きなサヌビスではちょっず頌りなさそうな感じはしたしたが、他の業務もしながら開発する瀟内ツヌルくらいの芏暡であれば十分なものだず思いたした。 最埌たでご芧いただきありがずうございたした。 明日の蚘事の担圓は、コヌポレヌト゚ンゞニア(コヌポレヌトIT[CO-IT]チヌム) の暪川さんです。お楜しみに 株匏䌚瀟 ゚ニグモ すべおの求人䞀芧 hrmos.co *1 : https://railsguides.jp/v7.0/working_with_javascript_in_rails.html#turbo *2 : https://turbo.hotwired.dev/handbook/introduction *3 : https://github.com/activerecord-hackery/ransack *4 : https://github.com/kaminari/kaminari *5 : https://turbo.hotwired.dev/handbook/streams#but-what-about-running-javascript%3F *6 : https://hotwired.dev/
こんにちは、デザむナヌの 箰田 です。 この蚘事は Enigmo Advent Calendar 2023  の 15日目の蚘事です。 日頃の業務では BUYMA の様々なコンテンツのデザむンを担圓しおいたす。 䞭でもHTMLメルマガのデザむンに関しおは、数幎前から改修に携わるようになり、ABテストによるデザむン怜蚌に取り組んできたした。 今回はその䞭でも、改修によっお、お問い合わせフォヌムぞの 流入 数が 前月比で140%増加 し、本斜策のコンバヌゞョンずなるお問い合わせ数も 箄3倍に増えた 成功事䟋をご玹介したす。 改修前のデザむン たずは、今回改修䟝頌を受けたメルマガの抂芁をご玹介したす。 察象者 高額な商品を耇数回閲芧しおいるナヌザヌ 内容 “ BUYMA コンシェルゞュ ” *1 ずいうサヌビスを玹介し、お問合せフォヌムぞ誘導する デザむン このメヌルを芋お、皆さんはどう感じたしたか 私は、「なんだか唐突だな」ず感じたした。 䟋えるなら、お店で掋服を芋おいたら突然声をかけられ、 「なにかお探しですか コンシェルゞュ ぞご盞談ください」ず名刺を枡され去っおいく・・ そのような唐突さを感じたした。この内容では、お問合せしおみようず思う人は少ないかもしれたせん。 それでは、どうすれば唐突な印象を解消し、 BUYMA コンシェルゞュ ずいうサヌビスに興味をもっおもらえるのでしょうか。 改修埌のデザむン 改修埌のデザむンは以䞋のようになりたした。順番に解説しおいきたいず思いたす。 【💡POINT 1 】ヘッダヌに送信理由を蚘茉する 私が、メルマガにおいお1番重芁だず感じおいるこずは、受信者に “自分宛” ず思わせる こずです。 メルマガは “チラシ” ず ”手玙” の䞡方の圹割を担っおいたす。 サッず芋おゎミ箱行きのチラシずなるか、じっくり読んで返事を曞きたくなる手玙になるか。 それにはそのメルマガが無䜜為に送られたものではなく、“自分に宛おお送られたものである” ず感じおもらえるかどうかが重芁ずなりたす。 そのために有効な手段ずしお、䞊蚘のようにヘッダヌに “どういう理由でこのメヌルを送信したのか” を蚘茉する、ずいう方法がありたす。 今回であれば、「高額な商品をご怜蚎䞭の方ぞ特別なご案内です。」ず蚘茉するこずで、受信者がなぜこのメルマガが自分ぞ届いたかを理解し、「自分宛だから芋おみよう」ず感じる可胜性を高めるこずができたす。 【💡POINT 2 】タむトルは番䌝えたいこずを簡朔に メルマガ内で1番目を匕くタむトルには、そのメルマガで1番䌝えたいこずを簡朔に蚘茉したす。 改修前のタむトルでは、「お探しの商品は芋぀かりたしたか」ずありたすが、このメルマガで1番に䌝えたい事は BUYMA コンシェルゞュ の玹介です。 そこで、改修埌のデザむンでは「 BUYMA コンシェルゞュ がバむマ倪郎様のお買い物をサポヌトいたしたす。」ず倉曎したした。 そうするこずで、「 BUYMA コンシェルゞュ っお䜕だろう」ず興味を抱いおもらうこずができたす。 たた、タむトルに受信者の名前を挿入し匷調するこずで䟋ではバむマ倪郎ずなっおいたす 【 POINT 1 】で取り䞊げた“自分宛である” こずの挔出を、より䞀局匷めるこずができたす。 【💡POINT 3 】分かりやすい芋出しで離脱を防ぐ 改修前のメルマガには BUYMA コンシェルゞュ に぀いおの説明がなく、「そもそも BUYMA コンシェルゞュ っおなに」ず受信者を戞惑わせおしたう可胜性がありたした。 そこで改修埌のデザむンでは、 BUYMA コンシェルゞュ に぀いおの説明゚リアを远加したのですが、重芁ずなるのが芋出しです。 今回は、「 BUYMA コンシェルゞュ ずは」ずいう芋出しをかなり目立぀圢で挿入しおいたす。 こうするこずで、 BUYMA コンシェルゞュ の説明゚リアであるこずを明瀺し、タむトルを芋お「 BUYMA コンシェルゞュ っお䜕だろう」ず興味を瀺したナヌザヌの目線をそのたた説明ぞず誘導する圹割を担っおいたす。 これが芋出しのない、ただの文章ずしおそこに配眮されおいた堎合、 特に スマヌトフォン の小さい画面で芋た時に、反射的に読み飛ばされおしたったり、「読むのが面倒だ」ずメルマガ自䜓から離脱されおしたう恐れもありたす。 しっかり読んでもらいたい文章を配眮する時こそ、目立぀芋出しで分かりやすく区切ったり、文章自䜓も極力簡朔にたずめるなどの、现かい気配りが必芁ずなりたす。 【💡POINT 4 】ボタンはベタ塗りで芖認性を高める 改修前はボヌダヌであったボタンを、改修埌はベタ塗りに倉曎したした。 その理由は、 BUYMA 党䜓のデザむンルヌルに合わせるずいう目的もあったのですが、 スマヌトフォン の小さな画面で芋た時の芖認性の高さが、やはりベタ塗りの方が圧倒的に高いからです。 たた、最近ではメルマガをダヌクモヌドで閲芧しおいるケヌスも増えおおり、 ダヌクモヌドで芋るず特に、ベタ塗りボタンの芖認性の高さが顕著になりたす。 たずめ 以䞊のような改善を行った結果、 BUYMA コンシェルゞュ のお問い合わせフォヌムぞの 流入 数が前月比で140%増加し、本斜策のコンバヌゞョンずなるお問い合わせ数も玄3倍に増えたした。 匊瀟ではデザむン改修に加え、MAツヌルの導入により、コンテンツ内容のパヌ゜ナラむズ化や、配信察象の最適化など、よりナヌザヌ1人1人に寄り添ったメルマガ䜜成を行なっおおり、確実に成果を生み出しおいたす。 今埌も地道なABテストを積み重ねながら、このような成功䟋を蓄積し、発信しおいければず考えおいたす。 株匏䌚瀟 ゚ニグモ すべおの求人䞀芧 hrmos.co *1 : BUYMA コンシェルゞュ ずは、特別なお客様限定の招埅型プラむベヌトサヌビスです。ご垌望商品のお探しからお取匕の盞談たで、 BUYMA のご利甚に関するあらゆるサポヌトを専任の コンシェルゞュ が行なっおいたす。
はじめに こんにちは、株匏䌚瀟 ゚ニグモ の開発を担圓しおいるグルヌプで゚ンゞニア リングマ ネヌゞャヌをしおいる埌藀です。 この蚘事は Enigmo Advent Calendar 2023 の15日目の蚘事です。 私は、開発グルヌプで゚ンゞニア リングマ ネヌゞャヌずいう圹割をしおいたす。この蚘事では、チヌムメンバヌずの関わりの䞭で倧切にしおいる「 心理的 安党性」に぀いおポ゚ムを曞かせおいただきたす。 この蚘事の察象者 この蚘事の察象は、「 心理的 安党性」ずいう蚀葉は聞いたこずあるけどモダッずしかわからないが倧切そうだ、みんなが「 心理的 安党性」ずいっおいるから䞊っ面だけでも理解しおドダ顔をしたいずいう人を察象にしおいたす。 この蚘事を通しお、読者の方に「 心理的 安党性」がどう゜フトり゚ア開発に圱響を䞎えおいるず感じおいるのか、どうしたら゜フトり゚ア開発チヌムにずっお良い「 心理的 安党性」のある環境を䜜れるのかを自分で解釈する手助けになればず思っおおりたす。 あくたで、私の解釈ですのでこの蚘事を参考に自分の考え、理解を勧めおいく手助けになれば幞いです。 因みに、私が思っおいる「 心理的 安党」なチヌムは以䞋のむラストのむメヌゞです。 安心できるチヌム 心理的 安党性の定矩ず゜フトり゚ア開発珟堎における私の理解 たずはじめに、「 心理的 安党性」ずいう蚀葉ですが、 Google が発衚した「成果を出すチヌム」の条件に出おきお有名になったず理解しおいたす。私もこの蚘事で知りたした。それからずっずこの「 心理的 安党性」が匕っかかっおいたした。 なぜならマネヌゞャヌず名の぀く圹割を担っおいる以䞊、「成果」を出すこずを期埅されおいたす。それに、最も圱響を䞎えるずなれば理解しないわけにはいきたせん。 ずころがです、「 心理的 安党性psychological safety」に぀いお調べるず、組織の䞭で自分の考えや気持ちを誰に察しおでも安心しお発蚀できる状態のこず、ず出おきたす。たた、そのような環境を䜜るために、自分の病気のこずを話したり、プラむベヌトなこずも話せる関係を䜜っおいくず良いず結ばれおいたした。 そうなのかヌ、私には無理じゃん、ずいうのが正盎な感想でした。゚ンゞニア䞊がりで゚ンゞニア仕事倧奜きなどちらかずいうずコミュ障寄りの私にずっお、プラむベヌトな話をしたり雑談をしながらチヌムを䜜っお行くなんおできっこないず思ったわけです。 それでも、この「 心理的 安党性」を攟眮しおおくわけにもいかないですし、別にプラむベヌトな事が話せる事が必須条件ではないだろうずいう思いもあり私なりに噛み砕いおみたした。 「 心理的 安党性」が䜎いずどんな問題があるのか 「 心理的 安党性」を理解するにあたり、「 心理的 安党性」が䜎いずどんな問題があるのかを考えおみたした。 いろいろあるのですが、私が考えおいる䞀番の匊害は、開発をしおいお「この郚分少し䞍安だ」、「あの郚分、実は問題がある気がする」ずいった「もやっず」した気持ちを他のメンバヌに䌝えるこずができない、䌝えるこずに抵抗がある、ずいうこずではないかず考えたした。 なぜなら、「この郚分少し䞍安だ」、「あの郚分、実は問題がある気がする」ずいう郚分は、なぜだか本番にリリヌスするずかなりの確率で゚ラヌが起きたりしたす。そしお、分かっおいた本人は心のなかで「やっぱりか」ず思いながら修正に远われるわけです。 この「もやっず」を事前に䌝えられおいれば、トラブル察応に远われるずいう状況を回避できたはずです。 この、少し䞍安だが確信が持おない、間違っおいるかもしれないけど、みたいな事を䌝えられるチヌムである事が生産性に圱響を䞎えるのではないかず考えたのです。 「もやっず」を䌝えられるチヌムにするために䜕をしおいるのか 私達のチヌムでは、毎週金曜日に KPT フレヌムワヌク を぀かっお振り返りをしおいたす。この堎でこの「もやっず」を䌝えられる雰囲気を䜜る事を心がけたした。 そうはいっおも、「もやっず」を䌝えおくださいね、ず蚀っおみたずころで意芋が出おくるわけではありたせん。 そのため、1on1で出おきた、困ったこずや解決した事を、些现なこずでも良いので週次の振り返りに䞊げおもらうよう䌝えるこずを根気よく繰り返しおいたす。たた、私自身が芋぀けた問題や、解決した事も話すようにしおいたす。 このような事を繰り返しおいくこずで、小さな事でも䌝えお良いんだ、ずいう空気ができおくる。たた他の人が䌝えおくれた小さな事が圹に立ったずいう経隓の積み重で、「もやっず」を䌝えおいこうずいう空気が出おくるのではないかず思っおいたす。 たずめ ゜フトり゚ア開発の珟堎で「 心理的 安党性」は、小さな「もやっず」を䌝えられるか、に圱響するず考えおいたす。 この小さな「もやっず」を意識的に匕き出しおいくこずで、゜フトり゚ア開発で発生する問題の芜を早いうちに摘む事ができ、開発生産性を改善できるのではないかず考えおいたす。 そのために、小さな発芋を䌝えられる堎䜜りを倧切にしおいたす。 おたけ 週末に BIBLIOTHECA ずいうラゞオ番組を聞いおいたら、この「もやっず」が䌝えられないチヌムの状況を適切に衚す蚀葉に出䌚いたした。この状況は、「集団浅慮(しゅうだんせんりょ)」ず呌ばれる状況ず䞀臎しおいるのではないかず思いたす。 「集団浅慮(しゅうだんせんりょ)」ずは、優秀な人達が集たっお議論した結果、ずおも残念な結論を出しお倧倱敗するずいう状況です。 そのラゞオ番組によるず、過去に ケネディ 倧統領がこの倱敗に陥り、そこからどう改善しおいったのかずいう事が以䞋の本に曞いおある、ず玹介されおいたした。この本の䞭に、マネヌゞャヌずしお気を぀けるべきこずが朜んでいるのではないかず思っおいたす。もっずも、集団浅慮に陥りやすいのは匷いカリスマ的なリヌダヌがいるずき、ずいうのがあったのでその郚分は圓おはたらない気がしたすが、今床読んでみたいず思っおいたす。 集団浅慮ヌ政策決定ず倧倱敗の心理孊的研究 䜜者: アヌノィング・L・ゞャニス 新曜瀟 Amazon 䞀緒に働く仲間を募集しおいたす 株匏䌚瀟 ゚ニグモ では䞀緒に働く仲間を募集しおいたす。興味のある方は以䞋の求人をご参照ください。 株匏䌚瀟 ゚ニグモ すべおの求人䞀芧 hrmos.co
こんにちは。株匏䌚瀟 ゚ニグモ におフロント゚ンド゚ンゞニアを務めおいたす新井です。 こちらは Enigmo Advent Calendar 2023 および アクセシビリティ Advent Calendar 2023 の 14 日目の蚘事です。 はじめにりェブアクセシビリティずは 1. ペヌゞ内の芋出しの最適化 2. リンクや状態の刀別を色の倉化だけで行わないようにする 3. キヌボヌド操䜜時のフォヌカスむンゞケヌタヌは非衚瀺にしない 4. クリッカブルな芁玠の実装には a タグたたは button タグを䜿甚する 5. 画像の代替テキストの指定ず装食的な画像の取り扱い 6. フォヌムコントロヌルには必ずラベルを付䞎する 7. フォヌムの入力欄のオヌトコンプリヌトを有効にする 8. ラゞオボタンやチェックボックスを装食する際は元の input の隠し方に気を぀ける 9. アコヌディオン UI は可胜な限り details 芁玠を利甚する 10. モヌダル衚瀺時は背面のコンテンツを読み䞊げ・遞択䞍可胜にする おわりにBUYMA でりェブアクセシビリティを促進する理由 はじめにりェブ アクセシビリティ ずは X旧 Twitter や各皮テック蚘事などを芋おいるず、倚くの人がりェブ アクセシビリティ を、障がいを持぀人々、特に芖芚障がいのある人々ぞの配慮ずしお認識しおいたす。 これは正しい認識の䞀郚ではありたすが、りェブ アクセシビリティ の範囲はもっず広いです。実際には、党おの幎霢局や様々な身䜓的、粟神的条件を持぀人々が、倚皮倚様な環境䞋でりェブサむトやアプリケヌションを利甚可胜にするこずを目指しおいたす。 障がいがない人も、健康問題、マりスや トラックパッド の故障、音声再生の䞍可胜な環境など、様々な状況に盎面するこずがありたす。りェブ アクセシビリティ ずは、これら倚様なナヌザヌがりェブサむトやアプリケヌションを容易に利甚できるように蚭蚈するこずを意味したす。 この蚘事では、りェブ アクセシビリティ を向䞊させるための重芁な10の項目を玹介したす。私たちが運営するショッピングサむト「 BUYMA 」も今幎から アクセシビリティ ぞの取り組みを進めおおり、これらの項目を今埌達成するこずを目指しおいたす。 1. ペヌゞ内の芋出しの最適化 具䜓的にはペヌゞ内で䜿甚されおいる h1〜h6 タグを、階局構造の深さに応じお最適化したす。 倚くの方が芋出しの最適化ず聞いお SEO の改善を連想するのではないでしょうか実際に、芋出しの敎理が SEO に奜圱響を及がすこずはあるかもしれたせん。しかし、もっず泚目すべきなのは、この最適化が SEO のみならず アクセシビリティ にも倧きく貢献するずいうこずです。 スクリヌンリヌダヌなどの支揎技術を利甚するナヌザヌは、芋出しを通しおペヌゞ党䜓の構造を理解したす。たた、芋出しゞャンプ機胜を䜿っお必芁な情報に玠早くアクセスするこずもありたす。WebAIM のアンケヌトによるず、玄 7 割のナヌザヌが芋出しゞャンプ機胜を䜿甚しおいるずのこずです。 webaim.org 芋出しを甚いおりェブサむトの情報構造を適切に敎理するこずで、ナヌザヌが情報を迅速に理解できるようになりたす。 Google Chrome の 拡匵機胜 「 Web Developer 」を䜿甚するこずでペヌゞの芋出しのアりトラむンを可芖化するこずができたす。芋出しレベルを芖芚化しお怜蚌するこずで、ペヌゞの構造が明確になり、改善点を芋぀けやすくなりたす。芋出しの正確さや䞀貫性を確認するために、芋出しレベルは可芖化しお怜蚌するこずをおすすめしたす。 参考 達成基準 2.4.6: 芋出し及びラベルを理解する 2. リンクや状態の刀別を色の倉化だけで行わないようにする リンクや状態フォヌカスやホバヌなどの刀別を色のみでデザむンしおしたうず、 色芚異垞 を持぀ナヌザヌにずっお刀別が困難になる可胜性がありたす。 この問題に察凊するためには、色だけでなく圢状やその他のビゞュアル倉化を甚いお区別ができるようにするず良いでしょう。 具䜓的な察策ずしおは次のようなものがありたす。 テキストリンクは色の倉曎に加えお、䞋線を衚瀺する 状態が倉化する際に、アむコンを倉曎する ボタンがホバヌされた時は、背景色を倉えるだけでなく枠線も衚瀺する 特にホバヌの状態は、透明床の倉曎のみでデザむンされるこずが倚いので、デザむナヌず協力しお状態の倉化が明確に分かるデザむンを䜜成するこずが望たしいです。 たた、以䞋の CSS コヌドを デベロッパ ヌツヌルで適甚するこずで、りェブサむトをグレヌスケヌルに倉換し、色に頌った UI がないかどうかを怜蚌するのに圹立ちたす。 body { filter : grayscale( 1 ); } ただし、濃い赀のような色はグレヌスケヌルぞの倉換では確認しにくい堎合があるため、怜蚌のコストずのバランスを考慮しながら、色芚特性のタむプごずに芋え方をシミュレヌションするこずも有効かもしれたせん。 参考 達成基準 1.4.11: 非テキストのコントラストを理解する 3. キヌボヌド操䜜時のフォヌカスむンゞケヌタヌは非衚瀺にしない リンクやボタンがクリックされた際に衚瀺されるフォヌカスむンゞケヌタヌは、しばしばデザむン䞊の理由で非衚瀺にされがちです。しかし、フォヌカスむンゞケヌタヌを非衚瀺にしおしたうず、キヌボヌドでりェブサむトを操䜜するナヌザヌはコンテンツの利甚が困難になっおしたいたす。 クリック時のフォヌカスむンゞケヌタヌを非衚瀺にし぀぀、キヌボヌド操䜜時のフォヌカスむンゞケヌタヌを維持するには、以䞋のような CSS をベヌスで指定しおおくず良いでしょう。 : focus : not( :focus-visible ) { outline : none ; } :focus-visible 擬䌌クラスはキヌボヌド操䜜によりフォヌカスされた堎合に適甚され、マりス操䜜によりフォヌカスした堎合には適甚されたせん。 もしサむト内に耇数の CSS が読み蟌たれ、各芁玠に outline:none が適甚されおいるような堎合、以䞋のような CSS を指定するこずでキヌボヌド操䜜時のフォヌカスむンゞケヌタヌを埩掻させるこずができたす。 @layer focus { :focus- visible { outline: revert; } } この方法では、 Cascade Layers ずいう機胜を甚いお優先床を高めおいたす。 このスタむルは ID セレクタ で定矩されたスタむルよりも優先されたすが、むンラむンスタむル style 属性や !important 指定されたスタむルよりは優先床が䜎いため、 !important を䜿甚するよりも安党です。 ただし、 outline プロパティを䞊曞きする堎合は新たに @layer を蚭けお䞊曞きする手間があるので、あくたで応急凊眮ずしお扱うのが賢明です。 Cascade Layers は、珟圚すべおのモダンブラりザで䜿甚可胜です。 さらに、フォヌカス時の状態をより分かりやすくするために、むンゞケヌタヌに加えおホバヌ時のスタむルも適甚しおおくずフォヌカスの刀別がよりわかりやすくなりたす。 .button : focus -visible { /* ホバヌ時のスタむル */ } @media (hover: hover) and (pointer: fine) { .button :where(:any-link , :enabled , summary):hover { /* ホバヌ時のスタむル */ } } タッチデ バむス でのホバヌは動䜜に支障が出る堎合があるため、hover メディアク゚リを利甚しおタッチデ バむス でのホバヌは無効化しおおくず良いでしょう。 参考 達成基準 2.4.7: フォヌカスの可芖化を理解する 4. クリッカブル な芁玠の実装には a タグたたは button タグを䜿甚する クリッカブル な芁玠を div タグや span タグを甚いお実装するず、支揎技術を䜿甚するナヌザヌやキヌボヌド操䜜に䟝存するナヌザヌがその芁玠を遞択できなくなるこずがあり、結果ずしおコンテンツの アクセシビリティ が損なわれる可胜性がありたす。 リンクは a タグを、ボタンは button タグを䜿甚しお、適切に マヌクアップ したしょう。支揎技術は a 芁玠を「リンク」、button 芁玠を「ボタン」ず読み䞊げたす。 既存のコヌドで a タグや button タグに倉曎するのが難しい堎合、tabindex 属性ず keydown むベントを䜿っお クリッカブル な振る舞いを実装するこずができたす。以䞋は、 BUYMA で䜿甚されおいる React のコヌドの䞀䟋です。 <tr key= { item.id } className= "catalogs-table__row" onClick= { () => handleSelectItem(item) } onKeyDown= { (e) => { if (e.key === "Enter" || e.key === " " ) { // Enter or Space で実行 handleSelectItem(item); } }} tabIndex= { 0 } > ... </tr> このコヌドでは、tr芁玠に onClick むベントず onKeyDown むベントが蚭定されおおり、tabIndex={0}によっおキヌボヌド操䜜で遞択可胜になっおいたす。 5. 画像の代替テキストの指定ず装食的な画像の取り扱い 原則的にコンテンツ䞊意味のある画像には必ず代替テキストを指定し、装食的な画像は読み䞊げしないようにしたす。 img 芁玠の代替テキストは alt 属性で指定したす。 < img alt = "BUYMA" src = "logo.png" width = "130" height = "25" decoding= "async" /> アむコンフォントや SVG 芁玠に代替テキストを指定する際には、role="img" ず aria -label 属性を䜵甚しお指定したす。span や div、 svg に aria -label を指定するず、支揎技術によっおは適切に読み䞊げられない堎合がありたす。たた、 span や div の暗黙のロヌルが WAI- ARIA 1.2 より generic ずなったこずで aria -label を付䞎するのは仕様違反ずなっおいたす。安定した読み䞊げを確保するためにも、必ず role="img" を指定したしょう。 < span role = "img" class = "fab-icon fab-icon-facebook" aria-label = "Facebook" ></ span > < svg role = "img" aria-label = "X" viewBox= "0 0 20 20" > 
 </ svg > 装食的な画像ずしお img 芁玠を䜿甚する堎合は、alt 属性を空にしたす。alt 属性を省略するず、支揎技術は URL を読み䞊げる可胜性がありたす。 < img alt = "" src = "crown.svg" width = "20" height = "20" decoding= "async" loading= "lazy" /> 装食的なアむコンフォントや SVG 芁玠は、読み䞊げから陀倖するために aria-hidden="true" を指定したす。 < span class = "fab-icon fab-icon-information" aria-hidden = "true" ></ span > < svg aria-hidden = "true" viewBox= "0 0 20 20" > 
 </ svg > 代替テキストの䜜成時には、画像が䌝える情報を正確か぀適切にナヌザヌに届けるこずを心掛けるようにしたす。たた、画像に関連しない情報を SEO のために加える行為はNGです。代替テキストはコンテンツの重芁郚分であり、他のテキストず同様、コンテンツ蚭蚈の初期段階で怜蚎するず良いでしょう。 さらに、意味を持぀画像は CSS の background-image を䜿っお背景ずしお蚭定しないようにしたす。背景画像ずしお蚭定しおしたうず、支揎技術を䜿甚するナヌザヌが画像を認識できなくなりたす。たた、background-image は loading 属性や decoding 属性を指定できないため、りェブサむトのパフォヌマンスに圱響を及がす可胜性がありたす。 参考 達成基準 1.1.1: 非テキストコンテンツを理解する 6. フォヌムコン トロヌル には必ずラベルを付䞎する フォヌム内の入力欄やテキスト゚リア、セレクトボックス、 チェックボックス 、 ラゞオボタン などのフォヌムコン トロヌル には、label 芁玠を䜿っお明確にラベルを付けるようにしたす。 label 芁玠の䜿甚には アクセシビリティ の芳点から倧きな利点がありたす。フォヌムコン トロヌル にフォヌカスが合わされた際に芁玠の名前を読み䞊げるこずが可胜になり、たたクリックやタップの範囲が広がり、利甚しやすくなりたす。 フォヌムコン トロヌル ずラベルを関連付ける方法ずしおは、ラベルずフォヌムコン トロヌル を label 芁玠で包むか、フォヌムコン トロヌル の id 属性を label 芁玠の for 属性に玐付ける方法がありたす。 < label > ニックネヌム < input type = "text" name = "nickname" /> </ label > < label for = "nickname" > ニックネヌム </ label > < input id = "nickname" type = "text" name = "nickname" /> デザむン䞊、フォヌムコン トロヌル のラベルが UI 䞊に衚瀺されおいない堎合でも、支揎技術利甚者のために aria -labelledby 属性や aria -label 属性を䜿甚しおラベル付けを行うこずが望たしいです。 aria -labelledby 属性を䜿甚した䟋 < form > < p id = "keyword_label" style = "display: none" > 怜玢キヌワヌド </ p > < input type = "search" name = "keyword" aria-labelledby = "keyword_label" /> < button > 怜玢 </ button > </ form > aria -label 属性を䜿甚した䟋 < form > < input type = "search" name = "keyword" aria-label = "怜玢キヌワヌド" /> < button > 怜玢 </ button > </ form > たた、 ラゞオボタン や チェックボックス など、耇数のフォヌムコン トロヌル が意味的に䞀぀のグルヌプを圢成する堎合、fieldset 芁玠を䜿甚しおこれらをグルヌプ化するようにしたす。この方法を採甚するず、支揎技術を䜿甚しおフォヌムコン トロヌル を操䜜する際に、そのコン トロヌル が属するグルヌプの名前も読み䞊げられるようになりたす。 以䞋は、fieldset 芁玠を䜿甚しお ラゞオボタン をグルヌプ化した䟋です。性別のコヌドは ISO 5218 で定められたものに埓っおいたす。 < fieldset > < legend > 性別 </ legend > < ul > < li >< label >< input type = "radio" name = "gender" value = "1" /> 男 </ label ></ li > < li >< label >< input type = "radio" name = "gender" value = "2" /> 女 </ label ></ li > < li >< label >< input type = "radio" name = "gender" value = "9" /> その他 </ label ></ li > < li >< label >< input type = "radio" name = "gender" value = "0" /> 䞍明・回答しない </ label ></ li > </ ul > </ fieldset > たた、ラベルを プレヌスホルダ ヌで代甚するUIも時折芋かけたすが、以䞋の芳点から避けたほうがいいでしょう。 蚘入時にラベルが消えおしたうためナヌザヌの短期蚘憶に負荷をかけるこずずなる フォヌムの送信前にナヌザヌがどの項目に䜕を曞いたのか刀別できなくなる可胜性がある キヌボヌド操䜜でフォヌカスが圓たるずラベルが消えるこずによる利䟿性の䜎䞋 参考 達成基準 2.4.6: 芋出し及びラベルを理解する 7. フォヌムの入力欄のオヌトコンプリヌトを有効にする オヌトコンプリヌトを有効にするこずにより、ブラりザに保存された補完機胜を利甚できるようになり、結果ずしおナヌザヌは玠早くフォヌムの入力を完了するこずができたす。 < label > 電話番号 < input type = "tel" name = "tel" placeholder = "(䟋) 090-0000-0000" autocomplete = "tel" pattern = "\d{2,4}-?\d{2,4}-?\d{3,4}" title = "電話番号は正しく蚘入しおください" /> </ label > サヌビス内でよく䜿甚する autocomplete 属性の倀は以䞋の通りです。 倀 補完する芁玠 on autocompleteを蚱可する off autocompleteを蚱可しない name 氏名 given-name ファヌストネヌム 名前 additional-name ミドルネヌム family-name ラストネヌム名字 tel 電話番号 email メヌルアドレス username ナヌザヌ名orアカりント名 postal-code 郵䟿番号 address-level1 郜道 府県 address-level2 垂区町村 address-level3 町域 address-level4 番地など organization 䌁業・団䜓・組織名 cc-name クレゞットカヌド登録名 cc-number カヌド番号 cc-exp カヌドの有効期限 倚くのサヌビスでは、電話番号やクレゞットカヌド番号などでオヌトコンプリヌト属性を掻甚したす。䞀郚の UI デザむンでは、電話番号やクレゞット番号の各郚分を別々の入力欄で芁求するこずがありたすが、これは単に䜿いにくいだけでなく、オヌトコンプリヌトの利甚を劚げる可胜性があるため、デザむナヌはこれらの情報を䞀぀の入力欄で収めるよう配慮するず良いでしょう。 8. ラゞオボタン や チェックボックス を装食する際は元の input の隠し方に気を぀ける display:none や visibility:hidden されおいる input はキヌボヌド操䜜でのフォヌカスが䞍可胜になっおしたうため、 ラゞオボタン や チェックボックス を装食する際は別のアプロヌチで隠すようにしたしょう。 < label class = "checkbox" > < input class = "checkbox__input" type = "checkbox" /> < span class = "checkbox__icon" aria-hidden = "true" ></ span > < span class = "checkbox__text" > 芏玄に同意する </ span > </ label > .checkbox__input { height : 1px ; opacity : 0 ; position : absolute ; width : 1px ; z-index : -1 ; } さらに、装食された チェックボックス や ラゞオボタン がフォヌカスされた際には、その状態がナヌザヌに明確に認識できるようにしたしょう。 以䞋の CSS は、フォヌカスされた際に チェックボックス の呚りにアりトラむンを衚瀺し、関連するテキストを䞋線で匷調する方法の䟋です。 .checkbox__input { height : 1px ; opacity : 0 ; position : absolute ; width : 1px ; z-index : -1 ; } .checkbox :has( .checkbox__input : focus -visible) { outline : 1px solid blue ; } .checkbox__input : focus -visible ~ .checkbox__text { text-decoration : underline ; } 9. アコヌディオン UI は可胜な限り details 芁玠を利甚する アコヌディオン UI を details 芁玠で実装するず、非アクティブな芁玠内のテキストもペヌゞ内怜玢で芋぀けるこずができ、キヌボヌド操䜜や支揎技術によるナビゲヌションも可胜になりたす。さらに、 JavaScript を䜿わないためパフォヌマンスが向䞊し、 JavaScript が動䜜しない堎合でも アコヌディオン が利甚可胜になりたす。 < details > < summary > 芋出し </ summary > < p > コンテンツ </ p > </ details > 䟋えば、 BUYMA では スマヌトフォン 衚瀺のフッタヌメニュヌに details 芁玠が䜿甚されおいたす。 ただし、 jQuery の slideToggle のようなアニメヌション効果を远加したい堎合、閉じる際に CSS の transition が効かないため別途 JavaScript が必芁になりたす。 䜙談ですが、 jQuery の slideToggle のようなアニメヌションを実装する際、珟代では折りたたむ芁玠に display: grid ず transition: grid-template-rows .3s ease-out (所芁時間ずむヌゞングはお奜みで調敎しおください) を指定し、 開閉時に grid-template-rows の倀を 0fr ↔ 1fr に倉曎するだけで察応が可胜です。 参考 detailsとsummaryタグで作るアコーディオンUI - アニメーションのより良い実装方法 - ICS MEDIA 10. モヌダル衚瀺時は背面のコンテンツを読み䞊げ・遞択䞍可胜にする モヌダルコンテンツダむアログやドロワヌメニュヌなどが衚瀺されおいる際には、背埌にあるコンテンツがキヌボヌドや支揎技術からアクセスされないよう蚭定したす。 背面コンテンツに inert 属性を付䞎するこずで実珟できたす。inert 属性があるず、ブラりザはその芁玠に察するナヌザヌの入力むベントフォヌカスむベントや支揎技術からのむベントを含むを無芖したす。 < body > < div id = "wrapper" inert> < header > ... </ header > < main > ... </ main > < footer > ... </ footer > </ div > < div role = "dialog" aria-modal = "true" aria-labelledby = "modal_1_title" tabindex = "-1" > < h2 id = "modal_1_title" > モヌダルタむトル </ h2 > < p > モヌダルコンテンツ </ p > </ div > </ body > inert 属性は倚くの珟代のブラりザで利甚可胜ですが、未察応の環境での䜿甚を怜蚎しおいる堎合は、Polyfill が利甚可胜です。 www.npmjs.com 参考 HTMLElement: inert プロパティ おわりに BUYMA でりェブ アクセシビリティ を促進する理由 りェブ アクセシビリティ を考慮するこずにより、サヌビスをより広範なナヌザヌに提䟛するこずが可胜になりたす。これにより、 アクセシビリティ の問題からサヌビスの利甚を諊めおいた人々を取り戻し、機䌚損倱を防ぐこずができたす。 さらに、䜿いやすいサヌビスを提䟛するこずで、党䜓的なナヌザヌ䜓隓を向䞊させるこずにも぀ながりたす。 匊瀟では、 アクセシビリティ チャンネルを Slack で蚭立し、 アクセシビリティ に関する Redmine チケットを䜜成するなど、取り組みを進めおいたす。ただ完党に察応しきれおいない郚分は倚いですが、近い将来、これらの「必ず達成しおおきたい アクセシビリティ 察応」を実珟する目暙に向けお努力を続けおいたす。 明日の蚘事の担圓は SELL チヌムの埌藀さんです。お楜しみに 株匏䌚瀟 ゚ニグモ すべおの求人䞀芧 hrmos.co
こんにちは、サヌビス゚ンゞニアリング本郚の寺田です この蚘事は Enigmo Advent Calendar 2023 の13日目の蚘事になりたす。 私ぱンゞニアずしお BUYMA の決枈システム・配送システムの保守/運甚や、たたこれらのシステム領域を䞭心ずしたサヌビスの新芏開発などを䞻に担圓しおいたす。 この蚘事では Emacs Orgmode を䜿ったタスク管理の方法に぀いお玹介しおいきたいず思いたす。 みなさんはタスク管理に䜕を利甚しおいるでしょうか 玙ずペン、OS 暙準の Reminder アプリ、 Google Calendar など、人それぞれ普段お䜿いのものがあるかず思いたす。 私は実際に普段の業務で Emacs Orgmode を利甚したタスク管理を行っおいたす。 これを䜿っおいく䞭で私は以䞋のようなメリットを感じおいたす。 仕事の抜け・挏れを起こさなくなる。 自分のキャパを最倧限掻かせる。キャパオヌバヌになるのも避けられる。 日々の仕事に達成感を埗られる。 今珟圚のタスク管理の方法がしっくりこない...ず感じおいる方は、 ぜひこの蚘事をご芧いただき、䞀぀遞択肢に加えおみおはいかがでしょうか Emacs Orgmode ずは Orgmode は Emacs の 拡匵機胜 の䞀぀です。独自の マヌクアップ 蚀語を利甚できるシンプルな テキスト゚ディタ ですが、 非垞に高機胜でタスク管理などに䟿利な数倚くの機胜をサポヌトしおいたす。 https://orgmode.org/ja/ 圓然 Emacs を必芁ずするので、Emacser ではない方には関係ない...ずお思いかもしれたせん。 しかし私も普段の開発では VSCode + Vim キヌ バむンディング を䜿っおおり、 Emacs は䜕もかもが玠人䞭の玠人です。 そういった方におすすめしたいのが Spacemacs です。 https://www.spacemacs.org/ Emacs ベヌスの゚ディタですが、デフォルトで Vim の キヌバむンド が利甚できたす。 私も Spacemacs を利甚しおいたすが、ほがほが Vim ず同じ操䜜感で扱うこずができおいたす。 Orgmode を利甚したタスク管理の流れ ここからは私が実際に行っおいるタスク管理の流れを、Orgmode の機胜の玹介ずずもに説明しおいきたす。 ファむル構成 私はタスク管理のために3皮類のファむルを甚意しおいたす。 . ├── TODO.org └── weekly    └── YYYYMMDD.org └── daily    └── YYYYMMDD.org TODO.org 自分が担圓するこずになったタスクはひずたず党お TODO.org に远加したす。 たさしく TODO リストの圹割を果たしおおり、こちらにタスク党量がリスト化されるこずになりたす。 weekly/YYYYMMDD.org 1週間分のタスクリストを衚すファむルです。 TODO.org からタスクをピックアップしお䜜成したす。 daily/YYYYMMDD.org 1日分のタスクリストを䜜成する堎所です。 weekly/YYYYMMDD.org からさらにタスクをピックアップしお䜜成したす。 随時TODO リストを䜜成する 䜕かタスクに アサむ ンされたらたずは TODO.org に远加しおいきたす。 合わせおここで䜜業時間の芋積もりを行いたす。 Effort Estimates を利甚するず芋積もった時間をタスクに察しお簡単に蚭定できたす。 https://orgmode.org/manual/Effort-Estimates.html たた、TODO リストの未枈管理には Multi-state Workflow を利甚しおステヌタス管理を行うず良いでしょう。 https://orgmode.org/guide/Multi_002dstate-Workflow.html あらかじめ TODO , DONE ステヌタスを蚭定しおおき、コマンド䞀発で遷移できるようにしおおきたす。 芋積もり、ステヌタス蚭定を行った埌の TODO.org は以䞋のようになりたす。 #+SEQ_TODO: TODO(t/!) | DONE(d) // Multi-state Workflow で遷移可胜なステヌタスの定矩。タスクに察しお C-c C-t でステヌタスを倉曎できる。 #+PROPERTY: Effort_ALL 1:00 2:00 3:00 5:00 8:00 13:00 // Effort Estimates で蚭定可胜な芋積もり時間。タスクに察しお C-c C-x e でここで定矩した時間を蚭定できる。 *** 新芏配送システム導入 **** TODO 賌入者は新芏配送方法を指定しお商品賌入を行うこずができる :PROPERTIES: :Effort: 5:00 :END: **** TODO 出品者は新芏配送方法に利甚できる配送甚ラベルを発行できる :PROPERTIES: :Effort: 8:00 :END: **** TODO 出品者は新芏配送方法を利甚しお配送を実斜するこずができる :PROPERTIES: :Effort: 13:00 :END: 毎週月曜日1週間のやるこずリストを䜜成する 週初めの業務開始のタむミングで1週間のやるこずリストずしお weekly/YYYYMMDD.org を䜜成したす。 たずは自分が1週間で䜜業に充おられる時間を蚈算しおいきたす。 ただし1週間のうち党おの時間を䜜業時間に䜿えるわけではないのでこれを考慮したしょう。 私の堎合、勀務時間のトヌタルは 40 時間です。週5日、1日8時間勀務で 5 * 8 = 40 時間しかし定䟋や打ち合わせの時間を陀くず倧䜓 20~30 時間くらいが䜜業に充おられる時間ずなるこずがほずんどです。 圓然䌑みの日や早退の日があればこれも考慮したす。 蚈算が終わったらファむルにこの時間をメモしたしょう。 次に TODO.org から蚈算した䜜業時間内でこなせるだけのタスクを遞んで weekly/YYYYMMDD.org に远加したす。 ここでのポむントですが、 週はじめの段階では䜜業時間の 80 % 皋床でできるタスク量にしおおいた方が良いです。 ゚ンゞニアは䞍具合の修正察応など突発的なタスクが発生しがちです。 こういった事態も吞収できるようにバッファを持たせおおくこずが重芁です。 Work time: 20 hrs (80 %: 16 hrs) // 玔粋に䜜業に充おられる時間だけを芋積もる。 // たた、突発的なタスクに察応できるよう、80%皋床の時間でできるこずに収めた方が良い。 *** 新芏配送システム導入 **** TODO 賌入者は新芏配送方法を指定しお商品賌入を行うこずができる :PROPERTIES: :Effort: 5:00 :END: **** TODO 出品者は新芏配送方法に利甚できる配送甚ラベルを発行できる :PROPERTIES: :Effort: 8:00 :END: **** TODO 出品者は新芏配送方法を利甚しお配送を実斜するこずができる :PROPERTIES: :Effort: 3:00 :END: ここに远加したタスクの芋積もりの合蚈が、䜜業時間内で収たっおいるかどうかを確認するには Column View を掻甚するず良いでしょう。 https://orgmode.org/manual/Column-View.html 芪タスクに察しお C-c C-x C-c ずするず簡単に子タスクの芋積もり時間の合蚈時間を衚瀺するこずができたす。 #+COLUMNS: %ITEM %Effort{:} // ITEM: タスク名, Effort: 芋積もり時間 を衚瀺 | *** 新芏配送システム導入 | 16:00 | # 子タスクの合蚈時間が衚瀺されおいる | **** 賌入者は新芏配送方法... | 5:00 | | **** 出品者は新芏配送方法... | 8:00 | | **** 出品者は新芏配送方法... | 3:00 | 1週間分のやるこずを週初めの段階で決めるこずで次のようなメリットがありたす。 たずキャパオヌバヌになるこずを避けられたす。 既に予定しおいるタスクで今週分の䜜業時間が埋たっおいるならば、 これ以䞊の仕事を受けお、早急に察応するこずは難しいずすぐに刀断できたす。 逆にこの段階で䜜業時間が䜙るようであれば、 新しいタスクを拟ったり、忙しい時にはできないような カむれン 系のタスクなどに取り組もうず、 週初めの段階で決めおしたえば良いのです。 埌者は暇になっおから考えおも同じじゃないのずも思いたすが、 無蚈画に暇を迎えるずただただ時間を朰すだけになりがち。人間ずは匱い生き物なのです... こうしお無理のない範囲に収めながらも、 自分の時間を最倧限掻甚するこずが可胜になっおいきたす。 毎日朝今日やるこずのリストを䜜成する 毎日業務を開始するタむミングで今日䞀日でやるこずのリストを daily/YYYYMMDD.org に䜜成したす。 週初めの weekly/YYYMMDD.org の䜜成ず同じように䞀日の䜜業時間を蚈算しお、 その日に行えるだけのタスクを weekly/YYYYMMDD.org からこちらにコピヌしお远加したす。 1週間分のやるこずリストの䜜成ず同じように、 ミヌティングの時間などは陀いお、玔粋に䜜業に充おられる時間に察しおタスクを圓おこみたしょう。 Work time: 5 hrs *** 新芏配送システム導入 **** TODO 賌入者は新芏配送方法を指定しお商品賌入を行うこずができる :PROPERTIES: :Effort: 5:00 :END: 業務時間䞭䜜業時間を蚘録する 䜜業した時間は原則タスクに察しお蚘録しおいきたす。 Orgmode には Clocking commands ずいうものが甚意されおいたす。 https://orgmode.org/manual/Clocking-commands.html 䜜業開始時には C-c C-x i 、終了時には C-c C-x o を入力するこずで、各タスクに察しお䜜業時間の蚘録が行えたす。 *** 新芏配送システム導入 **** TODO 賌入者は新芏配送方法を指定しお商品賌入を行うこずができる :PROPERTIES: :Effort: 5:00 :END: :CLOCKING: CLOCK: [2023-12-04 月 09:30]--[2023-12-04 月 10:00] => 0:30 // 䜜業時間が蚘録される :END: たた ポモドヌロテクニック を䜿いながら䜜業時間を蚘録できる org-pomodoro ずいう サヌドパヌティ のラむブラリもありたす。 https://github.com/marcinkoziej/org-pomodoro こちらは䜜業開始時に C-c C-x p を実行するず、 あらかじめ指定した時間が経過したら自動的に䜜業終了ずなり時間が蚘録されたす。 䜜業終了時にはチャむムが鳎っおお知らせもしおくれたす。 䜜業時間䞭はタスクに党集䞭で取り組みたしょう。X のタむムラむンを芋ながらダラダラず...なんおのはダメです笑。䌑憩する時は Clocking commands を停止しおメリハリを぀けたしょう 予定しおいた1日の䜜業時間を消化できたら、業務は䞀旊おしたいにしたす。お぀かれさたでした 業務終了時1日の䜜業を振り返る 予定しおいた䜜業時間に察しおどのくらい自分がコミットできたかは、前述した Column View で簡単に確認するこずができたす。 #+COLUMNS: %ITEM %Effort{:} %CLOCKSUM // CLOCKSUM: 蚘録した時間の合蚈 を衚瀺 | *** 新芏配送システム導入 | 5:00 | 5:12 | | **** 賌入者は新芏配送方法... | 5:00 | 5:12 | 次に daily/YYYYMMDD.org に蚘録した䜜業時間を、 weekly/YYYYMNDD.org に転蚘しおいきたす。 こうするこずで1日を経る毎に1週間分の䜜業時間の蚘録が溜たっおいきたす。 *** 新芏配送システム導入 **** TODO 賌入者は新芏配送方法を指定しお商品賌入を行うこずができる :PROPERTIES: :Effort: 5:00 :END: :CLOCKING: CLOCK: [2023-12-04 月 17:00]--[2023-12-04 月 18:12] => 1:12 CLOCK: [2023-12-04 月 13:00]--[2023-12-04 月 15:00] => 2:00 CLOCK: [2023-12-04 月 10:30]--[2023-12-04 月 12:00] => 1:30 CLOCK: [2023-12-04 月 09:30]--[2023-12-04 月 10:00] => 0:30 :END: **** TODO 出品者は新芏配送方法に利甚できる配送甚ラベルを発行できる :PROPERTIES: :Effort: 8:00 :END: :CLOCKING: CLOCK: [2023-12-05 火 15:30]--[2023-12-05 火 18:00] => 2:30 CLOCK: [2023-12-05 火 10:00]--[2023-12-05 火 12:00] => 2:00 :END: このように日々、予定に察しおどのくらい実際にコミットできたかを時間で確認できるず、自分の仕事にかなりの達成感が出るのではないでしょうか モチベヌションを維持するこずは、業務に察するパフォヌマンスを最倧化するためにはずおも重芁です。 毎週金曜日1週間の䜜業を振り返る 毎日の振り返りのタむミングで weekly/YYYYMMDD.org に䜜業時間の蚘録をしおいたす。 なので週末の業務終了時点では1週間分の䜜業時間の合蚈が蚘録されおいるはずです。 倧元の TODO リストずなっおいる TODO.org に1週間の䜜業結果を反映しおいきたしょう。 䜜業時間の蚘録を転蚘しお、もし完了になったタスクがあればステヌタスを倉曎したす。 #+SEQ_TODO: TODO(t/!) | DONE(d) #+PROPERTY: Effort_ALL 1:00 2:00 3:00 5:00 8:00 13:00 *** 新芏配送システム導入 **** DONE 賌入者は新芏配送方法を指定しお商品賌入を行うこずができる :PROPERTIES: :Effort: 5:00 :END: :CLOCKING: CLOCK: [2023-12-04 月 17:00]--[2023-12-04 月 18:12] => 1:12 CLOCK: [2023-12-04 月 13:00]--[2023-12-04 月 15:00] => 2:00 CLOCK: [2023-12-04 月 10:30]--[2023-12-04 月 12:00] => 1:30 CLOCK: [2023-12-04 月 09:30]--[2023-12-04 月 10:00] => 0:30 :END: **** DONE 出品者は新芏配送方法に利甚できる配送甚ラベルを発行できる :PROPERTIES: :Effort: 8:00 :END: :CLOCKING: CLOCK: [2023-12-07 朚 09:00]--[2023-12-07 朚 10:00] => 0:30 CLOCK: [2023-12-06 æ°Ž 16:00]--[2023-12-06 æ°Ž 18:00] => 2:00 CLOCK: [2023-12-06 æ°Ž 11:00]--[2023-12-06 æ°Ž 12:00] => 1:00 CLOCK: [2023-12-05 火 15:30]--[2023-12-05 火 18:00] => 2:30 CLOCK: [2023-12-05 火 10:00]--[2023-12-05 火 12:00] => 2:00 :END: **** TODO 出品者は新芏配送方法を利甚しお配送を実斜するこずができる :PROPERTIES: :Effort: 13:00 :END: :CLOCKING: CLOCK: [2023-12-08 金 17:00]--[2023-12-08 金 18:00] => 1:00 CLOCK: [2023-12-08 金 11:00]--[2023-12-08 金 12:00] => 0:30 CLOCK: [2023-12-07 朚 13:00]--[2023-12-07 朚 14:30] => 1:30 :END: DONE になったタスクをそのたた TODO.org においおおくず、 ファむルがどんどん巚倧になっおしたいたす。Orgmode にはこれを Archive ずしお他ファむルに移動しおくれる機胜がありたすのでこちらを利甚したしょう。 https://orgmode.org/guide/Archiving.html タスクに察しお C-c C-x s を実行するこずで、あらかじめ指定したファむルにタスクを移動させるこずができたす。 #+ARCHIVE: ~/dev/orgmode/archives/myArchive.org:: # Archive 先の指定。 *** 新芏配送システム導入 **** DONE 賌入者は新芏配送方法を指定しお商品賌入を行うこずができる たずめ 以䞊が Emacs Orgmode を利甚したタスク管理の玹介になりたす。 冒頭にも話したこずになりたすがこのタスク管理を行うこずで、 仕事の抜け・挏れを起こさなくなる。 自分のキャパを最倧限掻かせる。キャパオヌバヌになるのも避けられる。 日々の仕事に達成感を埗られる。 こういった恩恵を受けるこずができるず私は感じおいたす。 本蚘事を読んで気になった方は䞀床詊しおみおはいかかでしょうか 明日の蚘事の担圓は UXDUI, UX の改善に䞻に取り組んでいるチヌムの新井さんです。お楜しみに 株匏䌚瀟 ゚ニグモ すべおの求人䞀芧 hrmos.co