プログラマとスクラムが社会実装を変えていく #Findy_GovTech
今夜、ガバテックの話をZoomで聞いていた。
話は面白かったが、色々考えさられた。
考えたことをラフなメモ書き。
【参考】
経済産業省デジタル化推進マネージャーと弁護士ドットコムが語る!行政にエンジニアが関わる意義 - connpass
【1】政府行政をエンジニアが関わって、DXを推進していくのがガバテックと言えるかもしれない。
パネラーが言うように、今まさに旬のテーマ。
デジタル庁ができるし、ITエンジニアがより政治に関わっていくこともできる。
パネラーは、エンジニアリングで社会実装を変えていく、と言っていたが、話を聞いていたら、僕は「プログラマとスクラムが社会実装を変えていく」という意見を持った。
理由は2つある。
【1-1】1つ目は、プログラマが政府行政のIT化で活躍できる場がすごく多く、昔から受け継がれる問題、今まさに直面している問題に対し、プログラマしか解決できないテーマが多すぎるから。
たとえば、コロナワクチン接種管理システムの構築もそうだし、コロナ不況で失業したり、緊急事態宣言でビジネスを制限された人達に補助金を出すシステムもそう。
こういうシステムが必要とされているのに、インフラ構築できない、Webシステムを構築できない、業務要件をデータモデリングでまとめられない状況にある。
政府行政にいる人達は、ITの専門家ではないのだから、そういう技術に詳しくないのは当然だ。
だからこそ、ITエンジニアがより深く関わるチャンスがあるし、それによって、社会を変革していく道筋も生まれる。
ハンコ押印を使った各種申請、税金の支払いが楽になるだけでなく、より積極的に、ITという手段を通じて、政府を通じて世の中をより良くしていく、という活動にコミットできるわけだ。
【1-2】2つ目は、プログラマが政府行政のIT化に関わっていく場合、組織体制はスクラムに即した体制にならざるを得ない印象を持ったから。
パネラーが言うには、政府行政で、パネラーに協力してくれる人達は、事実上、プロダクトオーナーの役割を担ったり、色んな部署と調整したり、逆にパネラーのようなITエンジニアを守ってくれるような活動をしてくれたらしい。
パネラーのようなITエンジニアと政府行政の人達の間に信頼関係が構築できたことで、より深くコミットすることもできた、と。
そういう話を聞くと、まさに、そういう組織体制はスクラムで実装することになるだろう、と思う。
なぜならば、スクラムを適用すれば、スクラムの3つの役割にピッタリ当てはまるからだ。
【1-3】国民の公共サービスの利便性を提供するようなサービスを提供するケースを考えよう。
すると、そのような業務要件を考えるプロダクトオーナーが必要であり、政府行政の業務や法律に詳しい、政府行政の人達自身が担当する。
インフラを構築したり、システムを実装したり、セキュリティ対策を考える人達は、各分野のITエンジニアがチームを形成する。
そして、外部から雇い入れたスクラムマスター、または政府行政の人でファシリテーションが上手い人が、プロダクトオーナーとチームの間で調整する役割を担うだろう。
結局、そのようなプロジェクトチームをシステム毎にたくさん作り、スピード感を持って政府行政のDXを推進していくしかないだろう。
【2】しかし、政府行政のDX推進を妨害する問題は、内製開発できずにベンダーに発注してベンダーロックインになってしまうことだろう。
現状は、政府行政の中の人達が、ITプロジェクトをマネジメントする能力が不足しているし、発注者として、プロダクトオーナーの役割を果たす能力も不足している。
【2-1】本来のあるべき姿は、政府内部で公共サービスを提供するシステムは、全部自前で開発できると一番いい。
リリース後も常に保守する責任を持つし、サービス利用者の声を集めることで、次々に新たなサービスを提供して利便性を高めて、世の中をより良くしていくことができるはずだ。
そういう内製開発が政府内で実現したならば、SaaSベースの開発スタイルになるだろう。
文字通り、ソフトウェアでサービスを提供するわけだ。
理由は、「ソフトウェア・ファースト」の本に書いてある通りと全く同じ。
そして、そのシステム開発のプロセスはスクラムで行われるのが自然だ。
政府行政内の人がプロダクトオーナーを担当し、その業務要件がプロダクトバックログで表現され、サービス利用者が使いやすいように、業務フローやデザインは、ストーリーテリングのように数々の利用ストーリーを踏まえたもので作られるだろう。
【2-2】しかし、現状はギャップが大きすぎる。
パネラーも言っていたように、いきなりデジタル庁で解決するわけではないだろう。
おそらくは、デジタル庁のメンバーは発注者のプロジェクトマネージャーの立場がまず求められて、そういう仕事から現状の問題をこなしながら、今後のあるべき姿へ地道に変革していくことになるのではないか。
【3】しかし、政府行政のIT化の根本問題は、個人のプライバシーとどのように折り合いをつけるべきなのか、があると思う。
【3-1】実際、確定申告のWebシステムであれ、コロナ接触管理アプリCocoaであれ、国民全員に10万円をばらまいた補助金であれ、全て、国民1人が持つプライバシーをどのように扱えばいいのか、に苦慮している。
そもそも、中国のような監視社会であれば、個人の行動履歴、購買履歴、所得や資産情報、医療情報も全て、政府が把握できているのだから、本当に困っている人達に特定して補助金を配ることもできるし、特定した感染者を強制隔離することで、世間の人達の健康を守ることもできる。
だが、政府の公共サービスでは、個人のプライバシーが他人に悪用されるリスクや脅威がとても影響が大きいために、セキュリティ面の対応によって、機能は複雑化し、業務フローもとてもややこしくならざるを得ない。
たとえば、確定申告のeTAXは、なぜあんなに、スマホでもPCでも使いにくいのか、とみんな思っているのではないか。
しかし、過去の歴史を踏まえると、政府に個人情報を預けると何をされるか分からないという、命に関わる危険性をみんなが持っていたし、政府を信用していないから、プライバシー保護という名目で、今までこの問題を放置してきた。
コロナ感染という特別な状況が、その問題が自分たちの生活に直結するぐらい重要である、と分かってきたのではないか。
【3-2】一方、今回のコロナ不況で薄々分かったことは、我々自身も、政府の行動が信用できるならば、自分の個人情報を預けてもいい、と考えているのではないか。
実際、現在の政府の公共サービスは全て申請主義なので、サービスを受けたければ、自分たちからたくさんの書類を集めて、大量の文書を書いて、提出後は長く待たないといけない。
本当に困っている人達に、給付金を直接渡すべきなのに、政府から困っている人達を特定できないから届けることもできない。
よって、失業者が溢れたり、犯罪者や自殺者も増えたりして、社会自体が重苦しく、不便なものになっていく。
だからこそ、そうならないように、例えば、本当に困っている人達に給付金を配ったり、あるいは、コロナワクチンを接種すべき人達を政府自身が特定すべきだし、それらを一括管理できるようにすべきだろう。
【3-3】他方、プライバシー保護のグレーゾーンや法律のグレーゾーンに積極的にリスクを取って関わっていくことで、新しいビジネスを生み出すことの重要性も分かってきたのではないか。
たとえば、テスラは電気自動車を単に提供するだけでなく、販売した電気自動車の走行ログをもとに自動運転技術をより強化させている。
また、走行ログというビッグデータをもとに、自動車損害保険ビジネスに乗り出す、とか、Uberのような配達ビジネスに自動運転をミックスしたビジネスも生まれるだろう。
アップルも、アップルウォッチを提供することで、個人の健康情報を収集することで、ヘルステックという新たなビジネスを生み出そうとしている。
個人の健康情報のログをもとに、医療サービスや保険サービスの新たなビジネスが生まれるし、健康に関わるスポーツビジネスも生まれるかもしれない。
【3-4】つまり、個人情報の保護がグレーゾーンであっても、それに関するビジネスにソフトウェアが決定的に重要な役割を果たし、大きく社会を変えている状況では、この流れに乗り遅れると、もはや国自体が衰退するしか無い。
実際、コロナ感染の社会状況において、日本の大臣は、日本はデジタル敗戦だ、という発言もした。
すなわち、日本はソフトウェアでビジネスを変革するだけでなく、ソフトウェアで公共サービスや社会を変革していくことすらも、他国から大きく遅れてしまった。
米国は、多くのベンチャー企業などが法律のグレーゾーンをものともせずに、ソフトウェアで新たなビジネスを生み出した。
中国は、一党独裁の統制社会を維持するために、ソフトウェアを上手く利用して、インターネット規制やネット検閲、監視カメラなどによる監視体制などを利用してきた。
もちろん、BATのようなIT大企業も生み出しているが。
EUもプライバシー保護や民主主義を掲げてGPDRとか色々作ってきているが、結局、米国や中国のソフトウェアビジネスやソフトウェアの変革の波から乗り遅れているのではないか。
【3-5】そんなことを考えると、プライバシーはもちろん重要だが、各種申請や税金支払、補助金受け渡しのような公共サービスの利便性を求めたり、コロナ感染のように公共性を重視すべき場面では、ある程度のプライバシーは政府に委ねる方向性に今後進んでいくような気がしている。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「ソフトウェア」カテゴリの記事
- Javaのモジュールシステムの考え方をまとめてみた(2022.10.21)
- Javaのenum型はシングルトンクラスみたいだ(2022.06.20)
- テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること(2022.02.09)
- 「RubyやRailsは終わった」という記事のリンク(2022.01.09)
- 実践した後に勉強するのがエンジニアの本来の道(2022.01.09)
「ビジネス・歴史・経営・法律」カテゴリの記事
- ビジネス書の名著はどれ?(2023.09.18)
- 営業は顧客の”購買代理人”である(2023.08.16)
- 第85回IT勉強宴会の感想~概念データモデルからビジネスモデルを構築すべきという考え方(2023.05.13)
- 令和4年度春期試験のITストラテジスト試験第4問をastahでモデル化してみた(2023.04.15)
- ChatGPTで起きている事象の意味は何なのか(2023.04.02)
「プロジェクトファシリテーション」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 「世界を動かすプロジェクトマネジメントの教科書」の概念図(2022.01.16)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- 昭和の管理者の承認処理は判子押印、令和の管理者の承認処理はいいねボタンを押すこと(2021.12.31)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
「Agile」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
「経済学・ERP・財務会計」カテゴリの記事
- ビジネス書の名著はどれ?(2023.09.18)
- 第85回IT勉強宴会の感想~概念データモデルからビジネスモデルを構築すべきという考え方(2023.05.13)
- 令和4年度春期試験のITストラテジスト試験第4問をastahでモデル化してみた(2023.04.15)
- 経営戦略とIT戦略をつなぐ鍵は何なのか(2023.01.04)
- 計量政治学と計量経済学の考え方の違い(2022.10.02)
コメント