全員リモートでの開発ミーティングを振り返ってみる

立秋の候、残暑が続きますが暦の上ではもう秋ですね。 多分に漏れず、我々 ICP 開発チームも３月４月頃から在宅での仕事が行われているので開発での打ち合わせ／スクラムイベントを中心に工夫や変わったことなどを振り返ってみたいと思います。

同じように打ち合わせで工夫されている方、開発チームの様子に興味ある方に軽い気持ちで読んでいただければ幸いです。 （スクラムに関する用語説明などは省略しております、ご了承ください）

スクラムスタートの経緯などは @yukung がこちらの記事にしております。 スクラムに興味がある方はこちらもご参考にしていただければ！ http://lab.astamuse.co.jp/entry/we-started-scrum

目次

• デイリー・スクラム（通称 DS）
• スプリント・プランニング（通称 プランニング）
• スプリント・レビュー＆振り返り（通称 レビュー／振り返り）
• オフィス勤務との兼ね合い
• ツールまとめ

デイリー・スクラム（通称 DS）

（基本は）毎朝定時に開催される DS から朝が始まります。

開始時間になると、Google Meets にメンバーは集合します。カレンダーに予定を入れておけば、自動でミーティング開催場所が準備されるので非常に便利です。開発のミーティングは殆どが Google Meets で行われます。突発的なものは slack で済ませることもあります。

さて、最近ではその日の司会が決まっているので司会の人が画面共有をしながら、取組中のストーリー／タスクを確認していきます。 かつてはオフィスに模造紙でスクラムボードを作っていたこともありましたが、編集の便利さや画面共有を簡単にしたいということから Jamboard でスクラムボードを運用しています。 模造紙→Jamboard への移行は、リモートをテストしてみようと言う話になった３月頭頃からスタートしていました。

Jamboard 内の構成は模造紙の頃と大きく変わってはいないですが、必要に応じてお知らせ欄を追加したり、それぞれのアイコン画像を設定したりと工夫もしています。

アイコン画像は視認性が高いので良いですね。 注目して欲しいコメントは、みんな自然と文字を大きくしてアピールしています。

スプリント・プランニング（通称 プランニング）

一週間の計画をたてるプランニングも Meets で行っています。

こちらも司会を立てています。リモートでの司会業は試行錯誤と行った感じでしょうか。 PdMからの説明で話を振ってもらったり、発言が少ない人に話を促してみたりと、司会の仕事は瞬発力が求められる面もあるので少し大変です。 お休みの人がいても大丈夫なように当番を回す形になってきました。大変さをシェアするという意味合いも結果的に大きいです。

プロダクトバックログ・スプリントバックログは Asana で管理しています。

Asana はリモート前から使っていましたが、最近はプランニングで話し合うことを事前に開発の Wiki 上でまとめるようにしました。

Asana 上にはカード説明を最新の状況にしておくのが望ましいと思うのですが、説明が長くなりすぎると読みづらく、すぐに一番話したいことがどこなのか伝わりづらかったので議事録の場を事前に設けて読んでもらうことにしました。

話す話題を明確にするということは、リモートに限らず大事だなと実感しています。

スプリント・レビュー＆振り返り（通称 レビュー／振り返り）

作業の完了をデモを中心に見ていく場なので、Google Meets で適宜画面を切り替えてデモをしてもらっています。

デモはオフィスでもディスプレイに繋いだものを見ていたので、個人的には変わりはないですね。 レビューは質問をするメインが PdM だから、話の交錯が起きづらいのかもしれません。

一方で振り返りはほとんどが話し合いです。 チームで issue だと感じていることと、スプリント内での各自の困りごとなどをテンショングラフを中心に振り返っています。

伝わりづらいかもしれませんが、各自のアイコンと日時コメントをつけています。

タスクとして忙しくなりがち／悩みがちなことを共有することも出来ていますし、制限時間内で雑談をする場としても機能しているかと思います。 直近覚えているものだと、一人4分以内で振り返っていました。

リモートで顔を合わせていないこともあり、重要性が以前より増しているかもしれません。

オフィス勤務との兼ね合い

全員リモートを前提として各種ミーティングを開催していますが、色々な事情で出社をする人もいます。

自分が出社の機会に感じたことは、やはりディスプレイの違いでしょうか。 打ち合わせとは関係なさそうですが、リモートの打ち合わせは共有される画面を写す必要があるので、やはりディスプレイが大きいに越したことはないですね。

幸い、在宅でも会社がディスプレイを送る手配をしてくださったので開始当初から助かりました。 最初の時期に総務の方などの負担があったと思いますが、確実に生産性の向上につながっていると思います。

椅子も在宅で座る時間が長いので影響は大きいですね。姿勢をサポートする座椅子を個人的に使っています。 とはいえ、椅子はさすがに家に送られてきても、、、少なくとも自分は困ります。。

ツールまとめ

リモートで積極的に導入された - Google Meets（カレンダーから自動でルーム生成） - Google Jamboard（Web のみ）

以前より - slack - G Suite - Asana - Crowi（社内で立てている Wiki に利用）

また、会議中での会話が重ならないように、画面上にチャットを表示しやすくするアプリケーションを試してくれているメンバーもいます。 今後も、柔軟に試行錯誤をして生産性を上げられればと思います！

いかがでしたでしょうか

少しでもリモートでの雰囲気が伝われば幸いです。 それと同時に振り返ることで改善点も話し合いをしやすくなるかと思うので、定期的に振り返る機会は大事ですね。

また、リファインメントとの向き合い方がスクラム自体を非常に改善させたと感じています。 それを振り返るには時間が足りないのでそれはまたの機会に。

暑さ厳しき折、どうか皆様お元気でお過ごしください。 勝手にブログにお盆休みを設けた gyopi でした。

こんな情勢ですが、お約束のご案内となります。

チームメンバーと議論を深め合いながら成長していきたいエンジニア、デザイナー、PM の方を絶賛大募集中です！ ご興味のある方は下記バナーの採用サイトからご応募いただければ幸いです。

SQLからC言語を呼ぶ方法 ～MeCab編～

前書き

お久しぶりでございます。Scalaでバックエンドを開発しているaxtstar(@axtstart)です。

ずいぶん昔になりますが、OracleDBでアプリ開発をしていたころ、DBの中でデータが（なぜか）バイナリで格納されていて、そのビット演算を行いながら検索するみたいな案件をやったことがあります。はじめはアプリサイドからSQLで頑張って演算していたのですが、あまりにも遅くて、結局OCI(Oracle Call Interface)を利用して、C++でバイナリを扱うように書き換えたら激的に速度が改善したことがありました。

今回ふと思い立ち、Postgresqlってそういうことができるのかしら？と思い至り今回のブログ担当を利用して検証してみることにしました。

なので、（確実に）プロダクション環境で実施するのははばかられるような内容ですのでご注意下さい。

使用できる言語は...

ちなみに、今回対象としたPostgresqlはDockerHubから持ってきたpostgresql:latestを対象としています。

select version();

結果

version
PostgreSQL 12.3 (Debian 12.3-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit

現時点*1だとPostgreSQL12.3のようです。

上記imageの初期状態で、Postgresqlで使用できる言語は下記でした。

select * from pg_language;

結果

oid	lanname	lanowner	lanispl	lanpltrusted	lanplcallfoid	laninline	lanvalidator
12	internal	10	False	False	0	0	2246
13	c	10	False	False	0	0	2247
14	sql	10	False	True	0	0	2248
13398	plpgsql	10	True	True	13395	13396	13397

なんと～デフォルトでcの文字がありますね！

どうやるのか？

OracleのOCIにあたるものがないのか調べているとspi(Server Programming Interface)というものがあることがわかりました。

Oracleの場合と同様、PL/SQL(PostgresだとPL/pgsql)からC/C++で書かれたプログラムを何らかの与えられた方式で呼び出せばよい感じ。

libpqというのを初めに見つけましたが、こちらはPro*C*2みたいなものっぽいですね。

• C/C++ から SQLを呼び出す（libpg） ←これじゃない
• SQLからC/C++を呼び出す(spi) ←これ

Server Programming Interface(spi)

PostgresqlはC言語とのインターフェースにサーバプログラミングインターフェースという名前の機構を用意していて、ユーザ定義のC関数をSQLから呼び出すことができるようです。

調べた限りだと、ソースコードのビルドに必要なパッケージとして以下が必要でした。*3

※imageのpostgresql:latestからの差分として必要という意味です。

apt-get install -y make clang llvm gcc postgresql-server-dev-12

またdb serverのインストール時にpg_configというプログラムが同時にインストールされ、これが様々な情報を教えてくれるようです。

例えば、PostgreSQLのサーバプログラム作成用のCヘッダファイルの格納パスとか

pg_config --includedir-server

結果

/usr/lib/postgresql/12/lib

詳しくはこちら

また、どのように作成するのかというのもかなり詳しくマニュアルに記載がありました。

C言語関数の部分を要約すると

• 共有ライブラリとして作成すること(so、dll、dylib)
• バージョン互換性マクロを一度だけ記述すること
• 「version 1」呼び出し規約をサポートすること
• 参照渡しの入力値の内容を決して変更しないこと*4

などなど。。。

なので結構マクロを多用する実装になるようです。

作るもの

せっかくなので、ちょっとだけ実用になりそうな（気がする）ものをサンプルで作ってみます。今回は、MeCabをインストールしてそちらを呼び出して、結果を返すことにします(本当はC言語のライブラリがあるので対象として適切だったのが本音)。

とはいってもこちらはメインではないのでサクっとaptで導入します

apt-get install -y mecab libmecab-dev mecab-ipadic-utf8

※MeCabの詳しい記事は↓こちら↓からどうぞ～ lab.astamuse.co.jp

作るものはこんな流れになります。

No	使用マクロ	意味
1	PG_MODULE_MAGIC	非互換性のチェック
2	PG_FUNCTION_INFO_V1(function)	関数宣言
3	Datum function(PG_FUNCTION_ARGS)	Version-1呼び出し規約、引数引き渡し
4	PG_GETARG_xxx()	SQLからの引数取得
5	palloc/palloc0	メモリアロケーション（マクロではない。。と思います。）
6	SET_VARSIZE	サイズ確保
7	PG_RETURN_xxx()	SQLへの返却設定

できたソース

ビルド用のmakefileはこちら

ビルドしてインストールしておきます

make
make install

下記ディレクトリにmecab_simple.soという名前で配置されます

/usr/lib/postgresql/12/lib

このユーザ定義関数を呼び出すにはファンクションとして定義する必要があります。

CREATE FUNCTION mecab(text) RETURNS text
     AS 'mecab_simple', 'mecab'
     LANGUAGE C STRICT;

その際、パス、ファイル名に関しては以下のルールに従います

第一引数

• 絶対パス
• 名前が$libdirという文字列から始まる場合、その部分はPostgreSQLパッケージのライブラリディレクトリ
• 名前にディレクトリ部分がない場合、そのファイルはdynamic_library_path設定変数で指定されたパス内
• 拡張子(.so、.dll、.dylib)を補って上記パスを検索
• 上記以外は失敗

第二引数

• 省略時は第一引数と同じとみなす
• 指定時は関数

結果

すもも

おお！どうやらうまくいったみたいですね！！

上記の一式をDockerfileでまとめているので、 ↓こちらに置いておきます。

github.com

おまけ

デフォルト機能ではないのですが、Postgresqlの拡張機能にplpython3uというものがあり、Postgresqlからpythonのスクリプトが実行できるようです。

事前準備として、postgresql-plpython3-12といったパッケージが必要なようです。

事前準備

apt-get install -y postgresql-plpython3-12

Postgresql上でExtensionを有効にします。

CREATE EXTENSION plpython3u;

Pythonのバージョンを確認してみます。

ファンクションを定義します。

CREATE FUNCTION pyversion()
  RETURNS text
AS $$
  import sys
  return sys.version
$$ LANGUAGE plpython3u;

バージョン確認

select pyversion();

結果

3.7.3 (default, Dec 20 2019, 18:57:59) 
[GCC 8.3.0]

こちらも機会があればもう少し調べてみたいと思いました。

最後に

Oracleと同様PostgresqlでもC/C++の呼び出しはサポートされていました。今回速度検証まではできませんでした、また、このような組み込みモジュールを使うのは一般的ではないかもしれないですが、マクロが充実していて、以前のOracleの時よりは楽にプログラミングできる印象*5でした。またpythonを利用するのも比較的簡単に実現できたので、こちらはもう少し深堀したくなりました。

最後になりましたが、アスタミューゼでは現在、エンジニア・デザイナーを絶賛大大大募集中です！ 興味のある方はぜひ下記バナーからご応募ください！！

*1:2020/07/28現在

*2:もう比喩が若い人に通じない話をしているかもしれない

*3:条件によってはさらに必要かもしれません。

*4:変更すると、ディスク上のデータを破壊してしまうかもしれません。とのこと。。こわい

*5:llvmなどその他の技術の発展のおかげかもしれませんが。。。

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:弊社では夏の季語として認識されております