Classi開発者ブログ

教育プラットフォーム「Classi」を開発・運営するClassi株式会社の開発者ブログです。

RubyKaigi Takeout 2021 参加レポート

はじめに

Classi 株式会社 開発本部です。

先日開催された RubyKaigi Takeout 2021、弊社もスポンサーとして後援したりメンバ数名が参加してセッションを見たりして盛り上がりました。
毎日の開発で日常的に使いつつもどんな人がどのように作っているかをあまり意識していない Ruby そのものについて色々なことが知れる刺激的な Kaigi だったと思います。

以下、参加したメンバの印象に残ったセッションの感想になります。

Ractorをワーカーとして使うアプリケーションサーバの課題

1年前に新卒入社したWebtestチームの@minhquangです。 Classiのおかげで、初めてのRubyKaigiに楽しく参加できました。 私にとってほぼ未知の世界なので、様々なセッションを見てみました。
今回は一番興味があった tagomoris さんRactor's speed is not light-speedに関するお話を紹介します。

Ractor は 笹田さんから2016年に紹介されて、CPUのコアを並列で実行できる仕組みとしてRuby 3.0に導入されました。 (※ Ractorの仕様を詳しく知りたいなら、Ruby repository の資料をご覧ください)

Ractor間でオブジェクトはメッセージとして共有されるのですが、以下のオブジェクト以外は共有禁止されています。

  • Module, Classes
  • Application Code (Proc)
  • Definitions (constants), Settings/Configurations (frozen objects)

Ractor間でオブジェクトを共有するには、オブジェクトにshareableをマークする必要があります。

# Usual Proc
x = 1
p1 = ->() { x + 2 }

p p1.call #=> 3

x = 5
p p1.call #=> 7


# Isolated Proc
x = 1
p2 = ->() { x + 2 }
p Ractor.shareable?(p2)
# false
Ractor.make_shareable(p2)
p Ractor.shareable?(p2)
# true
# p2 is isolated

p p2.call #=> 3

x = 5
p p2.call #=> 3 (!)

このようにマークすると、Proc自体はisolatedになって共有できるようになります。

けど、Procの中で共有できないオブジェクトがある場合はもうちょっと深くisolated化にする必要があります。

s1 = "Yaaaaaaay"
p3 = ->(){ s1.upcase }
p Ractor.shareable?(p3)
=> false
Ractor.make_shareable(p3)
# <internal:ractor>:816:in `make_shareable': can not make shareable Proc because it can refer unshareable object "Yaaaaaaay" from variable `s1' (Ractor::IsolationError)

s2 = "Boooooooo".freeze
p4 = ->(){ s2.upcase }
Ractor.make_shareable(p4)
# OK

なお、この辺の面倒なのを避けるために Ruby 3.0 には凄く便利なマジックコメントが追加されているみたいです

# shareable_constant_value: literal

TABLE = {a: 'ko1', b: 'ko2', c: 'ko3'}
#=> Same as: TABLE = Ractor.make_shareable( {a: 'ko1', b: 'ko2', c: 'ko3'} )

(セッションの中でもこういうマジックコメントほしい!と tagomoris さんが言ってましたが既にあったようです。ブログでもフォローされていました)

Ractorを使ってどのようにWebアプリケーションのパフォーマンスを向上させるか、4コアなら4倍になるのか、 tagomoris さんはRactorをワーカーとして使うアプリケーションサーバのright_speed を作りました。

私も tagomoris さんの作ったデモで実験してみました。

Rackサーバで起動してみると以下のエラーが発生しました (Bug #18024)。また、 RailsとSinatraを起動してみたところエラーもたくさん発生しました。

# Rackサーバーを4つのworkerで起動する
> right_speed -c config.ru -p 8080 --workers 4
# wrkでベンチマークテストする
> wrk git:(master) ./wrk  -t12 -c100 -d30s http://127.0.0.1:8080/
Running 30s test @ http://127.0.0.1:8080/
  12 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     8.67ms    1.69ms  13.77ms   71.14%
    Req/Sec   328.83    105.85   484.00     66.67%
  797 requests in 30.04s, 51.37KB read
  Socket errors: connect 0, read 796, write 0, timeout 0
Requests/sec:     26.53
Transfer/sec:      1.71KB
# Rackサーバーでエラーが発生した

7fff90200000-7fff90400000 rw- /usr/lib/dyld
7fff90400000-7fffc0000000 r-- /usr/lib/dyld
7fffc0000000-7fffffe00000 r-- /usr/lib/dyld
7fffffe00000-7fffffe01000 r-- /usr/lib/dyld
7ffffff3f000-7ffffff40000 r-x /usr/lib/dyld
[IMPORTANT]
Don't forget to include the Crash Report log file under
DiagnosticReports directory in bug reports.

[1]    27965 abort      right_speed -c config.ru -p 8080 --workers 4
# 同じようにSinatraでもエラーが発生します
[2021-10-05 22:17:05 +0900] ERROR Unexpected error: can not access instance variables of classes/modules from non-main Ractors

確かに上記の説明と同じように Rack/Rails/Sinatraの中に unshareableが多すぎて問題が発生しました。 unshareableオブジェクトはRactor間で共有できないため、オブジェクトをshareableにマークしたり、オブジェクトの中にもデフォルトインスタンスや frozenなどもdeepに指定したりしなければなりません。

Ractorはまだまだ新しいものですし、既存のプロダクトに導入するには対応しなければならないことが多くありそうに思いました。しかし、Ractorで動くアプリケーションの未来は面白いと感じますし、対応が大変だからこそ Contributionチャンスになります。自分も出来る限り、この未来に力を入れたいと思います。

Ruby開発の実情を聞いて背筋がピンとした話

こんにちは。プロダクト開発部 webtestチームに所属している中村(真)@s_nakamuraです。今回RubyKaigi Takeout 2021に参加しました。オンライン開催ということで雰囲気はどうなるのか楽しみでしたが、実際想像していた以上にオンラインでも以前参加したRubyKaigiと同じような熱気を感じることが出来ました。
さて私は今回一番印象に残った「How to develop the Standard Libraries of Ruby?」について紹介したいと思います。 このセッションではRubyの開発がどのような観点を持って進めているのか話されていました。

最初にRuby3.0についてです。RubyはStandard LibrariesとDefault Gemsで構成されていて、必ず含まれていなくても良いものはBundled Gemsとされています。
このような構成にすることでセキュリティ対応の時にアップデートが必要な箇所だけアップデートすれば良いというのは、理にかなっていると思いました。各機能が適切に分割されて作られていれば、問題があった箇所だけ入れ替えることで確認すべき範囲を絞り込むことが出来ます。使う側としては確認する作業に変わりはないですが。

次に3.1についての話もありました。それによるとRuby3.1からdefault gemに含まれていたライブラリを幾つかRubyのリポジトリから外した物がありました。その一方で外せなかったものもあったというのが興味深かったです。例えばEnglishというgemは外したかったがrubocopの方で推奨されるなど影響度が広いためdefault gemsから外せなかったとの事でした。何をdefault gemsとして入れるか判断するのに現在の状況や他のgemの挙動/世の中への影響度も考慮に入れて判断しているというのが、言語開発という世の中に大きな影響を与えているプロジェクトの苦労するポイントなのかと思いました。

そして一番これは大変だと思ったのがRuby開発者それぞれが開発したコードをマージしていく作業についてです。ある程度までは自動チェック出来るそうですが、自動でチェック出来ないところは「手動による心温まる手作業」との事です。
普段業務でたまにconflictが発生することがありますが、それを解消するのも割と神経を使う作業ですし骨が折れるときもあります。それが開発言語の開発で発生した場合に手作業でマージする作業が如何に神経を使う繊細な作業か・・・・。開発人数が多くなったり、規模が大きくなるとそういう部分の苦労もある、今Rubyが使えているのは日々言語開発者の方々の繊細で緻密な作業の結果なのだと再認識し背筋がピンとのびました。

その他

あとセッションの内容とは直接関係ないのですが、gitではリポジトリが違ってもcherry-pickが出来るというのが勉強不足で知りませんでした。どんな感じで出来るのか、試しに自分のプライベートで使っているリポジトリで試してみました。試してみたことはまずリポジトリAでhoge.txtというファイルを追加しcommit & pushします。次に同じ修正をリポジトリBに入れるというのを試します。

$ git add hoge.txt
$ git commit -m'hoge.txtを新規に作成'
$ git push origin HEAD
$ git log
commit f863xxxxxxxxxxxxxxxxxxxxxxx (HEAD -> master, origin/master, origin/HEAD)
Author: nakaearth <shinichiro.nakamura@classi.jp>
Date:   Wed Jul 10 15:29:29 2019 +0900
次にリポジトリBで先ほどリポジトリAでした修正をcherry pickする。
最初にリポジトリBに移動する
$ cd repo_b
git remote add でリポジトリAを追加する
$ git remote add add_hoge https:://github.com/nakaearth/repo_a
add_hogeをfetchしcherry-pick
$ git fetch add_hoge
$ git cherry-pick add_hoge

cherry-pickした後に実際リポジトリAで行なった作業がリポジトリBにも反映されていることが確認できました。今回は簡単に1ファイルだけでしたが、これが複数のファイルで更にコンフリクトが発生した場合、これもまた繊細な作業になると思いました。

以上が「How to develop the Standard Libraries of Ruby?」についての私のレポートになります

RubyにおけるDSLの短所を克服するための静的解析支援

新卒入社3年目の@willsmileです。アプリチームでサーバサイドの開発・運用を担当しています。
会社からもらったスポンサーチケットで、今年のRubyKaigiにも参加できて、3年前初めて参加する時の印象と変わらず、セッション内容の多様性に富んでいると感じています。それに参加することを通じて気づいたことを言語化し、他の人に紹介する経験は、自身の技術者のロールモデルの形成と更新にとても役に立つと自覚しました。このような経験学習において自身のモチベーションを高めるために、今回は技術ブログの執筆に担当させてもらいました。

紹介したい発表は、@paracycleさんのDemystifying DSLs for better analysis and understandingです。以下でこの発表の内容を自分の言葉で説明してみます。

  • DSL 1 の特徴
    • 長所:複数の場所で繰り返されるボイラープレートコードを無しにできること(No boilerplate)と、シンプルな表現でAPIを定義できること(Natural API)
    • 短所:Static Analysisが難しくなり、Code Readabilityが低下する恐れがある
  • 問題定義
    • Rubyで構築されたDSLを、RBI・RBSのような静的型解析にも対応できれば、上記の短所を乗り越えられるのではないか
  • 解決方法
    • DSLにより動的定義されたメソッドに対応して、RBIを自動生成するライブラリーtapiocaを開発した 2

手元で簡単な Rails app を作成し(要件:UserがArticleを作成・編集・一覧・削除でき、1件のArticleに複数個のTagを付けることが可能)、 tapiocaのREADME.mdを見ながら、手元で各モデルのRBIを作成してみました。モデルの定義と生成されたRBIのファイルは以下の具体例で示しています。 3

# article.rb

class Article < ApplicationRecord
  belongs_to :user
  has_many :article_tags
  has_many :tags, through: :article_tags, dependent: :destroy

  enum status: {archived: 0, wip: 1, published: 2}, _prefix: true
end
> bundle exec tapioca init
> bundle exec tapioca dsl Article
# article.rbi

# DO NOT EDIT MANUALLY
# This is an autogenerated file for dynamic methods in `Article`.
# Please instead update this file by running `bin/tapioca dsl Article`.

# typed: true

class Article
  include GeneratedAssociationMethods
  include GeneratedAttributeMethods
  include EnumMethodsModule
  extend GeneratedRelationMethods

  sig { returns(T::Hash[T.any(String, Symbol), Integer]) }
  def self.statuses; end

  module EnumMethodsModule
    sig { void }
    def status_archived!; end

    sig { returns(T::Boolean) }
    def status_archived?; end
    #...
    #量が多いため、一部コードを略する
  end

  module GeneratedAssociationMethods
    sig { returns(::ActiveRecord::Associations::CollectionProxy[::Tag]) }
    def tags; end

    sig { params(value: T::Enumerable[::Tag]).void }
    def tags=(value); end

    sig { returns(T.nilable(::User)) }
    def user; end

    sig { params(value: T.nilable(::User)).void }
    def user=(value); end
    #...
    #量が多いため、一部コードを略する
  end

  module GeneratedAttributeMethods
    sig { returns(T.untyped) }
    def status; end

    sig { params(value: T.untyped).returns(T.untyped) }
    def status=(value); end

    sig { returns(T::Boolean) }
    def status?; end

    sig { returns(T::Boolean) }
    def status_changed?; end

    sig { returns(T.nilable(T.untyped)) }
    def status_was; end
    #...
    #量が多いため、一部コードを略する
  end

  module GeneratedRelationMethods
    sig { params(args: T.untyped, blk: T.untyped).returns(T.untyped) }
    def not_status_published(*args, &blk); end

    sig { params(args: T.untyped, blk: T.untyped).returns(T.untyped) }
    def status_published(*args, &blk); end
    #...
    #量が多いため、一部コードを略する
  end
end

生成されたRBIファイルを眺めてみて、以下のことを気づきました。

  • Railsの仕組みにより、DSLとして自動生成されたメソッドには以下のような分類がある。
    1. GeneratedAssociationMethods:アソシエーション(ActiveRecord::Associations)により定義されたされたインスタンスメソッド
    2. GeneratedRelationMethods:クエリインターフェイス(ActiveRecord::Relation)により定義されたクラスメソッド
    3. EnumMethods:Enum(ActiveRecord::Enum)の定義により定義されたインスタンスメソッド
    4. GeneratedAttributeMethods:属性(ActiveModel::Attributes)により定義されたされたインスタンスメソッド
  • GeneratedAttributeMethodsで定義されたstatus_changed?status_wasなどActiveModel::Dirtyにより定義されたメソッドは初めて知った
  • specific_instance_of_article.tagsの戻り値のタイプがActiveRecord::Associations::CollectionProxyであることに“なるほど”と思った

今回の試みを全体的に振り返ってみると、業務の中でtapiocaを実際に使う機会が少ないかもしれないが、Railsで定義された便利なメソッドを網羅的に知るきっかけになったと思います。冒頭でも述べたように、RubyKaigiではいろいろな“面白い”発表があります。その面白さは、人によって捉え方が違います。人(発表者)がどのような問題定義・解決方法を考えているのかを考えてみること、自分が少し試して気づいたことを話してみることは良い学び方かなと考えて、お勧めします。

参考文献

Fowler, M. (2010). Domain-Specific Languages. Pearson Education, p28.

Ruby3.1 から irb が進化するみたいなのでさわってみた

今年Classiにエンジニアとして新卒入社しました北村です。
今回私もRubyKaigi Takeout 2021 に参加し、初めて RubyKaigi を体験しました。運営の方、発表者の方、視聴されている方、全ての方から Ruby への熱い思いが溢れ出るこのイベントでまさに「Ruby 漬け」な三日間を過ごすことができたのは、とても貴重な経験になりました。

そんな RubyKaigi Takeout 2021への参加レポートとして、私からは @aycabta さんによるセッション「Graphical Terminal User Interface of Ruby 3.1」で発表された irb の新機能について、その内容と実際に使ってみた時のログを書きたいと思います。

セッション要点

Ruby3.1 から irb において以下の二点が新機能として追加されると発表されました。

  • 自動補完を実現する dialog window 機能
  • dialog window 内での RDoc 参照機能

dialog window 機能についてはもともと @aycabta さんが reline という gem の中でこれまで実装されてきた機能で、それが Ruby3.1 の irb で採用されるということでした。
RDoc の dialog window 内での参照機能については、元々 RDoc の参照機能自体がすでにリリースされた irb で実現されていた機能ではあったものの、その使用体験に問題意識を感じた@aycabta さんが dialog window 内で RDoc を参照できるように実装されたということでした。

やってみた

今回発表された新機能は、 Ruby3.1 が出るのを待たずしても prerelease 版の irb をインストールすればいますぐ使えるということだったので試しに触ってみました。

準備

(今回は Ruby 3.0.2 で検証しました。)

  • gem install irb --pre を実行
    • reline と irb の prerelease 版がインストールされました
  • irb -v でバージョンを確認
  • f:id:ClassiJP:20211011181204p:plain:w500

確認

まずは dialog window の表示してみる

irb を起動してみてどういう感じに dialog window が表示されるのかを見てみました。
セッション内の demo では String クラスが例として使用されていたので、ここでは Array クラスを見てみようと思います。

  • irb を起動しA とタイプ

    • f:id:ClassiJP:20211011181124p:plain:w500
  • tab キーを押して dialog window 内の Array を選択する

    • f:id:ClassiJP:20211011181039p:plain:w500

ちゃんと dialog window が出て自動補完が効いていること、そして RDoc も dialog window 内に出ていることが確認できました。(Alt+d を押せば対象のドキュメントを全て表示することもできます)

処理中に挟んだ binding.irb の場合どうなるの?

ここまでやってみて、ふと「binding.irb などを使って処理の途中で irb を実行した場合についても、処理に関わるクラスやそのメソッド、変数などについて自動補完機能を利用できるのでは?」ということを感じたので、それについても試してみました。

  • サンプルコード
class Book
  def initialize(title)
    @title = title
  end  

  def title
    @title
  end
end

book = Book.new("title")
binding.irb
  • コードを実行し止まったところでメソッドや変数の自動補完が出るか確認
    • bと打った時点で book が候補の中に表示される
      • f:id:ClassiJP:20211011180827p:plain:w500
    • tabキー押下で book まで打ち込める。そこから、. を打つと title と表示される。再び tabキー押下で title まで打ち込める
      • f:id:ClassiJP:20211011180541p:plain:w500
      • f:id:ClassiJP:20211011180501p:plain:w500

自動補完機能はこのような使用用途でもきちんと使うことができそうです。
これなら irb の使用中にクラス名やメソッド名がわからずにいちいちコードを見にいって確認する、などの手間が省けそうで開発者にとっては嬉しい限りですね。

そしてこの検証をした後に気づいたのですが、実はこの内容、 Rails を背景としたお話ではありましたがセッション中に @aycabta さんがきちんと言及されていました。

Now you can use the rails console without worrying about adding many classes and methods to your business code.
(aycabta/RubyKaigi2021_daihon.md より)

rails console は内部で irb を使用しているということで、rails での開発体験についてもかなり向上が見込めそうです。

実際Classiでも「たくさんのクラスやメソッドが定義された rails コード」が多数存在します。もし rails console 上でクラス名やメソッド名が自動補完されるようになれば、 debug の際などに非常に嬉しいはずです。今後の日常の開発でもどんどん使っていこうと思いました。(なお、使用用途によっては debug gem を使用していくのが良い場合もありそうです)

以上、「Graphical Terminal User Interface of Ruby 3.1」セッションに関するレポートでした。

Rails app に RBS 導入試してみた!

開発本部所属エンジニアの匿名希望です。

今回見たセッションでは @pocke さんの The newsletter of RBS updates がよかったです。

※セッションの内容については公開されてる動画を見るのが早いと思うので割愛します

Ruby の型関連、気になってはいたのでたまにブログ記事とか見てへ〜みたいになりつつも導入までは至ってなかったんですが、このセッションで rbs collection っていうのを使うと始めやすいっぽい!と知れたのでせっかくだしちょっと触ってみよ〜ってなりました。

早速業務コードで……と思ったのですが、まずは簡単にお試し。

以下で試したサンプルはこちら:

rails scaffold で簡単なアプリ作って→ライブラリ等の設定をして→以下の型定義を作って、

# 引数を取らずに string を返すよ
def id_string: () -> String

型定義に合わないように実装ミスをして、

def id_string
  # 型定義では String を返すことになっているが Integer を返す
  id
end

型検査をしてみると、

> bundle exec steep check

app/models/task.rb:2:6: [error] Cannot allow method body have type `::Integer` because declared as type `::String`
│   ::Integer <: ::String
│     ::Numeric <: ::String
│       ::Object <: ::String
│         ::BasicObject <: ::String
│
│ Diagnostic ID: Ruby::MethodBodyTypeMismatch
│
└   def id_string
        ~~~~~~~~~

ちゃんと怒られた!うれしい!

やってみた感想は、rbs collection 最高〜!こんな導入簡単でいいの?です。 今回試す前に rbs で検索して出てきた他の方が書いた過去のブログとかも見て予習していたのですが、git submodule したり長いコマンドとか打ち込んでてめっちょ大変そう〜って思ってたので、シュッと終わって正直拍子抜けでした。

ってわけで業務コードにも導入!……と思ったのですが、年代物のコードだとあれこれ出てしまってすんなりはいかなそうでした🙃 とまれ、簡単なアプリで試して勘所を軽く掴んだ気がするので引き続きやっていこうと思います〜。

終わりに

個人的にオンラインの Kaigi に参加したのは初めてだったのですが、セッションごとのチャットで講演者に質問して盛り上がったり、社内の Slack で実況中継したりオンラインならではの楽しみ方ができてとてもよかったです。

素晴らしい Kaigi を開催してくれた運営チームの皆さんに感謝です!


  1. DSLとは、Domain Specific Languageの略語で、特定のドメインでのタスクのために設計・実装されたプログラミング言語です。Martin Fowler氏はその実装方式によりDSLをExternal DSL、Internal DSL、Language Workbenchという3つのタイプに分類しました(Fowler, 2010)。今回紹介する発表でのDSLは、Rubyのメタプログラミングの特徴を生かして構築されたinternal DSLのことを指しています。

  2. 実現する原理・方法は、発表ビデオの16分~20分の間に説明されたので、興味がある方は詳細をご覧ください。

  3. サンプルコードは、ruby 2.7.4、rails 6.1.4.1、tapioca 0.4.27により作成しました。

QAチームが取り組む「品質の見える化」への挑戦

こんにちは、QAチームの牛木です。

QAチームでは今期「品質の見える化」に挑戦しています。 この記事では、QAチームが取り組む「品質の見える化」の歩みをお話します。

なぜ「品質の見える化」をやるのか

昨今のソフトウェア開発手法の主流が「ウォーターフォール開発」から「アジャイル開発」(アジャイル開発の中でもスクラム開発)へ変化しつつあります。

アジャイル開発においてもテスト業務は依然として必要ですが、包括的なドキュメントではなく、動くソフトウェアや対話の中でのテスト設計、開発サイクル全体を見通した素早いテスト実施、開発から運用まで含めたプロセスの中での継続的なフィードバックの獲得も求められます。 こういった体制を「DevOps」とも捉えていますが、QAが継続的なテスト、継続的なフィードバックを提供する足掛かりとして「品質の見える化」に取り組んでいます。

「品質の見える化」とは何か

「見える化」とは、”「可視化」された対象を「モニタリング(監視)」し、「課題を抽出・分析」、フィードバックに基く「改善活動を行う」ことである” とQAチームでは考えます。 「見える化」という言葉は、トヨタ自動車による業務改善の観点において初めて登場した言葉です。

可視化の対象となる「品質」は、現在以下のデータに絞っています。

  • QAチームが検出した不具合データ
  • QAチームが担当したテスト業務データ

ソフトウェアにおける「品質」の定義は、企業によって多種多様であり、品質の対象もさまざまです。

品質の定義から、ISO/IEC9126の品質特製(プロセス品質、内部品質、外部品質、利用時の品質)を思い浮かべる人もいれば、狩野モデルの品質要素(魅力品質、一元的品質、当たり前品質)を思い浮かべる人もいるのではないのでしょうか。 この全ての品質をスコープとすると膨大なデータと、そのデータを蓄積するための運用整備が必要となります。そのため、まずはミニマムスコープとしてQAチームの管理下で蓄積・運用されているデータを対象としています。

 今何をやっているのか

「品質の見える化」のプロセスとして、以下ステップを目標に活動を進めています。

  1. 品質データの”蓄積”
  2. 品質データの”可視化”
  3. 品質”課題抽出・分析”
  4. 品質”フィードバック”
  5. 1~4のサイクルの”運用”
  6. 他チームへの横展開

f:id:cku0301:20210913164859p:plain
社内に展開した「品質の見える化」のサイクル

上記ステップのうち、1”蓄積”と2”可視化”に現在取り組んでいます。 その活動の詳細についてお話しします。

 1. 品質データの蓄積

前述した品質データは、タスク管理ツール「Asana」を使い、QAチームがチケット管理をしています。 各データには以下のようなラベリングをしています。

  • 不具合データ:不具合分類、不具合レベル、不具合混入工程、不具合見逃し理由、不具合検出手法など
  • テスト業務データ:案件名、開発チーム、テスト工程、テスト項目数、実績工数など
    f:id:cku0301:20210913165114p:plain
    QAチームが管理するAsana

各チケット(データ)はQAチームが各プロダクトチーム統括でClose作業をしており、ラベルの未入力チェックや、不具合のステータスチェック(例えば、案件がCloseしているのにも関わらず、案件に紐づく不具合がOpen中である場合には確認を入れる等)のチェック運用を行っています。

 2. 品質データの可視化

BIツール「Tableau」を使い、「Asana」に蓄積された品質データのダッシュボードを作成し、社内に展開しています。 社内の役割によって気になる観点が異なるため、「全社向け」と「プロダクトチーム向け」に分けてダッシュボードを作成しています。

「全社向け」では、Classiサービスの品質状態が良いのか悪いのかを端的に伝えるために、Classiサービス全体の平均不具合件数や不具合密度の推移、不具合の改修状況などを表示しています。

f:id:cku0301:20210913165238p:plainf:id:cku0301:20210913165324p:plain
全社向けのダッシュボード一部抜粋

「プロダクトチーム向け」には、機能毎に不具合データのラベリング別の割合や、推移を載せています。各チームが、不具合の傾向から原因や課題を拾いやすくすることを目的としています。

f:id:cku0301:20210913165646p:plainf:id:cku0301:20210913165655p:plain
プロダクトチーム向けのダッシュボード一部抜粋

現在取り組んでいるステップとして「1.品質データの蓄積」と「2.品質データの可視化」をお伝えしました。

可視化のステップは次に見据えている”品質課題抽出・分析”のための活動でしたが、可視化をして最初に見えてきた課題は蓄積ステップの運用課題でした。 例えば、ステータスの中で新規起票状態のチケットが多いことが分かったのですが、これは実際に新規起票チケットが多いのではなく、ステータス更新が適切に行われていないことが原因でした。 他にも不具合レベルがあるレベルに偏っておりレベルの細分化・再定義が必要であったり、ある項目の未入力が多くフローがうまく機能がされていないことが判明したりと、可視化をすることで前ステップの改善にも繋げることができました。

蓄積されたデータが正確でなければ品質課題の抽出もできません。蓄積と可視化を反復しながら品質データが適切に蓄積されることが見える化における初めの一歩になると思います。

 今後何をやるのか

今後のステップとして、蓄積/可視化の管理・運用を推進しつつ、「3.品質課題抽出・分析」と「4.品質フィードバック」の取り組みを開始しています。

品質データの「蓄積」「可視化」では、品質データの対象をQA管理下のデータに絞り込んだこともあり、QAチーム主体で活動を進めることができました。 しかし、品質「課題抽出・分析」「フィードバック」では、プロダクトチームを巻き込んだ活動でないと価値を出すことは難しいと考えています。

というのも、Classiのプロダクトチームは複数存在しており、チーム毎に開発スタイル、リリースサイクル、人数、担当機能などが異なります。チームによってデータ結果の背景・原因は異なりますし、重視している観点も異なります。

「可視化」したところで...

  • 可視化したデータをそもそも見てもらえない
  • データを見ても、「それで?」となる
  • データ結果が実際の業務と紐付けられない
  • なぜこのような結果になっているのかの根本的な背景や原因が分からないから活用できない

などなど...

Classiサービス全体としてデータの結果を表示できても、チームに寄り添った分析とフィードバックを行えなければ、「見える化」できているとは言えません。

そこで現在は、プロダクトチームに参画し、品質データを生かしたフィードバックをどう推進していくのが有効か?の情報収集をしている段階です。他チームへの展開も視野に入れて、まずは特定チームで「品質の見える化」のサイクルを確立することを目指して活動をしています。

 おわりに

「QA」と聞くと「テスト業務」が連想されると思いますが、QAはQuality Assuranceであり、「品質保証」業務全般を差します。最近はQAの担当領域も広がってきましたが、品質目標やQAが担う領域は、企業によってさまざまであると感じています。わたしも勉強中の身ですが、Classiにおける「品質保証とは?」をつきつめられるように精進していきます。

Classi QAの品質向上への道

こんにちは、Classi QAチームの竹林です。 Classi QAチームでは、単にテストをするだけのチームではなく品質向上をミッションとするチームとして、品質向上に向けた施策を実施してきました。

この記事は、Classi QAチームの品質向上に向けた歩みの共有になりますので、QAの進め方について検討している方の参考になれば嬉しいです。

「品質の見える化」で始める

Classi QAの品質向上に向けた取り組みは「品質の見える化」から始めています。 品質向上のための課題抽出や施策提案を、現状に最適な優先度や内容で進めるために、まずは現状を把握する必要性があるから、との考えからです。 また現状把握だけの利用でなく、今後の品質向上PDCAサイクルなど、QAの中長期的な取り組みのベースにすることを想定しています。

「品質の見える化」の実装は、バグなどの不具合発生時に「どんな事象が?」「どこで混入した?」「なぜ混入した?」などの情報を残していく方式で進めました。 この方式は、開発者の協力がないと成り立たないのですが、Classiの開発メンバーは品質意識が高くとても協力してくれるので、スムーズに進めることができました。(改めてこの場で感謝します。)

f:id:classi_qa:20210913141816p:plain

     

「品質データの活用(第一弾)」を始める

「品質の見える化」で見えてきた品質データは、「テスト結果レポート」を作るために活用しています。 「テスト結果レポート」は、テストから得られた情報を基にしてリリースリスクを把握できるため、「リリース品質の向上」に繋げることが期待できます。   

  • 【リリースリスクを把握するための、テスト結果レポートの項目(例)】
    • テストの進捗状況
    • 不具合の発生・収束状況
    • 不具合の内訳(バグ?デグレード?仕様?など)
    • 不具合の対応状況・残存状況など
    • リリース見解(総合的なリスク判断)

f:id:classi_qa:20210913141902p:plain

     

「開発とテストの専業化」をトライアル

「開発作業と検証作業を専業化するかどうか」は意見の別れる事案ですが、Classi開発では「専業化」をトライアルでスタートしています。 開発スピードが企業戦略的にも重要な要素になっている現在では、専任メンバーがテストを専業することで得られる「開発メンバーの負担軽減」は大きなメリットです。

一方で、専業化によるデメリットとして「開発者のテスト意識やテストスキルが低下する懸念」などがあり、今後はメリットとデメリットのバランスを観察しながら、随時ブラッシュアップしていく予定です。

f:id:classi_qa:20210913141956p:plain

     

「QA効果の最大化」を始める

「上流でのバグ検出」を目的として導入されることが多い「QAの上流参加(仕様レビューなど)」ですが、Classi QAでも始めています。 「上流でのバグ検出」を目的とする理由は、「品質のV字モデル」で提唱されるように開発後期(下流工程)で検出したバグは手戻りが多いため、できるだけ開発前期(上流工程)で検出したいとの考えからです。

f:id:classi_qa:20210913142009p:plain

     

「テストの自動化」を始める

開発スピードがUPしたりリリース頻度が高まることで懸念されるのがデグレード発生リスクですが、その対策として利用されているのがテストの自動化で、Classi QAでも導入を開始しています。 かなり以前(10年以上前)からある自動化施策ですが、ここ数年は特に盛り上がりを感じており、多くの開発現場でデグレードに苦労していることが分かります。

f:id:classi_qa:20210913142028p:plain

     

「品質データの活用(第二弾)」を始める

品質データの活用(第一弾)では『リリース品質の向上』に活用しましたが、(第二弾)では課題や改善のヒントなどの見えた情報を開発工程にフィードバックして、『開発品質の向上』に活用します。

この(第二弾)は非常に難しい施策で、本施策の実現に必須となるPDCAサイクルを「継続運用できている」という事例を私はあまり聞いたことがありませんが、Classi QAでは挑戦を始めています。

本施策については、当開発者ブログの別記事【QAチームが取り組む「品質の見える化」への挑戦】に投稿を予定していますので、併せてお読みいただけると嬉しいです。

f:id:classi_qa:20210913142048p:plain tech.classi.jp    

おわりに

Classi QAチームの品質向上施策をフェーズ分けすると、現在は後期に入ったあたりです。

f:id:classi_qa:20210913142109p:plain

     

ただ、後期フェーズに入ったとはいえ、やることが少なくなったわけではありません。

今後更にスピードアップが求められるソフトウェア開発や、日々進化する開発技術に対応するために、新しい施策の提案や実施済みの施策のブラッシュアップなど、タスクは尽きません。

今後もClassi QAチームの品質向上への道は続きます。

Angular+Storybookで画像回帰テストを小さくはじめる

Classiのフロントエンドエキスパートチームlacolacoです。最近AngularのプロジェクトでStorybookをベースにしたUIコンポーネントの画像回帰テストをはじめたので、この記事ではそのなかで学んだことを共有します。

画像回帰テスト

画像回帰テスト(visual regression testing)は、UIの見た目のバグを防ぐためのテストです。見た目はユニットテストのようにコードでテストするのが難しいため、画像回帰テストではその名の通りテストに画像を使用します。実際に描画されたUIを画像としてキャプチャして、ソースコードの変更前後での画像の差分から「見た目が変わっていないか」をテストできます。

最近では画像回帰テストをサポートするツールやSaaSなどさまざま出てきていますが、画像回帰テストをはじめるにあたっての問いはシンプルに次の2つだけです。

  1. どのように画像をキャプチャするか
  2. どのように画像を比較するか

どのように画像をキャプチャするか

最初の問いは、そもそもどのようにUIを画像化するかということですが、今回はStorybookと、そのプラグインであるreg-viz/storycapを選択しました。

Classiでは社内で利用するAngularのUIコンポーネントをライブラリとして開発しています。そのライブラリにはもともとドキュメンテーションを目的としてStorybookを導入していました。すでに見た目の確認のためのStoryを定義しているので、これをそのまま画像にできれば一石二鳥です。

別の選択肢として、Cypressをベースにすることも検討しました。Cypressには画像回帰テストをまるごとサポートするプラグインがあったのですが、Cypressを新規に導入する手間や、すでにあるStorybook資産を再利用したいことなどを考えた結果、最終的にStorycapを選びました。

どのように画像を比較するか

次の問いが、キャプチャした画像をどのように比較して回帰テストするかということです。極端にいえば2枚の画像を1ピクセルずつ比較して差異を探せばよさそうですが、実際はそこまで単純ではありません。ブラウザのスクリーンショットという手段で画像化する過程で、わずかな誤差が生じる可能性があります。差分があることだけわかっても「どの部分がどう変わったか」を人の目で見つけるのは大変なので、テスト結果の視覚的な支援も重要です。

というような観点で検討した結果、今回はreg-viz/reg-cliを使用しました。reg-cliは機能面で要求を満たしていましたし、Storycapと同じ開発元ということで親和性という点でも安心して使えました。

f:id:lacolaco:20210909104917p:plain
差分が出たときのレポートの様子。フォントサイズが変わって文字がずれていることが視覚的にわかる

小さくはじめるための工夫

今回はすでにあるプロジェクトへ後から画像回帰テストを導入し、有効性を検証することが第一の目的であったため、なるべく最小限の変化ではじめられることを重視しました。そのためにいくつかの工夫をしています。

対象を絞る

最初からすべてのコンポーネントに対して有効にせず、仕様が比較的安定している限られたコンポーネントだけを対象にしました。対象を絞ること自体はStorycapの skip オプションや exclude オプションなどを使用して簡単に実現できました。

今後対象コンポーネントを広げていく上でも、すべてのStoryを回帰テスト対象にはしないだろうと考えています。対象が増えるごとにキャプチャの時間的コストが開発体験上で問題になることが予想できます。コスパのバランスを考えて適用範囲を広げていく必要がありそうです。

ローカルでスナップショットを更新する

今回の導入では、開発者がUIを変更したらローカルでキャプチャした画像を新たなスナップショットとしてGit pushします。巷の画像回帰テストツールでは、スナップショット画像はGit管理せずクラウドストレージに保存することが多いようです。これは画像回帰テストの実行には時間がかかることが主な理由のようです。画像回帰テストはCI環境だけで実行し、結果をクラウドストレージに保存することでローカルの開発者体験を損なわないようにされています。

確かに大規模に画像回帰テストを導入するとなるとその部分がボトルネックになることは想像できますが、今回は小さくはじめることを目的に簡略化しました。本格化するにあたっては、Storycapやreg-cliと同じ開発元のreg-suitやSaaSのPercyなど、このあたりのツールを検討する見込みです。

ちなみに、ローカルとCIでは環境が違って同じChromeでも描画結果が変わるため、StorycapはDocker上で実行するようにしました。特にフォントレンダリングで差が出ます。最初はどうにかしてやろうと闘いましたが、途中で徒労だと悟ってDockerに切り替えました。これも実際にやってみたらあっという間だったので、はじめからこうしておけばよかったと反省しました。

導入後の学び

まだ小規模な導入なので著しい変化はありませんが、それでも適用対象のソースコードに関しては画像回帰テストがされていることでリファクタリングへの安心感が高まりました。社内で横断的に使われるので、ライブラリのアップデートが意図しない破壊的変更を含まないことを検証する仕組みとして、やはりとても重要だと感じています。

既存のStorybookの運用についても、画像回帰テストしたいパターンのStoryが作られていないことに気づいたり、コンポーネントの仕様上の問題に気づいたりと、新たな視点でコンポーネントを見ることで改善の種が見つかることもありました。

まとめ

この記事の内容自体は特に目新しいものではないと思います。画像回帰テストは普及してきつつありますが、しかし「知っているし導入したいと思ってるができていない」という状態のプロジェクトがまだまだ多いと感じています。思ってたより簡単だったり逆に大変だったり、実際にやってみないとわからないことは多いので、この記事がこれからはじめたいと思ってる人の後押しになれば幸いです。 ここでは語れていないこともたくさんあるので、もっと詳しい話をしながら意見交換していただける方は lacolaco 宛にDMなどいただけると喜びます。 それではまた!

Hardening Drivers Conference 2021でCSIRTの受援力についてパネルディスカッションをしました

f:id:nomizooon:20210902111309j:plain

こんにちは、サイバーセキュリティ推進部の野溝(@nomizooone)です。普段はClassiサービスの脆弱性診断や顧客対応などを担当しています。

先日、Hardening Projectにより開催された/dev/hardening – Hardening Drivers Conference 2021 のセッション「CSIRTの受援力」にて、私を含むClassiサイバーセキュリティ推進部の3名がパネラーとしてお話をさせていただきました。

「Hardening Project」(ハードニングプロジェクト)とはウェブサイトの安全性を追求する技術の啓蒙と人材の育成や、技術の社会的認知の向上による健全なネット社会への進歩に貢献することを目的としたセキュリティ界隈の皆さんにはおなじみのコミュニティです。

インシデント情報公開が登壇のきっかけに

Classiは昨年度、大規模な個人情報漏えい事件をおこしてしまいました。そして、その件に関して、2021/5/11にあらためてお客様向けに精緻な情報公開を行いました。

corp.classi.jp

セキュリティインシデントを起こしてしまった会社の報告というのは、様々な配慮や事情から、一般的にはぼかした表現になりがちです。

そんな中で、インシデントの発生から1年という時間を経て「判明している限りの情報を時系列で精緻に報告を行なった」という点で、Classiの業界への貢献を評価いただいたことがセッション登壇のきっかけになりました。

インシデントの情報公開や、普段からどのように備えておくべきかについて、Classiの他にもセキュリティベンダや保険会社の方も含めて90分ディスカッションしてきました。 アーカイブ動画の公開範囲はイベント(有料)の申込者の方に限られているので、この記事ではお話した内容をピックアップしてお伝えします。

テーマは「CSIRTの受援力」

みなさんは「受援力」(じゅえんりょく)という言葉をご存知でしょうか?

恥ずかしながら、私は今までこの言葉を知りませんでした。簡単にいうと「 "助けて" と言える力」だそうです。(特にセキュリティに限定した言葉というわけではなく、災害のときとかによく使う言葉みたいです)

また、CSIRT(シーサート)というのは、「Computer Security Incident Response Team」の略語で、名前の通り、セキュリティインシデントに関する報告を受け取り、調査などの対応活動を行う組織体のことです。社内のセキュリティ消防団みたいな感じですかね(組織によって位置付けは違うことがあります)

私はサイバーセキュリティ推進部という、セキュリティを専門に扱う部署に所属していますが、会社やサービスのセキュリティを守るためには、専門部隊である部署の中の力だけではなく、エンジニアや営業や法務や広報などなど…いろんな人達に助けてもらう必要があります。

そしてもちろん、社内だけではなく、社外の専門会社や関係機関との連携も会社としての対応をしていくためには欠かせません。

いざというとき、あるいは普段から、どのように周りを巻き込んで助けてもらいながら組織やプロダクトのセキュリティを高めていくか? 言葉にすると些細なことに感じますが、とても重要で深淵なテーマです。

己を知ることがセキュリティの第一歩

そのテーマに対して、インシデントの発生から対応を振り返ってセキュリティの受援力を発揮するためにまず必要なのは「自組織の弱い部分を把握すること」というお話をしました。

Classiでは、セキュリティアセスメントを事前に行い、組織として弱い部分を把握し、外部ベンダと支援のたてつけを合意しておいたことがいざというときのスムーズな対応につながったと分析しています。

セキュリティアセスメントとは、会社の中にどのようなセキュリティリスクが存在するのか調査して洗い出し、それぞれについて影響度を評価して、対応をきめていくことです。

保険の考え方と同じですが、たとえばリスクが発生する可能性は低いが、いざ発生すると損害が大きすぎて自社で対応しきれない、と想定される場合は、外部の専門業者にあらかじめ助けてもらえるように準備をして、いざというときに備えるなどの対応を行います。

自力に限界があることを認め、弱い部分を把握することではじめて、人に助けてもらう範囲を決めることができるってことですね。 そう考えるとアセスメントはとても大事です。

f:id:nomizooon:20210902110315j:plain
時系列と巻き込んだ組織の整理

改めて振り返ると、昨年のセキュリティインシデントのときには、本当にさまざまな人に助けていただきました。ほんの一両日の間にグループ内を含めた社内関係者はもちろん、社外関係者の協力を仰ぐことができたのは、事前の準備と、協力範囲の設計の賜物だと言えると思います。

情報をいつどこまで公開するべきか問題

セキュリティインシデントの中でも、発生した事象が個人情報の情報漏えい事故である場合、その事故を起こしてしまった会社は、適切に情報公開することが求められます。 (2022年の個人情報保護法の改正で義務にもなりますね)

しかし、起こった事故の性質によっては、まだわからないことがあったり配慮して伝えないといけないことがあったりして、ぼかした報告をせざるをえないことが往々にしてあるのではないかと思います。

かくいうClassiでも、インシデント発生直後に行った報告では、事故の詳細を載せることができていませんでした。その時点ではっきりしていないこともありましたし、グループ会社やお客様である学校の先生方への影響などを心配したからです。

f:id:nomizooon:20210902110413j:plain
インシデント情報の公開時の最大リスク

しかし、インシデント終息後このままで良いのか?本当に「お客様のために」なる情報公開とはどのようなものか? ということを考えて、議論を続けました。

約1年間かかりましたが、いったんこのインシデントにおいての結論として、前述の情報公開に踏み切ったという経緯です。

f:id:nomizooon:20210902110809j:plain
インシデント情報公開に関するClassiの結論

基本方針は「お客様本位、公明正大を前提としてお客様に利益を届ける」ことです。 目的は「お客様にこれからのClassiをより安心して使っていただくこと」で、あくまでお客様本位の情報公開が必要である、ということを強調してお伝えしました。

なんだかとても綺麗な話として綴ってしまいましたが、実際は1年の間、さまざまな方との意見交換や調整を続けたClassiのメンバーの泥臭い努力と、周りの理解があって実現したことです。

今回Classiとしてはこのような結論を出しましたが、当然、それぞれの会社の状況やご意見もあるので何でもかんでも透明にして情報公開を行えばいいかというと、そう簡単ではないことも多いと思います。

ただ今後、世の中で起きるセキュリティインシデントの情報公開が、少しでも利用者の利益になる方向に進むことを願っています。

おわりに

今回オンラインでの登壇だったので、時間や場所の制約なくたくさんの方に見ていただけて嬉しかったです。登壇中のチャット欄も盛り上がっていて、リアルイベントよりも参加者の方のワイガヤがダイレクトに伝わってきたのが印象的でした。

セキュリティはあまり正解といえるものがない分野ですが、他の視点を持った立場の方々とのディスカッションを通じて、みんなそれぞれ悩みながら先に進んでいることを知り、勇気をもらうことができました。 また、Classiは本当に色んな人に助けていただいて成り立っていると、あらためて実感する機会にもなりました。

今回のセキュリティインシデントに関しては、お客様向けの発信の他に当開発者ブログでエンジニア観点の発信も行っています。よろしければ併せてご覧いただけると嬉しいです。

tech.classi.jp

tech.classi.jp

最後に、私に貴重な機会をあたえてくださったHardeningProjectの皆様、インシデント対応にご協力いただいたClassiやほかの関係者の皆様に、この場を借りてお礼申し上げます。

本当にありがとうございました!

Airflowの処理の一部をdbtに移行しようとして断念した話

こんにちは、データプラットフォームチームでデータエンジニアをやっている滑川(@tomoyanamekawa)です。

以前紹介したデータ分析基盤であるソクラテスの改善のためにCloud Composer(Airflow)で行っている処理のdbtへの置き換えを検討しましたが、導入を見送りました。 調べてみてdbtに対するわかりみも深まったので、その供養のために検討内容を公開します。 同じように検討している方の参考になれば幸いです。

続きを読む

Data Engineering StudyでClassiのデータ組織の歩みと題して発表しました

f:id:tetsuro-ito:20210810181549p:plain みなさん、こんにちは!データAI部の部長をしている徹郎(id:tetsuro-ito)です。

先日開催されたforkwellさんとprimeNumberさんが主催されているイベント、Data Engineering Study #9「企業規模別に見る、データエンジニア組織の作り方」にて、Classiのデータ組織の歩みについて発表してきました。

Data Engineering Studyはこれまで8回開催されていて、データエンジニアリングの話題を中心にデータ分析に関する話題やデータ基盤に関する話題、それを扱う組織における話題を取り上げたりと、人気の勉強会です。

9回目の勉強会では「企業規模別に見る、データエンジニア組織の作り方」というトピックで、それぞれ従業員数が100人・300人・3000人と企業規模の異なる3社が下記のようなトピックを発表する趣旨として開催されました。

  • 企業の課題と、データ分析の目的
  • データ分析に関する組織構成と、各組織のメンバー構成
  • データエンジニア職の採用をどのように行っているか

Classiはこのうち、100人規模の組織の事例発表ということで招待され、300人規模の事例として弁護士ドットコムさん、3000人規模としてLINEさんが事例講演をされました。

当日の発表資料

当日発表した資料がこちらです。Classiの会社紹介とデータ組織の紹介を行ったのちに、データAI部が取り組んでいるプラクティスを中心にご紹介させていただきました。

データAI部の前身であるAI室が創設されたのが2018年の6月ですが、約3年間の歩みをわりと赤裸々にご紹介させていただいたつもりです。

また、YouTubeにて当日の録画配信も公開されているので、興味がある方はぜひご覧ください

当日いただいた質問

また、イベントではkoibumiというサービスを通して、視聴者のみなさんからのご質問もいただきました。いただいた質問と回答は下記のとおりです

  • Q:データエンジニアはGCPをよく使うことから、管理者的な役割を期待されることも多く、困っているのですが、そういったことはありますか?どう対応されていますか?

    • A : 発表の中でもあった通り、データエンジニアがadminとしての役割を担っていることからも、そういったことはあります。理想的には専門組織を作り、そうしたことを担ってもらうのが望ましいですが、現状では主管部署が責任を持って管理し、他の専門的に見ている部署と連携してるのが現状です。
  • Q : 部長さんということですが、部下の方のキャリアアップなどのプランは練られていますか?

    • A : ちょうど今年度、評価の基準をアップデートしているところです。その評価基準にグレードがセットになっていて、そのグレードをあげることでできることも増えたり影響力が上がるような設計にしています。そういう観点では、プランは練っています。
  • Q : 採用はフルリモート可ですか?

    • A : Classiではコロナ禍以降、基本的にフルリモートで業務を行なっています。例えば、コロナ禍以降に入社したメンバーの中には、一度もまだオフィスに来たことがない方もいて、会社全体がフルリモートワークに対応しているといえます。今後については、議論しながらClassiにとって一番良い方法を検討していきますが、リモートワークがメインになることを軸にオフィスをコンパクトにしたため、「再び毎日出社」にはしないと考えています。
  • Q : 一人のデータエンジニア がどの程度の業務を担当されているのでしょうか?また人員は足りていますか?

    • A : 発表の中でデータ基盤の構成図をお見せしましたが、メンバーの中でも得意な技術領域にグラデーションがあります。エンジニアリングに強いメンバーはよりソフトウェアエンジニアリングに近いデータエンジニアリングに重心を置き、ビジネス活用に近いスタンスのメンバーはDWHやDMの部分に重心を置いています。最後に募集をさせていただいた通り、人員は足りていません(笑)

おわりに

以上のように、オンラインでのイベントでもあったにもかかわらず、多くの方に参加をいただき、質問も色々していただけました。 ClassiのデータAI部の取り組みについて知っていただけたり、自分たちの取り組んでいることを聞いていただいて、新しい発見や気づきにつながれば幸いです。

最後に、ClassiのデータAI部ではデータ関連職を3職種募集しています。 もし、ご興味を持っていただいたら、こちらの募集要項を読んで、ぜひご応募してください!お待ちしています!

© 2020 Classi Corp.