魔改造Redmineによる"シフト管理ポータルチケットシステム"を供養する。

この記事の目的

はじめましてこんにちは🤗
大阪公立大学で職員をしている中村といいます。
　そういえばTryangleという名前でPublishingをしていたのに、自分たちがどういった組織なのかを説明していませんでした。
　詳細は別記事をいずれ用意するとして、ここでは簡単に説明しますと、本学では学内での学生雇用なんかの一貫として、私が所属する情報系の部署では高いITスキルを持つ（）学生をいろいろな形で集めてなんやかやしています。
　この学生のスタッフたちが使うためのシフト管理システムは、5年ほど前に学生たち自らで構築したものでした。
　現在、新しいシステムを構築していますが、このシステム（Octopus）が単に落として葬ってしまうにはもったいない！いい出来です。
　そこで、スクショによる見栄えだけですが…供養として紹介します。

魔改造Redmineによる全部乗せシステム

今回ご紹介するOctopusはすべてRedmine標準の機能とVC（View Customizeプラグイン）のみによって作られています。

まず、学生スタッフには種類があり、MS、SSがあると思ってください。
・MSさんは、どっちかというと教室の管理運用や常駐スタッフ的な感じです。
　人数（シフト）が多く、定型業務が多い仕事です。
・SSさんは、どっちかというとチケットに割り当てられた仕事をする感じです。
　急ぎがなければできる作業を選んで行えるのでチケット管理と相性〇です。

この二つの存在のどっちもを欲張りに1システムで管理しよう、しかもWikiも何もかも全部使おう！というのがOctopusです。
　大体こういう仕様です。

・１勤務を１チケットとして、勤務用チケットによってシフト管理をして、
　報告用チケットを勤務報告書代わりにしています。
　→最終的に報告したものがTeamsにWebhookで飛びます。便利！
（ただ、Incoming Webhookはもうすぐなくなっちゃうらしいので丁度システム更新するタイミングといえばそうですね）

・各所属（MS、SS）はチケットの詳細が違います。ここは個別のチケット内容の作りこみで対応しています。例えばMSなら教室の巡回記録など、SSの場合は自由記述の消化チケット申告等…。

・ナレッジとしてのwikiを豊富にすることでポータル機能も完備。

Pros/Cons

pros

・Redmineのみで完結している。
今は（バックエンド・ミドルウェアを例えばAirtabelやもっとコンシューマー向き（で高すぎる）なkintoneなど…）やろうと思えば様々な方法がありますが、複数システムを連携させてしまうとそれぞれの知識がいりますが、このシステムはオンプレRedmineだけで何もかもを行えるのが素晴らしい。Redmineって発明だよな～。
・複数種類の雇用に対応している。
これって結構大事ですよね。世の中のシフト管理システムって、単にカレンダーと打刻機能だけのものが多いですが、複数種の報告用チケットをつけたことにより、さまざまな雇用体系とまた日報機能に対応しています。

cons

・VCの限界
VCは直接ソースをいじらない・でも直接中身をいじれるという点では優れたアドオンだと思いますが、VCにVCを重ねた経年的保守のせいで、まあちょっとお見せできる状態ではないですね。
・内部完結しすぎたかも
（そもそも当時は現在のSSOもなかったのでよかったっちゃよかったのですが）Octopusでは手動で内部にユーザーを作る必要があり、その管理やらなんやらが結構大変です。

実際のシステム

雇用種別ポータル

こんな感じです
　これはMS向けポータルになります。
　要は、Wikiですね。それをスタートページ代わりにしていて、十分な機能を持ったポータルになっています。見栄えもいいですね。MSさんはチケット管理システムとしては使わないので、シフト管理にフォーカスしています。
　では、シフト管理部分をみてみましょう。

シフト管理画面

カレンダー
　
サマリー
魔改造カレンダーによって誰がどこのシフトに入っているかがわかるカレンダーです。
黒塗りは当然名前が入っていると思ってください。
もちろん、月のサマリーも。すばらしいですね～。

チケットの中身

書き込む画面
　

見る画面

はっきりと便利ですよね！
カスタマイズされた入力フォームにわざわざノーコードツールなんていらんかったんや！
「チケット」という書き込み・閲覧のベース単位になるテンプレート仕様が無駄なく活かされています。
もともと、チケット管理システムって一般ユーザのバグ報告管理用で発展してきたシステムだと思うので、エンドユーザーに確実な定型の処理を「押し付ける」っていうのがいいんですよね～。

そして伝説へ…

Redmineというハコの仕様が緩いおかげとVCでの根性カスタマイズによって、大学統合という大きな事象にも耐えたこのOctopusくんですが、サーバの耐久年数や運用変更などが重なり、引退の運びとなりました…。

ですが！
内製シフト管理システムの夢は消えちゃいねえ！
次の更新で、さらなる次の魔改造をお見せできればと思います。

宣伝

というわけで、大阪市立大学の優秀な学生による魔改造Redmineのチョイ見せでした。
どうでしょう？
頑張ればやれそうだけどやるのは大変なラインじゃないですか？
手作り感もあって好きなんですよね。なくなる前に記事に残せてよかったです。

さて、思い出したかのようにいうのもなんですが、本学大阪公立大学ではこのように学内での開発活動もしています。
現在はメンバー募集を行っていないため、これを含め特に勧誘目的の記事ではないのですが、この機会に活動に興味もっていただけたら幸いです。
本学での活動の珍しい点は大学公認ということでしょうか。
現在システムとして学外に公開しているものは授業カタログ（https://catalog.sp.omu.ac.jp/ )のみですが……こういった活動でチーム作りや運営、またはシステム構築をしながら、いつでも何かの機会に飛びつけるように学生スタッフの皆さんに腕を磨いていただいています。
　大学組織あるある（って勝手に言っていいのかな…w）の硬直気味の保守的な体制と実際若い学生の目線でのDXのイケイケ感という相反する属性をいつかよい感じにミックスできたらと思っています。

そしてその活動の一環として本Publishでは、昨年度の一年を通して皆さんに記事を書いていただきました。
お題は完全ゼロでおまかせ、編集だけ少し僕が手を入れました。
僕はみんなそれぞれのレベルでちゃんと小さくても発見をしていて、どれもいい記事だなと思ってます。
このレベルの自分で考えることができて経験ある新人を揃えるのは、普通の企業でも結構難しいのではないでしょうか。

今年度もよろしくお願いします。