はじめに こんにちは。ニフティ株式会社入会システムチームの高畑です。 最近マスタデータ管理のために、Adminer Editorというアプリケーションを試してみましたので紹介します。 背景 システム設定やマスタデータをDB上のテーブルで管理している際に、操作ミスによっては影響が大きいためSQLを直接操作したくありません。そのため、社内運用ツールを作成することもありますが、シンプルなデータであれば汎用的なツールで十分な場合もあると思います。 汎用的なツールとしてAdminer Editorというアプリケーションを検証しました。本記事では実際に使う上で必要な機能として以下を挙げてカスタマイズ例と動作確認をしています。 データ操作以外のテーブル作成、変更操作をしたくない 不要なテーブルは見えないようにしたい 不要な列は見えないようにしたい 誰がデータを操作したか記録を残したい アクセス制限をしたい Adminer Editorとは Adminer Editor とはPHP製のDBデータ編集ツールです。SQLを操作せずに画面上の操作だけでテーブル上のデータ修正ができます。類似のツールにAdminerがありますが、Adminerと比較するとテーブル作成や削除といったDDLが制限されているためDB管理者というよりはDB利用者のためのツールになります。 また、MySQL、PostgreSQL、OracleDB、Microsoft SQL Server等さまざまなRDBMSに対応しています。 ツール本体は単一のPHPファイルとなっており導入しやすく、クラスを継承してインスタンスメソッドをオーバーライドすることでPHP触ることができれば簡単にカスタマイズできます。 今回は、導入の手軽さと利用できるRDBMSの豊富さから検証してみました。 デモ ソースコードと実行環境はDockerを用意しています。MySQLが提供している world database というサンプルデータをMySQLにインポートして操作していますので、実際に触ってみたいという方はREADMEを参考に構築してみてください。 https://github.com/octop162/adminer-editor-customized Adminer Editorの設定とカスタマイズ方法 導入に必要なのはAdminer Editor本体と設定ファイルの2つだけです。設定ファイルにはDBのホスト名、ユーザー名、パスワード等の基本設定の他、データ挿入、変更、削除等の操作をした際に呼ばれるメソッドのオーバーライドをします。 ここでは設定ファイルをworld.php、本体をeditor.phpとしています。world.phpにアクセスするとAdminer Editorが利用できます。さらにadminer.cssを設置することでCSSを読み込み反映してくれます。 設定方法は以下ページを参考にしています。 https://www.adminer.org/en/extension/ . ├── adminer.css ├── editor.php └── world.php それぞれの機能実現方法 前述したカスタム方法により機能追加しています。 不要なテーブルを非表示にしたい tableNameをオーバーライドすることでどのテーブルを表示させるか制御できます。非表示にしたいテーブル名なら空文字を返します。 ここではテーブル名が country   を非表示にしています。 function tableName($tableStatus) { // countryテーブルを非表示 $ignored_list = ['country']; if (in_array($tableStatus["Name"], $ignored_list, true)) { return ''; } return parent::tableName($tableStatus); } 不要なテーブルの列を非表示にしたい 同様に非表示にしたい列名は空文字を返すと非表示にできます。ここでは、 ID 列を非表示にしています。 function fieldName($field, $order = 0) { // ID列を非表示 $ignored_list = ['ID']; if (in_array($field["field"], $ignored_list, true)) { return ''; } return parent::fieldName($field, $order = 0); } 操作記録を残す 必要なファイルが増えてしまいますが、利便性を考えてPHPのログライブラリであるMonologを導入します。追加情報としてIPアドレス、X-Forwarded-For、ログインユーザーを出力することで誰が操作したかわかるようにしています。 class AdminerSoftware extends Adminer { private $logger; function __construct() { $this->logger = $this->getLogger('php://stdout', Level::Debug); } function getLogger($filename, $level = Level::Debug) { $logger = new Logger('adminer'); $handler = new StreamHandler($filename, $level); $handler->setFormatter(new JsonFormatter()); $logger->pushHandler($handler); $logger->pushProcessor(function ($record) { $record['extra']['remote_user'] = $_SERVER['REMOTE_USER']; $record['extra']['remote_ip'] = $_SERVER['REMOTE_ADDR']; $record['extra']['xff'] = $_SERVER['X-Forwarded-For']; return $record; }); return $logger; } ... SELECT、INSERT、 UPDATE、DELETEはそれぞれ selectQuery 、 messageQuery メソッドがAdminer Editor本体から呼ばれるため、用意したロガーオブジェクトでログ出力します。 function selectQuery($query, $time, $failed = false) { $output_query = str_replace("\\n", " ", $query); $this->logger->debug($output_query); } function messageQuery($query, $time, $failed = false) { $output_query = str_replace("\\n", " ", $query); $this->logger->info($output_query); } Monolog導入後は以下のようなファイル構成になりました。 . |-- composer.json |-- composer.lock |-- public | |-- adminer.css | |-- editor.php | `-- world.php `-- vendor |-- autoload.php |-- composer |-- monolog `-- psr アカウント認証する ログイン認証は login メソッドが担当しています。ユーザ名、パスワードを入力すると引数として渡されますので、簡易的に認証したいのであれば、それらを比較するだけで認証できます。 実際にはIPアドレス制限やリバースプロキシ導入する、パスワードをハッシュ化しておく等対策が必要に思います。 以下はIPアドレスをもとにしてアクセス制限をかける例と、簡易的な認証の例です。 <?php $permit_ip = ["x.x.x.x", "y.y.y.y"]; if (!in_array($_SERVER['REMOTE_ADDR'], $permit_ip, true)) { } ... class AdminerSoftware extends Adminer { ... function login($login, $password) { return $login === 'xxxx' && $password === 'yyyy'; } 実際に触ってみる 上記の設定後、ローカル環境で動作確認を実施します。 ①ログイン画面   ②テーブル一覧（countryが非表示になっています）。 ③データ一覧で神奈川県で検索してみます（ID列が非表示になっています）。   ④神奈川県に人口2000人の町TestCityを追加してみます。追加時もID列は表示されていません。 ⑤無事TestCityが追加されました。 ⑥編集リンクを押すと修正、削除ができます。 ⑦ログからそれぞれの操作を確認できました。 adminer-editor-customized-adminer-1 | {"message":"INSERT INTO `city` (`Name`, `CountryCode`, `District`, `Population`) VALUES ('TestCity', 'JPN', 'Kanagawa', '2000');","context":{},"level":200,"level_name":"INFO","channel":"adminer","datetime":"2023-06-16T01:46:58.380121+00:00","extra":{"remote_user":null,"remote_ip":"xxxx","xff":null}} adminer-editor-customized-adminer-1 | {"message":"UPDATE `city` SET `Name` = 'TestCity', `CountryCode` = 'JPN', `District` = 'Kanagawa', `Population` = '3000' WHERE `ID` = '4081';","context":{},"level":200,"level_name":"INFO","channel":"adminer","datetime":"2023-06-16T01:48:36.217265+00:00","extra":{"remote_user":null,"remote_ip":"xxxx","xff":null}} adminer-editor-customized-adminer-1 | {"message":"DELETE FROM `city` WHERE `ID` = '4081';","context":{},"level":200,"level_name":"INFO","channel":"adminer","datetime":"2023-06-16T01:50:09.335932+00:00","extra":{"remote_user":null,"remote_ip":"xxxx","xff":null}} おわりに 本記事では、Adminer Editorをカスタマイズすることで運用上必要な機能を追加できることを検証しました。参考になれば幸いです。 We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering

イベント概要 NIFTY Tech Talkは、ニフティ株式会社の社員が主催するトークイベントです。 本イベントでは、ニフティグループの社員が業務を通じて学んだことを発信しています！ 第12回目のテーマは「スクラム開発の真髄を探る！認定スクラムマスター研修参加者が語る成功のカギ」です。 研修から試験、そしてその先へ。 研修や試験、資格取得後どうだったか、第一歩を踏み出す方へニフティの認定スクラムマスターが語る回となります。 概要 日程：6月27日（火）12:00〜12:45 配信方法：YouTube Live 視聴環境：インターネット接続が可能なPC/スマートフォン 参加方法 connpass にて登録をお願いいたします。 ※YouTube Liveにて配信いたします。 ※YouTube LiveのURLは決定後、参加者への情報欄に記載いたします。 こんな方におすすめ 認定スクラムマスターに興味ある方 認定スクラムマスター研修を受けてみようか考えている方 タイムテーブル 時間 コンテンツ 12:00 – 12:05 オープニング 12:05 – 12:10 認定スクラムマスターってなんですか？ 12:10 – 12:20 LT1: 認定スクラムマスター研修と認定試験について 12:20 – 12:30 LT2: スクラムに向かない情シスチームのスクラムマスターがCSMを取得して2年の間に思ったこと 12:30 – 12:40 LT3: 認定スクラムマスターになった後　A-CSMって取るべき？ 12:40 – 12:45 クロージング テーマ スクラム開発の真髄を探る！認定スクラムマスター研修参加者が語る成功のカギ 登壇者プロフィール 青木 大海（登壇者） ニフティ株式会社 会員システムグループ 第2開発チーム 新卒入社7年目で、ニフティポイントクラブの開発・運用を担当しています。 2023年3月に認定スクラムマスターを取得しました。 小浦 由佳（登壇者） ニフティの情シス担当者です。 主にプラットフォーム、アプリケーションの社内システムを見ているチームのスクラムマスターで、2021年に認定スクラムマスターを取得しました。 NIFTY Tech Talk、NIFTY Tech Dayを始め、社内外のイベントを企画したりもしているニフティのにぎやかしです。 西野 香織（登壇者） ニフティ株式会社 会員システムグループ 第2開発チーム ニフティのスペシャリストを任命するN1!制度にて、スクラムエヴァンジェリストを担当しています。 2019年?スクラムマスターとして、ニフティへのスクラム導入を開始。 8チーム、エンジニア約30名以上に対しスクラム導入を支援しています。 アドバンスド認定スクラムマスター（A-CSM）資格所持。 ニフティグループでは一緒に働く仲間を募集中です 新卒採用、キャリア採用を実施しています。ぜひ リクルートサイト をご覧ください。 ニフティエンジニアが業務で学んだことやイベント情報を エンジニアブログ にて発信しています！ ニフティエンジニアのTwitterアカウントを作りました NIFTY Tech Talkのことや、ニフティのエンジニアの活動を発信していきます。 Tweets by NIFTYDevelopers 「NIFTY Tech Day 2022」を開催しました 技術イベント「NIFTY Tech Day 2022」のアーカイブはこちら  NIFTY Tech Day 2022 アンチハラスメントポリシー 私たちは下記のような事柄に関わらずすべての参加者にとって安全で歓迎されるような場を作ることに努めます。 社会的あるいは法的な性、性自認、性表現（外見の性）、性指向 年齢、障がい、容姿、体格 人種、民族、宗教（無宗教を含む） 技術の選択 そして下記のようなハラスメント行為をいかなる形であっても決して許容しません。 不適切な画像、動画、録音の再生（性的な画像など） 発表や他のイベントに対する妨害行為 これらに限らない性的嫌がらせ 登壇者、主催スタッフもこのポリシーの対象となります。 ハラスメント行為をやめるように指示された場合、直ちに従うことが求められます。ルールを守らない参加者は、主催者の判断により、退場処分や今後のイベントに聴講者、登壇者、スタッフとして関わることを禁止します。 もしハラスメントを受けていると感じたり、他の誰かがハラスメントされていることに気がついた場合、または他に何かお困りのことがあれば、すぐにご連絡ください。 ※本文章はKotlinFest Code of Conductとして公開された文章( https://github.com/KotlinFest/KotlinFest2018/blob/master/CODE-OF-CONDUCT.md )を元に派生しています。 ※本文章はCreative Commons Zero ライセンス( https://creativecommons.org/publicdomain/zero/1.0/ ) で公開されています。スクラム開発の真髄を探る！認定スクラムマスター研修参加者が語る成功のカギ第12回目のテーマは「スクラム開発の真髄を探る！認定スクラムマスター研修参加者が語る成功のカギ」です。

はじめまして。SREチームの島です。 今年の3月にニフティに入社した駆け出しSREです。 前職では10年ほどアプリ開発に携わっており、この度SREデビューしました。 そんな私がニフティに入って最初に行った「Four Keysの設定」について、試行錯誤した経験を交えながら綴りたいと思います。 この記事の内容 触れること Four Keysの概念 実体験に基づいたFour Keysの設定例 触れないこと Four Keysの詳細な説明 GitHubやCI／CDに関する用語の説明 前提のおはなし ※Four Keysを理解している方は読み飛ばしてOKです Four Keysとは ズバリFour Keysとは DevOps Research and Assessment（DORA）チームが実施した 6 年間の研究から、ソフトウェア開発チームのパフォーマンスを示す 4 つの指標が確立されました。 https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance DORAチームとは企業のDevOpsの導入状況やパフォーマンスを調査しているGoogle社内の組織のようです。 つまり要約すると Google社内の組織が決めた「開発チームのパフォーマンス」を測る4つの指標 のことです。 以下がその指標となります。 指標名 定義 デプロイの頻度 組織による正常な本番環境へのリリースの頻度 変更のリードタイム commit から本番環境稼働までの所要時間 変更障害率 デプロイが原因で本番環境で障害が発生する割合（%） サービス復元時間 組織が本番環境での障害から回復するのにかかる時間 チームのパフォーマンスとは？ では、「開発チームのパフォーマンス」とは具体的に何なのでしょうか？ Four Keysの世界では「ソフトウェアデリバリーのパフォーマンス」のことを指します。 分かりやすく言うと、 「開発したソフトウェアをいかに速く、安定して顧客に提供できるか」 です。 それを計測し、評価することがFour Keysの目的となります。 Four Keysのメリット／デメリット メリット チームのパフォーマンスを可視化できる 部外者からもパフォーマンスを評価しやすい チームメンバー自身もパフォーマンスを把握しやすい CI／CDの改善が反映される指標である CI／CDをより良くしようという働きかけになる デメリット（注意点） Four Keysが高い＝パフォーマンスが高い ではない あくまで指標の1つ 例えば意味のないデプロイを繰り返せばFour Keysは高まるが、本来そうすべきではない。数値に捉われすぎないこと 自動化することが前提 Four Keysを計測するために労力を割くのは本末転倒 つまり、 チームのパフォーマンスが視覚的に分かるようになり、改善意識の向上、パフォーマンス改善につながる ということがメリットとして挙げられます。 実際に設計してみる ここからは実際にFour Keysを設計するために行なったことを述べていきます。 今回は@niftyトップページ開発チームのFour Keysを設計しました。 １．開発フローを知る まずは現状どのようにCI／CDが行われているのか、現状のフローを知る必要があります。 開発チームのメンバーにヒアリングを行い、情報収集をしました。 要点はこちらになります。 ソース管理はGitHubで行なっている 障害管理はGitHub上では行なっていない リリースが原因で障害が発生した場合は必ず切り戻しを行なっている 以上のことから、今回はGitHubから必要な情報を取得してFour Keysを作成しようと思います。 イメージはこんな感じです。 Four Keysに必要なデータ取得の流れ ※ Googleスプレッドシート icon by Icons8 まずは試作ということでスプレッドシートを使ってデータの集計、グラフ化をすることにしました。 ２．定義を決める Four Keysの定義はGoogleで提唱されていますが、それを組織の定義に落とし込みます。 定義のポイントとしては 何を計測・改善したいか を意識することです。 例えばFour Keysの1つである「変更のリードタイム」について、以下の2通りの定義で指標の意味合いが変わります。 ＜変更のリードタイムの定義例＞ 定義 計測できるもの 開発に着手してからリリースされるまで 実装や単体テストを含めた 開発速度 PRを作成してからリリースされるまで 単体開発以降の リリース準備の速度 チームにとって最適な定義を決めましょう！ @niftyトップページ開発チームでは以下のように定義しました。 ＜Four Keysの定義＞ 指標 @niftyトップページ開発チームでの定義 デプロイの頻度 1日あたりの平均デプロイ回数（切り戻しを除く） 変更のリードタイム ① 変更をメインブランチにマージしてから、本番環境へのデプロイが完了するまでの所要時間 ② 変更のPRを作成してから、本番環境へのデプロイが完了するまでの所要時間 変更障害率 デプロイ回数に対する、切り戻しによるデプロイの割合 サービス復元時間 障害発生源の変更が本番環境へデプロイされてから、その切り戻しがデプロイ完了するまでの所要時間 「変更のリードタイム」、「サービス復元時間」を開発フローに乗せて説明すると、下記のようなイメージです。 変更のリードタイムのイメージ サービス復元時間のイメージ 今回は開発速度ではなくリリースまでの所要時間を計測するため、PR以降の時間を計測することにしました。 変更のリードタイムは、試作として2パターン計測し、どちらを採用するか決める方針としました。 ３．ロジックを決める 上記で決めた定義から、具体的に使うデータ、計算式を決めます。 今回は下記のように決めました。 ＜Four Keysの算出ロジック＞ 指標 ロジック デプロイの頻度 デプロイ回数(切り戻しを除く)／日数 変更のリードタイム ①(デプロイ完了日時 – メインブランチへのマージ完了日時)の合計／デプロイ回数 ②(デプロイ完了日時 – PR作成日時)の合計／デプロイ回数 変更障害率 (切り戻しのデプロイ回数／切り戻しを除くデプロイ回数) * 100 サービス復元時間 (切り戻しのデプロイ完了日時 – 障害発生源のデプロイ完了日時)の合計／切り戻しのデプロイ回数 ４．データを取得する ロジックまで決まったら、いよいよ実際にデータを取得します。 今回はGitHub REST APIを使ってコミット履歴、PR履歴、デプロイ履歴を取得し、集計しました。 最終的にこのような集計結果となりました。（実際の計測値とは変えています） GitHubデータの集計結果 ５．グラフ化する 上記の集計結果をスプレッドシートのグラフ機能を使ってグラフ化しました。 Four Keysをグラフ化した結果 上記の結果から 変更障害率は低く安定しており、サービス復元時間も短いため、 障害発生時の切り戻しを安定して素早く行えている デプロイの頻度も安定している。（障害の発生した月は増加傾向にある） 変更のリードタイムの マージ以降の所要時間は短く安定しているが、PR作成以降の所要時間は増加傾向 にある。つまりPR作成〜マージ間のタスクを改善できると良い といった分析ができます。 実際、このチームではマージ以降の処理（デプロイ）は自動化されているため、マージ以降の所要時間が短いという結果は実態と合っていると言えます。 また変更のリードタイムは マージ以降の所要時間（青色の線） を採用することにしました。 理由としては下記の2点となります。 PR作成後に企画担当とリリース日の調整を行うので、 PR作成以降の所要時間（赤色の線）は開発以外の要因に左右されやすい 。 そのためこちらは不採用 マージ以降の所要時間は今は安定しているが、 今後何かの要因で所要時間が増えた際に検知、分析できると良い。 そのためこちらを採用し、定期的に計測する。 以上でFour Keysの作成ができました。 まとめ 苦労したこと 定義、ロジックを決める作業が一番苦労しました。 定義は明確に決まっているわけではなく、チームにとって最適な定義を決める必要があります。 上では省略していますが、定義を決めるフェーズでは 何度もチームメンバーとレビューや議論を重ねて 定義を決定しました。 明確な正解がない中で、最適解を求める作業は大変でしたが、 納得できる定義が決まった時はとても達成感がありました。 今後の展望 データ収集、集計の自動化 継続的にFour Keysを計測するために、自動化できるところは自動化していく予定です。 また、今はスプレッドシートで集計からグラフ化まで行なっていますが、自動化するにあたって最適なツール選定なども行う予定です。 他チームへ展開するために、全社共通定義の 決定 今回は@niftyトップページ開発チーム独自の定義を決めましたが、ニフティ社内での共通定義を決めていく予定です。 共通定義が決まればニフティとしての指標が明確になり、チームごとの比較もできるようになるので、Four Keysをより有効活用できます。 最後に 今回はFour Keysを作成し、@niftyトップページ開発チームのパフォーマンスを計測しました。 パフォーマンスが可視化されたことで開発フローを見直すきっかけになれば幸いです。 まだまだ試作段階ですが、今後さらに便利なものにして有効活用していきたいと思います。 最後まで読んでいただき、ありがとうございました！ 参考記事 エリート DevOps チームであることを Four Keys プロジェクトで確認する We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering

こんにちは、最近はスプレッドシートの値をgetValuesした時の型が自由すぎることが悩みの宮本です。便利といえば便利なんですが、自由奔放すぎてTypeScriptだとちょっと手を焼いています。 はじめに みなさん clasp はご存知でしょうか？claspは、Google Apps Script（以下GAS）のプロジェクトをコマンドラインでデプロイできるようにできるツールです。GASをローカルで開発し、コード自体もgit管理したりと、これ一つでGASの使い勝手が一気に上がることでしょう。 さて、このclaspを使うとローカルからのデプロイの他に、デフォルトでもTypeScriptに対応しているという便利機能がついてきます。型がないと生きていけなくなってしまった私としては飛び上がって喜びたいのですが、残念なことに 対応しているバージョンが3.8.2 と若干古いです。他にもexport/importが素直に使えなかったりと、やや痒いところに手が届きません。どちらかというと、こっちの方が辛い……。 そこで私は gas-webpack-plugin を使ってローカル内でwebpackを使いコードをビルドし、ビルドしたコードをclaspでデプロイという方法を使ってます。さらにclaspで管理するプロジェクト設定の入っている .clasp.json を環境ごとに用意すれば、GASでも本番・開発環境を分けてデプロイすることができてしまいます。これで完璧。 と、言いたいところですが、これにもちょっと不便なところがあります。ちょっと多いんですよね……実行しないといけないコマンドが。 古いビルド済みファイルが残っていると嫌なので削除 webpackでビルド デプロイしたい環境に合わせて .clasp.json を切り替え claspでデプロイ いや、改めて見るとそんなに多くない気もしてきました。でも、これをちょっと変更して動作確認して……となってくると毎回打つのが結構面倒です。特にスプレッドシートと連携したGASだと、ちょっとした動作確認でもローカルだと難しくデプロイしないと正常に動くかわかりません。 ということで、環境を分けて一発でデプロイできるようにコマンドを整えましたというご紹介です。本題に入るまでが長かった。 一発で環境を分けてGASをデプロイできるようにする さて、ごちゃごちゃしたコマンドをまとめるとなると、シェルスクリプトでも用意する必要がありそうですが、ちょっと面倒です。ということで、今回はpackage.jsonのscriptsのpre/post scriptsを使って一発でデプロイできるようにしてみます。 pre/post scripts よくpackage.jsonのscriptsフィールドに "build": "next build" のようなものは登録すると思います。pre/post scriptは、たとえばscriptsフィールドにpreで始まるコマンド登録されていたらpreに続くコマンドの実行前に、postで始まるコマンドが登録されていたらpostに続くコマンドの実行後に自動で実行されるスクリプトです。 buildを当てはめるとこうなります。 prebuild: buildコマンドの前に自動で実行 postbuild: buildコマンドの後に自動で実行 実はいままで使ったことがなかったのですが、今回はこれで良さそうです。 デプロイコマンド では、コマンドで環境を分けつつ一発でclaspをデプロイするpackage.jsonのscriptsとdevDependenciesの抜粋です。 前提 環境ごとの .clasp.jsonは用意済み 開発環境: .clasp.json.dev 本番環境: .clasp.json.prod webpackのビルド設定は完了済み ビルドすると ./dist ディレクトリにビルド済みファイルが入る "scripts": { "prebuild": "rimraf ./dist", "build": "webpack", "predeploy": "yarn build", "deploy": "clasp push", "postdeploy": "rimraf .clasp.json", "predeploy:dev": "node -e \"require('fs').copyFileSync('./.clasp.json.dev', './.clasp.json')\"", "predeploy:prod": "node -e \"require('fs').copyFileSync('./.clasp.json.prod', './.clasp.json')\"", "deploy:dev": "yarn deploy", "deploy:prod": "yarn deploy" }, "devDependencies": { ... "rimraf": "^4.4.1", ... }, // 利用ライブラリの追加 yarn add -D rimraf // 開発環境へのデプロイ yarn deploy:dev // 本番環境へのデプロイ yarn deploy:prod やっていることの説明 まず、buildコマンドでwebpackを呼び出し、ビルドするようになっています。そしてprebuildとして、 rimraf ライブラリを使い以前のビルド済みファイルを削除しています。これで、buildコマンド実行時に以前のファイルを確実に削除してファイルをビルドすることができるようになっています。 そして、deployコマンドではpredeployとして、buildコマンドを実行するようにしています。これで、デプロイ時に事前にファイルを自動でビルドすることができます。ビルド後にclasp pushでGASのプロジェクトにデプロイします。その後、postdeployで.clasp.jsonを削除しています。 そして環境ごとの出力先変更ですが、それぞれdeploy:devとdeploy:prodの2種類のコマンドを用意しています。どちらもyarn deployを呼び出していますが、事前のpreコマンドで対応する.clasp.json.{dev|prod}をnodeのコマンドライン実行で.clasp.jsonにコピーしています。ここだけnodeのコマンドライン実行をしている理由としては、ファイルを別名コピーする丁度良いライブラリが見当たらなかったためです。 おわりに claspでコマンドラインからデプロイできるようになったけど、コマンド4つも打つの面倒くさい！という低レベルな悩みから、コマンド一つで環境を分けてGASのプロジェクトをデプロイできるようにしてみました。実際にやってみると、そこまで手間はかからない割にストレスフリーになって結構気に入っています。ただ、scripts内で別名で同じコマンドを呼び出していたり、もう少し綺麗にできないかなとも思ったり……。とはいえ現状はこれで十分かなと感じているので、ほどほどに妥協も入ってます。 claspというよりはpackage.jsonのscriptsでできること意外とある！！という感じの記事になっていますが、お役に立てれば幸いです。 参考 google/clasp: Command Line Apps Script Projects fossamagna/gas-webpack-plugin: Webpack plugin for Google Apps Script scripts | npm Docs rimraf – npm We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering

はじめに ニフティ株式会社 会員システムグループの深田です。 ニフティではブカツ制度という社内交流の活動支援制度があり、最近会社でも健康志向が高まってきているので、筋トレ部なるものを発足しようかと考えています。 早速ですが、みなさんは Python でマルチスレッド（以下、並行処理）を実装されていますか？ Python で並行処理を実装する方法はいくつか挙げられますが、ここでは concurrent.futures モジュールの ThreadPoolExecutor について紹介していきたいと思います。 ThreadPoolExecutorとは ThreadPoolExecutor は Python の concurrent.futures モジュールに含まれるスレッドプールを実装するクラスであり、並行処理を効率化するために使用されます。スレッドプールは、複数のスレッドを作成し、再利用することで、タスクの実行を効率化することができます。 ProcessPoolExecutorとの違い concurrent.futures モジュールには Executor のサブクラスとして ThreadPoolExecutor の他に、もう一つ ProcessPoolExecutor というクラスが存在ます。 ProcessPoolExecutor はプロセスを利用して並列処理（マルチプロセス）を行うため、複数のプロセスを実行します。主にCPU負荷の高いタスクに適しています。 一方、ThreadPoolExecutor はスレッドを利用して並行処理（マルチスレッド）を行うため、同一のプロセス内で複数のスレッドを実行します。メモリ使用量も比較的少ないため、I/OバウンドのタスクやCPU負荷の低いタスクなど、主にI/O待ちの時間が長いタスクに適しています。 Pythonでの並列処理・並行処理 Pythonで並列処理や並行処理を実装したい場合、主に以下が挙げられます。 threadingモジュール multiprocessingモジュール concurrent.futuresモジュール asyncioモジュール サードパーティのライブラリ 今回は「3. concurrent.futuresモジュール」のクラスである ThreadPoolExecutor について解説しますが、特徴の1つとして「1. threadingモジュール」をベースにしているという点にあります。concurrent.futures モジュールは threading モジュールを抽象化して提供し、スレッドやプロセスの選択を自動的に行っています。 したがって、concurrent.futures モジュールを使用することで、パフォーマンスやリソース利用の効率化を図った並列処理・並行処理を実現することができます。 しかし、場合によっては直接 threading モジュールを使用することもあるので、どちらを選ぶかは具体的な要件次第になります。 ThreadPoolExecutorの基本的な使い方 ThreadPoolExecutor を使用するには、まず concurrent.futures モジュールをインポートします。次に、ThreadPoolExecutor クラスのインスタンスを作成し、引数にスレッド数を指定します。スレッド数は、同時に実行されるスレッドの最大数を表します。 from concurrent.futures import ThreadPoolExecutor # スレッド数を指定してThreadPoolExecutorのインスタンスを作成 with ThreadPoolExecutor(max_workers=5) as executor: # タスクを実行する関数をsubmitメソッドでスレッドプールに登録 future = executor.submit(my_function, arg1, arg2, ...) submit   メソッドには、実行したいタスクを関数として渡し、必要に応じて引数を指定することができます。 submit   メソッドが実行されると、 my_function   メソッド内の実行を待たずに次の行に進み、非同期に処理が進行します。 コールバック関数を使用した結果の取得 submit   メソッドは、concurrent.futures.Future オブジェクトを返します。このオブジェクトを使用して、タスクの実行結果を取得したり、タスクの完了を待ったりすることができます。 from concurrent.futures import ThreadPoolExecutor # スレッド数を指定してThreadPoolExecutorのインスタンスを作成 with ThreadPoolExecutor(max_workers=5) as executor: # タスクを実行する関数をsubmitメソッドでスレッドプールに登録 future = executor.submit(my_function, arg1, arg2, ...) # コールバック関数を使用して結果を取得 future.add_done_callback(my_callback_function) def my_callback_function(future): result = future.result() # タスクの実行結果を取得 add_done_callback   メソッドを使用して、コールバック関数を登録することができます。コールバック関数は、タスクの実行が完了した際に自動的に呼び出され、タスクの結果を受け取ることができます。 例外のハンドリング ThreadPoolExecutor を使用して並行処理を行う際には、例外のハンドリングに注意が必要です。タスクの実行中に例外が発生した場合には、その例外を処理する必要があります。ThreadPoolExecutor では、各タスクの実行結果を保持する Future オブジェクトに例外が発生した場合には、その例外を含んだ状態で完了します。これを受け取るためには、 add_done_callback   メソッドで登録したコールバック関数の中で、Future オブジェクトの result   メソッドを呼び出すことで、例外を取得することができます。 from concurrent.futures import ThreadPoolExecutor # スレッド数を指定してThreadPoolExecutorのインスタンスを作成 with ThreadPoolExecutor(max_workers=5) as executor: # タスクを実行する関数をsubmitメソッドでスレッドプールに登録 future = executor.submit(my_function, arg1, arg2, ...) # コールバック関数を使用して結果を取得 future.add_done_callback(my_callback_function) # コールバック関数の中で例外をハンドリング def my_callback_function(future): try: result = future.result() # タスクの実行結果を取得 # タスクの結果を処理 except Exception as e: # 例外をハンドリング print(f"例外が発生しました: {e}") 実践的な使い方 先ほど紹介した add_done_callback   メソッドで完了した並行タスクを検知することができますが、 as_completed   メソッドでも並行タスクの完了を検知することができます。 as_completed   は、複数のタスクが同時に実行されている場合に、完了したタスクのイテレータを返します。つまり、各タスクが完了したときに取得できるため、コールバック関数を設定する必要がありません。 以下はHTTPリクエストを伴う大量の短時間タスクのバッチ処理を想定したサンプルコードです。 import urllib.request from concurrent.futures import ThreadPoolExecutor, as_completed # タスクを実行する関数（例として、指定したミリ秒数応答が返ってこないHTTPリクエスト） def long_task(milli_second: int) -> tuple[str, int]: with urllib.request.urlopen(f"https://httpstat.us/200?sleep={milli_second}") as response: body = response.read().decode() return body, milli_second # ThreadPoolExecutorを作成 executor = ThreadPoolExecutor() # タスクをリストに格納 tasks = [6000, 2000, 7000, 13000] # タスクを並行して実行 futures = [] for task in tasks: future = executor.submit(long_task, milli_second=task) futures.append(future) # 結果をas_completedメソッドで反復処理 for future in as_completed(futures): # タスクの完了を検出したら結果を取得 result = future.result() print(f"Task completed: {result}") # 出力例: # Task completed: ('200 OK', 2000) # Task completed: ('200 OK', 6000) # Task completed: ('200 OK', 7000) # Task completed: ('200 OK', 13000) add_done_callback   は、個々のタスクごとに結果を処理するために使用され、 as_completed   は、複数のタスクを並行で実行し、それぞれのタスクが完了したときに結果を取得するために使用されます。 要件によって使い分けましょう。 スレッドプールの最適なスレッド数の設定 ThreadPoolExecutor の引数である max_workers   には、スレッドプール内のスレッド数を指定します。この値の設定には注意が必要であり、適切な値を選ぶことが性能の向上に繋がります。スレッド数を多くしすぎると、スレッドの切り替えや同期によるオーバーヘッドが増え、逆にパフォーマンスが低下する可能性があります。一方、スレッド数を少なくしすぎると、スレッドプールが効果的に利用されず、処理能力が十分に引き出されない可能性があります。 最適なスレッド数は、実行するタスクの性質や環境によって異なります。I/Oバウンドなタスクの場合には、より多くのスレッド数を許容することができます。ただし、前述したようにスレッド数を無制限に増やすと、オーバーヘッドが発生する場合があります。リソースの制約やタスクの性質に応じて、適切なスレッド数を見極める必要があります。実際のシナリオでのベンチマークなどを通じて最適なスレッド数を見つけることが重要です。 まとめ ThreadPoolExecutor は、Python の concurrent.futures モジュールを使用して、スレッドプールを作成するための便利なクラスです。スレッドプールを使用することで、複数のタスクを並行して実行し、処理を効率化することができます。 ニフティではメールアカウントの作成をはじめとした、メールに関わる多種多様な設定変更をこの技術を用いて日々大量に処理しています。 ぜひ、必要な場面で活用していきましょう！ 参考記事 https://docs.python.org/ja/3/library/concurrent.futures.html#module-concurrent.futures We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering

はじめに 基幹システムグループの大里です。 新年度になってもう2か月になりました。新年度になってから部署替えやチーム編成の変更も生じるかと思います。 私の所属するチームは去年の6月に他のサービスを担当していた2人とチームが合併して3人チームになりました。このチーム編成の変更の際にまず立ち向かわないとならない問題として、自分が担当しているシステムを他のメンバーに理解してもらわなければならない問題が生じました。その際にシステムのコードを理解してもらう方法としてモブプロを選び実施しましたが、その時に工夫したことや所感などを記載します。 チームで実施したモブプロのルール モブプロの基本ルール チーム内でナビゲーターとドライバーで役割を分担する ナビゲーター：ドライバーに対しどのコードを見て、どのようなコードを入力するかを指示する ドライバー：ナビゲーターの指示を聞いてタイピングや画面切り替えを実施する それに加えてコーディング中に疑問があったら質問・回答を行う チームの独特なルール モブプロを実施する前に修正箇所の処理の流れをチーム全員で検討・共有する システムを理解している人は基本的にナビゲーターとして固定する 使用したツール Visual Studio Code チーム共有で使っているエディター Visual Studio Live Share リアルタイムで共同開発できるVisual Studio Codeの拡張機能、ドライバーの修正内容の共有に使用 Meet ビデオ会議ツール、音声を共有するためやVisual Studio Live Shareの画面共有に慣れるまでの画面共有に使用 draw.io 作図ツール、コード処理の共有や検討に使用 工夫したこと オンボーディング資料の準備 システムを理解してもらうためのモブプロの前にチームメンバーにはオンボーディング資料を読んでもらって、以下のような知識を共通認識として持ってもらうようにしました。 担当システムでどういうサービスを実現しているのか 担当システムにはどういったバッチやAPIがあるのか モブプロを始める前にコード内容は分からない状態であっても、担当システムの概要を理解してもらうようにしました。 設計書の記述もモブで実施する 設計書の記述もモブで実施することで、コードが分からない状態でも修正するコードのフローを議論できる状態にしました。修正するコードのフローを議論する際に、全体的なフローを設計書ベースで理解してもらえるように工夫しました。事前に設計を共有することによってコード記述をするモブプロをした時に、チームメンバーはコードの全体像を早く理解できるようにしました。 ナビゲーターはコードの記述するときの思考を言語化する ナビゲーターとしてコードを記述する際に考えることを一から言語化して伝えることで、実際に修正するコードだけではなくその周辺のコードや基本的な処理を漏れなく見せることを意識しました。チームの背景としてチームメンバーはシステムで使用しているフレームワークを触ったことがありませんでした。モブプロを通してチームメンバーが一人でコードを読めるようになるため、チームメンバーにとって初めて触れるフレームワークの処理の流れを説明する必要がありました。モブプロ中はコード修正をするときに最初に実施するであろう修正するコードを探すところから思考を言語化することに努めました。 良かったこと チーム全員で設計の検討ができた 設計書の記述からモブプロをすることによって、チーム全員で修正箇所のフローを検討できました。今回のチーム編成の変更では、幸運にも別のシステムの開発担当者と同じチームになりました。そのため、モブプロによって設計の議論を設計書ベースで考えることができるようになることで、コードを見たことがない開発者の知見を設計に生かすことができました。 副次的な効果として、設計に関してはチーム全員で責任が持てるようになったことが良かったです。このチーム編成の変更で担当システムの有識者が自分だけのような状態になり、自分の責任を重く感じてました。しかし、設計つまりコード修正の基本指針はチーム全員で合意が取れたことで、自分の気が軽くなりました。 実装力の強化 設計書さえあれば簡単な機能追加は各々1人で実装できるようになりました。これの要因の一つとして、モブプロ前にオンボーディング資料や設計書をチームメンバー全員が読み通すことで、モブプロ中は設計書をどのようにコードに落とし込むかの説明に集中できたためだと考えています。フレームワークの細かい仕様の理解ができていなくても設計書からコードへの落とし込み方を理解すれば、どのようにコードを記述すればよいかのヒントを各々で探すことが可能になりました。 反省点 疲労する これにつきます。 システムに慣れないドライバーの負担が大きい 今回のチームでは3人構成であったため、1人がナビゲーターとして固定されてしまい、他の2人がドライバーとなりました。さらに、ナビゲーターは見慣れたコードの修正を口頭で説明するだけで、ドライバーであるチームメンバーにとっては内部を見たことがないシステムの説明を聞きながら読み続けることになります。ナビゲーターとドライバーで負担が異なることになるため、意識して休憩を取らないと集中するのが難しいと分かりました。 モブプロの時間が長くなってしまう この工夫は設計のタイミングからモブプロを実施するため、時間が長くなってしまいます。上に述べたようにこの方法はシステムに慣れていないメンバーの負担が大きいことが分かったため、設計とコード修正で日を分けるなどの工夫が必要だと感じています。 終わりに システム理解を最優先の目的としてモブプロを実施したため、本来のモブプロの方法とは少し外れたルールで実施することになりました。次は開発速度を上げることやチームメンバーがコードに慣れるために、モブプロの本来の方法で実施できるように修正が必要だと考えています。 We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering

基幹システムグループ N1! オートメーションスペシャリストの南川です。 今回は、自動ワークフロー作成サービスである Zapier を使った Google フォーム (Google Forms) と Notion データベースの連携について紹介します。 こちらの記事は、 NIFTY Tech Talk #10「 Notion で仕事のスピードを加速するテクニックとは？」 にて発表した内容がベースとなっており、その時の スライド も公開しているので、興味のある方は確認してみてください！ 背景 Notion にはデータベースというアイテム（ページ）を管理する機能があり、その機能を使ってタスク管理をしているとします。データベースのプロパティにはタスクのタイトル、「Todo」「In progress」「Done」といったステータス、担当者、依頼者があります。 また、データベースには様々なビューがあり、ボードビューを使うと、タスクの進捗状況が分かりやすくなります。 そして、担当しているシステムに関する依頼は Google フォームで受け付けており、 Google フォームの申請内容をもとに手動で Notion のデータベースにアイテムを追加しています。しかし、手動でのデータベースへの追加は面倒だと思います。 「ならば、 Google フォームではなく、 Notion のデータベースに依頼者が直接追加すればいいのでは？」という話も出てくるかと思いますが、以下の理由から Google フォームを依頼の申請フォームとして使いたいです。 データベースのロック機能があるとはいえ、依頼者が誤ってアイテムを消してしまう可能性がある。 Google フォームだと、必ず記入してほしい必須項目の指定や、各項目の説明の記述などができて自由度が高い。 このような背景から、 Google フォームに送信された依頼の内容をもとに、 Notion のデータベースにアイテムを自動的に追加したい というわけです。ここで登場するのが Zapier というサービスです。 Zapier とは Zapier は複数のサービスやアプリを連携する自動ワークフローを、ノーコードで作れるサービスです。 対応しているサービス・アプリは5000個以上で、Gmail や Google スプレッドシート、 Google ドライブ、 Google フォームといった Google 製品はもちろんのこと、 Notion や Slack 、 GitHub などにも対応しています。対応サービスの一覧は https://zapier.com/apps から確認できます。 これらの対応しているアプリを互いに連携させ、以下のようなワークフローを作ることができます。 検索にマッチしたメールを受信したら、 Slack にメッセージを送信する。 Notion のデータベースに新しいアイテムが追加されたら、 Google スプレッドシートに行を追加する。 Zapier の用語 ここで Zapier に出てくる用語の一部を簡単に説明します。 今回紹介しない用語や詳しい説明については、以下のURLをご確認ください。 https://help.zapier.com/hc/en-us/articles/8496181725453 Zap Zap とは、アプリやサービスを連携させる自動化されたワークフローです。 Zap は Trigger と1つ以上の Action で構成されます。この Zap を On にすると、 Trigger のイベントが発生するたびに、 Action が実行されます。 Zap の例としては、先ほどの Zapier で作れるワークフローの例で挙げた「検索にマッチしたメールを受信したら、 Slack にメッセージを送信する。」や「 Notion のデータベースに新しいアイテムが追加されたら、 Google スプレッドシートに行を追加する。」が挙げられます。 Trigger Trigger とは、 Zap を開始するためのイベントです。 Trigger は、先ほどのワークフロー (Zap) の例における、「検索にマッチするメールを受信したら」や「 Notion の DB に新しいアイテムが追加されたら」に該当します。 Action Action とは、 Trigger が発動した後に Zap が実行するイベントです。 Action は、先ほどのワークフロー (Zap) の例における、「 Slack にメッセージを送信する」や「 Google スプレッドシートに新しい行を追加する」に該当します。 やりたいことを Zapier に落とし込む ここで、今回やりたいことについて振り返ってみます。今回は「 Google フォームに送信された依頼の内容をもとに、 Notion のデータベースにアイテムを自動的に追加する 」ということをやりたいです。これを Zapier に落とし込んでみると次のようになります。 以下の Zap を作成する。 Trigger : 「 Google フォームから回答が送信されたら」 Action : 「 Notion のデータベースにアイテムを追加する」 実際に作ってみる (1) 事前準備 Zap を作る前に、 Zap で連携する Google フォーム、 Notion のデータベースを作ります。 まず、「依頼デモ」という名前の Google フォームから送信された依頼を管理するための Notion のデータベースを作成します。このデータベースは、タイトル、ステータス、依頼者のプロパティを持っており、ステータスにはこの依頼の進捗状況として「Todo」「In progress」「Done」が値として入ります。先ほどのデータベースには担当者のプロパティを用意していましたが、今回は簡単にするためにプロパティをこの3つのみにします。 次に依頼を送信するための Google フォームを作成します。質問の内容は「依頼者の名前」「依頼の件名」「依頼の内容」となっています。 そして、 Zap を作るにあたり、 Google フォームで送信したダミーの回答が必要になってくるので、作成した Google フォームで以下のように適当な回答を記入して送信します。今回作る Zap では、左の Google フォームの回答を送信すると、右の Notion のデータベースのアイテムを自動作成することを目標とします。依頼者の名前がアイテムの依頼者プロパティ、依頼の件名がアイテムのタイトル、依頼の内容がアイテムの本文に対応しています。 (2) Zapier へのアクセス 事前準備が終わったので、本題の Zap 作成に移ります。 まず、 Zapier にログインし、左上の「Create Zap」ボタンを押します。この前に Zapier のアカウント作成などがあるかと思いますが、今回は省略します。 (3) Zap の名前を変更 「Create Zap」ボタンを押すと、 Zap の編集画面に遷移します。この画面の左上から、必要に応じてZapの名前を変更します。今回は「Google Form x Notion Demo」という名前にしました。 (4) Triggerの作成 次に、 Zap を開始するためのイベントである Trigger の作成をします。今回は「 Google フォームから回答が送信されたら」という Trigger を作成したいので、検索フィールドに「Google Forms」と入力し、「Google Forms」を選択します。 すると、 Event を選択するドロップダウンメニューが出てくるので、「New Form Response」を指定し、「Continue」ボタンを押します。 次に、 Google Forms account には、この Zap で Google フォームを操作するアカウントを指定します。今回は、黒塗りになっていますが私のアカウントを指定しています。 そして、 Form には、手順(1)で作成した Google フォームを指定し、「Continue」ボタンを押します。 あとは、作成した Trigger のテストをするため、「Test trigger」ボタンを押します。 すると、事前準備で回答した内容が表示されることが確認できるかと思います。確認できたら、「Continue」ボタンを押します。 (5) Action の作成 次に、 Trigger が発動した後に Zap が実行するイベントである Action の作成をします。今回は「Notion のデータベースにアイテムを追加する」という Action を作成したいので、検索フィールドに「Notion」と入力し、 Latest のほうの「Notion」を選択します。 すると、 Event を選択するドロップダウンメニューが出てくるので、「Create Database Item」を指定し、「Continue」ボタンを押します。 次に Notion を操作するアカウントの設定をします。 Notion account では、まず、「Connect a new account」ボタンを押します。 すると、 Notion へのアクセスをリクエストするウィンドウで出てくるので、「ページを選択する」ボタンを押します。 検索欄に手順(1)で作成したデータベース名を入力します。検索結果に候補として出てきたデータベースを選択し、「アクセスを許可する」ボタンを押します。 そして、作成したアカウントを選択し、「Continue」ボタンを押します。 次に、 Database には手順(1)で作成したデータベースを指定します。データベースを指定すると、そのデータベースの各プロパティの入力フィールドが出現します。 この入力フィールドには Trigger の情報（出力結果）を埋め込むことができます。タイトルでは、「Show all options」ボタンを押し、「1. 依頼の件名」を選択します。これにより、新しく追加するアイテムのタイトルは、先ほどの Google フォームの回答の依頼の件名の欄の値になります。 同じ要領で、依頼者のプロパティには「依頼者の名前」、 Content には「依頼の内容」を入力し、 Content Format には「Plain Text」を指定して、「Continue」ボタンを押します。 Content はデータベースのアイテムの本文で、以下の画像の赤枠の部分になります。 そして、作成した Action のテストをします。「Test action」ボタンを押すと、黒塗りが多いですが、 Action の実行結果が表示されます。 ここで、手順(1)で作成した Notion のデータベースを確認すると、先ほどの Google フォームの回答内容をもとに、アイテムが新しく作成されていることが確認できます。 (6) Zap の有効化・動作確認 Zap の編集画面に戻って、右上の「Publish」ボタンを押すと、 Zap が有効化され、トグルが On になります。 最後に Zap の動作確認をしてみます。 Zap を有効化した状態（トグルがOnになっている状態）で、 Google フォームから回答が送信されると、その内容をもとにして Notion のデータベースに新しくアイテムが作成されます。これで、 Google Form の回答内容を Notion DB に自動追加するワークフロー (Zap) の完成です。 まとめ 今回紹介したサービス Zapier を使うことで、 Notion や Google フォーム などの様々なサービスの連携をする自動ワークフローを、先ほどのデモのようにコードを一切書かずに作ることができます。 また、有料プランのみの話になりますが、 Zap は2つ以上の Action を持てるということで、 Action をさらに追加して、データベースにアイテムが追加されたことを Slack のチャンネルに通知することもできたりします。 他のサービスとの Notion の自動化の例については、公式サイトに色々載っているので興味のある方はご覧ください。 https://zapier.com/apps/notion/integrations We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering

はじめに こんにちは！NIFTY Tech Talk運営の碇川（いかりがわ）です！ 2023年4月19日（水）に開催した「落ちないシステムの作り方〜NIFTY Tech Talkとニフクラエンジニアミートアップのコラボレーション企画！〜」にて司会進行を務めさせていただきました。 今回のNIFTY Tech Talkは ニフクラエンジニアミートアップ とのコラボレーション企画で開催しました！ 業務で扱っているシステムが安定して稼働するための工夫やノウハウを、クラウドサービス「ニフクラ」の提供者である富士通クラウドテクノロジーズ株式会社（以下、FJCT）と、多彩なクラウドサービスを扱って、様々なWebサービスを開発しているニフティ株式会社が「落ちないシステムの作り方」について語っていただきました！ イベント概要 「NIFTY Tech Talk」は、ニフティ株式会社の社員が主催する、技術に関するトークイベントです。 このイベントでは、ニフティグループの社員が業務を通じて学んだ知見や経験をLT形式で発信しています。 今回のテーマは「落ちないシステムの作り方」として、業務で扱っているシステムが安定して稼働するための工夫やノウハウを、現場社員がLT形式で紹介していただきました！ 今回の登壇内容は以下のようになっています。 落ちないシステムって何？可用性の基本と仮想環境のでの可用性の高め方 「高可用性と高い信頼性を持つシステム」を実現するためにアプリケーションエンジニアができる事って何だろう？ 安定稼働するポータルサイトの作り方 月1億PVのニュースサイトを落とさない技術 また、今回のTech Talkのアーカイブ動画をYouTubeにアップロードしております。是非ご覧ください！ 内容レポート 各セッションの内容について、紹介していきます！ 落ちないシステムって何？可用性の基本と仮想環境のでの可用性の高め方 1つ目のLTは、FJCTの奥山さんです。 ハードウェア的な側面での落ちないシステムの基本的な考え方について語っていただきました。 まずは落ちないシステムを高可用性なシステムと定義し、高可用性なシステムを作るためにはどうしたら良いかわかりやすく説明していただきました。 また、仮想環境における可用性向上の具体的な手法として、VMwareHAについて紹介していただきました。 VMware HAは、仮想化環境において仮想マシンの可用性を高めるための機能です。 仮想マシンが障害を起こした場合に自動的に他のホスト上に仮想マシンを移動させることで、システムの停止を最小限に抑えることができるそうです！ 最後に、クラウド環境における可用性の考え方についても触れられていました。 クラウド利用においては、高い可用性を確保するだけでなく、物理機器の故障やメンテナンスに対する注意やSLAの理解、責任の明確化が重要です。 これらのポイントを留意し、リスクを最小限に抑えながらクラウド環境を活用することが重要であると、説明していただきました。 ニフクラでの高可用性を保つための取り組みについても紹介していただきました！ 「高可用性と高い信頼性を持つシステム」を実現するためにアプリケーションエンジニアができる事って何だろう？ 続いては、同じくFJCTの北條さんです。 FJCTのアプリケーションエンジニアとして、様々な観点で高可用性と高信頼性を実現するためにどうすれば良いか、FJCTでの取り組みとともに話していただきました。 具体的にいくつかピックアップして紹介していきたいと思います！ まず、モジュール性と疎結合についてです。 紹介されている通り、疎結合な設計を行うことは、システムの強化に不可欠です。 この設計手法により、システム全体が密結合でなくなり、モジュール間の依存性が低くなるため、変更や修正が容易になり、保守性や拡張性も向上します。 また、FJCTの一部プロジェクトではDDDやクリーンアーキテクチャの考え方を取り入れていることも紹介されました。 続いて、スケーラビリティです。 スケーラビリティは現代のアプリケーション設計において欠かせない要素であると説明していただきました！ またFJCTでは、コンテナ環境を前提としたアプリケーション開発を行なっており、容易に水平スケーリングできるような環境が整っているプロジェクトもあるそうです。 一部抜粋して紹介させていただきましたが、それ以外でも様々な観点で、アプリケーションエンジニアとしての高可用性・高信頼性の実現について、FJCTでの取り組みを通じで解説していただきました！ 安定稼働するポータルサイトの作り方 続いて、ニフティ株式会社の会員システムグループ第１開発チームでニフティのトップページを開発・運用を担当されている、渡邊さんに登壇していただきました！ ユーザーが日常的に利用しており、安定稼働が必須なニフティのトップページを落とさないようにするためにどのような工夫をしているか語っていただきました。 安定稼働するための工夫として最初に挙げていたものは、APIの管理にはTerraform、アプリケーションのデプロイにはServerless Framewortkを採用しているということです。 こういった、IaCツールを使うことでコードでの変更の追跡や、バージョン管理が容易になります。 構文チェックなどの機能がデフォルトで搭載されていることがTerraformの魅力ですね！ また、Lambdaを使ったサーバレス構成で動作しているため、サーバー内での作業が不要となり、アプリケーションの開発に専念することが可能になっています！ 続いて、ソースコードの管理やデプロイ周りの工夫点です。 pre-commitを用いた構文チェックの自動化や、GitHub Actionsを用いた単体テストやデプロイの自動化など、CI/CDが実現されています。 こうすることで、リリース時のオペミスを防ぐことができ、安全なリリースを行うことができるようになっています！ こちらのLTは資料を公開しておりますので、こちらも是非ご覧ください！ 月1億PVのニュースサイトを落とさない技術 最後に、ニフティ株式会社の会員システムグループ第２開発チームで、@niftyニュースの開発・運用を担当されている中村さんに登壇していただきました！ まず、ニュースサイトの特性について簡単に紹介していただきました。 SEO対策のための頻繁な更新あり、Googleから不定期な大規模な更新があると、そこに合わせた改修が必要となります。 また、瞬間的にPVが跳ね上がることもあり有名人のニュースなどが流れるとアクセスがスパイクしてしまいます。定常的なPV数も一般的なサービスと比較すると大規模となっています。 このような特性の中で、どんな時でも安定したレスポンスを返したい！ということが、目的となっています！ 今回は以下のような3つの観点でニュースサイトを落とさないための工夫について話していただきました。 まずは、リリースの自動化です。 ニフティニュースは先ほど紹介したニフティのトップページ同様、リリースフローを自動化しています。 ニフティニュースでは、サーバレス構成ではなく、ECSを使ったコンテナ環境で動作させる構成のため、CodePipelineによるリリースの自動化を行なっています。 また、CodePipelineの機能の一つである、Blue/Greenデプロイによって寸断なく自動でデプロイされます。 続いてはコンテナとクラウド技術についてです。 ニフティニュースでは、ECSを使用しており、オートスケーリングが容易となっています。 この機能により、突発的にPV数が跳ね上がったとしても、開発者が手をいれる必要なくシステムが自動でスケーリングし、安定してサービスを提供することができます！ また、一部の機能ではニフティトップページ同様、サーバレスアーキテクチャを採用しております。 そのため、運用の手間をかけることなく高い耐障害性を実現することができます。 最後にCDNの活用についてです。 CDNは、世界中に配置された多数のサーバーからコンテンツを配信し、ユーザーに高速で安定したアクセスを提供することができます。 AWSではAmazon CloudFrontというCDNがあり、ニフティニュースではこちらを利用しています！ こういったCDNを活用することにより、キャッシュを利用してコンテンツを近くのサーバーに保存し、ユーザーへ高速で安定した配信が可能となります。 これにより、遅延を軽減し、コンテンツの読み込み時間を短縮することができます。 中村さんの発表は、月1億PVのニュースサイトを落とさないための技術でした！ リリースの自動化やコンテナとクラウド技術の活用、CDNの活用など、多角的なアプローチが紹介されていました！ これらの取り組みにより、ニフティニュースは高い安定性とパフォーマンスを維持しながら、ユーザーに最適なニュース体験を提供しています。 こちらのLTは資料を公開しておりますので、こちらも是非ご覧ください！ まとめ 本記事では、落ちないシステムの作り方の各発表内容を紹介しました！ 安定稼働のためには自動化、スケーラビリティ、監視、セキュリティなど多岐にわたる要素が重要であることがわかりました！ また、クラウド技術や最新のツールの活用が安定稼働に大きく貢献していることがわかりました！ 今回のイベントは、NIFTY Tech Talkとニフクラエンジニアミートアップのコラボ企画で開催させていただきました。 インフラからアプリケーションまでの様々な観点で、システムの安定稼働について考えることができました。 いつもとは異なる開催形式で一味違ったNIFTY Tech Talkでしたが、楽しんでいただけたでしょうか？ 今後もコラボイベントをやっていきたいと思います！ 次回のTech Talkもお楽しみに！ We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering

はじめに 初めまして。 ニフティ株式会社 会員システムグループの川上拓哉です。 今回は、私の所属しているチームでの運用業務を、Webサービス「Zapier」とSlackを用いてChatOps化をしてみた、という記事です。 Zapierとは Zapier とは様々なクラウドサービス、アプリ間をノーコードで連携することができるSaaS です。 クラウドサービスのイベントやスケジュール（Trigger）をもとに、特定の操作（Action）を実行させることができ、煩雑な操作の自動化に一役買うようなサービスとなっています。 設定、編集もGUIで直感的に操作できるため、導入と実装がとても簡単です。 Slackから実行したい操作 今回ChatOps化したい操作・作業は、毎朝実施している作業です。 クラウド上の自社サーバーにあるバッチを、サーバーに入って手動で実行しています。 毎回毎回サーバーに直接入らなければならず、サクッとSlackから実行できると便利そうですね。 Slackから直接サーバーの操作はできませんが、Zapier経由でSlackをトリガーにしたさまざまな操作が可能なので、いくつか組み合わせることで今回のChatOpsの一部を実装できそうです。 構成図 ChatOpsのシステム全体では以下のような構成にしていきます。 運用者がSlackワークフローを実行しSlackに特定のメッセージを投稿すると、Zapier が起動して AWS S3 のバケットにリクエストファイルが置かれます。（今回はこちらの処理について説明します。） サーバー側で定期実行されるシェルスクリプトが、リクエストファイルを検知し、バッチを自動実行してくれます。 今回使う機能 今回は、「指定のSlackチャンネルにメッセージが投稿」されたら「AWS S3の特定バケットにテキストファイル（リクエストファイル）を作成」する機能（Zap）を活用していきます。 ZapはTriggerとActionという要素でで構成されており、今回活用していくZapだと以下のようになります。 Trigger：指定のSlackチャンネルにメッセージが投稿される。 Action：AWS S3の特定バケットにリクエストファイルを作成する。 S3バケットにリクエストファイルを置くことができれば、サーバー上から検知できるので、この機能を活用していきましょう。 （S3の操作は、有料の Professional プラン以上でしか使えない機能となりますのでご承知おきください。） Zapier Tips 実際に編集していきましょう。 最終的には、実行結果をSlackに通知もしたいので、以下のような構成のZapにしました。 Trigger：Slackにメッセージが投稿される。 Action：Slackメッセージに特定のキーワードがあった場合に続行する。 Action：Slackメッセージの投稿時間をフォーマットして抽出する。 Action：AWS S3バケットに、名前に投稿日付を含めたリクエストファイルを作成する。 Action：実行結果をSlackに通知する。 ここからは、今回のZap実装に活用した、いくつかの便利な機能やActionを紹介したいと思います。 チャンネル一覧に出てこないSlackチャンネルを指定したい Slackのチャンネルをチャンネル名で検索してもでてこないことがあります。そんなときは「SlackチャンネルをIDで指定」しましょう。 SlackチャンネルID の確認方法は割愛いたしますが、ZapierのSlackチャンネル選択画面にて「Custom」を選択しIDを入力することで指定することが可能です。 特定のメッセージが投稿された時のみ処理をしたい チャンネルに投稿されたメッセージ全てで発火してほしくない。そんなときは「キーワードを指定して続行」させましょう。 Zapierの「Filter」の中の「Only continue if…」を使います。 画像のように設定することで、指定したSlackチャンネルに、「指定したい文言」が含まれたメッセージが投稿された時のみ後続の処理を行うことができます。 今回は、専用のチャンネルのSlackワークフローから、特定のキーワードを含んだメッセージを投稿するよう実装しました。 日時のフォーマットやタイムゾーンを変更したい 今回、ChatOps実行時の日時を取得してリクエストファイルの名前に含めることにしました。 Slackに投稿されたメッセージから時間が取得したいときは、「Format」の「Date / Time」を活用しましょう 実は、Slackメッセージから取得できる時間はUTCになっており、今回は日本時間（東京タイムゾーン）での実行開始時間が欲しいので少し工夫が必要でした。 Zapierの「Format」の「Date / Time」では、タイムゾーンを変更して出力できるだけでなく、出力フォーマットを指定できます。 出力形式についてはテンプレートもいくつか用意されています。 「YYYYMMDD」のように自由に指定もできます。 以下画像のように、フォーマットを指定した出力ができました。（タイムゾーンの修正もうまくいきました。） 後続の処理でも出力結果が利用できます。 無事ChatOps化できました！ 今回作成したZapを使い、SlackからリクエストファイルをS3に作成することができました。加えてサーバーからシェルスクリプトでリクエストファイルを検知することでChatOpsを実装することができました。 ZapierにはSlack、S3の他にも連携サービスがたくさんあるので、みなさんもZapierを活用してみてください。 We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering

イベント概要 NIFTY Tech Talkは、ニフティ株式会社の社員が主催するトークイベントです。 本イベントでは、ニフティグループの社員が業務を通じて学んだことを発信しています！ 第11回目のテーマは「新人エンジニアに贈る最強の開発環境」です。 ニフティのエンジニアが、働き始めた新人エンジニアに開発環境を紹介する回となります。 概要 日程：5月30日（火）12:00〜13:00 配信方法：YouTube Live 視聴環境：インターネット接続が可能なPC/スマートフォン 参加方法 connpass にて登録をお願いいたします。 ※YouTube Liveにて配信いたします。 ※YouTube LiveのURLは決定後、参加者への情報欄に記載いたします。 こんな方におすすめ 新人エンジニアの方 Python開発環境に興味がある方 ターミナル・シェル開発環境に興味がある方 Webアプリ開発環境に興味がある方 ニフティが業務で使っているサービスに興味がある方 タイムテーブル コンテンツ 12:00 – 12:05 オープニング＋会社紹介 12:05 – 12:20 LT1: Python開発環境 ( 個人的Python開発環境構築 ) 12:20 – 12:35 LT2: ターミナル・シェルを最強にする話をすると思います 12:35 – 12:50 LT3: StrongestNewsによる最強の自作WEBアプリ開発環境 12:50 – 13:00 まとめ＋クロージング テーマ 新人エンジニアに贈る「最強の開発環境」 登壇者プロフィール 小倉 聡司（登壇者） ニフティ株式会社 基幹システムグループ 課金システムチーム 新卒入社3年目 書面発送システム他、入会系、課金請求系システム等の開発・運用を担当 上原 直希（登壇者） ニフティ株式会社 会員システムグループ 第2開発チーム 新卒入社3年目 ニフティニュースの開発・運用を担当、Rustオープン社内勉強会を主催 最強の開発環境を追い求めて、週末はdotfilesを育てている 中村 伊吹（登壇者 / ファシリテーター） ニフティ株式会社 会員システムグループ第２開発チーム 新卒入社5年目 ニフティニュースの開発リーダーを担当し、最近はモダンなフロントエンド開発を学習中。 男女混成チアリーディング元日本代表。 ニフティグループでは一緒に働く仲間を募集中です 新卒採用、キャリア採用を実施しています。ぜひ リクルートサイト をご覧ください。 ニフティエンジニアが業務で学んだことやイベント情報を エンジニアブログ にて発信しています！ ニフティエンジニアのTwitterアカウントを作りました NIFTY Tech Talkのことや、ニフティのエンジニアの活動を発信していきます。 Tweets by NIFTYDevelopers 「NIFTY Tech Day 2022」を開催しました 技術イベント「NIFTY Tech Day 2022」のアーカイブはこちら  NIFTY Tech Day 2022 アンチハラスメントポリシー 私たちは下記のような事柄に関わらずすべての参加者にとって安全で歓迎されるような場を作ることに努めます。 社会的あるいは法的な性、性自認、性表現（外見の性）、性指向 年齢、障がい、容姿、体格 人種、民族、宗教（無宗教を含む） 技術の選択 そして下記のようなハラスメント行為をいかなる形であっても決して許容しません。 不適切な画像、動画、録音の再生（性的な画像など） 発表や他のイベントに対する妨害行為 これらに限らない性的嫌がらせ 登壇者、主催スタッフもこのポリシーの対象となります。 ハラスメント行為をやめるように指示された場合、直ちに従うことが求められます。ルールを守らない参加者は、主催者の判断により、退場処分や今後のイベントに聴講者、登壇者、スタッフとして関わることを禁止します。 もしハラスメントを受けていると感じたり、他の誰かがハラスメントされていることに気がついた場合、または他に何かお困りのことがあれば、すぐにご連絡ください。 ※本文章はKotlinFest Code of Conductとして公開された文章( https://github.com/KotlinFest/KotlinFest2018/blob/master/CODE-OF-CONDUCT.md )を元に派生しています。 ※本文章はCreative Commons Zero ライセンス( https://creativecommons.org/publicdomain/zero/1.0/ ) で公開されています。

はじめに こんにちは、ニフティ株式会社 基幹システムグループの小倉です。今回は、業務で扱うことの多いPython開発環境に対して、個人的に快適でモダンな開発環境を考えてみたので、共有しようと思います。 使用するツールについて Visual Studio Code 今回使用するエディタになります。 Docker コンテナ技術を提供するツールです。 Poetry PoetryはPythonパッケージマネージャの1つです。普段の開発ではpipenvを用いることが多いですが、Poetryでは依存解決を高速に行える点と他のパッケージの設定ファイルをまとめて管理できるメリットがあるため今回は使用してみました。 Ruff Ruffは、Rustで記述されたPython用Linterです。Rustを使用しているだけあって処理速度は既存のLinterライブラリの中で最速です。また、スター数も伸びていて、AWS SAMやFastAPI等の有名なオープンソースプロジェクトでも使用されています。 Black BlackはPEP8に準拠したFormatterライブラリです。autopep8やyapfなどの他のFormatterより制限が厳しく、個人で自由に設定できる項目が少ないです。このため、フォーマットに関して、チーム内でルールを決める時間を省けます。 Mypy MypyはPythonの静的型チェックを実行するライブラリです。mypyを用いることで、型ヒント不足や型の矛盾の検知が可能になり、コードの可読性向上や堅牢性向上に繋がります。 Pytest Pythonの単体テストでよく使われているライブラリです。 Poethepoet Poetryと相性の良いタスクランナーです。PoetryにはPipenvのScriptのようなタスクランナー機能がないので、Poethepoetを使って実現しています。 事前準備 Visual Studio Code（以下VSCode）、Dockerのインストール VSCode拡張機能のDev Containersのインストール 環境構築 開発環境としては、Dockerを用いたPythonコンテナ環境を構築し、VSCode拡張機能のDev ContainerのRemote先に今回のコンテナ環境を指定します。このように、Dev Containerを経由することで、コンテナ環境下でもローカル環境と同様にVSCodeの便利な拡張機能を使用した開発が可能になります。 作業ディレクトリ構成 作業ディレクトリは以下のようになっています。 . |____app | |____Dockerfile | |____pyproject.toml | |____tests | | |______init__.py | | |____test_main.py | |______init__.py | |____.gitignore | |____main.py |____.devcontainer | |____devcontainer.json |____compose.yaml Dockerfile まず、ベースとなるPythonコンテナ環境を作成するため、以下のようにDockerfileを記述します。 FROM python:3.11-slim WORKDIR /app RUN apt update -y && \ apt install -y curl ENV POETRY_HOME /etc/poetry RUN curl -sSL https://install.python-poetry.org | POETRY_HOME=$POETRY_HOME python3 - ENV PATH="$POETRY_HOME/bin:$PATH" ENV PYTHONPATH /app COPY ./app /app RUN poetry config virtualenvs.create false && \ poetry install compose.yaml compose.yamlに関しては以下のように記述しています。 services: app: container_name: "python-dev" build: context: . dockerfile: app/Dockerfile working_dir: /app volumes: - ./app:/app tty: true pyproject.toml pyproject.tomlではpoetryによる開発環境用と本番環境用のライブラリの記述以外にも、今回使用するRuff、Black、Mypy、Pytest、Poethepoetの設定もまとめて管理します。 [tool.poetry] name = "python-dev-demo" version = "0.1.0" description = "python dev-container env" authors = ["Your Name <you@example.com>"] readme = "README.md" [tool.poetry.dependencies] python = "^3.11" pydantic = "^1.10.4" [tool.poetry.group.dev.dependencies] mypy = "^0.991" ruff = "^0.0.237" black = "^22.12.0" pytest = "^7.2.1" pytest-cov = "^4.0.0" poethepoet = "^0.18.1" [tool.mypy] warn_return_any = true warn_unused_configs = true disallow_untyped_defs = true strict = true [tool.ruff] select = [ # pyflakes "F", # pycodestyle errors, warnings "E", "W", # isort # "I", # flake8-2020 "YTT", # flake8-bugbear "B", ] target-version = "py311" line-length = 120 [tool.black] line-length = 120 target-version = ["py311"] [tool.pytest.ini_options] testpaths = [ "tests", ] [tool.poe.tasks.pytest] shell = "pytest -v --cov=. --cov-branch" interpreter = "bash" [build-system] requires = ["poetry-core"] build-backend = "poetry.core.masonry.api" Poetry 環境ごとにライブラリの依存関係を分離するためには tool.poetry.group.<group> を使用します。 Mypy strict = true にすることでmypyのオプションのエラーチェックフラグをすべて有効にし、厳重な型チェックが可能になります。ただし、いくつかのオプションはstrict モードでも無効になっています。無効になっているフラグに関しては、  mypy --help  の出力で確認することができます。 Ruff Ruffでは、現時点で500を超えるlint ルールをサポートしており、 select に追加したいルールに紐づくコード名を記述するで有効にすることができます。デフォルトでは Pyflakes（F） と pycodestyle （E）が有効になっています。 Black 基本的な設定としては、 line-length によって1行の文字数制限を変更できます。 Pytest testpaths でテストディレクトリの設定しています。 今回はついでにカバレッジを取得するPytest-covもInstallしています。 Poethepoet 基本的な使い方としては、今回のpyproject.tomlで定義しているように [tool.poe.tasks.<task_name>] で設定し、 poe <task_name> で実行できます。 今回の例では、 pytest -v --cov=. --cov-branch コマンドでpytestのテスト結果とカバレッジを毎回叩くのが面倒なので、 poe pytest で実行できるようにしています。 devcontainer.json devcontainerの設定にはdevcontainer.jsonを使用します。 今回の用途ではまず、compose.yamlの場所、compose.yamlで定義するservice名とワークディレクトリを指定しています。 devcontainer環境で使用したいVScode拡張機能を extensions 、その拡張機能の詳細設定を settings で定義します。 今回は拡張機能として、Python拡張機能とruffの拡張機能を入れています。 拡張機能の詳細設定としては、デフォルト設定の不要な機能無効化、それぞれのライブラリのインタープリタパスとpyproject.tomlで定義したライブラリの設定を拡張機能側に反映させています。 { "name": "Python-dev Template", "dockerComposeFile": ["../compose.yaml"], "service": "app", "workspaceFolder": "/app", "customizations": { "vscode": { "extensions": [ "ms-python.python", "charliermarsh.ruff" ], "settings": { "editor.formatOnSave": true, "[python]": { "editor.codeActionsOnSave": { "source.fixAll": true, } }, "python.defaultInterpreterPath": "/usr/local/bin/python", // "python.formatting.provider": "none", "python.formatting.provider": "black", "python.formatting.blackPath": "/usr/local/bin/black", "python.formatting.blackArgs": ["--config=${containerWorkspaceFolder}/pyproject.toml"], "python.linting.mypyPath": "/usr/local/bin/mypy", "python.linting.mypyArgs": ["--config=${containerWorkspaceFolder}/pyproject.toml"], "python.linting.mypyEnabled": true, "python.linting.enabled": true, "python.testing.pytestPath": "/usr/local/bin/pytest", "python.testing.pytest": ["--config=${containerWorkspaceFolder}/pyproject.toml"], "python.testing.unittestEnabled": false, "python.testing.pytestEnabled": true, "ruff.args": ["--config=${containerWorkspaceFolder}/pyproject.toml"], "ruff.path": ["/usr/local/bin/ruff"], "ruff.interpreter": ["/usr/local/bin/python"] } } } } 動作確認 以上の設定が完了したら、コマンドパレッド（command + option + P）を開き、 Reopen in Container を実行することで、以下の画像のようにdevcontainer環境に入れます。 Dev Container環境に入ると以下のような機能が利用できるようになっています。 それぞれのライブラリのルールに違反したコードに波線ハイライト e ditor.formatOnSave によってBlackによる保存の際に自動フォーマット Pythonコード内で保存した際にruffによる自動修正 Pytestの機能として、画面左側のフラスコマークをクリックすることでテスト対象のディレクトリ、ファイル名、テスト名が表示されデバッグやテストがGUIから実行可能 おわりに ここまで、Dev Containerを使ってPythonのDocker開発環境を構築しました。 今回は必要最低限の設定しかしていないので、このコードを参考に独自にカスタマイズしていただければ幸いです。 We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering

イベント概要 NIFTY Tech Talkは、ニフティ株式会社の社員が主催するトークイベントです。 本イベントでは、ニフティグループの社員が業務を通じて学んだことを発信しています！ 第10回目のテーマは「【エンジニア必見】Notionで仕事のスピードを加速するテクニックとは？」です。 ニフティのエンジニアがNotionを使ってどのように開発を進めているか、今すぐ真似できる事例、テクニックを交えつつLT形式で発表します。 概要 日程：4月27日（木）12:00〜13:00 配信方法：YouTube Live 視聴環境：インターネット接続が可能なPC/スマートフォン 参加方法 connpass にて登録をお願いいたします。 ※YouTube Liveにて配信いたします。 ※YouTube LiveのURLは決定後、参加者への情報欄に記載いたします。 こんな方におすすめ エンジニアのNotion活用事例、活用術について興味がある方 今すぐ役立つNotionのテクニックを知りたい方 Zapierを使ってNotionを自動連携して効率的に仕事を進めたい方 ニフティが業務で使っているサービスに興味がある方 タイムテーブル 時間 コンテンツ 12:00 – 12:05 オープニング＋会社紹介 12:05 – 12:20 【LT/松阪】世界一利便性が高くてかっこいいプロダクトwikiを目指す 12:20 – 12:40 【LT/南川】Zapierを使った Google FormとNotion DBの連携 12:40 – 12:55 【LT/石川】NotionのWiki機能を使ったページ管理を考えてみる 12:55 – 13:00 まとめ＋クロージング テーマ 【エンジニア必見】Notionで仕事のスピードを加速するテクニックとは？ 登壇者プロフィール 石川 貴之（登壇者） AWS/GCPの組織管理、Notion/GitHub等のSaaS管理、自社Webサービス基盤の担当をしています。 松阪 僚子（登壇者） @nifty会員向けスマートフォンアプリ「マイ ニフティ」の開発・運用を担当しています。 快適な開発体験のため、ドキュメント整備に熱意を注いでいます！ 南川 大樹（登壇者） 普段はシングルサインオンやユーザーサインアップなどの開発や運用を担当しています。Notionまわりの自動化を模索中。 小浦 由佳（ファシリテーター） ニフティの情シスをやっています。Notion力はまだまだなので、この機会に学びたいです！ ニフティグループでは一緒に働く仲間を募集中です 新卒採用、キャリア採用を実施しています。ぜひ リクルートサイト をご覧ください。 ニフティエンジニアが業務で学んだことやイベント情報を エンジニアブログ にて発信しています！ ニフティエンジニアのTwitterアカウントを作りました NIFTY Tech Talkのことや、ニフティのエンジニアの活動を発信していきます。 Tweets by NIFTYDevelopers 「NIFTY Tech Day 2022」を開催しました 技術イベント「NIFTY Tech Day 2022」のアーカイブはこちら  NIFTY Tech Day 2022 アンチハラスメントポリシー 私たちは下記のような事柄に関わらずすべての参加者にとって安全で歓迎されるような場を作ることに努めます。 社会的あるいは法的な性、性自認、性表現（外見の性）、性指向 年齢、障がい、容姿、体格 人種、民族、宗教（無宗教を含む） 技術の選択 そして下記のようなハラスメント行為をいかなる形であっても決して許容しません。 不適切な画像、動画、録音の再生（性的な画像など） 発表や他のイベントに対する妨害行為 これらに限らない性的嫌がらせ 登壇者、主催スタッフもこのポリシーの対象となります。 ハラスメント行為をやめるように指示された場合、直ちに従うことが求められます。ルールを守らない参加者は、主催者の判断により、退場処分や今後のイベントに聴講者、登壇者、スタッフとして関わることを禁止します。 もしハラスメントを受けていると感じたり、他の誰かがハラスメントされていることに気がついた場合、または他に何かお困りのことがあれば、すぐにご連絡ください。 ※本文章はKotlinFest Code of Conductとして公開された文章( https://github.com/KotlinFest/KotlinFest2018/blob/master/CODE-OF-CONDUCT.md )を元に派生しています。 ※本文章はCreative Commons Zero ライセンス( https://creativecommons.org/publicdomain/zero/1.0/ ) で公開されています。

「エンジニアを目指していながら、知らない事ばかりだった」 「炎上という言葉はニフティから生まれた？！」 「ブログブームの火付け役がニフティ？」 「多くの情報関連の法律が整備されるきっかけになっていた事を学びました」 これらは新入社員研修の中で、当社のCIO（最高情報責任者）の講義を聞いた後の新入社員の感想です。 これってIT業界を目指す就活生はほとんど聞いたことが無いのでは……？ ……という事で、ネット業界のエンジニア界隈で「生ける伝説」が語る、特別説明会を急遽開催することにしました！ 参加はこちらから（24新卒限定）。 https://job.axol.jp/jn/s/nifty_24/entry_5918530314/ マイページからご登録の上、ご予約をお願いいたします。 登壇者：取締役（兼）専務執行役員CIO　前島一就 本セミナーは4月25日限定でのWEB開催です。 創業時から日本のインターネット業界を大きく牽引してきた前島が、ニフティのこれまで、そして将来のIT業界を志す若者に期待することなどをお話します！ ぜひご参加下さい！ これから面接に参加される方や選考途中の方もぜひ当社への理解を深めるためにご参加ください！ エンジニア職志望の方だけでは無く、ビジネス職（※）志望の方の参加も大歓迎です。 （※）カスタマーサポート、企画、営業、コーポレート） 日程（オンライン実施） 4月25日（火）10時～12時 内容 会社説明 役員からの話 質疑応答 若手社員からの業務紹介 選考のご案内 登壇役員の紹介 取締役（兼）執行役員（兼）CIO　前島 一就 パソコン通信「NIFTY-Serve」のサービス開発から運用まで携わる。 現在はCIO（最高情報責任者）としてニフティの技術部門を統括。 ＜登壇役員掲載記事＞ 社員インタビュー アマゾン ウェブ サービス (AWS)導入時のインタビュー記事 ニフティへの理解をさらに深める機会となります！ ぜひご参加ください！ 参加方法 https://job.axol.jp/jn/s/nifty_24/entry_5918530314/ マイナビ2024 マイページからご登録の上、ご予約をお願いいたします。

概要 「NIFTY Tech Talk」は、ニフティ株式会社の社員が主催する、技術に関するトークイベントです。 このイベントでは、ニフティグループの社員が業務を通じて学んだ知見や経験をLT形式で発信しています。 今回は、富士通クラウドテクノロジーズ株式会社のニフクラエンジニアミートアップの方々もゲストとして参加されます。 テーマは「落ちないシステムの作り方」として、業務で扱っているシステムが安定して稼働するための工夫やノウハウを、現場社員がLT形式で紹介してくれます。 基本情報 日程：4月19日（水）20:00〜21:30 配信方法：YouTube Live, Zoom 視聴環境：インターネット接続が可能なPC/スマートフォン 参加方法： connpass にて登録をお願いいたします。 こんな方におすすめ システムの安定稼働を目指しているエンジニア ニフティやFJCTの技術や風土に興味があるエンジニア タイムテーブル コンテンツ 19:50-20:00 入場開始 20:00-20:05 挨拶 20:05-20:20 落ちないシステムって何？可用性の基本と仮想環境での可用性の高め方（仮） 20:20-20:35 「落ちないシステム」実現に向けてアプリ開発でできる事って何だろう？（仮） 20:35-20:50 サービス依存度の高い環境でも安定稼働するポータルサイトの作り方 20:50-21:05 月1億PVのニュースサイトを落とさない技術 21:05-21:30 Q&Aセッション 21:30 中締め 残れる人は残って交流 内容 落ちないシステムって何？可用性の基本と仮想環境での可用性の高め方（仮） 登壇者名：奥山 洋平 富士通クラウドテクノロジーズ株式会社 「落ちないシステム」実現に向けてアプリ開発でできる事って何だろう？（仮） 登壇者名：北條 裕 富士通クラウドテクノロジーズ株式会社 サービス依存度の高い環境でも安定稼働するポータルサイトの作り方 登壇者名：渡邊 大介 ニフティ株式会社 会員システムグループ第１開発チーム @niftyトップページなどの自社WEBサービスの開発・運用担当をしています。 最近はプライベートでChatGPTを活用したサービスを何か作れないか模索しています。 月1億PVのニュースサイトを落とさない技術 登壇者名：中村 伊吹 ニフティ株式会社 会員システムグループ第２開発チーム 新卒入社5年目。 ニフティニュースの開発リーダーを担当し、最近はモダンなフロントエンド開発を学習中。 男女混成チアリーディング元日本代表。 ニフティグループでは一緒に働く仲間を募集中です 新卒採用、キャリア採用を実施しています。ぜひ リクルートサイト をご覧ください。 ニフティエンジニアが業務で学んだことやイベント情報を エンジニアブログ にて発信しています！ ニフティエンジニアのTwitterアカウント NIFTY Tech Talkのことや、ニフティのエンジニアの活動を発信していきます。 Tweets by NIFTYDevelopers 「NIFTY Tech Day 2022」を開催しました 技術イベント「NIFTY Tech Day 2022」のアーカイブはこちら  NIFTY Tech Day 2022 アンチハラスメントポリシー 私たちは下記のような事柄に関わらずすべての参加者にとって安全で歓迎されるような場を作ることに努めます。 社会的あるいは法的な性、性自認、性表現（外見の性）、性指向 年齢、障がい、容姿、体格 人種、民族、宗教（無宗教を含む） 技術の選択 そして下記のようなハラスメント行為をいかなる形であっても決して許容しません。 不適切な画像、動画、録音の再生（性的な画像など） 発表や他のイベントに対する妨害行為 これらに限らない性的嫌がらせ 登壇者、主催スタッフもこのポリシーの対象となります。 ハラスメント行為をやめるように指示された場合、直ちに従うことが求められます。ルールを守らない参加者は、主催者の判断により、退場処分や今後のイベントに聴講者、登壇者、スタッフとして関わることを禁止します。 もしハラスメントを受けていると感じたり、他の誰かがハラスメントされていることに気がついた場合、または他に何かお困りのことがあれば、すぐにご連絡ください。 ※本文章はKotlinFest Code of Conductとして公開された文章( https://github.com/KotlinFest/KotlinFest2018/blob/master/CODE-OF-CONDUCT.md )を元に派生しています。 ※本文章はCreative Commons Zero ライセンス( https://creativecommons.org/publicdomain/zero/1.0/ ) で公開されています。

はじめに こんにちは。新卒3年目メンダコです。普段は社内NW・サポートセンターNWの担当をしています。最近午後の紅茶を午前に飲んだら怒られが発生しました。 業務とは関係ないのですが、趣味でCTFというものをやっています。初心者向けの大会にしか参加していないのですが、とても楽しかったので今回はCTFの紹介をしたいと思います！！ CTFとは 概要 CTFとは「Capture The Flag(キャプチャーザフラッグ)」の略で、セキュリティに関する競技会です。CTFでは、様々なセキュリティ課題が用意され、参加者はそれらの課題を解決することでポイントを獲得します。セキュリティエンジニアやハッカーなどが参加し、自身の技術を磨くための場としても利用されています。 大会で有名なものとしては、アメリカのDEFCON、国内ではSECCONがあります。 ルール flagと呼ばれる文字列が隠されているので、それをセキュリティの知識を使って探し出します。探し出したflagを回答サーバに送信することで、ポイントを獲得できます。flagの形式については、flag{hogehoge}や、FLAG_fugafugaなど大会によって違うので、ルールを確認しましょう。 大会によって違いますが、制限時間は12時間～48時間ぐらいがほとんどです。 個人戦だけでなくチーム戦もあります。 出題される問題について セキュリティにかかわる技術を使用して解く問題が出されますが、とても出題範囲が広いため幅広い知識が必要になります。 出題分野、出題範囲については大きく分けると次の通りになります。 出題分野 出題範囲 ネットワーク 信号処理通信技術 ネットワークトラフィックのキャプチャ フォレンジクス 情報の秘匿 ログ解析 ファイルフォーマットデータの復元 Web技術 Webアプリケーションの脆弱性 データベースアクセス プログラミング プログラミング言語 組み込み技術 リバースエンジニアリング 暗号化技術 符号化公開鍵基盤（PKI） 脆弱性調査 脆弱性バグ攻撃コードの送信 チームで参加する場合は、何か一つ得意分野を作ってチームメンバーと手分けして問題を解くのがいいと思います。 取り組む際にあると便利なツール たくさんあるのでここでは主要なものだけ紹介します。 Google 一番大事。 わからないことがあったら検索しよう！！！！！！！！ 大会中でも検索できます！！！！！！！！！ Wireshark ネットワーク問題で、パケットを解析するのに使います。 CTFでpcapファイルが出てきたらこのツールの出番です。 バイナリエディタ その名の通りバイナリを編集できるエディタになっています。 ヘッダ情報を書き換えて、開けないファイルを開けるようにしたり、バイナリの置換をする際に使用します。 ちなみに私は私生活ではMacを使用しているので、0xEDというバイナリエディタを使用しています。 CTFの勉強法 基本は過去問・常設CTFを使って、実際に問題を解いて手を動かしてみるのが初心者・経験者ともにおすすめの勉強法になっています。 過去問 大体の大会の問題は以下のサイトを探せばあると思います。あまり古い問題だと環境によっては動かないことがあるので注意する必要があります。 GitHub captf.com 常設CTF 有名どころとしては以下の4つです。私は一部のサイトの問題しか見たことがないのですが、初心者向けの問題も結構多めです。 ksnctf akictf CpawCTF Flaggers 本 この2冊が初心者入門にお勧めと有名な本です。ルールの説明などあるのでCTFに参加したいけど、問題のイメージがつかみにくい人にいいと思います。 セキュリティコンテストチャレンジブック(通称ハリネズミ本)には、演習ファイルもついています。 セキュリティコンテストチャレンジブック -CTFで学ぼう! 情報を守るための戦い方 Hacking: 美しき策謀 第2版 ―脆弱性攻撃の理論と実際 大会の探し方 SECCONについては公式サイトに日程が載っています。 CTF関連の勉強会などの情報もあるのでとりあえずここを見るのがいいと思います。 https://www.seccon.jp/2022/ SECCON以外の大会は以下のサイトに日程が載っています。 こちらで初心者向けの大会を探すのもいいと思います。 https://ctftime.org/ 結局やって何の役に立つの？ 例えば、ネットワーク問題であれば、トラフィックをキャプチャする技術を身に着けることができます。それを覚えることで、ネットワークの通信が通らないときなどの、トラブルシューティングに役立てることができます。 Web系の問題であれば、脆弱性をついて攻撃をして問題を解きます。攻撃方法を知ることにより、安全なアプリケーションの作り方を理解できるようになります。 上記のように実際の開発や運用などでも役に立つことがいっぱいあると思います！ 注意点 サーバーをハッキングしたり、ソフトウェアの脆弱性を突いたりするような問題がありますが、 許可された範囲外で行うと、違法行為となる可能性があります。 CTFで出されている問題は、出題者が攻撃されることを前提に公開しているものなので問題ありません。 許可された範囲内で楽しみましょうね！ We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering

こんにちは、気づけば入社してから3年目も終わろうとしている宮本です。先日は、NIFTY Tech Talk #9 「SvelteKit, Next.jsの導入事例紹介など 〜ニフティのフロントエンドの今とこれから〜」で担当している @nifty トップページのNext.js化について話してきました。当日ファシリテーターをしていた筑木くんの紹介記事がすでに掲載されているので、ぜひご覧ください！ 紹介記事： SvelteKit, Next.jsの導入事例紹介など 〜ニフティのフロントエンドの今とこれから〜 NIFTY Tech Talk #9 を開催しました！ さて、今回の記事はここからが本題です。Tech Talk中で@niftyトップページではTypeDocを使いドキュメントを作成していると軽く触れました。フロントエンドアプリケーションのドキュメント生成といえばやはりStorybookが有名どころですが、今回はTypeDocをご紹介させていただこうと思います。 TypeDocってなに？ TypeDoc は、TypeScriptで記述されたアプリケーション用のドキュメント生成ツールです。記述方法は簡単で、JSDocに非常によく似たTSDoc形式でコード内にコメントを書いていくだけ。あとはドキュメント生成コマンドを打てば、自動でドキュメントが作成されます。めっちゃ便利。 簡単な例ですが、次のようなドキュメントを作成することができます。こちらは create-next-app で自動生成したサンプルアプリケーションに、いくつかコンポーネントやカスタムフックを追加したアプリケーションです。 画像は型情報についてのドキュメントで、これを生成した元のコードは下のようになってます。TypeScript本来の型定義に加え、軽くコメントで補足している程度です。細かい記法についてはかなり量が多いので、公式ドキュメントをご覧ください。 export type UseCheck = { /** * チェック済みであるかを表す */ isChecked: boolean; /** * チェック状態を切り替える * @returns */ toggleCheck: () => void; }; TypeDocの設定 ここからは、アプリケーションにTypeDocを導入する方法を紹介します。create-next-appなどでサンプルアプリケーションを作成してこの手順を試してみると、どのようなドキュメントが生成されるのかなどもわかりやすいと思います。 1. インストール yarn add -D typedoc 2. 設定 TypeDocはドキュメントをビルドするタイミングで設定を入れることもできますが、typedoc.jsonというファイルを用意していると、毎回自動で設定を読み込んでくれるので手間がかかりません。 最初に、必須の設定のみ追加しておきます。schemaは入れておくとvscodeでの補助が効くので便利です。 entryPoints：ドキュメントを生成する対象のコードが存在する最上位のディレクトリを指定します。 entryPointStrategy：ドキュメントを作成する元になるファイルの指定方法を変更します。 デフォルト設定ではentryPointsに指定したディレクトリのindex.tsファイルを起点として指定しようとするため、そもそもindex.tsを用意していない場合は生成自体ができません。ディレクトリごとに必ずしもindex.tsを用意しないフロントエンドのために、全ファイルを起点にドキュメントを生成するようにします。 typedoc.json { "$schema": "https://typedoc.org/schema.json", "entryPoints": ["./src"], "entryPointStrategy": "expand", } 3. ドキュメント生成 このコマンド一つでドキュメントを生成することができます。 yarn typedoc 4. プラグイン さて、上記までの手順でドキュメントを生成することはできるのですが、実際に生成されたドキュメントを見るとデフォルトでは結構見づらいです。特に辛いのが、このサイドバー……。スラッシュが入っていることからも分かる通り、entryPointsで指定したディレクトリからの相対pathをそのまま利用しています。 ファイルごとに表示されているが、全ファイルが同一階層で表示されてしまう だいぶ手抜き気味なこのサンプルこそ9ファイルしか用意していないのでまだ良さそうに見えますが、実際のアプリケーションではもっとファイル数も多いと思います。その分がずらっと並ぶと考えると、かなり見づらくなってしまうでしょう。 うん、これは無理です、諦めよう……。と思いましたが、幸いTypeDocにはさまざまなプラグインがあります。 フロントエンドのドキュメントを書く場合は、以下のどちらかが使いやすいと思います。なお、今回ここで挙げた両方を適用すると、ファイルが階層を無視して統合されたりと使いづらくなってしまったのでご注意を。 typedoc-theme-hierarchy typedoc-theme-hierarchyは、サイドバーに表示されるファイル名が実際のディレクトリと同じように階層化されて表示できるテーマプラグインです。テーマプラグインとは、生成されるドキュメントの見た目のみに手を入れるプラグインです。 注意点として、テーマプラグインはTypeDocが0.23にアップデートした際に後方互換無しで新しくなったため、古いテーマプラグインは使えない可能性があります。 導入方法はyarnでインストールし、設定ファイルで利用するテーマを選択します。 yarn add -D typedoc-theme-hierarchy@^3.0.0 typedoc.json { "$schema": "https://typedoc.org/schema.json", "entryPoints": ["./src"], "entryPointStrategy": "expand", "theme": "hierarchy" } hierarchyテーマを適用することで、画像右のような階層表示がTypeDocにも適用されるようになり、だいぶ見やすくなります。 defaultテーマ（左）とhierarchyテーマ（右） typedoc-plugin-merge-modules 二つ目の方法は、typedoc-plugin-merge-modulesを利用する方法です。entryPointStrategyをexpandにした場合、デフォルトでは1ファイル=1モジュールとなります。それをこのプラグインを用いることで複数のファイルをTypeDoc上で一つのモジュールとして扱い、関連する機能ごとにまとめることができます。 yarnやnpmでインストールし、設定ファイルにmergeModulesMergeModeを追記します。 yarn add -D typedoc-plugin-merge-modules typedoc.json { "$schema": "https://typedoc.org/schema.json", "entryPoints": ["./src"], "entryPointStrategy": "expand", "mergeModulesMergeMode": "module" } mergeModulesMergeModeはモジュールをまとめ方を選択するオプションです。以下の3パターンがあります。 project：全ファイルを1モジュールとして扱う ファイルや関数ごとに追記する必要がない アプリケーション全体で定義している関数の数が多いとわかりづらくなる module：明示的にファイルごとのモジュール名を指定し、同じモジュール名がつけられたファイル全てを合わせて1つのモジュールとして扱う 関連している機能をごとにまとめて1モジュールとして扱える ファイルごとにモジュール名を追記する必要がある module-category：同一のカテゴリタグに含まれるものを1モジュールとして扱う ドキュメントを記述する関数や変数ごとにカテゴリタグを追加する必要がある 個人的な感想としては、手軽さはprojectですが、コンポーネントやカスタムフックが多くなってくると、projectだとややドキュメントを追いづらいように感じました。一方でmoduleモードではファイルへの記述は増えるものの、機能の分割基準がはっきりしているのであれば、自由にモジュールの分割基準を決められるため、比較的管理しやすいように感じています。module-categoryモードもcategoryタグの使い方次第ですが、moduleモードとそう変わらないかもしれません。 下の画像の場合では、itemページに関わる以下のファイルを同一のitemモジュールとしてファイルにmoduleタグを追記し、まとめています。ごとに利用する関数やタイプがはっきりしている場合では、モジュール=機能という単位でドキュメントをまとめられるこの方法がわかりやすいかもしれません。 types/item.ts component/item.tsx pages/item/[id].tsx itemページに関連する複数のファイルをまとめて一つのモジュールとしてドキュメントを生成 実際に生成してみて まず初めにぶっちゃけてしまうと、フロントエンドのコンポーネントに特化したドキュメントとしてTypeDocを考えると、結構使いづらいかなと感じています……。というのも、UIドキュメントの代表格であるStorybookと異なり、直接コンポーネントの見た目や動作の確認などはできないためです。画像を添付することはできますが、変更があった際は画像を変更しなければどんどん古びてしまいます。そして、変更のあるたびに画像を作成して入れ替えて……というのは実際の手間としては些細なことですが、些細だからこそ凄まじく面倒です。フロントエンドのUIドキュメントという点ではやはりStoryBookの方が便利に感じました。 TypeDoc自体はフロントエンドアプリケーションというより、npmなどで公開されているような一般的なライブラリに適しています。出力結果に見た目というものが存在しない関数では、自動で型情報を取得してドキュメントとして表示してくれるだけでも結構ありがたいです。 一方で、コンポーネントそのものというよりは、細かいロジックを含むカスタムフックの振る舞いを記述するにはかなり向いていると思います。特に再利用されることの多いカスタムフックでは、しっかりドキュメントを書けばそれだけ後の開発が楽になると思います。また、コンポーネントではない関数について記述する分にも、こちらはTypeDoc本来の想定された使い方になるので十分使いやすいかと思います。 コンポーネントはStoryBook、コンポーネント以外はTypeDocに記述するようにして書き分けるというのが案外良いかもしれません。 最後に注意点ですが、exportされている関数・クラス等をもとにドキュメントを生成するという性質上、VueやSvelteのようなファイル内でコンポーネントを明示的にexportしないフレームワークでは、そもそもドキュメントの生成自体ができません。SvelteKitのサンプルアプリケーションからドキュメント生成を試してみましたが、一部のexportしているもののみドキュメントを生成し、肝心のコンポーネントについては何も出力されませんでした。この辺り、やはりそもそもフロントエンドアプリケーション向けに特化して作られたツールではないというあたりが大きい気がします。 ドキュメントを生成してみるという点では非常に楽に始めることができるため、一度自身のアプリケーションで生成してみて、使い勝手がどうか試してみるというのが良いかもしれません。 参考 Home | TypeDoc Create Next App | Next.js typedoc-theme-hierarchy – npm typedoc-plugin-merge-modules – npm We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering

はじめまして、新卒2年目サービスインフラチームのムサシです。 突然ですが、こんな状況になっていないでしょうか？ 「いつも同じ人が問い合わせ答えてるなあ。」 「でも自分でしっかり答えられる自信はないな…。その辺りの仕様は自信ないし…。」 とか、 「この件は自分が回答してないから聞かれてもよくわからないな。」 「時間かけて調べていたけど、この間Aさんが対応した件と全く同じだった…。」 とか。 これではいけませんね。仕様問い合わせ・調査/対応依頼回答で属人化が起きてしまっている状態です。 そんな回答の属人化を解消するために私のサブチームでは問い合わせ共有会を開いています。 問い合わせ共有会、こんな感じでやっています。 日々の問い合わせの内容と回答を共有する会です。週に１回、30分だけサブチームで共有会用に時間を取っています。 進め方を紹介するので、是非みなさんもやってみてください。 ①共有会までに問い合わせをチェック その週に来た問い合わせを見直して、「会話が長すぎて読む気がしない。3行でまとめて！」「自分では答えられなさそう。これどういうこと！？」というものをピックアップ。ピックアップした問い合わせはその日の共有会の議事録ページに書いておきます。何が聞きたいかも合わせてメモ。 【Tipsその１】 このとき、読めば理解できそうなものは個人的に読むようにします。意外と30分は短い。 【Tipsその２】 もし初歩的な質問だと思っても、どんどん聞いてOKです。新しく入ってきた人も同様に分からない可能性が高いですし、こういうのを聞いても良いんだ！っていう空気作りにもなると思います。 ②ピックアップされた問い合わせの確認タイム 議事録ページに書かれた問い合わせについて、担当した人が答えていきます。経緯や前提知識を共有していく中で、新しく疑問があれば追加質問します。 これらの質問と回答は議事録に付け加えていきます。これによって、昔対応した記憶がある…とか、口頭で伝えられてきたような「頭の中にしかない情報」をどんどん文として残すことができます。楽ちん。 【Tipsその３】 「途中で出てきた○○連携っていうのは何のこと？」「どこを見たらそれを他の人でも調べることができる？」など、次に似たような問い合わせが来た時に自分は答えられるか？という視点を持つと役立つと思います。 数ヵ月やってみた結果。そして今後の課題。 実は既に問い合わせ共有会を始めて4～5ヵ月経っています。この辺りで1度ふりかえりを入れて、参加者でGood/Badを話し合ってみました。というわけで、ここからは実際にやってみた感想の紹介です。 Goodな点 ①仕様についても詳しくなっていった 同じ問い合わせが来ることはほとんどありませんが、追加質問や関連する事項の確認を通してフローを確認したりコードを読みに行ったりしたため、少しずつ仕様に詳しくなっていきました。そのため、問い合わせ回答以外にもPBRや作業時のふとした疑問にも効果がありました。新しいメンバーが増えた時にも活用できそうですね。 ②他チームへも浸透してきた 似たような悩みを抱えていた他のサブチームでも問い合わせ共有会が浸透してきました。他のサブチームではピックアップ方式ではなく、すべての問い合わせをみんなで１つ１つ確認していく流れでやっているそうです。問い合わせの量に応じて、自分のチームに合わせてカスタマイズすると良さそうですね。 Badな点とその対策 ①準備に時間がかかる すべての問い合わせをチェックしてリストアップする、ということを私が行っていたのですが、量が多い週は準備に数十分かかってしまっていました。 この課題については週1回30分→週2回20分にすることで、1回あたりの確認対象を減らし準備期間を減らすようにしました。また、そうすることで全ての問い合わせを見る余裕も生まれました。 ②この目標って達成できるのか？ 問い合わせ共有会は「チームのみんなが問い合わせに回答できるようになる」ために行っていたのですが、多種多様な問い合わせに完璧に１人で答えるというハードルはなかなか高いものでした。達成できる気がしない目標があっても飾りになってしまうので、一歩手前の段階に再設定してみました。 みんなが回答できるために「ナレッジを溜める」。こっちの方が参加のモチベ上がりますよね。 ③情報の散らばり 問い合わせ共有会の進め方に書いた通り、その場で得た情報の管理は議事録を付けているだけでした。○月X日問い合わせ共有会というタイトルの議事録群から「あの会話いつのページだ…！？」と探す必要がありました。大変。ちょうど先ほど目標を「ナレッジを溜める」にしたので、溜め方を変えてみました。 ニフティではnotionを利用しているので、DB機能を使って質問を溜めていくことにしました。DBに溜める部分はzapierで自動化しました。担当者が回答や調べた情報をページ内に簡単にまとめることでドキュメントとしてもイイ感じです。また、タグを適宜つけることで検索性を向上できないか実験中です。DB機能、便利ですね。 問い合わせ共有会やってみたい方へ 記事を参考に始めてみてもいいですし、しなくても良いのですが、もしよかったら「こんな感じでやってみたよ！」というのを発信してくれると嬉しいです。参考になります。 また、同じような悩みを抱えていて「やってみたいけど、うちのチームの文化的に厳しいな…そもそもチームじゃないんだよな…」と困っている方がいれば、私たちと一緒に働いてみませんか？お待ちしております。 私のチームの上司が絶賛カジュアル面談受付中なので（投稿日の時点では）こちらも是非チェックしてみてください。 https://meety.net/matches/cVJuDlRiIhZh We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering

はじめに こんにちは。ニフティ入社新卒四年目の佐々木です。今回はAWSのリソースの一つである S3 についてコスト削減を行う方法を紹介します。 背景 ニフティではクラウドとしてAWSを活用しており、その中でサービスに対してクラウドリソースのコストを削減するといった活動も行っています。 そこで、今回は担当システムでAWSのコスト削減を行う機会があったので、何故削減するのか？どういう点で主に削減できそうか？削減する場合の注意点や考え方について紹介します。 この記事の内容 触れること S3のコスト削減方法 S3のコストを削減する上での注意点 実際に試したコスト削減例とTips 触れないこと S3そのものの説明 ストレージクラスなどの詳しい説明 S3を使用したコスト削減方法 課金形態 普段はニフティトップページの運用を担当しており、AWSにデプロイしたサービスを採用しています。 特にAWSの中でも、S3はほぼ制限なしで容量を必要な分だけ増やして使えるのでとても便利なサービスですが、使用した分だけコストがかかってしまうというデメリットもあります。 そこで、 S3の課金形態 について最初にご紹介したいと思います。2023年3月現在では主に以下のようになっています。 ストレージに対する課金 S3バケットにオブジェクトを保存するには料金がかかります オブジェクト内に保存されているデータサイズによって月額のコストが決まります リクエストとデータ取り出しに関する課金 S3バケットとオブジェクトに対して行われたリクエストに対しても料金がかかります リクエストの量に応じて課金されます リクエストタイプによって料金が異なります オブジェクトにデータを保存し取得するといった単純なフローを考える場合、基本的にはこれらの 2つの要素 がほとんどの課金要素になってくるかなと思います 削減方法 次に、主に既に使用しているS3に対して対処できそうな方法をご紹介します ストレージクラスの選択 上記でも触れたとおり、S3には様々なストレージクラスがあり、アクセス頻度に応じてコストを削減できます 例えば、サーバーのアクセスログを年単位で保存すると言った場合には、すぐにログを取りだす必要がないのであれば、低頻度のストレージクラスに移動させることでコストが節約できます ライフサイクルルールの設定 これはストレージクラスの話にも関わってきますが、アクセス頻度の低いバケットに対しては「一定期間たった後にアクセス頻度の低いストレージクラスに移動する」などといった柔軟性をもたせた対処ができます もし、ログの保存ルールが決まっている場合は、例えば最初の3ヶ月はすぐに取り出せるよう高頻度アクセス用のストレージに保管し、その後アーカイブとして1年間低頻度用のストレージに保存するといったこともできます リクエストコストの削減 S3にあるデータの取り出しにはコストがかかるので、それらを削減する方法も重要になります 例えば、S3にアクセスするためのリクエストの頻度を減らす、S3に保存するデータ量を見直すといった対処ができます 不要データの削除 単純に不要となっているバケットそのものを削除する方法です 不要なデータはそもそも保存させない、不要なバケットそのものを削除する、といった節約方法になります 実際にためしたこと 次に、S3のコスト削減を考えた際に実際に試したことや注意点などについて、Tipsを話していきたいと思います S3の課金項目の把握 何はともあれ、まずは現状のコストの把握から始めないといけません。実際にどの程度S3にコストが掛かっているのかを把握するため、Cost Explorerでサービスごとに料金を確認していきます。 例えば、S3のどの要素に課金がされているのかを把握することが重要です。S3バケットに対してタグを付与することで、Cost Explorerからのコスト把握がしやすくなります。 また、実際にタグを付与したりしたりすることで、「このバケットは何に使われていたのか？」といった目的の確認ができたりします。それらを活用し現状を把握することで、その後に削減する箇所のアイデアが浮んだり、後述するリソースの洗い出しにつながってくるといったメリットはあると思います。 S3バケットとオブジェクトの精査 次に、S3ストレージに保存されているオブジェクトサイズを把握するために精査を行いました。 ここでは、 S3 Storage Lens という機能を活用することで、S3の様々な情報をコーンソール上で確認することができます。以下はとあるバケットの例ですが、ストレージクラスごとのバケットサイズやオブジェクトの合計数などの詳細を把握できます。 また、閲覧出来る数に制限はありますが、使用量が上位のバケット一覧もこちらから確認できます。今回調査した範囲ではバケットが100個程度と数が多かったので、これを活用することでバケットサイズなどを容易に洗い出すことができました。 不要なバケットの削除 ここまでで、バケットのストレージサイズや使用用途について洗い出せたので、さらに不要なバケットの削除を行いました。 担当システムのチームで洗い出しを行った上でバケットの削除を行いましたが、今回の例ではそもそもデータ容量が多い不要なS3バケットがあまり存在しなかったので、コスト削減の効果は限定的でした。 ただ、不要なバケットを削除しリソースの整理ができたので、「このリソース何だっけ？」といった将来の管理面の負担を減らせたという点で、コスト面以外でもメリットがあったかと思います。 ライフサイクルルールの見直し検討 一方で、ストレージクラスごとの料金から現状のルールと変更後のルールを比較しコストの計算を行いました。 結局、今回はこちらも効果が限定的だったので変更は見送りましたが、もし保管しているデータ量の多いS3バケットが存在するのであれば、かなり手軽に削減出来る方法だと思いました。 まとめ 今回はS3のコスト削減について紹介しました。 全体を通した感想としては、アーキテクチャの把握からコスト削減までを一通りやることで知識も身につくので、担当プロジェクトでもし余裕があるのであれば一度そのような取り組みをやってみると良いなと思いました。それに加えて、AWSについて詳しくなれますし「この部分も実は改善できるのでは？」といったサービスに対する一歩上の視点で見れるようになったので学びになりました。 S3単体だけでなく、他のサービスと組み合わせることでさらにコスト削減を仕組みを導入する予定なので、また機会があればそちらも紹介したいと思います。 参考記事 https://aws.amazon.com/jp/s3/ https://aws.amazon.com/jp/s3/pricing/ https://aws.amazon.com/jp/blogs/news/s3-storage-lens/ We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering

はじめに こんにちは！ 「SvelteKit, Next.jsの導入事例紹介など 〜ニフティのフロントエンドの今とこれから〜」の司会進行を務めました新卒入社3年目の筑木（つづき）です。 先日2月21日にNIFTY Tech Talk #9として「SvelteKit, Next.jsの導入事例紹介など 〜ニフティのフロントエンドの今とこれから〜」を開催しました。 今回はその様子をレポートします！ イベント概要 NIFTY Tech Talkは、ニフティ株式会社の社員が主催するトークイベントです。 本イベントでは、ニフティ社員が業務を通じて学んだことを発信しています。 第9回目となる今回は「フロントエンド」に関するテーマで開催しました。 ニフティで現在使用されているフロントエンド技術や行っている取り組み、Web制作のお話など多岐にわたる内容でお送りしました。 今回の登壇テーマは下記となります。 ニフティトップのNext.jsでのキャッシュ戦略を考えた話 テンプレートエンジン + jQueryからNext.jsに置き換える ニフティのLP（ランディングページ）ができるまで 新サービスにSvelteKitを導入してみた！ 社内にWebアクセシビリティを取り入れていきたいなぁと思っている話 また、今回のTech Talkのアーカイブ動画をYouTubeにアップロードしております。ぜひご覧ください！ 内容レポート 各セッションから抜粋して、どのような内容だったかを紹介します！ ニフティトップのNext.jsでのキャッシュ戦略を考えた話 登壇者：会員システムグループ　佐々木 優 登壇資料はこちら   まず1つ目のLTは、 @niftyトップページ のキャッシュ戦略を考えた話です。 @niftyトップページは2022年7月にシステム基盤の刷新を行っており、刷新のタイミングでNext.jsを導入しました。 刷新については、過去に開催された NIFTY Tech Talk #4 レガシーシステムからの脱却のレポート記事 を参照ください。 キャッシュの種類・内容・そしてどう分ける？ キャッシュには CDNのキャッシュ と ブラウザキャッシュ の2種類があり・・・ その違いについて分かりやすく説明してくださいました。 キャッシュを行うにあたって、どのコンテンツをどうキャッシュする？と考えることに。 まず、キャッシュするコンテンツとしないコンテンツを分けました。 キャッシュするコンテンツは画像やCSSなどの更新頻度が低いコンテンツ・データ転送量が大きいコンテンツなどをあげられ、しないコンテンツとしてAPIを挙げられてました。 @niftyトップページでは、ログイン機能を用いた固有情報、つまりキャッシュする意味がないものがキャッシュされてしまう懸念があるため安全に舵を切ったとのこと。 確かに不明なコンテンツがキャッシュされていると意図しないコンテンツが出てしまったりする可能性がありますから、なるほどと思いました。 紆余曲折を経て無事リリース！ ・・・と思いきや失敗談もあったとか。 画像ブラウザキャッシュが短く設定されてたため、本来不要な画像のリクエストが発生し結果コスト増加を起こしてしまったとのこと・・・。想定外はあるあるですね。 こちらはルールを追加することで対応完了！ リクエスト数も減り、月1,000USD程度のコスト削減に繋がったとのことでした！ およそ13万円・・・（2023年2月現在）。画期的ですね。 キャッシュを行う上でどのような考えを持って、どう取り組んでいけばいいか、どの点に注意すればよいかを1から学ぶことができたLTでした。 テンプレートエンジン + jQueryからNext.jsに置き換える 登壇者：会員システムグループ　宮本 達矢 登壇資料はこちら   続けて2つ目のLTはテンプレートエンジンとjQueryの構成をNext.jsに置き換える話です。 初めのLTと同じく @niftyトップページ の刷新において行われた取り組みとして置き換えが行われたようです。 以前の環境では、約7,000行の巨大なCSSや、ローカルに動作環境がなく開発環境にアップロードを行なって動作確認を行なったり、ページ仕様のドキュメントが不完全だったりと課題が多くありました。 刷新後は見事、モダンな環境になりました！ アプリケーションの構成はNext.js + TypeScriptとなり、TypeDocを利用することで内容を充実させていきました。 となると気になるのは・・・ この構成にどうやって書き換えていったのか気になりますよね。 この構成にどう書き換えていったのか？ どう手をつけていくか、から着目を行い機能ごとに分けて開発を行う方針を固めたとのこと。 @niftyトップページはニュースの枠やサービスの枠など様々あるため、分割したということですね。 書き換えていく方法については、Reactで1から作成することに。 これはjQueryのコードから部分的に移植をすると、変更漏れによるstate化した変数のsetStateを通さない更新や、最適化されていない処理によるパフォーマンス悪化の可能性が否めないからだそうです。 当然刷新したからハッピー！と思いきや、刷新したからならではの課題が出てきたとのこと。 具体的には、ブラウザ未対応の記法をしたためjsファイルが読み込まれずにエラーなどの問題等が起きていたなど・・・他にもあったみたいです。 ニフティのLP（ランディングページ）ができるまで 登壇者：事業開発グループ　新田 万智 登壇資料はこちら 3つ目のLTはランディングページができるまで、できてからの改善活動についてのお話です。 ニフティの制作チームはデザイン制作系、動画制作、撮影業務、アプリ制作など幅広い範囲を作成、関係者がとても幅広いチームです。 依頼が来てから公開までの流れを紹介してくださったり、公開から後の活動についても発表されました。 ニフティのWeb制作の特徴は、取り扱っているサービスが自社サービス！ということもあり、公開までが目標ではなく公開後にくる改善提案やそれに対する改善策を考えることが多いのが特徴です。 また、幅広い制作を行なっているため、動画やロゴ制作の経験を積むことができたり新規サービスリリースの経験を積むことができるのもまた1つの特徴となっています。 このLTでは、改善活動の一例も紹介してくださいました。 突然ですが、下の画像を見てどちらのLPの方が良いと思いましたか？ 今回の場合は、 右側 のLPの方が結果が良くなりました。 PDCAで改善活動をされており、Plan → Doでは課題を見つけ、そこから仮説を立て提案を行う取り組みがされています。 課題を見つけるときはヒートマップやGoogleの分析ツールを利用し見つけています。 イメージで見るとすごくわかりやすいですね。 実際にこの改善を行ったところ、アプリのダウンロード率は改善前は9%だったのに対し、22%まで改善されました！ Check → Actionでは、効果検証を進める中で色々な視点で見ることが大事でLPに誘導する前のバナーやアプリ画面に問題がないかなども見ています。 最後はディレクターとして、意識されていることを共有されました。 新サービスにSvelteKitを導入してみた！ 登壇者：会員システムグループ　たけろいど 登壇資料はこちら 4つ目のLTはv1.0.0がリリースされたSvelteKitを導入し、リリースを行なった話です。 Svelte愛が感じられるLTで、Svelteを導入する利点や導入に選ばれた理由などが語られました。 広告ブロックアプリ AD Cleaner  の申し込みフォームのフロント部分がSvelteKitでできています。 スピード感のあるリリースができたのはSvelteKitのおかげとのことでした。 SvelteKitのポリシーとして 「高速、楽しい、柔軟」 があり、高速で動作し、書いていて楽しい！どんな環境でも柔軟に対応できる。 とても素晴らしいですね。 公式ドキュメントも充実しています。 書き方もVue Likeでとっつきやすいです。が、それだとVueで良くない？ともなりますよね。 Nust3もありますしSSRでは問題なさそう。Nust3はバージョンが1.0になりました。 ですが、Svelteは「コンパイラ」です。 ここが他とは異なり、JavaScriptにビルドされるという特徴があります。 Svelteは仮想DOMを使わないのでより速いし、学習コストが低い、コード記述量が少ないなど多岐にわたって強い点があり、SvelteKitが選ばれました。 プロダクトに採用されるメリット・デメリットも取り上げられました。 社内にWebアクセシビリティを取り入れていきたいなぁと思っている話 登壇者：会員システムグループ　関 歩武 登壇資料はこちら 5つ目のLTは、Webアクセシビリティを社内に取り入れていく取り組みの話です。 Webアクセシビリティとは、Webページにある情報や機能の利用しやすさのことであり様々な人々、様々なデバイスが利用しやすい状況を作っていきましょうという取り組みのことです。 関さんの担当されているシステムでは、改善できる点がいくつかあり社内で広めていく活動を始められました。 その活動として大きく2つに分けられます。 1つ目は社内ツールの作成です。 実際に良かった点としてJIS X 8341-3:2016の早見表を参考にされてチェックリストを作ったり、支援ツールを実際に使ってみるなどの取り組み内容が話されました。 2つ目に勉強会の開催を行われました。 実際の実装方法からアクセシビリティを学ぶ形式にし学びやすい体制を導入。こちらは 主催した社内勉強会の課題でアクセシビリティ的に優れているTODOリストの課題を出した話 というブログ記事にもなっていますのでぜひご確認ください。 こちらの勉強会では、オーサリングプラクティスを活用されました。 オーサリングプラクティスとは、アクセシブルに要素を実装する例がまとめられているドキュメントとなっており実装方法を学ぶ資料として最適だったようです。 また、ただ輪読するのではなく実装を体験する方が理解度が上がるため作ったものを後で見返すこともできとてもよかったと好評でした。 最後に今後やっていきたいこととして、向上施策の実施やその効果をまとめたり、関さんが担当されているシステムの不足点を取りまとめて改善していきたいと夢を語っていただきました！ システムを全ての人に便利に使ってもらえるサービス、良いですね。 Webアクセシビリティを勉強する上で参考になる本も紹介されてましたので、気になる方はアーカイブ動画をチェックしてみてください。 まとめ 今回のTech Talkはフロントエンドの技術だけでなく、制作までの流れなど幅広い範囲を聞くことができて私自身勉強になりました。 短い1時間の枠だったため、話しきれなかった内容もありましたが参考にできるものがあれば幸いです。 ニフティでは、フロントエンド勉強会を開催しており日々フロントエンドの技術についてディスカッションを行なっています。 また機会があれば、Tech Talkもしくは別の形でできればいいなと思っています。 We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering

はじめに ニフティでエンジニアをしている添野 翔太です。ここ最近、 @niftyトップページ システム基盤の刷新を進めています。 本稿では GitHubプロバイダー を利用してCI/CDパイプラインに関するリソースをTerraformで管理しようとした際にハマったポイント、そしてそれに対する解決方法を紹介します。 背景 担当するシステムではGitHubでコードを管理しているのですが、CI/CDパイプラインに関連するCodeファミリーへソースコードをミラーリングするにあたりWEBフックを仕掛けています。そしてこちらのコードはモジュール側に存在します。 resource "github_repository_webhook" "web" { repository = var.repository_name configuration { url = aws_codepipeline_webhook.webhook.url content_type = "json" insecure_ssl = true secret = aws_ssm_parameter.github_personal_access_token.value } events = ["push"] } resource "aws_codepipeline_webhook" "webhook" { name = replace("${var.application_name}_webhook_deploy", "-", "_") authentication = "GITHUB_HMAC" target_action = "Source" target_pipeline = aws_codepipeline.dummy_codepipeline.name authentication_configuration { secret_token = aws_ssm_parameter.github_personal_access_token.value } filter { json_path = "$.ref" match_equals = "refs/heads/{Branch}" } } ハマったポイント その他のコードの記載は割愛しますが、デプロイしたところ以下のような404エラーが出てくるようになりました。このままだとTerraform Applyを行うGitHub Actionsワークフロー上でもコケてしまう状態に…… % terraform apply POST https://api.github.com/repos//dummy-repo-nifkuji/hooks: 404 Not Found [] 質問サイト などを閲覧し調査を進めてみたのですが、解決に向けてなかなか進展しない状況でした。 ハマった原因 上記の404エラーを受けて、プロバイダー周りの設定がおかしくなっているのではないかという仮説を立てて、以下のコマンドを打ってみました。 % terraform providers Providers required by configuration: . ├── provider[registry.terraform.io/hashicorp/aws] ~> 4.59.0 ├── provider[registry.terraform.io/integrations/github] ~> 5.18.3 ├── module.ci_cd │   ├── provider[registry.terraform.io/hashicorp/aws] │   └── provider[registry.terraform.io/hashicorp/github] 上記の結果を見るとモジュール側と呼び出し側とでGitHubプロバイダーの設定が違うことに気付きました。この事が今回の404エラーを引き起こした原因です。 より具体的には、 公式ドキュメント によれば、sourceの指定がintegrations/githubに変わり、デフォルトだとhashicorp/githubの方が落ちてきている状態だったことです。 解決方法 そこで今回はモジュール側にもrequired_providersを用いた設定を施したファイルを配置しました。 terraform { required_version = ">= 1.4.2" required_providers { aws = { source = "hashicorp/aws" version = "~> 4.59.0" } github = { source = "integrations/github" version = "~> 5.18.3" } } } そうしたらプロバイダーの設定が揃いました。 % terraform providers Providers required by configuration: . ├── provider[registry.terraform.io/hashicorp/aws] ~> 4.59.0 ├── provider[registry.terraform.io/integrations/github] ~> 5.18.3 ├── module.ci_cd │   ├── provider[registry.terraform.io/hashicorp/aws] ~> 4.59.0 │   └── provider[registry.terraform.io/integrations/github] ~> 5.18.3 そうして404エラーは無事に解決されました。ついでにterraform init時のWarningメッセージも消えました。思い返すとこのWarningメッセージで原因と解決策を思い付けたかもしれないなと思いました。 │ Warning: Additional provider information from registry │ │ The remote registry returned warnings for │ registry.terraform.io/hashicorp/github: │ - For users on Terraform 0.13 or greater, this provider has moved to │ integrations/github. Please update your source in required_providers.<code></code> まとめ 今回はGitHubプロバイダーを利用してCI/CDパイプラインに関するリソースをTerraformで管理しようとした際にハマったポイント、そしてそれに対する解決方法を紹介しました。 何かの参考になったら幸いです。 We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering