Classi開発者ブログ

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

JSConf JP に参加してきました

こんにちは。開発本部プロダクト開発部学習チームでエンジニアをしています、id:tkdn 武田です。

弊社もスポンサーとして後援していた JSConfJP へ参加してきましたので、今日はそのレポートと特に気になったセッションを中心に感想をまとめていきます。

なお、この記事は Classi developers Advent Calendar 2021 の 3 日目の記事です。

JSConfJP について

本カンファレンスは本年が 2 回目の開催です。前身となっている Node 学園祭が、各国で開催する JSConf といった冠のついた日本版 JSConf といった趣きのイベントとなり、2019 年から生まれ変わっています。私個人としては前身のイベントには 2017, 2018 に参加、JSConfJP 2019 に参加しているので、今回のオンラインイベント含めて 4 回目の参加になります。

今年は SpatialChat の会場が用意されスポンサーブースの設置もありましたが、自身の性格もあいまって話しかけるのは難しかったなという印象でした。Twitter でのハッシュタグつきの投稿は盛り上がっており、当日は私も見ていたセッションについて積極的にコメントしていました。

アーカイブが残っていますので見逃したセッションのある方や当日参加できなかった方は以下からご覧になれます。

ソフトウェアをめぐる話

最初に取り上げるのは Classi フロントエンドのプロジェクトに入っているツールの 1 つでもある Prettier、そのメンテナーである sosukesuzuki さんのセッション。そして、今年会社化され Deno Deploy など分散ホスティングサービスも展開する Deno、その中の人でもある kt3k さんによるセッションです

エコシステムを支える OSS の努力や課題

sosukesuzuki さんのセッションで語られた印象的な部分は Prettier がエコシステムでどういった立ち位置にあるのかといったものです。

下記は TC39 Proposal の策定プロセスから、各ツールチェインに新しい構文がどう反映されどのパーサにどういった役割があるか発表のスライドから引用したものですが、かなり複雑な図に感じますね。

sosukesuzuki スライドより

セッション後の質疑応答では sosukesuzuki さんの個人的な見解ではあるものの、「今の JavaScript を支えるツールチェインは歪な形をしている」という話が出ていました。

Rome などのオールインワンの OSS が代替ツールとして出てくることについても、各ツールが独自にもつパーサによる解析を統一すればコンピュータリソースの削減もできるし計算効率も高くなり無駄がなくなる、順当な流れなのではないだろうかというお話でした。このくだりは本当にいいお話だったので、執筆の際にも何度か繰り返し再生しています

OSS のメンテナーが感じている所感をほかのソフトウェア(webpack, Babel)のメンテナーのインタビューも交えながらリアルな声を聞けたのは、OSS の実際というところを垣間見る良い機会となりました。

しばしば話題になる以下のようなメンテナー不足の issue を見るたびにユーザーとして心を痛める反面、ソフトウェアにできることは何なのかを考え、還元していかなければとあらためて感じました。

法人化しユーザー・ソフトウェアを増やそうとするプラットフォーム

スライドリンク:Deno のこれまでとこれから JSConf JP 2021

一方で Deno は法人化しており Deno Deploy をベータで公開しながらも GA した際には収益化も検討しているプラットフォームでありカンパニーです。すでに GitHub においての採用が発表されていますし、つい先ごろ発表された Slack の新しい開発プラットフォームのバックエンドとしても採用されています。

kt3k さんから語られたのは Deno のこれまでの歩みとこれからについてでした。Deno は Node.js の作者でもあった Ryan Dahl が Node.js をデザインした際の後悔を元に、それらを克服したプロジェクトとして立ち上げたものです。

kt3k スライドより

Ryan Dahl の後悔はいくつかあるようなのですが、その中でも実行環境におけるセキュリティサンドボックスのモデルについてをここでは取り上げています。

Node.js は実行時の許可なくファイルの読み書き、ネットワークアクセスなどが自由にできますが、Deno では実行時のパーミッションオプション(--allow-read, --allow-net など)を有効にしないとできません。実行時に明示的に権限を与える必要があるのです。これによって高いセキュリティを期待できる点も採用事例が増えてきた理由でしょう。

ですが、セッションでも語られたように 10 月に大きなロードマップの追加がありました。それが Node.js 互換モードです。おい待てよと、Node.js との差別化のために生まれたはずなのに迎合しているのでは、といった意見がコミュニティや社内から湧き上がったそうです。

Node.js 互換といった 180 度の転換が Ryan Dahl 本人からの発案であることも驚きですし社内では反対意見が多かったということも驚きですが、背景としては Deno をインストールするユーザー数の今のところ横ばいであるのも起因しているようです(質疑応答より)。

スライドでも登場しますが、卵が先か鶏が先かのプラットフォームの問題にも触れ、ユーザーが少なければそのプラットフォームで動くソフトウェアは増えず、ソフトウェアが少なければそのプラットフォームを使うユーザーが増えないという Deno が今直面している状況と、今回の Node.js 互換モードが紐付けられています。

こういった Deno の裏側を知ることができたのも興味深くおもしろい話でした。

アクセシブルな Web のためのフロントエンド開発

最後に取り上げるのは yamanoku さんによる「アクセシブルなフロントエンド開発のこれまでとこれから」というセッションです。

この発表の前に yamanoku さんは「HTML だけで UI を作る限界、あるいは無理なくユースケースと向き合っていくためには」と題した発表も別の場でされており、そちらも強く私の印象に残った内容でした。

yamanoku スライドより:HTML でアプリケーション相当の UI を作るのキツくない?

今回はその限界を示しながらもっとアクセシブルであるためには、といった内容が主題になっています。Web, HTML そして HTTP の父であるティム・バーナーズ・リーの引用も交えながら、アクセシブルとは普遍的に障害の有無に関係なく誰も使えることが本質だという力強い言葉に、Web が好きなフロントエンド開発者として冒頭から胸が打たれました。

そして肝心のアクセシビリティに関してですが、セッションの内容には恥ずかしながら自身にとっては初めて知ることが多く反省も多くありました。

たとえば SPA におけるルーティングの遷移後、スクリーンリーダーでの読み上げ時にページが変わったことを検知できないというデモを見て、初めて WAI-ARIA aria-live について認識できました。Angular では下記のような実装イメージで画面タイトルの変更をスクリーンリーダーを扱うユーザーに通知できます。

<div *ngIf="pageTitle$ | async as pageTitle" aria-live="polite">
  {{ pageTitle }}
</div>

発表のあとに調べると Angular CDK では LiveAnnouncer といったモジュールも提供されておりこちらもうまく活用できそうです。

@Component({/* ... */})
export class MyComponent {
  // ...
  constructor(liveAnnouncer: LiveAnnouncer) {
    liveAnnouncer.announce(this.pageTitle));
  }
}

ほかにも Custom Elements に直接 role 属性を与えずに JavaScript から内部的に与えるという Accessibility Object Model といった案もコミュニティから出ていると知りました。利用時に都度必要な属性を利用者が付与せず、Custom Elements の実装者が内部的に担保できるというのは納得の提案ではあります。

スクリーンリーダーへの対応というと身構えそうですが、スライドでも出てきたようにキーボード操作のタブフォーカスでアクセスが可能かといった小さなところからでも始められるはずです。UI が知覚可能であるかどうかということを気にかけるだけでも、考慮できるポイントが増えそうだと感じました。

JSConfJP オンライン参加を終えて

Node 学園祭から参加し続け、今回は初めてのオンライン開催でしたが、オフラインと変わりなく JSConfJP を楽しむことができました。カンファレンスでは新たに気付くことも多く、今回は特に OSS やソフトウェアが成立するためのプラットフォームの話から、我々開発者はどうコミュニティに貢献するのかといったことをあらためて考えさせられる良い機会を得ることができました。

まだまだ数は少ないですが社内メンバーの登壇やコミットメントという形でも成果を発揮しながら、Classi は今後もコミュニティを通じて OSS への還元を目的に、利用技術のカンファレンスやイベントに支援していく予定です。

またカンファレンスで得た知識、特に今回はアクセシブルな UI を実装していくことなどを現場のプロダクト開発に持ち帰りたいと思います。

JSConfJP 運営の皆さま、ご苦労さまでした!

Google Cloud Security Summitに登壇してきました

こんにちは、データAI部の滑川(@tomoyanamekawa) & 工藤( id:irisuinwl )です。 今日(2021-12-01)、2人でGoogle CloudのSecurity Summitに「Security Command Center から始めるクラウド セキュリティ運用」というタイトルで登壇してきました! その報告と発表内では話しきれなかった各施策の実装面の補足の記事です。

続きを読む

マネージャーからエンジニアに役割を変えた話

はじめに

すっかり寒くなりましたが、皆さまいかがお過ごしでしょうか。Classiの佐々木(@sasata299)です。

タイトルにもありますが、9月まで担っていた開発本部長*1を離れて、10月からエンジニアに役割を変えました。この記事では、どんなことを思って、どんな風に考えて進めてきたのかをお伝えできたらと思っています。

最近やっていたこと

開発本部として80名を超える大きな組織となり、最近は主にこの辺りに関わってきました。

  • 開発本部として大切にしたいことを決定
  • CTOの責務を、VPoTとVPoEに分解*2
  • アラート対応の体制化や手当検討
  • 既存の部から役割を分けて分割する形で、開発支援部の新設
  • 評価体制の変更

余談ですが、こういった組織課題に対して、当初はVPoTである丸山(id:nkgt_chkonk)、稲富(@laco2net)、佐々木という3人体制でスクラムで進めていました。実際やってみて、プロダクトづくりに限らず組織課題に対してもスクラムは有効なんだなというのを実感しました。

途中からは開発本部内の各部長も加えて少し形を変えましたが、今も変わらず、こういった組織課題にはチームとして継続的な対応を続けています。

マネジメントを経験してみての気付き

組織は生き物で日々いろんな課題が出てきますが、組織全体の生産性を上げる仕組みを作るなど、マネジメントとして関わることの魅力や悩みはたくさん感じてきました。

実際にやってみないと向いてる/向いていないもわからないので、いろいろな組織規模でマネジメントを経験することができたことは、とてもとても良かったなと思っています。

一方で、先に挙げたような課題に取り組んでいく中で、今、このフェーズで開発本部長に求められているのは、課題を抽出して抽象化して、解決策として適切な仕組みをつくる力なんだろうなと感じていました。 そしてそこは、佐々木に足りないところ、弱いところだな、とも感じていました。

課題は明確になってきていて、適切な人がやればもっと早く対策を打ったり仕組みが作れそう。だけど、佐々木が開発本部長でいることでボトルネックになってしまう。より良くなるために、もっと適切な人に開発本部長という役割を担ってもらうべきだと思ったんです。

エンジニアとしてやっていく

もう一方の理由として、コードを書きたい、コードを書いて貢献したい、というのがありました。ここ数年はよりボトルネックになっているマネジメントをやってきましたが、もともとコードを書くのが好きでエンジニアになったので。(大体の人がそうですよね)

加えて、マネジメントをやる期間が長くなり、また、組織の成長もあってマネジメントする対象範囲が広がったことで求められる役割も現場から離れてしまっていたので、エンジニアとしての現場感が無くなってきていてヤバいという危機感も強くありました。

こういったことを考え、開発本部長を離れてエンジニアとしてやっていきたい、と少しずつ代表と相談を進めていきました。

次の体制の検討

開発本部長を離れるにあたって一番の課題は「次の体制をどうするか?」というものでした。どんな形を取るとしても一定の不安や変化は発生しますが、それらを出来る限り小さくしたいと考えて進めました。

開発本部長に求められる役割やスキルを改めて整理し、誰がもっとも適任なのか。今のClassiにとって最善なのはどういう形なのか。いくつかの選択肢から経営陣とも何度も議論を重ね、開発本部内のデータ/AI部(データサイエンティストやデータエンジニアが所属する部署です)の部長である伊藤(@tetsuroito)に開発本部長をお願いすることを決めました。

伊藤のこれまでの社内での活躍やそれによる信頼もあり、10月からの体制を社内に周知した際には前向きな反応が得られました。あれもこれも完全に引き継げた!というわけではないので課題はあるのですが、まずは少しだけホッとしました。

今やっていること

10月からは役割を変え、新規事業の立ち上げにエンジニア(not マネージャー)として関わっています。「tetoru」という小中学校向けの保護者連絡サービスです。

tetoru.jp

エンジニアとして手を動かすのは久しぶりですが、ユーザに価値を提供するためにプロダクトを作っていくのは純粋に楽しいな〜と感じてます。 Classiは高校(一部中高一貫校含む)向けにプロダクトを提供しているのですが、「tetoru」では小中学校向けにプロダクトを提供していきます。

私事ですが、子供がちょうど小学生なので自分自身がまさにユーザーです。保護者として自分が使いたいプロダクトを自分で開発しているというのは楽しいし、エンジニア冥利に尽きます。早く子供の学校でも導入されてほしいし、大きくなったら子供にも自慢したいなぁと、そんなことを思ったりしています。

まだまだやりたいことはたくさんあって仲間を募集しているので、少しでも興味あれば気軽にお話させてください!

hrmos.co

おわりに

Classiに限らずだと思いますが、一度マネジメント側に行くと戻りにくい感じがしますよね。マネジメントをされている方がコードを書きたくて別の会社に転職するという話もよく聞きます。

マネージャーからエンジニアに役割を変えるキャリアを普通にしたいし、Classiであれば大変だけどやれなくはないだろうと思ったのでまずは自分自身でチャレンジしてみた、という話でした。この事例が少しでも参考になれば幸いです。

そういえば今日からアドベントカレンダーですね!弊社のトップバッターは伊藤なので、お楽しみに。

*1:以前の記事ではVPoEと呼んでいたのですが、紆余曲折あり、途中から開発本部長と呼ぶようになりました。

*2:詳しくは https://tech.classi.jp/entry/2020/11/13/120000 を参照ください

エラスティックリーダーシップ読書会 修了レポート

新卒入社三年目の小野です。校務チームで生徒を登録する機能の開発を行っています。 先日、弊社で新卒オンボーディングチームに所属されている @igaiga555 さんが主催するエラスティックリーダーシップ読書会を修了しました。会の概要や感想を書かせていただきます。

開催されるまでの流れ

新卒オンボーディングチームで、新卒メンバーにチーム開発時に知っておくべき知識を身につけて欲しい、という課題感があったようです。オンボーディングチームの方が、知識を身につけるには社内メンバーによく読まれている本を読むと良いのではと考えて、プロダクト開発部の雑談・相談チャンネルでマネジメントや組織についてのおすすめの本を募りました。結果、エラスティックリーダーシップ が最多得票しました。さらに、エラスティックリーダーシップについて、フロントエンドエキスパートチームの @lacolaco さんが「必読書で良いのでは」と強く勧めたことから、エラスティックリーダーシップ読書会をやろう、という動きが新卒オンボーディングチーム内で活性化したようです。その後、@igaiga555 さんが以下の呼びかけを行って、読書会が開催されることとなりました。

f:id:yukoono01:20211115154812p:plain

私は新卒入社の1人として必須参加だったこともありますが、社内で複数人の方がこの本を勧められていたのを見ていたため、本の内容に興味を持って参加しました。

読書会でやったこと

読書会は月曜日の1時間を使って行われていました。会の流れは以下です。

  • 参加者が集まるまで雑談する。(2分程度)
  • あらかじめ指定されていた章を各自で読みながら、感想をJamboardに書く。(人数により変動。だいたい25分)
  • 残りの時間でJamboardを見ながら、参加者が1人ずつ感想を読み上げていき、他のメンバーはコメントしたり、質問などをして議論する。

感想は最初の1回目はJamboardではなくesaに各自で書く形式でしたが、@kiryuanzu さんの提案により2回目以降はJamboardを使うようになりました。各自違う色の付箋を使うことでコメントを書いたのが誰かすぐ分かるようになり、リアルタイムな議論がしやすくなりました。

f:id:yukoono01:20211116180234p:plain
Jamboardを用いた議論の例

印象に残った章

私個人として一番印象に残ったのは、4.2.1節「必要なゆとり時間はどれくらいか」の一節である、「学習時間の生産性が通常の生産性よりも10倍も低い」です。目の前の仕事に追われるサバイバルモードから、スキルを伸ばせる学習モードにチームを導いていくべきであり、またモードを移行するにはゆとり時間が必要であるという説明の一部としてこの一節が書かれています。当時、私はフロントエンドにページビューを取るためのタグを埋め込むという全く経験のないタスクを任され、進捗が思うように上げられずにいました。この一節から、経験がないことを学習しながら進めることは、時間が10倍かかるのだから大変でも当然である、という気付きを得ました。もっとも、5章において学習のためには逆境に飛び込む必要があることが述べられており、学習が決して易しいことではないことも書かれています。

次に印象に残ったのは、6章の「コミットメント言語」です。コミットメント言語とは、相手に言質を与える言い方のことです(ex: 今週中までに終わらせます、毎日何時間ずつタスクに取り組みます、など)。逆にコミットメント言語でない言葉は、実現できない余地を残します(ex: ○○する必要がありますね、できるだけ早くやろうと思います、など)。コミットメント言語を使い個人のコミットメントが明確になることで、目標達成を阻害する要因を見つけることに役立ちます。 印象に残ったポイントとしては、私自身がコミットメント言語でない言い方を使いがちであったことや、コミットメント言語を習得すること自体が不快なものである、と感じたことです。話し相手が聞きたいことを言ってしまった結果、コミットメント言語ではない言い方を使ってしまう傾向があると気付いたので、今ではコミットメント言語を使うよう心がけています。コミットメント言語を習得することの不快さは、6.6節「どうやって取り組みに彼らを乗せるか」、8章「自己組織化を促進させるためにクリアリングミーティングを行う」を読んで感じました。チームでコミットメント言語を習得するためには、自分がお手本になってコミットメント言語を使うことや、相手がコミットメント言語でない言い方をした場合は言葉を直していくことが必要になると述べられています。これはやる側にとっても、やられる側にとっても不快な取り組みであると感じますが、新しいことを学び、安全地帯から出る時には不快になることは必要であると述べられています。何かを学ぶ際には不快になることを避けるべきではない、ということが、5章~8章での主要なメッセージであると読んでいて感じました。

感想

まず本の内容については、具体的な手法については応用できそうだと思えた一方で、この本ではリーダーに対して極めて高い技術力とコミュニケーション力、飽くなき向上心を求めていると感じたので、「こんなに凄いリーダーになるのは難しい」とも感じました。しかし、本の内容で同意できるところはいくつもありましたし、良いチームを作るためにリーダーがどう動くべきかを理解して、さらにリーダーを補佐できるチームメンバーになるためには、リーダーシップについての知識は必要だと感じました。実際に目の前の問題をどう解決するか?チームでどのように振る舞っていくか?については、読書会の他の参加者や先輩と議論しつつ、チームを良い方向に導いていけたらと思います。

読書会としては、新卒メンバーが書いた本の感想に対して @igaiga555 さんからさらに考えの深まるコメントを返していただくなど、和やかながら学びのある時間でした。議論が盛り上がる一幕もあり、特に評価制度について、「学習に時間を使えるようになるためには、評価制度に工夫が必要なのではないか」という観点で話が盛り上がりました。

読書会を通して学んだ、”コミットメント言語” を使うといった点を普段のチーム開発で心がけたところ、「できないことをできないとしっかり言ってくれるから仕事がしやすかった」とディレクターの方からフィードバック頂きました。今後も読書会への参加や、本を読むことは継続しつつ、得た知識を仕事で使っていくことも欠かさず取り組みます。

iOSDC2021でアンケートを取らせて頂いたので結果を公開します!

はじめに

こんにちは!

Classi 株式会社でiOSエンジニアをしている横田です。

先日開催されたiOSDC2021、弊社もスポンサーとして協賛させて頂きました。
当日はメンバー数名も参加してセッションを見て、リアルタイムチャットで感想を共有したり補足し合ったりして、とてもよい時間を過ごすことができました。

今年は2度目のオンライン開催で、運営もパワーアップしとてもスムーズに進行されていて、気持ちよくセッションを見ることが出来ました。運営のみなさまに感謝です!

来年以降はオフラインでの開催になるかもしれませんが、並行してオンラインでの開催もぜひお願いしたいところです。
というのも個人的には、沖縄県出身ということもあり、地方からの参加は旅費交通費のハードルが高いので、地方のエンジニアのためにもぜひご検討頂きたいです。

ただ、運用も例年以上に大変になってしまうと思うので、来年と言わず、将来的に実現してもらえれば嬉しいですね。

今年のiOSDC2021のセッションの内容も非常に有用なセッションが多かったのですが、個人的に印象に残ったのは、リファクタリングやサービスクローズの話、SwiftUIやGraphQLの話です。

iOSDC2021でのアンケートの結果について

弊社は、去年のiOSDC2020からスポンサーとして協賛させて頂いておりますが、今回、参加者のみなさまに向けてアンケートを取らせて頂きました。

参加されたみなさまには運営を通じてメールをお送りさせて頂きましたが、その中に弊社からのアンケートが含まれていますので、まだの方は今からでも遅くないのでぜひご回答頂けると嬉しいです。

既にアンケートにご回答頂いたみなさまについては、ご協力頂き本当にありがとうございました!

アンケートを取らせて頂いた目的としては、さまざまな会社や開発者からの運用の知見を集めて、まとめ記事のような形でご紹介することが出来れば、iOSのコミュニティなどに有益で面白そうな記事になるかなという狙いがありました。

その意味でこのアンケートの回答期限は設けておりません。いつでも構いませんので、ぜひアンケートにご協力いただければと思います。

アンケートはこちら forms.gle

アンケートの結果は以下のような興味深いものになりました。
※複数回答のパーセンテージは、回答者数に対するパーセンテージになります。

f:id:apla:20211115212508p:plain

5人以下の人数が半数以上という結果が出ました。

f:id:apla:20211115211956p:plain

GitHubが一番多いという結果になりました。コードレビューがしやすいからでしょうか?
その他の回答の中には、Google DocsやNotionといったツールを使っているという回答もありました。

f:id:apla:20211115212307p:plain

モックサーバーが簡単に立てられるからでしょうか、Swaggerが多いという結果になりました。
その他の回答の中には、GraphQLを使っているという回答もありました。

f:id:apla:20211115212310p:plain

Figmaが多いですね。
デザインツールに関連がある記事を見ていると、最近はFigmaを採用してるところがよく見受けられるのですが、思った以上に勢いがあるなと感じました。
その他の中にはZeplinも多く、中には手書きという回答もありました。

f:id:apla:20211115212313p:plain

ほとんどの回答者がコード品質を高める方法としてSwiftLintを利用しているという回答でした。Dangerも半数いるので、どのように運用されているか参考にしたいところです。

f:id:apla:20211115212316p:plain

テスト用アプリの配信・テスト実行・AppStoreへのアップロードでCIを活用しているという回答が多いですね。AppStoreの掲載情報更新は、弊社も取り入れたいところではあります。

f:id:apla:20211115212320p:plain

意外と定期リリースは行っていないところが多いですね。

f:id:apla:20211115212323p:plain

弊社だと学校単位での導入となるのでアプリのインストール数はコントロールできません。
そのため監視するデータとしてあまり見ることはないのですが、アンケート結果を見るとアプリのインストールを監視するというところは多いですね。
また、AppStoreのレビューは弊社だと非常にたくさんのコメントを頂いていますが、その中でもサービス利用に関する重要なレビューがないかどうかを監視しています。

f:id:apla:20211115212326p:plain

開発者がQAも行うところが多いですね。QA部門がない会社が多いのかなと推測できそうです。
その他の中には「開発者がおおよそのテスト仕様書を作成し、それに基づいて企画チームがQAを行う」といった意見も見られました。

アンケートの最後に「クオリティの高いモバイルアプリを安定して提供し続けるために開発チームに必要だと思われることがあれば教えてください」という質問をさせて頂きました。

この質問の回答には、以下のようにご意見も頂きました。

  • 自動テストを増やしていくことと、テストがちゃんとパスすること、壊れたらすぐに直すをキープし続けること
  • チーム内のフラットな関係性、PO, エンジニアのデザイン理解度
  • リファクタリング可能な状態を保つこと、コミュニケーションをとりやすい組織になるように努力すること

この質問に対して頂いたご意見をまとめてみると、以下を備えているチームならクオリティの高いiOSアプリを安定して提供できるのではないか?と感じました。

  • コミュニケーション
    意識や意思の統一や設計などの共通認識を揃えること
  • 技術力や人材
    ユーザーへの価値提供を実現できる技術力や、価値を届けるための自己研鑽を続けることができる人材
  • ユーザーファースト
    プロダクトがユーザーを幸せにするかどうかを基準にする

iOSDC2021でのアンケートの結果をうけて

今回のiOSDC2021でアンケートを取らせて頂いたのですが、いろいろと弊社の運用改善にも活かせそうなものも多く、あらためてご回答頂いたみなさまには感謝です。

今回、iOSDC2021でのアンケートの結果を受けて、開発者ですぐに導入できそうなものとしてまずはDangerの導入を検討しようと思っています。

理由としては、社内でもコードレビューの質を高めて品質向上を計る取り組みが検討されているので、より効率よくレビューが行えるように機械的な指摘はなるべくDangerに任せたいと思ったからです。

例えば、レビューの際のルールに以下のようなルールがあります。

  • PRの説明文にチケットへのリンクを貼る
  • 1つのPRに対して変更が多いときは、なるべくPRを分ける

これらに対する指摘は、機械的にDangerで指摘できればよさそうです。

もちろん、Danger のみでコードレビューにおけるすべての問題を解決することはできません。
機械的に判断できる点をDangerにてチェックし、人間の目が必要な観点にフォーカスしてメンバーでコードレビューを行う。それによりコードレビューの質が上がり、ひいてはコード自体の質が上がることを期待し、検証を続けてまいります。

まとめ

今年のiOSDC2021は参加者のみなさまからアンケートを取らせて頂けたこともあり、個人的にも会社的にも、よい学びがありました。
今後は、iOSDC2021で学んだことや得た知識をもって、Classiのアプリの運用に活用させて頂だくことはもちろん、iOSのコミュニティなどへも貢献できるような活動ができればと考えています。

Python Conference JP 2021で登壇してきました!!

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

今回は、PyCon JP 2021で登壇してきましたのでそちらの登壇ブログになります。 いままで一人で世界中のPyConで毎年登壇してきました。今年は、三年目になります。

いままでの登壇歴

PyCon US 2019 at US(オフライン開催) Lighting Talk:"How to Transform Research Oriented Code into Machine Learning APIs w/ Python"

PyCon TW 2019 at Taiwan(オフライン開催) Talk: "How to Transform Research Oriented Code into Machine Learning APIs with Python"

PyCon JP 2019 at Japan(オフライン開催) Poster: "Hybrid Keyword Extraction Automated by Python With Cloud Speech To Text API and Video API"

PyCon HK 2020 at 香港(オンライン開催) Talk: "How to Transform Research Oriented Code into Machine Learning APIs w/ Python"

PyCon JP 2020 at 日本(オンライン開催) Talk: "How to Transform Research Oriented Code into Machine Learning APIs with Python"

PyCon Taiwan 2020 at 台湾(オンラインとオフライン開催) Tutorial: "How to develop ML APIs with Python from Online Learning Dataset"

PyCon APAC 2020 at アジア太平洋(オンライン開催) Panel Discussion: "ML/DL on Edge Computing"

PyData Global 2020 at 世界(オンライン開催) Talk: "Transformation from Research Oriented Code into Machine Learning APIs with Python"


また、Classiは去年に引き続き、今年もシルバースポンサーをしています!

さらに、データAI部にPythonエンジニアが一人増え、今年からやっと一緒に参加してくれる仲間が増えたので、記事を書いていきます。

今回の発表内容について工藤さんの初参加レポートを当記事に書いていきます。

発表内容

今年、発表したタイトルは、"Flask 2.0 vs FastAPI in REST API developments" です。

FlaskとFastAPIは、Pythonのマイクロフレームワークを選ぶ際に、よく選択肢として上がってくるマイクロフレームワークのうちの2つになります。

この2つを比較するのは、人によっては挑発的なタイトルだと思わせてしまうかもしれません。

Flaskが良いという内容であれば、FastAPIユーザを攻撃することに、FastAPIが良いという内容になれば、Flaskユーザを攻撃することなりかねない内容です。

ただ、結論から言うと、両方ともいいとこがありますよ、という内容です。 内容が全て英語なので、日本語で軽く補足していきます。

f:id:JesseTetsuya:20211102132947p:plain

JetBrains社の調査結果によると、PythonフレームワークのなかでFlaskが一番人気のようです。

f:id:JesseTetsuya:20211102133032p:plain

下記、4つのクライテリアを設定して、それぞれの軸で評価していきます。

  1. フレームワークの機能性や拡張性
  2. パフォーマンス(スピードと安定性)
  3. REST API設計の柔軟性
  4. 学習コスト

ここで、Flask 2.0としているのは、今年の5月にメジャーversion upがあり、大きく変更点がありましたので、比較するFlask のversionを2.0としています。詳細は、こちらのClassi開発者ブログ記事のFlask 2.0.xのアップデート項目紹介をご覧ください。

f:id:JesseTetsuya:20211102133046p:plain

フレームワークの機能性や拡張性という点において、FlaskもFastAPIでの大きさ差分はなく、あるとしたらFlaskのApplication ContextとRequest Contextの実装は、ユニークなのではないか、また、拡張性においてFlaskの方が多くの拡張モジュールがあるという意味で、Flaskのほうが多少フレームワークの機能性や拡張性があるという結論にしました。

f:id:JesseTetsuya:20211102133057p:plain

パフォーマンス(スピードと安定性) については、私が軽く実施した負荷試験や他の性能計測サイトでの確認によるとFastAPIの方が良いという結論です。これは、アーキテクチャや負荷試験の仕方によって異なってくる場合があります。負荷試験をどのコードをつかって、どう実施したかについては、スライドの中身を御覧ください。

REST API設計の柔軟性は、ディレクトリ構成の柔軟性という意味です。FlaskもFastAPIも似たようなディレクトリ構成が可能なので、どちらが良いかという判断はできない、と結論になりました。

f:id:JesseTetsuya:20211102133117p:plain

ここで学習コストをはかる指標として、書き方の難しさ書き方を知りやすいかという指標をおきました。

書き方の難しさの点において、両方とも簡潔な書き方ができるフレームワークです。また、Flask2.0とFastAPIの間では、書き方に殆ど差分がないと言ってもいいでしょう。

書き方の知りやすさに関しては、Flaskが2010年に作られ、FastAPIが2018年に作られたということもあり、Flaskの方が学習リソースは多いです。

そのため、Flaskの方が学びやすいだろうと結論づけました。

f:id:JesseTetsuya:20211102133300p:plain

総評として、Flaskの方が少し強みがあるのかなという結論になりました。これは、FastAPIの歴史がまだ浅いのが影響しているかと思います。

また、FastAPIは、未だにPEPになっていないASGI準拠のフレームワークです。

PythonコミュニティでのコンセンサスがとれているPEPにあるか否かは、Pythonコミュニティでの認知度や信頼度、開発スピードにも影響しているかと思います。

また、近年の技術進化の早さにより、どれだけ早くキャッチアップできるかキャッチアップしやすいか、という観点が技術選択において、大事です。

フレームワークの機能性や拡張性は、パッケージをインストールするか、モジュールを実装すれば済む話ですし、パフォーマンス(スピードと安定性)は、フレームワーク以外の部分、例えば、CPythonでかいたり、ロードバランサーを置くなり、インスタンスサイズをあげるなどの部分で補うことができます。

そのため、上記4つのクライテリアの中では、学習コストが一番大事な要素になると思います。

f:id:JesseTetsuya:20211102133234p:plain

最後にFlaskとFastAPIへの今後の期待を込めてのスライドを追加しました。FlaskとFastAPIの日本語でかかれた学習リソースが未だに少ないです。

学習リソースの量が増えれば、とくに書籍が増えると、学習者が増え、コミュニティのサイズも大きくなっていくと思います。

とは言いつつ、自分からアクションをしていかないと気がすみません。

そこで、来年度、Flaskについての書籍を出版します!楽しみにしていてください!

今回の発表や当記事をきっかけにFlaskとFastAPIへの興味を持っていただき、学習者が増え、みんなで学び合いができたら良いなと思っています。

PyCon JP 2021に初参加したミニレポート(工藤さん)

こんにちは、データAI部でPythonエンジニアをしている工藤( id: irisu-inwl )です。

今回はPyCon JP 2021に初めて参加したので、個人的に興味深かった講演について紹介します!

Vertex Pipelines ではじめるサーバーレス機械学習パイプライン

Sugiyama Asei さんの Google Cloud の Vertex Pipeline を使った機械学習パイプライン構築についての講演です。 公演詳細リンク

Vertex Pipelines は Kubeflow Pipelines SDK, TensorFlow Extended を利用したパイプライン実行できる ML パイプラインサービスです。

元々、Google Cloud には AI Platform Pipeline というKubeflow Pipelinesのマネージドサービスがありましたが、Vertex AI という AI Platform が GA となり、サーバーレスな MLパイプラインサービスとして Vertex Pipeline がリリースされました。

発表で下記のことを知ることができました。

  • fullstack Kubeflowと比較して、Vertex Pipelines の良いところとして、管理が楽 (Data Scientist には k8s を管理しながらは辛い)

  • 実際に弊社でもアプリケーション基盤として GKE の standard mode を運用していますが、バージョン管理戦略や、ノードの管理、スケーリングの設定など、諸々を考えなくては運用が難しいので、運用負荷が高いことは容易に想像ができました。

  • Kubeflow Pipelines を使った パイプライン構築の例

  • コンポーネント実行順序のプラクティス

  • Kubeflow上での GPU 利用などの計算リソースを設定する方法

弊社のデータAI部でも Vertex AI の様々な機能を MLプロダクト開発に活用していこうと考えているので、非常に参考となりました。

実装で知るasyncio -イベントループの正体とは-

REI SUYAMAさんのasyncioの生成処理部分を解説した講演です。 公演詳細リンク

こちらの講演に興味を持った理由は以下です。

  • データAI部で平田さんが FastAPI と Flask の性能比較などしていることもあり、asyncio は FastAPI を使っていく上で、理解を避けて通れません。

  • データAI部の勉強会で CPython Internals の Multiprocessing の章を読んでいたので、内部実装が気になったためです。

講演では、asyncio の具体的な処理の解説と、理解する上で必要な CPython の coroutine について解説されてます。

まず、generator の特徴を解説し、その次にcoroutine と generator の類似について説明することで coroutine を説明するアプローチがされてました。特にバイトコードでの処理の比較があったのは非常に理解しやすかったです。

Pythonでのコードの例と、実際に asyncio の内部挙動をシークエンス図として示しており、 EventLoop が Task を作ってから send で実行し、Future に結果を格納するまでの流れが詳細に分かりました。

参加してみた所感

今回、PyCon JP に初めて参加しましたが、最近の動向を知ることや、様々な Python Engineer の方の知見を得るいい機会となりました。

PyCon JP の会自体が円滑に運営されており、discordのチャットやボイスチャンネルの雰囲気も良く、楽しく参加することができました。

今回はオンラインでの参加となりましたが、是非今後はオンサイトでの参加や、スピーカーとしての登壇をしていきたいと思っております!


最後に、Pythonエンジニアの募集を引き続き行っています。

下記URLを確認していただきカジュアル面談の応募お待ちしています!

hrmos.co

インターン体験記

こんにちは。滋賀大学大学院データサイエンス研究科の白瀧 豪(しらたき ごう)です。 この度2021年9、10月の2ヶ月間、データサイエンティストのインターン生としてjoinさせていただきました。 このインターン期間の振り返りと学びなど書いていこうと思います。

インターン参加の背景

今回のインターンは、来年度の新卒入社に向けての準備という位置付けにあります。 そのため私はClassiという会社の雰囲気・業務の流れなど、自分がClassiで働くことのイメージをする機会と捉えて参加しました。

主な業務内容

私が所属した部署はデータAI部で、チームはコミュニケーションチーム(校内グループ・アンケート・コンテンツボックス・欠席連絡などのコミュニケーション機能を担当しているチーム)でした。

インターン期間には主に以下の3つの業務を行いました。

  • データAI部が関わっているプロジェクトのキャッチアップ
  • コミュニケーションチームでのダッシュボード作成タスク
  • Classiのデータを用いた探索的データ分析*1

最終週には、「Classiのデータを用いた探索的データ分析」の結果を中心にインターン期間の成果発表を行いました。

探索的データ分析を通しての学び

Classiのデータを用いた探索的データ分析を進めていく中で学びを

  • テーマ設定
  • 仮説の設計
  • 発表後のフィードバック

の3つの段階に分けて書いていきます。

テーマ設定

Classiのデータを用いた探索的データ分析がこのインターン期間でのメインのタスクでした。 このタスクはテーマ設定などもなく、自由に分析してほしいとのことでした。 これまで私が経験した過去のインターンやデータ分析コンペでは、テーマやデータが与えられた状態からスタートでした。 そのため、何から手をつけたら良いのかわからず戸惑いました。しかしそれと同時に分析テーマを見つけるのが最も大事な仕事ということにも気付きました。

そこでまずは、サービスの理解・過去行っている分析内容・自分の興味はどこかを整理しました。 最終的には、

  • 最も使われている機能は校内グループであること
  • 先生ごとに活用レベルが大きく違うこと
  • 入社の志望動機である「学校の先生をサポートしたい」だったこと

この3つを組み合わせて「校内グループにおける先生の活用レベルでの違いに関する分析」をテーマとして設定して分析を進めました。 (ここまでに1ヶ月ほどかかってしまった…)

f:id:ClassiJP:20211101162154p:plain

仮説の設計

テーマ設定ができたので、探索的にデータ分析をするといろんな傾向が見えてきました。 しかし仮説を設定していなかったため、背景や目的がわからず、分析結果に対しても「へぇー」という感想にしかなりませんでした。 ここで仮説を立てて、その仮説を検証することの重要性に気付きました。

仮説ベースで分析を進めることができたかというと、あまり実現できなかったかなという印象です。 知識としては知っていたり、頭でわかっていてもそれを実行することの難しさを痛感しました。 この部分が自分の今後の課題かなと感じました。

発表後のフィードバック

私の成果発表に35名ほどの方に参加していただきました。(たくさんの方が参加してくれてびっくりしました…笑) 発表後にデータAI部以外にもいろんな部の方から質問・コメントをいただきました。

ユーザーストーリーをもう少し考えることができれば、より良い分析ができたのかなという気づきができました。 その他にも、資料の作成方法・テクニックや伝え方などの基本的なところから丁寧にアドバイスをいただけて大きな学びになりました。 これらのフィードバックを整理していく中で、入社後に挑戦してみたいことがいくつか思いついたのでとても良い経験・機会になったと思います。

全体を通して感じたこと

インターン期間の最初にClassiのサービスを実際に触ってみました。そこで、サービスの機能についてや使い方について疑問に思ったことをドキュメントにまとめたところ、とても反響が大きく驚きました。

f:id:ClassiJP:20211101162251p:plain

「Classiのサービスをずっと触っていると気付けないから参考になる」や「実際に使い始めた先生は同じことを感じるはずだ」というコメントをしていただいて、吸収する雰囲気が社内全体にありました。 こういう雰囲気が発言しやすい環境に繋がっているのかな、と強く感じましたし、ClassiのValueにもなっているUnlearn & LearnやLove Diffenreceとはこういうことでもあるのかなと思いました。

さいごに

このインターンを通してClassiについて知ることができ、自分がClassiで働くことのイメージをつけることができた良い機会になりました。 それもメンターの方をはじめ、データAI部やコミュニケーションチームのメンバーのサポートがあったおかげだと思います。 本当に感謝しています。

これから大学院の研究に戻りますが、 研究を進める中でデータサイエンスの専門的な知識やドキュメント力などレベルアップして来年4月にClassiに戻って来たいと思います。

*1:探索的データ分析(EDA:Exploratory Data Analysis)とは、データの特徴を探索的に分析し、構造を理解することを目的とした最初に行う作業を指す

© 2020 Classi Corp.