第1回演習（教員活動情報システムの失敗例）で各グループから提出された回答（全96件）を、匿名化したうえで設問ごとに論点別へ整理したものです。 個々の回答を全部読まなくても傾向がつかめるよう要約していますが、多数派の意見だけでなく、少数だが鋭い視点も残すようにしています。正解はありません。自分たちのグループの意見と比べてみましょう。

表記：◎多くの回答が指摘 ／ ○複数の回答が指摘 ／ △少数・特徴的な視点

1. 誰がどんな問題を起こしているのか？

教員側の問題

  • ◎要件の肥大化：「使うかどうかは別として、入れられるデータは全部入れておけばいい」（教員A）という発言を起点に、不要なデータまで集める方針になった。最も多く挙がった指摘。
  • ○目的・比較基準の曖昧さ：「学部間で比較したい」と言うだけで、何を・何のために比較するのかを決めていない。目的が曖昧なまま要件が膨らんだ。
  • ○入力方式を主観で決定：「年配の教員はWebが苦手」「Excelなら使い慣れている」という根拠のない思い込みでExcel方式を選んだ。
  • △会議が機能していない：教員B・C・Dが反対や具体案を出さず、教員Aの意見をそのまま採用。最終決定権が教員Aに集中している。

設計者・開発者側の問題

  • ◎共通テーブル設計：学部ごとに異なる項目（医学部の臨床実習時間、文学部の論文数など）を1つの共通テーブルにまとめ、NULLだらけ・肥大化・保守困難を招いた（設計者A・B）。
  • ◎全件置換のアップロード方式：差分更新ではなく「毎回すべて置き換える」方式。「ロジックが簡単でバグが減る」という開発側の都合を優先（設計者B）。
  • ○Excelエクスポート→追記方式：既存データを全部書き出して追記する形にしたため、1ファイルが巨大化した。
  • ○専門家としての責任放棄：教員の素人要件に対し、技術的リスク・デメリットを説明せず、メリットだけで合意してしまった。

テスト・運用の問題

  • ◎テスト不足：教員Aが自分の学部分を1人で入力して「動きました」で完了。1,700人・大容量ファイルの同時アクセスを想定した負荷試験をしていない。

△少数・特徴的な視点

  • 「開発はウォーターフォールなのにテストはアジャイル」になっている。
  • サーバが1台のみで冗長化されていない。
  • 教員Aが教員Bの要件を正しく理解していない／事前会議では「保存する」しか決めていないのに、設計段階で勝手に「データベース」前提で話が進んでいる。
  • CiNii・科研費・学務システムなど外部データベースと連携していないため、業績を手入力させている。
  • そもそも現場で使う教員にヒアリングしておらず、教員への教育・参加意識も不足している。

2. 技術的な問題と、コミュニケーションの問題は？

技術的な問題

  • ◎共通テーブル設計：学部差を無視した集約でNULLが多発、正規化不足で保守が困難（学部追加のたびに列追加が必要）。
  • ◎全件置換方式：差分でなく全置換のため、毎回10MB超のファイルを処理し、年々データ量が増える。
  • ◎Excelアップロード方式そのもの：1,700人 × 大容量ファイルの同時送信に耐えられない。
  • ◎負荷試験・性能試験の不足：本番規模（人数・同時アクセス・ファイルサイズ）を想定した検証がない。
  • ○不要データ収集によるデータ量増大、○サーバが脆弱・冗長化なし。
  • △外部システム連携不足・UI/操作性の悪さ：同じ情報を何度も再入力させる、入力画面が複雑。

コミュニケーションの問題

  • ◎目的・比較内容が曖昧なまま合意：「比較したい」だけで、評価指標や使い道を詰めていない。
  • ◎リスク指摘が出ない／全員が妥協・全肯定：反対意見や批判的視点を持つ人がいない（「妥協」という言葉が複数回登場）。
  • ○設計者が技術的リスク・デメリットを教員に説明していない。
  • ○利用規模の認識が共有されていない：1,700人・締切前のアクセス集中・1ファイルの大きさが開発者と共有されていない。
  • ○利用者（現場教員）へのヒアリング不足、○教員「使いやすさ」と開発側「実装しやすさ」のすれ違い。
  • △責任範囲が曖昧、△テスト条件が関係者間で共有されていない。

△少数・特徴的な視点

  • 「これはすべて技術的な問題だ」とする回答（コミュニケーション要因を認めない立場）。
  • 教員が2人しか参加しておらず、「各学部最低1人は必要」。
  • 教員どうしでも利用目的がバラバラ。

3. みなさんならどこで軌道修正して失敗を回避しますか？

軌道修正のポイントは「要件定義の段階」に戻すという意見が最も多く、加えて設計・更新方式・運用・体制それぞれに具体案が出ました。

◎要件定義の段階で立て直す（最多）

  • 「とりあえず全部」をやめ、目的（誰が・何を・何のために比較し、何の意思決定に使うか）を明確化し、必要なデータだけを厳選する。
  • プロトタイプや教員ヒアリングで利用者の声を反映し、最小機能版から始める。定期レビューで早期に問題を発見する。

○入力方式を見直す

  • ExcelをやめてWebフォーム入力／MS Formsで収集し、管理側で1つに集計する。
  • 年配教員には「使えないから諦める」のではなく、マニュアル・説明会・分かりやすいUI・入力チェックで対応する。
  • Excelを残すなら、入力セル以外を編集不可にしてフォーマットを統一する。

○データベース設計・更新方式を直す

  • 共通項目と学部固有項目を分離（または学部ごとにテーブル）して正規化する。
  • 全件置換ではなく差分更新にする／過去データを除いて当年分だけ送る。

○負荷対策・運用設計を加える

  • ダミーデータで1,700人・大容量同時アクセスを再現した負荷試験を本番前に実施する。
  • サーバ増強・冗長化、アップロード期間を学部ごとに分散、一時的なアクセス制限。

△体制・会議の進め方（少数だが本質的）

  • 議事録を残して伝達ミスを防ぐ、リスク検討を徹底する、開発方式を一貫させる。
  • 教員C・Dや開発者・システム管理者も議論に巻き込み、反対意見を出せる場にする。

△特徴的なアイデア

  • 学生のGPAのように、各項目に係数をかけた合計点で学部横断的に比較できるようにする。
  • 「学内のある学習サイトが課題締切前に落ちる」実例を引き、締切前の一斉アクセスを想定した負荷試験を提案。

総評

  • 技術面：共通テーブル・全件置換・Excel方式・負荷試験不足という設計／検証の問題が繰り返し指摘された。
  • コミュニケーション面：目的の曖昧さ、リスクを誰も指摘しない雰囲気、利用規模の認識共有不足が根底にある。
  • 回避策：多くのグループが「要件定義に立ち返って目的とデータを絞る」ことを軌道修正の起点に挙げ、Web入力・差分更新・本番規模の負荷試験・利用者ヒアリングを具体策として示した。