この記事は microCMSでこんなことができた！あなたのユースケースを大募集 by microCMS Advent Calendar 2024 3日目の記事です。 はじめに こんにちは、ニフティ株式会社の宮本です。 今回はmicroCMSのアドベントカレンダー参加記事なので、初めてNIFTY engineeringを閲覧する方も多いと思います。 ニフティでもmicroCMSを利用して複数のサイトを運用をしており、せっかくなので今回のアドベントカレンダーに参加させていただきました。 コンテンツの内容によって通知先を変えたい microCMSには、コンテンツの変更があった際に叩くことのできるWebhook機能があります。デフォルト機能として、Slackへの通知や主要なホスティングサービスのビルド用Webhookが用意されています。ビルドも通知もコンテンツの更新時に実施したいので、欠かせない機能ですね。 さて、本題ですが自分が触っているAPIの中には、コンテンツの内容によって叩きたいWebhookが変わるAPIがあります。たとえばお知らせAPIでも、お知らせの種類によって別のSlackに通知をしたいなどです。あまり考えたくはないですが、障害関連のお知らせは障害用のチャンネルにも流すなど……。 このとき、microCMSのデフォルトのWebhookだと、Webhookを叩くコンテンツの更新タイミング自体を細かくカスタマイズすることはできても、コンテンツ内容によって叩くWebhookを決めることはできません。 これを解決しようとした場合、カスタムWebhookを使った上で処理内容によって分岐するAPIを作成する必要があります。実現する方法の一例としてAPI Gateway + Lambdaが挙げられますが、わざわざこれを立てるのは結構面倒です。というか面倒でした。別件でやや複雑な処理をすためにAPIをわざわざ作成したんですが、cdkでAPI Gatewayを建てるのが地味に面倒くさい……。できれば、もっと簡単な方法で実現したいです。 そこで、Zapierを用いてWebhookの叩き先を柔軟にカスタマイズする方法を紹介します。 Zapier Zapier はノーコードでワークフローを作成できるiPaaSです。他の様々なSaaSと組み合わせることでいろいろなことができ、社内でも さまざまな場面 で利用されています。 なお、今回扱うWebhook機能は有料プランでなければ利用できないためご注意ください。 microCMSの更新をZapierで受け取って通知する microCMS側でお知らせの種類をセレクトボックスで選べるようにした次のようなスキーマのAPIで考えます。 これをお知らせの種類に合わせてSlack通知するには、以下のような手順が必要です。 ZapierのWebhookを起点にmicroCMSからのデータを取得 コンテンツの種類に応じた叩きたいWebhookを取得 通知用のWebhookを叩く ZapierのWebhookを起点にmicroCMSからのデータを取得 Zapierで提供されているWebhook Appをトリガーにすることで、取得自体はできるようになります。この時点でWebhookを叩くテストが実行ができるので、microCMSのカスタムWebbhookにZapier側で発行されたWebhookを指定すると、実際に動作した際の返却値を確認できます。 返却値は以下のよう確認できます（だいぶ長いので一部抜粋）。 含まれるデータは microCMSの公式ドキュメント から確認できます。 このとき、新規作成・公開・下書き追加・公開した状態での下書き追加・削除等々、発火時の操作によって含まれるコンテンツのデータの量がやや異なるため注意が必要です。また、この後のステップで参照したい値はテスト時のリクエストに含まれている必要があります。 下書きが存在する公開済みのコンテンツの下書きを更新する操作でWebhookを発火させておくと、ひとまず全部載せのデータが取れるはずです。 通知先を取得 Zapierには処理を分岐させるPath Appがあり、これを使うと簡単に分岐処理を分岐できます。しかし、分岐上限がデフォルト5件と決まっています。上限を増やすこともできるそうですが、それよりも便利な方法があります。 あらかじめGoogle スプレッドシートやZapier Tableにコンテンツの内容と叩きたいWebhookのURLを記入しておけば、コンテンツの内容から検索して対応する行の情報を取得することができます。 こんな感じのスプレッドシートを用意して コンテンツのステータスをもとに検索するようにすれば Zapier側で該当の行を取得できます。 取得したWebhookを叩く 最後は簡単です。これもWebhook Appを使って、前のステップで取得したURLに向けてリクエストを投げるだけですね。 また、通知内容も編集できるためコンテンツの内容を含めた通知にすることも可能です。 Headerなども自由に指定できるため、単なるSlack通知以外にも、認証が必要なWebhookを叩くことができます。その際はデータを取得するWebhookをまとめたスプレッドシートなどに、認証情報の行などを追加して参照できるようにしておくと便利です。 最後に microCMSとZapierを組み合わせることで、コンテンツの更新の種類だけでなくコンテンツの内容に応じて、通知先を柔軟に変更することができます。Slackへの通知文言に更新内容を含ませるだけでも便利かもしれません。通知の作成自体がとても簡単なのも嬉しいです。今回紹介したZapも、たった3ステップでできています。 また、使いようによってはSlack通知以外にも、かなり柔軟に別のSaaSへの連携などを仕込むことができます。 一方でZapierにも限界はあり、より複雑なことや、クラウドリソースに対して何かしようとする場合はAPI Gateway + Lambdaのような構成を作る必要もあると思います。この辺りについては、事前に何がしたいかしっかり考える必要がありますが、とりあえずZapierで動くか試してみることが簡単にできることも魅力の一つだと思います。microCMS自体とても使いやすいので、日々の運用をより快適なものにするためにも、いろいろと工夫のしがいがありますね。 参考 Automate without limits | Zapier コンテンツのWebhookを設定｜microCMSドキュメント Paths – limited to 5? | Zapier Community

目次 はじめに dbt CoreのEOLバージョンサポートについて dbt Coreをアップグレードするときの推奨事項 環境について [前半] エラーの解決 [後半] 解決に至るまでのプロセス はじめに データ基盤チームの鹿野です。 データ基盤チームではソースデータのデータ変換処理、及びデータモデルの管理用途でData build toolのOSSリリース dbt Coreを利用しています。 本記事では、dbt Core 1.5へのアップグレード時に直面したエラーについて、その解決策、解決までのプロセス、そして得られた教訓を共有します。 本記事のメイン部分は前半・後半に分かれています。 前半は1〜2分で読める内容です。同様のエラーでお困りの方は、まず前半をご覧ください。 dbt CoreのEOLバージョンサポートについて dbt CoreのEOLバージョンサポートはそのマイナーバージョンのリリース日から1年間と定められています。 1 サポート期間が終了すると、セキュリティパッチとドキュメントの提供が終了します。 また新機能を利用できなくなるため、特別な理由がない限りは定期的なアップグレード対応が推奨されます。 dbt Coreをアップグレードするときの推奨事項 アップグレード対象のバージョンは、現在のマイナーバージョンから1つまたは2つの範囲内に留めること これはOSSアップグレードに限らず、変更によるリスクを最小限に抑えるため アップグレードと関係のない修正は避けること 新機能の追加や既存の挙動変更でリファクタリングしたくなっても、それは後回しにすること 環境について dbt CoreはAmazon Redshiftデータプラットフォームに接続することを前提としています。 dbt Coreバージョン dbt Redshiftアダプターバージョン 実行環境 1.4.9 1.4.1 コンテナ（Python 3.9 slimイメージベース） Github Actions ホステッドランナー（ubuntu-latest） [前半] エラーの解決 エラーの説明と補足 遭遇した複数のエラーの中から、特に解決に時間を要した1つを取り上げます。 dbt run実行中に発生したエラーで、スタックトレースは残っていないため文字情報のみです。 Connection reset by peer  見覚えのある方も多いのではないでしょうか。 これはdbt Core固有のエラーではなく、ネットワークスタック（TCPレイヤー）に起因するエラーです。 以下に補足を記載します。 調査の過程で判明したのですが、このエラーはGithub Actionsホステッドランナー環境でのみ発生していました。 どうやって解決したか？ A. 実行環境をGithub Actionsホステッドランナーからセルフホステッドランナーへ移行しました。 具体的には、Github公式が提供するubuntu-latestランナーから、EKSクラスター上のm5.largeタイプのワーカーノード上のランナー（ポッド）へ移行することで解決しました。 補足で既に答えを示唆していますが、特定環境でのみ発生する問題だと判明したため、実行環境の変更で解決を図りました。 内容を深めるため、以降のセクションで補足説明を加えます。 Github Actions セルフホステッドランナー環境について 正式名称は self-hosted runner です。 弊社では、dbtモデルを安全に本番環境へ公開するためのCIをGithub Actionsで構築していました（以降、CIワークフローと呼びます）。 CIワークフローでは、Github公式が提供するubuntu-latestランナーを使用していましたが、これを自前で用意したランナーに切り替えました。 Github Actions セルフホステッドランナーの考慮事項 セルフホステッドランナー環境の構築自体は公式ドキュメントに従えば容易ですが、運用面では以下の懸念事項を考慮する必要があります。 ランナーを実行するマシンをどうするか？ マシンのメンテナンス マシンのセキュリティ担保 Githubホステッドランナーではこれらの懸念事項はGithub側が対応してくれますが、セルフホステッドランナーは名前の通り実行環境を自己管理する必要があります。 このセクションでは結論のみ記載しますが、 Actions Runner Controller (ARC) の導入でこれらの課題を解決しました。 詳細なプロセスは後半で説明します。 [後半] 解決に至るまでのプロセス 前半は前座で、後半がメインです。 ただし、こちらは主に経緯を詳しく説明する内容となるため、文章量が多くなり、より詳細な記述となります。 ご理解いただいた方からお進みください。 以下に、解決までのプロセスを時系列順に記載します。 各ステップについて補足を加え、最後に得られた知見をまとめます。 解決までのプロセスを時系列順に列挙しました。 それぞれのセクションで補足をし、最後に気づきをまとめます。 dbt Coreを1.5にアップグレード dbt run でエラー発生 Redshiftクラスターのモニタリングデータ、およびエラーログの確認 dbt-redshiftアダプター設定の見直し RedshiftアダプターのCHANGELOG確認 類似の事象探索・調査 今後の進め方を決める Github Actions セルフホステッドランナーでCIワークフロー検証 Github Actions セルフホステッドランナー環境の選定 まとめ dbt Coreを1.5にアップグレード dbt Coreはpipでインストールをしています。 1.5へのアップグレードと書いていますが、1.8より前のバージョンでは、dbt Core自体を直接インストールするのではなく、各データベース用のアダプターをインストールすることが推奨されています。 dbt Coreは、インストールしたアダプターの依存関係として自動的にインストールされます。 pip install dbt-redshift==1.5.11 この時点では、アダプターのバージョン1.5.11をインストールしていました。 これは単に最新のパッチバージョンを見落としていたためです。 dbt run でエラー発生 Github Actionsホステッドランナー環境で実行されるCIワークフローのdbt runステップにおいて、「Connection reset by peer」エラーが発生しました。 このエラーは、実行コストの高い一部のモデルでのみ発生することが判明しました。 しかし、この段階では実行環境の違いがエラーの発生に関係しているという可能性に気づいていませんでした。 Redshiftクラスターのモニタリングデータ、およびエラーログの確認 RedshiftクラスターはサーバーレスではなくRA3インスタンスのノードで構成されています。 実行コストの高いモデルでのみエラーが発生していたため、Redshiftクラスターに負荷がかかっているのではないかと考え、モニタリングデータとエラーログを確認しました。 マシンリソース（CPU・メモリ） アクティブ接続数 クエリの同時実行数 キューに入ったクエリ数と処理されたクエリ数の統計 エラーログには特に目立った問題は見られず、接続数、同時実行数、クエリ統計のいずれもクォータには達していませんでした。 CPUの使用率は高止まりしていたため、スペックアップで解決できる可能性はありましたが、まずは他の解決方法を探ることにしました。 dbt-redshiftアダプター設定の見直し クライアント側で負荷を軽減できないかという観点からアダプター設定を見直すことにしました。 1.5で非推奨となった設定項目がいくつか見つかりましたが、これらは一旦保留としました。 threads: 8 -> 4 -> 2 connect_timeout: 30 -> None read operation timed out がIssueにあったのでここで同時対応 sslmode: prefer -> disable keepalives_idle: 非推奨となったので削除 threadsの調整により一部のモデルでは問題が解消されましたが、より処理コストの高いモデルについては依然としてエラーが発生しました。 その他のパラメータ変更では目立った効果は得られませんでした。 keepalives_idleが非推奨になっていたことが気になったため、次にアダプターにどのような変更が入ったのかを確認することにしました。 RedshiftアダプターのCHANGELOG確認 CHANGELOGを確認したところ、以下の重要な点が判明しました。 Redshiftクラスターへの接続ドライバが psycopg2 から redshift_connector に変更されていること さらに、この時点で「開発環境ではdbt runのエラーが発生していない」という重要な事実に気づきました。 類似の事象探索・調査 dbt、redshift_connector、environmentをキーワードとして、以下の情報源で類似事象を調査しました。 dbt-labs/dbt-core のIssue dbt-labs/dbt-redshift のIssue aws/amazon-redshift-python-driver のIssue dbt公式のユーザーコミュニティ 完全に一致する事象は見つかりませんでしたが、ネットワークスタックに関連すると思われるIssueをいくつか発見しました。 https://github.com/dbt-labs/dbt-redshift/issues/701 https://github.com/dbt-labs/dbt-redshift/issues/518 https://github.com/aws/amazon-redshift-python-driver/issues/212 これらのIssueから、Github ActionsやCodeBuildなどの環境で同様のエラーが報告されていることが分かりました。 いずれのケースも明確な対処策やパッチは提供されず、「Redshift Pythonドライバーには安定したネットワーク接続が必要」「実行環境に起因する問題」という結論でクローズされていました。 今後の進め方を決める 実行環境の変更で解決できる可能性が見えてきたため、次の2つの対応を進めることにしました。 アダプターのバージョンを最新（1.5.12）にアップデートする セルフホステッドランナーでCIワークフローの検証を行う 検証結果でエラーが発生しなければCIワークフローの実行環境を変更し、エラーが続く場合は別の方針を検討する パッチ適用だけでは解決できない可能性が高いと予想されましたが、可能な対応は全て試してみることにしました。 Github Actions セルフホステッドランナーでCIワークフロー検証 EC2インスタンス（Amazon Linux 2023、t3.small）にセルフホステッドランナーを構築してCIワークフローを実行したところ、エラーは発生しませんでした。 これにより、実行環境の変更を解決策として進めることを決定しました。 Github Actions セルフホステッドランナー環境の選定 セルフホステッドランナーは自己管理が必要なため、実運用開始前に運用方針とセキュリティ面について十分な検討が必要です。 マシンの運用 VMのメンテナンス 静的なVM一台の管理負担が発生 ランナーのバージョン管理、セキュリティパッチ適用、OSアップグレードなどが必要 スケーリングの課題 オートスケーリングの実装は過度な工数となるため現実的ではない 非稼働時間の扱い ワークフローの実行時間は1日のごく一部のみ ワークフローのprehook、posthookでマシンの起動・停止を制御することは技術的には可能 ワークフロー以外のタスクを組み込むとメンテナンスコストが増大するため避けたい 実行環境の構成管理 ランナーのホストマシンのランタイムやライブラリの構成管理が必要 コンテナによる環境分離は可能だが、管理負担が増加しワークフローの変更も必要となる モニタリング リソース・ログ・コストの監視が必要 セキュリティ面 マシンのライフサイクル管理 ホストマシンとランナーは、ホステッドランナー同様のクリーンな環境を維持することが望ましい（環境汚染やバックドアを防ぐため） 必要時のみ起動し、用済み後は速やかに終了する運用が望ましい 実行権限管理 ワークフロー実行時のユーザー権限を適切に制御する必要がある セットアップの利便性のために「runner ALL=NOPASSWD」などの安易な設定を行うと、環境が脆弱になるリスクがある 要件を整理してみると考慮すべき点が多岐にわたり、さらに検討漏れもありそうです。 マシンの適切な運用には相当な労力が必要となるため、できれば避けたいところです。 これらの課題を検討しながらGithub Actionsの公式ドキュメントを確認していたところ、ほとんどの課題を解決できそうなARCを発見したため、検証を経て実運用への導入を決定しました。 まとめ 今回のdbt Coreアップグレード作業から得られた教訓を以下にまとめました。 この内容が誰かの参考になれば幸いです。 アップグレード作業における基本 アップグレード作業の際は、変更点の確認と影響範囲の特定を標準プロセスとして組み込むこと また、環境ごとのアップグレードガイドラインを事前に整備することで、担当者によらず安定的なアップグレードを実現できる可能性が高まる 問題解決アプローチの改善点 詰まっている時ほど客観的な視点での状況把握が重要、そのためには意識的に「リセット」できると良い 適切な判断を導くために 公式ドキュメントや一次情報を優先的な情報源として参照すること 解決策の選択に関する考察 その場における最適解はあるが、正解はない 最適解を追求する姿勢は大切だが、過度に固執すると単なる時間の無駄になってしまうこともあるため、バランスを保つことが重要 単一の解決策にとらわれず、複数の選択肢を検討することも重要 参考資料 https://docs.getdbt.com/docs/dbt-versions/core https://docs.getdbt.com/blog/upgrade-dbt-without-fear https://docs.getdbt.com/docs/dbt-versions/core ︎

こんにちは！NIFTY engineeringブログ運用チームです！ 今年もあっという間に残りわずかとなりました。クリスマスが迫り、アドベントカレンダーの季節が到来しましたね！ ニフティグループでは毎年、アドベントカレンダーに積極的に参加しており、今年でなんと9回目の開催となります！ 日頃の知見をアウトプットする機会として、ニフティグループのエンジニアが楽しみながら成長していくことができています。 今年も皆様に新たな技術や知識をお届けできることを楽しみにしています！ アドベントカレンダーとは？ 元々はクリスマスまでの日数をカウントダウンするために使われていたカレンダーで、12月1日からはじまり、25個ある「窓」を毎日1つずつ開けて中に入っている小さなお菓子やプレゼントを楽しむものです。 このカレンダーにならい、定められたテーマに従い参加者が持ち回りで自身のブログやサイトに記事を投稿する、リレー形式のブログ執筆イベントです！ ニフティグループ アドベントカレンダー ニフティグループではフリーテーマとなっておりますので、好きに執筆してもらっています。 また、記事に関してはQiita様のアドベントカレンダーページにて登録させていただき、 公開自体はNIFTY engineeringや ニフティライフスタイル Tech Blog 、Qiitaにしていく予定です！（ニフティ、ニフティライフスタイル、セシールでそれぞれ投稿場所が異なります） ニフティグループ AdventCalendar 2024 アドベントカレンダーでは、ニフティグループのエンジニアが日頃の業務で培ったノウハウを共有していきますのでぜひチェックしてみてください！

こんにちは、新卒1年目の後藤と滝川と藤岡です！ 新人研修の一環としてニフティ2024年度新卒入社の9名がAWS JumpStart 2024 for NewGradsに参加しました！ AWS JumpStart for NewGradsとは?   新卒1年目 のエンジニアの方々を対象とした、2日間の実践的な研修プログラム。 将来的にAWS活用をリードする人材になるための第一歩をスムーズに踏み出せるようなコンテンツをというコンセプトで企画されているため、単なるAWSサービスの学習だけでなく、チームに分かれて要件に合った適切なアーキテクチャを検討・設計する経験を積む部分にフォーカスした内容。 プログラムの到達目標 一般的なリファレンスアーキテクチャを理解できる AWSのコアサービスの概要や選定基準を理解できる AWSのアーキテクチャ図を作成する流れを知る 参加するまでやること 事前学習では、システムアーキテクチャ設計の考え方とAWSの主要サービスについて動画を視聴しました。 1.Cloud for Beginners（約40分） Webサービスの基礎 2-1.AWS Skill Builder （約4時間） AWS の基本的な概念を包括的に or 2-2.Cloud for Beginners（約2時間） Webサービスの基礎（1の続き） 内容 アジェンダ AWSやアーキテクチャ設計に関する講義 チームに分かれてのWebアプリケーションのアーキテクチャ検討 ハンズオンワークショップ 実施期間 開催日時 (各回2日間) 2024 年 5 月 21 日（火）~ 22 日（水）各日 09:00 – 18:00 オンライン開催 2024 年 9 月 26 日（木）~ 27 日（金）各日 09:00 – 18:00 オンライン開催 スケジュール １日目 VPC、ECS Fargate、Application Load Balancer (ALB)、RDSを使用してToDoアプリケーションの構築 VPCの設定：ネットワーク環境を構築 ECS Fargateの設定：コンテナ化されたToDoアプリケーションのデプロイ AutoScaringの設定 ALBの設定：トラフィックの分散とルーティングの実装 RDSの設定：データベースの構築（Writerインスタンス、Readerインスタンスの作成） システムの耐障害性テスト（Taskを意図的に停止させ、システムの挙動を観察） Taskの停止：手動でTaskを終了 新しいTaskの立ち上がりを確認：システムが自動的に新しいTaskを起動 サービスの継続性を確認：アプリケーションが中断することなく稼働し続けることを確認 RDSの構成確認RDSの構成 Writerインスタンスにフェイルオーバーを行い、Readerインスタンスと入れ替わることを確認 成果 ２日目 アーキテクチャ検討 miroを使用し、まずは個人でアーキテクチャを検討していく課題です。 ECサイトの作成を目的として1日目の内容を参考にしながら各自、アーキテクチャ図を作成していきます。 そして、午後からは5人1グループずつほどに分かれ各グループでそれぞれのアーキテクチャ図を発表しました。 各グループは運営の方が決め、初対面の人同士で議論し組み合わせながらチームでひとつのアーキテクチャを完成させました。 以下それぞれ3人のチームのアーキテクチャ図です。 成果 後藤チーム 私たちのチームでは、Amazon ECRでコンテナイメージを一元管理し、Elastic Load Balancerで負荷分散を実現しました。Auto Scalingにより、スケーラブルな環境を構築しています。セキュリティ面では、VPCによるネットワーク分離とIAMを最小権限の原則に則ってアクセス制御を導入しました。さらに、AWS LambdaとAPI Gatewayを活用したサーバーレス構成を採用し、CloudWatchで監視を行っています。データ管理にはAmazon RDSを使用し、クラスタ構成にすることで高可用性を確保しました。外部API連携やCI/CDパイプラインは、AWS CodePipelineとCodeBuildを用いて自動化しています。チームメンバーのAWSの経験が浅い中、1日目や資料を確認しながらなんとか作成することができました。チームメンバー全員のAWS経験が浅かったにもかかわらず、1日目の学びと提供された資料を活用しながら、協力してアーキテクチャ図を完成させることができました。 滝川チーム 私たちのチームでは1日目で作成したToDoアプリをベースに構成図を作成していきました。 意識した点は可用性を高めること、管理の容易さの２点です。 可用性の点では、AZにリソースを分散配置、RDSの冗長化構成の導入、AutoScalingを活用した自動スケーリング機能の実装。 管理の容易さの点では、CI/CDの構築、CloudFrontを利用したコンテンツ配信の最適化、カスタマーサポート用の管理画面へのセキュアなアクセス経路の確立。 実際のAmazon ECサイトをモデルとしてイメージすることで、必要な要素を明確に把握し、効率的に作業を進めることができました。 藤岡チーム 私たちのチームでは2つの可用性ゾーン（Availability Zone 1とAvailability Zone 2）を設定することで、冗長性と高可用性を確保しつつ「Elastic Load Balancing」を中央に配置し、ユーザーからのリクエストが均等に分散されるようにしました。ロードバランサーの後ろには「Auto Scaling」機能で、需要に応じてサーバー数を自動的に増減させています。また、アプリケーションはコンテナとして実行しています。 チームメンバーで全体的にAWSの経験はそこまでなかったですが、1日目の資料を参考にしたり運営の方への質問、さらにAmazon Bedrockを活用することでなんとか形にすることができました。 感想 後藤 AWSについて、業務で少し触れた程度の経験しかありませんでした。アーキテクチャ図の作成を通じて、これまで業務で使用したことのないサービスについても知識を深めることができました。さらに、チームでリソースの必要性を議論する機会があり、実際の業務に近い形で経験を積むことができました。この研修は非常に学びの多いものでした。 滝川 AWS JumpStartでは特に可用性に重点が置かれている気がしました。具体的には、Auto ScalingやRDSのライター・リーダーインスタンス、Application Load Balancer (ALB)の重要性について学ぶことができました。クラウドを利用する上で、セキュリティは利用者自身が責任を持って管理しなければならない領域のため、今回セキュリティについて学べたことは非常に有意義でした。 藤岡 私はAWSを触ったことがある程度の状態で今回の研修に参加しました。2日間の研修の中でも主に実践課題に取り組むことで理解が深まったと感じました。アーキテクチャ検討では、正解は1つではなくチーム内でも様々な意見が出ましたが、生成AIであるBedrockをうまく活用することができチームの方向性が定まっていきました。今回の研修で、答えのないところから構築していくAWSの面白さを感じたとともに生成AIの活用の幅広さを体感できました。

こんにちは。2024年に中途入社した おおい と申します。 今回はニフティに中途入社してみて私自身が感じたことを書いてみようと思います。 ニフティという会社の雰囲気をなんとなく感じていただけると嬉しいです。 自己紹介 前職はSIerでエンジニアとして、主にJavaを使ってシステム開発業務をしておりました。 ご縁がありニフティに入社し、基幹システムグループのサービスインフラチームに配属となり、 @nifty v6サービス の申込システム担当として業務にいそしんでいます。 入社後に感じたこと そんなSIer出身の私がニフティに入社してから感じたことを3つお伝えします。 わりと自由 服装や髪型が自由であることや、社内で使用しているコミュニケーションツールでちょっとした雑談があるなど働くうえでかなり自由にさせてもらえているなあと感じました。 社内イベントも活発で、イベント時には多くの方が全力で楽しんでいる姿をよく目にします。 また業務においても裁量をもって遂行させてもらえているので、これまで未経験だった技術スタック (Python、DevContainer etc…) を使用して開発してみるといったこともできています。 思ったよりも運用業務が多い 前職ではお客さまのシステムを開発しており、そのほとんどが開発業務でした。 一方でニフティではお客さまに直接サービスを提供している会社なので、時期や所属部署などにもよりますが、日々の業務では開発に関する業務に比べると運用に関する業務のほうが多めに感じました。 ただ入社して日が浅い私にとっては、担当システムの知識を習得するのにとても助かった点だったりします。 挑戦する機会がたくさん 先に「業務においても裁量をもって遂行させてもらえる」と書いたとおり日々の業務ではもちろん、このエンジニアブログの執筆や定期的に開催されるLT大会への登壇など、挑戦することによって自分を成長させることができる機会がたくさんあると感じました。 おわりに ニフティは自由な雰囲気の中で挑戦、成長できる環境が整っています。 日々の運用業務を通じてシステムへの理解を深めながら、新しい技術にも挑戦できる。そんなバランスの取れた環境で、エンジニアとしての可能性を広げていけることを実感しています。 これからもこの環境を最大限に活かしながら、お客さまのため、ニフティの発展のために貢献していきたいと思います。

イベント概要 NIFTY Tech Talkは、ニフティ株式会社の社員が主催するトークイベントです。 本イベントでは、ニフティグループの社員が業務を通じて学んだことを発信しています！ 天気予報があなたの手元に届けられるまで   〜今日傘を持って出掛けることができるための仕組みの裏側〜 2008年に開始した@nifty天気予報がついにリニューアル。その開発のウラ側についてのテーマでお話をしました。 また、Tech Talk#22はコラボ企画となっており、ウェザーニューズ様とコラボしています。 リニューアルで使用したNext.js、Go、GraphQLでどのように開発していったのか、気象データを提供する側の仕組みなどをウェザーニューズとニフティの技術者が紹介しております。 当日見ていない方もご興味あれば是非、 アーカイブ からご視聴いただければと思います。 【10/2 (水曜日) 19:00～20:30 ハイブリッド開催】ウェザーニューズ社コラボイベント！ Next.js/Go/GraphQLで生まれ変わった@nifty天気予報 開発のウラ側を開催します！ 【LT1】天気予報があなたに届けられるまで ウェザーニューズからの登壇者によるお話しで、気象情報の収集から提供についてが主な内容です。 天気予報という身近なものでその仕組みでとても興味深いお話しでした 資料 【LT2】@nifty天気予報：フルリニューアルへの挑戦 このプロジェクトの全体像がよくわかります。体制や採用した技術などなど。 @niftyが提供する天気サービスは1997年から始まったらしく1997年入社な私としてはちょっと親近感わきます 資料 【LT3】@nifty天気予報のフロントエンドを実装するまで タイトルどおりフロントエンド開発についてです。 採用した技術の理由など、これからの開発の参考になるという方もいるのではないでしょうか。 資料 【LT4】AWS AppSyncを用いたGraphQL APIの開発について バックエンドのお話しです インフラ構築のお話しからやっているので、これからシステム構築されるような方に参考になるかもです 資料 まとめ 初の他社様とのコラボレーションとなりましたが、いままでのオフライン参加よりも多くの方に来ていただけました。質疑応答でも毎回何件か質問いただき、なかなか盛り上がったのではないかと思います。 フロントエンド、バックエンドで同じ技術を使うではなく、それぞれに適したものを検討・採用されており、工夫されて作られているのだなという感想を持ちました。 ご視聴された方々に少しでも参考になる内容であったなら幸いです。 次回予告 次回のTech Talkは2024年11月26日12:00～13:00開催を予定しております。 テーマはTerraformの入門編です アーカイブ（YouTube） 発表資料（Speaker Deck）

ねんがんの Notionフォーム がリリースされました！ プロパティの入力値をフォームのフィールドとして設定でき、フォームを好きな場所に埋め込むことも可能です。Notion AIと組み合わせれば、自由記述からのキーワード抽出ができ、さらにグラフで可視化もできます。アンケートフォームなどでの活躍が期待できますね。 Notionフォームで主にできること プロパティの入力 リレーションの選択も可能 ページ本文の入力 フィールドの入力必須化 フィールドの説明 フィールドの種類 プロパティの種類に応じて変化 フィールドのValidation 見出しやテキストの挿入 入力後の自動処理 データベースオートメーション フォームの埋め込み Notionフォームには基本的な機能はありますが、まだ完全とは言えません。 特にValidation機能がないのが個人的に困っている点。プロパティなら仕方ないと思っていましたが、フォームの形をしているとこの機能が欲しくなります。 そこで今回は、NotionフォームにValidation機能を追加できないか検証してみます。 入力時やPOST前に制限をかけることはNotion単体ではできないため、入力後に値が期待通りかチェックする方法を取ります。今回のアップデートでオートメーションのアクションに数式や変数が使えるようになったので、これを早速活用してみます。 データベースオートメーションと数式(Formula)でValidationっぽいものを作る 覚えておくべきオートメーションの仕様 トリガー → アクション * n の2ステップまで アクションはおそらく非同期で処理される アクションを実行するユーザーは Notion （ユーザープロパティ等では選択できないシステムユーザー） Notion ユーザーが実行したアクションは新たなオートメーションをトリガーしない アクションの実行有無に関する条件分岐は設定できない Slackへの通知内容はカスタマイズできない メールアドレスと文字列のprefixをチェックするサンプルフォーム フォームに入力してもらいたいフィールドを用意。 メールアドレスとSlackのチャンネル名を入力してもらい、入力規則に沿っているか確認するのが目的。 次に入力された内容が正常か確認するための Validate と Log プロパティを用意。 Validation本体はオートメーションを利用。 数式で正規表現にマッチするか調べて変数に格納。 変数の値を元に Validate と Log プロパティの値を更新、最後に入力したユーザーに通知を送信。 これで入力値が正しければ正常なメッセージの通知が行われ、間違っていれば修正を促す通知がフォーム送信者に送られる、Validationっぽいものが完成です。 ただし、この構成には課題もあります。初回フォーム送信時は問題ありませんが、編集時には文字を記入中でもトリガーが発火されるため、通知が頻繁に来てしまいます。通知はデータベースのページごとにまとめられるので、まだ許容できる範囲ではありますが、トリガーはボタンにしてもいいかもしれません。 まとめ 自力でValidationっぽいものは作れましたが、完成度がいまひとつですね。 フォームの内容に厳密性を求める場合は、まだGoogleフォームなど他のツールを使った方が良さそうです。フォーム機能の改善については、Notionにリクエストを送り実装されるのを期待して待ちましょう。 触ってみると分かりますが、最近のアップデートで表現力や柔軟性はかなり上がっています。特にオートメーションで数式や変数を使用できるのを求めていた人は多かったのではないでしょうか。この記事を読んで「今ならここまでできるのか、それならこれもできるのでは？」と新しいアイデアが湧くきっかけになったら嬉しいです。

ニフティ株式会社でエンジニアリングマネージャーをしています芦川です。 今回は、インナーソースを日本に広めるべく、InnerSource Commons Japanの運営メンバーとしての立場からも意見を書いてみたいと思います。 ニフティではここ数年間、社内にインナーソースを導入するための活動を行ってきました。 導入のきっかけや詳しい活動内容については、以下をご参照ください。 インナーソースを導入してみた その① お試し導入編 インナーソースを導入し てみた その② 土台作り編 導入後、学習を続けていく中で、社内でインナーソースが広まりやすい部分と、広まりにくい部分が見えてきたように感じます。実際の社内の結果や、今後に期待できる点も含めて書いてみたいと思いました。 ここからの話は、あくまで「こういうパターンだとインナーソースは広まりやすい」という話になります。本来、インナーソースでは社内で自由にコントリビュートできる環境を目指しています。パターンにあてはまらなくても当然個人のスキルアップやエンジニア体験の向上が期待できます。そのため、「これ以外のパターンはやらない方がいい」という制限を意図しているわけではありませんのでご注意を！ では、インナーソースが効果的に導入できるパターンについて、モデル図を作成しましたのでご紹介いたします。 効果的な導入1️⃣ みんなで便利ツールにコントリビュートしよう！ これはご想像の通りだと思いますが、出退勤や日報（弊社には日報文化があります）、コミュニケーションツールなど、業務に直接関わらないツールについて、エンジニアが自ら作成しやすく、また、作成したツールを社内に広めやすい環境があります。このようなツールに対してインナーソースは非常に効果的です。まさにOSSのように、コントリビュートが生まれやすい環境と言えるでしょう。 効果的な導入2️⃣ プラットフォームチームのリポジトリにコントリビュートしよう！ ここからは、チームトポロジーのチームタイプに基づいた例になります。 もう少し業務的な例として、プラットフォームチームのリポジトリへのコントリビュートが挙げられます。プラットフォームチームは、広範な部署からの依頼を受けることが多く、全社にわたる影響を持つこともあります。 ニフティでは、リポジトリ内での定義追加などをプルリクエストとして他チームから受けることで、依頼のワークフローが簡略化され、リードタイムが短縮されました。新機能のエンハンスや新しいAPI I/Fの提案などもっといきたいところはありますが、まだそこは道半ばではあります。 なぜプラットフォームチームだけがそうなのか、と考えた理由ですが、上の便利ツールと同じくメリットを享受できる人が、つまり利用者が単純に多くなるからです。 そもそもコントリビュートは、コントリビュートしたいモチベーション、つまり利用者自身へのメリットがあることが前提になります。 例えば、特定のストリームアラインドチームの持つリポジトリへ、プラットフォームチームのメンバーがコントリビュートするのか？そこでの業務的なメリットはなんだろうか？そのモチベーションは果たしてなんでしょうか？と考えていくと、4つのチームタイプの中ではプラットフォームへのコントリビュートが広まりやすいのでは？という話になります。 （コンプリケイテッドなシステムについて、スキルアップを目指してコントリビュートする例も、組織的な観点から見ると、おそらくその会社にとって重要な意味をもつシステムであるはずなので、そのシステムを知る人間が増えるということは会社にとってすごく大事なところです。もっと将来ではそういうところも目指していきたいです。） 効果的な導入3：ドメイン知識が似てビジネスの方向性が同じストリームアラインドチームのコラボレーション ここからは、弊社でまだ実践例が少ないものの、期待が大きいパターンになります。 コントリビュートのモチベーションが広まりやすさに大きく関係すると考えていますが、その意味では、ドメイン知識が似てビジネスの方向性が同じストリームアラインドチーム同士では、お互いにメリットが生まれることが多いと思います。 例えば、あるチームが作成したAPIを、別のストリームアラインドチームが共通のものとして利用するケースです。弊社では、郵便番号から住所を引くAPIや共通のID登録を行うAPIなどがこれに該当します。こうしたコラボレーションでは、プルリクエストを柔軟に行うことでリードタイムが短縮され、他のチームにもメリットが生まれます。 逆に、ドメインが全く異なるストリームアラインドチーム同士のコラボレーションは、両者にメリットが少なく、認知負荷の増大にもつながるため、あまり広がりそうにないのかな、と思っています。 効果的な導入4：ドキュメントへのコントリビュートを全社的に推進しよう！ 最後に、広がりが期待できるのがドキュメントへのコントリビュートです。 最近発表された「 State of InnerSource Report 2024 」でも言及されていますが、企業がインナーソースを導入する際に、ドキュメント管理は比較的ハードルが低いとされています。 documentation-as-codeが一般的な初期のInnerSourceプロジェクトタイプとして登場していること。この傾向は、組織がInnerSourceの取り組みを始める際に、実践的でハードルの低い入り口を見つけていることを示唆している。 State of InnerSource Report 2024 , P2 ただし、ニフティの場合、すべての開発ドキュメントがgitで管理されているわけではなく、主にNotionに保存されています。また、全社の人事・総務なども含めたドキュメントを対象とする場合、GitHubアカウントがエンジニアにしか配布されていないことが課題となっています。 しかし！コードとして管理されているドキュメントに限らず、「コントリビュートして互いに助け合い、良いドキュメントを作る」ことを目的とするならば、Notionのサジェスト機能を活用できるのではないかと考えています。 Notionサジェスト機能について サジェストモードでNotionページを編集すると、ページの持ち主に対して編集の提案ができ、承認されると反映されます。これは、ゆるいプルリクエストのようなもので、社内でのインナーソース活動と同義です。エンジニアに限らず誰でも使える機能であり、インナーソースの認知を広げる起爆剤としても活用できるのではないでしょうか。 以上、ニフティでもインナーソースはまだまだ促進中で、未来は明るく、これからもやれることがたくさんあると感じています。今後も導入事例や展望を発信していきます！ ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

はじめに こんにちは、ニフティ株式会社の小林です。 最近、日常業務の効率化に向けて積極的に新しい方法を探求しています。 百聞は一見に如かず 文章での説明に加えて、視覚的な例を用いて質問をさせてください。 以下、左右にあるサイトを見比べて何が異なるのかを探してみましょう。 ※ 私の友達であるmyfriendGPTを利用し、適当にコンテンツを作成しています。 　⇒ ChatGPT APIを活用したSlackbotを作成して、30分以内に会社内に有能な友達を作る １問目 質問 以下の画像でお互いに違う箇所はどこでしょうか。 答え 申し訳ありません。実は、画像の内容は同一ですが、URLのみが異なっています。 2問目 質問 以下の画像でお互いに違う箇所はどこでしょうか。今度はURLは同じとします。 答え ID部分が異なっています。 似て非なる環境が生み出す問題 上部の質問で登場した環境は非常に似ていて、開発環境と本番環境の見た目の近さが思わぬ問題を引き起こすことがあります。 以下のような問題が時折発生すると考えています。 本番環境でのデータ調査を意図していたが、開発環境で実施していた 気付くまでに不要な工数がかかってしまった 開発環境での作業を想定していたが、本番環境で実施していた 内容次第では障害に繋がるリスクがある なぜ起こるか 本問題は、システム的要因と人的要因が絡み合って発生すると考えています。 システム的要因 開発環境と本番環境の区別が不明確 視覚的な差異が少なく、誤操作のリスクが高い ログイン情報の長期保持 アカウント切り替え時の確認不足を誘発 人的要因 作業への慣れ 警戒心の低下や確認作業の省略に繋がる 疲労 注意力の低下 視覚的な認識能力の低下 小さな文字の見落とし 焦点が合わせにくくなる 対応策 このブログの本題となりますが、以上の発生に対する対応策を提示します。 本番環境のみタイトルを赤色にする ブログ用の極端な色付けのため、実際は目に優しい色でも問題ないと思います。 特定のURL/文字列に該当する場合に制御できる 気付きそうですね どう実現したか Tampermonkeyを使用 Tampermonkeyは、ウェブページのHTML要素やCSSを動的に変更できるJavaScriptコードを実行する拡張機能です。主にChromeで使用されますが、EdgeやFirefoxなど他のブラウザでも利用可能です。 以下等、他に影響を与える実行をしないこと 過剰なリクエストの送信 著作権侵害 プライバシーの侵害 マルウェアの配布 上記の通り、Tampermonkeyは要素変更以外にも多様な機能を持つため、意図しない影響を及ぼさないよう注意が必要です。HTMLやCSSの要素変更のみであれば、サーバには影響を与えないことを「開発者ツール」のNetworkから送信されていないことから確認しております。 以下に例を示しますが、より深い理解を得たい方は、「DOM」や「JavaScript」について学習することをお勧めします。 URLベースでスクリプトを変更可能 Tampermonkey内の@matchに該当のURLを含めるとURLベースで実行することが出来ます。 // ==UserScript== // @name Header Background Color Changer // ~~~ // @match http://localhost:8088/hoge.html // ~~~ // ==/UserScript== 文字列制御でスクリプトを実行可能 コード内に以下のような特定の文字列の有無で実行を制御するように変更することが出来ます。 // ページ内に特定の文字列があるかチェックする関数 function checkForTargetString() { return document.body.innerText.includes('1992TORI'); } 最後に 本番環境と開発環境の視覚的な違いについては、実装上必要な場合もありますが、一般的には両環境の見た目を同一に保つことが、運用とテストの観点から望ましいと考えています。 このような場合、Tampermonkeyなどのブラウザ拡張機能を活用し、開発者側で対応することをお勧めします。これらのツールは簡単にオン/オフを切り替えられるため、視覚的なテストにも柔軟に対応できます。 本ブログが、人ではなく仕組みで解決する方法の１つになって頂ければ幸いです。 ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

前回の記事では、ニフティのメールチームで働く社員に、業務内容やチーム環境についてインタビューを行いました。 今回はインタビューの後編をお届けします。前編はこちらの記事をご覧ください。 【前編】@niftyメールの開発チームに業務のあれこれ聞いてみた！   過去頑張ったエピソードを教えてください。 M.Sさん 冒頭に触れた基盤移行ですね。基盤移行のきっかけにもなったのですが、ニフティのメール基盤は独特な作りをしていて作った人にしかわからないような状態でした。期限が迫る中、バグを踏んで対応に追われたり色々あったなという感じです。 Y.Mさん 3月に入ったばっかりなのでまだあまりエピソードはありませんが、メールを理解するところかなと。アーキテクチャはしっかりされていながらも、理解しないと進められないところもあり、OJTではそのあたりを知る機会がなかったので勉強しながら進めています。 K.Fさん 私も基盤移行です。スケジュールが厳しくて、2週間で社内向けのメール送信システムを作らなければいけない状況もありましたが、何とか完遂しました。 休日はどう過ごしていますか？ M.Sさん 去年くらいから犬を飼い始めたので犬と遊んでいます。社交的なわんこなので、週末はドッグランに連れて行っています。 M.Sさんのわんこ K.Fさん リモート会議の時にワンちゃんの声がして癒されました。 M.Sさん 足元にじゃれついてきて鳴くので、その時の声かな？ Y.Mさん 家でのんびりしていて、ゲームをやっています。金曜に友人からゲームの誘いがあって、朝までやって、昼起きて夜はまたゲームしています。 M.Sさん 月曜は辛くないですか？笑 Y.Mさん 日曜は早めに切り上げています。笑 夜遅いながらも、朝も早めに行動していて最近8時に出社しています。朝は涼しいとマネージャーに教えてもらったので… K.Fさん 最近ビリヤードにはまってます。バッティングセンターに行ったりもして、おとといは群馬でパターゴルフをしたりしています。ゴルフ、サバゲ―にも興味が出てきて忙しいです！ M.Sさん K.Fさんが多趣味なのは知ってましたが、ゴルフは初めて聞きました。 Y.Mさん きくたびに新しい趣味が出来てる気がしますw K.Fさん 筋トレははまりすぎて日常になりました。社内のSlackの筋トレチャンネルで筋トレ情報をのやりとりをしていたりします。ブカツを通してボルダリングにも興味を持ち、プライベートで登ったりもしています。 いま楽しみなことは何ですか？ M.Sさん 来月沖縄に行くので楽しみです。2年前に行った時は台風が直撃してずっと雨だったので、今回こそは晴れてほしい。沖縄料理が好きです。 K.Fさん NIF BARというニフティ社員のためのバータイムが始まったので、お酒を飲みながらボドゲをやりたいです。 Y.Mさん 実家に帰るので、実家で焼肉を食べるのが楽しみです！ 今回はニフティのメールチームのインタビューの様子をお届けしました。ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する .is-style-rounded + .has-text-color{ font-size:95%; }

今回はメールチームへのインタビューです！   M.Sさん 2018年5月にキャリア採用で入社しました。入社から現在までメールチーム一筋です。2023年10月から体制変更に伴いメール開発サブチームのリーダーを担当しています。@nifty 安心メールパックやWebメールの開発・運用を中心に、@niftyメールを構成するシステムの面倒を幅広く見ています。仕事の後はスプラトゥーンをゆる〜くプレイしています。2023年に犬を飼い始めてから毎日溺愛しています。 K.Fさん 2020年4月に新卒で入社しました。2か月の研修を経て2020年6月に配属されました。私が配属された当初はメールチームでAWSが利用されておりませんでしたが、新規サービスを中心に積極的にAWSを導入していきました。今は@nifty 安心メールパックの開発・運用を担当しています。週末はバイクでツーリングに出かけたり、キャンプで自然を満喫しています。楽器やビリヤード、ボルダリングなど、いろんな趣味に挑戦するのが好きです。体力づくりのため、週に5日ほど筋トレに励んでいます。 Y.Mさん 2023年4月に新卒で入社しました。1年間3つのチームの業務を体験できるジョブローテーションを経て、2024年3月にメール開発チームへ配属されました。担当業務は@nifty 安心メールパックの開発・運用です。ゲームが好きで、友人とスプラなどをやります。社会人になってからはおいしいランチも趣味です ニフティメールとは何ですか？ M.Sさん ニフティメールはざっくりというとニフティの会員向けに提供しているメールサービスです。歴史が長く、パソ通時代のNIFTY-Serveから続いているニフティでも歴史のあるサービスなんです。無料で利用できる迷惑メールフィルタ、有償のメールウイルスチェック、@nifty セキュア・プライバシー for Mailなど、様々なオプションが利用できるメールサービスです。 そういえばK.FさんとY.Mさんはニフティ、ニフティメールを入社前から知っていましたか？ K.Fさん 実は全くニフティのことを知りませんでした。知らずに説明会にきてしまったのですが笑、説明会で魅力的な会社だと感じられたので入社しました。横のつながり、縦のツナガリが感じられて、透明感が高く風通しがよさそうだと感じました。なんていうかこう…まぶしく見えました。自社開発メインなのも大きかったです。 Y.Mさん 同じく私もニフティのことを知らなかったです。デイリーポータルZの会社として認識していて、興味を持って参加しました。説明会の雰囲気も良かったので入社を決めました。 M.Sさん 私はニフティが回線サービスを提供していることも知っていました。学生時代にユーザーでもあったので、ちょっとショックですね。笑 安心メールパックとは何ですか？ M.Sさん 通信端末が故障した時に修理費用を補償するサービスのことです。 （安心メールパックのサービスサイトは こちら ） 名前にメールという単語がついているんですが、メールアドレスが一つついてくるためです。（ セカンドメール と言います） 2021年3月末くらいからサービスを立上げ、1か月後の4月末にはリリースしました。かなり急ピッチでの開発となりましたが、企画からの強い要望があり、最優先で対応しました。 K.Fさん インフラ、バッチの開発を担当していたのですが、2年目でまだ経験が浅かったのですが、PythonやTerraformなど初めて触る技術で楽しく開発させていただきました。 M.Sさん AWSの環境構築はすべてK.Fさんが担当してくれました。 K.Fさん 資格勉強はしていて、AWS認定資格をいくつか取得したのですが実践は初めてでした。 Y.Mさん 急いで作られたとは仰ってましたが、アーキテクチャがしっかりしているのですごくやりやすいです。 メールシステムにはどういった技術が使われていますか？ M.Sさん Python、Terraform、AWSがメインです。 Webメールの現在のバージョンは2010年に作られていて、バックエンドがJava、Tomcatです。フロントエンドはPrototype JavaScript FrameworkやjQueryを使用しているので、Webメールをモダンな技術を使って刷新しようというプロジェクトを計画しています エンジニアが触ってて楽しい技術を採用していきます！ K.Fさん 心躍ります！ Y.Mさん わくわくが止まんないです。 メールチームのチームはどういう構成になっていますか？ M.Sさん メール開発チーム、メールDevOpsチームの2チーム体制です。もともとメールDevOpsチームが主に担当していた配送基盤をKDDIさんの基盤へ移行したのですが、現在のメールDevOpsチームはニフティに残った配送系システムの運用や認証系システムの開発・運用を主に担当しています。 メールDevOpsチームは、現在Gmailの送信者ガイドライン対応などのメール配送の重要な部分をより良くするための開発をKDDIさんと協力しながら進めています。 ※メール基盤の移行プロジェクトについてはこちらの動画をご参照ください！ 開発チーム、DevOpsチーム間のやりとりはどうしていますか？ M.Sさん 迷惑メールフィルタの案件は両チームで動かしています。毎週水曜日にメールチーム全体の定例会で話をしたり、普段からSlackでやり取りしています。 K.Fさん AWSの技術的な相談をしたりしています。コンテナ周りの知識をDevOpsチームに教えています。 M.Sさん K.Fさんは先生役なんです。 安心メールパックについては企画とのやり取りがありますね。 Y.Mさん メールチームの定例に企画の方が参加されるので、新しい企画についての話をしたりしています。 M.Sさん 今年くらいからY.Mさん、K.Fさんに企画とのやり取りは任せています。 企画とやり取りしているときに心掛けていることはありますか？ Y.Mさん システム的な話をしても伝わらないので、企画の方に歩調を合わせるようにしています。 K.Fさん 企画から要望があっても嫌な顔をしない、断らないことを心掛けて要望に応えられるように調整するように意識しています。 M.Sさん おかげで企画との関係は良好です！ 現在のチームにはどういった課題がありますか？それに対してどうやって取り組んでいますか？ M.Sさん メール開発チームとして始動したのが去年の10月で、サブチームリーダーとしての立ち回りもそこからなのでチーム運営をどうしようかという課題はありました。 スクラム、アジャイル開発のフレームワークを取り入れて日々試行錯誤しながら取り組んでいます。スクラムマスターも私が担当しています。 Y.Mさん スクラムのイベントをM.Sさんが企画してくださり、どんどん良くなってます。 K.Fさん 時間を確保してスプリントレビューやレトロスペクティブをやることで、Webメールへの理解が深まったり、アイスブレイクを通してチームのプライベートの姿を知れてチームが良くなっていく実感があります。 M.Sさん K.Fさんの話にもあったんですが、業務と人がセットになって属人的になってしまっていました。開発チームのタスクをチーム全体で見られるようにしないといけないなと考えていました。 優先的なPBIに対してフロー効率を考えてみんなで当たっていくことを目標に、プロダクト勉強会を週一でやっています。 K.Fさん Webメールの森羅万象を知りたいです！ M.Sさん 森羅万象。笑 私もWebメールの全てを理解できているわけではなく、主担当になってから5カ月くらいなので勉強しながらやっています。教える立場になってはじめて気づくこともあります！ Y.Mさん Webメールなんも分からん状態なので、安心メールパックのことをやりつつ学んでいきたいです。 後編に続きます！ 今回はニフティのメールチームのインタビューの様子をお届けしました。続きは後編の記事をご覧ください。 【後編】@niftyメールの開発チームに業務のこととプライベートの過ごし方を聞いてみた！ ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する .is-style-rounded + .has-text-color{ font-size:95%; }

概要・はじめに こんにちは。ニフティ インフラチームの西澤です。 みなさんは毎月クラウドにかかっているコストはどのように管理していますか？ ニフティでは複数のクラウドを利用しており、私の所属しているチームでは全社的なクラウドのコスト管理を行っています。 本記事では弊社で実施しているクラウドコストの管理方法についてご紹介させていただきます。   クラウドコスト管理の目的 クラウドを利用し始めた当初は、予算と実績の乖離が非常に大きかったため、一定の範囲内に抑えるための施策として取り組みが始まりました。 また、予実管理を通じてクラウド利用料の最適化を図ることも目的の一つとなっています。   主な実施内容 [1]クラウドコスト見通し額の記載 まず、各チームが利用しているアカウントについて、月ごとの見通し額を算出した上でスプレッドシートに記載してもらっています。 基本的には年度の初めに1年間分の見通し額を入力してもらいますが、変更が必要な場合は随時金額の修正が可能です。 変更の際はSlackのワークフローから申請してもらい、その内容がスプレッドシートに記録される仕組みになっています。 直接編集にしていないのは、金額の変更理由や履歴を追跡できるようにすることと、承認のフローを組み込むことが目的です。 [2]見通し額と予測額を比較してSlackへアラート通知 続いて、想定した見通し額通りの利用となっているかを確認するため、各アカウントごとにその月の予測額を毎日取得しています。 そして、記載してもらっている見通し額と予測額を比較し、定めている閾値を超えた場合はSlackチャンネルへアラートを通知します。 ※予測額の算出や取得方法は各クラウドで異なります アラート通知内容 利用者はアラートの内容に基づいて、現時点で見通し額と予測額のずれが発生している原因を確認したり、今後の見通し額の変更を実施します。 見通し額との乖離を通知することで、意図せずリソース利用に増減があることに気づいたり、見通し額の精度を向上させることを目指しています。 [3 ]実績確定後の見通し額との差額比較 次に、実績が確定し、各クラウドベンダーから請求書をもらった後の対応です。 各アカウントごとに見通し額と実績を比較し、乖離があったアカウントを抽出して利用者へ連絡します。日々見通し額のアラートを出していますが、想定外の事態やアラート確認漏れ、見通し額の申請漏れなどにより乖離が発生する可能性があります。 [4]差額が出た理由の確認 連絡を受けた利用者は差額内容を確認し、差額が出た原因や今後の対策を報告してもらっています。毎月理由は様々ですが、以下のようなものが主な例として挙げられます。 ログ量の増加 通信量やデータ転送量の変動 料金の値上げ 割引適用の期限切れ 検証に伴うリソース追加 ※利用後の停止予定を忘れてしまうなど 特にネットワークやログなどは予測が難しかったり、検証中の料金については意識しにくいことがあるため、こういった理由が多い印象です。 [5]コスト評価ミーティング コストに関する情報が出そろったら、確定した実績について各部署のリーダー向けにコストの評価ミーティングを実施しています。 確認しているのは以下のような内容で、認識の相違や課題などがないか話し合う場にもなっています。 クラウドの金額 クラウド全体および各クラウドごとの金額推移 前月と比較し、差額が大きかったアカウントの増減要因 アカウントごとの実績推移および今後の見通し額推移 見通し額との差額が出ていたアカウントの理由 さらに、各部署にこの場で課題となった情報を持ち帰り、適正化に取り組んでもらっています。このように様々な観点や立場からコストを確認し、クラウド利用部署全体で意識していくことでコスト削減につなげています。 取り組みによる効果 クラウドコスト管理の運用が始まったのは2021年からと比較的最近ではあるのですが、 年間の金額を2023年と比較すると、約25%ほど削減できたという結果になりました。 全てがこの取り組みの影響ということではなく、利用者の協力もあってのことですが、効果が金額として顕著に出てくるとやりがいがありますね！   おわりに 今回はニフティで実施しているクラウドコストの管理方法について簡単に紹介をさせて頂きました。 クラウドコストを管理することで減額の効果は出ていますが、管理を始めてから時間が経過し、クラウドの新規利用や各クラウドの割引施策などにより、アカウントごとの正確な金額の算出や予測は難しくなってきています。 また、クラウドベンダー側の仕様変更で現状の運用には即していない部分も出てきており、様々な課題が浮かび上がってきているため、システムやフローを全体的に見直すタイミングに差し掛かっていると感じています。 こういったエンハンスの取り組みに興味のある方、ぜひニフティで一緒に働いてみませんか？以下のリンクよりご応募お待ちしています！ ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

はじめに おはようございます。IWSです。 AWSを使っている人であれば一度は見たことがあるであろう Amazon CloudWatch のダッシュボード(以下ダッシュボード)。 私達のチームではコンソール画面からぽちぽち手動で作っていたのですが、今回 Terraform で1から環境を作る機会があり、ダッシュボードも Terraform を使って作ってみました。 せっかくなので備忘録がてら記事にしていこうかなと思います。 Terraform 今回使うTerraformのディレクトリ構成はこちらです。関係しないファイルなどは省略しています。 . ├── dev │ └── dashboard.tf # 各環境ごとの値をmoduleに渡す ├── modules │ └── dashboard │ ├── api.tf # 各グラフの設定 │ ├── main.tf # ダッシュボード本体の設定 │ └── variables.tf └── prod └── dashboard.tf # 各環境ごとの値をmoduleに渡す module にダッシュボードとそのグラフの設定を書き、各環境ごとの値（ECS クラスターの名前や ALB の ID など）を dev, prod 配下の dashboard.tf から渡しています ダッシュボードをつくろう Terraform でダッシュボードを作るには aws_cloudwatch_dashboard を使います。 https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/cloudwatch_dashboard resource "aws_cloudwatch_dashboard" "main" { dashboard_name = var.dashboard_name dashboard_body = jsonencode( { "start" : "-P4W", # 過去4週間 "periodOverride" : "inherit", "widgets" : [] # グラフの設定 }) } dashboard_name : ダッシュボードの名前 dashboard_body : ダッシュボードや表示するグラフを設定、JSON 形式 start , end : ダッシュボードで使用する時間範囲 periodOverride : ダッシュボードとグラフの時間範囲どちらを優先するか widgets : 表示するグラフの設定 dashboard_body の詳細はAWSのドキュメントにあります https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/APIReference/CloudWatch-Dashboard-Body-Structure.html periodOverride を inherit にしておくとグラフごとに自由に時間範囲を設定できます。 逆にすべて統一したい場合は auto にしておけばダッシュボードの時間範囲が優先されるのでそちらを設定しましょう。 グラフをつくろう グラフの設定は widgets に書きます。 例として、ECS の CPU Utilization のグラフを作るコードは以下のとおりです。 [ { "type" : "metric", "x" : 0, "y" : 0, "width" : 6, "height" : 6, "properties" : { "metrics" : [ [ "ECS/ContainerInsights", "CpuReserved", "ServiceName", "${var.api.ecs_service_name}", "ClusterName", "${var.api.ecs_cluster_name}", { "id" : "m1", "visible" : false, "stat" : "Maximum" } ], [ "ECS/ContainerInsights", "CpuUtilized", "ServiceName", "${var.api.ecs_service_name}", "ClusterName", "${var.api.ecs_cluster_name}", { "id" : "m2", "visible" : false, "stat" : "Maximum" } ], [{ "expression" : "m2/m1*100", "label" : "CPUUtilization" }] ], "period" : 300, "stat" : "Average", "region" : "ap-northeast-1", "title" : "API ECS CPUUtilization", "liveData" : false, "legend" : { "position" : "right" }, "yAxis" : { "left" : { "label" : "Percent", "showUnits" : false } } } } ] 何を設定するか上から見ていきましょうか。 x,y ではグラフをどの位置に配置するかの設定をしています。 [ { "type" : "metric", "x" : 0, "y" : 0, ... Terraformからダッシュボードを作る場合は、どこにウィジェットを配置するかを左上を (0, 0) として座標で設定することができます。デフォルトで次に使用可能な位置が使われるとあるため上から詰め込んで表示するのであればとくに気にする必要はありません。 グラフの設定については properties の metrics から設定できます。 このコードでは、 ECS/ContainerInsights から CpuReserved と CpuUtilized のグラフを取得、 expression で率を計算して表示しています。（計算に使った m1, m2 のグラフは "visible" : false, で非表示にしています） "properties" : { "metrics" : [ [ "ECS/ContainerInsights", "CpuReserved", "ServiceName", "${var.api.ecs_service_name}", "ClusterName", "${var.api.ecs_cluster_name}", { "id" : "m1", "visible" : false, "stat" : "Maximum" } ], [ "ECS/ContainerInsights", "CpuUtilized", "ServiceName", "${var.api.ecs_service_name}", "ClusterName", "${var.api.ecs_cluster_name}", { "id" : "m2", "visible" : false, "stat" : "Maximum" } ], [{ "expression" : "m2/m1*100", "label" : "CPUUtilization" }] ], ... } ちなみにこんなグラフも作れます。 しきい値を超えた場合赤く警告が出るゲージのグラフです。 レスポンスタイムのようなしきい値を超えた場合に分かりやすくして表示ほしいようなものにおすすめです。 [ [ "AWS/ApplicationELB", "TargetResponseTime", "LoadBalancer", "${var.api.load_balancer_id}", "TargetGroup", "${var.api.target_group_id}", { "id" : "m1", "visible" : true, "label" : "Average", "stat" : "Average", "color" : "#ff402e" } ], [ "AWS/ApplicationELB", "TargetResponseTime", "LoadBalancer", "${var.api.load_balancer_id}", "TargetGroup", "${var.api.target_group_id}", { "id" : "m2", "visible" : true, "label" : "p99", "stat" : "p99", "color" : "#ff402e" } ] ], "period" : 30 * 24 * 60 * 60, "view" : "gauge", "region" : "ap-northeast-1", "title" : "API ECS responseTime", "liveData" : false, "legend" : { "position" : "right" }, "yAxis" : { "left" : { "label" : "Seconds", "min" : 0, "max" : 1 } }, "annotations" : { "horizontal" : [ { "label" : "Target", "value" : 0.2, "color" : "#7bff71", "fill" : "below", } ] } "view" : "gauge", を指定することでこのグラフを作ることができます。 "color" : "#ff402e" がグラフのデフォルトの色です。なぜか赤を設定していますが理由は後述します。 ゲージの横にある小さいバーは水平注釈です。しきい値内の範囲を表しています。このグラフでは value で 0〜0.2 をしきい値内（正常値）として設定しています。 "annotations" : { "horizontal" : [ { "label" : "Target", "value" : 0.2, "color" : "#7bff71", "fill" : "below", } ] } color と fill でしきい値以下のときのグラフの色とどちらに出すかを設定しています。ここでは #7bff71 （緑色）と below を指定していますね。 "fill" : "below", でしきい値以下のときに color の色で塗りつぶすように設定しています。デフォルトは赤色、しきい値以下のときは緑に塗りつぶしてねとしているわけです。 「デフォルトは緑色、しきい値以上のときは赤色にするでもいいじゃん」となりそうなのですが、反対の above にすると水平注釈の位置が最大値側になったりと少し変に感じるのでこのようにしています。 まとめ 今回は線とゲージのグラフをお見せしました。もちろん線とゲージ以外の種類のグラフもTerraformから作ることができますのでぜひご自身の環境でも色々試してみてください！ ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

Notionを日々便利に使わせてもらっていますが、たまに感覚的に合わない挙動が行われることがあります。個人的によく遭遇するパターンについて回避策を書いていこうと思います テキストをコピペしたら1つのブロックになってしまった 回避策：Markdownで書いてから貼り付ける 回避策：Notion AIに頼む テキストをコピペしたら1つのデータベースアイテムになってしまった 回避策：Spredsheetなど表計算ソフトを中継してから貼り付ける 回避策：ブロックにしてからD&Dする 回避策：CSVとしてインポートする テキストをコピペしたら1つのブロックになってしまった 改行ごとにブロックにして欲しかったのに1つのブロックに書かれた文章になってしまうケース。 原因は貼り付けた内容がMarkdownとして認識されているからだと思います。 Markdownでは行末にスペース2つか空行を追加しないと改行だと認識されません。 通常であればスペースとして変換されるところを、ブロック内改行（Shift+Enter）にしているところを見ると、完全にMarkdownを再現しているわけではなく、Notionに合った形で変換しているのでしょう。 原因が推察できれば、おのずと回避策もわかってきます。 回避策：Markdownで書いてから貼り付ける ワンステップでできないのが歯痒いのですが、現状これが早い解決策だと思います。 エディタで行末にスペース2つ付けるだけですし（正規表現で $ に対して処理）、下書きファイルの拡張子をmdにしておけば拡張機能の設定によっては自動で付けてくれます。 貼り付ける際に内容によってはコードブロックにされてしまうので、ペーストしてスタイルを合わせる（Ctrl+Shift+V）を利用しましょう。 ちなみにSpredsheetを中継する技は今回は使えません、行ごとに水平線が差し込まれます。 回避策：Notion AIに頼む Notion AIに頼めばブロックに分けて貼り付けてくれます。 コードブロックにしたい内容も改行されてしまうのではないか、と思われるかもしれませんがちゃんと認識してコードブロックに変換してくれました。 テキストをコピペしたら1つのデータベースアイテムになってしまった 改行ごとに別アイテムにして欲しかったのに1つのデータベースアイテムのタイトルになってしまうケース。 リッチテキストエディタを採用しているツールは多々ありますが、テーブル表示のコピペ挙動はそれぞれ違っていることが多く、Notionデータベースも同じ。これに関しては挙動から回避策を探っていくしかないです。 こちらの回避策は複数あるものの、残念ながらどれもワンステップでできません。 回避策：Spredsheetなど表計算ソフトを中継してから貼り付ける 貼り付ける数が多くなければ体感一番早いのはこの方法です。 複数プロパティでもそのまま貼り付けられるので汎用性が高いです。 貼り付けたい順番とプロパティの順番が異なっていたら、一時的ビューを作るなどして貼り付けたい並びに調整しましょう。 回避策：ブロックにしてからD&Dする データベースアイテムもページ、もっと言えばブロックなので、ブロックをD&Dすればいいという理屈です。 上に書いた方法でテキストを改行ごとのブロックにした後に、データベースへD&Dすればデータベースアイテムとして扱われます。 回避策：CSVとしてインポートする 貼り付ける数も多くて、プロパティもしっかり入れたい時はCSVインポートが適切です。 データのインポート – Notion (ノーション)ヘルプセンター 1行目に書くプロパティ名を間違えると、新規プロパティとして作成されてしまうので注意が必要。 重要なデータベースにインポートしたい場合は、一度新規データベースとしてインポートしたあとに移動させるといいでしょう。 ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

こんにちは。会員システムグループでエンジニアをしている山田です。 今回はterraformの注意点について紹介します。 概要 terraform import はterraformを使っていなかった頃のリソースを取り込むためのものであり、定常運用で使うものではないという話です。 terraformで運用するならterraformだけで完結させてください。importは常用するための機能ではありません。 importの限界 importを前提とした運用には以下の問題があります import漏れ コンソールで作成したものを後からimportする、という運用では、作られたリソース全てがterraform管理下にある、という保証ができません。 コンソール上でよしなに作成されたIAM RoleやS3 Policy、Route53レコードなどを見逃してしまい、terraform管理外だから不要だと思って消したら実は必要だった、というような事態が発生します。 再現性がない 1から実行されたことのないterraformコードには再現性がありません。 例えば暗黙的な依存関係にあるInternet GWとNAT GWは resource "aws_internet_gateway" "igw" { ... } resource "aws_nat_gateway" "ngw" { ... depends_on = [aws_internet_gateway.igw] } のように depens_on を明示しないと実行に失敗しますが、importではこれに気づくことができません。 importブロックが使えないことがある terraform 1.5よりimportブロックが使えるようになりました。 これはimportの内容をtfファイルに記述できるものであり、コマンド実行前にplanができることでterraform importコマンドを使うより安全な操作が行えます。 しかしながら、AWS APIが非対称なケース、つまりPOSTで設定した内容と、GETで帰って来る内容が異なるようなリソースでは実行に失敗します。 ex) aws_lb_listener の default_action resource "aws_lb_listener" "https" { ... default_action { type = "forward" target_group_arn = aws_lb_target_group.a.arn } ... } Planning failed. Terraform encountered an error while generating this plan. ╷ │ Error: Invalid Attribute Combination │ │ Only one of "default_action[0].target_group_arn" or "default_action[0].forward" can be specified. │ default_action[0] │ │ with module.ecs_front.aws_lb_listener.https, │ on ../../modules/ecs_front/lb.tf line 41, in resource "aws_lb_listener" "https": │ 41: resource "aws_lb_listener" "https" { │ 上記例では default_action[0].target_group_arn のみを指定しようとしていますが、AWS APIのGET結果は default_action[0].target_group_arn と default_action[0].forward が両方指定された状態で返ってきてしまいます。両方指定された状態をterraform planは許容しないのでエラーとなります。 terraform importコマンドを使えばplanを実行することはないため、失敗することはなくなります。ただしimport後にchangedが出てしまうことがあります。 不要なchanged terraform importしたリソースは、 再度plan・applyすると必ずchangedが出る ものがあります。 これは主にAWS上に存在せず、tfstate上にのみ存在する値があることによって発生します。 ex) aws_ecs_service の wait_for_steady_state など、terraform自体の実行を制御するパラメータ ex) sensitive = true の設定などにより、terraform上でsensitiveとして扱うべきパラメータ これらがあるため、「importした後にchangedが出なくなるようにコードを編集すればOK」とはいきません。特に前者は tfstateを直接編集しないとapplyすらできない というケースも存在します。 import不可リソース 稀ですがimportが不可能なリソースも存在します。AWS Providerの場合はドキュメントにimportできない旨の記載があります。 ex) aws_lb_target_group_attachment これはimportができないため、applyしてみるしかありません。 (上記の場合、全く同じ設定でapplyすればエラーなく成功します) どうすればよいのか コンソール作業をやめて terraformですべて作るようにしましょう 。 一度コンソール作業を行わないとどのようなリソースを作ればよいのかわからない、という場合は以下のような手順にします。 コンソール上でお試しリソースを作り、動く状態にする このとき、リソース名は本番用とは別の名称にする 同等の構成を再現できるようにterraformコードを書き、applyする こちらのリソース名は本番相当とし、お試し用とは被らないようにする お試しリソースを手動で全削除する 動作検証を行う Terraformで0から作成できる状態を担保し、コードが信頼できる状態を保つようにしましょう。importは最後の手段です。 今回はTerraformの適切な使用方法と、Terraform inportの限界について紹介しました。 Terraformを利用する際はぜひこれらの注意点を念頭に置いて実践してみてください。 ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

はじめに こんにちは！ ニフティ株式会社、エンジニア定例運営の小林、柴田です。 ニフティでは毎年エンジニアの新人研修を先輩エンジニアが 内製 で行う文化があります（通称、 エンジニア定例 と呼ばれています）。 開催期間としては短期集中的に6月（一部5月）に実施し、準備は2か月前後で行います。 前年より資料の一般公開に取り組んでおり、今年も同様に一般公開いたします。 – 前年： ニフティ株式会社 エンジニア新人研修の内容を公開します | 2023年度版 新人研修の狙い ニフティ全体の技術力向上 以下を経験することで社内全体の技術力向上を目的とし、エンジニア定例の目指すところとしています。 体系立った基礎学習 チームでのサービス開発 短期的なサービス運用 生徒から講師による継続的運用 内製力の強化 育成強化 Webサービスを開発する上で必要なスキルを体系立てて学んでもらう スキルアップ 業務では学べない技術を積極的に取り組んでいく 今回の公開講義資料について 研修の到達目標として、「Webアプリケーションを独力で開発、クラウド上でリリースできるレベルの知識、技術力を身に付ける」を掲げており、それに伴う講義を行っています。 今年は新しく「サーバー運用入門」が追加され、「機械学習」については近年のトレンドを加味し「生成AI」に着目した内容に刷新しております。 それでは、以下公開可能な講義資料を掲示しますので、学習にお役立てください。 講義資料一覧 Git2024 AWS2024 [NEW!] サーバ運用入門2024 コンテナ2024 データベース2024 セキュリティ2024 オブジェクト指向2024 機械学習2024 Webアプリ2024 モバイルアプリ2024 ※ニフティ社内の開催日順で記載しています。 終わりに ニフティでは、長年にわたり自社開発の研修プログラムを実施しています。 このプログラムは、継続的な改善と進化を遂げており、教材の更新や新しい講座の導入、さらには前年度の新入社員が翌年には講師を務めるなど、独自の取り組みを行っています。 この制度の大きな利点は、 受講者としての経験を講師の立場で活かせること 、と感じています。 私自身、過去の受講で気づいた改善点を教材に反映できるだけでなく、講義後のフィードバックを通じて自己成長の機会を得られています。 この循環型の学習システムは、個人のスキル向上と同時に、研修プログラム全体の質の向上にも貢献しています。  弊社のエンジニア育成への取り組みや、最新の技術動向について詳しく知りたい方は、ニフティエンジニアブログをぜひご覧ください。 ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

チームの今後について 現在のチームの課題と、それに対する取り組みについてお聞かせください R.Fさん 私たちのチームが持っているシステムの数が膨大な為、知識の吸収やメンバーの作業リソースが追い付いていないのが課題ですね。さらに、レガシーなシステムも扱う中で勤続年数が５年目以下の社員しかいないのが現状です。 なので、そもそもチームでの扱う必要があるシステムなのか、維持する必要があるのか、といった前提から考えていくような提言を現場からしていけるようになっていきたいです。 お金を使ってメンバーやリソースを増やして解決したとしても、それって課題をすり替えてるだけで、後々より大きなツケを払わないといけなくなるんですよね。なので現場の課題を組織全体の課題に昇華させる必要があります。そういった現場から組織に働きかけるような取り組みをしていきたいです。 M.Mさん やっぱりレガシーシステムの刷新や取り扱いは課題として上がりますね。 R.Fさんが言っていたようにサービス数が膨大なので管理が大変ですし、言語や扱う分野もバラバラなので難しいです。全部をPythonに当てはめることは難しいので、リプレイスをする際には適切な技術選定をしていく必要もあります。 また、お客様のお金を扱うサービスでは強固なセキュリティの担保が必要なのでそういった点についても考えながら刷新に取り組んでいます。 S.Oさん M.M君と似た話ですが、チーム内にはレガシーなシステムが複数存在し、ものによってはブラックボックスになっているものもあるので、拡張や運用する際の障害になるという課題があります。 何も考えずに最新技術を取り入れるだけだと将来の負債にもなりえるため、そのシステムにあった最適な技術を取り入れていきたいです。 課題は山積みですが、今できる工数削減などを実践してチームの時間を増やす取り組みをしています。具体的には、追加機能が作られた際には都度テストの工数がかかっていたのですが、一部を自動化することで他のやりたいことに時間をさけるようにしました。 見えるところからコスト削減をしていって、課題に向き合う時間を増やしていきたいです。 休日の過ごし方について お休みの日はどんなことをされていますか？趣味やマイブームについて教えてください S.Oさん 私は旅行や音楽鑑賞ですね。 先週は金沢で海鮮料理を楽しんだり、21世紀美術館で作品に触れたりしていました。朝の散歩がてら兼六園に行って落ち着きながら回ることが出来たのも良かったです。 また、R.Fさんに影響されてアーキテクチャやクラウドに関する勉強をしています。最近はSQSやLambdaの並列化などを勉強してチームに還元できたので達成感がありました。 M.Mさん YouTube見ることがなんだかんだで多くなっています。スポーツ全般見るのが好きで、特にサッカーは一番です。最近は国立競技場でのJリーグを試合を観戦しに行きました。 自主学習では幅広く勉強しており、特にセキュリティに関する勉強をしています。ニュースを追ったり、効率的なソフトウェア管理方法を模索していたりします。 R.Fさん スクラム系であったり、組織に関する本を読んでいます。 今はニフティのN1!制度の中でアジャイルコーチを任命されているのですが、スクラムに触れた当初はスクラムのことを信じ切れていませんでした。 スクラムに限った話ではないかもしれないですが『導入すればうまくいく』みたいなことに懐疑的で、今までと違うやり方を導入していこうとしたらどこかにしわ寄せは出てしまうはずなのに、いろんな事例とかを見てもなかなかそういう話って書いてなくて、違和感を感じていました。 組織で仕事をしているので一部の人だけ楽しんでる、みたいなことは避けたくて、スクラムに関する書籍を読んだりやイベントに参加してきて学びを深めています。そのおかげで最近はスクラムへの考え方が変わってきました。 最近読んだ本の中では「ワインバーグのシステム思考法」「学習する組織」「大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法」が印象に残っています。 ニフティのN1!制度について このインタビューに関する求人情報 /ブログ記事 課金システムチームの求人情報 ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する .is-style-rounded + .has-text-color{ font-size:95%; }

自己紹介 R.Fさん ■入社年度 2020年4月 ■主担当サービス チームの業務全般 ■趣味 スクラム関連の本を読む S.Oさん ■入社年度 2021年4月 ■主担当サービス 課金系/書面発送/サービス申込サービスの開発・運用 ■趣味 旅行/音楽フェス M.Mさん ■入社年度 2021年4月 ■主担当サービス 課金系/書面発送/サービス申込サービスの開発・運用 ■趣味 動画鑑賞/サッカー観戦大河ドラマ鑑賞/囲碁 課金システムチームとは 課金システムチームとはどういったシステムを管理しているチームですか R.Fさん ニフティの回線をお客様に契約を申し込んで頂く所から、ご利用料金の請求まで様々なシステムを取扱っています。 一例ですが、回線サービスの申し込み管理システムであったり、申込サービス内容や取り扱い説明書の書面データを発送するシステム、ご利用料金の決済システムなど様々なシステムを取扱っています。 PPPoE 固定IPオプション https://csoption.nifty.com/staticip/pppoe/ @nifty MAX光 https://setsuzoku.nifty.com/max/ その中でも、皆さんはどのようなシステムを担当されていますか R.Fさん メンバー全員でチームが抱えているシステムの面倒を見れるようにしてます。 というのも、うちのチームでは古くから扱っているシステムがあってそれぞれ担当者がいたんですけど、その担当者が離れた途端にそのシステムについて理解している人がいなくなってしまうといった過去があったんです。 そういった経験から、属人化を防ぐためにチームの方針として新旧のシステム問わず知見をメンバーに共有することを徹底して、全員の経験値が平等になるようにしています。 メンバーへの知見共有はどのように行われているのですか S.Oさん 自分たちはスクラム開発を取り入れていて、全員に対して課題報告や知見共有のタイミングがあるので、そういった時間で話をしています。 加えて、一つのタスクに対してもチーム全体で関わるようにしたいのでモブプログラミングを取り入れて、複数人で作業することを意識したりしています。 M.Mさん 成果物がある程度できたところで共有会を欠かさず実施したり、議論が必要な部分では全員で話し合うことを意識しています。 タスクのチケット管理をしていて、そのチケットの中に残すべき証跡はしっかり残すようにして貰ったりしていますね。形にすべきものはしっかりドキュメント化するように各メンバーが意識するようにしています。 なんにせよ、担当している人しかわからない。属人化を防がないといけないので何かは残してね。という状況にしていますね。 R.Fさん 長く使われているシステムをアップデートするためにレポジトリを確認してみたら、コメントが何もなくてコミットメッセージが少しあるだけで意図が分からなかったりして手がかかってしまったことがあったんですよ。 目の前のタスクを早くこなすことも勿論大事ですが、５年後１０年後そのサービスを扱う人を考えてものづくりをする必要があると考えています。 業務内容について 業務で扱っている技術について教えてください M.Mさん 基本的にはバックエンド系の開発ではPython,Docker、クラウドではAWSを主に使っております。 既存システムの調査ではGo, PL/SQL, Java, C, JavaScript, Perlなどを見ますね。ちょっとした確認程度も含めて色々な技術に触れる機会があります。 S.Oさん 新しく触ったりする技術や機能は基本的にメンバー間で知識が偏らないように進めています。 最近では監視設定を導入する際に、メンバーが新機能を見つけては共有会などを開いたりしていました。 業務時間内で調査する時間を意識的に取って、メリットデメリットを共有したりなどを話し合って技術選定をしています。 R.Fさん S.O君やM.M君がよく便利な機能を見つけて提案してくれていてとても助かっています。 今まで取り扱っていたシステムは社内向けのAPIだったため、厳密な性能を求められていませんでした。そこからお客様が見るデータを取扱うように切り替わったので、監視の徹底やAPIの安定稼働をシステム的に達成するためにAWSのApplication Signalsを導入しました。 S.Oさん 新しい技術の導入は、以前の開発案件で上がった課題を基に考えることが多いですね。 M.Mさん 雑談から「ここの部分まだいけてないよね」とか共有したり、話をしていく中で「その手があったか！」みたいな気付きもあって、そこから課題の共有や発見、解決に繋がったりしています。 業務で苦労した、頑張った案件や経験はどういったものがございますか R.Fさん 私がサブチームリーダーになる前のチームは、個人の開発力でタスクをこなしていく風潮が強かったんです。なので「チームで開発を行っていく」という意識を定着させることに取り組みました。 開発に関する課題を開発力のある人が解決してくことで、仕事が回る場面も勿論ありました。そうすることで新しい技術をチームに取り入れる機会もあったんですが、全員がその技術を扱えるわけではなかったり、長い目で見た時のパフォーマンスやチームの再現性に繋がらない状況でした。 このままでは将来を見越した開発という観点で安心できないと考え、チームビルディングを考えるようになりました。 タスクの大小に関わらず『チームとしてどうすべきか』という観点で話し合い、チーム全員で仕事の進め方を決めるようにしています。個人ではなくチームとして活動する意識を日頃から持つことを意識しています。普段の声掛けやコミュニケーションや打ち合わせなどでこういったイメージを持ってもらうようにしています。 S.Oさん 私は他チームが持っていた請求系システムを刷新したことが一番記憶に残っています。レガシーなシステムだったので構造を理解するのに苦労はしましたが、請求系のドメイン知識や、PL/SQLに関する知識が付きました。 また、リプレイス先の技術選定については、前プロジェクトで似たような構成でシステム刷新したことから、同様にAWSを採用しました。 以前開発したシステムに関する課題の解決策を考えて適応することで、アーキテクチャや監視、テスト周りをより良いものに作ることができ、結果としてシステム全般に関する面でチームとして成長できたという実感があります。 M.Mさん 細かい機能追加ももちろん頑張っていますが、なんだかんだで毎年一件ぐらい新規開発案件があって、そこでは特に気合を入れて頑張っています。先ほどのS.Oさんの話にもあったように前回の開発の経験から反省を生かしてより良いシステムを作る雰囲気がありますね。 同じ様な構成のシステムであったとしても、クラウドが持つ便利な機能を新たに取り入れたり、システムごとのやりたいことを考えて構築しています。より良くできたら達成感がありますね。 最近はこういった経験から、ただ作るだけでなく運用の負担を軽くするために何が出来るかを考えられるようになってきたのでチームとして良い傾向だと感じています。 後編に続きます！ 今回はニフティの課金システムチームのインタビューの様子をお届けしました。続きは後編の記事をご覧ください。 【インタビュー】ニフティの課金系システムチームに聞く！チームの課題と余暇の過ごし方【課金システム後編】 このインタビューに関する求人情報 /ブログ記事 課金システムチームの求人情報 ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する .is-style-rounded + .has-text-color{ font-size:95%; }

はじめに こんにちは。ニフティ株式会社の添野 隼矢です。 Vitestの Browser Modeが興味深いと聞き、実際に試してみようと思い、 本ブログ記事を書くことにしました。 以下、Vitestの公式ガイドの「Getting Started」に従って、Browser Modeを試していきます。 https://vitest.dev/guide/browser/ 今回は、以下の項目でテスト環境を作成します。 テスト言語：TypeScript ブラウザプロバイダ：Playwright ブラウザ：Chromium フレームワーク：Svelte $ pnpx vitest init browser This utility will help you set up a browser testing environment. ? Choose a language for your tests › - Use arrow-keys. Return to submit. ❯ TypeScript - Use TypeScript. JavaScript Choose a language for your tests › TypeScript ? Choose a browser provider. Vitest will use its API to control the testing environment › - Use arrow-keys. Return to submit. ❯ playwright - Playwright relies on Chrome DevTools protocol. Read more: https://playwright.dev webdriverio preview Choose a browser › chromium Choose your framework › svelte Install Playwright browsers (can be done manually via 'pnpm exec playwright install')? … yes Installing packages... @vitest/browser, @testing-library/svelte, playwright, @sveltejs/vite-plugin-svelte Packages: +111 -3 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--- Progress: resolved 208, reused 164, downloaded 7, added 111, done node_modules/.pnpm/msw@2.4.1/node_modules/msw: Running postinstall script, done in 1.5s devDependencies: + @sveltejs/vite-plugin-svelte 3.1.2 + @testing-library/svelte 5.2.1 + @vitest/browser 2.0.5 + playwright 1.46.1 Done in 5s Created a config file for browser tests vitest.config.ts Added "test:browser" script to your package.json. Installing Playwright dependencies with `pnpx playwright install --with-deps`... Packages: +3 +++ Progress: resolved 3, reused 3, downloaded 0, added 3, done Downloading Chromium 128.0.6613.18 (playwright build v1129) from https://playwright.azureedge.net/builds/chromium/1129/chromium-mac-arm64.zip 138.1 MiB [====================] 100% 0.0s Chromium 128.0.6613.18 (playwright build v1129) downloaded to /Users/Library/Caches/ms-playwright/chromium-1129 Downloading FFMPEG playwright build v1009 from https://playwright.azureedge.net/builds/ffmpeg/1009/ffmpeg-mac-arm64.zip 1 MiB [====================] 100% 0.0s FFMPEG playwright build v1009 downloaded to /Users/Library/Caches/ms-playwright/ffmpeg-1009 Downloading Firefox 128.0 (playwright build v1458) from https://playwright.azureedge.net/builds/firefox/1458/firefox-mac-arm64.zip 79.6 MiB [====================] 100% 0.0s Firefox 128.0 (playwright build v1458) downloaded to /Users/Library/Caches/ms-playwright/firefox-1458 Downloading Webkit 18.0 (playwright build v2051) from https://playwright.azureedge.net/builds/webkit/2051/webkit-mac-13-arm64.zip 68.3 MiB [====================] 100% 0.0s Webkit 18.0 (playwright build v2051) downloaded to /Users/Library/Caches/ms-playwright/webkit-2051 Add "@vitest/browser/providers/playwright" to your tsconfig.json "compilerOptions.types" field to have better intellisense support. Created example test file in vitest-example/HelloWorld.test.ts You can safely delete this file once you have written your own tests. All done! Run your tests with pnpm test:browser pnpm run test:browser を実行すると、 @sveltejs/vite-plugin-svelte パッケージがES module (ESM)であるのに対し、 CommonJSのコンテキストでインポートしようとしているとエラーが出ます。 そのため、package.jsonに以下を追加します。 "type": "module" package.jsonの修正後、再度実行すると新たなエラーが発生します。 表示されたエラーは、Svelteコンポーネント内でTypeScriptを使用しているにも関わらず、 TypeScriptのプリプロセッサが設定されていないというものになります。 そのため、以下の内容のsvelte.config.jsを追加します。 import { vitePreprocess } from '@sveltejs/vite-plugin-svelte'; const config = { preprocess: vitePreprocess(), }; export default config; svelte.config.jsを追加後、再度 pnpm run test:browser を実行したところ、新たなエラーが発生しました。 表示されたエラーは、プロジェクトにSvelteパッケージが導入されていないことを示しています。 そのため、Svelteを追加します。 $ pnpm add svelte 再度実行すると、ブラウザが正常に立ち上がり、テストが正常に実行されていることを確認できました。 $ pnpm run test:browser RERUN x1 ✓ vitest-example/HelloWorld.test.ts (1) ✓ renders name Test Files 1 passed (1) Tests 1 passed (1) Start at 17:20:25 Duration 13ms PASS Waiting for file changes... press h to show help, press q to quit 次に、Vitestの動作をより深く理解するために、initで自動生成されたコードを以下のように修正してみます。 最初は何も表示されていない画面を表示し、1秒後に “Hello Vitest!” というテキストが表示されるような処理に変更 HelloWorld.svelte <script lang="ts"> export let name: string </script> <h1>Hello {name}!</h1> HelloWorld.test.ts import { expect, test } from 'vitest' import { render } from '@testing-library/svelte' import HelloWorld from './HelloWorld.svelte' test('renders name', () => { const { getByText } = render(HelloWorld, { props: { name: 'Vitest' }, }) const element = getByText('Hello Vitest!') expect(element).toBeInTheDocument() }) 修正後のコード HelloWorld.svelte <script lang="ts"> import { fade } from 'svelte/transition'; export let name: string; let visible = false; setTimeout(() => { visible = true; }, 1000); </script> {#if visible} <h1 transition:fade>Hello {name}!</h1> {/if} HelloWorld.test.ts import { expect, test } from 'vitest' import { render } from '@testing-library/svelte' import HelloWorld from './HelloWorld.svelte' test('shows greeting after delay', async () => { const { getByText } = render(HelloWorld, { props: { name: 'Vitest' } }) // 最初はHello Vitest!が表示されていないことを確認 expect(() => getByText('Hello Vitest!')).toThrow() // 遅延後にHello Vitest!が表示されることを確認 await new Promise(resolve => setTimeout(resolve, 1100)) expect(getByText('Hello Vitest!')).toBeVisible() }) テストを実行した結果、以下の動作が確認できました。 1. テスト開始直後：画面上に何も表示されない。 2. 1秒経過後：画面に “Hello Vitest!” というテキストが表示される。 上記より、以下の点が確認できました。 1. Vitestが1秒の遅延を正確に処理し、その後の状態変化を適切にテストできていること。 2. 実際のブラウザに近い環境でコンポーネントが正しくレンダリングされ、DOMの更新が適切に行われていること。 3. 意図した動作（最初は何も表示せず、1秒後に特定のテキストを表示する）が正確にテストされ、期待通りの結果が得られること。 この結果から、Vitestの Browser Modeが非同期処理を含むUIコンポーネントのテストに効果的であることが分かりました。 特に、時間に依存する動作や状態変化を伴うコンポーネントのテストにおいて、Vitestが優れた能力を発揮することが確認できました。 VitestのBrowser Modeの機能を試していく過程で、Playwrightでよく使用していたスクリーンショット機能を試してみました。 await page.screenshot({ path: 'screenshot.png' }) しかし、上記をテストコードに追加して実行したところ、 page オブジェクトでエラーが発生しました。 上記のエラーより、Vitestの環境ではPlaywrightの page オブジェクトが直接利用可能ではないことが分かりました。 まとめ VitestのBrowser Modeは、公式には執筆時点ではExperimentalの機能になります。 上記のスクリーンショットの件などもあり、Playwrightの直接的な代わりにはならなさそうですが、単純なコンポーネントテストであれば、Browser Modeも考慮にいれてよいかもしれません。 ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

はじめに N1! 制度 でスクラムエバンジェリストを担当している西野です。 8月にCTIでCo-Avtiveコーチングの研修をうけてきたのですが、スクラムマスターにかなりフィットするスキルだなと思ったのでレポートしてみたいとおもいます。 コーチングに興味を持ったきっかけ 数年前、スクラムマスターについてより深く学ぶ「アドバンスドスクラムマスター」の研修を受けた際、コーチングをやってみるワークがありました。 スクラムチームの成長を助ける方法として良さそうだと思ったので、その研修以来1on1の場を通じてメンバーにコーチングをやっています。 スクラムチームに対しコーチングを始めたころは手応えを感じていたのですが、時間が経つにつれて 「恣意的に会話誘導しているかも…」 「アドバイスをしてしまっていないか？」 「1on1を終えたメンバーに活力を与えられているのだろうか？」 といった自身のスキルの限界を感じるシーンが増えてきて、一度きちんと学びたいという気持ちが膨らんできました。 その時ふと、「コーチング研修を受けて良かった」と言っていた人がいたことを思い出し、コーチング研修に興味を持つようになりました。 なお、ニフティのN1! ではこういった研修などに使える活動予算が年間100万円（！）もあるので、その予算を使わせてもらっています。 スクラムマスターはコーチング研修をうけるべき？ これはかなり食い気味に「YES」です。 スクラムガイドにも ⾃⼰管理型で機能横断型のチームメンバーをコーチする。 組織へのスクラムの導⼊を指導・トレーニング・コーチする。 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf とコーチングへの言及があります。 ティーチング（教える）ことは学校や会社で経験していますが、自分の場合きちんとしたコーチングを受けた経験はありませんでした。 スクラムマスターに必要なスキルである「コーチング」を、頭ではなく体で覚える経験は、なかなか他の手段で代替が効かないものだと思います。 そもそもコーチングってなに？ 一般的にコーチというと、スポーツのコーチというイメージが強いと思います。 自分の場合コーチングについて学び始める前は、コーチは「プレイヤーになにかアドバイスをする人」または「練習をさせる指導者」というイメージを持っていました。 スクラムガイドにある「コーチ」や、ここでいう「コーチング」は上記とは異なります。 「アドバイスをする」「練習などの行動を指示する」のはコーチングではなくティーチングと呼ばれるスキルです。 コーチングは「気持ちを上向かせる」「相手の成長をサポートする」、要は「他者の在り方を支援」をすることに特化したスキルだと今は思っています。 （念の為、近年のスポーツのコーチは、いわゆる自己成長を促すコーチング要素が多くなっていると聞いたことを付け加えておきます） コーチング研修を受けてみてどう変わったか 研修の詳細を書くことはできないのですが、もし書けたとしても「体験しないと伝わらないな」という内容が多かったので、研修を受けて気付いたことを中心にまとめます。 話題にフォーカスして人を見ていなかったと気づけた 研修をうけて一番衝撃が大きかったことは、これまでやってたつもりの「傾聴」が全然できていなかったことでした。 傾聴のつもりで自分がやっていたのは、「相手の話の内容をちゃんと理解して、次に何の質問をしようか一生懸命考えている」という状態でした。 相手の会話にどう切り込もうか考え込んでいるうちに、相手が何の話をしているかわからなくなってしまうことは普段の経験でもあるのではないでしょうか。 話の内容を深く理解することと、相手を知ることは必ずしもイコールではありません。 ほかに、メモをとりながら1on1をしていたことも、話の内容ばかりに目を向けてしまって相手を見ないことに繋がってしまっていたかもと思うようになりました。 相手の表情や声のトーン、体の動きをよく観察することも含めて傾聴です。 今までの1on1の場で、相手に意識がむいていない瞬間がどれほど多かったか気付かされました。 コーチングは異空間 「傾聴」をはじめとして、普段の会話とコーチングの対話には大きな差があります。日常会話ではまずしないな、と思うような質問をあえてすることが相手の新たな気づきに繋がります。 コーチングを日常の会話と同じ流れでやってしまうと、相談会や愚痴の発散で終わってしまいがちです。 「ここはコーチングの場だ」という違いを、コーチだけでなくコーチをうける側（クライアント）にも強く意識してもらう必要があります。 実際、研修の理解を深めるためにコーチングをやってみたときに、コーチングの場であることをクライアントが意識できず失敗してしまったことがあります。 練習として家族にコーチングをしてみたのですが、「コーチングの練習をしたい」としか伝えておらず、コーチングとは何か、この場をどうしていきたいかという前提の会話をしなかったために「何回も同じような質問をされて嫌な気持ちになった」というフィードバックをもらってしまいました。 家族間なので正直にフィードバックがもらえてまだよかったのですが、今までチームメンバーに対してこういうコーチングをしていたのかもしれないと思うと怖くなります。 効果的にコーチングを行うための聞き方や質問の仕方は日常会話とはかなりかけ離れています。研修中、飛躍した提案や、考えたこともないようなことを聞かれてクライアントとしてドキッとするシーンもありました。 研修を受けてみると、その「ドキッとする」気持ちは自分が思い悩むだけでは出ない答えに繋がることが体験できます。 一人で考えていると、どうしても思考の範囲が狭くなってしまいます。一見突拍子もなく感じる質問が、それを打破するきっかけになるのです。 このように「相手をドキッとさせるかもしれない」ような質問をする場でもあるので、受ける側とどんな場をつくっていくのかを擦り合わせないと、場が成立しないばかりか、ストレスを感じる方向に働いてしまう可能性があることにも気づけました。 スクラムマスターとしてどうコーチングを行うか 最後に、コーチングの研修をうけてみて自分がスクラムマスターとしてチームに接する上で変えようと思ったことを挙げていきます。 自律には「自分の価値観」が必要 スクラムマスター同士で集まると「どうやったらチームの自律を促せるのか」という話題があがることが過去何回かありました。 自律を養うためには「自分で決定、行動すること」を繰り返す必要があると思っていますが、そもそも決定することが苦手という人もいるでしょう。 決定は得意という人でも、決めたことを必ずやり切れる人は滅多にいません。 人が意志決定する重要なファクターとして、自分の「価値観」があります。 どれだけ世の中的に良いとされていても、自分にとって価値があると思えないことを無理に決定してしまうと、モチベーション持てずにやりきることができません。 仕事における「自分の価値観」が見つかるようチームをサポートする 仕事のフレームワークはさまざまにありますが、スクラムは「価値観」に言及していることが特徴的だと思います。 スクラムがうまく機能していないときは、スクラムにおける価値基準と、その人の仕事の価値観を照らし合わせることをしていないのではないか、と気づきました。 しかし、働くうえで何を大事にしているかをぱっと答えられる人はそれほど多くはないでしょう。自分も改めて考えると言語化が難しいです。 スクラムの価値基準は「確約」「集中」「公開」「尊敬」「勇気」ですが、その価値はわかりつつも、チームメンバーの価値観がスクラムの価値基準とどの程度マッチしているのか、あまり向き合ってこなかったと思います。 スクラムマスターとして、まずチームメンバーそれぞれが「自分の価値観」が見つけられるようサポートする必要があるのではないか？と思い至りました。その手段としてコーチングがあります。 「自分自身」に向き合うことは、多くの人が無意識に避けている部分です。 コーチングの時間を持つことで、意図的に「自分」や「自分の価値観」に向き合ってもらうことができます。 スクラムマスターは、そのときコーチとして「自分」に向き合うことの抵抗感をやわらげ、自分自身と向き合うことから逃げないように導くことで、指示以外の方法でその人の行動を変容させることができるのではないかと思えるようになりました。 過去ではなく未来に目を向けさせる 研修前にコーチングを意識して指示ではなく質問をするよう心がけていた時期もありますが、「なんでこのアクションになったの？」「なんでこの決定になったの？」という「WHY」の問いかけをしてしまうことがありました。 これは質問される方はもちろん、質問をする側も息苦しく、これを繰り返しても安心できるチームになりそうなイメージがわきませんでした。 今なら、この問いが効果的でない理由がわかります。未来に焦点を当てた問いかけではないからです。 もし同じことを問うなら「このアクションをすることで、何を得たい？」「この決定をすることはこの先どんな影響がある？」というような質問に変えると思います。 スクラムマスターとして、変えられない過去に焦点を向けるより、変えられる未来の行動に焦点をあわせてもらうほうが、よりスクラムチームの成長をサポートしやすいからです。 自分に向き合い、変化し、成長するために 私はコーチングの研修をうけてみて「スクラムチームが無意識のうちに逃げていることに対面させ、行動の変容を促し、成長を導く」ということにもっとチャレンジしたいと思うようになりました。 コーチングを通じてチームメンバーが自身の価値観を見つけ、自律的に行動できるようサポートすることは、スクラムチーム全体の成長に繋がります。 もうひとつ重要な気づきがあります。スクラムマスター自身が肉体的・精神的に元気で前を向ける状態にないとコーチは難しいということです。 自分のことでいっぱいいっぱいのときは、他人に目を向けられません。他人をみれないときは、スクラムマスターとして十全には振る舞えません。 チームメンバーが価値観に向き合うよう促すと同時に、スクラムマスターである自分自身の価値観にも向き合っていく必要性を感じています。 この自分自身と向き合う手段として、外部のコーチをつけてみるという選択肢があることを知れたのもよかったです。 さいごに コーチングの基礎研修を受けた後のアクションとして、コーチングの学習・実践をより深めていく方向もあったのですが、今はまず自分の価値観を知る方向でアプローチしていこうと考えています。 誰の人生においても、自分とどう向き合って生きていくかは大きな課題として立ち塞がります。 スクラムマスターは、スクラムチームや組織など外側に目を向けている時間が長いです。そんな中で、スクラムチームや組織の中に自分がいることを忘れていた気がします。 コーチングの学習を通じて、他者の成長を促すだけでなく、スクラムマスターである自分自身と正しく向き合おうという視点が持てたことは大きな変化でした。 記事の最初に「スクラムマスターはコーチングの研修を受けるべき」と書きましたが、これはチームのためだけでなく、スクラムマスターの自己管理のためでもあります。 スクラムマスターが成長する一つの手段として、コーチングの研修を受けてみるのはかなり効果的だと思いました。 今は、社内にコーチ制度を導入するために、コーチングに興味がある人を集めてコーチングの価値を広められるよう頑張っています。なにか実を結んだら、この取り組みも記事にしたいと思います。お楽しみに！ ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する