ICPのKeycloak導入記

はじめまして、2019年10月に入社しました開発・インフラ本部の丸山と申します。

弊社テックリード(@yukung)がついに短パン*1で出社したという観測情報に触れ、いよいよ日本にも夏が到来したことを実感しているところであります。

さて、私が担当させていただいているInnovation Captital Pathfinder（以下、ICP）におきまして、このほど認証機能をKeycloakに移行したので、機能移行までに検討したことを振り返ってみたいと思います。

前置き

私たち開発しているICPは、弊社が抱える膨大な数の特許情報や科研費情報などをもとに、お客様の新規事業の創出を支援するサービスです。公式には2020年1月にリリースしていますが、実はPoCも含めると2018年から開発が続いている弊社では比較的息の長いサービスです。

弊社が抱える膨大な量のデータを、いかにユーザーが利用しやすい形で提供するかを試行錯誤しながら開発してきた経緯があり、その規模の割にはとても複雑なアプリケーション構想になっていたため、機能追加が非常にしにくい状態になっていました。

しかしながら、ICPへの投資は継続して行われること、それに合わせてメンバーの採用を強化することが決まっていたことから、今後よりコア機能の開発に集中できるようにアーキテクチャの組み換えを行うことを決め、その取り組みの一つとして認証・認可機能の分離を進めてきました。

移行にあたって検討してきたこと

まず、Keycloakを採用した背景ですが、採用理由は至ってシンプルで、

• 我々の事業のコアとなる機能により多くの開発リソースを割きたいので、自分たちでは作らず何らかのプロダクトを使う
• 既存のコードベースに入る変更を極力少なくしたいので、クライアントプロキシ型のプロダクトが理想
• とはいえ非コアな機能にあまりお金もかけられないので、いざとなったら自分たちで面倒をみる覚悟でOSSを使う

という我々のニーズに対して、応えられそうだったのがKeycloakだけだった、という身も蓋もない理由です。

実際調べてみるとわかることですが、認証／認可に機能特化したプロダクトで、クライアントプロキシ型に対応し、かつOSSとなると、実はそんなに選択肢はありませんでした😅

また、利用するプロダクトの選定と並行で、ICPの認証・認可と絡む機能をどこまで切り出し、どこまでを既存のアプリケーションに残すかということも同時に検討していきました。検討の切り口としては以下の3点になります。

• 認証機能
• 認可機能
• アカウント管理

認証

ユーザーはどのようにログインし、システム側ではどのようにログインしていることをチェックするかという観点です。 我々のニーズとしては前述の通りクライアントプロキシ型が理想でしたが、Keycloakはそれに対応していることがわかりました。この辺りの詳細については、以前弊社の植木が執筆していますので、ご興味がある方はご一読ください。

lab.astamuse.co.jp

また、上記に合わせて、既存のアプリケーションには以下の改修が必要なことがわかりました。

• アプリケーションで独自に実装していたログイン画面を廃止
  • ログイン用のIDとパスワードもアプリケーション側では持たないように変更
• 既存の認証チェック用のフィルターを廃止
• Keycloakのクライアントプロキシを通過した前提の認証情報を受け取る認証チェックフィルターの実装

これらについては、クライアントプロキシ型の認証機能を所望していた時点でどこに改修が必要になるかはある程度の当たりはついていましたので、そこまで苦労することなく対応することが出来たと思います。

認可

ユーザーに与えられた権限に応じて利用可能な機能を制御するという観点です。 こちらについては、Keycloak自身が提供する認可機能には頼らず、引き続きICPのアプリケーション内で実現するという判断をしました。

はじめは認可機能もKeycloakに切り出す方向で検討していたのですが、ICPでこれを利用しようとすると、

• ロールの設定をするためにはKeycloakの管理コンソールを直接操作させるか、あるいは設定変更が必要な機能だけをラップした何らかの管理機能を別途提供する必要がある（管理者の誤操作による障害発生のリスク）
• ICPとして期待するような複雑な権限設定は出来ない（機能不足）
• ロールの設定変更のたびに、それに合わせたgatekeeperの設定変更、及び設定反映のためのデプロイ作業が必要になる（リードタイムの遅延リスク）

といった点をクリアする必要がありました。

また、ユーザーが利用可能な機能（ロール）を販売プランと紐付けるといった設定・調整を自分たちで速やかに行えるようにしたいというビジネスサイドからの要請もあり、今ある機能をわざわざ捨ててまでKeycloakに移行するメリットを見出せなかったことが最終的な決め手となりました。

アカウント管理

ログインための認証情報（ID、パスワード）、及びユーザー自身の情報（氏名、連絡先など）をどのように管理するかという観点です。 こちらについてはエレガントな方法はなく、ICPにおける既存のアカウント管理のユースケースを地道に再整理し、どれをICPに残し、どれをKeycloakに移行するかでチーム内で議論しました。そして、最終的には以下の対応方針を固めました。

• アカウント情報の管理は引き続き既存のアプリケーション内に残し、認証に関わるものだけKeycloakで管理する
  • ICPとして管理したいアカウント情報のうち、一部の情報はKeycloakに格納場所がなかった
  • 管理対象の情報ごとに画面が分かれているとUXを著しく損ねることから、アカウント管理画面は既存のアプリケーションにに一本化することにした
  • 一方で少なくとも認証に関わる情報だけはKeycloakで管理する必要があるため、管理APIを利用してバックエンドでKeycloakに対して更新をかける方式で実装することにした
• ログインパスワードを忘れたときの再設定機能は、Keycloakに全面移行する
  • 現行機能と同等のことをKeycloakで実現でき、かつ自分たちの実装箇所を減らすことができるため即決
• そもそも利用頻度の低い機能はこれを機に廃止する

ユースケースの整理の様子（一部抜粋）

やってきたことの振り返り

実はまだKeycloakへの移行が完了して1ヶ月ほどのため、移行したことによる効果を総括をするにはもう少し時間が欲しいところですが、とりいそぎ実際に移行するまでの検証／開発過程で感じたことをまとめたいと思います。

良かったこと

• アプリケーションの実装においてはよりコア機能をどう実現するかに頭を使えるようになった
  • 認証済み前提のAPIを実装すればよいので、よりコアとなる機能をどう作るかに集中できるようになった
  • OpenID Connectという標準化された仕組みを利用することで自分たちのシステムの認証の仕組みをより説明しやすくなった
• 認証に関連する便利な機能をKeycloakがすでに提供しているため、すぐに利用できる
  • これまでやりたくても対応優先順の関係で実現しなかったことが大抵実装されていたので、開発工数が大幅に下がった
    • ログイン後に元の画面にリダイレクトする
    • 監査ログを取得する
    • アクセスクライアントを追加／削除する
  • 代理ログイン機能が超絶便利
    • 特定のユーザーでしか発生しない事象があった場合に、エンジニアがそのユーザーになりかわってログインするといったことができるので、事象の再現がしやすくなることが期待できる （ちなみに、本番環境でこれをやるときは当然ながら事前にユーザーの許可を得てから行います！）
• Openstandiaに日本語のリソース情報があるのは大変心強かった
  • 本家の更新頻度に頑張って追従していたので大変有り難い
  • 英語のニュアンスが分かりづらいときは日本語で行間を補完し、逆に日本語で何を意図しているかわからないところは原文に立ち返って理解するという使い方が出来たので、ある意味英語の勉強にもなった

ちょっと困っていること

• Keycloak／OpenID Connectそのものへの理解はある程度要求される
  • 少数で対応したこともあり、詳細を突き詰めていくとメンバー間で理解度に差が生じているため、知識共有がこれからの課題
• Keycloak自身の開発ロードマップがイマイチ不明瞭なので、今後のアップグレード計画が立てづらい印象
  • ほぼ毎月メジャーバージョンアップしているようだが、変更点の大半がバグ改修のようなので、常に最新に追随していないと辛そう
  • Github上に定義されているマイルストーンに合致するリリース物が存在しないことがある
  • gatekeeperのプロジェクト名がある日突然変わった...だと…？
• 管理画面で意図しない設定変更をしてしまっても気づきにくい
  • 管理コンソールでほぼすべての設定をカジュアルに変更できてしまうので、意図せず設定を変更してしまう懸念がある
    • そんなわけで現時点ではエンジニア職以外への開放は検討しづらい

というわけで

Keycloakの導入にあたって検討したことをあれこれ振り返ってみました。 これから導入する、または導入を予定されている方にとって検討の一助となれば幸いです。

なお、コロナもなんのその、現在アスタミューゼではエンジニア・デザイナーを絶賛募集中です。 ご興味のある方は下記バナーの採用サイトからご応募いただくか、カジュアルにランチなどでお話させていただくことも可能です。皆様のご応募をお待ちしております。

*1:弊社では夏の季語として認識されております

開発におけるMVP（Minimum Viable Product）の3つのアンチパターン

こんにちは！ 2019年11月に入社し、プロダクトマネージャーをしている竹村（@juntakemura_pdm）です。
今回が初ブログになります。

先月から開幕したプロ野球ですが、このブログを書いている時点で東京ヤクルトスワローズが単独首位に立っています。
スワローズファンの私としては非常に気分が良い日々を過ごしております。
滅多にないことなので記念に書かせていただきました。

さて、本題に入りますが、私は入社してから「転職ナビ」という転職サイトに携わっております。
転職ナビに関しては、以下のエントリで触れられているのでそちらもご覧ください。 lab.astamuse.co.jp

PMとしてプロダクト作りに関わる中で、MVPに関する学びを多く得たので、今回はそれについてお話ししたいと思います。
前半はMVPに関する一般的な話となりますので、既に知っている方は読み飛ばしても構いません。

MVPとは

MVPとは「Minimum Viable Product」の頭文字を取った略で、日本語では「実用最小限の製品」という意味になります。
元々はフランク・ロビンソン氏の定義した言葉が、「リーン・スタートアップ」（エリック・リース 著）によって広まったとされています。
日本においても上記の書籍や、昨今のリーン開発・アジャイル開発の普及によって一般的な用語になってきていますね。

MVPの具体例として、靴のECであるZapposは、はじめ在庫は持たずに靴の写真を並べたLPを作成し、本当に売れるのかどうかをテストしたそうです。（注文が入ったら靴屋まで靴を仕入れに行って発送していたとか。）
イメージとしては「α版・β版」に近いものですね。

MVPはしばしば以下のような図で説明されます。

MVPのイメージ図

出展：MVP（Minimum Viable Product）とは？実践するメリットと検証方法

旧来のプロダクト開発では図の上のようなプロセスを踏むことが一般的でしたが、そうするとステップ4まで開発しないとユーザーが利用できる状態になりません。
一方図の下ではステップ1の段階で、「移動」という価値を提供できるスケートボード＝MVPを作っています。
最小限の機能を市場に出すことで、ユーザーの反応を素早く見ることができ、その後のプロダクト開発に生かすことができるという形ですね。

また、以下の図も合わせて用いられることが多く、「ある特定のユーザー層に取って価値のある、最小限の機能」であるべきだということを表しています。

MVPの範囲

出展：MVP（Minimum Viable Product）とは？実践するメリットと検証方法

機能の網羅性を捨てる代わりに、実装する機能は狙っているユーザーにとって価値を提供できるように意識する必要があるということですね。

なぜMVPを作るのか

もし仮に作るプロダクトがほぼ100%完成形が見えており、確実に成功するものであれば、MVPのプロセスはかえって遠回りとなります。
一度MVPを出すのではなく、はじめから完成品を作った方が早いのは当然ですね。
ですが、どのようなプロダクトが最適なのか、そもそも成功するのか、は実際に市場に出してみないとわからないというのが現実です。
MVPを作る理由は、この

• プロダクトの最適解は市場に出してみないとわからない
• アイデアの大半は失敗する

という事実によるものです。

そのためにMVPを作り

• 早く市場に出してユーザーからのフィードバックを得る
• 様々なリスクの検証を素早く行い、素早く失敗して、たくさんの学びを得る

といった活動を行います。

仮に失敗しても完成形を作る前に判明するため、素早く路線変更ができ、しかもノウハウが蓄積されていくのです。
特に近年はソフトウェアプロダクトが中心となり、技術の発展や時代の変化が著しい中で、こういったプロセスが重要になってきています。

この辺りは
リーン・スタートアップ（エリック・リース 著）
INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント（マーティ・ケーガン 著）
などで詳しく触れられていますので、興味のある方はご覧ください。
個人的に「INSPIRED」はプロダクトマネージャーのバイブルと呼んでも良い名著だと思います。

リーン・スタートアップ　ムダのない起業プロセスでイノベーションを生みだす

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント

MVPの失敗談から学ぶアンチパターン

前置きが長くなりましたが、ここからが今回のメインテーマになります。

入社してから約9か月、転職ナビの会員機能という新しいプロダクトづくりに携わってきました。
このプロダクト自体やプロダクトに追加する機能において「MVPで何を作るか」ということを度々考えてきましたが、なかなか上手く行かずに日々奮闘しています。
今回は、その中で見えてきたアンチパターンや学びを共有させていただこうと思います。

MVPのアンチパターン①　何を検証したいか・何が価値なのかが定義しきれていない

MVPは基本的に「学びを得る」ことが主目的の成果物です。
そのため、「どんな学びを得たいのか」「どんなことを検証したいのか」が曖昧だと、そもそもどんなものを作るべきなのか、ということや、いざ作ってみた後にどんな数値を計測するのかもブレてしまいます。
上記は言い換えると、「実装しないのはどの機能か」「計測しない・目を瞑るのはどんな数値なのか」とも言えます。

今回、プロダクトのMVPリリース直前に、当初想定していた機能・質がスケジュール通りに実装できなさそうということがあったのですが、「ではどこまでできていればリリースしていいのか」と改めて検討した際に上記の問題にぶつかりました。
以下のエントリでも語られている、CPF～PSFの部分に当たります。 lab.astamuse.co.jp

ここが定義されていないことはリリース後にも苦労しました。
MVPということもあり、不足している機能や不便な部分、改修したい点が山ほど出てきて、リリース後はその対応に追われてしまったのです。
この時も「検証したい箇所」が明確になっていれば、「その検証を進めるために障害となり得る部分を取り除く改修」や、「その検証で学びを得るために必要な機能追加」などに絞ることができたのかなと反省をしています。

MVPのアンチパターン②　MVPが「minimum」でない

MVPを用いた開発では早く学ぶことが何より重要です。
そのため「『Minimum』Viable Product」という言葉の通り、本当に「Minimum」な機能に絞ることが必要です。
「INSPIRED」でも言及がありますが、MVPの開発にかけるべき時間は本製品にかける時間の少なくとも1桁少ない時間と言われています。

今回、リリース直前に機能を見直した際、「あれ、これって本当に必要なんだっけ？」という機能がいくつか出てきました。
また、その後機能追加時にMVPを定義する時も、つい色んな機能を付けてしまい、開発陣からツッコミをいただくこともありました。

本当に必要な機能に絞れていないと、検証の開始が遅れたり、必要な部分の質が落ちてしまったりします。 簡単なようでなかなか難しい作業なのですが、「本当に必要な機能が何か」を決めるのもMVPにおいては重要だと痛感しました。

MVPのアンチパターン③　質を犠牲にする

こちらは意外と多い失敗パターンではないか、と（私が勝手に）思っています。
前述のとおりMVPの開発はスピードが重要ですが、スピードに固執するあまりに

• スピードに寄与しない部分の質
• 検証を行うために必要な質

がついおざなりになってしまうことがあるのではと考えています。

前者は、例えばボタンの配置や文言等、最初に決めてしまえば工数に影響はないようなものを指します。
私もつい「とりあえずこれでいいや」で決めてしまうこともあり、後から反省していますが、こういった部分が要因で機能の利用が進まずに検証が停滞してしまうのはもったいないですよね。
もちろん、何日もかけて考えろ、ということではないのですが、リリース後にすぐ修正したくなるようなものにならないように気を付けるべきかなと思います。

後者は、検証したい価値を実現する質とも言えます。
例えば、検証したい価値が「やり取りが簡単にできるスカウトサービス」であれば、プロダクトのレスポンス速度やUIは高いものが求められますが、機能の種類は最小限で良いでしょう。
逆に、「求職者の専門性が可視化できる」が価値であれば、可視化の精度や詳細度は高い質が求められる反面、プロダクトのレスポンス速度やUIは問題ない範囲であれば良いと考えられます。
ところが、開発スピードにこだわりすぎると、この「検証に必要な質」まで落としてしまうこともあるのではないかと思います。
価値提供のために必要な質も見極められるようにならなければいけませんね。

MVPに関する学び

以上のような失敗を受けて感じた、MVPで重要なことをまとめてみます。

1. ターゲット、顧客課題、提供価値の定義をしっかり行う。
2. 本当に「必要」で「最小限」な「作るべきもの」は何かを徹底的につきつめる。
3. MVPであれど必要な質をないがしろにしない。

1.はアンチパターンの部分で紹介した通りです。
機能や質を定義するにも欠かせない部分になります。

2.は日々難しさを実感している部分であり、PMの磨くべきスキルだと思っています。
どこからどのように作っていくか、運用や他の手段でまかなえる部分はどこか、を考えて作るべき部分を絞り込んでいく。
絞り込んだ上で、「作るべきものって本当にこれでいいの？」とつきつめる。
「最小限でも価値のあるもの」を作る力は今後磨いていきたいですね。

3.は忘れがちなため意識したい部分です。
特に、「決めるだけ」の部分はさぼらないように丁寧にやっていきたいですね。

やってよかったMVP

長々と反省文を書いていたので落ち込みそうになりましたが、それでもMVPという形で早く作って早く学ぶのは非常に役立っていると思っています。
早くユーザーに使ってもらうことで、機能を拡張する際に課題になる部分を予測でき、その後の方針に生かすことができています。
この仮説検証サイクルのスピードと精度を上げていって、より強力なプロダクト作りができるようになりたいと思う今日この頃です。

2種類のMVPと今後やりたいこと

ところで、日々業務内外で色々な方と話をしていると、「MVP」という言葉は2種類の文脈で使われているなと考えています。

• ある程度作ることが前提になっていて、ユーザーのフィードバックを受けてその後の機能拡張を柔軟に変更するための初期プロダクト
• 検証が前提になっていて、本製品を作る前に検証を行うためのプロトタイプに近いもの

リーン開発に慣れ親しんでいる人や、INSPIREDファンの人は後者をイメージするかもしれませんが、今回私が実体験でご紹介したものは前者となります。
ちなみに、いずれのパターンでも大きな目的は変わりませんので、今回の学びは共通するものになるでしょう。

前者では最終形のプロダクトをある程度意識して設計や実装を行うため、比較的初期リリースまでのスピードは落ちますが、その後に拡張する際にはスムーズです。

後者は検証用だと割り切り、捨てる前提で作ることが多く、その分色々な手法で時間を短縮するTipsも紹介されています。

• 先行登録のLPだけ作って需要を把握する（SmartHR社の事例など）
• 本来システム化するところを人力で行って、利用されるかを試す「オズの魔法使い」形式（Zappos社の事例など）
• 特定エリアや特定ユーザー限定でサービス展開する（Airbnbの事例など）

この場合は開発者も捨てる前提でコードを書きます。
他社のPMと情報交換をする中で、1週間でテスト用のスマホアプリを実装したという話を聞いて衝撃を受けたことがありますが、今後はそのくらいのスピード感が求められるのかもしれません。

今後は後者のような製品発見活動も積極的に行っていきたいと思っています。
次回のブログ担当の時にはこの事例が書ける状態を目指したいですね。

さいごに

MVPという言葉は一般的に使われるようになっていますが、MVPとして何を作るか、は非常に難しい部分かなと考えています。
同じようにMVPについて悩む人の参考になれば幸いです。

最後に、現在アスタミューゼでは、エンジニア・デザイナーを絶賛募集中です。
ちょっと話を聞いてみたいなどでももちろん大丈夫です！
少しでも興味を持っていただけた方はぜひ採用サイトからご連絡ください。

ペルソナ制定からはじまるUI/UXの土台づくり

こんにちは。2019年10月に入社しましたデザイナーのosatoです。
今回が初ブログです。

4月頃からコロナの影響でしばらく自宅でリモート勤務をしているのですが、
もともと引きこもり気質な上、この数ヶ月長く外出することが無かったので体力がミジンコ並に退化している気がします。

さて、同ブログにてGyopiさんから「ペルソナ制定についてはデザイナーが書いてくれるよ」との振りを受けたので、今回はペルソナ制定からはじまるUI/UXの土台づくりについてお話したいと思います。

これをテーマにしようと思ったのは「ペルソナを作るとなんか良いんだろうな」ということは広く知られているのですが、 ペルソナを作ったその後はどうなるの？という点はあまり知られていないと感じたからです。

ペルソナからサービスをどのように構築していくか、 私が担当しているサービスで実際に行った手順に沿ってご紹介します。

ペルソナってなに

まずはペルソナについて軽くご説明します。

ペルソナとは「サービス（商品）を利用する仮想のユーザー像」のことです。
氏名、性別、年齢、居住地、年齢、家族構成…など細かく人物像を設定し、その人物の生活パターンや思考を想像することでサービスの方向性や販売方法を決めていくヒントにします。

詳しいペルソナのつくり方はすでに色々なところで詳細されているので調べてみてくださいね。
（参考例：誰でもできるペルソナの作り方〜マーケティングの現場で活用できる良質なペルソナを作る手順 ｜MAmag.）

ペルソナを制定する最大のメリットは、
関係者間でイメージを共有でき、サービスの方向性が決まることにあります。

例えばサービスの新機能を作るときなどに、
ペルソナだったらどう感じるだろう？どんなシーンで必要とされるだろう？
と立ち返ることで方向性の照準を合わせることが出来ます。

このような理由から、UI/UXを考える時はまず最初にペルソナを立てるとスムーズです。

ワークショップを行いました

私が入社したあと担当することになったサービスで、実際にペルソナ制定からはじめるワークショップを行いました。

ワークショップを行った理由は大きく2点。
①サービスのコンセプトを明確にするため
②サービスのブランディングのため

①はどちらかというとビジネスサイドの目線で、なにを強みするか・どのように利用してもらうかをイメージするためです。
②は制作者サイドが、どんなサービスだと感じさせるか・どんな体験を提供したいかをデザインするためです。

実際に行ったワークショップの流れはこちらです。

このワークショップでも最初の制作物は「ペルソナ」です。
サービスを理解する→ペルソナ制定
ペルソナがどのように行動するか？→エクスペリエンスマップ
ペルソナの思考や行動に対して私達が何ができるか？→機能とサービス思想
というように発展させていきます。

今回はサービスに関わる色々な職種のメンバー8人程で、合計4回のワークショップを行いました。
UX設計はデザイナーだけで行うことではなくサービスに関わる全員で行うことが理想とされています。
デザイナーはUX設計において「全員にUXに対する意識を持ってもらう」ための役割を担っています。

ワークショップが終わったあとは、成果物をスライドにまとめ改めてチームの全員に発表しました。
そこでまた感想や疑問点などぶつけてもらい、こちらも今後に活かしていきます。

土台がないと育たない

前述したワークショップで出来上がった成果物から、次はサービスのコンセプトとビジョンを制定しました。
必要な機能を洗い出し、重要な要素をグルーピング出来たことでサービスの方向性が見えてきたからです。

その次はブランディングのためのイメージボード、更にロゴデザイン、UIデザイン…と、どんどんデザインが発展していきました。

もちろんここでもペルソナを起点にしてヒントを得ています。
この世代・性別のペルソナが受け入れやすい色調や文字の大きさは…使っているデバイスは…シーンは…などですね。

このようにペルソナからはじまったワークショップが基礎となりサービスの土台が作られていきました。
これらの土台をさらに発展させ、今後、機能の拡充や、新機能、マーケティングに取り掛かっていきます。

UI/UXの土台がしっかりしていないとサービスが大きくなればなるほど方向性のブレが大きくなってしまいます。
ペルソナ制定をし、土台をしっかり固めることでサービスがよりスムーズに大きく成長していけるようになります。


さいごに

ペルソナ及びUI/UXの土台は、一度作ったらそれで終わりではありません。
サービスの成長に合わせてその時々で見直すことが必要です。

それにせっかく作ったペルソナを忘れてしまっては意味が無いので、定期的に見直す機会をつくり、活かしていくことが大切です。

サービスがより良く発展し、ユーザーに満足してもらえるようにバランスを取っていきたいですね。

最後まで読んでいただきありがとうございました！

現在アスタミューゼでは、エンジニア・デザイナーを絶賛募集中です。
ちょっと話を聞いてみたいなどでももちろん大丈夫です！
少しでも興味を持っていただけた方はぜひ採用サイトからご連絡ください。