情報処理学会研究報告
IPSJ SIG Technical Report

学生と教員が共同運用する To-do 管理システムの開発
村上裕史 1

宮田優作 1 小島俊輔 1

概要：高専・大学等において課題やレポート（以下 To-do）の提示は，SNS やグループウェア，メールといった情報ツール以外に，口頭，掲示版，研究室ホワイトボードなどアナログ手段が今でも存在する．そのため学生は To-do を個別に漏れなく管理することが困難な状況にある．そこで本研究では「チーム」という概念を導入することで，学生と教員が自由に参加し共同で管理する To-do 管理システムを設計・開発する．システムは，チームの誰かが To-do を入力することでチームに所属する全員が入力したのと同じ状況を作り出す．システムは入力漏れの予防だけでなく，各自の To-do の過密度をヒートマップで可視化する機能を実現する．
キーワード： インタフェースデザイン，Web サービス，協同学習支援

Development of a To-Do Management System
to be Operated Jointly by Students and Faculty
HIROFUMI MURAKAMI†1 YUSAKU MIYATA†1SHUNSUKE OSHIMA†1Abstract: In technical colleges and universities, there are other ways to share assignments and reports (hereinafter referred to as"to-do") information tools such as SNS, groupware, and e-mail. In addition, there are other than information tools still analog
methods such as oral communication, bulletin boards, and whiteboards in laboratories. This makes it difficult for students toindividually manage their to-dos without omissions. Therefore, in this study, we introduced the concept of "teams" and designed
and developed a system in which students and faculty members can freely participate and collaborate in managing their to-do. With
this system, when someone in a team enters a to-do, it creates the same situation as if all team members had entered the to-do. Inaddition to preventing input omissions, the system can visualize the over density of each person's to-do on a heat map.
Keywords: interface design, Web service, Cooperative learning support

1. はじめに高専・大学等の教員が課題やレポートの出題や提出先，

2. 要件定義
2.1 想定する場面

締切日といった情報（以下 To-do）を提供する際は，インシステムの使用者は学生と教員を想定する．システム

ターネットの発展に伴い，SNS やグループチャット，メは使用者の役割に応じた機能をそれぞれ提供する．学生ールといった多くのツールが用いられている．情報共有

は学内での携帯性からスマートフォン（以下スマホ）で，方法は情報ツール以外にも口頭，掲示版，研究室ホワイト

教員は教員室での業務を想定してパソコン（以下 PC）でボードなどのアナログ手段も根強く使用されている．情システムへアクセスする状況を想定する．本稿で用いる報が拡散しているため，学生は To-do を個別に漏れなく概念とその用語を以下の通り定義する．

管理することが困難な状況にある．また，担任は担当するチーム

クラス学生の To-do の進捗状況を把握できず，個別指導

To-do を共同し互いに助け合って To-do リストを作り上げがしにくい．

る団体．ここでは，日常で To-do を共有する割合から，ク

そこで本研究は，学生が To-do の進捗状況を一目で確ラスと研究室を「チーム」として想定する．

認でき，学生と教員で共同し To-do を作成・編集・削除すメンバーるシステムの構築を行う．共同 To-do によって入力情報チームに所属するユーザ（学生と教員）をクラスや研究室で共有し，To-do の入力忘れを防ぐ．ま共有 To-do

た，共同 To-do の個人の進捗状況を教員が確認できるたチームによって共有・管理される To-do．クラスであればめ To-do が滞っている学生を把握し個別指導がしやすく課題の提出，研究室であれば書類の作成など，そのチームなる．に所属する全学生がこなすべき To-do が当てはまる．
個人 To-do

1 熊本高等専門学校
National Institute of Technology, Kumamoto Collegeⓒ2023 Information Processing Society of Japan1

情報処理学会研究報告
IPSJ SIG Technical Report
チームに共有されない個人が管理する To-do．

すく，学生にとって使いやすく，かつ実装しやすいシステ

2.2 要件ムとなる．

1 章で述べた問題点と 2.1 節で述べた想定場面から，シ(2) 誰でも使えるシステムシステムをブラウザ上で動作する Web アプリケーショ

ステムを構築するための要件を定義した．ここでは，要件を学生と教員という 2 つのロールに分けて示す．

ン（Web アプリ）として構築する．これにより，デバイス

学生やオペレーティングシステム（OS）に依存しないシステ-

スマホの OS に依存することなくシステムを使用

ムの開発・実装ができる．また，ユーザはどのデバイスか-

個人 To-do の追加・編集・削除

らもシステムを利用できる．Web アプリは開発者側と利-共有 To-do の追加・編集・削除

用者側，双方にとってメリットのあるシステムとなる．

-

完了した個人 To-do・共有 To-do(3) 使いやすいシステム-

個人 To-do・共有 To-do の数を確認-

チームに参加教員システムを SPA（Single Page Application）として構築する [5]．SPA とすることで，ページをフルリロードする必要がなく，動的コンテンツだけを更新できるため，アプリ-

PC の OS に依存することなくシステムを使用

ケーションの挙動が高速になりスムーズな動作が実現す-

共有 To-do を追加・編集・削除

る．

-

共有 To-do の数を確認-チームに参加

ェース（以下 UI）を提供する．学生の多くはスマホでシ-共有 To-do の学生ごとの完了状況を確認

ステムにアクセスするが，少ないタップ数で目的の画面

また，SPA はシンプルで分かりやすいユーザインタフ

既存の To-do リスト[1]を扱うアプリの中には，共有 To-に到達でき，かつ片手でも操作しやすい画面構成となる．

do を作成・編集・削除する機能を持つものやグループでまた，To-do の重要度や数といった情報が一目でわかるよ

To-do を共有する機能 [2]が存在するが，入力した情報をう，ライブラリを用いてアイコンやアニメーションを工一括してユーザ個々の To-do に割り当てる機能はない．

夫する．

そこで本システムは，チームに所属するメンバーの誰(4) 一目でわかる忙しさ

かが To-do を追加すれば，メンバー全員に To-do が追加さ課題の把握漏れの対策として，課題の量と締切日を容れる機能を搭載する．これにより，To-do の追加忘れを予易に把握できるように，カレンダーをヒートマップとし防することができ，また，チームメンバーの誰でも編集可て表示し課題の進捗状況を可視化する機能を搭載する．

能とすることで入力情報の修正が容易になる．
本稿では，システム全体の設計と学生機能の実装について報告する．学生機能を先に実装・公開した理由とし

3. システムの機能と運用ポリシー
3.1 ユーザごとの機能
システムの持つ機能について，ユーザごとに分類してて，本システムの重要なコンセプトである学生の UX がある．UX を向上させるためには，実際にシステムを使用

以下に説明する．

した学生からのフィードバックが必須であり，そのため(1) ユーザが共通して使用する機能

学生機能の構築と公開を優先した．教員機能は設計まで⚫

ユーザを認証する機能．Google アカウントを用いて認に留めており構築については別の報告としたい．
2.3 アプローチ
本研究ではシステム管理の効率と To-do の入力効率を目的としたシステムの実現を目指しており，次の 4 点に証を行い，教員と学生を判別する．また，ユーザを認証した状態から未認証の状態へ戻す．
⚫

本 学 で は ， す べ て の 学 生 に グ ル ー プ ウ ェ ア Google

チーム参加機能
共同したいチームへ参加する機能．チームのメンバー着目したアプローチをとる．
(1) 容易なシステム管理

ログイン・ログアウト機能となるには，ユーザ自身がチームに参加するだけである．
チームに参加後は，そのチームの共有 To-do を共同管理

Workspace [3]を利用した Google アカウントが付与されてすることができる．

いる．Google Workspace はクラウドベースのグループウ⚫

共有 To-do の閲覧・追加・編集・削除機能

ェアであり，学校は学生のアカウントをまとめて管理す共有 To-do を閲覧したり，操作したりする機能．チームることができる．また，Google の提供するモバイルプラに所属する全メンバーが使用できる．この機能によってットフォーム Firebase [4]を用いれば，Google のアカウンチームが持つ共有 To-do リストの管理が容易になる．

トを使ったユーザ認証が可能となり，セキュリティに配(2) 学生が使用する機能

慮した実装がしやすい．Google アカウントでのログイン⚫

機能を備えたシステムとすることで，学校側が管理しやⓒ2023 Information Processing Society of Japan

個人 To-do の閲覧・追加・編集・削除・完了機能
通常の To-do アプリにある個人 To-do を操作する機能．

2

情報処理学会研究報告
IPSJ SIG Technical Report
共有 To-do と併せて個人へ提供する．各個人 To-do は他のユーザやチームメンバーへは共有されない．
⚫

達成済み To-do の保管機能達成した To-do は，ホーム画面から達成済み To-do 画面に移動する．この操作により To-do を完了したとみなす．
万一，操作ミスや再提出となった場合でも，達成済み Todo 画面で完了操作を取り消すことができる．
⚫

ヒートマップ機能
To-do の過密度をカレンダーに可視化して表示する機

能．学生ごとに，未達成の To-do の締切日と現在の日付から過密度を計算し，カレンダーの各日付のセルに色付けして表示する．
(3) 教員が使用する機能⚫

共有 To-do 進捗閲覧機能

図 3.1 ユースケース図

チーム内の共有 To-do について，各メンバーの進捗状況を確認できる機能．共有 To-do ごとに達成していない作について考える．まず共有 To-do が追加されるユーザ

ユーザをアカウント名で確認できる．

は，その時点でチームに所属していたメンバーのみとす⚫

る．つまり，途中からチームに参加，あるいは途中で退会

チームのヒートマップ表示機能
To-do の過密度をカレンダーで閲覧する機能．チームごとに存在しており，そのチームの共有 To-do の締切日と現在の日付をもとに過密度を計算してカレンダーの各日するユーザは，チームに参加している間に追加された Todo のみを反映することとした．
以上，２つの運用ポリシーにより，システム管理者は最付セルを色で重みづけする．

初にチームさえ作成しておけば，その後のチームメンバ

3.2 運用ポリシー

ーや To-do リストの初期化処理は一切不要となる．

システム運用を厳密に行うためには細かな権限の設定あるチームのメンバーとなった教員は，共有 To-do のが必要であるが，年度更新などにおいてシステム管理のユーザごとの完了情報を知ることができる．これによっ手間が必要である．そこで，システム管理の手間を省くたて，教員が，そのチーム，例えば研究室や担任するクラス

め，本システムの運用ポリシーを次のように定める．に所属する学生の To-do 状況を確認することができる．

個人 To-do

3.3 ユースケース

本研究は To-do の管理・把握が前提になるため，共有

3.2 節で述べた運用ポリシーに従い，各機能のユースケ

To-do 機能に加えて従来型である個人 To-do 機能を搭載すースを図 3.1 に示した．紫色の線で示す機能が学生と教る．To-do をまとめて把握できるため，学生がより普段使員それぞれが使用する独自の機能となっている．

いしやすいシステムとなる．管理の手間は本学で別に運用している Google アカウントでログインしており，アカウント追加などの管理は不要である．
共有 To-do
共有 To-do はチーム全員が作り上げるものである．つ4. システム構成と設計・実装
３章で述べた運用ポリシーに従い，以下の様なシステム設計とした．
4.1 システム構成

まり，To-do の作成者以外でも，同じチームのメンバーで開発段階におけるシステム構成を図 4.1 に示す．シスあれば編集・削除が可能であるが，一方で誰かが悪意を持テムは，ローカルサーバ内にある Web サーバ，API サーって編集・削除することも可能になる．そこで，チームすバ，データベース（DB）で構成する．ユーザが各端末かなわち同じクラスあるいは同じ研究室という閉鎖的な中ら Web サーバにアクセスすると，Web サーバが API サー

では悪意を持ったメンバーは発生しないと仮定した．つバへリクエストを送信し，API サーバがデータベース内まりチームの権限管理はせず，メンバー全員を対等としの情報を取得する．ユーザは学内ネットワークに接続し，て扱う．さらに，チームへの追加や退会もシステム管理者

ブラウザから既定のアドレスにアクセスしシステムを利ではなくユーザとなる学生の自己申告制とした．チーム

用する．今回は，開発途中のセキュリティに配慮したたとは本来関係ないユーザがメンバーになることが可能でめ，サーバ・クライアント全てが学校内で完結しているあるが，無駄に To-do が多く表示されるだけであり，自らが，システム完成後はサーバを学外に設置し，運用しても好んで所属しないと判断した．

問題はない．

次に，To-do をチームメンバーの誰かが追加した際の動ⓒ2023 Information Processing Society of Japan3情報処理学会研究報告
IPSJ SIG Technical Report

表 4.1

開発環境

項目

名前開発マシン

Raspberry Pi 4OS

Raspbian GNU/Linux 10

開発言語

JavaScript

データベースMariaDB v10.6.11

JavaScript 実行環境

Node.js v16.18.1

パッケージ管理システム

npm v8.19.2

仕様想定ブラウザ

Google Chromeす．カラムやテーブルの命名では，シンプルな英単語を用
図 4.1

システム構成4.2 開発・実行環境

い，後置修飾で統一性を持たせており可読性を重視した．
共有 To-do 機能では，共有 To-do の情報を格納するテー

本システムの開発における実行環境および開発環境を

ブルと進捗状況を格納するテーブルを図 4.3 のように分表 4.1 に示す．本研究で使用するサーバは，Raspberry Piけ，外部キーを用いて進捗状況テーブルから情報テーブ

4 を採用した．理由として，扱う情報はテキストデータがルを参照する．また，共有 To-do が追加された際に，進捗主であるため Raspberry Pi でも充分と判断しており，ま状況のデータを含むレコードをメンバーの人数分作成すた，開発に関する情報が豊富であり，安価でかつ入手しやるよう設計することで，メンバーごとの進捗状況を保持すいためである．Web アプリとして実装するため，Web サできるようにした．各テーブルの用途を以下に示す．

ーバ・API サーバの両方で JavaScript を用いてコーディン

todos_private テーブル

グすることとし，実行環境として Node.js [6]を採用した．

個人 To-do の情報と進捗状況を格納するテーブルであ開発するシステムは主要機能の多くをライブラリによりる．個人 To-do の追加・編集・削除・追加の際に参照する．

実現しており，これらライブラリのパッケージ管理シス

teams テーブルテムとして Node.js と親和性の高い npm [7]を採用した．
4.3 ライブラリチームの名前と ID を紐づけるテーブル．
teachers テーブル・members テーブル使用したライブラリとバージョンを表 4.2，表 4.3 に示

ユーザが所属するチームを管理するテーブルである．

す．表 4.2 はフロントエンドで Web サーバ構築に，表 4.3

チーム ID とユーザ ID を紐づける．ロールを分けるため，はバックエンドで API サーバ構築に使用した．フロント

教員は teachers，学生は members へそれぞれ登録する．

エンドには，UI ライブラリとして React [8]を使用する．

todos_shared テーブル

React は Meta 社が開発・公開しているもので，UI の各要

共有 To-do の情報を格納するテーブルである．共有 To-

素を構成部品（コンポーネント）として小さく分けて考えdo の追加・編集・削除の際に参照する．

る「コンポーネント指向」が採用されている．モジュール

todos_shared_status テーブルやクラスがカプセル化されており，メンテナンス性が高

共有 To-do の各メンバーの進捗状況を格納するテーブ

く拡張性が高い．加えて，CSS フレームワークとして，ルである．各個人の共有 To-do の進捗管理で参照する．

React と相性がよい Material UI（MUI）[9]を使用する．MUIは Google が公開したマテリアルデザインと呼ばれるデザイン手法のガイドラインに則っており，シンプルで使い表 4.2

フロントエンド開発に用いたライブラリ
ライブラリ名バージョン

やすい UI を構築できる．また，バックエンドでは Web フ

React17.0.2

レームワークとして Express [10]を使用する．軽量でカス

React-router-dom

6.2.2

タマイズ性が高く Node.js 上で動作するため，API の設計・Material-UI

5.0.0

実装用に採用した．

axios

0.27.24.4 データベース

Firebase

9.15.0react-calendar

4.0.0

date-fns

2.29.3styled-components

5.3.5

データベースは Raspbian OS が推奨する MariaDB を使用した．本システムのデータベース設計を，図 4.2 と図4.3 に示す．図 4.2 は共有 To-do 機能実装に用いるテーブルで，図 4.3 は個人 To-do 機能実装に用いるテーブルである．主要テーブルにおけるカラムの説明を表 4.4 に示ⓒ2023 Information Processing Society of Japan

4情報処理学会研究報告
IPSJ SIG Technical Reportteachers (教員の所属情報)
id

int

固有ID

team_id

todos_shared_status(ユーザごとの進捗管理)

char

チームID (FK)uiddatetime

ユーザの固有ID

created_at

datetime

作成日時

updated_at

datetime

更新日時

id

int

固有ID

team_idint

チームID (FK)content

teams (チーム情報)
id

int

固有ID

name

char

チームの名前created_at

datetime

作成日時

updated_at

datetime

更新日時

id

int

固有ID

todo_shared_id

int

共同To-do ID (FK)member_id

todos_shared (To-doの情報)

members (学生の所属情報)

char

char

メンバーID (FK)is_doneboolean

ユーザごとの状態

created_at

datetime

作成日時

updated_at

datetime

更新日時

To-doの内容

deadline

datetime

締切日時

created_at

datetime

作成日時

updated_at

datetime

更新日時

memo

text

メモ

is_donebooleanTo-do全員が完了

テーブル名 (用途)
カラム

id

int

固有ID

team_idchar

チームID (FK)uiddatetime

ユーザの固有ID

created_at

datetime

作成日時

updated_at

datetime

更新日時

…

データ型

説明

…

…

テーブルの見方
１行目は「主キー」（各レコードの識別子）
矢印は「外部キー（参照先と参照元）」

図 4.2

共有 To-do に関する DB テーブル設計
4.5 ヒートマップ

表 4.3

バックエンド開発に用いたライブラリ
ライブラリ名バージョン

本節ではヒートマップの画面構成とヒートマップの色を決定する際の過密度の計算方法について説明する．

Express4.18.1

CORS

2.8.5

Firebase-admin

11.2.1MySQL

2.18.1

示で構成する．

nodemon

2.0.20

学生用カレンダーのヒートマップ表示

4.5.1 画面構成と機能
ヒートマップ画面はカレンダー表示と To-do リスト表

学生用カレンダーのヒートマップには，各ユーザの課題の過密度を表示する．過密度の計算対象には，ログイン中のユーザが未完了の個人 To-do と共有 To-do を使用する．
教員用カレンダーのヒートマップ表示
教員用カレンダーのヒートマップとして，教員が指定したチームの課題の過密度を表示する．過密度の計算には，締切日が過ぎていないチームの共有 To-do を使用す
図 4.3

個人 To-do に関する DB テーブル設計

る．
学生用 To-do リスト表示
カレンダーのヒートマップ表示の下に To-do リストを

表 4.4

各カラムの説明

カラム名

説明

name

チームの名前content

To-do の説明（タイトル）

uid

ユーザの固有 ID．初回ログイン時に表示する．表示する To-do は，ログイン中のユーザが未完了で，かつ To-do の締切日がタップし選択した日付を過ぎていない個人・共有 To-do である．これにより，To-doの締切日による絞り込み表示ができる．表示された To-doFirebase から発行されるの 1 つをタップすると，その To-do の詳細情報（メモ・作deadline

To-do の締切日成日）を確認できる．

created_at

To-do レコードの作成日

4.5.2 過密度の算出アルゴリズム

updated_at

To-do レコードの最終更新日

memo

To-do のメモ（補足説明など）

is_doneTo-do が達成されたかを判断する（1：達成済，0：未達成）

学生のヒートマップ表示に使う過密度の計算アルゴリズムについて述べる．
(1) To-do の重要度の計算
式(1)に示す通り，現在の日付 now と締切日 deadline から To-do の締切日までの残り日数 days_left を求め，この値から To-do の現時点での重要度 point を計算する．

ⓒ2023 Information Processing Society of Japan

5情報処理学会研究報告
IPSJ SIG Technical Report

表 5.1

次に point の算出方法を式(2)に示す．

重みづけのレベル

過密度

RGB（255, x, x）

1.0 以上43

0.7 以上

1.0 未満85

締切日が近いほど To-do の緊急性があると判断し，point0.5 以上

0.7 未満128

は days_left に反比例する値とした．ゼロ除算防止のため，

0.2 以上0.5 未満

170と定める．すべての To-do は0 より上0.2 未満

212のときは締切日までに完了すると仮定し，締切日が過ぎていない

0255

To-do を過密度の計算対象とした．
i 番目の To-do に対する重要度は式(3)により決定する．
カレンダーの各日付に対応した重要度を格納する配列
points を用意し，を満たす 日目に対して等しく point を配分する．
(2) To-do の重要度の合計(1)の計算アルゴリズムに従い， 個の To-do すべてに対し，重要度を計算する．計算式を式(4)に示す．任意の日付（ 日目）の重要度 points_all[ ]は，points[ ][ ]の合計値として計算できる．
図 5.1

学生用ホーム画面

5.2 チーム参加画面(3) 色による重みづけ
過密度を示す数値が格納された配列 points_all からヒー-

チーム選択フィールド．参加ボタンから構成される-

チーム選択後，参加ボタンをクリックするとチームトマップを生成する．色は赤ベースとし，過密度が低いほへ参加ができる．一度に複数のチームを選択でき，ど色は白く，高いほど赤くなるようにした．開発したシス参加が可能．

テムで使用した過密度と RGB 値との対応を表 4.5 に示

5.3 学生用ホーム画面

す．日付セルを塗りつぶす際，完全な赤色（RGB(255, 0,-作成した画面を図 5.1 に示す．ヘッダー，フッター，0)）だと鮮やかすぎる．そこで，色域を制限しかつ統一性

個人 To-do リスト，共有 To-do リスト，チェックボを持たせるため，G 値・B 値には 255/6=42.5 を 5 等分しタン，メニューボタン，To-do 追加ボタンから構成さた値を設定した．

れる．

5. 作成したシステムの画面表示開発したシステムの画面表示について説明する．主要-各 To-do の左にあるチェックボタンをクリックすると，To-do 完了確認アラートが表示される-

To-do の右にあるメニューボタンをクリックするとな画面は，ホーム画面，To-do 追加画面，ヒートマップ画編集ボタンと削除ボタンが現れる．編集ボタンを押

面の 3 つある．

すと To-do 編集画面に遷移し，削除ボタンを押すと5.1 共通ヘッダー・フッター-

学生ホーム画面，完了 To-do 一覧画面，ヒートマッ

To-do 削除確認画面が表示される-プ画面では，共通のヘッダーとフッターが表示され-To-do 追加ボタンを押すと，To-do 追加画面に遷移するる5.4 To-do 追加画面

ヘッダーは，ログイン中のアカウントのアイコンと-個人 To-do や共有 To-do を追加するページであり，ID，チーム参加ボタン，ログアウトボタンからなる

チーム選択フィールド，To-do フォーム，メモフォー-

フッターは 3 つの画面遷移ボタンからなる

ム，〆切日フィールド，To-do 登録ボタンから構成さ-チーム参加ボタンを押すとチーム参加画面に遷移すれる．作成した画面を図 5.2 に示す．

る--

フッターの各ボタンを押すと対応した画面に遷移する

表示され，チーム選択を行う
5.5 学生用ヒートマップ画面-ⓒ2023 Information Processing Society of Japan

参加しているチームのみがチーム選択フィールドにヘッダーとフッター，カレンダー，リストからなる

6

情報処理学会研究報告
IPSJ SIG Technical Report

表 6.1

点数方式アンケートの結果
質問

平均点数

クラスのメンバーが個人でそれぞれタスク
Q1を登録するよりも，クラスの誰かが一括で4.2登録する方が好ましい
このシステムにより自分の To-do を管理がQ24.2できた
ヒートマップで To-do の量を把握できたの

Q3

4.2は良かった

図 5.2

To-do 追加画面

クラスや研究室別にタスクが管理できたの
Q4

4.6
は良かった

Q5

タスクの登録項目の内容や数は適切だった

4.6

Q6

このシステムの使い方は分かりやすかった

4.5

点数方式のアンケートの結果を表 6.1 に，記述式アンケートの結果をキーワードごとに表 6.2 に示す．点数式
アンケートでは，全体として 4.2 以上と高い評価が得られた．
［Q1］［Q4］が 5 点満点中それぞれ 4.２，4.6 となり，共有 To-do 機能を便利と感じる学生が多かったことが伺える．また，［Q3］の結果から，ヒートマップに対する評価が 4.2 となった．最後に，［Q2］で学生自身による To図 5.3

ヒートマップ画面

do 管理の評価が 4.2 となった．
記述式アンケートについては，点数式アンケート［Q3］-画面上部には，To-do の過密度に応じて色で重みづと同様，カレンダーで可視化するという手法を高く評価けされたカレンダーが表示されるした学生がいた．また，重みづけをする色の変更や To-do

画面下部には，カレンダー上の選択された日付に応カテゴリごとのヒートマップなど，機能を提案する回答じたリストが表示される．表示の例を図 5.3 に示すが多くあった．

選択された日付のセルは青い実線で囲まれている．
画面にアクセスした直後は現在の日付が選択されている-7. 結論本研究では，共有 To-do の入力を簡便にするためのシリストには各 To-do の名前・締切日・締切日までのステムを設計・開発した．本システムは学生と教員を対象

日数に加え，ヘッダーに To-do の件数が表示される者としており，現在，学生用の機能は構築できている．学

リスト上の To-do をクリックするとダイアログウィ

生はスマートフォンでの使用を想定しており，React を用ンドウが表示され，To-do のメモ・作成日等の詳細情いた SPA アプリケーションとすることでストレスなく使報を確認できる．ウィンドウの外をタップすると閉用することができる．共有 To-do の実現にあたり，「チーじるム」と呼ばれるグループを提案し，チームに所属する学6. 評価生・教員全員が To-do を管理するシステムとして開発した．これにより，チームに所属した学生の誰かが To-do を学生に本システムを利用してもらった後にアンケート入力することで，全員が To-do を入力したのと同じ状況を実施した．まず，本校の学生 22 名（本科 3 年生～専攻を作り出すことができ，チームによる効率的な To-do 入

科 2 年生）に対して，システムの操作方法を教え，10 分力が実現できた．

程度使用してもらった．その後，5 点満点の点数方式，お開発したシステムを一般学生に使用してもらい，点数よびキーワードごとの記述式アンケートを実施した．機

形式でのアンケート調査を実施した．その結果，「システ

能や操作感，共有 To-do やヒートマップなど，本システムムにより自分の To-do を管理することができた」，「クラの有用性に関する質問は 5 点満点で入力してもらった．

スや研究室別に To-do が管理できたのはよかった」，「ヒートマップで To-do の量を把握できたのは好ましかった」ⓒ2023 Information Processing Society of Japan7

情報処理学会研究報告
IPSJ SIG Technical Reportのそれぞれの評価において，5 点満点中 4.2 点以上の評価を得た．このことから，研究の目的である学生の共有 To-

参考文献

do 管理は達成できたといえる．

[1] Microsoft To Do, https://todo.microsoft.com/tasks/. (参照 202302-13).
[2] Garoon, https://garoon.cybozu.co.jp/. (参照 2023-02-t3).
[3] Google Workspace, https://workspace.google.co.jp/intl/ja/. (参照2023-02-13).
[4] Firebase, https://firebase.google.com/?hl=ja (参照 2023-02-13).
[5] SPA とは : Devblog, https://blog.shiftasia.com/spa-single-pageapplication/. (参照 2023-02-13).
[6] Home | Node.js, https://nodejs.org/en/. (参照 2023-02-13).
[7] npm, https://www.npmjs.com/. (参照 2023-02-13).
[8] React, https://reactjs.org/. (参照 2023-02-14).
[9] MUI, https://mui.com/. (参照 2023-02-14).
[10]Express | Home, https://reactjs.org/. (参照 2023-02-14).

今後の展望として，教員画面の実装を予定している．共有 To-do の各学生の進捗を確認できる機能や，各チームのヒートマップを確認できる機能を実装する予定である．
学生用機能の開発と同様，実際に教員に使用してもらい，フィードバックを得ながら改良を重ねていく．
謝辞 本研究の遂行にあたり，熊本高等専門学校 技術・教育支援センターの岩本舞 氏には研究の遂行にあたり，日頃より有益なご助言を頂いた．また，評価にあたり熊本高等専門学生にはアンケートに回答して頂いた．ここに感謝の意を表する．
表 6.2

記述式アンケートの結果

キーワード

アンケート結果

To-do- To-do 締め切りを入力する部分で日付のみではなく，時間まで決めたい．
- 重要度を設定し色が変わる仕組みにしてほしい．
- 詳細ボタンをクリックするのが面倒なのでホームページにて一目ですべての To-do がわかるようにして欲しい．
- 誰が追加した共有 To-do なのかをわかるようにして欲しい．
- 共有 To-do ではみんなの進捗が知りたい．

通知- 期限が迫ると通知が来るようにすると使用してもらいやすくなる．
- 共有 To-do が追加された際に通知が来ると使いやすいと思う．
- ウィジェットへの追加や通知が来る設定をできるともっとよかった．

ヒートマップ- カレンダーの色を自分で変更できると個性が出て良いなと思った．
- カレンダーでタスク確認できるのがすごくよかった．

チーム- チームを作れるようになりたい．
- チームメンバーの確認や脱退などの，チームの管理画面が欲しい．

操作感- 簡単な操作でわかりやすかった．
- ローディング画面はバーかサークルどちらかでよいと思う．
- サクサク動いて使いやすいなと感じた．

ⓒ2023 Information Processing Society of Japan8