NGW開発BLOG
NGW の技術的な背景とアイデアの記録
該当する記事がありません。
-
メールクライアントは作らなかった — Roundcube を選んだ4つの条件
Webメール連携で、IMAPクライアントは自作しなかった。PHP製・無料・自社製品での実績・AutoLoginがある、の4条件でRoundcubeを選んだ。開けたらAutoLoginはサンプルだったが、選定は正しかった。
-
仕上げは、レプリ設定で収まる — 一度きりの手順を、何度でも回せる一本にした
二台を組んだ「あと」の仕上げ ― 保管先を分ける、最初のバックアップ、預かり、監視を映す ― が、いくつものボタンと手作業に散らばっていた。それを一本にまとめた。肝は機能の多さではなく「何度でもやり直せる」ことのほうだった。今日はそこに二つ足した。複製が運んでくる大きすぎるメモリの取り分を直す「最適化」と、預かりの一日二回化。
-
バックアップは「取った」ではなく「戻せる」 — 監視の緑が隠していた三つの穴
監視画面が一列に緑を並べていても、それが答えているのは「取れた」だけで、「戻せる」ではない。対象に書いてあるのに一度も取れていなかった DB、「取った」と言い張る画面、静かに何もしなかった「完全初期化」。この夏の運用でまとめて踏んだ、取得と復元のあいだの三つの穴。
-
バージョン表記に β を付けた — ベータ版の決め手は、機能が揃ったことではなかった
8月21日、メールを「収受転送」で添付ごと収受文書にできるメール連携が完成した。併せて道具が揃い、残るのは現地でしかできない試験だけになった。だからログイン画面の版数に β が付いた。夜3時の67秒、52時間の誤警報、複製した機体で死んだメール、そして再試験でのログ増分0行。
-
わしらは怪しいコピー隊 ― 138個だけが、どうしても写らないのだ
移行試験でファイル一式を写すことになった。408GB、73万個。Finderはぐんにゃり止まり、rsyncに乗り換えたら今度は138個だけが写らない。犯人はファイル名の切られ方であった。
-
LGWANに任意団体の事務局を持ち込んだら、つまづいたのはDatePickerだった
自治体向けの文書管理グループウェアに、任意団体向けの事務処理ツールを連携させた。一日の作業のうち、一番時間を食ったのは月名が英語で出ることだった。
-
負荷試験で壊れたのは、性能ではなく発信番号だった
何人まで耐えられるかを測るつもりで負荷試験を組んだ。だが出てきた不具合は、性能ではなく「正しさ」の問題ばかりだった。突破口は、デバッグのために溜めていた操作ログである。
-
Linux構築チームへ渡す — 私が Mac 使いのまま、新規団体のサーバを Ubuntu にした話
新規団体のサーバは Linux の実機にする。ただし私は Linux が苦手で、vi に至ってはお手上げである。だから組むのはパートナー企業にお願いすることにした。渡すのは Windows で動く構築ナビ一式。仮想環境の中で通してみたら、十を超える不具合と、送る直前にもう一つが出てきた。
-
phpMyAdmin も、いらなくなった — 本当に要る機能だけが残った
一ヶ月前に造った自作のSQLツールに、行の編集と削除を足した。カレンダーはブラウザ標準を捨てて自分で描いた。日付列を数えたら「0000-00-00」が974万件あったからだ。SQLを初めて書いたオフコンとORACLEの頃から、一列にカンマ区切りで持つFIND_IN_SETまで。要る機能だけを足していったら、phpMyAdminを開かなくなった。
-
取りに来るのか、送るのか — 仕様が決まらないまま、サイネージの「今日の会議」を無人化した
新しい庁舎の入口にデジタルサイネージが付く。そこへ「今日の会議」を出す。誰も更新しない仕組みにした。渡し方が決まっていないので、送る形と取りに来られる形の両方を用意した。作っている途中で、予約の時刻と会議の時刻は違うという当たり前に気づいた。
-
行ったり来たりで、よく忘れる — 構築の手順そのものをアプリにしたら、五つのバグが出てきた話
サーバ二台を建てるのに、三つのアプリを行ったり来たりしていた。順番は手順書の中にしかなく、覚えているのは私だけだった。それを工程順に案内するアプリにまとめたら、今まで見えていなかった不具合が五つ出てきた。どれも「動いているように見えて中身が違う」型で、人が目で見て気づけるものではなかった。
-
記憶なんて当てにならない — どこまで配ったか、どこまで配るべきかで悩んだ話
PDF共通関数は、外部ライブラリ用のディレクトリの下に置いてあった。それだけの理由で配布から落ち、呼び出す側だけが現場に届いた。関数が無いまま「対応済み」になるところだった。どこまで配ったのか、どこまで配るべきなのか。チェックひとつ付け忘れれば同じことが起きる仕組みを、憶えていなくても済む形に作り替えた一日。
-
リターンキーを、また「バーン」と叩くようになった — 体験用サーバ二台と、三十年前の手つき
二日かけて体験用のサーバを二台建てた。コマンドは覚えられないので、やることは全部ボタンにしてある。その途中で「画面にはオンと出ているのに誰も入れない Mac」に半日を溶かし、犯人は自分の設定ファイルの一行だった。そして夕方、自分がリターンキーを「バーン」と叩いていることに気づいた。昔やっていたように。
-
52時間、止まっていたのは見張りのほうだった — バックアップではなく、その周りを作り直した一日
朝、2台の画面が正反対のことを言っていた。片方は正常、片方は「52時間バックアップが止まっている」。追ってゆくと、バックアップは一度も止まっていなかった。止まっていたのは、それを見に行く先だった。その日、世代の預かりから監視アプリまで作って、最後にこう言われた。「十年後も正常に稼働しているためのバックアップシステムだと思う」。
-
「今日はここまでにしましょう」とAIに言われた — 完璧なバックアップは、たぶん無い
手順書をなぞって確認するだけの半日、のはずだった。終わったのは夜7時半で、コミットは20本を超えていた。5分ごとに静かに失敗していた同期、macOSが毎晩出す消せない警告、デモ機がCLONEを上書きしかけた事故。ついでにUSBケーブルが1本ポンコツだったせいで、新機能まで一つできた。そして最後に、疲れを知らないはずの相手から「今日はここまでにしましょう」と言われたのである。
-
毎晩3時に、ひとりでに立ち直る — 無人運用でつまずいた5つの落とし穴
現地に技術者はいない。Mac mini の上で動く Linux を、毎晩決まった時刻に止めて、立ち上げ直す。仕組みは半日で書けた。そのあとが長かった。ポートの奪い合い、SSHホスト鍵の食い違い、macOSの許可。どれも動いているように見えて、ある日静かに止まる種類だった。5つ潰した。実測ダウンタイムは67秒。
-
全部は運ばないほうが、きれいに移る — データ移行を保守コンソールのワンクリックにするまで
現行の Mac＋MySQL 5.7 から、新しい Linux＋MySQL 8.4 へデータを移す。全部を書き出して全部を読み込む。それで詰まった。新しい土台は古い書き方を受けつけない。答えは、運ぶものを減らすこと。そして「エラーが出なかった」ではなく「全部移った」を件数で確かめること。その一連を保守コンソールのワンクリックに畳んだ。
-
影武者は、本番の邪魔をしてはいけない — そっくりな予備機を、母艦を止めずに最新へ保つ
機器が壊れた日にすぐ入れ替えられるよう、本番そっくりの予備機を1台立てた。難所は動かすことではなく、本番に指一本触れずに最新へ保つことだった。派手なレプリケーションではなく、既にあるバックアップに相乗りする地味な同期に落ち着くまでの記録。
-
速いマシンは、優しい嘘をつく — 非力なLinuxがあぶり出した遅さを、母艦のMacごと直す
新しく建てたLinuxで、ホーム画面の起動に6秒かかった。RAMの潤沢なMacでは、この遅さが一度も表に出たことはない。非力な1台があぶり出したのは、何年も全職員が少しずつ払い続けていた全表スキャンだった。Linuxで見つけて直した手を、そのままMacへ持ち帰る。速いマシンほど、遅さを上手に隠す。
-
バックアップは、あるだけでは足りない — 静かに止まり、小さすぎて不安になった一日
前回建てたLinuxの土台に保守コンソールを載せた。ダッシュボードの数字が実機とずれていた。追うと、再構築のときにバックアップが静かに止まっていた。復旧させたら今度は6.5GBのデータが480MBに縮んで不安になる。バックアップは「ある」だけでは足りない。開いて、末尾まで揃っていると確かめて、初めてバックアップになる。
-
VMに、自分の住所は要らなかった — NGW初のLinuxサーバと「玄関を貸す」構成
NGWは20年ずっとMac上で動いてきた。次の10年に備えて、初めてLinuxの一台を建てた。仮想マシンを作るところまでは順調だった。つまずいたのはネットワークだ。VMに自分のLAN住所を持たせる計画は現実で通らず、ホストのMacを玄関として貸す形に落ち着いた。道中に現れた二つの脅し文句は、どちらも退屈な理由だった。
-
74件のうち、配るのは6件だった — 「更新日で選ぶ」が壊れた話
NGWの更新を配る仕組みは、とうに完成している。壊れたのは「何を配るか決める」ところだった。20年動いてきた「ファイルの更新日で選ぶ」が、AIと働き始めた途端に無関係なファイルを拾い出す。犯人はAIではなくgitだった。診断から、UPDATE MAKER を内容差分へ、さらに「案件を選ぶ」へ作り替えるまでの一日。
-
同じ図書館、日記なし — AIと交わした、技術の出てこない会話
半日の作業が片付いたあと、AIとの雑談が思いがけず面白くなった。コマンドラインはなぜ最強なのか。毎回違う人格に出会えるのか。そして——AIには記憶がない。HAL も Data もサマンサもドラえもんも覚えているのに、こいつは明日には忘れている。ならば CLAUDE.md とは何なのか。出張先のホテルの夜に交わした会話を、ほぼそのまま載せる。
-
つぎはぎのメニューを、一本の ngwMenu にまとめた話
同じデータから3通りに描かれていたNGWのメニューを、単一のサーバ描画メニュー ngwMenu に一本化した。標準とドロップダウンを1つの土台で出し分けるハイブリッド構成へ。150超のアプリを一切触らず、差引 −2,403 行。動くだけのコードを、読んで美しいコードへ近づける記録。
-
PNGからSVGへ — 次期NGWのアイコンを刷新する
次期バージョン（Linux）の、ずっとPNGだったアイコンを全点SVGへ。青×橙のフラットなベクターに一新する——ただの置き換えのはずが、AIと一日やり取りするうちに、DB移行バッチとアイコン設計ツールという実運用の道具が2つ残った、その記録。
-
NGWSqlAdmin — ないものは造る、私だけのSQL管理ツール
次期バージョンのLinuxで使うSQLツールが要る。多機能な有料版は、使わない機能ばかりだ。ならば造る。必要なものだけを伝え、AIとの対話で1本のPHPに仕上げた自作ツールの記録。
-
決裁箱を携帯する時代を、NGWで考える — 閉じた壁の、外から押す
弟分のCGWは最初からスマホが決裁箱だった。だが本丸のNGWは、外部から遮断された閉域網の中で動いている。出張の多い首長が、出先から決裁を押すにはどうすればいいのか。画面転送という現実解と、最新のサービス、そして保守にも同じ道が使えるという話を、正直に書く。
-
「かがみ書が反映されない」の取り違え — 一つの起案に、二つの宛先
「引用起案で保存してもかがみ書に反映されない」という問い合わせ。最初は意味が分からなかった。起案書とかがみ書は、宛先の違う別々の文書だった。その気づきと、判断を人に返す直し方の記録。
-
ひとり開発でも、GitHub — おいぼれになって、やっと腑に落ちた
リポジトリという言葉すら怪しく、commit・push・pull は呪文だった。バックアップのつもりで長年GitHubを使い、開発はいつも同じ一台。二台目を持ち歩きたくなって、ようやく同期の意味が腑に落ちた話。
-
みんな土日が休みではなかった
きっかけは「休暇の申請ができない職員がいる」というひとつの報告だった。雇用契約によっては、土日に勤務し火・木が休みという職員もいる。だがNGWは「休日とは土日と祝日である」という思い込みを、休暇・時間外・出勤簿・カレンダーの至るところに埋め込んでいた。それをたったひとつの式に一般化した記録。三つの環境への横展開と、カレンダーのバージョン違いを吸収した一手まで。
-
シャットダウンを、待たない — AIと「退勤打刻」を組み上げた半日のタイムライン
常駐している決裁通知クライアントに、PC起動＝出勤・シャットダウン＝退勤の打刻をやらせられないか。その一言から始まった半日を、提案・AIの回答・条件追加・実機試験での発見と改修まで、往復の順に記録した。ハートビート方式、操作ログの意外な転用、ネットワーク越しのIP食い違い。
-
決裁箱を携帯する時代 — スマホが、そのまま決裁箱になった
机の上の決裁箱は、画面の中へ移り、ついにポケットの中へ入った。NGWから機能を大幅に削って作った外郭団体向けグループウェアCGWは、最初からスマホを決裁専用の道具として設計した。館長や会長が事務所に居なくても、どこにいても決裁ができる。残念なのは、閉じた行政ネットワークの中では使えないことだけだ。
-
現場の困ったを、笑顔に変える仕事 — 昔の話をしよう
手元に一枚の古い基板がある。三菱のメインフレームから機器更新のときにもらってきた記念の板だ。白いセラミックの塊を何十個も並べてやっと一つのCPUだった時代。COBOL、緑の画面、テープの掛け替え。道具は変わり果てても、やっていることは40年前と同じだと気づいた話。
-
一部の端末だけが固まった — 大更新に潜む罠
最新へ大きく上げたダイアログライブラリが、一部の端末でだけログイン画面を覆って固まった。手元では再現しない不具合の核心を、現場のDOMが指し示す。原因特定より「依存の排除」で直した後日談。
-
サロゲートペアだけじゃなかった、日本語の難しさ — IPAmj明朝で解決した話
拡張漢字（サロゲートペア）を倒して外字は終わったと思っていた。ところが「囬」という一字が豆腐になった。原因はコード範囲ではなくフォントのカバレッジ。NGWの明朝をIPAmj明朝に切り替えるまでの話。
-
オンライン決裁は、進むか、やり直すかだけ — 決裁を、二択に整理した
紙の決裁は、いま案件がどういう状態なのか外から見えなかった。NGWのオンライン決裁は、決裁者の選択を「承認して進む」か「差し戻してやり直す」かのふたつに絞った。不在の停滞は代決・引き上げで逃がし、決裁中はロックする。文書管理シリーズ第8回。
-
文書管理は、捨てるためにある — 引継と廃棄が、本当の仕事だ
文書管理と聞くと、大切にためて取り出せるようにすること、と思うかもしれない。だが本当の目的は逆で、要らなくなった文書を、期日どおりに適切に捨てることにある。ためるのは簡単、正しく捨てるのは難しい。引継・廃棄という文書管理の本題。文書管理シリーズ第7回。
-
最初からXLSXで出す — どうせExcelで開くのだから
データ出力といえばCSVが定番だ。だが役所のデータをCSVで出すと、先頭のゼロが消え、コードが日付に化け、文字が壊れる。そして利用者は、結局それをExcelで開く。ならば最初からXLSXで出せばいい。NGWの出力はXLSXにした。文書管理シリーズ第6回。
-
決裁の時間を縮める、それがDXだ — 決裁箱を知らない世代が、もう庁舎にいる
NGWにとってのDXは、派手な新技術ではない。決裁を速くする、ただそれだけだ。2023年に作ったオンライン決裁は、紙とハンコの併用を残したのに、導入団体では8割以上が電子で決裁されている。長年の慣習は、正しい道具さえあれば、いとも容易く変わる。文書管理シリーズ第9回。
-
紙への印刷は、全てPDFにした — 帳票は一字もずらせない
役所の帳票は、罫線一本・一字のズレも許されない。だからNGWは画面から直接印刷するのをやめ、印刷をすべてサーバ生成のPDFに通した。PDFは紙面を固定するだけでなく、そのまま保存できる——ペーパーレスの土台になる。文書管理シリーズ第5回。
-
今ある棚と簿冊を、登録するだけ — 現状から始める文書管理
文書管理システムというと「まず全部を理想の形に整理してから」と身構える。NGWは逆で、今まさに使っている棚と簿冊を、そのまま登録すれば動き出す。理想のライフサイクルは、導入してから育てればいい。低い入口こそが、続く文書管理の条件だ。文書管理シリーズ第4回。
-
文書管理規程は、どこも似ている — なのに、誰も読んでいない
どの自治体にも文書管理規程があり、その中身は驚くほど似ている。だが正直に言えば、日々それを読んでいる職員はほとんどいない。読まれない規程を、どうやって現実の動きに変えるか。受発番号の「一連番号」を10,20,30と読み替えた話を例に、NGWは規程を「動く仕組み」に翻訳する。文書管理シリーズ第3回。
-
収受と起案は、受発簿から始まった — 文書の所在を管理する
NGWの文書管理は、大きな設計図からではなく、情報公開法に応えるための「文書の所在管理」から始まった。外から来る収受と、内から起こす起案。その二つの入口を、受発簿という一本の台帳で押さえる。文書管理シリーズ第2回。
-
全ての文書は、分掌事務で管理する — 業務は、分掌事務でしかない
役所の文書を「課・係」で管理すると、組織改編のたびに壊れる。NGWは文書を、条例で定義された分掌事務に紐づけて管理する。業務の実体は分掌事務でしかなく、組織はそれを盛る器にすぎない。文書管理シリーズの第1回。
-
AIが、初めてのWindowsアプリを書いた — 決裁通知クライアント NgwNotificationClient
オンライン決裁は決裁者を名指しで通知するが、NGWを開かなければ気づけない。文書管理だけのDOCU団体では毎日は開かない。そこでWindowsのトースト通知で知らせる常駐クライアントを、GET方式で、Goで作った。長く手が出せなかった初のWindowsアプリを、AIがあっという間にプロトタイプにした話。
-
メニューを、データで管理する — アプリメニューと NGWT_APP_MENU の JSON
NGWはアプリごとに専用のメニュー体系を出す。40超のアプリに40通りのメニュー。それをHTMLにベタ書きせず、NGWT_APP_MENU テーブルの1列にJSON配列として持つ。起動可能アプリは職員区分ごとに NGWT_BOOT_MANAGER で管理し、メニューで隠し起動で防ぐ。データで持つから、並べ替えも権限の出し分けも自治体ごとの差し替えも、デプロイなしでできる。
-
ひとりのワガママは、みんなの設定 — 個人設定 ngwPersonalInfo と Property枠
「カレンダーは日曜始まりがいい」「いや月曜だ」。どちらも正しい主張を、NGWはどちらかに決めず、各自で選べる個人設定に昇格させる。ngwPersonalInfo.php と NGW_STAFF_PROPERTY の汎用Property枠、そして「みんなの既定＋ひとりの上書き」という設計の話。
-
日付は和暦で見せる — 日付ピッカーと ngwFunc_SWHenkan
役所の日付は和暦で表示する。単純な整形に見えて、改元・元号の表記ゆれ・区切りと、制度の重みが詰まっている。NGWはそれを ngwFunc_SWHenkan というひとつの関数に集約し、CreateDBWebで「DATE」と定義するだけで和暦の日付ピッカーが生成される。
-
セレクトボックスは6行で作る — 共通ヘルパー（function）に揃える
NGWには数えきれないほどのセレクトボックスがある。それを、たった6行とひとつの共通関数ngwFunc_MakeSelectBoxに統一している。しかもその6行はCreateDBWebが生成する。手書きしないから、ばらつきが入らない。
-
NGWを作るアプリ「CreateDBWeb」 — テーブルを定義すれば、動くアプリが生まれる
NGWの画面の多くは手書きではなく、DBのテーブル定義から自動生成されている。その生成器がCreateDBWebだ。架空のNGWT_SAMPLEテーブルを題材に、「アプリを作るアプリ」の仕組みと、それがNGWの一貫性を支えている理由を書く。
-
NGWのアプリはどう動くか — SubModeという背骨
「ひとつのアプリが動く仕組み」を公開していく連載の第1回。すべての画面が従う共通の型＝SubModeディスパッチと、描画→部分再描画→確定→帳票というライフサイクルを、実際のコードで解説する。
-
FullCalendarで行政カレンダーを作る — 9時間のズレとLGWANの壁
自治体グループウェアにカレンダーを載せる。FullCalendarを使ってみると、9時間ずれる時刻、週の始まり、日本語化、フェリー、特別職、そして閉域網LGWANという壁が次々に現れた。その記録。
-
TCPDFを座標でなく行・列で組む — 汎用機のチャート用紙という発想
TCPDFはx,y座標で要素を置く。だが帳票は方眼のように「行と列」で考えたい。汎用機時代のチャート用紙にならい、行・列で組める薄いレイヤーをTCPDFに被せた設計の記録（初出2024年の記事を再構築）。
-
「少し大きく」で、ちゃんと伝わる — アナログな注文が数値になるまで
「少し大きく」「ちょっとだけ下に」。数値ではなく、そんな曖昧な言葉でよく指示する。AIはその尺度を学んでいる気がする。最後は数値に落ちるのだが、何度もやり直すこの往復が、なぜか面白い。
-
AIは、私のコーディングのクセまで真似てくれる
NGWを開発して10年。命名規則も書き方も、私という一人の書き手の流儀でできている。新しく足すロジックを、AIはその流儀そっくりに書いてくれる。均質さは、そのまま読みやすさになる。
-
このブログは、AIとの対話の記録である
NGW開発BLOG は、AI（Claude）との対話をもとに構築・執筆した。サイトの仕組みも、最初に並んだ記事群も、その協働の産物である。何をAIに任せ、何を人が担ったかを正直に記録しておく。
-
「流行に乗り遅れるな」から始まった — AIを開発に迎えるまで
軽い気持ちで試したAIコーディングが、いつのまにか開発の相棒になっていた。導入のきっかけ、6月にClaude Codeへ乗り換えた経緯、そして何が変わり、何は変わらないのかを正直に記録する。
-
このブログをCMSなしで作った理由 — 静的HTMLという選択
技術ブログにCMSもSSGフレームワークも使わず、Node標準ライブラリだけの自作ビルドで静的HTMLを吐く構成にした。道具の複雑さを問題の複雑さに合わせるという設計判断の記録。
-
NGW開発BLOG をはじめます
自治体向け行政システム NGW の設計判断や実装の裏側を、少しずつ言葉にして残していくブログを開設しました。その辞（ことば）です。
-
「見せない」を権限で設計する — 文書管理のプライバシー保護
機微な文書を「隠す」機能を作ると、UIで消すだけでは足りない。所属×役職以上の二軸判定と、取得段での秘匿という原則を、あらゆる参照経路の一貫性から考える。
-
テキストに画像を混ぜると崩れる — 帳票グリフ差込みの3つの罠
BMP外の文字をベクター画像として帳票本文へ差し込むと、テキストなら自然に効いていた色・縦揃え・行数の前提が崩れる。混在レイアウトで遭遇した3つの罠とその補い方を綴る。
-
外字をSVGで差し込む — 純PHPでTrueTypeの輪郭を抽出する
BMP外の一文字だけを検出し、そのグリフ輪郭を純PHPでSVGに起こしてPDFへ差し込む。豆腐問題の解決編。
-
名前と実体が食い違う関数を掃除する — フォント設定のリファクタ
帳票PDFのフォント設定関数群が長年の変更で荒れていた。名前が嘘をつく関数をどう安全に掃除したか、その過程で見えた命名の価値を綴る。
-
PDFで「𠮷」が豆腐になる理由 — TCPDF とサロゲートペア
純PHPのPDFライブラリTCPDFがBMP外の漢字を出力できず「豆腐」になる。フォント差し替えでは直らない理由を、符号がGID 0へ落ちるエンコード経路から追う。
-
「今の所属」で過去を絞ってはいけない — 申請日時点の所属で判定する
決裁状況を所属で絞るとき、現在の所属で判定すると、異動者の過去の申請が異動先の部署に現れてしまう——見えてはいけない申請が見えてしまう。正しくは申請日時点の所属で判定する話。
-
複合索引ひとつで決裁一覧が変わる — 全表スキャンを畳む
職員ごとの決裁状況一覧が本番規模で遅くなった。複合索引を1本、列順を正しく張るだけで全表スキャンとfilesortが消えた話。
-
時間外は「区間」で表す — 単一ブロック描画をやめた話
時間外勤務の自-至表示。合計から逆算する単一ブロック描画をやめ、勤務区間の配列を集計と共有する設計に直した記録。
-
派生フォークを「構成一致」でなく「振る舞い一致」で同期する
本体から勤怠だけを切り出した派生フォークを同期する話。構成の一致を捨て、振る舞いの同等性を実体で判定するという設計判断の記録。
-
移行を「登録」と「付替え」に分ける — 一括処理の設計
組織再編に合わせた財産・備品の一括移行。新しい所属コードが登録作業に間に合わないという制約から、処理を「登録」と「付替え」の二工程に分けた設計を綴る。
-
壊さずに直す — 件数アサート付きの冪等な一括置換
ファイルを丸ごと差し替えられない環境へ同じ修正を手で当てる。件数アサートと冪等性チェックで置換を検証つきの適用に変える型を紹介する。
-
インストーラを自分で管理者昇格させる — Windows UACと共存の実際
セットアップexeが更新時にAccess is deniedで落ちる。マニフェストでなくコードで自己昇格を選んだ理由と、実機で確かめたUAC共存のポイントを綴る。
-
空文字で検索したら、消したはずの行が返ってきた — MySQLの型変換
新規登録画面で、IDがまだ空なのに既定の行が選択済みになる。犯人はSQLの暗黙型変換で、空文字が数値0に化けて残骸行を掴んでいた話。
-
「?v=」で一度だけキャッシュを捨てる — 静的アセットのバージョン付け
JS/CSSを大きく差し替えたのに更新が効かない。原因はブラウザや中間キャッシュが掴む古いファイル。固定のバージョン文字列で一度だけキャッシュを無効化する運用を追う。
-
337箇所を書き換えずに SweetAlert2 を大更新する — 互換シム
ダイアログ表示ライブラリ SweetAlert2 を古いv3系から最新のv11系へ更新した。約337箇所・173ファイルの旧API呼び出しを書き換えず、ライブラリ末尾に薄い互換シムを1枚足して橋渡しした話。
-
休暇の「1日」は勤務時間と同じではない — 時間→日数換算の罠
時間単位の休暇を日数に換算するとき、割る数を「1日の勤務時間」にすると間違う。制度上の「1日」が持つ文脈依存の定義を掘り下げる。
-
本番相当のデータで性能を測る — 見積りが信頼できる検証環境
少量のテストデータでは性能問題は再現しない。本番と同規模・同分布のデータを手元に置くと、EXPLAINの見積りが実運用の見積りとして信頼できる理由を綴る。
-
動いているものを止めずに次を作る — 本番と次期版の二本立て開発
稼働中の本番版と大きく作り替え中の次期版を並行開発する。同じ論理修正を食い違う2つのコードベースへ確実に当てる運用の設計判断。
-
「唯一の基準」を作る — 二重実装が生む静かなズレ
同じ計算や判断が複数箇所に重複すると、片方だけ直して片方が古いまま、という静かなズレが必ず生まれる。NGWの開発で何度も立ち返った「唯一の基準」という設計原則を、集約の実務と落とし穴とともにまとめる。
-
決裁者は「いつ時点の役職」で決まるか — マトリクスの基準日
決裁経路の役職から決裁者を解決するとき、どの日付時点の人事配置で写像するかで結果が変わる。時点を持つデータの設計論を綴る。
-
「所属は1つ」という前提が崩れるとき — 兼務と共通所属
職員は1つの所属に属する、という素朴な前提が兼務と共通所属で崩れたとき、文書管理はどんなバグを生み、どう直したかを綴る。
-
2系統のIDを1つのカラムで共存させる — オフセット方式
独立したAUTO_INCREMENT主キーを持つ2つのテーブルのIDを、下流の1カラムで取り違えなく共存させる。スキーマ不変・最小侵襲を優先して選んだオフセット方式の設計と落とし穴。
-
「係長」という役職名は、思ったより難しい
決裁欄の役職名は「所属名＋長」で組み立てられそうに見える。だが制度の現実は例外だらけだ。例外を消さず、一箇所に閉じ込めて名前を付けるという設計判断を綴る。
-
同じ役職名を6箇所で組み立てていた — 唯一の生成点に集約する
決裁欄の「◯◯課長」を作るロジックが帳票・画面・マトリクスに6重複し、画面ごとに表示がズレていた。唯一の生成関数へ集約するまでと、差分ゼロを確認してから切り替える移行のポイント。
-
操作マニュアルをMarkdownで書く — Marpでスライド/PDF化する
操作マニュアルをWordでなくMarkdownで書き、MarpでPDF化する。ドキュメントもソース管理する運用の記録。
-
switch を match に変えたら、静かに壊れた — PHP 8 の厳格比較
PHP 7→8 移行で switch を match に一括変換したら、DB から int で返る値と文字列定数の比較が === で外れ、値が静かに default へ落ちた。型契約を意識せよという教訓。
-
定数をコードでなくデータベースに置く — 団体差を吸収する仕組み
団体ごとに変わる設定値を定数としてDBに持ち、起動時にdefineする設計。その利点と、型・存在をコード側で守る契約について。
-
NGWとは — 自治体の内部業務を支えるグループウェア
市役所・町村役場の内部事務と意思決定を支える行政システム「NGW」の全体像と、その設計に潜む行政システム特有の難しさを概観する連載の第一回。