デジタル・カイゼン

カイゼン活動の亡霊「DTK」、変革を骨抜きにしてDXやAXを滅ぼす　日経クロステック　木村岳史　(2026/05/25)

【デジタル・カイゼン】　
木村岳史氏は、現場主導の改善としてのデジタル化はDXではなくDXを阻害することを、以前から指摘しておられる。

DXに限らず、昔から変わらない構造的な問題だ。
昔々、ペーパーレスが流行ったときに、稟議もFAX、スタンプラリー、ドッチファイルもなくならなかった。
パソコンが使えるようになったが、パソコンでせっせと稟議書を作り、スタンプラリーをして、ドッチファイルに綴じていたのである。

昔も今も、仕事のやり方(業務)を変えず、現状の作業をITで置き換えていた。
例えるなら、最新の建材で竪穴式住居を建てているのである。

【DXは改善?】
「DX」を検索すると、「DXで業務改善」など、改善がヒットする。
経産省によるDXの定義は、

• デジタル技術やツールを導入すること自体ではなく、データやデジタル技術を使って、顧客目線で新たな価値を創出していくこと。
• また、そのためにビジネスモデルや企業文化等の変革に取り組むことが重要となる

だ。(太字は著者による)
改善ではなく改革なのである。

日本の組織は現場のカイゼン運動で成功してきた歴史があるが、局所最適になりがちだ。
自分や、自分の部署の作業は改善できるが、組織的な問題が改善されているわけではない。
とりあえず、目先の不便が解消すれば良いと考えるのは人の性で、それを良しとするのは、組織風土だ。

例えば、組織全体で使用することが多い情報システムを構築、更新しようとすると、情シス部門vsその他の部門という構図が生まれる。
局所最適で改善している部署が抵抗勢力になるからだ。

【トヨタのカイゼン】
木村岳史氏によると、カイゼン活動がDXを阻害すると指摘すると、「だったら、カイゼン活動の元祖であるトヨタ自動車はどうしてあんなに好業績なんだ」という反論があるという。

トヨタ生産方式(TPS)はカイゼン活動がフォーカスされがちだ。
しかし、本当の強みは、問題解決の8ステップを、現場、管理職、経営層それぞれの階層で実行する組織風土があることだろう。
だから、現場だけで問題を解決しているわけではなく、管理職や経営層が局所最適にならないように、カイゼンしている。

「4. 真因を考え抜く」を真面目に実行すれば、業務フローの不備に気が付くはずだし、真因を考え抜く組織風土が無いことに気が付くだろう。
つまり、DXを現場に丸投げしたり、現場で野良マクロや野良RPAを作るだけでは、根本的な問題は解決しないのである。

【1人情シス】
組織が大きくても、小さくてもこの問題はある。
40年間大きな組織で働いていたときに、この問題を痛感していた。
今は、小さな組織で1人情シスをやっているが、やはりこの問題はある。

他の業務が関係する作業は障壁が多く効率化できないのである。
仕方がないので、情シスだけが関係する作業をRPAとAIを使用して効率化した。

結局、局所最適だ。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【ほぼ1人情シス】

人が余っているから情シス

AIに代替された人材で、情シスの派遣事業を始めるというアイデア

3月頃からSES会社の社長によく相談を受けます。「今、人が余ってきているので、中小企業のIT支援業務とかやろうと思っているのですが、何したらいいですか？」……そんなに簡単な仕事なら、ひとり情シスの方々はこんなに苦労されていないのですよ。 https://t.co/LHnTYViPfU

— 清水 博 (@Shimizu1manITDX) May 17, 2026

清水博氏は

そんなに簡単な仕事なら、ひとり情シスの方々はこんなに苦労されていないのですよ。

とおっしゃるとおり!　我が意を得たりだ。
世の中の経営者が、「情シス」は誰でもできる程度の仕事と思っているから、情シス不足問題は解決しないのだと思う。

【1人情シスの仕事】
特に1人情シスの仕事は多岐にわたる。
例えば、ICT機器の保守・整備、ヘルプデスク、情報セキュリティ、開発、ユーザ管理、情報資産の管理などが挙げられる。
それぞれの業務は、専門性があって、複数の業務で高い能力を持つ人材は少ない。

大きな企業では、それぞれの業務の作業量が多いから、業務ごとに専門の担当がいる。
一方で、小さな企業や事業所では、それぞれの業務の作業量が少ないから、全ての業務を1人で担当することになる。
これがいわゆる「1人情シス」だ。
つまり、「1人情シス」は、作業量は少ないが専門性が異なる作業を1人で担当している。

全ての分野で、高い専門性を発揮できる人は「スーパー1人情シス」と呼ばれるが、そのような人は、極々稀な存在だ。
ところが、ITを一括りにして、全ての業務に詳しいことを前提にして、作業量が少ないことを理由に低賃金で雇用しようとする。
これが、情シス不足の要因だろう。

【客先常駐の情シス】
業務委託で週3日、客先常駐の情シスをやっていたことがある。
その経験では、最も重要なことは、コミュニケーション能力だと思う。

コミュニケーション能力に難があると、仕事は少なくなるが、何をやっているのかわからないと言われる。
普通のコミュニケーション能力があれば、仕事がふえるが、契約範囲外の依頼がある。
やっている仕事を報告するにも、契約範囲外の仕事を断るにも、コミュニケーション能力は重要だ。

【心がけていたこと】

• 愛想よくする
  自分の、知識・技能は使ってなんぼと考えているから、なるべく愛想良くしていた。
• 作業を報告する
  日報が無かったので、グループチャットに作業を投稿していた。
• 無茶ぶりされたときは、安易に引き受けない
  「それは金で解決する案件ですよ。外注しましょう」と正直に助言していた。

【受注企業】
受注企業は、社員の仕事をサポートするのは当然として、仕事が正当に評価されるよう配慮すべきだ。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】【ほぼ1人情シス】

コパさんの配慮 ＜フールプルーフが実装されている?＞

「AIを使って、過去の原稿データの整理や、それを元に新たな原稿の作成はできるのか？」仕事歴20年超のベテランライター格闘記 
渥美 志保  mi-mollet  (2026/3/10)

「過去原稿のデータベースから、AIに原稿を書かせてみたい」ところが...。仕事歴20年超のベテランライターが気づいた【AIの使いこなし方】とは？
 渥美 志保  mi-mollet  (2026/3/11)

渥美志保氏は、AIについて、

すごい時代になったと思うけど、この流れはもう止められない。どうにかこうにかついていくか、それとも完全に背を向けた世界に生きるか。選択を迫られているなあ。

とおっしゃる。

冒頭の記事は、渥美志保氏が過去に書いた原稿のファイル名を、AIを使用して一括してリネームしようと奮闘した顛末だ。
渥美志保氏の職業は文筆業だから、この投稿で紹介されているのは、専門分野以外の領域でのAIの使用だ。
だからだろうか、最後の部分は客観的でどこか他人事のようにも感じる。

渥美志保氏が専門分野でAIを使用(評価)した、投稿を読んでみたいと思う。

閑話休題

この投稿では、ファイルを一括してリネームするPowerShellのスクリプトを、Copilot(コパさん)に作成させようと奮闘し、結果的にスクリプトが生成できなかったようだ。
コパさんはフェールセーフを考えているような気がする。

「ほぼ1人情シス」の業務に、M365の管理が含まれている。
作業が、GUIで実現できない場合や、手間がかかる場合は、PowerShellのスクリプトを作ることが多い。
使い捨てではなく、他の人が使うスクリプトを作る際には、-Execオプションがない場合は、 -WhatIf オプションを付けて実行するようにしている。
いわゆる、フールプルーフだ。
破壊的なコマンドレットが含まれる場合、いきなり実行してエラーが発生したときの、復旧作業は面倒だから、なるべく事前に防ぎたい。

2年くらい前に、Copilotに簡単な作業のスクリプトを書かせたら、ネットからパクってきたような出力だったが、最近は、時に過剰なコードを出力するくらい賢くなった。

おそらく、渥美志保氏が使ったコパさんも、フールプルーフが実装されていて、危険度のレベルを超えたら、コードを出力しないようにしているのだろう。
相当ヤバいコードになっていた可能性がある。

蛇足だが

ファイル名を規則的に一括リネームするなら、PowerToys に含まれている PowerRenameを使うと目的は達成されるような気がする。
複雑な変換は正規表現を使用しなければならないから、コパさんに教えてもらうことになるけど。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】【ほぼ1人情シス】

読めない専門用語

Xでこんな投稿が流れてきた。

エンジニアしか読めない「初見殺し」の呪文10選

1. async
2. IEEE
3. nginx
4. a11y
5. k8s
6. chown
7. zsh
8. azure
9. sudo
10. lambda

皆さんはいくつ読めましたか？
他にも難易度が高いものがあれば教えて下さい🔥

— ななな_エンジニア (@hima_engineer) March 24, 2026

1. あしんく
2. あいとりぷるいー
3. えんじんえっくす
4. ??
5. くーばねてぃす
6. しーえっちおうん/ちぇんじおうん
7. ざっしゅ
8. あじゅーる
9. すーどぅー(すどー)
10. らむだ

※ちなみに、Linux は「りぬくす」

「a11y」
が読めなかった。
「a11y」や「k8s」のような略し方を見たのは、30年くらい前に、「l9n」や「i10n」で知った。
当時、アプリのローカライズやそれを発展させたインターナショナリゼーションが話題になっていたので、ざっしの記事で見かけた。
堅い記事では「現地化」とか「国際化」と記述されていたが、柔らかい記事では、「l9n(Localization)」「i18n(internationalization)」などと記述されていていたように記憶している。

「chown」

は、はファイルの所有者を変更するUNIXのコマンドで、「しーえっちおうん」とか「ちぇんじおうん」と読んでいる。
UNIXはコマンドやシステムコールを短縮してあるしてあるので、初見では読めないことがよくある。
読めなくても、適当に読んでいるから、方言がたくさんある。

「cd」

10選にはないが、cd(しーでぃー) はカレントディレクトリを変更するコマンドで、Change Directory を省略している。
MS-DOSやWindowsでも同じコマンドが実装されていて、コンソールを使用する場合は、必須のコマンドだ。

cd を動詞的に使用することがある。
「zipを解凍して、そのディレクトリに、しーでぃーして」などと使うことがある。

前提として、
・ファイルシステムのツリー構造
・ワーキングディレクトリ
・絶対パス/相対パス
の知識が必要だ。
この操作を、普段CLIを使わない人向けの説明書で説明しようとすると面倒だ。
最近は、画面キャプチャを貼って、説明を減らしている。

【初心者でも読めばわかる】

「初心者でも読めばわかるような(ニワトリでもわかる)手順書を」要望されることは多いのだが、極めて難しい。
要望する人は、理解していれば、それをニワトリでもわかるように説明することができると思っているのだ。
これらに必要な能力は、まったく別物だと説明するのだが、なかなか理解してもらえない。

フリーソフトを配布していたころに、この問題で困っていた。
詳しく書けば分かりやすいとは限らないし、文字数が増えると、そもそも読んでもらえない。
そこで、分からなくても、手順書のとおりに入力したら最低限使える説明と、ソースを読む際に参考になる解説に分て、解説は、自分と同じくらいの知識がある人を対象に、ちょっと丁寧に書いていた。

【本当の問題】
ニワトリでもわかる手順書は、本当の問題にならない。
ニワトリでもわかる手順書が必要な人は、ちょっとしたトラブルに対応できないことが多いからだ。

職業プログラマーではなく、「ほぼ1人情シス」だから、現場で作業を効率化するくらいのツールを作ることが多い。
そのツールを他の人が使えるようにと、ニワトリでもわかる手順書を書いたとしても、トラブル対応が減らないとしたら、自分の仕事は効率化できていない。

ICTで効率化したいならば、そもそも、トラブル対策が必要なツールと「ニワトリでも分かる説明書」で一時しのぎせず、システムを外注すれば良いと思う。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】【ほぼ1人情シス】

AI-Ready ＜課題は技術ではなく人的組織的＞

【迷惑メール】
問い合わせ窓口用に公開しているメールアドレスがある。
そのメールアドレスに届くメールの90％は、迷惑メールで、本当の問い合わせ案件のメールが埋もれてしまう。

更に、最近の迷惑メールは巧妙になっていて、一見すると見分けがつかないので、フィッシングメールをつい開いてしまう危険性もある。

【Agent】
そこで、問い合わせ窓口宛てのメールを判定するAgentを作成してみた。
Agentのお題としてはよくあるお題だ。

メールの着信をトリガーにして、迷惑メールか否かを判定し、SharePointのリストに登録して、共有するようにした。

迷惑メールの定義をざっくり与えたら、
・スパムメール
・フィッシングメール
・DM
を迷惑メールとして判定しているようだ。

ウイルス付きメールや危険なリンクを含むメールはメールシステムがブロックしたり、迷惑メールフォルダに振り分けるので、ユーザーのメールボックスに配送されるメールを対象にしている。

当初、使用していたAIのモデルは、かなり緩い判定をしていた。
同じモデルを使用しているAI-Chatに与えた結果と違うことが多かった。
また、プロンプトで詳細に指示しても反映されないことも多く、回答が得られないこともあった。

GPT-5に変わってから、判定精度が上がって、プロンプトの指示が反映されるようになった。

そこそこの精度になったので、
次のアクションとして、問い合わせメールの場合は、返信の下書きを生成させてみた。
これまでの返信から作成した返信テンプレートと、問い合せメールを与えると、下書きを作成してくれる。

ここまでできたら、
担当者に、下書きと問合せメールの着信を通知して、
・必要であれば、回答する人が下書きを修正して、
・管理者が承認したら、
回答メールを送信するところまで実装できそうだ。

ところがである。
困ったことに、誰に通知すればよいかわからない。
問い合わせを処理する人は、その都度変わるから、自動化できないのだ。

【AI-Ready】
AIを活用するためには、AIが使用できるようなデータが必要と書いた。
AIが使うデータだけでなく、AIが適用できるワークフローも必要だ。
人間が処理することを前提に作成されたExcelや、その都度、指示を受けて人が処理している作業は、AIで効率化できない。

つまり AI-Readyではないのだ。

---

• M365をきちんと使う ＜SharePointはNASじゃない＞ (2026/01/10)

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】【ほぼ1人情シス】

M365 Copilot導入 ＜小規模事業所で導入してみた＞

M365 Copilot 導入で起こり得る誤算
なぜ手厚いサポートが社員の「AI 離れ」を招くのか
キーマンズネット (2026/02/18)

M365 Copilotを全社導入した内田洋行の事例をダウンロードできる。
内田洋行は大企業だから、活用推進担当がいて、定期的に勉強会を開いていたらしい。
その中で、明らかになった活用推進の要点がまとめてある。

ところで、
中小企業向けでも購入できるようになった頃から使っている。
30人程度の小規模事業所で導入し、現在進行形で格闘している事例を、「ほぼ1人情シス」の立場から書いてみる。
大企業の導入事例を参考にするのは難しいと思っている人には、参考になるかもしれない。

【前提】
M365 Copilotは他の生成AIと比較して、以下の特徴がある。
・M365アプリ(Office, Teams, Outlook etc.)との連携
・SharePoint, OneDrive内など組織内のデータの活用(検索、資料作成)
これらの機能を使用せず、AI-Chatだけ使用する場合はコスパが悪い。

【導入】
PowerPointのスライドを生成したかったので、Copilotの導入を提案したのだが、
Copilotライセンスは高価で1年更新だから、最初から全員にライセンスを付与することが難しかった。

経理担当は、効果があるなら、使うなら買ってもよいとおっしゃる。
じゃあ、使いたという人にライセンスを付与しようとなるのだが、何に使えるか、どう使ったらよいのかわからないので、使いたいと言えない。卵鶏問題だ。

とりあえず5ライセンス購入して、PowerAutomateとFormを使用して申請すると14日ライセンスが付与される仕組みを作った。(1ライセンスは直接自分に付与しておいた ^^)

★思いついたときに使えることが重要だが、試しに使ってみるために、年契約のライセンスを全員に配布する方法はコスパが悪い。
　少ないライセンスを複数のユーザで共用する仕掛けを作ることは可能。

【普及活動】
何に使えるか、試している人が多数く継続して使用している人は1人だけだった。σ^^)
更新時期が近づいてくると「活用されているのか?」と問われるので、啓蒙活動をはじめた。

ChatGTPを使っている人も多いから、生成AIの説明に困ることはない。
しかし、生成AI＝Chat-GTPと考えている人は、CopilotもAI-Chatと捉えている人は多かった。

使用例を示して、「CopilotはOfficeアプリに組み込まれたAI」という説明をした。
「ほら、このスライド30分でできます。簡単でしょ?」
と説明していた。
アウトラインが重要で、アウトラインを書いた時間はあえて説明しなかったのだが．．． (^^ゞ
とりあえず使ってみることが重要だと考えていた。

PowerPoint、Excel、Word、 OutlookなどのアプリでのCopilotの使用例をTeamsのチャネルに投稿していたら、使い続ける人が徐々に増えてきた。
(Copilot説明会　＜最初のハードルを越える＞ (2025/05/19))

★使用頻度が高い人は申請しなくても使用できるようにした。
　雑談で使用例を話してくれるけど、Teamsに投稿してくれない。

【AI-Agentを作ってみる】
CopilotStudioで生成AI機能が使えるようになったのでAgentを作ってみた。
今までのやり方で十分と考えている人は使おうとしない。そろばんが得意な人がExcelを使わないのと同じだ。

そこで、システムにAIを組み込むと、ユーザはAIを使う意識がなくなるので活用できるだろうと考え、TeamsのFAQ botを作ってみた。(よくあるお題だ。)

分かったことは、
・CopilotStudioの生成AI機能で期待した結果を得るのが難しい。
　プロンプトと格闘したのだが、安定して期待する出力になるまで追い込むことができなかった。

・フリーフォーマットのナレッジは検索精度が悪い
　CopilotStudioは、ファイルやSharepointのフォルダ内のファイルをナレッジとして(RAGのように)使える。
　ところがフリーフォーマットでは、検索制度が悪い、特にPowerPointは難しいことが分かった。
　そこで、ナレッジに指定したファイルの先頭に要約を追加したり、PowerPointのタイトルページのノートに要約を追加した。
この作業は面倒だが、劇的に改善するわけではない。
ダメダメな出力が、イマイチの出力になるくらい改善された。
(無償版Copilotで十分 ＜有償版が使える環境になっていない?＞ (2025/12/10) )

Webで公開している連絡窓口のメールアドレス宛に届くメールは、ほぼ迷惑メールだ。
これを、判定するAgentを作ってみた、組織内のデータを使用しないので、有効だろうと考えたが、それでも判定精度が悪い。
プロンプトを試行錯誤してみたが、使ってみてくださいと言えるレベルにならなかった。
(Copilotで自立型エージェント (2025/09/07))
(GTP-5が使えるようになって見違えるように改善した)

★業務に組み込むには、まずデータを整理すること。Garbage in, garbage outは正しい。
　GPT-4とGPTｰ5とでは技術革新といえるくらいの差がある。

【組織のデータを使ってみる】
Google検索の代わりに使ったり、ChatGPTと同じようにAI-Chatに使うには高価すぎる。
最近の生成AIは、Officeドキュメントを生成できるようになったので、pptxファイルやdocxファイルを作成できることの価値は低下している。M365 CopilotはSharePoint、OneDrive、Outlook、TeamsなどM365のデータを扱うことで真価を発揮する。

ただし、M365のデータが使えるようになっていることが前提だ。
SharePointを昔のNASのように使っていたり、無秩序にチームやグループチャットが作られていたり、Outlookに予定を入力していないようでは、Copilotを使っても満足な出力は得られない。
(M365をきちんと使う ＜SharePointはNASじゃない＞ (2026/01/10))

★検索する方法や製品は議論するけれど、検索されるデータは議論されない。
　AIならごみ箱化したNASでも賢く検索してくれると思っている。

←今ココ

【振り返り】
・個人の作業の効率化 → 関心ない人の行動様式を変えるのは難しい。
・組織的な業務の効率化 → データの整理や業務フローの見直しが必要。
・「ほぼ1人情シス」の作業は効率化できた。

【冒頭で紹介したPDFを読んで再認識したこと】
・「詳しく指示して」はもう古い 
　GTP-5は、情報が足りない場合は、ユーザに質問して、会話するようになった。
　精度が向上したと感じるのは、
　・性能が向上したこと
　・AIがユーザの要求を引き出すようになったこと
　・pythonのサンドボックスを使うようになったこと
などが考えられる。

・音声入力
　展示会で音声認識と翻訳機能の説明を聞いたら、今後キーボードを使わなくてよくなると言っていた。
　話し言葉と書き言葉は違っていて、　思ったことや考えたことは、文章にするより、話すことの方が簡単だ。
　GTP-5はユーザと会話するので、キーボードより音声会話の方が簡単かもしれない。
　職場で隣の人が近い場合、「こいつ、独り言多いな」と思われてしまう．．．(^^

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】【ほぼ1人情シス】

エラーメールがRFC準拠していない ＜故意か?＞

エラーメール(NDR)がメーリングリスト宛てに返ってきて、展開されていたので調べてみた。

そのメールは発信者をメーリングリストのアドレスで送っていたので、NDRメールはメーリングリスト宛てに返送される。
メーリングリスト宛てのNDRメールを展開すると、ループになる可能性があるので、展開しないようになっている。

届いていないことやエラーの原因が分からないので、メーリングリスト宛てのNDRメールは管理者に配送される設定にしている。
ところが、エラー(NDR)メールがメーリングリスト宛てに返ってきたので調べてみた。

【原因】
RFC 3462, RFC 3464ではNDRのヘッダーに

Content-Type: multipart/report;
 report-type=delivery-status

が含まれると規定されているが、

Content-Type: text/plain; charset="UTF-8"

となっている。
つまり、NDR風の普通のメールとして送信されているので、メーリングリストメンバーに展開されていることがわかった。

【誰がNDRを作成したか?】
更に、メールヘッダを調べると、某セキュリティベンダーのクラウド型メールセキュリティ・ゲートウェイを使用しているることがわかった。

NDRは送信先サイトのメールシステムが作成していて、セキュリティゲートウェイを通過しているだけという可能性もある。
しかし、送信先サイトのメールシステムはNDRメールをRFC準拠で返送することがわかったので、セキュリティゲートウェイが返送しているNDRがRFC準拠でない可能性が高い。

【困った】
わざとそうしているのか? > 某セキュリティベンダー

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【ほぼ1人情シス】

Excelマクロ ＜問題は禁止/許可の先にある＞

XにExcelマクロに関する投稿が流れてきた。 

Excelマクロが禁止されてた企業に勤めてたものの面倒なExcel作業が多いのに冗談じゃないとこっそりマクロ組んで仕事終えてた社員が辞める際、後任はマクロ使わない手作業のやり方で引き継ぎを受けたものの当然仕事のスピードが激落ちしてなぜだとなり、退職済みのその方に相談したところ実はマクロ使っ…

— 吉田拳｜Excel丸投げ外注サービス（毎月定額制）のすごい改善代表 (@sugoi_kaizen) February 23, 2026

多くの人がそれぞれの立場で、レスを投稿している。
大抵は、自分の立場や環境だけを考えていると思う。

ユーザの立場も、情シスの立場も、マネージャーの立場も経験したのでそれぞれの立場で考えてみた。

【ユーザの立場】
Excelマクロは野良化しやすいという指摘は正しい。(Excelマクロがすべて野良という訳ではない)

これまで、目の前の作業を終わらせるために、野良アプリ、野良ツールをたくさん作ってきた。
これらの、自分が使うためにやっつけ仕事で作ったプログラムを配布したり、引き継ぐと後からトラブルに巻き込まれた経験が何度もあるので、配布も引き継ぎもしないようにしていた。

「配布しない!」というと、勿体ぶってると言われるし、「as isで!」 と念押しして配布しても、不具合の修正や機能追加の依頼がある。
「勝手に修正していいよ」と答えると、「それができるくらいなら、頼まない」と．．．orz

★今時、手作業でコピーしたり、手打ちで入力する作業は人の仕事ではない。
★経験的には、自分のためのツールを、配布したり引き継ぐと、トラブルの元になる。

【情シスの立場】
Excelマクロは、セキュリティ上の脆弱性になりやすいので禁止したい。
使ったこともない野良マクロの不具合や機能追加の相談を受けることがあるが、正直なところ面倒だ。
野良はいくら改修したところで、所詮野良だ。

Excelファイルはクラウドサービスでは使いにくい、マクロ付のExcelファイルはクラウドサービスでは使えない。
Excelマクロだけが使えないわけではなく、ネ申エクセルも同様に使えない。
Excelマクロや神エクセルが残る業務は整理されていないことが多く、クラウド化しても効率化できない。

★Excelマクロや神エクセルは、業務が整理されていないことを示していて、新しいクラウドサービスやAIなど新しい技術を導入する際の足かせになる。
★問題は業務が整理されていないことだから、Excelマクロを禁止しても効果がないどころか、逆効果になる可能性がある。

【マネージャーの立場】
正直なところ、目の前の仕事をExcelマクロなどで片付けてくれる存在はありがたいが、甘えてしまうと、無駄な業務は減らない。

無駄な業務と認識しながら、対応しなければならないことがあると、マネージャーとしては辛く、自分の無能さを感じる。
そのような時に、Excelマクロなどの野良ツールで解決してくれると、正直ありがたいと思う。

しかし、その仕事が無駄であることに変わりなく、さらに優秀な部下の能力を無駄使いしている。

マネージャーは無駄な仕事をなくしたり、必要なシステムを導入すべきだが、
マネージャーも人の子だから、つい目の前の無駄な仕事を片付けるために野良ツールを使い続けてしまう。

★正直なところ、業務フローの変更が必要なことは分かるが、実現可能性を考えると言い出しにくい。
★無能なマネージャーが野良マクロ、野良ツールの使用を助長し、有能な能力を無駄に使ってしまう。

【結論】
Excelマクロの使用はリスクがあることは事実だが、リスクを承知で使わなければ終わらない仕事があることも事実だ。
現場にいる人がそれぞれの立場で声高に賛成/反対を言うことでは、問題は解決しないし、不毛だ。

野良マクロを使用しなければ業務が回らない現実を見ないようにして、問題を先送りしていることが問題だと思う。
つまり、Excelマクロの禁止か許可かの問題ではない。
立場を超えて、真の問題に取り組んではどうだろうか。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【Excel】

2025年の反省

今年も一人反省会。

2025年の目標は

• できることよりやりたいこと
• 100%にしない
• CPUを使ってみる

だった。

【できることよりやりたいこと】
AI技術の進歩が速い。
自分の作業の省力化だけでなく、興味の赴くままに、業務の効率化に使ってみた。

AIを使用することで、作業の省力化、高度化できることが分った。
そして、AIを業務の効率化に使用することの難しさも痛感した。

【100%にしない】
今年は、考える余裕があった。
「ほぼ1人情シス」として4年を経過して気が付いたのは、保守やヘルプデスク業務に必要なマインドの重要性だ。同じ仕事を長くやっていると、当然のことになっていたようだ。

保守やヘルプデスク業務経験のない人に、「マインド」を求めるのは無理だと思うようになった。
知識や技術は比較的容易に獲得できる。しかし、「マインド」の獲得は容易ではない。
情シスの後継者不足が顕在化しているが、技術だけでは解決できないだけに難しい。

【CPUを使ってみる】
CH559picoに豊四季BASICを実装してみた。楽しい

CH559picoでTOYOSHIKI-BASIC
CH559picoでTOYOSHIKI-BASIC (2)

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【ほぼ1人情シス】

ランサムウェア被害

ランサムウェア被害が相次ぐ日本企業　アスクル、無印良品、アサヒ、そしてトヨタが示した「初動対応の差」【いづも巳之助の一株コラム】
 セブツー 2025/10/22

ランサムウェア被害を受けた企業の株を持っていたら、どう「心配」すればいいのか、という株主目線のお話。

いづも巳之助氏は、3段階で評価すべきとおっしゃる。

■第1段階：24時間は「誠実さ」を見る
■第2段階：72時間で「仕組みの強さ」を測る
■第3段階：1週間で「信頼」を勝ち取れるか

組織の危機管理の観点で読むと非常に参考になる。
しかし、「ウチは大丈夫👌」と言える組織は少ないのではないかと思う。

これらの情報は、「危機管理」「BCP」「コンテンジェンシープラン」などで調べると、たくさん見つけることができる。
重要なことは、自分たちの組織で実際に運用できるか、という観点だろう。

システム管理の観点から考えてみた。
組織の危機管理は経営課題だが、ランサムウェア被害のように情報システムのインシデントは組織にとっても重大なインシデントになる。

■第1段階：24時間は「誠実さ」を見る
経営者が誠実であっても、責任者(経営者)がインシデントを把握し、公表する情報を整理する時間が必要だ。

セキュリティー製品が、異常を検知すると自動的にアラートが出る。
担当者がアラートを受信して、インシデントを確認してから、判断できる責任者までエスカレーションする必要がある。
エスカレーションができなかったり、時間がかかる組織は多い。
原因は
・マニュアルに、エスカレーションの基準、手順が明文化されていない
・エスカレーションの訓練を実施していない
・エスカレーションしたときに責任者の機嫌が悪かった．．．
など

責任者(経営者)は「なぜ早く報告しないのだ」ということが多いが、報告が遅れるのは理由がある。
インシデントが発生しないと気が付かないものだ。

★第1段階が最も厳しいかも。

■第2段階：72時間で「仕組みの強さ」を測る

BCPやコンテンジェンシープランがあれば粛々と実行するだけなので、情報システムについても粛々と実行するだけのはず．．．だ。
しかし、定期的に訓練しておかないと、切り替えでトラブルが発生する可能性が高いし、システムが切り替わっても、運用を切り替えることができないこともある。
BCPやコンテンジェンシープランの不備は、訓練を実施して、その結果を評価しなければ改善できない。　

★BCPやコンテンジェンシープランがあって、定期的に訓練されていれば可能かも。

■第3段階：1週間で「信頼」を勝ち取れるか

　短期間で、原因を特定して対応と再発防止対策まで考えられるのは、規模の小さいインシデントか、規模が小さい組織か、限定的な対応でよい場合だろう。
ランサムウェア被害のような場合は、原因特定に時間がかかるため1週間はハードルが高いと思う。
被害を受けていない部分から、段階的に稼働再開させるなど、全面的に業務が止まらないような構成にしておくことが必要で、
デススターのように、一撃で崩壊するシステムにしないことが需要だ。

★インシデントが発生する前が重要。インシデントが発生した後の対応では難しいかも。

【結論】
記事にあるように、「単なるITトラブルのように見えて、実は経営レベルが露呈する」という指摘は正しいと思う。
情報セキュリティを経営課題としてとらえていない経営層も多い。
セキュリティレベルは、そのシステムの中で最も弱い部分で規定されるから、弱いのは、たいていは人の意識や体制だったりする。
と考えると、情報セキュリティに金を使わないという経営者の判断はバランスが取れていたりする。きっと自分に合わせているのだろう。(^^;

---

※「ほぼ1人情シス」業務をやっているのだが、自サイトのことを書くと生々しいので一般論にした。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【ほぼ1人情シス】