Classi開発者ブログ

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

Classi developers Advent Calendar 2022の振り返り

ついに今年もラストの更新となりました。開発者ブログ編集委員のid:tetsuro-itoです。

時は師走、ソフトウェアテック界隈ではおなじみとなったアドベントカレンダーの季節でした。

当社もClassi developers Advent Calendar 2022と銘打ち、24本の記事が集まりました。 今年のアドベントカレンダーを振り返る記事で締めさせていただきます。

Classi developers Advent Calendar2022

昨年も同じ方式での振り返りをしていますが、今年も同様のテイストで編集部で改めて投稿された記事を振り返り、一言ずつコメントで紹介することにしました。 もしまだご覧になっていない記事があったらぜひこの機会に読んでみてください。

振り返り

12/1 id:tetsuro-ito: 開発本部でレポートラインを整理してユニット制度を導入した話

id:ClassiJPより

開発本部が抱えていた組織課題をどのように考え変更していったか、またその効果はどうだったかについてまとめられています。

社内のslackや開発本部の全体会等でも発信してくれていたので流れは追っていましたが、こうやってまとまった状態になると色々やってたんだな〜って感じで歴史を感じました。

12/2 id:aereal: GitHub運用委員の紹介

id:kiryuanzuより

社内で行われているGitHub運用委員の活動を紹介した記事です。 今まで Web上で確認していた各種クレジットの残高状況を自動化および可視化する仕組みを作ったり、ポリシーを制定・広報することで過剰な権限を持つことを防ぎ望ましいデフォルトを用意することを進めてくださったりと様々な取り組みをしてくださっています。 今まで単純作業で情報を確認していたところから、GitHubのAPIから取得したデータをBigQueryに取り込むツールを作って効率的に可視化することによって、快適な運用へと繋がっているのがまさに技術で課題を解決していく動きそのものという感じでとても良かったです。

12/3 id:tkdn: 経年的な既存 Rails コードを前に、何からやっていくか

id:aerealより

泥臭い話ですがよくある話でもあります。小綺麗な話ばかりじゃないところが肩肘張っていなくて良いなと思います。

ちなみに僕もアプリケーションをキャッチアップする時にはリクエストテストから見ていきます。同じですね。

決して突飛であったり極めて新規性のある内容ではないのですが、それだけに「当たり前のことを当たり前にやる」ことの価値について考えさせられます。

著者の id:tkdn は粘り強いエンジニアリングをしてくれるという印象を持っているのですが、それを裏付けるような記事に思わず笑顔です。

12/4 onigra: プロジェクト及びチームに秩序をもたらすために初手やっていること

id:aerealより

図らずも似たトピックが続きました。僕もChatGPTには様々な (おもしろさにまつわる) 可能性を見出しています。

この世には「やったほうが良いこと」はそれはもう無限に等しく存在しますし、それらすべてをやれたら最高なのは間違いないのですが、それは非現実的だから現実を見て一歩ずつ良くしていこう、という内容でした。

この記事も事もなげに書いていますが秩序が失われているプロジェクト・チームは本当にしっちゃかめっちゃかなので、一歩前進させるにも苦労したりするものです。

ゆくゆくはこの記事を思い出して秩序を失う前に踏み止まれる強いチームを作っていきたいですね。

12/5 かおり🧚‍♀️ワーママエンジョイ勢 「技育祭2022秋」で登壇しました!〜年1登壇のススメ〜

id:ClassiJPより

@kaori_cho さんの技育祭2022秋登壇エントリです。 9月入社→10月に会社の名前背負って登壇のスピード感がすごい!

記事中でも記載ありましたが、社内のSlack等での他のエンジニアを巻き込んでの事前準備してる様子はパワーあふれていて印象的でした。

12/6 id-kiryuanzu: Classiセキュリティ強化への道・後編~Hardening本戦へいざ出陣編~

id:tetsuro-itoより

先月に出た前編に引き続いて、Hardeningの後半の記事でした。Hardeningの概要や実際のイベントの内容について、そしてそのイベントにどのようなことを意識して臨んだのかが書かれており、とても勉強になりました。最近ではセキュリティの意識を上げていかねばいけない状況もあるので、こうした取り組みを率先して取り組んでいるメンバーがいるのは心強いです。 あと、写真が多めに掲載されていて、沖縄の感じや本戦の状況などが視覚的にも理解しやすくてよかったです。

12/7 Yuta Endo: s3fsを使ってEC2の特定のディレクトリをS3と同期させる

id:kiryuanzuより s3fs という S3バケットを FUSE(Filesystem in Userspace)経由でサーバのファイルシステムにマウントするツールを使った時の設定や注意点についてまとめてくださりました。

s3fs を触っていく中で、 FUSE のオプションと s3fs 独自のオプションがそれぞれ存在していることや、そもそも FUSE はカーネルの機能でファイル操作をジャックするのは FUSE が提供する機能であり、そこから拡張して S3 とやりとりしているのが s3fs であるということを調べていく中で理解したという話をされており、ツールの使い方以外にも技術の仕組みについてもしっかり深掘りされていたのが印象的な記事でした。FUSE がどういうツールなのか含めて学ぶことのできて興味深かったです。

筆者の id:ut61z さんはSRE留学という社内制度で基盤インフラチームに在籍しており、インフラ周りの経験をガンガン積んでいます。今後もインフラ系で良いネタの記事を持ち込んでいただけたら幸いです!

12/8 id:lowput: 【入門】ElectronをTypeScriptで手軽に試したい

id:tkdnより

デスクトップアプリになっている Slack や Teams などは実は Electron 製ですが、実際に起動するまで何が必要か基礎的なことをまとめている記事でした。Content Security Policy や Web フロントエンドのビルドなどデスクトップアプリとはいえど、Web 開発スタートのエッセンスが詰まっているなと記事を読んで感じました。lowput さん、Slack でも TypeScript 勉強会をチームでやりたいので TypeScript 実践のためのおすすめリンク教えてほしい、などキャッチアップや率先した活動をお見かけしています。次回はぜひ開発者ブログへのアウトプットを期待しています!

12/9 白瀧豪: 学校現場で、プロトタイプを使ったロジック検証をしてきました!

id:tkdnより

普段の業務において私は白瀧さんと近しいようで遠いお隣さんのようなポジションで仕事をしていたので、Slack での投稿やプロジェクトの近況を知るくらいで断片的にしか情報を得ていませんでしたが、今回の記事でプロトタイプの実装や学校へ持っていきユーザーインタビューする中で PoC を着実に形にしていく過程が分かってようやく点が線になりました。学校検証という 顧客を含めたいろんな方を巻き込んでの成功体験が伝わってくる、非常に良い記事でしたね。

12/10 id:kudoa: 新卒がAngularのアップデート対応から経験したこと

id:tkdnより

わたし自身 daichi さんと同じ領域のお隣さんチームかつフロントエンドを得意としていることもあり、進め方の相談を受けたり壁打ち相手をしたり場面が多く最後の振り返りまで参加させてもらいました。Angular アップデートだけではなく、最近は断捨離活動や他のメンバーも巻き込んだ改善やプロダクトグロースにもアジリティ高く動いてるのを目にして、記事中の経験が生きているのかもしれないと感じています。

12/11 Kanako 入社前後で感じたClassi QAチーム

id:tkdnより

記事中でも触れていますが、QA チームがすごいとわたしも Classi に入って感じるところです。まだまだユニットテストだけでは担保できていないチームもあるなかで QA チームの手厚いサポートによって安心してリリースできる場面が少なくありません。身を任せられるだけではなく記事中にあるナレッジ共有のおかげでドメインに対する知識の豊富さも心強く感じます。来年 Classi QA チームが JaSST’23 Tokyo で登壇するのは本当に楽しみですね。

12/12 id-kazumeat:detail: 研修担当として、リモートネイティブから学んだワークスタイル

id:tetsuro-itoより

今年の新卒研修を担当してくれた中島さんの記事です。リモートワーク環境における研修の実施の難しさや、その中での気づきを等身大に語ってくれていて、他の組織でも同様の担当をしている方などの意見を聞いてみたくなる記事でした。その研修を経て、新卒メンバーからみた観点の記事もあり、色々な伏線回収になりました。

12/13 id:youichiro ogawa:detail: SageMakerで機械学習パイプラインを実行する

id:ClassiJPより

機械学習何もわからないので完全に知らない世界すぎてめちゃめちゃ興味深く読みました。 サンプルコード丁寧に書いてくれてるので年末年始にコピペして触ってみようと思います!

12/14 id:ClassiJP: 開発者ブログ記事のレビューの仕方をご紹介します

id:aerealより

私も参加している編集部のレビュープロセスについての紹介です。

編集部のメンバーが増えてレビュープロセスが安定して回せているのも、こうした観点を共有できているからに他なりません。

会社の名前を出しているので下手なものを出さないために……というのももちろんありますが、執筆者がせっかく意欲をもって書いてくれるのだから良いものにしようという意識でレビューしています。

12/15 @nomizooone: いそのー!クリスマスだしセキュリティで遊ぼうぜ!|やわらかセキュリティ

id:ClassiJPより

弊社の誇るセキュリティ芸人 @nomizooone さんがセキュリティ学習ができる教材を紹介してくれてます。

紹介されている2つのサイトどちらもホリデーシーズンっぽいテイストだったり、記事中に豊富に貼られた画像がとても楽しそうだったりして、年末年始の空いた時間にでも触ってみようかなという気分にさせてくれてとてもよいです。

冒頭で触れられていた弊社の脆弱性対応をどうやってるかの真面目な話の執筆もお待ちしております!

12/16 すずまさ: 新卒エンジニアが配属されてから学んだチーム開発との向き合い方

id:tetsuro-itoより

今年入社した新卒が配属された後で、チーム開発にどのように向き合ったかを赤裸々に書いてくれた記事です。 どのようなスタンスで仕事をしていくか、新卒なのにここまで言語化できていて、すごいなと感心しました。チーム開発がどこかうまくいってないなと悩んでいる人には気づきを与えられる内容だと思うので、そうした方に読んでもらいたいですね。

12/17 id:ic_lifewood: appwrite で始める Angular 開発の紹介

id:kiryuanzuより

Classi のフロントエンド方面でバリバリ活躍されている id:lifewood さんの個人ブログの記事です。appwrite という Baas(Backend as a Service)プラットフォームを用いて Angular開発を行う上での tips を紹介しています。 データベースや認証機能をシュッと作ることができたり、Webアプリケーション以外にもモバイルアプリの環境も触ることができたりと、色々試せそうなプラットフォームで面白そうです。

12/18 id-soudai1025:detail: MySQLからPostgreSQLに移行する際のTips

id:tetsuro-itoより

DBといえば、そーだいさん。そーだいさんといえばDBというイメージ通りにMySQLからPostgreSQLにデータを移行する際の注意点を書いていただきました。両者は互換性がないので、色々とハマりポイントが多そうなことも、この記事からわかりました。 最終的にこの移行自体はそんなに進めていないけれども、もしそういう方がいるならこうした方がいいよというそーだいさんのおせっかい優しさを感じるまとめでした。 急遽欠番となってしまった日に記事を提供していただき、編集部としても感謝です。

12/19 廣田正之: 学習コンテンツ制作効率化の取り組み [Side DS]

id:ClassiJPより

来年度リリースの新プロダクト「学習トレーニング」に向け、質の高い学習コンテンツのスムーズな制作のためにデータサイエンティンストとしての知見をどう活かしているかが紹介記事でした。

完全に一読者の感想ですが、個人的に学習コンテンツ作成等は人間がウンウン考えながら作るイメージがいまだにあるので、自動作問のために何を考えどのように実現しようとしているかのプロセスが見えてとてもおもしろかったです。

12/20 陳巍: Build an IoT-based Temperature Monitoring System

id:tetsuro-itoより

普段、バックエンドエンジニアとしてRailsを書いている陳さんがプライベートでIoTの温度モニタリングのシステムを作った記事です。全文英語で書かれているので、そうした記事を読みたい人におすすめです。 通信プロトコルにMQTTを採用した話やラズパイの実装の話など、普段はあまり接しない話題で、とても勉強になりました。

12/21 id:irisuinwl: ソフトウェア開発の共通言語をチームで持つために「Googleのソフトウェアエンジニアリング」勉強会をしました

id:aerealより

私も参加した勉強会の報告記事です。記事中で触れられているように今年の新卒メンバー (ジュニア) からキャリアを積んだシニアまで幅広いメンバーで臨んだおかげでとても豊かな示唆を得られました。

ジュニアメンバーが「この前勉強会で出てきたことと同じ失敗をしてしまった! 次はこういう風に変えたい」というような感想を持っているのを見て将来は明るいなあと感じたことを思い出します。

12/22 インディ: ミニアプリからはじめる新規プロジェクト開発

id:kiryuanzuより 新規プロジェクトを始めるにあたって動作検証用のミニアプリを作って開発を進めた記事です。 執筆者の id:indiamela さんとは同じチームで仕事をしていて、私も実際にこのブログで出てきたミニアプリにお世話になりました。記事で説明されていますが、このように素早く作って検証することで、やってみたい動作のテストやデザインの反映などがスムーズになりとても効率的な動き方になっていると思います。 今やっている開発についてまだまだ書きたいことがあるとのことなので、次の新作記事も楽しみにしています。

12/23 原田紘子: tetoruが2022年度グッドデザイン賞を受賞するために意識したこと

id:kiryuanzuより

Classi が小中学校向けに展開している保護者連絡サービスの「tetoru」が今年のグッドデザイン賞を受賞した際の過程を紹介した記事です。 グッドデザイン賞に関してはよくSNSで目にしますが、審査において求められている4つの視点や審査の進め方に関してはは知らなかったのでとても興味深かったです。記事中でも述べられていますが、リリースされる前からグッドデザイン賞に受賞できるサービスになったらいいなという想いを密かに抱かれていたとのことで、実際に夢を叶えているのがとてもアツいエピソードだと感じました。

12/24 中村さやか: Figmaで幸せなデザイン管理

id:tetsuro-itoより

tetoruでデザイナーをしているさーさんの記事です。新規事業であるtetoruのデザイン管理をXDからFigmaに移行する時のTipsを紹介してくれています。導入部分のストーリーテイストも読みやすくてさすがだなぁと感じました。 エンジニアもディレクトリ構成などを議論するのと同様にデザイナーもこうしたデザイン管理をどのように行うとよいのかきちんと考えられているのだなととても参考になりました。

おわりに

今年も無事にアドベントカレンダーを完走することができました。投稿してくれた社内のメンバー、そして読んでくれた読者の方々、ありがとうございました。

今年の記事は開発者ブログに寄稿してくれるメンバーが多く、編集部もレビュー対応にてんやわんやな状態になりました。 しかし、その甲斐もあって、良い記事が今年はたくさん出てきたと思いますし、普段は業務で絡みがないメンバーの記事を読むと、その人たちのチームの状況や関心ごとがわかるので、とても良いなと感じました。

アウトプットを継続して行うことの大事さというのは、皆理解していることと思いますが、こうしたイベントによって少し密度や強度を持った発信の機会は今後もうまく使っていきたいと思います。来年のClassi開発者ブログにもご期待ください。 それではみなさま良いお年を!

tetoruが2022年度グッドデザイン賞を受賞するために意識したこと

この記事はClassi developers Advent Calendar 2022の23日目の記事です。

UXデザイナーの原田です。小中学校向けに展開している保護者連絡サービスの「tetoru」を担当しています。tetoruは2022年度グッドデザイン賞を受賞いたしました!

www.g-mark.org

初めての挑戦で受賞することができ、とても嬉しく感慨深かったため、今回は受賞に至るまでに意識したことを審査過程を絡めてご紹介いたします。

🏆グッドデザイン賞とは

まずは簡単にグッドデザイン賞の説明をします。 といっても公式サイトでは丁寧に説明されてますのでこちらのページをご覧ください。

www.g-mark.org

グッドデザイン賞は、製品、建築、ソフトウェア、システム、サービスなど、私たちを取りまくさまざまなものごとに贈られます。かたちのある無しにかかわらず、人が何らかの理想や目的を果たすために築いたものごとをデザインととらえ、その質を評価・顕彰しています。 さらに、複雑化する社会において、課題の解決や新たなテーマの発見にデザインが必要とされ、デザインへの期待が高まっています。グッドデザイン賞は、審査と多様なプロモーションを通じて、デザインに可能性を見出す人びとを支援し、デザインにできること・デザインが生かされる領域を広げ、私たちひとりひとりが豊かに、創造的に生きられる社会をめざしています。

グッドデザイン賞というとどうしても「見た目の美しさ」が問われるイメージがありますが、実は以下の4つの視点が重要です。

  • 人間的視点
  • 産業的視点
  • 社会的視点
  • 時間的視点

グッドデザイン賞の審査基準
グッドデザイン賞の審査基準(YouTubeより抜粋)

tetoruは学校の教職員と保護者の負担を軽減し、子どもの見守る時間と機会を向上するために生まれたサービスです。そこには上記4つの視点が十分に含まれているため、応募してみよう!ということになりました。

📝一次審査

一次審査は書類による審査です。 限られた文字数で tetoruの価値を伝えることはとても難しい作業でした。なにせ4名の審査員は全員教育業界の方ではありませんし、他にも数多くの審査を抱えています。ですので tetoruがどのようなサービスであるのか「初見で正しく伝わる」ということを念頭におきながらまとめました。

細かいテキストもチームメンバーからフィードバックを受けていました

また、審査は日英の2ヶ国語で審査されます。私自身は英語は翻訳ツールに頼っている人間なので、日本語でまとめ終わった後に、海外勤務経験のある先輩に英語の翻訳をお願いしました。当たり前ですがよくある翻訳ツールで訳された文章とは全く異なった活きた文章がそこにはあり、ひとりで尊敬してました。

🖥二次審査

二次審査は現地による現品審査です。今年は愛知国際展示場にて3日間にかけて開催されました。約90cm四方のブースを自由に使えるのですが、こういった経験は初めてなので参考になる画像をまず探して、tetoruらしいブースを模索しました。

1ヶ月かけて準備をしていましたが、この期間は毎週出社してはブースイメージと掲載内容をプロトタイプで作成しては微修正を繰り返す、そのようなことをしてました。当時の写真はこちらです。

最終の一歩手前のブースイメージ

これで当日の審査を迎えようと思ったのですが、たまたま近くを上司が通りかかったので即興で仮想審査員としてブース審査してもらいました。その際に初見の人でも伝わりやすい情報量やパネルの配置なども改めて確認することができ、印刷業者へ発注をかける直前で最後の修正。すごく良い時間になりました。

最終版は目線の移動を意識してパネルの配置を修正した

🎉無事、受賞!

さまざまな試行錯誤を経て、ありがたいことにtetoruは受賞することができました。今年の応募総数は5,715件あり、その中で受賞できたのは1,560件でした。受賞確率は約27%になるので4件に1件の割合で受賞になるのですが、応募する前は出したら全員受賞できるのではという軽い気持ちで捉えていた部分が正直ありました。でも実際に応募してみると審査ごとにtetoruについて見つめ直し改めて提供価値について棚卸しをする良い機会になりました。やれることは全てやりきったので、この結果になったと思います。

🎄さいごに

このようなプロセスを経てtetoruは受賞できたのですが、最後に開発中の出来事を紹介させてください。実はリリース前から密かに「グッドデザイン賞に受賞できるサービスになったらいいな」という想いがありました。

☆マークと一緒に「グッドデザイン賞」がマーキングされている

これは今から2年前、チームメンバーとワークショップを実施した際のひとコマです。この時のテーマは「2〜3年後に作りたい世界は?」という問いに対してtetoruの未来をメンバーが自由に想像して付箋を出し合っていました。この時のワークショップがきっかけで「いつかチャンスがあったら応募してみたい!」という意識が明確に芽生えるきっかけにもなり今回に繋がりました。少しでも思っていることは、外に出して発言してみることって大事だなと感じます。受賞できて、本当によかったです!

オフィスに飾ってもらってます!

明日は同じデザイナーのさあさんになります。アドベントカレンダーも終盤ですが引き続きお楽しみください。

adventar.org

ミニアプリからはじめる新規プロジェクト開発

この記事は Classi developers Advent Calendar 2022 の 22 日目の記事です。

こんにちは!Classiでモバイルエンジニアをしています、楠瀬大志(id:indiamela)です。
最近、とあるプロジェクトを進めるにあたって、動作検証用のミニアプリを作りました。
本稿ではiOSアプリ開発に絞り、ミニアプリからはじめる新規プロジェクト開発の進め方やメリットについて、僕が学んだことを書いていきたいと思います。

※現在進行中のプロジェクトなので詳しい技術や画面は今回紹介しません。そういった内容はまた別の記事で紹介できればと思います。

背景

今回のプロジェクトは、先の見えないことが多く、ロジックや画面設計を手探りで決めるところから始めなければいけませんでした。
そういった状況では、新しいAPIの仕様やUI/UXを検討するために、モバイルアプリ上ですぐ試して確認する必要があります。
しかし、これを現状のClassiアプリで行おうとすると、ビルドやUIの構築に時間がかかることが想定されました。
そこで、私たちは機能を検証するためのミニアプリを作り、そこで動作検証を重ねてから本体アプリに実装を載せることにしました。

ミニアプリからはじめる新規プロジェクト開発の進め方

一般的なミニアプリは、スーパーアプリを基盤として動作するアプリのことを指しますが、私たちが指すミニアプリは、新しい機能や画面の検証をするためだけに使用するアプリのことです。
ここからは、私たちがミニアプリをどのように作って、どうやって運用しているのかを説明します。

本体アプリの中からミニアプリに搭載する機能を検討

ミニアプリを作るには、まず本体アプリと同じ機能をある程度搭載する必要があります。
例えば、ホーム画面から新規の画面に遷移することを考えたいのであれば、本体アプリと同様のホーム画面を実装するといった具合です。
開発チームとデザインチームで話し合った結果、今回のプロジェクトでは本体アプリと同様のログイン画面とホーム画面を作成することになりました。

開発者以外の人も確認できるようにアプリを配信

開発者だけでなく社内の誰もが触れるようにしたいので、すぐアプリを配信できる環境を構築しました。
iOSではFastlaneとCircleCIを導入して、変更がmainブランチにマージされる度にTestFlightに配信されるようにしています。
これにより、チーム内だけでなく多くのメンバーからフィードバックを集めることができ、さらに変更をすぐ反映できます。

アプリ配信後の投稿

サポートバージョンを最新に引き上げて素早くミニアプリを開発

現在リリースされているClassiの本体アプリは、サポートバージョンが12.0以降(2022年12月時点)になっており、SwiftUI等のモダンな技術を扱うことができない環境です。
この本体アプリと同じサポートバージョンでミニアプリ開発を進めるかどうかを検討しました。
サポートバージョンを引き上げ、モダンな技術を使ってミニアプリを作ると、あとあと本体アプリに適用するのが大変になるという懸念があります。
しかし、今回の目的は「素早く作って素早く検証できるアプリを作る」ことなので、サポートバージョンを引き上げることにしました。
結果、SwiftUIやCombineを駆使して爆速で開発を進めることができました。

APIの動作確認やデザインの検討状況に合わせてどんどんアップデートする

必要最低限の機能を実装したら、APIの仕様やデザインの検討状況に合わせてどんどんアップデートしていきます。
私たちの場合、デザイナーと定期的に会議をしながら、検討中の画面デザインをどんどんミニアプリに反映していました。
また、デバッグ画面を作成して、アプリ上で簡単にAPI通信の結果を表示するようにしました。
このように、ミニアプリをどんどんアップデートすることにより、ビジネスロジックやデザインの仕様検討を効率的に進めることができています。

デザイナーからのコメント

開発して感じたメリット

本体アプリより素早くビルド・開発ができる

今回の目的通りですが、一番のメリットはClassi本体アプリより早くビルドや開発を進められる点です。
本体アプリと比較してミニアプリのビルド時間は約4分の1程度で済むので、実装スピードが飛躍的に上がりました。

思考したものをすぐ反映できる

素早く画面を構築したり壊したりできるので、チームで検討した内容をすぐ試すことができます。
通常のアプリ開発ではデザイナーがデザインをある程度決定し、その後に開発者がデザインを反映すると思います。
しかし、このミニアプリを作ったことで、デザイナーと開発者が密にコミュニケーションを取りながら、一緒に作っていけるようになりました。
ユーザーに提供したい理想のUIと、どうしたら素早く価値を提供できるかのバランスを考えるうえで、ミニアプリはとても重要な役割になりました。

デザイナーからのコメント

新しい技術の実験ができる

今回のプロジェクトだけでなく、現在運用中の本体アプリ自体にもメリットがありました。それは、新しく取り入れたい技術を実験してから導入できたことです。
例を一つ挙げると、SwiftPackageによるマルチモジュール化です。
当時、本体アプリのビルド時間を削減するため、SwiftPackageによるマルチモジュール化の導入を検討していました。
これは割と規模の大きい改修になるため、一旦ミニアプリを実験台として、マルチモジュール化を進めました。
そこで得られた知見を元に本体アプリの実装を適用することで、規模の大きめなモジュールでもスムーズに載せ替えることができました。

ミニアプリで取り入れた技術を本体アプリに適用

最後に

本稿では、ミニアプリからはじめる新規プロジェクト開発の進め方やメリットについて、私が学んだことを書いてきました。
読者の方々が今後新規開発を始めるにあたって「とりあえずミニアプリを作ってみる」という選択肢を持つことができれば幸いです。
今回はまだリリースされていない内容が含まれているため、詳しく書くことはできませんでしたが、正直もっと色々書きたいことがありました。
いつか、また別の記事で紹介できればと思います。

以上、ここまで読んでいただきありがとうございました。

明日のClassi developers Advent Calendar 2022は原田紘子さんの記事です。たのしみにしてます!

ソフトウェア開発の共通言語をチームで持つために「Googleのソフトウェアエンジニアリング」勉強会をしました

この記事はClassi developers Advent Calendar 2022の21日目の記事です。

こんにちは。データAI部 Pythonエンジニアの工藤( id:irisuinwl )です。 最近は、ポケモンSVとぼっちざろっくとDwarf Fortressにはまってます。一日48時間くらいほしいです。

さて、最近、自分が主催していた「Googleのソフトウェアエンジニアリング」勉強会を終えました。 ソフトウェアエンジニアだけでなく、データサイエンティスト、ディレクター、プロダクトマネージャーを巻き込んで行い、13人もの参加者が集まりました。

今回の記事では、「Googleのソフトウェアエンジニアリング」勉強会で得られた学びや、方法をお伝えできればと思います。

これは打ち上げの肉

続きを読む

学習コンテンツ制作効率化の取り組み [Side DS]

この記事はClassi developers Advent Calendar 2022の19日目の記事です。

みなさん、こんにちは。 データAI部でデータサイエンティストをしています廣田と申します。今回は、データサイエンティストが学習コンテンツ制作チームとタッグを組んで進めている、学習コンテンツ制作効率化の取り組みについて紹介したいと思います。

弊社の学習コンテンツは大まかに以下の2つに分類されますが、本記事では主に後者(テスト/問題)の意味で「学習コンテンツ」という表現を使います:

  • 学習動画
  • テスト/問題

現在弊社では、2023年度リリース予定の学習トレーニング(詳細は紹介動画をご覧ください) に向けて、学習コンテンツの内容の大幅な見直しを進めています。そこで、学習コンテンツ制作チームがスムーズに質の高い学習コンテンツを制作していけるように、データサイエンティストも各々の知見を活かして様々な取り組みを進めています。

本記事では下記の2点についてお話したいと思います:

  • 学習コンテンツ制作の課題
  • 学習コンテンツの質・量の担保に向けた取り組み

学習コンテンツ制作の課題

学習コンテンツが生徒に提供されるまでの大まかなフローは以下の通りです:

  • Classi
    • 企画
    • 制作
    • ユーザーへ公開
  • 先生
    • 配信

弊社の各ステップにおいて、社内では様々なメンバーが知恵を出し合い、良い学習コンテンツを提供していけるよう試行錯誤しています。中でも、実際の学習体験に直結する制作については特に慎重に検討がなされています。

デザイナー・エンジニアの検討課題の一例としては「テスト/問題の取り組みやすさを上げるにはどうすべきか」といったものがあり、

  • 問題・解説を読みやすくするための飾り文字はどの範囲まで許容するか
  • 図はどう配置しておくと取り組みやすいか

などといった点について、コンテンツ制作チームと議論を重ねています。

一方データサイエンティストは多大な作問コストと品質の担保という課題に向き合っています。全教科・学年および様々な難易度に対応できるように学習コンテンツを整備するとなると、問題であれば数万問程度は必要になり、質・量の担保は大きな課題となります。そこで、学習コンテンツの量と質を両立させるための取り組みについて紹介していきたいと思います。

学習コンテンツの質・量の担保に向けた取り組み

学習コンテンツの制作は大まかに初期案の検討・推敲の2ステップに分かれます。さらに制作対象(問題 / テスト)によってアプローチが変わってくるため、それぞれで分けて説明したいと思います。

現在進んでいる取り組みを分類すると、以下の表のようになります。「推敲」の部分の取り組みについては、現状は単なるアイデアの状態で、まだ具体的に踏み込めていません。しかし、将来的には何かしら寄与していきたいと考えています。

ステップ \ 制作対象 問題 テスト
初期案の検討
推敲 - -

①問題の初期案検討のサポート

問題の質・量を確保するには「高い品質の問題を自動生成するシステム」があれば完璧なわけですが、実現のハードルが非常に高いです。そこで現在「どのレベルまでなら十分な品質の問題の自動生成が可能か」といった点を探っています。

問題の質・量を確保しようと思った場合、素直に考えると以下の2ステップを踏むといった発想になると思います:

  • ステップ1:まずは品質の高い問題を制作
  • ステップ2:その問題を参考にしながら、同等の品質の問題を制作

ステップ1(品質の高い問題制作)については、特に教科指導・教材作成の知見が重要で、なかなか一般的なデータサイエンティストが入り込みにくい部分です。一方ステップ2(既存と同等の品質の問題制作)に関しては、データサイエンティストの知見が活かせる領域が広がっていると感じています。

非常に単純な例として「計算問題の自動生成」について紹介します。いわゆる「データサイエンスっぽさ」はありませんが、あくまで取り組みのほんの一部ということで、ご容赦ください。

下に2次関数の問題が2つありますが、こちらはプログラムで自動生成した問題となっています。中身を見ると、この2問が問題・解答・解説の数字を入れ替えただけの問題であることはすぐにわかると思います。こういった「数字を入れ替えただけ」の問題であれば、プログラムを組めば容易に大量に生成することができます。

自動生成問題の例

ちなみにこの問題を生成したプログラムでは、計算のつらさ(問題の品質の1要素)を制御するために以下のような制約を入れています:

  • 頂点の座標と軸の方程式の数値で現れるのが整数のみ
  • 元の2次関数の各係数の絶対値が大きくなりすぎない

このように、問題の品質につながる要素を制御しつつ、問題を自動生成していくことができれば、少なくとも「量」で困ることは防げます。

以前弊社では英単語の問題を自動作問する実証研究も行っていました。現在は、上で示した計算問題の例のように、英単語の問題に限らず少し広い範囲を視野に入れて自動作問の検討を進めています。

②テストの初期案検討のサポート

テスト作成の基本アイデアは「用意した大量の問題の中から問題を選んでテストを作る」というものです(足りない問題があれば追加で作成)。問題を選ぶ際には、様々な制約(出題範囲、問題数、解答時間、難易度など)を考慮する必要があります。

全教科全学年のあらゆる難易度帯に対応するには3〜4桁程度の数のテストが求められるため、それらのテストの初期案を全て人手で作るとなると、非常にコストがかかることは容易に想像できると思います。

そこで現在、テストの初期案の自動生成によって、初期案生成のコスト削減および初期案の品質の均一化を目指しています。ある程度の品質の初期案を短期間で作成できれば、その分スケジュール進行も安定しますし、推敲に余裕を持って取り組めるため、テストの品質向上も期待できます。

具体的な取り組み内容は以下の通りです:

  • テストの要件を整理
  • 組合せ最適化手法を用いてテスト初期案の自動生成
  • 推敲時に検討がしやすいフォーマットで初期案の出力

得られた初期案については、その後コンテンツ制作チーム側で推敲を行い、実際のサービスに搭載されていく予定です。

ちなみに「テストの要件整理」が一番苦労している点です。互いに干渉し合う要件(例:出題範囲を網羅したい v.s. 問題数は○○問に抑えたい)が色々とある中、どの要件を優先していくかについて日々コンテンツ制作チームと共に検討しています。

自動生成の仕組みについては、日本オペレーションズ・リサーチ学会 2022年春季研究発表会において発表させていただいた内容をご参照ください。こちらで検討していた整数計画問題と現状扱っている整数計画問題はだいぶ異なったものになっていますが、雰囲気は感じていただけるかと思います。

さいごに

今回は、学習コンテンツ制作にデータサイエンティストが首を突っ込んでみた話をお伝えしてきました。色々課題は見えてきたものの、一朝一夕で解決するようなものはほぼなく、学習コンテンツ制作の難しさを日々痛感しています。来年にはいくつか課題を解決まで持っていけると良いなぁと願いつつ、本記事の締めとさせていただきます。

明日は@willsmileさんの記事です。お楽しみに!

新卒エンジニアが配属されてから学んだチーム開発との向き合い方

こんにちは。今回Classi developers Advent Calendar 2022の16日目を担当します、すずまさです。

今年新卒入社して7月中旬まで研修を受けており、その後配属されて約5ヶ月チーム開発を続けてきました。

学生時代にも友達と作品を作ったり、エンジニアとしてバイトをしたりとチーム開発の経験はありましたが、そこでは得られなかった学びがたくさんありました。

その中でも今回は、「チーム開発との向き合い方」に絞って学びを書いていきます。

疑う姿勢を持つ

Googleのソフトウェアエンジニアリングの中に「目隠しを特定せよ」という節があります。

ある問題に初めてアプローチする際に、既にその問題と何年も戦っている人々の一団がいるのを発見することがしばしばあるだろう。そのような人々は、非常に長い間その問題に浸かっていたために「目隠し」を装着している。

この節では、無垢な人ほど目隠しの存在を発見でき、質問して改善していけると書いてあります。

私は社内勉強会でこの本を読み、チーム参加後に新卒に求められる役割のうちの一つはこれだと思い、意識していました。

しかし、わかった気になっていたものの、私は最初、この「目隠しの特定」ができていませんでした。

具体例を挙げると、下記のような部分をスルーしていました。

  • M1 Macだと環境構築が大変なリポジトリ
  • 煩雑で面倒なリリースフロー
  • 微妙な変数名やコード設計
  • アップデートされずに放置されている古いライブラリ

全てに共通しているのは、面倒だったり理解に時間かかるなとは感じつつも、そういうものかと受け入れていたことです。

例えばM1 Macの環境構築では、ドキュメントでわかりづらい部分があればその都度追記、修正等できていました。しかし、構築が面倒になっている根本原因に関しては直そうとは思わず、「M1 Macだと大変なんだな」と思うだけで終わっていました。 コードに関しても、自分がまだ経験不足ということもあり、「ちょっと違和感あるけどついこの前レビュー通ったやつだしこれでいいのだろう」と疑ってすらいませんでした。

自分が目隠しの特定ができていないなと気づいたのは、チームの体制が変わり、他チームから新しく人が入ってきてからでした。 その人が入ってきてからは、上記に挙げたものがどんどん改善されていき、それを間近で見て自分がいかにできていなかったかを痛感しました。

思うに、私には疑う姿勢が足りていませんでした。早くチーム内のルールや知識を吸収しようと躍起になった結果、既存のものに対して考えたり疑問を持つことを疎かにしてしまい、チーム内の「目隠し」も一緒に吸収していたのだと思います。

改善アクションを間近で見続けるうちに意識も変わり、最近はちょっとでも違和感を覚えたら疑問の声をあげたり、すぐに改善できそうならその場でやってしまうといった行動ができるようになってきました。

改善点をスルーしていたことはかなり反省していますが、一度やって後悔した経験はもう忘れないと思いますし、良い学びになりました。

細かい箇所でも指摘する

上述したのはそもそも疑問すら持っていなかったものでしたが、今回のは気付いていたのに声をあげられなかったケースです。

「ここちょっと気になるけど…まぁ時間かかるし大変だろうからいいか」という具合に、声を上げられなかったことがありました。

例えばPRのdescriptionです。 仕様書をしっかり読み込まないと何をやっているのかわからないものや、チーム外の人が見たら理解できなさそうな説明などを、指摘せずにそのままapproveしていました。

その時の私は、細かいところばかり指摘するのは揚げ足とりになるかと思い、言い出せずにいました。

しかし、そもそも「細かい」と思っていること自体が誤りかもしれません。指摘せずに放置することで他のメンバーにも伝播していき、悪い文化として定着してしまう可能性もあります。 「細かい」と思っている指摘でも、チームにとっては十分プラスになる素晴らしい働きなのだと、考えを改めました。

これができるようになったのは、typoを指摘しているチームメンバーを見たのがきっかけでした。 その内容は "ESLint" と "EsLint" くらいの違いでしたが、その方は「こういうものであっても正式名称で書かないことですれ違いが起きることもあるし、正式名称で書くようにする癖をつけた方がいい」と語っており、それに私も影響されました。

また、そのチームメンバーが細かいと思っていた指摘を進んでしてくれたおかげで、小さな指摘でも遠慮せずに言う文化が醸成されつつあるのを感じています。 特にPRのdescriptionに関してはそれが顕著で、「descriptionのここを直してほしい」というレビューを最近はよく見かけるようになりました。

ペアプロのやりすぎには注意

チームに入ってから一ヶ月ほど、私は入社時期が近いチームメンバーとペアプロをかなりやっていました。 丸一日ペアプロし続けることもざらにありました。

やっていた時は、ずっと喋りながら作業しているのでチームに入りたてでも孤立感が全くないですし、お互いの弱点をフォローしながら一緒に開発できて体験が良いと感じていました。

ですが、長時間ペアプロに没頭しすぎたことで失敗もありました。

ある時、面倒見のよい先輩とのミーティング中に「最近timesチャンネルの流量が減って心配していた」と言われ、そこで初めて孤立化が進んでいたことに気付きました。 (timesチャンネルとは、Slackの個人用分報チャンネルのことで、Twitterのように自由に呟ける場所です。)

同時に、下記のようなアドバイスをいただきました。

  • ペアプロは一日ずっとじゃなくてコアタイムを設けてやった方が良い
  • ペアプロは集中できるメリットはあるけど、周りの状況が見えづらくなってサイロ化しやすいから注意

確かに、周りの状況が見えづらくなるデメリットは当時も感じていました。 ずっと喋りながらやっているので、並行して何かをやる余裕がなく、必要な時以外Slackはあまり見られませんし当然他の人との会話も減っていました。

ペアプロに没頭した我々からすれば孤立を感じていなかったとしても、チームからは孤立気味になっていたのかもしれません。

報連相はやりすぎてもいい

今いるチームでは、Slackの流量が多い人がチームに加わってから劇的に会話が増えました。

下記は、その人がチームに加わる前のチームチャンネルのSlackアナリティクスです。

そして、下記がその人がチームに加わった後です。

投稿したメンバー数は減っているにも関わらず、投稿されたメッセージ数は 2,928 → 6,631 と、2倍以上増加しています。

これは、Slackの流量が多い人が加わったことにより、つられて他の人のSlackの粒度が上がったのが理由だと思います。 それまでは3行以上のまとまった文章が流れることもしばしばあったのですが、最近は短文での連投がかなり多いです。

これにより報連相がしやすくなりました。

今までは短文連投が少なかった上に、チャンネル参加者が多いこともあり、通知がうるさくないかなどを気にして纏まった文章を送りがちでした。 しかし最近は、ちょっと気になったことや雑談のような内容でも以前と比べて気軽に投稿できるようになっているのを感じます。 チームメンバーが何をやっているかの様子が前よりもくっきり見えるようになってきました。

共有事項や作業の実況、相談などが以前と比べて明らかに増えており、前よりも断然仕事がしやすくなりました。

ただそれでも、いまだに報連相が足りていないという趣旨の会話がされることがあります。 そういったことから、報連相は過剰にやるくらいの気持ちでやった方がいいなと学びました。

リモート下でのコミュニケーションについては他にも何度か記事になっています。 是非併せてご覧ください。

tech.classi.jp

tech.classi.jp

tech.classi.jp

まとめ

学びの多くに共通して思うのは、勇気が足りなかったということです。 既存のものを疑って批判するのも、細かい指摘をするのも、投稿量の少ないチャンネルでたくさん投稿するのも、どれも私にとっては少し勇気が必要なことでした。

今回振り返ってみて、文化にすぐ順応するのではなく、最初に少し勇気を出して自分から良い文化を築けるようになりたいと思いました。

ここまで読んでいただきましてありがとうございます。

Advent Calendarの次回は id:ic_lifewood さんです。

開発者ブログ記事のレビューの仕方をご紹介します

この記事はClassi developers Advent Calendar 2022の14日目の記事です。

はじめまして、Classiでエンジニアをしている(な)です。 普段は開発業務をする傍ら、このClassi開発者ブログ(以後、開発者ブログ)の編集部業務もしています。

開発者ブログについては開発者ブログ編集部編集長の id:aereal さんが記事にしていました。

tech.classi.jp

さて、筆者が日常的に行っている主な編集部業務としては以下があります:

  • 社内でいい感じのことをやってる人見つけたらスカウトして記事を書いてもらう
  • 書いてもらった文章をレビューすることでより読みやすく伝わりやすくするためのサポートをする

今回は2点目の文章のレビューについて、筆者がどういう観点で見ているかについて書こうと思います。

前置き

  • この記事で語るのは筆者個人の観点であり、開発者ブログ編集部を代表とするものではありません
  • あくまでも筆者の観点ですので基本的にお気持ちや意見だらけです。何らかのデータに基づいたテクニック等は皆無です。それらを求める人は多分ほしいものは得られないのでタブを閉じてお帰りください。ここまで読んでくれてありがとうございました!

読んだ人が内容を理解できるか

いきなりド直球ですがこれが一番大事です。

記事レビューの依頼がきたら、レビュアー目線だけでなく、最初の読者としての目線も持ちつつ読んでいきます。その時のポイントは読んだ人が内容が理解できるように書かれているかです。

基本的にブログに書かれる記事は説明文です。雄大な世界観を表現するような美文よりは、著者が説明したい内容が読者に理解されやすい文章で書かれている方がわかりやすくなります。 ですので、読者目線で読んだ上で、意図が伝わりづらい点や内容を理解のために補うといい部分、逆に冗長・不要な箇所を削る提案等々、何か気づいた点があれば指摘、提案等するようにしています。

とはいえ、内容が理解できるようにって言うけどそのためにはどんなとこ見てるの?という話もありますので以下で述べていきます。

個々のパラグラフや文の論理的関係が明確であるか

文章を構成するパラグラフ同士、パラグラフを構成する文同士、それぞれの論理的関係性が明確であること、そしてそれらが妥当なつながり方をしていることはとても大事です。論理的関係性が不明確だったり、明確であったとしても妥当なつながり方をしていないと途端に文章から内容を取るのが難しくなります。

逆にそれらが揃っていると、記事で語る内容の明瞭性が支えられ、内容を追いやすくなります。

なお、文章を書くというと「起承転結」みたいなフレーズも浮かびがちですが、物語を書くわけではないので「転」で示されるような飛躍は不要です。文章のリズムや流れを変える意味で少しくらいは転要素を入れるのもありかもしれませんが、ほどほどにしないと「さっきまで読んでた内容なんだっけ?」と読者を戻らせたり、「この記事が何を語ろうとしてるのかわからなくなってきたな?」とぼんやりした印象にさせてしまったりするので注意が必要だと思います。

過不足がない、その記事を読むだけで一通りわかるか

理解するために前提知識を必要とする文章になっていると、読むためのハードルが上がってしまい興味を持ちづらくなります。

個人ブログ等でいつも読んでくれる方向けに「このくらいは知ってるだろうからこの書き方でわかるだろう」と適度に説明を端折ったりすることはありだと思います。 ですが、記事ごとに執筆者が違う会社のブログでは各記事で扱う内容や書き方はバラバラですし、もし全部の記事を読んでくれる常連読者がいたとしても全ての記事内容の前提知識を持っていることはそうないでしょうし、むずかしそうです。

そのため、検索したりどこかに貼られたリンクを踏んできてくれた初見さんにも内容を理解してもらえるように必要な説明が随時差し込まれていると読んでもらいやすくなるのではないかと思っています。(読んでも内容がわからなそうに見えると、興味を持つ前に読まなくていいかとなることもあると思いますし)

とはいうものの冗長すぎるのもまたよくありません。余分な文章があるとそれに邪魔されて内容を追いづらくなるのもありますので論旨に必要な話だけが書かれているとよい……んですが、とはいえ、それだとストイックすぎる気もしますし、余談めいたものが差し込まれてることで読みやすくなることは一定あるのでやりすぎない程度に入っててもいいと思います。

(と書いているこの流れが正に余分なわけで、僕がレビュアだったら「このパラグラフ要ります?」とかコメントして削除提案をすると思います。今回は冗長すぎる例としてだらだらと連ねましたが当然のように他の編集部レビュー時にツッコミをもらいました)

誤った内容や根拠のないことが書かれていないか

読んでいて「これ間違ってるのでは?」とか「辻褄が合わない?」というような内容に遭遇すると、この先読む意味あるのかな?となって読む気がなくなってしまいます。

それを避けるために、語られている対象が事実であれば根拠も一緒に示せるとよいです。ドキュメントや書籍、リンク等、元にした情報の出所を付記したり、開発者向けのブログであれば自分で動作確認したコマンドやコード等を貼ることも有用でしょう。なお根拠を示す場合、引用等で完全なものを示す必要はないと筆者は思っています。あまり長く引用しすぎても読みづらくなりますし、あくまでも読者がソースをたどって事実確認ができるようになっていれば十分だと思います。

意見が意見として、またどのような意見であるかわかるように書かれているか

ブログの記事は前項で触れた事実だけではなく、意見によっても構成されます。 また意見にも、著者自身の感想のような主観的意見もあれば、事実による裏付けのある客観的意見もあります。それらが見てわかるように使い分けられていると読者は内容を追いやすくなってよいです。

ちなみにこの記事は100%主観的意見によって書かれています。

その他:細かい観点いくつか

その他、細かいけど気にしておくと読みやすさ向上に効く項目を列挙します:

  • 大文字/小文字、英字/カタカナ、漢字/平仮名、半角/全角等の表記ゆれ
  • 文末表現や、係り受け等の不揃い
  • 不適切な接続詞が使われていないか
  • 人名、サイト名、引用したエントリのタイトル、書籍名等、固有名詞の誤表記
  • 同じ文やパラグラフ内での同じフレーズ、表現が連続で出てこないか

あとこんなのもチェックしてます:

  • 外に出してはいけない社内情報が書かれていないか
    • プロジェクト等の機密など
    • 社内のメンバの名前、写真等を出したいときは事前確認がされているか
  • 著作権侵害をしてないか
    • 外部から持ってきた画像、コード等を使うときはライセンス的に問題ないか?
    • 他のサイトや本等から文章を引用するときは引用であることがわかるように書かれているか
    • 引用したURL、タイトルが間違っていないか

レビュー実例

この記事執筆時にも当然のように、他の開発者ブログ編集部メンバーのレビューを受けています。 今回のレビューをしてくれたのは Ruby onelinerで選出された id:tetsuro-itoid:kiryuanzu さんです。

以下にはお二人がこの記事のレビュー時にしてくれたコメントの一部を掲載します。 (ここまでどこにも書いてませんでしたが、弊社開発者ブログの執筆時はGoogle Docsに下書きして、そこにコメントしたりしています)

(※画像サイズ、トリミング等は開発者ブログ下書き時に調整予定)

文章表現変更の提案

雑な文章のわかりづらい点について見てくれて助かります。

見せ方についてのコメント

途中にあった「その他」の項のように箇条書きメインの方が読みやすいのではという提案。たしかに見やすくなると思いつつも作業時間の都合で反映しませんでした。

冗長な文章を削る提案コメント

冗長な文章はよくないよねって説明のところについたコメント。だらだらした文章あったら削るように指摘するよね!わかる!と思いつつも狙い通りいいコメントをしてくれたので記念撮影。

まとめ

以上になります。

レビューは毎回時間かかって大変なのですが、レビューを通じて同僚のやってることを伝わりやすくして広めるのはなかなかやりがいがあります(どこまで寄与できてるかはわかりませんが)。

今後も引き続き本ブログの裏方としてやっていきます。ここまで読んでくれてありがとうございました!

明日はセキュリティ芸人の @nomizooone さんです。お楽しみに!

© 2020 Classi Corp.