【Techの道も一歩から】第27回「BERTで作ってみた日本語固有表現抽出器の推論部分を書く」

こんにちは。DSOC 研究開発部の高橋寛治です。

今回は、前回の 「BERTで日本語固有表現抽出器を作ってみた」 に続き、作った固有表現抽出器をWebAPI化します。

モデルを把握する

transformers ライブラリの 固有表現抽出のサンプル を流用してモデルを作成しました。

こちらのコードをもとに学習を実行すると、コマンドライン引数で指定したディクレトリにモデルファイルが出力されます。

model_dir
├── config.json
├── eval_results.txt
├── pytorch_model.bin
├── special_tokens_map.json
├── test_predictions.txt
├── test_results.txt
├── test_test_predictions.tsv
├── tokenizer_config.json
├── training_args.bin
└── vocab.txt

transformers ライブラリでは、固有表現抽出器で利用する BertTokenizer や BertForTokenClassification クラスがファイルから読み込むメソッド（from_pretrained）を提供しています。 このメソッドに、上記のモデルファイルのディレクトリのパスを渡すことで、モデルを読み込みます。

ここから紹介するコードではやや冗長な箇所もありますが、サンプルで提供されている utils_ner.py を最大限に利用しています。

Eight、Sign in with Apple対応したよ！

はじめに

こんにちは！ Eight事業部でiOSアプリエンジニアをしている福尾です。
コロナウイルス大変ですね...
弊社も原則在宅勤務になっており、日々リモートでの業務をしております。*1
幸い、僕が所属するアプリチームには普段からリモートの方が数人いるため、チーム全員がリモートになったからといって特に変わりはなくいつも通りに業務が行えております。
先が見えないですが、Stay Homeで頑張りましょう！

さて、みなさん去年のWWDC 2019で発表されたSign in with Appleという機能をご存知でしょうか？
対応しているアプリも出始めているので使ったことがある人もいるかもしれません。

我々が日々開発を行っている名刺アプリのEightというサービス(以下、Eight)も対応しました。
今回は、そのSign in with Appleについて、実装するに至った背景やざっくりとした対応方法を紹介したいと思います。

*1:執筆時現在

Eightの品質を保ち続ける「Rails × RSpec × AWS」なローカル & CI環境

Eight事業部プロダクト部 Platform Group / Engineering Manager の 藤井洋太郎(yotaro) です。

さて、私が属するPlatform Groupは「アーキテクチャ刷新」「データ基盤整備」「セキュリティ」「環境整備」など多方面での開発・改善を行っています。

本記事では「ローカル開発/CI環境改善」の取り組みについて取り上げたいと思います。

早速ですが、みなさん、

テスト書いてますか？

書いてますよね、そうですよね！！！この令和時代において、テストを書いてない人がいるわけ無いですよね😇

一方で、AWSなどのフルマネージドサービスに依存するテストコード となるとどうでしょうか？
ドキっとする人も多いのではないでしょうか？

外部サービスに依存するテストを真剣にやろうと思うと、意外と考えることが多く後回しになってしまいがちです。

みなさんも以下のような経験があるのではないでしょうか？

マネージドサービスあるある

1. Stubしがち👷🏻‍♂️

Aws.config[:stub_response] = true

AWS SDKを通したAPIリクエストをstubすることで、それっぽい挙動を検証することができます。 しかし、AWSサービス側の制約やリクエストパラメータの検証など細かいケースをケアするにはかなりの体力が必要となってきます。

2. テスト書かなくなりがち🤷🏻‍♂️

stub したコードが多くなってくると、価値の無いテストコードが生まれがちです。 そうなるとテストを書くモチベーションも下がっていきます。

expect(dynamodb_client).to receive(:query).with(expected_query_parameters)

上記のテストは意味がないとまでは言いませんが、経験上安心感を持てるとは言えませんね。

3. ローカルから実環境につなぎがち🚀

また、ローカル環境での動作確認のためにStaging環境に直接つなぐといったことを考えたことがある人もいるのではないでしょうか。

# ~/.aws/credentials
aws_access_key_id=[stagingのkey]
aws_secret_access_key=[stagingのsecret]

仮に設定を誤って migration 等を実行してしまった、本番につないでしまった、なんてことになったらそれこそ大事故です。

これらはあくまで一例ですが、ローカル環境やテスト環境を整備しないと、品質の低下、開発生産性の低下、事故リスクの増加 につながってきます。

ということで、ここからは Eight で改善を積み重ねてきた Rails × AWS なローカル/CI環境を紹介できればと思います。

ゼロから再出発するQAグループ立ち上げの話

はじめまして。プロダクト開発部の横田です。昨年の12月より、QAグループのマネージャーをやっています。
グループとしては12月に正式に発足しましたが、グループになる前からの準備期間を含めると、すでにおよそ9ヶ月が経過していました（早い・・・！）。
せっかくなので、ここまでの活動を振り返りがてら、グループを立ち上げた直後にしたことの話でも書いてみようかと思います。
少々長い話にはなりそうですが、よかったらお付き合いください。

プロダクト開発部とQA

この話を始める前に、部門としてQAはどういう歴史を辿ってきたかについて触れてみようと思います。

前身

実はかつて、部門としてQAを担うチームが存在していました。もうかれこれ8年くらい前のことです。
少数かつ別業務と兼務するようなメンバーばかりながらも、なんとかやろうとしていたのですが、開発メンバーが増えていくなど、様々な事情があり、発展的解消となりました。
以降、プロダクトの品質は、開発者個人、後にフィーチャーチームとなった各チームが、暗黙的なノウハウを継承しながら維持していくことになります。
メンバーも徐々に代替わりしていくうち、QAという存在があったこと自体を知る人の割合もかなり少なくなりました。

再出発

ちょうど1年くらい前のことです。開発部内で大きな体制変更がありました。
詳細はこちらの記事によくまとまっていますが、フィーチャーチーム形式からの脱却が図られ、ひとつの機能を複数のチームが触るようになりました。チームの人数も1チームあたり3人程度のサイズに分割され、ノウハウを持ったシニアなエンジニアがいるチームとそうでないチームができるなど、プロダクトに関する知識にも濃淡が現れ始めました。
そんな組織の変化の中、改めて横断的に品質を見るQAが必要なのではという発想に至ります。

立ち上げ前夜

実は、テストを専門にした会社から業務委託としてお手伝いしてくれているメンバー4人で構成されたグループがすでに存在していました。
メインの領域はモバイルアプリのテストで、それ以外の領域は依頼ベースでお願いするスタイルです。
彼らとの窓口は、アプリチームのリーダーで、必要に応じて連携を取っていました。

このチームリーダーに代わって窓口になるところから、私がQAグループを立ち上げる話が始まります。

たまには仕事に関係ないプログラミング教育活動、CoderDojoの運営について書いてみる

こんにちは、糟谷勇児です。
普段、ニューラルネットについてブログを書いたりしていますが、今回は私が地域活動として実施しているCoderDojoについて書いてみようと思います。

composed_of を使って Rails で値オブジェクトを扱う

DSOC サービス開発部でエンジニアをしている石畑です。普段は Rails で名寄せサービスを作っています。 今回は Rails で値オブジェクトを扱うのに ActiveRecord の composed_of が便利なので、紹介します。

値オブジェクト

値オブジェクトは DDD でも紹介されている概念です。多くのわかりやすい解説が世の中にあるので、詳しくは検索してもらえればと思いますが、ものすごく大雑把に説明すると「各属性で等価を判断できる不変なオブジェクト」です。

例えば「とあるスーパーでお肉を売る」を考えたときに、最初「300 円」で売っていた「お肉 A」を途中タイムセールで 100 円引きの「200 円」で売ったとしても「お肉 A」は値段を変更する前と「同一のお肉」です。

お肉のセール

そのため、「お肉」の同一性は属性で判断することはできず、バーコードのような識別子で同一性を追跡します。これは「値オブジェクト」ではありません（DDD ではエンティティと呼ばれます）。

これに対して、お肉の「値段」は「数字部分」と「貨幣単位」という二つの属性で等価かどうか判断することができます。例えば、「300 円」と「300 円」は常に同一の物（等価）で、「300 円」と「200 円」は常に別物です。また、「300 円」と「300 ドル」も常に別物です。そして、各値段は不変で、「数字部分」だけを取り替えることはできません（別物になってしまいます）。このような概念は「値オブジェクト」として扱えます。

どっちも同じ 100 円

※ 調子乗って「常に」とか言ってしまいましたが、値段を「値」として扱うかどうかはそのドメインによるもので、もしかしたらあるサービスでは「ある 300 円」と「ある 300 円」を別々に扱いたいこともあるかもしれません。とある概念をエンティティとして扱うか、値として扱うかはドメインによります。詳しくは調べてみてください 🙏

値オブジェクトの説明としては不十分な気もしますが、大方こんな感じです。

在宅勤務をしてみた

こんにちは。Sansan事業部プロダクト開発部の楠原です。

現在、プロダクト開発部では福岡開発拠点設立を目指して準備を進めています。 私は今は本社で開発者として勤務していますが、福岡開発拠点のメンバーになる予定です。そのため、拠点設立後に本社と福岡の混合のチームになることを見越して、リモートに変わっても生産性を落とさずにチームとして機能していけるように準備を進めています。

おりしも感染症対策のために在宅勤務が加速したことで、リモート拠点に移った場合に発生する問題を先んじて体験することになりました。 通常時は「イエーイ」という制度を使って、生産性向上を目的とし、ルールに基づいて在宅勤務することが可能です。しかし、チーム全員が同時にその制度を利用することはありません。 今回は、全員が同時に在宅勤務を行ったことで実際に直面した問題とその対策といくつか紹介します。