はじめに mediba Advent Calendar 2022 と、 New Relic Advent Calendar 2022 の8日目の記事となります。 みなさんNew Relicでアラート設定していますか? おはこんハロチャオ!medibaでSREをしている北浦（ @kitta0108 ）です。 今回はNew Relicでオンコール対応を初めとした通知機能を運用に実装しようとした際に、 お世話になるであろうAlert機能の中で、時間にまつわる設定値の話をつらつらと書いていきます。 弊社の中でも、この設定値は1つずつ紐解いていくのが困難でわからないという声が多くあがっていたので、筆をとってみました。 というわけで、この”時間”を指定する設定について、 - なぜ必要なのか - どんな時にチューニングするのか - 一旦は何も考えずに設定したいときはどうしたらいいのか を紹介していきます。 読者想定 こんな方々へ何かしらの貢献ができる記事になるよう意識しています。 New Relicでアラート設定をしたいモチベーションがある メトリクスの扱いに自信がない 今までなんとなくアラート設定していたので理解を深めたい 問題の設定値 時間を設定する値って5つもあるんですよねー。 今回は以下を解説していきます。 Condition thresholds Signal loss expiration time Window Duration Slide by Interval Event flowのDelayまたは、Event TimerのTimer お題 解説の便宜上、以下、2つの例を使っていきます。 -  例A(ALBのHealthy Host Countが0になったらアラートする) SELECT max(aws.applicationelb.HealthyHostCount) FROM Metric FACET aws.applicationelb.LoadBalancer - 例B (ALBのHTTPCode_Target_5XX_Countが10以上になったらアラートする) SELECT sum(aws.applicationelb.HTTPCode_Target_5XX_Count) FROM Metric FACET aws.applicationelb.LoadBalancer 1.Condition thresholds アラートの閾値としての時間指定です。 例えば、 above or equals 2 at least once in 1 minutes と指定した場合は、 少なくとも1分間に指定のメトリクスが2以上に上がった時、 アラート判定とする設定です。 アラートとして、メトリクスを見にいく頻度（回数）という見方もできます。 この時間は、短くすればするほど、 こまめにメトリクスが上がってないか見てくれるので、 解像度を高めることができます。 -  例A(ALBのHealthy Host Countが0になったらアラートする) equals 0 at least once in 1 minutes 0になったらアラートなので、equals 0と指定します。 頻度に関しては、0となった時にすぐ連絡が欲しいので、1分間毎にします。 -  例B (ALBのHTTPCode_Target_5XX_Countが10以上になったらアラートする) above or equals 10 at least once in 5 minutes 10以上になったらアラートなので、above or equals 10と指定します。 頻度に関しては、5分間の総量を判定させたいので、5分毎にします。 2.Signal loss expiration time メトリクスがNew Relicで受信できなかったときに、 Signal lossと判定させるまでの時間です。 -  例A(ALBのHealthy Host Countが0になったらアラートする) ALBのHealtyHostCountメトリクスは 1分間に1回の頻度で集計されるメトリクスなので、 AWSからNew Relicに対しては、以下のように1分間に1回のペースでメトリクスデータが送られます。 しかし、このメトリクスデータがネットワークの揺らぎなどの原因により、 New Relicに3分間届かなかったとします。 このようなケースにおいて、アラートとしてどのような振る舞いをするべきか、 厳密な設定が可能です。 HealtyHostCountのケースでは生存確認の意を含んだアラートになる為、 3分間データが届かなかった場合は、 メトリクスデータが届いていないというアラートを起票するようにしたいです。 そのため signal lost after 3 minutes で Open New “lost signal” violation にチェックを入れます。 -  例B (ALBのHTTPCode_Target_5XX_Countが10以上になったらアラートする) HealtyHostCountは定期的に集計されて送られてくる継続データでしたが、 一方で以下のように、とあるイベントが発生したとき だけ、 送るといった不定期なデータも存在します。 ※画面例は4XXエラーです。5XXエラーはなかなか画面ショットを撮りたい時に発生してくれないものでしてあしからず。 このような不定期データをアラートとして扱う場合、 以下で説明するEvent Timer設定により詳細なコントロールが可能であるため、 無効化しておくことが個人的なおすすめです。 3.Window Duration いつのメトリクスデータを評価するのかという枠の指定です。 1分間の合計を評価するのか、あるいは5分間の合計を評価するのか。 評価するための時間枠はここで設定します。 -  例A(ALBのHealthy Host Countが0になったらアラートする) HealtyHostCountの場合、一度でも0だった場合、 不健全とみなし、アラート発報させたいので 可能な限り頻度の高い設定値にします。 このメトリクスデータは1分間集計なので、 Window Durationは1分間という枠にします。 -  例B (ALBのHTTPCode_Target_5XX_Countが10以上になったらアラートする) HTTPCode_Target_5XX_Countは5分間の合計値を1分間の頻度で確認したいため、 Window Durationは5分間に設定します。 4.Slide by Interval Window Durationで指定した枠を、どのくらいスライドして評価させるかという指定です。 弊社でも多くの人の理解を挫折に導いた設定値ですが、 適切なアラートをさせるために重要な設定でもあります。 -  例A(ALBのHealthy Host Countが0になったらアラートする) このケースでは使いません。 -  例B (ALBのHTTPCode_Target_5XX_Countが10以上になったらアラートする) Window Durationを5分間に設定した場合、このSlide by Intervalの設定をしないと、 5分間に1回の評価しかできません。 5分間の集計を1分間の頻度で評価をするためには、 5分間集計を1分間毎にスライドさせて評価する必要があります。 これを実現させるために、このケースではSlide by Intervalの設定を1分間に設定します。 参考イメージ＜ https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/nrql-query-tutorials/create-smoother-charts-sliding-windows ＞ 5.Event flowのDelay または、Event TimerのTimer Streaming Methodによって、より確実に集計するための設定です。 メトリクスデータが継続的なものか、不定期なものかによって、 Event Flowを使うか、Event Timerを使うか変わってきます。 Cadenceという設定もあるのですが、 現在では非推奨設定なので、選択肢からは除外してよいでしょう。 例A(ALBのHealthy Host Countが0になったらアラートする) HealtyHostCountは継続データなので、Event Flowを使います。 結論から伝えると2分間のDelayを設けます。 この設定を入れることにより、現在の時刻が12:02だった場合、11:59 ~ 12:00のメトリクスデータを評価するようになります。 Signal lossの箇所でも解説した通り、 メトリクスデータはリアルタイムで届かない可能性があり、 その考慮がないと適切な評価ができず、 閾値を超えているのにアラート判定がされない…という状況が起きかねません。 2分間のDelayを設けることにより、 メトリクスデータが到着している可能性を高めることができます。 ここは確実性と検知スピードのトレードオフになるので、 適切なチューニングが必要とされます。 まぁ、2分間も設けておけば、検知スピードとして問題となるケースも少ないでしょう。 -  例B (ALBのHTTPCode_Target_5XX_Countが10以上になったらアラートする) HTTPCode_Target_5XX_Countは不定期データなので、 Event Timerを使います。 結論から伝えると5分間のTimerを設けます。 この設定をいれることにより、 12:00に初回のメトリクスデータが到着した場合、 その時点から5分間のタイマーがセットされます。 その後、12:03に2回目のメトリクスデータが到着した場合、 その時点から追加で5分間のタイマーがセットされ、 12:08に12:00 ~ 12:05のメトリクスデータが評価されます。 このTimerは仕組み上、 Window Durationよりも少ない時間を指定することがは非推奨なので、 その点は注意しましょう。 おわりに ざざっと該当項目に関して解説してみましたがいかがでしょうか。 例などを出してわかりやすくしたつもりではありますが、 改めて見返しても、 必要となる前提知識や背景などの情報量の多さ故に腰を据えてみていかないと理解が難しい側面はあるかもしれません。 何かしらアラート設定でつまづいた時にでも、 こんなこと書いてたやつがいたなーと思い出してもらえたら幸いです。 ちょっとだけ宣伝 NRUG(New Relic User Group)：通称ぬるぐ というユーザーグループがあります。 弊社でも板谷（ @mary_tuba ）がNRUGの運営、 僕がNRUG SRE支部の運営を勤めておりまして、直近の予定は以下になります。 12/14(水) NRUG Vol.5 Day1 1周年だよ!全員集合!! https://nrug.connpass.com/event/265357/ 12/15(木) NRUG Vol.5 Day2 交流会  https://nrug.connpass.com/event/266747/ ?/? NRUG SRE支部 Vol.3 来年春頃まで必ずやりたい…!! 気になる方は是非チェックしてみてください！

はじめに ※この記事は mediba Advent Calendar 2022 の5日目の記事です。 株式会社mediba バックエンドエンジニアの @hrktcy です。社会人2年目になりました。 みなさまの運用するサービスには監視SaaSを導入していますか。弊社では 1日目の記事 でもお伝えしている通り、近年New Relicによるサービス監視が主流となっています。現在私が参加している、ポイントリワードサービスにおけるポイント付与機構の開発プロジェクトにも導入する運びとなりました。本記事では題目の通り、New Relic Alert Condition設定におけるチームでの基本指針を策定したのでその内容を共有したいと思います。 アプリケーション側のコードの見直し まずはConditionの設定をする前に、アプリケーション側のコードの見直しを行うことにしました。コーディングしていた時期から結構期間が空いていたので、記憶から抜けていた部分を埋めていきながら、「適切なエラーハンドリングができているか」「使用しているカスタムログのログレベルが正しいか」の2点を重点的にチェックしました。 ログレベル 値 内容 Info 実行状態を把握するために出力する　　　　 Warn 致命的ではないが想定外の挙動をしたときに出力する Error 予期しないエラーでサービス及びシステムに影響があり調査及び復旧が必要な時に出力する ポリシーを分ける ポリシーとは、1つ以上のコンディションのグループを指します。今回、ポリシーは以下の2つに分けることにしました。 オンコールポリシー Slack通知ポリシー オンコールポリシー 検知された場合、インシデントとなり得る事案のため至急対応が必要なもの をオンコールポリシーに割り当てます。ログレベルで言うとErrorレベルのものを指します。具体的には、 バッチが多重起動している AWSサービスのクライアント読込、アクセスに失敗している 外部サービスへのアクセス、SFTP経由でのダウンロードに失敗している といったものになります。 ポイント誤課金事故を防ぐためにもこのようなインシデントに対しては早急に調査・復旧対応する必要があるので、ローンチ段階ではNRQLの条件を厳しめに設定し、Slack通知+Twilioで業務端末へ架電するように設定しました。しかし条件が厳しいほど、アラートによる疲弊問題にも向き合う必要があり、インシデント対応プロセスでケアレスミスやコミュニケーションミスに繋がりやすくなるので、架電対象者はランダム(不在時は別の対象者に架電)にして、NRQL条件については保守運用が安定してきたら少しずつ緩和していきたいと考えています。 Slack通知ポリシー 検知された場合、想定外のエラーでサービス及びシステムに影響があるが、調査及び復旧が至急ではないもの をSlack通知ポリシーに割り当てます。ログレベルで言うとWarnレベルのものを指します。具体的には、 ポイント付与に失敗している CPU/メモリ/DB使用率が一定期間n%を超えている DBコネクション数が一定期間n件以上 といったものになります。 「ポイント付与に失敗している」については、リカバリーを考慮した設計になっているため、基本的には楽観視しても良いのですが、断続的に失敗している際は調査が必要になります。また、インフラのパフォーマンス監視についてもワーニングポリシーに割り当てておき、検知がされたタイミングで高負荷となっている要因の調査が必要になります。こちらのポリシーについてはSlack通知のみ行うように設定しました。 コンディションの管理について TerraformによるIaC化を行い、ポリシーに紐づくコンディションを一元管理しました。 terraform apply で素早くAlert Conditionを設定できるようになるため、将来顧客が増えた場合のインフラ環境の増築に対しても即対応が可能になります。 実際どうだったか ローンチから1ヶ月ほど経ちましたが、至急対応が必要な事案は現状1件、検知によって迅速な復旧作業を行うことができました。また、ローンチ後にはAlert Conditionに加えてAPMによるHTTPトランザクションや、関数・クエリ単位での計装を実装することができ、サービスの信頼性維持の体制が整ってきていると感じます。 終わりに 特にオリジナリティのある指針ではないかもしれませんが、私はAlert Condition設定をしている際に、いろいろと考え過ぎてしまい沼にはまることが度々ありました。チームメンバー間の認識を合わせるためにも一度言語化しておくと困った時に立ち返ることができるかと思います。また今後の新規開発の際には、予め監視対象やAlert Condition設定を意識しながらコーディングできるように心がけていきたいです。 宣伝 KDDIグループ企業各社のDeveloperが集い、「エンジニアが楽しめる」イベントを提供するコミュニティKDDI Group Developer Community(KGDC)の運営スタッフとして活動しています。来年も引き続き開催していきますので、ぜひ Connpass よりメンバーになっていただき、次回のイベントに参加していただけると嬉しいです！

こんにちは、データアナリストの左海です。 今回はパケットキャプチャツールCharlesを活用してレスポンスヘッダーの Content-Security-Policy フィールドにGA4のディレクティブを追加したお話について書いていきます。 課題と背景 Universal Analyticsのサポート終了発表に伴い、弊社でも対象のサービスサイトにてGA4の導入を進めていたのですが、CSP(Contents Security Policy)関連でエラーが発生しGA4ログの疎通が確認できませんでした。 Google Chromeのデベロッパーツールで調査すると、サイトのCSPにGA4のオリジンが宣言されておらず、リソースがブロックされていたため、ログが飛んでいないことが判明しました。 加えて、対象のサービスサイトは外部の会社が運用しており、私自身の環境でデバックする必要があったため、Charlesを活用することにしました。 方策 Google ChromeのConsoleでエラーログを確認すると、有難いことにエラーの解決方法まで記載されています。 A site’s Content Security Policy is set either as via an HTTP header (recommended), or via a meta HTML tag. HTTP ヘッダーまたはHTMLのメタタグに以下の通りにGA4のディレクティブを宣言すれば解決できるようです。 script-src: https://.googletagmanager.com img-src: https://.google-analytics.com https://.googletagmanager.com connect-src: https://.google-analytics.com https://.analytics.google.com https://.googletagmanager.com では、実際にCharlesのRewriteという機能を使用してレスポンスヘッダーの Content-Security-Policy フィールドにGA4のディレクティブを追加しデバックしてみることにします。 CSP(Contents Security Policy)とは Charlesでデバックする前にCSPについて解説します。CSPについてMDNには以下のように記載されています。 HTTP の Content-Security-Policy レスポンスヘッダーは、ウェブサイト管理者が、あるページにユーザーエージェントが読み込みを許可されたリソースを管理できるようにします。いくつかの例外を除いて、大半のポリシーにはサーバーオリジンとスクリプトエンドポイントの指定を含んでいます。これはクロスサイトスクリプティング攻撃 (クロスサイトスクリプティング) を防ぐのに役立ちます。 https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Content-Security-Policy レスポンスヘッダーの Content-Security-Policy フィールドにてサイトに必要なリソースを宣言することでリソースの管理が行えます。CSPに宣言されていないリソースは読み込まれないため、悪意のあるリソースの読み込みを回避しクロスサイトスクリプティング攻撃（XSS攻撃）を防ぐことにつながるようです。 Charlesでデバックする CharlesのRewriteという機能を使用すればHTTPリクエスト/レスポンスの内容を書き換えることが可能です。早速、レスポンスヘッダーの Content-Security-Policy フィールドにGA4のディレクティブを追加していきます。 1.Charlesを選択した状態でアプリケーションメニュー > Tools > Rewriteを選択する Charlesを起動してアプリケーションメニュー > Tools > Rewriteの順序で添付画像のRewriteを選択します。 2.Enable Rewriteのチェックボックスにチェックを入れ、Rewrite Settingsを追加する Rewrite SettingsでEnable Rewriteを有効にし、Rewriteの設定を新規作成するのでAddを選択します。設定の名前は modify csp としました。 次に、Rewriteの対象となる該当のURIを添付画像の赤枠箇所のAddから設定していきます。 URIをProtocol、Host、Port、Path、Queryに分けて記載することで、Locationの設定は完了です。 最後に、Rewrite Ruleにてレスポンスヘッダーの Content-Security-Policy フィールドの修正を設定していきます。赤枠箇所のAddからURIの設定の際と同じようにRewrite Ruleの新規作成を行います。 設定項目について順番に解説します。 Type 実行するRewriteのタイプを指定します。今回はレスポンスヘッダーを修正するので Modify Header を選択しましょう。 Where Rewriteを適用する場所を選択します。レスポンスヘッダーを修正するので Response にチェックを入れましょう。 Match 修正するヘッダー名とその値を指定します。値は空白にし、どんな値でも置換されるように、 Match whole value にチェックを入れます。大文字と小文字を区別したい場合は Case sensitive に、正規表現を使用したい場合は Regex にチェックを入れます。 Replace 修正後の Content-Security-Policy フィールドの値を設定します。値にGA4のディレクティブを追加します。値はすべて書き換えるので、 Replace All にチェックを入れます。 以上でRewriteの設定は完了です。 3.該当のサイトにてGA4ログが正しく飛んでいるか確認する 添付画像の通り、意図した通りにGA4ログを確認することができました。 おわりに CharlesのRewriteは、実際にサーバーの設定を変更することなく私自身の環境でデバックすることが可能です、かなり便利ですね。 今回の私のケースのように、外部の会社にサイトの運用を依頼している場合は原因調査に時間とコストがかかると思いますのでCharlesの利用をぜひ検討してみてはいかがでしょうか。 どなたかの参考になれば幸いです。

はじめに こんにちは。エンジニアの中畑（ @yn2011 ）です。 今年の4 月から現在のチームでテックリードの役割を担うようになり、開発チームのパフォーマンスに関心を持つようになりました。開発チームのパフォーマンスという漠然としたテーマを前に、自分は何をするべきなのだろうか？と悩みながら情報収集をしていたのですが、 texta.fm #5 Accelerate で Four Keys と呼ばれる開発組織のパフォーマンス指標（と書籍「 Lean と DevOps の科学 」）について知り、「これは良さそう」と思い開発チームに導入してみることにしました。 今回は開発チームが Four Keys 運用の最初の一歩として、どのような技術を利用して計測と可視化を実現したかご紹介させて頂きます。 なぜやるか Four Keys は既にユーザに対してプロダクトを公開し、継続的なリリースを行っているチームを前提としていると認識していますが、 私のチームでは新規開発を行っていて、まだプロダクトを公開していません。 とはいえ、新規開発においても開発の生産性や健全性に関心を持つことは重要だと考えています。開発チームのパフォーマンスを定量で語れる状況を作ることで、解くべき課題を明らかにし、チームが行った改善の結果を正しく認識することができます。 Four Keys をツールとして捉えれば、新規開発を行っているチームにおいても有用なのではないかという仮説の元、 本質を見失わない程度に Four Keys の定義をチームに合うように変更することで、新規開発においても開発チームのパフォーマンスを定量化できるはず、と考え導入の検討を始めました。 何から始めるか まずは、現在のチームの Four Keys を計測し可視化する仕組みが必要です。Four Keys の運用は私やチームにとって初めての試みなので、最初から大掛かりな計測と可視化の仕組み（システム）を構築するのではなく、できるだけ小さく始めようと計画しました。 そこで、Four Keys のうち開発リードタイムとデプロイ数の 2 つの指標に絞ることにしました。変更障害率とサービス復元時間は取得が難しいことと、プロダクトを公開していないのでそもそも定義できないというのが理由です。システムのアーキテクチャも GitHub Actions と GitHub Pages を使った簡易的な構成から始めてみようと考え、開発を開始しました。 対象とする指標については、新規開発であることを考慮して以下の定義としました。 開発リードタイム: コミットしてから main ブランチにマージされるまで デプロイ数: main ブランチにマージした回数（main ブランチにマージすると開発環境向けのビルドとデプロイを行うため） システム構築 今回は以下の機能を持つシステムを構築しました。 スケジュール実行できる 対象のリポジトリから開発リードタイムとデプロイ頻度を収集する 収集したデータを元に指標をダッシュボードとして Web に公開する（ただし社内メンバーのみアクセス可能） ダッシュボードの更新を Slack 通知する 以下にシステム概要図を示します。 それでは、システム概要図を元に詳細についてご紹介します。 リポジトリ データ収集対象のリポジトリとは別に、Dashboard 用リポジトリを新たに作成しました。Dashboard 用リポジトリでは、GitHub Actions を利用して以下を行っています。 リポジトリからのデータ収集 Dashboard 作成 GitHub Actions でスケジュール実行する 指標は 1週間の中央値や平均値で算出したいので、データの収集と Dashboard の更新は週に 1 度だけ実行します。 例えば、毎週月曜日の日本時間 9 時に実行する場合は以下のように記述します。スケジュール実行に加えて、手動で実行したい場合のために workflow_dispatch: も含めておくと便利です。 // actions.yaml on: schedule: - cron: '0 0 * * 1' workflow_dispatch: 収集する shibayu36/merged-pr-stat を利用して、開発リードタイム（コミットから main ブランチマージまでの日数）とデプロイ頻度（PR のマージ数）を取得します。（main ブランチにマージした際にビルドとデプロイを実行しているのでデプロイ数は PR 数と同等と見なしています） 後続のダッシュボード生成で利用するため、取得した結果は JSON ファイルとして出力します。 今回は「小さく始める」というコンセプトで開発しているので、 1 度取得したデータを永続化せず、GitHub Actions を実行する度に全てのデータを再取得することにしました。当然時間の経過と共に GitHub API のリクエスト数は増えてしまいますが、まだプロジェクトの開始から3ヶ月程度しか経過していないのでしばらくは大きな問題にはならないだろうという判断です（とはいえそのうち何とかしたい） ちなみに、基準日から 7 日間毎のデータを繰り返し取得するため、 zx でスクリプトを書いて merged-pr-stat を実行しています。 実装イメージ while (startDate.add(7, "day").isBefore(now)) { // ...省略 await $`GITHUB_TOKEN=${process.env.GITHUB_TOKEN} yarn merged-pr-stat --start=${isoStartDateTime} --end=${isoEndDateTime} --query="repo:mediba/repo-name"`.pipe($`tail -n +2`); } ※補足ですが、コミット日時がコマンド引数に与えた対象期間外でも PR マージが対象期間に含まれていれば計測対象になります。 zx を使うことで、JavaScript から直感的に分かりやすくシェルスクリプトを実行し、その結果を利用することができます。また、ESM に対応しているため top level await が使える点も便利です。今回は利用していませんが、 Promise.all でコマンド実行を並列化することで処理速度を上げることもできそうです。 可視化する 出力した JSON ファイルを元にグラフを描いて Next.js で SSG します。 react-chartjs-2 を利用して以下のようなグラフを作成しました。 参考用に実装例を掲載します。 PR 数のグラフの場合は、以下のようにオプション（軸ラベル）とデータセットを定義し // 軸の設定 const prOptions = { ...options, scales: { x: { title: { text: "週", display: true, }, }, y: { title: { text: "PR数", display: true, }, }, }, }; // x 軸の目盛りラベル const labels = json.map((d) => `${d.startDate} 週`); // データセット const prs = { labels, datasets: [ { label: "1日にマージされた PR 数の週平均", data: json.map((d) => d.count / 7), borderColor: "rgb(53, 162, 235)", backgroundColor: "rgba(53, 162, 235, 0.5)", }, ], }; Line コンポーネントに受け渡せば OK です。 <Line options={prOptions} data={prs} /> GitHub Pages にデプロイする peaceiris/actions-gh-pages を利用して、生成したダッシュボードを GitHub Pages にデプロイします。GitHub Actions は main ブランチで実行し、SSG で生成したディレクトリを gh-pages ブランチにコミットします。 通知する 最後にダッシュボードの更新を Slack に通知します。今回は使い慣れていたので rtCamp/action-slack-notify@v2 を利用しました。 継続的にチームメンバーへ共有することで Four Keys に対する意識が高まっていきそうです。 まとめ GitHub Actions と GitHub Pages を利用して、定期的に開発リードタイムとデプロイ頻度を収集し可視化する仕組みを作ることができました。 今回は Four Keys に対する取り組みの技術面をご紹介しましたが、今後は新規開発チームで Four Keys を計測・可視化する仕組みを導入した結果、どのようなメリットやデメリットがあったのか等開発プロセスとの関わりについてもご紹介できればと思います。 最後までお読み頂きありがとうございました。

はじめに こんにちは、SRE Unitの北浦( @kitta0108 )です。 皆様、今日も元気にブランチを切っていますか？ 僕は今まで、脳死でDevelopブランチを切っては、 ただただ空を見つめる・・・そんな人生を送っていました。 そんな僕にも救いの光が差し込みまして、 とても上手に運用しているなと思うチームから、 運用論や具体的な方法を聞くことができました。今回はその内容をご紹介したいと思います。 ※ 社内では発案者である下地さん( @primunu )のお名前をお借りして「shimoji-flow」と呼ばれているそうです。 便宜上、当ブログでもそのように呼ばせていただこうと思います。 僕らがGitの運用に求めること たかがブランチ戦略、されどもブランチ戦略。 システム運用の安定化という観点でも、開発アジリティ向上という観点でも、ブランチ戦略を精錬させ、日々見直しをかけていくことは投資対効果の高いものだと個人的には思っています。 内容のご紹介に入る前に、僕らがGitを運用するにあたって、 考慮するべきものは一体どのようなものがあるのか、書き出してみました。 各環境の状態がどのコードベースで適用されているのか可視性が高い状態であること 運用ナレッジの習得量が少なくても運用ができること = シンプルであること 高速且つ信頼性の高いデリバリーが実現できること 前バージョンへの切り戻しが高速且つ容易であること ブランチ構成 上記を踏まえ、ブランチの構成、運用サイクルを以下のようにしました。 運用サイクル デリバリーの工夫点 shimoji-flowでは、デリバリーの速度と信頼性の向上を実現するために、 STG/PRD環境向けのデリバリーに関しては、ビルドとデプロイのトリガーを分離させています。 ビルドの責務はReleaseブランチのGitHashをイメージタグとして、コンテナレジストリへのプッシュまでを行うこととし、 Releaseブランチに機能群が出揃ったタイミングでビルドのワークフローを実行するようにしています。 また、同じビルドから作成されたコンテナイメージをSTG/PRD環境で参照するようにもしています。 このように一つのコードベースによる複数のビルド & デプロイが実行されることにより、 環境差異を最小限に抑えた検証が実現できる = 信頼性の向上 ビルドが事前に行われている = PRD環境へのデリバリーの高速化 が実現できていると感じます。 ※ ご参考: The Teweleve-Factor App I. CodeBase https://12factor.net/codebase まとめ さて、ちゃんと冒頭に述べた要件が満たされているか振り返ってみましょう。 各環境の状態がどのコードベースで適用されているのか可視性が高い状態であること ->Releaseブランチによる各環境へのデプロイ後、環境名のブランチにマージすることにより、コードベースで適用状態がわかるようになりました。 運用ナレッジの習得量が少なくても運用ができること = シンプルであること ->開発の進行においては、Releaseブランチへのマージだけを考えれば良いという点でとてもシンプルかと思っています。ビルドやデプロイのワークフローも必ずReleaseブランチから実行されるという点も仕組み的にシンプルですよね。 高速且つ信頼性の高いデリバリーが実現できること ->上記に述べたデリバリーの仕組みにより実現できました。 前バージョンへの切り戻しが高速且つ容易であること ->各環境名のブランチにリリース後、マージする運用を取り入れているので、いざ切り戻しが必要になった場合、そのブランチのどのコミットまで戻せばいいのかという点に議論は収束されます。 環境名のブランチが存在するのでパッと見の可視性が高いのも個人的に○な点かなと思います。 さいごに shimoji-flowいかがでしたでしょうか。 さすが2年間運用していて、たくさん改善もされているとのことだったので、完成度の高いものだと個人的には思いました。 良きものは世に出さねばと思って筆を取らせていただいた次第でしたが、みなさんにも、ブランチ戦略見直しのきっかけや、プラクティスの取り入れなどで活用いただいたら大変に嬉しく思います！！

はじめに こんにちは。エンジニアの野崎です。最近は現場でプロダクトの開発を行いつつ、 兼務としてセンター全体の課題解決にあたり、テックリードというロールを持ち、複数のプロダクトにまたがるテクノロジーセンターの課題を 技術的な点を軸にしながら解決に向けて取り組んでいます。 ※参考記事： [2020年度エンジニア組織について | mediba Creator × Engineer Blog] 本記事では、21年度上期に検討し取り組み始めた 「システムガイドラインの運用」 について その内容と背景をお伝えてしていきます。 特に今後エンジニアとして弊社に入社を検討頂ける方に向けて、 どのように技術と組織について考えているかをお伝え出来ればと思います。 medibaにおける非機能要件/運用要件 このガイドラインは弊社の開発において、 機能要件以外の、いわゆる 非機能要件や運用要件 についてのものになります。 プロダクトのサービスグレードや商流の違いによって差異はありますが、 概ねそのプロダクトだけでこの非機能要件や運用要件のすべてを定義するようなことはなく、 medibaとして、あるいはKDDIグループ企業として 標準化された非機能要件/運用要件をベースに検討することがほとんどです。 これら非機能要件/運用要件の内容ですが、 性能やセキュリティに関するアプリケーションやインフラを対象にしたもの、 システム全体の可用性を対象にしたもの、 システムの運用における管理やリリースなどを対象にしたもの、 監視や障害に関するもの、などなど多岐にわたります。 また、これらの実施管理は一元化されているわけではないため、 ある項目は具体的な要件から設定方法・実現方法まで記載されている、 またある項目は要求事項のみしかなく実現方法は個別に検討が必要なものなどあります。 また当然プロダクト毎の機能的な要件と、これらの非機能要件/運用要件の整合性も取らなくてはならず、 総合的な理解が必要となってきます。 こういった面から、非機能要件/運用要件の把握からその実現方式の検討、継続的な運用まで どうしてもスキルや経験が高いエンジニアに集中しがちで属人化することが課題となっています。 この課題を解決するために、 「システムガイドライン」 を再整備し、その運用を始めました。 ※正確に言うと、「システムガイドライン」の作成は数年前に作成されていましたが、現状の課題/運用に適さなくなっていたため再整備を行ったという形となります。 システムガイドラインとは システムガイドラインは、 Github上で管理されており、「前文」と「アプリケーション」「インフラ」「セキュリティ」「システム運用」「リリース」などと言ったようないくつかの業務別のページに分かれています。 「前文」には、ガイドラインの目的や使い方、修正方法などが記載されています。 業務別のページの内容は、上述した非機能要件/運用要件を元に具体的な実現方法を記載しています。 一例として、「アプリケーション」の業務別ガイドラインにおいては、 管理システムのログは、どのような内容を出力するか・どれくらいの保持期限にするか といったことが具体的に記載されています。 このガイドラインを新規メンバーの参画時、あるいはチームの組成時などに読み合わせ理解を深めて貰い、 実際のシステムの設計や実装時にどのような内容にすれば良いかの手助けにしてもらいたいと考えています。 また、ガイドラインの内容の変更に関してですが、 このような文章は横断的な非機能要件/運用要件の変更やアーキテクチャの発展などにより 最新に保つ必要があります。 変更するのが特定のエンジニアに偏らないように、また組織全体で変更内容を議論していくために エンジニアなら誰でも修正のPullRequestを送れるようなフローにしています。 最後に 今回は、「システムガイドライン」の運用についてお伝えさせて頂きました。 まだ運用を始めたばかりで目に見える効果はありませんが、 組織全体で継続的に内容を理解し修正して活用していくことで 横断的にプロダクトの品質向上に寄与して行くと考えています。 ビジョン：「良いもの」を届け続ける また、この取り組みはいちエンジニアのスキルの向上にも寄与すると考えています。 私たちのビジョンに『「良いもの」を届け続ける』がありますが、 自身の成長にも繋げてほしいとの想いもあります。 「システムガイドライン」を通して『「良いもの」を届けたい』エンジニアの方の応募をmedibaではお待ちしております。

こんにちは、medibaのエンジニアカルロスです！ 昔、暗号(crypto)に強い関心があったにもかかわらず、暗号通貨にはあまり興味が持てません。Bitcoinは始まったころに少し採掘していましたが、大した量は稼げずウォレットのログイン方法も覚えていません。 尚、生活側面の全てを計装化された経済に移行することに対する現代の興奮には共感できません。 厳密に言えば、技術的なレベルだと、私はまだ信者になれていません。 そこで、現在web3について注目すべき点をふまえた上で、いくつかの点を徹底的に勉強して、見逃していることがあるか確認することにしました。 Web 1.0と2.0についての意見 web3はやや曖昧な用語であり、web3の野心を厳密に評価することは困難ですが、一般的な理論では、以下になります。 web1:分散化 web2:すべてをプラットフォームに集中化 web3:すべてを再び分散化 web3はweb2の豊かさを提供しつつ、分散化されています。 まずは、集中型プラットフォームが何故登場した理由をある程度明確にするほうがいいでしょう。私の考えでは、説明は非常に簡単です! 誰も自分のサーバーを管理したくないし、決してしません web1の前提は、ネット上の全ての人がコンテンツの発行者であると同時に消費者であり、インフラストラクチャの発行者と消費者でもあるということでした。 皆が、個人サーバーの上に個人ウェブページをホストし、個人のメアドのための個人のメールサーバーを用意し、個人のステータスメッセージ用の個人のフィンガーサーバーがあるようにします。 しかし、強調してもしすぎることはないだろうと思いますが、一般ユーザーがこれを望んでいることではないでしょう。一般ユーザーは自分のサーバーを管理したくないし、それはオタクでもしたくないことです。ソフトウェアを開発している組織でさえ、現時点ではサーバーを管理したくないです。私たちがこの世界について学んだことを1つ挙げるとしたら、それは人間がサーバーを管理したくないということです。 だから、代わりにそのサービスを提供してくれる会社は成功しました。そして、それらのネットワークの上の可能であることを拡張して新しい機能をイテレーション(※１)した会社はさらに成功しました。 プロトコルはプラットフォームよりもはるかにゆっくりと移動します 30年以上経っても、電子メールはまだ暗号化されていません。一方、WhatsAppは1年で暗号化されていない状態から完全なe2eeに移行しました。 未だにIRCを介してビデオを確実に共有することを標準化しようとしていますが、一方、Slackでは、ユーザーの表情に基づいてカスタムのリアクション絵文字を作成できます。 これは資金調達の問題ではなく、何かが完全に分散化されていると、変更が非常に難しくなり、時の流れの中で取り残されたままになることがよくあります。これはテクノロジーの問題であり、エコシステムの動きが非常に速くて常に並走していなければ置いていかれます。膨大な数の人々のグループを編成して早く移動できるようにする方法を見つけることが非常に重要であるため、アジャイルのような方法論の定義と改善に焦点を当てた並行業界全体が存在するのでしょう。 テクノロジー自体が動きよりも停滞を助長するとなると大問題です。成功の確実な秘訣は、時間に追われていた90年代のプロトコルを採用し、それを集中化して、迅速に反復することだと考えられます。 しかし、web3の意図は違うところにあるので、そのことを確認してみましょう。技術の感じをつかんで将来がどうなるかをよりよく理解するためにいくつかのdAppを利用してNFTを作成することにしました。（今後自分で作成したいみたいと思いますが…） 分散型アプリケーション(dApp)を使ってみました web3を感じ取るために AutonomousArt というdAppを使ってみました。これにより、NFTに視覚的な貢献することで、誰でもNFTのトークンを発行できます。視覚的な貢献をするためのコストは時間の経過とともに増加し、貢献者がミントのために支払う資金は以前のすべての貢献者に分配されます（この財務構造はピラミッド型に似たものになります）。 そして、原資産を追跡する金融デリバティブのように、原資産を追跡するNFTデリバティブを作成、発見、交換させてくれる FirstDerivative というdAppも使ってみました。 どちらもdAppの仕組みを感じさせてくれました。正直にいうと、アプリ自体について特に「分散」されているものはありませんでした。アプリは通常のReactのウェブサイト… その「分散性」とは、ステートとそのステートを更新するためのロジック/権限が存在する場所になります。その場所は「集中型」データベースではなく、ブロックチェーンの上です。 私がいつもおかしいと思っているのは、クライアント/サーバーのインターフェイスへの注意の欠如です。誰かがブロックチェーンについて話すときには、信頼の分散、指導者のない総意、そして仕組みがどのように動いているかについて話しますが、多くの場合最終的にクライアントができないことは何であるかがうやむやになっているように思えます。 どんなネットワーク図にも載っているものはサーバーばかりで、信頼モデルもサーバー間のものであり、すべてはサーバーに関するものです。ブロックチェーンはピアのネットワークとして設計されていますが、モバイルデバイスまたはブラウザがピアになれるようには設計されていません。 たとえば、モバイルでもPCでも、AutonomousArtやFirstDerivativeのようなdAppは、ステートの変更またはレンダリングするため何らかの方法でブロックチェーンとやり取りする必要があります。ただし、ブロックチェーンはモバイルデバイス（もしくはＰＣブラウザー）上で動作できないため、クライアント側からこれを行うことは実際には不可能でしょう。したがって、唯一の代替手段はどこかのサーバー上でリモートで実行されているノードを介してブロックチェーンと対話することです。 やっぱりサーバーだ！でも、すでに書いたように、人はサーバーを管理したくありません。偶然にも、サービスとしてetheriumノードへのAPIアクセスを販売する企業が出現し、分析、拡張API、および履歴トランザクションへのアクセスを提供しています。なんか聞いたことありますよね…現時点で、ほとんどすべてのdAppは、ブロックチェーンと対話するために2つの会社を使っています。InfuraまたはAlchemy。実際、MetaMaskのようなウォレットをdAppに接続し、dAppがウォレットを介してブロックチェーンと対話する場合でも、MetaMaskはInfuraを呼び出しているだけです。 これらのクライアントAPIは、ブロックチェーンの状態や応答の信頼性を承認しようとしていません。結果は署名すらされていません。AutonomousArtのようなアプリは、「このスマートコントラクトでのこのビュー機能の出力は何ですか」と訊いて、AlchemyまたはInfuraは、「これは出力だよ」というJSON BLOBで応答し、アプリがそれをレンダリングします。 これは驚きでした。信用不要(※2)の分散型コンセンサスメカニズム(※3)の構築には多大な労力、エネルギー、時間が費やされてきたのに、それにアクセスしたいほとんどのクライアントは、検証なしに、この2つのサービスからの出力を単に信頼しています。また、プライバシーの面からも最善ではないでしょう。すべてのwriteトラフィックは、もちろんブロックチェーン上ですでに公開されていますが、この2つのサービスはほぼすべてのdAppのユーザーからの読み取り要求を可視化することが可能となっています。 NFTを作る それから、もう少し一般的なＮＦＴを作成してみたいと思いました。ほとんどの人は、NFTについて考えるときに画像やデジタルアートについて考えますが、普段はNFTがそのデータをチェーン上に保存しているわけではありません。ほとんどの画像のNFTの場合、これは非常に費用のかかるものです。画像のデータをチェーンに保存する代わりに、データを指すURLになっています。この標準について私が驚いたのは、URLにあるデータにハッシュコミットメントがないことです。数十ドル、数百ドル、または数百万ドルで販売されている人気のある市場のNFTを見ると、そのURLは、Apacheを実行しているVPSを指していることがよくあるようです。そのマシンにアクセスできる人、将来そのドメイン名を購入する人、またはそのマシンを侵害する人は、NFTの画像、タイトル、説明などをいつでも好きなように変更できます（そのトークンを「所有」していないにもかかわらず）。NFT仕様には、画像が「こうであるべき」や、「正しい」かどうか確認させてくれるものは何もありません。 インターネットを再現する web1がweb2になった理由を考えると、web3の奇妙なところは、ethereumのような技術がweb1で既に明らかになっているはず多く罠で構築されていることです。これらの技術を使用可能にするために、プラットフォームを中心に統合されています。また同じことが起こっています。あなたの代わりにサーバーを運営し、出現する新しい機能をイテレーションするサービス。それはInfura、OpenSea、Coinbase、Etherscan、などです。 同様に、web3プロトコルの進化は遅いです。 例えば、 First　Derivativeは原資産の価値のパーセンテージとしてミントの価格を設定することもできたけれど、そのデータはチェーン上にありません。OpenSeaが提供するAPI内にあります。多くの人がクリエイターに利益をもたらす方法でNFTの特許権使用料に期待していますが、使用料はERC-721で指定されておらず、変更するには遅すぎます。そのため、OpenSeaには、web2スペースにその使用料を構成する独自の方法があります。集中型プラットフォームでの迅速な反復は、すでに分散プロトコルを上回り、制御をプラットフォームに統合しています。この方法だと暗号通貨ウォレットでのNFTのビューがOpenSeaのNFTのビューになっているとしても驚きはないでしょう。OpenSeaは、標準を変更することが不可能/困難で、可能な範囲を超えてプラットフォームを反復することに忙しいため、置き換え可能な純粋な「ビュー」ではないことに驚くことではありません。 これはメールの状況と非常に似ていると思います。自分のメールサーバーを運用することはできますが、プライバシー、検閲への抵抗、または制御に関しては、私が送受信するすべてのメールの裏にGMailがいるから、結局意味がありません。分散型エコシステムが利便性のためにプラットフォームを中心に集中すると、両方の世界の悪い部分だけを抽出した形になってしまいます。集中管理されていますが、時間内に混乱するほど十分に分散されています。自分のNFTマーケットプレイスを構築することはできますが、OpenSeaがユーザーが使用するウォレット内のすべてのNFT（およびエコシステム内の他のすべてのアプリ）のビューを仲介するため特別な制御は何も提供できません。 創造性は十分ではないかもしれません web3を試しに少しやってみただけですが、この小さな試しの視点から見てみると、なぜこれほど多くの人たちがweb3エコシステムをとてもきれいだと思うのかが簡単にわかります。集中化されたプラットフォームから離せてくれる軌道になっていることやテクノロジーとの関係が根本的に変わるとは思いませんし、プライバシーのところもすでにインターネットの水準を下回っていると思いますが、私のような開発者がここで何かを構築することに興奮している理由もわかります。少なくとも新しいものであり、初期のインターネット時代を思い出させる創造性/探索出来るようなスペースになっているからです。皮肉なことに、その創造性の一部は、おそらくweb3を非常に不格好にする制約から生じています。今目にしている創造性と探求が前向きな結果をもたらすことを願っていますが、過去のインターネットと同じ帰結を防ぐために十分かどうかはわかりません。 テクノロジーとの関係を改善したいのなら、意図的にやらなければならないと思うのは： インフラストラクチャを分散させずに信頼を分散できるシステムを設計することで、皆が自分のサーバーを管理しないという前提を受け入れる必要があります。 ソフトウェア構築の負担を軽減するよう努めるべきです。 しかし、正直いうとGameStopとLoopRingが作ろうとしているマーケットプレイスには少し期待があります！！ 私からは以上です。最後まで読んでいただきありがとうございました。 参考 ※1 https://it-trend.jp/development_tools/article/32-0022 ※2 https://komugi.jp/?p=859 ※3 https://support.okcoin.jp/hc/ja/articles/4403552067865

こんにちは、データアナリストの左海です。 最近アサインされたプロジェクトにてアプリ/WebのGoogle Analytics 4(以下GA4)での計測を検討していましたが、私自身アプリもGA4も知見がなかったため、SwiftUIでネイティブアプリを作成しログ検証を行うことにしました。 ※なお、Apple Developer Programを契約していないためiOS Simulatorを使用しています。 実行環境 XcodeのVersion：13.2.1 (13C100) iOS Simulatorの名前：iPhone 13 iOSのversion：iOS 15.2 最終的にできたもの 以下の通り、テストアプリを作成しGA4のDebugViewでscreen_viewイベント、カスタムイベントが意図したタイミングで飛んでいるか検証可能になりました。 作業手順 以下の作業手順の通りに進めていきます。 SwiftUIでネイティブアプリの作成を行う ネイティブアプリへFirebase SDKを追加する GA4のDebugViewでログを検証する それでは、ネイティブアプリ作成の流れ、Firebase SDKの追加、GA4を用いたログ検証について説明していきます。 1.SwiftUIでネイティブアプリの作成を行う 画面遷移のイメージ まずは、XcodeでFirebase SDK追加に必要なアプリの作成を行います。 ここでは、3つの画面を作成します。画面遷移は添付画像のようなイメージです。 ContentView SubView MyWebView ContentViewの作成 ContentViewから作成します。ContentViewでは、SubView、MyWebViewそれぞれに遷移するリンクを作成し、Buttonも画面右上部に配置します。加えて、イベント送信処理も追加します。 画面遷移は以下の通り NavigationLink を用います。 destination には遷移先のView名を、 Text() にはリンクに表示する文字列を記述します。 NavigationLink(destination: SubView()) { Text("Go SubView") } NavigationLink(destination: MySecondWebView(urlString: "https://test-c1632.web.app/")) { Text("Go WebView") } screen_viewイベントはインスタンスメソッド onAppear でContentViewが描画されたタイミングで送信します。 イベントパラメーターとして、 screen_name と screen_class を定義しておきます。 同様の処理をSubView、MyWebViewでも記述していきます。 .onAppear() { Analytics.logEvent(AnalyticsEventScreenView, parameters: [AnalyticsParameterScreenName: "\(ContentView.self)", AnalyticsParameterScreenClass: "\(ContentView.self)"] ) } 次に、画面右上部のButtonをタップした際に送信するカスタムイベント button_tap を追加します。イベントパラメータとして button_name を定義します。今回送信するイベント送信処理の記述は以上です。 Button(action: { let button_name = "hoge" Analytics.logEvent("button_tap", parameters: ["button_name" : button_name as NSObject,] ) } SubViewの作成 ContentViewの遷移先であるSubViewの作成を行います。ここではダミーの遷移先を設定しておきました。 MyWebViewの作成 ContentViewの遷移先であるMyWebView画面の作成を行います。MyWebView画面は私が作成したWebサイトを表示します。 WebサイトはFirebase Hostingで公開しています。 これでアプリの作成は終了です。以下の通り、問題なくビルドすることができました。 2.アプリへFirebase SDKを追加する アプリに接続するFirebase プロジェクトを新規作成する 作成したアプリにFirebase SDKを追加します。まずは、 Firebase コンソール でアプリに接続するための Firebase プロジェクトを新規作成します。 作成したアプリをFirebaseに登録する プロジェクト概要 > iOS+ アイコン > 設定ワークフローに進みます。すると、Apple バンドルIDの入力を求められます。 ナビゲーターエリアの上のプロジェクト名 > TARGETS のプロジェクト名 > General タブでApple バンドルIDを確認できます。 設定ファイルのダウンロード ダウンロードした GoogleService-Info.plist ファイルをXcode プロジェクトのルートに移動し、すべてのターゲットに追加します。 Firebase SDKを追加する Firebase SDKはいくつかインストール方法がありますが、今回はCocoaPodsを利用します。 Podfileを作成する プロジェクトディレクトリのルートから次のコマンドで、Podfileを作成します。 pod init PodfileにFirebaseAnalyticsを追加する アプリで使用する'Firebase/Analytics'をPodfileに追記します。 # Add the Firebase pod for Google Analytics pod 'Firebase/Analytics' # For Analytics without IDFA collection capability, use this pod instead# pod ‘Firebase/AnalyticsWithoutAdIdSupport’ # Add the pods for any other Firebase products you want to use in your app# For example, to use Firebase Authentication and Cloud Firestore # pod 'Firebase/Auth' # pod 'Firebase/Firestore' Podをインストールする pod install を実行します。ただし、M1 Macだと上手くインストールできないことがあるようです。 私の環境下ではターミナルのアーキテクチャに依存していたので以下のページを参考に、ターミナル > 右クリックで「情報を見る」 > 「Rosettaを使用して開く」 に事前にチェックを入れます。そうすることで、問題なくPodがインストールできました。 【参考】M1 Macでpod installを実行する pod install Podインストールが完了すると、 .xcworkspace ファイルが作成されます。以降は .xcworkspace ファイルからXcodeプロジェクトを開きます。 初期化コードを追加する アプリ起動時に Firebase を接続するには、Xcodeプロジェクトの@mainアトリビューションの指定の場所に指定のコードを追加します。 import SwiftUI import Firebase //追記 @main struct testApp: App { var body: some Scene { WindowGroup { ContentView() } } init() { FirebaseApp.configure() //追記 } } これで、Firebase SDKの追加は完了です。 3.GA4のDebugViewでログ検証を行う 最後に、GA4でログ検証を行います。早速ログ検証といきたいところですが、事前にいくつか設定を行う必要があります。 Debug Modeを有効にする Xcodeを開き、メニューバー > Product > Scheme > Edit Scheme > Run > ArgumentsのArguments Passed On LaunchにFIRDebugEnabledを追加することで、Debug Modeを有効にします。 Firebaseの自動ログ取得をオフにして手動ログ取得を設定する 今回SwiftUIとの相性かもしれませんが、自動ログ取得では画面遷移でscreen_viewイベントが飛んだり飛ばなかったりしていたので、手動でログ取得をする実装にしています。 Info.plist ファイルに以下を追加することで自動ログ収集をオフにします。 Key：FirebaseAutomaticScreenReportingEnabled Value：NO(Boolean) デバック時にXcodeのReport Navigatorで以下のようなログが確認できれば、自動ログ収集がオフになっています。 Analytics screen reporting is disabled. UIViewController transitions will not be logged. ログ検証 Debug Viewでscreen_viewイベント、buttun_tapイベントが計測されているのが分かります。問題なくログが飛んでいます、検証完了です。 BigQuery連携 BigQueryに連携してエクスポートされているログを確認しました。添付画像のカスタムイベントbutton_tapのログは実装した通り、button_name に設定した値 hoge が格納されています。 おわりに 今回無事にアプリを完成させてログ検証を行うことができました。私自身プログラミング未経験だったため、取り組む前は分からないことだらけでした。具体的には、プログラミングの基礎がなく、エラーの解決方法が分かりませんでした。他にもターミナルやGitHubで何ができるのかすら知りませんでした。 しかし、Udemyで学習したり、分からないことを一つ一つ検索エンジンで調べることで問題解決することができました。アプリ制作の場面はエラーの連続でしたが、エラーを解決した瞬間が最も楽しかったです。 そして、何を取り組むにしても「やればできる」と自信がつくようになりました。これからもさまざまなことにチャンレンジしていきます。 どなたかの参考になれば幸いです。

はじめまして、mediba FEエンジニアの楊です。 最近猫パンチ避け上手になっているので、猫を困らせています。 React Native初見 ネットで調べてみて、第一印象は「可愛いかった」です。 その他に感じた印象は下記です。 facebookのcross-platformフレームワークで、1回書いたらAndroid、iOS、Web全部動くだろう。 React Native（以下RN）という名前付けなので、React開発者にとって、使いやすいだろう という浅い認識で、チームメンバーと一緒にRNのプロジェクトを書いてみました。 React Native振り返る ある程度コードを書いてみると、以下の事に気が付きました。 バージョンアップが早い 最近のリリースを見ると1年間3個のメインバージョンがもうリリースされて、RNのバージョン管理が課題になりそう、特にキャッチアップには、互換性の問題が目の前に debugの難しさ Web開発と比べると、RNでよくみる真っ赤な画面のエラー画面あるが、それのメッセージだけで、フロントかネイティブかのエラーの判断は難しい 要素の高さがスクリーンの高さを超えたらスクロールできない Webだと生まれつきでスクロールできるけど、RNの場合一番外側にスクロール可能のエレメントでwrapしてあげないと iOSとAndroidにおいての違い ある程度RNがその違いを埋めてくれてますが、それぞれの環境に依存した処理がある（外部libで済む場合も） リストの選択 RNのリスト、元々listViewとflatList二つもあって、listviewは性能的な問題で放棄されて、flatListが推奨されてます（実際カルーセルを作った際に困ってた） つまり、RNは依存心の強い子でした。 印象的ポイント RNを触ってみて、一番興味深いところというと、native codeで書いたSDKを扱える部分でした、いわゆる Native Module Bridging というものです。 前述の通りある程度RNがiOSとAndroidの違いを埋めてくれてますが、それぞれのOSに依存したAPIはJSでの扱いは不可なものもあり、あるいはより高いパフォーマンス的、マルチスレッド的に作りたい場合、native moduleを介してそれを実現できます。 実際手を動かして、 公式ドキュメントをみながら、自分なりに簡単な「hello-world」を作ってみました。（学校でJavaを学んでたので、個人的に親切な Android を選んだ^^） ステップ： 環境設定 なんとなく動くnative code書く RNを介して、native moduleとして、JS側にに披露(expose)する JS側で呼び出し 環境設定 公式ドキュメント に沿って環境設定できます。JavaScript(以下JS)、TypeScript(以下TS)両方作れますが、 自分はTSのテンプレートを作りました(TS最高) なんとなく動くnative code書く 環境設定終わりましたら、下記のandroidのフォルダで作業をしていきます（自分はJavaの構文あまり自信ないから、Android Studioでandroidフォルダーを開いてコードを書いているw） android/app/src/main/java/com/awesomeproject の配下で HelloModule.java という新規Javaファイルを作ります。 ファイルの中身はこんな感じ： public class HelloModule extends ReactContextBaseJavaModule {    private static ReactApplicationContext reactContext;    HelloModule(ReactApplicationContext context) {        super(context);        reactContext = context;    }    public static void setTimeout(Runnable runnable, int delay){        new Thread(() -> {            try {                Thread.sleep(delay);                runnable.run();            }            catch (Exception e){                System.err.println(e);            }        }).start();    }    @ReactMethod    public void sayHelloToPopUp(String name) {        Toast.makeText(reactContext,"Hello World,"+name,Toast.LENGTH_LONG).show();    }    @ReactMethod    public void sayHelloAfterThreeSecond(String name, Promise promise) {        setTimeout(()->promise.resolve("Hello after 3 seconds,"+name),3000);    }    @NonNull    @Override    public String getName() {        return "HelloModule";　//この命名でNativeModulesに追加    } }; とりあえず試しに、下記二つの関数を作ってみました。 AndroidのToastを使って出力できる sayHelloToPopUp Promiseを返す sayHelloAfterThreeSecond App(JS側)に披露(expose)する init後に自動生成された android/app/src/main/java/com/awesometsproject/MainApplication.java の中身を見てみると protected List getPackages() {          @SuppressWarnings("UnnecessaryLocalVariable")          List packages = new PackageList(this).getPackages();          // Packages that cannot be autolinked yet can be added manually here, for example: ※        // packages.add(new MyReactNativePackage()); ←この行を解放          return packages;        } 既に用意してくれたPackage名でpackageを作ります。上記のファイルと同じフォルダー配下で MyReactNativePackage.java のファイルを作成し、nativePackage作り、NativeModuleに先程作成したHelloModuleを追加すれば完成です。 public class MyReactNativePackage implements ReactPackage {    @NonNull    @Override    public List createViewManagers(@NonNull ReactApplicationContext reactContext) {        return Collections.emptyList();    }    @NonNull    @Override    public List createNativeModules(            @NonNull ReactApplicationContext reactContext) {        List modules = new ArrayList<>();        modules.add(new HelloModule(reactContext));        return modules;    } } JS側で呼び出し 最後の一歩は、App.tsxで使うことですね。   import { NativeModules } from 'react-native';   まずNativeModulesをimport,それから先程作った sayHelloToPopUp と sayHelloAfterThreeSecond を呼び出します！  const { HelloModule } = NativeModules  const sayHello = React.useCallback((words)=>{    HelloModule.sayHelloToPopUp(words)  },[])  const sayHelloThreeSecondsLater = React.useCallback(()=>{    HelloModule.sayHelloAfterThreeSecond('lalalalala').then((res)=>sayHello(res))  },[]) ... <button title="{"> 最後、rootでyarn androidすれば、起動を待ち、シミュレーターが立ち上がってアプリインストール完了、アプリでpressボタンをポチる 3秒後に添付画像のトーストが出てきます 感想 RNのようなクロスプラットフォームのフレームが宣伝したように、「一回書いたらどのプラットフォームでも動ける」という理想があるが、 実際にプロジェクトを作るに当たって、ネイティブアプリもフロントを全部理解し、一人でのiOS,AndroidとWeb全てのコードを書けることはありえない。 しかしRNを架け橋に、ネイティブチームとフロントチームを連携し、斬新なビッグ（B.I.G）フロントチームを生み出せるではないでしょうか。 ことわざの通り「理想なき者に成功なし」^^

こんにちは。Eng6G バックエンドエンジニアの土屋( @hrktcy )です。もうすぐ社会人2年目ということで月日の流れがとても早く感じます。 はじめに 現在開発中のプロダクトで、API リクエストパラメータに含まれるお客様の個人情報をデータベースに暗号化して格納するためにAWS Key Management Service(KMS) を導入することになりました。導入するにあたり、KMS での暗号化のリクエストパフォーマンスが、開発中のシステムに定めたSLA に耐えうる性能かを検証する必要がありました。本記事ではその結果を共有したいと思います。 検証項目 出力するものは以下の3つです。 平均暗号化処理時間(ms) 各暗号化処理時間を昇順にソートした際の90パーセンタイル値(ms) 最大暗号化処理時間(ms) 環境 ローカル環境でGolang で検証用のサンプルコードを書きます。そしてクロスプラットフォームビルドによって生成されたバイナリファイルをS3 にPUT し、EC2から実行します。 言語 Golang SDK aws-sdk-go-v2 実行場所 EC2(t2.micro/x86) 暗号化する文字列を作成する関数を定義する まず、検証用の文字列[0-9a-zA-Z](32文字)を生成する関数を定義します。生成には math/rand パッケージを用いてランダムな文字列を生成するようにします。生成数はコマンドライン引数から指定できるようにしておきます。 package main import ( "math/rand" ) func randomStr(n int) string { letters := "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz" lettersLen := len(letters) dst := make([]uint8, n) for i := 0; i < n; i++ { l := rand.Intn(lettersLen - 1) dst[i] = letters[l] } return string(dst) } 暗号化処理を行う関数を定義する 暗号化処理を行うexec 関数を定義します。この関数をgoroutine で並行処理するようにします。sync.waitGroup のDone() をdefer することで、処理の最後に完了を知らせるようにしておきます。 var wg sync.WaitGroup var keyID = "*******" // マスターキーのKeyID var client *kms.Client // data 結果格納用構造体 type data struct { Encrypted []byte ProcessTime time.Duration } func exec(plain string, results *[]data) { defer wg.Done() // 計測開始 start := time.Now() // keyIDと暗号化する文字列を代入 input := &kms.EncryptInput{ KeyId: &keyID, Plaintext: []byte(plain), } // 暗号化リクエスト output, err := client.Encrypt(context.TODO(), input) if err != nil { fmt.Printf("Got error encrypting data:%v\n", err) return } // 暗号化文字列と処理時間をdata型の変数に代入する result := data{ Encrypted: output.CiphertextBlob, ProcessTime: time.Since(start), } *results = append(*results, result) } main 関数を実装する 前述の関数を用いてmain 関数を実装します。main 関数ではrandomStr 関数で生成した文字列を格納する配列を用意し、KMS クライアントを生成してから暗号化処理をgoroutine で並行処理させます。なお、for ループの中でtime.Sleep() させることでTPS を調整できるように設定し、ループ処理が終了したら検証項目を計算して出力するようにします。 package main import ( "context" "flag" "fmt" "log" "math/rand" "sort" "sync" "time" "github.com/aws/aws-sdk-go-v2/config" "github.com/aws/aws-sdk-go-v2/service/kms" ) // data 結果格納用構造体 type data struct { Plain string Encrypted []byte ProcessTime time.Duration } var wg sync.WaitGroup var keyID = "*******" // KeyID var client *kms.Client var num = flag.Int("num", 100, "暗号化実行回数") var interval = flag.Int("interval", 1, "-interval ") // randomStr ランダム文字列を生成する関数 func randomStr(n int) string { letters := "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz" lettersLen := len(letters) dst := make([]uint8, n) for i := 0; i < n; i++ { l := rand.Intn(lettersLen - 1) dst[i] = letters[l] } return string(dst) } // exec 並列処理する関数 func exec(plain string, results *[]data) { defer wg.Done() // 計測開始 start := time.Now() // keyIDと暗号化する文字列を代入 input := &kms.EncryptInput{ KeyId: &keyID, Plaintext: []byte(plain), } // 暗号化リクエスト output, err := client.Encrypt(context.TODO(), input) if err != nil { fmt.Printf("Got error encrypting data:%v\n", err) return } // 暗号化文字列と処理時間をdata型の変数に代入する result := data{ Encrypted: output.CiphertextBlob, ProcessTime: time.Since(start), } *results = append(*results, result) } func main() { flag.Parse() // 検証用文字列準備 maxStrLen := 32 plainList := make([]string, *num) for i := range plainList { plainList[i] = randomStr(maxStrLen) } // KMSのクライアントを作成 loadOptions := []func(*config.LoadOptions) error{config.WithRegion("ap-northeast-1")} sdkCfg, err := config.LoadDefaultConfig(context.TODO(), loadOptions...) if err != nil { panic("configuration error, " + err.Error()) } client = kms.NewFromConfig(sdkCfg) // 暗号化処理実行 results := make([]data, 0) for _, v := range plainList { wg.Add(1) go exec(v, &results) time.Sleep(time.Millisecond * time.Duration(*interval)) } // 終了を待つ wg.Wait() // 結果判定 success := len(results) if success < 1 { log.Fatal("empty success result") } // あらかじめ昇順でソートしておく sort.Slice(results, func(i, j int) bool { return results[i].ProcessTime < results[j].ProcessTime }) // 平均暗号化処理時間を計算 total := int64(0) for _, v := range results { total = total + v.ProcessTime.Milliseconds() } fmt.Printf("avg:%dms\n", total/int64(success)) // 90パーセンタイル値を計算 percentile := int(float64(success)*0.9 - 1) fmt.Printf("Percentile:%dms\n", results[percentile].ProcessTime.Milliseconds()) // 最大暗号化処理時間を計算 fmt.Printf("max:%dms\n", results[success-1].ProcessTime.Milliseconds()) } 検証結果 500(req/sec)で400個の文字列暗号化を行った場合 avg(ms) 90 percentile(ms) max(ms) 9 9 68 500(req/sec)で1000個の文字列暗号化を行った場合 avg(ms) 90 percentile(ms) max(ms) 7 8 61 暗号化処理を増やした場合でも各暗号化処理時間に大きな差は生まれませんでした。しかし、最大暗号化処理時間は90パーセンタイル値よりも大幅に時間がかかっていることがわかりました。この値は初回暗号化処理時間の値でしたので、2回目以降はKMS クライアントを使い回しており、初回はKMS クライアントを読み込んでいる分時間がかかっているのではないかという推測をしました。 暗号化処理毎にKMSクライアントを読み込んでみたらどうか main 関数内で行っているKMS クライアント作成処理をexec 関数内に移動し、暗号化リクエストの都度クライアントを作成するように変更してリクエストパフォーマンスを検証してみます。 同様の条件で検証を試みたところ、以下のIMDSの認証エラーが生じてしまい暗号化が行えませんでした。 Got error encrypting data:operation error KMS: Encrypt, failed to sign request: failed to retrieve credentials: no EC2 IMDS role found, operation error ec2imds: GetMetadata, http response error StatusCode: 429,request to EC2 IMDS failed [参考]:429 Too Many Requests そこで、暗号化処理数を減らして処理速度を計測してみます。 500(req/sec)で10個の文字列暗号化を行った場合 avg(ms) 90 percentile(ms) max(ms) 52 65 73 500(req/sec)で100個の文字列暗号化を行った場合 avg(ms) 90 percentile(ms) max(ms) 749 2113 2158 処理数を増やすと応答時間が長くなることが分かりました。TPS を下げてみたらどうなるでしょうか。 100(req/sec)で100個の文字列暗号化を行った場合 avg(ms) 90 percentile(ms) max(ms) 28 39 54 TPS を下げると各処理時間もだいぶ落ち着きました。 まとめ KMS クライアントを使い回すパターンでは初回暗号化処理時間に少し時間がかかるものの、暗号化処理数を変えても各処理時間に大きな差は生まれませんでした。一方、都度KMS クライアントを読み込ませるパターンでは、応答時間が長くなる+大量の暗号化処理を行う場合はTPS を下げる必要がありそうです。

初めに こんにちは。エンジニアの野崎です。最近は現場でプロダクトの開発を行いつつ、 兼務としてCTO準備室に所属しテックリードというロールを持ち、複数のプロダクトにまたがるテクノロジーセンターの課題を 技術的な点を軸にしながら解決に向けて取り組んでいます。 ※参考記事： 2020年度エンジニア組織について | mediba Creator × Engineer Blog 本記事では、テックリードの取り組みとして21年度上期に検討し取り組み始めた 「新規開発時の技術選定の指針」 について その内容と背景をお伝えてしていきます。 特に今後エンジニアとして弊社に入社を検討頂ける方に向けて、 どのように技術と組織について考えているかをお伝えて出来ればと思います。 これまでの技術選定方針 これまでは、新規開発時には各プロダクト毎に利用する技術（ツール・ソフトウェア)を選定して来ました。 各プロダクト毎に利用する技術（ツール・ソフトウェア)を選定することで、 プロダクトやそのチームにあった開発をし、新しいものを積極的に取り入れることを目指していました。 この方針で数年たちましたが、この点は達成できてきました。 ただ、その中で特に運用保守において上手くいかない点・歪みが生まれてきました。 今回「新規開発時の技術選定」の指針にて、部分的に利用する技術(ツール・ソフトウェア）の指針を設けることによって 複数のプロダクトにおいても横断的に運用保守をより効率的に品質高く行うことを目指したものになります。 新規開発時における技術選定の指針 今回取り決めた「新規開発時の技術選定」の指針について、 そのまま公開は出来ませんので、3点にポイントを絞って説明します。 ■指針1. 以下の領域において、基本となるツール・ソフトウェアを指針を定義する パブリッククラウド コンピューティング バックエンドアプリケーション開発のプログラミング言語 データベース CI/CD環境 ここでは全て記載しませんが、 例えば「パブリッククラウド」においては「AWS」を利用すること基本とする、といった内容です。 また、ここに挙げた領域以外のもので検討中のものもあります。 例えば「ネイティブアプリケーション」についてですが、 社内で開発運用実績もありますが担当するチームが一つになっていることもあり、検討している段階になります。 領域やツール・ソフトウェアの選定に当たっては、 プロダクトにとってコアとなる技術領域か、ライフサイクルはどのくらいを見込んでいるかなど鑑み、 既存システムでの採用事例・既存メンバーのスキルセットを重要視し選定を行いました。 ■指針2.「指針1」に記載されていない場合は、センター内で話し合い決定する 今後新規開発時の要求要件によっては、「指針1」で定義したものでは実現出来ない可能性ももちろんあります。 その場合は、新規開発の担当チームだけではなく、他の開発チームも含めセンター内で話し合って決定していきます。その上で、導入事後のフィードバックを行い再評価します。 ■指針3.「指針1」の内容は1年程度のスパンで見直しを行う 「指針1」の内容も、長い年月を経ると継続的なメンテナンスに問題が出たり、 より良い代替のツール・ソフトウェアが出てくる場合もあります。 そういったメリット・デメリットを評価せずに技術を硬直化させることは望んではいないため、 定期的に内容を評価・見直していきましょう、ということです。 これら指針を軸に、 「横断的な検討→試行→評価」のサイクルを目指すことが骨子にあたります。 medibaにおける開発の特徴 ここでは、medibaにおける開発の特徴を取り上げ、 「新規開発時の技術選定」の背景を説明します。 大きな特徴として、 一つのプロダクト(システム）の新規開発から運用（グロースフェーズ）・保守まで、 社内で一気通貫で対応することが挙がります。 また、「新規開発」や「運用」を専門にするチームはなく、 あくまでプロダクト毎でのチームで担当するのも特徴的です。 社内で扱うプロダクト（サービス）数は数十ほどあり、 必然的にチーム組成の機会が多くなります。 下記の図を使って説明します。 例として、プロダクトAとBの時系列で「新規開発」「運用」「保守」のフェーズと その時点で必要とされるエンジニアを図示してみました。 プロダクトBの運用フェーズ開始時について考えてみます。 簡単のためにプロダクトAの運用メンバーが、プロダクトBの運用を担うことになる場合、 プロダクトAとBの採用技術が大きく異なる場合、 その技術的な習得、オンボーディングなどに大きく時間を取られてしまい、 本来運用（グロースフェーズ）に期待されるような積極的な開発やシステムの安定性を高める取り組みが達成できない、 あるいはそもそもチーム組成が難しいといった課題が発生してきました。 このような背景から上述の「新規開発時の技術選定」の指針を作成しました。 最後に ビジョン：「良いもの」を届け続ける テクノロジーセンターのビジョンとして、『「良いもの」を届け続ける』があります。 日々現場での業務を行っていると、 短期的な納期や自チームのメンバーにしか意識が集中することが多く、視点が狭くなりがちです。 時にはこう言ったビジョンに立ち返り、長期的に組織全体や業界全体にも目を向けつつ 「良いもの」を届け続けるために、自分たちが使う技術をより良く変化させていくことは、 組織としても個人としても更なる成長に繋がると信じています。 ビジョンの実現のために、 地道に一歩ずつ一緒に取り組んで頂けるエンジニアの方の応募をmedibaではお待ちしております。

mediba Advent Calendar 2021 の 18 日目の記事です。 こんにちは。エンジニアの中畑（ @yn2011 ）です。最近は Switch の月姫で直死の魔眼について学んでいます。 初めに プロダクトを新規に開発する際に、どんな Lint ツールを導入し、どのような設定で利用するかは悩むことが多いです。最終的にはチームメンバーと議論をして決めていく必要がありますが、社内外の他のプロダクトでどのようにしているか参考事例が欲しい場合があります。業務で開発したプロダクトのコードベースは社外に公開されることは少ないため、他社でどのような Lint ツールを導入しているのかを知る機会は少ないです。 そういった背景から、直近のプロダクト開発において ① どんな Lint ツールを導入しているか、② 特に工夫している設定は何か、 という Lint にフォーカスした内容を書いたらどうだろうと考え、今回の記事のテーマとしました。 昨年から引き続き、mediba のプロダクトでは Next.js の採用が増えています。その中のとある Next.js 採用プロダクトを例として今回ご紹介します。 tsc TypeScript です。Next.js 9 以降は、TypeScript 関連の機能はビルトインされていて yarn build 時に型検査を行いますが、型検査だけを任意のタイミングで行う場合は、 tsc -p . --noEmit のようなコマンドを実行します。Lint ツールではありませんが、型検査のためにだけ使用しているので一応記載しました。 ESLint ESLint です。Next.js 11 以降は、ESLint 関連の設定をビルトインするようになり、 next lint で実行と設定ができます。 Next.js 向けのコンフィグとして、 eslint-config-next があります。以下のルールはオフにしています。 "@next/next/no-img-element": "off", "@next/next/no-html-link-for-pages": "off", "@next/next/next-script-for-ga": "off", "@next/next/no-sync-scripts": "off", Next.js の機能を活用するためのルールをなぜオフにしているか疑問に思われるかもしれませんので理由を説明します。 no-img-element は、Next.js が提供する next/image を使用せずに、img 要素を使用している場合に警告を行うルールです。プロダクトでは、SSR ではなく、SSG を使用していて next/image は未使用なのでオフにしています。 no-html-link-for-pages は、Next.js が提供する next/link を使用せずに anchor 要素のみを使ってリンクを実装している場合に警告を行うルールです。next/link を使用することで、CSR でページ遷移を実現することが可能になりますが、mediba で利用している Google Analytics 向けの実装ではページ遷移時の集計に懸念があることが分かっています。そういった理由から意図的に next/link を使用しないようにしているため、ルールをオフにしています。 next-script-for-ga と no-sync-scripts は、 next/script の仕様をきちんと調査できていなかったので暫定的に script 要素を使用していましたが今後対応するかもしれません。 Stylelint Stylelint です。プロダクトでは、styled-components のような JS in CSS ではなく、 .scss ファイルに定義した CSS を CSS Modules から利用しているためプロパティの並び順の auto fix 等、Stylelint の機能を全て活用することができています。 プロパティの並び順定義は、 stylelint-config-recess-order を使用しています。定義されているプロパティの数とメンテナンスの頻度の面で、他のライブラリや自身で作成するよりも良さそうだったため選定しました。 また、 Prettier を使用しているので stylelint-config-prettier で競合を防いでいます。 markuplint markuplint です。HTML Living Standard の仕様に準拠した HTML になっているかを検証できます。React (JSX) にも対応しています。 ルールを独自に追加しています。 { "nodeRules": [ { "selector": "meta[property]", "rules": { "invalid-attr": { "option": { "attrs": { "property": { "type": "String" }, "content": { "type": "String" } } } } } } ] } meta 要素の属性についてです。SNS でページを共有された際の挙動を定義するため、このような meta 要素を実装することが多いと思います。 <meta content="ページタイトル"> この実装は markuplint が 2 つ警告を出します。まず、HTML Living Standard の meta 要素の仕様には、property 属性が定義されていないため警告を出します。 また、name 属性が定義されていない場合に、content 属性を使用することができないため、こちらについても警告を出します。 では一体この属性は何なんだ、という話になりますが、property 属性については RDFa で定義されており、 OGP に従ってこの meta 要素を SNS 側が解釈します。したがってここでは例外として取り扱うようにルールを変更しています。 なお、React 独自の属性（ key や dangerouslySetInnerHTML ) は @markuplint/react-spec に含まれているため独自にルールを追加する必要はありません。便利です。 まとめ 直近の Next.js 採用プロダクトを例に、使用している Lint ツールと、その設定についてご紹介しました。これらの Lint ツールは全て GitHub Actions で commit push をトリガーにして実行していますので、ルールに違反しているコードをコミットするとすぐに気づくことができ、Lint ツール運用の形骸化を防ぐことができています。 Lint ツールの導入によって、コードベースをクリーンに保つことはもちろんですが、標準仕様やベストプラクティスを知る良いきっかけにもなっています。 Lint ツール導入時の参考になれば幸いです。最後までお読み頂きありがとうございました。

はじめまして、mediba 新卒2年目 データアナリストの左海です。 mediba Adventカレンダー 10日目ということで、私からはGTMを使用して自社サイトにMicrosoft Clarity(ヒートマップツール)を設定したお話を書いていきます。 Microsoft Clarityでできること Clarityとは、Microsoft社から2020年10月にリリースされた無料のヒートマップツールです。 Clarityでできることは、主に以下の3つです。 サイト訪問者数、離脱者数、任意のページにおけるスクロールされた割合など基本数値を把握できる 1ユーザーにフォーカスして、サイト上でどんな行動をしたのかセッションレコーディング(録画)できる どこをクリックして、どこまでスクロールしたのかヒートマップで視覚的に可視化できる 導入編 設定手順 GTMを使用する場合は、以下の順に設定していきます。 Microsoft Clarity アカウントを作成する GTMを使用し、Clarity tracking codeを配信する GTMのプレビューで、設定したタグが配信されているか確認後、公開する Clarityの管理画面で、正しく数値が計測されているか確認する Microsoft Clarityのアカウントを作成する Microsoft Clarity にアクセスし、赤枠箇所をクリックしてアカウントを作成します。その後、必要事項を記入します。 GTMを使用し、Clarity tracking codeを配信する Clarity管理画面 > Settings > SetupからClarity tracking codeをコピーし、GTMのタグ設定画面のHTMLに貼り付けます。 GTM側で、タグの作成とトリガーの設定を行います。 タグの作成は、GTM 管理画面 > タグ > 新規 から作成をします。タグとトリガーの設定は以下の通りです。 タグの種類：カスタムHTML トリガーの設定：All Pages 以上で、タグの作成とトリガーの設定は完了です。 GTMのプレビューで、作成したタグが問題なく配信されているか確認する GTMのプレビュー画面のTags FiredにMicrosoft Clarityタグが確認できました。問題なく、タグが発火されているようです。公開ボタンをクリックします。 GTMの設定は以上になります。 Clarityの管理画面で、正しく数値が計測されているか確認する 最後に、Clarityの管理画面で、問題なく数値が計測されているか確認します。タグ公開から2時間ほどで、Clarityのダッシュボード画面に数値が反映されました。 ヒートマップのデータも反映され、活用できるようになっています。 GTM経由で、自社サイトにClarityの設定が完了しました。 Session Recordingsについて 以下の通り、Session Recordingsも活用できるようになっています。ユーザーのカーソルの動きが鮮明に閲覧できます。 活用方法の検討 Clarityはどういった場面で活用することができるのかを検討しました。ここでは、仮設として、任意のページの次のページへの遷移率が減少傾向であるとします。そうすると、以下のような課題発見から意思決定までの流れがが考えられます。 課題発見 まずは、課題を設定します。ここでは、仮の課題として、「任意のページの次のページへの遷移率が減少傾向である」とします。 現状把握・要因調査 GAの定量データを使用し、課題の要因を突き止めようとします。しかし、定量データだけでは、特に要因が分かりません。 次に、Clarityを使用して、任意のページで何が起こっているのかセッションレコーディングとヒートマップで要因を調査します。例えば非活性箇所がクリックされているような場合には「誤クリックで離脱している」と言えるかもしれません。 方策 方策として以下の案が浮かぶのではないでしょうか。 クリックできない箇所をクリックできるように活性させる 以上のように、GAの定量データでは普段発見できないようなユーザーの行動でもClarityを使用すれば、簡単に把握することができるでしょう。その結果、意思決定につながると考えています。 おわりに GTMを使用することで、エンジニアに依頼せずとも、Clarityを設定できるのは便利かと思います。 Clarityは無料でかつ実装に手間がかかりません。そして、ヒートマップやセッションレコーディング機能など多様な機能も魅力的です。ぜひご自身のサイトにClarityを導入してみてはいかがでしょうか。 どなたかのご参考になれば、幸いです。

こんにちは。エンジニアの中畑（ @yn2011 ）です。千葉県は最高です。 今回は NewRelic ブラウザモニタリング を使用して JavaScript のエラー収集を行おうとした際に、NewRelic のソースマップアップロード機能の仕様で色々とハマってしまったというお話をします。 ソースマップアップロード API について NewRelic ブラウザモニタリングでは、ソースマップというファイルを利用して発生した JavaScript エラーのスタックトレースを取得することができます。 ソースマップは、以下のような内容のファイルです。 { "version": 3, "file": "static/chunks/254-be419541614271942b8c.js", "mappings": "gFAAoEA,... } NewRelic ブラウザモニタリングにはソースマップのバージョン管理機能があり、ソースマップにユニークな識別子をアップロード時に付与することができます。提供されているソースマップのアップロード API を利用してアップロード時に識別子の付与ができます。 publishSourcemap({ sourcemapPath: './dist/bundle.js.map', javascriptUrl: 'https://example.com/assets/bundle.js', ... releaseName: 'OPTIONAL RELEASE NAME', // 追加 releaseId: 'OPTIONAL RELEASE ID', // 追加 }, function (err) { console.log(err || 'Source map upload done')}) releaseName と releaseId を指定できることに違和感を持った方もいるかもしれません。これは次項の伏線です。 ハマリポイント releaseId と releaseName は両方必須 早速伏線を回収します。NewRelic ブラウザモニタリングでバージョン管理を行う場合は、 releaseName と releaseId の両方が必須になります。 ドキュメントに記載はないように認識していますが、 @newrelic/publish-sourcemap の実装を確認すると、しっかり条件式に含まれていました。 if (releaseName && releaseId) { console.log('Using release name:', releaseName, 'and release id:', releaseId) request = request.field('releaseName', releaseName) request = request.field('releaseId', releaseId) } コミットハッシュを活用する場合など、どちらか 1 つの項目を利用できれば十分なことが多いと思います。なぜこのような仕様になっているのかは分かりませんでした。 コンフリクトエラー ソースマップのバージョン管理を行わない場合は、 releaseName と releaseId を指定する必要はありません。しかし、1 度これらの項目を空でアップロードしてしまうと、次にアップロードする際に releaseId と releaseName を指定してアップロードしてもコンフリクトエラーというレスポンスが返り、アップロードが失敗します。 コンフリクトエラーは、NewRelic に同一のソースマップをアップロードした場合に発生する仕様となっています。 releaseName と releaseId が異なる場合は別のソースマップとして解釈されるためアップロードが可能です。 バージョン管理を行う場合は、1度、 releaseName と releaseId が空のソースマップを削除し、再度アップロードする必要があります。 ブラウザ側で addRelease を呼び出す必要がある ソースマップのバージョン管理を行う場合、ブラウザ側で browser agent API から次のメソッドを呼び出す必要があります。 newrelic.addRelease(string $release_name, string $release_id) このメソッドを呼び出さないと、発生した JavaScript エラーを正しいバージョンのソースマップにマッピングすることができません。メソッドを呼び出さずに JavaScript エラーを発生させた場合、NewRelic の画面上では releaseName と releaseId は空になります。 addRelease の呼び出しの実装としては、スニペットの末尾への追加が可能です。 NewRelic ブラウザモニタリングを利用する場合は、New Relic から提供されるスニペットをブラウザで実行する必要があります。このスニペットの実行後に、browser agent API が利用可能になるため、以下のように末尾に呼び出しを追加します。 // 省略... applicationID:"${config.applicationID}",sa:1}; newrelic.addRelease("foo", "bar"); // 追加 addRelease の呼び出しは、類似サービスである Sentry では不要であったため、検証時に気づかずハマってしまいました。 まとめ NewRelic ブラウザモニタリングのソースマップに関するハマりポイントを 3 つ書きました。 最終的に、プロダクトではソースマップバージョン管理機能の導入は見送りましたが、今後必要に応じて対応を検討する予定です。 最後までお読み頂きありがとうございました。

はじめに こんにちは、SRE Unitの北浦( @kitta0108 )です。 当ブログは、執筆活動をモブでやったらどうかという新しい試みをしておりまして、 テクノロジーセンター6G Managerの下地さん( @primunu )、 SRE Unitの板谷さん( @mary_tuba )、 そして北浦の3人でお送りしております。 さて、皆さんはアプリケーションの実行基盤としてのコンテナイメージを選定するとき、どのような関心軸を持って望んでますか？ 今回はDistrolessイメージについて、何の嬉しみがあるのか、どのような優位性があるのかなどを深掘りっていきたいと思います。 皆さんの引き出しの一つとして、知見に加えていただけるようなことがあったならとても嬉しく思います！ 対象者 イメージを選定する人 = DockerFileを書く人 イメージの脆弱性対応を強めたい人 コンテナサイズの軽量化を追い求めたい人 概要 Distrolessとは、Googleが公開しているアプリケーションとそのランタイム依存のみが含まれたDebian10(buster)に基づいて作成されたコンテナイメージです。 https://github.com/GoogleContainerTools/distroless 必要な依存のみが含まれるとは？ Distrolessにはアプリケーションの実行に必要な依存しか含まれていません。 なので、Shellはおろか、aptやcdといった機能も有していません。 だが、それが良い。それで良いのです。以下をご覧ください。 この図はAWSのECRにそれぞれ以下のプレーンイメージをプッシュした結果になります。 （Goのアプリケーションを動かすという前提でイメージを選んでます。） alpine:3.13 golang:1.16.5-buster gcr.io/distroless/static-debian10 どうでしょうか。この時点で嬉しみポイントが2つ見えていませんか？ 嬉しみポイントその1 軽量であるということ Debianの318MBというのは置いておいてw Alpineの2.81MBと比較してもDistrolessの0.66MBはめちゃくちゃ軽いです。 コンテナを扱う上では、インフラの振る舞いとして、スケーリング性能や可搬性の向上を期待したいですから、この軽量ポイントは嬉しいですよね。 嬉しみポイントその2 セキュアであるということ 実はこっそりとECRにImage Scanning機能をONにしておきました。 ここでもDistrolessイメージは堂々のNoneの文字が…！ アプリケーションを実行する上で余分な依存が含まれないということは、それだけ脆弱性が露呈する可能性が低くなることにも繋がります。 コンテナイメージのレイヤーでここを抑えられるのは嬉しいポイントですよね。 イメージのバージョン上げ作業の頻度も少なくなりそうです。 まとめ 今回はアプリケーションコンテナのイメージとしてDistrolessを紹介してみましたがいかがでしたでしょうか。 利用している言語がDistrolessに対応しているのであれば、積極的に利用を検討してもいいと個人的には思います。 ただし、Distrolessを利用したイメージの作成にはShellが含まれていないという点でちょっとしたコツが必要になります。 時間があったら、イメージの作成方法などを具体的にしたものを書いてみようかな…！！

はじめまして、2021年度新卒の木村です。 フロントエンドエンジニアとして テクノロジーセンター5G に所属しています。 今回は、Nuxt.js ならびに TypeScript を利用して、簡単な抽選ツールを作成してみた内容についてご紹介します。 Nuxt.js と TypeScript Nuxt.js は、Vue.js ベースの JavaScript のフレームワークです。Webページ構築に有用な UI 以外の機能（ Ajax やサーバーサイドレンダリングなど）をまとめて利用できる環境を提供してくれます。 Nuxt.js 公式サイト TypeScript は、省略可能な静的型付けとクラスベースオブジェクト指向を加えた JavaScript のスーパーセット（上位互換）です。一言で言うと「型定義できる JavaScript 」。 TypeScript 公式サイト なぜ抽選ツールを作ったのか 主な理由は、以下の2点です。 私の所属するチームで扱っている Nuxt.js および Typescript の概要を掴むため チーム内でMTGのファシリテータが偏ってしまう課題を解決するため 完成物 さっそくですが、完成した物がこちら。 ランダムにユーザーを抽選できるシンプルなツールです。 デザインは近年流行ったニューモーフィズムを取り入れてみました。 少ない配色でも凹凸によって奥行きができるので、シンプルなツールでも見栄えが良くなります。 使った技術 Nuxt.js 2.15.7 TypeScript 4.2.4 Vue.js 2.6.14 Vuex 3.6.2 firebase 8.7.1 tailwindcss 2.2.4 sass 1.35.1 環境 M1 Mac VSCode yarn 機能 今回の抽選ツールの機能は以下とおりです。 ユーザーを登録・削除する ユーザー情報をDBで保持する 登録したユーザーからランダムに抽選する 完了した人・休みの人にチェックし、抽選対象から外す 抽選終了後、選ばれた人は自動で完了チェックされる 全員チェックしたら一括リセットできる 作成手順 全体的な流れは以下のとおりです。 環境構築 各機能作成 Vuex導入 firebase導入 1. 環境構築 create-nuxt-appを利用して環境を構築しました。 create-nuxt-app 公式サイト と Nuxt.js 入門の記事 を参考にしました。 2. 各機能作成 前述した各種機能を実装していきます。 欠席者の対応 完了した人だけでなく、休みの人など抽選対象から除外したい場合を想定して、完了チェックとは別に除外したいユーザーを指定できるようフラグを持たせています。 コンポーネントについて 個人的に苦労したのはコンポーネント周りです。 まず、どのくらいの単位で区切れば良いのかがわかリませんでした。 そこで今回は Atomic Design を参考に切り出しました。 また、他の箇所でも使えるように汎用的に作ることです。 クリックなどのイベントは全て親へ渡し、スタイルや表示の変更は親から値を渡すようにすることで、atoms単位のコンポーネントがどこでも使えるよう心がけました。 例えばボタンコンポーネントは、予めいくつかのスタイルを定義しておき、親コンポーネントで使うときに下記のように props で必要なスタイルを渡すとともに、$emit でクリックイベントを親に渡しています。 //Button.vue <div> <button :class="[ colorStyle[buttonColor], sizeStyle[buttonSize], fontStyle[buttonFont], ]" @click="$emit('button-click')" > <slot></slot> </button> </div> //Input.vue <Button button-color="gray" button-size="short" button-font="small"> ADD </Button> そしてコンポーネント間のデータの受け渡しです。 例えばユーザー情報は、子から emit で親コンポーネントに値を引き渡し、さらに別の子コンポーネントに props で渡して表示しています。 今回はシンプルなツールなのでコンポーネントも少ないですが、こうした受け渡しが重なってくるとコードが煩雑になりメンテナンスがしづらくなります。そこで、Vuex を導入し状態管理をすることにしました。 3. Vuex 導入 Vuex のストアでユーザー情報の状態を管理します。 今回はDBも使う予定なので、actions でDBに接続した後、値を state に反映させています。 Nuxt.js は store ディレクトリにファイルを作成するだけでストアを有効化してくれるので便利ですね。今回は管理するのがユーザー情報だけなので、index.ts を作らず users.ts を直下に作りました。 Vuex ストアでデータを一元管理できるので、本当にわかりやすくなりました。コンポーネントを超えて共有される情報を管理するには、とても強力なツールだと思います。 一方で、Vuex を使用する際には、注意点もあります。 例えば、小さいレベルのコンポーネントからは Vuex を使用しない方が良いでしょう。 コンポーネントの使い回しが難しくなるのと、１画面の中で複数の箇所から Vuex のストアへの参照と変更が入り組んだ場合、処理が追いにくくなるためです。 参考： Vuexはなるべく避ける 　　　 Vuexで何をするか、何をしないか Vuex を利用する際は、 Atom や Molecule レベルのコンポーネントの中では使わない 、 state を直接参照しない 、などのルールを設けて運用したいと思います。 4. firebase 導入 DBとデプロイは firebase を利用します。 firebase は以前にも使ったことがありましたが、やはり firestore を使えば面倒な手間をかけずにDBが実装できますね。万歳。 デプロイも firebase の Hosting を使って行いました。 さらに、今回は社内向けツールなので、デプロイにあたり外部からのアクセスを制限するため、 Authentication を使用してログイン認証を追加します。管理者アカウントとしてユーザーを一人だけ登録し、簡単なPWを打てば誰でも使えるようにしました。 ログインしていない状態では認証後のページへ飛べないようにするため、強制的にindexへリダイレクトするmiddlewareも追加しています。 const auth = firebase.auth() const middleware: Middleware = ({ route, redirect }) => { auth.onAuthStateChanged((user) => { if (!user && route.name !== 'index') redirect('/') }) } また、Authentication の認証状態は、デフォルトではユーザーがブラウザを閉じた後でも永続的に維持されるようになっています。 今回は管理者アカウント一つだけの使用になるため、ログアウトせずにウィンドウを閉じてしまうと、他の人がアクセスした時でも前のセッションが続くことになります。 そこで、 firebase.auth().setPersistence メソッドで永続性タイプを SESSION に変更することで、ウィンドウやタブを閉じるたびにログイン状態がクリアされるようにしました。 ちなみに、Nuxt.js には nuxt/firebase というモジュールがあります。firebase をより簡単に利用できるので、興味があればご覧ください。 詰まったところ sass の導入 sass の導入で沼りました。どうやら node のバージョン16 かつ M1チップ だと node-sass が動かないようです（2021/09 執筆時点）。node のバージョンを下げることで解決しました。 型定義 Vuex での型定義、props での型定義、firebase で扱う日時の型定義… 型推論が効かず、気づけばanyになっている型に苦しめられました。 特に Vuex は、ストアへアクセスするための便利な型がなく、今回使用した this.$store は Nuxt.js で型指定されていません。 自前の型を使うか、 nuxt-typed-vuex を利用することで改善するしかないようです。 また、 TypeScript と Vuex の相性は良くなく、コンポーネントから store を呼び出したときに型安全が守られない、インテリセンスが効かないといった問題があります。 次に TypeScript で Vuex を扱う際は、Nuxt.js 公式で推奨されている vuex-module-decorators を使用したいと思います。 振り返り さて、ここまで長々と書いてきましたが、今回のアウトプットを通して Nuxt.js と TypeScript の概要は大体掴めたかな、という感じです。 結論、Nuxt.js 便利！ 日本語ドキュメントが充実していてほぼ誰でも簡単に始めることができる ルーティングを自分で作成する必要がない SSRなどモードを選べるて柔軟なサイト設計ができる …など、Nuxt.js を使うことで直感的にDOMの内容を操作でき、より簡単に抽選ツールを作ることができました。 また、TypeScript についても、型定義のおかげで、コンポーネント間のデータの受け渡しでもどういう型か判断でき、コードが見やすくなります。 さらに、力補完のおかげでコードを書く時間を短縮できる、エラーチェックを機械に任せることができる、など多くのメリットがありました。 一方で、Vuexとの連携は公式で推奨されているパッケージを使うなど、改善の余地があります。 最後に 以上、Nuxt.js を利用して抽選ツールを作成してみた内容の紹介でした。 最後まで読んでいただき、ありがとうございました。 どなたかの参考になれば幸いです。

こんにちは。エンジニアの中畑（ @yn2011 ）です。8 月から千葉県民になります。 先日、新チーム発足にあたり、チームビルディングのワークショップとして有名なインセプションデッキの作成にチャレンジしました。その際に改めてインセプションデッキについて勉強し直したのですが、 実際にチームがどういった経緯で、どのようにインセプションデッキを作成したか 、という具体的な事例の公開が少ないなと感じました。 そこで今回は、私達が ① なぜインセプションデッキを作成し、② どのようにワークショップを進めたのか、③ そして何が得られたのか について書きたいと思います。 なぜインセプションデッキを作成したか 新チーム発足 新プロダクトの開発が決まり、ビジネスチームが先行して企画と要求の洗い出しを行っていました。ある程度の整理が完了したため、デザイナーとエンジニアが合流し、本格的に開発を始めていくぞ、という経緯で新しいチームが形成されました。 したがって、ここで言う「チーム」とは、特定の職種のみで構成されたチームではなく、ビジネスのメンバーやデザイナー等プロダクト開発に必要な全ての職種を含むチームです。 ちなみに、エンジニア同士、ビジネスのメンバー同士はこれまでも同じチームで仕事をしていましたが、エンジニアとビジネスのメンバー同士はほぼ一緒に仕事をしたことがありませんでした。 何が課題だったか デザイナーとエンジニアは途中からビジネスチームに合流したわけなので、これから開発するプロダクトの目的やプロジェクトとして何を重要視しているのか等をしっかり理解できていませんでした。したがって、 プロダクトの要求事項が書かれたドキュメントを読んでも、それが適切なのか、なぜ必要なのかという部分の理解や納得度が低い 状態でした。 また、プロダクトの開発を始めるためには、要求を要件に落とし込んだ上で初回にリリースをする範囲(MVP) を決める必要もありました。 どうするか この 2 つの課題について、チームメンバーと相談し、インセプションデッキを作成することと、ユーザーストーリーマッピングを行うことで課題を解決することになりました。（なお、この記事ではインセプションデッキについてのみ取り扱います） しかし、やろうというのは簡単ですが、実際に私がインセプションデッキ作成のワークショップを企画するにあたり、いくつもの課題に直面することとなりました。とても現場感溢れるものです。 例えば時間の面では以下の課題がありました。 参加して欲しい関係者は 15 人以上で、全員が参加可能な日程の調整が難しい 既に多くの予定が組まれていて、1 時間以上の時間の確保が難しい プロダクトのリリース日は大まかに決まっていたことから、できるだけ早く完了させなければいけない これらの制約から、インセプションデッキは 10 個の項目で構成されていますが、重要だと思ういくつかの項目を選択し、それ以外の項目は検討対象から外しました。そして、ワークショップは 1 回 1 時間で、複数回に分割することとして、何とか全員参加のワークショップ実施の見通しを立てることができました。ちなみに、参加可能なメンバーだけで実施して後で結果を共有する、といったやり方はせず極力全員参加に拘りました。インセプションデッキは結果と同じぐらい構築過程の議論が大事だと考えていたためです。 また、内容の面では以下の課題がありました。 インセプションデッキのワークショップを実際にファシリテートした経験のあるメンバーがいない そもそもインセプションデッキを知らないメンバーも多い これらについては、私が書籍や Web から情報を得つつ創意工夫して実施していくことになりました。 どのようにインセプションデッキを作成したか 検討の結果、ワークショップのアジェンダは以下になりました。かなり厳選し、最低限必要だと思う 3 つの項目のみを選びました。 自己紹介 インセプションデッキの説明 我々はなぜここにいるのか エレベーターピッチ トレードオフスライダー 分割してワークショップを行うことにしていたので、初回は「我々はなぜここにいるのか」までで、次回に残りのアジェンダを消化しました。 では、それぞれどのように進めていったのか、当日の様子と合わせてお伝えしていきます。（「自己紹介」、「インセプションデッキの説明」については一般的なものなので省略します） なお、付箋を使いたいことと、原則在宅勤務のため Miro を使用してオンラインで実施しました。 我々はなぜここにいるのか 「我々はなぜここにいるのか」は、プロジェクトの目的について認識を合わせるためのワークショップです。 最初に個人ワークの時間を取って、1 人ずつ自分の考えを付箋に書いてもらいました。その後に共有の時間を取り、ファシリテーターが補足や質問と、似ている意見のグルーピングをしていきました。 こちらが実際のワークショップの結果です。 グルーピングは難しいですが、大きくは定性的なものと定量的なもので 2 つに分けました。上の図では 3 つに分かれていますが、定性のものを更に 2 つに分割しています。 例えば、定性的な目的は「ユーザに〜という価値を提供する」等で、定量的な目的は「利用率 x % 向上」等です。 基本的にどの意見も間違っているということはないのですが、どうしても定性的なものほど達成できたかどうかを判断しにくく解釈にもブレがあります。定量的で、 達成できなければプロジェクトが解散になるものはどれか と問い直すことで、明確な目的を探していきました。ここは前提となっているインプットの差もあるので、ビジネスチームの方々にリードして決めて頂きました。ただし、今回はこの時点では具体的な数値までは盛り込めませんでした。ひとまずはプロジェクトが向かっていく方向の認識を合わせることが大事なので、計測可能な指標であるならば良いのかなと思います。 エレベーターピッチ エレベーターピッチは、事前に用意されたテンプレートを埋めることで、プロダクトの骨格を明らかにするワークショップです。 ちなみに、通常 エレベーターピッチは 1 プロダクトに対して作成しますが、今回は関連するプロダクトが複数存在していたので同じ時間に複数のエレベーターピッチを作成しました。複数プロダクトを同時に開発する必要があったのです（現実は教科書通りにはいかないということが実感できます） エレベーターピッチの進め方としては、テンプレートの項目を 1 つずつ埋めていく方法を取りました。1 つの項目毎に、個人ワーク → 共有 → グルーピング → 最終的な答えという手順を踏みました。（初めは、一気に全ての項目を埋めてもらい 1 人ずつ共有してもらったのですが、付箋の整理がしにくいのと、最初の項目の認識が合っていないと後半の内容も異なってくるのでやり方を変えました） こちらが実際のワークショップの結果です。右の付箋が個人ワークで書いて頂いたもので、左の赤い付箋が整理した結果です。 エレベーターピッチで意見が分かれやすかったのは「ユーザは誰なのか」と「差別化要素は何なのか」でした。定義が難しいからなのか、 経験上この部分が曖昧なままプロダクトの開発が進行することも多いので最初に確認できる のはこのワークショップの利点だと感じました。 トレードオフスライダー トレードオフスライダーはプロジェクト（プロダクト）で何を大切にするかの優先順位を決めるワークショップです。 今回はプロダクトというよりは初回のリリースまでに時間を区切ったプロジェクトとしての優先順位として検討しました。 けっこう悩みましたが、進め方は以下にしました。（付箋をドットシールとして利用するイメージです） 個人ではなく職種ごとに色分けした付箋を利用する（エンジニアなら黄色等） 個人毎に自分の職種に該当する付箋を利用して、1 番優先順位が高いと思うものに投票 次に 1 番優先順位が低いと思うものに投票 投票結果を元にプロジェクトとしての合意を形成する こちらが実際のワークショップの結果です。今回は都合により予算は検討から外しました（予算の増減が実質的に不可） スライダーの各項目は、スコープ、時間、品質等の言葉が使われますが、必要に応じて言い換えを行うことによって参加者の認識齟齬を防いでいます。 個別の要素の評価値が 2 なのか 3 なのかといった部分はあまり議論せず、重要なものについてざっくりと認識を合わせました。優先順位が中間のものについては、正直あまりプロジェクトの進行中に意識されることは少ないと思ったためです。また、個人毎ではなく、職種毎にしたのは参加人数が多いためです。職種毎の傾向を大まかに把握した方が効率良く議論できると考えました。 トレードオフスライダーによって、 リリースの期日に対するステークホルダーの温度感等、プロジェクトの制約について全員の認識を揃えることができる のは利点だと感じました。また、プロジェクト中盤での機能追加や方針変更に対して、トレードオフスライダーの優先順位に従って意思決定や議論を行える点も魅力的です。 インセプションデッキをやってみてどうだったか インセプションデッキのワークショップの終了後に、参加者の方々から感想を頂きました。 インセプションデッキの作成がどういったものか知ることができた ワークショップ形式で議論ができたことによって、プロダクトについて理解が深まったり認識齟齬があることに気づけた といったポジティブな感想を頂きました。インセプションデッキによって、 当初の課題であった「プロジェクトの目的や何を重要視しているのかの理解不足」を補うことに貢献できたと言えそうです 。 また、プロダクトについてもエレベーターピッチによって複数観点から議論することで、以前より理解が深まりました。 テンプレートが決まっていることによって、観点漏れが少ないのと、質問しにくいことも全て議題に乗せることができる のも良かったです。次の工程であるユーザーストーリーマッピングを行うための最低限の共通認識の形成にも役立ちました。 一方で 発言に偏りがある ツールの使い方には少し戸惑った 最終的なまとめをもう少ししっかりやりたい といった意見も頂けました。 発言の偏りについては、私のファシリテーション能力が足りていないのと、ワークショップの時間にゆとりを持たせることができなかったことも一因だと思います。時間に追われていて、進行を優先しすぎていました。 ファシリテーションの際には、 インセプションデッキを完成させることだけが目的ではなく、全員でフラットな議論をすること・共通の認識を作ることも意識することが大事 という学びがありました。 また、最初に Miro の使い方に慣れる時間や、最後にインセプションデッキ全体を振り返る時間も考慮したアジェンダを作成するとより良いものになりそうです。 まとめ 新チームの発足にあたり、インセプションデッキの作成を行うに至った経緯と、ワークショップの実施方法、その結果得られた成果や知見について書きました。 新しいプロジェクトを始める際や既存のプロジェクトの方向性が曖昧になってしまっていると感じられている方は、インセプションデッキの作成に挑戦してみると何らかの手がかりになるかもしれません。 最後までお読み頂きありがとうございました。

はじめに はじめまして、2021年4月新卒入社の土屋( @hrktcy )です。バックエンドエンジニアとして6月にテクノロジーセンター Eng6G に所属しました。 背景 Eng6G では スマプレチャレンジ と呼ばれるサービスを、サーバレスなシステムを構築して開発・保守・運用しています。またバックエンドには Go を採用しており、比較的モダンな技術スタックによるプロダクト開発が行われています。 [参考]mediba に入社したらアジャイル志向のチームで最高だった件〜モブワーク無双でテレワークを超越します〜 Go は基本的に暗黙的型変換が認められないため、開発関連のタスクを全てモブで行う弊チームにおいて、ナビゲーターがレビューしやすいというメリットがあります。またモダンな技術を扱うことで、エンジニアとしての市場価値も高まると考えています。 そこで Go 未経験の私がバックエンドエンジニアとしてジョインするにあたり、学習とアウトプットを兼ねて、本稿では  Go でスクレイピングした  mediba+  の記事を Slack に投稿するバッチを作った話 を備忘録として残したいと思います。 開発環境 M1 Mac Docker 20.10.7 Golang 1.14 Terraform 1.0.1 AWS provider 3.49.0 事前準備 Slack API トークンを生成しておく Slack に投稿する App を作成し、予め API トークンを取得しておきます。   Slack API  へアクセス 「  Create an app  」をクリック 「  Create New App  」をクリック 「 名前 」と「 ワークスペース 」を指定する アプリを作成した後に表示されたページで「  Permissions  」をクリック 「  Scopes  」の項目で  chat:write  権限を設定 「  Install App to Workspace  」をクリックし API トークンを取得する バッチの仕様を固める Go でスクレイピングした mediba+ の記事を Slack に投稿するにあたり、まずはバッチの仕様を固めることにしました。 スクレイピング方法 スクレイピング系のパッケージ(  goquery  , etc. )を用いることもできますが、今回は mediba+ の RSS フィードをパースすることでスクレイピングを行います。当たり前ですがスクレイピング先の情報が更新される度にフィードの内容は変更されます。バッチ実行時点の日時と、スクレイピング先の記事日時を参照する必要があります。そこで今回は、バッチ実行時点の日時に更新された記事のみを Slack に投稿するようにします。 同一記事を重複して投稿しない バッチを実行するたびに同一記事が投稿されるのは避けたいです。これについてはテーブルにスクレイピングした記事情報を格納しておき、 Slack に投稿する文章を生成する前段階で、記事が投稿されたものなのかを判定する必要があります。 バッチの運用方法 バッチプログラムを任意の日時に実行されるような環境を整えたいです。これについては ECS Fargate + CloudWatch Events で任意の日時にバッチが実行されるような環境を構築することで解決します。本稿では以下のシステムを構築しました。本システムは Terraform によって一元管理しています。 ソースコード 1. DB へ接続する Go の OR マッパーとして提供されている  gorm  を用いて、 env ファイルに記載した DB の情報から接続を行います。 DBTYPE := "mysql" USER := os.Getenv("USER") // ユーザ名 PASS := os.Getenv("PASS") // パスワード ENDPOINT := os.Getenv("ENDPOINT") //エンドポイント DBNAME := os.Getenv("DBNAME") //データベース名 CONNECT := USER+":"+PASS+"@tcp("+ENDPOINT+":3306)/"+DBNAME+"?charset=utf8&parseTime=True&loc=Local" db, err := gorm.Open(DBTYPE, CONNECT) if err != nil { fmt.Println("DB接続失敗") panic(err) } fmt.Println("DB接続成功") 今回接続先のテーブル情報は下図の通りです。 記事タイトル(title)と URL (link)、投稿済み判定(status)の3つのカラムを定義してあります。 2. mediba+ の記事をスクレイピングする RSS フィードからバッチ実行時の日時に投稿された記事をスクレイピングしテーブルへ insert します。フィードの取得には  gofeed  を用います。 # mediba+をスクレイピングする fp := gofeed.NewParser() feed, _ := fp.ParseURL("https://koho.mediba.jp/feed/") 変数 feed にはパースされたフィードが格納されており、 feed.Items で投稿記事全てを取得することができます。今回はバッチ実行時点の日時に更新された記事のみを取得するために、要素1つ1つを for 文で回し、各記事の投稿日時とバッチ実行時の日時を比較します。 比較するにあたり、パースされた PubDate(UTC) は string 型なので time 型と比較することができず、スクレイピング先によってはフォーマットも違う可能性があるため合わせてあげる必要があります。また PubDate を JST にする必要もあります。 こちらについては RFC1123Z フォーマットで統一しました。まず PubDate を time.Parse で変換します。さらにそれを RFC1123Z のフォーマットに変換し、タイムゾーンを JST にすることで、投稿日時とバッチ実行時の日時を比較します。公式フォーマットは こちら から参照できます。 // RSS構造体 type Article struct { link string published string } // RSSのPubDateを文字列→日時の型に変換、それをRFC1123ZのFormatに変換し、タイムゾーンをJSTにする for _, item := range feed.Items { m := make(map[string]Article) if item == nil { break } var timeParse = time.Time{} timeParse, _ = time.Parse(time.RFC1123Z, item.Published) pubDateJST := timeParse.In(time.FixedZone("Asia/Tokyo", 9*60*60)).Format(time.RFC1123Z) // 以下Insert処理 ... } 投稿日時とバッチ実行時の日時が同じ時、構造体 m に記事の情報を格納し、 gorm を用いてテーブルに insert すれば OK です。このとき、 status カラムにはデフォルト値として false を入れておきます。 3. Slack に投稿する Slack に投稿する処理は以下の通りです。 // envファイルに記載したAPIトークンからクライアントを生成する tkn := os.Getenv("TOKEN") c := slack.New(tkn) _, _, err := c.PostMessage("#チャンネル名", slack.MsgOptionText( " テキスト " , true)) if err != nil { panic(err) } else { fmt.Println("投稿完了") } テーブルに格納されている、投稿日時がバッチ実行時の日時と同じ且つ status が false の記事のタイトルとリンクを取得し、 slack.MsgOptionText の第一引数に代入します。記事1つ1つを連投すると Slack の通知が多くなり煩わしく感じるので、 string 配列の中に取得した記事とタイトルを append していき、 strings パッケージの strings.Join を用いて、各要素を結合してから投稿処理を行うようにしました。 投稿処理が完了したら gorm を用いて status カラムの値を true に update することで、バッチを実行し直しても同じ記事を再度 Slack に投稿しないようにします。また全てのクエリ操作はトランザクション内で行うようにし、返ってきた err が nil かどうかを見てロールバック、コミットを判断するようにします。 実行結果 無事バッチが動作することを確認できました。 バッチの実行時間は大体1秒でした。 つまづいたところ Dockerfile の設計 バッチプログラムでは  Go Modules  という外部パッケージ管理システムを用いています( Go Modules を使用する場合、 Go のバージョンは1.11以上である必要があります)が、 Docker イメージをビルドする際に毎回 Go Modules のダウンロードが走るため、バッチの実行時間が長くなってしまうという問題がありました。また M1 mac でビルドした Go イメージを ECR に Push すると、自動的に Go イメージが linux/arm 版になってしまうようでした(記事執筆時点)。こちらについては、  Docker Buildx  で linux/amd64 でビルドし ECR に Push することで対応できましたが、実行時間問題は解決していません。 そこで  Multistage Build  を採用することにしました。開発環境用のイメージの中でビルドを行い、生成されたシングルバイナリを本番環境用の Alpine イメージに移すことで、大幅なメモリ削減ができるだけでなく実行時間も短縮することが可能です。 FROM amd64/golang:1.15-alpine AS builder WORKDIR /go/src/tsuchiya COPY . /go/src/tsuchiya ENV GO111MODULE=on RUN CGO_ENABLED=0 GOOS=linux go build -o api main.go FROM alpine:latest WORKDIR /root/ COPY --from=builder /go/src/tsuchiya/api . CMD ["./api"] コンソールから ECR のプライベートリポジトリを覗いてみます。 イメージサイズを確認すると100 MB 以上削減されていることが分かりました。 おわりに スクレイピングした mediba+ の最新記事を Slack に投稿するバッチを作りました。静的型付け言語に苦手意識を持っていた私ですが、 Go は構文もシンプルなため、とても楽しく実装まで取り組むことができました。 なおご存知だとは思いますが、スクレイピングは相手先のサーバにアクセスするため短時間で大量のアクセスを行うのは NG です。迷惑がかからないよう十分配慮をしましょう。 最後に、 mediba では一緒にモノづくりができるエンジニアを募集しています。 少しでもご興味がありましたら こちら からどうぞ。

こんにちは。テクノロジーセンター6GでManagerをしている下地( @primunu )です。 メンバーとの雑談でたまに話題になるエンジニアのキャリアパス。 どのキャリアを選択するかはもちろん各々が決定しますが、昨今のソフトウェアエンジニアのキャリアパスは多様かつ、組織によって若干役割が異なる事があるので、目指す方向がわからず迷子になる事があると相談を受けました。 そこで一度立ち戻り、medibaではどんなキャリアパスがあるのか？また、どのような役割なのか？を整理を含め図解してみました。 キャリアパスの概要 役割を図解した所、23のキャリアがありました。 その中でもイメージが付きにくい、または他社と若干領域に乖離があるキャリアを重点的に説明していきます。 ※ マネージャー/PjMはこちらを参照下さい SRE 主な業務はAWS全体管理や、インフラ管理や構築、SLO/SLA/SLIの定義、セキュリティ、バジェット管理、トイルの洗い出しやトラッキング等が主な業務になります。なお、IaCやアーキテクチャ設計はリードバックエンドエンジニアやテックリードが実施する事が多いです。 インフラ組織から名前がSREに変わった背景があるので、SREという職能のコミットメント領域がまだ不明確という課題があり、組織の納得度を高める為にも定義したいと考えています。 ※ SRE奮闘記 に今後記載していきます。 リードエンジニア(セキュリティエンジニア含) 豊富な知識・経験から最適なアーキテクチャを選定し、技術選定を行いながらPoCを回し、技術で牽引してくキャリアになります。後述するテックリードと似た振る舞いしますが 大きな違いは影響範囲 になります。リードエンジニアの影響範囲はチームになりますが、テックリードは組織全般に及びます。 ここまで記述するとエンジニアリングしかしないと思われがちですが、ステークホルダーとの会話も行いも各メンバーへの教示も行うので、 ただコードを書くキャリア ではありません。 テックリード予備軍のキャリアなのでテックリードと連携をしプロダクトの技術的意思決定を行います。 システムディレクター medibaでは完全自社開発の会社ではなく、プロダクトによっては受託開発もあります。 現時点だと受託開発プロダクトのみのキャリア になり、そこでステークホルダーと技術ナレッジを活かしながらディレクションを行います。ディレクターという事もあり提案や、要件定義はもちろんの事、ファシリテータも行います。ステークホルダーや協力会社・外部会社と技術的な会話ができ、意思決定ができ必要があるので〇〇エンジニアの上級職になると感じています。 プロジェクトリーダー プロダクトによってPjMと責務が被る事がありますが、開発チームオンリーのチームや、8人未満の小規模チームのリーダーがmedibaで言うプロジェクトリーダーになります。 サーバントリーダーではなく前に出て引っ張っていくリーダー となります。 ステークホルダーとの会話はもちろんの事、スケジュール管理や、チームビルディングも行います。チームによってはスクラムマスターがプロジェクトリーダーを兼任する事が多いと感じています。ハードスキルとソフトスキルの両面を求められるので、マネージャーを目指す方が通るキャリアになります。プレマネバランスですが感覚値としてプレーヤー7、マネージャー3です(個人の感想です)。 そんなプロジェクトリーダーですが、 マネージャーとの大きな違いはピープルマネージャーと組織へのコミットメントの有無 になります。チームへのコミットメントは当然ですが、組織への干渉は低く、ピープルマネージメントは直属マネージャーの責務になります。 品質管理リーダー 品質管理はスポットで入る事が多く、協力会社と連携する事が多いです。そこで試験項目作成やスケジュール確認、SLA的に問題ないか実施、確認すると平行し、協力会社との連携や契約、統率を行うのが品質管理リーダーになります。品質管理の知識以外にも他社を巻込み組織しなければらないので、 メンバーをまとめ組織するスキル が求められます。E2Eテストのシナリオを記述したり品質管理におけるPDCAを回す所までは介入できておらず今後の課題となっています。 なお、品質管理とテスターの大きな違いは要件から試験項目作成ができるの有無です。 テックリード テックリードとは完結に言うと、リードエンジニアの上位職になり、リードエンジニアの箇所でも触れましたが、影響範囲が組織全般となります。厳密にこれを実施する等はなく、PjMを実施したり、PoCを回したりと技術的な意思決定を主導し推進します。コードの品質管理はもちろんの事、チーム全体の生産性、アーキテクチャ・設計も行うので広さと深さの両面を求められます。 なお、 medibaのテックリードはマネージャーではなく 、成長支援等は行やメンタリングは適宜行うもののコミット領域ではなく、あくまでも技術でリードしプロダクトの成功に寄与するキャリアになります。 Unitマネージャー、マネージャー、シニアマネージャー。何が違うの？ 細かい違いはあるものの、 大きな違いは管轄するチームの種別とコミット領域、比率 になります。 Unitマネージャーはプロダクト横断チーム、マネージャーとシニアマネージャーはプロダクトに強く関わるマネージャーになります。マネージャーとシニアマネージャーの役割は大きく変わりませんが、 シニアマネージャーの方が組織へのコミットメント が求めれます。 PO(プロダクトオーナー)や、PM(プロダクトマネージャー)のキャリアパスは？ Biz職からのPO/PMのキャリアパスはあるものの、POの業務範囲にエンジニアに馴染みが薄いPL管理が含まれているのが起因しているせいか、 エンジニアとしてのPO/PMのキャリアを描けていません 。 【翻訳】プロダクトマネジメントトライアングル にあるように、プロダクトは開発者、ユーザー、ビジネスの 3 つで構成されており、エンジニア視点は必要不可欠だと認識しています。 エンジニアリング、データ分析、エンジニアとのコミュニケーションと言った領域をカバーできるのはエンジニア出身のPO/PMの強みだと感じており、 プロダクトの意思決定を素早く判断できる と感じています。 先述の通りまだエンジニアのキャリアとして描けていないのもの、現場ではマネージャーや、テックリードが中心となりエンジニア領域をカバーしています。マルチタスクになってしまうので、キャリアパスにない事を組織課題と捉え、PO/PMのコミット領域を明確にし、キャリアパスとして描きたいと考えています。 まとめ 如何だったでしょうか。複雑に見えるキャリアパスですが、目指す方向の咀嚼ができれば、日々の行動が変わり、目標、引いては組織へのコミットメントが高くなると考えています。 これを気にキャリアプランを再考してみるのは如何でしょうか。少しでも手助けになれば幸いです

はじめに こんにちは、SRE Unitの北浦です。 私達がSRE活動を推進していく中で、行き詰まった点や逆にうまくいった方法などの知見を共有していこうと思い、筆を取りました。 “アプリケーション"のシステムとは違い、"人"のシステムを改善・介入していくためには、 関係各者へたくさんの説明や知見を共有していかないといけないのは当然のこと。 重要なポイントを割愛してしまうと、要らぬ誤解を生んでしまい、物事がうまく推進できないという自体に陥ります。 今回は、我々の体験談としてエラーバジェットというものがネガティブに誤解されてしまった過程と、その軌道修正に必要だった説明をまとめてみました。 エラーバジェットって何よ まずはエラーバジェットそのものについて、足並みを揃えていきましょう。 Googleで検索をかけると以下のような説明が出てきます。 エラーバジェット（Error Budgets）とはエラーに対する予算であり、SLOに基づき算出される損失可能な信頼性である。 サービスの計測された稼働時間がSLOを超えている、換言すればエラーバジェットがまだ残っている状態であれば、チームは新しいリリースをプッシュ（デプロイ）できる。 例えば、正常な稼働時間という切り口のSLIを設定し、そのSLOを99.9%と定義したとしましょう。 そうした場合、残りの0.1%がエラーバジェットになります。 100% - SLO（99.9%） = 0.1% 1ヶ月を30日間とした場合、残りの0.1%は43.2分です。 1ヶ月(43,200分）/1000 = 43.2分 この場合、仮にダウンタイムが1ヶ月のうちに43.2分未満であれば新規開発を続行し、 43.2分を超過する自体に陥っていた場合は、新規開発を中断し、この値が回復するまでの間はダウンタイムの時間を減らす活動を行う。 このように使われるのがエラーバジェットです。 生まれる誤解 エラーバジェット自体はDevとOpsの課題を絶妙なバランスで解決した良い手法なのですが、 これを良いものと認識するためには、いくつかの前提知識が必要であり、 加えて、何を解決しているものなのか、課題を捉える必要があります。 前提知識と課題、ここの相互理解がないまま導入を提案しても、 「うちは予算取って動いているプロダクトなので、なかなか柔軟に舵切ることは難しい」 「納期があるから、新規開発中断は困る」 「うちは組織形態として大きいから・・・SREってスタートアップやテックリードのような企業で導入するやつでしょ？」 …などの反応が返ってきそうです。 上記の反応は、見方によれば至極真っ当で、 そもそも開発プロダクトとして、開発への投資を信頼性に向けるか新規開発に向けるかといった意思決定は、プロダクトの命運を左右する重要な要素でしょう。 そんな重要な要素の一つをエラーバジェットなるものに背を預けて良いものでしょうか。 こう考えると、なかなか心理的にもハードルが高そうです。 ということで、エラーバジェットを理解するための知見、そして何が解決されて嬉しいのかというポイントをふかぼっていきたいと思います。 暗黙のエラーバジェット ところで、システム開発に関わりのある読者の方には質問なのですが、 「あなたが担当しているシステムのエラーバジェットは最適化されていますか？」 ・ ・ ・ 「いや、エラーバジェット導入してねーよ」 と言われてしまいそうなのですが、 実はそうとも言い切れないケースが多いのではないかと思っています。 例えば、 システムに致命的な欠陥が見つかり、予定していた開発を中断、 回復作業に注力した。 という状況はイメージできないでしょうか。 この場合は、エラーバジェットを大幅に超過しているということが、 関係者全員の共通認識となった時に起こる状態です。 ・・・ふむ。こう考えると、どうやらエラーバジェットというものは、 暗黙的には存在しているもののようです。 暗黙のエラーバジェットが引き起こすもの エラーバジェットが暗黙的であるものの場合、言い換えれば、 ”人”それぞれの感覚値に依存していることになります。 Aさんは0.1%の感覚かもしれませんし、Bさんは0.01%の感覚かもしれません。 プロダクトとしての意思決定を行う際、この感覚の乖離を埋める手段はコミュニケーションになることと思いますが、 この感覚値は各役割にも影響されることが多く、 そして、正解が存在しないところが実に厄介なところで手をこまねいているプロダクトも多くありそうです。 「あなたが担当しているシステムのエラーバジェットは最適化されていますか？そしてその感覚は関係者各位で共通しているものですか？」 もしかしたら、あなたのチームはこの暗黙のエラーバジェットのコミュニケーションに多大な工数と労力を強いられてるかもしれません。 この質問にYesと答えられず、且つ、コミュニケーションや実態に課題を感じているのであれば、 プロダクトとして指針を決めることに一度注力し、エラーバジェットの運用をしてみるのも良い選択肢かもしれませんね。 機能性と信頼性、ユーザーはどっちが欲しい？ 一つ、エラーバジェットの嬉しみポイントが見えたところですが、 以下に、極端ですがToDo管理アプリケーションの例を二つあげてみます。 ケースA ユーザーからも評価の高い機能性のあるアプリケーションだが、 3日に1日くらいのペースで利用ができなくなる。 ケースB 24時間365日正常に稼働するが、ToDoの登録と削除の機能しかない 上記、どちらかのアプリケーションを使いたいと思いますか？ ・・・どちらも使いたくないと思ったことでしょう。 実際に市場に出してもユーザーから選んでもらえることは無さそうです。 つまり、ビジネスとしてプロダクトが成功するには、 新機能の開発と信頼性の向上、両方のタスクをバランスよくおこなっていかなければならなそうです。 しかし、ここで二つ立ち塞がる障壁があります。 新機能開発を行うとバグが発生する可能性があるため、信頼性が低下する。 SLOに9を加えるには、その前の9を実装するのにかかったコストの10倍かかる。99%から99.9％にするためには99%にするためにかかったコストの10倍かかる。99.99%にするためには、それのさらに10倍のコストがかかると言われています。 どうやら新機能開発と信頼性の向上は、お互いにトレードオフの関係性にあるようです。 <参考> https://cloud.google.com/architecture/defining-SLOs?hl=ja#why_slos 高すぎるSLOが引き起こすもの 例えば、暗黙的にSLO99.99999…%のように高い水準のSLOを設定してしまい、 エラーバジェットがとても少ない状況下にあったとしましょう。 その場合、信頼性の担保に対して必要なコストがかなり高い水準で必要とされ、 結果的に新規開発への着手が困難という自体に陥るわけです。 ただし、そんな状況下だったとしても、プロダクトとして新機能開発がゼロということは考えづらいですから、 信頼性が担保できていない状態なのに新機能も開発しなくちゃいけないという大変な状況になるかもしれません。 思い当たる節があるようであれば、まずは今のシステムがどれほどの水準で信頼性があるのか、 SLIを定義し、計測するところから始めると良いでしょう。 SLOをあげてしまうと新規開発に投資できるだけのコストが失われてしまうという前提のもと、 実現可能性が高い値を定義できると、少しづつ新規開発にも投資できるようになるかもしれませんし、それでも今の現状で信頼性が担保できていないと考えるのであれば、定量的な指標によって、現在行っている信頼性向上の施策が効果があるのかないのか。判断することができるでしょう。 まとめ ネガティブな解釈をされがちなエラーバジェットに関して、 今回は課題の背景や解決アプローチを説明させていただきましたが、誤解は解けましたでしょうか。 エラーバジェットを定義するのは良いかも。とか、 改めて自分の担当しているプロダクトには、緊急的には必要なさそう。など、諸々考えてくれたら嬉しいです。 さいごに medibaでは、現在、各プロダクトの価値を向上すべく、 日々SRE活動を積極的に行っております。 次回は、エラーバジェットをより有効なものにするために、信頼性を上がると何が嬉しいのか、下がってしまうとどんなことが起こりうるのかという点を深堀し、より効果の高いSLI定義についてのナレッジを共有しようかと考えてます。お楽しみに・・・！