ドワンゴ教育事業ソフトウェアエンジニア採用説明資料 / for-engineers

ソフトウェアエンジニア採用説明資料株式会社ドワンゴ教育事業

未来の「当たり前」の教育をつくる Vision / Mission ほんの少し先の未来、ネットで学ぶときに「当たり前」とされるようなサービスを創るのは、私たちにしかできない。日々そう考えて企画開発しています。それは教育の「当たり前」を変えること。この前人未到の挑戦に、加わってみませんか。

教育事業について学校法人角川ドワンゴ学園が運営する「N高等学校・S高等学校」と連携し、ネット時代に合わせた教育関連のサービスを提供しています。  (写真) img

ネットの学校とは？ N高等学校・S高等学校は KADOKAWA・ドワンゴが創るネットと通信制高校の制度を活用した、新しいネットの高校です。生徒数は両校合わせて22,267名になります（2022年6月30日現在）。

N高等学校・S高等学校について 

• 2016年4月　N高開校、N予備校リリース • 2018年4月　N予備校でN高の単位認定授業を受講できるように • 2020年3月　コロナ禍をきっかけにN予備校無償提供 • 2021年4月　S高開校 • 2021年8月-11月　ホームリニューアル
• 202X年次世代N予備校へ... 歴史 

アプリケーション   • N予備校 ◦ 月額1,100円で大学受験・プログラミングなど多様なコンテンツを学び放題 ◦ NS高生は単位取得のための授業を受講 • 教務システム
◦ NS高の生徒の出願から卒業まですべての工程を管理 ◦ 個人情報、成績管理など ◦ 校務を効率よく行うために内製

教材・生授業・Q&Aをスマホにも最適化したオールインワン受験アプリスマホに最適化された教材なかまと受ける双方向生授業なかまと話し教え高め合いができる場所 N予備校  
https://www.nnn.ed.nico/pages/introduction/feature/

2021年4月からは最新のITテクノロジーを使ったVR学習機能をサポートしています。 VR空間で学び・仲間と交流。ネットの高校は、進化し続けます。

N予備校サービスと、その技術① • ←のような、「授業」「参考書」「問題集」等をコンテンツ素材として管理 ◦ 先生や問題作成者がコンテンツを作れるよう、 HTMLに独自タグやスクリプトを組み込んだ仕様を策定 • iOSアプリ(Swift)、Androidアプリ(Kotlin)、 PCブラウザ(React
+ Redux + TypeScript)でWeb コンテンツとして提供 ◦ 動画部分のみネイティブ化するなど、よりよいユーザー体験を求めて改善

N予備校サービスと、その技術② • 「問題に正答した」「章を理解した」など、学習者の進捗度をサーバ+データベースで管理 ◦ Ruby on Rails、AWS Lambda 等を利用
◦ マイクロサービスで開発効率を維持し、変化に対応 ▪ 問題、成績、Q&A、プロフィール… VR対応も ◦ Kubernetesで各サービスをインフラストラクチャに展開 • N/S高生徒は、進捗度が先生にレポートされる ◦ 先生が多数の生徒を効率良く指導できるシステムを構築

数万人に達する生徒の出願〜入学〜進級〜卒業までの管理業務や、定期テスト・スクーリングなどの活動成績管理を、なるべく少ない教職員で効率的に行えるよう自社開発。教務システム  

次世代N予備校で目指すこと ❶ • いままで ◦ NS高生がネットを活用した勉強ができて、高卒資格が取れる • これから ◦ 大多数の人にとって、(受験)
勉強とは、「できればやりたくない」「でも、やらなければいけない」ものであることを認めたうえで、学習を続けられる・したくなる仕組みを創っていく

次世代N予備校で目指すこと ❷ 生徒がモチベーションをもって、迷わず学習できる仕組みづくり • ミクロからマクロまで、各場面でのインセンティブを設計 ◦ [ミクロ] ちょっとした、一つひとつの行為を褒める ▪ 問題を少し解いてみた(正解は問わない)
▪ 何時間か授業を受けてみた(基準は生徒ごとに違う) ◦ [マクロ] ミクロの積み重ね & 学力向上 (次スライド)を褒める • 適切な科目・教材のリコメンド ◦ [ミクロ] ちょっともう一問やってみませんか? ◦ [マクロ] あなたの目標にはこの教材が良いでしょう • 適切な勉強時間の推定等々...

次世代N予備校で目指すこと ❸ 学力を定量的・効率的に測定できる仕組みづくり生徒は、 N予備校で勉強はしているが、本当に身についているのどうか、目標大学に受かるのかどうか、外部模試など受けないとわからない生徒自身がN予備校だけで、現状と目標のギャップがわかるようにする
• IRTテスト（IRT=項目反応理論を用いた学力の定量化） • アダプティブなテスト（生徒の学力に応じた学習サポート）「あなたの学力は現在500です」「目標の foo大学 bar学部は1000目安です」現状今後

次世代N予備校で目指すこと ❹ • 基本は、次世代N予備校の機能でどんどん学習をしてもらう前提 ⇒ 技術による省力化 • その上で、人間がキメ細かな指導をする ⇒ 人間だけにしか出来ない大事なことに集中
• そのために LMS (ラーニングマネジメントシステム) を開発する ◦ 多数の生徒の状況が把握できるダッシュボードを整備 ▪ 詰まっている生徒、伸びている生徒がわかる ◦ 個別の生徒の状況もわかる ▪ どんな教材・問題をどれだけ進めているのか ▪ 計測した学力がどれくらいか、最近の伸び具合はどうなのか等々... 指導員(先生/TA/メンター)が、生徒をより良く支援できる仕組みづくり

組織と環境 

全社　組織体制  教育事業本部　N予備校や学園に関する業務サービス開発部 N予備校や学校管理システムの開発・保守・運用コンテンツ開発部 N予備校の教材制作、授業運営、カスタマーサポート他の本部　ニコニコ事業本部など N高等学校・S高等学校の運営その他の部　学園との協働やバックオフィス

バックエンドセクションサービス開発部組織体制  フロントエンドセクション Webフロントグループ iOSアプリグループ Androidアプリグループデザイン
セクション SRE セクション教務システムセクション品質保証セクションフロンティア企画開発セクション教務システム

使用言語 / 技術 / ツール  言語 / フレームワークインフラ /
運用管理ツール

      機材貸与  開発者向けのハイスペックなMac / Windowsが選択可能。キーボードもUS/JISを選択可能。   VPN接続で社外から内部ネットワークへ接続してテレワークできます。 
制度・福利厚生      ・リフレッシュ休暇  （5日間以上の連続した休暇のうち   　2日間以上の有休・振休を取得することで   　2日間のリフレッシュ休暇が取得できます）休暇   ・対象資格を取得すると、   　月額3,000～50,000円を3年間支給します   　  　－ITストラテジスト   　－システムアーキテクト   　－プロジェクトマネージャ   　－ネットワークスペシャリスト   　－データベーススペシャリスト   　－情報処理安全確保支援士   　－システム監査技術者     上記以外にも、対象資格あり。     ※入社前に取得した資格は、支給対象外です資格取得手当  ※テレワーク対象者のみ公共交通機関を使った通勤経路の定期代の実費相当額を上限月額50,000円まで支給します。  ※テレワーク対象者は、原則、通勤交通費手当の支給はございません。　ただし、業務指示における出社時の交通費は、会社が認める範囲で別途支給します       テレワーク手当テレワークを実施するにあたっての電気代及び通信費等並びに就業環境を整えるための費用として、月額20,000円を支給します。    通勤交通費手当

    満3歳未満のお子さんを養育する場合、育児休業の取得が可能です。   「育児・介護休業法」で定められた最長2歳までの期間よりも長く取得が可能です。男女ともに取得実績があります。  育児休業制度・福利厚生 
    小学校入学までのお子さんを扶養しており、保育園などの育児サービスを継続的に利用する場合、その月額基本料金の2分の1相当額を、上限50,000円まで育児手当として支給します。   育児手当   小学校卒業までのお子さんを養育する場合、勤務時間の短縮が可能です。   標準勤務時間は１日8時間ですが、5時間、6時間、 7時間から選択可能です。   育児短時間措置     ・同好会（公認の同好会は、会社より補助金支給）   ・LT大会（職種ごとに、持ち回りで5分ほどの短いプレゼン大会を開催しています)   ・slack (社内で用いているコミュニケーションツール。メールはあまり使いません！) ・ドワンゴ大忘年会 (全社員が一同に集まり、1年の振返りや社内表彰などを行います)   コミュニケーション活性・artifata GINZA KABUKIZA店（会社の中に美容院があります！）  施設       ・福利厚生倶楽部（RELO CLUBが運営する福利厚生サービスが利用可能）   ・関東ITソフトウェアの健康保険組合各種サービス（保養施設やスポーツ施設の利用が特別価格で利用可能）   ・財産形成制度（財形貯蓄制度、社員持ち株制度）       その他  子育て支援

N予備校    Webフロント   チーム   

Webフロントチームの担当範囲アプリケーション Webフロントエンド教材コンテンツフロントエンド主要なものはふたつ主にPC向けの体験を提供 PC/SP双方に共通の体験を提供 1
2

アプリケーション Webフロントエンド 1

アプリケーションWebフロントエンドの見どころ  不確実性と戦うために常に変化し続ける  いわゆるふつうのSPA React(hooks) React Router Redux + Redux-Observable TypeScript
styled-components Ruby on Rails view上の React ReactやjQuery page.js, slim Redux TypeScript 身軽なSPA React(hooks + Suspense) React Router React Query, etc… TypeScript styled-components 脱Railsべったり  リリース当初の実装から脱却  これは目立つ事例、常にすべてを見直し続ける  React v18以降を見据えて  多方面に身軽にしやすく変化 

アプリケーションWebフロントエンドの今後次世代N予備校とその先の世界を見据えて  • 素早く仮説検証が可能な状態の確立 ◦ より柔軟なフィーチャートグル、ABテスト等を可能にしたい • 変更が容易かつメンテしやすい形に寄せ、保つ ◦ ex.
画面どうしが独立になるように寄せ、互いを知る必要をなくす ◦ ex. 多くの画面でReduxは不要なうえ、暗黙の依存を作りやすいのでやめる • パフォーマンスの向上と維持 ◦ 計測体制を確立、当たり前品質を維持 • アクセシビリティ向上と維持 ◦ 機械判定できる最低限を確保済（WCAG 2.1 Aの一部相当）判定が難しい領域でも、持続可能な形の確立を目指す ◦  

教材コンテンツフロントエンド 2

教材コンテンツフロントエンドのあらまし一定のフォーマットに従うHTMLから、コンテンツを再生  Android N予備校アプリ iOS N予備校アプリ N予備校 Web
教材コンテンツフロントエンド TypeScript jQuery→React移行中教材 HTML - 参考書 - 問題集 - 選択式問題 - 記述式問題 - 論述式問題 - …

教材コンテンツフロントエンドの見どころ • 全クライアントから同じものを表示すること ◦ PCWeb, iOS, Android全クライアントに同じ実装で提供 • これまで作成された教材との互換性を保つこと ◦
実装を改めるときや、機能を拡張するときに問題が起こりやすい • 数式や縦書き文書に対応すること ◦ 各種仕様やライブラリについて、正確な理解を要する • 問題文などはかなり自由な記述が可能なこと ◦ ブラウザやWebViewのバグも踏みがちで学びが多い学習体験の核、簡単に求められがちだが厳しい要求の数々を全部やる

教材コンテンツフロントエンドの課題 • リリース以来の伸びしろが大きい実装からの脱却 ◦ 実装整理からの置き換えを種別ごとに進行中 ▪ Web フロントエンドのレガシーコードを置き換えるためのテストの考え方 • 入稿時点のHTMLそのままでは動作に耐えない
◦ 必要な動作・セマンティクスが備わるように整える ▪ 現状は外観優先になっていて、アクセシビリティが不足 • 教材作成者への支援が不足している ◦ 教材作成者しか知りえない知識を織り込ませるよう補助したい ▪ img要素のalt属性にこういう情報を埋めてほしい、などと言いたい ◦ 最終的な動作を確認するために手間がかかりすぎている ▪ ここはまだ手が届いていない Webの技術に乗った教材という資産の価値を守り、高めていきたい

Webフロントチームについて • 総勢6名（2022年9月時点） ◦ 社員5名、業務委託1名 • GitHub Enterprise上でPR中心の開発 ◦ 厳しく優しくレビューしています
◦ CIでのテストの他、外観差分やPRごとのStorybookなど整備しています • 特に担当コードベースの概念はない ◦ 事実上の主担当はあるが、壁は設けていない（見直すかも • 1週間のスプリントで計画＆振り返り ◦ 5分程度のデイリーミーティングで毎日状況共有 • 週1回のチーム内Webフロントエンド勉強会 ◦ 世のトレンド把握からWebまわりの仕様把握、業務知識共有まで

N予備校    iOSアプリ   チーム   

iOSチーム • 7名（社員4名、業務委託3名） ◦ 今年度2名が参画現在も採用中 • 1週間単位のスプリントでチケット駆動開発 ◦ デイリーミーティングでやることや課題の相談など
• GitHub.com で開発 ◦ Bitrise のため GitHub.com を利用 ※ 社内では通常 GitHub Enterprise を利用

iOS 利用技術使っている技術使わない技術使いたい技術・Swift ・SwiftUI ・RxSwift ・Action ・Alamofire
・Quick ・Nimble ・OHHTTPStubs ・CocoaPods ・SwiftLint ・Danger ・fastlane ・XcodeGen ・Objective-C ・SwiftPM サポート対象OS　iOS 14以上（2023年4月から iOS 15 以上）

iOS アーキテクチャ View MVVM  ViewController Storyboard ViewModel ViewModelInputs ViewModelOutputs Model,
Repository RepositoryProtocol テストあり依存あり

iOS 最近のリリースホーム画面リニューアル  動画を続きからみる機能 

iOS その他の開発 • 便利なデバッグモードの作成 • ビルド構成の整理 • XcodeGen, SwiftGen の導入
• Firebase - BigQuery 連携 • リファレンスリポジトリの作成とメンテナンス

iOS 技術的課題の例 • Swift UI への移行 • 機能追加 ◦ バックグラウンド再生
◦ Picture in Picture ◦ Wi-fiでの動画ダウンロード

N予備校    Androidアプリ  チーム   

Androidチーム • 5名前後 • 1週間単位のスプリントでチケット駆動開発 ◦ デイリーミーティングで開発状況の共有と困りごとの相談 ◦ Pull Requestの作成・レビューを素早く回すことで、コード品質の担保と開発速度の向上を
実現 • GitHub.com で開発 ◦ Bitrise のため GitHub.com を利用 ※ 社内では通常 GitHub Enterprise を利用

Android 利用技術サポート対象OS　Android 7.0 以上（2023年4月から 8.0 以上）  使っている技術  使いたい技術  ・Kotlin 
・RxJava  ・Navigation  ・Jetpack Compose  ・ViewModel, LiveData   ・Retrofit  ・moshi  ・mockito-kotlin  ・releases_hub  ・DI  ・Kotlin Coroutine, Flow    

Android アーキテクチャモジュール構成図  app app アプリのエントリーポイント ui home ホーム画面の UI
domain data forum フォーラム画面の UI lesson 授業画面の UI setting 設定画面の UI common 共通の UI material 教材画面の UI home ホームのロジック forum フォーラムのロジック lesson 授業のロジック setting 設定のロジック common 共通のロジック material 教材のロジック repository データを取得 contract インターフェースの定義 datasource データの定義

Android 最近のリリースホーム画面リニューアル  動画を続きからみる機能 

Android その他の開発 • Jetpack Compose の導入と移行  • マルチモジュール化  •
Single Activity 化  • Navigation 移行 

Android 技術的課題の例 • コードベースの改善 ◦ ライブラリの刷新 ◦ 技術的負債の解消 ◦ 新しい技術の導入
• アクセシビリティの改善 ◦ 誰もが使いやすいアプリに

N予備校 / 教務システム    品質保証  チーム   

品質保証チーム • 8名（社員3名、業務委託5名） ◦ 現在も積極的に採用中 • 1週間単位のスプリントまたは案件単位でテストスケジュール ◦ N予備校と教務システム2つのアプリケーションをチーム分けして対応 ◦
デイリーMTGはアプリケーションごとに情報共有 ◦ 週1のMTGで社員間のコミュニケーション

品質保証取り組み • チーム立ち上げ2年目 ◦ テスト環境の整備 ◦ テスト領域拡大 ◦ チーム体制整備
• リグレッションテスト導入 • シフトレフト体制で品質保証活動を推進

品質保証今後の課題 • テスト領域拡大 ◦ フロントエンド以外のテスト領域の推進 • テスト自動化 ◦ Autify
などの導入検討

N予備校    サーバーサイド開発の取り組み   

N予備校のサーバーサイド開発の取り組み • 開発体制・技術スタックやアーキテクチャのご紹介 • 開発における課題と取り組みの事例 • 今後の展望

開発体制・技術スタックやアーキテクチャのご紹介

開発体制 • 2022/10/1時点で13名（内正社員 11名）の開発チーム ◦ 2021年度は5名の社員を新たに迎え拡大中のチーム • プロジェクト毎に規模に応じた小規模なチームを編成し開発 ◦ 3〜4名規模のチームとなることが多い
◦ プロジェクトを推進するリーダー間でのコミュニケーションや週1で開催される定例において各プロジェクトでの意思疎通や連携を行っている

言語 / フレームワークインフラツール技術スタック・開発環境

マイクロサービスアーキテクチャを採用 • 機能毎にサービスを分割し開発を行っている • プロジェクト毎にチームを編成しているため、メンバー全員がすべてのサービスに対して機能追加などの開発を行っているドワンゴ教育サービス開発者ブログ
「N予備校のマイクロサービス」で詳しく解説

技術選定開発時の状況や提供する機能などに応じて適宜選定代表的な例: • Ruby, Ruby on Rails ◦ 開発初期でのメンバーのスキルセットやリリースに向けての開発速度に重点が置かれていた
◦ 様々なドキュメントが充実していた • Node.js ◦ WebSocketを用いた機能においてイベント駆動のアーキテクチャが求められていた

開発における課題と取り組みの事例

開発における課題 • 技術的負債の蓄積 ◦ リリースから5年が経過し様々な機能追加を実施してきたトレードオフとして複雑化した仕様やボトルネックが明らかになってきた ◦ モノリス化するマイクロサービス • 継続的なN高・S高の規模の拡大への対応
◦ 生徒数の増加に対してスケーラビリティの確保 ◦ 学習を支えるインフラとして高品質かつ早いサイクルでのデリバリー要求への対応 • 学習体験のさらなる向上に対しての取り組み ◦ 価値のあるサービス提供のための機能追加やコンテンツへの対応 ◦ ユーザーの学習に対して指導や評価を効果的にできるサービス開発への取り組み

開発における課題に対する取り組みの事例 • 教材・学習進捗管理サービスの改善 • 教材入稿ツールの改善

教材・学習進捗管理サービスの改善（2021/4〜）課題 • モノリスとなりつつあるサービス ◦ 全体像の把握に要するリードタイムから機能開発の障害に ◦ 複雑化する仕様に比例した複雑度の高いコードベース • 開発当初の要件に対する設計思想と変化してきた要件
◦ 教材のデータ構造に対しての考え方が開発当初から大きく変化し設計思想を反映した開発の継続の難易度が上がってしまった ◦ 単位認定授業の導入による教務システムとの連携など当初想定していない要件の変化に対して設計の見直しなどの時間が確保できなかった

教材・学習進捗管理サービスの改善（2021/4〜）改善へのアプローチモノリスとなりつつあるサービスの分割を目指しAPIインターフェイスの改善と各モデルの責務を明らかに • 複雑化する仕様に対して大規模に変更を行うことが厳しいと判断し徐々に改善していく方針をとった • サービス分割の障壁となりうるAPIインターフェイスを刷新 ◦
教材と学習進捗を一緒に返していた APIの分割 ◦ 教材とカリキュラムのデータ構造の見直し

教材入稿ツールの改善（2021/10 〜）課題 • 教材・学習進捗管理サービスの改善への追従 ◦ 既存ツールは教材・学習進捗管理サービスへの依存度が高く改善を推進するのであれば何らかの形で依存度を低くする必要がある • 仕様と共に複雑化する教材に対応する制作コスト
◦ サービス仕様の複雑化に伴い教材に対しても様々な表現を可能にするため入稿時の仕様や作業が複雑となり制作スタッフの作業負担が大きくなっている ◦ 教材増加に伴う入稿の長時間化や軽微な修正であっても反映に時間がかかる仕様など質の高い教材の提供への障害に

教材入稿ツールの改善（2021/10 〜）改善へのアプローチこれまでJenkinsなどで実行されるツールであったがWebサービス化を行うことで複雑な教材仕様を吸収し制作スタッフの負荷軽減へ • より教材制作に集中できるような環境を目指し制作スタッフからの改善要望やヒアリングをもとに企画 • 教材・学習進捗管理サービスの改善を推進するためにも
教材の入稿フローやライフサイクルについてもゼロベースで再検討を実施

課題に対する取り組みの一例教材・学習進捗管理サービスの改善

プロジェクトの成り立ちと初期設計 • 開発チームからの提案によりボトムアップで実現 • サービスが目指す将来像やあるべき姿などの議論を経て課題箇所の特定や改善のためのアプローチに対して徐々に大枠を決定 • 具体的にどこを改善するか・どれくらいの工数を費やし何をするかなどプロジェクトチームで合意形成を行い設計に落とし込む

開発体制・スクラムの導入開発体制 • 8名のチームで開発 ◦ SM, Architect (2), Engineer (5)
スクラムの導入 • スクラムガイドをベースに、フレームワークに則った各イベントを開催 • チームとして1つのゴールを目指すための課題認識やふりかえりにより課題の可視化やアクションの定義・実践へ ◦ ふりかえりや改善を通してチームに合ったスクラムのやり方に変えていく

OpenAPIを利用したスキーマ定義と改善に向けての取り組み • 新たなAPIインターフェイスについてはスキーマ駆動で実施 ◦ 実装提案と実際のユースケースの検討についてそれぞれ担当者を分けインターフェイスを中心としたコミュニケーションができるようにタスクを定義 ◦ これまでの提供してきた機能を継続して提供することができるかなど細かくシーケンス図を作成し議論を行う •
クライアントコードの自動生成やAPI仕様書としての活用 ◦ これまでOpenAPIでの定義を十分に活用できていなかった過去を反省しクライアントのコード生成や API仕様書としての活用を模索 ▪ Redocly/redocなどを利用し仕様書として把握しやすいドキュメンテーションを意識 ◦ interagent/committeeの利用によりテストにも活用

N予備校のコアドメインとしてのサービスの立て直しこれまでの検討の中で • 教材・学習進捗管理サービスは教材そのものの提供やその教材を利用した学習記録を行うN予備校のコアドメインといえる • 検討を進める内に教材と学習進捗についてモデルとして別々の関心事を有するのではないかという発見があった今後は教材と学習進捗について別々のマイクロサービスに分割しやすくするためにもAPIインターフェイスの整理とそれぞれのモデルの分析・設計を
推進していく

今後の展望

今後の展望 • N予備校をより教育的にも価値のあるサービスにしていく ◦ より開発を効率的に行うためにも継続した改善を実施する ▪ 直近で行いたい改善： • 教材・学習進捗管理サービスのマイクロサービスへの分割 •
BFFとなるAPI Gatewayサービスの改善 ▪ Railsでの開発における課題を解決するためにも技術選定のゼロベースでの見直し ◦ 学力が正確に測定できる・効果的に学習を行えるサービスを目指した企画開発を行う • N高・S高の教職員や教材制作スタッフの業務改善をシステム化で支援しより質の高い教育の提供へ ◦ 教育のインフラとして要望されている機能の実現やエンジニアリングによる課題解決で教育の品質を向上させていく ◦ ユーザーへのN予備校における学習体験の向上により「未来の当たり前の教育」の実現へ

こんな人と一緒に働きたい • 「教育」というドメインにおいて高い関心や課題感を持っている ◦ N予備校が目指す実現したい未来は単純「利用するユーザーが目標に向かい学習を行いその目標に対してどれくらい到達できているかを正確にフィードバックし最適な学習を促したい」 ◦ 実現したい未来や現状の課題の解決や
N予備校の今後を一緒に創る仲間を探しています！ • 業務フローの改善や効率化といったキーワードにピンとくる ◦ N予備校はリリースから 5年が経過し教材制作や運用の面において業務フローの改善・効率化といったポイントが明らかになってきた ◦ N高・S高の堅調な生徒数の増加というバッググラウンドの中で技術支援によってより効率が良く質の高い教育を提供できるのではないかという仮説の提案や実証のためのPoCを経てエンジニアとして主体的に取り組んでいただける方！

「未来の当たり前の教育」を創っていきたい！ • 「改善」にチカラをいれています ◦ ボトムアップで改善や機能追加の提案をプロジェクト化していくという営みがある ◦ 現在進行形で進めている改善プロジェクトにおいても意思決定のためプロジェクトメンバーの合意形成の大事にし納得感のある改善を推進 • これまでの技術選定に縛られずゼロベースで検討を行う風土
◦ 「技術が好き」というメンバーが集まりこれまでチャレンジを恐れていたということを反省し適材適所の技術選定を実施し提供するサービスの品質向上を目指す！「教育」「改善」「効率化」に共感してくれる仲間を探しています！

N予備校    企画 x 技術検証  チーム   

企画 x 技術検証チーム • 7名（社員7名、内他チームとの兼務2名） ◦ リーダー1名、企画 2名、技術検証/データ解析エンジニア 4名の構成
• 企画・技術検証(PoC)・データ解析を1つにしたチーム ◦ 普段は企画チーム・技術検証チームに分かれてデイリーミーティング ◦ メンバーそれぞれの特性を生かし有機的なつながりを作ることを目指しています企画技術検証データ解析

企画 x 技術検証チームの取り組み • 2022年4月に発足し1年目 • 企画と技術検証の距離を近くし、「未来の教育」を実現する

技術検証チームの取り組み • 行動履歴基盤の構築 • 学力定量化への挑戦 ◦ 項目反応理論(IRT) • 今後
◦ 問題の性質分析 ◦ リコメンドのモデル

教務システムについて

これまでの流れ・概観

技術について

旧技術基盤とは • 外部パッケージで使われ、つくられたもの ◦ 開発 ▪ Java8 / jQuery ▪
独自MVC / 独自ORM ◦ インフラ ▪ AWS EC2を手動構築 • 教務システムとしては 6年前開発開始だが、おそらく技術自体は相当な歴史があるものと推測 • DXが良くなく、今後10年内製チームで利用していくには心許ない • ユーザー体験も悪い、 Form Submit とページ遷移の繰り返し (後述) • (補足) 当時の判断を責めるものではない ◦ 速く安くしたかっただろうし、そしてこれほど生徒も職員も増えると思っていなかっただろうし ◦ 大事なのは、変化にいかに対応するか ⇒ 内製化のキモでもある

新技術基盤とは • 内製チームで技術選定したもの ◦ 開発 ▪ TypeScript / Next.js(React) /
Prisma ◦ インフラ ▪ コード化、コンテナ化、ECS + Fargate で実行 • 今後10年内製チームで利用していくことを見込んで選定 ◦ (Prismaに迷いはあるがオニオンアーキテクチャで依存を回避) • Next.js で SSR + 部分的CSR • 閲覧と編集をシームレスにしてクリック数を削減 (後述)

旧技術基盤UI 新技術基盤UI

旧 ⇒ 新技術基盤への「ゆるやかな移行」 • データベースは旧/新で共有 ◦ データの寿命はシステムより長い • 100画面以上ある全ての JavaAction
と HTMLテンプレートを一気に移行することは不可能 ◦ そもそもユーザーの要求の捉え直しをせずにやっても意味はない • したがって既存画面の改修は旧基盤のまま躊躇なく行いつつ新たな要求(新規画面追加、既存業務の見直しなど)を新基盤で実現 ⇒「ゆるやかな移行」 • 並行して開発者もサーバサイド Java メインから TypeScript / Next.js を修得、レベル上げしていく

今後について & なかま募集

• 角川ドワンゴ学園の生徒数&学校数増加の勢いはこれからも続き、近いうちに10万人オーダーになっていく • その一方で、教員・職員の数はなるべく増やさずに済むよう、効率的な業務デザイン・システムデザインをしていく • また角川ドワンゴ学園以外にも、ネット教育の「当たり前」を目指して他法人へのサービス提供もしていく •
多くのユーザーに、軽快で使いやすいシステムを新技術基盤を武器に提供していく今後について

なかま募集たとえばこんな方... • 抽象的な業務課題を吸い上げて、システムに落とし込む上流工程やりたい ◦ 年々進化する学校なので課題も多いが、やりがいもあります • 業務システム開発で TypeScript /
Next.js / コンテナ技術ができる・やりたい・やれるようになりたい ◦ いまはJavaしかできないけど…な人も歓迎 • いままで受託だったけど、内製やっていきたい ◦ ユーザーの感謝が得られますし、生徒数が増えたりコストが下がるのも嬉しいですまずはカジュアル面談からお待ちしています! 🙏

ドワンゴ教育事業ソフトウェアエンジニア採用説明資料 / for-engineers

ドワンゴ教育事業ソフトウェアエンジニア採用説明資料 / for-engineers

Other Decks in Technology

Featured

Transcript