技術選定で失敗しない、正解にする力

プログラミングが好きなエンジニアの渡辺です。

先日 TechMTG という社内のエンジニアミーティングの場でお話させて頂いたことを書いてみようと思います。 表題の「正解にする力」というのは様々な意思決定に適用出来るものとして考えていますが、今回は技術選定という観点でお話します。

技術選定というと、世の中のデファクトだとか、新しい技術だとか、社内で実績のある枯れた技術とか色々な理由や基準で選ぶのが良いと、至るところで言われていると思います。 選定時に議論が平行線にならないように、判断基準を設けるべきというのもあるでしょう。 これらは重要であり、検討、準備することは必要ですが、それに加えて「正解にする力」というのも重要なのではないか?という提案です。

まず、組織における技術選定とは「正解を選ぶ」ことではないと思っています。 これはその技術選定結果はその人個人についてまわるのではなく、組織として維持し続けなければならないからです。 また、選定した人だけでなく、組織の他の人も同じように技術を活用している状態を作ることも必要です。 採用理由がいかに合理的であろうが、判断基準を満たしていようが、世の中のデファクトだろうが、賛同者がいなければ独りよがりになってしまいます。 なので重要なのはその選択を「正解にする力」なのです。 もちろん選択も「正解にしやすい」「正解にし続ける」ためにより確度が高い選択はあると思っています。 それは前に述べた、採用理由や基準というものです。 「正解にする力」とは分解すると「正解にしやすくする」と「正解にし続ける」となります。

「正解にしやすさ」とは

「正解にしやすさ」は賛同してもらいやすさとも言えます。 これは世の中のデファクトだったり、流行りだったり、社内実績がすでにあったりと賛同してもらうための条件がすでに整っている場合です。 もしくは提案者の技術的信頼があり、人に賛同して貰うという場合もあるでしょう。 勉強会などの啓蒙活動や実績を作って行くという行動がこれにあたります。

「正解にし続ける」ということ

「正解にし続ける」は組織や、仕組みとして成り立たせることとなります。 技術に完璧な銀の弾丸はありません。 見方を変えればみればどんな技術にもデメリットになるポイントもあるでしょう。 それを踏まえて総合的にメリットが多く、リスクが低いことがある意味技術選定の「正解」と言えるでしょう。 それは総合的なメリットやリスクを抑えるために、前提としている事柄を維持しないと「正解」ではなくなってしまいます。 これを維持するために組織の役割に組み込んだり、仕組み化をすることが「正解にし続ける」ことです。 例えば AWS を使っていなかった組織が AWS を使うようにしたとして、最初の導入は有識者が行ったとしても、それをサービスチームに移管した後、受け入れられる状態にしなければいけません。 サービスチーム側の組織に責任を持つ役割を作ったり、または基盤側の組織としてサポート体制を作ったり、権限管理やコスト管理を効率的に行えるようにしないと属人化したり、評価として行えない状態になってしまいます。 また、デメリットの理解を組織の共通認識にし、それに対する対応方法まで整備することも重要です。 そうしないと後述する技術負債を生むことにもなりかねません。

一人で「正解」にする必要は無い

大きな影響を与える判断を一人で「正解にする、し続ける」ことが難しい場合は協力が必要となります。 その協力を得られるかどうかも、その人の「正解にする力」の一部です。 協力を得るのはチームだけでなく、会社として、ひいては世の中全体までいけば最高ですね。 (今はデファクトでなくても自身がオープンソースなり設計思想なりで広めてしまえばいいということです)

正解を「選ぶ」人

「正解を選ぶ」だけの人はその判断理由や基準に対して正解ではなくなってきた時に何もすることができません。 これは正解とするための前提として置いた事柄が変わった場合の話ですね。 「前はそれで正しかったけど、今はこっちが正しい」となるだけとなってしまいます。 もしくは前提が変わったのに「この技術課題にはこの技術が正しい」と言い続けるだけです。 こういった人の技術選定は最初は採用されても採用され続けるのは難しいと思っています。 なぜなら、技術選定は一回判断すると切り替えるのが難しくコロコロ変わるとついていけないからです。 もちろん、世の中的なデファクトが長く続く技術を選べば「正解を選ぶ」だけでも結果的に正解になることもあります。 私としてはこの「選ぶ」と「正解にする」の違いを理解しているかどうかが、技術選定を任せられるかどうかの判断基準となっています。

今の技術に固執することではない

誤解してほしくないのが、本記事で書いている「正解にする力」は「特定の技術を何が何でも維持する」ということではありません。 変化を起こした方がいいことも、もちろんあります。 なので変化していくための技術革新を「正解」にすることも含んでいます。 そのときに、「今のやつをリファクタリングする時間を使ってでも、こっちにしよう」と働きかけたり、そのための理解を得るようにすることが「正解にする力」です。 理解を得るために、今まで前提としていた事柄を変えにいったり、変えたことによるメリットを最大化するために活動することでもあります。

選定基準

技術選定の基準に関しては本記事の範囲外ですがひとつだけ。 「正解を選ぶ」人はその「技術としての正しさ」を最重要視し、それ以外の事柄をそれに比べて軽視する傾向があると思っています。 「技術としての正しさ」は選定基準の前提であり、それが間違っている技術は候補に上がらないだけです。 技術的正しさというものに尺度があるとして、より技術的に正しいものを選定するのではなく、その候補から自身の組織に対してどれが一番メリットが大きく、リスクが低いかということでしょうか。 このあたりの話は他にもいろいろな技術選定基準や理由を書いてくれている記事はたくさんあると思います。

技術負債

技術負債という言葉には色々な意味があると思いますが、今回の話の文脈でということでお話します。 誰しもが見て「これは技術負債だ」と決まっているものはありません。 ただ、大多数が「これは技術負債だよね」となることはありますよね。 これは、「正解にする力」の「正解にし続ける力」がなかったことも要因の一つではないかと考えています。 技術に対する理解が全員に行き届かず、誤った使い方が蔓延してしまった その技術のデメリットを最小化することを怠った これらを維持するための仕組みがそもそもなかった きっちりその技術に対して、組織で、仕組みで正解にし続けることが出来れば大多数が「これは技術負債だよね」とはならないのでは無いかと思っています。 そしてデメリットの部分は承知の上なので、そこを見て「技術負債だよね」という人も減るでしょう。 そしてそれはその技術を選び続けることが一番のメリットであることを会社的にも証明、維持することと同義です。 そして変化に対応する必要になった場合は、「正解する力」によって変化していくことが出来るので、結果的に技術負債を抱えている期間が短くなるのではと思っています。

「正解にする力」を持っている人

ざっくばらんに言えば、この「正解にする力」を持っている人がテックリードであったり技術選定を任せられる人なのかなと思っています。 技術選定には対象の技術を正しく理解する力はもちろん必要ですが、それをいかに組織の「正解」とするかも同じぐらい重要だと思います。 そして単に、開発のことだけでなく採用や評価制度、育成に対してのメリットを最大化していく意識も必要です。

最後に

この「正解にする力」は技術選定だけではありません。 サービス、機能、組織、評価や評価制度等なんでも自らの「意思決定」に対して当てはまります。 それぞれの意思決定で「課題への正しい理解」「当事者意識」「巻き込み力」「やり抜く力」等をある意味一言で表した言葉です。 これは瞬間的な正解、不正解ではなく、再現性がある継続的な力です。

「正解にする力」という言い回しは、数学のように「正解とはすでに決まっていて、それを見つけるもの」というバイアスがかかっている「正解」に対して、それを自らの力で「正解にしてしまう」という表現にすることで簡潔に私の意図を伝えやすいかなと思ってこの言葉にしています。

いろいろ書きましたが皆様の人生で何かの参考になれば幸いです。 皆様の中での理想の技術選定を歩んでいってください。

クックパッドたんによる正解にする力の要約
クックパッドたんによる正解にする力の要約

要約の画像は知り合いに書いて頂いたものを使わせて頂いています。
また、キャラクターについては©ナイセン様のクックパッドたんを使わせて頂いています。

twitter.com

クックパッドマートのドライバー向けWebサービスのアカウントの仕組み

買物プロダクト開発部の中村です。クックパッドマートという生鮮食品のECサービスでサーバーサイドエンジニアとして流通のシステム開発に携わっています。

この記事は、「クックパッドマートを支えるアカウントたち」連載6本目の記事で、ドライバー向けWebサービスのアカウントの仕組みについて紹介します。 シリーズの全貌については以下の記事を御覧ください。

クックパッドマートを支えるアカウントたち - クックパッド開発者ブログ

クックパッドマートでは実際に商品を購入するユーザーはもちろんのこと、商品を販売する販売者や、販売者からユーザーまで商品を運ぶドライバーなど様々な立場の人が関わってサービスが成り立っています。 それぞれの立場の人に向けて異なるシステムを開発して提供していますが、今回はその中でもドライバーが配送を行うために利用するサービスの概要とアカウントの取り扱い方について紹介します。

ドライバー向けのサービス

ドライバーは商品を届けるために、いつ、何を、どこから、どこに運ぶか知る必要があります。これらの情報をドライバーに提供するため専用のWebサービスを開発しています。商品が流通していく過程では複数の流通経路を辿っており、各流通経路で異なる運び方が必要になるため、それぞれ別のドライバーが担当し、Webサービスも流通経路毎に用意しています。
ドライバー向けのWebサービスについてはこちらの記事でより詳細に紹介しています。

特性と制限

前述のドライバー向けWebサービスの要件を満たすため、アカウントは次のような特性や制限があります。

全てのアカウントを管理

運送会社のドライバーに対して個別にアカウントを発行する必要があります。新しい担当ドライバーに対してアクセスする許可を与えたり、担当から外れたドライバーはアクセスできないようにしたりと細かく制御する必要があります。

流通経路別のアクセス権限をつける

流通経路別に別のサービスを提供しており、それぞれアクセスするドライバーが異なります。とはいえ、ドライバーによっては複数の流通経路を担当することもあったりします。そのため、どの流通経路のサービスにアクセスできるかという権限を設定できる必要があります。

運送会社別にアクセス権限をつける

配送は複数の運送会社の協力のもとで成り立っています。それぞれの運送会社の担当範囲以外にはアクセスできないよう制限をかける必要があります。

権限レベルをつける

アクセスする人にはドライバーの他にもいくつかの種類の人がいて、それぞれのアカウントは以下のような要件を満たす必要があります。

名称 説明 要件
ドライバー 商品を運ぶドライバー いつ、何を、どこから、どこに運ぶかという情報が必要
管理者 ドライバーを管理する運送会社の管理者 複数のドライバーの進捗管理などの管理者用の機能を使う権限が必要
クックパッドの配送管理者 クックパッド側の配送全体の管理者 全ての流通経路のサービス、全ての運送会社の情報にアクセス可能

IDaaSの選定

認証を自前で実装したくないので何らかIDaaSを使用したいと考え、Azure ADを採用しました。前述の特性や制限を満たす使い方ができるということの他に、Azure AD は元々社内の様々なサービスのSSOに利用されているため、

  • 社内の人間のアカウントがすでに存在する
  • 新たなIDaaSの契約が不要で作業工数やコスト面で有利

といったメリットがありました。

Azure AD

構成

ドライバーのアカウントはAzure AD内で以下のようなイメージで構成しています。

詳しく見ていきます。

グループ (Group)

運送会社の権限レベル別にグループを作成しています。つまり運送会社A,Bがある場合、以下の4つのグループを作成します。

  • 運送会社Aのドライバーグループ
  • 運送会社Aの管理者グループ
  • 運送会社Bのドライバーグループ
  • 運送会社Bの管理者グループ

管理単位 (Administrative Unit)

Azure AD のグループへのアカウントの追加・削除といった操作は社内のコーポレートエンジニアリング部門の管理者しか許されていません。
しかし、ドライバーの追加・削除はそれなりの頻度で発生するので、別部署の権限を持つ管理者の負荷が高くなりますし、ドライバーがサービスを使い始めるまでのリードタイムが長くなってしまいます。 そこで流通チーム内で自由にドライバーの追加・削除が行えるよう、Azure AD の管理単位 (Administrative Unit) を使用しています。管理単位はユーザーやグループの管理権限を他のユーザーに委任することができる機能で、ドライバー向けサービス用の管理単位を作成し、運送会社のグループを管理単位の対象として登録しています。
そして流通チームに管理単位のグループ編集権限を渡してもらうことで、流通チームだけでドライバーの追加・削除ができる運用体制を実現しています。

アプリ (App)

ドライバー向けサービス用のアプリを定義しています。アプリへは運送会社のグループと社内管理者(Admin)ユーザーを登録しています。
1つのアプリで全てのドライバー向けサービスの権限を扱っており、細かい権限管理は後述のアプリロールを使って実現しています。

アプリロール (Role)

アプリロールは、グループやユーザーにアプリへのアクセス許可を与える設定です。アプリロールにvalueを設定し、valueをドライバー向けサービス側でチェックすることでアクセス制御しています。valueには 対象のサービス, 運送会社, 権限レベルの情報を持たせており、 対象のサービス/運送会社/権限レベル という形で表現しています。
例えばサービスX(service-x)にアクセスできる運送会社A(company-a)ドライバー(driver)ロールの場合は以下のようになります。

service-x/company-a/driver

また、複数のドライバー向けサービスを単一アプリで扱っているので、理想としてはドライバー向けサービス別にロールを用意し、グループに許可したいサービスのロールを複数付与したくなります。
しかし残念ながら、ユーザーやグループには単一のアプリロールしか設定することができません。そこで、運送会社グループと権限レベル別にロールを用意し、各ロールのvalueには複数のドライバー向けサービスの情報を入力、ドライバー向けサービス側でvalueをパースして権限チェックするようにしています。
先ほどのロールにサービスY(service-y)のアクセス権限も加えると以下のようになります。

service-x/company-a/driver,service-y/company-a/driver

ここでサービスXに運送会社AのドライバーがアクセスするとAzure ADから以下のような情報が渡ってきます。

{
  "provider": "driver_service",
  "info": {
    "name": "Takuya Nakamura"
  },
  "extra": {
    "raw_info": {
      "name": "Takuya Nakamura",
      "roles": [
        "service-x/company-a/driver,service-y/company-a/driver"
      ],
    }
  }
}

サービスX側ではこの情報の roles を確認します。

service-x/company-a/driver,service-y/company-a/driver

ここには複数のサービスのロールが含まれているので、パースしてサービスX自身に該当するロールを抽出します。

service-x/company-a/driver

さらにこれをパースし、サービス, 運送会社, 権限レベルに分割します。

service-x # サービス
company-a # 運送会社
driver # 権限レベル

これでサービスX(service-x)に運送会社A(company-a)のドライバー(driver)としてアクセスできることがわかりました。 この情報を元にリクエストに対する認可処理を行い、別の運送会社の情報にアクセスできないようにしたり、管理者権限が必要な操作をドライバーが行えないようにしたりしています。

まとめ

ドライバー向けWebサービスのアカウントについて紹介してきました。改めてまとめると、ドライバー向けアカウントの特性や制約を満たすことができるIdPとしてAzure ADを選択、認可はAzure AD上でサービス用のアプリと運送会社のグループを作成してグループにアプリロールを付加、サービス側でアプリロールに含まれる値をチェックすることで実現しています。
日々流通の形が進化することに伴い、ドライバー向けサービスも日々進化したり新たに生まれるといった変化が起こっていますが、Azure ADを使ったアカウント管理をすることで柔軟に対応できる体制を実現できています。 もし少しでも興味がある方がいらっしゃいましたら是非ご連絡ください。

アカウント連載の記事一覧

クックパッドマートでの店舗の認証方法移行の取り組み

クックパッドマートの開発に携わっているソフトウェアエンジニアの塩出(@solt9029)です。「クックパッドマートを支えるアカウントたち」連載シリーズの5本目の記事です。本記事では、クックパッドマートでの店舗の認証方法移行の取り組みについて紹介します。

美味しい生鮮食品をユーザーにお届けするサービスであるクックパッドマートでは、日々街の販売店や地域の生産者が商品登録や出荷作業を行っており、それらの操作を行う際に、専用の管理画面を利用しています。

今までは、店舗向け管理画面の認証のために、ユーザー登録の仕組みを設けていませんでした。専用のチャットアプリ上で管理画面のログインURLを都度発行する方式を取っていました。このログイン方式では、「店舗のスタッフごとの権限管理や操作ログの監査ができない」という明確な課題や、「店舗とクックパッドのユーザーは分離された概念となり、クックパッドにおけるサービス共有資産が活用できない」という中長期的な課題がありました。

そこで店舗の認証方法を、クックパッドのユーザーを利用したOAuth認証に移行しました。認証方法の移行の際、多くの困難な課題を解決する必要がありました。本記事では、店舗の認証方法の移行の背景や経緯、実現のために求められた要件や解決した課題について紹介します。

認証方法の移行前と移行後の比較

背景・目的

クックパッドマートは、弊社が力を入れて取り組んでいる新規事業の1つです。生鮮食品を中心として扱っているECプラットフォームで、街の販売店や地域の生産者がクックパッドマートに参加しています。コンビニエンスストア・ドラッグストア・駅・マンションなどの様々な場所に、ユーザーの受け取り場所として専用の冷蔵庫が設置されています。ユーザーはアプリから注文を行い、冷蔵庫から生鮮食品を受け取ることができます。

クックパッドマートでは、店舗が商品の登録や営業日の管理、日々の出荷作業などを行うための機能を提供する、店舗向け管理画面を開発しています。

店舗向け管理画面

クックパッド運営は、店舗の問い合わせサポートをするために、専用のチャットアプリを利用してやり取りしています。店舗向け管理画面では、今までユーザー登録の仕組みを設けておらず、チャットアプリ上での発言に応じて、ボットが管理画面のログインURLを都度発行する方式を取っていました。

チャットアプリ上でログインURLを都度発行する様子

店舗向け管理画面が誕生した当時、ミニマムの機能でなるべく多くの店舗にスムーズに使ってもらえるような形で検証を行いたく、ログインの手間を最小限に抑えた作りとしていました*1。実際にしばらく運用したところで、店舗向け管理画面はクックパッドマートを回すために必要不可欠な存在にまで成長しました。しかし、ログインURLを都度発行する方式では、以下のような課題が存在していました。

  • 1店舗の中でも複数のスタッフが商品登録や出荷作業を行っているケースがある一方で、どの操作をどのスタッフが行ったかを、ログから特定することが難しい。
  • クックパッドマートの注文ユーザー向けECアプリでは、レシピサービスであるクックパッドのユーザー基盤を用いて認証を行っている一方で、店舗の認証はクックパッドのユーザーから切り離されており、クックパッドにおけるサービス共有資産が一切活用できない。つまり、例えばクックパッドマートのECアプリ上では、店舗として活動できない状態であり、「クックパッドマートのECアプリ上で店舗として登録されたユーザー限定機能を提供する」といった施策は実現できない。

本来であれば、検証段階に作ったプロダクトをそのまま成長させるのではなく、認証方法を含めて一度あるべき姿で作り直すべきでした。しかし、時間を巻き戻すことはできないため、改めて認証方法の移行に踏み切ることにしました。上記に掲げた前者の課題から、何かしらのアカウントを利用した認証の仕組みが必要となり、後者の課題から、その「アカウント」はクックパッドのユーザーであるべきだと整理しました。そこで店舗の認証方法を、クックパッドのユーザーを利用したOAuth認証に移行することにしました。

設計・実装

店舗の認証方法の移行にあたって、機能として必要となった要件や設計、実装を紹介します。

認証方法移行に伴うデータ設計

今まで店舗ごとに、チャットアプリ上からログインURLを都度発行する方式をとっていたため、「店舗としての操作」という扱いになっていました。

実際には、背景・目的の章で述べたとおり、1店舗の中でも複数のスタッフが商品登録や出荷作業を行っているケースがあるため、1店舗に対して複数のユーザーを登録できる状態を実現する必要がありました。

また、1事業者が複数の店舗を運営しているケースもあります。例えば、「〇〇マート株式会社」という事業者が、「〇〇マート横浜店」と「〇〇マート川崎店」といった店舗を運営している場合です。この場合、例えば事業者の代表者が複数の店舗の売上情報を閲覧したいといった要望がありえるため、1ユーザーが複数の店舗に登録できる状態も実現する必要がありました。以上から、店舗とユーザーの関係は多対多として実現する必要がありました。

また法務や権限管理の観点から、1事業者は管理者としてのユーザーを1つのみ登録する必要がありました。そのため、「事業者」を表す概念もデータ設計時に組み込む必要がありました。これまでの内容を図解すると、以下のようになります。

移行前と移行後の認証の単位の比較

もともとは shops テーブルで完結していたものが、認証方法の移行にあたって以下のようなデータ設計になりました。大した複雑性ではありませんが、移行前と比較すればそれなりに登場人物の増えた状態になりました。

データ設計の変更

認証方法移行に伴うログイン体験の変化

今までは都度発行されるログインURLと店舗が1対1の関係であったのに対して、認証方法を移行した後は、前章の通り1ユーザーが複数店舗を保持できるようになります。そのため、クックパッドのユーザーを利用して店舗向け管理画面にログインしたとしても、「どの店舗の操作をしたいか」は確定しません。

実現方法は主に2つ考えられました。1つ目は、リソースを扱うようにパスなどで指定したIDに応じて操作対象の店舗を指定する方法です。ECサイトの管理画面などでたくさんの商品マスター情報を操作する考え方に近いです。2つ目は、セッションなどで操作対象の店舗のIDを指定・保持する方法です。厳密には根底の概念から違いますが、TwitterやFacebookなどのSNSに見られる「アカウント切り替え」の見せ方に近いです。

認証方法の移行にあたっては、2つ目の「アカウント切り替え」のような見せ方を採用しました。以前の店舗向け管理画面では、都度発行されるログインURLと店舗が1対1の関係であったことから、「店舗」主体での操作しかありえなかったため、管理画面の操作体験の変化を最小限に留めることや、移行のための実装の容易性を意識したことが主な理由です。

「アカウント切り替え」のような見せ方

複数の認証方法の並存

認証方法の移行にあたって、ログインURLを都度発行する方式からいきなり全てをクックパッドのユーザーを用いたOAuth認証に切り替えることは当然できません。認証方法の移行に関する告知を出した後、一定期間どちらの認証方法も受け入れられる状態を用意する必要があります。認証方法の移行が完了した店舗から随時、旧認証方法(都度発行されるログインURLの認証)が無効になる形にしました。

また、どちらか片方の方法で認証された状態だけでなく、両方の認証方法が同時に適用された状態が必要になる場面も存在するため、それを考慮した実装を行う必要がありました。具体的には、店舗の認証方法の移行手順を実施するタイミングです。

両方の認証方法が同時に適用された状態が必要になる場面

複数の認証方法があるだけでなく、その複数の認証方法を同時に扱わなければならない場面があったため、想定されるケース数も多く、実装も複雑になり、認証方法の移行にあたっての1つの大きな鬼門になりました。実装の詳細については軽く紹介するにとどめますが、大きく3つのメソッドが重要になりました。

  • 新旧の認証方法に関わらず、現在選択中(ログイン中)の店舗を返却するメソッド(current_shop
  • 旧認証方法によってログインしている店舗を返却するメソッド(current_shop_by_old_auth
  • ログイン中のクックパッドのユーザーを返却するメソッド(current_user
# 新旧の認証方法に関わらず、現在選択中(ログイン中)の店舗を返却するメソッド
def current_shop
  if logged_in_with_cookpad?
    # ユーザーに登録された店舗が1つのみの場合、操作対象の店舗をわざわざ選択しなくとも、店舗は一意に定まる
    if session[:current_shop_id].nil? && current_user.authorized_shops.size == 1
      session[:current_shop_id] = current_user.authorized_shops.first.id
    end

    current_user.authorized_shops.find_by(id: session[:current_shop_id])
  else
    current_shop_by_old_auth # 都度発行されるログインURLで認証を受けている場合、その店舗を返却するメソッド
  end
end

運営スタッフによる問い合わせサポートの考慮

今までは、店舗ごとにチャットアプリ上からログインURLを都度発行する方式をとっていました。店舗からの問い合わせサポートを行う際、クックパッドの運営スタッフは実際にログインURLを通じて、その店舗として店舗向け管理画面にログインして、画面状況を確認することが時折ありました。

認証方法の移行によって、クックパッドのユーザーによるOAuth認証が必要になりますが、当然セキュリティ上、クックパッドの運営スタッフはその店舗スタッフとして登録されたユーザーのIDやパスワードを把握できません。しかし、認証方法の移行後も引き続き、問い合わせサポートや緊急対応の目的で、クックパッドの運営スタッフが店舗向け管理画面を閲覧できる状態を維持したいと考えました。社内の管理画面でもほとんどの必要な操作はできますが、なるべく店舗スタッフが実際に日々利用している画面を、クックパッドの運営スタッフも閲覧できる状態とすることで、店舗スタッフの抱える課題を、より現場目線で把握しやすい状態にできると考えたからです。

そのため、運営スタッフが店舗向け管理画面を任意の店舗として閲覧できる仕組みを別途設けました。限られたクックパッドの運営スタッフは、あらかじめクックパッドのユーザーを社内の管理画面上で登録することによって、特別な権限を付与し、そのユーザーを利用すれば任意の店舗として店舗向け管理画面を閲覧できる仕組みにしています。

しかし、例えばそのクックパッドの運営スタッフが退職をした際に、退職後もその登録したクックパッドのユーザーを利用して任意の店舗としてログインできる状態となってしまっては、セキュリティ上の問題があるため、クックパッド社員退職後の自動処理の中で、その権限を無効化する機能を作りました。社員退職後の自動処理について、詳細は「退職処理を可能な限り自動化する」の記事にまとまっています。

ユーザー登録の解除の考慮

クックパッドのユーザー登録は解除することができます。しかし、一定の条件において、このユーザー登録の解除はブロックされています。例えば、クックパッドマートでの注文した商品の受け取りが完了していないケースでは、ユーザー登録を解除してしまうと受け取り不可能な状態となってしまうため、受け取りが完了するまでの間、解除がブロックされています。

同様に、例えばクックパッドマートで注文が入っているにも関わらず、未出荷の状態の店舗のスタッフが全員ユーザー登録を解除してしまうと、店舗向け管理画面に一切アクセスできない状態となってしまいます。そこで、クックパッドマートから退店をしない限り、かならず店舗のスタッフとして登録されたユーザーが存在するように、クックパッドのユーザー登録の解除についてブロック処理を設けました。

リリース・運用にあたって

これまで、実装や設計について紹介しました。実際にリリースや運用をするにあたっては、開発以外にも考慮すべき点が多数あります。本章では、その中でも特に注力したものを軽く紹介します。

法務の観点

クックパッドのユーザーは、基本的には個人が営利を目的とせずに利用することが想定されています。しかし、認証方法の移行によって、クックパッドマートに出店している営利目的の店舗(法人含む)がクックパッドのユーザーを利用することになります。法務チームと仕様の認識合わせを行いながら、最終的には営利活動における特約を定めることとしました。また、認証方法の移行にあたって一定期間の告知を設ける必要があるなど、その他にも多くの項目について連携を取りながら開発を進めました。

運用の観点

認証方法の移行にあたって、期限にある程度の余裕を持たせていましたが、なるべく早く、より多くの店舗が認証方法を移行した状態になることが望ましいと考えていました。そこで、社内の管理画面上で認証方法の移行の進捗状況がすぐに確認できる機能を作成し、認証方法の移行完了を目指して、運用チームがアクションのとりやすい状態をつくりました。また、店舗と直接コミュニケーションをとる機会の多い営業チームとも連携し、スピーディーな移行に努めました。

また、認証方法の移行時のトラブルも細かく考慮しながら進めました。認証方法の移行時のトラブルの一例として、1店舗において複数のスタッフが出荷作業を行っている場合に、誤ってあるスタッフが店舗内で何も周知せずに認証方法の移行を行ってしまった結果、旧認証方法(都度発行されるログインURLの認証)が無効になってしまい、他のスタッフが店舗向け管理画面にアクセスできなくなってしまうケースが想定されました。

認証方法の移行の際に想定されたトラブルの一例

店舗向け管理画面の中には、注文商品の出荷作業のような、数時間以内に行う必要のある緊急を要する作業を行うための機能も含まれており、認証方法の移行時に何かトラブルがあると、この出荷作業に影響が出てしまい、最悪の場合ユーザーに注文商品をお届けできなくなる恐れがあります。そのため、ドキュメント整備による認証方法の移行時のトラブル発生の未然防止や、すぐにトラブル対応できるようなサポート体制を整えることはもちろん、問い合わせベースで認証方法を一時的に元に戻せる仕組み作りなども行いました。

最後に

クックパッドマートでの店舗の認証方法の移行の取り組みについて紹介しました。認証方法の移行にあたって、一時的に複数の認証方法が並列して存在したり、店舗とユーザーの多対多の関係にする必要があったり、様々な困難がありました。リリース後の問い合わせは週数件のペースでありましたが、量も内容も想定していた範囲内に留まっており、大きなトラブルもなくスムーズに進めることができました。

本プロジェクトを通じて、「認証方法の移行」は避けられるのであればなるべく避けたいものだとも痛感しました。今まで紹介したように、認証方法の移行には開発はもちろん、多方面で非常に多くのコストがかかるからです。本記事で紹介したケースでは、検証用のミニマムの機能として開発したものをそのまま開発継続して広く普及させず、価値に確信できたタイミングで、早々に認証方法の移行や、新しく別のアプリケーションとして作り直すべきだったと感じました。

一方で、どうしても後から認証方法の移行をしなければならない場面も現実世界では多々あると思います。そんな場面に遭遇してしまった方に、本記事で紹介した実装時の考慮項目や運用が一例として参考になれば幸いです。

最後になりますが、クックパッドマートでは事業成長のためにスピードを高めて開発に取り組んでおり、様々な技術に触れる機会も多くとても楽しい環境です。弊社では絶賛エンジニア募集中なので、興味を持って頂けた方はぜひ採用情報をご覧ください。

info.cookpad.com

アカウント連載シリーズの記事一覧

*1:詳しくは過去の記事「街のお店や生産者が使ってくれる仕組みのつくりかた」をご覧ください。