LGWANに任意団体の事務局を持ち込んだら、つまづいたのはDatePickerだった
自治体向けの文書管理グループウェアに、任意団体向けの事務処理ツールを連携させた。一日の作業のうち、一番時間を食ったのは月名が英語で出ることだった。
役所の職員は忙しい。
そのうえで、業務そのものではない仕事を抱えていることがある。防犯協会、体育協会、公民館運営委員会、祭りの実行委員会。この手の任意団体の事務局を、担当課の職員が兼ねることがある。会計も、総会資料も、会議録も、本来の業務時間外に作っている。
私たちはこの二つに、別々のツールを作っていた。
- NGW — 自治体向けの文書管理グループウェア。LGWAN環境で動く
- CGW — 民間等の任意団体向けの事務処理ツール。インターネットで動く
CGWは、年間行事予定を立て、文書を収受し、起案し、会議録を記録して、オンラインで決裁できる。さらに予算管理から伝票処理へ進み、決算を集計して決算書まで作る。総会資料の主な書類は、CGWから出せる。
任意団体の一年は、だいたいこの8つで回る。行事を決め、文書をやりとりし、会議を記録し、金を管理して、決算を出す。そのすべてに決裁が要るのが、団体運営の面倒なところだ。
団体が単独で使うぶんには、インターネットからアクセスすればいい。だが事務局を担っているのは役所の職員で、その職員は日中ずっとLGWANの中にいる。別のネットワークにある別のツールを、片手間に開きに行くのは現実的ではない。
だから、インターネット版のCGWをLGWANのNGWに連携させた。この記事は、その仕上げをした一日の話である。
欠点は最初から分かっていた
LGWANの中にCGWを置けば、外部の人が入れなくなる。
団体の役員が役所の職員だけということはまずない。地域の代表者、学校関係者、団体の会計担当。その人たちはLGWANに入れないので、外部の人の決裁だけはオンラインにならない。 これは連携の構造上、どうにもならない。
それでも連携する価値があると判断した。事務局の職員は、年間行事予定も、収受も、起案も、会議録も、予算も伝票も決算も、普段使っているNGWと同じ場所で、同じ画面の作法のまま触れるようになる。ネットワークをまたぐ手間と、書類を手で組み直す手間が消える。
欠点を一つ残しても、事務処理が楽になるほうが大きい。
画面をLGWANに馴染ませる
連携で一番効いたのは、NGWのライブラリをそのまま共有したことだった。
CGWは自前の lib を持たない。jQuery、Bootstrap、FontAwesome、DataTables、FullCalendar、PDF生成のTCPDF — すべてNGW側のものをURLで参照している。CSSも同じテーマファイルを見る。
結果として、CGWの画面はNGWの画面と見分けがつかない。同じヘッダ、同じアプリメニュー、同じ和暦の日付入力、同じカレンダー。職員から見れば、NGWの中に団体用のメニューが一つ増えただけに見える。学習コストがほぼゼロになる。
ただしこれは借り物である。CGWを単独の機体（インターネット版）へ出すときは、必要な分をコピーして参照先を書き換えないと、全画面でCSSとJSが404になりPDFは落ちる。宿題として残してある。
移植は、そのまま持ってくることではなかった
この日の本題は、NGWの「行事予定」をCGWへ移すことだった。年間行事予定は総会資料の柱なので、これが無いと話にならない。
テーブル定義も画面もNGWにある。一対一で写せば終わり — と思っていたが、二か所で立ち止まった。
一つは、絞り込み。 NGW版は部門で絞らず全件を出す。役所の行事予定は全庁で共有するものだからそれでいい。しかしCGWは一つのデータベースに二十を超える団体が同居する。そのまま持ってくると、公民館の予定に別の公民館の予定が混ざる。抽出条件に団体を足した。
もう一つは、参加者管理を作らなかったこと。 移植元には無いが、スケジュール機能には参加メンバーの管理がある。付けるべきかを訊いたら、答えは明快だった。
「メンバーは考えない。行事は団体全員で共有するから」
役所の課と違って、任意団体は人数が少なく、行事は全員が知っておくべきものだ。誰が登録したものでも、団体の誰でも直せる。 権限を作り込まないことが、この規模では正解になる。旧データを引き継いでいたメンバー管理のテーブルは、まとめて捨てた。移植の差分は、追加3,094行に対して削除6,142行になった。
総会資料は、展開してはいけない
活動報告書のPDFを作るとき、一つ判断が要った。
「毎月第2土曜日」のような繰り返しの予定を、実施日ごとに一行ずつ並べるか、繰り返しの条件のまま一行にするか。
前者のほうが「報告書」らしく見える。だが、毎週の予定が一つあるだけで年間五十行を超える。資源回収と役員会と定例会が並んだ時点で、総会で配れる紙ではなくなる。
後者を選んだ。
| 日程 | 区分 | 活動名 |
|---|---|---|
| 令和7年4月1日〜令和8年3月31日 毎月第2土曜日 | 清掃 | 資源回収 |
| 令和7年5月24日(日) 10:00〜12:00 | 総会 | 定期総会 |
| 令和7年8月1日(土)〜8月2日(日) | 行事 | 夏祭り |
一覧は読ませるためにある。網羅するためではない。
対象期間は年度で、年度の開始月は団体マスタの設定に従う。会計年度が4月始まりでない団体があるためだ。
去年の行事を、今年にドロップする
NGWにはないCGWだけの新機能が、これだった。動機は利用者の一言である。
「前年度を踏襲して、同時期に今年度も予定を入れることが、よくあるので」
言われてみれば当たり前で、任意団体の年間行事はほとんど毎年同じである。総会があって、清掃があって、夏祭りがあって、年末に大掃除をする。去年の予定表は、今年の予定表の下書きとして完成している。
そこで、カレンダーの左に前年度の活動を並べ、右のカレンダーへドラッグ＆ドロップすると、その日付で今年度に登録されるようにした。
落とした日を開始日にし、期間の長さは保ったまま移動する。二日間の夏祭りを8月1日に落とせば、8月1日〜2日で入る。時刻も場所も区分も引き継ぐ。日付だけを、今年の曜日に合わせて決め直せばいい。
これは入力の省力化に見えて、実のところ共有の道具だと思っている。年度の頭に去年の一覧を左に出すと、「いつ頃、何をしなければいけないか」が一枚で見える。事務局が一人で抱えていた年間の段取りが、画面に出る。
つまづいたのは、DatePickerだった
ここまでは順調だった。時間を食ったのは、まったく別のところである。
日付入力の月の選択が英語だった。 Jan、Feb、Mar。曜日もMo、Tu、We。年も西暦のまま。NGWでは日本語で、しかも和暦で出ているのに、である。
日本語化のファイルは読み込まれている。中で setDefaults も呼んでいる。それなのに効かない。私は原因の特定を諦めて、日付入力を作る側で日本語の設定を明示的に上書きするという小細工に逃げた。既定値がどうあれインスタンス指定のほうが強いので、これで見た目は直るはずだった。
直らなかった。そして利用者から、こう言われた。
「NGWの
ngwFunc_MakeDatePickerJを見てください。ライブラリーが同じならこれでいいはず」
その通りだった。同じ /ngw/lib を共有しているのだから、NGWで日本語なら、CGWで英語になる理由はどこかにある。 小細工で覆い隠すのではなく、その理由を探すべきだった。
読み込み順を並べ直して、見つかった。
NGW: jquery-ui → datepicker-ja 日本語のまま
CGW: jquery-ui → datepicker-ja → ympicker 英語で上書きされる
CGWだけが読んでいた年月ピッカーのライブラリが、jQuery UIのdatepickerを丸ごと同梱していた。 英語の月名・曜日名も、既定値を設定する処理も、和暦表示を差し替える処理も、全部その中に入っている。それが日本語化ファイルの後に読まれるので、日本語化が丸ごと巻き戻されていた。NGWはこのピッカーを読まないので、無傷だっただけだ。
読み込む順番を入れ替えたら、月も曜日も和暦も、一度に直った。ついでに日付入力の実装をNGW版とオプション単位で突き合わせ、差分ゼロにした。逃げの小細工は消した。すると、CGWの全画面の日付入力が同時に直った。土日と祝日に色が付き、週の始まりが日曜になった — NGW版には最初から入っていたのに、CGW版には無かったものだ。
ライブラリを共有していても、読む順番が違えば別物になる。 そして、動いている実装が手元にあるなら、まずそれと突き合わせる。 自分の推測から書き始めてはいけなかった。
隙間は、計算では埋まらなかった
同じ日にもう一つ、同種の失敗をしている。
モーダル画面のメニュー帯が、左右にわずかな隙間を残していた。私は、内側の要素にかかっている余白を足し算して、その分だけ負の余白で打ち消そうとした。16px、15px、−5px、15px。合計41px。合わせたつもりが、まだ残る。
三度やって、三度外した。
最後に、帯をモーダルの本文の中から出して、ヘッダと同じ親の子にした。 親が縦方向のフレックスなので、子は何もしなくても同じ幅に伸びる。打ち消すべき余白が、最初から存在しなくなった。CSSは一行になった。
合わない数字を合わせにいくより、数える必要のない形に変えるほうが早い。
事務局の負担は、どこへ行くのか
この日でやったのは、行事予定の移植、活動区分マスタ、総会用の活動報告書PDF、前年度からのドラッグ登録、それと画面の細かい手直しである。残っているのは決裁まわりの確認だけになった。
出来上がったものを引いて眺めると、新しく作った機能は少ない。 大半は、すでにNGWにあるものをCGWの文脈に置き直す作業だった。団体で絞る、権限を作らない、繰り返しを展開しない。どれも「何を持ってこないか」を決める仕事だ。
事務局を兼ねている職員にとって、この連携で減るのは操作の手数ではない。別のネットワークに切り替えて、別の作法のツールを開いて、去年の紙をめくって、今年の予定を書き写す — その一連が消える。去年の一覧を左に出して、今年の日付へ落とすだけになる。
任意団体の事務局は、たいてい引き継ぎの資料が薄い。前任者が何月に何をしていたかは、去年の予定表にしか残っていないことが多い。その予定表を、そのまま今年の下書きにできるようにしたのが、この日の一番の成果だったと思っている。
AIとの協働作業での学び
この日、私の手を止めたのは自分の推測で、前へ進めたのは利用者の一言だった。
DatePickerが英語のままだったとき、私は原因を探すのをやめて、日付を作る側で日本語を上書きするという小細工に逃げた。AIと相談しながら書いたその小細工は、それらしく効きそうな形をしていた。だが直らなかった。 直したのは「NGWの ngwFunc_MakeDatePickerJ を見てください」の一言である。
ここが今回いちばん効いたところだと思っている。同じライブラリを読んでいるのに、片方だけ英語になる。 ならば理由は必ずどこかにあって、覆い隠すのではなく探せばよかった。読み込む順番を入れ替えただけで、月も曜日も和暦も、土日祝の色まで一度に直った。小細工では絶対に届かなかった範囲である。
そして、AIはこちらが渡した材料の中で最善を尽くす。私が「原因が分からない」と言えば、分からないまま動かす方法を一緒に考えてくれる。「NGWでは日本語で出ている」と最初に伝えていれば、推測ではなく差分を見にいったはずだ。何を渡すかは、私の仕事だった。
これは前回、対策と検証を同じ手で書いて「緑」になった話と根が同じである。自分の頭の中だけで閉じると、間違いも一緒に閉じ込められる。
モーダルの隙間も、同じ形をしていた。16px、15px、−5px と足し引きして、そのたびに外した。最後に効いたのは計算ではなく、数える必要のない形に変えることだった。CSSは1行になった。合わない数字は、合わせにいくものではなかった。
最後に、この日いちばん地味な学びを1つ。
移植で書いたのは、追加3,094行に対して削除6,142行だった。 参加者管理を捨て、権限を作り込まず、繰り返し予定を展開しない。持ってこないものを決める作業が、移植の大半を占めていた。
「NGWのこの機能をCGWへ移して」と頼めば、AIはたぶん全部きれいに移してくれる。移さないものを決められるのは、現場を知っている側だけである。
移植したのは行事予定機能（テーブル2本）。列定義はNGW側と一対一で揃え、団体を表す列だけをCGWの団体CDに割り当てた。繰り返し予定は7区分（開始日時／期間／期間毎日／毎週の曜日／毎月の日にち／毎月の曜日／毎年の日にち）をそのまま移し、カレンダー表示時に日付へ展開する。前年度からの複製は、開始日をドロップ先に置き、終了日は元の期間長を保って平行移動する。他団体のレコードは複製できないようにしてある。PDFはTCPDFで、繰り返し予定は展開せず条件を文章化して1行に畳む。日付入力の日本語化は、年月ピッカーが同梱するjQuery UI datepickerに上書きされていたため、ロケールファイルを最後に読むよう並べ替えて解決した。