参加登録はこちらから (connpass)7月 30 AWS GameDay入賞者が語るAWS Summit JapanとGameDayでの学びとは？ イベント概要 NIFTY Tech Talkは、ニフティ株式会社の社員が主催するトークイベントです。 本イベントでは、ニフティグループの社員が業務を通じて学んだことを発信しています！ テーマ 2024年6月20日、21日にAWS社の大規模イベント AWS Summit Japan 2024 が開催されました。AWS Summit Japan（以前はTokyo）には毎年ニフティのエンジニアが多く参加しています。 NIFTY Tech Talk #20では、AWS Summit Japan内で行われた実践的なチーム学習演習イベントであるAWS GameDayの入賞チームメンバーから、AWS GameDayの楽しさや学び、あるいは攻略法について語ってもらいます。 ご参考 AWS GameDay @ AWS Summit Japan 2024 結果発表！！ ※ AWS GameDayはその性質上内容のネタバレは厳禁とされてますため、ネタバレを避けた範囲でのトークとなります。ご承知おきください 開催概要 ※オンライン配信のみです 日程：7月30日（火）12:00〜13:00 YouTube Liveで配信 こんな方におすすめ AWS GameDayに興味があるが参加したことがない方 AWSを使っているがAWS Summit Japanに参加したことがまだない方 参加したことはあるが、楽しみ方をより知りたいという方 タイムテーブル 時間 コンテンツ 12:00 – 12:10 オープニング 12:10 – 12:50 対談セッション： AWS GameDay参加による学びと120％楽しむためには 12:50 – 13:00 クロージング 登壇者プロフィール @rubihiko (浅見 則彦)（登壇者） ニフティ株式会社　会員システムグループ / N1! SRE Web系のサービスの開発・運用。社内でSREを広める活動しています。 いかりがわ（登壇者） ニフティ株式会社 会員システムグループ 第１開発チーム 新卒4年目。ニフティのポータルサイトの開発運用を担当しています。 普段はNext.jsやGoをCopilotさんと一緒に書いてます。 ニフティグループでは一緒に働く仲間を募集中です 新卒採用、キャリア採用を実施しています。ぜひ リクルートサイト をご覧ください。 ニフティエンジニアが業務で学んだことやイベント情報を エンジニアブログ にて発信しています！ ニフティエンジニアのX(旧Twitter)アカウント NIFTY Tech Talkのことや、ニフティのエンジニアの活動を発信していきます。 Tweets by NIFTYDevelopers アンチハラスメントポリシー 私たちは下記のような事柄に関わらずすべての参加者にとって安全で歓迎されるような場を作ることに努めます。 社会的あるいは法的な性、性自認、性表現（外見の性）、性指向 年齢、障がい、容姿、体格 人種、民族、宗教（無宗教を含む） 技術の選択 そして下記のようなハラスメント行為をいかなる形であっても決して許容しません。 不適切な画像、動画、録音の再生（性的な画像など） 発表や他のイベントに対する妨害行為 これらに限らない性的嫌がらせ 登壇者、主催スタッフもこのポリシーの対象となります。 ハラスメント行為をやめるように指示された場合、直ちに従うことが求められます。ルールを守らない参加者は、主催者の判断により、退場処分や今後のイベントに聴講者、登壇者、スタッフとして関わることを禁止します。 もしハラスメントを受けていると感じたり、他の誰かがハラスメントされていることに気がついた場合、または他に何かお困りのことがあれば、すぐにご連絡ください。 ※本文章は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/ ) で公開されています。

こんにちは、NIFTY engineering編集部です。 ニフティのエンジニアが InnerSource Gathering Tokyo 2024 というイベントに運営として参加すると聞き、InnerSourceという言葉も知らなかった編集部員はエンジニアたちにインタビューしてInnerSourceとはなにか、なぜInnerSourceに取り組んでイベントの運営に参加したのかを聞いてみました！ InnerSource（インナーソース）とはなにか ――そもそもInnerSourceとはなんでしょうか？私もIT業界にいた人間ですが、恥ずかしながら初めて聞いた言葉でした。 芦川 InnerSourceの定義は、「組織という限られた環境において、ソフトウェア開発におけるオープンソースの原則とプラクティスを活用すること」です。 簡単に言ってしまうと壁がありがちな部門間の開発のコラボレーションを促進し、また、エンジニア自体が開発する楽しさを享受し、称賛しあう社内の文化形成までを含んでいます。浸透していくと、専門知識やアイデアが部門の枠を超えて共有され、プロダクトの質や開発リードタイムの減少によりプロダクト成長のスピードが向上します。さらに、開発者は楽しさ以外に他のプロジェクトに参加することで新たなドメイン知識、テックスキルを習得し、自己成長を実現できます。 具体的な導入方法については、 InnerSource Commons （インナーソースの実践者の世界最大のコミュニティ） にノウハウが溜まっています。 ニフティ内でのInnerSourceへの取り組みと楽しさ ――どんなきっかけがあってニフティ内でInnerSourceを始めることになったのでしょうか？ 小松 最初に導入した経緯は、いわゆるプラットフォームチームで管理しているプロダクトへの開発が集中してしまうと、スピードのボトルネックになってしまうな、という未来の懸念があって、なにかいい方法はないかと調べていったところ、インナーソース、というワードを知ったのがきっかけです。取り組み自体のプロセスについては、以下の記事が詳しいです。 NIFTY engineering – ニフティ株式会社のエンジニアたちのいまを伝えます#インナーソースを導入してみた その① お試し導入編 – NIFTY engineering ​ NIFTY engineering – ニフティ株式会社のエンジニアたちのいまを伝えますインナーソースを導入してみた その② 土台作り編 – NIFTY engineering ​ ――社内のInnerSource活動を運営・推進されているわけですが、どんなところに楽しみや充実感があるのでしょうか？ 日本でも実践例が少ないため、やっている感があります。今後も取り組みをどんどん発信していき、１つのユースケースとして広めていきたいと思います。そして、他の方が導入に悩んでいるところの解消の一助に、果ては日本企業の中での開発者体験の向上、サイロ化の解消への一助になりたいと考えています InnerSource Commons Japanコミュニティにも参加してます。他社の方とふれあい、お互いの悩みやアドバイスが共有でき、とにかく楽しいです。スクラムマスターやテックリード、部長クラスの方など「組織を変えたい」と強く思っている方が多く、かつエンジニアとしてのレベルが超絶高いのでとても刺激的で勉強になります InnerSource Gathering Tokyo 2024とはなにか ――今回、運営スタッフとして参加しているイベントが来月開催されるとのことですが、どんなイベントなのでしょうか？ 芦川 組織の未来を切り拓く鍵が探せるイベントです。 InnerSource Gathering 自体は世界各地で行われてますが、日本で行われたことはありませんでした。 今回の InnerSource Gathering は日本初開催となります。 各登壇者の方からインナーソースの文化をどう企業に広めたのか、その取り組みの紹介やお楽しみ企画、懇親会などのコンテンツもあります！ ニフティのエンジニアの小松も登壇いたします。 運営参加の理由 ――イベントの運営、それも日本で初開催となるとなかなか大変だと思うのですが、運営に参加しようと思ったのはなぜでしょう？ 小松 冒頭にあった、 インナーソースを導入してみた その① お試し導入編 の記事をInnerSource Commons Vice Presidentの服部さんに拾っていただき、途中、 Commonsでの登壇 もしながら、コミュニティの方へ積極的に参加するようになっていきました。その中で、今度日本初のInnserSourceイベントをやるんですがどうですか？というお声がけを頂き、超面白そう！ということで運営参加させていただくことになりました。 ーー イベント運営に参加する楽しさを教えてください！ 登壇者の選定からできることになり、各有名エンジニアと直接お話できるところとか貴重な体験をさせていただいています 社外コミュニティに参加＆イベント運営自体がはじめてだったので最初は不安でしたが、コミュニティのタスク（サムネイル作成ツイート文面作成など）をやるうちに、だんだんとこうしたらいいんじゃないかみたいな自我を出せるようになってきました。自分がよいとおもってやったことを称賛されるのはうれしいし、楽しいですね！ サイト作成で協力させていただいたりもしていますが、イベント内容が固まっていくのに従ってサイトの内容も拡充されていくので、進み具合を目で感じられるのも新鮮な感覚でした イベントの見どころ ーー試行錯誤しながらもモチベーション高くイベント運営を進めているようですね。そんなInnerSource Gathering Tokyo 2024の見どころを教えてください 田澤 まずは、登壇者の方々が超絶豪華になります。 InnerSource CommonsのファウンダーであるDanese Cooperさんのビデオメッセージからはじまり、「世界一流エンジニアの思考法」著者 牛尾さんによる組織内で感謝を含めたフィードバックをし合うメンタルモデル・組織文化の醸成、「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」訳者 ryuzeesさんによるチームトポロジーとインナーソースの関係の深堀り、スポンサーセッションとしては、The Linux Foundation 日本代表 福安さんによる組織間コラボレーションを通して価値を創出する上でのキーポイントを具体的実例や手法など紹介いただきます。また、各社様からはインナーソーシング活動の実際の具体例をいただき、これからインナーソースを導入しようとしている企業様、また導入したが文化の醸成までは至っていない企業様へのヒントとなること間違いなしです。 中盤の休憩では、日本におけるインナーソースの認知を広めようと、現在、コミュニティの方で作っている歌を紹介するコーナーがありますので、こちらも乞うご期待！（先日も歌詞作りなどに参加させていただいて、これはこれでものすごい楽しいです。） 後半はインナーソースにおける悩み共有の場、もっと深く話せる場として、OST(Open Space Technology)を企画しています。 イベントはリアル開催のみですでに定員に達しておりますが、後日、セッションについては動画公開予定ですのでお楽しみに！ （※ InnerSource Gathering Tokyo 2024のイベント詳細は connpassのページ をご覧ください） 読者のみなさまへ @InnerSourceJP をぜひフォローしてみてください。InnerSource Gathering Tokyo 2024を含めたInnerSource Commons Japanコミュニティの活動の様子がわかります。 また @NIFTYDevelopers では、ニフティのエンジニアによる技術記事やイベント情報を発信していますので、こちらもフォローお願いいたします。 ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

はじめに こんにちは！NIFTY Engineering運営のいかりがわです！ 今回はニフティのエンジニアに色々アンケートを取ってみたので紹介します！ 以前開催されたNIFTY Tech Day 2023にて、実際に現場で活躍しているエンジニアからアンケートを取る企画を実施したので、改めてブログで紹介させていただきます！ 今回は全エンジニアおよそ150名のうち、64名の方に回答いただきました。回答ありがとうございます！ 基本情報 まずは基本情報についてです。 在籍年数は？ 在籍年数はこんな感じになりました。 ニフティは昔からある会社ではありますが、在籍年数を聞いてみると在籍年数が比較的浅い人が多いですね！ おそらく新卒採用の方々でしょうか？ 毎年10人程度エンジニアを採用しているので若手社員も毎年増えています！ 採用形態は？ 採用形態についてです。 先ほど新卒採用でエンジニアを採用していると説明しましたが、キャリア採用も年々増えています！ 休日は何をしていますか？ 休日はゲームや動画鑑賞をしている方が多いですね！ 筋トレ、ウォーキングなど運動をしている方々もいます。 エンジニアはデスクワークで運動不足になりがちなので、健康に気を遣っている方は多いように感じます！ プログラミング言語・クラウドサービスについて 業務でよく使う言語は？ 表で表すとこんな感じです！ 順位 言語 % 1 Python 29.5 2 ShellScript 17.4 3 Java 11.4 4 JavaScript 9.4 5 TypeScript 8.1 とても面白い結果になりましたね！ 最も多く使用されている言語はPythonで、29.5%を占めています。 Pythonは汎用性や書きやすさから世界的に人気な言語ですが、社内でも人気な言語となっています！ 次の項目で紹介する好きな言語でも1位となっています！ 続いてShellScriptが17.4%と高い割合を示しています。 サーバーの運用やタスク自動化などでは必ず必要となってきますので、重要な言語だと思います！ Javaは11.4%で3番目に多く使用されていますね！ ニフティのサービスの基盤となるシステムで動いている言語にJavaは多く使われている印象を受けますね。 JavaScriptとTypeScriptは合わせると17.5%です！ 特にTypeScript（8.1%）の採用が進んでいるので、社内のフロントエンド界隈でも型安全性を重視する傾向になってきていますね。 その他、Go言語（5.4%）やGoogle Apps Script（GAS、4.7%）、Ruby（2.7%）なども使用されており、さまざまな言語を現場のエンジニアが採用することができます！ ニフティのエンジニアは、自分自身でさまざまな言語やツールを柔軟に活用して日々開発しています！ 好きな言語は？ やはりPythonが圧倒的な人気を誇っています！ 業務での使用率（29.5%）をさらに上回る32.4%のエンジニアがPythonを好んでいます。 やっぱりPythonは書きやすいですよね〜。私も最初に自分から勉強した言語はPythonでした。 初心者でも扱いやすく、とても書きやすい言語だと思います！ 2位のGoは業務での使用率（5.4%）を大きく上回る11.7%となっています！ パフォーマンスの高さや並行処理の扱いやすさが魅力的ですよね。 現在の業務での使用頻度は部署によりますが、全社的には広く普及していない印象ですが、今後増える可能性はありそうですね！ 3位のShellScriptは業務での使用率（17.4%）よりは低いものの、高い人気を保っています。 日々の業務で欠かせないツールとして、多くのエンジニアに愛されているんだと思います！ TypeScriptは4位にランクインし、JavaScriptよりも高いです！ 型安全性を重視する傾向が好みにも表れていますね。 私が所属しているチームのみでの話になりますが、本番環境で動いている主要なフロントエンドのシステムはほぼ全てTypeScriptで記述していますね。 Javaは5位となり、業務での使用率（11.4%）よりもやや低い結果となりました。 しかし、多くのエンジニアに支持されている言語であることに変わりはないと感じています！ 最新のトレンドにも敏感なエンジニアが比較的多く、最近だと Rust勉強会 が開催されていました！ この結果から、ニフティのエンジニアは業務で使用する言語に留まらず、幅広い言語や技術に興味を持ち、常に新しいことにチャレンジする姿勢を持っていることがうかがえます！ 業務でよく使うクラウドサービスは？ AWSが圧倒的な支持を得ていることがわかります。73.4%のエンジニアが業務でAWSを利用しています！ アンケート結果にはないですが、最近だとAWSに限らず、AzureやGoogle Cloudも積極的に使っていこうという動きが出てきています。 ニフティのエンジニアたちは、最新のクラウド技術を積極的に活用しつつ、幅広い開発に取り組んでいます！ 今後は、AWS一強から、より多様なクラウドサービスを使いこなすマルチクラウド環境へと移行していきます。 クラウド技術の進化に合わせて、エンジニアたちのスキルセットがどのように変化していくのか、そしてそれがニフティのサービスにどのような影響を与えていくのか、非常に楽しみですね！ ニフティについて 最後に、ニフティについてです。 ニフティの良いところは？ 社員の人柄や雰囲気が良いと言っている方が1/4近くいますね！ 次にワークライフバランスや、成長できる環境が続いています。 このアンケート結果から、ニフティは従業員の快適な職場環境と個人の成長を重視している環境であると言えますね！ ニフティのエンジニアの強みは？ 続いてエンジニアの強みです。 先ほど、社員の人柄が良いとありましたが、こちらでも優しさや思いやりが上位に来ています。 また、チャレンジ精神、熱心さも上位です。 成長できる環境であるからこそ、いろいろなことにチャレンジをすることができると思っています。また、チャレンジの一環でどんどんアウトプットしていくことで、チャレンジしたい人が自然と集まってくる。良い循環が生まれているような気がします！ 終わりに 今回はNIFTY Tech Day 2023にて実施したアンケートを紹介させていただきました。 この機会にニフティのエンジニアについてより知っていただければ幸いです！ ありがとうございました！ ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

この記事は、リレーブログ企画「24新卒リレーブログ」の記事です。 はじめに こんにちは。はじめまして新卒1年目の藤岡です。 これから24新卒リレーブログをしていきます！ そんな私は現在ジョブローテ第一期にてISPオペレーションサブチームに配属され未知の情報の荒波にもまれています。 今回はRcloneでローカルPCからAWS S3にファイルを転送しようとした際にアクセス権限の付与で苦しんだお話をしていこうと思います。 やろうとしていること rcloneでローカルPCからs3にアクセス サーバー内のファイルをs3バケットにアップロード s3バケットにあるファイルを読み取る したいことだけ見ると詰まるところがなさそうに思えます。 ということで早速ネットで同じことをしている人がいないか調べていきます。 Rcloneでs3をローカルPCにマウントしてみる | DevelopersIO RCloneでAW3 S3 バケットにファイル転送してみた 「rclone s3」と検索したところ、もう組み合わせるだけでいけそうな記事がありました。 早速記事通りに作業を進めていきます。 IAMユーザー しばらく進めるとrclone configの設定で IAMユーザー の「アクセスキー」、「シークレットキー」の入力が求められます。 「IAMユーザーってなんぞや」 AWS初心者の私はこうなるわけです。調べましょう。 IAM（アイエム）ユーザーは、AWSのIdentity and Access Management（アイデンティティとアクセス管理）の機能の一つです。IAMユーザーは、AWSリソースへのアクセスや操作を行うために使用されるアカウントです。 引用： https://zenn.dev/sudoukky/articles/b418490a38fdc6 なるほどAWSのリソースにアクセスするためにそれ専用のアカウントを作成しなければならないということですね。 ということでIAMユーザーを作成していきます。 が、作成しようとすると 許可のオプション という設定を求められます。 「許可ってなんや、ポリシーってなんや」 また出ました。調べましょう。 IAM でのポリシーとアクセス許可 AWS でのアクセスを管理するには、ポリシーを作成し、IAM アイデンティティ (ユーザー、ユーザーのグループ、ロール) または AWS リソースにアタッチします。ポリシーは AWS のオブジェクトであり、アイデンティティやリソースに関連付けて、これらのアクセス許可を定義します。AWS は、IAM プリンシパル (ユーザーまたはロール) によってリクエストが行われると、それらのポリシーを評価します。ポリシーでの権限により、リクエストが許可されるか拒否されるかが決まります。 引用： https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies.html なるほどリソースにアクセスするためのアカウントが「何に対して、何ができるか」とかの権限ということですね。 「何ができるか」については全てActionとして指定することで権限を付与することができるそうです。 では今回はs3のバケットに対してファイルのアップロードと読み取りをできるようにすればいいので PutObject と GetObject の2つ付与すればいけそうです。 ということでポリシーを作成してユーザーにアタッチ。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::バケット名/*", "arn:aws:s3:::作成したバケット名/フォルダ名/*" ] } ] } これで無事にIAMユーザーが作成できました。 そして肝心のアクセスキーとシークレットキーもユーザーページから発行できました。 ついに上の記事の作業が進みます。 その後は特に詰まることなくrcloneでローカルPCからs3にアクセスする設定が完了しました。 いざ rclone copy コマンド実行！ rclone copy C:\Users\xxxxx\xxxxx\xxxxx s3:作成したバケット名/フォルダ名 #実行結果 2024/xx/xx xx:xx:xx Failed to copy: Forbidden: Forbidden status code: 403, request id: xxxxxxxxxxxxxxxx, host id: xxxxAVBHF/hihccgvXxxxxxxFTFZOh/xx-GUKLvxxxxxxxxxxxxxxxxx 「 Forbidden 」 アクセス拒否！？どこが間違ってるんや。と思いながら記事を見直すもどこも間違っているようには見えません。 どうやらアクセス権限がないと言われているようです。 PutObject GetObject 以外にも必要なアクションがあるということですね。 最小権限の原則 他にどんなアクションがあるのか調べ中、「すべてのアクションの許可を付与する」みたいなフルアクセスというものがあるじゃないですか。 早速ポリシーをs3に対するフルアクセスに変えて実行。 そりゃできます。 最初からフルアクセスにしとけばよかったんや。なんて考えているとトレーナーの方から 「最小権限の原則というものがあってね」 セキュリティの観点から権限というものは必要なもの以外は付与しないことが望ましいというものらしい。そうしないと万が一アカウントが乗っ取られたりしたときに内部から侵略されてしまう。 ということで今回の処理における最小権限はどれなのかの調査が始まりました。 しかし、どれだけ調べても出てくるのは 「ファイルの書き込みに必要な権限は PutObject 、読み取りに必要なのは GetObject 。」 それに加えてs3に対するアクションの総数がまあまあな数あります。とてもじゃないですが1つ1つどんなアクションなのか調べるのは無理があります。 頭を抱えながら調べていると「 AWS Cloud Trail 」というサービスの存在を見つけました。 Cloud Trail ログインなどのユーザアクティビティとAPI操作をログに記録するサービスです。AWS CloudTrailを利用することで、AWSアカウントのガバナンス、コンプライアンス、リスク監査などを行うことができます。そのため「いつ」「誰が」「何を」したのかをすぐさま確認することが可能です。 引用： https://www.skyarch.net/column/aws-cloudtrail/ これでフルアクセスの時にs3に対してどんなアクションを起こしているのか調べれば足りないアクションが分かりそうです。 いざログ確認。 CreateBucket ！？ なんと CreateBucket というアクションが実行されていました。 どうやら rclone copy では毎回同名のバケットを作り直しているそうです。 早速ポリシーに追加します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:CreateBucket" ], "Resource": [ "arn:aws:s3:::*" ] }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::作成したバケット名", "arn:aws:s3:::作成したバケット名/フォルダ名/*" ] } ] } いざ rclone copy ！ rclone copy C:\Users\xxxxx\xxxxx\xxxxx s3:作成したバケット名/フォルダ名 #実行結果 2024/xx/xx xx:xx:xx Failed to copy: Forbidden: Forbidden status code: 403, request id: xxxxxxxxxxxxxxxx, host id: xxxxAVBHF/hihccgvXxxxxxxFTFZOh/xx-GUKLvxxxxxxxxxxxxxxxxx 「 Forbidden 」 まだか。しかし CreateBucket が実行されていることから学んだことがあります。 実行するコマンドの処理について考えることが大切なのではないかということです。 実際にRcloneの公式ドキュメントには rclone sync コマンドを実行する際の最低限必要な権限が記載されています。 Amazon S3 ここにも記載されているようにフォルダの同期を行う sync コマンドではファイルの削除も行うため DeleteObject などのアクションが必要になってきます。 では rclone copy はどんな処理をするコマンドなのでしょうか？ rclone copy 同期元と同期先で同じファイルはスキップするようコピーする。この時、同期元で削除したファイルは同期先で削除されないため、同期先の容量はどんどん膨らんでいることに注意 引用： https://www.phi.phys.nagoya-u.ac.jp/~fujiie/memo/rclone.html copy では同期元と同名のファイルが同期先にあるときはファイルの更新を行い、同期先にないときにはファイルを新しく同期先に作成しています。 ということはフォルダの中のオブジェクトの全てを一度参照していることになります。 現在のポリシーにはオブジェクトの一覧を参照できるアクションの権限はありませんのでアクション一覧から探します。 ListBucket ：バケット内のオブジェクトの一覧を取得する これが使えそうです。ポリシーに追加していきましょう。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:CreateBucket" ], "Resource": [ "arn:aws:s3:::*" ] }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::作成したバケット名", "arn:aws:s3:::作成したバケット名/フォルダ名/*" ] } ] } 満を持して rclone copy ！ rclone copy C:\Users\xxxxx\xxxxx\xxxxx s3:作成したバケット名/フォルダ名 #実行結果 ついにエラーなく実行できました。 AWSのコンソールにてs3バケットを確認するとローカルのファイルがs3バケット内にコピーされてると思います。 これでついにrcloneでローカルPCからs3にアクセスできたといえます。 お疲れさまでした。 おわりに 今回はAWSも触ったことがない、Rcloneとはなんぞやといった何もわからない状態で作業し始めたためIAMポリシーの規則などで詰まってしまいました。 AWS初心者の私はまずAWSリソース間でのアクセスに必要な権限で躓いてしまい、さらに外部アプリケーションを介することでさらに必要となる権限があるということの2点躓くポイントがありました。 前者の問題は色々な記事があるためネットで検索すると情報が出てきます。 しかし後者の問題は今回のように全く同じことをしている人が少ないことが多いです。 そこで実行したいコマンドがどういった処理をしているものなのかや、ログをたどることで対策できることもあると分かりました。 実際rcloneは実行するコマンドによって必須の権限があるため注意が必要ということが分かりました。 特に今回の rclone copy では GetObject PutObject ListBucket CreateBucket の４つは必須です。 今回の経験を活かして今後も実行したいものがどういった処理を行うものなのか考えながら業務に励んでいきたいと思います。 以上、新卒1年目がRcloneでAWSへアクセスするときの権限で苦しんだ話でした。 ありがとうございました。 次回は、keylium さんです。 ここから24新卒リレーブログ企画スタートです！ ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

こんにちは。NIFTY engineeringブログ運用チームです。 ブログ運用チームでは、ニフティのエンジニアについての情報を世の中に広めるための活動をしています。 その活動の一環として、リレーブログを実施しています。 【リレーブログ企画第一弾】チーム紹介リレーブログをやります！ 現在、リレーブログ第一弾を実施中ですが、第二弾も並行して実施します！ リレーブログ第二弾のテーマは「24新卒リレーブログ」です。 本記事に、24新卒社員のブログ記事のリンクをまとめていきますので、ぜひチェックしてください。 24新卒リレーブログは以下のスケジュールで投稿予定です。お楽しみに！ 投稿予定 執筆者 記事タイトル 2024年7月22日 藤岡さん RcloneでAWS S3へアクセスするときにIAMの権限で苦しんだ話 2024年8月2日 keyliumさん .inputrc を設定してshell入力を高速化する 2024年8月9日 山本さん roboflow体験記 ～ 画像認識AIモデルを活用する 2024年8月12日 塚崎さん 未定 2024年8月23日 けにさん 未定 2024年9月5日 佐藤さん 未定 2024年9月6日 後藤さん 未定 2024年9月6日 滝川さん 未定 2024年9月6日 緑川さん SvelteKit関連(仮) ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

「社内向けのインナーソースガイドラインってどう作るんだろう…」 「インナーソースポータル（カタログ）をどう構築しよう…」 「ボトムアップでインナーソースの土台作りをどう進めればいいんだろう…」 ✔記事の内容 これまでの記事 社内向けインナーソースガイドラインを作成 ニフティのインナーソースガイドラインの目次 「3．社内のインナーソース情報を得るには」の内容 「4．コントリビューターとして参加するには」 の内容 「5．担当しているリポジトリをインナーソースにするには」の内容 「6．質問・相談」の内容 「7．さらにインナーソースの理解を深めるには」の内容 インナーソースポータルを構築 エンジニア全体会で、インナーソースガイドラインを公開！ 次の記事に続く… 【告知】InnerSource Gathering Tokyo 2024 に登壇します！ こんにちは！社内でインナーソース普及活動もやっている小松です！ 今回は実際に社内のメンバーがインナーソースに取り組むための土台作りになる、ガイドラインやインナーソースポータルのご紹介をしたいと思います！ これまでの記事 前回の記事は、ニフティでインナーソースお試し導入をしてみた様子と、エンジニアのアンケート結果を公開しました。 アンケート結果からインナーソースの導入に 反対する人が0% ということがわかり、社内展開に向けて動き始めました。 インナーソースを導入してみた その① お試し導入編 ちなみに、この記事をきっかけに、InnerSource Commonsのイベントに事例紹介として登壇させていただきました！ 質疑応答でディープな質問にも答えてもらったので、ご興味のある方は以下の記事をご覧ください！ ボトムアップで始める事例紹介と悩み相談【 InnerSource Commons #11に登壇】 今回は社内展開に向けたガイドライン作成、インナーソースポータルの構築、商用システムリポジトリをインナーソースにしてみるなど、土台作りの部分を共有します。 社内向けインナーソースガイドラインを作成 社内のNotionページに公開して、誰でも閲覧できるようになっています。 実際にインナーソース活動をやってもらうためにも、ガイドラインがないと何から手を付ければいいかわからずハードルが上がってしまいます。 ただリポジトリを公開するだけでは、コントリビュートの仕方がよくわからず、コントリビューターの負荷も増え、ホストチームもコミュニケーションコストが発生するので、CONTIBUTING.mdの書き方や、品質のためにも、テスト、lint環境を整備してもらうなど、手順を書きました。 ガイドラインの一部をご紹介しようと思います。 現時点での目次は以下です。 ニフティのインナーソースガイドラインの目次 1．インナーソースとは 概要 このガイドラインは何か？ 2．役職と責任範囲 ホスト ゲスト 3．社内のインナーソース情報を得るには 4．コントリビューターとして参加するには 5．担当しているリポジトリをインナーソースにするには 6．質問・相談 7．さらにインナーソースの理解を深めるには 「1. インナーソースとは」「2. 役職と責任範囲」については、インナーソースの一般的な説明になるので割愛します。 「3．社内のインナーソース情報を得るには」の内容 ここは以下のリンク集になっています。 ドキュメント Slackチャンネル インナーソースポータル FAQ 活動評価 「4．コントリビューターとして参加するには」 の内容 こちらはせっかく興味を持ってくれた方が、なるべく途中離脱しないように以下のような詳細なステップを書いています。 インナーソースポータルの紹介 CONTRIBUTING.mdの紹介 上長に許可をもらう 評価時に他社貢献、スキルアップのアピールとなるためにも 非同期でのコミュニケーションとなるため、コメントを詳細に残す 仕事表の付け方 細かいルールは各リポジトリごとCONTIBUTING.mdに従ってもらいます。 「5．担当しているリポジトリをインナーソースにするには」の内容 こちらも詳細な手順を書きました。 以下のような流れになっています。 プロダクトオーナーにリポジトリをインナーソースにする旨を共有 InnerSourceCommonsが公開しているラーニングパス に出てくるプロダクトオーナーは、技術の前提知識があるように読み取れます。 ニフティでは、ビジネス職の方がプロダクトオーナーになっている場合が多いです。 そのためトラステッドコミッターにインナーソースにおけるプロダクトオーナーの役割と権限を委任してもらう形にしています。 トラステッドコミッターを決める リポジトリの設定 インナーソースポータルに追加するクローラーに拾ってもらうようにDescriptionのTopicsに inner-source を追加。 現在は社内事情により、Forkでなく権限を付与してコントリビュートしてもらうので、権限の設定等。 ブランチ保護ルールなどは各リポジトリに任せます。 テスト・lintなどローカル開発環境の準備 違う開発文化を持った人も関わることがあるので、品質の観点からテストとlintは導入してもらうことにしています。 README.mdを用意 README.mdについては、 InnerSourcePatternsが紹介しているテンプレート があったので、そちらを参考に作った例を載せています。 コントリビュートについては、別途CONTIBUTING.mdを参照するように書いています。 CONTRIBUTING.mdを用意 コントリビューションするための詳細な手順を書きます。 CONTRIBUTING.mdについても、 InnerSourcePatternsが紹介しているテンプレート があったので、そちらを参考に作った例を載せています。 異なる開発文化の人でも理解ができるようにしておきます。 詳細にしておくことで、コミュニケーションコストも減らせます。 例えば、ブランチ名、コミットメッセージなどのフォーマットを決めておいたり、テスト実行方法など説明しておきます。 Slackなどで宣伝 「6．質問・相談」の内容 NotionにFAQのデータベースを公開しているので、リンクを張っています。 誰でも編集できるようになっています。 またインナーソースのSlackチャンネルに気軽に問い合わせもらうようにしています。 ハードルが低いおかげか、Slackチャンネルでの質問が多いです。 「7．さらにインナーソースの理解を深めるには」の内容 インナーソースの学習に使えそうなリンク集です。 InnerSource Commons JapanのYouTubeチャンネル 日本向けのチャンネルなので、最初はここを見てみるのがいいかもしれません。 InnerSource Commonsが公開しているラーニングパス 一番最初に読むには難しいかもしれません。 InnerSource CommonsのSlackチャンネル 日本チャンネルもあるので、 #jp_general に気軽に入ってみてください。 InnerSource Commons Japanのconnpass InnerSource Commons Japanのイベントに参加してみたい方向け。 堅苦しくない雰囲気なので、まずは気になるイベントを参加してみるのをおすすめです！ インナーソースポータルを構築 ※リポジトリ名などは黒塗りしています。 社内のインナーソースになっているリポジトリを探すためのツールです。 インナーソースパターンブックでも紹介 されています。 参考実装のリポジトリ が公開されているので、まずは利用させてもらいました。 ニフティでは、 社内リポジトリはGitHubの1つのOrganizationで管理 しているため、実装はほぼそのまま社内サーバーに構築しました。 インナーソースリポジトリを自動で拾ってくれるクローラーは、 zkoppert/innersource-crawler のリポジトリを使わせてもらいました。 リポジトリのTopicsに inner-souce を追加すると、インナーソースポータルに追加してくれます。 後ほどインナーソースポータル自体もインナーソースにしてみました。 すると、新人が学習の一貫として、Next.jsに移行するコントリビュートをしてくれました！ さらに他のメンバーも加わり、私がなかなか時間を取れず進められなかった、インフラ周りの整備、社内ドメイン取得など、エンジニア同士がコンラボレーションしながら、進めてくれました。 まさにインナーソースの良さを感じました！ エンジニア全体会で、インナーソースガイドラインを公開！ ニフティでは、月に1回エンジニアが全員参加する全体会があります。 社内のトピックを共有したり、最後には謎解きコーナーがあったり！？する会なのですが、LTさせてもらえる時間があるので、そこでインナーソースガイドラインの公開も兼ねて発表しました。 発表内容は、インナーソース実験の結果、アンケート結果、インナーソースガイドラインの紹介でした。 インナーソース実験の結果とアンケート結果は その①の ブログ 記事 で公開しています。 エンジニアからの反応はポジティブなものが多く、 「実際に〇〇リポジトリをインナーソースにしてほしい！」 「担当業務以外の環境に触れる貴重な機会」 などコメントをもらいました。 実際にこのLTをきっかけに、新人が作っていた便利ツールをインナーソースにしてもらいました。 インナーソースの文化を作っていくにあたり、比較的時間に余裕がある若い世代にどんどん実践してもらい、徐々に広めていくのは効果的だなと思いました。 次の記事に続く… 続きはその③の記事で公開予定です。 いろいろネタは溜まってきているので、随時公開していきたいです。 「インナーソースオフィス立ち上げ」 「インナーソース導入後の効果」 「非エンジニアもインナーソース!?」 「InnerSource Commons Japanとのつながり」 「成熟度モデル導入はまだ難しかった」 「社内の創意工夫賞金賞受賞!?」 「商用システムリポジトリをインナーソース」 【告知】InnerSource Gathering Tokyo 2024 に登壇します！ InnerSource Gathering Tokyo 2024 にニフティの事例紹介として登壇します！ 日本初となるインナーソースカンファレンスです！ またニフティからはイベント運営自体にも数人協力しています！ 興味のある方は、イベント参加は以下のからお願いします！ https://innersourcecommons.connpass.com/event/317995/ ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

はじめに 宮永です。2024年7月のJANOG54 meeting（以下JANOG54）に参加してきました。 感想などを書いていきます。 JANOG Meetingとは JANOGとはJApan Network Operators’ Groupを意味し、 インターネットに於ける技術的事項、および、それにまつわるオペレーションに関する事項を議論、検討、紹介することにより 日本のインターネット技術者、および、利用者に貢献することを目的としたグループです。 https://www.janog.gr.jp/information/ 　より引用 年に2回meetingが開かれ、日本全国から様々なバックグラウンドを持つ人が集まります。インターネットに関する技術やノウハウについての発表や議論が行われます。 どうして参加したのか？ 私は社内の「ISPオペレーションサブチーム」に所属しており、日々ニフティのお客様が快適にインターネットを使えるようにするための業務を担当しています。現在の業務にぴったりのコミュニティであると思い、参加しました。 参加にあたっての社内説得方法 私「参加したいです」 上司「いいですよ」 これだけです。いやぁ、ニフティっていい会社ですねぇ（ダイレクトマーケティング）（ここで採用ページのリンクを貼る） https://recruit.nifty.co.jp/ JANOG54現地 今回参加したJANOG54 meeting（以下JANOG54）は奈良県にある奈良県コンベンションセンターで開催されました。木のいい香りがしました。奈良県でのJANOG meeting開催は初だそうです。 会場の雰囲気会場には40~50代のオジサンしかいない……と勝手に想像（失礼）していましたが、全くそんなことはありませんでした。高校生からベテランまで幅広い層が参加していました。 というのも、初参加が44%ほどいるそうです。若くなくても初参加だったり、20代で6回目だったり、いろいろな人がいました。 参加者の所属企業も様々で、私のようなISP事業者だけではなくネットワーク機器メーカー、コンテンツ事業者などなど、様々な人が集まっています。 キッチンカーも来ておりお祭りムードです。 JANOGでは「カンファレンス」ではなく「ミーティング」と呼ぶことを大切にしているようです。発表時間に対して質疑応答の時間が長く、積極的な議論が歓迎されている雰囲気を感じました。発表後は年齢問わず活発な議論が行われ、時間終了後に場外戦が繰り広げられる場面も見かけました（そのための「替え玉エリア」が各会場の外に用意されていました）。 プログラム 200~400人ほどが入りそうな大きな会場3か所で様々な発表が行われます。楽しそうな発表ばかりで、どこに行くか迷います。人気のプログラムはすぐに席が埋まってしまうので、絶対に聞きたい発表があれば早めに会場に行くことをおすすめします。 BoF プログラムとは別に、選考が行われない自由な発表、議論の場であるBoFがあります。こちらも3部屋ありますが、50人程度の比較的小さい会場です。発表というより議論のほうが雰囲気としては近く、BoFの主催者が提示した議題に対していろいろな人が意見を出していました。 参加したBoFでは意見を出してみました。学会のような緊張感ある質疑ではなく、ワイワイと同じ目標に向かってアイデアを出していく雰囲気に近かったです。 NOCツアー 3日間開かれる会場には十分すぎるほどのWi-Fi環境が構築されており、会場のどこに行ってもAPが見えます。AP70台に約2000同時接続だそうです。そんなネットワークの裏側の見学会がありました。3日間のために複数ASとピアリングし、約100本のケーブルを会場に敷設し、監視体制まで整えていました。本当にすごいです。 公開してよさそうな写真を1枚。NTPサーバまで自前で立てているそうです。 反省点 もっと積極的にコミュニケーションをとればよかった とくに初日では場の温度感が分からず、積極的に動けていなかった部分がありました。単なるカンファレンスではなく話し合いを大切にする場なので、もっと積極的に色々な人とコミュニケーションを取りたかったです。 懇親会争奪戦に勝ちたかった 懇親会は大人気で、申し込み開始後数時間で売り切れになってしまうそうです。それを知らず、申し込み時は売り切れになっていました。次回こそは参加したいです。 上着をもってくればよかった （皆さん涼しいサーバルームにお住まいの方が多いからか）会場が寒いと感じる事が多かったです。　真夏の開催でも羽織るものを持っていると良かったです。 まとめ 何も分からない初心者が一人で参加しましたが、様々な知見を得たり、似た業務をしている人たちとコミュニケーションを取れたりなど、普段の仕事中ではなかなかできない経験ができました。 次回は2025年1月に京都で開催されるそうです。みなさんもぜひ参加してみてください！ ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

8/6(火)に開催される PagerDuty on Tour に当社エンジニアが登壇いたします。 当社エンジニアの熊谷が、PagerDutyを活用したシステム運用の変化についてお話しします。 登壇のスケジュールは以下の通りです。 タイトル PagerDutyを導入して変わったシステム運用とこれから 概要 PagerDuty活用により、これまで人力中心のシステム監視・運用からの変化した点を共有します。 従来の監視や連絡（リソース・プロセス監視、メール通知）を、PagerDutyを活用し最適化したことで、クリティカルな問題に素早く気づけるようになりました。 システム運用の変化、良かった点や課題について、事例を交えて紹介します。 日時 8/6(火) 19:40 – 19:45 PagerDuty ON TOUR 2024

SREコミュニティのイベント SRE NEXT 2024 が2024年8月3日、4日に開催されます。 当社エンジニアの島が公募から採択され、2日目のLTに登壇いたします。 タイトルは『FourKeysを導入したが生産性向上には至らなかった理由』です。 詳細は SRE NEXT 2024の講演 スケジュールを参照ください。 ニフティでは、島が属するSREチームが全社横断のSREイネーブリングチームとして活動をしています。SREチームの活動については以下のインタビュー記事をご覧ください。 【インタビュー】ニフティのSREに聞く！インターネット黎明期から安心・安全を体現してきたニフティが2023年に取り組んでいるSREとは？【SRE前編】 【インタビュー】ニフティのSREはどんな人？【SRE後編】 また、SRE NEXTには2022にスポンサーセッションで登壇しております。登壇内容につきましては以下の記事に詳しいです。動画のアーカイブもありますのでぜひご覧ください。 SRE NEXT 2022にGOLDスポンサーとして協賛＆登壇します！

こんにちは。気づいたら新卒 2 年目の statiolake です。人間がやらなくていいことは極力プログラムにやらせようと思って日々を過ごしています。 さて、最近関わっている業務の中で、draw.io を利用してかかれたフロー図をコードの修正に応じてメンテナンスするというタスクが発生しました。draw.io はこういう図を書くのに本当に便利ではあるのですが、だとしても後からステップや条件分岐を足したりするのは面倒です。正直コードを書く労力の 10 倍くらい大変な作業に感じました。この手間をなんとかなくしたいと考え、draw.io は難しくてもテキストベースの Mermaid であれば Python から自動生成することも可能なのではないか？ と思い至り、色々試してみたというエントリです。 忙しい方向け Python のコードを Mermaid に変換するツールを作りました。コードは以下のリポジトリに置いています。 https://github.com/statiolake/python-to-mermaid また、このツールを Web から使うことができるようにもしました。以下のリンクから覗いてみてください。 https://statiolake.github.io/python-to-mermaid-frontend/ Mermaid とは Mermaid はテキストベースで色々なグラフがかけるツールです。その中にはフローチャートもあります。例えば以下のようなテキストを書いたとしましょう。 flowchart TD; A("Begin: sum_numbers"); B("End: sum_numbers"); C["total = 0"]; G("return: total"); subgraph "Begin: for num in numbers" D[/"Begin: for num in numbers"\]; E[\"End: for num in numbers"/]; F["total += num"]; end A --> C; E --> G; G --> B; C --> D; D --> F; F --> E; ここから以下のようなフローチャートを表示できます。 Mermaid は Notion や GitHub との相性もいいです。Markdown のコードブロックに上の Mermaid のコードを書くだけで、自動的にフローチャートが表示されるようになります。 本題: Python から Mermaid に変換したい 広く使われている言語であるところの Python からこんなに便利な Mermaid に変換する機能、需要もありそうですし、探せばどこかにはあるだろうと思っていました。しかし意外にも Google で検索した限りでは見つかりませんでした。となると何らかの方法で自分で用意する必要があります。 生成 AI の力を頼ってみる 現代なので、とりあえずこういう汎用的なタスクには生成 AI が使えるのではないかと考えるのが常です。実際、Python から Rust に書き換えるなど、プログラミング言語間の変換は割と正しくやってくれるイメージです。というわけで、同じように Python から Mermaid のコードに変換するようお願いしてみました。 今回使用した Python のサンプルコードは以下のコードです。いい感じにループや条件分岐があってよさそうな感じなので採用させていただきました。生成 AI によって生成された (ものを一部手直しした) 、ブラックジャックのスコア計算っぽい関数です。 def calculate_score(self, hand): score = 0 aces = 0 for card in hand: if card == 'Ace': aces += 1 score += 11 elif card in ['Jack', 'Queen', 'King']: score += 10 else: score += int(card) while aces > 0 and score > 21: score -= 10 aces -= 1 return score で、まずこれを Claude 3 Haiku に投げてみました。プロンプトにはあまり凝っていません。それで生成されたのがこちら。 flowchart start[開始] --> init[score = 0, aces = 0] init --> loop{"card in hand"} loop -->|"card == 'Ace'"| a["aces += 1, score += 11"] loop -->|"card in ['Jack', 'Queen', 'King']"| b["score += 10"] loop -->|else| c["score += int(card)"] loop --> d{"aces > 0 and score > 21"} d -->|true| e["score -= 10, aces -= 1"] d -->|false| return["return score"] e --> d うーん、雰囲気は感じますが、フローチャートではないですね。突然矢印が途切れていますし、これを見せられたらより混乱してしまうような気がします。まだコードを直接読んだほうが簡単ではないでしょうか。ちなみに出てきたものをそのまま与えると syntax error になってしまい、手動での手直しも必要でした。 もう一つ、GPT-4o にも聞いてみました。 flowchart TD A[Start] --> B{カードが残っているか？} B -- Yes --> C[カードを取得] C --> D{カードは'Ace'か？} D -- Yes --> E[acesに1を加算<br>scoreに11を加算] D -- No --> F{カードは'Jack', 'Queen', 'King'か？} F -- Yes --> G[scoreに10を加算] F -- No --> H[scoreにカードの数値を加算] E --> B G --> B H --> B B -- No --> I{aces > 0 and score > 21か？} I -- Yes --> J[scoreから10を減算<br>acesを1減らす] J --> I I -- No --> K[scoreを返す] K --> L[End] さすがというべきか、正しい処理フローは抑えています。ただこれもフローチャートとしては見づらいです。これも結局元のコードのほうが読みやすい気がします。 まあ、フローが間違っていない以上、GPT-4o 側というよりはどちらかというと Mermaid 側のレイアウト計算にとって難しいという問題なのかもしれません。だとしてもループなどの制御構造についてはもう少し見やすいほうがありがたく、まるで goto 文を見ているかのようです。 諦めて自力で実装してみた 結局生成 AI にそのまま聞くだけでは満足行く成果は得られませんでした。冷静に考えると元々が機械可読な Python のコードなわけですから、機械的に変換してしまったほうがよいかもしれません。こんな感じのステップでいけるはずです。 Rust に Python のパーサー があったことが決め手となり、実装に踏み切りました。そしてその完成したツールがこちらです。 https://github.com/statiolake/python-to-mermaid これを使って生成したフローチャートが以下です。 flowchart TD; A("Begin: calculate_score"); B("End: calculate_score"); C["score = 0"]; D["aces = 0"]; Q("return: score"); subgraph "Begin: for card in hand" E[/"Begin: for card in hand"\]; F[\"End: for card in hand"/]; G{"if: card == 'Ace' ?"}; H["aces += 1"]; I["score += 11"]; J{"if: card in ['Jack', 'Queen', 'King'] ?"}; K["score += 10"]; L["score += int(card)"]; end subgraph "Begin: while aces > 0 and score > 21" M[/"Begin: while aces > 0 and score > 21"\]; N[\"End: while aces > 0 and score > 21"/]; O["score -= 10"]; P["aces -= 1"]; end A --> C; C --> D; N --> Q; Q --> B; D --> E; E --> G; G -->|"T"| H; H --> I; G -->|"F"| J; J -->|"T"| K; J -->|"F"| L; I --> F; K --> F; L --> F; F --> M; M --> O; O --> P; P --> N; どうでしょう。個人的には一番きれいに生成できているのではないかと思います。また、生成 AI と違ってこのプログラムは何回実行しても同じフローチャートを返します。スタンドアロンなプログラムなので CI 環境下でも使えます。つまり… GitHub Actions に仕込めば、変更を自動的にフローチャートに反映させることも可能です。夢が広がりますね。 また、ここまででも結構いい感じなのですがもう一歩、この段階まで用意してあげてから生成 AI にかけると、構造を維持しながらラベルをもう少しわかりやすくすることもできます。あるいはもっとうまくプロンプトを指定してあげれば、冗長な部分を削ったり適当な粒度でステップを結合してくれたりもするかもしれません。そこまでできたらもう手動でフロー図を書く必要はないと言っても良さそうです。 flowchart TD; A("計算開始: 得点計算"); B("計算終了: 得点計算"); C["得点 = 0"]; D["エース = 0"]; Q("戻り値: 得点"); subgraph "開始: 手札の各カードについて" E[/"開始: 手札の各カードについて"\]; F[\"終了: 手札の各カードについて"/]; G{"もしカードがエースであれば ?"}; H["エース数を 1 増やす"]; I["得点を 11 加算"]; J{"もしカードがジャック、クイーン、キングであれば ?"}; K["得点を 10 加算"]; L["得点にカードの数値を加算"]; end subgraph "開始: エース数が 0より大きく、得点が 21より大きい間" M[/"開始: エース数が 0より大きく、得点が 21より大きい間"\]; N[\"終了: エース数が 0より大きく、得点が 21より大きい間"/]; O["得点を 10 減算"]; P["エース数を 1 減算"]; end A --> C; C --> D; N --> Q; Q --> B; D --> E; E --> G; G -->|"はい"| H; H --> I; G -->|"いいえ"| J; J -->|"はい"| K; J -->|"いいえ"| L; I --> F; K --> F; L --> F; F --> M; M --> O; O --> P; P --> N; なお、今後の余裕があればラベルをソースコード側でカスタマイズできるようにする機能追加も考えています。 おまけ: 手軽に試してみたいあなたに せっかくなので、このツールを気軽に試せるよう、GitHub Pages を使って Web 化しました。 https://statiolake.github.io/python-to-mermaid-frontend/ お手元の Python ソースコードをつっこんで遊んでやってください。 …ところでコアロジックは Rust で書かれています。GitHub Pages は静的サイトホスティングサービスなので、裏で Rust の API サーバーが動いているわけではありません。それではこの Web ページはどうやって変換処理を実行しているのでしょうか？ 実はこの Web ページでは WebAssembly にコンパイルされた Rust のコードがあなたのパソコンの中で動いています！ 今回のフロントエンドは GitHub Actions + SvelteKit (adapter-static) + Rust WebAssembly で構成されています。びっくりするほど簡単に Rust のプログラムをブラウザで動かすことができたので、もしかしたら次の記事で紹介するかもしれません。 終わりに 今回は Python のコードを Mermaid のフローチャートに変換するツールを実装しました。こういったルールベースの厳密な変換処理はただ適当に生成 AI に投げるだけでは厳しく、まだまだ手書きしたほうが強い部分もありそうです。また、確率的に文言を生成する AI の仕組み上、一定の品質で決定的な結果を得ることも難しいです。 ただし、ラベルの調整部分は AI の得意分野で、非常にわかりやすいフロー図にブラッシュアップしてくれました。些細な例ですが、このように他の手法と AI による手法を組み合わせることで質が大きく向上する例はいくらでもありそうです。AI をただ適当にそのまま使うのではなく、うまく組み合わせて更に高い価値を生み出すことができるように精進していきたいと感じました。 ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

はじめに 接続会員向けアプリ「マイ ニフティ」のスクラムマスターをしている西野です。 私は2024年時点でスクラムマスター4年目になりますが、どのチームでも前回とは異なるレトロスペクティブをやるように取り組んできました。 いろいろなレトロスペクティブを実施する中で、ある程度レトロスペクティブの手法（アクティビティ）のカテゴリーが見えてきたので、テーマ選びと振り返り方のコツをまとめてみました。 スクラム以外のスタイルでも参考になる部分があると思うので、ぜひ活用してみてください。 なぜレトロスペクティブをするのか あなたのチームは世界一良いチームですか？　もしそう言い切れないなら、レトロスペクティブをやる価値はあります。 スクラムガイドによれば、レトロスペクティブはそのスプリントの「検査」の場です。振り返りをしない（検査しない）というのは、テストせずに本番リリースするくらい組織にとって危険なことだと思います。 チームのよかった点や問題点を検査することで、仕事や人に対する不安を解消し、心理的安全性を確保します。そして、検査を重ねることでより良いプロダクトをつくるチームになるためには何が必要かを割り出し、成長に繋げます。 難しく考えずに、もし「最高のチームワーク」が欲しいなら、どうやったら協力しやすいか過去の活動をもとに考えるのではないでしょうか。それがレトロスペクティブです。 振り返りのフォーカスの当て方 「これについて振り返りたい」とチームメンバーからアイデアが出てくるのが理想ですが、ある程度狙いどおりに進んだスプリントが続くと、良いことも悪いことも浮かびにくくなります。振り返りのテーマを探るためのヒントを挙げてみます。 スプリント固有のイベントにフォーカスする 例えば、障害が起きた、今までできたことが今回はうまくいかなかった、新しいメンバーが増えた（減った）というようなスプリントであればテーマは選びやすいでしょう。 思い当たる出来事がなくても、ベロシティが著しく変わってないか、PRの回数、レビューの滞留時間など客観的な数字から普段との違いを見つけることもできます。 もし前のレトロスペクティブで上げたアクションが今スプリントで機能しなかった場合は、引き続きその課題について話し合ったほうが良いかもしれません。 スプリントで何が起きたかを把握する スプリント固有のイベントが思い当たらない場合、そのスプリントで何が起きていたかを把握すること自体をテーマにしても良いでしょう。 チームのあるべき姿を考える もし特に目立つイベントがない、または取り上げるべき問題がないと感じられる場合、あるべき姿をイメージし、その差分を見つけることをテーマにしてみましょう。 チームの状況をメタファーで捉えることで、改善点が見えてくることもあります。 今後のことにフォーカスする 今起きていないが「今後」起きるかもしれない心配ごとがある場合、それについてどんな出来事が過去にあったか、どんな未来を招く可能性があるかをイメージし、対策を考えることも効果的です。 振り返り方法の選び方 振り返りの方法には多くの種類があり、どれを選べば良いか迷ってしまうことも多いです。私が参考にしている書籍やサイトを一部紹介します。 アジャイルレトロスペクティブズ （書籍） FunRetrospectives Easy Retro Miro – Retrospective templates Retrium 少し見ただけでも、膨大な数があり迷ってしまうかもしれません。 これらの振り返り方法は大きく5種類に分けて把握できると考えています。GOOD/BAD系、連想、時系列、メタファー、数値化です。 GOOD/BAD系 特定の観点に基づいて、各々が思う出来事を挙げていきます。 観点を少し変えるだけでアクティビティの内容も変わるため、最もパターンが多い振り返りの種類です。 オススメのシーン スプリントで起きたことを幅広く知りたい時 意見が出やすいチームやテーマの時 オススメではないシーン 意見が出にくいチームやテーマの時 発言する人・しない人が偏ってしまう時 アクティビティの例 KPT YWT Start-Stop-Continue Mad Sad Glad Easy As Pie 象、死んだ魚、嘔吐 Starfish Retrospective 連想 前の人の意見を受けて順に意見出しをするやり方です。 連想形式のため、GOOD/BAD系で意見が出にくくても、このスタイルだと意見が出やすくなることが多いです。 オススメのシーン 意見が出にくいチームやテーマの時 発言する人・しない人の偏りをなくしたい時 オススメではないシーン 活発なディスカッションをしたい時 アクティビティの例 555 質問の輪 5つのなぜ 時系列 出来事を時系列で挙げていきます。 その時のチームメンバーそれぞれの感情を合わせて記載することで、出来事の評価がしやすくなります。 オススメのシーン プロダクト開発が走り始めた時 波乱万丈なスプリント（出来事が複雑な時） オススメではないシーン 平穏無事なスプリント（何が起きたかある程度わかっている時） アクティビティの例 Timeline メタファー チームの状況を別のものに例えることで客観的に見つめて、追い風となるもの、今負担となるもの、これから障害になりそうなものなどを洗い出します。 オススメのシーン チームの状況を俯瞰して捉えたい時 グラフィカルで楽しい振り返りをしたい時 オススメではないシーン とくにありませんが、結果がある程度似てしまうことが多いので、1-2ヵ月に1度くらいの頻度がオススメです。 アクティビティの例 熱気球 スピードカー 三匹の子豚 数値化 チームがどの程度できているかを項目別に点数をつけることで、理想的な状態との差分を知ります。 オススメのシーン チームの短所がぱっと思いつかない時 オススメではないシーン 心理的安全性が低く、数値化することに恐れを感じる場合 アクティビティの例 チームレーダー アジャイルの車輪 【その他】チームメンバーを知る 振り返りとは異なりますが、チームメンバーが増えた時にレトロスペクティブの時間を相互理解の時間にあてることがあります。（スプリントの検査としては機能しないので、別の時間でやったほうが良いと思います） アクティビティの例 価値観ポーカー ムービング・モチベーターズ ある程度パターンと長所短所がわかれば、具体的にどの手法を選ぶかはテーマだけでなく季節感で選んでも良いと思います。例えば夏や海がテーマの振り返りだけでも何種類もあります。季節的な要素を加えると楽しさもアップします。 レトロスペクティブの手法を毎回変える意味とは レトロスペクティブのやり方を毎回変えていると、なぜ常にKPTなどで振り返ってはいけないのでしょうか、と尋ねられることがしばしばあります。 以前 ケース別！リモートでのおすすめレトロスペクティブ で「毎回同じ手法では観点に偏りが出てしまい、新たな問題に気づきにくくなる可能性がある」と書きましたが、最近は「お祝いは、工夫を凝らしたほうが楽しくて盛り上がる」という答えがよりしっくりきています。 そのスプリントが無事に、またはトラブルはあったものの終えられたということは、お祝いしていいことだと思います。 スプリントの最後のイベントこそ、どのスクラムイベントよりも楽しく、ポジティブに終えることができたほうが次のスプリントが良くなりそうな気がしませんか。 実際、チームメンバーが楽しんでレトロスペクティブに参加している姿や、今回のレトロスペクティブは面白かったと言ってもらえるとスクラムマスターとしてもやる気がでます。 逆に、今回のレトロスペクティブはやりにくかったというフィードバックでも、次の振り返りにつなげることができます。 毎回同じ振り返り手法では、このようなフィードバックは得にくいです。 レトロスペクティブをスプリントの中でもっとも素敵な時間にするために、今回はどんなアクティビティが盛り上がりそうか、この「GOOD/BAD系」「連想」「時系列」「メタファー」「数値化」という5種類の分類を手がかりに、工夫を凝らしてみてください。 ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

はじめに 会員システムグループのkiqkiqです。最近PySparkというライブラリを触ってみたので紹介したいと思います。 Apache Spark・PySparkとは PySparkは、Pythonを使ってApache Sparkを操作するためのライブラリです。そのApache Sparkというのは、オープンソースの大規模データ処理フレームワークで、高速で汎用的なデータ処理エンジンです。Sparkには主に４つの特徴があります。 分散処理 Sparkはクラスター上で分散処理を行うことができ、大量のデータを効率的に処理することができる 高速 メモリ内で処理を行い、複数の並列操作でジョブのステップ数を減らすことでデータを再利用することができる 汎用性 Sparkはバッチ処理だけではなく、ストリーミング処理、機械学習、グラフ処理などのデータ処理に対応 多様なAPI Sparkは、Scala、Java、Python、R など、さまざまなプログラミング言語からアクセスできる これらの特徴から、Spark関連のものは大規模データ処理、機械学習、ストリーミング処理など、さまざまな用途で利用されています。このブログではPySparkの基本的な機能や簡単な使い方などを紹介していきます。 機能紹介 Spark SQL Spark SQL は、SQLライクなクエリ言語を使ってデータ処理ができる。 SQLを使ったデータ分析や 抽出、変換、ロードのようなタスクを簡単に実行できるもの。 Spark Streaming Spark Streamingは、リアルタイムのデータストリーミング処理を可能にするコンポーネント。Spark Streamingでは数秒ほどの短い間隔に区切られたバッチ処理を繰り返し行い、ストリームデータ処理機能を実現されている。 MLlib MLlibは、Sparkに組み込まれている機械学習のライブラリで、分類、回帰、クラスタリング、共起分析などの主要な機械学習アルゴリズムが用意されている。 GraphX GraphXは、グラフ処理のための Spark のコンポーネントで、ソーシャルネットワーク分析、推薦システム、ルーティングアルゴリズムなど、グラフ構造のデータを扱うことに特化した機能。また、組み込まれているグラフ処理用の API を使って、グラフの作成、変換、分析などの処理を行える。 使い方 環境構築 今回は jupyter notebook と pyspark がインストールされたコンテナイメージ jupyter/pyspark-notebook 上で実行していきます。以下の docker-compose.yml を実行するだけで pyspark を実行できる環境を構築できます。 version: '3' services: jupyter: image: jupyter/pyspark-notebook ports: - "8888:8888" # notebook のポート - "4090:4040" # Spark UI のポート environment: - JUPYTER_ENABLE_LAB=yes - CHOWN_HOME=yes - CHOWN_HOME_OPTS=-R - GRANT_SUDO=yes - NB_UID=1000 - NB_GID=100 command: start-notebook.sh --NotebookApp.token='' また、この記事では気象庁が公開している神戸市の気象データを使用します。 https://www.data.jma.go.jp/gmd/risk/obsdl/ 実行 PySparkのDataFrameを使用しSpark SQLの使い方を紹介します。 SparkSessionの作成とPySparkのDataFrameへの変換は以下のように行います （また、SparkSessionの作成時にワーカーノード上のExecutorの設定もできる） from pyspark.sql import SparkSession spark = SparkSession.builder.appName("spack test").getOrCreate() PySparkのDataFrameはpandasと同じような操作ができます df = spark.read.format("csv").option("inferSchema","True").option('encoding', 'shift_jis').option("sep",",").option("header","True").load("../data/data.csv") PySparkのDataFrameに対してSpark SQLを用いてSQLの操作を行うことができます (普通のselect３件) spark.sql("select * from data limit 3").show() +---------+--------+---------+---------+--------+---------+---------------+---------+---------+----+----------+---------------+----------+----------+ | 日時|最低気温|品質情報2|均質番号3|最高気温|品質情報5| _c6|品質情報7|均質番号8| _c9|品質情報10| _c11|品質情報12|均質番号13| +---------+--------+---------+---------+--------+---------+---------------+---------+---------+----+----------+---------------+----------+----------+ |2020/6/20| 22.7| 8| 1| 26.5| 8|2020/6/20 14:20| 8| 1|20.0| 8|2020/6/20 05:19| 8| 1| |2020/6/21| 23.7| 8| 1| 28.2| 8|2020/6/21 15:03| 8| 1|18.5| 8|2020/6/21 04:39| 8| 1| |2020/6/22| 25.8| 8| 1| 29.2| 8|2020/6/22 15:57| 8| 1|23.2| 8|2020/6/22 05:53| 8| 1| +---------+--------+---------+---------+--------+---------+---------------+---------+---------+----+----------+---------------+----------+----------+ このように普通のSQLの実行結果のように出力することができます。 結果の確認 Spark UIの「SQL / DataFrame」タブで実行情報を確認できます また、SparkSession作成時に設定したExecutor（ワーカーノード上で実行されるプロセス）などの確認はEnvironmentタブやExecutorsタブで確認することができます。 ブログ内で使用した程度のデータの規模だとSparkを使用する意味はほとんどありませんが、大きいデータになれば分散処理による工夫が必要ななるため、Sparkなどが有効になると思います。 おわりに PySparkを使用すればPandasやSQLを使うように簡単に分散処理を実行することができるので、分散処理に興味がある方や大規模なデータ分析をする方は試してみてください。 ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

はじめに 2024年6月21日に、Anthropicの新モデル「Claude 3.5 Sonnet」がリリースされました。 Claudeの最新バージョンということで、とても注目を集めています。 Claudeシリーズは他の生成AIと比較しても引け目を取らない回答精度や速度を出していますが、 3.5になりさらに回答精度や速度が向上したようです。 引用元: https://www.anthropic.com/news/claude-3-5-sonnet また、同時にArtifactsという機能も追加されました。 詳しくはAnthropic社のリリースをご参照くだ さい 今回はArtifactsを使って遊んでみたいと思います。 Artifactsとは 2024/6/21にClaude 3.5 Sonnetと一緒に追加された新機能です。 こちらはチャットの回答を拡張する機能のようです。 Claudeにコンテンツの生成を依頼すると右側に専用ウィンドウが表示され、作成物をリアルタイムで表示することができるようになりました。 また、インタラクティブにコンテンツを生成してくれるので、 生成されたコンテンツを会話をしながら確認、修正することができます。 メリット Artifactsを使うことでのメリットは以下のようになります。 簡単なコンテンツ確認: リアルタイムで生成され、即座に結果を確認することができる 専用のウィンドウに表示されるので、会話の流れを妨げることなく内容を確認できる 柔軟な編集が可能: 生成されたコンテンツについて、コメントをすることで修正や調整ができる 再利用可能な出力: コード、文書、HTMLなど多様な形式で出力されるため、様々な用途に適用可能 上記で解説した特徴やメリットをまとめると以下のようになります。（この画像もArtifactsを使って作成しました） 今回はArtifactsを使って簡単なTodoアプリを作ってみます。 2024年6月現在、Artifactsを用いたリアルタイム生成でのプレビューはHTML、CSS、JavaScriptのみのようです。 Pythonなど他の言語で実行すると、コードのみが表示され、プレビューすることができないようです。 ここは、今後のアップデートに期待ですね！ 設定 Feature PreviewからONにすれば良さそうです。簡単ですね。 Todoアプリを作ってもらう 雑にプロンプトを投げてみる まずは雑に投げてみます。Claude3.5になったということで応答精度も向上していると思います。 HTML/CSS、JavaScriptを使ってTodoアプリを作ってください 生成されたWebアプリの画面を実際に触ることができるので確認しやすいですし、 うまくいっていないところを見つけやすいです！ ここで生成されたコンテンツではinputのテキストボックスに入力しても タスクを追加できませんでした。なので、追加できるように修正してもらいます。 追加ボタンを押してもタスクが追加されません inputにテキストを入力した状態で、追加ボタンを押すと、タスクが下に表示されるようにしてください。 追加できるようにしてくれました。 もうこれで簡単なTodoアプリとしての機能は完成しました！ 一瞬で作れてしまうので便利ですね！ ただ、このままだとデザインがあまりイケてないので、 デザインをいい感じにしてくれってお願いしてみます。 デザインをもっといい感じにしてください * チェックボックスとタイトル、削除ボタンの間隔が狭すぎます * タスク間の間隔が狭いです * 削除ボタンが大きすぎます * チェックボックスが小さすぎます * タイトルが小さすぎます いい具合に綺麗にしてくれました。 この状態でも良いんですが、タスクのステータス（Todo、In Progress、Done）があると もっと良いですよね。なのでコードを修正してもらいます。 ステータスでTodo, In Progress, Doneを持てるようにしてください。 なので、チェックボックスでの管理はやめて、ステータスごとにまとめて3レーンで表示するようにしてください。 ちゃんと作ってくれました。 ステータスの状態遷移は矢印ボタンを押して遷移できるようです。 生成されたテキストを見てみると、以下のように言っているのでこちらもやってもらいましょう。 さらに機能を追加したり、デザインを調整したりする必要がある場合は、お知らせください。例えば、ドラッグアンドドロップ機能の追加や、タスクの編集機能の実装なども可能です。 ドラッグアンドドロップ機能の追加と、タスクの編集機能の実装をお願いします ドラッグ&ドロップと編集ができるようになりました！ 簡単なWebアプリであればめちゃめちゃ早く作ることができますね！ （あと内部のコードなど気にしなければ…） SVG画像とかも作れるらしい 冒頭の公式YouTubeでも最初に作っていましたが、SVG画像が作れるようです。 ということで、このWebアプリのアイコンを作ってもらいましょう。 ポメラニアンを使ったSVGアイコンを作ってください ポメラニアンの特徴を活かしたデザインをお願いします まぁまぁまぁまぁ、許容できる範囲ですね。プロンプトも雑なのでこの程度だと思っています。 これを作成したWebサイトに埋め込んでもらいます。 先ほどのTodoリストのWebサイトにこのアイコンを埋め込んでください。 タイトルの左側に丸く表示するようにしてください。 いい感じに装飾できました！ デモ 完成したTodoアプリを実際に動かしてみたいと思います！ まとめ 今回はClaude 3.5とArtifactsを使ってWebアプリを作ってみました。 ArtifactsはWebアプリだけでなく、スライド作成やSVG画像作成などさまざまな用途に使用することができます。 公式サイトにも書いてありますが、Artifacts機能が追加されたことで、Claudeがただのチャット用AIから共同作業環境へと進化したと感じました。 さまざまなアイデアを会話を通じてリアルタイムで迅速で形にすることができるのは見ていて楽しいですし、効率的にアウトプットできるなぁと思いました。 今回紹介したArtifactsはFeature Previewということで、正式リリースされていません。 こちらのブログも2024年6月末時点での情報となっております。 今後、機能変更が入る可能性がありますので注意が必要です。 ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

はじめに こんにちは。ニフティ株式会社入会システムチームのtakahataです。 GitHub ActionsからCodeBuildをAWS CLIで呼ぶ構成から、GitHub Actions self-hosted runnerでCodeBuildを呼ぶ構成とECS on Fargateを実行する構成への変更を検証した話を共有します。また、ECSを利用したself-hosted runnerの検証も実施しました。 背景 所属しているチームのWebサービスではデプロイ前のリグレッションテストとして、E2EライブラリであるPlaywrightを利用して検証環境上でブラウザテストを実行しています。 検証環境では外部からのアクセスを遮断していますが、GitHub ActionsのIPアドレスはIPアドレスリストのどのIPアドレスからアクセスされるかわからないため（ 参考 ）、GitHub Actionsが持つホストからテストを実施することができません。 そのため、現在は、GitHub Actions から AWS CLI を使ってAWS CodeBuildを実行することによって、Playwrightを実行していました。CodeBuildはVPC内で実行できるため検証環境にアクセスすることができます。 課題 現状の構成ではGitHub Actionsから見るとCodeBuildの実行に成功したことしかわからず、テストに成功したかどうかはCodeBuild上でしか確認できませんでした。 ニフティではAWSをマルチアカウントで運用しているため、テストが終わるとAWSアカウントにログインしてCodeBuildからテスト結果のレポートを確認する必要があります。 また、テスト結果をGitHub側に連携することができていないため、テスト結果を元にプルリクエストのマージを許可するといった運用ができていませんでした。 解決手段 上記課題について2通りの方法で検証を実施しましたので、以降は概要と手順について説明します。 CodeBuildのマネージド型のself-hosted runnerを利用する ECS on Fargateの実行環境を構築する CodeBuildのマネージド型のself-hosted runnerを利用する GitHub Actionsのself-hosted runnerとは、GitHubがホストしているサーバを使わず利用者が用意したサーバ上でGitHub Actionsのワークフローを実行する仕組みです。2024年4月にマネージドなself-hosted runnerの実行環境としてCodeBuildを容易に利用できるようになりました（ 参考 ）。 この対応を受け、AWS CLIでCodeBuildを実行する構成からself-hosted runnerで実行する構成に変更することを検証しました。 VPC上で動作するCodeBuildを実行環境としてGitHub Actionsのワークフローを実行することにより、GitHubのプルリクエスト等の機能と連携しながらGitHub ActionsとしてVPC内でテストを実行することができます。 対応手順 https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/action-runner.html を元に設定をしました。対応手順は大きく2つあります。 ①CodeBuildプロジェクトを作成する ②GitHubのワークフローを作成する ①CodeBuildプロジェクトを作成する CodeBuildのソースに利用したいGitHub Actionsのリポジトリを指定します。 ウェブフックイベントを以下のように設定します。ここでは複数のリソースは指定できずプライマリリソースとして上記で指定したGitHubのイベントを設定できるようです。 公式ドキュメントによるとGitHub Actionsで実行されるワークフローは workflow_jobのqueuedイベントによって実行されますので（ 参考 ）、フィルタグループのイベントタイプに WORKFLOW_JOB_QUEUED を指定します。 その他設定としてイメージファイルはPlaywrightの実行要件に指定されているUbuntuを指定しました。 それ以外にはVPC経由で実行したいためVPCやセキュリティグループを指定しました。 ②GitHubのワークフローを作成する CodeBuildのbuildspec.ymlファイルをGitHub Actions用のyamlファイルに移植しました。 self-hosted runnerの指定をするためにrunnerにCodeBuildのプロジェクト名を指定します。 name: Playwright Tests (Self-Hosted Runner) on: push: ... jobs: test: runs-on: codebuild-Codebuildのプロジェクト名-${{ github.run_id }}-${{ github.run_attempt }} ... 実行結果 GitHubが提供するホストと特に違いなくワークフローを実行することができ、VPC内部のサーバにもアクセスすることができました。 GitHub-hosted runnerとの違いとしては、CodeBuildがself-hosted runnerの実行環境を構成するために90秒ほど待ち時間が発生していました。 CodeBuildがself-hosted runnerを構成する実行ログの様子 Downloading GHA self-hosted runner binary % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 13 179M 13 24.9M 0 0 63.5M 0 0:00:02 --:--:-- 0:00:02 63.4M 55 179M 55 100M 0 0 73.7M 0 0:00:02 0:00:01 0:00:01 73.7M 100 179M 100 179M 0 0 80.5M 0 0:00:02 0:00:02 --:--:-- 80.6M Configuring GHA self-hosted runner -------------------------------------------------------------------------------- | ____ _ _ _ _ _ _ _ _ | | / ___(_) |_| | | |_ _| |__ / \\ ___| |_(_) ___ _ __ ___ | | | | _| | __| |_| | | | | '_ \\ / _ \\ / __| __| |/ _ \\| '_ \\/ __| | | | |_| | | |_| _ | |_| | |_) | / ___ \\ (__| |_| | (_) | | | \\__ \\ | | \\____|_|\\__|_| |_|\\__,_|_.__/ /_/ \\_\\___|\\__|_|\\___/|_| |_|___/ | | | | Self-hosted runner registration | | | -------------------------------------------------------------------------------- # Authentication √ Connected to GitHub # Runner Registration √ Runner successfully added √ Runner connection is good # Runner settings √ Settings Saved. Running GHA self-hosted runner binary √ Connected to GitHub GitHub ActionsがCodeBuildの実行を待っている様子 ECS on Fargateの実行環境を構築する 続いてECS on Fargateを実行する方法になります。こちらの方法では上記CodeBuildで指定していたWebhookの向き先となるサービスを自身で構築し、構築したサービス上でECSタスクの起動とself-hosted runnerへの登録をする必要があります。 また、常時ECSタスクを実行する必要はないため、コスト削減のために必要に応じてタスクを実行するように設定しています。 対応手順 AWSが提供するサービスを組み合わせて構築しています。手順は以下のようになります。 ワークフロー実行に合わせてAPI GatewayにWebhookでHTTPリクエストを実行するようGitHub上で設定 API GatewayのAWS統合でStep Functionsを実行 ※Step Functionsを利用することでタスク起動失敗時に再実行できるようにしています Lambdaを実行しWebhook検証とself-hosted runnerへの登録に必要なトークンを取得 ECSタスクを実行 ECSタスク上のコンテナでself-hosted runnerへの登録 ECSタスク上のコンテナを利用してブラウザテストを実行 ①ワークフロー実行に合わせてAPI GatewayにWebhookでHTTPリクエストを実行するようGitHub上で設定 リポジトリのSettings→WebhooksからAdd Webhookで追加できます。 Payload URLにAPI Gatewayのエンドポイント、Content typeにapplication/json、Secretに後にWebhook検証をするためのランダムな文字列を入力します。 トリガーにWorkflow jobsのみ選択します。 ②APIGatewayのAWS統合でStep Functionsを実行 Step Functionsを実行するようAPIGatewayを実行します。 ここで、統合リクエストのマッピングテンプレートを適切に設定する必要があります。ここではHTTPリクエストヘッダに含まれる「X-Hub-Signature-256」とHTTPリクエストボディを文字列にエスケープしたJSONに変換しています。「X-Hub-Signature-256」はWebhookの検証に必要です。 { "stateMachineArn": "arn:aws:states:[Step FunctionsのARN]", "input" : "{\\"secret\\": \\"$input.params().get('header').get('X-Hub-Signature-256')\\", \\"body\\": $util.escapeJavaScript($input.json('$')) }" } Step Functionsは以下のようなフローになっています。Webhookからイベントを特定し、イベントがqueued（ワークフロー作成された際に発行されるイベント）である場合のみLambda実行に分岐し、それ以外のイベントの場合はなにもせずに終了します。 ③Lambdaを実行しWebhook検証とself-hosted runnerへの登録に必要なトークンを取得 作成したAPI Gatewayはどこからでもアクセスできてしまうため、最悪の場合大量アクセスにより大量にECSタスクが実行できてしまいます。そのため、WebhookがGitHub Actionsから呼ばれたものか検証する必要があります。 詳細については https://docs.github.com/ja/webhooks/using-webhooks/validating-webhook-deliveries を参照ください。 API Gatewayから取得されたHTTPリクエストボディに ①で設定したSecretを利用してハッシュ値を計算し、「X-Hub-Signature-256」と一致しているか検証しています。SecretはSSM Parameter Store等で管理します。 ここで単純にLambdaのeventでHTTPリクエストボディを渡してしまいますと各Lambdaランタイム言語の辞書型に変換されてしまいますので、文字列として渡してあげる必要があります。一度辞書型になってしまうと文字列に再変換したときに検証がうまくいきませんでした。 また、self-hosted runnerに登録するには一時的なトークンを取得する必要があります。トークンを発行するにはREST APIを実行する必要があります（ 参考 ）。REST APIの実行に必要なGitHubのPersonal Access TokenもSSM Parameter Storeから取得します。 ④ECSタスクを実行 ECSタスクを実行します。この際に③で取得したトークンを連携します。 ⑤ECSタスク上のコンテナでself-hosted runnerへの登録 ECSタスク上でトークンを利用してself-hosted runnerへ登録を行います。 詳細については https://docs.github.com/ja/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners を参照ください。 コンテナイメージ上で依存関係のインストール、設定更新、self-hosted runnerへの登録を用意されたシェルスクリプトを使って実行します。 詰まったポイントとしては実行者をrootユーザーと一般ユーザーで実行を分ける必要があること、今後GitHub Actions上で利用するコマンドが使えるようにしておくことです。 今回のケースではgit checkoutをするためにgitのパッケージが必要でした。また、一般ユーザーからsudoする場合にパスワードが求められないようにするためNOPASSWDの設定であったり、ホームディレクトリの作成が必要であったりしました。 # サンプル FROM ubuntu:24.04 RUN apt update && apt-get -y install curl sudo git RUN mkdir /actions-runner RUN useradd runner -m RUN echo 'runner ALL=NOPASSWD: ALL' >> /etc/sudoers RUN chown runner /actions-runner USER runner WORKDIR /actions-runner RUN curl -o actions-runner-linux-x64-2.317.0.tar.gz -L <https://github.com/actions/runner/releases/download/v2.317.0/actions-runner-linux-x64-2.317.0.tar.gz> RUN tar xzf ./actions-runner-linux-x64-2.317.0.tar.gz USER root RUN ./bin/installdependencies.sh USER runner COPY ./register.sh /actions-runner/ CMD [ "bash", "/actions-runner/register.sh" ] register.shでは以下のように設定しています。必要なオプションを指定しないとインタラクティブに入力を求められますのでコマンド内で全て指定します。 ここで「 --ephemeral 」オプションをつけることでタスク実行完了時に自動でself-hosted runnerからの登録を解除してくれるため、使い回されることなく使い捨てでコンテナを利用できます。 #!/bin/sh NOW=`date '+%Y%m%d%H%M%S'` ./config.sh \\ --url $GITHUB_URL \\ --token $TOKEN \\ --ephemeral \\ --disableupdate \\ --name runner_$NOW \\ --runnergroup Default \\ --labels self-hosted \\ --work _work ./run.sh ⑥ECSタスク上のコンテナを利用してブラウザテストを実行 ブラウザテストの実行はCodeBuildと同じですので割愛します。 実行結果 結果についてもCodeBuild同様特に問題なく動作することができましたので割愛します。 まとめ 今回VPC内部でPlaywrightをしたいという課題に対して、「CodeBuildのマネージド型のself-hosted runnerを利用する」「ECS on Fargateの実行環境を構築する」という2通りの手段を検証しました。 これまでself-hosted runnerをVPC内で実行するためにはEC2やECS等で環境を用意する必要がありましたが、self-hosted runnerにマネージドで対応したCodeBuildを利用することで簡単に実行環境を構築することができましたので、構築の手軽さという点ではCodeBuildを使う利点があると思いました。 一方で、ECS on Fargateの実行環境を構築する手法は構築が大変であるものの、コストの点で利点があります。東京リージョンのx86アーキテクチャで比較するとCodeBuildの最も安価であるgeneral1.smallが1分あたり0.005USDであるのに対して（ 参考 ）、同等スペックの2vCPU、メモリ4GBのFargateは(0.05056×2vCPU+0.005534×4GB)/60分 = 0.002054USDと単純計算ではありますが半額程度のコストで実行できます。またFargateの場合はより低いスペックでも稼働できますのでスペックを必要としない場合はさらにコスト削減できると思います。 実際にself-hosted runnerを構築することでマネージド型のありがたみを時間しました。両手法についてぜひ試してみてください。 ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

この記事は、リレーブログ企画「チーム紹介」の記事です。 ニフティでシニアエンジニアをしている伊達です。今回は、私がEMをしている第一開発チームを紹介いたします（伊達については 社員インタビュー をご覧ください）。 第一開発チームとは 第一開発チームはいくつかの役割を持っています。 一つ目は、 @niftyトップページ 、 @nifty天気予報 、 @niftyビジネス といった@niftyの接続会員のお客様向けのポータルサイトや有償コンテンツ、あるいは ニフティキッズ のような広く子どもたちのためのサイトの開発と運用をしています。 二つ目は、静的なサイトを運用するためのCMS基盤の提供です。@niftyトップページはNext.jsのアプリケーションとして開発しているのに対して、こちらはコンテンツの管理や静的ページの生成の機能をニフティ社内のサイト運用者向けに提供しています。 こちらは旧来のCMS基盤から新基盤への移行が進んでおり、以下の記事に詳しいです。 自社製CMSで動かしていたサイトをmicroCMSへ移行した話 三つ目は、エンジニア向けのツールや基盤の提供です。GitHub、Notion、Zapier、Pingdomといったエンジニアの業務に必要なSaaSの管理や利用促進を行ってます。 最後に四つ目として、全社へのSRE推進も行っています。詳しくはインタビュー記事をご覧ください。最近はPagerDutyを重要なサービスに導入して障害からの復旧を早くする活動などを行っています。 【インタビュー】ニフティのSREに聞く！インターネット黎明期から安心・安全を体現してきたニフティが2023年に取り組んでいるSREとは？【SRE前編】 レガシーとの戦い やっていることは多岐に渡っていますが、ここ数年行っていることは「レガシーなシステムや仕組みを新しいシステムや仕組みに変えていくことで、素早く開発してお客様に価値を届けられるチームにしよう」ということです。 @niftyトップページ、 @search 、@nifty天気予報などは、2000年代に作られたシステムを適宜メンテナンスしながら使ってきました。サイトを運用するという面では問題なかったのですが、Core Web Vitalsのようなユーザ体験の指標を改善するには最近のフロントエンド技術の採用が近道ですし、機能開発を素早く行うにはGitHub/GitHub Actionsを活用した開発・CI/CDフローに適したシステムである必要がありました。こういった技術的負債の解消のため、チーム内で要件定義や技術選定から行って順次新しいシステムに置き換えています。 結果、クラウドにはAWS、フロントエンドにはReact/Next.js/TypeScript、バックエンドにはGo、IaCにはTerraformを採用することが多く、チーム内での共通の技術スタックが徐々に整いつつあります。 システムは作ったときからレガシー化が始まります。せっかく刷新したシステムが誰もわからない、手を入れられない代物にならないようにする取り組みもしています。 ドキュメントの面ではDesign Docs、ADRを作るようにしており、なるべくドキュメント作成を軽量にしながら意図を残そうとしています。 ADRについては以下の記事を参照ください。 意思決定を記録するArchitecture Decision Record (ADR)の話 さて、今回はチームの役割と最近の取り組みについて紹介しました。また機会があればプロダクトやメンバーについて紹介したいと思います。 次回のチーム紹介記事は同じ会員システムグループの第二開発チームの松尾さんです。 ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

はじめに Windows 運用しているとPowersShellでスクリプトを書くことがあります。 スクリプトを書くなら、ユニットテストは自動化したいですよね？ そこで、PowerShellの標準モジュールであるPesterについて紹介します。 現在Pesterはv5 が最新バージョンですが、古いPowersShell(5.x.x系など)はv3がインストールされています。 構文や使える機能が若干異なるので、利用する前に必ず確認しましょう。 Pesterについて 公式ドキュメントは以下を参照してください。 V5： https://pester.dev/docs/quick-start V4： https://pester.dev/docs/v4/quick-start V3： https://github.com/pester/Pester/wiki/Should-v3 ちなみにPesterは「しつこくせがむ」「うるさくせがむ」みたいなニュアンスらしいです。 「全てがgreenになるまで根気強くテストせよ」みたいな意味なんですかね。 Pesterの使い方 pesterのバージョン確認のコマンドは以下の通りです。 今回は5系を使用します。 ❯ Get-Module -ListAvailable -Name Pester Directory: C:\Users\sci02118\Documents\PowerShell\Modules ModuleType Version PreRelease Name PSEdition ExportedCommands ---------- ------- ---------- ---- --------- ---------------- Script 5.6.0 Pester Desk {Invoke-Pester, Describe, Context, It…} ディレクトリ構成は以下の通りです。 │ ├ Functions.ps1 └ Functions.Tests.ps1 テスト実行時は以下のようにします。 Invoke-Pester .\Functions.Tests.ps1 各ファイルの中身は以下の通りです。 ・Functions.ps1 # 関数やオブジェクトを宣言するファイル function Get-Planet ([string]$Name = '*') { $planets = @( @{ Name = 'Mercury' } @{ Name = 'Venus' } @{ Name = 'Earth' } @{ Name = 'Mars' } @{ Name = 'Jupiter' } @{ Name = 'Saturn' } @{ Name = 'Uranus' } @{ Name = 'Neptune' } ) | ForEach-Object { [PSCustomObject] $_ } $planets | Where-Object { $_.Name -like $Name } } ・Functions.Tests.ps1 # 同じディレクトリにある同名ファイルを呼び出して関数をImportする BeforeAll { . $PSScriptRoot\Functions.ps1 } # テスト定義 Describe 'Get-Planet' { It 'Given no parameters, it lists all 8 planets' { $allPlanets = Get-Planet $allPlanets.Count | Should -Be 8 } } テスト定義については、書き方の構文が決まっています。 # Desctibe はテストの説明です。基本的にはどのメソッドをテストするかが書かれます。 Describe 'Get-Planet' { # It はテストケースの説明です。 It 'Given no parameters, it lists all 8 planets' { $allPlanets = Get-Planet # テスト結果を比較します。 # Should の右側に期待する値を書きます。 # 今回の場合、実行結果として8つのオブジェクトが返ってくることを期待しています。 $allPlanets.Count | Should -Be 8 } } テスト結果を取得するshoudについてはバージョンによって構文が異なります。 公式ドキュメントを確認して、適切な値で書いてください。 実行するときは Invoke-Pester コマンドを使います。 Invoke-Pester .\Functions.Tests.ps1 Describing Get-Planet [+] Given no parameters, it lists all 8 planets 52ms Tests completed in 52ms 試しに失敗するテストを書いてみます。 Functions.Tests.ps1を以下の通り修正します。 # 同じディレクトリにある同名ファイルを呼び出して関数をImportする BeforeAll { . $PSScriptRoot\Functions.ps1 } # テスト定義 Describe 'Get-Planet' { It 'Given no parameters, it lists all 8 planets' { $allPlanets = Get-Planet $allPlanets.Count | Should -Be 8 } } Describe 'Get-Planet-Failed' { It 'Given no parameters, it lists all 6 planets' { $allPlanets = Get-Planet # 要素数を6に変更(本来の返り値は8) $allPlanets.Count | Should -Be 6 } } 実行してみます。 Invoke-Pester .\Functions.Tests.ps1 Describing Get-Planet [+] Given no parameters, it lists all 8 planets 71ms Describing Get-Planet-Failed [-] Given no parameters, it lists all 8 planets 92ms Expected: {6} But was: {8} 19: $allPlanets.Count | Should Be 6 at <ScriptBlock>, C:\Users\sci02118\dev\pester\Functions.Tests.ps1: line 19 Tests completed in 164ms Passed: 1 Failed: 1 Skipped: 0 Pending: 0 Inconclusive: 0 2個目のテストが失敗していることがわかりますね。 コードブロックだとわかりにくいですが、実際のpowershellはcolor表示してくれるのでだいぶ見やすくなっています。 おわりに 今回はpowershellの標準モジュールであるPesterの使い方について紹介しました。 ユニットテストを実施する時にぜひ使ってみてください。 ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

ニフティ株式会社でシニアエンジニアしています芦川です。今回は、最近調べた開発生産性の中で語られるフロー状態について書きます。 要約 エンジニアの開発生産性を向上させるためには、「開発集中時間」を確保することが不可欠です。この集中時間とは、エンジニアが中断なく作業を遂行できる時間のことで、これにより作業に没頭できているフロー状態に入ることができます。フロー状態に入るには、コンテキストスイッチをなくすことが重要であり、１つの実践例では、slackやメールの未読表示をOFFにすることで集中時間を確保できます。 開発集中時間とは 開発集中時間とは、エンジニアが中断なく作業を遂行でき、フロー状態となる時間のことを指します。フロー状態とは、作業に没頭し、時間の経過を忘れるほどの集中状態を意味します。 開発者の生産性は複数の指標を持って測るべきと書いてある、 「SPACE」フレームワーク の中でもフロー状態の重要性について触れられています。 Some research associates productivity with the ability to get complex tasks done with minimal distractions or interruptions. 2   This conceptualization of productivity is echoed by many developers when they talk about “getting into the flow” when doing their work —or the difficulty in finding and optimizing for it, 　一部の研究では、開発生産性を『気を散らせず中断を最小限に抑えながら複雑なタスクを完了する能力』と関連付けています。この生産性の概念については、多くの開発者が、フロー状態に入り最適化することの難しさを共感しています。」 h ttps://queue.acm.org/detail.cfm?id=3454124 この状態に入るためには、少なくとも1時間以上の連続した作業時間が必要です。例えば、「1時間の作業+1時間のMTG+1時間の作業」と「2時間の作業+1時間のMTG」では、後者の方が集中度が高くなります。つまり、作業時間を1日の中でどれだけ確保できるか、ではなく、どれだけ連続した時間で確保できるか、ということになります。 「 なぜ、エンジニアの”フロー状態”は見落とされるのか？ 継続的なフロー状態が開発生産性を高める 」の中でさらにまとめられている記述があるのでご参考ください。 つまり、ミーティングとミーティングの間に1時間が2つある状態の開発生産性と、2時間まとまった空きがある状態での開発生産性は等価ではありません。その時間の連続性が非常に重要です。 https://codezine.jp/article/detail/19022 コンテキストスイッチの影響 エンジニアが現在取り掛かっているタスクの作業中に他のタスクを行うと、コンテキストスイッチが発生し、脳にストレスがかかります。これにより集中が途切れたり、あとあと疲労を感じやすくなったりするかと思います。以下のような要因がコンテキストスイッチを引き起こします。考えられる要因としては数限りなくあると思います。 Slackやメールの未読数表示を気にしてしまい、ついついタスクを中断し、そちらを読んでしまう。 デスクトップ通知に気を取られてしまう。 オフラインで急に声をかけられてしまい、タスクが中断する。 システムから通知されるメッセージが常に多く気になってしまう。 急なMTG招集があり、タスクを中断する。 トラブルが発生し、そちらの対応を優先することになる コンテキストスイッチをまるでなくすには、１人でそもそも完結する仕事の仕方をしていなくてはなりませんが、チームで開発していたり、システムの運用保守もする立場では、ある程度その時に必要なコミュニケーションや、急なアラート対応は見過ごすわけにはいきません。 とはいえ、日々、 工夫することで、自身やチームの開発集中時間を確保することはできる と思います。 コンテキストスイッチを減らす方法 ここでは、私が実践している、しようとしている方法をいくつか紹介します。 Slackの未読表示や通知の無効化 デスクトップアプリのSlackの未読表示や通知を無効にします。これにより、作業中に通知が気になって中断することがなくなりました。何名かのメンバーにも試してもらいましたが反応は上々です。Windowsでは以下のように設定できます。 　 注意として、数時間全くSlackを見ないようになってしまっては、緊急のシステムアラートや連絡について無頓着になってしまうので、それはだめということです。私は30分-1時間の作業の間に意図的な休憩時間を5分設け、その間にSlack通知を確認するようにしています。（フロー状態と言っても適切な休憩時間は取ってくださいね！） チームでの改善策 システムアラートを見て常に作業が中断してしまうようであれば、システムアラートの量やレベルの最適化がもしかしたらできてないこともありそうです。つまり、INFOレベルの通知の量が多かったり（都度見る必要はない）、調査や対応不要なシステムアラートもCRITICALレベルで通知しているかもしれません。（WARNレベルでよい）このあたりは、SREでのトイルマネジメントにも共通するところであり優先度をあげて対応したほうがよいと思います。 もう1つ、これから実践してみようと思うことに、MTGのクラスタリング化があります。こちらはまだ実施前ですが、会議を 2 ～ 3 時間の枠にブロックし、残りの時間はMTGを入れずに作業時間に充てるようにします。これをチームとして意図的に設定します。例えば、スクラム開発では、プランニングやタスクリファインメントなどイベントが数多くありますが、それらは小分けにせず（適切な休憩時間を持って）集中的に行うようにし、また、開発以外のチーム会など開催時間も午後のど真ん中にやるのではなく、1日の最後にするなど、連続する作業時間の確保については組織的に工夫できるところはあると思います。 まとめ 今回はフロー状態について書きました。エンジニアの開発生産性を向上させるためには、開発集中時間を確保し、コンテキストスイッチを減らすことが重要です。個人としてできる対策や、チーム全体での改善策を実践することで、より効率的で満足度の高い開発環境を作りましょう。そして生産的で充実したエンジニアライフを送りましょう！ We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering

こんにちは。NIFTY engineeringブログ運用チームです。 ブログ運用チームでは、ニフティのエンジニアについての情報を世の中に広めるための活動をしています。 その活動の一環として、リレーブログを実施します！ リレーブログ第一弾のテーマは「チーム紹介」です。 本記事に、チーム紹介記事のリンクをまとめていきますので、ぜひチェックしてください。 また、既にチーム紹介記事が投稿されているチームもありますので、そちらもあわせてチェックしていただければと思います！ 基幹システムグループ 入会システムチーム サービスインフラチーム 課金システムチーム 会員システムグループ 第三開発チーム インフラシステムグループ インフラチーム チーム紹介記事は以下のスケジュールで投稿予定です。お楽しみに！ 投稿予定 チーム名 2024年6月 会員システムグループ　第一開発チーム 2024年7月 会員システムグループ　第二開発チーム 2024年8月 インフラシステムグループ　業務支援チーム 2024年9月 インフラシステムグループ　情報システムチーム ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

参加登録はこちらから (connpass)2つのスクラムチームの調和的な協働・連携について ニフティのスクラムトーク vol. 3 イベント概要 NIFTY Tech Talkは、ニフティ株式会社の社員が主催するトークイベントです。 本イベントでは、ニフティグループの社員が業務を通じて学んだことを発信しています！ テーマ NIFTY Tech Talkでスクラムにテーマを絞った「ニフティのスクラムトーク」シリーズが始まりました。 Vol 3となる今回は、社内のスクラムチームが協力会社との連携を円滑に行うためのノウハウを紹介します。 スクラム開発では、自律的で生産性の高いチーム運営が重要です。 コミュニケーションの取り方、優先順の決め方、POとの連携など、協力会社との協働を最大限に活かして、より生産性を高められるよう実践していることについてお話します。 協力会社との融和を図り、高パフォーマンスを発揮するチーム作りのヒントが得られるはずです。 スクラム開発に携わる方・SES契約を検討している方は、ぜひご参加ください。 過去のニフティのスクラムトークはこちら スクラムマスターの技を磨く！ ニフティのスクラムトーク vol 1 / 動画 ( Youtube ) スクラムマスターによるチーム改善LT！ ニフティのスクラムトーク vol 2 / 動画 ( Youtube ) 開催概要 ※オンライン配信のみです 日程：6月18日（火）12:00〜13:00 YouTube Liveで配信 こんな方におすすめ チームの体制について興味がある方 協力会社とのスクラムの進め方に興味がある方 スクラムイベントのやり方・連携について興味がある方 タイムテーブル 時間 コンテンツ 12:00 – 12:10 オープニング 12:10 – 12:50 LT1 ニフティと協力会社のスクラムの形 12:50 – 13:00 クロージング 登壇者プロフィール 南 奈歩（登壇者） ニフティ株式会社 基幹システムグループ 入会システムチーム 新卒入社5年目。@nifty光をはじめとする光コラボシステムの開発・運用・運用改善・刷新などを担当し、スクラムマスター兼開発者として日々活動しています。 高田 渉（登壇者） ニフティ株式会社 基幹システムグループ 入会システムチーム @nifty光などの開発チームのサブチームリーダーを担当しています。 ニフティグループでは一緒に働く仲間を募集中です 新卒採用、キャリア採用を実施しています。ぜひ リクルートサイト をご覧ください。 ニフティエンジニアが業務で学んだことやイベント情報を エンジニアブログ にて発信しています！ ニフティエンジニアのX(旧Twitter)アカウント NIFTY Tech Talkのことや、ニフティのエンジニアの活動を発信していきます。 https://twitter.com/NIFTYDevelopers アンチハラスメントポリシー 私たちは下記のような事柄に関わらずすべての参加者にとって安全で歓迎されるような場を作ることに努めます。 社会的あるいは法的な性、性自認、性表現（外見の性）、性指向 年齢、障がい、容姿、体格 人種、民族、宗教（無宗教を含む） 技術の選択 そして下記のようなハラスメント行為をいかなる形であっても決して許容しません。 不適切な画像、動画、録音の再生（性的な画像など） 発表や他のイベントに対する妨害行為 これらに限らない性的嫌がらせ 登壇者、主催スタッフもこのポリシーの対象となります。 ハラスメント行為をやめるように指示された場合、直ちに従うことが求められます。ルールを守らない参加者は、主催者の判断により、退場処分や今後のイベントに聴講者、登壇者、スタッフとして関わることを禁止します。 もしハラスメントを受けていると感じたり、他の誰かがハラスメントされていることに気がついた場合、または他に何かお困りのことがあれば、すぐにご連絡ください。 ※本文章は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/ ) で公開されています。

はじめに 相変わらずCDKを触る機会が多めな宮本です。今回は比較的最近リリースされたばかりのCloudFront KeyValueStoreのCDK管理についての記事です。待望のCloudFront Functionsで使えるデータストアということで無邪気に喜んでましたが、IaCで管理しようとすると結構癖がありました。 CloudFront KeyValueStore Amazon CloudFront KeyValueStoreは、CloudFront Functions内で利用可能なその名の通りキーバリュー方式のデータストアです。リリースされたのも昨年と、かなり新しいサービスです。 今までCloudFront Functions上で扱うデータは、CloudFrontから渡されるリクエストまたはレスポンス情報を除きコードに直書きする以外に保持する術がありませんでした。そのため、たとえばパスごとのリダイレクト情報を複数書こうとすればそれだけコード行数が膨大になり、コードの挙動そのものがどんどん下の方に追いやられ可読性が落ちるという問題がありました。 KeyValueStoreが登場したことで、CloudFront Functionsでもロジックとデータを完全に分離することが可能になりました。データとロジックを混在させなければならないという部分に正直辟易としていたので、この機能追加はとてもありがたいです。 詳しくは 公式ドキュメント や こちらの記事 をご覧ください。 コード 実装してみたコードの紹介です。PythonのCDKを用いて記述しています。 また、省略のためにCloudFront FunctionとKeyValueStoreの作成のみ実施しています。 import json import random import string from aws_cdk import aws_cloudfront as cloudfront # functionのコードにKVSのIDを埋め込むためにファイル読み込み cloudfornt_function_src_path = "src/index.js" with open(cloudfornt_function_src_path, "r") as file: file_content = file.read() # json形式のvalueを文字列化するためにファイル読み込み kvs_file_path = "kvs.json" with open(kvs_file_path, "r") as file: row_kvs_items = json.load(file) kvs_items = [ { "key": kvs_item["key"], "value": json.dumps(kvs_item["value"], separators=(",", ":")), } for kvs_item in row_kvs_items ] def rand_suffix(seed: str): """ kvs名のsuffix用ランダム文字列を生成する関数 seedを与えることでkvsのデータが変わらない場合は同じsuffixが生成されるようにする """ random.seed(seed) suffix = "".join(random.choices(string.ascii_letters + string.digits, k=4)) # seedをリセット random.seed() return suffix class CloudFrontStack(Stack): def __init__( self, scope: Construct, construct_id: str, **kwargs ) -> None: super().__init__(scope, construct_id, **kwargs) # KVSの初期値文字列作成 kvs_source = json.dumps({"data": kvs_items}) keyValueStore = cloudfront.KeyValueStore( self, "KeyValueStore", # KVSのsuffixとしてKVSに格納する値をseedとしたランダム文字列を生成 # 格納する値が変わった場合にKVSの名称を変更して再デプロイする key_value_store_name=f"kvs-{rand_suffix(kvs_source)}", source=cloudfront.ImportSource.from_inline(kvs_source), ) cf_func = cloudfront.Function( self, "CFFunc", key_value_store=keyValueStore, code=cloudfront.FunctionCode.from_inline( code=file_content.replace( "<KEY_VALUE_STORE_ID>", keyValueStore.key_value_store_id ) ), runtime=cloudfront.FunctionRuntime.JS_2_0, ) function_associations = [ cloudfront.FunctionAssociation( event_type=cloudfront.FunctionEventType.VIEWER_REQUEST, function=cf_func, ) ] CloudFront Functionsのコード import cf from "cloudfront"; const kvsId = "<KEY_VALUE_STORE_ID>"; // This fails if the key value store is not associated with the function const kvsHandle = cf.kvs(kvsId); async function handler(event) { const request = event.request; const key = request.uri; let value; try { value = await kvsHandle.get(key, { format: "json" }); } catch (err) { value = ""; } console.log(value) // 処理いろいろ return request; } KeyValueStoreの初期値を入れたjsonファイルの例 [ { "key": "/hoge", "value": { "url": "https://example.com/hoge", "statusCode": 301, } }, { "key": "/fuga", "value": { "url": "https://example.com/fuga", "statusCode": 302, } }, ] CDKによる管理 他のリソースと同じく、CDKを用いてCloudFront KeyValueStoreの操作が可能です。が、いくつか欠点もとい注意点があります。先に示したコードでは、その対策を入れています。 CloudFront Functions側からの指定がコード直書き以外不可 CloudFront Functions側からvalueをjson文字列として読み込むことはできるが、初期値のファイル投入時には必ず文字列として投入する必要がある CDKからはKeyValueStoreに保存されたデータの更新をする方法がない CloudFront Functions側からの指定がコード直書き以外不可 これについては、すでに クラスメソッドさんの記事 に対策がまとまっています。Cloudfront Functions内からKeyValueStoreにアクセスするために、IDを指定する必要があります。しかしこのIDはKeyValueStoreのリソースが作成されなければわからず、その上でコードに直書きする必要があるので、デプロイ時にコードに埋め込むように実装する必要があります。 CloudFront Functions側からvalueをjson文字列として読み込むことはできるが、初期値のファイル投入時には必ず文字列として投入する必要がある KeyValueStoreのValueがjsonとして解釈することができる場合、CloudFront Functions側でjsonを解釈したobjectとして読み込むことができます。しかし初期値として投入する場合は、あくまでvalue部分は文字列である必要があります。 文字で書くとわかりづらいですが↓ということです。 // 以下のようなデータをKeyValueStoreの初期値として入れたい場合は {"hoge":{"fuga":"hogefuga"}} // この形式のjsonファイルを用意する必要がある { "data": [ { "key": "hoge", "value": "{\"fuga\":\"hogefuga\"}" } ] } jsonファイルを使ってKeyValueStoreの初期値を管理することができるのは便利なのですが、valueにjsonを入れたい場合は文字列化する必要があるのが厄介です。折角jsonファイルで管理できると思ったのに、見づらくなってしまいます。このあたりはCDKなので、前処理としてjsonファイルを読み込んで文字列化することで解決できます。 一方で、valueに入れるのがただの文字列である場合は以下の変換は不要です。 ImportSource.from_asset() を使うことで、直にファイルを指定し読み込むことができます。ただし、この初期値を入れたファイルの内容を変更する予定があるのであれば、後述のエラー対策として、ファイルデータ自体は読み込みハッシュ値などを使ってseedとして利用することが良いと思います。 kvs_items = [ { "key": kvs_item["key"], "value": json.dumps(kvs_item["value"], separators=(",", ":")), } for kvs_item in row_kvs_items ] CDKからはKeyValueStoreに保存されたデータの更新をする方法がない これはさらに厄介です。例えばKeyValueStoreでリダイレクトルールを管理しようとした場合、IaCで管理するならルール自体もファイルに保存しておきたいです。しかし、このKeyValueStoreの初期値を決めたファイルに変更を加えた場合、次のようなエラーが発生して更新ができません。 CloudFormation cannot update a stack when a custom-named resource requires replacing. Rename <KVS名> and update the stack again. これについては、少々強引ですが初期値を変えるたびに毎回KeyValueStoreの名称を変えて作り直すと解決するようです。 参考にしたコード では毎回ランダムに名前を割り振っていましたが、初期値を定義するjsonファイルの内容をseedにすることで、値が変わらない限り無駄なデプロイが走らないようにすることが可能です。 ただし、この時完全にKeyValueStoreは作り直しになるため、もしコンソールやSDKから内部の値を変更していた場合は完全に失われてしまうためご注意ください。 また、今回はPythonでCDKを書いているため簡単にseedの指定ができます。一方でJavaScriptではデフォルトで乱数のseedを固定することができないため、追加でライブラリを入れる必要がありさらに一手間必要です。 さいごに 現時点でCloudFront KeyValueStoreをCDKで管理する方法についてまとめました。機能としてはありがたいのですが、若干引っかかるポイントが多く今後改善されると嬉しいです。 ちなみに今回はCDKで紹介しましたが、一応TerraformでもKeyValueStore自体の作成は可能です。ただし、初期値として投入できるファイルを指定することはできません。 issue は出ているので、早めに追加されると嬉しいです。 参考 Amazon CloudFront KeyValueStore – Amazon CloudFront CloudFront KeyValueStoreがリリース。CloudFront Functionsからキーバリューストアを利用可能に！ | DevelopersIO AWS CDK v2.124.0 で CloudFront KeyValueStore の Functions への関連付けがサポートされました | DevelopersIO [New Resource]: Amazon CloudFront KeyValueStore · Issue #34512 · hashicorp/terraform-provider-aws Replacing custom paths results in CFN update error · Issue #2 · ssennettau/CloudFrontRedirector-Construct [Enhancement]: Add support for import_source for aws_cloudfront_key_value_store · Issue #36524 · hashicorp/terraform-provider-aws ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する