Aarif Sumra

Md Abdur Rafi Ibne Mahmood

Abdur Rafi

Abinash Ghosh

Md. Abu Farhad

Ahmed Madkor

Ahmed Naseef Chowdhury

Alexander Bondarenco

Amdadul Hoque

An Wonho

Andrei Hogea

Andrew Lloyd

Antonin Joly

S M Asad Rahman

Md. Aslam Hossin

Aslam Hossin

Md Atiqur Rahman

Atiqur Rahman

Bob De Kort

Brett R. Toomey

Carmen Mihaila

Cheryl Cheng

Chris Combs

Christian Weinberger

Daisuke Hirata

Daniel Eddy

Danny Lee

Deniz Tunç Tuncer

Dennis Haulund Nielsen

Dinakar Maurya

Dipanjal Maitra

Dominik Hádl

Dominik Ringler

Dongyu Wang

Emil Marashliev

Enric Macias Lopez

Fahim Ahmed

Faisal Ahmed

Faisal Islam

Ferdous Al-Quraeshi

Golam Shakib Khan

Heidi Puk Hermann

Hiroki Saito

Hitoshi Hasumi

HongYang Chen

Hui Zhou

Inna Marchenko

Jakob Mygind

Jigna Patel

Jinma Yamashita

Jiri Bucek

Joao Alves

Johnny Sørensen

Jonas Stokholm Olsen

Jonas Schwartz

Jose Nieto

Kamel Mohamad

Kiyotaka Kunihira

Kun Luo

Li Huang

Lin Chen

Diarmaid Lindsay

Lucas Sales

Majid Mvulle

Marius Constantinescu

Markus Rubey

Matko Smoljan

Md. Mazharul Islam

Md. Mamunur Rashid

Milan Vít

Miyuki Akimoto

Morten Turn Pedersen

Morten Nikolaj Pløger

Muddi Walid

Muhammad Bin Farook(Rafi)

Laurentiu Narcis Zait

Md Nazmul Hasan

Nazmul Hasan

Nicolai Harbo

Nikolay Mitikov

Noboru Ishikura

Nozomi Igarashi

Nyle Levi

Oliver Wang Hansen

Oliver Hegelund Duedam

Peter Bødskov

Rasmus Ebbesen

Rasmus Thirslund

Redwan Hilali

Ricardo Tokashiki

Md. Rifat Alam

Rifat Alam

Mohammed Rokon Uddin

Rokon Uddin

Roman Levinzon

Roxana Jula

Ryosuke Hashimoto

Saad Bin Amjad

Sabrina Rashid

Sebastian Ly Serena

Full-Stack Tech-Lead engineer

Sébastien Caparros

Shafin Ashraf

Shahnewaz Leon

Shuhei Okuda

Siemen Sikkema

Sivan Payyadakath


**TL;DR:** [NestJS Framework](https://github.com/nestjs/nest)を基に Node.js の backend スターターキットを構築しました。**モノリシック** なアーキテクチャを採用し、**REST API** を実装しています。

スターターキットはオープンソースでこちらの[Github Repo](https://github.com/monstar-lab-oss/nestjs-starter-rest-api)にて公開しています。

## はじめに

[Monstarlab](https://monstar-lab.com/jp/)では最新の技術ソリューションを用いて、企業様が抱えるビジネス課題を解決するべく、製品開発およびコンサルティングを行っております。

Monstarlab のエンジニアは 4〜6 ヶ月毎に新しいお客様のプロジェクトに関わることが多いです。新しいプロジェクトを開始するたびに、技術スタックやソフトウェアアーキテクチャなど、選定に多くの時間を費やしていることに気付きました。

ダイレクトな解決策がない点は仕方ないのですが、上記については改善の余地があるという結論に達しました。例えばロガーサービス、リクエストバリデータ、JWT 認証ミドルウェアは毎回設計をし直す必要がありません。

**Tada!** そこで、こちらのスターターキットを用意しました。

## ゲームプラン

このようなことが必要と思ったのは、私たちが初めてではありません。以前にもこの問題を解決しようとしましたが、意見の相違、モチベーション、時間管理など様々な理由で残念ながら失敗しています。
今回も同じような結果となることを心配していたので、異なる方法にて再度挑戦することにしました。

#### オープンソースにしておく

過去にこのような試みを行った際に、様々な理由からモチベーションが下がってしまったことが挙げられました。オープンソースにすることで、社外でも本プロジェクトが共有されるので、達成感がうまれました。

#### ハッカソン形式へ

このプロジェクトに貢献できるのはほとんどのメンバーが空いた時間にしかできませんでした。平日はクライアントプロジェクトに取り組むことが多いので、費やせる時間は非常に限られていました。
ブレインストームをした後に、私たちはこのスタータキットへの取り組みを週末に行うこととしました。Monstarlab はハッカソンを行ううえで多くのサポートをしてくれました。そのため、プロジェクトリリースやスケジュールを維持することができたのです。

![]({{ sitePrefix }}/assets/img/articles/2022-07-19-NestJS-Starter-Kit-Monstar-Lab-Edition-Jp/Q3-B&W.png)

#### We need to go left, no right

このスターターキットに何を入れるか。または何を**入れてはいけないのか**。このようなディスカッションはいつも難しく時間がかかるものでした。

このプロジェクトに貢献できるのはほとんどのメンバーが空いた時間にしかできませんでした。平日はクライアントプロジェクトに取り組むことが多いので、費やせる時間は非常に限られていました。

結果:

- スターターキットはモノリシックパターンとマイクロサービスに基づくものの２種類に別ける
- モノリシックの中で、さらに REST API と GraphQL を構築
- 軽量にする
- 高度な機能を含めるために、スターターキットに構築された実際の制作プロフェクトを紹介する[サンプルソリユーションリポジトリ](https://github.com/monstar-lab-oss/nestjs-sample-solutions)を作成する

## Features

前述のようにスターターキットはできるだけ軽量にすることが大原則です。そこを踏まえスタータキットに追加された機能をご紹介します。

#### 認証

認証は、ほとんどの全てのプロジェクトで必要とされるものです。私たちは、ここで車輪の再発明したわけではありません。JWT 実装では、人気の高い Node.js ライブラリである PassportJS を使用して、重い作業のほとんどを代わりに行っています。bcrypt ライブラリを使用して、salts などを使ったパスワードのハッシュ化などが正しく行われていることを確認しています。よりエンタープライズグレードのプロジェクトでは、KeyCloak や Okta などの堅牢な ID 管理プロジェクトを使用するよう、皆さんにお勧めしたいと思います。今後、このような例を作っていくかもしれませんので、[サンプルソリューションレポジトリ](https://github.com/monstar-lab-oss/nestjs-sample-solutions)にご注目ください。ご質問がございましたらお気軽にご相談ください。

#### Authorization

認証の上に、多くのプロジェクトで次に必要とされるのが可能です。認可とは、ユーザーが何をすることができるかを決定するプロセスを指します。私たちは、基本的なロールベースアクセスコントロール（RBAC）認可モジュールを実装しています。このモジュールがどのように動作し、どの程度簡単に使用できるかを確認するには、プロジェクトリポジトリ内のこの[ドキュメントファイル](https://github.com/monstar-lab-oss/nestjs-starter-rest-api/blob/master/docs/acl.md)を参照してください。

#### ORM インテグレーション

ORM（Object-relational mapping とは、オブジェクト指向のパラダイムを使ってデータベースのデータを照会・操作できるようにする技術です。TypeORM はデータを操作するのに必要なコードをカプセル化するので、生の SQL を使う必要はもうありません。

#### DB マイグレーション

マイグレーションは、データベース内の既存のデータを保持しながら、アプリケーションのデータモデルと同期させるために、データベースのスキーマを段階的に更新する方法を提供します。DB スキーマのマイグレーションは、リレーショナル・データベースに関しては、常に多くの人にとって悪夢のようなものでした。TypeORM では、移行ファイルを簡単に生成することができます。

#### ロギング

NestJS には、独自のロガーが内蔵されています。しかし、それはテキストベースのロガーであり、プロダクションの要件には合いません。そこで、私たちは、非常に人気のあるプロダクションロギングパッケージである Winston をベースに、独自のカスタムロガーを実装しました。さらに良いのは、コールスタック全体でリクエストコンテキストを渡すことで、リクエスト ID、リクエストユーザーなどの追加情報を使って**コンテキストロギング** を行うことができることです。

#### バリデーションリクエスト

ウェブアプリケーションに送信されるデータが正しいかどうかを検証することは、ベストプラクティスです。NestJS は、強力な[class-validator パッケージ](https://github.com/typestack/class-validator)とその宣言的な検証デコレータを利用します。

#### ページ分割

REST API は、基本的なページングがないと完全とは言えません。私たちは、limit や offset といった単純なページネーションパラメータのサポートを追加しました。また、レスポンスには常に meta と呼ばれる子プロパティが含まれます。このプロパティには、リソースの総数などの情報が含まれており、フロントエンドアプリケーション側でのページネーションの実装をさらにスムーズにします。

#### Docker 準備

Need we say more?
![]({{ sitePrefix }}/assets/img/articles/2022-07-19-NestJS-Starter-Kit-Monstar-Lab-Edition-Jp/memegenerator.jpeg)

#### 自動生成された OpenAPI

これは NestJS で最も愛されている機能の一つです。OpenAPI 仕様は、RESTful な API を記述するために使用される、言語に依存しない定義フォーマットです。Nest では、デコレータを利用してこのような仕様を生成するための専用モジュールを提供しています。

#### 追加機能

上記の機能以外にも、私たちのスターターキットには、prettier integration、commit-linting husky hooks、package import sorting、SonarCloud github actions、データベース依存のための docker-compose など、たくさんの細かい素晴らしい機能が搭載されています。

## 最後に

先日、Monolithic + REST API をベースとしたスターターキットのメジャーバージョンをリリースしました。
長い間「作業中」でしたが、ようやく皆さんに試していただき、貴重なフィードバックを提供できる準備が整いました。

## What's next

#### ChangeLog の自動生成

このスターターキットのバックログは、これが最後です。この機能を最後に、このスターターキットに手をつけることはしばらくないと考えています。

次のロードマップは、GraphQL を使用したスターターキットです。

## リソース

- [Official NestJS Website](https://nestjs.com/)

_Article Photo by [Gaelle Marcel](https://unsplash.com/@gaellemarcel)_  
_Docker Meme Photo by [Meme Generator](https://memegenerator.net/)_


Monstarlab版NestJS スターターキット


入社して間もない頃、先輩から初めてコードレビューを依頼されたとき、光栄に思う反面戸惑いも覚えました。先輩の長年のコーディング経験に対して、自分のような若輩者が指摘できることなどあるのだろうかと戸惑ったのです。その時私が理解していなかったのは、最高のコードなんてものは存在しない、ということでした。ベストなコードとは、コードがないことなのです。[1](https://blog.codinghorror.com/the-best-code-is-no-code-at-all) 

プロジェクトに追加される新しいコードの１行は、すべからく、ビルド、テスト、レビュー、デバッグ、そして後で必要ならロードテストが必要となります。たとえば、仮にあなたがチームの中で最も経験豊富な開発者であったとしましょう。そのときあなたがどんな解決策を提案しようとも、それを承認してもらうことなく追加することができるような、白紙委任状を与えられたような状態になってしまってはいけません。

コードを書くということは、簡単に言えば、解決すべき問題の理解度とそれを解決する人のスキルによって、最適な解決策を提案することです。人間である以上、間違いや判断ミス、無知はつきものです。だからこそ、効果的なコードレビューを実施することが重要なのです。

この記事では、まず、コードレビューのベストプラクティスをいくつか紹介します。次に、採用候補者のコードチャレンジのレビューにおける、具体的なケースを簡単に説明します。

## 時間はかけても無駄にはしない

コードのレビュー時間は、短すぎるのも問題ですが、かといって長すぎるのもよくありません。レビューの要求ペースに圧倒されてしまい、基本的なチェックだけで済ませてしまいたくなることはよくあります。しかしコードレビューの時間は、タスクのしっかり見積もり、時間をとるべきです。「どうせこれは手作業でテストするのだから」という罠にはまらないようにしましょう。

また、レビュー時間が長くなってしまうことは、タスクの分割がうまくできていれば避けられます。必ず、特定のロジックだけを扱うような、小さなタスクに分割するようにしましょう。一度に全機能をレビューするよりも、そうした方が楽です。

## チェックリストの使用

レビューチェックリストを用意することで、コードの一貫性を担保することができます。コードは同じ基準で評価され、抜け漏れがないことを確認することができます。このリストは、チームの経験値に合わせて常に更新していく必要があります。

![]({{ sitePrefix }}/assets/img/articles/2022-04-06-Best-practices-for-doing-code-reviews/spring-boot-java-checklist.png)

## 自動コードレビューツールの使用

コードレビューのプロセスを支援するための、効率的でカスタマイズ可能なコードレビューツールやアナライザツールがたくさんあります。 [2](https://www.softwaretestinghelp.com/tools/top-40-static-code-analysis-tools).

![]({{ sitePrefix }}/assets/img/articles/2022-04-06-Best-practices-for-doing-code-reviews/sonar-cloud.png)

![]({{ sitePrefix }}/assets/img/articles/2022-04-06-Best-practices-for-doing-code-reviews/linting.png)

## ローカルでビルドし、必要なときにテストする

コードを見るだけでは、重要なエラーを発見できないことがあります。例えば、バッチ処理をレビューする場合、コードのビルドをローカルで実行することで、目視で確認するよりも多くの情報を得ることができます。しかし、この時点で発見されたものは、テストコードの品質が低いことを意味する可能性もあることに注意してください。

## コードレビューのやり方

コードレビューの実施方法はチームによって様々です。多くの方は GitHub にコメントを書いたり、Slack でフィードバックメッセージを送ったりするのが主なレビュー方法かと思います。

しかし時間が許す限り、ペアプログラミングを行ったり、開発者とのレビューミーティングを行ったりしましょう。これらの方法はただコメントを残すよりも効果的で、よりインタラクティブであり、良いメンタリングの手段でもあります。

命令するのではなく提案をし、なぜそれがより良い方法だと思うのか、常に理由を伝えましょう。そうすることで開発者がよりよく理解できるようになります。

間違いを見つけることだけに集中せず、ポジティブなコメントも常に歓迎されます。あなたが感動するような、巧妙で魔法のようなコードに出会ったら、親指を立てたり、褒め言葉を書いたりしてください。そうすることで開発者に感謝され、よりよい仕事上の関係を築くことができます。

## レビューの際に確認すべきこと

- 要件は満たされていますか？
- コードは良い設計原則に従っていますか？
- コードはどの程度複雑ですか？読みやすいでしょうか？
- パフォーマンスとスケーラビリティの問題はどうでしょう？データはシステムの最も重要な部分であることを常に念頭に置き、大規模なスケールでどのように動作するかを常に考える必要があります。
- セキュリティの問題は？SQL インジェクション、XSS、個人情報の取り扱いなど、潜在的なセキュリティ上の脅威がないかどうかを確認します。
- コードにきちんとコメントが書かれていますか？
- 保守性についてはどうですか？コードは DRY でしょうか？
- コードのスタイルは、事前に定義したガイドラインに従っていますか？
- 再利用性、命名規則などについてはどうでしょうか？

## コードチャレンジのレビュー

上記の内容のほとんどは、採用候補者コードチャレンジのレビューをする際にも当てはまります。解決すべき問題は通常単純であっても、候補者を次の採用ステップに進めるかどうかを判断するのに役立つ興味深い点があります。

審査基準には、以下のものが含まれますが、これらに限定されるものではありません。

- 与えられた要件を理解する能力
- 問題解決へのアプローチ
- 提案されたソリューションのコア・アーキテクチャとデザイン
- 初期設定の複雑さ：OS に依存せず、箱から出してすぐに動くこと。
- 使用する技術スタックの選択
- 提案されたコードの品質...

また、コードレビューを行う側への注意として、採用候補者のコードレビューを行う際に、これらのコードチャレンジはコンテストではない、ということを常に念頭に置いておくべきです。候補者が提案したソリューションが、以前にレビューした他の候補者のコードよりも見劣りしたからといって、ペナルティを課してはいけません。

## 結論

優れたコードレビューは、本番環境に移行する前に潜在的な問題を発見することで、時間とコストの節約になります。さらに、技術やヒントを共有することで、より良いチームコラボレーションを構築することができます。特に、多くの開発者が孤立して時間を過ごしているこの時代、GitHub にコメントを残すだけでなく、コードレビューのために会う時間を取りましょう。

### Thanks for reading!

## References

[1] [The Best Code is No Code At All](https://blog.codinghorror.com/the-best-code-is-no-code-at-all)

[2] [TOP 40 Static Code Analysis Tools](https://www.softwaretestinghelp.com/tools/top-40-static-code-analysis-tools)

[3] [How to do a code review](https://google.github.io/eng-practices/review/reviewer)


コードレビューをしよう


こんにちは、Qualitylabです。
テストの基礎をお伝えするにあたって、前回は「テストとは何か？」ということを解説しました。この記事では、テストの必要性について解説していきます。


### ◯目次
- なぜテストが必要だと思いますか？
  - サービスイン後のインシデントを未然に防ぐこと
  - 品質基準を満たしていることを証明すること
  - 当たり前品質を実現し、安心・安全なプロダクトを届けること
- JSTQBで定義されているテストの必要性
- テストの必要性を説明するときに欠かせない「品質」との関係性は？
- 最後に



## 早速ですが、なぜテストが必要だと思いますか？
近年ソフトウェア開発ライフサイクルの中で、テストの必要性が注目されてきています。
Qualitylabではテストの必要性を大きく分けて以下の3点だと考えており、日々目標にして業務に取り組んでいます。

__①サービスイン後のインシデントを未然に防ぐこと__<br>
__②品質基準を満たしていることを証明すること__ <br>
__③当たり前品質を実現し安心・安全なプロダクトを届けること__ <br>


下記に順に説明していきます。
### __①サービスイン後のインシデントを未然に防ぐこと__
 -  最終コストの削減はもちろん、サービスイン後のインシデントを防ぎ、クライアントの社会的な信用を向上・維持することに貢献します。

Qualitylabでは、これまでのノウハウを元にして作成した観点リストや複数名でのレビューなどを導入し、客観的な目線で個人のバイアスがかかったテストを設計することがないように取り組んでいます。
また、仕様の抜け漏れを指摘することによって、不具合の作り込みを未然に防ぐこともインシデントを防ぐために必要な取り組みです。そのために、上流工程からプロジェクトに参加して、顧客の要望や要件、仕様に対してQA目線でレビューすることが必要です。上流工程からプロジェクトに参加することの重要さや最終的なコストの削減などの利点をお客様にお伝えすることを意識しています。


### __②品質基準を満たしていることを証明すること__
 -  テストプロセス標準を開発プロジェクトで使用し、策定したテスト計画に基づいたテスト設計・検証を実施することで品質基準をクリアしていることを証明します。

品質基準をクリアできていることを証明するためには、テストプロセスを標準化することが必要です。なぜなら、基準を評価するテストプロセスが属人化していたり主観に基づいていると、同じ目線で評価出来ないからです。策定されるテスト計画や設計されたテスト・実施にばらつきが出てしまい、品質基準がブレてしまいます。
しかし、すべての開発プロジェクトで使用可能なテストプロセス標準を作成することはほとんど不可能といえます。Qualitylabでは、継続的にテストプロセス標準の見直しを行い、プロジェクトに応じてテーラリングが可能な状態にすることを目指しています。

### __③当たり前品質を実現し安心・安全なプロダクトを届けること__

 - クライアント・エンドユーザ・システム運営者などの利用者目線でプロダクトを評価することで当たり前品質を実現し、関係者が幸せになること。

品質は大きく「当たり前品質」と「魅力的品質」と捉えることができます。

![当たり前品質と魅力的品質]({{ sitePrefix }}/assets/img/articles/2022-03-03-Test-Basics-2/01.Test-Basics-2.jpg)

スマートフォンで例えると、「問題なく充電できること」や「通話音声が聞こえる」といった品質は当たり前品質であり、「写真を高画質で撮ることができること」といった品質は魅力的品質と考えられます。

__当たり前品質__ や __魅力的品質__ などのソフトウェアの品質は顧客の満足度に繋がります。
しかし、「魅力的品質」を重視しすぎることにもリスクがあります。
例えば、納品の直前に「魅力的品質」を増やすために仕様の追加をした場合、それまでに行なっていたテスト結果や、テストを行って得られた信頼性を低下させることになり、「当たり前品質」が下がってしまう可能性もあるためです。

Qualitylabでは、「当たり前品質」を当たりに実現できるように顧客が納得する水準の品質を目指して、自分たちの仕事に取り組んでいます。

> JSTQBで定義されているテストの必要性
> また、JSTQB FLのシラバスでは、このようにテストの必要性を説明しています。
> “ソフトウェアテストでは、コンポーネントやシステムが稼働する前に欠陥を検出して修正することで品質向上に貢献したり、契約や法律上の要件、および各業界の標準に合致していることを証明したりするために必要になります。そのためには、ソフトウェア開発ライフサイクルの中の適切な時点で、適切なテスト技法を適用したテストを行うことが重要です。”


品質向上はもちろん、さまざまな基準を満たしていることを証明するためだけではなくクライアントやエンドユーザーの暮らしがより便利になるためにもテストは必要です。
ではなぜ、ソフトウェア開発ライフサイクルの中の適切な時点で、適切なテスト技法を適用したテストを行うことが重要なのでしょうか？


### 1:10:100の法則 

まずは、以下のグラフをご覧ください。

![1:10:100の法則]({{ sitePrefix }}/assets/img/articles/2022-03-03-Test-Basics-2/02.Test-Basics-2.jpg)

欠陥を発見するタイミングが遅くなるほど、修正作業・修正コストが増大することがわかると思います。ソフトウェアのバグ修正コストは、発見されるタイミングによっては10倍、100倍になりえます。特にリリース後では、大幅に増えることになります。こういった事象を起こさないためにも、適切なタイミングで適切なテスト技法を適用することが重要です。



## ソフトウェアと品質
ソフトウェアテストの必要性を考えるにあたって、「品質」という言葉は欠かせません。ソフトウェアと品質については次の３つと関係があります。

### ・品質の確保

ソフトウェアの品質を確保するため、リリース前にテストを行います。
適切に設計したテストを実施することで、リリース後の欠陥多発や欠陥偏在によるリスクの度合いを下げることができます。
また、期待する結果と実際の結果に差異が生じた場合は不具合として報告します。
報告された不具合や欠陥を修正することによって、システムの品質を上げることができます。
リリース前のテストは品質を確保するために行うといったことを認識すると、テストは手段であり、不具合や欠陥を修正してシステムの品質を上げるための目的であることがわかると思います。
発見した不具合や欠陥が修正されているか確認する際のテストも重要です。仕様通りに修正されているか、別機能に影響が及んでいないかといったことまで確認して（リグレッションテスト）、初めて品質が確保されたと自信を持って言えるでしょう。

### ・品質の計測

テストから検出した欠陥を基に、ソフトウェアの品質を計測することができます。
欠陥や故障の計測によって、品質に対する定量的な判断を行うことができます。
判断には、ソフトウェアの機能要件/非機能要件や品質特性(使用性、効率性、保守性など)を指標として計測することができます。ただし、適切なテストケースを使用している場合に限ります。
また、計測の例としては以下のものがあります。
1.	テストケース消化数と故障発生件数から割り出したバグ密度
2.	テスト実施時間の経過と故障発生件数の推移
3.	システムの性能(応答時間など)に関するデータの収集

### ・プロセス改善のための情報提供

テストを行っていると様々な欠陥が見つかります。
例えば、過去に似たような欠陥が見つかっていたというケースもあるでしょう。なぜ似たような欠陥が見つかるのでしょうか。理由としては、過去に見つかった欠陥を修正する際に、欠陥の根本原因を除去せず修正しているためです。
欠陥の分析を行うことで、欠陥の根本原因を理解することができ、開発プロセスを改善する必要があるかもしれないということが発見できるかもしれません。
そして、開発プロセスが改善されれば同じ欠陥の作り込みを未然に防ぐことができます。同じような過ちを繰り返すことがなくなれば、将来開発するソフトウェアの品質の改善にも繋がります。
また、テストは品質保証活動の一つとして組み込む必要があります。
テストそのものを目的にしたり結果を放置せず、欠陥の修正やプロセスの改善に反映させることが重要となります。



## 最後に

ここまでソフトウェアテストの必要性や目的などを説明してきました。
この記事を通じて、少しでもテストの重要性が伝わっていたら幸いです。

次回は「テストの7原則」についてご紹介します。



## 『Qualitylab』とは（※1）

ソフトウェアの品質保証を行う弊社サービス『Qualitylab』には、JSTQBが実施している、JSTQB認定テスト技術者資格試験の資格保有者が在籍しています。

Qualitylabとは、アプリケーションの機能・サービス品質をテストすることに特化した新サービスで、APAC,EMEA,Americasの20の国と地域、32拠点から豊富な人材リソースおよび国内外パートナー企業との豊富なネットワークにより、コスト最適でスピーディな提案をいたします。

Qualitylabは自社サービスの品質に課題を感じている顧客、バージョンアップ頻度が高くリグレッションテスト（※2）にコストと時間がかかっている顧客を対象にコスト効率・検出効率を最適化し、独立した第三者チームを提供いたします。

※1: 2022年4月より名称がテスター・ラボからQualitylabに変更となりました。<br>
※2: リグレッションテストとは、開発でプログラムの一部を変更した際に、新たな問題が発生していないかを検証するテストのことです。<br>


テストの基礎 その2


こんにちは、モンスターラボ Front-end の 山下 です。
普段のプロジェクトでは React、Vueで開発していますが、2021年末から急速に成長している Front-end フレームワーク Solid のことを知り、習得していくと、React 開発経験者を考慮した API 設計や Solid のシンプルなソリューションなど React に替わる選択肢として興味深いものでした。この記事では React の経験者目線で書きたいと思いますので、同じく React 開発経験があり、これから Solid の使用を検討している方の参考になれば幸いです。

## Solid について

Solid はパフォーマンスを重視した宣言的な UI 構築のフレームワークです。2016 年、[Marko](https://github.com/marko-js/marko) のコアメンバーでもある [Ryan Carniato](https://twitter.com/RyanCarniato) 氏により、10 年ほどの Knockout での開発経験に基づいて、Knockout のモデルを現代的に再解釈するという趣旨が、このプロジェクトの動機だったそうです。

> Knockout is a perfect example of this since its View Models run once, it is the primitives that update. My library Solid is like a modern re-interpretation of Knockout.
> https://ryansolid.medium.com/i-used-knockout-in-professional-dev-environment-for-almost-10-years-b94ab2be5c96

また、React のような一方向性のデータフロー設計、React Hooks に大きく影響を受けた API、React の設計思想にも沿っている点や JSX 使用など、React を使って開発したことがある人なら、Solidもなじみやすい設計になっています。

2021 年 6 月には [1.0 バージョンがリリース](https://dev.to/ryansolid/solidjs-official-release-the-long-road-to-1-0-4ldd)され、パフォーマンスを重視しつつ、DX コストもそこまでかからない点で人気が急上昇、[Wang](https://engineering.monstar-lab.com/jp/authors/dongyu-wang/) さんの[記事](https://engineering.monstar-lab.com/jp/post/2022/05/27/Is-Virtual-DOM-Outdated/)にも言及されたように 2022 年 2 月まで実施された「State of JavaScript 2021」では Svelte とともに最も満足度が高い [Front-end framework](https://2021.stateofjs.com/en-US/libraries/front-end-frameworks) としてトップランクされました。

Solid については仮想 DOM を使わない framework、他の framework と比べてパフォーマンスが優れているなど、
いろんな特徴がありますが、まずは開発者の DX を考慮した二つの API から紹介できればと思います。

## React の設計思想に沿うと同時に、異なる仕組み

1 秒ごとにカウントが増加するアプリケーションを作るとします。

React のライフサイクルフックを考えると、下記のコードは正常に動かないことがわかります。setInterval の コールバック関数 は state を毎秒ごとに変更、state が変更される度に、
コンポーネント関数は再度実行するので、結局 memory leaks が発生してしまうからです。

```jsx
import { useState, useEffect } from "react";

const Counter = () => {
  const [count, setCount] = useState(0);

  setInterval(() => setCount(count + 1), 1000);

  return <div>{count}</div>;
};
```

正常に動作するコードを書くのであれば、ライフサイクルフックをを考慮して下記の手順でコードが書けると思います。

```jsx
import { useState, useEffect } from "react";

const Counter = () => {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const id = setInterval(() => setCount(count + 1), 1000);
    return () => clearInterval(id);
  }, [count]);

  return <div>{count}</div>;
};
```

動作自体には問題ないですが、count の状態は頻繁に変更されて、その度に setInterval を登録・解除してしまう問題があるので、
依存配列から count を抜くことでそれを解決できます。

> If you want to run an effect and clean it up only once (on mount and unmount), you can pass an empty array ([]) as a second argument.
>
> https://reactjs.org/docs/hooks-effect.html

```jsx
useEffect(() => {
  const id = setInterval(() => setCount(c => c + 1), 1000);
  return () => clearInterval(id);
}, []);
```

これで期待通り毎秒ごとに増加された最新の count は描画しながら useEffect 内の setInterval は mount された時に 1 回だけ実行されるようになりました。
unmount の際には setInterval も clear しているので、他に気になるところはありません。

このようにコンポーネントの開発する際に、

1. コンポーネントのライフサイクル
1. ライフサイクルに相応するフック、フック関数を再実行するための依存配列の値

などを常に頭の中でイメージしながらコンポネートの開発する必要があります。

Hooks やライフサイクルのルールを理解して、常に頭の中でイメージしながらコンポーネントを開発する必要があります。

上記例は簡単な例でしたが、実際はもう少し複雑なコンポーネント構造の中で、さまざまな状態の依存関係を考慮しないと、意外と発見しづらいバグが発生します。
eslint のルールを使って、ある程度は防ぐことができるかもしれませんが、全部防げるわけではありません。

同じ動作をするコードを Solid にてみてみましょう。

```jsx
import { createSignal, onCleanup } from "solid-js";

const Counter = () => {
  const [count, setCount] = createSignal(0);

  const id = setInterval(() => setCount(c => c + 1), 1000);
  onCleanup(() => clearInterval(id));

  return <div>{count()}</div>;
};
```

React 開発者には Solid のコードが初見でもすぐ理解できると思います。
例えば `createSignal` は React の `useState` と似たような挙動をする関数に見えますね。
ただ、`setInterval` が hooks にてラップされていない点や、コンポーネント自体のライフサイクルなども気になるかもしれません。

実は Solid でライフサイクルがほとんどなく、関数コンポーネントは（レンダリングサイクルごとではなく）一度しか実行されません。

> Render-once mental model: your components are regular JavaScript functions that run once to set up your view
>
> https://github.com/solidjs/solid/blob/main/README.md

Sample にて関数に console などを出力して見ると、関数コンポーネントは一度実行されてビューの部分に変更があっても再度実行されないことがわかります。

![]({{ sitePrefix }}/assets/img/articles/2022-05-30-Similar-To-React-But-Efficient-Solid/sample1.gif)

[Try playground](https://playground.solidjs.com/?version=1.4.1#NobwRAdghgtgpmAXGGUCWEwBowBcCeADgsrgM4Ae2YZA9gK4BOAxiWGjIbY7gAQi9GcCABM4jXgF9eAM0a0YvADo1aAGzQiAtACsyAegDucAEYqA3EogcuPfr2ZCouOAGU0Ac2hqps+YpU6DW09CysrGXoIZlw0WgheAGEGCBdGAAoASn4rXgd4sj5gZhTcLF4yOFxkqNwAXV4AXgcnF3cvKDV0gAZMywT8iELeDEc4eFSm3iymgD4KqprU9JLamYBqXgBGPvCBkqH1OAA6NVoPdJUAJWExCRLOeOFcAEIVXYhcwSqmBMuBvIAHhM9FwuHivAIxEaKhBYPiKl48USGmYAGtGiBRkIJrhJLMvnk8iBVstMpJCbxAfo4eCIASBh8KZ8IEJROJ0jNGvNAUs0rx9LNyiJaMx6Ljjh4qgBRNTjZ4AIXwAEkRJcwFBCIR3i8PmBJHUgA)

`createSignal`が戻す値 Signal は [Proxy で実装された追跡が可能な Observer](https://github.com/solidjs/solid/issues/2)で、
現在の Signal の値を返すゲッター関数と Signal を更新するセッター関数を持つ配列で構成されています。

Solid ではコンポーネント関数はコンストラクタのような役割で、プログラムの実行時に Signal が更新されて Signal のゲッターを呼び出した側のコンテキストのみ（この例では JSX 式にて呼び出した部分）再実行を行います。

コンポーネント関数が一度しか実行されないことは、特に親コンポーネントと子コンポーネント関係の再レンダリング問題に便利です。
例えば、コストの高い計算を行っている子コンポーネントがあって、親コンポーネントの状態や条件が変わって再度レンダーされるかもしれないということに注意したり、また、Hooks にてメモ化するのであれば、どの Hooks を使うのが一番効果的なのかを考えながら、開発した経験があるかもしれません。下記の簡単な React コードを見てみましょう。

```jsx
const ExpensiveChild = props => {
  console.log("Render ExpensiveChild...");
  return <p>Child {props.count}</p>;
};

const Parent = () => {
  const [count, setCount] = useState(0);

  return (
    <div>
      <button onClick={() => setCount(c => c + 1)}>{count}</button>
      {count > 3 && <ExpensiveChild count={count} />}
    </div>
  );
};
```

React にて親コンポーネントの `count` が 3 を超えたら、子コンポーネントをレンダリングさせたいと思っています。
ここで問題は、`count` が 3 を超えて 4、5、6 に変更される度に、子コンポーネントは毎回レンダリングされてしまうことです。

![]({{ sitePrefix }}/assets/img/articles/2022-05-30-Similar-To-React-But-Efficient-Solid/sample2.gif)

[Try playground](https://stackblitz.com/edit/react-ts-u4oz8q?file=.vscode%2Fsettings.json,App.tsx)

コストの高い計算を行っている場合、すぐ思いつくのは `count > 3` の状態をメモ化するか、再レンダーを発生させない ref オブジェクトを使うかでしょうか。

```jsx
const Parent = () => {
  const [count, setCount] = useState(0);
  const isVisibleExpensiveChild = useMemo(() => count > 3, [count]);
  return (
    <div>
      <button onClick={() => setCount(c => c + 1)}>{count}</button>
      {isVisibleExpensiveChild && <ExpensiveChild count={count} />}
    </div>
  );
};
```

コンポーネント関数が最初に作成されたときに一度だけ実行される Solid では、
上記のように関数コンポーネント内の条件分岐で、子コンポーネントが再度レンダリングされるかどうか、メモ化について考える必要はありません。

```jsx
const ExpensiveChild = props => {
  console.log("Render ExpensiveChild...");
  return <p>Child {props.count}</p>;
};

const Parent = () => {
  const [count, setCount] = createSignal(0);

  return (
    <div>
      <button onClick={() => setCount(c => c + 1)}>{count}</button>
      {count() > 3 && <ExpensiveChild count={count} />}
    </div>
  );
};
```

![]({{ sitePrefix }}/assets/img/articles/2022-05-30-Similar-To-React-But-Efficient-Solid/sample3.gif)

[Try playground](https://playground.solidjs.com/?version=1.4.1#NobwRAdghgtgpmAXGGUCWEwBowBcCeADgsrgM4Ae2YZA9gK4BOAxiWGjIbY7gAQi9GcCABM4jXgF9eAM0a0YvADo1aAGzQiAtACsyAegDucAEYqA3EogcuPfr2ZCouOAGU0Ac2hqps+YpU6DW09CysrZloIMj4AUQpiaLQANzgAYQALNDURXgBeXgAKQnlCMgBKfIA+fiteByiguAA6NVoPQpUAJWExCXjEshT0rJzm8ZVyywh6oVwmGYAeQirM7NyQEtoy5sj6CFxJRf0V6clpiMa+AAUoIQP8osq8mpA6hui+YD2DrF4yOC4NIMA4AXUejjgzjcnm8hQADFNwjNBICFkV3vVFiIUlVMfVeIsTPRcLgorwomkNMwANZ5ECFZ41AFAkG4QqFZhMhy8ADUvAAjOVJFUQD9DsdiaSoniUQT+OLGbwagBmXgAMnVhIGwiGqTWOQa+1w9PF0n0VUk+OOOOSsvqSIg52R9z6HO5i1u9z4Fr+IlozHo8AOzQ8gNiajgwdwACF8ABJESdMBQQiESYAQkdYEkoKAA)

count が 4 に変更されたら、一度子コンポーネントがレンダリングされ、5、6 に変更されたとしても、再度レンダリングされないことがわかります。
さらに、親コンポーネントの `count` を子コンポーネントの props で渡すとしても、同じ結果です。

コンパイルされたコードを見ると、このような結果になる理由についてヒントを見つけやすいです。

```js
import { createComponent, insert, memo } from "solid-js/web";
insert(
  _el$3,
  (() => {
    const _c$ = memo(() => count() > 3, true);

    return () =>
      _c$() &&
      createComponent(ExpensiveChild, {
        count: count,
      });
  })(),
  null
);
```

```js
const _c$ = memo(() => count() > 3, true);
```

`ExpensiveChild` のレンダリングの条件に Signal が使われた場合はまず、条件式を Hoisting、そしてメモ化します。`count()` が 3 を超えた時点で内部的にメモ化するので、5、6 に変更されても、`_c$` は変更されることはなく、子コンポーネントもレンダリングされることはありません。

また、Signal 自体が独立しているリアクティビティなので、コンポーネント関数にてネストして細かく設定して処理することも可能です。

```jsx
const TodoApp = () => {
  const [todos, setTodos] = createSignal([]);

  const addTodo = text => {
    const [completed, setCompleted] = createSignal(false);
    setTodos([...todos(), { id: ++todoId, text, completed, setCompleted }]);
  };

  const toggleTodo = id => {
    const index = todos().findIndex(t => t.id === id);
    const todo = todos()[index];
    // 各 todo はネストされた Signal を参照しているので、正確な値をゲッター、独自でセットできる
    if (todo) todo.setCompleted(!todo.completed());
  };
};
```

リストを複製して置き換えることもなくなり、無駄なく必要最低限の DOM のみレンダリングができます。

では、関数内にて更新された Signal を検知して何か付加的に処理を行いたい場合を見てみましょう。
Solid にも React の`useEffect`のような `createEffect` にて Signal に依存する副作用を実行することができます。

```jsx
import { createSignal, createEffect } from "solid-js";

const Counter = () => {
  const [count, setCount] = createSignal(0);

  const id = setInterval(() => setCount(count() + 1), 1000);

  createEffect(() => {
    console.log("The count is ", count());
  });

  return <div>{count()}</div>;
};
```

`createEffect` に依存配列は存在しません。その代わりコールバック関数内にて Signal のゲッター関数が呼ばれたら、再度コールバック関数を実行します。
stale closures が存在しないので、フック外部のことについて気にする必要もなくなります。

コールバック関数内でゲッター関数を実行することが少しオーバーヘッドのように見えましたが、この発想はなるほど！と思いました。
Effectを自動的に適用しなおすアプローチは Vue、Svelte でも採用していて、比較的単純な動作で開発者のミスも減らせるのではないでしょうか。

## 最後に

React と同じ哲学を持っていて開発者の DX を向上しつつ、内部的に行う効果的なレンダリング処理をする Solid について
簡単に紹介しました。今回の `createSignal`、`createEffect` や他にも React 開発者ならおなじみの、かつ Solid の思想が感じられる魅力的な API がまだまだたくさんあるので、今後も期待できるフレームワークとして使い続けたいと思います。皆さんも是非活用してみてくださいね。

## 参考

- [SolidJS 公式ドキュメント](https://www.solidjs.com/docs/latest/api)
- [A Hands-on Introduction to Fine-Grained Reactivity](https://dev.to/ryansolid/a-hands-on-introduction-to-fine-grained-reactivity-3ndf) by [Ryan Carniato](https://dev.to/ryansolid)

## 画像引用

- Header Photo by [Terry Vlisidis](https://unsplash.com/@vlisidis?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/atoms?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)


React に似ているけど、もっと効率的？モダンフレームワーク Solid

フロントエンドエンジニアや、主流のフロンエンドフレームワークの React と Vue.js を触った経験がある方なら、仮想 DOM という言葉を聞いたことがあると思います。仮想 DOM はフロンエンド開発において、パフォーマンスを向上させるスタンダードになるほど、普及してきました。しかし、その一方で仮想 DOM を使わないトレンドも最近流行っています。この記事では、仮想 DOM について、また仮想 DOM の時代はもう終わりなのかを討論したいと思います。

---

![The Dom title image]({{ sitePrefix }}/assets/img/articles/2022-05-26-Is-Virtual-DOM-Outdated/the-dom.jpg)

## The DOM

最初に、DOM についてみてみましょう。[MDN docs](https://developer.mozilla.org/ja/docs/Web/API/Document_Object_Model/Introduction)によると、

> DOM (Document Object Model) はウェブ文書をノードとオブジェクトで表現します。そうやって、プログラミング言語をページに接続することができます。

すなわち、DOM のおかげで、HTML のノード上に直接作業し、Javascript と CSS を使って、Web ページでインタラクティブなコンポーネントを作成することができました。

### DOM ツリーの例

![DOM Tree Example]({{ sitePrefix }}/assets/img/articles/2022-05-26-Is-Virtual-DOM-Outdated/dom-model.jpg)

下記は一番シンプルな HTML 要素を編集する例です：

```javascript
document.xxx.xxx.element.innerHTML = "Hello DOM!";
```

### DOM 操作の懸念

上記の例の DOM ツリーと HTML コンテンツは簡単なので、ここまでは開発者やユーザーにとって特に問題はありません。

ただし、ユーザーに見える HTML 内容の裏側に、DOM 自身がたくさんの複雑な要素と属性を持っています。シンプルな HTML 内容を作成するにも、ブラウザがたくさんの作業をする必要があります。

さらに、子ノードが複数あった親ノードが変更された場合、親ノード全体を再構築し、全てのコンテンツをユーザーにレンダリングし直すことになります。

これは明らかに、余計にコンピューティングリソースを消費し、パフォーマンスに影響を与える要因であります。特に Web ページが多くノードを持って、もっとインタラクティブな変更があった場合です。

---

![The Dom Revolutions title image]({{ sitePrefix }}/assets/img/articles/2022-05-26-Is-Virtual-DOM-Outdated/the-dom-revolutions.jpg)

## The (Virtual) DOM Revolutions

### コンセプト

前述のように、DOM 操作のコストが高いので、それを回避する方法が必要です。例えば、開発者が使いやすいとともに、不要なロードを削減し、効率的にピンポイントで変更を DOM に反映できるゲートウェイみたいものがあれば助かります。そこで今日の本題である仮想 DOM の登場になります。

仮想 DOM とは、DOM と開発者の間にある、軽量的な抽象化レイヤーとなります。その中身実は、DOM ツリーと下のノードを表すために必要な要素と属性しか持たない Javascript オブジェクトの集合です。この抽象された DOM ツリーがあれば、普通の Javascript オブジェクトを操作するように、DOM のノードを追加、編集や削除が簡単かつ速くなります。

さらに、仮想 DOM により、レンダリングのプロセス実体も抽象化ができます。その上で、Web ブラウザーだけではなく、モバイルネイティブやその他の GUI コンポーネントの開発クロスプラットフォームの互換性も向上させました。

### アプローチ: diff & patch

多くの人は仮想 DOM を知ったのは React がきっかけかもしれませんが、実は仮想 DOM は React が発明したものではありません。多くのフレームワークやライブラリーが仮想 DOM のアプローチを採用しています。また、仮想 DOM の実装を専門的に扱うプロジェクトも進んでいます。例えば [virtual-dom](https://github.com/Matt-Esch/virtual-dom) と [millionjs](https://millionjs.org/)。

仮想 DOM の実装がそれぞれで異なりますが、アプローチの思想は大体似ています。根本的に二つのステップが diff と patch となります。

![Virtual DOM Approach]({{ sitePrefix }}/assets/img/articles/2022-05-26-Is-Virtual-DOM-Outdated/diff-patch.jpg)

DOM 操作コストの問題では、レンダリングし直す際に、変わってないノードが出来るだけ影響されないほど、効率が高くなります。なので、まず重要なタスクとして変更された箇所を特定することで、一般的に **diff** 計算と呼ばれます。変更内容を確定したら、それを実際の DOM 反映するためのもう一つタスクは **patch** 作業になります。

このプロセスの中に、**diff** 計算は最も中心的な部分です。基本の考えとしては全てのノードをトラバースし、変更前の仮想 DOM ツリーを変更後の内容を比較します。

下記のコードは diff を実装する簡単な例になります。 by [livoras](https://github.com/livoras/simple-virtual-dom):

```javascript
// diff compare two DOM tree
function diff (oldTree, newTree) {
  var index = 0 // current node index
  var patches = {} // record changes on each node
  dfsWalk(oldTree, newTree, index, patches)
  return patches
}

// depth-first walk through two DOM tree
function dfsWalk (oldNode, newNode, index, patches) {
  // compare the changes and record by index
  patches[index] = [...]
  diffChildren(oldNode.children, newNode.children, index, patches)
}

// compare child nodes
function diffChildren (oldChildren, newChildren, index, patches) {
  var leftNode = null
  var currentNodeIndex = index
  oldChildren.forEach(function (child, i) {
    var newChild = newChildren[i]
    currentNodeIndex = (leftNode && leftNode.count) // calculate node index
      ? currentNodeIndex + leftNode.count + 1
      : currentNodeIndex + 1
    dfsWalk(child, newChild, currentNodeIndex, patches) // traverse all child nodes
    leftNode = child
  })
}
```

違う仮想 DOM の実装は、各自のアルゴリズムを持って、diff のパフォーマンスを最適化されています。彼らの努力のおかげで、仮想 DOM はどんどん成熟に進化し、今なら特に仮想 DOM のことを考えずに開発を進めることができます。

ただし、仮想 DOM はいつも唯一の解決法ではありません。

---

![The DOM Resurrections title image]({{ sitePrefix }}/assets/img/articles/2022-05-26-Is-Virtual-DOM-Outdated/the-dom-resurrections.jpg)

## The DOM Resurrections

### 新世代の夜明け

仮想 DOM は既にここまで進化され、業界標準にもなるぐらいだったのに、なぜ「仮想 DOM の時代はも終わり」というでしょう？　先に [stateofjs](https://2021.stateofjs.com/en-US/libraries/front-end-frameworks/) という、フロントエンドフレームワークやライブラリーについてのオンライン調査結果から面白い事実を見て見ましょう。

![Front-end Frameworks Rank]({{ sitePrefix }}/assets/img/articles/2022-05-26-Is-Virtual-DOM-Outdated/ranking.jpg)

調査結果によると、過去 5 年間では、React、Angular と Vue.js はずっと**一番利用されてる**ランキンングで上位 3 位でした。これは多分皆さんの予想通りだと思います。しかしながら、2020 と 2021 年度の**満足度**や**興味**のランキングを見ると、あまりなじみのない二つの名前 [Solid](https://www.solidjs.com/) と [Svelte](https://svelte.dev/) がトップに上がりました。そして、いずれも**仮想 DOM**を使わずに高速で高性能を実現したと主張しています。

### DOM に戻る

どうして Solid と Svelte は実際の DOM を使いながら高いパフォーマンスを提供できたですか？大まかに二つの理由があります：

#### 1. DOM 自体はそんなに悪くはない

話したように、DOM は必要のないリソースを消費することがあり、特に複雑な変更がある場合コストが高いです。でも、今のパソコンとブラウザも進化して、DOM の操作は実際のユーザーの目から見ると、そんなに変わりがないです。Jason Knight 氏が [DOM パフォーマンス](https://levelup.gitconnected.com/the-live-dom-is-not-slow-bad-or-wrong-web-developers-are-2bf86c3b9e2e)のテストを実行する記事があります。それは DOM、Doc Fragment と Shadow DOM の比較になりますが、私たちはその中から手がかりを得ることもできます。もし開発者が DOM 操作を慎重に処理すれば、実際の DOM でも効率になれます。

\* _Doc Fragment と Shadow DOM_ は仮想 DOM とは別物です。この記事では詳細を割愛します。

#### 2. 仮想 DOM もそれなりにコストがかかる

仮想 DOM は確か効率的ですけれども、完全に不要なリソースを消費しないわけではありません。例えば、diff のアルゴリズムの場合、ただ一つ小さい変更でも全てのノードを見比べするのは消してスマートなやり方ではないです。加えて、指定されたフォーマットでコンポネートコードを書いて、仮想 DOM を作成して、そしてランタイムでレンダリングするプロセスも、実にブラウザーに負担をかけています。

Svelte の作者、Rich Harris 氏が書いたように：

> '仮想 DOM は大抵、十分に速い'というほうがより近いですが、いくつかの注意点があります。... Svelte は、実行時にこの作業をするのを待つのではなく、どのように変更されるかビルド時にわかるコンパイラです

### 出来るだけ簡単に

それなら、仮想 DOM は自分達に合うかどうかどうやって分かるでしょう？実際には、問題を複雑に考える必要がありません。出来るだけ簡単に行けば良いです。

どちらのアプローチもより良い開発環境のためで、仮想 DOM もその一つにすぎないです。Ryan Carniato 氏の記事に書いた通りに、_すべてのアプローチには、自身なりの妥協があります。参考するのはパフォーマンスやサイズではなく、代わりに、**開発者のエクスペリエンス**を検討する必要があります。_

したがって、一番大事なのは、あなたとあなたのチームがどのやり方で開発がしやすいかということです。

---

## 結論

仮想 DOM の時代はもう終わり？答えは、**もちろん NO** です。

仮想 DOM は既に最適化され、ほとんどの場面でも充分に使えます。依然として、それも選択肢の一つです。仮想 DOM に関しては決して true or false の問題ではありません。

よく使われるかつもっとコミュニティサポートを持つベストプラクティスを従って、プロジェクトを成し遂げるのは重要です。その一方、この急速に変化しているフロントエンドの世界では、新しいものを挑戦し続けるのも良いじゃないですか？あなたが次のベストプラクティスを作るかもしれません。

---

## 参考記事

- _[Virtual DOM is pure overhead](https://svelte.dev/blog/virtual-dom-is-pure-overhead) by Rich Harris_
- _[Reports of the Virtual DOM’s Death are Greatly Exaggerated](https://javascript.plainenglish.io/reports-of-the-virtual-doms-death-are-greatly-exaggerated-2206d00beead) by Ryan Carniato_

## 画像引用元

- _Header Photo by [Federica Galli](https://unsplash.com/photos/aiqKc07b5PA?utm_source=unsplash&utm_medium=referral&utm_content=creditShareLink)_
- _DOM Tree image on [Wikipedia](https://en.wikipedia.org/wiki/Document_Object_Model)_
- _Diff and Patch image by [Chameera Dulanga](https://blog.bitsrc.io/incremental-vs-virtual-dom-eb7157e43dca)_
- _Front-end frameworks and libraries Rankings by [stateofjs](https://2021.stateofjs.com/en-US/libraries/front-end-frameworks/)_

仮想DOMの時代はもう終わり？


# AI の産業化とデータの課題

AI が事業に活用されるようになって久しいですが、実のところ、現在の AI 事業はほぼラボの延長です。さまざまな産業の中で共通化され、相互運用性を持ったツールとして使われている状況とは、まだまだなっていません。
その理由はデータをとりまく環境にあるのではないかと思います。データの見直しなくして、AI の産業化はありません。

## AI の産業化とはなにか

さまざまな業種のなかで、すでに AI が使われはじめているのは確かです。例えば画像認識技術によって、スマートフォンのロックは解除されますし、スマートスピーカーは、あなたの声を識別して応答するなど、さまざまなケースがあるでしょう。

しかしそれらは、産業全体からみるとごく一部に過ぎません。
農業・漁業・建設業・製造業・運輸業・小売業・金融業・不動産業・教育・研究・技術サービス、これらの各業種では、確かに AI の成果は聞こえ始めていますが、それらはまだまだ点在しているような状況です。

ここでいう「産業化」の定義は曖昧ですが、一般的には工業化と同じ意味でも使われます。つまり、「AI の産業化」とは、産業全体において AI が入り込み、富を生み出すような状況のイメージでここでは捉えています。

しかし現在のところ、少数の専門家が、特定の事業領域において AI を使って成果を上げる、いわゆる研究開発の成果を既存の業務に適用させるのが実情です。

多数の AI 人材が、部門や業種を超えたさまざまなデータを取り込んで、最大の効果を得るのには、まだまだ難しい状況にあると思います。

いっぽう、そうした状況に対し、AI 技術にそこまで習熟しなくとも、ある程度の結果を出すことのできる、AutoML といったソリューションが生まれ、気軽に学習や最適化を行える環境にはなってきました。

しかしそうした AI に関するツールだけでは、この問題は解決することはないように見えます。

これらの状況から推察するに、AI の産業化には

- 体系的データ管理
- 包括的なデータの民主化
- 企業としてのデータガバナンス

といった課題への取り組みが求められると考えられます。

# 産業において AI はどこまで活用されているか

昨今、さまざまな産業において AI がキーとなるとされてきましたが、実際のところはどうでしょうか。

AI には潤沢なデータが必要です。しかし実際、それらのデータはどのようにデータ基盤に保持されているでしょうか？

例えば、ある EC サイトがあったとします。そこでの売上やユーザ行動といったデータは、ある程度 DWH 的なものに保持され、活用されるようになっていることでしょう。

しかしそこで疑問が生まれます。これらをどのように AI と接続するのがよいでしょうか。

AI の現場は実際のところ、まだまだラボによるピンポイント的な活用にとどまっているように見えます。AI の力の源泉は、学習データにあるはずです。しかしながら学習対象となるデータは、ラボに閉じているケースが多いように思います。

本当の意味で AI を産業化するためには、まずは企業内で AI を意識してデータを整備しなければなりません。

## 体系的データ管理

現在のところ、学習のためのデータの流れは、目で追える範囲のパイプライン構造ではあるものの、それぞれのラインでの処理まで含めるとやはり複雑です。データの構造化やモデリングはそこそこ困難ですし、場合によっては非構造化データも含めた統合についても考えなければなりません。

そして、さまざまな AI ユースケースに対応できるような、パイプラインの再利用には、まだまだ超えるべき壁があるように感じます。それはデータスキーマの共通化が困難なだけではなく、AI モデルの求める形式も発展途上であることも影響しています。

### そのメタデータは救いとなるか

データ環境の全体に適用可能な、魔法のようなメタデータ管理手法は今のところ無いように思います。おそらくそこにあるのは、テクニカルなメタデータばかりで（それはそれで重要ですが）、データを意味ある情報として捉えたときの、データ系譜（リネージュ）についての整理はどうでしょうか。

たとえば、データソースに変更が起きた場合、パイプライン全体に影響が起き、結果的にダッシュボードの信頼性に影響するでしょう。そうしたケースを考えると、データ系譜の体系的な管理がなされているかは、データシステム設計において重要な指標となります。

### KPI をどう扱いますか

従来の DWH 領域で、KPI といったビジネス指標を扱うのは自然な流れでしょう。しかし私たちの今の課題は、それらと AI との接続です。どのようにデータレイクとデータマートを設計すれば、これらを効率的に扱えるでしょうか。

## 包括的なデータの民主化

データの民主化とは、一般的には組織内で自由にデータを利用できる状態のことを指します。これは、DHW の世界ではさまざまな BI ツールより実現できています。（できていないこともありますが）

しかし私たちの課題は AI におけるデータの民主化です。AI の学習目的で用いられるデータは、DWH に格納された分析データだけではなく、DHW 格納以前の段階の、非構造化データが含まれるのが一般です。そうした構造化され整理される以前の、あらゆるタイプのデータに、あらゆるユーザがアクセス可能となる環境を目指す必要がありますが、ここにもいくつかのハードルが存在します。

### データプロビジョニング

データプロビジョニングとは、例えば IoT 機器などのデータを、データレイクに接続して抽出することを指します。ここでの課題は、テクニカルな側面では I/F やアクセス権の定義などが考えられます。そして、エンドユーザの協力の下、パイプラインを開発することになりますが、データの所有者を含めた調整が発生するため、多くの反復プロセスが発生し得ます。したがって、これらのデータを利用する予定の AI プロジェクトにとって、大きなボトルネックとなりうるポイントとなってしまいます。

### データエンジニアリング

狭い意味でのデータエンジニアリングとは、データモデリングと結合、そしてクレンジングを指します。基本的には、一部のデータサイエンティストとデータエンジニアによって進められますが、ここにも困難がつきまといます。

データエンジニアリングには、ソースシステムにおける、データ構造に関する知識が求められます。そしてそれらを扱う包括的なプログラミング能力も求められ、技術の総合格闘技のような領域になりつつあります。

### データ探索での課題

データから情報と知見を引き出すためには、データサイエンティストは R や Pandas、ときに Spark Job を扱うでしょうし、データアナリストは BI ツールを操作することでしょう。

しかしここでも問題が起きます。扱っているデータの品質はどこまでのものなのか、ビジネス上の意味の詳細はどうなっているのか、データエンジニアに確認しなければならないことでしょう。そしてそのデータに法律的に問題は有りませんか？それはおそらく法務部に確認することになるでしょう。

## 企業としてのデータガバナンス

データガバナンスとは、データを企業資産として扱うものとして組織構造を定義することを指します。

そのデータレイクにあるデータの所有者は誰ですか？
それは大抵の場合、ソースシステムのデータ所有者のはずです。

つまり、データレイクにあるデータを統合して扱うためには、それぞれのデータ所有者の承認が必要です。したがって、データは企業資産ではなく、より小さな人格の資産として取り扱われます。

たとえば、ある部品を製造する企業があったとします。そこでは製造部門のデータと、ビジネス部門のデータを組み合わせて、AI 予測による保守サービスを展開するとします。この場合、データの所有者であるそれぞれの部門がデータに責任を追う必要がありますが、データの利用方法自体が当初の想定外である可能性があります。また、それらを組み合わせて AI 予測保守で利益を生んだとき、メリットはエンジニアリング部門に発生します。このとき組み合わせたデータの所有権は、元のデータソースの所有権は切り離して考えるのが妥当と思われます。

こうした部門間などの調整を含めたデータスチュワードシップについては、これまでは個人情報や商品情報などを中心として扱われてきました。しかしこれからは業務プロセスで発生するあらゆるデータに対して、企業全体としてポリシー設定が求められるでしょう。

# AI 時代のデータエコシステムを求めて

これまで課題となる点を整理してきましたが、実際のところこれらを解決する妥当な結論や、スタンダードなフレームワークがあるわけではありません。

これらの問題領域について、MLOps が回答となるかと言われれば、あくまで Techie な側面なのかなと感じます。

引き続きデータエンジニアとして、これらの課題に役立つようなアイディアを、日々の業務の隙間からでも、作り出せていけたら良いなと、そう考えています。

# Links

_[Data Warehousing in the Age of Artificial Intelligence](https://learning.oreilly.com/library/view/data-warehousing-in/9781491997963/)_

_[A Chat with Andrew on MLOps: From Model-centric to Data-centric AI](https://www.youtube.com/watch?v=06-AZXmwHjo)_

_[Article Photo by Luke Chesser](https://unsplash.com/photos/JKUTrJ4vK00?utm_source=unsplash&utm_medium=referral&utm_content=creditShareLink)_


AIの産業化とデータの課題


初めまして、株式会社モンスターラボ（以降、モンスターラボ）フロントエンドチーム TechLead の安です。

今日はコーディングテストに役立つチートシートを電撃公開します。

もしコーディングテストに恐れを感じているなら、この記事を見たらそのような心配がなくなると思います。
評価項目に適切な時間配分で最高の評価を受けることができるからです！

![]({{ sitePrefix }}/assets/img/articles/2022-03-25-Coding-Test/tokyo-office.png)

**_この記事で説明しているコーディングテストはモンスターラボ東京本社でエンジニア採用の時に使用しているものです。職業の区別や拠点によって、コーディングテストがない場合や異なる場合があります。_**

## コーディングテストの目的は？

口頭で進行する面接で確認できない部分を見るためです。ソースコードは、個人のスタイルと経験の集約体ですから、どの程度のレベルに達しているかを把握することが可能です。

![Photo Christopher Gower]({{ sitePrefix }}/assets/img/articles/2022-03-25-Coding-Test/christopher-gower-m_HRfLhgABo-unsplash.jpg)

_Source [Photo by Christopher Gower](https://unsplash.com/photos/m_HRfLhgABo)_

モンスターラボの TechLead はエンジニアの能力とマネージャーとしての能力の両方が必要です。複雑で深いソースコードも優れていますが、一般的な観点から誰が見ても分かりやすく、今後の運用に良いのかが評価項目に含まれています。これはチームワークを基本とするモンスターラボのチーム体制に適切な人材かを評価する尺度でもあります。

簡単に言えば、モンスターラボのコーディングテストは正解不正解があるようなアルゴリズムのようなテストではありません。モンスターラボが望む人材像と合うかを見るための事です。11 件の評価基準によって、平均点を元に採点者の判断で合格するかどうかが決まります。ここで平均点も重要ですが、チームプレーができるような一緒に働きたい人材なのかが重要なポイントになります。

![]({{ sitePrefix }}/assets/img/articles/2022-03-25-Coding-Test/role-image01.jpg)

_以下の評価基準は 2022 年 3 月を基準にしています。課題によっては一部変更されることがあり、今後変更される可能性がありますのでご注意ください。_

### 全体的な項目

広い意味で全体的の確認です。領域によっては固定された項目もあるので、採点に含まれない場合があります。

#### General Info

ソースコードの一般的な情報に関する項目です。プラットフォーム、フレームワーク、言語などを確認しますが、課題によって一般的な環境であり、特別な部分がない場合は採点項目から除外します。

たとえば、フロントエンドの場合、Web アプリケーションに関連する一般的な環境は共通であるため、採点には含まれません。

#### Architecture

どのアーキテクチャを使用したかについての項目です。さまざまなアーキテクチャパターンがあるので、基本的にはそのようなアーキテクチャパターンを意図的に使用したかどうかを見ています。

厳密な意味でアーキテクチャを評価することは難しく、そのような部分まで要求するわけではないので、一般的に使用するモダンアーキテクチャの中で一つを使って作成されているかを確認します。

![Photo by JOHN TOWNER]({{ sitePrefix }}/assets/img/articles/2022-03-25-Coding-Test/john-towner-3Kv48NS4WUU-unsplash.jpg)

_Source [Photo by JOHN TOWNER](https://unsplash.com/photos/3Kv48NS4WUU)_

### 詳細な項目

提出されたソースコードの詳細を確認する項目たちです。

#### Setup/Build

**「プロジェクトを Setup して駆動することに問題はないですか？」**

Setup とビルドに関する項目です。README などを元にした初期動作の確認なので、手順通りに進んだときに問題なく実行されると評価点が得られます。開発を進めてみるとローカルに依存する場合が発生する可能性がありますが、これらの部分に対して正しく処理したかどうかを見ることです。

可能であれば、開発を進めていたローカル以外の環境で Setup およびビルドを進めて問題がないことを確認してください。プロジェクトビルドに必要なツールやライブラリがある場合は、その部分についても明示してください。言語のインストールまで説明する必要はありませんが、一般的なもの以外に必要な部分があれば書いた方がいいです。

たとえば、環境変数として設定する必要がある場合は、その環境変数を実行`command`に含めるとか、環境変数の発行が必要な場合は、その部分に対する手順を書くなどの実行をするために追加的に必要な部分についての確認です。

ただし、環境変数については、セキュリティ的に秘密にする必要があるものについてどのように扱っているかを見たりもします。

#### Dependency/Library

**「プロジェクトの依存関係とライブラリはどうですか？ あなたならそうしますか？」**

ライブラリに関する項目です。プロジェクトに適切なライブラリと依存関係を設定しているかどうかを確認しています。特に、使用したライブラリが常に管理および更新されているかどうかを確認します。もはや実際の業務で使用するのが難しい古いライブラリを使用している場合は、減点要因になります。

`javascript`フロントエンドを基準に説明すると、`dependencies`と`devDependencies`の区切りを適切にしたのか、ライブラリのバージョンが古いのではないかを確認しています。古いライブラリの判断は難しいですが、基本的な判断基準は LTS（Long Term Support）または npm の Versions を確認しています。ライブラリによって違いがあるのでその部分も考慮しています。

例えば、使っている`node`の Version は？`gulp`を使っているなら、`3.9`以前なのか`4.x`以降なのかの区分です。

React を例にして見ると、

> 新しいメジャーがリリースされると、通常、以前のメジャーの新しい修正のリリースを停止します。唯一の例外は、重大なバグ（セキュリティの脆弱性を含む）です。

> Once a new major is released, we generally stop releasing new fixes for a previous major. The only exception is absolutely critical bugs (including security vulnerabilities). — [Major version LTS dates](https://github.com/reactjs/reactjs.org/issues/1745#issuecomment-466767389)

上記の引用によると、新しい major version がリリースされると、以前の major version は基本的にこれ以上更新されないと言っています。

したがって、2022 年 3 月基準では、React の LTS は最新の major である React 17 といえるので、React 17 以前のバージョンを使用しているかを確認しています。

#### Tests

**「テストはありますか？ 作成されたテストは`pass`判定をしていますか？」**

テストに関する項目です。 作成したすべてのソースコードに対してテストを作成する必要はありません。重要なロジックについてユニットテストが作成されているのかを評価しています。

#### Readability

**「コードの可読性はどうですか？」**

読みやすさに関する項目です。 初見した時、全体的な流れを理解しやすく書かれているかを見ています。

#### Code Style

**「コードスタイルが対象プラットフォームに適しているか？」**

プラットフォームによって異なりますが、同様に現代的で一般的な意味で適切に作成されているかを見ています。一貫して同じスペース、タブ、インデント、垂直ソートなどを使用しているかを基本に使用する文法にも一貫性があるのか（この部分は eslint、tslint、beautify などでも問題ないです）、古い文法と新文法の混用がないかなどを基準にしています。

javascript で説明すると、関数を宣言する時に `let` と `const` を使いながら、ある部分では `var` を使うかなどの場合です。

#### Code Comments

**「コメントがありますか？」**

テストの項目と同様に、すべてのロジックに対するコメントを評価するのではなく、コメントが必ず必要な重要なビジネスロジックなどに適切なコメントを作成しているかを見ています。 コメントの言語は英語や日本語どちらでも構いません。

#### Code Structure

**「ソースコードの構造はどのように構成されていますか？」**

意図をもって適切なツリー構造になっているかを確認しています。どのようなツリー構造でも構いませんが、使用するプラットフォームやフレームワークに合わせて理解しやすく、今後の拡張性を考慮した形を基準に評価しています。

極端な例として、すべてのファイルを 1 つのフォルダに管理している場合、減点要因になります。

![Photo by Yann Jacobsen]({{ sitePrefix }}/assets/img/articles/2022-03-25-Coding-Test/yann-jacobsen-j3KhPniqdXQ-unsplash.jpg)

_Source [Photo by Yann Jacobsen](https://unsplash.com/photos/j3KhPniqdXQ)_

### その他

メンテナンス、そして採点者の経験に基づいて追加の要素を採点する項目たちです。

#### Maintenability

**「作成されたソースコードに基づいてメンテナンス性はどうですか？」**

ソースコードの構造、コードスタイル、可読性などに基づいて機能を追加・変更・削除することが便利なのかを確認します。 一般的な意味で OOP（Object-oriented programming）を活用したロジックを推奨し、ツリー構造などを基準に誰でも簡単に理解して拡張できるかを評価しています。

#### Other consideration

上記の 10 個の採点項目に含まれていないか、含まれていても各項目を連携した時に追加点として考慮できる部分が対象となります。またはコーディングテストの必須項目ではないが、対象課題に追加の機能が含まれている場合も対象となります。

さまざまな領域があるため、例を挙げることは困難ですが、実際のサービスに展開した時にユーザーの満足度を満たすか、繰り返し作業を除去する DevOps 的な要素があるのかなどです。

![]({{ sitePrefix }}/assets/img/articles/2022-03-25-Coding-Test/tech-1.png)

## 最後に

これまで、モンスターラボコーディングテストの採点基準について説明しました。

最小限の基準としては業務遂行に問題のないレベルかを確認しており、一般的な基準としては現在のトレンドをもとに個々の確立されたノウハウを適切に使用しているかを見ています。

言葉を変えると、モンスターラボはコーディングテストで 100％確実な正解を要求するのではなく、製品としての完成度と熟練度を評価尺度と考えています。

![]({{ sitePrefix }}/assets/img/articles/2022-03-25-Coding-Test/tech-2.png)

チートシートというには長すぎる文になりましたが最後に個人的にアドバイスを伝えたいと思います。評価されるためのソースコードを書くことではなく、ユーザーに公開することを前提として自分がユーザーでも使い続けたいと考えることができる製品を作ってください。

採点者はすべて現場で活躍しているエンジニアなので、そのような真心はソースコードを通じて十分に伝達されます。製品への愛着と熱意が最大の評価基準だと思います。

それでは、モンスターラボで仲間として出会える日を楽しみにしています。今後ともよろしくお願いします。

## 参考

- [モンスターラボ採用ページ](https://www.join.monstar-lab.com/)

_[Article Photo by Clay Banks](https://unsplash.com/photos/8q6e5hu3Ilc)_


「コーディングテスト」チートシート電撃公開

Introduction to GPUs with OpenGL


モンスターラボに入社をして約半年が経ちました。働く中で感じた『モンスターラボで TechLeadとして働く環境』がどんなものかをお伝えできればと思います。私個人の感想ですが、これからモンスターラボに興味を持つ方の参考になれば幸いです。

## 多様性

モンスターラボで働く多くの方が感じているのではないでしょうか。

世界各地に拠点を構えているモンスターラボでは、日本語以外の様々な言語でのコミュニケーションがされており、同じプロジェクト内でも国の垣根を超えてチームビルディングが行われています。日本人の価値観に固執することなく、様々な国や地域の人と意見交換ができる環境に刺激を受けました。

各国やチームで連携するため、カルチャーブックと呼ばれる、モンスターラボの文化を共有する取り組みを行なっています。多様なチームの強みを理解し、その上で、お互いの強みを生かせるような業務接続を自主的に行うことができる組織・開発チームになることを目指しています。

一方で、言語の違いに苦労することもあります。基本的には日本語と英語を使うことが多いです。ただ、福利厚生で英語を勉強する支援も整っており、これから英語を勉強したい方は、自分の言語スキルを伸ばすチャンスになります。

## TechLeadの仕事

TechLeadの仕事内容は、一言で言うとサッカーのミッドフィルダーのような仕事です。  
具体的には、技術選定や各担当とのコミュニケーションが大きな役割になります。プロジェクトや得意分野によって、担当範囲は様々です。一例として、プロジェクト内でTechLeadが担当する範囲に色をつけた図になります。  

![]({{ sitePrefix }}/assets/img/articles/2022-02-17-Work-at-ML/image01.jpg)

コーディングが得意であれば実装を担当し、設計が得意であれば設計書を書くこともあります。技術に関して、プロジェクトをうまく進めるための司令塔のような存在になることが多いです。上流工程において、お客様と話しながら仕様を決めたり、技術の要の部分を作っていくのでとても重要なポジションになります。ビジネスの観点で技術支援をしていきたい人や、新しい技術を提案してより良いプロダクトを作っていきたいという人は、魅力的なフィールドになり得ます。


## オフショア開発

自社グループ内にオフショア拠点を持っているため、オフショア開発に積極的に取り組んでいる風潮があります。  
初めての経験で不安もありましたが、プロジェクトメンバーに通訳のようなコミュニケーターが配属しているためスムーズにプロジェクトを進めることができました。
オフショア開発は、高品質かつ低価格で提供できる手段であり、グローバルな視点で開発を進めています。お客様から多くの案件をいただく一つの要因になっています。

## クライアントワーク

モンスターラボでは、クライアントワークに取り組む機会が多くあります。

企業のデジタルトランスフォーメーションをビジネス戦略から携わることがあります。問題を解決するために、新しい技術を提案しチャレンジする機会に多く出会うことができます。  
言われたことだけをやるだけの仕事はほとんどなく、自分から技術の提案やキャッチアップ能力が求められます。自由な風潮や環境で仕事ができる分、広い範囲の意思決定を経験することができます。また、たくさんの業界を経験できる特性から、様々な技術の習得が可能です。プロジェクトを経験するたびに自身のスキルが広がっていく感覚は面白いと思いました。

## フルリモート

フルリモートで作業やコミュニケーションが完結できます。本社から離れて仕事をしている方も少なくはないです。もし、話をしたい場合はSlackで声をかけて、ハドルミーティングや Google Meet などで気軽に話すことが多いです。また、休憩もとりやすく、自分のペースで仕事ができることも利点じゃないでしょうか。

## いい人が多く、相談しやすい

とても人間関係が良好で、上長との距離も近く、いつでも相談に乗ってもらえる環境があると感じています。  
メンター制度を導入しており、仕事や生活面などの不安などを気軽に相談することができます。
例えば、仕事量の調整やキャリアプランに沿ったスキルアップ、仕事とプライベートの両立ができるような働き方などを親身にアドバイスいただいたりしました。  
自分だけだと難しい問題は、技術や分野ごとにSlackのチャンネルが用意されており、質問をすれば世界各国のモンスターラボメンバーからアドバイスをいただくこともでき、とても丁寧に教えてくれます。

## 入社時期関係なく意見を発信できる

ポテンシャルを発揮するために、意見を自由に発信して反映することがしやすい環境です。  
自ら手を挙げて、議論できる場所があり、活躍の場を広げることが可能のように思います。

## 子育て世代に優しい

子育てしながら働いている人に、とても寛容だと感じました。  
裁量労働制を採用しており、働く時間を柔軟に設定することが可能です。家庭の予定に合わせて仕事の調整をしたり、仕事の仕方を生活に合わせてカスタマイズしやすい環境は、とても衝撃でした。男女問わず育休を取得しており、時代にあった働き方が可能です。これも多様性のある会社だからこそ実現可能なのでしょう。

## 最後に

外からではわかりにくい、モンスターラボを少しでもお伝えできればと思い、感想を述べました。これからキャリアを考える上で参考になれば嬉しいです。  
モンスターラボでは、”多様性を活かし、テクノロジーで世界を変える”のミッションに共感できる人材を募集しています。興味がある方はモンスターラボ採用ページをご覧いただき詳細を確認してみてください。

## 参考

- [モンスターラボ採用ページ](https://www.join.monstar-lab.com/)

_[Article Photo by fauxels](https://www.pexels.com/@fauxels)_


モンスターラボの環境でTechLeadとして働くこと


こんにちは。モンスターラボのQAチーム・テスターラボの秋元です。

この記事では、アジャイル開発におけるテスト（以下「**アジャイルテスト**」）について、ISTQB Foundation Level Agile Tester（※1）のシラバスを参考にしながら、以下の3つのテーマで整理します。
- ウォーターフォール型開発のテストとの違い
- 高い効率性を実現するには？
- アジャイルテストと第三者目線のジレンマ

※1 ISTQB（International Software Testing Qualifications Board：国際ソフトウェアテスト資格認定委員会）認定のアジャイルテストに関する資格

## ウォーターフォール型開発のテストとの違い
### ウォーターフォール型開発のテスト
ウォーターフォール型開発（以下「WF」）では、要求分析・設計・開発・テストの各工程で、成果物が確定してから次の工程に進みます。Waterfallと言う名の通り、前工程に戻ることは想定されていません。

テストに関しても、単体テストの完了を条件として結合テストを開始し、結合テストの完了を条件としてシステムテストを開始・・・というのが基本です。

また、図1で示すように、要件定義の成果物がシステムテストのテストベース（※2）となり、基本設計の成果物が結合テストのテストベースになる・・・といった工程間の関連性があります。

<figure>
<img src={{ sitePrefix }}/assets/img/articles/2022-02-10-What-is-QA-in-an-Agile-Process/fig1_vmodel-jp.jpeg>
<figcaption>図1. V字モデル</figcaption>
</figure>

※2 テスト設計のインプットになる資料や情報

クライアントが直接プロダクトを触れるのは、受入テストの段階です。案件の規模にもよりますが、すべての工程で1年以上かかることも珍しくありません。

### アジャイルテストは短いスパンで繰り返す
一方、アジャイル型開発では、**数週間程度の短い開発サイクル**（**イテレーション**）ごとに動くプロダクトをリリースし、フィードバックを受けながら改良していきます。

テストも各イテレーション内で実施します。短期間でテスト設計から実施までを完了させるために、**高い効率性**が求められます。

<figure>
<img src={{ sitePrefix }}/assets/img/articles/2022-02-10-What-is-QA-in-an-Agile-Process/fig2_agile-model.jpeg>
<figcaption>図2. アジャイルモデルのイメージ</figcaption>
</figure>

### アジャイルテストのテストレベル
WFでは結合テスト、システムテストなどのテストレベルが明確に定義されていますが、アジャイルテストでは少し異なります。下表は、ISTQB Foundation Level Agile Testerのシラバスの説明を要約し、私の解釈を少し加えたものです。

テストレベル|実施者|実施タイミング|実施内容
--|---|---|--
単体テスト|開発者|イテレーション内|コンポーネントレベルの確認
フィーチャ検証テスト(*3)|開発者 or QA|イテレーション内|ユーザストーリーの受入基準を満たすことを確認
フィーチャ妥当性確認テスト(*3)|開発者・QA・ビジネスステークホルダ|イテレーション内|フィーチャーが利用に適していることを確認
システムテスト|QA|イテレーション外|ユーザーストーリーをテストベースとした機能テスト、非機能テスト
受入テスト|ユーザー全般|各イテレーション、またはすべてのイテレーション完了後|α/βテスト、ユーザ受入テストなど

上記をすべて必ず実施するのではなく、プロジェクトのニーズに応じた実施内容を検討し、計画することが求められます。

また、各イテレーションで実施したテストケースを積み上げて、リリース前に**リグレッションテスト**(*4)を行うケースもあります。

*3 『ISTQBテスト技術者資格制度 Foundation Level Extension シラバス アジャイルテスト担当者 日本語版』の用語を使用
*4 プログラムの一部に対する変更が、システムに意図しない影響を及ぼしていないか検証するテスト

## 高い効率性を実現するには？
### 仕様変更に対応しやすいテスト技法 ・・・ 探索的テスト
「アジャイルソフトウェアの12の原則」(*4) の1つに、

_”要求の変更はたとえ開発の後期であっても歓迎します。”_

という原則があります。WFでは考えられませんが、アジャイル開発ではプロダクトの価値を高めるために仕様変更は許容されます。

開発の後期で仕様変更が発生すると、**テスト設計の修正やテストのやり直し**が必要になります。最悪の場合、一生懸命作ったテストケースがすべて水の泡に・・・ということもあり、無駄なコストになります。

このような状況で有効なテスト技法として、**探索的テスト**があります。

*4 [アジャイル宣言の背後にある原則](https://agilemanifesto.org/iso/ja/principles.html) から引用

従来の**スクリプトテスト**では、テスト手順や期待値などが明記されたテストケースを使用しますが、探索的テストではテストケースを使いません。と言っても、アドホックテストやモンキーテストのようにやみくもに実施するテストとも異なります。
下表は、スクリプトテストと探索的テストの違いを整理したものです。

テスト技法|テストケース|メリット|デメリット  
--|---|---|--
スクリプトテスト|あり|・結果の個人差が出にくい<br>・網羅性を担保できる|・仕様変更時の手戻りが大きい
探索的テスト|なし|・経験に頼り効率的にバグを検出できる<br>・テストケース作成の工数が不要|・実施者に一定のスキルが必要<br>・網羅性の担保が難しい

探索的テストにはいくつかのアプローチがありますが、テスターラボでは**テストチャーター**と呼ばれるテストの指針が書かれたドキュメントを用意し、これに沿ってテスト実施することが多いです。テストチャーターを使用することで経験の少ない実施者にもヒントを与えることができ、また定量的な分析も可能になります。

探索的テストはアジャイル開発にフィットするテスト技法ですが、表のとおりデメリットもあるため、**重要な機能はスクリプトテストを実施する**など、使い分けが必要です。

## 何度も実施するリグレッションテストを自動化
アジャイル開発ではコードの追加・変更・削除が多く発生するため、デクレードが起こりやすくなります。よって、**リグレッションテスト**の重要度が増します。

多くの場合、リグレッションテストでは過去に作成したテストケースを使い回して繰り返し実施するので、テストを自動化することで実行工数の削減が期待できます。これにより、QAは**新規機能や変更箇所のテストに集中できる**という利点もあります。

また、PRやデプロイのタイミングで自動テストを実行することで、バグの早期発見も可能になります。

アジャイルチームのQAには、自動テストの知見も求められます。

## アジャイルテストと第三者視点のジレンマ
一般に、**QAの独立性が高いほどバグを効率的に検出できる**と言われます。開発者と分離された環境で、より客観的かつ批判的な視点でプロダクトを評価できるのです。

一方、アジャイル開発では、QAはアジャイルチームの中でビジネスステークホルダや開発者と協調してプロダクト・プロセスの品質向上に取り組みます。つまり、**独立性とのトレードオフ**が生じることになります。

### ISTQBが示すアプローチ
アジャイルチーム内で協調しながら、独立性を維持するにはどうすれば良いか？

このジレンマについて、ISTQB Foundation Level Agile Testerのシラバスでは、

_”独立かつ分離したテストチームを持ち、そのチームに属するテスト担当者に、プロジェクトの開始から長期にわたってアジャイルチームを担当させる”_

というアプローチを示しています。

役割分担として、アジャイルチーム内のQAはプロダクトへの理解やチームメンバーとの関係性を深め、アジャイルチーム外のQAは自動化や非機能テストなど、イテレーションに依存しない活動を担当します。

<figure>
<img src={{ sitePrefix }}/assets/img/articles/2022-02-10-What-is-QA-in-an-Agile-Process/fig3_qa-team-jp.jpeg>
<figcaption>図3. アジャイルモデルのイメージ</figcaption>
</figure>

ただしこの場合にも、アジャイルチーム内のテスト担当者には一定の客観性、批判的目線が求められます。でなければ、QAとしてアジャイルチームに参加している意義がなくなってしまうでしょう。

## まとめ
アジャイルテストの特徴として、記事を通じて以下が伝われば嬉しいです。
- WFに比べると画一的な定義がなく、プロジェクトに応じた計画が求められる
- 探索的テストや自動テストを活用して効率化に対応
- QAの独立性を損なわないよう注意が必要

テスターラボが参加するプロジェクトは、アジャイル型開発のプロジェクトが多くを占めます。開発モデルはWFやアジャイルの他にも存在していますが、どのような開発モデルにおいても最適な品質保証を提供できることを目指したいと思います。

## リファレンス
- [ISTQB Foundation Level Agile Tester](https://www.istqb.org/certification-path-root/agile-tester.html)
- [ISTQBテスト技術者資格制度 Foundation Level Extension シラバス アジャイルテスト担当者 日本語版 Version 2014.J01](http://jstqb.jp/dl/JSTQB-SyllabusFoundation-AgileExt_Version2014.J01.pdf)

※本記事で使用している画像は無断転載不可です。

## 『TESTAR LAB(テスターラボ)』とは
テスターラボとは、アプリケーションの機能・サービス品質をテストすることに特化した新サービスで、18カ国 30都市の豊富な人材リソースおよび国内外パートナー企業との豊富なネットワークにより、コスト最適でスピーディな提案をいたします。
テスターラボは自社サービスの品質に課題を感じている顧客、バージョンアップ頻度が高くリグレッションテストにコストと時間がかかっている顧客を対象にコスト効率・検出効率を最適化し、独立した第三者検証チームを提供いたします。

_Article Photo by [Patrick Perkins](https://unsplash.com/photos/ETRPjvb0KM0)_


アジャイル開発におけるQAとは？

一昔前は、データの保存といえば MySQL や PostgreSQL といったRDBMS（Relational DataBase Management System）を使うことがメインでしたが、最近は [Firestore](https://firebase.google.com/products/firestore) を利用することも増えてきました。  
データを保存するという役割は同じですが、RDBとは使い方・設計思想が大きく異るかと思います。

この記事では、RDBとは異なるFirestoreの制約を確認していきます。

## 集計関数が無い

RDBでは、インデックスやデータ量には依存しますが、数百・数千レコードを対象としても `COUNT(*)` や `SUM(amount)` といった集計が比較的手軽にできます。  
ですが、Firestoreでは現実的ではありません。

例えば、1つの伝票にそれぞれ10明細が紐付いており、20伝票をリスト表示する画面があったとします。  
そのリストに「合計金額」も表示したい場合、RDBではサブクエリで `SUM` をするなどで、高速に結果を取得できます。

一方、Firestoreで同様のことをする場合は、クライアントサイドで200ドキュメントを読み込み、処理として集計する必要があります。これでは、コストや性能の面で問題があります。  
このような場合、明細データの追加・更新時に伝票データの「合計金額」を更新しておき、画面表示時には伝票データのみの参照に抑えることが一般的かと思います。

他の制約においても、このように「書き込み時点で、読み込みのことを考えてデータを作成・更新しておく」という考え方が必要になってきます。

## 検索は苦手

2つ以上の条件を指定して検索するためには、インデックスを作成する必要があります。  
さらに、インデックスを作成しても実行できないクエリが存在します。

> 範囲（`<`、`<=`、`>`、`>=`）または不等値（`!=`）の比較は 1 つのフィールドに対してのみ実行できます。

[Cloud Firestore で単純なクエリと複合クエリを実行する | Firebase Documentation](https://firebase.google.cn/docs/firestore/query-data/queries?hl=ja)

例えば、「作成日時はA以降で、更新日時がB以降」といった、2つのカラムに対する範囲検索ができません。また、範囲検索と別のカラムでのソートもできません。

画面の仕様を変更してしまうか、別の検索用カラムで完全一致検索にするなど、回避策が必要となります。  
例えば上記の例であれば、「実際には作成日が”特定の年月”のデータで、更新日時がB以降」で良いのであれば、作成年月（”yyyyMM”の文字列）という別カラムを追加しておくことで、一方の条件を完全一致に変えることができ、この制約を回避できます。

## 全文検索はできない

特定の文字列を含む投稿を検索するなど、全文検索が必要な場合には、 Algolia などの外部のサービスを利用することが一般的となります。

> Cloud Firestore では、ネイティブ インデックスの作成やドキュメント内のテキスト フィールドの検索をサポートしていません。  
> さらに、コレクション全体をダウンロードして、クライアントサイドでフィールドを検索することは現実的ではありません。

[全文検索 | Firebase Documentation](https://firebase.google.cn/docs/firestore/solutions/search?hl=ja)

Search with Algolia という Firebase Extensions を利用することで、FirestoreデータをシームレスにAlgoliaに同期することもできます。

## 件数指定での読み飛ばしができない

RDBMSでは、offsetを指定することでページングを表現できます。  
Firestoreでは、limitは指定できますが、offsetは指定できません。  
そのため、「ページ番号単位での読み込み」といった仕様に対応するのは難しくなります。

一方で、無限スクロールのような「連続したデータを読み込む」ことは容易に実現できるようになっています。

## 複数データの一括更新・削除ができない

「条件に該当したデータの、とあるフラグをすべて更新する」とか、「親データを削除したから、そのIDを持つ子データを一括で削除する」といったことができません。  
条件指定で一旦取得して、個別に更新・削除していく必要があります。

トランザクションやバッチといった機能は存在するので、atomicに更新・削除することはできます。  
ただし、1トランザクションでは500件の書き込みしか行なえません。

> Commit オペレーションに渡すか、トランザクションで実行することができる書き込みの最大数	500

[使用量と上限  |  Firebase Documentation](https://firebase.google.com/docs/firestore/quotas?hl=ja#writes_and_transactions)

## security ruleはcollection単位のみで、フィールド単位には指定できない

RDBを利用する場合、クライアントとDBの間にAPIを実装するかと思います。  
そのため、読み取り制限などはAPI側に”処理”として実装するのが一般的かと思います。

Firestoreの場合は、security ruleとして読み取り制限を定義するため、クライアントが直接Firestoreを参照することが一般的かと思います。

security ruleを設定することで、collection単位でさまざまな制約を付けることができます。  
ただし、1つのデータの中で、「特定のフィールドだけは閲覧できない」といった制約を付けることはできません。  
そのため、「ほかユーザーに見せる、公開用のユーザー情報」と「本人だけが見える、個人情報などを含んだユーザー情報」が存在する場合には、別々のcollectionで管理するのが一般的となります。

## 1つのドキュメントに対して、1秒に何度も書き込めない

> ドキュメントへの最大継続書き込み速度: 1 秒あたり 1  
> 1 秒あたり 1 回を超える書き込み速度が持続すると、レイテンシが増加し、競合エラーの原因になります。これはハードリミットではなく、短時間のバーストでは上限を超えても構いません。

[使用量と上限  |  Firebase Documentation](https://firebase.google.com/docs/firestore/quotas?hl=ja#soft_limits)

というソフトリミットがあります。

前述の通り集計ができないので、例えば投稿に対する「いいね数」を表示するためには、整数としてカウントアップしていく必要があります。  
ただし、「いいね」はたくさんのユーザーから1つの投稿に集中する場合があるので、上記のソフトリミットに制限される可能性がありそうです。  
公式ページに、回答が用意されています。

> カウンタをもっと頻繁に更新できるようにするには、分散カウンタを作成します。  
> 各カウンタは「シャード」のサブコレクションを持つドキュメントであり、カウンタの値はシャードの値の合計です。

[分散カウンタ  |  Firebase Documentation](https://firebase.google.com/docs/firestore/solutions/counters?hl=ja)

簡単に言うと、10個のカウンタドキュメントに分散して保存することでソフトリミットを1/10程度に引き下げ、読み込むときにはそれを合算することで読み込みコストもある程度で済ませる形です。

## まとめ

Firestoreは、比較的低コストで運用できたり、リアルタイムに変更を検知することが簡単に実装できたりと、メリットが大きいです。

しかし、今まで利用してきたRDBMSとは、目指している方向や得意な場面が異なっています。  
制約を理解した上で、適材適所で使い分けていくことが重要だと思います。

## 参考

- [実践Firestore](https://www.amazon.co.jp/dp/B0851BGDQG)

_[Article Photo by Jan Antonin Kolar](https://unsplash.com/photos/lRoX0shwjUQ)_


RDBMS経験者が、Firestoreを使うときに知っておくべきこと


Playwright とは、Microsoft が中心に開発をしている web のテストや自動化のフレームワークです。2020 年にリリースされ、テスト自動化のフレームワークとしては後発で、[npm のトレンド](https://www.npmtrends.com/cypress-vs-playwright-vs-puppeteer-vs-testcafe)では Cypress や Puppeteer と比べると、ダウンロード数はまだまだ少ないですが、Github の Star 数は Cypress にも匹敵している人気のフレームワークです。
言語は JavaScript、TypeScript、Python、Java、.NET に対応しているので、web の E2E テストを書いたことがある方なら、簡単に試すことができますね。
モンスターラボでは Selenium や WebdriverIO を使うことが多く、他のツールに振れる機会がないので、試しに使ってみようと思います。

## Playwright の特徴

### クロスブラウザテスト

Chromium（Google chrome や Microsoft Edge）、Firefox、Webkit（Safari）が 1 つの API で実行できるため、クロスブラウザでのテストが容易に行えます。Safari に対応していないために、Cypress や Puppeteer の利用を諦めたという方も多いのではないでしょうか。
Playwright では、下記のように設定ファイルに記載するだけで、手軽に試すことができます。

```typescript
const config: PlaywrightTestConfig = {
  projects: [
    {
      name: "chromium",
      use: { ...devices["Desktop Chrome"] },
    },
    {
      name: "firefox",
      use: { ...devices["Desktop Firefox"] },
    },
    {
      name: "webkit",
      use: { ...devices["Desktop Safari"] },
    },
  ],
};
```

### Auto-waiting

自動テストでは要素が見つからない、操作できないことによるエラーが非常に多く、自動テストを書いたことがある人なら必ず体験したことがあるはずです。これを解決するために要素の出現を待つ API の記載が必要でしたが、Playwright ではデフォルトで [Auto waiting](https://playwright.dev/docs/actionability)が採用されているので、コードを簡潔に書くことができます。

### 位置情報の偽装

Playwright では、デバイスや User agent、位置情報を偽装することができます。
試しに、位置情報をエッフェル塔に設定して、Google Map で東京タワーを検索し、現在地に移動するテストを書いてみました。

```typescript
import { test, expect, chromium } from "@playwright/test";

test("my test", async ({ page }) => {
  // Open browser and open google Top page
  await page.goto("https://www.google.com/");

  // Input Tokyo Tower in the search form.
  await page.fill(".gLFyf", "東京タワー");

  // Start search
  await page.keyboard.down("Enter");

  // Wait for the map to appear
  await page.locator("#lu_map").waitFor();

  await page.click("#lu_map");

  // Move the cursor to the button
  await page.locator("#pWhrzc-mylocation").hover();

  // Wait for the text to appear
  await page.locator('text="デバイスに基づく"').waitFor();

  // Click the Show Current Location button
  await page.locator("#pWhrzc-mylocation").click();
});
```

※ デフォルトで Auto wait が採用されていると前述しましたが、地図の表示については、明示的に wait を入れています。おそらく他の API を利用すれば記載は不要になるはずなので、後日試してみようと思います。

偽装する位置情報は、設定ファイルに記載してます。

```typescript
const config: PlaywrightTestConfig = {
  use: {
    geolocation: { longitude: 2.294481, latitude: 48.858807 },
    permissions: ["geolocation"],
  },
};
```

### 画像比較テスト

[Visual comparisons](https://playwright.dev/docs/test-snapshots) の機能で、画像比較のテストが簡単に行うことができます。この機能は、pixelmatch のライブラリが使われており、threshold の指定を指定することもできます。デフォルトの設定では結果として Fail になるだけで、画像のどの部分が異なるのかは明記されないので、カスタマイズが必要なようです。

### Trace Viewer

Playwright を使ってみて、一番良かったのは [Trace Viewer](https://playwright.dev/docs/trace-viewer) です。この機能はテストの実行結果を GUI でトレースすることができる機能で、テストにどれくらいの時間がかかったか、どの時間帯にどういう動きをしていたか、を探索することができます。
実際に画面の動きはこのようになります。

![]({{ sitePrefix }}/assets/img/articles/2022-01-14-Try-Playwright/trace_viewer.gif)

<div style="text-align: right;">©2022 Google</div>

この機能や各テストの Video や Screenshot についても設定ファイルに記載するだけで実装できます。

```typescript
const config: PlaywrightTestConfig = {
  use: {
    video: "on",
    trace: "on",
    screenshot: "on",
  },
};
```

テスト実行後は、trace.zip というファイルが作られるので、以下のコマンドを実行すると Trace Viewer が立ち上がります。

```terminal
npx playwright show-trace test-results/tests-googlemap-my-test-chromium/trace.zip
```

## まとめ

今回 Playwright を試してみましたが、非常に良いツールだと感じました。ツールの使い勝手も良いですし、何より[公式のドキュメント](https://playwright.dev/docs/intro)が充実しているのがありがたいです。自動テストを書いてみたい方はぜひ使ってみてください。

Playwright には紹介した機能以外にも、レポート機能や、[Test Generator](https://playwright.dev/docs/codegen) という GUI での操作をテストコードに変換する Selenium IDE のような機能など他にもたくさんの機能があります。最近ではアップデートも頻繁に行われていて、新しい API も順次追加されているので、今後の Playwright にも注目です！


Try Playwright


こんにちは、モンスターラボで BackEnd の TechLead をしています、国平です。

今日は、いよいよ有料化が迫った Docker Desktop についてモンスターラボで検討されている代替案の一つをご紹介します。

Docker Desktop の有料化に伴う対応について、モンスターラボが世界中のグループ、パートナー、そしてお客様と一緒に働いていることもあり、一律 Docker Desktop を有料利用するという判断が行えないプロジェクトもあります。
そのため、モンスターラボではこの問題に対応するワーキンググループが Slack 上で結成され、世界中の拠点から対応に関する知見が集まっています。
今回はその中で挙がったの一つを紹介します。

なお、モンスターラボ内では開発機として macOS が主流なため、ここでは macOS の利用を前提とします。

## 代替案

前述のワーキンググループで挙がった代替案を列挙します。

- podman
- minikube
- multipass
- Docker on Lima
- Colima
- 脱 macOS (Windows や Linux の利用)

今回はこの内、 Lima を使う方法を詳しく説明します。

## Docker on Lima

Docker Desktop に代わる案として、 Lima を用いて macOS 上に Linux 環境を構築し、 macOS 上の docker client から Lima 上の docker daemon にアクセスする方法があります。

[https://github.com/lima-vm/lima](https://github.com/lima-vm/lima)

## Install Docker client on your Mac

まず、ホストとなる mac 上に docker client をインストールします。

```shell
brew install docker
```

この時、間違えて `--cask` オプションをつけてしまうと、有料化の対象となる Docker Desktop がインストールされるので注意してください。

## Install & Lanch Lima

```shell
brew install lima
```

今回は Docker を使いたいので、公式に配布されている `docker.yaml` を利用して vm を立ち上げます。

```shell
curl https://raw.githubusercontent.com/lima-vm/lima/master/examples/docker.yaml -o docker.yaml

limactl start docker.yaml --tty=false
```

これで、 Lima が起動しました。

```shell
limactl list

# NAME      STATUS     SSH                ARCH      CPUS    MEMORY    DISK      DIR
# docker    Running    127.0.0.1:51139    x86_64    4       4GiB      100GiB    /Users/kiyotaka_kunihira/.lima/docker
```

## Connect host docker client to Lima's docker daemon

ホストマシンの Docker client から Lima 上の docker daemon に接続できるよう設定を行います。
先ほどダウンロードした `docker.yaml` には、 ホストマシンの `DOCKER_HOST` 環境変数を設定するコマンドが記載されていますが、今回は `docker context` を利用して、接続先を切り替えられるようにしたいと思います。

```shell
docker context create lima --docker "host=$(limactl list docker --format 'unix://{{.Dir}}/sock/docker.sock')"

docker context use lima
```

期待通りホストマシンから Lima 上の docker が利用できるか試してみます。

まず、ホストマシン上で適当に docker run します。

```shell
docker run hello-world

docker ps -a

# CONTAINER ID   IMAGE         COMMAND    CREATED          STATUS                      PORTS     NAMES
# ab69d9e5cdf3   hello-world   "/hello"   26 seconds ago   Exited (0) 25 seconds ago             flamboyant_jang
```

Lima 上でも `docker ps -a` して、同じ結果が得られるか確認します

```shell
limactl shell docker docker ps -a

# CONTAINER ID   IMAGE         COMMAND    CREATED         STATUS                     PORTS     NAMES
# ab69d9e5cdf3   hello-world   "/hello"   2 minutes ago   Exited (0) 2 minutes ago             flamboyant_jang
```

`CONTAINER ID` が一致しているので、問題なく Lima 上の docker がホストマシンから操作できています。

## VSCode からアクセス

## Lima で writable 設定

デフォルト設定で起動した場合、Mac のホームディレクトリが読み取り専用でマウントされるため、そのままではファイルの保存ができません。以下のマウント設定を参考に Lima の設定ファイルを修正する必要があります。

```shell
vim `limactl list docker --format '{{.Dir}}/lima.yaml'`
```

ファイル内の `mounts` の ホームディレクトリを `writable` に変更します。

```yaml
mounts:
  - location: "~"
    writable: true # Add this line
  - location: "/tmp/lima"
    writable: true
```

Lima を再起動すれば設定が反映されます。

```shell
limactl stop docker
limactl start docker
```

## VSCode からアクセス

[Remote - Containers](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) を使ってコンテナ上のファイルを編集します。

ここではサンプルとして、 nginx の docker コンテナを立ち上げ、コンテナ上のファイルを編集します。

まず、ホストマシン上で適当な html ファイルを用意します。

```shell
echo "<html><body>hello world</body></html>" > index.html
```

そして、 nginx コンテナを立ち上げます。

```shell
docker run -v $(pwd):/usr/share/nginx/html:rw -d nginx
```

VSCode の Remote Explorer ペインを開くと、 nginx コンテナが表示されるので開きます。

![The remote container pane in VS Code]({{ sitePrefix }}/assets/img/articles/2022-01-12-Docker-on-Lima/vscode-remote-container-pane.PNG)

nginx から コンテナ内のファイルを編集できました。

![Editing an file on remote container in VS Code]({{ sitePrefix }}/assets/img/articles/2022-01-12-Docker-on-Lima/vscode-edit-file-in-container.PNG)

## まとめ

Docker Desktop の代替案として、 Mac から Lima 上の docker-daemon を利用する方法をまとめました。
また、 docker container 上のファイルを VS Code から編集するための設定しました。

_Article Photo by [cottonbro](https://www.pexels.com/photo/shallow-focus-photo-of-wooden-whale-toy-3663069/)_


Docker on Lima


この技術ブログでは、コンピュータビジョンとディープラーニングによるレシートの認識と認識結果の改善方法を紹介します。
さらに、コンピュータビジョンを使って半自動で学習データを作成した様子も紹介します。
以下のに興味がある方は、ぜひご覧ください。
 - ディープラーニング - インスタンスのセグメンテーション
 - コンピュータビジョン - 輪郭形成、アフィン変換、ホモグラフィー変換、薄板スプライン変換
 - 半自動でのデータ作成

## これは何なの？

AI関連技術の使い勝手や利便性の向上により、私たちの日常生活の中でAIの普及が着実に進んでいます。
レシートを認識してその内容を理解することは、人事の請求書チェックや会計、文書の解析・分析など様々な用途があります。
レシート認識を民主化するためには、スマートフォンの写真を使って行うのが簡単ですがスマートフォンで撮影した写真は、スキャナーを使用したものよりも、ノイズ（画像の背景）が多いため、正確なレシート認識が難しくなります。

<img src={{ sitePrefix }}/assets/img/articles/2021-12-20-Receipt-recognition-using-computer-vision-and-deep-learning/figure0.PNG>

レシート認識の目的を達成するために、2つのアプローチが考えられます。
- コンピュータビジョン：入力画像に様々な変換を施して、画像内のレシートの位置を取得し、その観測を強化する。
- ディープラーニング：学習されたモデルを用いて画像内のレシートの位置を検索し、その観測を強化します。

コンピュータビジョンはより効率的に、より少ないコード行で問題を解決できるため、ディープラーニングは時として過剰な機能となります。
しかし、コンピュータビジョンがすべての状況で機能するわけではなく、ディープラーニングを使用することでレシートの認識をより強固にすることができます。このブログでは、両方のアプローチを調査してその結果を確認し、パフォーマンスの高いレシート認識を実現する方法についてご紹介します。

## 手順

レシート認識とその観測の強化の異なるステップは、次のとおりです（専門用語は次項で説明します）:

1. 画像内のレシートの輪郭を見つける。
2. アフィン変換を適用して、レシートを垂直方向に回転させる。
3. レシートの角を取得します。
4. 角とバウンディングボックスの角を使ってホモグラフィー変換を適用します。
5. レシートの輪郭と対応するバウンディングボックスの間のグリッドマッピングを計算します。
6. thin plate spline transformationを適用して、レシートの歪みを補正します。

上述した操作のうち、ステップ1が最も重要であり、この輪郭形成操作が後続の操作の成功を左右します。 したがって、ステップ1はコンピュータビジョンとディープラーニングの両方を使用して実現し、次のステップはコンピュータビジョンのみを使用して実現します。

## コンピュータビジョンの運用

上記のセクションでは、受信機の理解と向上を実現するためのさまざまなステップを示しました。このセクションでは、各ステップの技術的な説明を提案します。

輪郭処理は、エッジを持つ形状の周りの境界を検出する操作です。輪郭処理アルゴリズムは、周囲のピクセル値の勾配を計算して、閉じた形状を検出することができます。
これは、コンピュータビジョンとディープラーニングの両方でよく知られている問題です。
レシートの輪郭と、それを囲むバウンディングボックスを用いて、アフィン変換によりレシートを垂直方向に回転させます。
バウンディングボックスとは、ある物体（ここではレシート）を囲む、縦と横の辺を持つ最小の長方形のことです。
コンピュータビジョンにおけるアフィン変換とは、画像の移動や回転などの線形変換の集合を指します。

<figure>
<img src={{ sitePrefix }}/assets/img/articles/2021-12-20-Receipt-recognition-using-computer-vision-and-deep-learning/figure1.png>
<figcaption>図1. 元画像、輪郭線とバウンディングボックスの推定、回転したレシート</figcaption>
</figure>

平面ホモグラフィー演算とも呼ばれるホモグラフィー演算は、ある画像の点をマッピングして、その画像を別の視点から観測できるようにする変換です。
ここでは、画像を平行移動させ、ヨー／ピッチ／ロールの角度を変更して、上から観察できるようにしています。

<figure>
<img src={{ sitePrefix }}/assets/img/articles/2021-12-20-Receipt-recognition-using-computer-vision-and-deep-learning/figure2.png>
<figcaption>図2. 元の画像とホモグラフィーを用いた観測結果の修正</figcaption>
</figure>

thin plate spline transformationとは、2組の格子から空間的なマッピングを行い、その格子内の値を補間することで、画像の歪みを補正することができる演算である。

<figure>
<img src={{ sitePrefix }}/assets/img/articles/2021-12-20-Receipt-recognition-using-computer-vision-and-deep-learning/figure3.png>
<figcaption>図3. 輪郭解析、ソース（青点）とデスティネーション（赤点）のグリッド検索、レシートの歪みをなくすための薄板スプライン変換</figcaption>
</figure>

上の画像では、コンピュータビジョンはチケットの認識とその観察の強化に十分な効果があると思われます。
しかし、輪郭処理は、画像の背景やレシートの状態（くしゃくしゃのレシート）、画像の明るい部分などに大きく左右され、うまくいかないことがあります。
ここでは、輪郭処理がうまくいかず、失敗に終わった例を紹介します。

<figure>
<img src={{ sitePrefix }}/assets/img/articles/2021-12-20-Receipt-recognition-using-computer-vision-and-deep-learning/figure4.png>
<figcaption>図4. 輪郭処理の失敗（緑）とバウンディングボックスの推定（赤）</figcaption>
</figure>

この問題を解決するために、コンピュータビジョンができなかった複雑な認識タスクを処理できるディープラーニングが検討されています。

## ディープラーニングの運用
### インスタンスの分割

ディープラーニングは、人工知能のサブセットであり、入力データを層状のモデルにマッピングして、分類や回帰問題として変数を推定することを目的としています。
入力データには、画像、テキスト、表データ、時系列信号などの形式があります。
出力データは、セグメンテーションマスク、バイナリ変数、ベクトルなど、任意の形をとることができます。

インスタンスセグメンテーションは、ディープラーニングの一つで、画像に写っている興味のある個別のオブジェクトを検出することを目的としています。
同じクラスの複数のオブジェクトを個別のインスタンスとして扱い、インスタンスごとに異なるピクセル単位のセグメンテーションマスクを生成します。

今回のケースでは、1枚の画像に複数のレシートがある場合でも、レシートの輪郭として使用できるセグメンテーションマスクが得られるという利点があります。

<figure>
<img src={{ sitePrefix }}/assets/img/articles/2021-12-20-Receipt-recognition-using-computer-vision-and-deep-learning/figure5.png>
<figcaption>図5. インスタンス・セグメンテーションの概念</figcaption>
</figure>

コンピュータビジョンとは異なり、ディープラーニングは学習するためのトレーニングデータが必要ですが、これについては次のセクションで説明します。

### データ作成の半自動

ディープラーニングモデルの学習に必要なデータ量は、実現を目指すタスクによって大きく異なります。レシートは単純な形状をしており、背景とのコントラストが強い場合が多いため、数百個のサンプルで良い結果が得られると考えられます。
しかし、レシートのセグメンテーションのためのオンラインデータセットは存在しないため、これらのデータを一から作る必要があります。
ゼロからのラベリングは、反復的で時間のかかる面倒な作業なので、ほとんどのAIエンジニアは他者に委ねたがります。

今回の例では、コンピュータビジョンを用いて画像中のレシートの輪郭を推定することができるので、セグメンテーションマスクの作成はこのアプローチに基づいて行われます。
コンピュータビジョンによる輪郭抽出がうまくいかない場合は、ポリゴンデータのラベリングソフトを使ってセグメンテーションマスクを編集します。
このように、学習データの作成には時間がかかりますが（データの品質を確認するためのレビュー）、半自動化することで、その負担を軽減することができます。

## ディープラーニングのコンタリング運用

インスタンス・セグメンテーション・モデルを学習した後、問題のあるレシート画像をテストしました。

<figure>
<img src={{ sitePrefix }}/assets/img/articles/2021-12-20-Receipt-recognition-using-computer-vision-and-deep-learning/figure6.png>
<figcaption>図6. 問題のある画像でのインスタンス・セグメンテーションの結果</figcaption>
</figure>

コンピュータビジョンでは正しく輪郭抽出ができていませんでしたが、インスタンス・セグメンテーション・モデルをでは、正しくレシート・セグメンテーション・マスクを推定することができました。
輪郭処理が正しく行われたことで、以下のコンピュータビジョンステップが正常に適用されました。

## まとめ

このブログでは、スマートフォンで撮影した写真からレシートを認識するために、コンピュータビジョンとディープラーニングを組み合わせたり、別々に使用したりする方法を紹介しました。
コンピュータビジョンの長所であるわかりやすさと、ディープラーニングの短所である学習データの必要性を組み合わせて、強固なレシート認識ソリューションを実現しました。
レシートの認識以降は、コンピュータビジョンの手順を適用して、レシートの観察を強化しました。

我々のソリューションの精度とロバスト性を向上させるために、ディープラーニングアプローチでは以下のタスクを考慮しています。
- トレーニングデータセットにさらにデータを追加する。
- インスタンス・セグメンテーション・モデルのための様々なバックボーンのベンチマークを行う。
- コンピュータビジョンを用いてディープラーニングの結果を改良する。

_[図5. COCOデータセットの例](https://cocodataset.org/)_

_[PexelsのKarolinaGrabowskaの記事の写真](https://www.pexels.com/photo/person-using-a-computer-and-holding-a-credit-card-and-receipts-4968390/)_


コンピュータビジョンとディープラーニングを用いたレシート認識



先日12月10日（金）から12日（日）の3日間で、「Monstarhacks2021」と題して、モンスターラボグループ全体で参加できるグローバルなハッカソンを行いました。
海外拠点の拠点内でハッカソンを行うことはありましたが、グローバルの規模で行うことは初めての試みでした。

## ハッカソンとは
ハッカソンとは、定められた短期間の間に異なるスキルを持った人々が数人（3~5人）でチームを組み共同でプロジェクトを行う、ソーシャルかつイノベーションに焦点を当てたイベントです。

多くの場合決められたテーマがあり、そのテーマに沿って自分たちのアイデアを出しプロトタイプを作るために作業をします。

知り合い同士で参加することもありますが、イベントで初対面の人同士でチームを組んで、得意分野を活かしながらチームワークを発揮して成果物を作ることもまた面白みの一つであります。

## Monstarhacks
### 今回のテーマ
今回のMonstarhacksでは**SDGs**に焦点を置き、テクノロジーを使って定められたゴールに対してアプローチを創出することがテーマとなりました。

#### SDGsとは
> 持続可能な開発目標（SDGs：Sustainable Development Goals）とは、2001年に策定されたミレニアム開発目標（MDGs）の後継として、2015年9月の国連サミットで加盟国の全会一致で採択された「持続可能な開発のための2030アジェンダ」に記載された、2030年までに持続可能でよりよい世界を目指す国際目標です。17のゴール・169のターゲットから構成され、地球上の「誰一人取り残さない（leave no one behind）」ことを誓っています。SDGsは発展途上国のみならず、先進国自身が取り組むユニバーサル（普遍的）なものであり、日本としても積極的に取り組んでいます。

*引用元: [外務省](https://www.mofa.go.jp/mofaj/gaiko/oda/sdgs/about/index.html)*

このSDGsによって定められた17のゴールのうち下記の3つに絞って選択し、いずれかの解決を狙うアイデア・プロダクトを作り出すことがトピックとなりました。
- ゴール3: あらゆる年齢のすべての人々の健康的な生活を確保し、福祉を促進する
- ゴール4: すべての人々への、包摂的かつ公正な質の高い教育を提供し、生涯学習の機会を促進する
- ゴール5: ジェンダー平等を達成し、すべての女性及び女児の能力強化を行う

*引用元: [ゴール](https://gooddo.jp/magazine/sdgs_2030/)*

<figure style="text-align: center;">
  <img style="display:inline;margin:30px 15px;" src="{{ sitePrefix }}/assets/img/articles/2021-12-17-Monstarhacks-2021/sdg_icon_03.png">
  <img style="display:inline;margin:30px 15px;" src="{{ sitePrefix }}/assets/img/articles/2021-12-17-Monstarhacks-2021/sdg_icon_04.png">
  <img style="display:inline;margin:30px 15px;" src="{{ sitePrefix }}/assets/img/articles/2021-12-17-Monstarhacks-2021/sdg_icon_05.png">
</figure>

*引用元: [国際連合広報センター - SDGsのアイコン](https://www.unic.or.jp/activities/economic_social_development/sustainable_development/2030agenda/sdgs_logo/sdgs_icon/)*

### 開催期間
冒頭にも述べましたように、12月10日（金）から12月12日（日）3日間で行われました。  
開催範囲がグローバルという単位ですので、一斉スタートというわけではなく、それぞれの国の生活時間として3日間が使える形です。

今回は金曜日の平日からでしたので、もちろん参加者はそれぞれクライアントのプロジェクトに参画しているのでそちらが優先ですが、プロジェクトが許す範囲で業務時間内に参加することが会社として許されています。

また、プライベートの都合などで期間内すべて参加ができなくてもイベントの参加自体は可能で、気軽に参加することができました。

### 参加者やチーム編成
参加者は世界中のモンスターラボグループの社員で、エンジニアやデザイナーをはじめ、プロジェクトマネージャーやビジネスアナリストなどいろいろな役職のメンバーが参加でき、普段のプロジェクトワークでは一緒に仕事をする機会が少ない人たちとチームを組むことができます。

また、違う国のメンバー同士でチームを組む多国籍チームもあったようです。

1チームが3〜5名で、APAC圏から12チーム、EMEA圏から3チームが参加し、総勢15のチームが参加しました。

### 成果物の提出方法
成果物として下記を提出します。
- 簡単に問題提起と解決策が記された文書
- 期間内に作成された成果物（コード、デザインなど）
- 5分以内のデモまたはプレゼンテーションビデオ

フォーマットは特に決まっておらず、制作物の形式はフリーです。  
もちろんアイデアを説明した文章よりかは、プロトタイプやデザインモックのようなアイデアを具体的にアウトプットしたものが期待されますし、評価も得やすくなります。

### 審査
#### 審査員
審査員はアメリカ、EMEA、APACのCTOなど世界各地の拠点の重役6名が審査します。

#### 審査基準
今回審査にあたって、以下のような基準で審査が行われました。

- 新しいイノベーティブなアイデアであるか、少なくとも以前からある問題に新しいアプローチをとっているか
- 人々が必要としているものであり、実際に使うようなものであるか
- ハックを通してメンバー自身が成長する要素があったか
- 設計がうまくされているか
- ユーザーエクスペリエンスがスムーズか
- テーマに沿っているか
- プロジェクト自体がテーマを理解し、表現できているものか
- 採用した技術が印象的か
- 現時点で使用するうえで障壁が高くないか

## 参加レポート
今回は東京オフィスからは3チームが出場しました。

### メンバー
- Tagy Aldeen: Software Engineer
- Sara Alafifi: Assistant PM
- 森 未央子: UI/UX Designer
- 王 東宇: Frontend Engineer
- 齋藤 広貴: Frontend Engineer

![Members]({{ sitePrefix }}/assets/img/articles/2021-12-17-Monstarhacks-2021/member.jpg)

### テーマの選定
昨年から新型コロナウイルスの感染拡大により、在宅ワークを推奨する企業が増えました。

そんな中、子どもがいるご家庭では仕事をしながら子どもの面倒を見なくてはならないということも多いのではないかと思います。  
子どもが走り回ったり、仕事中に話しかけてきたりと、仕事をする集中力が損なわれてしまいます。  
と入っても放置するわけにもいかず、危険なことをしてしまっているかもしれないので見張っていないといけません。

そんな子どもの世話は、イクメンの増加はあるものの、奥さんが主に見ているという割合は多いのではないでしょうか？

上記のような考えから私たちのチームは、下記に詳細を記しますが、
- ゴール4: すべての人々への、包摂的かつ公正な質の高い教育を提供し、生涯学習の機会を促進する
- ゴール5: ジェンダー平等を達成し、すべての女性及び女児の能力強化を行う

2つのテーマにフォーカスし、「**AIによるバーチャルシッター**」を作れないか考えました。

### 具体的なアイデア
このアイデアは3~6歳の子どもで、ある程度言葉が理解できたり自分でなにかできるようになった子をターゲットとしました。  
Google HomeやAmazon Alexaを使用して、子どもとの対話とモニタリングの2つの機能をもたせようと考えました。

#### 子どもとの対話
- 家事のお手伝いをリマインド
- 歯みがきや寝るタイミングのお知らせ
- 子どもがその場を離れようとしたときに留まらせるか、実行中のものを停止する
- 教育的・対話的な活動を提供
- 子どもに呼びかける声は、親の声をベースにする

#### モニタリング
- センサーとIoTを利用して、子ども居場所や状態、室温や湿度を確認・調整する
- デバイスや活動（睡眠時間・歯みがき・モニタリング履歴）を親が確認できる
- 子どもの動き、行動の分析結果を親が知ることができる
- アクセスフィルタリングが必要なコンテンツにアクセスを検知して親に通知する

#### プロダクト設計
このアイデアのポイントは、親は子どもとAIをつなぐ仲介役です。  
AIに全面的に依存するわけではなく、親と子どもの人間的な交流を維持する補完機能としての役割を担ってもらおうというアイデアです。

![User story map]({{ sitePrefix }}/assets/img/articles/2021-12-17-Monstarhacks-2021/storymap.png)

今回は子どもとの対話部分を[Google Homeスピーカー](https://store.google.com/jp/magazine/compare_speakers?hl=ja)を使用し、子どもの行動などのデータのインプットは[SiMPNiC](https://simpnic.com/)などの比較的に安価で入手可能なセンサーを使用します。

![Architecture map]({{ sitePrefix }}/assets/img/articles/2021-12-17-Monstarhacks-2021/architecture_map.png)

親が仕事に集中するために、子どもが何かに興味を惹かれている状態を作り出す必要があると考え、子どもにはタブレットなどでYouTube Kidsを見て、子どもに教育や行動を促そうと考えました。  
YouTube KidsのAPIがあるので、YouTube Kidsの動画の中からAIがレコメンドするものを子どもに見てもらいます。

親が各センサーなどの情報を確認するために情報を集約する画面が必要だと思います。  
その機能は[Home Assistant](https://www.home-assistant.io/)を使用して、子どもの様子や動画の視聴履歴などを確認できるようにしました。  
この画面に、子どもの行動を分析して、結果のフィードバックを親が確認できる機能もこちらで確認できるようにしようと考えました。

このアイデアは、選定したテーマについて、下記のターゲットへのアプローチになると考えました。

- ゴール4: すべての人々への、包摂的かつ公正な質の高い教育を提供し、生涯学習の機会を促進する
  - 4.2 2030年までに、すべての子どもが男女の区別なく、質の高い乳幼児の発達支援、ケアおよび就学前教育にアクセスすることにより、初等教育を受ける準備が整うようにする。
- ゴール5: ジェンダー平等を達成し、すべての女性及び女児の能力強化を行う
  - 5.4 公共のサービス、インフラ、および社会保障政策の提供、ならびに各国の状況に応じた世帯・家族内における責任分担を通じて、無報酬の育児・介護や家事労働を認識・評価する。
    - 指標5.4.1 無償の家事・ケア労働に費やす時間の割合（性別、年齢、場所別）

*引用元: [ゴール4](https://gooddo.jp/magazine/sdgs_2030/quality_education_sdgs/), [ゴール5](https://gooddo.jp/magazine/sdgs_2030/gender_equality_sdgs/), [指標](https://www.mofa.go.jp/mofaj/gaiko/oda/sdgs/statistics/data/05/Indicator5.4.1(metadata)_ja.pdf)*

### 3日間の流れ
#### 金曜日
Slackでチームのチャンネルを作り挨拶をしました。  
平日のため、プロジェクトワークがある人はそちらを優先し、余裕のある人同士でディスカッションして、テーマの選定とアイデアの方向性の検討をしました。

私は、英語が苦手のためこの時点でコミュニケーションに不安を覚えています...  
Slackで進むディスカッションをDeepLで翻訳して、決まる方向性を追いかけました。  

#### 土曜日
メンバーは午後から作業ができる状態だったため、午後から会社に集まって作業することにしました。  
全員集まるのを待ちながら早く来た人と一緒にランチをしました。（上記メンバー照会の写真）

その後作業をはじめ、まずは前日決めたアイデアの詳細を詰めていく作業です。  
はじめはメタバースなど、近未来的なアイデアも出ましたが、コストがかかりすぎたり実現性が低いということで、よりリアリティのある案に落ち着きました。  
Miroなどを使ってユーザーストーリーマッピングを作成、アイデアのドキュメントの作成、プロダクトのアーキテクチャ検討を行ったところで解散としました。

![Working Image]({{ sitePrefix }}/assets/img/articles/2021-12-17-Monstarhacks-2021/working.jpg)

#### 日曜日
最終日です。

前日にアイデアの詳細を詰めたので、決めた内容をもとにUIデザインをFigmaに落とす作業と、アーキテクチャの実現検証をして、プレゼンの準備をしました。  
今回私たちのチームでは、時間の都合上実際にプロダクトの作成までは行わず、アイデアの主要部分のUIデザインとプレゼンのビデオを提出し終了しました。

## まとめ
モンスターラボでは初めてグローバル規模でのハッカソンを実施しました。  
今回はSDGsをテーマにして、達成へのアプローチを考えることにチャレンジしました。

私自身、ハッカソン自体今回始めて参加したのですが、テーマに向けたアイデア出しから、アイデアを形にするところまでを短期間で目指すスピード感が非常に面白いと思いました。  
また、今回入ったチームでは基本的に英語でコミュニケーションがとられていたので開始時は少し心配しましたが、日本拠点に籍をおくメンバーなので、私が理解しきれない部分は「わからないです！」と言えばすぐサポートしてくれるので、すぐに安心して取り組むことができました。

作業以外にも、会社に集まりランチをしたりして、普段のプロジェクトワークでは交わる機会少ない人達との交流ができたり、またチームメンバーが外国人の方であれば、違う文化の話ができたりしてとても楽しい時間でした。

こういった経験ができるのは、世界各地に拠点をおき、日本のオフィスにも外国出身のメンバーが多数在籍しているモンスターラボだからこそできることだと感じました。

来年以降も継続して、モンスターラボを代表する恒例行事にしていけるようにしたいと思います。


Monstarhacks 2021を開催しました


謎のハッカーが情報を盗み出すデータ流出事件をニュースで見たことがあると思います。お金をもらわなければ機密情報を公開すると脅すものです。しかし、悪意のある人が行う前に、セキュリティをプロアクティブにテストする方法があることをご存知ですか？

本ブログではどのように自身を守るか、ペンテストとはなんなのか、なぜ行うかとタイミングについて詳しくご紹介します。

## ペネトレーションテストとは？

ペネトレーションテスト（侵入テスト）とは、訓練を受けた専門家チームがシステムの弱点を見つけようとするものです。

ハッカー、企業ネットワークのオペレーティングシステム、サービス、およびアプリケーションの脆弱性を悪用します。脆弱性は、安全でない構成または危険なエンドユーザーの動作に存在する可能性があります。

また、私たちの評価では、防御が機能していること、およびセキュリティポリシーに従っているかどうかを検証します。

ペンテストには通常、サーバー、エンドポイント、Web アプリケーション、ワイヤレスネットワーク、ネットワーク機器など、クライアントの組織に接続するさまざまな機器やシステムを危険にさらすことが必要です。

セキュリティエンジニアは、特定のホストのセキュリティの脆弱性を見つけて、権限を特権に昇格させて他の内部リソースにアクセスするために、ホストを侵害しようとします。

ペネトレーションテストで見つけた脆弱性は、開発チームやクライアントに報告され、脆弱性がもたらすリスクを評価することができます。

最終的に、セキュリティテストは、システムまたはユーザーが侵害される可能性があるかどうかを判断し、そのような侵害の結果を評価するように設計されています。

## 脆弱性スキャンとペンテストの違いとは？

「脆弱性スキャン」と「セキュリティテスト」という用語は同じ意味で使用されることもありますが、実際には 2 つの異なるタイプのセキュリティテストを指します。

脆弱性スキャナーは、環境を調査し、スキャンの完了時にレポートを作成する自動化されたツールです。

これらのスキャナーは、多くの場合、既知の弱点に関する情報を提供するオープンソースの CVE 識別子を使用してこれらの脆弱性を一覧表示します。

高い優先順位付けが必要な深刻な脆弱性が見つかることがあります。

残念ながら、これらのスキャナーは誤検知を引き起こす可能性があり、セキュリティエンジニアが実際に有効な脆弱性であるかどうかを判断する必要があります。

セキュリティチェックでは、スキャナーで見逃されたセキュリティ問題を見つけるために、さらにペンテストを実施します。

ペンテストでは、自動スキャンツールによって検出された脆弱性が実際のセキュリティの問題なのか、それとも誤検知なのかを確認できます。

セキュリティテストは、最も保護する必要のあるアプリケーションを特定することにより、優先順位を付けた改善計画にも役立ちます。

## なぜセキュリティテストが重要なのか？

### 脆弱性の発見と優先順位付け

セキュリティテストでは、セキュリティ制御を回避する外部または内部の試みからネットワーク、システム、アプリケーション、およびユーザーを保護する組織の能力を評価します。

### 脆弱性をスマートに管理する

セキュリティテストでは、実際のハッカーによって悪用される可能性のあるセキュリティの脅威に関する詳細情報を収集します。

セキュリティテストを実行することで、どの脆弱性が最も重要で対処する価値があるか、どの脆弱性を無視してもよいか、どの脆弱性が誤検知である可能性があるかを確認できます。

これにより、組織はリスクをより徹底的かつ効率的に評価し、必要なパッチを適用し、リソースを割り当てて、最も必要なときに必要な場所で確実に利用できるようになります。

### セキュリティにプロアクティブなアプローチをとる

本日時点で、セキュリティ侵害を防ぐための唯一の解決策がないことは明らかです。

暗号化技術、アンチウイルス、SIEM ソリューション、IAM プログラムなど、サイバー攻撃から身を守るための高度なセキュリティ対策のポートフォリオが、現状の組織には必要です。

これらのセキュリティツールを使用しても、ネットワークまたは Web アプリケーションのすべての脆弱性を見つけて排除することは困難な場合があります。

ペネトレーションテストは、プロアクティブなアプローチで弱点を発見するため、企業は何を改善する必要があるのか、また追加のレイヤーを実装する必要があるのかを知ることができるようになります。

### 何が機能していて何が機能していないかを確認する

多くの場合、組織は、修正が必要な実際の問題を最初に特定せずに、セキュリティプログラムに全面的な変更を加えます。

セキュリティテストは、脆弱性を発見するためだけのものではありません。
どのポリシーが最も効果的で、どのツールが最高の ROI をもたらすかを知ることができます。

これらの洞察により、組織がセキュリティリソースを賢く割り当て、最も必要なときに必要な場所で確実に利用できるようにすることができます。

### セキュリティ戦略に自信を持つ

セキュリティ対策が効果的であるかどうかは、テストを行わなければわかりません。

セキュリティチームがセキュリティインフラストラクチャをテストすることで、攻撃から身を守ることができます。

## セキュリティテストはどのくらいの頻度で行うべきか？

IT と Web アプリケーションのセキュリティ管理をより一貫したものにするために、定期的にペネトレーションテストを実施する必要があります。

ペンテスターは、新たに発見された脅威や、攻撃者に悪用される可能性のある新たな脆弱性を特定することができます。

セキュリティテスターは、規制上の義務によって要求される定期的な分析と評価も実行する必要があり、次の場合はいつでも追加のテストを実行する必要があります。

- アプリケーションの依存関係を更新した場合
- アプリケーションのコードベースに大きな変更を加えた場合
- インフラやホスティング環境が調整

## セキュリティテストの後で何をすべきですか？

ペネトレーションテストの結果を確認しながら、セキュリティを改善するための計画について話し合い、全体的なセキュリティ体制を再検討しましょう。

セキュリティテストは重要ですが、単に脆弱性をスキャンしてリストにチェックを入れるだけではいけません。

発見されたものについて話し、結果を共有し、そこから学ぶために事後検証の時間を作りましょう。

組織内の意思決定者に実用的な情報を提供することで、脆弱性がもたらす影響と、その修正によるプラスの効果を理解してもらうことができます。

ペンテストレポートを確認することで、管理者および企業側は、セキュリティ問題に対処する必要があるかを判断できます。

## セキュリティをテストしたいですか？

ここ Monstarlab では、最近、Web、API、およびモバイルセキュリティテストを実施できる新しいサイバーセキュリティ部門を設立しました。

Monstarlab がセキュリティの向上にどのように役立つかについて詳しく知りたい場合は、[こちらからお問い合わせください。](https://monstar-lab.com/contact/)

_記事写真： [B_A](https://pixabay.com/users/b_a-363247/)_


ペンテスト（侵入テスト） What? Why? When?


今回は、Androidの非同期処理をKotlin Coroutineで簡単に行えるasync/awaitについて紹介します。
async/awaitがよく使われるケースは、例えば、詳細情報を取得するAPIと付加情報を取得するAPIを、Coroutineで処理した内容が終わったタイミングで待ち合わせて、詳細ページを作成します。

まず、asyncとはCoroutineを起動する関数の一つです。
基本的にlaunchと同じ。違いは、値を返すかになります。
値は、Deferred型です。Deferred型とは、返却値はfuture promiseになります。つまり、 Coroutineの処理が終わったタイミングで戻り値を取得します。

```
fun <T> CoroutineScope.async(context: CoroutineContext = EmptyCoroutineContext, start: CoroutineStart = CoroutineStart.DEFAULT, block: suspend CoroutineScope.() -> T): Deferred<T>
```

値が必要になったらawait()を呼び出します(ブロッキングコール)
値が利用可能であれば、すぐに返されます。
値が得られない場合は、得られるまでスレッドを一時停止します。

下記は、Coroutine で処理した内容が終わったタイミングで待ち合わせて、ランダム値の合計を返す例になります。簡単に説明すると、最初に2秒間後ランダム値を取得して、 次に3秒間かけてランダム値を取得します。その結果を待ち合わせして、合計値を算出したケースになります。つまり、getValueByAPI２と合わして並列に実行されてMax(1秒, 2秒, 3秒)で約3秒で実行されます。

サンプル:
```
import kotlinx.coroutines.async
import kotlinx.coroutines.delay
import kotlinx.coroutines.runBlocking
import kotlin.system.measureTimeMillis

fun main() {
    var time = measureTimeMillis {
        runBlocking {
            val firstDeferred = async { getValueByAPI1() }
            val secondDeferred = async { getValueByAPI2() }

            println("Doing some processing here")
            delay(1000)
            println("Waiting for values")

            val firstValue = firstDeferred.await()
            val secondValue = secondDeferred.await()

            println("The total value is ${firstValue + secondValue}")
        }
    }
    println("The total time (API1 + API2): ${time/1000.0}s")
}

suspend fun getValueByAPI1(): Int {
    delay(2000)
    val range = (1..1000)
    val value = range.random()
    println("Return value $value from API1")

    return value
}

suspend fun getValueByAPI2(): Int {
    delay(3000)
    val range = (1..1000)
    val value = range.random()
    println("Return value $value from API2")

    return value
}
```

出力結果:
```
Doing some processing here
Waiting for values
Return value 29 from API1
Return value 987 from API2
The total value is 1016
The total time (API1 + API2): 3.118s
```

 次回は、Gradleを使ったプラグインの作成をやります。


Kotlin async/await

Firebase Dynamic Links + Flutter


Vue.js のフレームワークである **[Nuxt.js の v3](https://v3.nuxtjs.org/docs/usage/data-fetching)** が、2021/10/12 にパブリックベータ版に移行しました 🎉  
Monstarlab でのプロジェクトの多くは React.js で開発されることが多いですが、個人的には一番初めに触れた Web Frontend JavaScript フレームワークが Vue.js だったこともあり、Nuxt.js も v1 リリース直後から使っていました。  
そんな思い入れがあるフレームワークで、社内でも Vue/Nuxt が好きと公言していますが、最近は触れることがあまりなくなってしまい・・・いい機会なので、今回は Nuxt3 について変更点や改善点をまとめようと思います。

## Nuxt.js について

このブログを見ているほとんどの方はすでに Nuxt.js について知識があるかもしれませんが、まずは Nuxt.js について簡単に説明します。

Nuxt.js は、JavaScript フレームワークである Vue.js の Web アプリケーションフレームワークで、Vercel が開発した **[Next.js](https://nextjs.org/)** に影響を受けて開発されました。基本的には Vue.js で開発するために必要なエコシステムや開発に必要な規約を簡単に導入できることに加え、SSR/SSG/SPA それぞれのレンダリングモードで Build 可能であり、個人的には Vue.js で開発するのであれば Nuxt.js を使用することを一番に考えるくらい良くできたフレームワークだと思います。

一般的に大規模開発に Vue.js は向かないよね・・・という話を Web Frontend 界隈ではよく聞きますが Nuxt.js の規約をもとに開発することで、規模が大きいプロジェクトでも十分使用できると思っています。大規模の場合 Vue.js だとパフォーマンスが・・・などの記事も見ますが、フレームワークによるパフォーマンスの優劣を感じたことはそこまで多くありません。（あくまで個人的見解です）  
React.js も Vue.js も開発がどんどん進み、より速くより便利になっていますので、どちらかがより良いということはないかもしれません。Monstarlab では React が多く使われていると冒頭で記載しましたが、これは TypeScript が Web frontend 開発においてスタンダードと言って良い状況の中で、Vue.js＆TypeScript の課題が多くあったことが一番の理由なのかなと感じます。

今回の Nuxt3(Vue3) は TypeScript のネイティブサポートもされており、今後は今までよりも Nuxt.js を選択する可能性があるのでは？と期待しています。

## Nuxt3 の主な新機能/変更点

Nuxt2 → Nuxt3 は大部分が新たに設計、開発されたようで多くの新機能や変更点があります。リポジトリも新しく作られていますね。  
_Nuxt2 https://github.com/nuxt/nuxt.js_  
_Nuxt3 https://github.com/nuxt/framework_

主な新機能は *https://v3.nuxtjs.org/* に記載されています。
![Nuxt3|With new features]({{ sitePrefix }}/assets/img/articles/2021-11-17-Nuxt3-beta-arrived/article_image1.png)

上記以外にも細かな部分含め多くの変更があるようですが、この中でも個人的に大きな変更点は以下です。

- Vue3 のサポート
- TypeScript のネイティブサポート
- Nitro Engine

### Vue3 のサポート

2021 年 9 月にリリースされた **[Vue3](https://v3.vuejs.org/)** を採用しており、CompositionAPI や Teleport、 `<script setup>`、Vite など、Vue3 で新しく追加された機能をすでにサポートしています。ただしその代わり Vue2 はサポートしていないため、Nuxt2(Vue2)からの移行には **[Nuxt Bridge](https://v3.nuxtjs.org/getting-started/bridge)** が用意されています。一部の機能は使えませんが Nuxt3 で追加された多くの機能は Nuxt Bridge を使用することで体験できそうです。

![Nuxt3|With new features]({{ sitePrefix }}/assets/img/articles/2021-11-17-Nuxt3-beta-arrived/article_image2.png)
*https://v3.nuxtjs.org/getting-started/introduction#comparison*

まずは既存の Nuxt2 プロジェクトに Nuxt Bridge を適用することが、Nuxt3 によるパフォーマンスの改善を感じることができる一番の方法かもしれません。

### TypeScript のネイティブサポート

Nuxt3 も Vue3 も JavaScript から TypeScript へ一新され、Composition API への変更もあり TypeScript の恩恵をストレスなく受けることができるようになりました。個人的にはこれが一番よかった、というかやっと対応した・・・という気持ちです。最近 React ばかり使っていた中で、やっとこれで Nuxt も本格的に使えるかも！と期待しています。（まだパブリックベータなのでもう少し時間はかかるかもしれません）

### Nitro Engine

おそらくこの新機能が一番話題になっていたように思います。Nuxt3 のサイトでもトップページで大きく取り上げていました。軽量で高速に動作し、Nuxt2 ではなかった機能も新たに追加されています。まだローカルでいくつかの機能を確認したレベルですが、動作については Nuxt2 よりも高速に Server が立ち上がりました。開発ではローカル環境でのパフォーマンスも重要になりますので、よりストレスを感じなくなって効率が上がるのではないかと思います。（Vite や Webpack5 への移行も影響していると思います）  
Nitro Engine については私もまだ理解できてない部分が多いのですが、主な機能を 2 つ紹介します。

#### クロスプラットフォームのサポート

いわゆる SSR(Server Side Rendering)をするために、Nuxt2 では Node.js が必要でしたが、Nitro Engine の採用により複数の環境での実行が可能になりました。この機能はかなり驚きで、Web Frontend の開発が今までとは違う選択肢を持つ可能性があると感じました。情報がまだ少なく完璧には理解できていないので、間違った部分もあるかもしれませんがご了承ください 😔  
Document 内では以下のような環境が記載されていました。

- Node.js
- Browser
- service-workers
- serverless

具体的には Nuxt3 の **[Docs](https://v3.nuxtjs.org/docs/usage/data-fetching)** の Deployment にいくつかのサービスでのデプロイ方法について説明されています。

- Azure (Azure Functions)
- Cloudflare Workers
- Firebase Hosting
- Netlify
- PM2
- Vercel
- Presets
  - Node.js server (default)
  - Node.js function
  - Lambda function
  - Service worker

設定方法はとても簡単で、`nuxt.config.ts` に Nitro Engin のターゲットを設定するだけのようです。

```JavaScript
export default {
  nitro: {
    preset: 'worker' // service-worker
  }
}
```

ただし、ローカル環境で Build が上手く行かず確認することはできませんでした 😞

今までは Nuxt をデプロイするにあたって、Node.js を使用できるサーバーで SSR、CloudFront+S3 や Netlify などで Hosting する場合は SSG で静的ファイルを生成した上でリリース、という選択肢をまず考えていました。  
今回の変更により、Node.js だけでなく CDN の Edge server や Netlify のような Hosting サービス、ブラウザの Service worker でサーバーが動作するようです。上記のような様々な環境でサーバーを起動できるということは、今までの選択肢だけでなく Serverless + JAMstack のような新たな選択肢をより簡単に使用できる事になりそうです。  
Github には Nitro Engin のデモリポジトリもあり、いくつかのサービスに Nitro Engin を使用した Nuxt でもサイトがデプロイされていました。

Github: _[nuxt/nitro-demo](https://github.com/nuxt/nitro-demo)_  
Nitro Project Demo: _[Netlify](https://nitro-demo.netlify.app/)_

Vercel, Cloudflare など他のデモサイトもありましたが、全て SSR が上手く動いているわけではなく中には 404 のページもあったので、現時点ではなんとも言えませんが・・・Netlify で SSR ができていることはすごいですね。

#### API ルートのサポート

Nuxt プロジェクトの中で API エンドポイントを作成できるようになりました。この機能は Next.js などではすでに実装されているので馴染みがある方もいるかも知れません。  
`server/api` ディレクトリに `xxx.ts|js` ファイルを作成すると、クライアント側から呼び出すことができるエンドポイントとして提供され、`/api/xxx` という形で呼び出せます。また、Nuxt3 で追加された `useFetch()` `useAsyncData()` でエンドポイントを呼び出した場合、自動的に type ファイルが生成されレスポンスに対して型が定義されます。  
例えば以下のようなエンドポイントを作成し、

```TypeScript
// server/api/test.ts

import type { IncomingMessage, ServerResponse } from 'http'

let count = 0

export default async (req: IncomingMessage, res: ServerResponse) => {
  return {
    Hello: "Monstarlab",
    count: ++counter,
  }
}
```

`yarn dev` もしくは `yarn build` を実行した場合、`.nuxt` ディレクトリに以下の定義が自動的に作成されます。

```TypeScript
// .nuxt/nitro.d.ts

// Generated by nitro
declare module '@nuxt/nitro' {
  type Awaited<T> = T extends PromiseLike<infer U> ? Awaited<U> : T
  interface InternalApi {
    '/api/test': Awaited<ReturnType<typeof import('../server/api/test').default>>
  }
}
export {}
```

結果、以下のように Pick 型で定義されました。

```TypeScript
const response: Ref<Pick<{
    Hello: string;
    count: number;
}, "Hello" | "count">>
```

もちろん、外部の API を `server/api/xxx` で呼び出した場合には any 型になってしまうので型定義が必要ですが、開発する際にかなり便利な機能ではないでしょうか。

## 最後に

他にもディレクトリの構造が変更されたり、CLI が新しくなったりと様々な変更点がありますが、私が感じた大きな変更点としては以上となります。（ちなみに IE はサポートしていません 😇）  
まだベータ版ということで、すぐにプロジェクトで使用できるとは思っていませんが、今後の Web Frontend 開発の選択肢の一つとして十分に期待できるフレームワークだと感じる事ができ、Nuxt(Vue)ファンとしてはとても嬉しいです 🥳

_Article Photo by [NuxtJS](https://v3.nuxtjs.org/)_


Nuxt3 beta arrived 🎉


こんにちは皆さん、モンスターラボ CTO APAC の 平田 です。この記事ではデータ利活用について書きます。

## データの利活用と言うものの？

「データは21世紀の石油だ」「データ活用が企業の命運を握ることになる」と言われます。
データの利活用がデジタル・トランスフォーメーション(DX)の鍵になるのは、おそらく間違いありません。ただ、データの利活用といっても、それが意味しているものが何か、人により捉え方はさまざまです。ある人にとっては機械学習であり、他の人にとってはデータ駆動経営を意味しています。他にも色々な捉え方があります。
データ活用のフィールドは昨今の盛り上がりもあり、ソフトウェアエンジニアだけでなくビジネスサイドなど多種多様な分野からの人の流入があり、多くの視点や観点で語られる混沌とした状況にあります。

![]({{ sitePrefix }}/assets/img/articles/2021-11-02-Three-ways-to-unlock-value-from-data/2021-10-29-18-10-15.png)

データの利活用は重要に違いないが、ビジネスでの活用や実際に成功にまで結びつけていく必要があり、そのためのより良い認知マップが必要だと感じます。この記事では、私が普段仕事を通じて得た、また書籍や動画を通じて学んだデータ利活用について、まとめてみようと思います。

## データ利活用の3種

1. データ駆動経営、分析、ターゲッティング
2. AIにより単純作業をなくす。ノウハウのAI化
3. データの組み合わせや保有データの新たな展開で新しいValueを創出する

この分類は、デジタル庁の平本 健二さんの[2021データ研修](https://www.youtube.com/watch?v=nuK3rnRhIQo)にインスパイアされています。それぞれでオーバーラップしている部分もあり、明確な線引はないですが、データの利活用方法をうまく分類出来ていると思います。
ひとつずつ簡単に見ていきましょう。

## 1.データ駆動経営、分析とターゲッティング

まずは「1.データ駆動経営、分析とターゲッティング」からです。
事業経営のモニタリングや方向性の決定をデータドリブンに行う取り組みです。データ利活用の王道と思います。
プロダクト開発の現場では、ソフトウェア・プロダクト開発する側も、ユーザー自身も現在の自分にどんなプロダクトが必要なのか分からない、誰もが答えを持っていない状況の中、事業を進める必要があります。正解がないものを作るということは、すべてが「仮説」ということになります。この仮説検証のために、

- 「アジャイル開発」であれば、プロダクトを適切な粒度で、素早く作り、ユーザーへ提供する、ユーザーの反応を学びながら、仮説検証を繰り返していくことになります。
- 「デザイン思考」であれば、例えば、仮説を持ってユーザーにインタビューすることで、仮説の正しさらしさを検証したり、課題の感覚を拾い上げたり、カスタマーの隠れたニーズを引き出したりします。
- 「データ駆動」では、データを見ることで仮説を検証し、少し先の未来を予測しながら事業を作っていく。「直感」や「経験」でしか考えらなかった問題に対して、データを武器にして、より客観的に見た指針で、次の戦略・仮説を立案する。主観のぶつかり合いではなく、客観的に見た指針で、スピード感をもった意思決定ができる場面を増やすということになるでしょう。

以下の図は、データ駆動経営の大まかな流れです。

![]({{ sitePrefix }}/assets/img/articles/2021-11-02-Three-ways-to-unlock-value-from-data/2021-10-29-16-35-23.png)

事業構造を数値モデル（KPIツリー）として正しく理解して、事業の観測可能性をあげます。そこから見えてくる勝ち筋に対するアプローチを検討するためにデータを活用するもので、指標に基づいた仮説検証ループ（構築 Build->計測 Monitor->学習サイクル Learn）を回しながら、日々事業改善を行います。
開発現場目線では、単にECサイトをソースコードを書いて構築していくだけではダメで、ユーザーの一挙手一投足を細かくトラッキングすることが必要です。このページをクリックして、ここまでページスクロールした上で購入ボタンを押したこのユーザーは、30歳男性で東京に住んでいるユーザーである。というようなものです。
ミクロな行動をしっかりと捉え、分析基盤を通じて売上のようなマクロなKGIを分析できるようにするなど、ミクロとマクロがシームレスにつながる状態を目指します。言い換えれば、財務諸表（P/L）からユーザーの行動までを結びつけるということです。

仮説検証ループ（構築 Build->計測 Monitor->学習サイクル Learn）の内、計測に特化した書籍が「LEAN Analytics」で、優れた KPI の特徴や事業のステージ毎にどのようにデータを活用していくのか、例を含めて丁寧に説明してあり役に立つと思います。仮説の検証にはA/Bテストなどが使われます。
また、書籍「DMM.com を支えるデータ駆動戦略」が、このテーマを扱っており、全体感の把握にとても参考になります。

### データ駆動経営の副産物 パーソナライズとAIを使ったデータ分析

データ収集のインフラが出来て、データが多く集まれば、機械学習による自動化・個別最適ができる基盤ができてきます。代表的なものが商品のレコメンドで、あなたにおすすめの商品はこちら、というものです。膨大なログデータから、ユーザーの趣味嗜好にあった商品などをおすすめします。コンテンツ、ユーザー属性、ユーザーの行動が合わせてリコメンデーションエンジンを作ります。
パーソナライズだけでなく、蓄積されたデータで機械学習を使った分析を行い、よりハイレベルな課題に取り組むことができます。どの商品をどこで売るべきか、新しい店舗はどこに開くべきか、閉じるべきかなどの複雑な問に対して、データ分析で答えていきます。

### データ分析基盤

データ駆動経営を支えるインフラ基盤にはいくつかベーシックな型があります。以下は AWS によるラムダアーキテクチャの例です。バッチ処理を行うScaleレイヤとリアルタイム処理を行うSpeedレイヤがあります。

![]({{ sitePrefix }}/assets/img/articles/2021-11-02-Three-ways-to-unlock-value-from-data/2021-10-29-17-10-18.png)

## 2. AIにより単純作業をなくす。ノウハウのAI化

次は、「2. AIにより単純作業をなくす。ノウハウのAI化」です。
AIの活用範囲は広大で簡単にまとめることは難しいですが、大雑把に捉えれば、蓄積されたデータを活用し、AIを使って業務効率化、自動化を目指すものといえると思います。具体的な事例は多くの場所で見つけることができるので、ここではAIを活かした事業戦略の検討に便利なフレームワークを紹介します。
「ダブルハーベスト」という書籍では、継続して価値を発揮するAIを構築するためのフレームワークが紹介されています。

![]({{ sitePrefix }}/assets/img/articles/2021-11-02-Three-ways-to-unlock-value-from-data/2021-10-29-16-42-51.png)

- 活用するAIの機能は何なのか？
- そのAIに何をさせるのか？
- 増大させたい最終価値は何なのか？
- 向上させたいUXは何なのか？
- そのAIを活用した活動を行うことで自然と蓄積されるデータは何か？
- 蓄積されたデータを使ってさらにAIを強化できるのか？

こうした問いに答えることで、検討中のAI戦略の筋が良いものなのかを明らかにします。特にデータが持続的にたまり、それによってAIの精度が上がり続けるループ構造（ハーベストループ）が構築できるかは重要であり、さらには事業を特徴づける他社が簡単に真似できない競争優位のあるデータを育てることができるかという発想も大事です。少ないデータ量で達成できるAIは、いずれレッドオーシャンになってしまいます。ループが構築できてしまえば、当初はデータの蓄積がなくても、事業活動により自然とデータが蓄積され、精度は後からついてくると考えます。設計段階からどんなデータを集めるかを考えて、AI戦略をデザインします。

## 3. データの組み合わせや保有データの新たな展開で新しいValueを創出する

最後に「3. データの組み合わせや保有データの新たな展開で新しいValueを創出する」です。
最もよく聞く例としては、気象データとTweetを組み合わせて販売量を予測するというものです。急ブレーキデータを都市計画に使う、というクリエイティブなものもあります。
既に蓄積されたデータのうち有効利用されずに保存されているデータのことをダークデータといいますが、新たな使い道を見出せる場合もあります。たとえば、カスタマーサポートで録音された音声が蓄積されているが有効利用されていない。よくあるお問い合わせを抽出してFAQとして活用したい。チャットボットによる応答に使いたいなどです。
スマートシティーは、データの組み合わせで価値を発揮できる良い例です。分野を横断してデータを組み合わせる。データを使いこなせるかどうかでサービスの競争力が変わり、より豊かに暮らせるかが変わります。
先に紹介した平本 健二さんの[2021データ研修](https://www.youtube.com/watch?v=nuK3rnRhIQo)に、とても刺激的なスライドがあったので引用します。

![]({{ sitePrefix }}/assets/img/articles/2021-11-02-Three-ways-to-unlock-value-from-data/2021-10-29-18-05-32.png)
![]({{ sitePrefix }}/assets/img/articles/2021-11-02-Three-ways-to-unlock-value-from-data/2021-10-29-18-05-58.png)

これらのデータを組み合わせれば何ができそうか、夢が膨らみますね。

## 最後に

データが生み出す価値をプロダクト開発に取り込む3つの方法を簡単に紹介しました。それぞれの How や事例については、またの機会に深堀りしたいと思います。実際の開発現場でも、これらのデータの利活用をどんどん進めて、より良い社会をつくりたいですね。


データが生み出す価値をプロダクト開発に取り込む３つの方法


こんにちは。奥田@島根です。

今回のブログでは、私の担当しているプロジェクトで利用していて便利と感じているにもかかわらず、あまり日本語の Web記事が多くない (日本での利用実績が多くない?) Twingate を紹介します。

## Twingate とは

昨今、リモートワークが推奨され、オフィスに出社する機会は減っていることでしょう。モンスターラボでもリモートワークが推奨されています。
自宅などの不特定なネットワークから開発環境などの制限されたネットワークにアクセスする際、どのような手法を取っているでしょうか。多くの企業では VPN を利用していることと思います。
Twingate は VPN　を置き換え、セキュリティ/メンテナビリティ/パフォーマンス/ユーザビリティを高めるソリューションです。

## Twingate のアーキテクチャ

Twingate はゼロトラストモデルをベースとしたアーキテクチャを採用しています。

![Twingate Architecture](https://files.readme.io/b886d14-Twingate-Overview.png "[title](https://files.readme.io/b886d14-Twingate-Overview.png)")
Reference: https://docs.twingate.com/docs/architecture-overview

## VPN vs Twingate

Twingate が VPN のどんな問題を置き換えるか、説明します。

### セキュリティ
- アクセス制御
  - VPN では VPN ゲートウェイとの間でコネクションを確立すると、VPN経由のアクセスを許可したすべてのネットワークにアクセスできます。例えば複数のプロジェクトの開発環境が存在する場合、担当外の開発環境にもアクセスできてしまうため、セキュリティ担保の観点で好ましくないでしょう。各プロジェクトごとにBASIC認証などの他の認証システムの導入も併せて検討が必要となりそうです。
    一方、Twingate ではリソース単位でのアクセス制御が可能となるため、特定のユーザやユーザグループのみにアクセスを制限することができます。
- インターネットへの露出
  - VPN の場合、VPN ゲートウェイをインターネットに露出する必要があります。すなわち、攻撃の脅威にさらされる事となります。
    一方 Twingate の場合、コネクタはインターネットへのアウトバウンドアクセスのみ持てばよく、プライベートなネットワークにホストすることができるため脅威にさらされることはありません。

### パフォーマンス
- リソース制限
  - Twingate では指定したリソースへのアクセスのみ Twingate を経由します。そのため、例えば Twingate を有効にしたまま動画配信サービスで動画を視聴しても、意図せず Twingate を経由することはありません。

### メンテナビリティ
- 設定
  - ユーザ、ユーザグループ、リソース、ネットワークなどの設定は Twingate コンソール上から設定できます。 Twingate ネットワークの Admin 権限さえあれば設定可能となるため、複雑なユーザ権限管理をする必要もありません。
- デプロイ
  - Twingate コネクタのデプロイは Docker / Helm / AWS ECS / Manual など多くのデプロイ方法が手順化して用意されているので、導入も容易です。Twingate コネクタとアクセス対象のリソースの間で通信ができること、Twingate コネクタがインターネットへのアウトバウンドアクセスが可能であること、の2点だけが注意すべきポイントです。

### ユーザビリティ
- 対象デバイス
  - VPN ソフトウェアによっては、接続可能なデバイスに制限があります。弊社の VPN ソフトウェアの場合、モバイル端末からの VPN 接続に問題があるようです。Twingate の場合、iOS / Android / macOS / Windows / Linux / Chrome OS 向けのクライアントアプリが用意されているので、ほとんどのデバイスをカバーできるでしょう。デバイスにクライアントアプリをインストールし、Twingate ネットワークに接続するだけで簡単に指定したリソースにアクセスできます。

## 料金
Twingate を導入するには以下の料金がかかります
- Twingate の利用料金
  - Teams プラン: $6 [user / month]
  - Business プラン: $12 [user / month]
- Twingate Connector のインフラコスト (EC2など)

注意点として、Teams プランでは最大50ユーザ/5リモートネットワーク、Business プランでは最大150ユーザ/10リモートネットワークの制限があり、大規模なプロジェクトの場合やクローズドテストを行おうとした場合は容易に制限を超えてしまうことが考えられます。その場合はカスタムの Enterprise プランも用意されていますのでサポートに問い合わせてみるとよいでしょう。

## Twingate 導入のステップ

それでは実際に Twingate の導入を試してみましょう。
今回はプライベートネットワーク内のローカルPCに立ち上げた Web アプリにネットワーク外からアクセスしてみようと思います。
なお、Twingate にはフリートライアル期間がありますので、この手順は無料で試すことができます。

### 0. Web アプリケーションの構築

アクセスするための Web アプリケーションを構築・実行しておきましょう。以下は Rails の例です。

```bash
$ rails new twingate_sample
$ cd twingate_sample
$ rails s -b 0.0.0.0
```

### 1. Twingate ネットワークの作成

[Twingate の Webページ](https://www.twingate.com/) にアクセスし、 [Create a new Network](https://auth.twingate.com/signup) リンクからネットワークを構築しましょう。サインアップやネットワーク名の入力などが求められます。画面の案内に従って入力していけばよいでしょう。

### 2. Connector の構築

次にコネクタを構築します。
まずリモートネットワークの Location は、今回は **On Premise** を選択します。
次に **Add Connector** > **Deploy Connector** と選択し、デプロイ方法には **Docker** を選択しましょう。
**Generate Token** すると、Twingate コネクタを Docker で実行するためのコマンドが表示されますので、それをコピーし、(Webアプリケーションを実行している) ローカルPC上で実行しましょう。
Twingate コンソールのコネクタ一覧に表示されるコネクションステータスが **Connected** になったらコネクタの構築は完了です。

### 3. Twingate リソースの設定

ローカルPC上のWebアプリケーションにアクセスするため、ローカルPCのプライベートアドレスをリソースに追加します。 Twingate コンソールから作成した Twingate ネットワークの画面に進み、 **Add Resource** を選択します。
CIDR を選択し、DNS Address にローカルPCのプライベートアドレス(例:192.168.10.100/32)を入力します。Label は任意で OK です。
次に、作成したリソースに対し、デフォルトで存在する **Everyone** グループを割り当てます。これで、Twingate ネットワークにアカウントを持つ全てのユーザが作成したリソースにアクセスできるようになります。

### 4. クライアントアプリのセットアップ

ここでは iPhone にアプリをセットアップしていきます。
App Store で **Twingate** と検索すると Twingate アプリが表示されるのでインストールします。
インストール後は作成した Twingate ネットワークのネットワーク名(*.twingate.com)を入力し、サインインします。

### 5. 確認

セットアップが完了しましたので、 iPhone からローカルPC上の Webアプリケーションにアクセスしてみましょう。(Twingate 経由でアクセスできていることを明確にするため、WiFi の接続を OFF にしてモバイル回線を利用するとよいでしょう)
iPhone のブラウザでローカルPCの Webアプリケーションの URL を入力してみましょう。(例: http://192.168.10.100:3000)

これだけのステップで簡単にプライベートなリソースにアクセスできます。

## まとめ

Twingate はサービス利用料はかかりますが、面倒な管理や保守、セキュリティリスクから開放されることを考えるとよい選択肢になるのではないでしょうか。14日間のフリートライアルもあるので、まずはその使い勝手のよさを試してみましょう。

Open the Twingate!


Open the Twingate

テストの基礎 その1

iOSアプリのCI/CDフロー ベストプラクティスガイド：gitブランチ戦略の選択から、FastlaneとCircleCIを利用して、Firebase App Distributionへの配布まで


私にとって初めてのデベロッパーカンファレンスだった「RubyKaigi」に参加してから、もう丸 1 年が経ったなんて信じられません。　この3日間、私は今年のトークやセッションを楽しむ機会に再び恵まれました。残念ながらここ最近は自身の業務のためにしばらく離れていた Ruby のエコシステムでしたが、それに再び浸ることができたのです。この記事では、カンファレンスでのお気に入りの瞬間をいくつか紹介したいと思います。

## RubyKaigi について

バラエティに富んだセッションの詳細を説明する前に、そもそも RubyKaigi とは何かを改めて説明することで、われわれの共通認識を確認させてください。[RubyKaigi](https://rubykaigi.org/2021-takeout)は、2006 年から（2012 年を除いて）毎年開催されている日本最大の Ruby プログラマのためのカンファレンスです。昨年同様、発表や議論の一部は日本語で行われますが、日本語を知らない多くの国際的なメンバーのために、同時通訳サービスが用意されていました。

それから昨年同様、今年の RubyKaigi はオンラインのみのカンファレンスに変更されました。来年は本来のイン・パーソン形式のカンファレンスに戻れることを願っています。

## TypeProf for IDE

遠藤侑介さんの基調講演では、静的型付けの利点と、Ruby 3.0 に同梱されているコード解析ツール[TypeProf](https://github.com/ruby/typeprof)についての説明があり、カンファレンスは大いに盛り上がりました。TypeProf を搭載した Visual Studio Code の拡張機能である TypeProf for IDE の発表がこの直後に行われ、これがこの日の特別発表でした。

TypeProf for IDE は、メソッドのシグネチャに関するヒントをオンザフライで提供したり（Code Lens に便利に表示されます）、入力中にエラーを報告したり、呼び出したメソッドの定義場所を見つけたり、型を考慮したコード補完を提供したりできます。もちろん、いつものように、TypeProf がメソッドの型を間違って推測した場合は、RBS を使ってメソッドのシグネチャを手書きして推測された型を上書きすることもできます。TypeProf for IDE は Ruby 3.1 とともにリリースされる予定ですが、上記の説明に興奮した方は、いくつかの手動ステップを踏むことで[いますぐに](https://gist.github.com/mame/86234de6a58352b9f994e0f8a6d6fbc2)使い始めることができます。

簡単なスクリプトを書いたり、コードにちょっとした変更を加えたりするために、本格的な IDE（心配無用です、私はまだ RubyMine を愛しています）を開く必要はありませんからね。

## "Ruby Archaeology", "Parallel testing with Ractors: putting CPUs to work" and "Regular Expressions: Amazing and Dangerous" 💎⛏

RubyKaigi の初日にはほかにも多くの素晴らしいセッションが行われましたが、もし 3 つだけ紹介するとしたら、Nick Schwaderer 氏による「Ruby Archaeology」は間違いなくその 1 つになるでしょう。ニックさんの講演では、Ruby の古代史を調べ、12 年前のバージョンの Ruby を動かすために乗り越えなければならなかった試練や罠をすべて説明してくれました。驚いたことに、Ruby 自体は当時の OS で問題なく動作するにもかかわらず、ほとんどの問題は別のところにあるようでした。特に、昔と同じようにはアクセスできないかもしれなく、リモートリソースに依存していることです。幸いなことに、ニックの足跡をたどって自分もタイムトラベラーになりたいと思っても、[彼のように頑張る必要はない](https://github.com/Schwad/portal_gun)のです。

それから、Ractor を利用してテスト実行を高速化するテストフレームワークの研究（テストスイートが遅いと、開発者の実行意欲が減退してしまいますからね）についての Vinicius Stock 氏の発表と、Martin J. Dürst 氏の驚くべき、しかし時に危険な正規表現の世界へのツアーがこの日のハイライトでした。

## キーボードは実質 Ruby、あるいは ⌨ = 💎

さてさて、これは私の偏見かもしれませんが、それでも言わなければなりません。カンファレンス全体とは言わないまでも、2 日目の個人的なハイライトは、弊社 Monstarlab の羽角均による[PRK Firmware](https://github.com/picoruby/prk_firmware)です。他のスピーカーやプレゼンテーションがどれほど素晴らしかったかを考えれば、これはかなりの快挙です。

羽角によるライブプレゼンテーションは、オーディエンスの心を揺さぶり続けていました。まず、自作のキーボードのファームウェアを Ruby でプログラムできるということ自体が、非常に素晴らしいことです。彼が「フィボナッチ」キーや「パスワードジェネレータ」キーで示したように、特定のキーを Ruby コードの実行に割り当てることができるのは、さらに素晴らしいことです。そしてさらに完全に別世界へぶっ飛んだレベルでは本当に驚かされました --- 「Ruby」キーが、キーボードと任意のテキストエディタ（Notepad.exe のようなシンプルなものでさえ）を、IRB シェルへと変えてしまいました。どこへでも Ruby を持ち歩くことができます。ただしその前に、PicoRuby における[静的型チェックの記事](https://engineering.monstar-lab.com/2021/05/27/Static-type-checking-in-PicoRuby)をお読みになることをお忘れなく。

## Graphical Terminal User Interface of Ruby 3.1

率直に言って、私はスマートで直感的でユーザーフレンドリーなターミナル・ユーザー・インターフェース（TUI）の大ファンです。IRB は、強力な自動補完機能、自動インデント、シンタックスハイライトなどを備える、すでに非常にスマートな REPL（read-evaluate-print-loop --- 自尊心のあるプログラミング言語ならば提供すべき）環境ですが、糸柳茶蔵さんの野心はそれだけに留まらないようです。Reline ライブラリを改良することで、Ruby 3.1 の IRB は、これまでのように`Tab`キーでコードを自動補完するだけでなく、他の IDE のように、可能なすべてのオプションを美しいドロップダウンメニューで表示するようになります。

## Do regex dream of Turing Completeness? 😴💭

[Conway's Game of Life](https://playgameoflife.com/)を正規表現で完璧に実装することで、正規表現がチューリング完全であるかどうかを調べるという Daniel Magliola 氏の調査目的で、RubyKaigi の 3 日目（最終日）がスタートしました。正規表現は十分にはチューリング完全ではないが、それほど的外れではないことがわかったという結論をお伝えするくらいなら、あまりネタバレにならないと思います。このトーク全体が非常に見応えがあり、Daniel 氏の創意工夫だけでなく、これまで気づかれていなかったかもしれないような正規表現の力と奇抜さを示しています。

## Native extensions and dead ends

続いて、Mike Dalessio 氏によるネイティブ・エクステンション（"this could take a time..."というメッセージは、誰もが過去に見たことがあり、端末に表示されるたびに少しため息をついたものです）とネイティブ gems（特定のアーキテクチャ用にコンパイル済みのライブラリを含み、C 言語のエクステンションを自分でコンパイルする必要がないもの）についての興味深い講演が行われました。

Richard Schneeman 氏は、非常にプロフェッショナルなプレゼンテーションで、[`dead_end`](https://github.com/zombocom/dead_end)に関する彼の研究を実演しました。これは、次回から「予期せぬ終了」エラーメッセージを簡単に診断して修正するのに役立ちます。これによって、 `end` や `do` といったキーワードの欠落や、 `|` や `}` といったシンボルの不一致を診断することができるのです。

## まつもとゆきひろ "Matz" さんのクロージング・キーノート

最後に、まつもとゆきひろさんのクロージング・キーノートでカンファレンスは締めくくられました。

前半では、比較的最近リリースされた Ruby 3.0 を振り返りました。このリリースは、（Ruby 2.0 以来）約 8 年ぶりのメジャーリリースであると同時に、後方互換性の重要性を念頭に置いたリリースでもありました。というのも、一部のコミュニティにとっては驚くべきことかもしれませんが、開発者は古いコードが動かなくなって書き直さなければならなくなるほどに新しいものを、あまり好きではないからです。

まつもとさんは、Ruby 3.0 が開発者にもたらした素晴らしい追加機能を紹介しました。例えば、RBS による型定義のサポートは、概念的には TypeScript の `d.ts` ファイルに似ていますが、個人的には、性質も構文も Elixir の Dialyzer と Typespecs に非常によく似ていると感じています。番号付きのブロックパラメータとパターンマッチのサポート（面白いことに、私が Elixir で気に入っていて、Ruby でも見られることをとても喜んでいる 2 つの機能です）も、より良い並行プログラミングのための 2 つのアプローチと同様に言及されました。高速なコンテキストスイッチを備えた Fiber スケジューラーは、I/O を多用する処理において理想的であり、Ractor は CPU を多用するすべてのタスクの窮地を救ってくれます。

話題は、次期リリースの Ruby 3.1 に焦点を移しました。Ruby 3.1 は、安定性の向上、より多くのバグ修正、そして特に 2 つのことを主な目的とした保守的なリリースになると述べられました。より強力な IRB と TypeProf for IDE による「開発者の快適さ」と「さらなるスピード」--- ただし理想的には、人工的なベンチマークで数値を無意味に追い求めるようなスピードではなく、現実のアプリケーションで本当に必要とされるスピードです。

私は、開発者の快適性がプログラミング言語の存続に関わる重要な要素の一つであると考えているので、この 2 つの側面に焦点を当てた決断を称賛せずにはいられません。来年の RubyKaigi にも参加したいと思っていますので、どうぞよろしくお願いします。


RubyKaigi Takeout 2021を振り返る

Steffen D. Sommer