※ IT技術者にとって重要なことが、後半に記されています。
※ 長文です。通常の2日分ぐらいあります。
――
「政府の情報管理を一元化する組織を設置せよ」という案は、私も前に考えたことがある。前にも言及した。
→ デジタル庁の設置: Open ブログ
だから、デジタル庁を設置するという方針そのものには、不満はない。
ただし、現在の方針を見ると、いろいろと問題点があることに気づく。
準備中というページ
「デジタル庁（準備中）」というページが、note という Web サイトの一部に開設された。URL は独自ドメイン。
なお、利用料金は月５万円の法人コースだ。
→ 企業の情報を発信するならnote pro
政府のサイトが note の一部分であるということには、疑問の声が多く出ている。
→ はてなブックマーク
私としても、難点をいくつか上げることができる。
・ 文字を色で修飾できない。（ note の仕様）
・ 目次がない。
・ サイト内検索ができない。（ note 全体の検索になる）
・ コメントするには note にログインする必要がある。
次の難点も指摘された。
「 robots.txt で、魚拓ページのクロールを拒否している」
このせいで、ページの保存（アーカイブ）が取れなくなっている。こいつは、安倍首相の「政府文書を残さずに、なるべく廃棄する」という方針と同じだが、デジタル庁そのものが、過去文書の廃棄に熱心だというのでは、本末転倒だろう。
デジタル庁は「行政の透明化」を掲げ、noteでの発信を始めます
と大々的に掲げているが、実態は「文書廃棄による証拠湮滅」をやっているわけだ。情けない。
※ アーカイブの拒否は、意図的なものというより、note の仕様らしいが。しかし、robots.txt を書き換えるだけのカスタマイズが、可能であるとは思えない。何しろ、文字を色で修飾する当程度のカスタマイズさえできないのだから。いわんや、サイト内検索をや。
こういうことが起こらないようにするには、普通のサイトを作ればいいだけだ。WordPress や Movable Type を使えば、初心者でもそれなりに Web サイトを作れる。
→ ブログから大規模サイトまで作れる CMS | WordPress.org 日本語
なのに、デジタル庁の職員は、その程度の知識もないのだろうか？ 「 HTML や CSS を書くだけの知恵もない」というのでは、先が思いやられる。
まったく、どこの素人がこんな none のサイトを使っているんだ。
せめて私みたいに、壁紙のデザインを変えるぐらいはすればいいのに。（ note は、カスタマイズの項目が非常に限られているので、それはできないが。そもそも壁紙すら存在しない。）
デジタル庁（本家）のサイト
デジタル庁（本家）のサイトもある。
→ デジタル庁（準備中）
「ただ今準備中」ということだが、これがまたひどいサイトだ。ネットリテラシーがあるのかよ、と疑いたくなる。
どこが駄目かというと、デザインが駄目だ。見映えがいいかどうかという以前に、「文字が読めるかどうか」という点で落第点である。
まず、基本としては、レスポンシブデザイン（スマホとパソコンで共用するデザイン）となっている。
・ 幅が狭い状態では、スマホデザイン。
・ 幅が広い状態では、パソコンデザイン。
すると、どうなったか？
(1) スマホで見る限りは、特に問題はない。
こういうふうにまともに表示される。
(2) パソコンで見ると、横に３段組になったり、２段組になったりする。次のように。
クリックして 拡大
これは、スマホページと共用にするために、こういうふうに分割したデザインにしたのだろう。だが、そのせいで、文字がやたらと小さくなっている。特に、２段組になっている箇所の文字が小さすぎる。
(3) そこで、文字を拡大するために、パソコンのブラウザでズーム（拡大）をしてみる。（ Ctrl ＋ マウスホイール）
すると、文字が拡大されて、見やすくなるのだが、同時に、レイアウトが崩れてしまう。
クリックして 拡大
これはひどい。文字がまともに読めない。
つまり、このサイトの文字は、どっちにしてもまともに読めないのだ。
・ 文字が小さすぎて読めない
・ 文字を拡大すると、文字が画像に隠れる。
どっちを選んでも、まともに読めない。このページをまともに読む方法はないのだ。ひどいものだ。
※ 「 note を使うなんて素人かよ」と思ったが、まさしくデジタル素人であるようだ。だったら note を使うのは、間違いではなかったのかもね。自力で作ると、こんなとんでもない Webサイトしか作れないのだから。「文字も読めないようなページ」を作るくらいなら、まだしも note の方がマシというものだ。note は「文字しか見えない」という感じもあるが。
（ 「文字情報は得られるが、文字の修飾ができない」という意味。「画像が表示できない」という意味ではありません。）
法案の解説
デジタル庁を設置する法案について調べようとすると、次のページが見つかる。
→ デジタル庁設置法案の概要 - 内閣官房（pdf）
このページは PDF なので、見やすくないし、コピペ（引用）もしにくい。不便な文書だ。
そこでとりあえず、私が画像のキャプチャを示しておく。
クリックして 拡大
また、上記文書のコピペも記しておく。（読まなくてもいい）
デジタル庁設置法案の概要
＜趣旨＞
デジタル社会の形成に関する施策を迅速かつ重点的に推進するため、デジタル社会の形成に関する内閣の事務を内閣官房と共に助けるとともに、デジタル社会の形成に関する行政事務の迅速かつ重点的な遂行を図ることを任務とするデジタル庁を設置することとし、その所掌事務及び組織に関する事項を定める。
＜概要＞
１．内閣にデジタル庁を設置
２．デジタル庁の所掌事務
(1)内閣補助事務
・デジタル社会の形成のための施策に関する基本的な方針に関する企画立案・総合調整
(2)分担管理事務
・デジタル社会の形成に関する重点計画の作成及び推進
・個人を識別する番号に関する総合的・基本的な政策の企画立案等
・マイナンバー・マイナンバーカード・法人番号の利用に関すること並びに情報提供ネットワークシステムの設置及び管理
・情報通信技術を利用した本人確認に関する総合的・基本的な政策の企画立案等
・商業登記電子証明（情報通信技術を利用した本人確認の観点から行うもの）、電子署名、公的個人認証（検証者に関すること）、電子委任状に関する事務
・データの標準化、外部連携機能、公的基礎情報データベース（ベース・レジストリ）に係る総合的・基本的な政策の企画立案等
・国・地方公共団体・準公共部門の民間事業者の情報システムの整備・管理に関する基本的な方針の作成及び推進
・国が行う情報システムの整備・管理に関する事業の統括監理、予算の一括計上及び当該事業の全部または一部を自ら執行すること
３．デジタル庁の組織
(1)デジタル庁の長及び主任の大臣は内閣総理大臣。
(2)内閣総理大臣を助け、デジタル庁の事務を統括するデジタル大臣を置き、２(1)の事務を円滑に遂行するため、関係行政機関の長に対する勧告権等を規定。
(3)副大臣一人及び大臣政務官一人に加え、デジタル大臣に進言等を行い、かつ、庁務を整理し、各部局等の事務を監督する内閣任免の特別職として、デジタル監を置く。
(4)全国務大臣等を議員とする、デジタル社会の形成のための施策の実施の推進等をつかさどるデジタル社会推進会議を設置。
４．施行期日等
(1)施行期日：令和３年９月１日
(2)一定期間後の見直し、関係法律の改正について規定。
以上から、デジタル庁の業務が何であるかが判明する。それは、
「政府のデジタル業務の管理」
である。つまり、これまでの各省庁のデジタル業務全般について、一段高い視点から、指導したり管理したり推進したりする。また、分野によっては全部または一部を自ら執行することもある。
要するに、部下に対する上司のような役割である。
しかし、「これでは駄目だ」というのが、私の判定だ。以下で説明する。
失敗の事例
これまでにも、政府のデジタル業務では、失敗してきた例が多々ある。たとえば、下記のように。
(1) COCOA
コロナ接触確認アプリ（COCOA) というものが開発されたが、これがまったくの役立たずのゴミぷりであることが判明した。すでに詳しく報道されたとおり。
ここでは、発注した厚労省がアプリについてまったく無知であることから、ほとんど丸投げの形で民間企業に随意契約をしたのだが、その民間企業自身が無知であるために、そこからさらに下請け会社に丸投げ状態となり、まったくの無責任体制と成り果てた。
(2) ワクチン予約システム
コロナのワクチン予約システムが全然ダメだった。
河野太郎・行革相が次のように述べている。
河野太郎行政改革担当相は12日夜のTBS番組で、新型コロナウイルスワクチンの高齢者接種予約が殺到している事態について「効率性より住民の平等性を重んじる自治体が多かった。これは完全に僕の失敗だ」と陳謝した
（ → 行革相「完全に僕の失敗」 ワクチン予約殺到巡り ｜ 共同通信 ）
河野太郎の見解には、次のような批判もある。
Gl17 「効率性より住民の平等性を重んじる自治体が多かった」いやそこじゃねえ、何で各国並みに国が率先して特別な接種体制を大規模構築しねんだよ。未だ自治体ガー言ってる感覚が100%平時じゃねえか、お前が。
（ → はてなブックマーク ）
一方、ワクチン予約システムが使いにくいということについて、次のような報道もある。
→ ワクチン予約、高齢者「難しくてできない」 ネットは複雑、電話は混雑
→ 70回線に９万件着信 ワクチン予約電話、初日から大混雑 高齢者「ネットは難しい」
使いにくいというが、具体的にはどんなものか？ それを知ろうとして、実際に試してみようと思ったのだが、入口で はじかれた。（ログインするためには、郵送で送られた「接種券番号」（半角10桁）を入力する必要がある。対象者以外はログインできないのだ。調査失敗。残念。）
対案
では、どうすればいいのか？ デジタル庁が駄目だとしたら、どこをどう是正すればいいのか？ それについて、以下で説明しよう。
法案を読むと、デジタル庁の仕事は、デジタル業務の監督や指導であって、具体的なデジタル業務そのものは、各省庁の各部門に所属することになるようだ。
つまり、基本は現状通りであって、それに対して修正を加える、という程度のことであるらしい。（一部の移管を含む。）
しかし私としては、「デジタル業務の全面的な移管」を提案したい。つまり、こうだ。
「各省庁のデジタル業務の執行は、すべてデジタル庁が担当する。ソフトウェアの発注もデジタル庁が担当する」……（i）
これはつまり、《 企業で言えば「情報システム部」をすべて、別会社（デジタル庁）に外注する 》ということに相当する。……（ii）
換言すれば、《 デジタル庁の分局が、各省庁に分散して配備される 》ということでもある。つまり、「分駐」だ。……（iii）
ひるがえって、現状では、各省庁には「情報システム部」というものが存在していない。かわりに、各省庁の各部局内で、個別に「情報システム担当者」という個人が何名かいるだけだ。それらの人々は、専門的な IT技術の知識がない。だから、COCOA の発注ミスのような素人的な失敗を重ねることになる。上の「失敗の事例」のように。
そして、そういうことを避けるのが、上記の （i）（ii）（iii） だ。
※ 上の「失敗の事例」を見て、なんでこの話が出たのか、わからなかった人もいるだろう。だが、すぐ上の話を読めば、意図がわかるだろう。「失敗を避けるための組織」を示すために、他山の医師となる事例が必要だったわけだ。
アジャイルとウォーターフォール
もう少し専門的な話をしよう。ソフトウェアの開発には、二つの方式がある。アジャイルとウォーターフォールという二つだ。
高井氏：ソフトウェアの開発は、米国のシリコンバレーなどではアジャイルという方式で行われています。エンジニアが企画者や実際に使う人と直接コミュニケーションを取りながら開発する方法です。中国もそうですね。この方法によって、新しいサービスが米国や中国から次々と生み出されています。
それに対して、日本の開発の多くはウォーターフォール方式です。工程別に分けて、モジュールごとに開発します。開発部分を多重下請けで働く人たちが担っています。
――ウォーターフォール方式だと、なぜよくないのでしょうか。
高井氏：私はいつも、システム開発はお絵描きと同じだと表現しています。あなたの好みの女性像を私が描く場合に、ウォーターフォール方式だとまずヒアリングをします。そのヒアリングした文字情報をもとに専門家に描かせて、出来上がったら見せます。これでイメージ通りの絵ができているでしょうか。
――それは難しそうですね。
高井氏：そうですよね。これがアジャイル方式だと、「目の大きさはこれくらいですか」「髪の毛の長さは」「髪の毛の色は」と聞きながら、同時に見せながら描いていきます。小さいパーツの確認も取りながら、全体像も見てもらう。シリコンバレーや中国ではこのようにして開発が実行されているのです。
（ → IT業界の「多重下請け地獄」が横行し続ける真の理由：「IT後進国ニッポン」の病巣に迫る【前編 ）
もっと詳しい話は、下記にある。
→ アジャイル開発とウォーターフォール開発の違いは何？アジャイル開発の手法や意味も要チェック
→ アジャイル開発とウォーターフォール開発は何が違う？併用はできるの？
→ 開発手法の比較！アジャイル vs ウォーターフォール
アジャイルとウォーターフォールは、どちらかが一方的に優れているというわけではない。一長一短ふうではあるが、単なる一長一短とも違う。それはどういうことか？
理想を言えば、こまめに仕様変更を繰り返して最適化をめざすアジャイルの方がいい。いろいろと条件がそろっているのであれば、アジャイルを採用するべきだ。
ところが現実には、アジャイルを採用したくても、採用できない。なぜなら、発注する側がソフトウェアに無知だからである。自分が何を発注したらいいのかをわかっていない状態だ。
典型的には、こんな感じだ。
顧客が本当に必要だったものについては、顧客自身がよく理解できていないのだ。自分でもうまく説明できないのだ。
こういう状態では、アジャイルをやろうとしても、やれるわけがない。顧客自身が何を望んでいるか わかっていないからだ。
デジタル庁の役割
ここまで見ると、デジタル庁のなすべきことがわかる。それは、こうだ。
「（顧客である）発注の現場の要求をきちんと理解して、それをプログラマの用語に変換するという、翻訳者の役割」
発注の現場では、（実務で）何をしたいかということは、よくわかっている。しかしそれをプログラムの用語で説明することはできない。漠然と「使いやすくしてくれ」と言うことはできても、「では使いやすいとは何を意味するか」ということが具体的には説明できない。
そこで、発注の現場で求められていることを、きちんとプログラマ向けの言葉（つまり仕様）に翻訳する必要がある。
たとえば、デジタル庁の本家ページ（上記）では、サイトを見やすくしたい。ここでは、「見やすく」という言葉を、次のように翻訳することが必要だ。
・ スマホでもパソコンでも読み取れる。（＝ レスポンシブ）
・ 文字を大きくする。（小さい文字は不可）
・ 拡大（ズーム）に対応できる。
・ 色盲、色弱への対策をする。
・ PDF ソフトがなくても読み取れる。
・ ユーザーが文字をコピペできる。
また、COCOA のようなアプリでは、受け取ったものをきちんと検収できる（不備がないか確認できる）だけのデジタル知識が必要だ。
そういう役割を果たすのが、デジタル庁だ。
この図のように、現場と開発者とは、分断されている。両者は乖離している。顧客は、自分が本当に求めているものが何であるかを、うまく説明できない。
そこで、この両者をつなぐ橋渡しをする者が必要となる。それが、デジタル庁だ。デジタル庁は、次の両方をよく知っている。
・ 現場における要求事項
・ その要求事項が IT用語では何を意味するかという IT知識
こうして、橋渡しをする者がいるおかげで、双方の分断は解消される。
現場は、自分が何を求めているかを、普通の言葉で語るだけでいい。（ IT用語で語る必要はない。）その語り方が不十分であれば、それを聞いたデジタル庁は、現場に質問を繰り返して、明確なIT用語に翻訳する。その翻訳を開発者に伝えることで、分断は解消する。
開発者は、自分が開発しようとするものを、デジタル庁に見せるだけでいい。それにどのような不備があるかを、発注の現場が理解する必要はない。デジタル庁が不備を発見して、開発者に修正を要求する。こうして開発者の不備は次々と修正されて、分断は解消する。
結局、デジタル庁が介在することで、アジャイルは可能になるわけだ。
――
逆に言えば、日本の会社や政府の多くで、アジャイルが使われず、ウォーターフォールばかりが幅を利かせているのは、デジタル庁に相当する「翻訳者」がいないからだ。そのせいで、現場と開発者が分断されている。かくて、アジャイルを採用したくても採用できないまま、ウォーターフォールという前近代的な恐竜のようなものを採用せざるを得なくなる。
前出サイトでも示されているように、ウォーターフォールという方式を採用すると、多重下請け構造を取らざるを得ず、組織全体の生産効率が落ちてしまう。日本の IT業界全体の問題でもある。だから IT技術者は、米国や欧州や中国やインドでは高給を取れるのに、日本では高給を取れない。それというのも、国全体で非効率な方式（ウォーターフォール）を採用しているからだ。
そして、その根源は、中間にあたる「翻訳者」がいないせいで、双方が分断されているからなのだ。
その穴を埋める役割が、デジタル庁に求められる。
――
では、そのために必要なことは？ それは、「発注の全権限をデジタル庁に移管すること」だ。デジタル庁は、発注の監督や指揮や管理や一部事務をになうだけでは足りない。発注の全権限をになうべきなのだ。
それと同時に、現場の声をよく聞くためのヒアリング業務を実行するべきだ。
このすべてを実行するためには、かなり多くの公務員（技術者）を必要とする。そのためには、民間の技術者を大量に採用する必要がある。そのための人件費は多大に上るだろう。
しかし、それに輪をかけて、開発費を大幅に削減できるはずだ。COCOA 開発やワクチン接種システム開発で、莫大な費用を投じたあげく、ゴミみたいなソフトを入手した……というような失敗は、なくなるはずだ。（ちゃんとやれば。）
【 関連サイト 】
先の紹介したページ（【 前編 】）には、その続き（【 後編 】）がある。下記だ。
→ IT業界の「多重下請け問題」を変える真の方法とは？ 1次請けから3次請けまで経験した社長が提唱する「0次請け」：「IT後進国ニッポン」の病巣に迫る【後編】
しかし、ここで述べていう「対策」は、てんでマトはずれだろう。はてなブックマークでも、悪評ふんぷんとなっている。そこで示した対策というのは、てんで見当違いであるようだ。
※ 開発者（社）の側で、会社の内部構造を変えることで対処しようとしているが、それでは駄目だ。発注者の側がまともになっていないのでは、しょせんは無難が埋まらない。開発者（社）だけがいくら努力しても、「顧客が本当に必要だったもの」は作れないのである。
ここにあるのは「間違った正解」であるので、私が「正しい正解」を本項で示したわけだ。
本項は、次項に続きます。
→ デジタル庁の組織: Open ブログ （次項）
「デジタル庁「noteはじめました」→ドメインが「.go.jp」であることの問題点を高木浩光先生が指摘」
https://togetter.com/li/1714221
「 note 社のシステムに収まっている（間借りしている）のだから、 go.jp という政府ドメインを使うべきではない」
という趣旨。
おおむね妥当だが、「本人開示請求」を持ち出すのは筋が悪い。
「管理者権限が政府になく、note 社の管理下にあるのが駄目だ」
と指摘するだけで足りる。
じゃあ、どうすればいいかというと、 go.jp でなく co.jp にすればいいのか、と思ったが、これは無理。 co.jp は、まともな企業に限られるので、政府や部局は不可。ただの .jp ドメインというのがあるので、それが妥当か。
（ググればわかる。）
「説明しますので、30秒だけお時間ください！」
と書いてあるが、あからさまな嘘だ。30秒で読めるわけがないだろ。
この嘘のひどさは、（遺留捜査の）磯村くん並みのひどさだな。（そっちは「 3分間だけ」だったが。）
https://dogatch.jp/news/ex/46443/detail/
「デジタル庁の最初のお仕事は？」
「まず、嘘をつくことです」
ただし、発注側は丸投げができません。一週間で次のバージョンが来てチェックしないといけませんから。
そういう意味で日本のお役所相手にアジャイル開発は無理なのではないでしょうか。
> 違うと言ってもらえば良い
「違う」と言われて、「どこが駄目なんだ？」と質問して、「よくわからないけど、何となく」という返事しか返ってこないと、直しようがない。どう直したらいいのかわからない。
顧客が……のイラストの通りになる。
――
「発注側がわかっていない場合に、どうしたらいいか？」
がテーマではなくて、
「発注側がわかっていない場合には、発注側がわかるようになれ」
が結論です。
「発注側がわかっていない場合に、どうしたらいいか？」
ということなら、どうしたって駄目です。アジャイルでもウォータフォールでも、どっちでも駄目。
「馬鹿はどうしたらいいでしょう？」
という質問には、
「馬鹿は死ななきゃ治らない」
と答える。
→ 「誰でも何度でも予約可能」 ワクチン大規模接種東京センターの予約システムに重大欠陥
https://dot.asahi.com/dot/2021051700045.html