第2回東京デジタルサービス会議を開催!!
東京都では、都政におけるＤＸの推進に向け、デジタルサービス局と各局が連携し、サービスの開発基盤を整備する取組を進めています。今回は、この取り組みの一つとして、12月27日にオールリモートで開催された「第2回 東京デジタルサービス会議」について、紹介します。
なお、第1回会議については、こちらをご覧ください。
1 第2回会議議事
第2回会議では、次の３つの点について、事務局から検討状況を報告し、各構成員から、ご意見等をいただきました。
①行動規範の検討状況
②標準プロセスの検討状況
③ワーキンググループの設置
2 行動規範の検討状況
第1回会議にて提案した行動規範・Code of Conduct「10か条」について、”システム開発・運用に携わる全ての職員”に普及・定着させていくため、各条項を、”なぜ定めているのか”という観点から社会的な課題感・ニーズなどの背景（①バックグランド）について整理するとともに、これらに対して、職員はどのように行動すべきなのかという行動原則や具体的な行動例（②ガバナンスコード）を示し、さらには、行動原則を守っていくために必要となる仕組や制度（③マネジメント）の観点から説明を加えた”10か条詳細説明”版を事務局で作成しました。
今回のサービス会議では、この詳細説明について、構成員の皆様に、各条項ごとに示した課題感、規範に基づき取るべき行動原則や具体的な行動例、行動原則を順守させていくために都として検討していくべき仕組や制度やこれらに関する具体的なアクションについて、それぞれ過不足がないか確認いただきました。
なお、マネジメントの部分については、すぐにやるべきことや、中長期的に考えていくべきことなど、粒度が異なるものがあることから、キーワードレベルでの確認を行なっていただきました。
また、この行動規範に対しては、第1回会議において、”行動規範をつくることで終わるのではく、これを受け入れ、育むための文化・風土の醸成にも努めていくことが重要”というご意見をいただいていることから、既に行動規範等を定め、定着に向けた取り組み等を進めている福島県磐梯町様や兵庫県神戸市様、クレディセゾン様への事前ヒアリング結果を報告したほか、都としての今後の取り組みについても提案しました。
《構成員の皆様からいただいた主なご意見等》
〇 行動規範と呼ぶべきなのか。”ビジョン”や”バリュー”ならば解るが、行動規範というと、倫理とか、モラルとか、”べからず集的”なことを印象に持つ。国ではデジタル原則と呼ぶなどしているが、言い方を変えた”より良いネーミング”もあるのでは。
〇 ”つねに見直し、チャレンジし続けよう”に関係するが、行政は完璧であることが前提に、いろいろなものができており、間違いが起きたとき、それを治す手法がないという話がある。そうではなく、誤りがあったら合理的な方法で、最大限早急に間違を治すという部分があったほうが良い。完璧でなければ始まらないという文化はやめたほうが良い。
〇 ”資源(データ）を最大限に活用しよう”という関係では、利活用するということが前面に出ている。活用することと同時に、データをオープンにしていくといことについても前面に出しても良いのではないか。ダッシュボードも良いことではあるが、データをオープンにすることで見える化を進めていくということは、今までの取り組みとも整合することである。
〇 ”誰一人取り残されないようにしよう”というなかで、すべてのユーザーや都民の方が行政サービスの恩恵を受けるためには、ダイバーシティという観点が重要である。世界的にも多くの先進国などで、高齢化の波が進んでいて、3人に1人が65歳以上になる超高齢者社会の先のポスト超高齢社会が到来するであろう考えている。また、世界ではデジタルシニアが拡大傾向にあるが、日本ではスマホやECが使える高齢者の割合がまだ低い状況で、日本のシニアの約４５％、アメリカやドイツ、スウェーデンンなどと大きく開きがでている。この状態はしばらく続くのではないかと考えている。
〇 また、情報弱者という面では、外国人への対応がある。国レベルではあるがデンマークやニュージーランドでは多言語対応でのデジタル行政が進められており、あらゆる社会課題となり得るグループへの想像力を持った丁寧な対応が大事である。
〇 このようなことから、”誰ひとり取り残されないようにしよう”とするためには、あらゆる手段の活用が大事であり、例えば、シニア活動会や老人クラブ、外国人居住者などの意見を積極的に取り入れる必要がある。また、自治会や高齢者クラブなどとネットワーク化することで、あらゆる世代が参画するような枠組みを作っていくことも一考かと思う。
〇 ”オール東京一丸となって取り組もう”について、国との施策の整合性や都内区市町村との連携はいずれも大事である。また、東京都は、世界ナンバー1のメガ都市でもあることから、日本のモデル都市として、世界ナンバー１のデジタルシティとしての価値を高めていく必要がある。この作り手となる職員のモチベーションを上げるための啓蒙活動を行うと同時に、どういう街が住みやすいのか検討していくことも大事である。
〇 規範を浸透させていくためには、トップダウン、ボトムアップの両方向から取り組んでいく必要がある。10か条を定めるのはトップダウンであり、一方で、（資料１「先行事例ヒアリング：クレディセゾン株式会社」に記載されている）印象的なエピソードを形造るということは、ボトムアップそのものである。
〇 従来組織に、スタートアップの創業経験者などが乗り込んで意見することは、すごくビックリすること。（受け入れる側も）異なる文化や人材や、これまでならばあり得なかった発言や行動を受容していくということと、マイノリティ側も従来のやり方や事業、システム、人に対してリスペクトしながら、いままであり得なかった発言をすることが必要である。総じていうならば、“HRTの原則”（Hはhumility＝謙虚、Rはrespect＝敬意、Tがtrust＝信頼）を互いに実践していくことが重要である。
〇 今後、意見を出し合うワークショップをやっていくことということではあるが、その場での意見をいかに受容できるかが重要である。
このほかにも、ご意見をいただいており、詳しくは、デジタルサービス局のWebサイトに後日掲載予定です。
福島県磐梯町様へのヒアリング結果については、別途、noteにて共有する予定です。
3 標準プロセスの検討状況
次に、標準プロセスの検討状況を事務局より報告しました。
この標準プロセスは、システムやサービスの開発・運用に携わる職員が、機能別ガイドライン全てを読むのではなく、担当するシステム開発・運用の各フェーズ・プロセスにおいて、どのようなことに注意すべきなのか、簡単に確認できるようなチェックポイントを設定するために作成するものです。
このため、今後、今回の提案した検証モデルを基に、各ワーキンググループでプロセス別チェックポイントの抽出を行いつつ、各ワーキンググループで議論したプロセスを統合し、標準化を図って行っていくことを想定しています。
【STEP1：当面の標準プロセス設定範囲の整理】
今回、ワーキンググループで検証するための検証モデルを設定するにあたっては、まず、どの範囲を対象とすべきなのかの検討を行いました。
検討にあたっては、①システム・サービスの開発の目的と、②開発手法、③調達範囲の３つの視点から整理を進めました。
まず、システム・サービスの開発目的を、SoR、SoE、SoIに分類し、そのうえで、ウォーターホールやアジャイル、プロトタイプなどの様々な開発手法を組み合わせ、都の現状を踏まえつつ、開発目的に応じた開発手法を設定し、都において主流となっているSoRのウォーターホール型開発と、最近取り組んでいるSoEのアジャイル型開発を、当面の標準プロセスの設定範囲として整理しました。
【Step2：設定範囲に応じた『検証モデル』を設定】
また、当面の標準プロセス設定範囲に合わせて、調達等の視点から、状況に合わせて改変していく必要性に応じた”システム・サービスの柔軟性”と、開発・運用なのか、または、イラスト作成や受付処理などの業務を含むものなのかという”委託範囲”の２つの観点のもとに、具体的にどのようなシステムやサービスを検証していくのか整理し、都の開発において比較的多い基幹系業務システムと、Web系サービス（ホームページ作成等）を、優先して取り組んでいく『検証モデル』としました。
【Step3：『検証モデル』に応じたプロセスを抽出】
さらに、当面の標準プロセス設定範囲に応じて、各検証モデルごとに標準プロセスの設定を行うため、検証モデルの開発目的に応じて２つの開発手法（ウォータフォール型とアジャイル型）を想定し、検討を行った結果、この２つの手法ではプロセスごとの作業量や重きを置く観点は大きく異なるが、ウォータフォール型に対してアジャイル型は、一部プロセスが反復的になるが、構成されるプロセスは共通しているものとして、整理しました。
今後、今回、提案した３つの検証モデルを基に、各ワーキンググループで検証を進めていく予定としています。
《構成員の皆様からいただいた主なご意見等》
〇 検証モデル①については、今までと全く変わらないという整理になるが、①のモデルにおけるUI/UXの観点では、②－１や②－２に関係する人材や組織、文化などを①にも溶け込ませていくことが重要である。（検証にあたっては、モデル間に）境界線をつくるのではなく、コミュニケーションをとっていくよう、会議体を設けるなどの仕組みを設計すべきである。
〇 ３つのモデルで検証していくということは、縦割りのモデルをつくることにもなるのではないか。
〇 ウォータフォールであっても要件定義が重要である。この段階で、SoE開発に携わるメンバーがUI/UXにかかるチェックを行うというプロセスを標準化するのでも良いのではないか。
〇 SoRにSoEの観点を溶け込ませるためには、3次元的な人材アーキテクチャも必要となるのではないか。
〇 レビューがテストの後ろにしかない。UIのことを含め、テストよりも前にレビューがあっても良いのではないか。
〇 ウォータフォールにしてもアジャイルにしても、組織の形態に向き不向きがある。組織の面でもアジャイルに対応したものを作っていく必要がある。
〇 アジャイルを実装しようとするときは、調達の面でも、からませて考えておかないといけない。
〇 運用という観点も重要では。今回示されたプロセスにはこの部分がないのでは。オペレーションという観点でのプロセスが必要ではないか。
〇 SoR、SoEに応じて、それぞれオペレーションのやり方や流儀は異なる。SoRとしては、外部のベンダーに委託することが多いが、SoEやモード2ではこれを含めて手の内化しなければ、自分事にならない。運用やリカバリーを自分たちでやっていくことで、ノウハウが蓄積されるとともに、開発と運用がシームレスにつながり、改善のサイクルを早く回していくことができるという感覚になっていきている。
このほかにも、ご意見をいただいており、詳しくは、デジタルサービス局のWebサイトに後日掲載予定です。
4 ワーキンググループの設置
第1回のサービス会議で提案し、了承された３つのワーキンググループについて、ワーキンググループメンバーや年度内における検討スケジュールについて、事務局から説明しました。
ポイントとしては、第1回サービス会議でいただいたご意見を踏まえ、各ワーキンググループにおいても、ガイドラインというドキュメントを作成していくだけでなく、どのようにその技術を受け入れていくための文化を作っていくのか、普及啓発策についても検討いただくとともに、トライアルしていくという点にあります。
今後、各ワーキンググループともに、1月にはキックオフミーティングを開催し、年度末にかけて検討を進めていきます。
東京デジタルサービス会議については、今後も検討状況について、いろいろな場面を通じて、共有してまいりますので、随時ご覧いただければと思います。
策定した行動規範についてご意見・ご感想を募集しておりますので、ご回答いただければと思います。リンクはこちら
この記事が気に入ったらサポートをしてみませんか？