DXやEUCと、初心者向けコミュニティと、倫理の話
要約
DXとかEUCとか、その周辺技術とかのユーザーコミュニティへの、安易なオトモダチ化への警鐘。
具体的には「互いが互いを安易に肯定し合い、間違いに気がつかないまま、承認欲求だけを満たしていく装置」にしてはいけない、という話を、前提条件やステップも含めて書いていきます。
前提的なもの
この話は、非常に色々な要素が混ざり合っています。なので、長くなりますが、まず関連する要素を、個々に書きます。
尚、この記事の状況などは、2023年1月時点の状況をベースに書いています。投稿日時はシステム的に表示されると思いますが、念のため。
1. 現時点で、DXに正解や手本は殆どない
DXとか、市民開発者（市民開発）といった単語が、本格的に世間で騒がれ始めました。また、それに伴い、既存のユーザーに向けての、リスキリングという単語も、徐々に普及してきています。
これらについて、私は、技術や社会の進歩に伴うものなので、是非もない話と認識しています。より率直に言うなら、多くの人や、社会的な枠組みが、技術の進歩に追いついていないのではないか・・・と思うことはあれども、それをとやかく言ってもはじまらないのも、また事実なので。
さて、DX自体は新しい概念――少なくとも、人類社会の歴史から考えたら、極めて新しいものです。故に、先人の積み重ねてきた知見や、こうすれば良い的な枠組みは、さほど多くはありません。
つまり、DXに関する諸々を考えていく上で、過去の知識の集積というのはあまりアテにならず、
既存の社会ルールとの互換性
技術的に何ができるか、どんな制約があるか
といった要素から、演繹して作り上げていくしかないものと思います。（これは理想論や「べき論」ではなく、他に選択肢が思いつかない、という理由です）
それ故に、というわけでもないのですが、「それっぽいこと」を言ってしまうと、DX論として、語れているように見えてしまうことがあります。実際には、技術的な誤りや、あるいは組織論・運用論などに、非現実的な点（ともすれば矛盾や破綻も含む）があっても、です。
そも、仕組みや概念の導入は、相応に理論的であり、かつ、整合性がなければいけません。理想や抽象論だけでは制度や仕組みは作れないからです。
なので、具体的な仕組みや、運用に落とし込めない（落とし込む方法を語れない）DX関連の言説や主張は、すべて誤りと言っても過言ではないと考えています。
DXについて語る何かを見たら、この事情をまず、頭に置いてください。
2. 話し合いで解決できる、という誤謬
人と人、あるいは組織と組織などの、意見や利害、行動目的などが衝突した時などに、話し合いで解決するのは、一般論として、理想とされています。それが理想的であることは、私も否定しません。
ただし、話し合いで解決するかといえば、そうとは限りません。
有り体に言えば、話し合いで解決できるのは、妥協点がある場合です。妥協点という言葉をもう少し掘り下げると、利害や目的の競合に対して、（たいていは暗黙的な部分もありますが）以下のようなプロセスを踏むことになると思います。
相互の、相手に対する認識を揃える
双方の目的や利害の、軸をあわせる方法を確定する
同じ軸上に乗せた利害に関して、妥協点を確定する
さて、この中で、難しいのは1番目と2番目です。
逆に言うと、たとえば商売における、金銭的な部分のみの競合・トラブルであれば、1がやや不完全であっても、2は「金銭的な利害」という軸が共有されているため、解決がスムーズに向かいやすいわけです。双方の妥協点をとりやすいからです。
他方で、「組織のメンツ」とか「担当者の感情」といった、すりあわせの軸を共有しにくい部分が絡むと、解決は難しくなります。これは直感的に、あるいは経験的に、多くの人が認識しているのではないでしょうか。
日本の現代社会において、法的にも、一般倫理的にも、正当防衛などの特殊なケースを除いて、基本的に、物理的な暴力は否定されています。もう少し正確に言うなら、大きなペナルティが科せられます。
なので、話し合いで解決できない場合、
経済力等、外部への影響力によって相手を封殺する
訴訟等、社会的なフレームワークで決着をつける
なし崩し的に立ち消えになる（物別れになる）
の、どれかしかありません。話し合えば問題は解決する、などということはないのです。
3. ソフトウェアは科学がベースである
DXとか市民開発とかの基礎になるのは、いわゆる情報工学にカテゴライズされる科学です。科学とは何ぞや、という定義を、厳密に掘り下げるとなかなか難しいのですが、おおよそ「事実ベースで論証を重ねた知識体系」という点は、一般的な共通認識になると思います。
たとえば「1＋1＝2」というのは、実のところ、「数」という極めて抽象的なものを扱っているわけですが、「リンゴが1つあるところに、もう1つリンゴを置きました。リンゴが2つになりました」みたいな、検証可能な具体化もあり、科学的に（一定の条件下で）正しいと見なされます。
しかしながら、上記のリンゴの例えも、「後から置いたものと、最初に置いたものが、一定の同質性がある」みたいな前提を共有する必要があります。
という風に考えたとき、どこまでが「暗黙の了解」として、きちんと共有できるかどうか、あるいは共有されるべきか、というのも、実はなかなかに難しい課題であることは、先に述べておきます。
さりとて、情報工学もまた、科学の一分野です。当然、事実ベースですし、その最低限の前提は共有されなければなりません。最低限の事実として、技術的にできることはできるし、技術的にできないことはできません。
つまり、プログラムは思った通りに動くのではなく、作成された通りに動きます。ソフトウェアが、ある機能を実装しているかは、その作られ方に依存します。開発者の願望や、使用者の需要・思い込みでは決まりません。
というのは、極めて当たり前のことではあるのですが。実際に使う現場になると、それを「当たり前」とは言えなくなります。
ユーザーは往々にして「自分がやりたいこと」をソフトウェアが実現してくれると期待します。開発者、特に未熟な開発者は、自分が客観的にどう実装したかでなく、自分がどのような意図で作成したかで、ソフトウェアの動作を捉えようとします。
それは、言葉を選ばずに言えば「誤り」なのですが、同時に、人間とはそのような認知エラーを起こすものです。というか、認知エラーが発生することもまた、科学的に検証・証明されていますから、それを愚かだ、そんな誤りをするのが悪い、と切り捨てるは、科学的であはりません。
とはいえ、事実は事実であって、少なくとも何らかの形――他者からの指摘だったり、プログラムのテストだったり、コンピューターが表示したエラーだったり――で指摘を受けたら、その認識を改める必要はあります。
そこで「事実」よりも「意図」に縋って、感情的な対応を行うことは。人間的ではあるし、そういう行動をとるのもまた、人間である、という点を加味しても。情報工学ベースの活動を行う上では、科学的な対応ではない、と言うしかありません。
DXやEUCを進める上で、ソフトウェアが、極めて重要な要素の1つであることは、流石に異論は出てこないでしょう。（ここで言う「ソフトウェア」は、OSや、いわゆるSaaS等、広義のものです）
それはすなわち、ソフトウェアの開発・運用をする上で、科学的な考え方は一定量、求められます。運用するのは人間で、感情など不確定要素もあるので、1から10まですべて科学、とは、間違っても言いませんが、少なくとも、DXを推進する側に、その理解がなければ、そこが障害点になり得るのは自明です。
4. 市民開発者の意義
「市民開発者」という言葉について、やや一人歩きしている感じはありますが、元はCitizen Developerの訳語である、という点は流石に、そうそう異論は出ないでしょう。では、Citizen Developerとは何か、というのを繙くと、元はガートナーが定義した用語で、平易に訳すなら、「IT部門に属さず、業務部門で、自分または他人の業務を遂行するために、アプリケーションの開発も行う人」です。
さて、なぜ市民開発者が必要なのか、という点で言うなら、主要な理由は、
IT部門で個々の業務部門の要求を取り纏め、開発を行うことには、業務への理解のための時間などがボトルネックになる
アプリケーションを開発するための難易度が下がった（開発環境の進化や、ハードウェアの高性能化）
上記も、ガートナーの記事を読めば、だいたいその辺の輪郭はつかめるのではないかと思います。（というかその点の是非から問題にすると、本当に記事1つでは終わらない分量になるので。その解釈がおかしい、というなら、議論には応じるので、個別に連絡くださいませ）
ちなみに、上記の記事では、いわゆる「シャドーIT」と、市民開発は、明確に別のモノであると定義されています。
つまり、市民開発（市民開発者）を標榜しながら、IT部門との連携を行わず、単独でやってしまう（＝シャドーIT）ことは、語義からは外れた行いであり、詐称であることを言明しておきます。
言うまでもなく、市民開発者がなぜ求められるのかは、上記の存在理由に起因します。
そして、市民開発を導入することは、組織にとって、上記のメリットと引き換えに、業務部門による、独自アプリケーション運用の、管理コスト（ガイドラインの制定や、社内ITポリシーとの整合性の維持、監査の実施など）を生じさせます。
当然、それらのデメリットが、市民開発を社内に導入するメリットよりも重いと判断されれば、市民開発を行わない（市民開発者を認めない）ことも1つの方策となり得ます。
すなわち、市民開発を認めることが、合理的・先進的という画一的な話ではなく、あくまで、組織の置かれている状況や、IT部門のキャパシティ等の要素を加味した上で、導入の是非を決定すべきなのです。
故に、「市民開発者を志す人が、勝手に業務のためのツール・アプリを開発する」のは、市民開発者の定義を曲解した行いとなります。
それが何を意味するかというと、市民開発者向けのツールがサポートする機能・仕様の想定外だったり、あるいは市民開発によるベストプラクティスの範疇から外れているので、どのようなトラブルを引き起こすかわからない、リスク要因になっている、ということです。要するに、シャドーITのリスクなわけですが。
兎にも角にも、市民開発者を志すのであれば、上記のことを意識する必要があります。別に個人が「今の職場で必要とされない」スキルや技術を学ぶことが無駄とは言いませんが、市民開発者を受け入れる余地がない組織では、能力的に市民開発者になれる人が居たとしても、市民開発者としての活動はできないのです。
当然、市民開発者になれば業務を改善できるとか、新しいキャリアが開ける、という言説は、その点を無視していることになります。残念ながら、市民開発者の教育を標榜している人に限って、その現実を無視していることが多々あるのですが。
5. 千丈の堤も蟻の一穴より崩れる
アプリケーションやソフトウェアを利用したり、あるいは開発する上で、不具合（いわゆるバグや誤動作）に遭遇することは、避けて通れないと言って良いでしょう。
そして、それらの不具合は、僅かな不備から生じます。
すなわち、たくさんの要素を組み合わせてソフトウェア作り上げる中で、1つや2つの、誤認識や誤表記だったり、あるいは間違った理解や設定だったり、作成時の想定外だったりが、不具合の原因になるわけです。
もっとも「最初から最後まで間違いだらけ」みたいな状態では、そもそもソフトウェアとして、マトモに成立しません。
つまり、不具合を内包しつつ稼働することが現実的でないので、徹頭徹尾「動かない」という1点だけになり、バグも何もあったものではなくなるわけですが。
つまり、開発者の理解や知識の中に、1つでも間違いがあり、それを用いてしまうことは、すなわちバグや不具合を引き起こします。
他の知識は正しくても、結果としては「正しく動作しないアプリケーション」ができあがってしまいます。いやまあ、きちんとテストして、そこで露見して修正すれば、それで良いのですが。
特にアプリケーションが複雑化した現状では、全てのユースケースや状況を想定してのテストというものは、なかなかに難しいものです。
（いわゆる「単体テスト」レベルであれば、テスト駆動開発などの広がりもあり、完全なテストの敷居は下がっています。
しかし、要件定義レベルの動作を検証する、システムテストのレベルでの、完全なテストの実施というのは、条件によっては不可能ではないにせよ、工数は馬鹿にならないもので、特に市民開発という規模感においては、現実的ではないことが一般的と考えられます。
本題
1. 間違いが何をもたらすか
人間は誰もが間違いを犯します。
もし、その内容がクリティカルなモノ――たとえば人を死なせてしまった、等――であれば、完全な償いというものは現実的ではありません。死なせた相手を生き返らせるとか無理ですし。
しかし、単純に「間違った情報を発信した」だけであれば、大抵の場合は、取り返しはつきます。
理想を言えば、間違いを受け取った人すべてに対し、訂正を行い、かつ、その間違った情報によって被った損害を補償することでしょう。これをやれば、ほぼ問題ないと言って良いでしょう。
そこまでは難しいにせよ、少なくとも、責任範囲が契約等に示されているのでなければ、大抵の場合、適切に訂正を行い、周知すれば事足りると思います。
ところがです。現実的には、コレすらマトモにできない人が少なからず居るのです。
さて、「間違った情報かどうか」という点について、もう少し明確にします。
少なくとも、前提で語ったように、「科学的な観点で間違いと指摘（説明）できる」ないしは、「用語の誤用」、あるいは「根拠が不十分、因果関係などが不適切なままの断定」などは、間違いと言って問題ないでしょう。
あるいは、技術を運用する上での、いわゆるベストプラクティス（推奨される事項）も、少なくとも「知っていて、あえて逸脱するだけの理由がある」というのであれば兎も角、知らずに、そこに反する行いをすれば、往々にしてデメリットのほうがメリットよりも大きい結果を生じます。
それらもあわせて、「間違い」を広めることは、リスクが生じるわけです。
前提において、多くの知識が正解であっても、一部が間違っている場合、その知識を用いてソフトウェアを開発すれば、不具合の原因になり得ることを述べました。すなわち、欠陥品を作ってしまうわけです。
状況的に、その不具合が許されるかどうかは、ケースバイケースです。とはいえ、それが仕事であれば、何の責任も生じないということはあり得ないでしょう。
その結果がどのような形で生じるかは、たとえば「予定されていた期日までにアプリケーションが仕上がらない」とか、「業務用に作成したアプリケーションが正常に動作せず、誰かに迷惑をかける」等です。
抽象的に言うなら上記のような話なのですが、たとえば「誤動作で何度もWebサイトにアクセスしてしまい、DoS攻撃のような事態を生じさせた」場合、刑事的な責任は兎も角、民事的な責任を負う可能性は少なからずあります。
あるいは、作成したプログラムのロジックに問題があり、金銭の会計処理を誤った場合、結果としてそれが、組織としての粉飾決裁につながる可能性もあります。
どちらにしても、発生してしまえば、ともすれば前科がついたり、そうでなくとも職を失う、あるいは個人での補填が現実的でないレベルの賠償責任を負う可能性も含めて、レアケースと言えるほど非現実的ではない事態になります。
アプリケーションやプログラムを開発することは、個人が手作業でできる事務処理等の能力を、遙かに拡張することができます。しかしながら、その力には、それを正しく使えるようにする、という、相応の責任が伴うわけです。
アメリカの漫画や、それを元にした映画等の作品で「スパイダーマン」という人気シリーズがありますが、作中で、しばしば用いられる、
with great power there must also come -- great responsibility!
が、まさにこれですね。
さて、「間違う」ことの恐ろしさをここまで記載してきたわけですが、その反対に、「間違いに寛容すぎる」コミュニティが、インターネットでは増えてきています。この恐ろしさについて、記載していこうと思います。
2. 間違いを許容することの危険性
たとえば、IT関連の勉強会などのコミュニティで、「他人の意見を否定してはいけない」等と書かれていることがあります。
意見を否定しないのは別に良いことだと思うのですが、問題は、これが「技術的な誤りを否定しない」に拡大解釈されてしまっているケースが散見されます。
何なら、「技術的な誤りの指摘に対して、自分がそう思って書いたのだから問題ない」という、なかば屁理屈で逃げるケースすら目撃したことがあります。
あるいは、技術的な間違いを直接的に指摘することを、スラングとして「マサカリを投げる」と表現するようですが、「マサカリ禁止」などと称して、技術的な誤りの指摘そのものを禁止する場面すら見受けられます。（参考：マサカリの起源について - Qiita）
まあ、参加者がある程度の知識がそろっていて、若干の失言レベルでいちいちツッコミが入ると、というのはわからなくもないのですが、少なくともそれが許容されるTPOはかなり限られる筈です。
なぜなら、前述のように、間違った知識を初心者（あるいは学習者）が覚え込んでしまい、訂正されないまま、市民開発者として活動をはじめた場合、事と次第によってはクリティカルな結果を生み出すからです。
それは、問題を起こした本人が辛い（辛いで済むかは兎も角）だけでなく、その組織の関係者も巻き込みます。あるいは、事態が公になれば、他の「市民開発者」への風評にも影響するでしょう。
まあ、全てのアウトプットに対して、責任を持つというのも難しいものではありますが。少なくとも、初心者向けの何か（コミュニティそのものだったり、あるいはコンテンツだったり）は、相応に「間違いがない」ことを担保しないと、将来に禍根を残すわけです。
ですが現実的には、前述のように、表面的なギスギスを避けるため等の目的だったり、あるいは単純に技術力不足を隠すためだったりで、技術的な間違いの指摘を受け入れない（あるいは無視する）コミュニティが、少なからずあります。
それが初心者向けを謳っていたりすると、もう手がつけられません。
この話が私の妄想でない、と言うために、あえて実例を挙げましょう。
Twitterで主催されていた「ハジメの一歩会」なるプログラミングの教室（？）で、配列の合計値を計算させる、といった課題が出題されていたことがあります。
これの何が問題かというと、そもそもソフトウェアの開発のベストプラクティス的に、データとロジックは分離するのが常識であるにも関わらず、それを無視する形で出題していることです。（参考： ハードコーディング - Wikipedia 、 データとロジックを分離せよ - Qiita ）
もちろん、初心者向けに、ある程度話を簡単にする、という大義名分はあり得ます。それ自体は否定しません。問題は、「将来的にはこういうやり方はNGである」ことを伝えていないことです。
少なくとも、この教材から学んだ人が、将来にわたって、プログラムの中にデータを直接持たせるような構造にしたらどうなるか。
良くてコードレビューでボロクソに叩かれるか、最悪、上記のようなハードコーディングに起因する問題を引き起こして、責任を問われるか、です。
一事が万事とまでは言わないにせよ、こういった質の低い「教え方」をしている人が、きちんと教えた相手のフォローをしているのを、私は見たことがありません。
つまり、こういった教え方がある現実は、そのまま、誰かが落とし穴に嵌まって、事故を起こす未来を作っているわけです。
3. なぜ「群れたがる」「教えたがる」のか
ところで、何故、このような「間違いを許容する」コミュニティが生じるのか。これについては、私が観測する範囲で、2つの要因があります。
1つは、単純に「教える側が、自己肯定感を得られるため」であり、「教わる側も、成長している感が得られる」ためです。
元来、技術における安全性というものは、先人の失敗によって積み上げられてきた、「こうすれば安全」や「これをしては危険」といったナレッジ、およびそれを知識体系化したものによって支えられています。
それらは、言ってしまえば「わかりにくい」ものだったり、「面倒くさい」ものだったりします。
一般的に経験しやすい話では、自動車の運転を習った人などは、やや思い当たるフシがあるのではないでしょうか。
そして、いわゆるIT分野は、大半のモノがデジタルであり、自動車の運転のように、物理的な事故に直結するわけではありません。
いや、デジタルな事故も、前述のように、他人のサーバーに被害を出したり、金銭的なトラブルを引き起こすケースや、あるいは、個人情報が漏洩する等、現実世界の被害に直結するケースも含めて、看過できないものは、たくさんあるのですが。
初心者向けの教材として、「これは教材であって、本番ではもっと安全のための対策が必要だよ」という面倒な注意書きなどを、過度に入れてしまうと萎縮するのは、おそらくその通りです。
ですが、だからといって、それらを完全に省いてしまえば、リスクを知らないまま育った初心者が、どこかで被害を引き起こす（あるいは被害に遭う）こともまた、事実です。
なので、「初心者に物事を教える」というのは、本来、かなり難しいことなのです。
しかしながら、中級者～上級者に教えるには「超上級者」である必要がある（＝極めてハードルが高い）ためか、「教えたがる」人に限って、初心者をターゲットにする傾向があります。
そして、そのチョイスをする人に限って、初心者に教えることの恐ろしさは知らない（あるいは知っていて無視する程度に自己中心的であるので）ため、こういった問題が発生するわけです。
もう1つは、初心者の側で、「上級者にマウントを取られたくない」等という、気持ちはわからなくはないにせよ、安全よりも安心を求める傾向が強い人が居ることです。
どだい、コンピューターというのは割と非情なもので、人間に対して忖度はしてくれません。
アプリケーションやプログラムを開発する上で、何か間違った設定を行えば、容赦なく「エラーだぞ」と返してくるか、間違った動作を馬鹿正直にやるだけの装置と成り果てます。
そんなモノを相手にするのに、間違っただけで指摘されるのが嫌だ、というメンタルでは、どうあれ長期的な成長は見込めないのです。コンピューター相手に「ぴえん」してみせても、人間と違って何かが変わるわけでもないですし。でもまあ、そういう現実から目をそらし続ける人も一定数居るし、それをどうこうすることは、おそらく他人には不可能でしょう。
しかしながら、何故か未だに「IT業界に参入すれば簡単に稼げる」みたいな情報商材屋はそれなりに生存できている（＝稼ぎがある、騙されるカモが居る）し、前述のように市民開発者の需要そのものはあるので、入ってくる人が多いのが実情です。
まあ、この辺はTwitterで「#駆け出しエンジニアとつながりたい」なんていう、初心者が初心者と繋がって傷をなめ合いつつ、情報商材屋のカモにされるために（文字通り）雁首並べているようなハッシュタグが、延々と需要があり続けるあたり、如何ともし難い部分ではあるのですが。
とまれ、「（長期的に問題があることなど考えずに）短期的に成長感が得られる教え方」や「初心者同士で集まり、上級者からの指摘は無視しつつ教え合う」みたいなことに需要が出てしまうのは、前述のような事情によります。
結論
私たちがDXや、業務のデジタル化、あるいはEUCを成功させるために
陳腐な表現になりますが、2025年の崖が近づいてきた昨今、DXをはじめとする、ITの業務導入や、既存のレガシーシステムからの脱却は、多くの職場で喫緊の課題となっています。
残念ながら日本ではエンジニアが不足している（PDF注意）のは今にはじまったことでなく、その点を加味しても、いわゆるDX人材や、市民開発者の需要や、活躍の場は、これから広がっていくでしょう。
しかし、活躍の場が広がるからといって、技術的なハードルそのものが下がるわけではありません。ましてや、活躍するということは、それ相応に責任も増すことになります。
そういった現状で、プログラミングや、あるいはDX関連の技術を学ぶこと自体は、極めて価値があることです。
しかし、前述のように、技術的な誤りを過小評価する、あるいは無視することで学習のコストを短期的に踏み倒すようなコミュニティが増長すれば、それは長期的には、DX人材の成長の芽を摘むことになり、社会にとってもマイナスでしかありません。
否、「社会にとって」などという大上段に構えた表現でなくとも、個人が、短期的に「簡単に」習得したつもりになって、その実、長期的には自身を蝕む毒となり得るような、質の低い知識を溜め込んでしまえば、それはその人にとっても、幸せな結果でないことは明白です。
すなわち、真に世の中を良くし、あるいはIT分野で高度に貢献していく人材になりたいのであれば、そういった、主催者の利益のために、学習者を食い物にするスタイルのコミュニティとは、明確に訣別し、また、それらを淘汰していかない限り、事態は悪化していくばかりになります。
なぜならば、前述のように、きちんと成長する機会が奪われたIT人材が増えれば、市民開発者そのものの一般的な評価を毀損し、あるいは質が低いかわりに、参加のハードル「だけ」は低いコミュニティによって、そういった状況の拡大再生産が行われるからです。それはまさに「悪貨は良貨を駆逐する」という状況です。
こういった事態を防ぐためにも、私たちは、安易な「馴れ合いや、主催者側の利益のために、初心者を食い物にする、自称・初心者向けコミュニティ」に対して、きちんとNoを突きつけていく必要があります。
そして、これらのコミュニティの需要や、主導する側の利益は、前述したように「参加者の本質的な成長」とは別に存在するため、これらのコミュニティに対して、改善のための対話を行うことは、現実的には無駄です。
（まー、初心者に簡単に教えられて、かつ将来的にトラブルにならないような方法論を発明できれば、解決できるとは思いますが。そんなモノが作れたら、それだけで一生、遊んで暮らせるでしょう。そして現実的には、「作れば一生遊んで暮らせる」のに、誰も作ってないのが、そんなモノは作れないということの証左です）
しかしながら、そういったコミュニティの駆逐が成されなければ、日本のDXや、EUC等を進めていくことは、どんどん難しくなっていきます。そして、残された時間は、そう多くはありません。
1人でも多くの、心ある人が、この問題に向かい合い、発信をしてくれることを祈るばかりです。
この記事が気に入ったらサポートをしてみませんか？