はじめに こんにちは！新卒入社3年目の塩田です。社内システムの開発・運用を担当しています。 先日「 NIFTY Tech Talk #2 SRE【ポストモーテム・品質向上】 」に登壇しましたので、 その様子を紹介していきます！ イベント概要 NIFTY Tech Talk は、ニフティ株式会社の社員が主催するトークイベントです。 本イベントではニフティ社員が業務を通じて学んだことを発信しています。 第二回目となる今回は、「SRE」というテーマに沿って座談会を開催しました。 テーマ1：「チームでポストモーテムをどのようにしているか！？」 テーマ2：「ポストモーテム導入後の効果は？」 テーマ3：「障害の備えとしてロールプレイングした話、どのように周囲を巻き込んでいったか」 テーマ4：「品質への取り組み、自動化や耐障害性について」 イベントの詳細については こちら の記事でも紹介しておりますので、ぜひご覧ください。 また、今回の Tech Talk の録画を YouTube にアップロードしております。 こちらもご覧いただけますと幸いです。 SRE とは？ SRE とは、Google が提唱したエンジニアのシステム運用論です。 詳しい内容については Google のページ をご参照ください。 内容レポート オープニング + 会社紹介 はじめに会員システムグループグループ長 小松より、ニフティの会社紹介、ニフティでの SRE に対する取り組みなどを紹介しました。 ニフティでの SRE 活動は、各チーム内で SRE 担当を決め、SRE 推進チームが全体のサポートを実施しています。 SRE 推進チームが行っているのは「Embedded SRE」で、各チームで担当者が実施しているのは「The Google Model」というものになります。ニフティではこの組み合わせで浸透を進めています。 テーマ1：「チームでポストモーテムをどのようにしているか！？」 早速本題に入ります。 まず一つ目のテーマ「ポストモーテムの運用形態」についてディスカッションしました。 そもそもポストモーテムとは、障害報告書とは違い、読み手として現場のエンジニアを対象としている障害振り返りドキュメントのことを指します。 ディスカッション内では、ポストモーテムを導入した目的や、ポストモーテム共有会の実施方法、実施時の工夫点などが会話されました。 障害対応を実施した方には大きな負担がかかるため、精神的な支援も含めた体制づくりを心掛けているチームもあり、とても参考になりました。 ディスカッション内で話された、導入、運用状況を一部抜粋して紹介します。 <舟久保> 根本原因の検討、ドキュメント化を主な目的として導入しました。スクラム開発手法を導入していますが、障害が発生した際はスクラムイベントとは別で組み込んでいます。 <浅見> ポストモーテムにはインパクトや根本原因などを調べてドキュメント化する必要がありますね。 <舟久保> 私のチームでは、根本原因や対応の項目はチームで話し合って書くようにしています。 … <浅見> 定期的なポストモーテム共有会を開くのも重要です。隣のチームに対して、自分の担当サービスではこんな障害が発生していてこんな対応をしていますという共有ができると、勉強にもなっていいと思います。 また、障害対応を頑張った人を MVP として表彰し、ピアボーナスを贈るといったこともしています。 <舟久保> ドキュメント化する際は、タイムラインを作成する必要があるなど負担がかかりますね。 <浅見> SRE 本（https://sre.google/books/）にも障害対応をした人にご褒美をあげるべき！と強く書かれていたので、導入しました。 共有会で MVP 表彰を取り入れ、ピアボーナスを贈る文化を形成しているチームもあり、とても興味深いですね。 テーマ2：「ポストモーテム導入後の効果は？」 2つ目のテーマ「実際にポストモーテムを導入して感じた効果」について紹介します。 ポストモーテムを導入することによってノウハウが見やすい形で多くの人に共有され、後の振り返りがしやすいという意見が挙げられました。 現在ニフティではチーム単位でのポストモーテム共有会にとどまっていますが、ドキュメントとしては全社員が見られる環境が整ってきています。今後はより大きい範囲で共有会を実施できる体制を整えていきたいですね。 <舟久保> 障害対応時に獲得できる重要な知見が集まるのがメリットかと思います。タイムラインを見れば全体の流れがつかめるので、当事者ではなくても重要な場所が分かります。共有会を実施することで、システムだけではなく運用面やチーム体制などの改善点が見えてきます。 <川上> 無意識に手を入れるのを避けてしまっている部分はあるので、ポストモーテムを見返すことで改めて見つめなおすきっかけになりますね。 … <塩田> ノウハウが蓄積されるのが大きなメリットに感じています。エンジニア歴が短い社員にとってはノウハウが蓄積されている場がまとまっていると、見返すことで自分自身の成長につなげていけると思います。 <浅見> ポストモーテム共有会を実施していく中でも、共有会で得られたノウハウを各チームで実践した結果障害を防ぐことができているという効果が少し感じられる気がします。 テーマ3：「障害の備えとしてロールプレイングした話、どのように周囲を巻き込んでいったか」 3つ目のテーマは「障害ロールプレイング」についてです。 障害が発生した際の対応マニュアルを作成するのは一般的ですが、いざ障害が発生してみると予測できていなかった事態が発生するのは珍しいことではありません。 事前にロールプレイングをしておくことで、不測の事態を防ぐことができます。 実際にロールプレイングを実施した際のコミュニケーションの様子をご紹介します。 事象発覚から関係者連絡、担当アサイン、その後の対応とスムーズに進んでいる様子が分かります。 ファシリテーター 浅見が SRE NEXT 2022 に登壇した際に上記の内容を発表しておりますので、 こちら もぜひご覧ください。 ディスカッション内でもいくつかロールプレイングを実施した体験談が話されましたが、事前に準備していたマニュアルでは対応しきれない部分がいくつか発生し、見直しにつながったとの意見が多数上げられました。 また、障害ロールプレイングは実施するのにコストがかかるという相談もありましたが、過去に発生した障害をトレースすることから始めるのがいいといった声もあり、参考になりました。 以下、ディスカッションの内容も抜粋してご紹介します。 <塩田> 社内勉強会がきっかけとなり「Slack で障害が発生した際のロールプレイング」を実施しているチームがあります。実際に障害が発生した際にパニックになることを防ぐこと、事前に設定していたフローに考慮漏れがないかをチェックすることを目的として実施しています。実施した結果、代替ツールの仕様が変更されていることにより若干の混乱が発生し、フローを一部見直すきっかけになったとのことです。 <浅見> ロールプレイングで気づきが得られたとのことですが、私のチームで実施した際も「これを見ておかなければいけなかった」といった気づきがありましたね。 <舟久保> 実施してみたい気持ちはありますが、実施するまでのハードルが少し高い気がします。 <浅見> 最初は過去に起きた障害をトレースする形で実施し始め、慣れてきた段階でこれから起こるであろう障害を再現する方式を取りました。過去に起きた障害を振り返るだけでもいいと思います。 テーマ4：「品質への取り組み、自動化や耐障害性について」 4つ目のテーマは「品質への取り組み」についてです。 各メンバーの所属チームにて、どんな取り組みを実施しているのかをディスカッションしました。 SLI / SLO を設定し、ダッシュボード上で管理できるように設定しているチームも複数ありました。 SLI / SLO の設定やダッシュボードの作成ににおいて、アーキテクチャやノウハウなどの詳しい部分についても今後ディスカッションしたいですね。 <川上> 月一でパフォーマンス会を実施しています。システムに SLI / SLO を設定していて、ダッシュボード上でこれらの値をチェックしたり、リソースの遷移グラフを確認しています。また、即時対応が必要な問題なのか、潜在的な問題がないかなどを議論しています。 <浅見> SLO を見ながら定期的に問題を確認する場ができているということですね。異常があった際にすぐ気づける状態になっていて、とてもいいですね。 <塩田> 私の担当システムでは、Toil の洗い出し・優先度付けを行い、撲滅活動を実施しています。Toil を自動化し撲滅することで、オペミスのリスクが減り品質向上につながっています。 まとめ 今回の Tech Talk では、ニフティで SRE がどのように展開されているのか、また各チームでどんな工夫を凝らして運用しているかをディスカッションしました。 1 時間という短い枠でしたが、他チームで運用している内容やノウハウが次々と出てきたので、大変貴重な時間となりました。 今後も NIFTY Tech Talk は継続して実施していきますので、ぜひご参加ください。 We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering

はじめまして、種田　大地（たねだ だいち）と申します。 ニフティに入社して10年以上エンジニアをしておりますが、 これまでに複数のシステムを新しく作ったり、廃止したりしました。 システムを新しく作ったことがある方は多くいらっしゃると思いますが、 廃止に携わった・実際に廃止作業をした方というのはあまりいらっしゃらないかもしれないと考えて、この記事を書きました。 システム廃止作業に取りかかる前に システム廃止を行う場合は、大きく2つに分かれると思います。 利用がなくなったため廃止する 利用はあるが、価値が低下しているので廃止する（別の方法に変更する） 後者の場合は、実際の利用がどの程度あるのか、それがどういった価値をもたらしているのか、代替手段で同様の価値を生み出せるのかといった点も考慮する必要が出てくるため、廃止を行うにあたっての事前調査がなかなか難しいです。 そのため今回は前者の「利用がなくなったため廃止する」場合を想定して書いていきます。 廃止想定システム AWS環境で構築された、以下構成のシステムを廃止する想定で記事を書いていきます。 赤枠で囲ってあるのが廃止対象システム、黒枠は廃止しないシステムです。 システム構成図 廃止の段取り 事前作業 記録の準備 はじめに、廃止作業を記録する準備をします。 皆さん普段から作業を行う際はチケットなどにどのような作業を行ったか、作業のログなどを残していると思います。 システム廃止作業でもそれは同じです。 後述する事前調査時には対応不要だと考えていた部分などが、記録を取るうちに対応が必要な部分であると気づいたり、万が一復旧作業を行う際には、作業記録を頼りに復旧計画を練ったりします。 システム構成の調査 システム構成をできるだけ正確に把握しましょう。 これにより副次的な障害発生を防ぐことができますし、廃止する担当者の心理的不安を軽減できます。 また、廃止による定量的な効果測定を行うためにも必要な段取りです。 今回は想定として具体例がありますが、通常であれば以下のような観点が必要になると思います。 サーバにディスクやNFSがマウントされているか LBを利用しているか 他システムとの連携はないか また、システム構成を調査をより簡単・確実にする方法のひとつとして、以下が考えられます。 インフラのコード管理（IaC化） 新規構築時のドキュメントは更新漏れがあったりしますが、IaC化されていればそれがそのままシステム構成を示すことになります。 廃棄予定になってからのIaC化はなかなか大変ですが、初期構築時からIaC化されていれば、 システム構成を調査するにあたって役立つと思います。 今回の例では、廃止対象システムで利用しているEFSが、廃止しないシステムからも 利用されていることがわかりますので、廃止しないシステムに移管します。 以下が廃止作業後のイメージとなります。 ※✕印が廃止対象 システム廃止後のイメージ また、システムの監視を行っている際は、監視の内容も確認しましょう。 監視ありの状態のままシステム廃止を進めてしまうと、急に「システム落ちてます」といった連絡が来てしまうことになります。 アクセス状況調査 利用がなくなった前提ではありますが、廃止前にはアクセス確認を行いましょう。 廃止の中心となるアプリケーションのログを確認するのはもちろん、アプリケーションの前段にあるApache, nginxといったWEBサーバのログ、LBのログなども必要に応じて確認します。 これによって、現状アクセスがあるか・ないか、アクセスがある場合は利用の頻度がどの程度かと言った点を確認します。 認証などが必要ないアプリケーションのログを確認する場合、自身がアクセスしたログを「どこからかまだアクセスがある」と誤認することがありますので注意が必要です。 ここまではログからアクセス状況を調査する方法に触れましたが、もしアクセス状況がCloudWatchのダッシュボードなどにわかりやすくまとめられていると、ログ調査を行うよりは楽にアクセス状況を確認することができます。 廃止するシステムが復旧可能か検討 システムの利用がないという前提ですが、復旧が可能かどうかの検討も行います。 例えば、以下のようなポイントを廃止前に検討する必要があります。 システムのソースコードが手元に存在するか OSSで提供されているツールなどは、同じバージョンのソースが手に入らない場合もあります システムのリリースを行うことができるか リリース手順などが残っているか 手順などがない場合、自身やチームのスキルで復旧が可能か DBは復旧可能か DBデータのバックアップがあるか ドメインの所有権は持ち続けているか ドメインが変更になるとリンク切れや、SEOへの影響が考えられます 他にも検討する事項はあると思いますが、上記の例にとどめておきます。 システムを廃止する 各種バックアップの取得 システムの復旧ができるように、各種バックアップを取得していきます。 バックアップを取得する対象の例を以下にあげます。 アプリケーションの設定ファイル DBの設定ファイル、データバックアップ cronなどのスケジュール また、システムによっては、OSレベルで個別の設定を入れている場合もあると思います。 そのような場合はOSレベルの設定ファイルをバックアップしておくと、より安心です。 システムの一時停止 システムの全リソース（サーバなど）を廃止する前に、一度システムの稼働を停止します。 アプリケーションの稼働に利用しているコンテナやプロセス、サービスを停止状態にします。 これは、システムを停止したことにより、問題が発生しないということを確認するためです。 停止する期間は過去に利用されていた頻度を参考にするのがよいと思います。 例えば、毎日利用されていたシステムであれば数日～1週間程度の停止でいいでしょうし、 月に1度利用されるようなシステムですと、ひと月～ふた月程度の期間停止していれば利用者が困ることはないと考えられるでしょう。 システム稼働に必要な周辺リソースの切り離し システム本体を廃止する前に、前述の システム構成の調査 で記載した様々な関連リソースの切り離しを行います。 これにより、今回の構成例では ELB経由で停止したアプリケーション以外へのアクセスができなくなる ようになります。 これにより、今回の想定からは外れるのですが 実はELB経由で利用されている別のアプリケーションが廃止対象のEC2に相乗りしている といった場合に、利用者からの申告や周辺システムからのアラートによって、廃止してはいけないリソースであるということがわかりますので、より安全に廃止を進めることができます。 以下の接続を切り離していくイメージです。 ※DynamoDBおよびS3との接続は、前述のシステムの一時停止を行った際に切り離されている想定です 切り離しのイメージ システムが稼働しているサーバなどの停止 各種リソースを切り離した後は、システムが稼働しているサーバなどを停止していきます。 今回のシステム構成例ですと、EC2を停止するイメージです。 なぜこのような段階を踏むかというと、別システムが廃棄対象システムへアクセスしに来る、かつアクセス頻度が低い場合などは、事前調査における影響確認が難しいためです。 例えば、ひと月に一度別のシステムからファイルの取得が行われていた場合、ログイン・ログアウトのログをしっかりと確認すれば問題を防ぐことはできますが、なかなか発見が難しい場合もあります。 このような漏れがあった場合、システム廃止済みだと復旧不可能になる場合があります。 その回避のために一旦サーバなどを停止するような段階を踏みます。 より慎重を期すのであれば、この際に切り離した各種リソースへのアクセス状況を再度確認します。 こちらは、別システムからのアクセスが本当にないかを特定するために役立ちます。 システムの廃止 多くの方はクラウドサービスでシステムを運用されているかと思います。 そういった場合はAPIやCLI、もしくはWEB画面でシステム稼働していたリソースを削除しましょう。 はじめてリソースを削除する際は緊張するかもしれませんが、ここまでの段取りを取っていれば、復旧する準備も十分にできているはずです。 安心してリソースを削除しましょう。 今回のシステム構成例で廃止を行った場合は、以下の状態になります。 システム廃止後のイメージ 廃止後の作業 効果測定 せっかくシステムを廃止したのですから、効果を測定して自分やチームの成果にしましょう。 今回廃止したシステム例は、利用者がいない前提のシステムでしたので、どれだけコスト削減に寄与したのかを測定するのがいいと思います。 もし、利用者がいるシステムの場合は、コスト削減効果に加えて、利用者からの問い合わせやクレームがどの程度あったか・どのような内容だったかも測定するといいかもしれません。 最後に いかがだったでしょうか？ 様々な事情はありますが、システムの廃止というのはいつか訪れると思います。 そんなときにこの記事が少しでも役に立つと嬉しいです。 ちなみに、本記事を書いている間も小規模な社内向けシステムの廃止作業中です。 現在は 「システムが稼働しているサーバなどの停止」 段階まで進んでいます。 We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering

初めに 新人研修の一環としてニフティ2022年度新卒入社の3名が、AWS JumpStart for NewGrads 2022（オンライン開催）に参加しました。 ニフティ2022年度新卒入社3名は、それぞれ別のチームで成果物を作成しました！ このワークショップ3日間で行った内容と成果物を紹介します！ 参加者 ニフティ2022年度新卒入社の小林、西牧、柴田の3名が参加しました！ AWS JumpStart for NewGradsとは? 新卒1年目 のエンジニアの方々を対象とした、3日間の実践的な研修プログラム。 将来的にAWS活用をリードする人材になるための第一歩をスムーズに踏み出せるようなコンテンツをというコンセプトで企画されているため、単なるAWSサービスの学習だけでなく、チームに分かれて要件に合った適切なアーキテクチャを検討・設計する経験を積む部分にフォーカスした内容。 約250 名以上のエンジニアが参加 情報処理サービス（SI）、Web、ゲームなど様々な業種からの参加 業種混同で64チームに分かれる 1チーム 3~5人 少人数のチームでアーキテクチャを作成 全てオンラインで実施 主に使用するツールについて Slack: 各種アナウンス、チーム毎のチャットルームとして使用 Zoom: 本イベント会期中、様々な目的でWeb 会議ツールとして使用 Bluescape: アーキテクチャ検討時のホワイトボードツール ハンズオン用AWS アカウント: ハンズオンの際にチーム毎にお渡し 参加するまでやること AWS JumpStart 事前学習コンテンツ（必須） はじめてのアーキテクティング（６０分） AWS入門（１８０分） ちなみに、ニフティの22新卒の研修では 事前学習コンテンツとは別に 下の内容を行いました！（一部抜粋） AWS基礎 ハンズオン – WEB３層アプリケーション – サーバレスなチャットアプリ チーム開発演習 – アプリの企画・開発 – AWSリソースの構築 内容 アーキテクチャ検討（メインイベント） 4人前後のチームに分かれ、お題に沿ったWebサービスのアーキテクチャを検討 最終日は工夫した点も含めてチームごとに発表 ハンズオン 実際にAWSのサービスを使ってみることで、実際の使い勝手や機能の詳細を学ぶ 実施期間 6/1(水) ~ 6/3(金)の３日間 スケジュール ※ お菓子・飲み物など持ち込み自由！ 目標/課題 など 大規模チャットサービスを作る 成果 小林チームの成果 小林チームでは、３日間を通して作り上げたAWSのアーキテクチャ構成図は下図のようになりました。作り上げていく３日間の軌跡を紹介します。 完成されたアーキテクチャ構成図 1日目 同じチームの皆様もAWSに関しては事前学習で培った知識が大半を占めて、お互いに探り探り調べながら行っていました。 初めてで何も分からなかったので、まずは最小構成でEC2のみを作成し、そこから要件に合わせてリソースを追加していく流れで行いました。 その上で、 スケーラビリティ どの箇所がボトルネックになるのか RDSとDynamoDBの違い など、調べながらアーキテクチャを作り上げていきました。 2日目 1日目の調査のおかげで、アーキテクチャがだんだん構成されていきました。 構成していく上で、実装におけるコスト管理やRDSの詳細について考えました。 RDSに関しては、リードではなくライトの部分に関して考える必要があり、以下のことを知りました。 シャーディング Auroraの場合にユーザIDの剰余などでどの部分のDBに入るのかを決定させることが可能 また、DynamoDBに関して、以下のメリットがあることを知りました。 1 秒あたり数十万のトランザクションへの即時スケーリング 3日目 最終日は大体の構成が決定しており、続いてセキュリティ面に関する調べものを行いました。 また、DNSウェブサービスに加え大量のトラフィックを吸収・障害を分離するサービスのRoute53を導入した際、信頼性確保のため当サービスに対するセキュリティに着目しました。調べたところ以下の2種類が存在し、より強力なAdvancedに注目しました。 AWS Shield Standard すべてのリソースで自動的に利用可能 一般的なDDoS攻撃から防御してくれる AWS Shield Advanced Route53などの特定のリソースのみに適用可能 より大規模なDDoS攻撃から防御してくれる これに加え、以下の2つを導入しました。 AWS WAF(Web Application Firewall) CloudFrontにWebアプリケーションに特化したファイアウォールの機能を追加できる ACM(AWS Certificate Manager) SSL/TLS用の証明書を管理してくれる また、小林チームではアーキテクチャ構成図以外に、AWS Well-Architected Framework という、アーキテクチャがクラウドのベストプラクティスにどの程度準拠できているかを把握できるドキュメントを用いて、信頼性やコスト、運用の効率化の各観点においてどのような利点があるかを記述しました。 AWS Well-Architected Frameworkに基づいて作成された当アーキテクチャの特徴 西牧チームの成果 私のチームは全員が研修でAWSを触ったことあるよ！の初心者チームでした。 1日目 まずは自己紹介の時間。想像以上に多種多様な企業の方々が参加されていることと研修で少しAWSを触っただけであることがわかりました。 メンバーのAWS知識が少しわかったところで、次にたくさんあるサービスを知るために各自で調べて付箋で貼りました。 (初日に調べたおかげで全員の理解度の向上や話し合いの円滑化につながり大正解でした！) サービスしらべの風景 調べたサービスをどうつなげるかを手探りで考えながら、1日目は終了しました。 2日目 サービスについての理解ができてきた中、構成図のむずかしさに直面しました。そこでAWS公式のページなどを見て構成図の作り方を勉強しながら必要なサービスを絞っていきました。 ここで初日にメンバー全員で書いたサービス調べが役立ちました！ 後半はAWS運営の方に質問しながらコスト管理について考え、サービスの内容だけでなくコストについての調査も行いました。 3日目 ここからはより実例のことを考えていきました。 大規模チャットサービスでありうることといえば？ 話し合いの中で出たものは「あけおめ」や特定の映画などのセリフの投稿でした。 そこで、それらが予測される日や時期（年末や映画の地上波公開など）には自動的にスケーリングするようにlambdaを使いました。 西牧チームの成果がこちらです。 柴田チームの成果 私のチームでは、1つの要素ずつ検討し、アーキテクチャ構成を徐々に変更を加えながら作成していきました。 1日目 初めに、簡単に自己紹介をしました。メンバーのAWSの経験は、ほぼ使ったことないからちょっと使ったことあるくらいでした。 次に、お題のサービスを実現するのに必要な機能を検討しました。また、それらの機能を実装するのに使いそうなAWSのサービスのピックアップを行い下の図のようにまとめました。「Webサイトの配信には、S3とCloudFrontは使いそうだよね〜」って感じです。 2日目 まずは、1日目にピックアップしたAWSのサービスを用いて必要な機能を実現する最小限の構成を構成図を作りました。 そして、作成した構成図を信頼性、スケーラビリティを意識してアップデートしました。 2日目の成果が下の図になります。信頼性を意識し、RDSを複数のAZに設置しました。また、スケーラビリティを意識し、ECSを使用しました。 3日目 3日目は、2日目までの構成からパフォーマンス、コスト、セキュリティを意識して変更を加えました。 チャットは低レイテンシを求められるため、マルチリージョンにすることを検討しました。しかし、全ての機能をマルチリージョンにするとコストが高くなるため、低レイテンシが求められる機能のみをマルチリージョンに配置することでコストを抑えました。 さらに、セキュリティ強化のため、AWS WAFを設置しました。 感想・学び 当社でも技術研修としてAWSの基礎について学びつつ、ハンズオンにおいてアーキテクチャ構成図を見ながらリソースの構築と削除を行う機会がありました。その時点ではAWSの概念と使用用途のみを学ぶことが出来ました。その上で当研修を行った後同じハンズオンを行いましたが、「なぜこのリソースを用いるのか」「リソースの影響範囲はどこまでか」をしっかり把握した上で完了できたので、AWSに対する理解度がより深まり、実際の業務でも生かせています。（小林） 3日間のワークに参加して、AWSサービス同士の効率の良いつなげかたを考えながらアーキテクチャ構成図の書き方や、それぞれのサービスの特色や使いどころを学ぶことができました。またワーク内ではコスト面やパフォーマンス面についても考えることができ、実際に運用する側の視点を身に着けました。これにより実際の業務の中で社内システムの構造への理解度の向上を実感しています。（西牧） 同じ機能を実装するのでも複数のやり方があり、実装方法によりコストが変わってくるため、最適なアーキテクチャ構成を作成するのが難しかったです。アーキテクチャ構成を検討する中で、様々なサービスを比較しながら調査することで、それぞれのサービスの特徴を学ぶことができました。また、ハンズオンを行うことでサービスへの理解度がより向上したと感じています。(柴田) We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering

初めに 最近全てのシステムは人間というシステムの運用開発であるという考えを持ち始めた, 会員システムグループの2年目社員の関です. システムにおいて最も重要なことは人間がいかに使いやすいかである と考えてアクセシビリティに興味関心を持ち, 社内に広げたいと考えています. TechDayという社内イベントのLTでアクセシビリティに関して話したりもしました. 今回は社内で開いたオーサリングプラクティス輪読会という勉強会の中での課題の話をしたいと思います. オーサリングプラクティス輪読会とは オーサリングプラクティス輪読会はオーサリングプラクティスを輪読する会です. オーサリングプラクティスって? 一言で言うと HTML/CSS/JavaScript/WAI-ARIA* を使用してどのようにアクセシブルなWebシステムの機能を作成するかについて実践的な記述方法が学べるWeb上のコンテンツです. *WAI-ARIAとは : HTMLだけでは表すことのできない構造や状態を表現するための仕様のことです. 以下のページで読むことができます. ARIA Authoring Practices Guide-patterns . 輪読会では上記のPatterns一つ一つを読んで, どのようにHTML/CSS/JavaScript/WAI-ARIAを使って機能を作成すれば良いのかということを学んでいます. オーサリングプラクティス輪読会で出した課題 オーサリングプラクティス輪読会では7回目までの理解度を測るための中間課題を出しました. 課題 ダイアログ要素を使用したTODOリストをアクセシブルに作成する 要件 React, Vue, Svelte, Solid.jsなどのライブラリは使っても良いが, React-modalなどのライブラリは使わずに自分で実装を行う 作ってほしいシステムのイメージ(以下のイメージを元にシステム作成を行なってもらいました) TODOリストメイン画面 TODOの追加画面.ダイアログとして作成する TODO編集画面.ダイアログとして作成する TODO削除画面.ダイアログとして作成する. 以上です. 課題としてはモーダル要素部分以外は正直大したことはないように思えますが, 実は考慮することは結構あります. 課題の答え 課題の答えも自分で考えて作成しました(ゆえに不足している点がある気がします). 答えにおいて肝になる点を何点か以下で紹介します. モーダルウィンドウを表示しているときのキーボードフォーカスについて これがモーダルを自分で実装する際の最も難関な部分だと思います. アクセシブルなモーダルを1から作るとなると以下の部分を考えなければなりません. フォーカスの移動 モーダルを開いている間はフォーカスをモーダル上に留めなければならない モーダルだということを 支援技術* に伝える( *支援技術 : スクリーンリーダーなどの障がい者等が使用する装置, ソフトウェアの総称です.) role=modalなどを使用して支援技術*にモーダル要素であることを伝える必要があります モーダルのデザイン 視覚的にモーダルだとわかるように, モーダルが表示されているときは元のページは灰色などでマスキングすることが理想です これを一から作るとなると大変です. 現状のHTMLにはdialogという要素が存在しており, これを使うことで簡単に上の要件を満たしたモーダルを作成することが可能です. <dialog>: The Dialog element . dialog要素は2022のInteropにて2022年以内に現在の主要ブラウザの全てで対応するようにすり合わせを行なっています.そのため, 2022年7月現在すでに主要なブラウザは対応している状態です. Interop 2022: browsers working together to improve the web for developers . そのため, 今回のシステムではHTMLのdialog要素を使用してモーダルウィンドウを作成しました. <dialog></dialog> dialog要素を使うことで非常に簡単にモーダルが作成できるため, 非常に便利だと感じました. 音声でそれぞれの操作が認知できるか チェックボックスをチェックしたかどうか?は目が見えないなど視覚にハンデを持っている人にとっては認識できないかもしれません. その場合には, そのような操作は逐次音声として伝える必要があります. どのように実装したか 今回はこれを解決するために以下のように画面には表示されないが, 支援技術には認識されるHTML要素を作成しています. <div className={styles.visuallyHidden} id='notes_save_status' role='alert' > {alertText} </div> 要素には role='alert' を設定して中身に変更があった場合は支援技術が検知するようにしています. React側のコードは以下のようになっています. setAlertText(`${title}のTODOを完了しました`); 上記は完了の例ですが, setStateでalertTextを切り替えることでTODOリストへの追加, 編集, 削除, 完了, 未完了などが支援技術を通してユーザに伝わるようにしています. WAI-ARIAを適切に設定しているか 今回のモーダル要素は複数存在するため, どのモーダルが表示されたのかをWAI-ARIAを使って支援技術に伝える必要があります.そのため, 今回は以下の二つのWAI-ARIAを設定しなければなりません. ariaの名前 説明 aria-describedby Dialog要素の中にタイトル以外にダイアログを説明する要素がある場合にそのIDを指定する aria-labelledby Dialog要素内のタイトル要素のIDを指定する HTML内に記述するaria要素とその説明 実際に設定すると以下のようなHTMLになります.(実装ではDialogコンポーネントを作っていたので微妙に違います). <dialog aria-describedby='deleteDialogDesc' aria-labelledby='deleteDialogLabel' .../> <h2 id="deleteDialogLabel">{title}</h2> 　　<div aria-describedby='deleteDialogDesc' > {`${todoVal[parseInt(selectTodoId)]?.title}`}のTODOを削除しますか? </div> </dialog> 上記は削除要素の例ですが, タイトルであるh2を aria-labelledby , 削除の文章に aria-describedby を指定しています(削除の確認の文章は説明ではないので設定する必要はなかったかもしれません). 削除以外の要素はフォーム以外に説明する要素はないのでaria-describedbyは設定していません. まとめ 今回の勉強会で課題の作成と答えの作成をしてみて, 現在のモダンフレームワークでどのようにアクセシブルなシステムを作成するのか, どのように要件を考えていくのかなどがなんとなくわかってよかったと思います. 将来的にこの経験を業務にも活かして, 全ての人間が使いやすいシステムの構築を目指していきたいと思います. We are hiring! ニフティでは, さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering

ニフティ株式会社でマネージャーをしている北浦です。 今回は私がマネジメントしている基幹システムグループ 課金システムチームのマネジメントについて紹介します。とはいえ自身のマネジメント歴が浅い（2022年4月〜）ので、今回は僕たちのチームがどのようにスクラムを導入していったのかを書いてみたいと思います。 (0) スクラム導入前 2017年まで課金システムチームの前身のチームではウォータフォール開発を採用し、ほぼ全ての開発業務を外注していました。社員の業務は要件整理や社内外調整、プロジェクトマネジメントなどがメインであり、自ら開発を行うシーンはとても少なかったと思います。社内向けツールや運用作業の自動化などで開発を行うメンバーもいましたが、コードを一切書かないメンバーもいました。 また、属人化もかなり進行しておりシステムごとに人（社員＆協力会社メンバー）が張り付いており、同じチーム内でも隣のシステムについては全く分からず手が出せない状況でした。 このような環境の中でチームメンバーが大きく変わっていきましたが、いざシステムを引き継いでみると多くの問題が発生しました。”ドキュメント化されていない業務仕様”、”ドキュメントがなくリポジトリ管理されていない謎のプログラムがプロダクション環境で動いている”、”ビジネス部門の担当者が不在”、”社員が仕様を把握しておらず協力会社メンバーしかわからない(そのメンバーは既にプロジェクトから離れている)”など、とても苦労しました。 このままではまずいということで、主に属人化の解消とエンジニアの技術力向上を目指しスクラムを導入することにしました。 (1) 1チームスクラム: 1プロダクトを開発 2018年からスクラムを導入しました。既存プロダクトの全面刷新をスクラムで完全内製開発しました。ポイントは以下です。 スクラムマスター研修に参加してスクラム開発を学ぶことで導入時のハードルを下げた 比較的規模の小さい既存プロダクトを対象として全面刷新する方針とした ビジネス部門に相談してPO(プロダクトオーナー)を立ててもらった 職制上のチームを跨いでスクラムチームを構成、若手メンバーに多く参加してもらった ウォータフォール開発に慣れていたメンバーにとって、最初はスクラムガイドや書籍で勉強してもなかなかスクラム開発のイメージを掴むのは難しいので、一部メンバーがスクラムマスター研修に参加して学んできたことはスクラム導入がスムーズに進められた要因の一つだと感じています。 以降、各フェーズごとにKPT法でふりかえってみたいと思います。 良かったこと ビジネス部門とシステム部門が協力して”プロダクトを育てる”という意識が芽生えはじめた 小さく始めることで無理なく少しずつスクラムに慣れていくことができた 完全内製によるチーム開発の土台づくりができた 開発スキルを向上できた 改善したいこと 暫定で組んだスクラムチームだったので”チームの成長”をメンバーが意識しづらかった スクラムチームメンバーは職制上チームのタスクも継続して担当していたため、スクラムに注力できないメンバーが発生してしまった 初期リリース実施前に職制上チームのタスクが忙しいメンバーはスクラムチームから外れることになってしまった メンバーが職制上チームを跨ぐのでマネジメントが難しい トライ（実験） チームを跨ぐ状況を改善して職制上チームとスクラムチームを一致させる (2) 1チームスクラム: 複数スクラムを同時に実施 2019年からは職制上チームとスクラムチームのメンバーが一致するようチームを再編しました。また、別プロダクトでもスクラム開発したいものがでてきたので、新規にスクラムを立ち上げて複数のスクラムを同時に実施してみました。以下がそのふりかえりです。 良かったこと 新規にスクラムを開始したプロダクトはプロトタイプを小さくリリースしてPOから早期にフィードバックをもらうことで必要な機能を素早く提供できた 改善したいこと 同時期に複数のスクラムを1チームで実施することによるオーバーヘッドが想像以上に大きく、開発時間の確保が難しかった(スイッチングコスト、各種スクラムイベントなど) スクラム対象プロダクト以外にもチームが担当しているプロダクトがあるが、それに割り当てる時間がなくなってしまった トライ（実験） 全てのプロダクトを1つのスクラムで管理してみる (3) 1チームスクラム: 複数プロダクトを対象とした1つのスクラムを実施 1つのスクラムチームが複数のスクラムを同時に実施するのはかなり厳しいことがわかりましたので、2020年からは1つの職制上チームが担当する全てのシステム・サービス・プロダクトを1つのスクラムで管理してみることにしました。ただし、全ての関係者のスケジュールをあわせることが難しかったため、各プロダクトのPOと簡易スクラムイベントを個別設定することで対処しました。以下がそのふりかえりです。 良かったこと スクラムイベントのオーバーヘッドが削減できた 職制上チームが担当する全てのプロダクトに関するタスクが可視化され属人化解消に役立った 簡易スクラムイベントの導入によって各種イベント実施が効率化できた 改善したいこと プロダクトを跨ぐ優先順位付けが困難 社内システムへの要望やシステムリプレース対応のような技術的負債の改善につながる活動は、相対的に優先順位が常に低くなってしまう レガシーシステムに関するプロダクトバックログアイテムは認知負荷が高く多くのドメイン知識が必要となるため共有が進まない トライ（実験） チームが担当するプロダクトのPOを集めて、各プロダクトのスケジュール共有会を定期的に実施してみる (4) サブチーム同士が協力してスクラムを実施(検討中) 各プロダクトのPOを集めて実施するスケジュール共有会の実施により、事前にスケジュールのバッティングが確認できるようになり、早い段階で関係者と調整するなど対策が立てられるようになりました。 また、2021年には大規模スクラム(LeSS：Large-Scale Scrum)を採用し新規接続サービスの内製開発も行いました(こちらは別途ブログ化される予定です)。 2022年現在では、”複数プロダクトを扱う1チームスクラム”と”LeSS”の2つのスクラムを同時に実施しています。一般的にスクラムは”1つのチームは1つのスクラムに専念する”という大原則があるのですが、現実はなかなか難しい状況ですので現在の形となりました。2つのスクラムで可能であればスクラムイベントを共通化するなど、できる限り複数スクラムを実施することによるオーバーヘッドの最小化を目指しています。 現在は途中でもう1つサブチームが合流して2つのサブチームで課金システムチームとなったのですが、サブチーム間の協力がまだまだ弱いのでより良いチーム体制を模索しています。 チームにどのようにスクラムを導入していったのかを紹介させていただきました。”スクラムは理解するのは簡単だけど実践するのは難しい”と言われています。上記の内容がどこかのチームの参考になれば幸いです。 We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering

NIFTY Tech Talkは、ニフティ株式会社の社員が主催するトークイベントです。 本イベントではニフティ社員が業務を通じて学んだことを発信しています！ 第三回目のテーマは「AWSコストダウン」。ニフティでは各チームコストとパフォーマンスの最適化を行っています。 ニフティが取り組んでいる「AWSコストダウン」について、現場のエンジニアを中心にパネルディスカッション形式でリアルな現場の声をお伝えします。 概要 日程：7月26日（火）19:00〜20:00 配信方法：YouTube Live 視聴環境：インターネット接続が可能なPC/スマートフォン 参加方法 Connpassイベントページ より参加申し込みください！ こんな方におすすめ AWSのコストを下げたい方 コスト削減のベストプラクティスを知りたい方 組織でのコスト削減の取り組みに興味ある方 タイムテーブル 時間 コンテンツ 19:00-19:05 オープニング＋会社紹介 19:05-19:15 登壇者紹介 19:15-19:55 メインディスカッション 19:55-20:00 クロージング ディスカッション テーマ 「AWSコストダウン」をメインテーマとして以下のような話題についてディスカッションします。 コストダウンの取り組みについて コスト意識醸成のための行ったこと 登壇者プロフィール 福田　紫穂（ファシリテータ） ニフティ株式会社　インフラシステムグループ クラウド・仮想化環境・ネットワークなどインフラ全般を担当。現在はハイブリッドクラウドのあるべき姿を検討中。 小松 初（登壇者） ニフティ株式会社 基幹システムグループ 新卒入社4年目。チーム内のクラウドコスト削減担当の一人として活動中。 河野 曜平（登壇者） ニフティ株式会社 インフラシステムグループ 新卒入社4年目。クラウドインフラ周りの整備をしています。最近はISUCONに夢中です。 深田 健太 （登壇者） ニフティ株式会社 会員システムグループ 新卒入社3年目。@nifty安心メールパックの開発・運用を担当しています。SAP勉強中。 ニフティでは一緒に働く仲間を募集中 ！ 新卒採用、キャリア採用を実施しています。 ぜひ リクルートサイト をご覧ください。 ニフティエンジニアのTwitterアカウントを作りました NIFTY Tech Talkのことや、ニフティのエンジニアの活動を発信していきます。 https://twitter.com/NIFTYDevelopers

はじめに インフラシステムグループの河野です。 最近集計・分析系のクエリを書く機会が多くなっています。 その中でGROUPING SETSに出会って感動したのでこの気持を分かち合いたいと思います。 記事中ではクエリエンジンとしてpresto 0.217を使用しています。 GROUPING SETSとは GROUPING SETSはGROUP BY句に付与する構文で、複雑なGROUP BYを実現するときに使用できます。 具体例を見ていきましょう。例えば、以下のようなstockテーブルを考えます。店舗ごとにフルーツの在庫がいくつあるか、値段はいくらなのかをまとめたテーブルです。 SELECT * FROM ( VALUES ('orange', 1, 100, 51), ('lemon', 2, 50, 102), ('melon', 3, 1025, 23), ('banana', 1, 25, 154), ('orange', 2, 104, 105), ('lemon', 3, 55, 55) ) AS t (name, shop_id, price, qty) 商品ごとの合計を出しつつ、全体の合計も出したいときが来たとします。この場合GROUPING SETSを使わないとすると以下のようなクエリで実現できます。 SELECT name, SUM(price) AS total_price FROM stock GROUP BY name UNION ALL SELECT NULL, SUM(price) AS total_price FROM stock # 実行結果 name total_price 1359 banana 25 orange 204 melon 1025 lemon 105 これをGROUPING SETSで書き換えると以下のようになります。 SELECT name, SUM(price) AS total_price FROM stock GROUP BY GROUPING SETS((), name) # 実行結果 name total_price 1359 lemon 105 melon 1025 orange 204 banana 25 このように複数の基準でGROUP BYしなければならないものを、GROUPING SETSで一つにまとめることができます。 実務ではクラウドコストを集計してグラフ表示するときに非常に役に立ちました。クラウドベンダごとに別のグラフを描く。合計値も同時に描画したい。といった要件が出てきて、はじめは愚直にUNIONしていて、30行程度のクエリになっていました。その後prestoのリファレンスを見ていたらGROUPING SETSを見つけたので試しに書き換えてみたら、15行ほどにすっきりとクエリを書き替えることができました。 ROLLUP、CUBEとの関係性 GROUPING SETSと似た構文にROLLUPとCUBEがあります。ROLLUPでは小計、総計をまとめて取得することができます。CUBEではすべての組み合わせに対して総計を取得することができます。 それぞれ先程のstockテーブルに対して適用した結果を見てみましょう。 ROLLUP: SELECT name, shop_id, SUM(price) AS price, SUM(qty) AS qty FROM stock GROUP BY ROLLUP(name, shop_id) # 実行結果 name shop_id price qty 1359 490 banana 25 154 orange 204 156 orange 1 100 51 lemon 3 55 55 melon 1025 23 lemon 2 50 102 melon 3 1025 23 lemon 105 157 banana 1 25 154 orange 2 104 105 CUBE: SELECT name, shop_id, SUM(price) AS price, SUM(qty) AS qty FROM stock GROUP BY CUBE(name, shop_id) # 実行結果 name shop_id price qty 1359 490 banana 25 154 2 154 207 orange 1 100 51 melon 3 1025 23 lemon 3 55 55 melon 1025 23 1 125 205 orange 2 104 105 orange 204 156 lemon 2 50 102 banana 1 25 154 lemon 105 157 3 1080 78 これらをGROUPING SETSで書き換えると以下のようになります。 ROLLUP → GROUPING SETS: SELECT name, shop_id, SUM(price) AS price, SUM(qty) AS qty FROM stock GROUP BY GROUPING SETS((), name, (name, shop_id)) # 実行結果 name shop_id price qty 1359 490 banana 25 154 melon 1025 23 lemon 2 50 102 melon 3 1025 23 lemon 105 157 banana 1 25 154 orange 2 104 105 orange 204 156 orange 1 100 51 lemon 3 55 55 CUBE → GROUPING SETS: SELECT name, shop_id, SUM(price) AS price, SUM(qty) AS qty FROM stock GROUP BY GROUPING SETS((), name, shop_id, (name, shop_id)) # 実行結果 name shop_id price qty 1359 490 banana 25 154 2 154 207 orange 1 100 51 melon 3 1025 23 lemon 3 55 55 lemon 105 157 3 1080 78 orange 204 156 lemon 2 50 102 banana 1 25 154 melon 1025 23 1 125 205 orange 2 104 105 それぞれの差分だけ見るとどういう動きをしているかわかりやすいと思います。 ROLLUP(name, shop_id) → GROUPING SETS((), name, (name, shop_id)) CUBE(name, shop_id) → GROUPING SETS((), name, shop_id, (name, shop_id)) 例えば、組み合わせが一個増えたときの対応はこうなります。ROLLUPでは一番左のカラムを基準としたときの組み合わせ、CUBEではすべての組み合わせをそれぞれグルーピングしています。 ROLLUP(name, shop_id, qty) → GROUPING SETS((), name, (name, shop_id), (name, shop_id, qty)) CUBE(name, shop_id, qty) → GROUPING SETS((), name, shop_id, qty, (name, shop_id), (name, qty), (shop_id, qty), (name, shop_id, qty)) GROUPING SETSで書くことで、どの組み合わせで集計しているのかがわかりやすくなるため、個人的にこの書き方が好みです。 終わりに 今回はGROUPING SETSについて使い方と、他の類似構文との関連性をまとめました。有効に使えるとクエリをすっきりとさせられるので機会があれば使ってみてください。 参考記事 https://prestodb.io/docs/0.217/sql/select.html We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering