こんにちは、エンジニアの川本です。 主に BUYMA の決済・配送を担当しているチームでバックエンドの開発をしています。 この記事は Enigmo Advent Calendar 2023 の 6 日目の記事です。 昨今の生成AIブームでChatGPTが注目を集めておりますが、私もChatGPTを積極的に業務に活用しています。毎日ChatGPTに質問することが当たり前になりつつあります。 今回は、実際の業務でChatGPTと Google Apps Script（GAS）を組み合わせてデータ収集を効率化できた事例を紹介します。 背景 弊社では各 バッチ処理 の実行時間が規定の時間よりも長い場合に Gmail でアラートメールを送信するシステムが稼働しているのですが、ある案件で過去数ヶ月のアラートデータを参照する必要が生じました。 しかし、アラートデータはDBに保存されておらず、 Gmail に直接送信されているため、 SQL で直接データを参照することが難しい状況でした。 DBに新しいテーブルを作成してアラートデータを保存する案も検討しましたが、データが十分に蓄積されるまでには半年近く時間がかかりそうでした。 長期的な解決策としては有用かもしれませんが、今回は案件の都合で即座にデータが必要でした。そこで、 Gmail に送信されたアラートメールからGASを利用してデータを抽出し、 スプレッドシート にまとめる方法を考えることにしました。 とはいえGASは未経験だったので1から調べながら実装するのは手間だなと感じ、物は試しにChatGPTに実装させてみました！ ChatGPT✖︎GASの活用 実際にChatGPTに入力したプロンプトと、ChatGPTが出力したGASについて紹介します。 ChatGPTに入力したプロンプト あなたのGmailのメールボックスには以下のフォーマットのメールが届いています。 2023年1月1日から2023年3月30日までに届いた下記メールからバッチ名（batch_id）、実行状態（run_status）のデータを抽出し、 スプレッドシートにまとめるためのGoogle Apps Scriptを作成してください。 # メールのフォーマット ## メールタイトル `[CRITICAL]過去1時間止まっているバッチを検出` ## メール本文 過去1時間エラーで停止しているか、実行し続けているバッチを検出しました。 状態を確認してください。 | batch_id | start_date | run_status | | Batch1 | Aug 17 2023 04:51PM | ERROR | | Batch2 | Aug 17 2023 10:01AM | RUNNING | | Batch3 | Aug 17 2023 01:04AM | RUNNING | | Batch4 | Aug 17 2023 15:04AM | ERROR | ChatGPTが作成したGAS function extractStopBatchIdStatusPair() { // メールタイトル var subjectQuery = "[CRITICAL]過去1時間止まっているバッチを検出" ; // 対象期間 var startDate = "2023/01/01" ; var endDate = "2023/03/30" ; // 対象期間のアラートメールを取得するクエリ var query = "subject:" + subjectQuery + " after:" + startDate + " before:" + endDate; // メールスレッドを取得 var threads = GmailApp.search(query); // スプレッドシートを指定 var spreadsheet = SpreadsheetApp.openById( "スプレッドシートID" ); var sheet = spreadsheet.getSheetByName( "シート名" ); sheet.clearContents(); // 抽出したアラートデータ var values = [] ; // メールスレッドごとに処理 for ( var i = 0; i < threads.length; i++) { var thread = threads [ i ] ; var messages = thread.getMessages(); // メッセージごとに処理 for ( var j = 0; j < messages.length; j++) { var message = messages [ j ] ; var body = message.getPlainBody(); var subject = message.getSubject(); // メール本文から正規表現で対象データ抽出 var tableMatches = body.match(/ \ | ( [ ^ \ | ] +) \ | ( [ ^ \ | ] +) \ | ( [ ^ \ | ] +) \ |/g); if (tableMatches) { for ( var k = 0; k < tableMatches.length; k++) { var tableRow = tableMatches [ k ] .split( "|" ).map(item => item.trim()); // batch_id var batchId = tableRow [ 1 ] ; // run_status var runStatus = tableRow [ 3 ] ; values.push( [ batchId, runStatus ] ); } } } } // データをスプレッドシートに一括で書き込む if (values.length > 0) { sheet.getRange(2, 1, values.length, 2).setValues(values); } } ChatGPTが作成したGASの実行結果 以下のように期待通りに スプレッドシート にデータが出力されました！ まとめ ChatGPTが生成するGASの精度は期待以上であり、ゼロからGASを調査・実装する手間を考えると、非常に時間を節約でき、効率的であると感じました。 また、高い精度の出力を得るためには、入力するプロンプトの内容が重要であることがわかりました。詳細に要件を整理し、適切なプロンプトを作成することで、ChatGPTによる出力もより精度が向上します。 初めての試行で高い精度を達成できなかったとしても、修正や リファクタリング の要望を的確に伝えることで、最終的には期待通りの結果を得ることができます。 今後は、プロンプトの適切な書き方を学びつつ、より高い精度の出力を得る方法を探求していきたいと考えています。 明日の記事はT&Sチームの杉山さんが担当しますので、お楽しみに！ 株式会社 エニグモ すべての求人一覧 hrmos.co

こんにちは、データアナリストの井原です。 この記事は Enigmo Advent Calendar 2023 の 5日目の記事です。 この記事では、不正対策のデータ分析から 機械学習 モデルの導入を決定した経緯についてご紹介します。 私は普段、データアナリストとして BUYMA の様々な業務にデータ分析担当としてかかわっています。 分析内容は施策の効果検証、ユーザーの行動分析、売れ筋商品の分析など マーケティング 的な要素が多く、ビジネス判断の正確性を上げることを目的とした業務が多いです。 機械学習 については、ある程度の知識と経験もありますが、本職のデータサイエンティストが社内にいることもあり、どちらかといえば、統計検定や因果推論などの手法を使用することが多いです。 ただ、今回は、不正対策をしているチームからの不正検知の精度を上げたいという相談があり、検証の結果として 機械学習 モデルを導入しようという結論になりました。 本記事では、その経緯について詳しくお伝えしたいと思います。 なお、この記事では、立ち上がり～検証内容の決定～検証実行と、検証を進めていったプロセスにフォーカスして記載します。 分析内容の詳細（プログラム、 アルゴリズム の説明など）は記載しませんので、ご了承ください。 依頼の経緯 近年、多くの ECサイト で決済の不正利用の被害が増えています。 決済の不正利用とは、フィッシングなどの悪質な手段によって他者のクレジットカード情報やサービスのログイン情報を不正に取得し、それを利用して換金性の高い商品を購入しようとする犯罪行為です。 BUYMA では、高額なブランド品が新品で購入できるということもあり、一 定量 、こういった不正利用による被害が発生してしまう状況にあります。 対策として、不正利用を防止するためのチームが社内に存在しており、日々対応を行なっています。 今回、そのチームから以下の依頼をデータ活用推進室にいただきました。 これまで、チームの知見を元に、不正疑いのある取引を検知する条件をルールベースで設定し、条件に該当した取引を一時的に止めて確認する（以下、買付保留 *1 ）という対応を行っていた。 近年、不正利用のパターンが多様化してきており、不正の事前検知の難易度が上がってきている。 蓄積したナレッジとデータを活用し、データから不正な取引を止めることが出来ないか？ ということで、こちらの依頼に自分が アサイ ンされ、データから不正検知を行うことが出来るか？を検証してみることになりました。 分析の進め方の策定 最初に実施したこととしては、検証内容を整理することです。 データ分析に関わっている方は想像つくと思いますが、分析のステップの中でおそらく一番重要なステップになります。 ここで、何を知りたいのか？それを知るための適切な方法は何なのか？を徹底的に考え、ビジネス側（今回は不正対策のチーム）と合意する必要があります。 目的は不正の早期検知ができることと明確でしたので、ここでは、検証方法について以下の3点を整理し、ビジネス側に提示しました。 精度の測り方 分析手法 検証に使用するデータ ひとつづつ、見ていきます。 1.精度の測り方 今回の案件では、精度をどのように定義するのか？が要所の一つでもありました。 単純に考えると、不正な取引を何件検知できたか？が指標になるように思われます。 この考え方であれば解決は簡単です。全ての取引を買付保留にしてしまえばよいのです。 全ての取引を買付保留にして、全て不正かどうかをチェックすれば、理論上、不正はすべて止められます。 しかし、当然ながらこの方法は取れません。 全ての取引を不正疑いとしてチェックすることはコスト的に現実的ではないですし、ユーザー からし ても取引完了までの時間が長くなるため、 ユーザビリティ ーが下がってしまいます。 今回のような検証内容の場合、見るべき指標は二つあります。 不正と予測した取引が実際に不正である確率（以下、買付保留的中率） 不正である取引を不正と検知できる確率（以下、検知成功率） ちなみに、 機械学習 の二値分類タスクでこの指標はよく出てきます。 （それぞれの指標は 機械学習 の言葉では適合率、再現率と言います。詳細は書きませんが二値分類の指標は他にも色々あったりしますので、知っておくだけでも便利です。） 図にしてみると以下のようになります。 買付的中率と検知成功率 基本的に、この指標は片側を改善すると片側が悪化する傾向があります。 例えば、検知成功率を上げるためには、買付保留の数を増やす必要がありますが、（きれいに不正だけを検知することは基本ないので）母数が増えて買付保留的中率は下がります。 検知成功率をあげようとしたときのイメージ 逆も同様で買付保留的中率は、基本的に母数を減らすことになるので検知成功率が下がります。 買付保留的中率をあげようとしたときのイメージ このあたりをどのラインで許容できるかは、ケースバイケースになります。 本ケースでも、二つの指標を総合的に見ながら、ビジネス側と方針を詰めていくこととしました。 2.分析手法 指標を決めましたので、どのように精度を改善していくか？という手法の選択に移ります。 選択肢としては、以下の二つの手法を考えました。 決定木分析で重要な要素を抽出し、ルールベース案を検討する。 LightGBMで 機械学習 モデルを構築し、不正予測スコアから推定する。 検証内容的に 機械学習 モデルを使った方が、精度は改善するだろうという感覚がこの時点でありました。 しかし、それでもルールベース案の検討を入れたのは、コスト的な観点からです。 経緯にも記載した通り、これまでも不正対策のチームではルールベースで買付保留を行うという運用を行ってきていました。 つまり、ルールベースであれば、すでにあるその運用に乗せることができ、開発などのコストも少なく短い期間での対応が可能でした。 一方の 機械学習 は全社での活用歴はいくつもあるものの、不正対策への適用は初めてでしたので、検証はともかく実行環境の構築にはコストも時間もかかります。 そのため、ルールベースでそれなりの精度改善が見込めるのであれば、わざわざ 機械学習 環境を構築する必要がなくなるというコスト的メリットがあるのです。 3.検証に使用するデータ 最後に検証に使用するデータの決定です。 幸いなことに、これまでの不正対策の取り組みのおかげでログは蓄積されていましたので、どの取引が不正だったのかという実データを使うことが出来ました。 過去ログは「学習用データ」と「検証用データ」に分割しました。 これは、学習させたデータでそのまま精度を検証すると精度が過剰に高く出て検証にならないので、学習させていないデータで検証を行う必要があるためです。 また、最新の1ヶ月のデータは、完全に学習用データから除外しました。 不正というのは一人の不正者が不正を一つだけ行うというものではないため、過去のデータ同士だとランダムに分割しても類似パターンを学習してしまう可能性があります。 そのため、未知のデータに対応しても精度がよいか検証する必要があり、最新1ヶ月分はそれ用の検証用データとしました。 まとめると以下のようなイメージになります。 データの用意 分析の実行 検証方法をビジネス側と合意しましたので、ここからは分析を実行していきます。 前項で書いた通り、「決定木分析からルールベース案の検討」と「LightGBMを使った 機械学習 モデルの構築」を行っていきます。 1.決定木分析からルールベース案の検討 途中の作業は省略しますが、決定木分析を行うと以下のようなアウトプットが出てきて、どのような変数・ 閾値 で分割すると、不正とそうではない取引をうまく見分けることが出来るかを可視化してくれます。 ※変数名や結果はダミーです。 決定木分析のイメージ 決定木の結果をそのまま使ったわけではないですが、重要そうな要素と 閾値 を見ながらルールベース案を4つほど作成しました。 また、決定木自体も予測を行うことが出来ますので、決定木によるモデル推定というパターンも用意しました。 これら5つのパターンと既存のパターン、合計6パターンについて、全組み合わせ（63パターン）での予測結果と精度を算出しました。 具体的な数字は出せませんが、この時点でモデル推定の精度が突出していました。 単純なモデル推定と既存パターンの比較では、買付保留的中率が数倍レベルで大きく改善し、検知成功率もかなり改善していました。 つまり、より少ない買付保留の数で多くの不正を検知することが、（シミュレーション上ですが）可能になったということになります。 また、モデル推定に既存ルールベースを組み合わせると、買付保留的中率は多少下がりますが検知成功率が大きく改善しました。 上記3つだけのイメージ図を書くと以下のようになります。 モデル推定と既存パターンの比較イメージ この結果からは、 機械学習 モデルの導入に対する期待値が高まりました。 決定木分析は精度があまり高くないと言われている手法ですので、この後実施するLightGBMならより改善するのでは？とも思えました。 また、指標を事前にすり合わせていたことで、この時点で数字を使った会話ができるようになりました。 数字は仮のものですが、例えば、以下のように整理ができます。 既存パターンでは1,000件買付保留を行い100件の不正検知が出来ている。 モデル推定＋既存パターン＋新ルール案すべてでは、5,000件買付保留を行い、200件の不正検知が出来る。 モデル推定＋既存パターン＋新ルールA案のみでは、2,000件買付保留を行い、195件の不正検知が出来る 数字でイメージがつくので、例えば、買付保留が5倍になっても不正検知を最大化するのか？多少の不正検知数が減っても、買付保留は2倍までに抑えたいか？などの議論を行うことができました。 2.LightGBMを使った 機械学習 モデルの構築 続いて、LightGBMを使って、 機械学習 モデルを構築しました。 ※LightGBMとはなんぞや？という説明は省略します。非常にメジャーな 機械学習 モデルですので、興味ある方は調べてみてください。 こちらは、シンプルに（LightGBMによる）モデル推定、既存パターンのみ、モデル推定＋既存パターンで精度を比較しました。なお、決定木と比較するとやはりLightGBMのモデル推定の方が精度は高くなっていました。 ※予測スコアの 閾値 の検証なども行っていますが、これも省略しています。 最終的な結果だけ記載しますが、モデル推定＋既存パターンでは既存パターンと比較して不正検知率が大幅に改善し、買付保留的中率もそれなりに改善することが確認できました。 買付保留件数も増加していたのですが、ビジネス側で許容範囲と確認いただきました。 コスト面を考えても大きな改善が見込めると検証できたので、 機械学習 モデルの導入に向けてプロジェクトが動くことになりました。 まとめ 本ケースで行った検証の大まかな流れは以上になります。 機械学習 モデルを実際に導入するには時間がかかるため、検証したルールベースの中で精度のよいものをまず導入し、 機械学習 モデルの導入は順次進めている状況になります。 今回は、明白な結果の差が出たため、導入の判断をすぐに行うことが出来ました。 機械学習 の精度がすごいというのはありますが、それとあわせてログとナレッジが大量に溜まっていたことが成功要因でした。 「Garbage in, garbage out」という言葉があります。 精度の高い アルゴリズム でも、ゴミデータを入れればゴミデータしか出てこないという意味ですが、今回は良質なデータのおかげで良質な結果がアウトプットされたと思います。 過去の取り組みまではデータアナリストはなかなか介入できません。 データアナリストとしては、これまでのビジネス側の蓄積された過去のナレッジをうまく ヒアリ ングして、データに変換していくスキルが重要かと思いますが、それらがうまくマッチした事例になれたのではないかと思いました。 本日の記事は以上になります。最後まで読んでいただきありがとうございました。 明日の記事の担当はエンジニアの川本さんです。お楽しみに。 株式会社 エニグモ すべての求人一覧 hrmos.co *1 : ※ BUYMA はCtoCの買付代行サイトのため、多くの場合、注文が入ったあとに出品者が商品を買い付けています。万が一、不正利用だった場合、商品買い付け後にキャンセルになると余分な在庫が発生してしまうため、取引のチェックを行うまで、出品者の方に一時的に買い付けを待ってもらう対応が「買付保留」という仕組みです。買付保留となる取引は確定した不正とは別物です。買付保留は不正疑いというニュアンスで読み進めていただくと分かりやすいと思います。

こんにちは、SE本部の hashino です。 現在、2年目の新卒入社のエンジニアです。BUY Domainに所属しており、 BUYMA の購入者向け機能を開発しています。 この記事は Enigmo Advent Calendar 2023 の 4 日目の記事です。 みなさんは振り返りをしていますか？ 週ごとや月ごと、年単位......振り返りの頻度や粒度は人によってさまざまだと思います。 仕事の進捗や自己成長を確認し、改善点を見つけるためには振り返りは不可欠です。 エニグモ の開発部門の新卒やジュニアは、YWT方式で毎週振り返りをおこなっています。 詳しくは以下の記事をご覧ください。 tech.enigmo.co.jp この記事では、振り返りが苦手で週の振り返り記事の作成にとても時間がかかっていた私が実践した振り返りの手法とその結果とともに紹介していきます。 前提として、できるだけ技術的なこと以外にも仕事のやり方などを振り返ることが推奨されています。 例えばわかったことに Rubyにこのような仕様があることを知った。 だけ書いてしまうのは次のアクションにつながりにくく非推奨です。 振り返りの作成をその都度していく。 振り返り記事を週末に一気に書くのではなく、日々気づいたことをその都度まとめておくことで、時間の節約になります。 私の結果: 最初は順調でしたが、徐々に習慣が薄れ、日報との二重作業に疲れてしまいました。 私には微妙でした。 第 三者 目線になる。 自分ごととして捉えると何に気付けたのか、何が悪かったのかがわからなくなりませんか？ 自分の仕事を客観的に見ることができるようになるために、第 三者 目線で振り返ります。 同じ悩みをもった後輩に今週の仕事をより良くするためのアド バイス を自分だったらどう声を掛けるかなどと考えるといいかもしれません。 私の結果: 成功や良い点を記述することが難しく感じましたが、失敗に焦点を当てると自分に合っているやり方でした。 振り返りの目的を忘れない 何か書かなければいけない〜！と焦ってしまい、余計になにも書けないことはありませんか？ 振り返りは書くことが目的ではなく、自己成長や仕事の進捗を把握する手段です。 私の結果: 焦らず、冷静に振り返りの目的を忘れないように心がけました。 何を伝えたいかを明確にし、それに基づいて振り返りを進めることで、メンターとの振り返りでは有益な情報を得られるようになりました。 たくさん書いてフィードバックをもらう 振り返りの内容を先輩やチームの人と共有し、フィードバックを得ることが重要です。 新たな気づきや改善点が見つかります。 よかったことも悪かったこともどんなことでも書いてみましょう！ 私の結果: もう少し書いてほしい！と言われても、最初は何を書けばよいのか戸惑いました。 しかし、小さな工夫や日々の取り組みを積極的に記述するようになりました。 私がどういう取り組みをして結果がどうであったかという記録が残っていくので、自分の傾向がわかるようになりました。 少しずつ振り返りが早くなり、自分の仕事の仕方の傾向を理解できるようになりました。 振り返りははじめこそ手間がかかるかもしれませんが、継続することで大きな成果を生むことができます。 同じような悩みを抱える方には、この経験が少しでも参考になれば幸いです。仕事の振り返りは、自分の成長を促進するための重要なステップであることを肝に銘じています。 株式会社 エニグモ すべての求人一覧 hrmos.co

こんにちは、エンジニアの岡本です。 主に BUYMA の出品者向け機能のサーバーサイドの開発を行っています。 この記事は Enigmo Advent Calendar 2023 の1日目の記事です。 今年の アドベントカレンダー は生成AIの話題が各所でたくさん提供されると思いますが、私はソフトウェア開発における見積り、そして私がプロジェクトの計画を立てる上で実践していることについてご紹介しようと思います。 プロジェクト当初になんとなく立てた見積りが甘くて、リリース予定日が近づいているのに差し込みタスクが発生したり不備が発覚したりで、当初のスケジュールから遅れを出し、精神的に苦しい思いをしてしまうという経験が私にはあります。 見積りと計画立てに科学的なアプローチを取り入れたいという思いから、まず先人の知恵を求めました。 見積りを科学的に解説する本を探していたときに「ソフトウェア見積り　人月の 暗黙知 を解き明かす」という名著と出会いました。 ソフトウェア見積り　人月の暗黙知を解き明かす 作者: スティーブ マコネル 日経BP Amazon 通読した時点で、自身の経験と照らし合わせた上で以下の感想を持ちました。 100%正確な見積もりは不可能 3点見積りなどはちゃんとやろうとするのは難易度が高そう… なんでも良いので、各タスクの規模感をカウントできるようにすると良いらしい これらの感想を持った上で、以下では実際に現場で工夫して取り組んでいることを紹介します。 作業スケジュールを立てる上での工夫 タスクを切ってコードを書くだけではないので、以下の工程もスケジュールに組み入れるようにしています。 プロジェクト開始時点で「QA」「QA過程で判明した不具合修正」「リリース作業」もサイズを見積もっておく 遅れることはあっても、早まることは基本的にないということで1~2週間程度作業バッファを初めから入れておく 見積もりに慣れていなかった頃、この二つをやっていなかったために失敗したことがありましたが、これらを意識するようになってからは大幅にスケジュールがずれることは無くなった感覚があります。 ストーリーポイント 人月などを試したことがありますがいい感触でなかったので、ストーリーポイントを使ってみることにしました。 プロジェクト管理方法はJiraで行っています。Jiraは見積もりという観点においては「ストーリーポイントが定義できる」という点が良いと思っています。 基準となるタスクを決めて、それを2ポイントと定義しています。フィボナッチ数に基づいて、振り返りミーティングにてスプリント計画を行うときに各タスクにポイントを割り振っています。基準タスクよりもすぐ完了できそうなら1ポイント、それよりも1日くらいプラス必要なら3ポイント、1スプリント（今のチームでは1週間）内で完結できるなら5ポイントという感じです。 1個のタスクに当てられるポイントの最大値は13と決めているのですが、大体のタスクは2~5ポイントくらいになるように分割されています。 私がいるチーム（squad）ではおよそ1年以上試行錯誤をしながらこのような方針でスケジュールを管理するようになっています。もしかしたら他にもいい方法があるかもしれないですが、その場合は適切にアップデートしていきたいと思っています。 現時点での結論 100％正確な見積りは不可能であると割り切った上で、各タスクの規模を数えられる形で単位化する という考えのもと、スプリントを計画・実行しています。 見積りの重要性を理解しつつも、実装の正確性やスピードの向上に焦点を当てることがソフトウェアエンジニアにとって重要な課題であると考えています。 私からは以上です。お読みいただきありがとうございました。 明日の記事は採用チームの 廣島 さんが登場します。 株式会社 エニグモ すべての求人一覧 hrmos.co

～「Committee・新開発体制」導入後の成果と魅力～ 目次 新開発体制について 新開発体制導入の背景／なぜこのような体制にしたのか 新体制導入後に感じている進化や手ごたえ 当社エンジニア組織の魅力・キャリア まとめ エニグモ のエンジニア組織の新しいマネジメント体制と、新開発体制についてCOOの安藤、エンジニア リングマ ネージャー（EM）の木村・山本にインタビューした記事の続編です。 前編は、Committee体制（エンジニア組織をCTOや部長を頂点とするワントップ型ではなく、EM陣で構成する「Committee」という合議体を意思決定のトップ機関）ができた経緯や、どのような体制でエンジニア組織を運営しているかを中心にお話ししました。 後編は、エンジニア組織全体がどのような体制になり、 エニグモ のプロダクトを開発しているのか、実際に新しい体制になりどのような効果があったのか、当社エンジニア組織の魅力やキャリアなどについてお話しします。 前回の記事はこちらです。 tech.enigmo.co.jp 新開発体制について 大谷： Committee体制の取り組みの第一弾として、エンジニア組織・開発体制をDomain、Squad、Chapter体制（以下、新開発体制）に移行したかと思います。後編ではまずは、新開発体制の概要についてお聞きできればと思います。 木村： エンジニアの新開発体制は、実態としては チームトポロジーの概念( Spotifyモデル) を参考に組織設計しました。 プロダクトの開発を担う機能別のDomain( ドメイン )と呼ばれるチームがあり、それをさらに細分化・構造化する形で、縦割りチームのSquad(スクワッド)や、横串チームのChapter(チャプター)があります。 Squadは事業的なミッションが与えられ、そのミッション達成に向けたシステムについてオーナーシップを持ちます。システムの全開発ライフサイクル（設計、開発、テスト、本番化、運用、不具合対応など）を担当します。 Chapterは、Squadの中でも特定の専門分野を担当するメンバーを横串に束ねた組織です。Squadに所属しながらSquad外でも、テクニカルな改善・基盤整備を独自に実施します。 ※新開発体制の詳細は下記記事でまとめていますのでご覧いただければと思います。 tech.enigmo.co.jp 新開発体制導入の背景／なぜこのような体制にしたのか 大谷： Committee体制の中で、なぜこのような新体制を構想したのかについて背景をお聞かせください。 木村： トップの役割をCommittee体制に引き継ぐ際に、開発組織はトップに依存せず、各チームに裁量を持たせ、自律的に成長・進化し続けることで、ビジネス課題を迅速に解決できる組織としたいという考えがありました。 各組織・チームに裁量を持たせるためには、各組織・チームが担うべきロール(役割)を改めて明確に定義し直す必要があると考えました。 その中で最適な組織の形は何かを考えた結果、この新開発体制が上手くフィットしました。 安藤： 以前から エニグモ では、ビジネスメンバー、ディレクター、エンジニアが、Oneチームで同じ事業課題解決に向かってプロダクト開発する「ユニット」体制がありました。昔からどういった体制がベストであるかを模索していた中で、この1、2年でDomainやSquadとして再定義し、メンバーを アサイ ンして、継続的にプロダクトを磨いていこうという体制になったと記憶しています。 山本： そうですね。Squadはもともと Spotify のSquadモデルを参考にしたり、「ユニット」の考え方を応用して、一部のチームでは導入していました。Squadの領域を定義し、リーダーを決め、縦に割って効率化しつつもSquad間でも横で連携して取り組もうという体制がありました。 また、ミッションが類似・関連しているSquadを束ねたDomainという考え方も以前からありました。 Committee体制を導入するタイミングで、木村さんがトップの役割を棚卸した際に、以前からあったDomainやSquadをより 言語化 ・明確化することで、上手くかみ合ったのかなと思います。 もともとはChapterの概念は省いていましたが、専門のロールをChapterとして整備し取り入れました。 安藤： Committee体制で進めることで、組織的にどのような体制で進めるのが自然であるかを改めて考える良い機会となりました。 トップの仕事は属人的であるということに気づき、トップが変わったとしても、組織を存続させるためには、こういうCommittee体制というハコ(仕組み)でやるのが自然だよねとなり、新開発体制へと昇華されました。 新体制導入後に感じている進化や手ごたえ 大谷： Committee体制、新開発体制の導入後に感じる手ごたえはどうでしょうか？ 木村： 手ごたえとしては、各メンバーが裁量を持ち、且つ負担がかかりすぎない良い体制で、元々のコンセプト通りに運営できているように感じます。 私はCommittee Headですが、HeadというのはあくまでCommitteeの中の役割で私がタッチしていない部分も多いです。そんな中でも、トップ(Head)に依存しすぎず、各メンバーが決めた持ち場でしっかり役割を担っていただいていると感じます。 山本： マネージャーやSquadリーダー同士での話し合う機会が増えてました。 例えば「開発で、今こういうことをやっていて、ちょっと相談したいんですけど」みたいな話は、Squad Weekly（Squadのリーダー以上が参加するミーティング）でしており、他のチームリーダーにも意見や相談ができます。 開発に関わること以外でも、「採用はどうしましょうか？」「組織をもっとこうしたい」「チームのマネジメントについて相談したい」といった話題はCommittee体制になりより話すようになりました。 大谷： 経営側からみて、安藤さんが感じる「ここらへんが変わり始めたな」というところはありますでしょうか。 安藤： すでに明確に変わっていると感じるところはあり、今まで 言語化 されていなかった組織やチームの役割やミッションが「こういうチームを目指していきたい」としっかりと 言語化 され、クリアになりました。そのことで、経営やビジネス的な視点で意思決定する際も説得力が持てるようになりました。 例えば、本来は優秀なメンバーは機能開発に アサイ ンしたいところです。直近立ち上がった（技術的な課題を解決する）チームも「Squadメンバーの生産性を最大化させるためにあるチーム」と定義することで、これからのエンジニア組織やサービス成長において重要な役割であることが明確になり、メンバーの アサイ ンにおいて納得感あるコンセンサスになりました。 採用に関しても、新しい体制下でのスピーディーでチームが一体となった採用活動ができるようになったことも、大きな進化だと感じています。 大谷： 新開発体制に移行したことによる、プロジェクトの進め方やメンバー間コミュニケーションの変化について、さらに詳しくお聞きしたいです。 木村： 以前は、プロジェクトが始まるタイミングで手が空いているメンバーを優先的に アサイ ンしていました。新開発体制のSquadではエンジニアとして担当する機能が固定化され、システムについてのオーナーシップを持つことができるようになりました。この変化により、技術領域と ドメイン 領域の両方に精通することができ、非常に効果的であると感じています。 以前は、「今日からあなたは、この機能を開発してください」となったときに、都度キャッチアップしながら探り探り進めることが多くありました。その結果、コードを壊してしまったり、元々の設計志向を理解せずに違う方向に修正してしまうことがありました。しかしこのような事態は新開発体制の導入によって解消されました。 山本： Squadは毎回新しいメンバーと組むわけでなく、2〜3名の小さいチームで同じメンバーで開発・振り返りを行うことができるため、チームごとにノウハウが蓄積し、息の合った開発・プロジェクト進行が可能となります。さらに、蓄積されたノウハウは他のチームにも共有され、良いア イデア が取り入れられる好循環が生まれています。 安藤： 新開発体制となり、エンジニアと企画•ビジネスメンバーが同じOKRをディスカッションして決めて、良い形で一体となってプロダクト・サービスを作っているように感じます。これは2人にとってはどう映っていますか？ 木村： エニグモ の企画・ビジネスメンバーはエンジニアへの理解が強く、理解しよう・寄り添おうとしてくれるメンバーが多いように感じます。 エンジニアが強すぎるというわけでも、ビジネス側が強すぎるわけでもなく、言われた物を言われたままに作るというわけでもなく、バランスのとれた形で開発が進められていると思います。 エンジニアも、長く働くメンバーが多いのは（10年以上在籍するメンバーもいる）のは、そういう環境にやりがいや面白みを感じているからかもしれません。 山本： もともとはビジネス側から、こういう企画がやりたいという話があり、さらに間にディレクターが入り要件定義し、エンジニアに下りて来るという形で、比較的受託開発のような開発の流れがあり、ビジネス側との距離感が少し遠いと以前は感じていました。 新開発体制になった後は、ビジネス側のメンバーが同じチームに所属することで、エンジニアが直接コミュニケーションを取れるようになりました。 エンジニアも参加するMonthly定例で、ビジネス側で持っている課題感や数値の進捗共有があり、「こういう数値を見てたんだ」といった新しい発見もあります。ビジネス側との距離がより近くなったと感じます。 さらに、SquadでOKRを決めて開発を進めるため、ビジネス的な目標についてもエンジニアとしてコミットし、プロダクトへの意識が変わってきています。 OKRを設定するためにはエンジニアも含めて多くのディスカッションが必要なため、ビジネス側の視点を持って開発をしたい方にとっては面白い環境であると思います。 当社エンジニア組織の魅力・キャリア 大谷： エニグモ ではエンジニアとして、どのような経験やスキルを身につけたり、キャリアを積むことができますか？ 木村： エンジニアは事業志向と技術志向の方がいると思っています。 事業志向の方は事業のミッションと向き合えるようなポジションに配置されるため、プロダクトの成長にどう貢献するかを考える機会があり、そういった方向でスキルを伸ばし、キャリアが積めると思います。 技術志向の方は、Squadで開発の一連のサイクルを経験できますし、またChapterやその他専門チームに所属することで、専門的なスキル・技術を深めることができます。 また、マネジメントを志向する方にも、DomainやChapterごとにマネージャーが配置されているため、そういったマネジメントのポジションを目指すこともできます。 山本： 実際のユーザーとの距離が近く、フィードバックをダイレクトに受け取ることができます。ユーザーのフィードバックを受けながらビジネス側のチームと協力して、エンジニアの視点でサービスやプロダクトに関する課題解決に取り組むことができます。 技術的な面では、大量の トラフィック を想定した開発など、大規模なアプリケーションの開発についての一通りの経験が得られるのが魅力です。 また、 BUYMA はユーザーも機能もすごく多く、機能も複雑に絡み合っているため、コードの一部を変更すると他の機能に影響が及ぶ可能性があります。そのため、自然と質の高い開発をする意識が養われます。 安藤： 確かに、プロダクト志向やビジネスに興味がある人も、技術的に突き詰めたい人にも、マネジメント志向の人にも様々なキャリアの可能性がありますね。 まとめ エニグモ にマッチするエンジニアとは？ 大谷： 最後に、さらなる組織進化にむけて今後どのような人材に加わっていただきたいか、こういう方は エニグモ で活躍できる（マッチする）などお話ください。 山本： 事業や、組織的、システム的なところなど課題をどんどん見つけて、もっとこういう風にした方が良いという思い(改善思考)を持ち、周囲を巻き込んで行動し、挑戦できる人が一番かと思います。 木村： どういう方が楽しめるのかなと考えると、世の中一般的にこうあるべきみたいなのがあって、そこに向かって今のその会社の形を無理やり変えていくみたいな人というよりは、会社それぞれで最適な形というのは当然あるため、会社や事業、組織、人のリアルな課題に向き合い最適解を探せる方ではないでしょうか。 安藤： エニグモ が求めている人物像は、基本的には エニグモ のバリューに沿った方が良いと思っています。 ※バリューについての詳細はこちら チームワークで解決できる人、物事をよりよく・より深く考えることのできる人。現状に満足せずに変えることができる人ですね。 変革の過程でギスギスすることやハードなこともあるため、そういった場面でも楽しみながら業務に取り組み、最終的には「夕日を見て肩を組めるような人、いろいろあったけど一緒にやれて良かった」と感じられる人が良いと思います。そんなに熱くなくてもいいですけどね笑。 大谷： 夕日を見て肩を組む、、、いいフレーズですね（笑） エニグモ が求める人物は「変革期で逆境やカオスな状況を乗り越えた先に、夕日を見て肩を組める人」ということで今回のインタビューは締めといたします。ありがとうございました。

こんにちは。 インフラグループ Kubernetes チームの福田です。 先日、 こちら でPrometheus Stackを使った監視構成の概要を紹介させていただきました。 本記事はそれに関連して、NodeGroup単位でのメトリクスの取得に関してハマりポイントがあったので、それを紹介できればと思います。 NodeGroupとは EKSにはNodeGroupという機能があります。 これは名前の通り、Nodeをグループとしてまとめる機能で、NodeGroup単位でマシンスペックを指定したりすることが可能です。 NodeGroupの詳細は こちらの記事 が特に参考になります。 また、NodeGroupの名前等の情報は各nodeにラベルとして付与することが可能です。 やりたいこと 我々の場合、EKS上に複数のプロジェクトを ホスティング しており、これらのプロジェクトに1:1でNodeGroupが存在しています。 そして、プロジェクト単位(NodeGroup単位)でnodeに関するメトリクスを収集したい要件があります。 例えば、あるプロジェクトのnodeの負荷を収集して、そのプロジェクトが設定しているEC2( Kubernetes node)マシンスペックが適切かどうか判断したい場合です。 言い換えると、あるnodeに関するメトリクスがどのNodeGroupに属するものか知りたいのです。 問題点 Prometheus metricsにはラベルが付いていて、このラベルを使ってメトリクスをフィルタしたり、グルーピングしたりできます。 我々の監視構成ではnodeのメトリクスはNode Exporter経由で収集していますが、Node Exporterが提供するメトリクスにNodeGroupラベルは付与されていません。 また、 relabel_configs 等のPrometheusが提供するラベル付与機能では決まった文字列のラベルを付与することはできても、「メトリクスの送信元ラベルからNodeGroupラベルを マッピング して付与する」といった動的なラベル付与はできません。 解決策 nodeにラベル(メトリクスのラベルではなく、 Kubernetes nodeに付与されているラベル)として付与されているNodeGroupの名前を Kubernetes API 経由で取得し、メトリクスにNodeGroupラベルを付与するプロキシ(Proxy Container)をNode Exporter Podにアダプタとして追加しました。 Proxy ContainerはGoで実装していて、以下のように動作します。 NodeGroupラベルの取得の挙動 自分自身がデプロイされている kubernetes nodeのhostnameを取得。 前のステップで取得したhostnameに対応するnodeのラベル一覧を Kubernetes API 経由で取得。 取得したnodeのラベル一覧にNodeGroupラベルが含まれる。 Proxyとしての挙動 Prometheusからリク エス トを受信する。 Node Exporterコンテナにメトリクスのリク エス トをする。 Node Exporterコンテナからレスポンスとしてメトリクス情報を受信する。 取得したメトリクス情報にテキスト処理を行い、メトリクスにNodeGroupラベル付与する。 Prometheusにレスポンスを返す。 まとめ NodeGroup単位でメトリクスを収集する方法について紹介させていただきました。 本記事で紹介したProxy ContainerはPrometheus形式のメトリクスに対して、任意のラベルを挿入できるように実装しています。 動的にメトリクスのラベルを弄りたくなる状況が同じようにあれば、これを再利用していきたいと思います。 エニグモ ではエンジニアを含む各種ポジションで求人を募集しております。 株式会社 エニグモ すべての求人一覧 hrmos.co

こんにちは。 インフラグループ Kubernetes チームの福田です。 みなさん、システムの監視はどうしているでしょうか？ 弊社では幾らかのサービスをEKS上で動かしており、その監視にはDatadogとPrometheus Stackを使っています。 この記事では特にPrometheus Stackを使ったEKS周りの監視構成について、その概要を紹介したいと思います。 クラスタ 毎の構成 まず、我々は以下の Kubernetes クラスタ を運用しております。 社内サービス用 クラスタ 商用サービス クラスタ integration環境 商用サービス クラスタ production環境 構成は下図のようになっています。 Grafanaだけ中央集権的に社内サービス クラスタ にのみ配置し、それ以外のPrometheus等の監視 コンポーネント は クラスタ 毎に配置しています。 また、各 クラスタ には Prometheus Operator をインストールしており、Prometheus自体の構築やPrometheusのコンフィグの管理はPrometheus Operatorを介して行っています。 監視項目 ここからは監視項目とその方法について紹介したいと思います。 外形監視 社内サービス用 クラスタ 上にある Blackbox Exporter から必要なエンドポイントへ外形監視をしています。 各 クラスタ の AWS アカウントはそれぞれ分かれているため、商用サービス クラスタ への通信は AWS アカウントを跨ぐようになっています。 worker nodeの監視 node単位でのリソース使用量等の情報はDaemonSetとしてインストールしている Node Exporter からメトリクスを収集しています。 コンテナの監視 コンテナ単位でのリソース使用量等の情報は cAdvisor からメトリクスを収集しています。 cAdvisorは自前でデプロイしたものではなく、kubeletに組み込まれているものをそのまま利用しています。 各種アプリケーションの監視 自社で開発したアプリケーションについては原則はPrometheusではなく、Datadogで監視を行っています。 ただし、Argo CD等の OSS についてはそれらのアプリケーションが公開しているmetrics用エンドポイントからPrometheusメトリクスを収集しています。 Logの集約 Logの集約は Grafana Loki で行っています。 DaemonSetとして各nodeにインストールしている Promtail が各 クラスタ にあるLokiへログを送信する構成です。 また、ログデータは永続化するためにLokiの機能を使ってS3に保存するようにしています。 まとめ 本記事では、Prometheus Stackを使ったEKS周りの監視構成について概要を紹介させていただきました。 ここでは構成の概要を紹介しただけですが、ハマりポイントや改善ポイントについても知見がある程度溜まった段階で、今後紹介できればと思います。 また、 エニグモ ではエンジニアを含む各種ポジションで求人を募集しております。 株式会社 エニグモ すべての求人一覧 hrmos.co

エニグモ のエンジニア採用担当の 廣島 です。 エンジニア組織が昨期から新体制になりました。今回は、エンジニア組織のトップが全社会議で新体制について説明した内容をまとめた記事となります。 エニグモ はCtoCグローバルECの BUYMA というサービスを運営していますが、どういう体制で開発しているのかというお話です。 ぜひご覧ください！ 目次 Committeeとは？ 新組織体制、新チーム、新ロールの概要 「Squad」「Domain」「Chapter」体制について Squad（スクワッド）とは Domain（ドメイン）とは Chapter（チャプター）とは 開発組織を支える5つのチーム あるプロジェクトの編成例 新体制の狙い この体制のメリット/Squad、Chapterの導入が納期短縮になる理由　 まとめ Committeeとは？ Committee Headの木村です。現在、 BUYMA のエンジニア組織のマネージャーおよび、エンジニア組織の意思決定機関であるCommitteeのHeadを担っています。 今回は、新組織体制となったエンジニア組織について説明します。 まず、私がHeadを務める Committee とは何かについてお話しします。 Committeeはエンジニア組織の意思決定を行うトップ機関です。 CTOや部長を頂点とするワントップ型ではなく、複数名のエンジニア リングマ ネージャーで構成する合議体です。トップは輪番制となっており、現在私が担っています。 エンジニアの意思決定機関は、Committeeの他、優先順位が高い組織課題は分科会を設置して議論・意思決定のスピードを上げています。分科会にはマネージャーの他、分野ごとの適任のエンジニ アメンバー が参加しています。 分科会は現在、 アーキテクチャ 分科会、KPI分科会、採用分科会などがあります。 Committee体制についての詳細は下記記事でも説明していますのでご覧ください。 tech.enigmo.co.jp 新組織体制、新チーム、新ロールの概要 こちらの図を用いて、まずはエンジニア組織の全体像を話します。 実態としては チーム トポロジー の概念 （ Spotify モデル）を参考に組織設計しました。 Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む（Spotifyモデル） | 『リーン開発の現場』越境せよ！ 図の左側は主にプロダクトの機能開発を担うチームであり、 Domain と呼ばれるチームが3つあります。それをさらに細分化・構造化する形で、縦割りチームの Squad や、横ぐしチームの Chapter があります。 右側の図は Domain/Squadを支援する位置づけのチーム であり、5つのグループ・チームがあります。 「Squad」「Domain」「Chapter」体制について 前段で登場した「Squad」「Domain」「Chapter」がどのようなチーム単位で、実際に エニグモ ではどのように運営されているかをお話しします。 Squad（スクワッド）とは 図の中でも一番多くあるチーム単位の Squadは、事業的なミッションが与えられ、そのミッション達成に向けたシステムについてオーナーシップを持ちます。 システムの全開発ライフサイクル（設計、開発、テスト、本番化、運用、不具合対応など）を担当します。 1つのSquadで開発者は2-5人程度のチームです。さまざまな技術領域・職能のメンバーが集まっています。 各Squadにはリードするメンバー1名がおり「Squad Lead」と呼びます。開発プロジェクトで設計・タスクへの落とし込み、タスクの アサイ ン、プロジェクトマネジメントを担います。 事業的なミッションの例としては、「魅力的な商品を増やす」や「競争力のある出品者さんにご活用いただける配送サービスを拡充する」「ユニークユーザー数・セッション数の改善を行う」などがあります。 エンジニアであってもビジネス的視点を持って開発を行い、メンバーに裁量や自律性を持たせた組織になっています。 他のSquad以外のチームの基本的なミッションはSquadチームを支援することと定義されています。 Domain（ ドメイン ）とは Domainとはミッションが類似・関連している複数のSquadの集まりです。 Domainのマネージャーを「Domain Head」と呼び、配下のメンバーのピープルマネジメント、リソース配分、Domain間の連携を担当します。 Domainは、ディレクター、データアナリスト、デザイナーなどエンジニア以外のメンバーも所属し、職能横断型組織となりプロジェクトを進めます。Domainはいわゆる事業部のような単位となっています。 BUYMA は現在、3つのDomainがあり、それぞれBUY Domain、SELL Domain、SI（SERVICE INFRA）Domainと呼びます。 3つのDomainがどういった開発をしているのかを説明します。 BUY Domain BUYMA の購入者向け機能を開発するチームです。主なカバー範囲としては、会員登録、商品詳細、購入リスト、レコメンド、クーポン、広告、特集ページ、カート、商品レビュー等を開発します。 SELL Domain BUYMA の出品者向けの機能を開発するチームです。主なカバー範囲としては、出品ページ、出品リスト、受注リスト、商品画像、お問い合わせ、タイムセール、ショップ連携等を開発します。 SI（SERVICE INFRA）Domain BUYMA サービスの基盤となる決済連携、物流（配送・倉庫連携）、入金関連、セキュリティ関連等の機能を開発します。 ※大型キャンペーン対応、商品画像施策など複数Domain横断のプロジェクトもあります。 Chapter（チャプター）とは Squadの中でも特定の専門分野を担当するメンバーを横ぐしに束ねた組織です。 Squadに所属しながらSquad外でも、テクニカルな改善・基盤整備を独自に実施します。 具体的な特定の専門分野は現在、フロントエンド、モバイルアプリ、QAがあります。 Frontend Chapter フロントエンド独自の戦略にもとづき横ぐしで施策を実行し、プロダクトの品質向上やパフォーマンス改善、計画的なバージョンアップや リファクタリング 、エンジニア組織全体の活性化や技術力の向上に取り組みます。 モバイルアプリ Chapter iOS ・ Android アプリの開発を担当するChapterです。 モバイルアプリの iOS やアンドロイドはそれぞれのチームとして独立していましたが、事業的なミッション達成の為には、どのDomainにおいても iOS やアンドロイドの協力は絶対必要不可欠です。とくに iOS は 流入 UUの約半分以上を締めておりユーザーとの重要なコミュニケーション接点です。企画段階から開発に参加することが健全のため、横ぐしのChapter組織としました。 QA Chapter サービス品質の維持・改善をミッションに持ち、各プロジェクトの上流工程から関わり、QAを担当します。 プロジェクト以外でも自動テストの導入、本番で検出された不具合分析など横ぐしでプロダクト全体の品質向上を目指した取り組みを行っています。　 開発組織を支える5つのチーム 続いて右側の図の開発組織Domain/Squadを支援する5つのチーム（Application Platform、Data Technology、Infra、DX、DevRel）について説明します。 これらのチームはソフトウェア基盤の構築・改善、開発環境の整備、組織開発などエンジニア組織を下支えしています。 ミッションは「Squadの生産性向上」とすることでSE本部組織全体としてのベクトルを揃えています。 各チームがそれぞれどのような役割を担っているかを説明します。 Application Platform Application Platformは新組織体制に移行した際に、新設したチームです。Squadが単独では担いきれなかったり、 各Squadで横断的に共通するようなテクニカルな課題を解決し、Squadの生産性を向上させることがミッションです。 具体的な取り組み例として、言語・ライブラリ・ フレームワーク のバージョンアップ、 AWS 化に向けたアプリケーション修正、 疎結合 化・モジュラー化・マイクロサービス化などの アーキテクチャ のモダナイズ、サービスの信頼性強化（SRE活動）などがあります。 Data Technology Domain/Squadでは担いきれない データ関連の専門知識（データ基盤・ 機械学習 ・検索）が必要とされるシステムを設計・開発から運用までを担当します。 初期の設計や開発フェーズではSquadと密接にコラボレーションします。 データサイエンティスト、検索・MLOpsエンジニア、データエンジニアなどデータに関わる スペシャ リストが所属します。 Infra Domain/Squadでは担いきれない インフラ・セキュリティ関連の専門知識が必要とされるシステムを設計・構築から運用・監視までを担当しています。 現在の取り組み例として、 BUYMA の環境をオンプレミスから AWS への移行、 Kubernetes クラスタ の構築・運用および開発支援、サービスのセキュリティの強化などを行っています。 ※次に紹介するDXチームとDevRelチームの2つのチームは、SE本部の組織の中でも人を集め、エンゲージメントを向上させる重要な役割を持ちます。専任メンバーでのチーム組成ではなく、他チームのメンバーが兼務するパートタイム組織となることも特徴です。 DX DXはDeveloper Experienceの略で、日本語では開発者体験という意味です。 開発者体験の維持向上を行うことがミッションとなります。 主に、 BUYMA のローカル開発環境やCI/CD ツールの整備をしています。 DevRel DevRelはDeveloper Relations の略で、 社内エンジニアの技術力向上・知識共有や交流促進の為、社内向けに勉強会、開発合宿などを企画します。 また、テックブログや対外イベント・カンファレンス協賛などの企画により、 対外的に社内の技術力の広報活動を実施するチーム です。 あるプロジェクトの編成例 今までは、開発組織がどういうチームで構成されているかをお話ししましたが、実際にプロジェクトベースでどのような流れ、関わり方になるかをお話しします。 プロダクトマネジャー（PdM）が企画をまとめプロジェクトがスタートし、PdMとSquad Leadやビジネスサイドのメンバーでどのようにシステムに落とし込むのかを要件定義します。その後、Squad Leadが設計を担い、タスク分解して、エンジニ アメンバー に アサイ ンします。 他にも、Data Technology、Application Platform、Infra などのこれらのチームはSquadの開発プロジェクトがいかに早く終わるかを支援していく立ち位置となります。 例えばプロジェクトで検索 API が必要だとなれば、データテク ノロ ジー グループの検索チームが開発したり、インフラ構築が必要であればインフラがサポートする。そういうプロジェクト編成になります。 新体制の狙い 先ほどからも狙いを織り交ぜながら話していますが、 新体制の一番の狙いとしては「案件（プロジェクト）の納期短縮によるユーザへの価値創造・事業への利益創出」です。 納期短縮により、案件のリリース回数が増えれば、その分 PDCA がまわって、ABテストなど試行錯誤が進みUXが改善され、ユーザーへの価値創造になります。 案件1つ1つリターンを得るものだとすると、一定の 工数 でリリースされる案件を増やせば増やすほど、組織のROIが改善されるので、利益創出になると思っております。 この体制のメリット/Squad、Chapterの導入が納期短縮になる理由　 新体制が具体的にどのように納期短縮なるか、その他新体制のメリットについて5つ紹介します。 ①Squadはいわば、ミッション特化型職能横断チームで、ミッションが共通しているので職能間のベクトルが揃い開発スピードが上がります。 ②職能間のタスクの受け渡しやすり合わせ MTG を個別で実施する必要がなくなります。 以前だと、例えばフロントエンドとバックエンドで作業をお願いするミーティングがありましたが、全部1つのチームとなるので、最初の企画ミーティング以降はチャットベースで仕事が進み、ミーティングが減るのではないかと考えています。 ③異なる職能間でお互いの進捗が見えやすくなり、メンバーが進んで仕事を取りにいけ、 アサイ ン待ちや依頼待ちが発生しづらくなります。 ④職能間でお互いの理解が進み、技術としては1人1人専門分野があるが、知識は フルスタ ック化していきます。例えば、フロントエンド側もバックエンド側の負荷を自然に気遣えるようになると考えています。 ⑤Chapterはそれぞれの専門で実績のある新しいツール、ライブラリ、 フレームワーク 、プ ラク ティスを常にChapterでフォローし、基盤やツールを整備しておけば、すぐにSquadへ展開可能になります。 まとめ 今回お話ししたエンジニア組織体制は目標とする体制で現在進行形の箇所も含まれますが、新体制のキックオフから約1年が経ち、目標の体制にかなり近づき、且つ全社に浸透し機能してきました。 ただ、チームとして組織として成果を出し・生産性を高めていくためには、まだまだ改善の余地があり、道半ばです。さらに、この体制は完成形ではなく事業や組織の状況によってアップデートしていければと思っています。また、Committee（組織運営や意思決定）に関わる人も今後、さらに増やしていきたいです。 よりよい価値のあるプロダクトをユーザーに届けられるよう、そして エニグモ がさらなる成長を遂げられるよう、これからも精進していく次第です。

こんにちは、エンジニアの片桐です。 エニグモ では、社内サーバインフラの構成管理に Ansible を採用しています。 Ansibleの前任の構成管理ツールには Chef を使用していました。 Chefと比較して、Ansibleで使用するファイルは YAML ベースの記述が可能で可読性が高いこと、エージェントレスで管理対象サーバに何もインストールする必要が無いこと等、Ansibleを導入することで様々なメリットを享受しています。 (Ansibleの導入話は以下の弊社ブログ記事でも話されている為、合わせて是非ご覧下さい！) tech.enigmo.co.jp 社内でのAnsible活用が進む一方、他社のAnsible活用事例にはどんな物があるのか知りたいなと思っていた所、 Ansible Night 2023.07 現場を支えるPlaybook編 というイベントが開催されることを知りました。 折角の機会ということで、聴講側で参加しましたのでレポートを残したいと思います。 Ansible Nightとは Ansibleのユーザコミュニティである、 Ansibleユーザー会 様主催の技術イベントです。 技術的な話題は勿論のこと、自動化を実装する為の組織作りの話題まで、Ansibleを使用した幅広いテーマを主体として開催されています。 イベント情報は Ansibleユーザー会のConnpass で公開されていますので、興味があれば覗いてみてください。 1. Ansibleによる、ネットワークOSに依存しないコマンド作成・設定変更 (APコミュニケーションズ 川名さん) 公演資料 github.com 公演内容 業務内容と現状業務の問題点 NW機器のサブインターフェースに設定する IPアドレス の計算と設定コマンドの生成を Excel で実施していた。 しかし、この作業には以下の問題点があった。 使用するネットワークOSが2種類混在しており、それぞれのOSでサブインターフェースを設定するコマンドが異なる為、コマンド生成と確認に必要なスキルレベルが高くある。 作業時に誤って Excel の計算式を削除してしまうケースがある。 そもそもの Excel への数値入力が大変。 問題点に対する改善 Ansibleとjinja2テンプレートを使って、 IPアドレス の計算と設定ファイルの生成を自動化した。 自動化実装の結果、作業者・レビュー者ともに作業負担が非常に軽くなり、作業効率も上がってミスも減った。 Ansible実装時に発生した問題 開発ツール(エディタ)を統一していなかった。 エディタ依存のインデント差分等が生まれ、レビューに時間が掛かった。 開発ツールは Visual Studio Code に統一し、使用する 拡張機能 もチーム内で共有した。 Playbookのコーディングルールが無かった。 変数名などの表記に揺れが生じ、レビューが困難だった Playbookの管理にGit等の構成管理ツールを使用していなかった。 Playbookの重複編集や、 誤爆 削除が発生していた。 自動化によって発生した課題 「手動での設定ファイル生成作業を経験したことの無い人」が発生するようになった 新しく着任した人は、既に自動化された作業をなぞるだけになる為、作業内容のイメージがしづらい。 検証環境で手作業での作業も実行させると理解が深まりやすい。 Ansibleで実行エラーが起きるたびに開発者に連絡が来るようになった。 既知のエラーについてのドキュメントの整備と エス カレーションフローを整備して、問い合わせの件数を軽減した。 感想 Ansibleでサーバに対して設定ファイルを展開するのではなく、テンプレートエンジン的な使い方をして設定ファイルの生成のみを行うという、自分の知らないAnsibleの使い方だと感心しました。 ネットワークOSによるサブインターフェースの設定コマンドの差異は以下の様になるとのことで、これだけ異なれば差分を吸収するのは確かに大変そうだな...と思います。 Junos: set interfaces fe-0/0/0 unit 11 vlan-id 11 set interfaces fe-0/0/0 unit 11 family inet address 192.168.0.1/28 IOS : interface GigabitEthernet1.11 encapsulation dot1Q 11 ip address 192.168.0.1 255.255.255.240 ! 各種言語を使用した スクリプト でも同様の設定ファイル生成処理は実現可能とは思いますが、OSによるホストの出し分けやPlaybookの再利用性など、Ansibleならではのメリットが享受できそうな使い方だと思いました。 また、実装時の問題点では「開発環境(エディタ)を Visual Studio Code に統一する」対応を取られていたとお話されていました。 Vim 使用者や サクラエディタ 使用者等、幅広いエディタ使用者が居たと言う事だったので、エンジニア間で揉める所があったんじゃないかなと思い、ハラハラしながら聴講しておりました...。 2. NetBoxを利用した IPアドレス の自動払い出し (APコミュニケーションズ 宮下さん) 講演資料 github.com 公演内容 業務内容と業務の問題点 社内にある VM 基盤上に VM を作成する業務が多く発生する。 VM の作成時には IPアドレス を アサイ ンする必要が有るが、以下の問題点がある。 IPアドレス の アサイ ン状況の管理を Excel ファイルで行っている。 作業担当者は、 アサイ ン可能な IPアドレス を Excel ファイル上から見て探して、手作業で アサイ ンした後 Excel ファイルを更新する。 Excel ファイル自体の管理が必要な他、棚卸しが大変だったり、 アサイ ンオペレーションミスが発生したりする。 改善内容 IPAM/DCIM機能を持つ OSS である、NetBoxを導入した。 IPAM(IP Address Management): IPアドレス 、 プレフィックス 、VLAN, VRF等の管理サービス DCIM(DataCenter Infrastracture Management): サーバ、回線、ラック、電源等の管理サービス AnsibleとNetBoxを連携することで、以下のフローを実現した。 AnsibleのPlaybookからNetBoxの API を叩き、指定ネットワークPrefix上で空いている IPアドレス を仮採番する。 仮採番された IPアドレス の利用状況を確認するため、AnsibleのCommandモジュールから Ping を実行して疎通確認を実行する。 Ping 応答が無ければ空きIPとして判断し、AnsibleのNetBoxモジュールを通して、NetBox上に IPアドレス と紐づいた VM 情報を登録する。 VM 構築にかかる稼働時間やリードタイム削減、オペミス頻度の低下、棚卸しの容易化などのメリットが生まれた。 自動化で生まれた課題 NetBox自体を管理するコストが増加した 社内の別のシステム上で VM の IPアドレス を管理しているものがあるらしく、NetBoxに集約していく作業が必要 感想 Ansibleを利用して人の手が必要な部分を上手く自動化し、業務の効率化だけではなく、業務の質も向上出来ているアプローチだなと感じました。 また、NetBoxと言う OSS はこの公演を通して初めて知りました。 VM だけでなく、物理サーバの管理やNW機器の管理も可能で、それぞれの管理項目もかなり詳細に設定出来る様です。 NetBoxのデモサイト が公開されている他、 Docker版のNetBox も公開されている為、是非社内でも導入検証してみたいと思いました。 NetBox デモサイト上でのIPAM管理ページ表示例。欲しい項目は一通り揃ってそうで良い。 3. チケット運用とAnsible連携による変更管理の自動化( RedHat 小野さん) 講演資料 公開なし 公演内容 業務内容と問題 あるインフラ関連作業について、メールや台帳で作業依頼を受けていた。 アサイ ンされた作業者が各々で手順書を作成して実行し、作業後に各人が依頼主に返信して対応完了にしていた。 チケット管理システム等による作業管理がされておらず、ナレッジの蓄積と共有がし辛い状態であった。 業務改善までのフロー 標準化: ServiceNowによるチケット管理の導入 あるインフラ関連作業について、メールや台帳で作業依頼を受けていた。 依頼によって発生したタスクを一元管理する為に、チケット管理システムであるServiceNowを導入した。 タスクをチケットとして一元管理できるようになり、依頼フローなどが整備された。 自動化: Ansible Playbookを用いた作業手順の統一化 作業手順の不均一性を解消するために、AnsibleのPlaybookに作業手順をコーディング。 担当者による作業の差異がなくなり、一貫性のある作業が可能になった。 人の手による作業からAnsibleが自動で作業を実行する方式に変更することで、作業効率が向上した。 サービス化: AWXによるフルオートメーションの実現 AWX(Ansible Tower)の API を活用して、作業依頼のチケットが承認されると自動で作業が開始されるように設定した。 作業フローは完全に自動化され、人の介入が不要になった。これによって作業のスピード、精度、効率が向上した。 仕組みづくりの為の3ステップ 標準化 ルール作成、 ガイドライン 策定 作業ミス低減、トレーサビリティ向上を目指す。 自動化 標準化された作業を、ソフトウェアやシステムで自動的に行う ユーザへの価値向上、プロセスタイムの削減を目指す。 サービス化 自動化されたプロセスを相互連携させて、ユーザに対して価値をもたらす。 リードタイム削減、価値最大化を目指す。 インフラエンジニアとして伝えたいこと インフラエンジニアは、自分に与えられた作業を正確にこなす内向きな作業者視点から、ユーザ視点の価値にフォーカスすべきである。 自分の作業効率を上げるための作業者視点の自動化から、ユーザへ価値を届ける仕組みづくりへの視点への転換が重要。 効率的な業務を行う為の仕組みづくりを行う、サービスプロバイダになるべき。 感想 完全手動かつ無管理だったワークフローを、チケット管理システムを使用して管理化した後、Ansible Tower(AWX)を使用して完全自動化するまでのステップを紹介していました。 標準化によって作業の品質が保たれ、自動化によって効率が上がり、最終的にはサービス化を通じてエンドユーザーに直接的な価値が提供されると言う一連のフローが、技術だけでなく組織全体での価値創出に繋がるという点は非常に参考になりました。 また、インフラエンジニアが単に内向きな作業にフォーカスするのではなく、ユーザ視点での価値を考える重要性が強調されていたのは、今後の業務においても非常に参考になると感じました。 自分自身の作業効率を上げることも重要ですが、それをどのようにサービスとして外部に提供するか、という視点も持つべきだというメッセージに、大いに共感しました。 最後に 久しぶりに技術イベントに参加して、新たな知見や視点に触れる充実した時間を過ごしました。 今回のイベント参加に使用した Connpass では、インフラに限らず多様なテーマで日々イベントが開催されています。特にリモート参加が可能なイベントも増えており、時間や場所に縛られることなく学びを広げられて良さを感じました。 気軽に参加出来ることもあり、自己研鑽も兼ねて今後も興味を持ったイベントのレポート出来れば良いな、と思いました。 株式会社 エニグモ すべての求人一覧 hrmos.co

こんにちは。 サービスエンジニアリング本部の寺田と橋野です。 こちらの記事は、RubyKaigi 2023に参加しました！<後編>です。 前編は以下からどうぞ！ tech.enigmo.co.jp 後編では、RubyKaigi2023で印象に残った講演の内容を紹介をしていきます。 1日目 Matz Keynote Youtube : [JA][Keynote] Matz Keynote / Yukihiro "Matz" Matsumoto @yukihiro_matz - YouTube Slide: 30 Years of Ruby - Speaker Deck [内容] 今年で Ruby は30周年を迎えました。 この講演では、「 Ruby 」の生みの親である まつもとゆきひろ （Matz）氏が、 Ruby の30年を時系列順に振り返っていました。 学んだ教訓や主要なイベントを含め、段階に分けて説明していました。 年代 トピック 1993-02 ~ 1994-12 始めは一人での開発 1994-12 ~ 1995-12 Alpha Release 共同開発を開始 1997-08 ~ 1999-11 Ruby v1.0 リリース 1999-11 ~ 2004-10 初の Ruby の技術書 2000-10 初の英語の Ruby の技術書 2001-09 JAOO ( Java And Object Oriented Language) 2001-10 初めての Ruby のカンファレンス 2004-10 ~ 2009-01 Ruby on Rails の登場 2009-01~2013.02 Ruby1.9 のリリース 2013-02 ~ 2015-11 Ruby2.0のリリース 2015-11 ~ 2020-02 Ruby 3x3 2022 ~ Ruby 3.0 それぞれ紹介したテーマからMatz氏が学んだことや教訓で締めていました。 例えば、海外の人から本を書きたいとMatz氏に連絡がきたというお話しがあり、 まつもとゆきひろ 氏は「この本がなかったらいまの ruby がなかっただろう」という学びを得たことをおしゃっていました。 [感想] Matz氏の学びの中に特に興味深かったものがありました。 「いい名前を選ぶ。」という教訓です。 Ruby の名前の候補に、「Coral」や「Tish」などがあったそうです。もしかしたら、Tish Kaigiになっていたかもしれませんねとお話しされていました。 TishKaigiであると言語のカンファレンスではなく、製紙会社のカンファレンスのようにみえていたかも？と思いました。 また、実務でもさまざまな場面でいい名前を選ぶということを感じています。 例えば、メソッドの 命名 でも、どのような役割をもったメソッドなのかをわかりづらいというレビューを受けたり、また、役割がややこしい 命名 をされた変数を見たりします。 「いい名前を選ぶ。」ということは私も大切であり、大きな意味と役割をもつと思っています。みなさんも大切だと感じることが多いでしょう。 この講演に参加することによって、 Ruby の30年もの歴史を一気に振り返ることができました。 知らない歴史も多く、この講演を通してさらに Ruby のことが好きになりました。 The future vision of Ruby Parser Youtube : [JA] The future vision of Ruby Parser / Yuichiro Kaneko @spikeolaf - YouTube Slide: The future vision of Ruby Parser - Speaker Deck [内容] この講演では、 Ruby のparser実装の話を聞くことができ、3つの課題を説明します。 以下がその問題です。 Usability (Error-tolerant parser) Maintainability Universal Parser Usability 今までのparserはとてもシンプルであったが、Language Server Protocol(LSP)の場合それだけでは十分ではなく、責任が増えてきています。 トーク ンを追加もしくは削除して リカバリ ーをおこなったらどうだというア イデア があります。 Insert/Deleteのオペレーションの組み合わせをやることで プログラマ が構文を考慮することなくError Recoveryが実装できた。 Error Recoveryを実装するためにLrama LALR parser generatorを実装をした。 Maintainability メンテナビリティの解決方法について、 Ruby の do を中心に密結合しているという根深い問題に関しても他の既存のテクニックと 組み合わせることで解決ができた。 Universal Parser CRuby以外でもparserを使いまわしをするためにUniversal Parserが必要になってくる。 CRubyの提供する関数やマクロへの依存を"parse.y"から剥がしていくことで問題を解決していく。 [感想] BisonをLramaに置き換え、 Ruby のmasterにマージされたそうです。 これでBisonのバージョンの依存関係がなくなりましたね:yatta: Kanekoさんは、今後LALR parserの可能性を引き出していくことをしていきたいと講演でお話しされていました。 まだまだ進化していきそうな Ruby のParserを watch をしていきたいと思います。　　 この講演の内容を詳しく知りたいという方は、Kanekoさんのブログに丁寧に解説されているのでおすすめです。 かねこにっき また、parserを書いてみたいけどどこから始めればいいかわからないという方向けに Ruby で電卓をつくる チュートリアル をKanekoさんが書いてくださってので、興味を持った方はこの講演と合わせて試してみましょう！ github.com Make Regexp #match much faster Youtube : [JA] Make Regexp#match much faster / Hiroya FUJINAMI @makenowjust - YouTube Slide: Make Regexp#match much faster - Speaker Deck [内容] この講演では、 正規表現 マッチングの実装と、 Ruby 3.2.0 で実装された 正規表現 マッチングの最適化の詳細について説明します。 流れとしては、 Ruby 正規表現 がいかにパワフルかの説明 ReDos 正規表現 マッチングには 脆弱性 がある。 ReDos を防ぐために高速化することによって防ぐことができる(メモ化による最適化) 正規表現 マッチングの今後の展望 の順にお話をされていました。 Ruby の 正規表現 マッチングはパワフルだけど、ReDosと呼ばれる 脆弱性 があり、その例をスライド内で紹介していました。 しかし、 正規表現 マッチングの実装の改善をし、待ち時間の短縮をさせ、ReDosが起こらないようにRuby3.2からではおこなわれています。 また、 正規表現 の拡張的な機能などはメモ化による高速化はおこなわれていないそうです。 [感想] ReDoSの起きてしまう理由やどのような手順で高速していったかを、ひとつひとつ丁寧に解説されていました。 しかし、 Youtube の内容を見直してみたのですが、本題であるメモ化による最適化の話のあたりが難しくまだ完璧には理解ができていません。 スライドの中に実行時間の比較があったのですが、Ruby3.2からでは時間がかなり短くなっていました。 Ruby3.2の変更を追えていなかったので、とても勉強になりました。 今後、理解していけるように 正規表現 について少しずつ学んでいきたいです。 Power up your REPL life with types Youtube : [JA] Power up your REPL life with types / tomoya ishida @tompng - YouTube Slide: rubykaigi2023_tompng.pdf - Google ドライブ [内容] この講演では、型定義の情報を使用して irb の補完機能を強力なものにするためのgem katakta_ irb について理解ができます。 irb の現状として、メソッドチェーンをすると正しい補完方法を出せなく、ありとあらゆるクラスのすべてのメソッドを出してしまったり、それ がパフォーマンスに問題があるということで最新の irb ではメソッドチェーンの補完は出さないようになってしまいました 。　　 katakata_ irb は、メソッドチェーンの補完をしていきます。 また、型定義の情報を使って補完をしてくれるので、かなり便利です！ katakta_ irb は、タップル型やレコード型、.is_a?などは未対応で、今後実装されていくそうです。 [感想] 私もさっそく入れてみました。 Integerと出ていますね！ gemをいれるだけで使えるようになるので、気になった方は是非使ってみましょう！ github.com 2日目 Build a mini Ruby debugger in under 300 lines Youtube : [EN] Build a mini Ruby debugger in under 300 lines / Stan Lo @_st0012 - YouTube Slide: slides/2023-05-11-rubykaigi/Build a mini Ruby debugger.pdf at main · st0012/slides · GitHub [内容] たった 200 行で Ruby だけで実装した Debugger を紹介しますという講演。 単 純化 した pry の再実装のようなものですが、 このコードを読むことで Ruby で実装された Debugger のエッセンスが簡単に理解できます。 Ruby で何か開発をしている人は、何かしらの Debugger を使っているはずです。 ただ、普段使っている Debugger が中でどのようなことしているか知っている人は少ないですよね。 しかし Debugger の中身を深く知っていれば、必要に応じて自分で Debugger をカスタマイズしたりできたりと応用が効くようになります。 Ruby の Debugger の基本的な機能はたった3つの コンポーネント の組み合わせから成っています。 Binding object and Kernel#Binding Tracepoint ruby/reline Library これだけで簡単な デバッグ に必要な、以下のようなことが実現できます。 Breakpoint を設定して対話的にコードを実行する(REPL) Step-in , Step-over を使ってコードを実行する Breakpoint を新たに追加 / 削除する [感想] Debugger に限らず普段使っている gem の ソースコード を読むと、 動いていることとは裏腹に実装がめちゃくちゃシンプルだな... という風に思うことが Ruby だとちょくちょくありますよね。 やはり Ruby の魔術って強力だなあと改めて思いました。 Yet Another Ruby Parser Youtube : [EN] Yet Another Ruby Parser / Kevin Newton @kddnewton - YouTube Slide: YARP - Speaker Deck [内容] Yet Another Ruby Parser は通称 YARP と呼ばれている、 Ruby の次世代のパーサーの一つです。 次に求められるパーサーを作るには主に3つの課題をクリアする必要があり、 YARP においてもこれらの点を解決するための取り組みがなされています。 エラートレラントであること 高いポータビリティを持つこと メンテナンスしやすいこと エラートレラントであるというのは、構文にエラーがあるコードが与えられたときでも、 何かしら意味のある結果を返すことができるということです。 エラートレラントであるパーサーを持つことで、コードの補完などを開発者に提供することができます。 IDE が充実している現代ではこういった機能は言語として必須といってもいいでしょう。 また、 Ruby にはさまざまな構文ルールがあり、実行ランタイムもさまざまです。 このような世界では何か特定の実装に依存した仕組みがあると、 パーサーは限定した環境でしか使えないもの、すなわちポータビリティが低いということになってしまいます。 YARP では CRuby や、特定のパッケージの利用を前提とした実装がありません。 あらゆる環境でも利用できるパーサーとなるとのことでした。 最後にメンテナンスしやすいという点では、YARP は拡張性が高いということを挙げています。 テストコードも十分にあり、 デバッグ の難易度も低く、比較的簡単に新たな構文の追加ができるようになっているとのこと。 Gem としてのリリースはまだですが Ruby 3.3.0-preview1 以降のバージョンであれば実際に使うことも可能。 既に ruby / ruby のコードベースを初めとして、多くの主要な gem においても動作することが確認できているようです。 講演では Ruby のパーサーを開発することが如何に難しいかということにも触れられています。 [感想] Ruby は開発者にとって自由度の高い書き方ができたり、 コミュニティによって多くのライブラリが産まれることで大きく発展してきた一方で、 それらを包括しなくてはならないパーサーの開発は非常にチャレンジングなんだなあと感じされられます。 The Resurrection of the Fast Parallel Test Runner Youtube : [JA] The Resurrection of the Fast Parallel Test Runner / Koichi ITO @koic - YouTube Slide: The Resurrection of the Fast Parallel Test Runner - Speaker Deck [内容] サービスの巨大化に伴い、テストの実行時間が肥大化するということはあらゆる場面で問題になっています。 実行時間を短縮するアプローチはさまざまありますが、その一つにテストの並列実行があります。 並列で実行することにより、直列で実行した時と比べて理論上は実行環境の CPU のコア数倍テストは早くなるはずです。 Minitest には parallelize_me! という機能があり、マルチスレッドでの並列テストの実行が可能です。 また、 Rails 6 以降ではテストの数によって Minitest を自動的に並列的に実行するようになっています。 しかし、 Minitest 以外のテスティング フレームワーク では並列テストは有効になりません。 そこで注目したのが test-queue という Gem です。 test-queue が優れている点はまず、実行時間の最適化を図れることです。 並列実行において問題となるのは特定のワーカーの処理時間だけが長くなってしまい、 全体の実行時間がそれに引きずられて遅くなるという部分です。 同じように並列テストを行うための Gem で parallel_tests というものがありますが、 こちらはテスト開始時にあらかじめワーカーにタスクを割り振るのでこういった問題が発生してしまいます。 これに対して test-queue ではテストを実際に実行するワーカーが空いたタイミングでタスクを逐次 pop するため、 こういった問題が起こりにくくなっています。 次に優れている点が、Pluggable であるという点です。 基本的な処理の実装は共通であるものの、 テストランナーの部分は各テスティング フレームワーク の API を実行する形になっています。 これにより test-queue は RSpec を初めとして、 Minitest , Cucumber などさまざまな フレームワーク で使用が可能です。 [感想] テストコードの存在が重要だというのはもはや常識であり、 CI ツールを用いて全テストをパスさせてからリリースを行う、 というパイプラインを構築するのは一般的なプ ラク ティスとなっていますよね。 ただこれにより、テストの遅さがリリースまでのリードタイムを遅くする要因となってしまうことになります。 我々のプロダクトでもテストを如何に早くするか、ということは改めて考えないとなと思います。 Multiverse Ruby Youtube : [JA] Multiverse Ruby / Chris Salzberg @shioyama - YouTube Slide: Multiverse Ruby - Speaker Deck [内容] 登壇者の @shioyama さんが作成した gem である im の紹介となる講演です。 Ruby においてプロダクトを拡張する場合 require が利用できます。 また Rails でも採用されている Zeitwerk などの autoload を利用する場合もあるかもしれません。 この場合は明示的にファイル名を指定しなくてもモジュール名からファイルを探索してロードを行ってくれます。 ただこれら両方において問題となるのが 名前空間 の衝突です。 ロードされたモジュールは共通の permanent root となる Object の 名前空間 に置かれます。 Foo というモジュールをロードした場合、 厳密には Object::Foo になり、 Bar なら Object::Bar となります。 モジュールの開発者は自由に 命名 を行うことができませんし、 モジュールを利用する方も名前が衝突しないように気を使いながら開発する必要があります。 im では匿名モジュールの仕組みを使ってこれを解決しています。 匿名モジュールは作成された時点では 名前空間 を占有しません。 mod = Module .new => #<Module:0x000000015316e1b8> mod:: Foo = Module .new => #<Module:0x000000015316e1b8>::Foo 匿名モジュールに定数を与えた時点で名前が設定されるのですが、 この時 Object ではなく、自身で設定した独自の名前が root になります。 irb(main):019: 0 > MyFoo = mod:: Foo => MyFoo このツリーの中でモジュールを拡張しても共通の 名前空間 は占有しません。 もし MyFoo という 名前空間 で Bar をロードすると MyFoo::Bar となり、 他に MyBaz という 名前空間 があれば、その中では MyBaz::Bar となるので同じ名前で異なる機能をロードできるわけです。 [感想] プロダクトが大きくなってくると名前の衝突って結構面倒な問題です。 我々のサービスでも意図せず名前が衝突してしまって不具合の原因になったこともあります。 また、名前が衝突しないように prefix をつけたり、 名前空間 の階層をたくさん作ったりしますが、 シンプルな名前を自由につけられるようになるのは DX 向上の面でもありがたいです。 Tips and Tricks for working in the MRI Codebase Youtube : [EN] Tips and Tricks for working in the MRI Codebase / Jemma Issroff @jemmaissroff - YouTube Slide: Kaigi 2023.pdf - Google ドライブ [内容] MRI (CRuby) のメンテナンスの手順について説明してくれている How to 的な講演です。 実際にあった issue を題材にして、そのバグの調査を行う過程を見ながら解説をしてくれています。 調査のためには実際にコードの挙動を確認しなくてはいけません。 まずローカルの開発環境に ruby をクローンしてビルドしていきます。 この時全ての機能をビルドすると時間がかかるので、 miniruby という軽量版としてビルドすることも可能です。 次にテストコードを作成して実行しバグの再現をしてみます。 バグが再現することがわかったら、問題となっているコードを探していきます。 ruby で実行可能なコードは C のソースの中では rb_define_ という prefix がついている関数によって定義されていることが多いです。 例えば sum という ruby の関数が定義されている場所を探すなら、 rb_define_method.*sum で grep すれば良いわけです。 また、クラス単位でファイルが分かれていることも多いです。 例えば Array クラスの関数は array.c に定義されています。 このように該当のクラスの .c ファイルを探すというアプローチもあります。 問題の C のコードを見つけたらデバックしていきます。 ruby のコードの デバッグ には irb などが用いられますが、C のコードの デバッグ には lldb または gdb を利用します。 irb と同様に ブレークポイント の設定やステップ実行などをしながらバグの原因をさらに特定していきます。 [感想] RubyKaigi では尖った技術を駆使した最近の成果発表が多い一方で、 このような普遍的な How to を紹介する講演は少なかったのでとても印象に残ってます。 聞いてみるとなんだか自分にも CRuby のメンテナンスができそう（な気がしてくるだけ）になってきます。 僕含め RubyKaigi でこういった世界に初めて触れて面白そう！と思った方にはぜひ聞いていただきたい講演です。 Optimizing YJIT’s Performance, from Inception to Production Youtube : [EN][Keynote] Optimizing YJIT’s Performance, from Inception to Production / @maximecb - YouTube Slide: YJIT RubyKaigi 2023 slides - Google スライド [内容] Ruby 3.2 よりいよいよ YJIT が本番アプリケーションでも実用的だというアナウンスがありました。 この講演では YJIT の開発の歴史を振り返るとともに、 実際に Shopify が本番アプリケーションに YJIT を投入してどの程度パフォーマンスが向上したのか？についてお話ししてくれています。 そもそも JIT コンパイラ とはなんなのでしょう？？ JIT とは Just In Time の略で、プログラムの実行時に コンパイル を行うのが特徴です。 表面上は インタプリタ の様に振る舞うため、 Ruby のような インタプリタ 言語でも違和感なく開発が行えます。 また、事前 コンパイル と違い実行時の環境に応じて最適化を図れるため、より優れたコードを生成できる可能性もあります。 YJIT は初め Ruby と同じく インタプリタ 言語である MATLAB の JIT コンパイラ が原型となっています。 そして登壇者である Maxime 氏が Shopify に Join し、μ JIT -> YJIT へと開発を進め今に至ります。 実際に YJIT は多くが Ruby で作成された Shopify の Website に本番投入され、既にパフォーマンスの測定がなされています。 2023年1月地点で応答速度が 6% 向上しており、 さらに改善が図られた2023年4月にはなんと 18% もの速度向上が認められたようです。 また以前は Warm up のタイミングで膨大にメモリを消費する点が問題となっていましたが、 開発が重ねられた2023年以降は YJIT を使わない場合とほとんど変わらないレベルにまでなっているそう。 [感想] Ruby でアプリケーションを開発している人間にとって、 採用するだけでパフォーマンスが向上する YJIT を使わない手はないよなと思いました。 我々のプロダクトでもガンガン使っていきたいです！ 3日目 The Adventure of RedAmber - A data frame library in Ruby Youtube : [JA] The Adventure of RedAmber - A data frame library in Ruby / Hirokazu SUZUKI @heronshoes - YouTube Slide: The Adventure of RedAmber - A data frame library in Ruby - Speaker Deck [内容] 登壇者の Suzuki さんが開発に携わっている RedAmber というライブラリの紹介になります。 RedAmber はデータフレームを作成、操作するためのライブラリで、 同様の機能を提供しているものは他言語だと Python の Pandas や R の dplyr などが有名です。 データフレームは行方向でデータを操作したり、列方向でデータを操作したりすることができ、 非常に柔軟かつ簡単にデータ処理を行えることが特徴になっています。 RedAmber では各関数の戻り値が Ruby の Array や Hash になっていたり、 Ruby の シンタックス によく似た表現が多く使えるため、 普段 Ruby を使う人にとってはかなり直感的に操作を行うことができそうです。 また、Suzuki さんは普段はエンジニアではない仕事をしているそうで、 こういった OSS 活動はア マチュア として行っているそうです。 [感想] 世界中のあらゆる人が Ruby を一緒に盛り上げているんだなあと感じられる、 Ruby コミュニティの素晴らしさもわかる講演でした！ Ruby + ADBC - A single API between Ruby and DBs Youtube : [JA] Ruby + ADBC - A single API between Ruby and DBs / Sutou Kouhei @ktou - YouTube Slide: Ruby + ADBC - A single API between Ruby and DBs - Kouhei Sutou - Rabbit Slide Show [内容] データベースとアプリケーション間でデータを読み書きするときには多くのオーバーヘッドが発生します。 これはデータが少ないうちはまだ良いですが、 大量のデータになってくるとそのオーバーヘッドによる遅延はとても許容できるものではありません。 講演内で紹介されている ADBC はそのような大量データの読み書きに適したライブラリです。 Read 時には結果セットを分割し並行に処理を行うことで高速化を実現し、 Write 時にはバルクインサートを実行し最適化された大量データの書き込みを行うことが可能です。 また、クライアント側で扱うデータには Apache Arrow データフォーマットを採用し、 こちらもデータベースのデータとの変換コストが非常に安くなるよう設計されているようです。 既に Postgres の一般的なクライアントである libpq との比較では、 1カラム1000万レコードの読み取りで2倍の高速化を実現しているとのこと。 高速化以外の面でも、抽象化された API をインターフェースに持っており、 クライアント側ではデータベースの違いを意識することなく利用できる使い勝手の良さも魅力です。 [感想] Ruby は Rails のイメージが強く、Web アプリケーション向けの言語という印象を持つ方も多いのではないでしょうか？？ こういったデータ処理の分野での利用が盛り上がって、 AI やデータ分析の現場でも Ruby の存在感が増していってくれば Rubist にとってとても嬉しいことですよね！ Code indexing: How language servers understand our code Youtube : [EN] Code indexing: How language servers understand our code / Vinicius Stock @vinistock - YouTube Slide: Code indexing: How language servers understand our code - Speaker Deck [内容] ruby-lsp は Shopify が提供する Ruby のためのモダンな LSP (Language Server Protocol) です。 LSP はエディターと連携して開発者体験を向上させるための様々な機能を提供してくれます。 今回の講演では Go to definition 機能がどのように実装されているのか？というのを詳しく紹介してくれています。 Go to definition は具体的にいうと、呼び出している関数やクラスなどが定義されているファイル、場所にジャンプする機能です。 エディター上でクラス名などの一部をクリックすると、 ファイル名とクリックした場所を含むオブジェクトがどこにあるのか？という index 情報を LSP にリク エス トします。 index 情報にはファイル中の何行目の何文字目にそれがあるのか？という情報が含まれており、 ファイル名と組み合わせることで何がみたいのかを一意に特定できるわけです。 LSP 側では index 情報を受け取って、その場所にあるオブジェクトは何か？を特定し、 また、その定義がある場所をエディター側にレスポンスしなくてはいけません。 このためにはあらかじめ全てのコードの index 情報を持っておく必要があります。 なので LSP では立ち上げ時にこれを行っています。 また、LSP 立ち上げ後のコードの変更に対応できるよう、 変更を検知すると index 情報も併せて更新するよう設計されています。 [感想] これらの機能は Ruby で開発されていて、 この講演では設計/実装内容もかなり詳しく説明されています。 気になるかたは動画の方を見ていただけますとかなりおもしろいと思います！ Unleashing the Power of Asynchronous HTTP with Ruby Youtube : [EN] Unleashing the Power of Asynchronous HTTP with Ruby / Samuel Williams @ioquatix - YouTube Slide: presentations/2023/Unleashing the Power of Asynchronous HTTP.pdf at main · ioquatix/presentations · GitHub [内容] HTTP はあらゆるデータをクライアントとサーバー間でやりとりするための 通信プロトコル です。 現在のインターネットの根幹をなす技術と捉えて差し支えないでしょう。 HTTP は現在から 30 年以上前に誕生し、当初はテキストファイルのみのやり取りしかできませんでしたが、 Web の発展と共に画像や音声データ、動画までをサポートし徐々に進化してきました。 中でも HTTP 1.0 は広く我々に受け入れられ、 長らく Web の世界のスタンダードとなっていましたが、今はその転換機にあると言えます。 まず初めに HTTP 2.0。特に重要なアップデートがストリーミングの多重化による並列処理です。 HTTP 1.0 まででは1つのコネクション内で一度に1つのリソースのやりとりしかできませんでした。 しかし、HTTP 2.0 では同時に複数のリソースを処理できるため、 高速化が期待できるのと、大きなコンテンツを取り扱うと他の処理が待たされる（HoL ブロッキング ）のを回避できます。 次に HTTP 3.0。ここでは HTTP 2.0 にあった欠点をさらに克服しています。 HTTP 2.0 では並列処理といってもコネクションは同じなので、ここが途絶えれば全ての処理が止まります。 しかし HTTP 3.0 では コネクションレス であり多重化されたストリームは独立で、他の処理に影響を与えることはありません。 また固有のコネクションIDを持ち、これらは IP アドレスなどが変わっても固定です。 すなわち途中で通信が途切れて別のネットワークに変わっても継続して処理を行うことが可能です。 これらの機能は通信が不安定になりがちな、屋外でのインターネットの利用において非常に強力です。 今や多くのユーザーが スマートフォン からインターネットを利用しており、 HTTP 3.0 はこれからのスタンダードになっていくことが予想されます。 ただ、 Ruby にて HTTP 2.0, 3.0 をサポートしているアダプタはほとんどありません。 登壇者の Samuel 氏は falcon という HTTP Server の開発を進めており、 既に HTTP 2.0 はサポート済み、年内には HTTP 3.0 のサポートを開始するようです。 [感想] ゴリゴリにネットワークの話で、RubyKaigi のなかでも異色を放っていた講演でした。 ただ自分のような Web 業界の人間にはとても刺さる内容で強く記憶に残っています。 Parsing RBS Youtube : [EN][Keynote] Parsing RBS / Soutaro Matsumoto @soutaro - YouTube [内容] Ruby の型定義を記述するための RBS のパーサーを改善しました、という講演です。 RBS のパーサーはこれまでエラートレラントではなかったので、 シンタックス エラーが発生するような場合に 構文解析 が中断し、 そのエラー理由を知ることもできないという状態でした。 改善されたパーサーでは3つのアプローチでエラートレラントを実現しています。 まず初めに MissingTree の導入。 正しい構文には始端となる トーク ンがあれば終端となる トーク ンが対となって存在する必要があります。 例えばクラスを定義するための class という トーク ンがあるなら、その後に end がどこかで現れる必要があるわけですね。 もし終端の トーク ンが存在しないときは シンタックス エラーを raise する代わりに MissingTree としてノードを作成し、 構文解析 を先に進めます。 次のアプローチは不要な トーク ンをスキップすることです。 attr_reader foo: -> String のような場合ですが、 本来 attr_reader をパースするとき : の後に -> がくるのは構文エラーになるのでここで解析が終了してしまいます。 特定の トーク ンの後に来ても問題のない トーク ンをあらかじめルールとして用意しておき、 ルール外の トーク ンはスキップすることでこの問題を回避できます。 最後がネストされた定義のパースに関する問題です。 例として以下のような構文を見てみましょう。 class Foo class Bar def initialize end Bar クラスに終端がなく、 initialize 関数にも終端がありません。 このような場合どちらも MissingTree として Bar の関数として initialize 関数があると解析されます。 これを以下のように変更したらどうでしょう？ class Foo class Bar ; end def initialize end Bar クラスが編集されて終端記号が補われました。 編集後は initialize 関数は外側のクラスの Foo の関数として解析される必要があるわけです。 これを解決するためには終端記号を最後に補った場所に [EOF] のような トーク ンを追加します。 再度パースを行う際に [EOF] を見つけたらネストを抜け、 外側のメンバーとして解析を行うようにすることでこの問題を解決しています。 [感想] パーサーに関する講演は RubyKaigi 中にも多くありましたが、 みなさんそれぞれ違ったアプローチで問題解決に取り組んでいました。 比較しながら聞いてみるとおもしろいと思います！ 来年は、沖縄で会いましょう！ ありがとうございました！ 株式会社 エニグモ すべての求人一覧 hrmos.co

今回はQAエンジニアのインタビュー記事です。 エニグモ のQA業務の詳細や、QAチームが抱えている課題や今後の展望などについてお話を伺いしました。ぜひご覧ください！ インタビュイープロフィール：K.I   ソフトウェア検証（第 三者 検証）企業でクライアントの様々なプロダクト・サービスの品質管理業務に携わり、2019年に エニグモ に1人目の専任QAエンジニアとして入社。 どのような業務を行っておりますか？ 「 BUYMA 」を中心とした エニグモ の自社サービスの、Webサイトやアプリの品質保証に関する業務を担当しています。 私が所属するチームはサービスエンジニアリング本部というエンジニア組織のQAチャプ   ターです。現在QAチャプターの専任エンジニアは1名体制です（2023年6月15日時点）。  チャプターとは専門性を持ったエンジニアのチームで、QA以外にもフロントエンドチャプターなどがあります。 具体的な業務はQAエンジニアとして、担当プロジェクトの上流工程から関わり、仕様の段階から不具合がないかを確認し、テスト項目を開発側と決めて、開発が始まればテストを行います。また自動テストは Autify を利用しており、会員登録･購入･発送などのシナリオを毎日実行して、Slack へテスト結果を通知しています。 直近関わったプロジェクトは、他社との配送サービスの連携や出品者向けの新規画面の開発などを担当していました。  QAエンジニア1名体制で、どのように エニグモ 全体のQA業務に対応してますか？ もともと エニグモ は専任のQAエンジニアがいない時期の方が長かったこともあり、開発のフローにテストやQAの視点が組み込まれており、ディレクターや開発者がテストを含めた開発や設計を行っていました。 大中規模のプロジェクト、特に iOS 、決済など、不具合があった際、影響が大きいプロジェクトを中心にQAエンジニアの私が担当しておりますが、QAエンジニアがいる前提でないプロジェクトもあります。 プロジェクト参加の流れを教えてください。開発者やディレクターと関わりながらどのように進めていますか？ 参加の流れは、開発者やディレクターから依頼があり、そこで開発スケジュール（リリースの予定や、テスト・開発の期間）を確認します。さらに、ミーティングでより詳細の内容をドキュメントやデザインを見ながら、QAなりの観点で他の機能との不整合がないか、考慮漏れしている画面がないかを確認します。 その後テスト設計や実施を進め、不具合があればチケットを起票して開発者と共有しています。 また、所属するプロジェクトの朝会や定例に参加し、その日の作業や抱えている課題の共有を行います。スプリントの終わりには振り返りを行っています。 開発者やディレクターとは常にコミュニケーションがとれる状況で、不明点があれば、slackやzoomなどですぐに確認ができます。リモートで勤務しているメンバーが多いですが、あまり出社時と変わらない環境で開発を進めています。    現在のQAチームの課題と今後の展望を教えてください。 BUYMA の開発チームは ドメイン ごとに主に4つに分かれています。具体的には、出品者向けの機能を開発するチーム、購入者向けの機能を開発するチーム、モバイルアプリチーム、決済や配送の開発を行うチームです。 それぞれ、開発者やディレクターが所属しておりますが、QAは現在私1名なので、QAエンジニアが上流から入れていないプロジェクトがあることや、案件が重なった時にプロジェクトのリリースを調整する必要があることが課題です。 今後の展望は、QAチームを拡大し、ゆくゆくは各 ドメイン チームに最低1名ずつQAエンジニアが所属する体制にしたいです。QAエンジニアが全ての開発案件に上流の設計フェーズから関わり、プロダクト全体の品質向上を目指したいです。 さらに、そういった体制になることで、プロジェクト アサイ ン時に必要な、 ドメイン ・開発機能のキャッチアップのプロセスが短縮化することで、QAのみでなく開発プロジェクト全体の開発サイクルが速くなることを期待しています。   最後に 現在、QAエンジニアも募集しておりますので、ご興味をお持ちいただけましたらお気軽にエントリーください。ぜひお話ししましょう！ QAエンジニア以外も、 エニグモ では技術課題の解決、サービスグロース、ビジネスやユーザーの課題解決のための開発など、より良いシステム作りを一緒に進めていくためのメンバーを募集しています。   hrmos.co  

自己紹介 初めまして！2023年4月に新卒で入社した中村友哉です！ 入社して早2ヶ月経ちましたが、早く仕事を覚えるためにがむしゃらに働いております。 この記事では、エンジニア就活のことや、 エニグモ に入社してどう感じたかお話しして行こうと思います。 エンジニアを目指したきっかけ 私がエンジニアを目指したきっかけは、小学校からの幼馴染です。 彼とは大学生になっても毎年会うような仲で、よくくだらない話で盛り上がっていました。しかし、大学3年生になると急に意識が高くなっており、別人のようでした。話を聞くとエンジニアを目指すようになってから考え方・行動力を意識して変えていったとのこと。 将来の理想的なキャリアを想像し、そこから逆算して今何をすべきか考え実行する、そんな彼の行動・姿勢に感銘を受け、彼のように自分の考えを持った人間になりたいと思いエンジニアという職業に興味を持ち始めました。 そこから、とりあえず勢いに任せて Python の入門書を買ってプログラミングの勉強を始めました。意外と新しいことをやってみるのは楽しく、 競技プログラミング で アルゴリズム の勉強もするようになりました。 学部時代はプログラミングの授業があり、情報系の知識に触れる機会がありましたが、当時は苦手意識を持っており、まさか自分がエンジニアを志すとは夢にも思いませんでした。 エンジニアになるためにやったこと 大学院に進学するタイミングで就活をスタートしましたが、IT業界・エンジニア種類などの知識が皆無だったことから、どんなエンジニアになりたいか考えるところからスタートしました。 試行錯誤 まずは Python をやっていたこともありデータ周りの技術を学びましたが、途中フロントやバックエンドの技術も学び、現状のスキルのみで自身の適正を判断しないよう心がけました。 この時点では確信は持てなかったものの、データ周りの技術に興味が湧き、データサイエンティストを目指すようになりました。大学院の専攻は電子工学というソフトウェアと真逆のものでしたが、指導員の方と相談して 機械学習 を取り入れた研究ができることになり嬉しかった思い出があります。 それからは、 統計学 ・データ分析をはじめとし、SIGNATEというデータ分析コンペなどで 機械学習 モデルの勉強に取り組みました。 方向性の決定 データサイエンスを学んでいくにつれデータを用意するところが難しいことを知り、その泥臭い作業を担当するデータエンジニアという職種があることを認識しました。 確かに個人レベルで扱うようなデータは綺麗なものが多く、整形せずとも使えることが多かったので気にしていませんでしたが、企業が扱うような ビッグデータ は扱える形にするには多くの苦労を伴うだろうと想像できました。 そこで、ビジネスの世界でどのようなデータが扱われ、どんな苦労が発生するのか知りたいと思い、 修士 一年の12月から東京のとある企業でデータサイエンティストとして インターン を始めました。 インターン 経験 インターン では以下のように幅広い技術を経験させていただきました。 データ分析基盤の開発・運用 BIツールの整備・ビジネスサイドへの展開 自然言語処理 NLP モデルのPoC・プロダクト応用 MLOps プロンプトエンジニアリング その中でも、私が特に興味を持ったのはデータ分析基盤の開発業務でした。というのも、データを活用しようにもデータを活用できる環境がないことには何も始まらないので、非常に重要な領域だと感じたからです。 そのような基盤作りに携わり、社内の関係者・ビジネスに貢献していきたいと思い、データエンジニアになることを軸に就職活動に臨みました。 ポートフォリオ の作成 就職活動に望むにあたって、自分のやりたいこと・技術スタック・課題解決能力などを伝えるために ポートフォリオ の作成も行いました。 私は当時フットサル部に所属しており、我が部のコミュニケーションにおける課題を解決するために部活仲間と協力し、LINEbotを作成しました。ユーザーの要求を満たすことを最優先に考え、できるだけフラットな視点で技術選定を行ったり、私が卒業した後のことも見据え、運用しやすい構成にするなどの工夫を凝らしました。 この開発経験は、データエンジニアとしての技術を伸ばすというよりも、エンジニアとして課題を解決する際の思考・取り組み方を改めて考える良い機会となりました。 就職活動〜入社 修士 一年の1月くらいから本格的に就職活動をスタートしました。 ドメイン にこだわりはありませんでしたが、昔から服が好きだったので、できればアパレル系のデータを扱える企業で働きたいという願望がありました。しかし、アパレル系の事業会社でエンジニアを募集しているところはそもそも母数が少ないので、探すだけでも一苦労でした。 そんな中、自分の好きなインポート系のブランドを扱いつつエンジニアを募集している エニグモ を見つけました。 エニグモ のことを調べていくうちに、「ここしかない！」と思いすぐに応募しました。 一次面接から早速データエンジニア・マネージャーの方とお話しすることができ、自分のやりたいこと、 エニグモ の目指しているところを早い段階で擦り合わせることができました。個人的な野望として、ブランドの情報を集めて最新のファッション動向を知れるようなプラットフォームを作りたいと思っており、そのような考えに共感してくださり、現場のエンジニアの方と意気投合したことを覚えています。 この時点で、ご縁があったら絶対に エニグモ で働きたいと思っていたので、続く二次面接・最終面接では他のチームの業務や、社長の目指しているところを把握することを主眼において面接に臨みました。 面接を担当していただいた方々は全員優しく、素の自分を受け入れてもらったことが印象的でした。内定後も人事の方と何回か面談する機会を設けていただき、不安要素が全くない状態で入社することができました。 入社して2ヶ月経ち感じること 入社後、データ・ 機械学習 ・検索の基盤開発・運用を行うデータテク ノロ ジー グループに配属されました。具体的な業務としては、データエンジニアとしてデータ分析基盤の開発・運用を担当し、他部署からのニーズに応えるため日々データ周りの整備を行います。 入社して一ヶ月くらいは単語レベルでわからないことが多く、いわゆるパニックゾーンに入っていました。特に、現状把握する上でドキュメント等が完全に整っている訳ではないので、現場のエンジニアが前提として備えている技術・知識をキャッチアップするのに苦労しました。 しかし、困っているときは、一人でデータエンジニアを務めてきたメンターの方や、 エニグモ でのエンジニア歴が長く、開発背景を熟知しているマネージャーの方が親身に相談に乗ってくださるので、滞りなく業務することができました。 二ヶ月経った今、まだ周りの方々の手助けなしではタスクを完遂できないので、早くチームの方々、会社に貢献できるような人材になるべく、多くの経験を積んでいきたいと思っています。 今後の抱負 まずは、一人で滞りなく業務を遂行できるようになることを目標にしています。 大きな目標としては、データドリブンな意思決定ができる環境をさらに整え、データの 民主化 を目指していきたいと考えています。 入社式で社長から激励のお言葉をいただき、その中でも「コンフォートゾーンに逃げない」という言葉が胸に刺さりました。その言葉を信条に、日々業務に取り組んでいきたいです。 最後に この記事を見て、エンジニア就活に役立ててくださる方がいらっしゃれば幸いです。 データエンジニアは地味なイメージを持たれる方が多いと思いますが、ファッションデータを扱える弊社は、服好きにとっては楽園のような環境だと思います。 とは言っても、弊社はファッションにそこまで興味があるわけではないエンジニアも多いです。ファッションに興味がないけどデータエンジニアを志す方にとっては、分析基盤の拡大フェーズを経験できるという点でとても魅力的な環境だと思います！ ざっくばらんな話になってしまいましたが、最後までお読みいただきありがとうございました！

こんにちは。サービスエンジニアリング本部の寺田と橋野です。 RubyKaigi 2023にenigmoから2名、現地の参加をしました。 今年のRubyKaigi 2023は2023年5月11日〜5月13日に長野県 松本市 の まつもと市民芸術館 で開催されました。 去年と大きく違うところは、公式パー ティー やスポンサー企業によるドリンクアップの企画があったところです。 去年より多くの Rubyist との交流ができるようになりました！ 本ブログは、前編と後編に分けてお届けします。 1日目 今年は夜に Official Partyが Hotel Buena Vista で開催されました。 たくさんのドリンクやフードが用意されており、立食形式でおこなわれ、自由に参加者と交流することができました。 参加者の中には知り合いの知り合いに出会えたりして、エンジニアの輪はつながっていることを実感することができました。 Official Party後には、Findyさんによるドリンクアップの企画がありました。 そこでは、去年RubyKaigiで知り合った方達と再開することができ、楽しい時間を過ごすことができました。 また、お店も ドライフラワー がたくさん飾ってあってとてもおしゃれでした！ 2日目 2日目にはスタンプラリーがおこなわれていました。 対象の企業ブースを巡り、スタンプを全て集めるとピンバッチをもらえます！ ピンバッチは複数種類があり、どれも魅力的でした。 シールだったりスタンプだったり✨ 夜には、スポンサー企業さんがドリンクアップの企画が複数ありました。 橋野はライザップさんのドリンクアップに参加させていただき、馬肉を食べながら、 Rubyist と交流しました。 参加者の中にMatzさんもいて、色々とお話を聞くことができました。 3日目 RubyKaigi終了後には、アフターパー ティー が開催されました。 また、夜にはRubyMusicMixinも開催されていました。 (私たちは不参加だったため、写真や感想はありません!!😭) 今年は色々な企画やイベントがあり、たくさんの Rubyist と交流することができました。 観光 観光名所へ行ったり等はなかったのですが、名物であるそばを食べました！ 受付時に貰える3000円分のバウチャーチケットがあるのでそちらを使用しました。 駅周りにはたくさんの飲食店があり、ご飯に困ることはありませんでした。 珈琲屋さんや喫 茶店 などの魅力的なお店がたくさんありました。 しゃぶしゃぶも食べました 感想 私にとっては初めての RubyKaigi でした。技術カンファレンスとして多くの最先端の研究に触れられたことはもちろんのこと、何より Ruby コミュニティのことが大好きになれた3日間だったなあと思います。パー ティー では普段からお世話になっている Ruby や Gem のコミッターと出会い、貴重なお話しを聞くことができました。さらにここで出会ったコミッターの方とその後も一緒に オープンソース のプロジェクトに参加させてもらえるようになったりと、自身と Ruby との関わりを一気に近づけてくれました。スポンサーブースではさまざまな企業の方々とお話しをして、同じく Ruby を使って Web アプリケーションを作る仲間としてさまざまな苦悩を共有したり、これはいいなというア イデア を得たりと多くの学びがありました。名刺も交換させていただき、仕事の面でのつながりも作れました。（寺田） 去年参加したRubyKaigi 2022での反省をいかして、気になる発表の情報を事前に調べるようにしたり、事前イベントに参加したりしました。 その結果、去年より話の内容がわかるところが増えたので、用意をしてから参加をしてよかったです！ 今年も同世代のエンジニアの方との交流ができたり、また、女性エンジニアの方と知り合うことができました。同じ悩みを共有したり、キャリアについて色々教えていただいたりして技術以外のことも新たな発見をすることができました。 3日間、発表を聞いたり、コミッターさんたちの話を聞くにつれて、 Ruby のことをもっと知っていきたいという新しい気持ちが芽生えました。 Ruby のしくみを購入したので読み進めたいと思います。 長野県には初めて訪れたのですが、とてもいい場所だったので、次は観光しに行きたいです！(橋野) 後編は印象に残ったセッションの紹介をしていきます！ お楽しみに！ 株式会社 エニグモ すべての求人一覧 hrmos.co

こんにちは。 株式会社 エニグモ 　新卒 2 年目 エンジニアの橋野です。 先月開催された、 AWS Summit Tokyo 2023 に行ってきました。 今年の AWS Summitはハイブリット開催で、オンライン、オフライン共に参加できるようになっていました。 会場での開催は、2019年以来の4年ぶりということです！ 私は、現地で1日目のみ参加させていただきました！会場は、千葉県の 幕張メッセ です。 AWS については初心者ですが、初心者でも楽しめるということで行ってみました！ サミットでの過ごし方 時間 行程 10:00~ 受付 朝昼兼用ごはん 11:00~ スポンサーブース 12:00~ これから始める AWS クラウド 、最初の一歩は AWS Cloud Essentials 13:00~ AWSome Day ～踏み出そう、 AWS への最初の一歩～ 16:00~ ニンテンドー アカウント リノベーションプロジェクト 17:00~ AWS AI サービスを使ってあなたのシステムにも 機械学習 を導入しよう！ 幕張メッセ の会場について、すぐに受付を行いました。事前に受講票を印刷していたので、スムーズに会場内に入ることができました。 スポンサーブースでは、企業から ノベルティ をもらうと受講票をスキャンするという仕組みは新しくて面白かったです。 また、 AWS 社員から直接話を聞けたり、スポンサーの導入事例やスポンサーのサービスを詳しく聴くこともできました。 午後からは予約していたセッションに参加しました。 わたしは業務で AWS を担当していないので、初心者向けのセッションに参加しました。 私が参加したセッションはほとんどがサイレントセッションでした。発表者のマイクの音を手元のレシーバのチャンネルを設定することによって、聴くことができます。新しい！！ この取り組みは、没入感があって受講者としては非常に体験が良かったです。ただ、座席が取れないと立ち見できないので、早めにお席を確保しておきましょう！ 今年は、事前にセッション予約をしていても、5分前くらいまでに入場しておかないと、予約していない方でも入場することができるようになるようでした。(私が見た限りでは) ちなみに、椅子はパイプ椅子なので長時間のセッションを受講するとお尻が痛くなるので、 ノベルティ のクッションがあってよかったです。 印象に残ったセッションの感想 AWS Cloud EssentialsとAWSome Day AWS Cloud EssentialsとAWSome Dayは、 AWS クラウド をこれから利用する方にとって非常に役立つプログラムでした。 この２つのプログラムを受講すれば、 AWS に多様なサービスについて、どのようなことが実現できるのかということを理解することができるようになっています。 AWS Cloud Essentialsは、 AWS の基本的なサービスの紹介でした。具体的には、「リージョンとAZ」「EC2」「RDS」「 VPC 」「責任共有モデル」について理解することができます。 話のテンポがゆっくりで聞き取りやすく、集中して受講できるようなセッションでした。 AWSome Dayの方は、 AWS Cloud Essentialsよりもより、多様な AWS の主要なサービスについて、理解することができるプログラムです。 AWS Cloud Essentialsの内容に加えて、「IoTサービス」「 機械学習 」「 ブロックチェーン 」などについての説明を受けることができました。聞いたことがないサービスなどもたくさんあったので、ワクワクしながら受講することができました。 講演後には、 AWS のエキスパートの方と直接話すことができるので、質問や疑問点を解消することができます。現地参加ならではの魅力です！ 以上のように、 AWS Cloud EssentialsとAWSome Dayを受講することで、 AWS の主要なサービスについて知ることができました！ この２つを受講することによって、より理解が進むことができました。 たとえば、ストレージでは、S3やEFS、EBSという３つのサービスが紹介されていました。私はファイルの管理にはS3を使っていますが、他の2つのサービスについては知りませんでした。 S3は非常に便利ですが、ファイルを直接マウントしたい場合や、より高速な スループット が求められるワークロードでは、EBSやEFSの利用も検討できると思いました。 リレーショナルデータベースでは、 Amazon RDSと、 Amazon Aurora というサービスが紹介されていました。私はアプリケーション開発をしているので、 SQL クエリを通じてデータベースとのやり取りをしますが、そのインフラが AWS やオンプレミスのサーバー上でどのように動作しているのかについてはあまり考えたことがありませんでした。 この講演を聞き、 Amazon Aurora というデータベースを使うことで、高い障害耐性やデータ耐久性を提供していると知りました。 Auroraを利用することでDBの運用が楽になると思いました。 これから AWS を学びたいという方は、来年のSummitで、 AWS をより深く理解するための第一歩として受講することをおすすめします！ ニンテンドー アカウン トリノ ベーションプロジェクト 次に受講したセッションは、「 ニンテンドー アカウン トリノ ベーションプロジェクト」という 任天堂 株式会社と株式会社 ディー・エヌ・エー のセッションです。 このセッションでは、 ニンテンドー アカウントという Nintendo Switch などでゲームをする際に利用するユーザーアカウントシステムにおけるリノベーション案件をどう進めたかのセッションでした。 元々はEC2 + Perl で構成されたシステムで、そのリノベーションを実施する理由としては、いくつか挙げられていましたが、さらなる利用者の増加に伴って、現状の技術スタックでのサービスレベルの維持が困難と判断したことと集約できそうでした。 リノベーションは、アプリケーションを全面的に Perl から Java に書き換え、インフラをコンテナに置き換えていき、 アーキテクチャ をマイクロサービスにしていくという内容です。 多くの企業が採用しているモダンな アーキテクチャ や言語の採用というような一般的な内容に見えます。 実際に移行を進める上で、莫大な Perl のコードを全て Java に書き換えるのはかなりの労力です。 そこで、 ニンテンドー では、一時的に人員を増加させるためのリノベーションチームを発足しました。ここが、私がこの登壇で一番興味深いと思った点です。 このチームはリノベーションが完了された段階で、解体されることを目標に作られたチームで、リノベーションプロジェクトを推進する責務を担っています。 サービスレベルについての責務を持っているチームと独立したチームを作ることによって、保守的にならずプロジェクトを進めることができるという側面があると思いました。 もし、同じチームにしてしまったら、目先のサービスレベルの方が重要になるため、なかなか進まなかったのではないかと思います。 普段使っているサービスのシステムについて知ることができて大変興味深かったです。 参加を通して AWS クラウド について初めて学ぶことができ、非常に勉強になりました。 AWS の基礎知識や主要なサービスについての説明や、それらを活用するメリットや具体的な活用例など、わかりやすく解説していただき、初心者でもとても楽しめました！ AWS クラウド の無料枠の紹介があったので、個人の開発でも利用してみようと思いました。 セッション登録の際にレベルが記載されているので、自分に合ったレベルのセッションを登録することで、楽しめると思います！ また、企業ブースでは、たくさんの展示や AWS の事例紹介があるので、余裕のあるスケジュールを組むとより楽しめそうです。 エニグモ でも AWS を利用しています！ 株式会社 エニグモ すべての求人一覧 hrmos.co

エンジニアの竹田です。 BUYMA の検索システムやMLOps基盤の開発・運用を担当しております。 今回はSolr Operatorによる検索システム構築を行いましたので、その実施内容と得られた知見についてご紹介したいと思います。 はじめに 昨期から今期にかけて、オンプレミスのシステムからの脱却、およびマイクロサービス化を目指し、商品検索システムのリプレイスを進めていました。 エニグモ では機能毎に Apache Solrを用いた複数の検索システムを保持しており、 クラウド 移行に伴い、構築面や運用面の負担は大幅に軽減できております。 なお、リプレイスを行った商品検索システムの構成も下記の記事と大きくは変わっていません。 tech.enigmo.co.jp 今回フォーカスする検索システムの課題 検索システムの運用には、開発案件や障害対応、システムのバージョンアップやシステム増強作業などがあります。 中でも開発案件は、本番と同等のデータを利用したシステムにて検索の並び順や検索ヒット内容の検証が必要となる場合があります。 今まではオンプレミス環境にそのシステムを構築していましたが、今回の商品検索の クラウド 移行に合わせ、同環境を クラウド 上に構築することになりました。 システムのライフサイクルが短いため、より簡素に構築・廃棄を行えるようにしたいという課題があり、そこで案として出たのがSolr Operatorの利用です。 結果次第ではサービス運用でも利用できる可能性も考慮してSolr Operatorを利用した構築の検証を行いました。 なお、本記事ではある程度 Kubernetes や Apache Solrのことをご存知の方を対象としている点をご容赦ください。 Solr Operatorについて Welcome - Apache Solr Operator Solr Operatorは Kubernetes のCRD(Custom Resource Definition)として提供されているもので、SolrCloudやZookeeperClusterといったkindによりSolrシステムを一元管理するイメージという理解で良いかと思います。 2023/04/24にv0.7.0がリリースされています。 Solr Operatorの概要や簡素な構築方法については、 Google CloudのShimojo様が非常に分かりやすいブログ記事を公開されていますので是非ご参考にしてみてください。 Solr Operator を利用して SolrCloud クラスタ を GKE Autopilot に構築する (前編) zenn.dev Solr Operator を利用して SolrCloud クラスタ を GKE Autopilot に構築する (後編) zenn.dev 構築時の簡単な構成は、以下のようになっています。 Zookeeper Operatorについては特に触る必要がなかったため、本記事では触れていません。 構成図 Solr Operator CRDの各リソース項目について Solr OperatorはCustom Resource Definition(CRD)として提供されており、項目に合わせて定義を埋めていく形になります。 構成管理を考えた場合、 helm install でSolrCloud クラスタ を構築する際に適宜パラメータとして指定するよりも、 Kubernetes マニフェスト として管理するのが望ましいと思われます。 ※ helm install ではなく、 マニフェスト を作成して kubectl apply -f <作成したマニフェストのyamlファイル> で構築する方式 以下に、 kind: SolrCloud において利用頻度が高いと見込まれるパラメータを列挙してみました。 spec配下の設定項目 内容 備考 solrImage 利用するsolrのコンテナイメージを指定 独自ビルドしたイメージも指定可能 solrOpts solr起動時のパラメータを指定 solrJavaMem java のヒープサイズを指定 solrAddressability solrの解放ポートや外部接続定義を指定 solrGCTune GarbageColleciton用のチューニングパラメータを指定 customSolrKubeOptions solrのカスタム項目を指定 (※1) updateStrategy solrの更新方式をを指定 未指定時のデフォルトがrollingUpdateのため注意 dataStorage solrのデータ格納先ストレージ persistentにして永続ディスクを利用 replicas solr podのレプリカ数 (※1) 以下、customSolrKubeOptions配下の項目 spec.customSolrKubeOptions配下の設定項目 内容 備考 ingressOptions 外部に ingress を利用している場合に利用 annotationsでBackendConfigを指定するなどで利用 configMapOptions providedConfigMapにカスタムConfigMapを指定 solr.xml や log4j2.xml を定義できる podOptions solr podに対するオプション項目 (※2) (※2) 以下、podOptions配下の項目 spec.customSolrKubeOptions.podOptions配下の設定項目 内容 備考 resources CPUやメモリのlimits/requestsを設定 livenessProbe Solrが動作しているかどうか 指定しないとhealthcheckが通らず、podが起動しない readinessProbe Solrが トラフィック を受けられるかどうか 指定しないとhealthcheckが通らず、podが起動しない initContainers Solr PodのinitContainersを定義できる sidecarContainers Solr Podに設置する サイドカー コンテナを定義できる あくまでサンプルですが、以下のような マニフェスト になるかと思います。 apiVersion : solr.apache.org/v1beta1 kind : SolrCloud metadata : name : example namespace : solr spec : replicas : 3 solrImage : tag : 9.2.1 pullPolicy : IfNotPresent solrGCTune : -XX:NewRatio=3 -XX:SurvivorRatio=4 solrJavaMem : -Xms2048M -Xmx2048M solrAddressability : commonServicePort : 8983 updateStrategy : method : StatefulSet dataStorage : persistent : pvcTemplate : spec : resources : requests : storage : 100Gi reclaimPolicy : Retain customSolrKubeOptions : configMapOptions : providedConfigMap : solr-config-map # configMapは先に作成・適用しておく必要がある ingressOptions : annotations : cloud.google.com/backend-config : '{"ports": {"8983":"solrcloud-backend-config"}}' cloud.google.com/neg : '{"ingress": true}' podOptions : resources : limits : cpu : 2 memory : 6Gi requests : cpu : 2 memory : 6Gi livenessProbe : initialDelaySeconds : 30 periodSeconds : 10 httpGet : scheme : HTTP path : /solr/admin/info/health port : 8983 readinessProbe : initialDelaySeconds : 15 periodSeconds : 5 httpGet : scheme : HTTP path : /solr/admin/info/health port : 8983 補足となりますが、Solrが起動しない場合は、概ね以下の方法で原因を特定できます。 Solr Podを kubectl describe で確認 kubectl describe pod example-solrcloud-0 -n solr solr-operator Podを kubectl logs で確認 kubectl logs solr-operator-xxxxxxxxxx-xxxx -n solr マニフェスト 適用後は、solr スキーマ 定義やsolrconfig. xml の配置、コレクションの作成と進めて検索できる状態にします。 こちらの作業についての手順は割愛します。 Solr起動後の管理画面等への接続については、上記で図示した通り ingress 経由としました。 実際に構築してみた所感 まだ検証段階ではありますが、以下の恩恵を得られるものと思います。 Zookeeperを特に意識しなくて良い ディレクト リ構成も基本的には意識しなくて良い SolrCloudを構築する上でのSolrの学習コストが下がる マニフェスト さえ用意しておけばSolrCloudシステムの作成、削除がkubectlコマンド一発で完遂する CRDの項目が充実しており、かなり細かい点まで定義可能 苦労した点としては以下になります。 マニファストの設定誤りや漏れがあると結構ハマる 特にヘルスチェック、リソース定義周りの定義誤りは何が問題なのか分かり辛い CRDはかなり長大な マニフェスト のため読み解くのが大変 Yamlの参考リンク 日本語での参考文献がほとんどない 運用利用に当たっては以下の項目を意識・検討する必要があることも分かりました。 Solr Operatorで構築できるのはSolrのインフラ面のみ Solrの スキーマ 定義や構成ファイルの配置は configsets API や zkCliコマンド を利用する必要がある アクセス周りのセキュリティを気にしておく必要がある 監視関連の定義は別途検討の必要がある エニグモ では検索システムの監視にDatadogを利用しているため、対応方法を調査・検討する必要あり Solr Prometheus Exporterを利用する方法もある 用途の異なる検索システムを1つのSolrCloud kindに集約しない方が良いかもしれない Solr Podの名称がprefix固定の連番suffix(例: xxx-solrcloud-1 、 xxx-solrcloud-2 )での管理となるため、Pod名称から用途が判別し辛い 実サービスでの利用はAutopilot クラスタ よりStandard クラスタ の方が良いかもしれない オートスケールに時間を要するため、ある程度リソースが確保された状態でないと運用は難しそう Solr Operator自体のバージョンアップへの追従 また、合わせてSolr構成も見直した方が良いと感じました。 NRTや全TLOGのレプリカタイプでコレクションを作成した方が良い 1podがダウンしても更新や検索に影響のないシステム構成にする必要あり 必然的にDataImportHandlerのようにデータをpullする方式の採用は難しくなる 検証用途には手順を圧縮できるため便利に感じる一方、サービス運用には検討すべきことが多いという印象でした。 業務等でSolr Operatorの利用を検討されているようでしたら、本記事が一助になれば幸いです。 最後に 弊社では、本記事に記載したような新しい取り組みや、より良いシステムを作りを一緒に進めていくためのメンバーを随時募集しています！ 株式会社 エニグモ すべての求人一覧 hrmos.co

BUYMA Globalの事業統括責任者をしているHibaruです。 私はエンジニアではないのですが、プロダクトマネージメント業務にも携わっており、今回は私が BUYMA Globalのプラットフォームに導入したAI企業「 Mad Street Den （以下MSD）」が開催したカンファレンスに招待いただき、たくさんのインスピレーションを得ることができたので、ブログを書かせていただきます。 Montego Bay, Jamaica カンファレンスが行われたのは、なんと カリブ海 にあるジャマ イカ 。 私は普段ロサンゼルス在住なのですが、ジャマ イカ は初上陸でした。 今回は開催企業の取引先で米国企業を中心に世界中からリーダーシップが招待され、 ケーススタディ や新しい技術へのアプローチ方法などをディスカッションする2日間のイベントでした。 DAY 1: Dinner / Meet & Greet 美しい カリブ海 に浮かぶジャマ イカ のMontego Bayにあるリゾートに全員宿泊し、そこからバスで歴史的なハウス ミュージアム であるローズホール・ゲストハウスへ。 Rose Hall Guest House REBUILDと題されたイベントは今回で3回目の開催だそうで、初回はインド（MSDはインドが本拠地です）、2回目がドバイだったそうです。 REBUILDは単なるイベントではなく、「コミュニティ」だと開催にこめた思いなどがMSDのCEOとCTOから語られました。 “テク ノロ ジー のトレンドは、ユーザーのインフルエンス力が大きなパワーとスピードをもたらす” Dinnerの Keynote スピーチは、元P&GでGlobalのITチーフをしていたAndy Walter氏が務め、レガシー的な大きな組織に「インターネット」を導入した際のお話や、彼のキャリアでは常に「もっと社内の人にインフルエンスしなさい」と言われ続けてきたストーリーを話してくれました。 それから、Chat GPTの話にもなりましたが参加者たちの意見では Google がいずれovertakeするだろうとの見解。 この大きなトレンドには、業界の インフルエンサー たちが大きく貢献しているという例でした。 Dinner Dinnerでは海外のビジネスシーンでは欠かせないネットワーキングで、お互いのビジネスやチャレンジ、コラボレーションの可能性などを話します。（これがいまだに苦手ですが頑張りました） アフリカ向けにブティック連携した マーケットプレイス を展開している会社や、 中南米 の Amazon と呼ばれる マーケットプレイス などEcommerceに関わる企業や、メディカル、 ファイナンス など様々な業界から、CEOやCTO、プロダクトマネジャーが参加していました。 Day 2: Case Studies & Panel Discussion 2日目はカンファレンス本番で、会場を Half Moon Resortに移し、朝から夕方まで ケーススタディ やパネルディスカッションが行われました。（ちなみにこの Half Moon Resortは、 エリザベス女王 を始め多くのロイヤルファミリーが宿泊したそう！） データセントリック vs モデルセントリック？ 世界のCIO, CDTO, CDO , CEOが回答した答えはクリアだった Data centric AI approach AIにフォーカスする市場での答えは「 データセントリック 」 CDO とCIOは、20-21年にAIに $50B を費やしたが、ビジネスの成果という点では、何の成果も得られていない（*MITSloan） 機械学習 やAIの技術者・担当者は、「モデル構築」することにフォーカスしがち。しかし正解は「 データのクリーンアップ、コネクト＆ アクティベーション 」である（モデル構築が答えではない） 全ての基盤となる「データ」 Data is everything MSDが考えるAIアプローチ・AI Transformationの始まりは、全てデータから始まる。 データがクリーンでない、統合されていない、正しいデータソースを見極められない、これらができていないと、結果としてコストが高くなり（データサイエンティストやマニュアル作業の時間的コストも含める）ROIが見合わなくなり、エンドレスにモデル構築をしなければならない。 “これまでの「AI Transformation」から「ROI-Driven AI Transformation」へ” ケーススタディ から学ぶAIアプローチ AYA Healthcare : San Diego発のトラベルナース派遣サービス。Pandemicで急激に増えたトラベルナースの アサイ ンメントのマッチングをするため、リアルタイムで対応できるAIレコメンデーションを使用。 ナースのプロフィールやスキル・資格と アサイ ンメントが合っているか、お給料の希望レンジや希望ロケーションなど、そして特別な アサイ ンメントには条件がクリアできるナースが登録している中から2名とかしかいない場合もあるので、そういった急務な案件をそのナースの検索結果のトップに出せるようにした。 今後はDocumentationスキャンのAutomationを導入しようと思っている。ナース登録や アサイ ンメントに入る際のAgreement、書類のアップロードなどがスムーズにできるようにする Fedex : Fedex x ShopRunner のFulfillment OptimizationにAI活用。 特に荷物がどこのロケーションにあり、どこへ送るのか、またカスタマーが希望している優先順位は何か（配送の速さ、Sustainability、価格）によって配送オプションの出しわけをできるようにした。今後Cross-border向けのDocumentationスキャンもAI導入予定 PICARD : ドイツ発の老舗バッグブランド。PandemicをきっかけにOnline Storeに力を入れることになったが、モデル着用画像がなくEcommerceパフォーマンスは低迷。MSDの提供するVue.aiモデル着用AIを利用し、CVR +65%、AOV +12%、返品率 22%ダウンを実現させた。 Retail業界をAIがどう変えていく！？ 実はこのテーマのパネルディスカッションに私も登壇させていただきました。 英語で世界のリーダーたちとゲストの前で登壇をするのはとても緊張しましたが、前もってかなり練習をしていったので、スムーズに発言できたのではないかと思います。 終わった後にたくさん皆さんに声をかけていただき、また BUYMA のサービスにもとても興味をもっていただけました！ 消費者の検索動向トレンドに合わせてAIを活用していくケースや ユースケース が出てきている AIを導入することでパーソナライゼーションやレコメンデーションが大幅進化している！例えば同じアカウントを使って違う家族のメンバーがお買い物をしようとしていたら？アクセスする時間帯と傾向をマシンラーニングし、そこでパーソナライゼーションやレコメンデーションを出し分ける例まであるそう。 過剰在庫の世界的問題にAIがどう貢献できるのか？この過剰在庫という問題は環境やエコノミーにも非常に大きく影響している世界的問題。AIを使って、過剰在庫になる前にそれらの商品を予測し、プロモーションをしたり、追加発注をしないようにできる技術も開発されている。 Innovation x Leadership（AIや新しい技術へのアプローチ、組織改革へのアプローチ） Victoria's Secret: どのようにDigital innovationをLegacy化した大きな組織に素早く導入するか。 Story-tellingできるプロトタイプを作ることが重要。 50つのアイディアがあっても、そこから検討テーブルに上がるのが7-8つだったそう。 PassionがInnovationを作っていくこと、社内で新しいInnovationやアイディアをインフルエンスしていくことが重要だとここでも語れました。 そしてGen-z世代はTechnologyと共に生きているので必要不可欠であることを理解する。 Mercado Libre : 中南米 の Amazon と呼ばれる大規模な マーケットプレイス 。 ビジネス拡大が加速し、1000人未満だったエンジニアが数年で15000人のエンジニア組織に急速拡大。 大きな技術・組織改革において、「Culture / Language / Technology」を素早く共有し、適応してもらうにはかなりのチャレンジがあった。 10000人以上にNew Hireのうち、なんと70%がRefarralで構成されていることで、「Culture / Language / Technology」の適応の大部分をカバー、30%は全くの未経験も含んでいたが、この3割にはト レーニン グに注力した。 たくさんの学びがありましたが、 Key Takeaway をまとめてみます。 ★基盤となるデータの重要性 ★TechnologyはCultureであること（技術そのものが人の役割をTake overするのではなく、技術を理解しどのように扱う・活用するか考える人が重要である） ★TechnologyはCommunityであること（今回のイベントのように、様々な業界から人が集まり ケーススタディ やUse caseをシェアし、課題を共有し、アイディアを出せること） 2日目はカンファレンス後、プライベートアイランドでサンセットを見ながらのパー ティー 。 こんな規模でイベントを開催するMSDにとても驚き感心しました！ そして何よりMSDのCEOはインド人の女性で、テク ノロ ジー 業界で成功する女性としてインスピレーションをもらい勇気づけられました！ Bonding with girls in tech! エンジニアではない私の体験＆感想を書かせていただきましたが、いかがでしたでしょうか？ 次回はぜひ社内のデータサイエンティストやエンジニアの方にも参加してもらえたら、また違った視点でインスピレーションがあるのではないかとおもいました。 最後まで読んでいただき、ありがとうございました！ Hibaru

サーバーサイドエンジニアの岡本です。 BUYMA の出品者向け機能の開発を担当しています。 弊社のエンジニアチームでは、昨年後半からいわゆる「お問い合わせ対応」の組織的な取り組みを行っておりますので、少しではありますがその取り組みについて紹介したいと思います。 エニグモにおけるお問い合わせ対応 お問い合わせ対応の流れ 調査 休日の対応 身に付いたことや改善点など エニグモ におけるお問い合わせ対応 これまで社歴の長いエンジニア数名が対応することが多かったのですが、エンジニア組織体制の見直しに伴い、CS対応の運用方針に関してもテコ入れを行うことになりました。 特定のメンバーがお問い合わせに対応することで他のメンバーに対してナレッジを共有する機会が少なくなり、お問い合わせ対応が属人化してしまうという問題を抱えていました。 BUYMA は機能ごとに大きくSELL/BUY/SI *1 の3チーム（以下、 ドメイン と呼ぶ）に分割している *2 ので、各 ドメイン から一次担当を行うメンバーを選抜し、 ドメイン ごとにお問い合わせに対応する運用を行うようにしました。 運用開始から半年以上が経過しましたので、振り返りを行います。 お問い合わせ対応の流れ お問い合わせ対応で取り組んでいることは以下になります。 一次対応 再発防止策の検討 ナレッジ共有のためのドキュメント作成・定期チケットの作成 休みの共有・緊急時対応への備え 調査 カスタマーサービス チーム（以下、CSチーム）の方がCS対応用のチケットを作成いただき、Slackで連絡していただきます。それをみて対応できそうなメンバーが順次チケットの内容を確認します。 不具合の報告の場合は、弊社で管理しているお客様のアカウント情報をもとに アプリケーションサーバ のログを追跡したり、仕様の調査を行います。調査が終わればチケットに調査内容を記載した上でCSチームの方に連絡をします。ここで、チケット作成から一次調査完了までのスパンをできるだけ短くできるように各自心掛けています。CSチームの方が調査が難航する場合もありますので、その場合はお断りを入れた上で調査を続けます。 調査の上でアプリケーションコードの修正が必要な場合は対応を行います。別途起票をして対応することが多いです。 データ補正が必要な場合は修正用の SQL 文を作成し、レビューを経た上で本番のDBサーバに対して実行します。 一次対応の流れ 対応したチケットは スプレッドシート に記載をして、ふりかえりを行う際や別のお問い合わせの調査を行う際に活用しています。 調査をしてみて、対応した内容や参照したログ、実行したコマンドなどなどを esa 上のドキュメントに記す取り組みも実施しています。 ドメイン ごとに整理でき、とても良いと感じています。 一次対応~対策防止策検討~ふりかえり 休日の対応 有給休暇を取る場合は事前に ドメイン 内で伝えておき、別のメンバーが対応できる体制を整えています。 また極めて稀ではありますが、土日祝日に緊急対応が必要な場合がありますので、待機できるメンバーを予め選出しています。 身に付いたことや改善点など 先日、お問い合わせを担当するメンバーに意見を聞き、これまでの取り組みを通じて身についたことや今後の課題などを話しました。 身に付いたこと ログ監視ツールを使ったり該当のログサーバに ssh するなどして、 アクセスログ やスナップショットを参照する方法が身についた BUYMA の ビジネスロジック を理解する機会が増えた。また、自身の担当 ドメイン 以外のコードも読む機会が増えた 作業見積もりの能力 例えば、午後1時にお問い合わせがきたら調査や作業に4時間くらい確保できると見積もり、その時間内でできそうなことを予想する。 限られた時間内で出来る複数の対応策を提案する CSチームのメンバーとの連携、検索やモバイルなど他チームとの連携を仰ぐ 今後改善できそうなこと 個人的な マインドセット 寄せられるお問い合わせに怯まず淡々とやる 依頼を受けてから返答するまでの時間の短縮・判断力の向上 組織的仕組みづくり 属人化しないために調査手順ドキュメントや仕様の拡充 お問い合わせ対応のリードタイム計測 バグ傾向の分析 お問い合わせ報告が多い機能を分析し、改善につなげる。 定期チケットの作成 プラスになる点として、 BUYMA 及び ECサイト の ドメイン 知識が身につくのは大きいと思います。私も入社して3年目となり、担当している出品者向け機能について少しは知っていると思いますが、まだ把握し切れていない仕様・機能は多くあります。特に決済や配送方法は難しい…。日々のお問い合わせ対応を通じて知見をアップデートしています。 改善点は様々ありますが、隔週で定例会議を行っており、日々改善に向けて取り組んでいます。 株式会社 エニグモ すべての求人一覧 hrmos.co *1 : SELLは出品者向け機能、BUYは購入者向け機能、SIは決済や配送などサービス基盤を担当 *2 : モバイルアプリやデータ分析や 機械学習 系や企画系などチームは他にもあります

こんにちは、22卒エンジニアの 川本 です。 先日「 AWS JumpStart 2023 設計編」という研修に参加してきました。 2日間と短い時間でしたが、とても内容が濃くて勉強になったので、本記事では研修の内容や参加した感想を綴っていきたいと思います。 AWS JumpStartとは？ AWS公式HP では以下のように書かれております。 「 AWS JumpStart 2023 設計編」は AWS 初学者のエンジニアの方々を対象とした、実践的な研修プログラムです 将来的に AWS 活用をリードする人材になるための第一歩をスムーズに踏み出せるようなプログラムをご提供します 単なる AWS サービスの学習だけでなく、要件に合わせて適切な アーキテクチャ を検討・設計する経験を積む部分にフォーカスした内容となっております 例えば、以下のような方々にもオススメです！ ・ AWS の名前は知ってるが使ったことは無い ・ EC2 等の単体サービスは触ったことあるが、全体のアーキテクティングは経験がない ・ クラウド ネイティブなアプリケーションを設計する上で重要な観点を知りたい AWS 初学者向けの クラウド アーキテクチャ を検討・設計するイベントで、参加人数が600人以上いる大規模イベントでした。 プログラム内容 研修は以下の構成で行われました。 事前学習 ハンズオン グループワーク 事前学習 研修参加前に事前学習として、 AWS SAA向けの動画学習教材が送られてくるのでそちらで AWS の基本的なサービスについて学習します。 また、 AWS のサービス説明だけでなく、アーキテクティングのコツみたいな内容も盛り込まれており、研修当日に非常に役に立ちました。 私は完全に AWS 未経験だったため、こちらの教材で事前学習しておいてほんとによかったです。 ハンズオン 1日目にまずハンズオンがあり、 AWS 上にTodo管理アプリを構築するといった内容でした。 以下の図のように ALB + ECS on Fargate + Aurora MySQL の アーキテクチャ を構築しました。 ハンズオンの中で面白くて勉強になったのが、上記の アーキテクチャ でECSタスクを片方停止させたときの挙動や、Aurora MySQL のフェールオーバーを実行したときの挙動を実際に手を動かして確認したことです。 ECSタスクが片方死んでも自動復旧している様子や、フェールオーバーしたことによりAurora MySQL のリーダーとライターが切り替わる様子を確認することができました。 このような実践的なハンズオンのおかげで、可用性やスーケラビリティを意識した アーキテクチャ とはどういうことなのかというイメージがより具体的になりました。 また、ここまでの アーキテクチャ を個人で作成するとお金がかかりますが、その辺りを意識せずに AWS サービスを触ることができるのもうれしいポイントですね！ グループワーク 2日目はグループで課題に沿った アーキテクチャ を構築するといった内容でした。 以下のような要件を満たす ECサイト を構築してくださいという課題が与えられました。 提供規模 利用者数:数万人 ピーク時間帯:日本時間の朝夕 提供エリア:日本 提供プラットフォーム:web システム要件 バックエンド: Java /Spring Boot（Dockerで開発中） フロントエンド:TypeScript/ReactJS データベース: MySQL 必須機能 商品一覧ページ 商品情報 商品画像 カート機能、購入機能 決済、在庫管理、配送システムは外部の SaaS API を利用するものとする アカウント管理機能 追加要件 CI/CD BI ダッシュ ボード機能 レコメンド機能 普段から BUYMA の開発をしておりECサービスには馴染みがあったのでイメージしやすかったです。 しかし BUYMA は全ての箇所で AWS 上のサービスを使っているわけではありません。 なので、 BUYMA のこの部分は AWS だとこのサービスが使えるなというような観点で アーキテクチャ を構築していきました。 このような観点で アーキテクチャ を構築することで BUYMA への理解も深まったので、私にとっては一石二鳥な課題内容でした。 最終的に構築した アーキテクチャ は以下構成図です↓ 工夫した点としては、 ECS on Fargateの構成によりコンテナのAutoScalingを実現してサーバーの可用性up RDSはMulti-AZ構成として、障害発生時にフェールオーバーしてリーダー、ライター インスタンス が切り替わるようにして可用性up ElastiCacheを使うことでデータベースクエリのレスポンスを高速化 Cloud Frontを使うことで静的コンテンツ配信の高速化 他にもCI/CDの整備やBIツールの導入、レコメンド機能への対応などを行いましたが、 AWS にはそれぞれに適したサービスが用意されており、本当にサービスの種類が豊富だなと思いました。 研修を終えた感想 参加前は AWS についてはなんとなくサービス名を知っている程度でしたが、研修で実際にハンズオンで手を動かしたり、チームで アーキテクチャ 議論をすることで AWS の全体感を掴むことができました。 また、Webアプリケーションの アーキテクチャ を設計する上で意識すべき可用性やスケーラビリティについて学べたことが大きな収穫だったかなと思います。 AWS のサービス名について知っていても、 アーキテクチャ を設計する上で重要なことがわかっていないと適切なサービスを選択することもできませんし、設計することもできないと感じました。 最後に 今回の研修を機にインフラのことについても少し興味が湧きました。 AWS SAAの資格取得なども目指していきたいです。 最後に、このような素晴らしい研修を無償で開催してくださったアマゾン ウェブ サービス ジャパン 合同会社 の皆さま、ありがとうございました! 株式会社 エニグモ すべての求人一覧 hrmos.co

こんにちは、インフラエンジニアの 加藤( @kuromitsu_ka )です。 はじめに Amazon RDSのEoS対応で、 インスタンス クラスとエンジンバージョンを変更する作業をしました。その際、 インスタンス クラスとエンジンバージョンを同時に変更しようとしたのですが即時適用されず困りました。 EoS関係のドキュメント Amazon RDS for PostgreSQL リリースカレンダー - Amazon Relational Database Service DB instance classes - Amazon Relational Database Service 解決の流れ 社内のサポートを受けて、保留になった変更を取り消す方法を教えて貰いました。保留になっていた インスタンス クラスとエンジンバージョンの変更の内、エンジンバージョンの変更を取り消したところ、 インスタンス クラスの変更が走りました。その後、エンジンバージョンも変更して、無事、メンテナンス対応できました。 わかったこと Amazon RDSの変更が保留に入ってしまった問題ですが、 AWS サポート窓口に質問したところ、既知の問題だったそうです。 Amazon RDSの インスタンス クラスとエンジンバージョンを変更する際は、 インスタンス クラスと、エンジンバージョンとで、2回に分けて変更する手順を推奨しているとのことでした。 以下、作業ログ インスタンス クラス エンジンバージョン 作業前 db.m3.xlarge 11.15 作業後 db.m5.xlarge 11.18 インスタンス クラス変更とエンジンバージョンのバージョンアップを同時に適用しようとしたら、変更が保留になってしまった。 実行したコマンド $ aws rds modify-db-instance \ --db-instance-identifier ${DB名} \ --engine-version ${バージョン} \ --db-instance-class ${インスタンスクラス} \ --no-allow-major-version-upgrade \ --apply-immediately --apply-immediately をつけているのに保留となってしまった。 "PendingModifiedValues": { "DBInstanceClass": "xxx", "EngineVersion": "xxx" }, 保留の取り消し 変更前の値を適用することで、保留状態を脱することができました $ aws rds modify-db-instance \ --db-instance-identifier ${DB名} \ --engine-version ${変更前のエンジンバージョン} \ --apply-immediately 保留されていた インスタンス タイプ変更が始まった。 よかった!! 振り返り 該当の インスタンス クラスが、エンジンバージョンをサポートしていないというわけではありませんでした。 Amazon RDS DB エンジンとインスタンスクラスでサポートされている Performance Insights - Amazon Relational Database Service 今回の問題ですが、開発環境ではうまく行って、本番環境だけ発生しました。 こちらは一度のコマンドで インスタンス クラスもエンジンバージョンも変更できた。（たまたまかもしれない。 インスタンス クラス エンジンバージョン 作業前 db.t2.micro 11.15 作業後 db.t3.micro 11.18 当日は、困りましたが、その場で社内のサポートを受けて解決できました。個人的に、 Amazon RDSの変更取り消し（と言っていいのか微妙ですが）コマンドが、裏コマンドっぽいので気に入りました。 株式会社 エニグモ すべての求人一覧 hrmos.co

～合議制 “Committee体制” の導入～ 目次 新体制の導入の背景について Committee体制の実行に向けて Committee体制の詳細について ビジネスサイドとの連携について 〈インタビュイー経歴・紹介〉 安藤 英男　COO／取締役 最高執行責任者 1997年に株式会社 電通国際情報サービス に入社。2004年株式会社 エニグモ 設立。2005年当社取締役、2010年に当社COO(取締役 最高執行責任者 )に就任。 木村 慎太郎 / エンジニア リングマ ネージャー Committee Head 2013年に エニグモ にWebアプリケーションエンジニアとして入社。 データ・ 機械学習 ・検索の基盤開発・運用を担当するエンジニアチームを立ち上げ、 BUYMA のエンジニア組織のマネージャーおよび、組織の運営方針を決定する合議体のHeadを務める。 山本 浩貴/ エンジニア リングマ ネージャー Committee Vice Head 2016年に エニグモ にWebアプリケーションエンジニアとして入社。 現在は出品者向け機能を開発するチームとフロントエンドチームのマネージャーおよび、組織の運営方針を決定する合議体のVice Headを務める。 〈インタビュアー経歴・紹介〉 大谷彰徳/ コーポレートオペレーション本部　人事総務グループ部長 2002年株式会社 博報堂 入社。アカウントプロデュース職として国内外企業のコミュニケーション施策に携わる。2015年に エニグモ に入社。コーポレートオペレーション本部／人事総務グループの部長に就任。採用、人事企画、 労務 、総務、コーポレートITの領域を統括。 新体制の導入の背景について 大谷： 今回、当社のエンジニア組織のマネジメント体制が大きくリニューアルされましたが、その背景や経緯についてCOOの安藤さん、エンジニア リングマ ネージャー（以下EM）の木村さん・山本さんにお話をお伺いできればと思います。 まずは本題に入る前に安藤さんにお伺いしたいのですが、COOとしてどのようなことを意識して、日頃からエンジニアの組織やメンバーと関わっていらっしゃいますか。 安藤： エンジニア以外にも当てはまることですが、特に意識している部分は、まず「人」の部分になります。 どのメンバーに重要なロール（役割）を担ってもらうかの判断はとても大事なため、そこはしっかりと自分なりの確信を持てる状態にしたいと思っています。 技術的な部分は基本的に自分が戦略を立てるわけではありませんが、会社レベルで決めるべき重要なことは、技術的な領域でも重要なロールを担うメンバーとディスカッションした際に、その良し悪しを自信をもって判断できる状態にしています。 大谷： 「どういう人にどのようなロールを担ってもらうのか」という判断は、まさに組織作りにも大きく関わる部分ですが、今回その組織作りの取組みのひとつとして実施された 「Committee体制」 の導入についてお聞きしたいと思います。 今回、 エンジニア組織をCTOや部長を頂点とするワントップ型ではなく、EM陣で構成する「Committee」という合議体を意思決定のトップ機関として新設し、そのHead、Vice Headを1年交代の輪番制で運営する という体制への移行しましたが、その導入背景を教えてください。 安藤： これまで エニグモ はエンジニア組織に関わらず、会社全体として少数精鋭の筋肉質な組織で成長してきました。その為、当社の技術志向の高いエンジニア達には過度なマネジメント負荷をかけずに開発に専念してもらいたいという思いがありました。それがフラットな組織で フルスタ ックに自分のスキルを発揮できる環境に繋がり、そこを魅力に感じるエンジニアが自然と集まっていました。 そして上場から10年が経ち、技術領域も多岐に広がり、組織やサービスも格段に大きくなり、今までのやり方で組織を最適にマネジメントすることが難しくなってきました。 それまでは経営陣もエンジニアにはマネジメントの負荷をなるべくかけないようにと考えていましたが、当社らしいエンジニア流のマネジメント体制への進化が必要なフェーズになりました。 そしてEMたちからも「組織的な課題を解決したい」「こういう組織にしていきたい」という前向きな意見が自然と出てくるようになりました。そのような中で、これまでの エニグモ のエンジニア組織のカルチャーを大切にしながら最適な方向を検討する中でCommitteeというコンセプトが思い浮かびました。 大谷： 新体制の中でも特徴的な 「EM陣による合議制」 のコンセプトや 「CommitteeのHeadとVice Headを1年交代の輪番制」 にしようと考えた背景はなんでしょうか？ 安藤： 社内のエンジニアで組織のトップの経験がないメンバーでも、ハードルが高くならずチャレンジしやすいようにしたかったのが一つです。また、属人化させず色々なメンバーの意見を取り入れて多面的に進化していく組織体制にしたいと考えました。 属人化しすぎないためにトップが行う業務を分解して「ロール（役割）」という抽象的な言葉で定義し、それをいろいろな人の手で育てていくような体制であっても良いのではないかと思いました。重要な判断をともなうロールなどにおいても、それをサポートする他のCommitteeメンバーも次回自分がやる可能性がある状況に置くことで、「自分だったらどうするか」という視点になり、自分ごと化して業務に取り込むことができます。そういった状態が組織として健全ではないかと感じ、輪番制を取り入れました。 さらに、マネージャーやトップの業務も1つのロールであると考えています。 優秀なエンジニアが エニグモ で長く活躍する際に、マネージャーとしてパフォーマンスが高かった人でも、自身がチャレンジしたいことに応じて自発的に スペシャ リスト（技術者）に戻るというキャリアがあっても良いと考えています。 マネージャーになること＝唯一のキャリアステップアップにしたくない と思っています。 マネージャーはあくまで組織の中でマネー ジャーロ ールを担っている人という形で定義することで、上下という立ち位置にせず、ある時はマネージャーをやっていたが、ある時は スペシャ リストである。らせん階段を登っていくようなキャリアの選択があっても面白いのではないか、それで組織全体にプラスになることもあり、キャリアアップの多様化にも繋がると考えます。 色々な観点でエンジニアが主体的に自らの組織や専門性を成長させていける体制になることを目指したいと考えたのが背景です。 Committee体制の実行に向けて 大谷： 続いて、木村さんと山本さんにお聞きしたいのですが、部長やCTOを置かないフラットな組織運営であるCommittee体制について、初めて方針を聞いた時にどう感じましたか？ 木村： 私も、エンジニア組織全体について「自分的にはこうした方がいい」みたいなところは考えていて、実際に話し始めていたタイミングでした。 フラットな組織体制については、他社でトップにCTOがいる場合でも、CTOを補佐するメンバーがたくさんいるCTO室を設置するような会社もたくさんあります。そういったトップを補佐する仕組みが必要であるというのは理解していました。そういったところから安藤さんから提案についても「いいな」と思いました。輪番制についても、Headになることへの 心理的 ハードルが下がりますし、自分に就任を打診された際もポジティブに受け止めることができました。 山本： 自分も今回の話がある前から、組織的にもう少しやった方が良い部分があるなと感じていました。他社の体制や取り組みを調べてみて、 エニグモ にはどんなやり方が最適なのかを考えていたので、Committee体制についても前向きにとらえました。 ただ、初めは部長やCTOという分かりやすいトップがいないことについては少し不安もありました。 でも実際にCommitteeが発足したおかげで、組織作りについてEM同士で定期的かつ積極的に会話する場ができたことで、今まで以上に組織がクイックに良い方向に向かい始めたことをすぐに実感できました。 Committee体制の詳細について 大谷： 木村さんが初代Headに決まってから、さらに具体的なCommittee運営に向けた体制づくりに着手されましたが、最終的な実施体制について概略を教えていただけますか。 木村： 繰り返しになりますが、新体制はCTO、VPoEという役職を置かず、複数名のEMがCommitteeという合議体を形成して、意思決定のトップ機関となっています。トップは輪番制となります。優先順位が高い組織課題は分科会を配下に設置して議論・決定のスピードを上げていきます。 Committeeが発足してまず行ったことは、トップが単独で担っていたロール・タスクを分解・抽象化していって組織に落とし仕込み、Committeeメンバーの誰が担当するかを決めていきました。 その際に現在足りない役割や、新たに採用すべきポジションなども同時に整理しました。 山本： エンジニア組織のトップがやるべき仕事は非常に多岐に渡ります。 トップの役割は、チームのマネジメント（ピープル〜プロジェクトマネジメント）や技術的意思決定、採用・評価に止まらず、システム監査、インシデント指揮、予算・経費管理といった様々な役割があります。技術職から見ると少し敬遠したくなる"雑務”と感じる業務もトップに集まりがちになるので、そういう業務も含めて、誰が担当するか？今後どのように管理・意思決定するのか？をCommitteeメンバー内で前向きに議論しながら決めることができました。 ビジネスサイドとの連携について 大谷： エンジニアとビジネスサイドが密に連携して業務を推進する当社においては、今回の体制変更はビジネスサイドの特にマネジメント陣にしっかりと理解してもらう必要がありますよね。どのような形でインプットを行ったか教えてください。 木村： はい。今回の組織体制はエンジニアだけでなく、ビジネスサイドにもリンクすることがとても重要だと考えました。経営陣からも、せっかくなのでオフィスから離れた場所で1日ワークショップ形式で時間を取って共有とディスカッションをしようよ、と提案いただいたのはありがたかったです。 安藤： エニグモ はエンジニアとビジネス側、企画メンバーが一緒になってプロダクト、サービスを創り上げていくことを大切にしている風土です。 今回はエンジニア組織のターニングポイントとなったので、ビジネス側の部長や、エンジニアと密に仕事をしているメンバーとは事前にキックオフをし、よく理解してもらい、もし疑問があれば解消しておく必要があると考えました。 やはり、エンジニアとビジネスサイドのメンバーが境界なく同じような価値観で同じような背景を理解した上で、協力・連携して仕事をすることはすごく大切なことです。 木村: 今回のキックオフを通して、エンジニア組織の話にとどまらず、開発側とビジネス側のさらなる連携強化についての議論にも発展し、例えば、全社横断的な重要プロジェクトの推進方針（カンパニーベットの概念）についても自然と議論が湧き起こったりして、非常に有意義な日になりました。 キックオフ終了後、そのビルの屋上でみんなでBBQをやったのもいい思い出です（笑） 今回の記事では新体制（Committee体制）の移行についてお話ししました。後半は新たな開発体制についてお話しします。後半もお楽しみに！