「設計」の記事
40 件
-
メールクライアントは作らなかった — Roundcube を選んだ4つの条件
Webメール連携で、IMAPクライアントは自作しなかった。PHP製・無料・自社製品での実績・AutoLoginがある、の4条件でRoundcubeを選んだ。開けたらAutoLoginはサンプルだったが、選定は正しかった。
-
仕上げは、レプリ設定で収まる — 一度きりの手順を、何度でも回せる一本にした
二台を組んだ「あと」の仕上げ ― 保管先を分ける、最初のバックアップ、預かり、監視を映す ― が、いくつものボタンと手作業に散らばっていた。それを一本にまとめた。肝は機能の多さではなく「何度でもやり直せる」ことのほうだった。今日はそこに二つ足した。複製が運んでくる大きすぎるメモリの取り分を直す「最適化」と、預かりの一日二回化。
-
phpMyAdmin も、いらなくなった — 本当に要る機能だけが残った
一ヶ月前に造った自作のSQLツールに、行の編集と削除を足した。カレンダーはブラウザ標準を捨てて自分で描いた。日付列を数えたら「0000-00-00」が974万件あったからだ。SQLを初めて書いたオフコンとORACLEの頃から、一列にカンマ区切りで持つFIND_IN_SETまで。要る機能だけを足していったら、phpMyAdminを開かなくなった。
-
取りに来るのか、送るのか — 仕様が決まらないまま、サイネージの「今日の会議」を無人化した
新しい庁舎の入口にデジタルサイネージが付く。そこへ「今日の会議」を出す。誰も更新しない仕組みにした。渡し方が決まっていないので、送る形と取りに来られる形の両方を用意した。作っている途中で、予約の時刻と会議の時刻は違うという当たり前に気づいた。
-
行ったり来たりで、よく忘れる — 構築の手順そのものをアプリにしたら、五つのバグが出てきた話
サーバ二台を建てるのに、三つのアプリを行ったり来たりしていた。順番は手順書の中にしかなく、覚えているのは私だけだった。それを工程順に案内するアプリにまとめたら、今まで見えていなかった不具合が五つ出てきた。どれも「動いているように見えて中身が違う」型で、人が目で見て気づけるものではなかった。
-
52時間、止まっていたのは見張りのほうだった — バックアップではなく、その周りを作り直した一日
朝、2台の画面が正反対のことを言っていた。片方は正常、片方は「52時間バックアップが止まっている」。追ってゆくと、バックアップは一度も止まっていなかった。止まっていたのは、それを見に行く先だった。その日、世代の預かりから監視アプリまで作って、最後にこう言われた。「十年後も正常に稼働しているためのバックアップシステムだと思う」。
-
つぎはぎのメニューを、一本の 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は「休日とは土日と祝日である」という思い込みを、休暇・時間外・出勤簿・カレンダーの至るところに埋め込んでいた。それをたったひとつの式に一般化した記録。三つの環境への横展開と、カレンダーのバージョン違いを吸収した一手まで。
-
サロゲートペアだけじゃなかった、日本語の難しさ — IPAmj明朝で解決した話
拡張漢字（サロゲートペア）を倒して外字は終わったと思っていた。ところが「囬」という一字が豆腐になった。原因はコード範囲ではなくフォントのカバレッジ。NGWの明朝をIPAmj明朝に切り替えるまでの話。
-
オンライン決裁は、進むか、やり直すかだけ — 決裁を、二択に整理した
紙の決裁は、いま案件がどういう状態なのか外から見えなかった。NGWのオンライン決裁は、決裁者の選択を「承認して進む」か「差し戻してやり直す」かのふたつに絞った。不在の停滞は代決・引き上げで逃がし、決裁中はロックする。文書管理シリーズ第8回。
-
最初からXLSXで出す — どうせExcelで開くのだから
データ出力といえばCSVが定番だ。だが役所のデータをCSVで出すと、先頭のゼロが消え、コードが日付に化け、文字が壊れる。そして利用者は、結局それをExcelで開く。ならば最初からXLSXで出せばいい。NGWの出力はXLSXにした。文書管理シリーズ第6回。
-
紙への印刷は、全てPDFにした — 帳票は一字もずらせない
役所の帳票は、罫線一本・一字のズレも許されない。だからNGWは画面から直接印刷するのをやめ、印刷をすべてサーバ生成のPDFに通した。PDFは紙面を固定するだけでなく、そのまま保存できる——ペーパーレスの土台になる。文書管理シリーズ第5回。
-
今ある棚と簿冊を、登録するだけ — 現状から始める文書管理
文書管理システムというと「まず全部を理想の形に整理してから」と身構える。NGWは逆で、今まさに使っている棚と簿冊を、そのまま登録すれば動き出す。理想のライフサイクルは、導入してから育てればいい。低い入口こそが、続く文書管理の条件だ。文書管理シリーズ第4回。
-
収受と起案は、受発簿から始まった — 文書の所在を管理する
NGWの文書管理は、大きな設計図からではなく、情報公開法に応えるための「文書の所在管理」から始まった。外から来る収受と、内から起こす起案。その二つの入口を、受発簿という一本の台帳で押さえる。文書管理シリーズ第2回。
-
全ての文書は、分掌事務で管理する — 業務は、分掌事務でしかない
役所の文書を「課・係」で管理すると、組織改編のたびに壊れる。NGWは文書を、条例で定義された分掌事務に紐づけて管理する。業務の実体は分掌事務でしかなく、組織はそれを盛る器にすぎない。文書管理シリーズの第1回。
-
メニューを、データで管理する — アプリメニューと 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枠、そして「みんなの既定＋ひとりの上書き」という設計の話。
-
セレクトボックスは6行で作る — 共通ヘルパー（function）に揃える
NGWには数えきれないほどのセレクトボックスがある。それを、たった6行とひとつの共通関数ngwFunc_MakeSelectBoxに統一している。しかもその6行はCreateDBWebが生成する。手書きしないから、ばらつきが入らない。
-
FullCalendarで行政カレンダーを作る — 9時間のズレとLGWANの壁
自治体グループウェアにカレンダーを載せる。FullCalendarを使ってみると、9時間ずれる時刻、週の始まり、日本語化、フェリー、特別職、そして閉域網LGWANという壁が次々に現れた。その記録。
-
TCPDFを座標でなく行・列で組む — 汎用機のチャート用紙という発想
TCPDFはx,y座標で要素を置く。だが帳票は方眼のように「行と列」で考えたい。汎用機時代のチャート用紙にならい、行・列で組める薄いレイヤーをTCPDFに被せた設計の記録（初出2024年の記事を再構築）。
-
このブログをCMSなしで作った理由 — 静的HTMLという選択
技術ブログにCMSもSSGフレームワークも使わず、Node標準ライブラリだけの自作ビルドで静的HTMLを吐く構成にした。道具の複雑さを問題の複雑さに合わせるという設計判断の記録。
-
NGW開発BLOG をはじめます
自治体向け行政システム NGW の設計判断や実装の裏側を、少しずつ言葉にして残していくブログを開設しました。その辞（ことば）です。
-
「見せない」を権限で設計する — 文書管理のプライバシー保護
機微な文書を「隠す」機能を作ると、UIで消すだけでは足りない。所属×役職以上の二軸判定と、取得段での秘匿という原則を、あらゆる参照経路の一貫性から考える。
-
名前と実体が食い違う関数を掃除する — フォント設定のリファクタ
帳票PDFのフォント設定関数群が長年の変更で荒れていた。名前が嘘をつく関数をどう安全に掃除したか、その過程で見えた命名の価値を綴る。
-
「今の所属」で過去を絞ってはいけない — 申請日時点の所属で判定する
決裁状況を所属で絞るとき、現在の所属で判定すると、異動者の過去の申請が異動先の部署に現れてしまう——見えてはいけない申請が見えてしまう。正しくは申請日時点の所属で判定する話。
-
時間外は「区間」で表す — 単一ブロック描画をやめた話
時間外勤務の自-至表示。合計から逆算する単一ブロック描画をやめ、勤務区間の配列を集計と共有する設計に直した記録。
-
派生フォークを「構成一致」でなく「振る舞い一致」で同期する
本体から勤怠だけを切り出した派生フォークを同期する話。構成の一致を捨て、振る舞いの同等性を実体で判定するという設計判断の記録。
-
移行を「登録」と「付替え」に分ける — 一括処理の設計
組織再編に合わせた財産・備品の一括移行。新しい所属コードが登録作業に間に合わないという制約から、処理を「登録」と「付替え」の二工程に分けた設計を綴る。
-
休暇の「1日」は勤務時間と同じではない — 時間→日数換算の罠
時間単位の休暇を日数に換算するとき、割る数を「1日の勤務時間」にすると間違う。制度上の「1日」が持つ文脈依存の定義を掘り下げる。
-
動いているものを止めずに次を作る — 本番と次期版の二本立て開発
稼働中の本番版と大きく作り替え中の次期版を並行開発する。同じ論理修正を食い違う2つのコードベースへ確実に当てる運用の設計判断。
-
決裁者は「いつ時点の役職」で決まるか — マトリクスの基準日
決裁経路の役職から決裁者を解決するとき、どの日付時点の人事配置で写像するかで結果が変わる。時点を持つデータの設計論を綴る。
-
「所属は1つ」という前提が崩れるとき — 兼務と共通所属
職員は1つの所属に属する、という素朴な前提が兼務と共通所属で崩れたとき、文書管理はどんなバグを生み、どう直したかを綴る。
-
2系統のIDを1つのカラムで共存させる — オフセット方式
独立したAUTO_INCREMENT主キーを持つ2つのテーブルのIDを、下流の1カラムで取り違えなく共存させる。スキーマ不変・最小侵襲を優先して選んだオフセット方式の設計と落とし穴。
-
「係長」という役職名は、思ったより難しい
決裁欄の役職名は「所属名＋長」で組み立てられそうに見える。だが制度の現実は例外だらけだ。例外を消さず、一箇所に閉じ込めて名前を付けるという設計判断を綴る。
-
同じ役職名を6箇所で組み立てていた — 唯一の生成点に集約する
決裁欄の「◯◯課長」を作るロジックが帳票・画面・マトリクスに6重複し、画面ごとに表示がズレていた。唯一の生成関数へ集約するまでと、差分ゼロを確認してから切り替える移行のポイント。
-
定数をコードでなくデータベースに置く — 団体差を吸収する仕組み
団体ごとに変わる設定値を定数としてDBに持ち、起動時にdefineする設計。その利点と、型・存在をコード側で守る契約について。
-
NGWとは — 自治体の内部業務を支えるグループウェア
市役所・町村役場の内部事務と意思決定を支える行政システム「NGW」の全体像と、その設計に潜む行政システム特有の難しさを概観する連載の第一回。