kippではプレイングマネージャーとして、プロダクトマネジメントチームをリードしています。kippにジョインする前はGoogle社でGoogle Ads（当時はAdWordsという名前でした）やGoogle Analyticsのエキスパートとして勤務しておりました。FinTech未経験で転職してきたこともあり、業界知識やソフトスキル含め学び続ける毎日を過ごしています。

輪読はじめました

今回のブログ記事では、kippで行っている輪読の取り組みについてご紹介します。kippでは社員の自主学習を推奨しており、スキルや知識を身につけるための学習も業務時間中に行うことが許可されています。業務に関係する書籍は基本的に経費として申請できますし、有料の講座も一部または全額補助された実績があります。輪読はこのような自学推奨の取り組みの一環として、CTO冨田の旗振りで開始されました。参加者全員で1冊の本を読み、回毎の担当者が学習内容を解説するという、大学のゼミや研究室では馴染みのある学習方法ですね。

記念すべき第1回目の輪読本は、戸田山和久著『論理学をつくる』です。フルリモートで業務しているkippでは、メンバー全員に論理的な思考とコミュニケーションを求めています。しかしそもそも「論理的」とはどのようなことか、という根本にアプローチしているのがこの本です。私の論理学の知識は高校の数学Aとエンタメ的な論理パズル程度しかなく、一から学ぶよい機会だと捉えて輪読に参加しました。

輪読はよいものだ

私が最後にまともな輪読をしたのは学部時代のゼミが最後ですが、全員の理解を促進する素晴らしい学習方法だと改めて感じました。「自分が担当するところだけ読んであとは他の人の発表を聞き流せばいい」などと思っていたわけではありませんが、実際全くそのようなことはなかったです。他人の発表中でも定理の証明や練習問題に回答するよう振られることがあるので、発表内容に集中し、理解できなければ都度進行を止めて質問する姿勢が必要です。少人数での実施のため何回も発表担当が回ってくるということもあり、皆アクティブな聞き手として積極的にセッションに参加していました。自分の担当回では内容にツッコミがこないか、タフな質問がこないかとヒヤヒヤしていましたが、そういうところも含めていい体験でした。

『論理学をつくる』の感想

結論から言うとかなり難易度が高かったです。私がガチガチの文系なのもありますが、「論理学って逆・裏・対偶とかだよね」という程度の認識で読み始めると序盤から度肝を抜かれます。

『論理学をつくる』という書名のとおり、まずは最も原始的な論理言語を構築するところから始まります。その後、意味論的なアプローチと統語論的なアプローチの両方を取りながらより複雑な論理言語へと発展させていきます。数学でいうと、以下を厳密に定義しながら論をすすめるという感じです。

• 「1」「2」「+」「=」という文字・記号の配置ルール（統語論、シンタックス）
• それぞれの文字・記号の意味（意味論、セマンティクス） 本の中では当然上記の逆・裏・対偶の概念も出てきますが、本当に一瞬で通り過ぎてしまうので私の数学A知識が役に立つことはありませんでした。

「数学は絶望的なまでに積み重ねの学問である」と絹田村子著の漫画『数字であそぼ。』で言っていましたが（うろ覚え）、この本の内容がまさにそれです。過去に出てきた定義や定理、証明を理解できていないと永遠に論理言語の海を漂うことになります。個人的には続々と追加される記号とそれらの意味づけの理解（あと口に出すときの読み方も）に苦労しました。

業務に役に立つか

本自体の難易度もあってか、三分の一程度進んだところから脱落者が出始めましたが、過半数は完走できました。とはいえkippでの業務に直接的に結びつけやすいのは序盤の内容なので、そこまで全員が到達できたのは良かったです。中盤以降についても、単純化された命題よりも複雑な、より現実世界で我々が取り扱う自然言語に近いところまで論理言語を拡張するという内容なので、日常的な会話を論理的に捉える上での解像度があがりました。

『レオン』という映画を最近見ていたんですが、作品中の会話で以下のようなものがありました。

マチルダ：「豚は臭いから嫌」
レオン：「臭くない豚もいる」

私はこの会話を聞きながら、以下のようなことを考えていました。
「∀xSx,∀xSx↔Hmxだというマチルダに対して∃x¬Sxだからその論理は成り立たないとレオンは主張しているんだなァ」
ということで、輪読の内容は確かに身になっているのだと実感できました。今後業務でもそのように活用していけるとよいのですが。

輪読は続く

去年の第四四半期から続いた「論理学をつくる」の輪読も2023年7月で一段落したので、また別の本で輪読を続けていきます。次に取り扱う本は『アンガーマネジメント11の方法』です。またしてもFinTechと直接関係ない内容です。しかし感情をうまくコントロールし、怒りを正しい方向に向かわせることは業務だけでなく人生にも通ずるテクニックですので、ぜひこの本からその方法論を吸収していきたいですね。

kippでは一緒に働いていただける方を募集しています。今入社すれば一緒にアンガーマネジメントを学ぶこともできます。ご興味ある方は、お気軽にpeople@kipp-corp.comまでご連絡ください。

kippでは安全なサービスを提供し、情報漏洩を防止するため、従業員の端末の管理やセキュリティ対策にも力をいれています。 現在はMicrosoft Defender for Endpoint （以下MDE）の導入を進めています。 MDEはWindows OS標準添付のセキュリティ機能として知られるMicrosoft Defenderの集中管理バージョンです。 通常のMicrosoft DefenderはWindows固有の機能ですが、MDEはWindowsのほかAndroid、iOS、Linux、macOSでもサポートされている点が優れています。 さらにLinux環境でもソフトウェアインベントリや操作履歴の一部が取得できます。 MDEをすべての環境にインストールし、すべての環境のマルウェア対策を一元管理したいと考えました。

MDEは上述のようにLinuxとmacOSにもインストールできるため現在の従業員の環境をすべてカバーしていると想定していました。 しかし実際にはWSL2上のLinuxはサポートされていません。 WSL2がLinuxをゲストOSとしてのみ動作させることを想定しているため、必要な一部機能が省略されているからです。 今回はいくつかのハックを組み合わせて、通常省略されている機能を復活させ、MDEを動作させることに成功しました。

なお、Microsoft社の公式見解は見つけられませんでしたが、MDEはWSL2のサポートを想定して設計されていないように見受けます。 最悪の場合、ハックを導入したためにベンダー標準の状態で使うよりも脆弱な状態に陥るリスクさえあります。 MDEの導入と安定していてサポートされたWSL2環境のどちらを取るべきか、各自が吟味するべきです。

どうしてMDEが動作しないのか

MDEを動作させるためには、まずサポートしないとされている原因を把握します。 本記事ではホスト環境としてWindows 10を、WSL2のゲストディストリビューションとしてUbuntu 20.04を使います。 サンプルもすべてUbuntu 20.04を利用しています。 Windows 11では一部動作しない恐れがあります。

インストールガイドによれば、適切な準備をしてsudo apt-get install mdatpを実行すればインストールが完了するとしています。 しかしWSL2の環境で実行するとmdatpのパッケージは展開されるものの、post install scriptsの実行に失敗し、中途半端な状態になってしまいます。 エラーメッセージをよく見ると、systemdがないためにエラーが起きているとわかります。

systemdは最近の多くのLinux distributionで利用されているinitシステムですが、標準のWSL2環境には存在しません。 スクリプトを動かしたりGCCなどLinuxの開発環境を使う程度であれば必要ないため、省略されているのでしょう。 しかしmdatpのみならずデーモンプログラムやサーバを動かそうとすると、systemdを要求されるケースがあります。

systemdを導入する

systemdはいくつかの方法で導入できますが、現在一番簡単で信頼性が高いのはwsl-distrodを使う方法でしょう。 wsl-distrodは既存のWSL2 distributionに影響を与えず、linuxcontainers.orgから新しいイメージを展開するオプションがあるので、非破壊的に導入できます。 導入方法自体もとても簡単です。 Windows上でexeファイルをひとつ実行し、CLIインタフェースでいくつかの質問に答えるだけです。 いくつかの導入方法がありますので、上のリンクから公式情報を確認してください。

導入に成功すると、ps -aux等で全プロセスを表示したときPID1で/usr/lib/systemd/systemdが動作していることを確認できます。

auditを有効にする

systemdが動いている状態でmdatpのインストールを再試行すると、auditがサポートされていないというエラーに変わりました。

Error - audit support not in kernel
Cannot open netlink audit socket

auditdを調べると、この機能はパッケージマネージャなどでインストールできるものではなく、カーネル設定で有効にしなければならないと分かります。 さらに調べると、WSL2カーネルをビルドし上書きする方法が見つかりました。 この記事のなかで.configファイルを編集していますが、これはカーネルのビルドオプションを指定するファイルです。 このファイルでCONFIG_AUDIT=yを指定すればaudit機能が有効になりそうです。

実際に手順に沿ってビルドするとカーネルイメージ（bzImage）が出力されます。 Linuxカーネル全体をビルドする作業なので、マシンスペックによりますが30分程度かかります。 このbzImageを一旦Windowsのファイルシステムに待避し、C:\Windows\System32\lxss\toolsにあるkernelというファイルを置き換えます。 WSL2で起動するすべてのdistributionのカーネルが置きかわるようです。

実際にこの手順を行ったあと、mdatpを再インストールすると今度は成功しました。 systemctl status auditdで確認するとauditdも動作しています。

さらにMDEのインストール手順を最後まで進めると、無事テストウイルスファイルに対して検疫が発動することを確認できました。

カーネル生成の自動化

この導入手順では通常のWSL2環境にくらべてsystemdの導入、カーネルのカスタムコンパイルという2つの余計なことをしています。 余計なことをした部分は通常よりインセキュアになっていると考えるべきです。

リスクを詳しく分析すると、systemdやdistrodに脆弱性がある場合と、カーネルに脆弱性がある場合に特に深刻な影響を受けるとわかります。 systemdとdistrodは配布されているものをそのまま利用しているのでそれぞれの脆弱性情報を確認しパッチを適用すればよいでしょう。

しかしカーネルについてはオリジナルのものを使っているため、通常配布されているバイナリを利用できません。 WSL2にはwsl --updateというカーネルファイルを更新する機能が実装されていますが、この更新を利用するとauditdが利用できなくなるでしょう。 かわりに自分達で常に最新のカーネルをビルドし、利用するプロセスを確立する必要があります。

今回はGitHub Actionsを使って定期的な自動ビルドを実装しました。 kipp-corp/wsl2-kernel-with-auditはシンプルなworkflowだけが定義されているリポジトリです。 ビルドスクリプトが上のビルド方法をGitHub Actions上で実行する定義になります。 実行結果はActionsの履歴から確認でき、ビルド成果物のカーネルファイルもダウンロードできます。

LinuxカーネルやWSL2カーネルの脆弱性情報を確認し、更新が必要なときここからダウンロードして利用できます。 新しいメンバーが増える時でも秘伝のタレを伝授するかわりに公開された信頼できるソースを提示できます。

最後に

今回は実験的な試みとして、WSL2上のUbuntuでMDEを動かしてみた過程をまとめました。 また長期的に運用する上で課題となりうる部分を検討し、自動化まで達成しました。

kippはアプリケーション開発に留まらず、コンピュータサイエンスやセキュリティの幅広い知識をお持ちの開発者と一緒に働きたいと考えています。 情報管理やセキュリティの取り組みに関心をお持ちの方はpeople@kipp-corp.comまでぜひお気軽にご連絡ください。

本記事はKipp社の投稿時点の内容となります。 現時点で変更を予定している部分はありませんが、長い時間が過ぎれば社会状況の変化や会社の体制変化に伴ってルールが変わることも予期されます。 また主に開発チームの状況を紹介しており、他のチームでは事情が異なる部分もあります。 ご了承ください。

リモートワーク比重度

原文に沿って、各項目を順に見ていきます。

リモートワークの導入期間

「4: 継続してリモートワークを3年以上導入している」になります。 創業時点よりリモートワークを継続して導入しています。 Kipp社は創業後4年目にはいったところですので、年数の句切りは3年以上になります。

リモートワークの導入ポリシー

「5: 恒久的な導入であり、根本的な制度変更が行われることはない」になります。 私を始め多くのメンバーがリモートワークに強い意志を持っていますので、容易に変更されることはありません。 しかし企業体制が根本的に変わるようなイベントがあれば制度変更が避けられなくなる恐れも生じます。

リモートワークのマジョリティ度合い

「4: 全員が常にリモートワークの可能性がある（出社している可能性もある）」が該当します。 ほとんどのメンバー、とくに開発チームやプロダクトマネジメントチームのメンバーは全員がリモートです。 しかしkippは物理オフィスを所有しているため、オペレーション担当者が定期的に出社して郵便物や宅配物の対応にあたっています。

申請・許可の必要性

「5: 申請や許可は必要ない」です。 原則がリモートワークであるため、手続きはありません。 逆にオフィスの入室は登録制で、オフィスに入れない正社員メンバーもいます。

リモートワークの適用範囲

「5: 業務に関わる全メンバー（正社員以外も含む）がリモートワークを利用できる」 業務委託も含め、すべてのメンバーがリモートワークをしています。

出社義務

「5: 出社義務は無い」 出社義務はありません。書類のやり取りが必要な場合、郵送での対応が基本です。 ラップトップPCなど貸与物も宅配便で送付、返却しています。

リモートワークで必要なサービス・アプリケーションの取り扱い

「5: 業務で利用するサービス・アプリケーションはすべてリモートワークを前提としており、リモートワーク・非リモートワークによる差異はない」です。 コミュニケーションの大半をSlackとGoogle Drive、Backlogに集約しています。 特定の拠点でないとアクセスできないツールや紙の書式はありません。

情報のアクセス範囲

「5: リモートワーク・非リモートワークでアクセスできる情報に差はない」です。 上述のとおり情報はすべてクラウドサービスで管理されており、アクセス制限も行っていません。

その他の制度や特徴

最大の特徴はCEOとCTOがともにオフィスのある東京に居住せず、リモートワークをしている点でしょう。 冒頭でご挨拶したとおり私は札幌に住んでいます。 稀にオフィスや東京のメンバーに用事がある場合は飛行機で出張しています。 私は暑いのが苦手なので、夏が短い札幌の気候は大変気に入っています。

ワーケーション（保養地や旅行先で羽を伸ばしながら就業するスタイル）を時折実施しているメンバーもいます。 昨今では旅行じたいしにくくなっていますが、2019年の夏には1ヶ月弱ヨーロッパを旅行しながら就業していました。

住宅手当という形で、月に5万円を給与に加算しています。 住宅手当といっても出社しやすい居住することを推奨するのではなく、労働に適した住環境を整えてもらうための手当としています。 もっぱら業務に利用する機器は経費で購入できますが、長期に個人で使いたい椅子や机、ディスプレイにはこの手当を活用できます。 申請や清算もないので、単にその分給与が上乗せされているというのが実態です。

リモートワークの文化

同期・非同期コミュニーションの割合

テキストの非同期コミュニケーションが中心です。

同期的なコミュニケーションは「A: 同期的なものを使うこともあるが全て非同期の方法で代替することができる」と「B: 一部で同期的なコミュニケーションが必要」の両方のケースがあります。

開発チームの業務委託のメンバーなど関与の範囲が限定的な場合、すべてのコミュニケーションを非同期で行っています。 深夜や休日に作業するメンバーも多いため、管理者の負担を下げることにもつながります。

一方、複数のサービスや会社全体の状況を理解すべき立場では、プル型の情報取得で把握するのが難しいこともあります。 またテキストのメッセージ発信はタスクに基づいたものが中心となり、ワークスタイルなど目前のタスクと直接関係ない相談がしにくい傾向にあります。 必要と感じた場合は躊躇せずビデオチャットを行います。 参加メンバーが必要に応じて定例のミーティングも行っています。

ビデオや音声を繋ぎっぱなしにするようなことは行っていません。

テキストコミュニケーションの割合

「B: テキストが主で、補助的にビデオ通話・音声通話を用いる」に該当します。 非同期のコミュニケーションはテキストのみ、同期のコミュニケーションはビデオ通話が中心です。

すこし論点がかわりますが、状況に応じてビデオ、音声の送信をオフにしてもかまいません。 アバターで参加しているメンバーもいます。

コミュニケーション頻度

概ね「E: 成果物のみでやり取りをする」になります。 timesチャンネル（分報）や趣味のチャンネルでの業務に直接関連づかないコミュニケーションがありますが、話が長く続くことはないので雑談とはすこし違います。

働く時間

「A: 全員働く時間は定まっておらず、同期的なやりとりには調整が必要」です。 実際に深夜、休日に作業しているメンバーもいます。 とくに開発チームはそういった時間に作業している比率が高いです。 予期せぬ時間にミーティングを入れると寝坊してしまうこともあるので、全員が出席できる自信のある時間に調整しています。

最後に

今回はチェックリストに照らして私達のリモートワークの様子を確認してみました。 まさにmugi-unoさんの指摘するとおり、リモートワークと一口に言っても様々な観点と様相があります。 いままでのカジュアル面談では聞かれるままに取り止めなく語ることも多かったですが、このように論点が整理されていると説明しやすくなります。 就職や転職を考える方も、基準に沿って列挙されていると就職先の比較検討が容易になりそうです。 ずっとリモートで勤務したい方は是非kippもご検討いただき、興味を持たれましたらお気軽にpeople@kipp-corp.comまでご連絡ください。

PCI DSSはカード会員データ（主にカード番号）を取り扱う事業体が準拠すべきセキュリティ基準です。 PCI DSSの監査は毎年受け、準拠状況を更新することが求められます。 監査は毎年国際マネジメントシステム認証機構に依頼しています。 Kipp社は2020年に初回の監査を受け、2022年で3回目になります。 初年度は準備も監査中もかなりの時間と労力を要しましたが、ノウハウを積み重ねることで年々監査の負担が減少しています。 今回はPCI DSS準拠の負担を軽減しつつ、セキュアにサービス構築するためのノウハウをお伝えします。

この記事で参照するPCI DSSはバージョン3.2.1です。 近くバージョン4への移行が予定されていますが、執筆時点では正式公開されていません。 AWSクラウドサービス上で構築することを前提に、全体でAWSの用語を使っています。 同様の考え方は他のクラウドサービスにも適用できますが、非クラウド形式のインフラサービスや自社が所有する機器では事情が大きく異なりますのでご注意ください。 本記事の内容はすべてkippの経験に基づくものであり、PCI SSCや国際マネジメントシステム認証機構の見解を示すものではありません。

対象領域のコントロール

PCI DSS準拠の負担を軽減する最も効果的な方法は、監査対象領域を縮小することです。 これがこの記事で説明するすべてです。 当たり前のように聞こえますが、実際に対象領域を縮小するアプローチは興味深いものがあります。 この記事ではkippが実際に行った対象領域をギリギリまで減らす努力を具体的に紹介します。

企業規模にかかわらず、事業体は複数の業務を行うの一般的です。 kippのようにプリペイドカードを発行する事業体でも、会員管理やプリペイドカードへの入金など、カード会員データと直接関係ない機能があります。 またkippが提供するサービスにはミライバライ向け機能のようにカード情報の取扱が一切生じないサービスもあります。 対象領域のコントロールをしないと、無関係にみえるサービス、実装もすべてPCI DSS監査対象になってしまいます。

これは直感的におかしいです。 カード会員データを扱わない部分はPCI DSSを適用する必要はないはずです。 PCI DSSより条件の緩い、別のセキュアなサービスを構築するプラクティスを適用すれば十分でしょう。

PCI DSSの監査対象になるのはカード会員データ（カード番号など）と機密認証データ（CVVや暗証番号など）の「保存、処理、伝送」に関わるシステムコンポーネントと事業体です。 決済サービスを行っていてもクレジットカードを取り扱わない事業体はPCI DSSに準拠する必要がありません。 カード発行機能を持つサービスの中でもカード会員データの「保存、処理、伝送」に関係ない部分は監査対象から外せます。

「関係ない」と言いきれるのはネットワークの構造やデータの流れを調査して、「保存、処理、伝送」のいずれにも関与しない場合です。 この3つの要素をよく見ると、保存するには処理する必要があり、処理するにはどこかからカード会員データを受け取る（伝送される）必要があります。 ですからカード会員データに関係するコンポーネントを図に整理したとき、伝送していない部分は対象外にできます。

データの流れはどのように調査するのでしょうか。 PCI DSS要件1.1はコンポーネントとその関係をネットワーク図やデータフロー図といった図にまとめることを要求しています。 図は人が手で書くものですので、実際のシステム構成とずれてしまうリスクがあります。 ずれが生じないよう定期的に見直す要件（1.1.2.b）もありますが、見直しも人手で行う点は同じです。 監査もこれら文書や図を元に行うので、図に抜け漏れがあると不正に準拠状態になってしまう危険があります。 人が作成した文書に基づいて人が監査するということの不確実性を肝に命じ、普段の業務でも監査時も嘘偽りなく対応することが健全な準拠の前提条件になります。

伝送していない部分は対象外になりますから、ネットワークが完全に分離しており、通信の手段がひとつもなければ間違いなく対象外です。 AWSではVPCが主要なコントロール手段になります。 カード会員データを取り扱うVPCが完全に独立してVPC PeeringやInternet Gatewayを持たなければ、そのVPCのみが監査対象になります。

kippではカード会員データを取り扱う専用のAWSアカウントを作成し、AWS Organizationsの機能で管理しています。 他のサービスもそれぞれ独立のAWSアカウントで動作しており、サービス間のデータの混入や障害の相互影響のリスクを低減しています。 その中でインターネットにも接続していないカード会員データ環境VPCを用意し、監査対象のネットワークをこのVPCひとつに限定しています。

アウトソーシング

通常、カード決済業務は外部サービスとの通信が必要です。 カード発行者（イシュア）であればブランドのネットワークと接続し、決済リクエスト（オーソリゼーション）や売上情報を受信します。 決済代行やアクワイアラであれば消費者からカード番号を受け取り、上位のアクワイアラやブランドに伝送します。 そう考えるとインターネットにも接続していないVPCで業務が成立するのは変ですね。

kippはブランド接続の機能をほとんどアウトソーシングしています。 TIS社のPAYCIERGE ブランドプリペイドプロセッシングサービス(以下、PAYCIERGE)はワンストップでプリペイドカードのイシュイング機能を実装できるサービスです。 ブランドネットワークと接続するための開発はとても分量が多く、慎重な実装が求められます。 PAYCIERGEを利用すればブランドネットワークとの通信はすべて提供されており、カスタマイズしたい部分だけを拡張できます。 kippではカード発行前に発行データを調整する部分と、決済リクエストに対して不正対策や複雑な残高処理を実現する部分で拡張しています。

PCI DSSはインターネットからのアクセスが特に重大な脅威源となることを踏まえ、インターネットからのリクエストを受け付けるネットワークとアプリケーションに重厚な要件を課しています。 しかしPAYCIERGEからの決済リクエストのカード番号はすべてPAYCIERGE内のトークンに置き換えられているため、決済リクエスト処理ではカード会員データを受け取りません。 同様にクレジットカードから入金を受ける場合も、決済代行のトークン化APIを利用することで自社のサーバでカード会員データを受け取るのを避けられます。 PAYCIERGEのようなトークン化の機能を持ったサービスを活用することで、機能性を損ねることなく公開されたコンポーネントからカード会員データを排除でき、監査対象を大幅に削減できます。

ただし私達はカード会員データの管理の一部をPAYCIERGEに委託していることになりますから、PAYCIERGEがカード会員データを適切に扱っているか確認しなければいけません。 PCI DSS要件12.8では委託先の適格性を各社が調査するほか、PCI DSS AOC（準拠証明書）を確認することでこの責務を果たすよう義務づけています。

マネージドサービスの利用

アウトソーシングによりkippがカード会員データを扱うのはPAYCIERGEからカード発行データファイルを受領し、変換し、印刷会社に受け渡す部分のみになりました。 この変換機能はAWSにあるので、PAYCIERGEおよび印刷会社との接続はインターネット経由になります。 するとPAYCIERGEからカード発行データファイルを受け取る部分、印刷会社に受け渡す部分も上述の要件の対象になりそうです。

ここでもアウトソーシングの考えを活用し自社の責任範囲から外すことができました。 AWSは非常に多くの機能に対してPCI DSSの準拠証明を受けており、S3やTransfer for SFTPもそのなかに含まれます。 PAYCIERGEからはS3 APIを利用してアップロードしてもらい、印刷会社にはTransfer for SFTPで提供したSFTPサーバからS3内のデータをダウンロードしてもらっています。 インターネットからのリクエストを受ける部分はすべてAWSマネージドサービスになりますから、自社でASVスキャンを受けずに済みます。 かわりにAWSのAOCを参照し、該当機能についてAWSが責任を持っていることを確認します。

ここまでの工夫により自社で管理する部分はS3バケットからデータを取り出し、別のS3バケットにデータを書き込む部分のみとなりました。 実にサービスの99%程度が監査対象から外せたと言えます。 この変換処理の中でも監査対象を減らす工夫があります。 AWS VPC内からS3にアクセスするのにインターネットを経由せず、VPC内にS3エンドポイントを建てています。 さらにEC2などのサーバを管理するとサーバのミドルウェアの更新（要件2.2）やウィルススキャンの要件（要件5.1）が生じます。 AWS Fargateで動作するように設定したECSタスクを利用すれば、これらも緩和できます。

結果的に、インフラストラクチャで監査対象になるのは以下に絞れます。

• ECSでタスクが動作するVPC
• そのルーティングテーブル
• そのサブネット
• そのセキュリティグループ
• タスク上で動くアプリケーションの開発、管理手順
• アプリケーションのイメージのビルド手順
• ECS実行環境の設定とIAM権限
• それらのCloud Watch Logsログ

12章もある要件のすべてが1時間程度で見られる項目に絞れるのは非常に価値があります。

なお、PCI DSSバージョン3.2.1はコンテナ技術やマネージドサービスについての言及が限定的であり、監査会社や監査人によって解釈が異なる場合もあります。

最後にAWSマネージドサービスを使い、かつペネトレーションテストを行う場合、AWSのテストポリシーに従う必要があることに注意します。 たとえばAmazon ECSやAWS Fargateはこの許可リストの中に含まれていないため、Fargate上で動作するコンテナにペネトレーションテストを行う場合は個別に判断を仰ぐ必要があります。 S3のパブリックエンドポイントのようにペネトレーションテストが許可されないだろうリソースについてはAWSのPCI DSS AOCを以て不要と整理します。

物理環境の管理

クラウド環境のみでなくオフィスやデータセンターなど物理環境を利用する場合、それらもPCI DSSの監査対象になります。 サーバを設置せず、オペレーション業務用の端末を利用するだけでも厳しいコントロールが必要になります。 kippも当初はカード番号を取り扱うオペレーション用のオフィスを用意していましたが、賃料から担当者によるメンテナンスまで費用が非常に高く付くので、現在は閉鎖しました。

カード会員データを取り扱えるオフィスを管理すると管理リソースが増え、結果的にカード情報漏洩の危険が増します。 カード会員データを扱うためには入退室管理、監視カメラの設置、私有デバイスの持ち込み禁止など通常のオフィスで求められる以上のコントロールが必要です。 すでに一般業務用のオフィスを持っていても、そこでカード会員データを扱えるように変更するのは手間です。 感染症の流行下にあり、また働き方が多様化する現在にあってはオフィスを開設しない選択肢を積極的に検討するべきでしょう。

しかしほとんどのカード会員データを取り扱う事業者はオフィスを持っており、また他の事業者もカード会員データを取り扱える場所を持つことを前提としています。 オフィスを置かない場合、オフィスがない、カード会員データを人が取り扱えないことを取引先に理解し、正しく対応してもらう必要があります。 カード業務を行う会社間ではチャージバックやカードデータ漏洩時の対応など、カード番号を伝達する場面があります。 kippの従業員はカード会員データを直接取り扱わない定めをしているため、そういった場合トランケートして授受するよう依頼しています。 特別にカード会員データを扱える場合を定めるより、端から扱わないよう業務を構築したほうがセキュアかつ簡単になります。

オフィスに関連した例外規定

カード会員データを扱える環境を廃止するにあたり、懸案になった箇所が2つあります。 ひとつは物理プリペイドカードを発送したもののカードが受け取られず、郵便が戻ってきた場合です。 郵便の返戻先はカード発行会社と自社オフィスを選べましたが、費用の問題もあり自社オフィスになっていました。 この返戻された封筒にはカード会員データが入っているため、そのまま取り扱うと監査対象になります。

PCI SSCは無効であると証明できるPANに適用されないという公式解釈があります。 そこでカード発行のライフサイクルを工夫し、利用者が自身でカードを受け取り、アプリから有効化しない限り利用できないように設計しました。 さらに同一カード番号での再発行を禁止し、すでに利用可能なカード番号や将来利用可能になりうるカード番号が返戻されてこないようにしました。 結果オフィスに返戻されるカードは返戻された時点で無効であり、将来にわたっても無効でありつづけるため、返戻カードをカード会員データ環境外で扱えます。

もう一点は管理アクセスの拠点の問題です。 実際にカード会員データを閲覧する業務は発生しないものの、カード会員データを保存するAWS環境を設定・運用するためのリモートアクセスが必要です。 kippは現在ほとんどすべての業務をリモートで行っているため、管理アクセスもリモートで行うべく検討しました。

こちらも公式のガイダンスが出ています。 簡単にまとめると、従業員の自宅からのアクセス経路は信頼できないネットワークと識別しなければならないが、その経路は事業体の管理が及ばないので監査対象にはしない。 そのかわり自宅からのリモートアクセスの手順と仕組み、接続をセキュアにして全体のセキュリティを担保すべきとなります。

AWS環境の例であればログインに使う端末、ログイン時の認証手段、そしてAWSとの通信経路が適切に保護されていることを確認します。 kippでは次のようにこの保護を達成しています。

• カード会員データ環境の管理に使えるラップトップの貸与
• ウィルススキャンの導入を含めたラップトップの管理方法の策定
• Oktaを導入し、きめ細かく認証とセッションライフサイクルを管理
• Okta、AWSとの接続がTLS v1.2以降で保護されていることの確認
• Okta、AWSのAOCの確認

管理対象を削減し一石二鳥

今回の記事では3回のPCI DSS監査を受けた経験をもとに、PCI DSS監査の負担を軽減する業務設計のノウハウを紹介しました。 監査負担の軽減が監査対象を減らすことによって達成されること、同時に漏洩リスクを抱える箇所が減ってセキュリティも向上することを説明しました。

私自身、当初は「そんなに削っちゃって大丈夫か」という不安を抱いていました。 最初はAWS Fargateを使わず、わざわざEC2インスタンスを起動してECSを運用していたほどです。 監査員の方々に丁寧に説明をしていただき、まったくの杞憂であること、むしろ管理する対象を減らすのが正しいことを理解しました。 業務効率化によってPCI DSS準拠の負担は年々減り、今年の監査は検出事項ゼロを達成したのみならず、予定より1時間以上早く終了しました。

本記事の内容はすべてkippの経験に基づくものであり、PCI SSCや監査会社である国際マネジメントシステム認証機構の見解を示すものではありません。 要件の具体的な取り扱いは監査会社や監査人によって異なる場合があります。 すべての監査において今回紹介したロジックが適用されるわけではありません。 あくまで一例、体験談として参考にしてもらえれば幸いです。

kippはプリペイドカードの発行サービスを維持、拡大し、ますます多くのお客様に安心して使っていただくため、今後もPCI DSSへの準拠とシステム全体のセキュリティ向上を続けます。 セキュリティの知見を生かしたい、セキュアなソフトウェア構築の現場で働いてみたいという方はお気軽にpeople@kipp-corp.comまでご連絡ください。

この記事では今まさに実践しているワークフローを紹介します。 主に開発チームメンバーの視点でお話ししますが、他のチームに興味がある方にも参考になるでしょう。 先述の記事とあわせて読むと、理念と実践がペアになり理解しやすいです。 複数のチームがどのようにコラボレートするのか、開発チームのメンバーがどう作業を進めているか伝われば幸いです。

チームの構成

kippには開発に携わるチームが開発チームの他に2つあります。 この他に運用担当、コーポレート業務のチームがあります。

• 開発チーム：サービスの開発、運用を担当します。正社員の開発チームメンバーは輪番でオンコールも担当します。
• 事業開発チーム：社外のパートナーと共に新プロダクトや改善の企画をします。
• プロダクトマネジメントチーム：全サービスの妥当性・整合性に対して責任を持ちます。仕様の調整から受け入れテストまで開発の全ライフサイクルを管理します。

事業開発チームとプロダクトマネジメントチームはもともとビジネスチームとしてひとつに数えられていました。 人数が増えるに従い開発チームの役割をすこし分担したプロダクトマネジメントチームと、新企画に専念する事業開発チームが出来ました。

すべての開発のスタート地点：提起

いかなるプロダクトも改善も、課題や要望があって始まります。 新規プロダクトの立ち上げであればプロダクトで実現したい内容が最初にあります。 改善要望であれば現在のプロダクトで困っている状況と実現したい希望があります。 リファクタリングでも、現在のコードの課題点と、こう変えたらこの実装がスムーズになるというビジョンがあります。 これら開発を始める動機を示すことをまとめて提起と呼びます。

リファクタリングやパフォーマンス改善を別として、提起は開発チーム外からやってきます。 社内の他チームの場合も顧客企業のスタッフの場合も、エンドユーザの場合もあります。 私達はこれらの意見に耳を傾けるべきですが、一から十まですべて鵜呑みにすべきではありません。 提案者は業務のプロフェッショナルであってもシステム設計や実装のプロではありません。 注意深く要望を聴取すると、当初案より包括的で効率の良い案が出てくることがよくあります。

kippでは提案者の要望を理解すること、要望を実現するとどう変わるのか理解してもらうことに時間を使っています。 規模の大きい変更や新機能の提案であればドキュメントにまとめ、議論の全体が一箇所でわかるようにします。 提起されたプロジェクトでやるべきことを整理するドキュメントなので、Project Scope Document (PSD)と呼びます。 PSDは設計や実装でも提起の原点を振り返る資料として有用です。 このステップは事業開発チームが中心となって進行します。

関係者との調整と並行して、法的な確認やパートナーの選定も行います。 ビジネス案を多数の金融関連法に照らし、弁護士とともに懸念点を潰します。 カードの印刷や決済ネットワークへの接続といった自社で賄えない機能を提供してくれるパートナーと交渉し、タイムスコープや収益性を確認します。

小規模な困りごとにはプロダクトマネジメントチームが対応します。 サービスを使っているうちに要件と現実が乖離してきたり、要件定義時に想定していなかったケースが出てきます。 エンドユーザ、利用社、オペレーション担当者から広くフィードバックを受け、疑問や希望を改善提案に繋げます。 事業開発チームが新しい価値を生み出す動力源であり、プロダクトマネジメントチームが既存の価値を高める精錬機であると対比できます。

BaaSへの統合：要件定義

kippは全システムをBaaS (Banking as a Service)として提供しています。 すなわち、個々の利用社が別々のシステムを使うのではなく、ひとつのシステムの個々の側面を利用しています。 提起された課題はその関係者のためだけに実装するのではなく、BaaS全体の資産価値を高めるために実装します。 機能が提案者に提供されるのはもちろん、将来の利用社に対しても提供でき、kippのシステム、会社としての価値が高まります。

この目的のために、提起内容をBaaSの文脈に置き直す必要があります。 前提として既存の仕様、実装と矛盾しないことが求められます。 たとえば同一のカラムを異なる利用シーンで別々の解釈をしてしまうと今後全ての実装が分岐を意識しなければなりません。 よく似ているが実は異なる概念も実装ミスの遠因になります。 負債になりうる仕様は実装前に回避します。

さらにBaaSの発展性に寄与するかという観点から検討を加えます。 特定の業務フローのためだけに実装してしまうと、業務内容は同じでも手順が違うシーンで再利用できません。 フロントエンドの画面ステップなどに合わせず、BaaSとして妥当なように実装します。 この観点を取り入れた事例のひとつが過去ご紹介したGraphQLの活用です。

要件定義はプロダクトマネジメントチームが中心になります。 提起内容をBaaSの文脈で評価した結果、一部を変更してもらうこともあります。 したがって要件定義作業は提起作業に一部食い込む形で行い、手戻りを避けます。 同様に次の設計ステップも要件定義や提起に食い込む形で行います。 事業開発チーム、開発チームと相談しながら進行します。

最終的な要件はBusiness Requirements Document (BRD)にまとめます。 BRDはその名のとおりビジネスを成功させるために必要なことを過不足なく記述するものです。 情報を取得・保存するタイミング、バリデーションなど業務を間違いなく行うために必要な内容は記載しますが、テーブル設計など内部の実装方針は記載しません。 社外のチームと同時並行で実装を進める場合、このタイミングで仕様書や説明書を配布します。

設計

BRDをもとに実装方針を立てます。 要件定義段階から開発チームのメンバー（おもにCTO）が議論に参加し、現在のコードベースに合う形でインテグレートする方法を想定しています。 設計段階ではその想定を書き起こし、開発チームの全メンバーに同じ方針を共有します。

大規模なプロジェクトでは新しくテーブルをたくさん作ったり、新しい通信相手にAPI定義を提供します。 これらの作業を実装する各人が一部ずつ進めるとコンフリクトが起きやすくなります。 また先行の作業が詰まって新しいタスクに着手できない状況も起きます。 トラブルを回避するため、新サービスを提供するような規模では、設計段階でテーブルとAPI定義を一気に作ります。

大規模なプロジェクトでは、タスクを複数人で分担する必要もあります。 Scalaで実装し、各コミットに実装した分のテストを義務づける環境ではタスクの分割や依存管理も重要です。 でたらめな単位でコミットするとコンパイルが失敗しマージできません。 利用者に提供するほど完成していなくてもテストで確認できるくらいの粒度で分割します。 各タスクの期日を設定し、全体スケジュールに対しては余裕があり、各メンバーの負担がきつくなりすぎないよう調整します。 依存関係によって手があいてしまうメンバーがでないよう工程を引くのも設計の一部です。

設計は開発チームが中心になりますが、要件定義に加わったメンバーがほぼ独力で行います。 内容は多岐に渡りますが作業量はさほど多くありません。 成果は、分量が多ければ実装メモという文書にまとめます。 それほどでもなければタスク管理の説明文に方針を記述します。 この準備によって作業中やレビュー時の手戻りを減らせます。

実装

開発チームのメンバーはそれぞれのペースで未アサインのタスクに着手します。 タスクは自分ができる範囲で締切が近いものから順に行う決まりになっています。

これまでのステップでPSD、BRD、実装メモやタスク説明が準備されています。 担当者はこれらの文書を丁寧に読むことからスタートします。 文書化されているため休日や深夜早朝、他のメンバーが勤務していないタイミングでも着手できます。

わからないところ、疑問、誤解しそうなところがあれば質問します。 改善案もこのタイミングで提案します。 実装中に疑問が出てきた場合、都度チャットで質問します。 記述がわかりにくい部分は修正し、次以降に読む人がわかりやすいように改善します。 BRDに制約が足りなくて振舞が一意に定まらない場合、BRDに追記し明確に定めます。

既存のコードの類似箇所を参考にしながら実装者自身が処理を設計し実装を進めます。 実装しやすくするための小規模なリファクタリングは実装前にちょっとやってしまうことも多いです。 実装と同時にテストを書き、BRDに記述されているケースを中心に自信がない部分、複雑なケース、壊れそうなケースを保護します。 kippは機能レベルのすべての動作を自動テストで担保しています。

あらかじめテーブルやAPIを定義していても、実装をすすめていく上で不足していたテーブルやカラム、APIメソッドが出てくることがあります。 設計者と相談しつつ不足や間違いを訂正し、機能が正しく動くようにします。

実装したものは1人以上のコードレビューを受けます。 コードレビューでは挙動の正しさだけでなく、コメントの過不足、可読性、保守性、テストの網羅性まで詳細にチェックします。 とくにデッドロックやパフォーマンスの問題はテストで検知しにくいので他の開発者の目で丁寧に検査します。

テストとデプロイ

Change Request（Gerritにおけるレビュー単位、GitHubのPull Requestに相当）がマージされると、自動的にAWS上の開発環境に展開されます。 そして次の週に自動的に本番環境に展開されます。

社内外の関係者はこのあいだに受け入れテストを行います。 実装者が追加したテストは、あくまで実装者の理解にもとづいたテストです。 丁寧にドキュメントを記述しレビューしても実装者の理解が間違っているリスクは残ります。 そこでプロダクトマネジメントチームを中心に関係者が変更された部分をテストし期待通りか確認します。 間違いがあった場合はBRDに照らして再確認し実装を修正します。 修正が次のリリースサイクルに間に合わない場合はrevertで該当部分を外します。

開発プラクティスとして

ここまでkippで実践している開発ワークフローを具体的に説明してきました。 最後にこのワークフローを開発プラクティスの観点でどう考えているか紹介します。

以上から分かるように、kippの開発プロセスはウォーターフォールに近く見えます。 継続的デリバリーを実践している点などアジャイルのプラクティスを取り入れている部分もあります。 私達はこれを、アジャイル志向のウォーターフォールと捉えています。

ここでアジャイル志向と言う理由はAgile Manifestoを参照している一点に尽きます。 要件定義と受け入れテストという顧客の意思を受け止めるべきステップでは協調を重視してます。 また要求を整理するドキュメントは丁寧に作成する一方、実装のためのドキュメントは最小限に抑え、開発成果物を早く、読みやすく作ることに注力しています。 提起から実装は速ければ2週間で完了します。 新規サービスの立ち上げも4ヶ月から6ヶ月で完了した実績があります。 ウォーターフォールのワークフローでありながら個々のトピックを高速で処理し、開発イテレーション数を稼ぐことで変化への対応力を身につけています。

私達が広く共有されている開発プラクティスを採用せず、このような手法を取っている理由をスクラムとの対比で説明します。 スクラムではチームの一体性を重視し、デイリースクラムをはじめ会話の場が多く準備されます。 イテレーションが軸となり、計画と振り返りを行います。

スクラム開発がkippにそぐわない第一の理由は直接の対話を重視する点にあります。 kippは個人主義が強く、業務委託メンバーも多いため、毎日決まった時間に全員が集合するのは不可能です。 正社員でさえ全員揃うタイミングがない日もあります。 時間、場所に囚われない働き方を前提としたチームには対話を強制できません。

第二の理由はイテレーションの考え方とkippのタスク管理がマッチしないことです。 スクラムのイテレーションの背景には単一の目標にむかってチームがイテレーションごとに前進していく像があります。 しかしkippのタスク管理表には緊急の障害対応から数カ月先のタスクまで規模も重要度もプロダクトも様々なタスクが混在しています。 これらをひとつのスプリント計画に落とし込むのは時間がかかるわりに無益な作業でしょう。

ではどのようにタスク管理をするのでしょうか。 答えは3つのルールだけでコントロールされています。

• 充分な時間を取る
• 出来ることをやる
• 締め切り厳守

タスクを作成するとき、すべての開発タスクは締切を2週以上先に置くルールがあります。 重厚なタスクでも、改善レベルであれば2週間で分担して終わらせられます。 大規模な新機能開発は例外で、戦略上のリリース時期から逆算して締切を順次設定します。

開発者はその時々で出来ることをやることを期待されています。 締切が短かったり不慣れなタスクで終わらなそうな場合は他のタスクを選択するべきです。 タスクの説明やBRDを読んですんなり理解できれば完遂できるだろうと見込めます。

締め切り厳守は一番身も蓋もないルールです。 スクラムで振り返りが必要なのは、締切を守れないことがあるからです。 初めから全ての締切を守れば振り返りは不要です。 一度タスクを取った以上、なにがあってもそれを完了させる責任があります。 完了する方策のなかには他のメンバーのヘルプを仰いで移譲することも含まれます。

締め切り厳守の仕組みとして、締切2日前から完了するまで、毎日Slackでメンションが飛んできます。 本人だけでなくチーム全員の目に触れるので、終了見込みを尋ねたりタスクを分担する契機にもなります。

これらのルールは開発者が高い実装能力を持つことを前提としています。 kippの開発者には行き詰まらず、常に見積もった日数で作業を完了する能力が求められます。 このワークフローに魅力を感じ、堅実で責任感ある開発ライフを送りたいと思った方はぜひpeople@kipp-corp.comにご連絡ください。

以前よりアナウンスされていましたが、ついに2月1日よりNTTドコモによるIPv6シングルスタック方式の提供が開始されました。 ドコモ社は日本有数の移動体通信事業者です。 ドコモ社がIPv6シングルスタックを開始することでkippのサービスを利用されるお客様の端末の接続環境の無視できない割合が影響を受けると予想されます。 またドコモ社の取り組みに倣い、他の移動体通信事業者も同様の取り組みを検討するでしょう。

移動体通信に限らずIPv6活用の取り組みは広く行われています。 多くの固定回線プロバイダがIPv6のオプションを提供しています。 実際にGoogleサービスへのアクセス統計を見ると執筆時点で日本からのアクセスの43%がIPv6で行われていると分かります。

本記事ではIPv6が普及していく、さらにはIPv4を持たない端末が増えてくる状況で金融サービス提供者が何をするべきか考察します。

IPアドレスと金融サービス

IPアドレスはインターネット通信において機器を識別する値です。 ある機器から宛先の機器にパケットを送信し、その返信を受け取るという通信の基本動作はIPアドレスによる発信元、送信先の指定によって実現されます。 なお本稿では金融サービスに限ってお話しするため、ローカルエリアネットワーク内でのIP通信に言及せずインターネット上の通信のみを扱います。

金融サービスをはじめとするインターネットサービスの多くはサービスプロバイダがサーバを提供し、エンドユーザがクライアントになります。 エンドユーザの機器からサーバに送られたIPパケットの送信元IPアドレスはエンドユーザの環境について一定の情報を持ちます。 この情報はサービスの利便性、安全性を向上する役に立つため、多くの事業者が送信元IPアドレスを記録、分析しています。

たとえばIPアドレス帯と国を紐づけるデータベースを利用し、送信元の国を推定できます。 kippは日本国内向けにサービスを提供しており、ほとんどの利用者は日本国内で利用しています。 直前まで日本国内からアクセスしていた利用者が突然国外の遠い地域からアクセスした場合、不正アクセスの被害に遭っている疑いがあります。 あるいは同一送信元IPアドレスから大量のアカウントを操作している場合、利用規約に反して複数アカウントを取得している懸念があります。

こういった推定は不確実です。 IPv4アドレスによる推定にまつわる誤検知のリスクはよく知られています。 たとえば学校や会社から複数の利用者が同時にアクセスすることで複数アカウント検知を発火させる恐れがあります。 IPv4アドレスと国の対応付けデータベースが更新されておらず、日本国内からのアクセスが国外からのアクセスと判定されサービスが利用できなくなった事例もあります。

それでは、IPv6利用が普及した状況でIPアドレスによる推定はどんな影響を受けるのでしょうか。 サービスプロバイダはどう対応するべきでしょうか。

ケースとリスク

具体的にサーバ・クライアントのそれぞれの状況の組み合わせについてリスクを分析していきます。 まずサーバ側にはIPv6とIPv4両方に対応しているケース（IPv6/IPv4デュアルスタック）とIPv4のみに対応しているケースを考えます。 IPv6のみに対応する運用は現在のエンドユーザのIPv6利用可能率を考慮すると実用的ではないため省きます。

次にクライアント側はIPv4のみ利用できるケース、IPv6のみ利用できるケース（IPv6シングルスタック）、IPv6/IPv4両方利用できるケースがあります。 IPv6シングルスタックではドコモの事例のようにインターネットサービスプロバイダによってIPv4アドレス変換されることがほとんどですので、変換機能を仮定します。

サーバ2パターン、クライアント3パターンの掛け算をすると6パターンですが、今回興味があるのはサーバ側の対応です。 サーバの受け取るIPパケットがIPv6パケットかIPv4パケットかでおおまかに場合分けできます。

IPv4通信の場合

伝統的なケースです。 前の節で議論したようにIPv4アドレスの利用は長く行われており、弱点も含めてよく知られています。

IPv6通信の場合

サーバとクライアントがともにIPv6対応している場合、IPv6で通信します。 ともにIPv6/IPv4デュアルスタックの場合、Happy EyeballsによりIPv4が利用されることもあります。 上述の「IPv4通信の場合」に該当するので、取り立てて議論する必要はありません。

サーバがIPv6アドレスを記録、利用する場合、追加で注意すべきことがあります。

1. IPアドレスの構造が違います。 IPv4アドレスは32ビット値であり、文字列表現としてはピリオド句切りの4つの10進数値の組がよく用いられます。 IPv6アドレスは128ビット値であり、文字列表現も16進数とコロンを使います。 IPアドレスを保存するデータベースカラムを32ビット値のみに対応した整数型や15文字までの文字列型にしているとIPv6アドレスを保存できません。 初歩的なミスなので、検証中にすぐ気がつけるでしょう。
2. 同一拠点でも別機器のIPv6アドレスは異なります。 小規模なエンドユーザの拠点、すなわち一般的な家庭を想定しています。 一般的な家庭ではグローバルIPv4アドレスを1つだけ利用し、NAT（network address translastion）機能によって複数の端末が1つのグローバルIPv4を共用します。 IPv6環境の場合、拠点にはプロバイダからグローバルルーティングプレフィックスが割り振られます。 それにルータがサブネット識別子を付加し通常64ビットのサブネットプレフィックスを作ります。 さらに各機器が64ビットのインタフェース識別子を持ち、全体で128ビットのIPv6アドレスになります。 IPv6アドレスではグローバルルーティングプレフィックス部を把握する方法がなく、IPv4アドレスに比して同一拠点判定の信頼性が揺らぎます。 グローバルルーティングプレフィックスは64ビットがよく見られますが、48ビットを割り当てるケースもあるようです（フレッツにおけるIPv6接続について(PDF)。古い資料です）。
3. 同一機器からのIPv6アドレスも経時的に変わります。 前項でも言及したインタフェース識別子が機器に対して固定だとIPv6アドレスが同じなら同一拠点の同一機器と識別できますし、機器を移動しても別拠点の同一機器と識別できます。 これはセキュリティ、プライバシーの観点で懸念があります。 この懸念を解消するため、いくつかのIPv6アドレスの自動設定技術は定期的にインタフェース識別子を変更します。 たとえばRFC8981で定義されるTeporary IPv6アドレスは1日程度でIPv6アドレスを変更します。

クライアントがIPv6シングルスタックでサーバがIPv4のみ対応の場合

「IPv4通信の場合」があえて詳細に分析されずわずか2文で終わったことに違和感を感じた方は鋭いです。

伝統的なケースです。

大嘘です。 IPv6アドレスしか持っていない端末がIPv4アドレスしか持っていないサーバに接続したくても、直接はできません。 だれかが間を取り持つ必要があります。 ドコモ社の資料の図にもあるとおり、このケースでは交換局が端末のIPv6アドレスからIPv4アドレスに変換します。 サーバと交換局の間はIPv4通信、交換局と端末の間はIPv6通信になります。 IPv4アドレスを収集しているサーバは、端末のIPアドレスのつもりで交換局のIPアドレスを掴まされています。

実際に交換局がどの程度の数のIPv4アドレスを利用するのかわかりませんが、IPv6アドレスと同数ではありえないでしょう。 交換局はNAT的に動作していると仮定するのが自然です。 IPv6シングルスタッククライアントが多数いる状況では多くのネットワーク技術に詳しくないエンドユーザが交換局のIPv4アドレスでアクセスしてくる状況が生まれます。

従来もエンドユーザがプロキシサーバやVPNを利用していて、サーバの受け取るIPv4アドレスがエンドユーザ自身のIPアドレスでないケースはありました。 しかしその率は無視できるほど低く、エンドユーザ側もなんらかの意図があって利用していたと考えられます。

この状況で従来型のIPv4アドレス分析をすると多数の一般的なエンドユーザに対して偽陽性を発生させるでしょう。 同一拠点判定で利用停止を実施しているならば、実際には全く関係のない多数のユーザが同一拠点からのアクセスとされ、一斉に利用停止されてしまいます。 これが本稿で取り上げる最大のリスクです。

対策

以上のリスクに対する対策を考えましょう。 まず「クライアントがIPv6シングルスタックでサーバがIPv4のみ対応の場合」ですが、サーバがIPv6に対応するか、IPv4アドレスの一致判定を止めるしかありません。 ドコモ社が利用しているIPv4帯を確認してそれだけ無視リストに登録するといった運用も考えられますが、今後IPv6シングルスタック通信を提供する通信事業者が増えることを想定すると無益な努力でしょう。

IPアドレスによる判定を止める、あるいは重要度を落とすのは価値ある判断です。 サービスプロバイダはIPアドレスの扱いにおいてもプライバシーを尊重するべきです。 非技術者のなかにはIPアドレスを住所と同じように本人や所在地を同定できる情報だと信じている人もいます。 この信念はIPv4アドレスのみ取っても大きな間違いであり、IPv6の普及に伴ってますます信頼性が揺いでいます。 IPv6シングルスタックの導入は信頼性が十分でない中でIPアドレスの分析がビジネス的価値を生むのか問い直す良い機会です。

IPアドレスの利用を続けるならば、サーバをIPv6/IPv4デュアルスタックに変更し、かつIPアドレス処理の仕組みをIPv6/IPv4両対応させましょう。 kippでは全てのサービスにALBを利用しています。 ALBは設定変更でデュアルスタックにできます。

「IPv6通信の場合」の分析から、IPv6アドレスを取り扱う際に保存と比較に注意する必要があるとわかります。 値の長さだけでなく、比較方法に依存して値の保存方法を考慮すべき点にも注意しましょう。 たとえば先頭64ビットだけ比較すると決めたら、その比較をデータベース上で効率よく実施できる保存方式を採用します。 極端な例ですが、IPv6アドレス全体のハッシュ値を保存していた場合、検索不可能になります。 文字列表現で保存して前方一致検索するのか、数値表現で保存して数値の範囲で検索するのか、保存時に先頭64ビットを切り取って別カラムに保存するのか、データベース製品の特性を調査し決定します。

同一拠点のチェックのためIPv4アドレスが同一であるという推定を使っていたならば概ね先頭64ビットが同一であるという比較に置き換えてよいでしょう。 その上で過去にIPv4アドレスチェックで偽陽性が頻発していたならばIPv6の特性を生かし条件を調整する余地もあります。

すべての対応を実施してもなお、IPアドレスによる所在地や同一性の判定は不確実性のあるものです。 ビジネス設計全体にこの不確実性を織り込むべきです。 たとえばIPアドレスだけを根拠にアカウントを停止するのは悪手です。 決済行動やアクセスタイミングなど複数の情報ソースを参照し、重み付けして判断しましょう。

不正判定はどうしても偽陽性を生むことがあります。 ユーザの行動を制限する前にサービス運営者が判定結果をチェックしたり、ユーザに確認のメッセージを送るのも重要です。 ユーザからの異議があった場合はユーザの虚偽を警戒しつつ、システムの誤判定や実装ミスも考慮して誠実に対応すべきです。

kippでは業界や世間の動向に素早く反応してサービスを改善するため、開発者の採用を強化しています。 また不正利用判定のような多くのログ、属性情報を組み合わせて信頼性の高い判断を下すデータ分析も改善を計画しています。 このような業務に興味をお持ちの方はお気軽にpeople@kipp-corp.comまでご連絡ください。

Service Level Objective (SLO)と監視

GCPのドキュメントでも述べられているように、SaaSの健全な発達にはSLOの策定が肝要です。SLOはService Level Indicator (SLI)と、その目標値で設定されます。

SLIはサービス全体のなかからサービスの継続にクリティカルな要素を洗い出し、その要素について測定可能な項目をピックアップする形で決定しました。例えば「正常に」といった定性的な要求は測定できないので、「内部エラーでない応答の数とリクエスト数の比率」といった定量的な指標に置き換えます。たくさんの値がSLIの候補になりますが、たくさんの値を精緻に追跡するのは負担が大きいので重要な値を絞り込みます。実際にkippで採用しているものの中にはAPIの処理成功率、日次のバッチ処理の終了時刻などがあります。

それぞれのSLIに対し閾値を定め、SLOを策定します。 閾値はサービスの性質上達成されなければならない目標と、一般的に要求される水準、そしてインフラ技術が提供する水準を考慮しました。 サービスの性質を考慮すべき代表的な例はバッチ処理です。 たとえば9時から始まるバッチ処理があり、次の社外の処理が12時に予定されていれば、3時間で必ず終了しなければなりません。 この場合、修正・復旧・リトライの時間を考慮し10:10までに終了することをSLOとします。 一般的な水準としては経済産業省のSaaS向けSLAガイドラインを参照しました。 顧客企業に開示や説明を求められたとき、客観的な妥当性のあるソースを示すことを重視しました。 最後に上限としてインフラ技術のSLAを確認しました。 例えばAWS FargateのSLAはmonthly uptime 99.99%ですので、これより厳しい目標を保証するのは困難です。 各SLIに影響する要素技術を確認し、当社の閾値がそれらの最低値に収まるよう考慮しました。

ログ監視と外形監視

SLOに沿って監視システムを構築しました。 社内ではSRE業務のノウハウが不足しており、作業に使える時間も不十分だったため、X-Tech 5さんにご協力いただきました。 過敏すぎるPagerDutyが設定されていただけの状態からDatadogの導入を経て信頼性が高く誤報の少ない体制をわずか数週間で構築していただきました。 アラート頻度が減ると同時に問題があったときの調査スピードも改善できました。

X-Tech 5のメンバーの方との相談で、できるところから開始し、改善していこうという方針を確認しました。 最初、監視対象はログとCloudWatchなどのモニタリングを中心にしました。 これらは予め準備されていたので低コストでスタートでき、またデータ量が豊富なため除外設定など細かい調整が容易なためです。

それからALBの障害など、サーバアプリケーションが原因となる障害ではないが顧客企業に報告するため把握する必要のあるものを追加していきました。 このような障害ではリクエストがサーバに到達しないため、ログを分析しても現象を発見できません。 そこで外形監視を導入することになりました。

外形監視とはシンプルにはネットワーク外からサービスにアクセスするだけのことですから、別系統のサーバでCron jobを回す程度のことでも達成できます。 しかし運用の観点では結果の確認や監視システムとの統合の利便性のほうが重視されます。 この時もX-Tech 5さんにアドバイスを仰ぎ、CloudWatch Syntheticsを紹介していただきました。 Canary Scriptとして設定したJavaScriptを定期的に実行し結果を収集できます。

gRPC APIをCanaryで監視する

CanaryはPuppeteer環境を持ち、画面キャプチャを撮れるなどウェブサービスの監視用の機能が充実したサービスです。 APIの監視にも利用できます。 しかし私達の監視したいAPIはgRPCであり、通常のhttps APIのテンプレートは利用できませんでした。 gRPCはhttp/2.0を要求するため、Node.jsでhttp/2.0とgRPCプロトコルに向けた監視スクリプトを記述しました。

まずGRPC Health Checking Protocolで定められたgrpc.health.v1.Health/Checkに向けてリクエストを送ることにしました。 このgRPC API MethodはRDBMSなどバックエンドの接続性も考慮してAPIが正常に利用可能か応答するように実装してありました。 簡単のため、リクエストパラメタのserviceは無視し、ステータスコードが200のとき正常と定めました。

Canary Scriptではhttps/2.0でgRPCの空メッセージをgrpc.health.v1.Health/Checkに送信し、レスポンスの:statusを確認すれば十分です。 gRPCのライブラリを導入する手間が省けます。

実際にCanary Scriptで上述の処理を記述するとこのようになります。 少し変わっているのは\0\0\0\0\0の部分です。これはgRPCプロトコルに沿って空メッセージをエンコードしたバイト列です。 少しhackyですが、簡単なものならばプロトコルに沿ったエンコード・デコード処理を静的バイト列や標準ライブラリによって実装することで1ファイルに収められます。

var synthetics = require("Synthetics");
const log = require("SyntheticsLogger");
const http2 = require("http2");
const syntheticsConfiguration = synthetics.getConfiguration();

function sendGrpcHealthCheckRequest(server) {
  return new Promise((resolve, reject) => {
    const client = http2.connect(server);
    client.on("error", (err) => {
      synthetics.addExecutionError("http2 error", err);
      reject(err);
    });

    // No compress (0u8) + Length 0 (0u32)
    const buffer = new Buffer("\0\0\0\0\0");

    const req = client.request({
      ":scheme": "https",
      ":path": "/grpc.health.v1.Health/Check",
      ":method": "POST",
      "content-type": "application/grpc+proto",
      "content-length": buffer.length,
    });

    let resHeader = null;
    req.on("response", (headers, flags) => {
      resHeader = [headers, flags];
      log.info(`Res flags:${flags}`);
      for (const name in headers) {
        log.info(`${name}: ${headers[name]}`);
      }
      if (headers[":status"] !== 200) {
        synthetics.addExecutionError("Response status is not 200");
        reject();
      }
    });

    let res = "";
    req.on("data", (chunk) => {
      res += chunk;
    });
    req.on("end", () => {
      log.info(res);
      resHeader.push(res);
      resolve(resHeader);
    });

    req.setEncoding("utf8");
    req.write(buffer);
    req.end();
  });
}

const apiCanaryBlueprint = async function () {
  const server = "https://example.com:443"; // server url

  syntheticsConfiguration.setConfig({
    restrictedHeaders: [],
    restrictedUrlParameters: [],
  });

  await synthetics.executeStep(`Verify ${server}`, async () => {
    return await sendGrpcHealthCheckRequest(server);
  });
};

exports.handler = async () => {
  return await apiCanaryBlueprint();
};

導入の結果

FargateやALBのSLAを考えれば半ば当たり前ですが、外形監視で問題が発見されることはほぼありません。 現在のところ監視スクリプトの設定ミス以外で問題が報告された事例はないです。 しかしアプリケーションログ、ALBのメトリクス、Canaryと複数段階で監視を持つことで障害時の切り分けが半自動的に出来るようになり、お客様に影響しうる事態を最も早く把握できるという自信が付きました。 「備えあれば憂いなし」のとおり、ひとつひとつの準備がいざという時の問題解決を簡単にします。 今後も監視を拡充し、高品質なBaaSを提供しながら枕を高くして眠れる体制を維持していきます。 kippではSRE分野に強味を持つ方も募集しています。 最強の体制の維持に興味をお持ちの方はpeople@kipp-corp.comまでお気軽にご連絡ください。

チームの構成

エンジニアリングチームは正社員、個人の業務委託の方々、業務委託の外部会社の方々で構成されています。 正社員は冨田を含め3名で、開発から運用まで全体をまんべんなく担当します。 社内外からの要望を聞き、本番環境をモニタリングして改善していくことがメインミッションです。

個人の業務委託の方々がさらに4名おり、こちらはScalaで実装された中核システムの開発を専門的に行います。 Scala技術者ですぐに正社員採用できる方は少ないですが、業務委託であればお願いできる方がいらっしゃいます。 技術に対する高い専門性を生かし、ハイペースでアイディアを実装に変えていく役割をお願いしています。

外部の会社の方々は社内で手のまわらない専門知識を要する分野をお手伝いいただいています。 現時点ではスマートフォンアプリケーション開発やインフラ構築のサポート、オンコールの一次請けをお願いしています。 会社で直接採用しにくい分野、人数が必要な分野で実績のあるチームのサポートを得ることが目的です。

本記事でお話するエンジニアリングチームは外部会社の方を除いた、正社員と個人の業務委託の方々のチームです。

チームコンセプト

エンジニアリングチームが目指している状態は次のようなものです。

• 責任が明確である
• コミュニケーションが明確である
• 自由である

責任が明確であるとは、個人に期待される職責が明文化されていて、理解されている状態です。 例としてオンコール制度を見てみましょう。 正社員はローテーションでオンコール担当になります。 オンコール担当中は電話を受けられるようにしておいて、インシデントが発生したらドキュメントを確認しつつ解決にあたります。

kippが大事にしているのはこのような責任を文書化し、全員に理解してもらうことです。 「オンコールを担当してください」とだけ言われても何をしたらいいかわかりませんね。 周囲の振舞から見よう見まねでキャッチアップすると時間がかかりますし、「あいつはやるべきことをやらない」など軋轢が生じかねません。 人によってやりかたが違って作業が矛盾し、トラブルになることもあります。 「ここに書いてあることをお願いします」と差し出せる文書を維持するよう努力しています。 べき・べからずに留まらず、具体的な手順、よくある問題なども載せ、手引きになるよう充実させています。

コミュニケーションが明確であるとは、相手の前提知識や暗黙の了解を当てにせず、一箇所を読めば主張が分かる状態です。 この価値が特に重要なのはタスクを依頼する時です。 概念の呼び名がまちまちだったり、タスクの説明に書いていない前提があると実装者は要求を正しく理解できません。 間違った理解にもとづいて作業した結果、実装を大幅に書き直さなければいけないという悲劇が何度もありました。 要求の文書やタスクの説明もレビューし、齟齬や言及不足、考慮不足を最も早い段階で直しています。

相談するときも何をしようとしていて、どのような方針を立てたかが明快だとすみやかに回答できます。 背景知識やプロダクトの状況、依頼者の思いから、適切な名詞、動詞の利用まで、内容のすべての層に注意を行きわたらせるようにしています。 さらにシステムの仕組みやプロダクトコンセプトをまとめた資料を作り、共通言語のプリセットとしています。 この資料はGoogle Driveに保存されているので、伝達内容のわからない部分はDriveで調べられます。

このやりかたはコミュニケーションが「硬い」ものになり、気軽な発話を阻害する面があります。 しっかり書こうと思って一人で長時間悩んでしまっては時間がもったいないですね。 そこでSlackのチャットは気軽な相談をする場として、思ったことを何でも、どこでも書けます。 社内外の最新状況をさっと書き出すヘッドライン的な場として効果を発揮しています。

それでもどれくらいのことまで書いていいか不安だったり、人のいるところで発言するのは恥ずかしかったりします。 そこで一部のメンバーはtimesチャンネル（個人の名前のついたチャンネル）を作っています。 timesではより発言の敷居が下るので、やってること、思ってること、気になったことが集まりやすくなります。 ちょっとしたぼやきからリファクタリングやルールの改善が生まれることもよくあります。 Slackを柔らかな空間に保つため、反対に依頼や合意はSlackで終わりにせず、文書にして残します。

コミュニケーションが明確であることの効果は意思伝達がしやすいに留まりません。 依頼の例では、依頼の文書が自己完結してコンパクトであることで、そこだけ読めば最近の議論、ビジネス動向などを理解していなくても作業できます。 フルタイムではない業務委託の方が週末だけ作業する場合でもタスクとコードを読めば実装を進められます。 すなわち属人化を防ぐとともに協力していただける方を増やしやすくなります。 新しく実装される部分が方針を理解して作られているのでチグハグになりにくいです。 次の実装がやりやすく、その次も、と長い期間を通して効率を維持できます。

最後の自由とは、責任の裏返しです。 責任とコミュニケーションが明確だとやるべきことが明確になります。 反対に、それ以外はやらなくていいとわかります。 他チームはやや状況が違いますが、エンジニアリングチームは正社員でも休みを自由に調整できます。 オンコール担当の時は連絡のつくようにするというルールがありますが、それ以外はどこにいてもかまいません。 真っ昼間からゲーセンに行くのも、唐突に箱根の温泉に浸かるのも、北海道で夏を満喫するのも自由です。 昼まで寝ている人も早朝から作業する人もいます。 土日に休みたい人も土日は仕事したい人もいます。 エンジニアリングチームはメンバーの自由意志を最大限許容することで多様な個性を認めようとしています。

あくまで職場での自由なので、恣意的な制限がついていることを気にとめておく必要があります。 たとえばテキストコミュニケーションをしない自由はありません。 なかにはテキストより口頭、対面の会話が得意な人もいます。 口頭のコミュニケーションを中心に構築されたチームがテキストコミュニケーションに劣らないことも知っています。 しかしチームはテキストコミュニケーションを中心に構築され、それを好むメンバーが集まっています。 全員の合意で方針を変えることはありますが、主張がかならず通るものではありません。 採用でもその時点のやり方に馴染むか確認する必要があります。

自由とはだらけている、いいかげんであるとは真逆の状態です。 オンコールやタスクを処理することは明確な責任です。 周囲との関係を保つなど、会社の一員として果たすべき義務もあります。 おたがいに責任を果たすという信頼があるから、それ以外の部分で一切の束縛をする必要がないのです。 自分を律する面でも社内外から信頼されつづける面でも、自由でありつづけることは非常に困難です。 週5日出勤して、その場でいわれたとおりにするほうがよっぽど楽でしょう。 後で怠けるために自動化を頑張るプログラマと、自由を得るために成果を出すチームはどこか類似を感じます。 エンジニアリングチームはこれからも自由であるために努力を続けます。

チームの維持

少しヒートアップしてしまいました。 地に足をつけて、以上のチームコンセプトを実現するための具体的な手段をお話します。 まずコンセプトの実装として、チーム維持のためにやっていることを説明します。 維持とは、チームをよい状態に保ち、業務しやすく改善していくことです。 それからチームメンバーを増やすための採用に触れます。

チームの維持に重要なのは意見を聞いて改善することです。 チームコンセプトの実現には様々なアプローチがあります。 長い時間の果てコンセプト自体がメンバーの希望と相反してくる恐れもあります。 今のやり方が適切か確認する場が必要です。

メンバーやビジネス状況や世相に対応するポイントとして、ふたつのミーティングを持っています。 ひとつは各チームリーダーが集まり、ビジネス状況をもとにエンジニアリングの方針とスケジュールを議論する場です。 隔週で行っています。 もうひとつはエンジニアリングチーム内での月1回の1on1です。 これらの場で細かいタスクの話から心情の話、大方針まで直接議論し、アップデートの原動力としています。

メンバーを不要に拘束しないよう、ミーティングは最低限にすることを心がけています。 議題がないのになんとなく集まる、大人数で集まって発言するのはごく数人というミーティングは無駄が多いです。 同期的なミーティングはその時間だけでなく前後の時間の自由も奪います。 この前提の上で最低限これらのミーティングはやるべきと考え、スタイルを見直しつつ行っています。

ビデオチャットでの1on1を開始したのは比較的最近で、今年の前半だったと記憶しています。 それまでは「なにかあったら言ってください」のスタイルで、意見を言う権利はありましたが機会はありませんでした。 「なにかあったら」のスタイルで意見を言える人もいますが言えない人も多いです。 わかったときには既に禍根となってしまっていたこともありました。

定期的な機会をつくることで相互理解が深まることを期待し設けました。 全体会議など人数の多い場にしてしまうとどうしても長くいるメンバー、今ホットな領域を担当しているメンバーに発言が集中します。 一対一の場にすることで気楽に話せると期待しています。 実際に私が見えていなかった課題を指摘してもらえています。 ひとつひとつは小さな問題でも、頻繁に同期することで大きな改善につながると信じています。

直接の改善からは少しずれますが、ときおり全体アイスブレイクを実施しています。 リモートワークが主体でミーティングの回数が少ないので他のメンバーと話す機会がほとんどありません。 自己紹介やレクリエーションを取り入れ、時間を一緒に過ごすことをテーマにしています。

チーム維持のためにもうひとつ重視しているのは文書化です。 完璧には程遠いものの、文書の品質を維持しつづける強い意志を持っています。 高速にシステムを改善しつづけるには良いコードと良い文書が両輪となります。 コミュニケーションをスムーズにするにも、責任を明確にするにも文書が基本の武器になります。

私自身とても忘れっぽいので、なんでも書いておかないと忘れてしまいます。 また何度も同じことを説明するのが嫌でもあります。 何度も聞かれるのはウェルカムですが、毎回説明するのが面倒です。 やったこと、考えたこと、伝えたいことはなんでもメモして、繰り返し参照されるものをたびたび更新しています。 よいドキュメントを作るぞと意気込んでとりかかると道半ばで挫折してしまいます。 とりあえずその時の用に足りるものをつくってすこしずつ手直ししていく感覚は内製ツールに似ていますね。

チームコンセプトのみっつめの要素、自由のための取り組みは難しいです。 これをしていれば自由になります、などという黄金律はありません。 思考停止は自分で自分を拘束している点で最大の不自由です。

私が気をかけているのは自分自身が満足して働ける環境であるか反省することと、メンバーにあなたは自由だと伝えることです。 人は他人の感情がわかりません。 リモートワークであればなおさらです。 自分については自分自身で反省し改善のきっかけを探せます。 しかし他のメンバーを見ていても不自由に感じているかわかりません。 それどころか、本人は仕方のないものと受容してしまっている恐れがあります。 「あなたは自由です」と伝えることで、こういう働き方はどうかな、これちょっと嫌だなと思いつくことが少しでも増えるのではないでしょうか。

しない自由と同じだけする自由にも注意を払っています。 例えばリモートワークの自由と同時に出社の自由があります。 オフィスはアクセスのよい大手町のFINOLABに入っています。 フリーコーヒーもあり快適に作業できる環境です。 しかし現在は外出するだけでも健康リスクがある状態なので自由を制限し、出社を必要最低限にするようお願いしています。

採用の考え方

会社の発展にともなってチームを拡大していくためには採用が必須です。 構成の部分で述べたとおり、正社員と業務委託はメインミッションが違います。 業務委託は補助ということは一切なく、どちらも同じウェイトで、違う価値観で採用しています。 ここでは正社員と業務委託に分けて採用のときに見ているポイントを紹介します。

正社員に求めるのは広範な知識と長期間にわたってシステムを改善する熱意です。 コンピュータサイエンスの基礎知識に加え、とくにkippの業務分野で重要なネットワーク、セキュリティ、RDBMS、パフォーマンス改善の知識が必要です。 じつはScalaが書けるかどうかは重視していません。 コンピュータサイエンスの知識にはプログラミング言語の仕組みや型理論、バーチャルマシンの理解も含まれます。 知識があれば文法を覚えるだけですぐにScalaを書けますから、ジョインしてから本を読めばよいです。 実際、kipp勤務以前にScalaの経験がなかったメンバーの方が多いです。

システムを改善する熱意はできるだけ長期間携わってほしい意図を反映したものです。 熱意というと大袈裟ですね。 なげやりにコードを積み重ねるのではなく、作業しやすい環境を維持する気持ちを持っていてほしいです。 具体的には使いづらい部分をリファクタリングしたりツールを作ることを期待しています。

業務委託の方々には反対に即戦力として働けることを求めます。 Scalaの業務経験がなくても、ライブラリも含めて一通り理解していて独力でコードを書ける必要があります。 タスクの説明とコードを読んで自力で業務を進めていくため、一定の問題解決能力も求められます。

性格や人物像の面では共通して責任感があり、実直であることを求めています。 金融システムの性質上、必ず踏まねばならない手順がいろんな面であります。 間違いや問題が発生した場合の報告手順も定められています。 手順をないがしろにしたり、間違いをもみ消すようなことがあると会社の存続に関わりうるので注意しています。 事業内容はBtoBtoCの性質が強いので、関係パートナーとの信頼を育むため確実に作業を完遂するのも重要な資質です。

よりよいチームに向けて

今回はkippエンジニアリングチームをいろんな側面から紹介しました。 スタートアップ企業は事業も手探りですがチーム構築も手探りでした。 チームビルディングや運用については様々な情報が発信されていますが、5人程度の小さいチームについて述べているものは少ないようです。 人数が少ないと一人一人の個性による振れ幅が大きすぎて、なにも画一的なことが言えないからでしょう。

この記事の内容もそっくりそのままやって上手くいくものでは決してありません。 むしろかなり特殊な事例でしょう。 すこしでもお読みになった方の参考になる部分があれば幸いです。

自分自身、人と話したり仲良くなるのは苦手です。 かなり苦手です。 しかし苦手だからこそよりよくしたいと思い、なあなあにせず改善の意志を持ちつづけられていると感じます。 ここで書いたことは通過点であり、毎月毎年変わっていくでしょう。 組織が良くなっていけるもっとも幸せな契機は新しいメンバーが加わることです。 このような組織で一緒に働いてみたいと思った方はぜひpeople@kipp-corp.comまでご連絡ください。

データ投入の課題

今回のテーマであるテストデータとは本番同等構成でアプリケーションを検証するときに必要なものを指します。 このような環境はステージング環境、開発環境、試験環境などと呼ばれます。 当ブログでは社内の呼び方にあわせて開発環境（dev環境）とします。

開発環境は本番同等構成なので原則スマートフォンアプリやウェブサイトの操作をおこなってデータを準備するルールにしています。 しかし遠い過去のデータが欲しい、大量のデータが欲しい、SMS番号など外部リソースに依存する部分を迂回したいなど、ルールどおりにできないケースがあります。 このため開発環境にはデータ投入用のスクリプトを用意することが多いです。

データ投入用のスクリプトはSQLなどデータ永続化層の操作言語か、アプリケーションの実装言語で書くのが一般的です。 kippでも一番最初は開発者が開発環境のみMySQLに直接ログインできるよう構成し、手書きのSQLを実行していました。 この方法は属人的で誤操作のリスクが高いのみならず、行暗号化されるテーブルのデータを用意できない欠点がありました。 そこでScalaスクリプトを受け取りサーバ上で実行する仕組みを用意しました。 開発者はデータを用意したり更新するスクリプトを準備し、リモート実行コマンドを呼び出すことでサーバ上のデータを自由に改変できます。 スクリプトをテスト、レビュー、共有することで最低限のエコシステムが出来ました。 しかしスクリプトはアプリケーションコードと同じコードベースを使って実行するので、十分な知識が必要です。 スクリプトがIDEを使ってかけない点も開発体験が悪く、あまり使われませんでした。

あらためてすべてのチームに聞き取りを行いニーズと問題点を整理しました。

• データ更新の要望は少なく、ほとんどが追加である。追加だけできれば90%以上の要求に応えられる
• パートナーによるテスト期間内にあたらしいデータが必要になることも多く、すばやく対応してほしい
• Scalaスクリプトは書きにくくSQLで無理やり作業している。SQLで対応できないものは発生しないよう回避している。結果パートナーとの軋轢が生まれる
• パートナーから渡される要望が曖昧で開発者には理解できない。意思疎通のための時間がかかる
• テスト期間はこまかい単位で何度も依頼が来て開発者の集中が妨げられる

プロセスの制度化

以上の課題を解決するため、まず投入のプロセスを制度化しました。 ルールとマニュアルを作成すれば属人性を排除でき、自動化も容易になります。 投入で重要なのはデータフォーマットです。 自然言語でニーズを表明されると、意味を解釈しデータを作成するという二段階が余計に挟まります。 時間がかかりミスも起きやすいです。 そこで最初から作成したいデータの全体を指定し、テキストファイルで受け渡すようにしました。

データといっても、ほとんどただのScalaファイルです。 次のような構造体を想定します。

type UserId = String
type CardId = String

final case class User(
  // Userの識別子
  userId: UserId,
  // 登録日時
  createdMs: Long,
  // 暗号化済み個人情報
  encryptedPersonalData: EncryptedMessage[PersonalData],
)

// 個人情報、要行単位暗号化
final case class PersonalData(
  // Userの氏名
  name: String
)

このとき投入データは次のようになります。 操作したいテーブルとファイル名は対応づけ、user.txtとするルールです。

User(userId = "XXX", createdMs = 1626663292000, personalData = PersonalData(name = "Yamada"))
User(userId = "YYY", createdMs = 1626663292000, personalData = PersonalData(name = "Sato"))

ご覧のとおりただのScalaファイルです。 EncryptedMessageなど内部的な仕組みは隠蔽し、GraphQLの構造に近づけています。 この形式ならGraphQLやサンプルファイルを見ながらデータ作成できるだろうと算段しました。 大量に連番のデータを作りたいときは表計算ソフトでデータテーブルを作成し文字列結合してテキストを準備できます。 開発者は具体的なデータで受け取るので、コピペしてすこし整形するだけでスクリプト化できます。

Soymilkの開発

フォーマットを決めたことで開発者の作業は簡単になり、自動化もできそうに思えました。 書き換えやAWSコマンドの実行を自動化し開発環境を不要にすればパートナーとコミュニケーションしている支援チームが作業できます。 この自動化をScalaで実装し、fat-jar形式で社内に配布しました。 社内で愛されるように、投入と豆乳をかけてSoymilkと名前をつけ、アイコンも作りました。

Soymilkを利用すると次の1コマンドでデータフォーマットの確認、スクリプトの生成、AWS ECS上での実行が完了します。

java -jar soymilk.jar user.txt

Soymilkはデータを受け取りサーバに準備されたコマンドが解釈できるスクリプトに変換する部分、AWS ECS APIを呼び出す部分の2つで構成されます。 前者はScalametaを利用します。 上の例のように、入力ファイルは1行ずつ見れば文法レベルで正しいScala式ですが、型は合っていません。 また一行ずつはただの式で、それをまとめる構造がないのでファイル全体が正しいScalaファイルではありません。 便宜的にobjectで包んだものを構文解析（parse）し、型を利用せず名前にもとづいたパターンマッチで整形します。

s"object X {$lines}".parse[Source] match {
  case src: Parsed.Success[Source] =>
    src
      .get
      .collect { case q"object X { ..$stats }" =>
        val inserts = stats.zipWithIndex.collect { case (s: Term, i) =>
          val msg = s"Insert $fileName $i-th record"
          val adjusted = wrapEncryptedFields(s)
          Seq(
            q"println($msg)",
            q"Await.result(db.run(tables.${Term.Name(fileName)} += $adjusted), Duration.Inf)",
          )
        }
        inserts.flatten
      }
      .flatten
  case err: Parsed.Error =>
    error(s"Cannot parse $path, Check file format is correct. $err")
}

ECS APIの呼び出しはAWS SDK for Javaを用います。 ECS Taskを実行するには様々なパラメータを指定しますが、すでに動いているタスクから取得するなどして隠蔽しています。 aws-cliのインストールなどを排し、Java実行環境だけあれば作業できるようにしました。 AWS credentialsのセットアップやコマンドの利用方法は社内ドキュメントに事例つきでまとめています。

効果

フォーマットの策定は効果的で、当初の課題はすべて解決できました。 開発者は一切作業しなくてよくなり、新規開発に集中できます。 要求へのレスポンスが大幅に改善し、投入できるかどうかの不自然な制約がなくなり、パートナーとのやりとりが円滑になりました。 たしかに投入したいデータを作成する人の負担は増えていますが、データの決定はテスト設計でなされるので元来必要なものを整形するのみです。 頻繁に利用されるテーブルにはSpreadsheetのテンプレートを用意し穴埋めで投入データが作れる仕組みも用意しました。 ミスや不整合があるときもこの行のこの部分と具体的に会話できます。

より高い視点では技術の民主化を推し進められた成果がありました。 データを書き下すのは煩雑にも見えますが、支援チームのデータ構造への理解が深まる効果をもたらしました。 だれでも、いつでも作業できるようにドキュメントを整備する意識も向上しました。 これらの効果はデータ投入だけでなく他の業務も効率化し、短時間で楽しく作業できるようになりました。

今後改善すべき点はテーブルをまたいだ整合性の問題です。 たとえば取引を通知するには取引テーブル、通知全体のテーブル、通知と通知先（メール、プッシュなど）を関連づけるテーブルの3つにデータが必要です。 サービスを企画する視点では取引テーブルに注意が集中し、他のテーブルを忘れがちです。 一方で大量に取引を追加するためにいちいち通知を送信したくない場合もあります。 さらにこのような複数のテーブルで一連の事象を表すケースは多数あり、ひとつずつルール化するには相当な手間がかかります。 現在はファイルを受け取った時に意思確認をしていますが、ゆくゆくは徐々にプログラムでカバーしたいです。

Kippでは他にも業務効率化、コミュニケーション効率化に取り組んでいます。 ルールの策定とScalaやRustを利用した自動化で楽しく円滑に働ける環境を目指しています。 そんな環境で働いてみたい、環境をつくってみたいという開発者の方はお気軽にpeople@kipp-corp.comまでご連絡ください。

スタートアップ企業は限られたリソースで高度なアプリケーションの開発を求められるのが常です。 Kippは社全体で少人数精鋭チームを目指しています。 開発チームでは生産性が高い技術を採用し、社内でより発展させてこの目標にアプローチしています。 今回のブログ記事ではその実例としてGraphQLサーバの構築事例を紹介します。

GraphQLの立ち位置

前回の記事でも紹介しましたが、GraphQLは管理用のデータベースアクセスインタフェースを担います。 社内で利用する管理用なので細かなアクセス権限管理が不要、ほぼすべてのデータを参照できる必要があるという特徴があります。 現時点でAurora MySQLには300程度のテーブルがあります。 GraphQLを通じてこの8割程度を参照できます。

200を超えるテーブルへのアクセスインタフェースを提供するのは気が遠くなる作業です。 PrismaなどRDBのスキーマから自動的にGraphQLサーバを運用するような仕組みも検討しました。 しかし複合主キーを持つテーブルがある、独自の行暗号化を行うテーブルがあるなどの理由で利用できませんでした。

そこでScala上でGraphQLサーバを構築することを考えました。 サーバ全体の実装にScalaを使っているため、DBアクセス、暗号レコード処理などで既存コードを再利用できる利点があります。 他方ScalaにはPrismaのようなワンストップフレームワークはありませんでした。 検索したなかでモデルが理解しやすかったSangriaを使って独自に構築することになりました。

GraphQL Schemaの要素と組み立て方

実際にkippのモデルのサブセットを使い、SangriaでGraphQLサーバを提供する方法を確認しましょう。 まず今後のコード例で利用するモデルを定義します。 実際にkippで使っているコードの一部を抽出して次のようなモデルを考えましょう。

type UserId = String
type CardId = String

final case class User(
  // Userの識別子
  userId: UserId,
  // 登録日時
  createdMs: Long,
  // 暗号化済み個人情報
  encryptedPersonalData: EncryptedMessage[PersonalData],
)

// 個人情報、要行単位暗号化
final case class PersonalData(
  // Userの氏名
  name: String
)

final case class PrepaidCard(
  // PrepaidCardの識別子、Primary key
  cardId: CardId,
  // PrepaidCardが属するUserのID
  userId: String,
  // 作成日時
  createdMs: Long,
  // PrepaidCardに割り当てらたPANの下4桁
  last4: String,
)

Userは複数枚のPrepaidCardを持てます。 kippのサービスで同時に有効なカードは1ユーザ1枚ですが、再発行やカード種類の変更の際には複数枚が関連づきます。 これらのモデルを取得するクエリは次のようになるでしょう。

{
  users {
    userId
    createdMs
    personalData {
      name
    }
    prepaidCards {
      cardId
      createdMs
      last4
    }
  }
  # PrepaidCardからUserを引くパターン
  prepaidCards {
    cardId
    last4
    user {
      personalData {
        name
      }
    }
  }
}

Sangriaでこのクエリを処理するために必要な部品を解説します。 まずusersとprepaidCardsのフィールド定義が必要です。 フィールド定義は次のようになります。

Field("userType",
  UserGraphQLType,
  resolve = ctx => ctx.ctx.db.run(ctx.ctx.tables.users.result))

resolveはcontextを用いてデータを取得する方法を定義します。 この処理はDBを読み出していると受け取ってください。 UserGraphQLTypeは上で定義したcase class UserをSangriaのObjectTypeに写像したものです。 Sangriaにあらかじめ実装されたマクロをつかって次のように定義できます。

implicit lazy val UserGraphQLType: ObjectType[Ctx, User] =
  macros.derive.deriveObjectType

Userの定義を再確認するとencryptedPersonalDataというフィールドを持っています。 しかし取得したいのは復号済みのpersonalDataです。 deriveObjectTypeを修飾しマクロにフィールドを置き換えるよう指示します。

implicit lazy val UserGraphQLType: ObjectType[Ctx, User] =
  macros.derive.deriveObjectType(
    ReplaceField("encryptedPersonalData",
      Field(
        name = "personalData",
        fieldType = OptionType(implicitly[OutputType[PersonalData]]),
        resolve = ((ctx: Context[Ctx, User]) =>
          ctx.value.decryptPersonalData(ctx.ctx.crypto)
        )))

このコードを動かすためにさらに2つ修正が必要です。 1つはPersonalDataのOutputTypeの宣言、もう1つはPersonalDataの復号の実装です。 Userと同様にPersonalDataにもderiveObjectTypeを利用します。 ObjectType is-a OutputTypeの関係があります。

implicit lazy val PersonalDataGraphQLType: ObjectType[Ctx, PersonalData] =
  macros.derive.deriveObjectType

復号のためUserにdecryptPersonalDataを追加します。 Cryptoは行レベル暗号を処理するモジュールです。 鍵などを持つでしょう。 decryptはEncryptedMessage[T] => Option[T]の型を持ちます。

final case class User(...) {
  def decryptPersonalData(crypto: Crypto): Option[PersonalData] =
    crypto.decrypt(encryptedPersonalData)
}

またUserGraphQLTypeの定義のなかのctx.ctx.cryptoはCtx型のcrypto: Cryptoフィールドを呼び出す処理です。 Ctx型はSchemaで出てくるresolveを実装するために必要なオブジェクトを持つ構造です。 cryptoのほかにデータベースへのアクセサなどを持つでしょう。 ここまでで以下のクエリが実行できるようになります。

{
  users {
    userId
    createdMs
    personalData {
      name
    }
  }
}

次にusersのなかでUserに関連づくPrepaidCardを取得できるようにしましょう。 SangriaはFetcherという仕組みを提供しています。

// オブジェクトとID (Primary key)の関係を定義
val relUserUserId =
  Relation[User, UserId]("User-userId", ((x: User) => Seq(x.userId)))
val relPrepaidCardUserId =
  Relation[PrepaidCard, UserId](
    "PrepaidCard-userId",
    ((x: PrepaidCard) => (x.userId)),
  )
implicit val hasIdPrepaidCard: HasId[PrepaidCard, CardId] =
  HasId[PrepaidCard, CardId]((x: PrepaidCard) => x.cardId)

// CardIdからPrepaidCardを取得するDB呼び出しを定義
val fetchPrepaidCard = ((ctx: Ctx, ids: Seq[CardId]) =>
  ctx.db.run(
    ctx.tables.prepaidCard.query.filter(x => x.cardId.inSet(ids)).result
  )
)
// UserIdからPrepaidCardを取得するDB呼び出しを定義
val fetcherPrepaidCardUserId = Fetcher.rel(
  fetchPrepaidCard,
  {(ctx: Ctx, arg: RelationIds[PrepaidCard]) =>
    val ids = arg(relPrepaidCardUserId)
    ctx.db.run(
      ctx.tables.prepaidCard.query.filter(x => x.userId.inSet(ids)).result
    )
  }
)

// User typeにprepaidCardsフィールドを追加
implicit lazy val UserGraphQLType: ObjectType[Ctx, User] =
  macros.derive.deriveObjectType(
    // 中略
    AddFields(Field(
      "prepaidCards",
      ListType(PrepaidCardGraphQLType),
      resolve = ((ctx) =>
        fetcherPrepaidCardUserId.deferRelSeq(relPrepaidCardUserId, ctx.value.userId)
      )
    ))
  )

PrepaidCardGraphQLTypeはUserGraphQLTypeとおなじようにderiveObjectTypeで定義します。 fetcherPrepaidCardUserId.deferRelSeqの部分「PrepaidCardにとってuserIdは関連先」であり「1：Nで関連づく」ことを定義しています。 関連先とはforeign key側のようなニュアンスです。 逆にUserにとってuserIdはprimary keyなので、deferを使います。 また1:0か1:1であればdeferRelOptを使います。 このように宣言しわけることでGraphQLのスキーマ型をより正確なものにでき、利用者によく意図が伝わります。

このように一部のモデルで試したところ、Sangriaはやりたい事に対して比較的記述量の多い印象でした。 Sangriaで欲しい機能が実現できると確認しましたが、200超のテーブルの定義を書き下すのは非現実的ともわかりました。 新しいサービス展開に伴ってテーブルが更新、追加されたときGraphQLのメンテナンスコストが開発者に重くのしかかると予想されました。

自動化=最適化

Sangriaがうまく活用できるだろうと見通しがたったところでGraphQLサーバ部分を自動的に構築する方法を検討しました。 私達は自動化=最適化というポリシーを持っています。 自動化は言語やライブラリを用途にカスタマイズし、作業内容を最適化する行為という意味です。 「早すぎる最適化は悪」と言われるように、早すぎる自動化も悪です。 上の例のようにSangriaを直接使ってみて、簡単なケースで期待どおりに動くことを確認しました。 この時作成したコードは自動コード生成を実装するときのサンプルにもなります。

自動化=最適化の観点から、自動化した部分のカプセル化を目指しました。 実行コードのパフォーマンス最適化の場合、ボトルネック箇所を特定し、ブラックボックスとして扱えるよう切り離して最適化すべきです。 自動コード生成においては手書きコードが生成されたコードの中身を気にするべきではありません。 簡単なインタフェースを用意し、グルーコードは一箇所に集中させて生成の知識を持たずに扱えるのが理想です。

Sangriaの仕組みはこの目標に適します。 スキーマ宣言はSchema[Ctx, Unit]という型で簡潔に表現されます。 手書きコードはSchema型のみを意識すればよく、自動生成コードはSchema型を返せば中身はなんでもよいです。 まず自動生成の入力の与え方を検討し、次にSchemaの自動生成方法を検討することにしました。

最小レベルの表現

SangriaはオブジェクトやIDの関係をすべて明示する必要があります。 明示する必要があるのはやむ無しとしても、繰り返しを排し、記述を簡略化したいと感じます。 そのため最低限必要な要素を整理しました。

1. GraphQLで参照したいテーブル
2. テーブルの主キー
3. テーブル同士の関連
4. 復号して返すべき項目

「1.GraphQLで参照したいテーブル」は明示的に宣言する必要があります。 一部のトークンなどを扱うテーブルは管理者であっても見えてはならないからです。

「2.テーブルの主キー」はテーブルの宣言を解析して取得できますが、明示的に宣言することにしました。 テーブル定義に使っているSlickライブラリがテーブル定義のメソッドのいずれかに主キーが宣言されているという解析しづらい構造だったためです。 「1.参照したいテーブル」を宣言する際にそのテーブルの主キーをあわせて与えればよいので、明示しても煩雑にならないと考えました。

以上の2つは次のように宣言します。 なおtablesはすべてのテーブル定義（SlickのTableQuery）を束ねた構造体です。

// userテーブルはクエリ可能。主キーはuserId
id(tables.user)(_.userId)

「3. テーブル同士の関連」も明示的に宣言することにしました。 Foreign keyをつかっていれば自動化も可能でした。 しかしデータ投入の都合や1つのテーブルが複数のテーブルに従属する構造があることからForeign keyは使わないコーディング規約としています。 関連を簡潔に定義する次の構文を考えました。

table(tables.user).key(_.userId).has(
  many(tables.prepaidCard)(_.userId),
)

fluent interfaceを意識したDSLになっています。 manyのほかにzeroOrOne、exactlyOneなどの関連が定義できます。

「4. 復号して返すべき項目」はConvention over Configurationでフィールド名に一貫性を持たせ、自動処理しました。 case classのencryptedXxxフィールドとdecryptXxxメソッドが定義されていたら前者のフィールドを後者のメソッド呼び出しで置換するというルールです。 結果的にEncryptedMessageの扱い全体が統一感あるものになり、コードの品質も良くなりました。

この表現ではさきほどの20行程度の記述がわずか3行で済むようになりました。

自動化

利用したい表現と出力したいコードがきまったら、その間の自動化を実装するだけです。 Scalaでコード生成する方法は複数あります。

1. マクロはもっとも基本的なAST変換方法です。コンパイル時に与えられた記述を別のASTに置き換えます。式の位置に立つので、クラスを定義できないなどの制約があります。生成されたコードを直接確認できないので大規模になるとデバッグがとてつもなく大変です。
2. マクロアノテーションは簡単に言うとクラスを定義できるマクロです。マクロがexpressionレベルで作用するのに対しマクロアノテーションは定義レベルで作用します。定義を書き換える性質上このマクロはtyper以前に実行されます。したがってこのマクロの中では型推論の恩恵が一切受けられません。上の例ではtables.userがUser型と関連するものだとわかりません。型パラメータや型注釈で明示する必要があります。これも大変な手間です。生成コードを確認できない点も同じです。
3. コンパイラプラグインはscalacに追加の処理ステップを設ける方法です。代表的な使用例はWartRemoverなどのlinterです。コンパイルされたすべてのASTを見られるので、ASTを見て新しくコードを作成する処理を実装できます。
4. Scalaファイルを扱うScalaプログラムを作ることもできます。Scalaファイルを構文解析し、別のScalaファイルを出力するプログラムを実装します。コンパイラプラグインはコンパイルフェイズのなかで実行されるのに対し独立の処理として実行されます。

今回は生成するコードの規模がとても大きいことから4の独立したプログラムの方法を採用しました。 すべて試したのですが、この方法がいちばんデバッグしやすく、ビルドに使っているsbtのキャッシュとも相性がよかったです。 sbtがマルチプロジェクト構成になっていて、メインのプロジェクトをビルドした後に自動生成のタスクが実行されます。 出力されたコードはgeneratedというサブプロジェクトのsrcとなり、自動生成後にsbtでビルドされます。 この構成では生成されたコードもsbtや最終的な成果物から見ればただのScalaコードなので、コンパイルエラーやデバッグ出力が読みやすいです。

ScalaはマクロをはじめASTの取り扱いに長けた言語です。 標準ライブラリにインタプリタ実装、AST、Quasi-quoteなど必要なツールセットがすべて組み込まれています。 すこしコツを掴めば簡単にAST変換で言語内DSLが実装できます。

まずScalaファイルを解析するためIMain (interpreter main)を作成します。 jarなどから実行する場合は単に作成するだけでよいのですが、sbtで実行する場合2つ余分に考えるべきことがあります。 1つはsbtがclass loaderをLayeredClassLoaderに差し替えており、単純に作成するとScalaの標準ライブラリが見つからないという妙な状態になります。 次にIMainにメインのプロジェクトの型解析をやらせるにはメインのプロジェクトをclasspathに追加する必要があります。 メインのプロジェクトはすでにビルド済みで.classが作成されていますから、sbtのdependencyを辿って出力先ディレクトリをclasspathに組み込みます。 LayeredClassLoaderの面倒をみつつ以上の目標を達成するコードはこのようになります。 このコードは試行錯誤して書いているので、不要な部分を含む恐れがあります。 また最後のところでtyperフェイズまで実行して止まるようにしています。 型のついたASTだけあれば十分だからです。

def makeInterpreter: IMain = {
  val settings = new Settings
  val matcher = "file:(.*?scala-library.*?\\.jar)".r.unanchored
  @tailrec
  def findPath(loader: ClassLoader): String = {
    val description = loader.toString
    description match {
      case matcher(path)
          if scala.util.Try(Files.exists(Paths.get(URI.create("file:" + path))))
            .toOption.getOrElse(false) =>
        path
      case _ => findPath(loader.getParent)
    }
  }
  def findClassPaths(cl: ClassLoader): Option[URLClassLoader] = {
    cl match {
      case c: URLClassLoader => Some(c)
      case null              => None
      case other             => findClassPaths(other.getParent)
    }
  }
  settings.bootclasspath.value +=
    Environment.javaBootClassPath +
      File.pathSeparator +
      findPath(GraphQLPlugin.getClass.getClassLoader) +
      File.pathSeparator +
      findClassPaths(Thread.currentThread().getContextClassLoader)
        .map(_.getURLs
          .map(_.toString.replaceFirst("file:", ""))
          .mkString(File.pathSeparator))
        .getOrElse("")
  settings.stopAfter.value = List("typer")
  new IMain(
    settings,
    Some(Thread.currentThread().getContextClassLoader),
    settings,
    new ReplReporterImpl(settings),
  )
}

interpreterが作成できたらソースコードを詠み込みinterpreterに処理させます。 結果はCompilationUnitというASTのルートオブジェクトになるので、これを解析していきます。

val (result, run) = interpreter.compileSourcesKeepingRun(getSourceFile(file))
require(result, "Compilation error")
run.typerPhase.next
run.units.foreach(x => process(x.asInstanceOf[global.CompilationUnit]))

Scala ASTはscala-reflectのTreeとして表現されます。 Tree解析の基本は次の形です。

tree.map {
  case q"<条件>" => // <処理>
}

Treeのtraverse系メソッドはVisitor pattern式にTree内の全要素を探索します。 条件の部分に対象としたいASTを指定します。

今回は次のように関連を宣言しました。 defClass、id()などはすべて型だけ合わせるようになっていて、実装は空です。 最終的な成果物で呼び出されることはありません。

class GraphQLRelationship {
  def kipp = GraphQLHelper.defClass(
    Seq(
      id(tables.users)(_.userId)
    ),
    Seq(
      table(tables.user).key(_.userId).has(
        many(tables.prepaidCard)(_.userId),
      )
    ),
    Seq(
      // アクセス制限、本稿では割愛
    )
}

これにマッチする条件は次のとおりです。 可読性のため複数行にしています。

q"""
def $name(): $_ =
  $_.GraphQLHelper.defClass($_.apply[$_, $_, $_](
    $searChes,
    $relations,
    $restrictAccesses))
"""

展開結果は次です。

name = kipp
searches = Seq(id(tables.users)(_.userId))
relations = Seq(tables(...)...)
restrictAccesses = Seq()

あとは同様にsearchesにidなどマッチさせて宣言を解析し、ASTからRDBの関連の内部表現に変換します。

// matcherの例
q"id(tables.$table)($fn)"

最後に関連データから冒頭のSangriaの仕組みに準拠したコードを生成し、.scalaファイルとして保存します。

その他の機能

実際のGraphQLインタフェースでは絞り込みや権限管理が要求されます。 これらも自動生成の仕組に閉じ込めることで生成されたSchemaを他のプログラムでいじらなくていいようにしています。 絞り込みはsearchesに次のように記述できます。

many(tables.prepaidCard)(_.userId)
// => userId: "123" のようなargumentが作られます
range(tables.prepaidCard(_.createdMs)
// => createdMs: {lt: 1625762709, gt: 1625762709} のようなargumentが作られます

ほかにネストした検索条件、オプショナル値が定義されているかなど業務で頻出の条件が定義できます。

権限管理は管理画面を操作する人物（オペレータ）の職権に応じて表示可能なテーブルを制限します。 部長はオペレータの操作履歴を見られるが一般のオペレータは見られないなどのアクセスコントロールが可能です。

表に出てこない機能として、エラーを起こしかねない状況を発見することにも注力しています。 インデックスを張っていない項目で絞り込みを行うと性能が悪化します。 一度に数百万件を取得しようとするなども同様です。 インデックスの問題であればコンパイル時に、件数の問題はクエリ実行前に検出しエラーとします。 自動化したことで網羅性のある機械的チェックが可能になり、より信頼性の高いシステムが構築できました。

効果

前回の記事にもあったように、当初はgRPCで管理画面にあわせてクエリを実装していました。 今回の例のUserとPrepaidCardのように、画面に応じてさまざまな組み合わせでデータを返す必要があります。 ページングや絞り込み条件もそれぞれに定義されているので、1APIずつ手で記述していました。 工数がかかるのみならず変更を忌避する気持ちが強くなっていました。

GraphQLを導入したのは呼出側が関連や絞り込みを柔軟に記述できると期待しての事でした。 社外のエンジニアの友人と夕食を共にしているとき、導入しやすいbackend for frontendとしてレクチャーされた記憶があります。 可能な限り少ない工数で最大の効果を上げることを目標として、RDBと密結合したクエリインタフェースを実装しました。

結果はすばらしいものでした。 多くのメンテナンスしにくい管理画面用のクエリ実装をすべて消し去りコードサイズが縮小しました。 新しい条件やテーブルの追加も数分から数十分でGraphQLに反映でき、開発者体験が改善しました。

さらにデバッグ用にGraphiQLを管理画面につけておいたところ、開発者だけでなく運用チームもデバッグや集計に使ってくれるようになりました。 すばらしい化学反応です。 管理画面は実装者に明確なリクエストを出し実装を待つ必要がありますが、GraphiQLは独力でちょっと調べることができます。 デバッグのために見られる情報が増え、開発者にトラブルシューティングが依頼される頻度も減りました。 GraphiQLのスキーマ表示や補完が充実していて非開発者に比較的使いやすかったこともプラスに働きました。 GraphQLというメジャーなシステムを利用した恩恵です。 最近ではGraphQLを通じてBigQueryやSpreadsheetにデータを書き出し、集計やモニタリングを自動化するところまで進んでいます。

ひとつ欠点を挙げるならば、AST変換実装がメタレベルのScalaコードとなるためやや理解しづらく、いざ変換コードに手をいれる時、担当者が限定されがちです。 Scala ASTとたわむれたい方はぜひお力をお貸しください。 正社員だけでなく時短や業務委託で活躍されているエンジニアの方も多数いらっしゃいます。 お気軽にpeople@kipp-corp.comまでご連絡ください。

この度プロダクトのローンチを受け、またKipp社内で取り扱っている技術の知見やノウハウの発信を目的として、エンジニアブログを始めるに至りました。 ブログを通して組織の雰囲気やKippという会社に興味を持っていただければ幸いです。

私自身の最初の投稿でもあるので簡単に自己紹介をします。 中高時代からHTMLやCSS・JS・Androidアプリ開発を独学し、大学では情報系の学部を卒業しました。 卒業後はアルバイトとして働いていた会社にそのまま就職後、転職を二度経験し現在に至ります。 前職、前々職ともフロントエンドエンジニアとして業務に携わっていました。 私個人としての主な興味はフロントエンドですが、Kippではフロントエンド・バックエンドと言った区分はなく、フルスタックエンジニアという肩書でバックエンドやインフラストラクチャにも携わっています。 少し前までは実質バックエンドエンジニアと言っていいほどもっぱらバックエンドの実装をしていました。 最近ではこのブログの構築等、フロントエンドが多くなっています。

さて、記念すべき1エントリ目ではKippが何をやっている会社なのかと、ある少し変わった実装について紹介します。

Kippという会社について

Kippでは現在、主にBanking as a Serivce（以下BaaS）と呼ばれる金融サービスを開発・運用をしています。

• Kipp、金融機関向けにBaaS（Banking as a Service）を提供開始、並びにシードラウンドで累計5億円の資金調達を実施｜Kipp Financial Technologies株式会社のプレスリリース
• キップ、金融基盤の提供開始　伊藤忠などから5億円: 日本経済新聞

弊社オフィスは日本の金融の中心街である東京都大手町の、数多くのFinTechベンチャー企業が集うFINOLAB内にあります。 オフィスは東京ですが、CEOは福岡県、CTOは北海道在住と柔軟な働き方ができる会社です。 エンジニアはコアタイムなしの完全フレックス制かつ完全リモートで、勤務日も柔軟に調整が可能です（稀に出社が必要になることがあります）。 業務において、普段のコミュニケーションはSlackを使ったテキスト中心の非同期なやりとりがほとんどです。 時間が取られがちである会議など同期的なものは極力避けて業務を遂行できるような環境・仕組み作りを行っています。

私自身、このような環境で働き始めてから半年以上経ちますが、プライベートとの両立がしやすくなり助かっています。 普段の生活に必要な買い物などでも気兼ねなく外出できますし、病院などが予約が必要な予定も入れやすいです。 普段の業務であれば離席時に逐一報告等も必要なく、仕事中の外出の心理的障壁が低いのも利点です。 仕事の合間に散歩してリフレッシュしつつ、何食わぬ顔でまた業務に戻る…という雰囲気で自由にやらせてもらっています。

BaaSとは

BaaSとは多岐にわたる金融サービスをワンストップで提供する中央集権的なSaaS (Software as a Service) です。 利用企業やエンドユーザーはそれぞれのAPIを通じてBaaSを利用します。 すでにリリースされているサービスではプリペイドカードの発行と残高管理・決済・送金機能・債権管理など多数の機能を提供しています。

なぜBaaSとして提供するのか

これまで金融サービスの開発と運用は利用企業ごとにデザインやワークフローをカスタマイズしたい需要が強いもので、一社一社に合わせて製品を提供していました。 しかし、金融サービスの提供事業者にとっては開発に時間とコストがかかるだけではなく、その基盤の上で新機能の追加や外部連携といった機能を追加するのは更にコストがかかってしまいます。 Kippはカスタマイズをした製品を売るのではなく、どんな企業にも受け入れられる機能セットを備えた1つのサービスを提供します。 利用者はAPIを通して提供したい機能を集中して開発し、エンドユーザーにサービスを届けることができます。

どのようにBaaSを提供しているのか

Kippのコア部分は主に定期的なジョブを処理するプログラムとAPIサーバとして処理を待ち受けるプログラムで成り立っています。 定期的なジョブはプリペイドカードの発行処理・財務局への提出が必要な日次・月次レポートの作成など多岐にわたります。 また、よく使われる管理機能を提供するウェブアプリケーション（管理画面）があります。 管理画面はカスタマイズのニーズが少なく、低いイニシャルコストで効率の良いものを使えることが望まれるので標準提供しています。

以上を踏まえて、今回は一例としてKippの管理画面を交えながら、技術スタックと少し変わった実装について軽く触れて終わりにします。

管理画面について

変わった実装の前に軽く技術スタックを紹介します。

管理画面のバックエンドとなるAPIサーバーはScalaで実装され、データベースにはAurora MySQLを利用しています。 バックエンドではPlay Frameworkのようなフルスタックフレームワークを用いず、データベースとの接続にSlickを、外部との通信は主にgRPCを利用するシンプルな構成になっています。 また、REST APIにおける純粋なGETのようなデータの取得がメインになる操作についてはSangriaと呼ばれるGraphQLライブラリを介してデータの取得、レスポンスをしています。

次に実際にユーザーが操作することになるフロントエンド部分についてです。 言語はTypeScriptを採用しており、フレームワークは古いプロジェクトではNuxt.js、最近のプロジェクトではNext.jsを採用しています。 管理画面のUIにはVuetifyやMaterial-UIと言ったマテリアルデザインベースのUIライブラリを採用しています。 UIライブラリは無数にありますが、マテリアルデザインベースのものを選択したのには3つ理由があります。

1. 既存のコンポーネントが充実しています。 今日UIとしてありがちなモーダル・テーブル・カードなど必要不可欠なものは一通り揃っています。 これらを組み合わせることで開発速度を上げることができます。
2. 実装方針が示されています。 既存コンポーネントが充実しているだけではどのように使うことがユーザーにとって最適なのかが判断しづらく、ときにちぐはぐなUIを構築してしまうことがあります。
3. マテリアルデザインというそこそこメジャーなUIを提供することで、使用者が既に同じようなUIを操作している可能性が高くなり、どんな操作をすれば良いかを自然と判断できることが期待できます。

3つ目に関しては、マテリアルデザインを使うとどうしても同じように見えて退屈に感じてしまうデメリットとも読み取れるので、コーポレートサイトなどブランドを前面に出したい場合は少し難しい場合もあります。 しかし、カスタマーに直接見えない管理画面の類ではあまり気にする必要がないですし、綺麗さ・使いやすさ・開発スピードのバランスが取れた優秀なUIと言えるでしょう。

gRPCメソッドのリクエストにGraphQLクエリをのせる

フロントエンドアプリケーションである管理画面はバックエンドとの通信の際、取得にはGraphQL、作成・更新にはgRPCという少し変わった戦略を取っています。 正確に言えば、データを取得する際のGraphQLのクエリもgRPCのリクエストの文字列として送信・受信をしているので、基本的には全てgRPCの上で通信していることになります。

なぜこのような実装になっているかと言うと、フロントエンドがデータの取得に関しては画面の構成に応じて柔軟に関連するデータを組み合わせることを要求することが理由です。 逐一クライアント側に合わせてgRPCのメッセージを作っていてはキリがありませんし、protoを変更すればサーバーとクライアントの両方を変更する必要があり、開発者の手間が増えます。

例としてユーザー情報を取得するアプリを考えてみます。

service UserAPI {
  rpc fetch(Request) returns (Response) {}
}

message Request {
  string id = 1;
}

message Response {
  string id = 1;
  string name = 2;
  string email = 3;
  // DBのフィールドが増え、クライアントにも必要になったとき
  // 逐一サーバーとクライアントで変更をする必要がある
}

コメントにあるように、フィールドが増えたときに変更を要します。

更にここからユーザーが記事を投稿できるような機能が追加され、ユーザー情報取得時に記事も取得したくなったとき、このような変更を加えることになるでしょう。

service UserAPI {
  rpc fetch(Request) returns (Response) {}
}

message Request {
  string id = 1;
}

message Response {
  string id = 1;
  string name = 2;
  string email = 3;
  repeated Article articles = 4;
}

message Article {
  string title = 1;
  string body = 2;
}

gRPCメッセージ自体に関連を定義してしまうと、今後クライアントの画面構成次第でprotoファイルに変更をする可能性があります。 その結果、サーバーでも実装の変更が発生するのは手間がかかってしまいますし、ナンセンスと言えるでしょう。 また、Webアプリでは記事情報が必要だけどモバイルアプリでは必要ない、と言った状況ではフィールドをoptionalにするのも、似たようなAPIをもう1つ生やすのも良い実装に感じられません。

そこで、データの取得に関してはGraphQLのデータをやり取りをするgRPCメソッドを用意することで、クライアントは自由にデータの型を定義できるようになります。 gRPCメソッドのリクエストとレスポンスはstring型のフィールドを持つシンプルなメッセージです。 サーバーは、リクエストに乗っているGraphQLのクエリ文字列（ミューテーションは含みません）の処理をSangriaで行い、結果をJSON文字列として返します。

service GraphQLAPI {
  rpc query(Request) returns (Response) {}
}

message Request {
  // 欲しいフィールドのGraphQLクエリをqueryの中に文字列として格納する
  string query = 1;
}

message Response {
  // queryに基づいたJSON文字列が返ってくる
  string result = 1;
}

こうすることでサーバーとクライアントの間でgRPCとしての型を気にする必要はなくなり、分担して開発を進めることが可能になります。 勿論、サーバーの実装としてDBのカラム情報をgRPCのフィールドへのデータの詰替え作業がなくなった分、GraphQLとしてのリレーションを定義する必要性があります。 ですが、interfaceの実装が必要なgRPCメソッドを直接いじらずにサーバーとクライアントが各々に作業できるのは利点でしょう。 これはある種のCQRS (Command Query Responsibility Segregation) 的発想と言えます。

さらにリレーションの定義はScalaの機能を生かした内製ライブラリで大幅に簡略化できています。 このライブラリについては次回ご紹介します。

終わりに

今回は少ない作業量で高品質な管理画面を提供するコツを紹介しました。 次回はGraphQL APIを提供するサーバ側の仕組みをより詳細に紹介する予定です。 今後もKippのテクノロジーや開発チームについて続々と情報発信していきますので、ぜひお読みください。 弊社に興味をもたれた方はお気軽にpeople@kipp-corp.comにコンタクトください。

今後ともよろしくお願いします。