昨今、新型コロナウイルス(COVID-19) が世間を騒がしていますが、皆さま如何お過ごしでしょうか。
弊社でも、2月の TechNight を中止したり、在宅勤務のサポートや手指衛生のモニタリングに活用できる弊社サービスの無償提供を始めたり、時差出勤や在宅勤務が取り入れられるなど、様々な動きが起きています。
さてさてこんにちは、技術統括本部 の Kikuchi です。 約1年前に、以下のような記事を書いた人です。 tech-blog.optim.co.jp
今日は OpenIDファウンデーション・ジャパン *1 の KYC WG *2 活動で、OpenID Connect for Identity Assurance という仕様の日本語訳を作成した話です。
OPTiM では「ネットを空気に変える」というコンセプトの元、 OPTiM Cloud IoT OS という AI・IoT プラットフォームや、OPTiM Store という SaaS Marketplace を開発しています。
これらのサービスにおいて、ID管理や認証連携と言った技術はサービスの下支えとなる重要な技術であり、標準化された技術を用いて開発することにより、エコシステムへ参入する障壁を減らしています。
一方で、標準技術も広く一般に普及しないことには、あるいは正しく使われないことには、標準化の効果を最大限に発揮できません。
そのため、OpenIDファウンデーション・ジャパン での啓蒙活動を通じて、ID関連技術の普及・促進に微力ながら貢献出来ればと思い、これらの活動に取り組んでいます。
本題に戻ります。
丁度1ヶ月ほど前、「サービス事業者のための、本人確認手続き（KYC）に関する調査レポート」という資料が公開されました。
その数日後に開催された、OpenID Summit Tokyo 2020 という Identity 分野のサミットでも、「OpenIDファウンデーション・ジャパンKYC WGの活動報告」というセッションにて紹介されていたので、ご存じの方も多いのではないでしょうか。
昨今、FinTech の流行に合わせて、日本では犯罪収益移転防止法（犯収法）が改正され、非対面での本人確認方法が緩和され、eKYC と呼ばれるオンラインで完結する本人確認方法が認められるようになりました。
また海外を中心に、学位や身元情報を Blockchain で共有し、保証するといった実験が動いていたりもします。
そんな中、KYC という文脈において、OpenID Connect の UserInfo API で本人確認済み情報がやり取りできるとよいのではないか？ということを思い立った方が、OpenID Connect for Identity Assurance という仕様のドラフトを書いて、OpenID の ML で議論されていました。
KYC WG の活動の中で、OpenID Connect for Identity Assurance という仕様を読んでみたりしていたので、調査レポートと合わせて翻訳を公開してみるとよいのではないか？という運びとなったのがきっかけです。
OpenID Connect for Identity Assurance とは？
簡潔にまとめると、OpenID Connect を使って、本人確認済みの属性をやり取りするための仕様です。
素の OpenID Connect では、自己申告の属性か、本人確認済みの属性かを区別することは出来ないため、このような仕様が策定されています。
今日は仕様解説はしないので、詳しいことは日本語訳をご覧ください！（宣伝です）
openid-foundation-japan.github.io
実際の翻訳活動での苦労話
本題はこちらです。実際に初めて翻訳活動をやってみた感想です。
仕様書の翻訳なので、ただひたすら英語を日本語に置き換えていくだけで、そんなに難しくはないのかな？と思っていました。 しかし、英語のドキュメントを読むときとは違った苦労がそこにはありました。
訳に困る単語や文章
ただただ機械的に日本語にしていくと、読んだときに意図が伝わらない部分がどうしても出てきます。
例えば、"Claim" という言葉を辞書で引くと、
名詞 可算名詞 1. (権利と(みな)しての)要求，請求 〔for，on，to，against〕. 2. a.主張，断言. b.〔+to do〕〈…するという〉主張. c.〔+that〕〈…という〉主張. 3. a. (要求する)権利，資格 〔to，on〕. b.〔+to do〕〈…する〉権利，資格. 4. (契約違反などに対する)補償[賠償]の請求(額) 《★【比較】 日本語で不満の意で「クレーム」という場合は complaint，また「クレームをつける」は make a complaint》. 5. 請求物; (特に)(鉱区の)払い下げ請求地. 6. 【保険】 (保険金などの)支払い請求(額).
( https://ejje.weblio.jp/content/claim より引用)
という風に出てきます。
しかし、ID関連の文章における Claim は "属性" という意味合いで使うことが多く、辞書通りに訳すとあまり意味が伝わらない感じになってしまいます。
その上、他の日本語ドキュメントでは、このニュアンスを伝えるために、あえて Claim と表現している文章も多いです。
それらも鑑みた上で、訳文も Claim という英単語のままにしました。
表記揺れ
当たり前と言われれば当たり前なのですが、すごい表記揺れします。
翻訳を行っているときに、すべての文章をぶっ通しで訳しているわけではなく、また複数人で行っていたため、同じような用語や文章に対して、微妙に違う文に訳していたりしました。
例えば、"verification data" をあるときは "検証データ" と訳し、あるときは "確認データ" と訳していたり、という風に、日本語にすると全然違うように取れてしまう表記揺れが発生していました。
最終的には、英文とセットでレビューしていくことで、揺れを吸収していきました。
この辺りは、作業が進むにつれて、プログラミングとも似ているなあという感想を抱いたりもしました。
xml2rfc に食わせるまでが大変
RFC を書いたことがある人は使ったことがあると思うのですが、RFC の文章を書くための XMLベースの言語 "xml2rfc" というものが存在しています。
xml2rfc は何度かバージョンアップしていて、Version 3 が RFC 7991、Version 2 が RFC 7749 、初代は RFC 2629 によって規定されています。
xml2rfc という名の通り、XML のタグを使って RFC の色々な仕組み（References など）を実現しているのですが、XML なので人間が空で書くのは辛いです。
... ということを思ってなのか、それ以外にも RFC を書くツールが提供されています。
今回の仕様の Editor の方は mmark という、Markdown で書いて XML に変換するツールを使っていたよう*3 なのですが、変換後の XML は Version 2 の形式となっていました。
一方、mmark というツールの Version 2 のサポートが、あるバージョンからなくなっていました。
これが原因なのか、どうにも変換がうまく行かず、うまく行かない...... と悩み続けていました。
結局、Github の Git のコミットログやソースコードを読みながらある程度の当たりをつけて、一つずつバージョンを下げながら確認するという、原始的な手法で乗り切りました。
ドキュメントを書くためのツールで、バージョン問題に苦しむとは思ってもいませんでしたが、この辺りもシステム開発に似たところがあるなあ、と感じたのも事実でした。
まとめ
色々苦労はありましたが、ただ英語の文章を読むのとは違って、
- editor はどういう意図でこの文章にしているのか
- 日本語にしたときに、どういう言葉に翻訳すれば、仕様や意図が正しく伝わるのか（自然な日本語の文章になるか）
- そもそもその日本語訳は、正しい仕様解釈になっているのか
- etc...
みたいなことを考えながら進めていくのは、苦労もあり面白さもありました。 とてもいい経験だったなあ、と振り返ってみて思います。
また、翻訳活動とプログラミングやシステム開発は、どこか似ている部分を感じることも多かったです。
プロダクトにおけるドキュメンテーションでも同じように様々な悩みがありますが、このような経験を通じて解決方法を探っていきたいと感じました。
引き続き、identity 関連技術の啓蒙活動に、微力ながら協力していければと思います。
OPTiMでは、TechBlog を中心に技術情報を社内外に発信していますが、このような活動も行っています。
弊社にご興味のある方は、こちらをご覧ください。
www.optim.co.jp
