なぜ学内向けサービスはUIが古いのか

Share

大学の履修登録、図書館の蔵書検索、成績確認。これらのシステムを使うたびに、どこか十年前のインターネットに迷い込んだような気分になる。ボタンの配置は直感に反し、画面遷移は不必要に多く、スマートフォン対応はおまけ程度。なぜ、大学のシステムだけが時代に取り残されているのか。

予算だけでは説明できない

真っ先に浮かぶのは予算の問題だ。大学は企業のようにUIに投資する余裕がない、と。

しかし、この説明だけでは不十分だ。世の中にはオープンソースの優れたソフトウェアが数多く存在する。無料で使える学習管理システム(LMS)でさえ、多くの学内システムよりも洗練されたインターフェースを持っている。予算がないから古いのではなく、予算以外の構造的な力が働いている。

実際、大学のIT関連支出は決して少なくない。ネットワークインフラ、セキュリティ対策、サーバ運用。予算は存在するが、その配分先がUI改善に向かわない。IRと大学経営で触れたように、データ活用の重要性が増すなかでも、投資の優先順位は利用者の体験よりも基盤の安定に傾きやすい。

動いているものには触るな

IT運用の世界には、暗黙の鉄則がある。動いているものには触るな。

これは怠慢ではない。合理的なリスク回避だ。学務システムが止まれば、数千人の学生が履修登録できなくなる。成績処理が狂えば、卒業判定に影響する。こうしたシステムは壊れたときの被害が大きいため、変更は最小限に抑えられる。

しかし、この力学には副作用がある。一度構築されたシステムは、当初の技術的前提のまま固定される。2010年代に構築されたシステムが2020年代になっても同じ見た目で動き続けるのは、技術の進歩が止まったからではない。変えるリスクが、変えないリスクを常に上回ると判断されているからだ。

そして「変えないリスク」は目に見えにくい。UIが古いことで学生が被る不便は、数値化されにくい。成績処理が一秒止まれば大騒ぎになるが、使いにくさで毎日数分ずつ失われている時間は、誰も集計しない。

使う人と買う人が違う

ここに、もっと根深い構造がある。

学内システムの利用者は学生だ。しかし、そのシステムの導入を決定するのは事務職員であり、予算を承認するのは大学の経営層だ。

UXの分野では、これは「ユーザーと購買決定者の乖離」として知られる古典的な問題だ。消費者向けの製品であれば、使いにくいものは売れない。市場の淘汰が働く。しかし、組織内で導入されるシステムでは、この淘汰圧が弱い。導入を決める人が日常的にそのシステムを使うとは限らない。

結果として、調達の場で優先されるのは、機能要件の充足、既存システムとの互換性、サポート体制、そして価格だ。「学生にとって使いやすいか」は、仕様書の評価項目に含まれていたとしても、最終的な判断を左右するほどの重みを持ちにくい。

大学のあり方を問うで整理したように、大学という組織の意思決定には多層的な構造がある。利用者の声が最終的な意思決定に届くまでの経路が長いほど、UIの優先度は下がる。

ベンダーロックインという重力

もう一つ、見過ごせない力学がある。

多くの学内システムは、特定のベンダーが大学ごとにカスタマイズして納品している。一度導入されると、そのベンダーの技術スタックに依存した運用が始まる。データ形式、API、サーバ構成。すべてが特定の実装に紐づく。

この状態で別のシステムに乗り換えようとすると、移行コストが膨れ上がる。データの移行、業務フローの再設計、職員の再教育。見積もりを取った瞬間に、「今のままでいい」という結論が出る。

これは大学に限った話ではない。エンタープライズITの世界では、ベンダーロックインは古典的な課題だ。しかし大学の場合、この構造がとりわけ強固に作用する。学務システムには競争市場がほとんど存在しないからだ。消費者向けアプリのように、不満があれば別の選択肢に移るという圧力が働かない。

見えるコストと見えないコスト

大学のシステムが古いのは、誰かが手を抜いているからではない。変えることのコストが具体的で大きく、変えないことのコストが抽象的で見えにくいという、構造的な非対称が原因だ。

システムを刷新すれば、予算が必要になり、移行期間中のトラブルが予想され、職員は新しい操作を覚えなければならない。これらはすべて、目に見えるコストだ。

一方、UIが古いまま放置されるコストは、学生の時間の浪費、操作ミスによる手戻り、デジタルネイティブ世代が大学の情報基盤に抱く不信感。どれも実在するが、数字として経営層の机の上には並ばない。

デジタルの紙を超えてで書いたように、情報の「見た目」と「中身」の分離は、技術的にも組織的にも未解決の課題だ。大学の学内システムもまた、見た目の改善が後回しにされ続ける構造のなかにある。

それでも使い続ける

システムが古くても、履修登録はできる。成績は確認できる。図書館の本は検索できる。「使えている」という事実が、改善の動機を奪う。

結局のところ、学内サービスのUIが古いのは、古いままでも動いているからだ。使う側の不便は、システムが止まるリスクに比べれば、常に小さく見積もられる。

この構造を理解したところで、明日の履修登録画面が美しくなるわけではない。ただ、あの画面の向こう側に、予算の制約と組織の力学と変化への抵抗が折り重なっていることは、知っておいて損はないだろう。

Read more

Dependabotの対応が面倒なのでRenovateを導入する

Dependabotくんはある程度の依存関係の更新を通知してくれるが、山のようにprojectを抱えているとなんとも痒いところに手が届かない。 ということで、Renovateを使ってみる。 Build software better, togetherGitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.GitHub ここからGitHub Appを入れる。 あとは、指示に従ってポチポチするだけで、超かんたんだった。 感想 自動化最高。

By Sakashita Yasunobu

nodejsのバグを見つけたのでPRを投げてみた

概要 要するに、node --testで特定のバイナリを標準出力に書くと、テストランナーが固まったり、異常終了したりするバグです。 バグ自体は既知のものだったようで、修正がされていました。 test_runner: infinite loop in FileTest#drainRawBuffer when child stdout contains FF 0F followed by large size bytes · Issue #62693 · nodejs/nodeVersion v25.9.0 (also reproduced on v24.14.1 LTS, v22.21.0 LTS, v23.4.0) Platform Darwin 25.

By Sakashita Yasunobu
青空文庫のParser

青空文庫のParser

青空文庫のParserを作ってます。 GitHub - P4suta/aozora: Pure-functional Rust parser for 青空文庫記法 (Aozora Bunko notation): ルビ, 傍点, 縦中横, 外字, 返り点, indent containers, page breaks.Pure-functional Rust parser for 青空文庫記法 (Aozora Bunko notation): ルビ, 傍点, 縦中横, 外字, 返り点, indent containers, page breaks. - P4suta/aozoraGitHubP4suta Rustで作ってますが、配布物はcargoのほかにnpm/pypiでも入手できます Documentation * Playground — try it in

By Sakashita Yasunobu