この資料は特定非営利法人 Digital Government Labsの自治体システム標準化に関する研究会第2回の資料です。(2020/12/26開催分)
## プログラム 1.オープニング/DGL代表 千葉 大右による挨拶および研究会趣旨説明 2.DGL 山村 智英による標準仕様書の解説 3.DGL 木村 祐介による先行事例取組の講演(資料非公開) 4.法改正・システム更改・共同利用等や住民記録事務の実務者によるパネルディスカッション 5.クロージング
「自治体システム標準化対応」研究会1特定非営利活動法人 Digital Government Labs
View Slide
2資料の取り扱いについて• 本資料は特定非営利法人 Digital Government Labsが、2020/12/26に開催した「自治体システム標準化対応研究会 概要編#2」の資料です。• 資料はCC-BYでご利用いただけます。• レビューは行っておりますが、無謬性を保証するものではない旨ご了承ください。
3セミナー映像(動画)の取り扱いについて• 当日のセミナー映像は、限定配信を行っております。再配布いただけないケースもありますのでご留意ください。⁃ セミナー申込者個人の再視聴は可能です。⁃ 行政職員間の閲覧・共有は無償で可能です。⁃ 民間法人内での共有は、DGLの法人賛助会員に限定します。• セミナー映像の配布を希望される方向けに、別途DGLのホームページにご案内を掲載する予定です。(3月上旬予定)
4前回配信のお詫び①• 前回配信で標準仕様書の検討会議体をご紹介した際に、構成員の方に漏れがありました。出典: 自治体システム等標準化検討会「住民記録システム標準仕様書【第1.0 版】（概要）」
5前回配信のお詫び②• パネルディスカッション内で、庁内連携については「未定」との会話がありましたが、正しくは「地域情報プラットフォーム標準仕様に基づく連携」です。出典: 自治体システム等標準化検討会「住民記録システム標準仕様書【第1.0 版】（本体）」 232頁
6前回以上に念入りにレビュー等を行っておりますが、無謬性を保証するものではない旨を予めご了承ください。
オープニングDGL代表理事挨拶、研究会趣旨説明7
8代表理事 千葉 大右DGL代表/船橋市役所職員情報システム課、市民税課、戸籍住民課等に在籍2018年から総務省地域情報化アドバイザー2020年にNPO法人デジタルガバメントラボを設立、代表理事を務める。
特定非営利活動法人 Digital Government Labs“自治体のデジタルガバメントを実現”9https://www.dgl.jp
10国の方針・計画 直近のアップデート1. R3年度概算要求に向けた政府の方針• 経済財政運営と改革の基本方針2020（R2.7閣議決定）⇒重点として、「「新たな日常」構築の原動力となるデジタル化への集中投資・実装・環境整備」を記載2. IT関連の計画デジタル・ガバメント実行計画 (R1.12改定閣議決定)国・地方公共団体・民間を通じたデジタル化の推進デジタル・ガバメント実現のためのグランドデザインデジタル・ガバメント実行計画の改定(R2.12)総務省：自治体デジタル・トランスフォーメーション（DX）推進計画出典：内閣官房IT戦略室「IT新戦略とデジタル・ガバメント実行計画等の関係性」(7.27デジタルガバメント分科会資料)を加工して作成各府省中長期計画法務省総務省厚労省…省…省…省…省デジタル社会の実現に向けた改革の基本方針（R2.12デジタル・ガバメント閣僚会議決定）世界最先端デジタル国家創造宣言・官民データ利活用推進基本計画 (R2.7閣議決定)(略称：IT戦略)
11国の情報化の経緯デジタル手続法デジタルガバメント改正法自治体システムについて標準仕様への統一を義務付ける新法法律世界最先端デジタル国家創造宣言・官民データ利活用推進基本計画(略称：IT戦略)情報システム整備計画 改訂(デジタル・ガバメント実行計画 改訂)総務省：自治体デジタル・トランスフォーメーション（DX）推進計画方針・計画IT政策全体デジタルガバメントIT基本法改正R3通常国会提出予定官民データ利活用基本法H28.12R1.5R3通常国会提出予定(8/26付時事通信)R2.7R2年中(IT戦略22頁)R3通常国会提出予定(8/3付日経新聞) R2年中(IT戦略25頁)• デジタル庁の創設• マイナンバー付公金受取口座制度の創設• 3分野以外へのマイナンバー情報連携の拡大• マイナンバーカードと免許証等の一体化• 新規施策の追記• 施策実現時期の前倒し• デジタル社会の構築に向けた取組みを全自治体において着実に進めていく
12https://www.soumu.go.jp/main_content/000695701.pdf
13新経済・財政再生計画 改革工程表2019https://www5.cao.go.jp/keizai-shimon/kaigi/special/reform/report_011219_1.pdf骨太における取組事項令和２年 令和３年 令和４年ＩＴに係る地方自治体への補助金の効率化を図るとともに、財源を含めた国の主導的な支援の下で情報システムやデータの標準化を推進する観点から、ＩＴ予算の一元化を契機に、内閣官房が中心となり関係府省庁が連携して、地方自治体のデジタル化の取組を後押しするための政策に関する検討を進める。内閣府・総務省・文部科学省・厚生労働省は、部内の検討体制を整備の上、市町村が情報システムを構築している以下の地域情報プラットフォーム標準仕様又は中間標準レイアウト仕様で示されている業務について、業務プロセス・情報システムの標準化に向け市町村の業務プロセスや情報システムのカスタマイズ状況等についての調査を行う。・児童手当（内閣府）・選挙人名簿管理、固定資産税、個人住民税、法人住民税、軽自動車税（総務省）・就学（文部科学省）・国民健康保険、国民年金、障害者福祉、後期高齢者医療、介護保険、生活保護、健康管理、児童扶養手当（厚生労働省）・子ども・子育て支援（内閣府・厚生労働省）上記の作業を踏まえ、行政サービスの利用者の利便性向上並びに行政運営の簡素化及び効率化に立ち返った業務改革（ＢＰＲ）の徹底を前提に業務プロセス・情報システムの標準化を進める。内閣府・総務省・厚生労働省は、情報システムの標準化に向けた調査に基づき地方自治体の状況等を踏まえた課題を整理し、情報システム標準化による効果が見込める場合には、地方自治体関係者やベンダー等を含めた研究会を組織し標準仕様書を作成する等、標準的なクラウドシステムへの移行に向けた技術的作業を進める。内閣府・総務省・厚生労働省は、情報システム標準化による効果が見込める業務について、標準仕様書を作成する等、標準的なクラウドシステムへの移行に向けた技術的作業を進める。特に、地方税、介護保険、国民健康保険、障害者福祉、就学業務については、速やかに地方自治体の状況等を踏まえた課題を整理し、業務プロセス・情報システムの標準化により効果が見込める場合には、地方自治体関係者やベンダー等を含めた研究会を組織し標準仕様書を作成する等、標準的なクラウドシステムへの移行に向けた技術的作業に着手する。このほか、各省は以下の事項に取り組む。（略）
14新経済・財政再生計画 改革工程表2019https://www5.cao.go.jp/keizai-shimon/kaigi/special/reform/report_011219_1.pdf
前回の振り返り
16前回のまとめ• 発注・運用管理や制度改正対応等、自治体が各々で対応しており、人的・財政的にも負担が高まっている。• データフォーマットが自治体毎で異なり、共通プラットフォーム上のサービスを検討する際の妨げとなっている。• 帳票類も自治体毎で異なり、利用する住民・事業者にとっても負荷を強いている。⇒基幹システムに係る標準化・共同化を推進し、重複投資の廃止と「AI-Ready」な行政基盤の整備が求められている。背景• データ項目や帳票項目の統一を始めとして、各種機能が統一される。• 各機能は「①実装すべき機能」「②実装してもしなくても良い機能」「③実装しない機能」に分けられる。• 「③実装しない機能」は、業務の見直しや住民記録システム以外でのシステム導入を検討する必要がある。標準化の範囲• 2022年度(令和4年度)～2025年度(令和7年度) にかけて、順次標準化システムに移行する必要がある。• 各自治体ではシステム移行に伴って、システムに合わせた業務設計を行うだけでなく、文字同定やPIA、各種連携テスト等の様々な事務が発生する。早急に実行計画を策定し、移行に向けた体制や予算等を固めていく必要がある。スケジュール力を合せて乗り切りましょう！
17標準化で目指す姿を実現するためには、「標準ではない業務」の見直し(＝BPR)が重要。「目指す姿」を全員で共有しつつ、今後研究会にて意見交換・事例共有を行っていきたい。標準化仕様が目指す姿 そのために必要な努力カスタマイズせずに利用可能⇒ベンダーとの導入要件定義が最小化できる発注・維持管理の負担軽減⇒先行団体の検証リリース結果を信頼できる等維持管理負担が低減できる制度改正対応の負担軽減⇒有識者で検討した成果物がそのまま自分の団体に適用できる広域クラウド上でアプリケーションサービスを提供⇒インフラコストは、割り算効果が期待できる標準「ではない」業務の見直し帳票項目・様式・データ項目の統一各種カスタマイズ機能の削除オンプレミスではないクラウドでの運用見直し今後、意見交換・事例共有を行いながら「集合知」を高めていきたい標準化で目指す姿を実現するために、必要な努力
18架空自治体D市として想定されるスケジュールをフィクションで作成。DGLでは、正会員有志によって運営する「自治体システム標準仕様書研究会」を立ち上げ、参加メンバー内での相互学習支援を図る。架空自治体D市スケジュール2020年度(令和2年度)2021年度(令和3年度)2022年度(令和4年度)2023年度(令和5年度)2024年度(令和6年度)2025年度(令和7年度)10-12 1-3 4-6 7-9 10-12 1-3 4-6 7-9 10-12 1-3 4-6 7-9 10-12 1-3 4-6 7-9 10-12 1-3 4-6 7-9 10-12 1-3マイルストンDGL研究会システム X社架空D市業務委託 Y社本日ソフトウェア開発先行団体導入影響調査・計画策定ベンダー選定移行PJ体制強化 システム移行・連携要件定義、構築等稼働研修• ネットワーク工事• 文字同定• PIA(特定個人情報保護評価)• 業務システム間連携テスト• コンビニ交付試験工程• 業務、規定類の見直し…等、各団体事情を踏まえたタスク設計が必須超概要編 虎の穴編クラウド運用体制構築連携モジュール開発住記準拠システム導入(～令和7年度まで)第1グループシステム導入(～令和7年度まで)第1グループ標準仕様書の公表(8月)第2グループ標準仕様書の公表(8月)住民記録システム標準仕様書の改訂税連携、XX連携テスト…選定仕様策定選定PJメンバー選出影響委託仕様変更
19研究会の全体像DeepDive(虎の穴編)研究会標準化仕様書の読み合わせ、課題のディスカッションを予定中補足:通知等の状況に応じて、プログラムが変更となる可能性があります。会議名 開催回/タイトル 主な解説事項OverView(超概要編)第3回 標準化×基盤・連携⁃クラウドの種類⁃クラウド運用⁃セキュリティ⁃地域情報PF(抜粋)の解説第4回 標準化最新情報⁃住記標準仕様書のその後⁃他16業務の標準仕様書に関する検討進捗⁃各ベンダーの動向第1回 全体概要⁃経緯・背景⁃検討対象業務⁃法的拘束力の強度⁃実装すべき機能等の解釈⁃スケジュール⁃標準仕様書の責務範囲⁃標準仕様書の目次構成⁃機能要件(一部抜粋)の解説⁃業務適用分析(FIT-GAP)の進め方例第2回 標準化×運用
セッション1講演「自治体システム等標準仕様対応」研究会 超概要編 第2回20
「自治体システム標準化対応」研究会超概要編 第2回21特定非営利活動法人 Digital Government Labs
22スピーカー 山村 智英DGL(事務局員)/富士ゼロックスシステムサービス(株)主にDBエンジニアとして、住民記録システム等の移行(ベンダ更改・法改正)に関わるプロジェクトをリード。2016年以降は、総合窓口の導入コンサルティングや転出証明書等のOCR化によって各種申請書を作成するシステムの設計等、窓口のUXに関する支援に携わる。※講演内容は私個人の見解であり、所属企業の見解を代表するものではありません。
23前置き本日は、9/11付け「住民記録システム標準仕様書【第1.0 版】」の内容に基づき解説を行います。今後提供される情報によっては、 工程表や仕様書などの変更が発生する可能性があることを予めご理解ください。
24今回話すこと• 標準仕様書自体の記載範囲• 標準仕様書の目次構成と今回取り上げる範囲• 抜粋した機能要件の解説• 今後の進め方参考例⁃ 適用分析（FIT＆GAP分析)⁃ 差異（GAP）の仕分け基準と進め方案
標準仕様書の外観
26(参考)実装すべき機能等の解釈現行機能新機能標準仕様書に記載標準仕様書の記載外(記載なし)標準仕様書上の区分実装すべき機能標準仕様書上での選定基準① 住民基本台帳制度上の事務② 住民基本台帳制度上の事務以外の機能であるが、住民記録システムの中で一体的に処理されることについて普遍的に有用性が認められるもの1実装してもしなくても良い機能(記載なし)2実装しない機能① 他業務関係の機能の追加により大きなカスタマイズの要因になるもの② 住民記録システムの中で普遍的に有用性が認められないもの(実装しない機能に準ずる)現時点でのDGL解釈 システムベンダ• 全ベンダが提供する機能 システムベンダ• ベンダによってオプション提供する機能 自治体• 必要な機能を選定仕様書に明記 システムベンダ• カスタマイズ開発も禁止されている機能 自治体• 他業務基幹システムへの実装を検討• 住民課業務所管の他システムとして調達• 業務廃止を検討3今回はこの部分に焦点をあてて解説を進めます。第1回講演資料より一部改変
27「住民記録システム標準仕様書」だけでなく、他業務の標準仕様書や地域情報プラットフォーム標準仕様書等、全体感を意識しながら移行を設計することが重要となります。標準仕様書の記載範囲APPLIC 地域情報プラットフォーム 標準仕様書(連携インターフェース)住民基本台帳法の範囲内標準仕様書が検討されない他業務標準仕様書が検討される他業務住民基本台帳法の範囲外現行の住民記録システムの業務カバー範囲As-IsTo-Be 住民記録システム標準仕様書 各市町村/既存の仕様(書) 他業務の標準仕様書条件該当する仕様と具体例(次頁以降) 印鑑登録・コンビニ交付・戸籍等 地方税・後期高齢等印鑑登録との接続方法については、次版に向けて現在協議中。
28時間の制約上、本日は約500頁の標準仕様書の中から、特に「読んだだけでは理解が難しい項目」を中心に解説を行う予定です。標準仕様書の目次構成と今回取り上げる範囲章 頁数 項 話したい範囲 今回話せる範囲第1章 本仕様書について 14頁 • 背景・目的 • 対象 ― ―(第1回配信参照)第2章 業務フロー等 62頁 • 業務フロー • 機能分析表（DMM）• データフロー図（DFD）― ―第3章 機能要件 193頁 • 管理項目• 検索・照会・操作• 抑止設定• 異動• 証明• 統計• 連携• その他の実装してもしなくてもよい機能• バッチ• 共通• エラー・アラート処理全部 一部のみ第4章 様式・帳票要件 141頁 ― 全部 一部のみ第5章 データ要件 35頁 ― 全部 一部のみ第6章 非機能要件 2頁 ― ― ―第7章 用語 24頁 ― ― ―― 参考 8頁 ― ― ―特に読んだだけでは理解が難しい項目を抽出
29研究会の全体像DeepDive(虎の穴編)研究会標準化仕様書の読み合わせ、課題のディスカッションを予定中補足:通知等の状況に応じて、プログラムが変更となる可能性があります。会議名 開催回/タイトル 主な解説事項OverView(超概要編)第3回 標準化×基盤・連携⁃クラウドの種類⁃クラウド運用⁃セキュリティ⁃地域情報PF(抜粋)の解説第4回 標準化最新情報⁃住記標準仕様書のその後⁃他16業務の標準仕様書に関する検討進捗⁃各ベンダーの動向第1回 全体概要⁃経緯・背景⁃検討対象業務⁃法的拘束力の強度⁃実装すべき機能等の解釈⁃スケジュール⁃標準仕様書の責務範囲⁃標準仕様書の目次構成⁃機能要件(一部抜粋)の解説⁃業務適用分析(FIT-GAP)の進め方例第2回 標準化×運用
抜粋した機能変更の解説
31抜粋した機能仕様書の説明1. 管理項目 (91頁-97頁、424頁-458頁)2. 帳票レイアウトの統一：改製しない住民票 （98頁-１０1頁、284頁、302頁-316頁）3. データ要件：文字(IPAmj明朝)の適用 (437頁-458頁)4. 他業務照会 (232頁-234頁)
32標準仕様書では、管理項目・帳票項目・(除票用のみ)データ構造の項等で、それぞれ住民データに対する項目・桁数・適用文字コード・フラグ区分等の指定が行われています。1.管理項目の統一出典: 自治体システム等標準化検討会「住民記録システム標準仕様書【第1.0 版】（本体）」 92頁、93頁、135頁、306頁管理項目の指定(1.1 住民データより一部抜粋) 桁数の指定(1.3.3 住所辞書管理より一部抜粋)桁数・文字コード等の指定(20.1.1 住民票の写しより一部抜粋)そもそも第4章「帳票様式・要件」では仕様書の帳票様式に従うことが記述されており、その中で、記載項目ごとに桁数や文字コード等の指定が行われています。
33履歴満欄による住民票の自動改製を行う「改製する住民票」から、満欄が発生しない「改製しない住民票」へと帳票レイアウトが変更となります。2.帳票レイアウト変更：改製しない住民票(1/5)出典: 自治体システム等標準化検討会「住民記録システム標準仕様書【第1.0 版】（本体）」 98頁•満欄が発生しないってどういうこと？•証明発行枚数って増えちゃう？•全く改製できなくなるの？
34改製する住民票は氏名欄や住所欄に記載できる履歴数が限られているため、満欄となると最新履歴だけをもつ住民票を調製し、満欄となったものを改製原住民票(除票)とする運用を行っています。2.帳票レイアウト変更：改製しない住民票(2/5)(住民基本台帳業務に携わらない参加者向け「改製する住民票」の紹介)改製する住民票サンプル(住所が満欄となる例)
35改製しない住民票は、履歴事項欄を(理論上)無限に追加することができるため、満欄による自動改製が発生しないことが特徴です。2.帳票レイアウト変更：改製しない住民票(3/5)出典: 自治体システム等標準化検討会「住民記録システム標準仕様書【第1.0 版】（本体）」 313頁、314頁住民票の写しサンプル(左：1枚目、右：2枚目)最新事項欄履歴事項欄令和●年●月●日異動(令和●年●月●日届出)異動項目：住所異動前：東京都●×区●●1丁目・・・異動後：東京都●×区▲▲4丁目・・・留意事項：・・・異動項目:世帯主異動前:住民 花子異動後:住民 太郎留意事項：・・・転居同時世帯主変更の例履歴事項欄のレイアウトが固定されていないので、履歴数が多い場合は2枚目・3枚目…と履歴事項欄の頁を足すことができます。満欄が発生しないってどういうこと？
362.帳票レイアウト変更：改製しない住民票(4/5)出典: 自治体システム等標準化検討会「住民記録システム標準仕様書【第1.0 版】（本体）」 313頁、332頁最新事項欄住民票の写しサンプル 住民票記載事項証明書(世帯連記式)のサンプル最新事項欄のみを抽出した記載事項証明書(世帯連記式)を発行することができます。勿論、住民票の写し(単票)の場合も履歴の印字有無を選択することができます。証明発行枚数って増えちゃう？
372.帳票レイアウト変更：改製しない住民票(5/5)出典: 自治体システム等標準化検討会「住民記録システム標準仕様書【第1.0 版】（本体）」 99頁、100頁いいえ。満欄による自動改製はなくなりますが、任意の改製はできます。任意改製の事例は、主に以下の2パターンに集約されます。• 帰化・特別養子縁組等の住民都合によるもの• 誤謬・システム更改等の市町村都合によるもの全く改製できなくなるの？
38標準仕様書内で、住民記録システムで用いるデータの文字セットは、「JIS X 0213(2012年版)」に準拠した文字セットを使うようにとの記述があり、これに準拠した具体的な文字セットとして「IPAmj明朝」が挙げられます。3.文字情報基盤で整備された文字(IPAmj明朝)への移行(1/4)出典: 自治体システム等標準化検討会「住民記録システム標準仕様書【第1.0 版】（本体）」 437頁、438頁IPAmj明朝が準拠しています
39住記がIPAmj明朝に準拠することで、システム内外のデータ連携の流動性が高まるメリットがあります。3.文字情報基盤で整備された文字(IPAmj明朝)への移行(2/4) 目指すべき方向性⁃ 住民記録システム及び戸籍システムを含む市区町村の住民情報系システムにおいて、これまで外字が存在してきた氏名等について、文字情報基盤文字によってデータが内字として保持され（外字がない、又はできる限り抑制され）、庁内外のシステム間でも文字情報基盤文字が用いられている状態 実現すべきこと1. 変換可能文字の内字を、文字情報基盤文字に置き換えること2. 変換可能文字の外字を、文字情報基盤文字に置き換えること3. 住民記録システムアプリケーションを文字情報基盤文字に対応させること出典: 自治体システム等標準化検討会「住民記録システム標準仕様書【第1.0 版】（本体）」 443頁
40行政で用いられる人名漢字等約6万文字の漢字が整備された国際規格準拠の文字セットです。文字情報基盤を活用することで、部門・機関を超えた文字情報の交換が簡単になります。3.文字情報基盤で整備された文字(IPAmj明朝)への移行(3/4)(文字情報基盤とは)出典:平成26年5月9日 ITコミュニケーション活用促進戦略会議(第７回) 参考資料3自治体システム等標準化検討会「住民記録システム標準仕様書【第1.0 版】（本体）」 445頁住記の氏名がIPAmj明朝になると、住基ネットや中間サーバとの文字変換の管理が楽に！
413.文字情報基盤で整備された文字(IPAmj明朝)への移行(4/4)文字基盤では縮退マップ等の基準が提供されているため、従来よりは簡便ですが、やはり文字同定を始めとした移行作業は発生します。(今回頑張れば、他業務システムも含めて標準化された後の運用は格段に楽になります！！)登壇いただいている皆さんに、過去のシステム移行の思い出を語っていただきたいと思います。（外国人住民票への移行、オープン化、他社更改…）チャット欄でもぜひコメントください。ところでシステムの文字を変えるのって、そんなに大変なんですか？
42他業務照会は、住民基本台帳を中心に、実装すべき機能・しない機能を整理。元々、統合ホスト等から派生した「各業務照会」や「他業務からの住基照会」とは考え方が異なるため、今後業務照会はシステム・根拠等の整理が必要か。4.他業務照会出典: 自治体システム等標準化検討会「住民記録システム標準仕様書【第1.0 版】（本体）」 232頁、233頁
今後の進め方(案)あくまで進め方の一案で、推奨ではありません。
44架空D市の適用分析(FIT-GAP分析)調査結果架空D市では、現行住記システムによる業務と標準仕様書の比較を行いました。「①標準仕様書にしかない業務」は住記ベンダーが対応するものとして新業務BPRのみを実施予定。「③現行住記にしかない業務」は次の基準で仕分けを行う予定にしています。住民記録システム標準仕様書で実現する業務現行住記システム業務62件 220件 100件標準仕様書にしかない業務• 実装すべき機能：ベンダーの開発は必須のため、新業務のみ設計• 実装してもしなくてもいい機能：ベンダーの開発は任意のため、選定仕様に含めると共に新業務を設計差分のない業務• 業務運用が変わる部分のみ手順を変更現行住記にしかない業務• 差異項目の仕分けを実施業務比較「1.1.6支援措置対象者管理」、「2.1.3基本検索(実装してもしなくてもいい機能)」、「10.1 EUC機能」、「20.2.1転出証明書等」など、機能強化されたものも存在。「6.1 統計」で、都道府県の独自調査による統計等、廃止となるものも…。
45差異（GAP）の仕分け基準と進め方(案)• 他業務システムの改修見込調査(法令に記載されているか)• 他業務システムが改修されるまでの代替手段検討• 業務変更検討• 代替手段調達(住民課業務所管の他システムとして調達)• 業務変更検討• 業務廃止検討• 代替手段調達の検討(住民課業務所管の他システムとして調達)標準仕様書が作成される事務か住民基本台帳法制度の事務かStartはいいいえはいいいえ今回の機能変更には含められませんでしたが、代替業務を円滑に進めるための機能も追加されています。(EUCや住民データのCSV出力機能、CSV取込機能、等)文字やレイアウトの標準化によって、マクロやRPA等と組み合わせての自動化も今までより検討・共有しやすくなっていますので、標準化の本旨に添いながらBPRを進めていきましょう！
セッション2講演絶賛更改中： 3市自治体クラウド導入ーシステム標準化と業務標準化の取組46
セッション3パネルディスカッション標準化における運用の整理〇パネラーDGL ： 千葉 大右 中川 茜矢島 征幸 木村 祐介内山 武司 山村 智英47
クロージング挨拶、事務連絡48副代表理事 ： 遠藤 芳行代表監事 ： 中川 茜
49次回開催予告2月上旬「標準化×基盤・連携」解説予定(今後の事務連絡等の内容に応じて、プログラム変更の可能性有)Facebook等で告知
50その他DGLへのお問い合わせQRコード公式サイトQRコードFacebookアカウント
ご視聴ありがとうございました♪51
digitalgovernmentlabs
hashport
cybozu0808
progmat
takahiroogoshi
gmofh_hr_team
ayaaoki1031
presentales
alexanderbyndyu
giuliapanozzo
.jpg){kind=avatar}
ikuodanaka
danielanewman
chrislema
swwweet
holman
mraible
afnizarnur
wjessup
tenderlove
jcasabona
yeseniaperezcruz
andyhume
marcduiker