ども。
最近、近くのものが見えづらくなってきた担当ちゅんです。ついに・・・。

昨今、自治体のDX部門では「フロントヤード改革」という言葉をよく耳にします。個人的には「また何でもかんでもカタカナにして・・・」という気分が無くもないわけですが、これは日本語で言うと「住民と行政との接点改革」ということになるのだそうです。その代表例が、手続きなどを行う窓口の改革。ワンストップ窓口や書かない窓口といった取り組みはすでに多くの自治体で行われていますし、総務省の自治体DX推進計画（第4.0版）でも重点取組事項の1番目として記載がされていることからも、重要な取り組みであることがわかります。

でも、このフロントヤード改革って、担当者としてはなかなか難しい取り組みだと感じています。なぜなら、自治体の規模や環境によって、どんなアプローチが向いているのかが違ってくるから。例えば、慢性的に窓口が混雑していて待ち時間が長いことを解消したい大都市の課題と、混雑はそれほどではないけど公共交通機関が少なくて窓口まで来庁いただくことが不便な小規模自治体の課題はまったく異なります。なので、フロントヤード改革という言葉だけで大都市と同じような取り組みをしても意味がないんです。そういうことをきちんと考えないと、本当の意味での「改革」にはならないなと、そう思っています。

八雲町の課題は、先ほど挙げた後者の課題に近いです。なので、我々が行っているフロントヤード改革は、住民にとって身近な「郵便局」の窓口でも各種手続きを行っていただけるようにする取り組みです（これをDX推進計画では住民との接点のオムニチャネル化というようです）。
これまで、熊石地域の館平郵便局でのみ手続きが可能でしたが、今年度からは新たに野田生郵便局と黒岩郵便局（どちらも役場までの距離が遠い）にて手続きを可能とします。本日はその準備として、郵便局に役場名義の光回線を開通させるというミッションでした。

自庁であれば「あ、そこでOKです」「穴をあけてもいいです」など自由自在に指示が出せるのですが、他人の建物なのでそうはいきません。電源も、郵便局内のコンセントを使わせてもらいたいのですが、空きが少ない場合は「電源工事もしないと・・・」など、考えなければならないことが多いです。ですが、前回の館平郵便局の時はLAN配線作業を誰も見込んでいなくて自分たちで配線をした反省から、今回はきちんと予算化して対応できています。やはり、経験に勝るものなし。今回はスムーズに、業務を進められそうです。
上記郵便局での手続き受付は7月に開始の予定です。地域の方々が便利になることをとても嬉しく感じています。

無事に開通しました

（投稿者：ちゅん）

てんちょです。久しぶりに熊石方面に外勤に行ってきましたが、急に暖かくなったからか眠気が…。しかも予想外の状況で何も成せずに帰ってきました。

現在使用しているWindows11端末。キッティング時に23H2でセットアップを行っており、サポート期限もあるので24H2へのアップデートを検討しなければなぁ…と思っていたのが昨年の12月。ダウンロードだけしてほぼ未検証のまま手を付けず放置して数か月経過してしまいました。ちょうど24H2の不具合も問題になっていたようだったので、放置して正解だったのかも。もう改善したんでしょうかね。

もう24H2の存在自体忘れていましたが、Windows11のアップデートについての相談が5月に2件入りました。過去のブログを見てということで資産管理ソフト経由でのFUに関してどのように実施したのかという内容。こちらもWindows11になってからまだ未実施だったので、いい機会なので検証してみました。とりあえずサーバに入れてあったインストーラに、Windows10の時と同じオプションで実施。配布はされましたがどうやらインストールされずにすぐに終了してしまいました。

Windows11のコマンドラインオプションを見てみると、エンドユーザーライセンス条項を表示しない/eula acceptというのがWindows11からの新機能として追加されていたようだったのでこれを追加。他には特に追加された項目がなかったようなので、これだけを追加してテスト端末に再配布をかけたところ、今度は何やら動いている感じ。結構時間もかかりそうだったので、そのまま放置して帰宅することにしました。

ちなみに使ったオプションはこちらです。
/Exec:setup.exe /Time:10800 /Rusult:<ファイルサーバー> /ROption:/Auto Upgrade /eula accept /Quiet /NoReboot /pkey <ライセンスキー>

翌朝確認してみると無事に実行されていたようで、再起動すると24H2に上がっていました。まだサポート期間あるので配布はかけませんが、しばらく検証端末で様子みて問題なさそうであれば夏くらいには全台配布しようかなぁ。

分散させて配布もできるのでほんと便利なソフトですね。

（投稿者：てんちょ）

ども。
今年度も出張が多くなっている担当ちゅんです。

先週は東京都で開催された「自治体課題解決ブレークスルーセミナー（フォーティネットジャパン主催）」でのパネルディスカッションにお招きいただき、昨年の千葉幕張に引き続いて2回目の参加となりました。毎回ですが、自分の身の丈をはるかに超える案件であり、このセミナーに参加するために自分なりに色々と勉強をしなければならないので、そういう意味でもとても成長できる場であると考えています。

第４回自治体課題解決ブレークスルーセミナー
https://jichitai.works/seminar/detail/668

前回は、あまりの緊張で「お昼ご飯の味を覚えていない」と感想を書いていましたが、今回はかろうじて味は感じられました。ですが、「東京」の、しかも会場があの有名な「丸ビル」ということで、北海道の田舎に暮らしている人間にはかなり刺激が強いのは事実。都会のキラキラを浴びると力が半減してしまうような感覚です・・・。

ですが、肝心の議論については大変満足のいく内容だったと思います。今回も豪華なメンバーが登壇している中ではありましたが、今年度、本町が予定している大きな事業である「公用スマートフォンの導入」を話題とさせてもらい、「昨今はゼロトラストアーキテクチャに注目が集まっていますが、正直、何が何だかわかっていませんでした」「でも、いざスマホを導入する段階になって、はじめて【あ、だから必要なんだ】と自分ごとに感じられるようになった」といった具合で、飾らずに正直にお話することができたと思っています。

今、自治体の情報ネットワークの考え方はまさに過渡期にあるのだと思います。LGWANとインターネット、マイナンバー利用事務を分離・分割した「三層分離対策」と並行して、常時インターネットで認証を行いながらシステムを利用する「ゼロトラスト」に移行しつつある中で、それらが混在することでカオスな状況が生まれつつあるように感じています。私としては力不足ではありますが、スマホ事業なども通して「それってつまりどういうことなの？」と課題や疑問を整理するためのお手伝いができればうれしいなと感じています。

かろうじて撮影できた「アリバイ写真」です

（投稿者：ちゅん）

てんちょです。もっと性能の高い業務端末がほしい欲がでてきました。メモリが足りない。

今週かなりの時間をかけてリソースの管理について方法を検討しましたが、ようやくある程度思った通りの動きをしてくれるところまでたどり着きました。ある程度です。この数日、PowerAutomateを使うことを強く勧めてくるChatGPTの意見は無視し、昨日、テスト用の会議室リソースを作り直すところからスタートしました。

『普通はこんな面倒な事しなくていいのでは？』という先日の疑問が払拭できず、リソースの権限についてなどを初期段階からしっかり確認しつつ作り直して一から検証をすることにしました。ExchangeOnlineでテスト用のリソースを作成。PowerShellをExchangeOnlineに接続し、リソースのパラメータを確認してみました。重複を制御するAllowConflictsは既定でFalseとなっており、そのほかのパラメータで気になるところは変更。

リソースのアクセス権も初期状態を確認。リソースを直接編集させることはしたくないので、フルアクセス権は付与せずに権限はReviewerにしました。テスト用アカウントにReviewer権限を与え、予定表から新しい予定を作成。場所にテスト用会議してを選択し、まずは予定が追加されるか確認しました。問題なし。次に重複した場合に拒否されるか確認。自分の予定と会議室に予定が追加されましたが、会議室から”辞退”の通知がきました。あれ…？できた？

結構早い段階で同じことやってたはずなんですが…。テストに使っていたリソースがどこかでおかしくなったということにしておきます。というわけでよくわかりませんが後から入った会議室の予約は無事に消え去りました。会議室予約できなかった時に自分の予定が消えないところがちょっと難点ですね。これをPowerAutomateでどうにかできないか考えてみます。
次は公用車と備品。会議室はRoomとしてアドレス帳一覧に出てきましたが、備品とか車とかはどうなるんでしょう。あと職員間のスケジュール確認もできるように準備しないと…。まだまだやることいっぱいです。

なんとか移行できそうな気がしてきました

（投稿者：てんちょ）

てんちょです。いつの間にか19時近くまで明るくて時間感覚がおかしいです。

引き続きリソースの管理方法について色々実験中ですが、重複予約を禁止する動作がうまくず迷走中。「AllowConflicts」や「AllRequestOutOfPolicy」をFalseに設定していても重複を防ぐことができず…。
先日はChatGPTから『メールボックスではなく、「:\予定表」にEditor権限を付けろ』と言われましたが、どうもこの権限を付けるのも違う気がしてきました。Authorが正しい？もう何が正解なのかよくわかりません。

いっそPowerAutomateを使って重複予約を削除してみようと、イベント作成→カレンダービュー取得→条件設定→イベント削除としてみましたが、重複予約をいれると全部消えるという謎動作になりました。どうにか修正をして使える状態にはなりましたが、一度スケジュールに登録されたように見えてしまうため、登録できたつもりで気付かない可能性も。そこで削除されたことをTeamsで通知しようとしましたが、今度はスケジュールの登録者を通知先として取得する方法が思いつかず保留しています。

そもそも予定表への入力時に重複予約を禁止するなんて出来て当たり前な気もするので、普通はこんな面倒な事しなくていいのでは？ということはメールボックスにつけているユーザーの権限の問題なのか、他の設定があるのか…。AllRequestOutOfPolicyの設定だけでできるはずなのではないか、という疑問が解消されないまま一日が終わりました。
今のところPowerAutomateを修正して通知する方法が有力ですが、重複した後に消えるまでの動作の遅さが少し気になります。

しかしこれを運用できたとして、今後の管理をPowerShellでやっていけるのかという不安もありますね。利用する側は便利になるならやるしかないのか、どこに向かうのが正解なんでしょうか。PowerShellに慣れるしかない？

デスクトップがPowerShell用のメモで溢れかえってます。

（投稿者：てんちょ）