システムリプレイスを乗り越える！成功体験に導く3つの心構え

こんにちは。エンジニアの竹田です。
BUYMAの検索システムやMLOps基盤の開発・運用を担当しております。
こちらはEnigmo Advent Calendar 2024の18日目の記事です 🎄

はじめに

2024年もいよいよ年の瀬ですね！寒さが増すこの季節、みなさまいかがお過ごしでしょうか？

早速ですが本記事の主題のシステムリプレイスについてです。
ここ言うシステムリプレイスとは、老朽化したシステムの刷新、管理目的での移設など、既存システムがあり、それを何かしらの方法で置き換えることを指しています。
例えば、古くなったオンプレミス環境をクラウドに移行したり、データベースをより新しいものに入れ替えるといった作業も含まれます。

サーバサイドから下位のレイヤを担当している方々は、システムリプレイスを行う機会が割と多いのではないでしょうか。
実際に自分もエニグモに入社してからもそうですが、それ以前からも新規システムを構築するよりはシステムリプレイスを行うことが多いと感じています。

• 今までの実績
  • 各種検索システムのリプレイス
  • MLOpsシステムのkubeflow pipelines→vertex ai pipelinesへのリプレイス
  • アカウント検知システムのリプレイス

どんなシステムでも老朽化が進むため、定期的なリプレイスが必要です。
気が付くとサポート期限間近であったりということは少なくないのではないでしょうか。
ただ、新しいもの作りという訳ではないので、なかなかモチベーションを上げ辛い作業ではないかなと思います。

また、旧システムとインプットやアウトプットは変えない、というのが命題となるので、結果比較に時間を要したりとナーバスになる作業も多いです。

そんな中でも、モチベーションを高く保つために自分が意識していることを紹介したいと思います。

システムリプレイスのモチベーションを高めるために

改善のチャンスと捉える：システムの価値を高める！

何か付加価値を提供できないかを考えます。
システムコストや学習コストの兼ね合いもありますが、思い切って足回りやミドルウェアの置き換えなど検討しても良いと思います。

• コスト削減
  • 新たなマネージドサービスの利用
  • 多めに見積もって構築されていたリソースの削ぎ落とし
• システム強化
  • 少し気になっていたコードの修正
  • 構成周りの定義での一工夫
• マイクロサービス化
  • 機能の一部を切り出して影響を局所化
• 監視強化
  • 迅速な障害対応、柔軟な運用

学びのチャンスと捉える：自身のスキル底上げ！

少なくとも現状を一切変更しないリプレイスはあまり存在しないと思います。
例えば、旧システムのデータベースを調査中に、想定外のデータ構造や運用上の工夫を発見することもあります。それが新システム設計のヒントになることもしばしばです。
そう考えると、以下の点で新しく学びを得られる機会があります。

• 各種ライブラリのバージョン最新化
  • 動作差異の確認、理解
• あまり深く知らない言語の理解
  • どの言語でも固有の特徴がある
• 旧システムの構成や思想の理解
  • wiki等が残っていれば確認、当時の思想が全く分からないこともある...
  • とにかく旧システムを把握しないことには作業を進めづらい

アウトプットのチャンスと捉える：学びを共有して価値を広げる！

どういった方法でシステムを刷新したか、その意図など、技術ブログなどで外部発信する機会を得られます。
技術ブログの他にも、社内勉強会やカンファレンスでのLT（ライトニングトーク）なども該当するかと思います。
自分もこの点はあまり実践できていないので、自戒の意味も込めて記載しています。

• 自身の技術棚卸し
  • こういった機会を作ることで、振り返りの機会を設ける
• 外部向け文章作成の機会
• 企業ブランディングへの貢献

より気持ちを高めるために

関わったことのなかった方と関わりを持てる可能性がある

過去担当していた方と関わりを持ち、人間関係を広げる機会になる可能性があります。
怯むことなく関わりを持てるようにしましょう。

今どきな言い方をしてみる

slack等でやりとりする際、リプレイスではなく モダナイズ という言葉を使ってみたりしています。
ただし、クラウドの新機能を利用したり、インフラやアプリの構成を大幅に見直すような場合でないと名前負けした感じになるので注意が必要です。

最後に

以上のようなことを意識して取り組んでいるため、比較的楽しくシステムリプレイスを行っていると思っています。
システム規模が大きくなればなるほどリプレイスは大変になるので、立ち止まって特定の機能を切り出せないかを考えたりするのも良いと思います。

みなさんもシステムリプレイスを楽しむ方法を見つけて、エンジニアとしての成長を一緒に楽しんでいきましょう！

明日の記事の担当は同グループの中村さんです。お楽しみに！！

---

株式会社エニグモ すべての求人一覧

hrmos.co

PHPerがRubyistになろうとしてつまづいたところ③SQL

こんにちは！WEBアプリケーションエンジニアの小松です！

この記事は[Enigmo Advent Calendar 2024]の17日目の記事です。  

Railsの場合: 自動的に日付オブジェクトとして認識

RailsはActiveRecordのORMを利用する場合だけでなく、rawクエリを用いた場合でもdate型はRubyのDateオブジェクトに変換されます。そのため、日付フォーマットの変換を簡単に記述できます。

サンプルコード（Rails）

テーブル定義

# migration
create_table :events do |t|
  t.date :event_date
  t.timestamps
end

rawクエリの利用

result = ActiveRecord::Base.connection.execute("SELECT event_date FROM events LIMIT 1")
raw_date = result.first["event_date"] # => #<Date: 2023-12-13>

puts raw_date.strftime('%Y%m%d') # => "20231213"

ポイント

• event_dateはRubyのDateオブジェクトとして取得される。
• .strftimeメソッドを直接利用してフォーマットを変更可能。

---

Laravelの場合: 明示的な型変換が必要

Laravelでrawクエリを使用した場合、デフォルトではdate型は文字列として取得されます。そのため、フォーマットを変更する際は、明示的にCarbonオブジェクトなどに変換する必要があります。

サンプルコード（Laravel）

テーブル定義

// migration
Schema::create('events', function (Blueprint $table) {
    $table->date('event_date');
    $table->timestamps();
});

rawクエリの利用

use Illuminate\Support\Facades\DB;
use Carbon\Carbon;

$result = DB::select("SELECT event_date FROM events LIMIT 1");
$rawDate = $result[0]->event_date; // => "2023-12-13" (文字列)

$carbonDate = Carbon::parse($rawDate);
echo $carbonDate->format('Ymd'); // => "20231213"

ポイント

• event_dateは文字列として取得される。
• PHPのCarbonライブラリを利用して明示的に日付オブジェクトに変換する必要がある。

---

RailsとLaravelの比較表

特徴	Rails	Laravel
rawクエリでのdate型の扱い	自動的にDateオブジェクトとして認識される	文字列として取得される
日付フォーマットの変更	.strftime('%Y%m%d')が直接利用可能	Carbon::parse($date)->format('Ymd')が必要
追加の変換処理の必要性	不要	必要
デフォルトの開発者体験	日付操作が非常に簡潔で直感的	明示的な型変換が必要で、柔軟性が高い
適用範囲	ActiveRecordでもrawクエリでも同じ	Eloquentとrawクエリで挙動が異なる

---

開発者の観点からの結論

Railsのメリット

• 開発効率が高い: 日付型は自動的にDateオブジェクトとして認識され、変換処理を意識する必要がありません。
• 統一性がある: ActiveRecordでもrawクエリでも同じように扱えます。
• 時間をかけてハマる前に、まず .to_sqlでクエリを確認 する習慣をつけると、デバッグがスムーズになります！

Laravelのメリット

• 柔軟性が高い: Carbonを使えば、細かい日付操作やタイムゾーン操作が可能です。
• 設計の自由度: 明示的な変換により、モデルやユースケースに応じた日付処理を柔軟に適用できます。

Railsは「標準的な処理が簡潔」、Laravelは「柔軟性を重視」といったフレームワークの哲学の違いが、日付型の扱い方にも表れています。どちらを選ぶかはプロジェクトの要件やチームの好みに依存しますが、簡潔さを求める場合はRailsが有利です。

PHPerがRubyistになろうとしてつまづいたところ②コンソール

こんにちは！WEBアプリケーションエンジニアの小松です！

この記事は[Enigmo Advent Calendar 2024]の16日目の記事です。  

コンソールを使ったデバッグは開発において非常に重要です。フレームワークや言語ごとに特性が異なるため、それぞれの仕組みに慣れる必要があります。以下にPHPやRailsを例に、デバッグ手法や注意点を詳しく解説します。

---

1. PHPのデバッグ方法

PHPにはRuby on Railsのような標準的なコンソール機能（例：rails console）が存在しません。そのため、デバッグの際には以下の手法を使うことが一般的です。

• var_dump()の利用
  PHPでは主にvar_dump()が使われます。これはCLIからの実行でもWEBブラウザ経由のアクセスでも有効です。
  例:

  $data = ['name' => 'John', 'age' => 30];
  var_dump($data);
  

• CLIでのPHPスクリプト実行
  テストスクリプトを作成してCLIから直接実行する方法もあります。これにより、サーバーを介さずにデバッグが可能です。

---

2. Railsのコンソール機能

Railsには標準でrails consoleが用意されており、デバッグやテストに非常に便利です。ただし、注意すべき点もいくつかあります。

• 関数のテストが容易
  Railsのコンソールでは、関数やクラスを直接呼び出してテストできます。
  例:

  def greet(name)
    "Hello, #{name}!"
  end
  
  puts greet("Alice") #=> Hello, Alice!
  

• デバッグにおける注意点
  Railsコンソールでのデバッグにはpを使用しますが、PHPのvar_dump()と異なるため、切り替えを忘れることがあります。
  例:

  data = { name: "John", age: 30 }
  p data #=> {:name=>"John", :age=>30}
  

• コード変更時の再起動
  コードを変更した場合、Railsコンソールに入り直す必要があります。これを忘れると、古いコードのままデバッグを続けることになり、時間を無駄にする原因になります。

---

3. RSpecでのデバッグ

RSpecのデバッグでもコンソールと似ています。以下に注意点と手法を挙げます。

• pを利用したデバッグ
  RSpecでは、ログを確認するよりもpを使う方が効率的な場合があります。しかし、つい忘れてしまうことも多いです。
  例:

  it "tests addition" do
    result = 2 + 2
    p result #=> 4
    expect(result).to eq(4)
  end
  

• コード変更時の挙動
  RSpecコードそのものを変更する場合、通常は何もせずにテストを実行できます。しかし、テスト対象のロジックを変更した場合、特定の環境では注意が必要です。

• コード変更と反映
  テスト用のコード変更は即時反映されますが、今の開発環境では実際のアプリケーションコードを変更した場合はDockerコンテナを再起動する必要がある場合があります。この手順を忘れると、古いコードでデバッグを進めてしまう可能性があります。

  手順:

  1. コードを変更する。
  2. 以下のコマンドでコンテナを再起動する。

---

結論

PHPやRails、RSpec環境それぞれに特有のデバッグ手法と注意点があります。特にRailsやDocker環境ではコード変更時の再起動を忘れがちになります。また、各環境でのデバッグ手法に慣れることで、無駄な時間を減らし、生産性を向上させることができます。

PHPerがRubyistになろうとしてつまづいたところ①シンボル？

こんにちは！WEBアプリケーションエンジニアの小松です！

この記事は[Enigmo Advent Calendar 2024]の15日目の記事です。  

PHPの場合

model['full_name']

こういう変数の持ち方を連想配列と呼んでいただけなので、シンボルキーという言葉と発想がなかったです。

呼び出し方でも

model['full_name'], model[:full_name], model.full_name

などがあり、

<%= debug model %> やログでオブジェクト全体の値が取れてもキーの持ち方が違って取得するのに時間がかかることがありました。

なので、呼び方の具体例や呼び出し方を記載しました。

model['full_name'] のような形式は、文字列キーを持つハッシュから値を取得する方法です。このような形式でのアクセスは、Rubyの基本的なハッシュオブジェクトの操作です。

呼び方の具体例

文字列キーを使ったハッシュアクセス

Rubyでは、ハッシュのキーとして文字列（String）を使う場合に、この形式でアクセスします。

model = { 'full_name' => 'AIR JORDAN 13(エアジョーダン13)' }
puts model['full_name']  # => "AIR JORDAN 13(エアジョーダン13)"

文字列キーアクセスを使う場面

JSONパーサーからのデータ: JSONをRubyでパースした場合、デフォルトではハッシュのキーが文字列になります。

シンボルキーを使ったハッシュアクセス

Rubyでは、ハッシュのキーとしてシンボル（Symbol）を使うことも一般的です。この場合は、:full_name のようにしてアクセスします。

model = { full_name: 'AIR JORDAN 13(エアジョーダン13)' }
puts model[:full_name]  # => "AIR JORDAN 13(エアジョーダン13)"

オブジェクト形式（OpenStruct）のアクセス

OpenStruct を使うと、ドット演算子（.）でプロパティにアクセスできます。

require 'ostruct'
model = OpenStruct.new(full_name: 'AIR JORDAN 13(エアジョーダン13)')
puts model.full_name  # => "AIR JORDAN 13(エアジョーダン13)"

確認方法

model.class を実行することで、オブジェクトがハッシュなのか、OpenStruct なのか、あるいは別の型なのかを確認できます。その型に応じたアクセス方法を選びましょう。

クラス内のインスタンス変数の確認方法

インスタンス変数の取得方法も初めは時間がかかりました。

docs.ruby-lang.org

p obj.instance_variable_get(:@foo) 

このように取得するみたいです。

シンボルはRubyのみ存在?

Python、PHP、C、Go、JAVAなどには存在せず、Javascriptには存在するけど、挙動が少し違うようです。

qiita.com

慣れればメリットもあるとの事ですが、他の言語にない概念なので、Ruby使い始めは正直紛らわしかったです。

表計算ツールでのサーバ管理台帳を卒業してDCIMツールのNetBoxに移行のことはじめ

こんにちは、インフラグループの片桐です。

この記事はEnigmo Advent Calendar 2024の 14 日目の記事として、サーバ機器管理台帳を表計算ツールから OSSの「NetBox」に移行した取り組みについて紹介します。

はじめに

サーバ機器やネットワーク機器、各機器に付随するIPアドレスの情報など、サーバ機器や関連情報をまとめる為に「機器管理台帳」は欠かせないものになっています。その中で、機器管理台帳はExcelやGoogle スプレッドシート等の表計算ツールで管理されているケースもよく見られます。

表計算ツールを台帳として機器管理している場合、台帳の規模が拡大するにつれて、管理すべき各種情報が複数のシートやファイルに分散しがちです。これにより管理コストが増大し、整合性の維持も難しくなります。こうした状況に心当たりのある方も多いのではないでしょうか。

弊部署も同様に、表計算ツールを用いた煩雑な機器管理に悩まされていました。そこで、データセンターのインフラ管理（DCIM)とIPアドレス管理(IPAM)を兼ねるツールであるNetBoxを導入し、機器情報管理の一元化・整合性維持を試みました。本記事では、機器管理台帳の表計算ツール管理からNetBox移行について、取り組み内容、移行に際する知見等を紹介します。

 用語の整理

DCIM

DCIM(Data Center Infrastructure Management)は、データセンターに関連するサーバ機器やネットワーク機器、ラック、配電や配線、設備など、さまざまなリソースを管理・可視化するためのツールや手法のことです。DCIMおよびDCIMツールを導入することで、ハードウェア配置や容量、ネットワーク接続状況などを一元管理することが可能となります。

IPAM

IPAM(IP Address Management)は、ネットワーク内で使用されるIPアドレスを一元的に管理し、その割り当てや利用状況、変更履歴などを可視化・追跡するためのツールや手法のことです。IPAM及びIPAMツールを導入することで、利用可能なアドレス空間のシステム的な管理と、管理に伴ったIP重複割り当ての予防等が可能となります。

NetBox

NetBoxは、DCIMとIPAMの機能を併せ持つOSSです。サーバ機器やラック構成、IPアドレス、ケーブル接続など、データセンターまわりの情報を一元的に、かつわかりやすく管理することに特化しています。 WebインターフェースやREST APIを通して各機器やネットワーク関連のデータを登録・編集・参照できるため、機器情報の管理をするだけでなく、管理の簡略化・自動化も可能です。 お試しで触りたい方向けの公式デモ版サイトも公開されています。 github.com

移行の背景と課題

これまで、弊部署の機器管理台帳には複数ファイル/複数シートを跨ぐGoogle スプレッドシートを使用しており、以下をはじめとする各種情報を管理していました。

• ハードウェア関連：機材情報、シリアル番号、ラック配置、納品日/保守期限、各機材のLAN接続状況
• ホスト関連：ホスト名、各NICごとのIPアドレス割り当て状況
• etc...

台帳上の各機器について、あるシートではホスト名とIPアドレスの紐づけ、あるシートではホスト名とラック上の設置位置の紐づけ...等、1箇所のデータを更新した際に関連するデータを複数シート上で合わせて更新する運用でした。

一方、この管理方式には以下の様な課題もあります。

• 台帳更新の煩雑さ:
  • 1つの機器について複数ファイル/複数シートを跨いで情報が登録されている場合。
  • シート上のある箇所を変更した際、別シートや別セルの依存箇所も特定して修正する必要がある。
  • 依存箇所を漏れなく特定できる運用フローや仕組み構築が必要になる。
• 整合性管理の困難さ:
  • 台帳更新の煩雑さ にも関連。
  • 依存箇所の修正漏れが起きやすい状況下にて、依存データ間で整合性の取れていないデータが発生した場合に事実確認の手間が発生する。
• 外部連携の困難さ:
  • 機器管理台帳に限らず、表計算ツールで作成された各種データファイルが完全なCSV形式で構築されていない場合。
  • 台帳上に存在する情報を読み込んでプログラマブルに利用したい場合や、外部のシステムにデータを取り込む際、各環境が扱える状態に一度変換する手間がある。

これらの課題に対してNetBoxを導入し、対応を試みました。

NetBoxのデプロイ

NetBoxのデプロイ先として、社内向けツール用に構築しているEKS(Amazon Elastic Kubernetes Service)クラスタ上に構築しました。

インストールには、Netbox CommunityのGitHub上で公開されているHelmチャート(netbox-chart)を使用しました。

github.com

helmを利用する場合は利用ガイドを読みながら、ご自分の環境に合わせてvalues.yamlの各値を変更してセットアップする流れとなります。 特に管理者ユーザ周りの設定値はログイン時に使用するため、ご利用の環境に合わせて事前設定することをおすすめします。

NetBoxへのデータ登録

NetBoxに登録できる項目について

データの登録を始める前に、既存の機器管理台帳では何の情報を管理しているのか、NetBoxには何の情報を登録できるのかを一通り把握しておくことを推奨します。

ドキュメントをご参照いただくと分かる通り、NetBoxに登録できる項目は多岐にわたり、かつきめ細かい情報を登録であるため、最初から全ての情報を入れ込むことが難しい場合も想定されます。 (以下NetBox ドキュメントの models 配下の大項目、並びに大項目配下の詳細情報を各機器/各グループ毎に入力可能となっています。)

github.com

もしスモールスタートで「データセンタ内の機器情報、ラックへの機器マウント情報、各機器へのLAN配線、VMホストとゲストVMの紐づけ、各NICへのIPアドレスアサイン」程度で運用を開始したい場合は、以下図のmodel項目を参考に入力していくことで簡素版な環境を構築可能です。

データの登録

NetBoxの導入を検討した当初はスプレッドシート上に散在していた情報を1件ずつ確認しながら手動で登録することも考えていましたが、登録すべき情報を整理していく中で、数百台以上の機器やIPアドレス、接続情報等をすべて手動で移行するのはあまりにも現実的ではない事に気付きました。

一方、NetBoxには機器追加/変更/削除等のデータ操作を楽にする為の仕組みが複数整備されており、一括でのデータ操作が可能となっています。

• CSV/YAML形式での一括インポート:
  • NetBoxのWEBインターフェースの機能として、CSV/YAML形式でのデータの一括インポートに対応しています。
  • 登録するデータを各形式に整形して事前に整備出来ている場合、各model毎のWEB UI上から楽にデータをインポート可能です。
  • 1行目に各modelに対応するヘッダを、2行目以降に登録するデータを入力する形で定義します。

CSV形式インポートの入力例

• REST APIでのデータ操作:
  • NetBoxに実装されているREST APIを活用することで、各種データ操作をプログラマブルに行う事も可能です。
  • CSVでのインポートはデータの登録のみ可能ですが、APIを利用することでCRUD各処理を複雑な条件式を絡めて実行することも可能となります。
  • Netbox API Document

上記2種類の一括操作方法を実施して、既存の機器管理台帳上のデータを移行していきました。

スプレッドシートから移行する際の知見

移行前の情報を整理した上で、完全に正規化されたCSVを作成するべき

移行前のスプレッドシートには現状との乖離として、例えば以下の様な不整合が発生していました。

• 新しいホストに付け替えたIPアドレスが古い機器に付随されたままになっている。
• ホスト名を変更したが、旧ホスト名のまま台帳に登録されている。

不整合を一つ一つ修正するのは非常に手間の掛かる作業となる上、独自管理の形式から完全な状態のCSV形式に落とし込むことは、手間と時間の掛かる作業となります。

一方、NetBoxには強力なCSVインポート機能が備わっているため、一度完全な状態のCSVを作成してしまえば、NetBoxの運用は直ぐにでも開始可能です。 私は不整合の解消作業は実施したものの、完全な状態のCSVを作成する前に移行を始めてしまった為、変更が必要な所はREST APIを使用して適宜修正する形での対応となりました。

再度移行作業を実施する機会のある際には、完全に正規化されたCSVを作成してから実施すべきと実感しました。

NetBoxに登録する情報の精査と入力先カラムの確認

前述の完全に正規化されたCSVを作成した後は、CSV上のカラムをNetBox上のどのモデルに入れるかを予め検討しておくべきでした。 ラックの情報は dcim > racksに、機器のモデル名やシリアルは dcim > devicesに、IPはipam > ip-addressesに登録出来る、あるいはこの項目について入力できそうな項目が存在しない、等を先行して把握しておくべきでした。

例えば、NetBoxには機器の納品日や保守期限といった項目を入力出来る箇所が標準項目としては存在しません。 そのため、機器情報の自由記述欄となる Comment カラムに入力するか、カスタムフィールドを追加することで、標準機能外の情報管理もNetBox上で可能になります。

一括登録を実施する前に、整理されたCSVの項目とNetBoxの入力項目を比較して、このデータは何処に入るのか？を明確にしておくとスムーズなデータの投入が可能でした。

カスタムフィールドで機材納品日の入力欄を追加する例

NetBox導入によって感じたメリット

情報の一元管理と可視化:

NetBox移行後はIPアドレス、機器モデル、シリアルナンバー、物理配置、接続関係など、あらゆる情報をNetBoxで一元的な管理が可能となりました。 スプレッドシートを利用していた頃は、ある箇所を修正した際依存する情報の修正を、複数シート/複数ファイルに跨って手動で行う必要がありました。 NetBox移行後には依存情報の修正も行われるため、整合性保持にも寄与します。

エクスポート/インポートの柔軟性:

前述の通り、NetBoxにデータを登録する際はCSV/YAML形式でのインポートが可能です。 また、NetBoxに登録されている情報は、CSV/YAML形式でのエクスポートも可能であるため、将来的に別の管理基盤へ移行する際にもデータ移行が容易になることが見込まれます。

拡張性と自動化:

NetBoxにはREST APIや各種WebHookが実装されています。APIによる台帳上のデータの一括操作が可能になった他、WebHookによって台帳に新規機材が追加された際にSlackなどチャットツールに通知する等の対応が可能となりました。別途仕組み作りを実施することで柔軟な対応が可能となるため、今後の拡張性として期待が高まりました。

サーバラックの情報可視化例。ラックの色のついている部分には登録した機器が紐づいている

まとめ

スプレッドシートからNetBoxへと台帳管理を移行した結果、情報一元化や更新作業の効率化が期待できる基盤が整いました。初期構築やデータ整備に手間はかかりましたが、その分、長期的な整合性維持と運用自動化の可能性が大きく広がりました。

一方、現時点では、NetBoxの基本的な機能を用いて、ハードウェアとIPアドレス、簡易な接続情報を一元管理する段階にとどまっています。今後は運用を通じてAPIやWebHookの活用やNetBoxのプラグイン導入など、さらなる効率化と可視化を進めていきたいと考えています。

明日の記事の担当はWEBアプリケーションエンジニアの小松さんです。お楽しみに。

---

株式会社エニグモ すべての求人一覧

hrmos.co

GoogleスプレッドシートとZapierを用いた勉強会チームのリマインド自動化(Zapier編)

こんにちは！インフラエンジニアの森田です！

この記事はEnigmo Advent Calendar 2024の12日目の記事です。
また、11日目のGoogleスプレッドシート編の続きであるため未読であればそちらからご一読いただければと思います。

前回の記事ではZapierで扱うデータのインプットとなるスプレッドシートの解説を行いましたので、今回は処理とアウトプットを行うZapの解説を行います。

現在以下のZapが稼働していますが、

• 毎月22日に翌月の発表者へまとめてリマインド
• 毎週月曜日に発表者へリマインドし、発表予定がなければ募集する
• 発表があれば開始のアナウンスをし、発表予定がなければスキップのアナウンスをする

今回は翌月の発表者へまとめてリマインドするZapの解説を行いたいと思います。

毎月22日に翌月の発表者へまとめてリマインド

1.毎月22日にトリガー

まず、翌月頭の発表者の準備期間が取れるように毎月22日にトリガーするようにしています。
キャプチャと同じように設定すれば毎月のトリガーとなります。

2.翌月が何月か計算

次の工程で使用するために翌月が何月なのかを取得しています。
具体的には1のトリガーが次に動く日付(翌月の22日)から正規表現で何月かを抽出しています。

import re
print(input_data['next'])
result = re.findall(r'-\d{2}-', input_data['next'])
return {'result' : result[0].replace('-', '')}

3.翌月の行を取得

翌月発表の行をまとめて取得してきています。
具体的には「リマインド管理シート」に開催月という列があったと思いますが、開催月が2で取得したものと同値かつ開催フラグがTRUEの行を取得しています。
注意が必要なのがEventの設定で、「Lookup Spreadsheet Rows」と「Lookup Spreadsheet Rows (Advanced)」という似たイベントが存在しますが、「Lookup Spreadsheet Rows」では取得できる行が1行のため、翌月の発表全てというような複数行取得したい場合は「Lookup Spreadsheet Rows (Advanced)」を選択する必要があります。

4.Slack送信メッセージ作成

3で取得した要素をSlackのメッセージへ整形するためpythonで実装しています。

date_list=input_data['date'].split(',')
title_list=input_data['title'].split(',')
SlackID1_list=input_data['SlackID1'].split(',')

result = f'''
【{input_data['month']}月 Hacker’s Delightスケジュールのお知らせ】
{input_data['month']}月のスケジュールの予定はこちらです。発表者の方は準備をよろしくお願いします。
何かあれば @devrel へご連絡ください
'''

for i in range(len(date_list)):
    string = f"\n{date_list[i]}：{title_list[i]} <@{SlackID1_list[i]}>"
    result = result + string

print (result)

return {'result' : result}

それぞれの発表の部分はリストの要素分ループで回して戻り値へ加算(追記)していく形になっています。

5.Slackへ送信

4で整形したメッセージ(戻り値)をシンプルにSlackのチャンネルに送信しています。

実際に以下のようなメッセージが送信されます。 Zapの解説は以上になります。

おわりに

今回は1つのZapを用いて解説を行いましたが、11日目の記事で解説したインプットがあれば

• 毎週月曜日に発表者へリマインドし、発表予定がなければ募集する
• 発表があれば開始のアナウンスをし、発表予定がなければスキップのアナウンスをする

上記のようなリマインドも実装することができます。
また、今回エニグモで行っているアドベントカレンダーのリマインドも同じ要領で自動化しています。

スケジュールを把握して色々なメンバーにリマインドをするというのは思いの外意識を割かれてしまうため、
GoogleスプレッドシートとZapierが利用できる環境にあれば是非自動化にチャレンジしていただければと思います。

2記事に分かれて長かったですが、お読みいただきありがとうございました。
明日の担当はRDチームの廣島さんです。お楽しみに。

---

株式会社エニグモ すべての求人一覧

hrmos.co

GoogleスプレッドシートとZapierを用いた勉強会チームのリマインド自動化(Googleスプレッドシート編)

こんにちは！インフラエンジニアの森田です！

この記事はEnigmo Advent Calendar 2024の11日目の記事です。

私は社内の勉強会チーム(DeveloperRelationsチーム)としても活動しており、 人力で行なっていたリマインドをZapierで自動化したのでそのご紹介をしたいと思います。

今回は毎週金曜日に実施している軽い勉強会(Hacker'sDelight)のリマインドの自動化を例に記載します。

元々は以下のようなスケジュール管理シートがあり、こちらを人の目で見て翌月の発表者やその週の発表者にSlackでリマインドを送るという運用をしていました。

ただずっと人力でリマインドを送るというのはツラいため、社内で自動化ツールのZapierを契約しているため折角なら自動化してしまおうということで自動化に着手しました。
調べながらZapを作成する中で意外にZapierの日本語のドキュメントが少なかったため、この記事が備忘録かつ同じような自動化をやりたい方の参考になればと思います。

今回の自動化を構成しているのは大きく分けて以下の3要素になります。

• スケジュール管理シート(パブリック)
• リマインド管理シート(クローズド)
• Zap

全ての要素の解説を１記事で行うと長くなってしまうため今回は「スケジュール管理シート」と「リマインド管理シート」の解説を行います。 Zapの解説は12日目の記事で解説したいと思います。

スケジュール管理シート(パブリック)

以下が「スケジュール管理シート」です。 基本的に上で貼ったスケジュール管理シートと同様ですが、「リマインド管理シート」でSlackIDをメールアドレスから自動検索するために列が追加されています。 こちらのシートは基本的にパブリックになっており、一般メンバーもHacker'sDelightのカレンダーとして見ることができます。 全て手動で管理しているので特に言及するところはありませんが、この後の解説で関連してくる列は以下となります。

• 内容
• 発表者1,2（敬称略）
• 発表者1,2メアド
• 日程

リマインド管理シート(クローズド)

「リマインド管理シート」は「Zapier通知用」と「Slackメンション用IDリスト」の2つのシートからなります。

Zapier通知用

このシートは「スケジュール管理シート」から参照した値から計算して自動的に埋められるため、手動での管理は不要になっています。 それぞれの列の解説をします。

• 日程
• 発表内容
• 発表者1,2
• 発表者1,2メアド

これらの列は全て「スケジュール管理シート」からそのまま参照しています。 別のスプレッドシートから値を参照してくるにはIMPORTRANGE関数を使用します。

例)
=IMPORTRANGE("https://docs.google.com/spreadsheets/d/xxxx","2025!G4")

また、発表者の部分は敬称をスプレッドシート側で入れておきたいのでカスタム数値形式で「@さん」と入れることで自動で敬称を付与するようになっています。

• 開催月

MONTH関数を用いて何月に開催されるのかを抽出しています。 これは翌月の発表をまとめてリマインドするのに使用します。

例)
=MONTH(A2)

• 当日までの日数

日程のセルからTODAY関数で今日の日付をマイナスすることで発表当日まで何日なのかを算出することができます。

例)
=A2-TODAY()

• メンション用ID

VLOOKUP関数で「Slackメンション用IDリスト」から発表者メアドに対応した IDを取得してきています。 元々人力でメンション用IDを探してコピペしていましたが辛すぎるうえミスが分かりずらいため、IDは自動で取得されるようにした方が良いと思います。

例)
=VLOOKUP(F2,'Slackメンション用IDリスト'!$A$3:$B$1435,2,FALSE)

• 開催フラグ

発表があるのかないのかを判別するためにISBLANK関数で発表内容のセルを空白判定しています。 また、そのままだと発表がある(セルが埋まっている)とFALSEと判定され違和感があるため、NOT関数で逆の論理値が返されるようにしています。

例)
=NOT(ISBLANK(D2))

Slackメンション用IDリスト

以下のドキュメントを参考にメンバーリストを取得すると、ユーザーのメールアドレスとUserIDが記載されたcsvファイルが取得できます。
ワークスペースのメンバーリストをダウンロードする

こちらのシートはcsvの内容をそのままコピペしたものです。 Zapierを使ってユーザーにメンションをする際にはこのUserIDが必要になります。
注意が必要なのはこのメンバーリストがSlackのオーナーまたは管理者権限を持っていないと取得できない点です。
不特定多数が見られる場所に書かれるのは好ましくないため、「リマインド管理シート」の参照権限はクローズドで必要のあるメンバーのみが見られるようにするべきです。

Zapierでリマインドを行うためのインプットとなるスプレッドシートの解説は以上となります。
明日の記事では実際にリマインドを行う部分であるZapの解説を行います。

---

株式会社エニグモ すべての求人一覧

hrmos.co