npocccties / chiloportal

CHiLO-Portal

CHiLO-Portalは，LMSで発行されたデジタルバッジ（Open Badges v2.0）のBadgeClass(JSON)を読み込み， バッジのカテゴリ分類，検索，概要表示，バッジの認定者（コンシューマ）設定，コンピテンシーへのマッピング機能を提供する， フロントエンドのシステムです．

なお現在はMoodleのみに対応しています．

chiloportal's Issues

ユーザージャーニーマップの作成

• ユーザーの属性、ペルソナ、利用目的
• 本システムの利用前～利用中～利用後の過程

等をFigJam等によって言語化視覚化できたら完了

本番相当環境へのデプロイのドキュメンテーション

どのような手順を踏むと本番相当環境へデプロイできるかドキュメンテーションできたら完了

教育委員会ごとの育成指標一覧を設計

キャリアステージの名称をステージごとの名称としてつくる

堺市の場合「教員養成期」「基礎形成期」など
大阪市の場合「第一ステージ」など

キャリアステージがまたがっている場合も想定する
（例）

充実 ・ 発展期

• 教諭, 保育教諭
• 指導教諭等, 主任保育教諭
• 主幹教諭, 主任保育教諭

---

• 大阪市教育委員会
• 堺市教育委員会

ができたらTIESさんに確認いただけたら完了

ブランチ戦略について

各機能の開発にあたって、プルリクエストの作成、そのマージ先の指定などに影響する

• 機能開発（プルリクエストの作成）のベースブランチを何にするのか

等チームで相談し合意を得られれば完了

LMS から Badge をインポートするときの下処理について明確化する

LMS (Moodle) から Open Badge のデータを定期(手動？)バッチ処理でインポートして SQL DB に格納する処理をするが、Moodle が管理・生成出来る Badge の制限の都合上で表現されるため、インポート時の下処理が必要。

この下処理内容を明確化・意識合わせしたい。

前提: フロントエンドは Badge のパース処理をしない。バックエンドでパース済みのデータを REST API で受け取ったものだけを利用する。従って、バッジの情報として必要な下処理は基本的にインポート時に行う + 認定をする教育委員会などのデータを追加で保持する形となる。

本 issue ではバッジクラスからのインポート処理を定義する。

育成指標を経由する導線を見直す

現状、

教育委員会一覧 -> 教育委員会別の育成指標一覧
と経由するわけだが、直近としては教育委員会の数がまだすくないうちであれば
トップページに教育委員会ごとの入り口があり、教育委員会別の育成指標一覧に遷移できたら、遷移が1ページ減る。

Figmaにて上記の導線ができたら完了。

将来
教育委員会が増えてきたときに現状設計段階の教育委員会一覧専用のページがあっていい。
自治体のサイトのように50音順などで探せると一般的なのでは。

カテゴライズドバッジとカテゴリの構造に関する提案

カテゴリが何階層になるか不定（これまでの議論としては最大3階層として、それ以上の階層は登録作業者が3階層になるように登録する認識）ということであれば、DBテーブルとその参照関係として表現するより、単一の構造化ドキュメントとして表現したほうが柔軟性という観点でいいのではと思った

例（Markdownで構造化した場合、ただしおそらくショートコードは標準化された仕様ではなく各Markdownパーサーの実装依存の機能）

# カテゴリ1

## カテゴリ2

### カテゴリ3

{{ badge <バッジのid> }} <!-- ショートコードとしてバッジを表記可能にする -->

関連するテーブルの該当箇所

chiloportal/backend/sql/create_table.sql

Lines 48 to 55 in f530911

	create table category (
	id serial not null, -- カテゴリID
	consumer_id int not null REFERENCES consumer, -- コンシューマ ID
	category1_name varchar(128) not null, -- カテゴリ1
	category2_name varchar(128) not null, -- カテゴリ2
	category3_name varchar(128) not null, -- カテゴリ3
	primary key (id)
	); -- 'カテゴリ'

chiloportal/backend/sql/create_table.sql

Lines 70 to 73 in f530911

	create table categorized_badge (
	id serial not null, -- カテゴライズID
	consumer_id int not null REFERENCES consumer, -- コンシューマ ID
	category_id int not null REFERENCES category, -- Category ID

ひととおりの画面の実装

• #46
• #47
• #48
• #49
• #50
• #51
• #85
• #86
• #260

ができたら完了

グローバルナビゲーションの見た目の実装

関連 #52

API サーバーのモックのレスポンスが固定値

他には json-schema-faker を使うとテストデータの生成が可能

#19 ではモックのレスポンスをハードコーディング（Swagger Editorのexampleからコピペ）しているので今後の課題

Originally posted by @knokmki612 in #11 (comment)

スキーマに適合する値を都度機械的に生成できたほうがモックデータの柔軟性やモックデータ生成の効率という観点で望ましい

フロントエンドとバックエンドのすり合わせのための時間をとる

https://www.figma.com/file/dCE06JShf29eqnvZ4vcE8U/OKUTEP で検討中のワイアーフレームについて、おおまかに画面構成が確定したところで、妥当なAPI、テーブル構造について具体的な検討を進めることを目的に
FigmaとSwagger Editorを画面共有しながら対面で認識共有して議論するための時間をもうける

ある程度目的を達成（なにかしら具体的な変更のためのissue/PRを立てるなど）したと感じられたら完了

Todoを用意する

Todoを用意してissueとリンクさせる．次回のミーティングでも議題にする．

CHiLO-Portalのペルソナ

大学

大学は，教師に提供したいオンラインコースのデジタルバッジに，カテゴリ，レベル，対象などの属性毎（タグをつけて？）にポータルに登録する．

教師

教師がオンライン研修を始めるきっかけは2つ

1. 自ら抱えている課題の解決や目的を達成するため（主体的）
2. 教育委員会にいわれて（能動的）

本来は1を目指しているが，そのためには，何らかの仕組みが必要．従って当面2になると考えている．

教師の選択方法は，以下が考えられる（要検討）

• 大学が分類したバッジの属性から選ぶ（**卸売市場から探す，に相当）
• 教育委員会がマップした教員育成指標から選ぶ（小売店から探す，に相当）
• フリーワードで検索する
• 最終課題の種類，ビデオ再生時間など，取得のしやすさから選ぶ
• 代替できる研修数で選ぶ

教育委員会

教育委員会は，大学が登録したバッジそれぞれが，自らの教員育成指標のどれに相当するのか指定する
教育委員会は，教師に，オンライン講習を受講し，バッジを獲得することを指示する

バックエンドAPIの認証について

バックエンドAPIは公開サーバーに置く想定でしょうか？
もしそうであるならば、認証情報が必要ですが、何か想定されておりますでしょうか？
特になければ、djangoの管理機能でAPIキーを発行できるので、それを認証情報としてヘッダーに付与して頂こうと思います。

• キー名：Authorization
• 値：Api-Key {APIキーの値} ※Api-Keyの後ろは半角スペースを入れる

能力バッジの見た目の実装

関連 #52

チャットの見た目の実装

関連 #52

ウェブアプリケーションフレームワークの選定

UIライブラリ、ルーティング等ウェブアプリケーション開発のためのフレームワークが選定導入できたら完了

https://github.com/npocccties/chibichilo でも採用しておりメンテナンス性を考慮すると Next.js になるのかなと思った

バックエンドで定義されるデータ構造からの型生成、バリデータ生成のためのライブラリの選定

• API エンドポイントごとのリクエストで受け付けられるパラメータ
• API エンドポイントごとのレスポンスから得られるデータ
• バックエンドでモデリングされるデータ構造

をもとに型そのもの、TypeScript の型が付与された API クライアント、バリデータを生成するためのライブラリの選定導入できたら完了

といいながら私もこの点に関してあまり経験豊富というわけではなくほぼほぼ他人のみようみまね

たとえば aspida を使うと型の付与された API クライアントが生成できる。バックエンドで定義されるリクエストレスポンスについて OpenAPI の仕様に適合した JSON が配布されている場合、openapi2aspida を併用することで、それをもとにクライアントを生成することができる。
しかし必ずしもそのようにする必要があるわけでなく、エンドポイントの定義を記述することでクライアントを生成することも可能。

またバックエンドでモデリングされるデータ構造をもとに JSON Schema の仕様に適合した JSON が配布されている場合 json-schema-to-ts などを使って型を生成することができる。モデリングされるデータ構造をもとに型が生成できれば、（OpenAPI によるドキュメンテーションがない場合でも）API エンドポイントのレスポンスに関して型定義をスクラッチでおこなう必要がなくなり効率的かもしれない。

同様に JSON Schema の仕様に適合した JSON が配布されている場合 ajv などを使ってバリデータを生成することができる。

バッチ処理でMoodleからバッジのデータを取得する際のIDについて

バッチ処理でMoodleからバッジのデータを取ってくる際のIDはどのように取得すればよいか？

能力バッジ
https://opedu.lib.osaka-kyoiku.ac.jp/badges/badge_json.php?id=41
https://opedu.lib.osaka-kyoiku.ac.jp/badges/badge_json.php?id=139
https://opedu.lib.osaka-kyoiku.ac.jp/badges/badge_json.php?id=145

上記の「id=」の数字

• 能力バッジ一覧取得のAPIがあってそれで取ってくる？（すべて取得するならこれでOK？）
• 取り込みが必要なIDをDBのテーブルであらかじめ定義しておく？（必要なものに絞る必要があるならテーブル化必要？）

バッジ一覧表示コンポーネントのバリアントを設計する

バッジ一覧表示にも、簡易的なバリアントを設計する必要があるので別Issueに立てる

Originally posted by @Hidetaro7 in #28 (comment)

• より詳しい内容が記載されているバリアント
• 簡易版のバリアント
  • 能力バッジ名
  • 取得条件
  • 発行大学名、ロゴ
  • n件の育成指標（hoverで詳細表示？）

育成指標から成長段階を選ぶ画面の実装

関連 #52

• #63
• #64
• #57
• #61

ができたら完了

UI コンポーネントフレームワークの選定

見た目、インタラクションの効率的な実装のためのフレームワークを選定導入できたら完了

ツクロアの考える UI を効率的に反映するという観点では

• Jumpu UI
• Headless UI
• Iconify

になると思う。

https://github.com/npocccties/chibichilo のデザインシステムを適用したいということであれば MUI と https://github.com/npocccties/chibichilo/tree/master/styles や UI コンポーネントを npm パッケージとして再利用可能にして導入など考えられるが、それだけで大きな作業になりそうで現実的ではないように思った。

SQL のテーブル定義を確認する

画面仕様案-テーブル定義等_20220609.drawio.pdf を元にテーブル定義を書いて頂いたが、実際にポータルでの表示に必要なデータを返す API の実装をする上で過不足がないか (特に不足がないか) 確認し、テーブル定義を (一旦) 固めたい。

https://github.com/npocccties/chiloportal/blob/develop/backend/sql/create_table.sql

教育委員会ごとの育成指標別バッジ一覧

Descriptionにおいては自由記述ができる想定で
堺市の場合

経験年数（めやす） -> 11年目〜
幼・小・中・支・高 -> 教諭
幼保連携型認定こども園 -> 保育教諭

大阪市の場合

初任教員 期

の人向けがわかるような文章にして、現状の表組みにはしない

「求める教師像」については、各教育委員会によって存在しない場合もあり、ここでは記載しない

ここにタグUIとして育成指標ごとの対象者が表示されている想定で作成する

カテゴリトップ画面の実装

関連 #52

• #59
• #60
• #57
• #61

ができたら完了

成長段階別バッジ一覧画面の実装

関連 #52

• #59
• #65
• #66
• #57
• #61

ができたら完了

トップで「カテゴリから能力バッジを探しましょう」セクションの作り方について議論・確認する

2022.8.30 のデザインミーティングで触れましたが、Aさんのような自発的に学びたい人のニーズを叶えるための入り口として、運営側でまとめた関心ごとのキーワードカテゴリにバッジを紐付けることで、探しやすくするための仕組みを提案中。

そのため、バッジごとにどのようなデータを持たせるのかという裏側の設計が必要と考えますので、issueとして立てておきます。

以下の画像のような想定です。

ペルソナBさんのユーザーストーリーの作成

関連 #12 #13

• ペルソナBさんの利用目的
  • 教育委員会の育成指標から自発的に学習したい
• 利用目的から想定されるユースケース
  • 「大阪市教育委員会の認定であれば、片っ端からバッジ取得したい」
  • 「大阪市教育委員会から、法令に関するバッジを優先して取得したい」
  • 「法令と教室に関係する複数の関心があるので、そのバッジを欲しい物リストのようなものに入れたい」

をもとに本システムの利用前～利用中～利用後の過程（○○画面にアクセス、○○にクリック、○○が分かった等）を言語化視覚化できたら完了

教育委員会が承認したバッジに当たる情報のとり方

1. Open Badgeの仕様としてはどこからとれるのか
2. テーブル定義 https://github.com/npocccties/chiloportal/blob/develop/backend/sql/create_table.sql としてはどこからとれるのか

について知りたいと思った

キーワード検索対象を明確にする

キーワード検索とチャットボットは同様の機能であるが、何を検索対象とするのかが定まっていない。
ペルソナCさん（育成指標ごと全部学んできてねと言われた人）にとって、いきなりトップからキーワード検索をする可能性がある。
その際考えられる行動として
「大阪市　インターン」
「堺市　養護」
とだけで検索をする行動にでることがあるのだろうか？

そのあたりのユーザーの行動についてはTIES様のほうが理解が深いと思いますので、想定される検索キーワードをいくつか教えていただき、それに応じて検索結果画面のフィルターが必要であれば設計する必要がありそうです。

参考（Figma）: https://www.figma.com/file/dCE06JShf29eqnvZ4vcE8U?node-id=254:2513#256063262

想定される検索キーワードが理解できたら完了。

Badge 種別をどのように表現するか決める

Moodle の現バージョンでは BadgeClass に対して tags フィールドの値を設定する機能を持っていない。
しかし、本システムでは能力/知識バッジの区別が必要である。今年の大教大のバッジデータでは取りあえず「知識バッジ "バッジの名前"」といった prefix で表現しているが、CHiLO Portal ではこのようなデータ表現及び下処理では実装したくない

現状の Moodle では version フィールドに任意テキストが記入出来る (OB 仕様上も許される) し、他に使っていないものなので少々ハックだが name などに書くよりマシだろうという話になっている。

version プロパティを使う場合にどのようなフォーマットにすべきか。

Semantic Versioning https://semver.org/ がより一般的で Node でも使われてるからそれでいい気がした。こちらは Mozilla などのバージョン名ルールと違ってハイフンが入るけど文字付きの方がナシより古いというのは一緒 (将来 "-letters" 外せるようになったら外した方が新しくなって自然)。

• Identifiers consisting of only digits are compared numerically.
• Identifiers with letters or hyphens are compared lexically in ASCII sort order.
• Numeric identifiers always have lower precedence than non-numeric identifiers.
• A larger set of pre-release fields has a higher precedence than a smaller set, if all of the preceding identifiers are equal.
• Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

従って、1.0-wisdom, 1.0-knowledge のようなバージョンにする感じだろうか。

ちなみに、バッジ定義の作成日というのがデータとして無さそう (個別のバッジの発行/期限は issuedOn, expires に記載) だがもしそのような情報も持っておきたくなったら 1.0.2022-wisdom などとする事も可能。いずれの場合も 最後の "-letters" 部分で判別することとすれば種別が 1 種類だけで済む実装である限り大丈夫。

参考

• version プロパティ http://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html#Properties

  The version property allows issuers to specify a version string or number. It is primarily used to update a BadgeClass without changing the meaning of previously awarded Assertions by duplicating and linking to the previous version.

• バージョン利用例 http://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/examples/index.html#-badgeclass-versioning

CIのセットアップ

リモートリポジトリへのプッシュ、プルリクエストの作成等のタイミングでコード整形、静的コード解析、ユニットテスト等がCIによっておこなわれることが品質管理の観点で望ましい

GitHub Actionsが使えるようであればGitHub Actionsで導入

検索結果画面の実装

関連 #52

• #59
• #60
• #56
• #57
• #61

ができたら完了

おすすめのバッジの見た目の実装

関連 #52

コードレビューについて

なにかしら変更をおこなった際は、第三者によるコードレビューがおこなわれるとバグの混入の抑制や実装のブラッシュアップが促され品質管理の観点で有用と思う

• フロントエンドの変更でのレビュワー
  • 基本セルフレビュー @knokmki612
• バックエンドの変更でのレビュワー
  • 基本セルフレビュー
  • 必要に応じて @m-takay
  • oopenapi.jsonとかDDLのSQL文等のドキュメンテーション @knokmki612
• それ以外（ドキュメンテーション等）のレビュワー
  • 未定（必要に応じて）

に誰を指定すればいいか明確化したい

開発方法のドキュメンテーション

• 構成
• ローカルでの起動方法
• 起動に必要なパラメーター

などができれば完了

ペルソナDさんのユーザーストーリーの作成

関連 #12 #13

• ペルソナDさんの利用目的
  • 教育委員会側の立場の者
• 利用目的から想定されるユースケース
  • 「Cさんに対してURLを探し当てて、URLをCさんに渡したい」

をもとに本システムの利用前～利用中～利用後の過程（○○画面にアクセス、○○にクリック、○○が分かった等）を言語化視覚化できたら完了

開発ディレクトリ構成の検討

フロントエンドとバックエンドをひとつのリポジトリで開発する都合上ディレクトリを分ける必要がある

フロントエンドとバックエンド個別のディレクトリ構成についてはスコープ外とする

分け方について決めてリポジトリに反映できたら完了

案

$ tree .
.
├── LICENSE
├── README.md
├── backend
└── frontend

ペルソナCさんのユーザーストーリーの作成

関連 #12 #13

• ペルソナCさんの利用目的
  • 教育委員会指定のバッジだけを取得
• 利用目的から想定されるユースケース
  • 「「このバッジを取得して報告してください」とURLを渡される」
  • 「「育成指標である『授業を展開する力』に関連するバッジをすべて取得して報告してください」と口頭で言われる」

をもとに本システムの利用前～利用中～利用後の過程（○○画面にアクセス、○○にクリック、○○が分かった等）を言語化視覚化できたら完了

デフォルトブランチを develop にする

#18 の議論で開発ブランチを develop にすることになったので、GitHubリポジトリのデフォルトブランチも develop に指定できるとうれしいと思った

手順 https://docs.github.com/ja/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/changing-the-default-branch

理由

1. プルリクエスト作成時のベースブランチにデフォルトブランチが指定される（現状あやまってmainブランチを指定する可能性がある）
2. 特定のキーワードでissueを完了する機能がデフォルトブランチにのみ対応している

キーワードの1つを使用してPull RequestをIssueにリンクしたい場合は、PRがデフォルトブランチ上になければなりません。

https://docs.github.com/ja/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue

状態管理のためのライブラリの選定

画面遷移やコンポーネントをまたいだ状態管理のためのライブラリを選定導入できたら完了

とくに問題なければ jotai になると思う

外部データ取得のためのライブラリの選定

バックエンドAPIを叩いて取得キャッシュするためのライブラリを選定導入できたら完了

とくに問題なければ swr になると思う

育成指標から探すの見た目の実装

関連 #52

ポータルトップ画面の実装

関連 #52

• #53
• #54
• #55
• #57
• #58
• #71
• #72
• #84

ができたら完了

カテゴリの見た目の実装

関連 #52

能力バッジ画面の実装

関連 #52

• #59
• #62
• #57
• #61

ができたら完了

検索欄の見た目の実装

関連 #52

トップで「おすすめバッジ」セクションの作り方について議論・確認する

ミーティングにて議題にしたい

トップの入り口として、
運営側がまとめたおすすめバッジリストをどのようにして運営、管理するのか、
あらためて確認した上で画面設計をする。

以前はブログのようなものが案に挙がっていた。

ペルソナAさんのユーザーストーリーの作成

関連 #12 #13

• ペルソナAさんの利用目的
  • 教育委員会の指定に関係なく自発的に学習したい
• 利用目的から想定されるユースケース
  • 「子どもの一人ひとりの個性を伸ばしてあげたい、具体的な方法を学習したい」
  • 「まだ学び始めなので、できたら少ない学習時間でバッジを取れないだろうか？」

をもとに本システムの利用前～利用中～利用後の過程（○○画面にアクセス、○○にクリック、○○が分かった等）を言語化視覚化できたら完了

継続的デプロイの検討

最新時点での状態、各プルリクエスト等による変更での状態を動作確認する際に有用

https://github.com/npocccties/chibichilo では

• Vercel
• Heroku

を使用していた記憶