AWS WAFの概念を分かりやすく説明してみた

技術 AWS WAF

背景

私は、半年ほど前に仕事でAWS WAFを運用し始めました。

最初の頃は、AWS WAFの概念や挙動の理解に苦しめられました。少しづつ理解を深めた結果、今なら他人に説明できるレベルには達した気がします。 そこで、備忘録もかねてこの記事を書こうと思った次第です。

これから下に書かれている内容は、ラフに書かれているため、公式ドキュメントよりは分かりやすいかもしれませんが正確性は劣ります。

正確性を求める場合は、AWS WAF | AWSドキュメンテーションを参照ください。

以下、AWS WAFを、WAFと記述します。

WAFの概略

  • WAFでは、webACLというリソースに対してルール（コントロールとも呼ばれる）のセットを設定します。ルールには評価する順番を意味する優先度が設定されます。
  • それぞれのルールは、独自のロジックに基づいてリクエストを評価します。
  • 評価の結果は、一致が検出されるか、一致が検出されないかのいずれかです。例えば、bot検知のルールでは、リクエストを評価し、botが検出されたか、botが検出されなかったかのいずれかの評価となります。
  • 一致が検出されたら、そのルールに対して事前に設定されたアクションが行われます。検出されない場合は何もせずに次のルールの評価に移ります。

アクションについて

WAFのアクションは、シンプルな仕様に見えて、認識がずれることが多いです。 そのため、私の認識がずれていたところを中心に、詳しく解説してみたいと思います。

まず、アクションにはALLOW BLOCK COUNT CAPTCHA Challengeの5つがあります。

文字通り、ALLOWはルールへの一致が検出されたリクエストを許可し、BLOCKはルールへの一致が検出されたリクエストをブロックします。COUNT、CAPTCHA、Challengeについては以下で詳しく説明します。

COUNTについて

  • Count は非終了アクションです – Count アクションのあるルールがリクエストと一致すると、AWS WAF はリクエストをカウントし、その後にウェブ ACL ルールセットに従うルールの処理を続行します。

引用元: ルールアクション | AWS公式ドキュメント

COUNTについては上記のような説明がされているのですが、私はこれを読んで完全に理解した気持ちにはなれませんでした。

非終了アクションは後に説明するため、一旦脇に置かせて下さい。

そもそもカウントするとはなんなのでしょうか？

カウントする、とは？

他の記事では、ログを取ることのように説明されていますが、COUNT以外のアクションでもログを取ることはできるのでこの説明は正確ではありません。

ずばり、カウントするとは、後に評価されるルールで利用できるステータス(ラベルと呼ばれます)を保持しておくことです。

例えば、API server全体に対してAWSが提供するXSS検知のルールを設定したとします。 このルールによって、明らかに正常だと分かっているリクエスト(定期ジョブによって発行されるリクエストなど)が誤ってBLOCKされてしまうことがあります。AWSが提供するルールの判定ロジックは、セキュリティの観点から公開されておらず、判定ロジックをいじることもできません。

このときにCOUNTをアクションとして設定します。

以下のようにwebACLを設定します。

  • 優先度1: (AWSが提供) XSS検知のルール(アクションはCOUNT)
  • 優先度2: (自分で作成) XSS検知されたリクエストのうち、明らかに正常なリクエストのみ通すルール(アクションはBLOCK)

最初のルールでXSSが検知されても、すぐにブロックせずに、「XSSが検知された」というラベルを保持しておきます。

次のルールでは、XSSが検知されたラベルが保持されている場合のみ、明らかに正常なリクエストかどうかを判定するロジックを組みます。

このように、後続のルールで利用できるステータスを保持できる性質を利用して、複数ルールの評価結果を組み合わせて判定ロジックを組むことができます。 他の具体的なユースケースについては、ウェブリクエストの AWS WAF ラベルが詳しいです。

webACLの設定を効率的にテストするためのCOUNT

上に載っていないCOUNTアクションのユースケースとして、WAFのテスト運用での活用があります。

正常なリクエストがWAFによってBLOCKされてしまうと、ユーザに迷惑をかけてしまいます。そのため、事前にテスト環境でWAFを運用し、正常なリクエストがブロックされないことと、攻撃と思われるリクエストがブロックされることを確かめておきたいです。

このとき、以下のようにwebACLを設定したとします。

  • 優先度1: ルールA(アクションはBLOCK)
  • 優先度2: ルールB(アクションはBLOCK)
  • 優先度2: ルールC(アクションはBLOCK)

ルールAによってBLOCKされたリクエストは、ルールBとルールCによる評価が行われません。WAFのログをみた時に、正常なリクエストがルールAによってBLOCKされてしまったことは分かりますが、ルールBやルールCに関しては評価がされていないので未知数です。

そこで、以下のように設定してあげます。

  • 優先度1: ルールA(アクションはCOUNT)
  • 優先度2: ルールB(アクションはCOUNT)
  • 優先度2: ルールC(アクションはCOUNT)

この設定では全てのルールが評価され、一致したルールのラベルがリクエストのログに含まれます。そのため、一気に3つのルールをテストできるというわけです。

COUNTモードに関する説明は以上です。

非終了アクションと、終了アクション

ついでに、非終了アクションと、終了アクションについて説明します。今ならスッと理解できると思われるためです。

複数のルールがwebACLに設定されている場合には、優先度が高い順から評価されていきます。

一致したルールのアクションがACTIONだった場合、そのリクエストは問答無用で許可され、後続のルールは評価されません。 同じように、一致したルールのアクションがBLOCKだった場合、その時点でstatus code 403のレスポンスが返され、後続のルールは評価されません。

これが、ACTIONとBLOCKは終了アクションである、という意味です。

一方、一致したルールのアクションがCOUNTだった場合、ラベルを保持して、次のルールの評価に移ります。そのルールの評価時点では、リクエストを許可することもブロックすることもしないため、非終了アクションと呼ばれます。

CAPTCHAとChallengeについて

CAPTCHAとChallengeというアクションは似ているようで、異なります。

まず、どちらもクライアントがbotかどうかを判定するという目的を持っている点では同じです。

どちらも、リクエストを送ってきたクライアントに対してチャレンジを要求します。クライアントがチャレンジに成功した場合のみリクエストを許可します。

WAFはクライアントがチャレンジに成功するとaws-waf-token というクッキーを設定します。このクッキーはトークンと呼ばれています。一回チャレンジに成功すると、次回からのリクエストでは、またチャレンジを要求するのではなく、トークンを検証するだけですみます。こうすることで、毎回、人間の手を煩わせたりするのを防げるわけですね。

参照: AWS WAF ウェブリクエストトークン

次にCAPTCHAとChallengeの異なる点について説明します。

ずばり、CAPTHCAがクライアントが人間であるかどうかを確かめるチャレンジを要求するのに対して、Challengeはクライアントがブラウザであるかどうかを確かめるチャレンジを要求します。

人間であるかどうかを確かめるチャレンジは、パズルと呼ばれ、人間に操作を要求します。よくある例としては、「9つのパネルのうち車が写っているものを全て選択してください」みたいなものです。

AWS WAFで要求されるパズルについては、CAPTCHA パズルとは？が詳しいです。

CAPTCHAはクライアントが人間であるかを検証するために、パズルという形式のチャレンジを要求します。

一方、ブラウザであるかどうかを確かめるチャレンジは、 人間の操作なしに実施されます。公式ドキュメントでは、サイレントに実施されると書かれてあります。 Challengeアクションでは、リクエストを受けたWAFが、JavaScriptのチャレンジを検証するスクリプトを含んだHTMLをクライアントに返します。クライアントがブラウザの場合は、そのスクリプトがブラウザで実行され、クライアントがブラウザかどうかが検証されます。

(ChallengeアクションでWAFから返されるHTML)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Human Verification</title>
    <style>
        body {
            font-family: "Arial";
        }
    </style>
    <script type="text/javascript">
    window.awsWafCookieDomainList = [];
    </script>
    <script src="https://xxxx.ap-northeast-1.token.awswaf.com/xxxx/xxxx/xxxx/xxxx.js"></script>
</head>
<body>
    <div id="challenge-container"></div>
    <script type="text/javascript">
        AwsWafIntegration.checkForceRefresh().then((forceRefresh) => {
            if (forceRefresh) {
                AwsWafIntegration.forceRefreshToken().then(() => {
                    window.location.reload(true);
                });
            } else {
                AwsWafIntegration.getToken().then(() => {
                    window.location.reload(true);
                });
            }
        });
    </script>
    <noscript>
        <h1>JavaScript is disabled</h1>
        In order to continue, we need to verify that you're not a robot.
        This requires JavaScript. Enable JavaScript and then reload the page.
    </noscript>
</body>
</html>

引用元: AWS WAFのChallengeアクションの動作を見てみる

CAPTCHAとChallengeは、終了アクション？非終了アクション？

CAPTCHAとChallengeは、終了アクションであるケースと、非終了アクションであるケースが存在します。

  • リクエストに有効なトークンが含まれる場合、後続のルールの評価を続けるため、非終了アクションです。
  • リクエストに有効なトークンが含まれない場合、すぐにリクエストをブロックするため、終了アクションです。

リクエストがブロックされると、Challengeの場合は、status code 202(Request Accepted)が返されます。CAPTCHAの場合は、status code 405(Method Not Allowed)が返されます。どちらも、チャレンジを実行するJavaScriptのスクリプトがレスポンスのHTMLに含まれます。

参照: CAPTCHA および Challenge アクション動作

ルールグループのアクションについて

冒頭で、webACLというリソースに対してルール（コントロールとも呼ばれる）のセットを設定しますと説明しましたが、これは少し単純化した記述でした。 実際には、webACLには、ルールに加えて、ルールグループを設定できます。ルールグループとは、複数のルールを意味のある単位にまとめられる仕組みです。

たとえば、Linuxに対するよくある攻撃を検知する複数のルールを1つのルールグループにまとめておくと、Linuxサーバを使っている時に1発で設定できるため便利です。

このルールグループに関して、似ているが全く挙動が異なる2パターンの設定オプションがあるため紹介します。

1. ルールグループに含まれるルールのオーバーライド

ルールグループは、webACLとは別の場所で管理され、複数のwebACLで再利用できるようになっています。プログラミング言語の機構に置き換えると、クラスとインスタンスみたいなイメージです。

クラスであるルールグループをwebACLに設定する際には、個々のルールアクションをオーバーライドしたインスタンスを作れます。

例えば、Linuxに対するよくある攻撃を検知するためのルールグループでは、全てのルールのアクションがBLOCKと設定されているとします。webACLに適用する際に、何らかの都合で一部のルールだけCOUNTにしたいということであれば、COUNTにオーバーライドすることができます。

COUNT以外のアクションにもオーバーライドできます。

2. ルールグループの評価結果をCOUNTにオーバーライド

これとは全く別の仕組みで、ルールグループの評価結果をCOUNTにオーバーライドすることができます。

ルールグループを活用して以下のようにwebACLを設定したとします。

  • 優先度1: ルールA (アクションはBLOCK)
  • 優先度2: ルールグループB
    • ルールB1(アクションはBLOCK)
    • ルールB2(アクションはCOUNT)
    • ルールB3(アクションはBLOCK)
  • 優先度3: ルールC(アクションはCOUNT)

これは、挙動としては、以下と同じです。

  • 優先度1: ルールA (アクションはBLOCK)
  • 優先度2: ルールB1(アクションはBLOCK)
  • 優先度3: ルールB2(アクションはCOUNT)
  • 優先度4: ルールB3(アクションはBLOCK)
  • 優先度5: ルールC(アクションはCOUNT)

ここで、ルールグループBの評価結果をCOUNTにオーバーライドします。

  • 優先度1: ルールA (アクションはBLOCK)
  • 優先度2: ルールグループB(アクションをCOUNTにオーバーライド)
    • ルールB1(アクションはBLOCK)
    • ルールB2(アクションはCOUNT)
    • ルールB3(アクションはBLOCK)
  • 優先度3: ルールC(アクションはCOUNT)

これは以下の設定と同じ挙動です。

  • 優先度1: ルールA (アクションはBLOCK)
  • 優先度2: ルールB1(アクションはCOUNT)
  • 優先度3: ルールB2(アクションはCOUNT)
  • 優先度4: ルールB3(アクションはCOUNT)
  • 優先度5: ルールC(アクションはCOUNT)

公式ドキュメントでは、次のように説明されています。

ルールグループ内のルールの設定または評価方法を変更せずに、ルールグループ評価の結果によって発生するアクションをオーバーライドできます

引用元: ウェブ ACL でのルールグループの動作の管理 | AWS公式ドキュメント

さいごに

私自身、公式ドキュメントと巷に溢れるWeb記事では、AWS WAFをちゃんと理解するには至れませんでした。 そのため、実際に動かしてみたりAWS Supportに質問することで理解していきました。

この記事では、私がAWS WAFを設定する時に理解しずらかった箇所を中心に、公式ドキュメントから一歩踏み込んだ説明をしました。

この記事が好評なら、WAFを運用する中で困ったことやハマりポイントについても記事を書こうと思うので、感想やフィードバックをいただけると嬉しいです。

具体的な指摘でも、「参考になった」「読みにくい」みたいな大まかなフィードバックでも構いません。

ポモドーロテクニックを実践している

私は集中力が切れると多様な行動をとる。コーヒーをゆっくり淹れてみたり、散歩に出たり、スマホをだらだら見てしまったりする。そこから復帰して、もう一度集中的な意識に戻れることもあれば、そうでないこともある。全然集中できない日もあれば、一日中集中できる日もある。

集中力とはそういう気まぐれなものであると捉えることもできるが、自分の能力を超えた高い目標を持っているときはそう言ってもいられない。

私は自分の集中力が安定して続かないことに対してどう対処すれば良いのかわからないでいた。

ポモドーロテクニックを知ったきっかけ

「SOFT SKILLS ソフトウェア開発者の人生マニュアル」という本で、ポモドーロテクニックが紹介されていた。 ポモドーロテクニックは、25分の作業と5分休息のセットを1ポモドーロとし、それを繰り返していくという時間管理法である。

The Pomodoro® Techniquefrancescocirillo.com

ポモドーロテクニックを使った作業は次の流れになる。

  1. やるべきタスクを洗い出す
  2. 各タスクが何ポモドーロかかるのかを見積る
  3. 一定期間にこなせるタスクをピックアップし、タイムライン上の実行計画に落とし込む
  4. 25分の作業と5分の休息を繰り返しながら、計画にそって実行していく(見積をオーバーしたり早く終わった時の対応は人によって異なる)
  5. 一定期間が終わったら振り返りをする

前述の本では、このシンプルな時間管理がいかに強力かという説明がなされている。その説明の中にはポモドーロテクニックが集中力の管理にも関係していると書かかれており、自分も興味を持った。

実践した感想

1週間ほどポモドーロテクニックを実際に試してみたので、その感想を書こうと思う。

結論、かなり使えるテクニックだと感じた。

私自身、なぜポモドーロテクニックが強力なのかを完全に整理できていないが、ぱっと考えた限りで以下の効果があるように感じる。

  • 1ポモドーロは短い時間なので、集中力を維持しながらタスクをやり遂げられる。一言でいえば、ダレない。
  • 休息を正当化できるのでメンタルに良い
  • タスクに必要な時間を正確に見積もれるようになる。よって正確な計画を立てられるようになる。
  • 思考を集中させるべきときと発散させるべきとき(計画を立てる時)が分けられているため、今やるべきことがはっきりする。

個人的には、「SOFT SKILLS ソフトウェア開発者の人生マニュアル」に書かれていることが一番しっくりきた。

問題は、一日にどれだけの仕事を終わらせたかが正確に評価できず、どれだけの仕事を達成すべきかについての明確な目標を持てないことによって生まれている。

この問題に対する解決策としてポモドーロテクニックが機能するのである。

不確実な状況で計画を立てるということ

ポモドーロテクニックの根っこにある考え方はアジャイル開発と同じである。

アジャイル開発ではストーリーポイントでタスクを見積もるように、ポモドーロテクニックではポモドーロで見積もる。それを元に不確実な中でもある程度正確な中長期の計画を立てる。一定期間のPDCAサイクルを繰り返していくうちに、計画が正確なものになっていき、目標を安定して達成できるようになる。

異なる点としては、ポモドーロテクニックでは不確実性が自分の体調や心理状態からくるのに対して、アジャイル開発では不確実性が外部環境からくるという点だ。外部環境には、事業の進捗や事業環境に加えて、自分以外のチームメンバーも含まれる。

アジャイル開発では、チーム内のメンバーによって、そのタスクを終わらせられる時間が異なる。だから、相対的な単位として、ストーリーポイントを持ち出さなければならない。それを絶対的なデッドラインに合わせるために、スコープを狭めなければならないこともある。

このことから、個人的にはポモドーロテクニックよりアジャイル開発の方が運用が難しいと思う。

ポモドーロテクニックは、個人レベルで導入できるイテレーティブな計画法だと言える。そのため、アジャイル開発におけるストーリーやバッファについての考え方も、ポモドーロに当てはめて応用するできると思う。

まとめ

私はこれからもポモドーロテクニックを実践していく予定だ。アジャイル開発の知識や経験を活かして、自分なりのアレンジも加えていけたらいいなと考えている。

あなたがもしポモドーロテクニックに少しでも興味を持ったなら、まずは1日実践してみるとどうだろうか。

何かを始めるのに遅すぎることはない

朝からジャズギターを聴いてテンションが上がっている。

私は高校時代にOne Minuteというバンドを組んでいて、そこではギターを弾いていた。当時は、RADWINPSやBUMP OF CHICKENのコピーをやっていた。その時の話は別のポストを書ければと思う。大学でもバンドを組みたかったものの、自分に合うサークルがなくて、頓挫。結局、趣味程度にアコースティックギターを弾いていた程度。

社会人になり3年ほど経ったが、その間ギターをほとんど弾いていない。仕事や仕事のための学びに必死になっており(それも楽しんでいた)、相対的にギターへの興味が薄れていた。一方で、ギターから離れれば離れるほど自分のスキルが落ちていくのは悲しいと感じている。

最近、体力がついてきたり、仕事に余裕が出てきた。仕事のための学びへの考え方も変わった。そういうわけで、またギターに挑戦したいという欲が湧いている。

今回は、ジャズギターをやりたい。というのも、最近YouTubeでTom MischやBruno Major、Gyoshiを聴いていて、ジャズギターの素晴らしさに気付かされたからだ。

ジャズギターは、一人で学べて、一人で楽しめて、長い年月をかけて積み重ねていくものであり、上達すればセッションを通して人と繋がれる。その点が自分の性に合っている。

この年になって金銭的な余裕も出てきたので、ちゃんとプロから学べるし、良いギターを用意できる。

そんなことをぐるぐる考えていると、今が始めるべきタイミングだなと感じる。

となると、まずは最高にアガるギターの調達だ。いちおう大学時代に購入したEpiphoneのHummingbirdが実家にあるが、アコースティックなのでジャズには少し向かない。

1ヶ月ほど前に楽器店を回って、テレキャスターを何本か試奏してみた。良いなと思えるギターはあったが、最高だと思える出会いはなかった。そうこうしているうちに1ヶ月経ってしまった。時々YouTubeでジャズギターを聴いては、ストラトキャスターもいいなとか考えてしまい(Tom Mischの奏でるストラトは本当に良い)、迷い始めている。このままだとただ時間だけがすぎてしまい、この新鮮な気持ちも薄れてしまう。

ということで、先ほど真剣にギターを探そうと決意した。ここから要件整理をして、それを元に周る楽器店を決める。

自分が愛せるギターを手に入れたらこのブログでも紹介したいなと思っている。

何かを始めるのに遅すぎることはない。

 

「マスタリングTCP/IP 情報セキュリティ編」を読んで

開発者にとって、プログラミング言語に関する知識や、ソフトウェア設計に関する知識、フレームワークやライブラリに関する知識は必要だ。 一方では、おろそかになりがちだが、大まかな歴史や基礎技術の概要くらいは知っておく必要がある分野が、いくつか存在する。情報セキュリティはその一つだ。

私はWebセキュリティやネットワークセキュリティといった特定のトピックについては、本やWeb記事で学んでいた。 具体的なセキュリティ攻撃やその対策を学んでいるのみであり、情報セキュリティの包括的な知識はなかった。

今回は、会社でセキュリティ関連のタスクにアサインされたので、入門として「マスタリングTCP/IP 情報セキュリティ編」を読むことにした。

情報セキュリティとは何なのか？

第一章の「情報セキュリティ概論」では、そもそも情報セキュリティとは何なのかを説明してる。情報セキュリティの定義や、歴史の概観、情報セキュリティの要素分解などによって、その輪郭を炙り出している。

私自身、情報セキュリティとは何なのかをよくよく考えてみると、意外とはっきりしないことが多かった。この第一章を読むことで、情報セキュリティという概念そのものに対する理解を深めることができたのは、大きな学びだった。

私はこの本を読む前は、情報セキュリティは機密性を守ることだと理解していた。 この本では、情報セキュリティを構成する3つの要素として、機密性・完全性・可用性が挙げられており、情報セキュリティを以前より幅広い概念として捉えるきっかけとなった。 確かに、ウィルスによって情報が盗み出されるだけでなく、正しい情報が破壊されたり、ランサムウェアによって情報にアクセスできなくなったりすることも情報セキュリティの範疇と捉えなければ、正しいアクションをとれない。

また、この本の注釈に書かれているように、真正性・責任追跡性・否認防止性・信頼性の維持、を情報セキュリティの要素として考え方もある。 情報セキュリティを構成するそれらの性質は、互いに関連しあっており相互排除的な概念ではないことから、情報セキュリティはなお捉えづらい概念だと感じた。

捉えづらい概念だからこそ、具体的な攻撃や、それに対する対策を学ぶことで輪郭を掴んでいくしかないのだと思う。

PKIについて

この本では第二章以降、具体的な要素技術や、セキュリティ攻撃、それを対策する仕組みについて紹介されている。 特にPKIについては、体系的に学ぶのが初めてだったので勉強になった。

PKIには、すでに信頼しているものを信頼することで輪を広げていくWeb of Trustモデルと、信頼できる対象を中心に据えた認証局モデルがあることを知れたのはよかった。 どちらも同じPKIであるが、その2つのモデルを区別できていないと、具体的なPKIの仕組みを理解する上での障害になってしまう。

PKIについては、OSCPステープリング・公開鍵ピニングといった一歩踏み込んだセキュリティ対策の仕組みについても知ることができた。

PFSについて

この本には、PFS (Post Forward Secrecy)という概念が何回か出てくる。これは、暗号鍵が漏れたときに、過去にその鍵によって暗号化された全てのデータが解読できてしまうことを防げる性質のことである。 もちろん暗号鍵が漏れないように対策する必要はあるが、この性質を備えていれば、もし暗号鍵が漏れたとしても一部のデータしか解読できず被害を局所化することができる。 例えば、TLSにおいて選択できる認証方式に、DH鍵共有アルゴリズムのパラメータを毎回生成し使い捨てることでPFSを備えることができるものが存在する(TLS_DHE_DSS_WITH_AES_128_CBC_SHA)。

ここまで考えられているのはすごいなーと純粋に思ってしまった。

まとめ

この本のように、特定の分野におけるトピックを網羅的に扱い重要な点を抑えていけるタイプの本は、入門にはとても良い。 一方では、断片的な知識が多く、一回読んだだけではその深さや繋がりを認識しずらいため、継続的に読み返すことで味わっていかないといけないなーと感じる。

業務の中では、以前なら自分の範囲外と捉えて軽く流してしまうトピックでも、もう少し深掘りしてみるようなムーブが大事だと思う。 例えば、パスワードを暗号化して保存しないといけないというときに、どの暗号アルゴリズムを使うべきかという問いをサクッと調べて、一般的に正しそうな情報を信じて選択するだけでなく、それがなぜ正しいとされているのかを少し深掘りしてみる。PFSを備えられる手段がないか調べてみるみたいなことだ。

あとは、この本で参照されていた「プロフェッショナルSSL/TLS」も読んでみたいなと思った。すでに読みたい本が山積みなので、まずは目の前にある本からですが...笑

コミュニケーション能力、という便利な言葉

去年、私は会社でエンジニア採用を担当しておりました。 採用活動の中で、ジョブディスクリプションを書いたり、スカウトを送ったり、面接をする中で、非常に多くの気づきがありました。

ちょうど今日、久しぶりに採用面接にサブで出席する機会がありました。その中で去年の気づきを思い出したので、書き残していこうと思います。

就活生を悩ませる問い

採用においてコミュニケーション能力を大事にする会社は多いと思います。 様々な人事担当者に対するアンケートの結果を見ても、コミュニケーション能力という項目は上位にランクインしていることが多いです。

私が、企業がコミュニケーション能力を大事にしていることを知ったのは、大学時代、就活のことをおぼろげに意識し始めたタイミングでした。

ただ、その時は、文字面が抽象的すぎて、本質的な意味が掴めませんでした。 新卒採用では、グループディスカッションというものがあり、そこでコミュニケーション能力を見ているのだろうということは何となくわかりました。

もっとも安直な発想では、"発言が論理的でありながら、他人の言葉を理解できて、グループディスカッションで会話をオーケストレートできる"といった能力をイメージするかもしれません。

実際に、グループディスカッションの場や、採用面接の場では、会話をリードしたがる人がよくいます。

でも、よくよく考えると、みんなが会話をリードしたがっているチームは上手く行かなそうです。そのため、その安直な発想は、少し真実とは異なるように思います。

「企業が候補者に求めているコミュニケーション能力とは何か？」という問いは、就活生が一度は向き合う問いだと思いますが、例に漏れず私もその一人でした。

私が採用担当者をする中で気づいたこと

私が、エンジニア採用の担当者になって最初に手をつけたのが、採用要件をまとめるという仕事でした。そこで、一番初めに思ったのが、「一緒に働きやすい人にきてほしいな」、ということでした。 もっと具体的にいうと、話のテンポが合うとストレスなく一緒に働けるだろうなとか、あまり難しい言葉を使われると困るなとか、言葉の端々に圧力を感じる人は嫌だなとか、そういうことです。

ただ、これらは、とても言葉にしずらいです。

感覚的だから言葉にしにくいという側面もありまずが、それを直接書いたり伝えるのは憚られるという側面の方が大きいと思います。面接の場でも、「話のテンポが合わないですね」とか言いずらいですよね...

私が採用担当をしている中で得た最も重要な気づきは、定量的っぽくてもっともらしい言葉が使われていても、その裏にはとても人間的な欲求があるのだということです。

私が感じていたのは、自分の安全に対する欲求です。 他にも、新入社員から刺激を得たいとか、自分のレベルを引き上げてくれそうといった成長欲求があります。 また、その人を採用して社内で活躍してもらうことで、自分自身が採用担当者として評価されたいといった、承認欲求もあると思います。

そういう、直接書いたり伝えたりするのが憚れる欲求が、"コミュニケーション能力"という文字面に押し込まれるのだろうと思います。

知は力なり

これに気づいた時、私は、なーんだ..そんなことか...とずっこけたあとに、私自身の振る舞いを改ねばと思うようになりました。

私が安心して働きたいと思っているのと同じように、同僚もおそらく同じことを考えています。 また、同僚は私が思っていないような欲求を持っている可能性も高いです。

だから、同僚が言葉に出しずらいことを理解しようと努めながら、必要があればそれを満たせるように振る舞おうと意識するようになりました。

本質的には、そういう姿勢のことをコミュニケーション能力と呼ぶのだと私は理解しています。

そういう意味のコミュニケーション能力は、外見上の振る舞いだけは達成されず、自分の脳にこびりついた思考プロセスや、自分が育ててきた個性や、他人の気持ちを察知する能力とか、簡単には変えられない要素を多く含んでいます。

そのため、コミュニケーション能力は長い時間をかけて向上させていくものです。また、どうしても変わらない部分はあるため、自分と相性が良い人や企業を探すのも大事だと思います。

最後に

本業とは違うロールにチャレンジすると、こういう新しい発見があってとても楽しいです。 今後も、好き嫌いせずに、様々なお仕事にチャレンジしたいものです。 今の会社はこういう機会に恵まれているので、大変ありがたいです。感謝。

DatadogでSendGridのEvent Webhookを環境別に監視する方法

前提

Webサービスやアプリのメール送信にSendGridを利用していて、かつ、複数環境（ex. 本番/ステージング/開発 ...）を運用しているケースを想定します。 SendGridはメールに関するイベントが発生すると、事前に登録しておいたURLにその内容をPOSTしてくれます。

参照: sendgrid.kke.co.jp

Datadogはこの仕組みを使って、SendGrid Integrationを提供しており、これによってSendGrid上で発生したイベントをDatadogで監視することができます。

参照: docs.datadoghq.com

このとき、Datadogに転送されるイベントがどの環境で発生したのかを確認できるようにしたい、というのが今回の内容です。 この記事で紹介する方法は、サブユーザを使わなくても設定可能です。

結論

1) Datadog > Integrations > SendGrid > CONFIGURE > Logs Collectionにて、API Keyを'Create New'します。

datadog-sendgrid-integration
datadog-sendgrid-integration

2) Copy URLします。

datadog-sendgrid-integration-post-url
datadog-sendgrid-integration-post-url

3) CopyしたURLに環境識別用のtagをクエリーパラメータとして追加します。

https://http-intake.logs.ap1.datadoghq.com/api/v2/logs?dd-api-key=ddxxxxxxxxxxxxxxxxxxxxxxxxxx&ddsource=sendgrid&ddtags=env:production

4) 3で得たURLをSendGrid > Settings > Mail Settings > Event Webhooks > Create New webhookにて設定します。

sendgrid-create-new-webhook
sendgrid-create-new-webhook

1~4の手順を各環境ごとに実施します。

解説

Datadogが発行するWebhook URLをそのまま使うと環境別の監視ができなくなってしまいます。 Datadogが発行するWebhook URLをよくよく見てみると、DatadogのSend logsエンドポイントとなっています。 公式ドキュメントにあるように、クエリパラメータにddtagsを設定できるので、これを活用すれば良いというわけですね！

さいごに

ddtagsを設定できるということは、今回の要件を満たすだけでなく、より詳細なイベントの分類もできそうですね。

石川県立図書館に行った感想

あの図書館は、地域にも、部外者にも、開かれている。僕のような観光客が、入館証やゲート通過なしに、ぬるっと内に入っていける。中では、小さい子供が走っていたり、中高生が机で勉強をしていたり、大人が写真をとっている。この図書館は、そういうふうに自由な空気が流れるように設計されたのだろうと思った。ここら辺りに住んでいる人をとても羨ましく思った。同時に、公共施設とは、本来こうあるべきではないかと思った。

僕の中にステレオタイプとして存在する公共施設と石川県立図書館は同じところと異なっているところがある。まず同じところは、どちらも公共施設であり、税金で運営されており、多様な人が利用するということ。違うところは、前者は入館証がありゲートがあり手続きがあるが、後者は自由に出入りできて手続きがないということ。

公共施設は、多様性と向き合いながらも、それらを包摂しなければならない。税金を使って運営できるのは、全員を包摂するという目的があるからだ。

前者は、外と内の境界にゲートを設けたり、ルールを作ったりして空間を守っている。それは手段として簡単だし、運用も楽であるが、全員を包摂できない。また、利用者としては、常に嫌疑をかけられ、緊張する。明示的なルールもあれば、小さい頃に親から教えられなければわからない暗黙のルールもある。

だから、建築やデザイン、都市工学、その土台となっている認知科学が、より良い解決策を提案しなければならない。石川県立図書館は、そういう現代の知を活用して、境界型の防御やルールの運用なくして、公共施設を成立させているんだなと思った。入館証やゲートはないけど多様な人がサービスを享受できていて、少なくとも僕は居心地が良いと感じた。