Classi開発者ブログ

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

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職種募集しています。 もし、ご興味を持っていただいたら、こちらの募集要項を読んで、ぜひご応募してください!お待ちしています!

Flask 2.0.xのアップデート項目紹介

こんにちは、データAI部でPythonエンジニアをしている平田(@JesseTetsuya)です。普段は、PoCとデータをもってくる、というところ以外全部やる、というスタンスで開発業務を行っています。

日頃は、Flask1.1.4を利用していましたが、2021年5月11日にFlask2.0へのメジャーバージョンアップがありました。

メジャーバージョンアップということもあり、多くのアップデート項目がありました。そこで、特に日頃の業務に関わりそうなアップデートについて当記事にまとめていこうと思います。

Flaskとは?

Flaskは、PythonistaのArmin Ronachertによって2010年に初回リリースされました。いまでは、 Armin Ronacherを筆頭にPalletプロジェクトと言う名前でFlaskを含む、Flaskに関連する各ライブラリのメンテナンスがPalletプロジェクトメンバーによって行われています。

Flaskは、WSGI準拠のPythonマイクロWebフレームワークです。Djangoのようなフルスタックフレームワークとは違い、決まったディレクトリ構成もなければデフォルトでのデータベース機能やアドミン画面もありません。

GitHubのスター数も多く、JetBrain社の「Python Developers Survey 2020 Results」調査結果で人気ナンバーワンになっているそうです。

f:id:JesseTetsuya:20210707105027p:plain

軽量のフレームワークであるため、手軽にWEB アプリケーション開発でもAPI開発でも利用しやすくなっています。WEBアプリケーション開発未経験者やPython初学者にとってとっつきやすいフレームワークだと思います。

データサイエンスの界隈では機械学習モデルを構築し、その結果を返すREST APIをFlaskで実装するというユースケースがよく聞かれます。

データサイエンスを担う人が手軽にREST APIを作るニーズが高まりをみせ、最近では、Fast APIというASGI準拠の非同期処理を得意とするStarletteをラッピングしたフレームワークの人気も台頭してきました。

Fast APIにあってFlaskにまだ実装されていない機能を実装したのが今回のFlask 2.0へのversion upに垣間みることができます。

では、Flask 2.0の各アップデート項目をみていきます。

Flask 2.0.xのアップデート項目

ざっと、日頃の私の業務で目にとまった項目をピックアップしました。その他のアップデートはこちらのリンクでご確認ください。

  • Werkzeug 2.0, Jinja 3.0, Click 8.0, ItsDangerous 2.0 MarkupSafe 2.0へのアップデート
  • Python 3.5以下のversionがサポート対象外に
  • Blueprintのネスト記法対応
  • Routingがよりシンプルにかけるように
  • Configファイルの読み込み方法の変更
  • タイプヒント対応
  • 非同期実装が対応
  • Werkzeug 2.0のmultipart/form-data の改善により、大きいファイルのアップロードが15倍速に

Flask 2.0.1とFlask 1.1.4の書き方の比較確認

まずは、Flask 2.0.1とFlask 1.1.4でのRouting、Blueprint、config.from_json()、async defの書き方について比較しながら確認してきましょう。

全て一つのapp.pyモジュールとして実行できるようになっています。

初めてFlaskにふれる方は、下記のコマンドを実行し、各スクリプトをapp.pyにコピペして挙動を確認してみてください。

$ touch app.py
$ pip install Flask
$ pip install "Flask[async]"
$ export Flask_APP=app.py
$ flask run

Routingの確認

from flask import Flask, Blueprint

app = Flask(__name__)

# 日本語文字化け対策
app.config["JSON_AS_ASCII"] = False

api = Blueprint("api", __name__, url_prefix="/flask")

# flask 2.0.x
@api.get("/v2")
@api.post("/v2")
def flask2():
    return "こちらは、Flask 2.0.1です。"


# flask 1.x
@api.route("/v1", methods=["GET", "POST"])
def flask1():
    return "こちらは、Flask 1.1.4です。"


app.register_blueprint(api)

わざわざ、httpメソッドを引数内に指定する必要がなくなりました。このRoutingの書き方は、Fast APIと同様です。


Nested Blueprintの確認

# flask 2.0.x
from flask import Flask, Blueprint

app = Flask(__name__)

parent_api = Blueprint("api", __name__, url_prefix="/parent")
child_api = Blueprint("api", __name__, url_prefix="/child")


@parent_api.get("/")
def parent_flask2():
    return "Hello Parent Flask 2.0.x"


@child_api.get("/")
def child_flask2():
    return "Hello Child Flask 2.0.x"


parent_api.register_blueprint(child_api)
app.register_blueprint(parent_api)

このアプリケーションを起動してhttp://127.0.0.1:5000/parent/http://127.0.0.1:5000/parent/child/にアクセスしてそれぞれ確認してみてください。 Blueprintは、もともと大きいアプリケーションを開発する際にファイル分割、ディレクトリ分割をして各モジュール間の疎結合状態をたもつための機能でした。

Blueprintのネスト化の対応により、各モジュールを各役割・責務ごとに束ねてルーティングをする際、更にもう1階層上のレイヤーでの各役割・責務ごとに各モジュールを実装し、ルーティングの紐付けがしやすくなりました。

# flask 1.x
from flask import Flask, Blueprint

app = Flask(__name__)

parent_api = Blueprint("api", __name__, url_prefix="/parent")


@parent_api.route("/", methods=["GET", "POST"])
def parent_flask1():
    return "Hello Parent Flask 1.x"


@parent_api.route("/child/", methods=["GET", "POST"])
def child_flask1():
    return "Hello Child Flask 1.x"


app.register_blueprint(parent_api)

flask 1.1.4で同じコードを書いてみると、違いが明らかにわかりますね。

一方で、ただでさえ、Flaskの場合はディレクトリ構成に悩むことが多く、これでさらに考えうるディレクトリ構成のパターンが増え悩むことが増えてきますね。


config.from_json()の確認

...
...
# flask 2.0.x
app.config.from_file("config.json", load=json.load)
app.config.from_file("config.toml", load=toml.load)

# flask 1.x
app.config.from_json("config.json")
...
...

たまに書くことがあり、自分で間違えそうということでメモ感覚で追記しておきます。 ふーん、こうなったんだ、という感じで大丈夫かと思います。


非同期処理の確認

最後に非同期処理の確認です。Python自体は、Python3.5以降からネイティブなコルーチンが実装されており、非同期処理の実装が可能でした。

しかし、Flask 1.xでは、フレームワークとしては対応しておらず、ルーティングにコルーチン関数を書いて実行しても対応していないためエラーがでておわるだけでした。

Flaskが非同期処理に対応していないため、FastAPIを選択した方も多いのではないでしょうか。

それが、今回のFlask2.0へのversion upで対応されました。

色んな書き方があるかとおもいますが、一番わかりやすい書き方でみていきます。

# flask 2.0.x
from flask import Flask, Blueprint
import time
import asyncio


app = Flask(__name__)

async_api = Blueprint("async_api", __name__)


async def async_get_data(name, sec):
    print(f"{name}: started")
    await asyncio.sleep(sec)
    print(f"{name}: finished")
    return f"{name}:{sec}sec"


@async_api.get("/")
async def flask_async():
    start = time.time()

    results = await asyncio.gather(
        async_get_data("TaskA", 1),
        async_get_data("TaskB", 3),
        async_get_data("TaskC", 2),
        async_get_data("TaskD", 1),
        async_get_data("TaskE", 2),
    )
    print(results)
    print(f"process time: {time.time() - start}")
    return "All async tasks are finised !!"


app.register_blueprint(async_api)

出力結果

$ flask run
 * Serving Flask app 'app.py' (lazy loading)
 * Environment: production
   WARNING: This is a development server. Do not use it in a production deployment.
   Use a production WSGI server instead.
 * Debug mode: off
 * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
TaskA: started
TaskB: started
TaskC: started
TaskD: started
TaskE: started
TaskA: finished
TaskD: finished
TaskC: finished
TaskE: finished
TaskB: finished
['TaskA:1sec', 'TaskB:3sec', 'TaskC:2sec', 'TaskD:1sec', 'TaskE:2sec']
process time: 3.00414776802063

Task A ~ Eまで順番に非同期で実行され、並列処理されているため、Task A、Task D、TaskC、Task E、Task Bの順番で処理が終わっています。

本来、同期処理で一つ一つ処理が終わるまで待って処理していると、全てのタスクが終了するのに9秒かかります。しかし、上記の非同期実装により、マックスでかかる3秒以内で全てのタスクが終了しています。これで非同期処理の挙動確認ができました。

次は、version間でパフォーマンスの違いがあるかどうかを念の為確認しておきます。

Flask 2.0.xのパフォーマンス確認

日頃は、Python製の負荷テストツールであるLOCUSTを利用していますが、まだFlask 2.0.xに対応していないため、Golang製の負荷テストツールVegetaを利用して軽く負荷をかけてどんなものか比較してみます。

先に結論を言うと、大きな差分はありませんでした。 とりわけ、フレームワーク全体のパフォーマンス改善のアップデート項目が明記されていたわけではなかったので悪くなっていなくてよかったという感じです。

Vegetaの使い方をみながら出力結果をみていきます。

Vegetaは、CLIコマンドで軽く負荷試験を実施するのに便利なのでどんなものか軽く知っておくだけでもいつか役に立つときがくるかもしれません。

では、パフォーマンス確認していきましょう。

f:id:JesseTetsuya:20210707104908j:plain

画像は権利関係上使えなかったので、筆者が手書きしました。ベジータ様を書いたつもりです。

「カカロットォォォ、いくぞーーーー!おりゃーーーー!」

事前準備

*Macを前提にしています。

vegetaのインストール

$ brew update && brew install vegeta
$ go get -u github.com/tsenart/vegeta

下記では、Flask 2.0.1とFlask 1.1.4を比較するために2つのvenv環境が必要になります。 Flask 2.0.1用のディレクトリを作成し、下記のコマンドを実行してvenv環境を作成してください。

$ python3 -m venv venv
$ python3 venv/bin/activate
$ pip install Flask==2.0.1

Flask 1.1.4用のディレクトリを作成し、下記のコマンドを実行してvenv環境を作成してください。

$ python3 -m venv venv
$ python3 venv/bin/activate
$ pip install Flask==1.1.4

Flask 2.0.1の検証用コード準備

from flask import Flask, Blueprint
import asyncio

app = Flask(__name__)
api = Blueprint("api", __name__)

    
@api.get("/flask_v2")
def flask2():
    return "Hello Flask 2.0"

app.register_blueprint(api)

Flask 1.1.4の検証用コード準備

from flask import Flask, Blueprint
import asyncio

app = Flask(__name__)
api = Blueprint("api", __name__)

@api.route("/flask_v1", methods=["GET"])
def flask1():
    return "Hello Flask 1.x"
    

app.register_blueprint(api)

Flask 2.0.1とFlask 1.1.4 のパフォーマンス計測結果

負荷試験実行コマンド*

$ echo "GET http://127.0.0.1:5000/flask_v2" | vegeta attack -rate=500 -duration=5s | tee result.bin

$ echo "GET http://127.0.0.1:5000/flask_v1" | vegeta attack -rate=500 -duration=5s | tee result.bin

*5秒間500RPSで負荷をかけるコマンド (rate: Request Per Second (RPS), s: second)

負荷テスト実行結果レポート確認

レポート作成コマンド

$ vegeta report result.bin

Flask 2.0.1の出力結果

Requests      [total, rate, throughput]         2500, 500.22, 338.90
Duration      [total, attack, wait]             6.81s, 4.998s, 1.812s
Latencies     [min, mean, 50, 90, 95, 99, max]  368.671µs, 369.698ms, 296.596ms, 569.892ms, 798.921ms, 2.191s, 4.202s
Bytes In      [total, mean]                     34620, 13.85
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           92.32%
Status Codes  [code:count]                      0:192  200:2308  
Error Set:

Flask 1.1.4の出力結果

Requests      [total, rate, throughput]         2500, 500.25, 364.51
Duration      [total, attack, wait]             6.581s, 4.997s, 1.584s
Latencies     [min, mean, 50, 90, 95, 99, max]  370.878µs, 296.992ms, 276.982ms, 458.868ms, 595.851ms, 1.038s, 4.02s
Bytes In      [total, mean]                     35985, 14.39
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           95.96%
Status Codes  [code:count]                      0:101  200:2399  
Error Set:

各メトリックスのみかたは、下記。

- Requests
    - total … 全実行回数
    - rate … 秒間の実行回数
- Duration
    - total … 負荷をかけるのに要した時間(attack+wait)
    - attack … 全リクエストを実行するのに要した時間(total - wait)
    - wait … レスポンスを待っている時間
- Latencies … それぞれ、平均、50%、95%、99%パーセンタイル、最大値
- Bytes In/Bytes Out … リクエスト/レスポンスの送受信のバイト数
- Success … リクエストの成功率(なお、200と400がエラーとしてカウントされない)
- Status Codes … ステータスコードのヒストグラム(0は、失敗)
- Error Set … 失敗したリクエストとその内容

「Flask 2.0よ、そんなものか、そんなにかわらんではないかっ、貴様っ!!」とベジータ様が申しております。

負荷テスト実行結果をヒストグラムで確認

さて、次はヒストグラムでみてみます。

ヒストグラムレポート作成コマンド

$ cat result.bin | vegeta report -type='hist[0,100ms,200ms,300ms,400ms,500ms]'

Flask 2.0.1の出力結果

Bucket           #    %       Histogram
[0s,     100ms]  159  6.36%   ####
[100ms,  200ms]  397  15.88%  ###########
[200ms,  300ms]  728  29.12%  #####################
[300ms,  400ms]  505  20.20%  ###############
[400ms,  500ms]  336  13.44%  ##########
[500ms,  +Inf]   375  15.00%  ###########

Flask 1.1.4の出力結果

Bucket           #    %       Histogram
[0s,     100ms]  188  7.52%   #####
[100ms,  200ms]  478  19.12%  ##############
[200ms,  300ms]  976  39.04%  #############################
[300ms,  400ms]  440  17.60%  #############
[400ms,  500ms]  191  7.64%   #####
[500ms,  +Inf]   227  9.08%   ######

「なにっ?!Flask 1.1.4のほうが若干安定してるようにみえるではないか、貴様っ!!」とベジータ様が申しております。

負荷テスト実行結果を時系列グラフで確認

時系列グラフのhtml生成コマンド

$ cat result.bin | vegeta plot > plot.html
$ open plot.html

Flask 2.0.1の出力結果

f:id:JesseTetsuya:20210707110159p:plain

Flask 1.1.4の出力結果

f:id:JesseTetsuya:20210707110225p:plain

「はやくしろっ!!!! 間にあわなくなってもしらんぞーっ!!!」とベジータ様が申しております。

最後に

このようにベジータ様がおっしゃっていますが、実際のところ大きな差分はありませんでした。

Flask 2.0.xへversion upするか否かは、利用したいライブラリが対応しているか否か、非同期実装したいか否か、Blueprintをネストしたいか否か、で決めればいいと思いました。

しかし、まだ確認できていない箇所や気になる項目もあり、全ての項目について当ブログ記事にて書ききることができませんでした。

というわけで、私のFuture Workとして箇条書きにて下記に残しておきます。

  • Fast APIとの書き方の比較をみる
  • 非同期処理のパフォーマンスをFast APIと比較してみる
  • multipart/form-dataの15倍速が本当にそうなったかをみる
  • Vegetaで分散アタックする
  • 今年度、どこかの国のPythonカンファレンスで上記の検証結果まとめを発表します
  • Flask全般の使い方については、チュートリアルを今年度、どこかの媒体でまとめて発表します

データAI部では、PoCとデータをもってくる、というところ以外全部やるPythonエンジニアを募集しています。

全部とは?!が気になる方は、下記URLを確認して頂きカジュアル面談の応募お待ちしています!!

hrmos.co

Flask 2.0.xへのメジャーバージョンアップ関連資料

停滞した開発者ブログを復活させるまで

こんにちは、サーバサイドエンジニアのid:aerealです。

この記事ではClassi開発者ブログ (以後、開発者ブログ) の編集長としてClassi開発者ブログが再始動するまで・再始動してからおよそ半年の振り返りを通して企業の技術ブログ運営の裏側についてお伝えしたいと思います。

開発者ブログ再始動の経緯

Classi開発者ブログは2020年3月の新型コロナウイルスの影響で全国の学校が休校になってどうなったか - Classi開発者ブログを境に2020年10月のClassiで発生した2つの問題を繰り返さないために我々が取り組んでいること - Classi開発者ブログまで記事の投稿がありませんでした。

これはご利用いただいているお客様への情報発信と歩調を揃える必要がありとても難しい状態であったという背景があるにせよ、投稿が一時途絶え寂しい状態であったことは事実です。

2020年8月にClassiに参画した筆者は、このブログをClassiに所属するデベロッパーにとって重要な情報発信の拠点として復興させたいという思いを強く抱き、ブログ再開に向けて動き始めました。

まず、ブログをどのような位置付けとするのか・再開するにあたってステークホルダーは誰でどのようなブロッカーが存在するのか、を明らかにするところから始まります。

位置付けは大きく、採用戦略の第一級の手段として扱うのか・Classiに所属するデベロッパーのアウトプットの拠点として扱うのか、といった方針が考えられます。 ざっくりといえば当面は後者としよう、と決めました。詳細は後述します。

ステークホルダーとブロッカーの整理は、いかにもカロリーが高そうで身構えたくなりますし実際その覚悟をしました。しかし開発者ブログに閑古鳥が鳴いている状況を憂うメンバーばかりで目的意識はスムーズに共有できたので少しの旗振りで動き出すことができました。 その結果、開発者ブログについて以下のことを確認しました。

  • 開発者ブログは開発に関わる情報発信の場とする
    • 顧客コミュニケーションの主たるチャンネルではない
  • 編集部によるレビューを必須とする
  • 広報レビューは可能 (can) であり必須 (must) ではない
    • この判断は編集部に任される

Classi開発者ブログの目指すところ

企業が運営する開発者ブログ・技術ブログの目的としてブランディングや採用活性化などが一般に挙げられます。 筆者自身も、以前所属していた企業で開発者ブログの執筆に関わっていた際にこれらにポジティブな影響があることは実感しています。

一方で、こうしたPRへの寄与はブログの執筆や運用にかなりの熱量と時間を費して得られるものであって、一朝一夕でなるものではありません。 また、採用への寄与やブランディング向上は外部要因が占める割合も小さくなく効果測定が難しいです。 こうした背景により開発者ブログを再興するにあたって目標をブランディングや採用活性化に置くのは実現や評価が難しく頓挫してしまうおそれがあると考えました。

そこで開発者ブログを 「より充実した発信環境を求めるClassiの技術者に向けた執筆の場」 とすることにしました。

これをもう少し分解すると:

  • 読み手にとっての価値より書き手にとっての価値を第一に考える
    • 場を作ったり書くことを継続することに踏み出せないでいるメンバーが主な対象
    • そのために慣れた書き手たちが技術ブログを暖めたり、期待値コントロール、レビュアーとしてサポートする
  • 以下のような点は「できたら良いこと」という扱いにして、当面は第一の目的としない
    • 会社のブランディング・認知向上
    • 採用への貢献

……ということになります。

主要KPIは以下の通りとしています:

  • 執筆者のUU (より多くの人々が書くほど良い)
  • ブログ全体の記事執筆継続率
    • 筆者は問わずブログの記事公開が根付いているか
    • 期間中に書かれた記事数を日数で割る

ただし参考指標としてPVの推移は編集部が責任を持って見ています。 執筆者に対しては積極的にフィードバックしていません。執筆者全員が権限を持っているので本人が望めばはてなブログのアクセス解析機能で参照することができます。

また、以下の指標は当面重視しないことにしています:

  • Twitterやはてなブックマークなどの言及数など、SNSでの反応
    • 上記の通り「会社のブランディング・認知向上」は当面の間、第一の目的としないため重視しない

編集部の運営

以上のような経緯で再開したClassi開発者ブログは、現在この記事を執筆している id:aereal が発起人となった編集部が中心となって運営しています。 編集部はid:sasata299id:tetsuro-ito と発起人となった筆者である id:aereal が務める編集長の計3人からなります。

主な仕事は:

  • 記事のネタと公開スケジュールの管理
  • 執筆された記事のレビュー
  • その他、ブログ運営にまつわる仕事全般
    • 著作権の帰属の整理・明文化
    • ブログホスティングサービスの費用管理 etc.

……です。

記事のネタはAsanaのカンバンで管理しています。一般的なカンバン運用に倣い“Backlog”, “Ready”, “Doing”, “Waiting for review”, “Done”のレーンを作って、現在何待ちなのか一目でわかるようになっています。

Asanaのカンバン。Doingレーンに「開発者ブログ振り返りの記事」。Waiting for reviewレーンは空。Doneレーンに「3月に2020新卒に振り返りを書いてもらう」。
Asanaのキャプチャ

BacklogとReadyを分けているので「とりあえずこういうネタがありそう」というラフなトピックをBacklogに入れておき、具体的に書けそうになったらReadyに移すという運用が可能になり、Slackで湧いたアイデアを取り上げやすくなっていて良いかんじに機能しています。

またレビューが済んで記事の公開準備が整ったらGoogle Calendarに予定を入れます。編集部カレンダーは編集部のSlackチャンネルに流すようにしているので「おっ 今週はこの記事が公開予定だな」と毎日わかるようになっています。

Slackに流れる予定通知のキャプチャ。開発者ブログ編集部カレンダーに設定された「記事公開予定: そーだい塾の記事公開」という予定が通知される。
記事公開予定がSlackに流れる

現在のところ週1くらいのペースなので、ラフに1週間の予定として入れています。 月間ビューだと「この週は記事公開予定がある、この週は空いているので調整しようかな」と一目でわかって便利です。

編集部カレンダーの月間ビュー。「開発者ブログ編集部定例」「記事公開予定: あんずさんの記事」「そーだい塾の記事公開」という予定が入っている。
カレンダーの月間ビュー

これらを毎週15分の定例で確認・最新状態に更新したり声かけする人を見繕ったりします。 アジェンダが決まっており事前に準備をしっかりしておけば15分で十分だろうと見立て、実際に必要十分で延ばそうと話題に上がったことはありません。 15分はなかなかタイトなので事前にアジェンダをしっかり準備しておかないといけない良いプレッシャーがあり編集部一同から好評です。

半年間の振り返り

以上のような経緯で再開したClassi開発者ブログは、現在この記事を執筆している id:aereal が発起人となった編集部が中心となって運営しています。

この記事を執筆している時点では:

  • 執筆者UU: 17人
  • 記事数: 20記事 (1ヶ月あたり約3記事超)

……となっています。

上記からわかるように新しい記事のほとんどを新しい執筆者が書いてくれていることがわかります。 当面は少数の熱量が高いメンバーを中心に記事を執筆していくことになると見立てていたので、これは嬉しい誤算です。

またVPoTのid:nkgt_chkonkとVPoEのid:sasata299がそれぞれ執筆した2020年4月期に発生した2件の問題とそれ以後の体制・改善に関する記事をきっかけにDevelopers Summit 2021へ登壇する機会をいただき全国一斉休校によって教育プラットフォームの「Classi」に起こった大障害 〜サービス・組織をどう変化させたのか〜という発表をさせていただきました。 当面はブランディングへの寄与等は目標に入れないこととしていましたが、早くも結実しつつあること実感し一同で喜びました。 執筆者の二人にとってもプレッシャーのかかる内容だったと思いますが、それを乗り越えて発信してくれたおかげでもあります。

参考:

記事を公開した際には社内のSlackチャンネルで「この人がこういう記事を書いてくれましたよ」という宣伝を私からしていたのですが、その甲斐あってなのかプロダクト開発部以外のメンバーからも「ブログを読んでいるよ」という声を聞く機会がありました。 身近に読者がいることは編集部としても執筆者一同としても励みになります。

編集部の振り返り

最後に先日、編集部で実施した振り返りについて述べます。

再開からおよそ半年が経ったタイミングで「どんなことをやったか」「やったことでどんな影響があったか」「思いがけず起きたことは何か、それを再現しつづける術はあるか」の洗い出しを主眼に置き、より持続的な開発者ブログ運営に繋げるための糧とすべく、YWT (= やった、わかった、Try = 次にやる) 形式で振り返りました。

以下に一部抜粋したものを載せます:

  • やったこと
    • 編集部立ち上げ
    • 毎週15分の定例実施
    • Slack上で記事レビュー
    • チームメンバーへ記事執筆の斡旋
  • わかったこと
    • 推進役がいることの重要性
    • 執筆に意欲的な人が多い
    • 記事のレビューが受けられることによる安心感がある
    • 定例は15分でちょうどいい
  • 次にやること
    • 執筆者のUUを増やしたい
    • 1人あたりの執筆数を増やしてリピーター化したい
    • 振り返りでは概ね「想定以上にうまくいっている」と話題になりました。
    • 開発者ブログ執筆に潜在的に意欲的だったメンバーの存在がとても大きく、うまく掬い上げられたからだろう、と結論付けています。

むすび

Classi開発者ブログは「やったら良さそうなこと」「やるべきこと」の淡々とした積み上げと少しの運に助けられ軌道に乗っているだけということがおわかりいただけたかと思います。

衆目の耳目をさらう開発者ブログは類まれなる情熱と資源と少しの運から成り立っているのだろうと推察します。 それらを一度目指せどもうまくいかず頓挫する企業の開発者ブログも少なくないことを知っています。

しかしClassi開発者ブログは当初立てた目標を果たしつつあります。それは身の丈にあったマイルストーンを設定していること、動機の内在化を図ったからといえます。 ゆくゆくはClassi開発者ブログが大きくなることを夢見ないわけではありませんが、それは今掲げている「より充実した発信環境を求めるClassiの技術者に向けた執筆の場」というスローガンの延長線上に大きくなることがあるからでしょう。

筆者は各企業のユニークな取り組みがより世の中で行き交う世界を望んでいます。 そのためにこうした素朴ながらヒロイックではない開発者ブログのありかたをひとつご紹介し「やってみようかな」と思い立ってくれる方が一人でも増えることを願い筆をとりました。おもしろい記事が世の中に増えれば幸いです。

2021年度新卒研修の一環としてそーだい塾に参加しました

2021年度4月に Classi に入社しエンジニアをしています、北村です。

先日新卒研修の一環としてそーだいさんによるそーだい塾に参加しました。今回はそーだい塾の当日の様子や学んだ内容を振り返りつつ、参加レポートを書きたいと思います。

そーだい塾とは

そーだい塾はそーだいさんが講師を務める勉強会の通称です。 Classi では今年度から、新卒研修の一環としてそーだい塾が開かれることになりました。今回はその記念すべき第一回目でした。

そーだい塾については、すでにそーだいさんご本人が書いてくださった記事もあるので合わせてご覧ください。

当日

今回のそーだい塾は一部と二部の計二回、二日間の日程で行われました。

資料

第一部資料

第二部資料

様子

当日は両日とも zoom ミーティングで行われました。 前半45分がそーだいさんによる講義タイム、後半45分が質疑応答タイムとして進められました。

f:id:liaob88:20210610193254p:plain (第二回の様子)

参加については、新卒研修という名目でしたが特に新卒だけに参加対象を絞る理由はなかったので、自由参加形式をとりました。その結果、当日は多くの先輩方も一緒に参加してくださいました。

このことは、

  • 自分一人だけで参加した場合では生まれなかったであろうわいわい感が生まれた
  • 講義の間に先輩方が自身の考えや補足情報を zoom のチャット機能や slack チャンネルに書き込んでくださり学びが多かった
  • 質疑応答の時間でも、自分には持てなかった思考や視点からの質問やディスカッションが行われ、これも学びが多かった

などなど、当初想定していなかった副次的効果ももたらしてくれました。

例えば以下の写真は、自分が

という質問をした際の slack の様子です。

f:id:liaob88:20210610193331p:plain

(第一回実施中の slack の様子)

自分の質問に対して、そーだいさんだけではなく多くの先輩方も一緒になって考えてくださり、ご自身の意見や補足情報を共有してくださっている様子が伝わるかと思います。

自分一人だけでそーだい塾に参加していた場合、もちろんこのようなことはありえなかったと思いますし、自分の講義内容に対する理解もその分浅いものになっていたと思います。

なので今回このように先輩方と一緒になって講義を聞き、議論し、学ぶことができたことは非常に良かったと思っています。

当日出た質問

ここでは資料には載っていない当日出てきた質問をいくつか紹介したいと思います。

Q1

コードに遊びを持たせるというお話の中で decorator パターンという手法が紹介されていました。しかし経験上、全てがdecorator パターンで書かれたプロダクトはあまり見たことがないです。これは、decorator パターンにもメリットデメリットがある、あるいは何か違う理由が存在しているからなのでしょうか?

A

理由は二つある。

一つ目はもちろん decorator パターンにもメリットデメリットがあること。decorator パターンの全てが正しいわけではない。重要なのは decorator パターンが何を解決したいのかを、他のデザインパターンとの比較を通してしっかりと理解し、用法用量を守って使用していくことである。

二つ目は全てのサービスがシンプルを目指しているわけではないということ。プロダクトによっては、戦略として意図的にイージーな設計をしているものもある。なので「今作っているサービスは一体何を解決したいものなのか?それにはシンプルな設計が良いのか、あるいは例外的にイージーな設計の方が良いのか?」を常に考えて実装していくことが不可欠。

Q2

小さくリリースしていく場合、どういう観点でリリースする順番を決めていきますか?

A

複雑で、影響範囲が広く、元に戻すのに時間がかかるような変更、あるいは、リリース後に得られるフィードバックですぐにその是非を判断できる変更やユーザーから遠い変更ほど先にリリースする。

例えばフロントエンドの変更はユーザーに見えてしまうという理由から、影響は広くユーザに近い変更と判断できるので、比較的リリースは最後になりがち。

Q3

スコープを小さくするという観点でDBが状態を持つことは良くないというお話がありました。その対応方法としてテーブルを分割する方法が紹介されていました。

しかし一方で DB は最小限の数に抑える方がいいというお話もありました。スコープを小さくするという観点で言えば、一つの DB にデータが集中することは良くないことであるように感じましたが、DB は最小限の数にした方が良いとされているのはなぜですか?

A

確かに責務が集中するという観点で言えば 1 つの DB にデータが集まることは良くないと言える。

しかし、DB を管理するという観点で言えば、 1 つの DB のみ面倒を見れば良いという点でスコープが小さいと言えるので最小限の数にした方が良いと言える。

但し、確かに DB にも得意不得意があり、正しい役割分担をさせる必要があるのでバランスをとる必要はある。例えば MySQL は画像の保存は苦手であり、それに関しては S3 などを使用する方が良いと考えられる。

印象に残った話

ここでは特に自分の中で印象的だった内容を二つ紹介していきます。

リリースはソフトウェアエンジニアの価値提供の手段

自分がそーだい塾の中で一番大事だと感じたのが「リリースはソフトウェアエンジニアの価値提供の手段」というお話でした。

これは「ソフトウェアエンジニアは、どんなに良い機能を開発したり良い改善を行って価値を創造したとしても、リリースを行わない限りはその価値をユーザーに届けることはできない。つまりリリースをすることはソフトウェアエンジニアの価値提供の手段である。もし価値をより多く届けたいのなら、より多くのリリースをしていくことが必要である。」という事実を説明しています。

自分はこれまで「開発すること」に自分の意識や時間のほとんどを割いてきました。それゆえリリースをきちんと想定した上での行動を取れたことはほとんどなく、その場限りの対応で乗り切ってきたと思います。コードを書いてある程度満足し、それが自分の仕事であるとさえ考えていたと言われても否定できないです。

なので今回の勉強会を通して、リリースが「ソフトウェアエンジニアの価値提供の手段」として位置付けられて説明されたことは、自分が普段行なっている仕事について改めて考え直す良い機会になりました。

今後は日々リリースすることまでを考えて業務に取り組み、より多くの価値を届けることを意識しようと思えました。

リリースをより多く行なっていくために「小さく、素早く、始める」

「リリースをより多く実施していくためにはどうすれば良いの?」という問いに対する答えとして示されたのがこの「小さく、素早く、始める」というお話だったと思います。

例えば今回の勉強会ではその例として「段階的リリース」という手法が紹介されています。あるリリースを、変更内容によって細分化することで、リリースによる影響範囲をなるべく小さくする方法です。これはバグの早期発見と早期解決という結果にも結びつきやすく、結果的にリリースのスピードが高まり、リリースの数を増やしていけるというメリットがあります。まさに「小さく、素早く、始める」の恩恵を享受できる良い例です。

個人的には「小さく、素早く、始める」という話は、普段の機能開発において、小さな変更でPRを作って行くことで開発スピードやその正確性を上げていくことが良しとされることと似た話だなとも感じました。

「小さく、素早く、始める」というのは UNIX 哲学の中で登場する概念ということも学んだので、自分も早速 UNIX 哲学の本を購入し勉強することにしました。

さいごに

正直自分はこれまでリリースに関して特別に勉強した覚えはなく、開発の最後の1工程という認識しか持てていなかったです。

なので、今回のそーだい塾を通じてリリースの重要性とその実施の手助けとなる多くの手段を学ぶことができたことは非常に良かったと思います。

しかし教えていただいただけでは意味がありません。今回教えていただいた内容を活かすためにも、今後の日々の業務で、できるところから「小さく、素早く、始める」を実践し、より多くのリリースをすることで、 Classi のソフトウェアエンジニアとしてより多くの価値を届けていきたいと思います。

© 2020 Classi Corp.