成績管理サイトtensile

主な使用技術：HTML CSS JavaScript firebase

目次：

|   制作のきっかけ  |   苦労したこと  |   試行錯誤  |   工夫  |   完成品について  |   今後について  |

Reason制作のきっかけ

U22へ出場することになり、チームで話し合う中で以下のような問題が話題に上がりました。ここからは実際のエントリーフォームへ入力した内容の抜粋です。
学生を学習で評価する際、絶対評価では正しくその人の努力量を評価できないのではないと私たちは考えています。例えば数学が得意でいつも満点を取っている学生にとっての80点はマイナス評価ですが、苦手で60点程度が多い学生にとっての80点はむしろプラス評価になるはずです。
更に、徐々に成績があがっていっているのが同じでも、伸び率も上がっているかどうかで、今後のスコアへの期待値も変わるはずです。
こういった塾講師がこれまで経験で補ってきた学生毎の評価を、システムによって誰でも使いやすくできるようにしたいという願いから制作を決定しました。
また、講師のマネジメント業務に関する激務軽減にもつながるのではないかと期待しています。

Difficulty苦労したこと

私は役割としてPMを担いました。部活動単位での出場でしたが、プログラミングがとにかく得意という学生もいれば、これからがんばっていきたい、あまり得意ではないという学生もいるわけです。簡単にいえば実力差が大きく、forで配列を回すのが精いっぱいという学生にfirestoreから取得したデータをふるいにかけるような処理を任せるわけにはいきませんし、逆に得意という学生は極力レビュー役に回ったり、教えたりする立場になるべきだと考えています。
ここで、そういった全体の役回りやスケジューリングとその調整、進捗の確認や定期会議の進行等々といった役が必須でした。そこで、プログラムもメンバーの中であれば2番手ですし、普段から部活動の進行をメインで行っていたり、リーダーシップがある方だと自負していたということもあり、私がPMを担うことになりました。
しかし、実際は苦難の連続でした。まず第一にスケジュール通りに物事が一切進まないということです。実際のスケジュールよりも大幅に遅れ、メンバーの学生もチーム開発の経験が乏しかったこともあり、あまり危機感なく開発をしていたところがあります。中には会議に出なかったり、報連相がまるでなかったり、アルバイトを優先せざるをえなかったり、音信不通になったり、進捗報告が届かなかったり……。日々頭を悩ませていました。
しかし、見方を変えればとにかく大きな経験となったわけです。リスケジューリングの考え方やその手の打ち方、分担やコードレビューの方法……。この約4か月間で、とにかく沢山のことを学びました。
ここからはシステム自体の技術についてお話していきます。こちらもエントリーフォーム入力内容からの抜粋です。
技術的に苦労した点としては、レートの算出式、データ構造の2つがあります。
1点目の算出式についてですが、数学的な知識が相当必要でした。そもそもどういった形式でレートを算出するかという時点で必要で、全体として点数が上がっているかどうか、上がり幅がどう変わっているか、点数を中央付近に圧縮したい等、イメージとしては固まっていましたが、ここをどうプログラム化するかという点で苦労しました。結局近似と微分を使うことになり、具体的には点数の一覧を基に近似式(回帰直線と曲線)を求め、それを基に算出しています。ここで、最小二乗法を用いて近似式を算出しておりますが、その最小二乗法自体を理解することにも手間取りました。更にそれをプログラムで実装するとなった時、numerc.jsについて学習し、それを使いこなす必要があったので、相当時間がかかりました。
2点目のデータ構造ですが、Cloud Firestoreを利用するにあたって、NoSQLを使用しています。しかし、今回のシステムに求められるデータ構造がRDBによっているため、どのようにドキュメント指向で実現しようかといったところで試行錯誤しました。基本的な関係はRDBを中心にし、一部にNoSQLの利点を生かす(ユーザ毎にテストの得点を持たせることで新たにテーブルを作る必要がないなど)ことで、問題点をクリアしたうえで、NoSQLの利点を最大限に生かすことができています。

Trial and Error試行錯誤

そういった苦労を踏まえ、私は各経験者(今回で言えば基本的に担当教員でしたが)にアドバイスをいただき、問題がありそうな学生に対しては個人面談を行って話を聞いたり、進捗があまりよくない学生に対しては困りごとがあるのではないかと踏んで技術の相談を受けに話を聞いたりと、色々な角度から全員をサポートできるように試行錯誤しました。
スケジュール通りに進んでいない中でも、例えば進捗が3日間停滞していたり、当初本人が立てた計画の倍以上の期間が経過していたりすると、ヒアリングを行うように心がけていました。もちろんそうでなくとも細々話を聞くようには意識していましたが、意識的に吸い上げないと、後々取り返しがつかなくなったり、手戻りが発生してしまう可能性があると考えています。そういった個々をよく見るというのを、このマネジメントをした期間を通して良く学びました。
また、タスク管理についても試行錯誤の上で形にしてきました。最初は全て私一人で管理するつもりでしたが、全員が共通で見れるものがあったほうが良いのではないかと考え、全員で共有するTo-Doリストを作成しました。今回の開発で作り、管理したマネジメントツールは以下のものです。

1. Microsoft Teams：ファイル共有やチャット・進捗報告・会議で使用
2. PERT図(draw.io)：ざっくりとした全体の計画の見通しを立てるために使用。チーム全体でファイルを見れるように共有
3. Microsoft To Do：全体で共有するタスク管理ツール(WBSのように細かく分けず、ざっくりと(例：テスト作成画面/テスト作成処理等))
4. WBS(draw.io)：分担をどのようにしていくかを明確にするために使用。チーム全体でファイルを見れるように共有
5. ガントチャート(Excel)：WBSで細かく分けた作業工程毎、計画と実績を一覧で見れるように作成。進捗報告を基に私1人で入力および管理し、会議時に毎回共有してコメント(予定に比べてどうか、このままだとどれくらいで終わりそうか等)
6. その他設計資料、各種連絡等(Word)：Teams上で共有

なお、会議は週に2回オンライン/オフラインで行い、出席できないメンバーにはチャット等で内容を共有していました。その日の進捗は全員が必ずするように体系化し、全員を私一人で管理するのではなく、小さなグループに分け、その中でグループリーダーを作り、リーダーが集約したメンバーの進捗を報告してもらっていました。こうすることによって、小さなもんだはグループ内で解決し、最終的に私や技術担当まで回るように、組織を体系化することができました。

Ideas工夫

工夫した点といえば、やはりレートの算出式でしょう。なんとなくイメージはありましたが、それを形にするのに相当時間がかかりました。基本的に私はマネジメントを担当していましたが、このレート算出式に関してはプログラム部分を担当していました。というのも、どうしても数学的な知識が相当量必要で、チーム内で唯一大学数学レベルまで学んでいたということ、単純に数学が得意ということを踏まえて担当しました。ここで記述すると相当な量になってしまうので、概要だけ載せて、その他はPDFで資料を添付させていただきます。

1. 点数をx、レートをrとしたとき、r=0.92×(x-50)+50とすることで圧縮する
2. 回帰、及び重回帰分析を行ってn次式に近似し、重みづけする
3. 3次式での近似では、変化率の変化を見るために 微分を行う

PDFはこちらから

Finished完成品について

こちらから実際にお使いいただけます。
作品の概要とアピールポイントの抜粋です。
tensileは、生徒の成績を一括管理することができるシステムです。独自のレーティング機能を用いて、テストの点数だけではなく、全く新しい角度で生徒の学業をサポートすることができます。これまでと比較して成績が上がっているかどうか、どのくらいの幅で変わっているか、変化率はどの程度か……。様々な観点を採用し、その生徒に合った、適切な評価が可能です。その他、これまで書類で管理していたような生徒のデータやテストの記録なども、全て一括管理することができます。複数の講師が一つのクラスを共同管理することもでき、幅広い活用が可能です。
また、生徒と講師の他に保護者もアカウントを作ることができ、生徒のアカウント(複数登録可)と紐づけることで、お子様の成績を参照することができます。
tensileの一番の強みは、レーティングシステムにあります。概要にある通り、「絶対評価」で生徒を評価せず、様々な要素から計算し、その生徒の元々の得意不得意も、努力量も同時に測ることができるようになっています。例えば、55, 65, 80と点数が上がっていった生徒の方が、80, 80, 80とずっと横ばいの生徒よりもその努力を認めてレートは高くなります。このレーティングシステムが何よりもtensileの強みであり、一番のアピールポイントです。
また、複数の講師でクラスを管理できたり、保護者が複数の生徒とアカウントを紐づけたりと、小さなところながら、不便を感じさせないように注力しました。

Future今後について

このシステムには、問題点が数多く残っています。UIの見にくさ、導線の分かりにくさ、レスポンスの遅さ……。このシステムの改善自体の優先順位が自分の中で高くないということもあり、すぐに改善していく予定はありませんが、今後改善するといえばそういった点の修正になるかと思います。