「ほぼ1人情シス」で気づいたこと ＜業務ごとのマインドが重要＞

「ほぼ1人情シス」を4年やって気づいたことがある。

「ほぼ1人情シス」で担当している業務は、

• 保守業務
• ヘルプデスク業務
• セキュリティ業務（監視、一時対応）

で、どの業務にも共通して必要なことは、

• 技術（知識、技能）
• 経験
• マインド

で、特に「マインド」が重要だと思う。

技術は共通している部分が多いが、それぞれの業務に特有のマインドがある。
例えば、保守業務に重要なマインドは、システム障害を未然に防止することだ。
障害が起こってから対応するのではなく未然に防止することが重要だ。

このマインドは昔保守業務やっていて身についたものだから、昨日今日身についたものではない。
そして、マインドを知識として知るだけではなく、それが体現できて初めて身についたと言える。

ヘルプデスク業務もセキュリティ業務も過去に経験してマインドが身についたと思う。
経験していない業務のマインドを身につけることは困難だから、経験も重要だ。

情シス部門が無いような小規模の事業所は情シス要員の確保は大きな課題で、特に1人情シスの後継者問題は深刻だ。
1人情シスは多くの業務を抱えているから、全ての業務に必要なマインドを持っている人を探すのは困難だ。
また、技術や経験は客観的に示すことができるが、マインドを客観的に示すことは困難だ。
だから、面接でマインドの有無を判断することは難しい。

情報システムの重要性を認識しない経営者や管理者は多い。
1人情シスの事業所はおそらく情報システム以外に大きな課題があるのだろう。
だから1人情シスでバランスが取れているのかもしれない。

---

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

Japan IT Week 2025 春

Japan IT Week に行ってきた。

Japan DX Week, 営業・デジタルマーケティング Week、EC・店舗 Week
も同時開催で、東京ビッグサイト東棟のホール1～ホール8まで使用していた。

印象は「混沌」似たようなサービスがたくさん出展していた。
狭い通路は、メイド喫茶最盛期の秋葉の裏通りみたいな感じで、客引きが多くて歩くのが大変なくらいだった。

〇エッジコンピューティングAI鳥害防止システム

カメラで撮影した画像をAIで解析して鳥を検知し、
無線で位置情報を送信して
ドローンが鳥を追い払う
という仕組み。
ドローンは格納ステーションに帰ってくると自動的に充電される。

〇情シスのぼや木
　情シス応援パビリオンが開催されていたが、ほとんどコンサルだった。


〇免振装置(μ-Solator)
　凸凹があるプレートの上にシート敷いて、その上にラックなどを設置する。
　床が動いても、シートの上に乗ったラックが滑って転倒を防止する仕掛け。
　サーバーラックへの導入事例もあるようだ。

↑銀色のプレートの上を黒色のシートが滑る。

〇4足歩行ロボット
　ARアプリと4足歩行ロボットとの連携させて、遠隔で現場の巡回監視するソリューション
　災害現場の調査への応用が紹介されていた。

偵察ロボット?

---

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

情シス業務に必要なこと ＜40年前に教えてもらった＞

情シスを(保守、監視、セキュリティ担当)４年くらいやって分かったことがある。

この仕事に重要なことは、
４０年前の通信設備の保守・運用の仕事で得たものだということ。

現在の保守対象は情報システムで、40年前は通信(無線や電話)設備の保守だから機器やシステムは違うのだが、保守の考え方は同じだと思う。

保守業務を経験していない人と、考え方が違うと感じるのは、リスク管理の考え方だ。

基本的な考え方は、リスクが顕在化したときに、

• 自分の知識・技能と時間、使用できる機器などの保有リソースで対応できるようにする。
• 顧客(サービスを提供しているユーザ）のダウンタイムを最小限にすること

だ。

リスクを管理するには、リスクが認識・評価できることが大前提だが、リスクが認識・評価できない人は、そのリスクが顕在化しなければ対応はできないから「トラブルが起きた時に対応を考えれば良い」と考えているようだ。

なぜ、自分はリスクを管理しようとしているのか考えてみた。

おそらく、
失敗の経験によるものだろう。
歳をとっているから失敗も多い(自慢にはならない)のだが、考え方が違う人は、失敗経験がない大門未知子なのかもしれない。

自分だけでは回復できないくらいの失敗や、多数のユーザに影響が出るような失敗を経験すると、失敗の原因を考えて、同じ失敗をしないように対策するものだ。
つまり、失敗したことで、リスクを認識し、失敗の後始末をすることで、リスクが顕在化したときの影響が評価できるようになった。

正直なところ、
失敗経験に由来する考え方の違いは埋めようが無いと思う。
しかし、考え方が違う人主流の環境で仕事をするのはストレスが溜まる。

閑話休題

組織的には、
経験が少ないメンバーの失敗経験をコントールすることで、リスクが管理できるようにな人材になり、リスクコントロールできる組織になる。
40年前に失敗が経験できる職場で働けたことに感謝している。

蛇足
先日もETCシステムの大規模障害があったが、保守の現場で失敗をコントロールする余裕がなくなっているのではないかと懸念している。

---

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

裏方 ＜動くことが当然のシステムが今日も動いていること＞

警察の情報通信を支える「縁の下の力持ち」 朝日新聞デジタル (2025/3/14)


(↑Micorosoft Copilotさんが考える「シンプルなアニメ風の、通信インフラ保守のプロフェッショナル」)

「裏方」は働く目的や目標でははないと思っているので、殊更「裏方」を強調する記事に違和感を覚えた。

多くの仕事は、
表に立つ人「表方」に比べて、裏で働いている人「裏方」の方が多い。
どちらが重要かという議論は無意味だ。
「表方」も「裏方」も同じ目的を達成するためにどちらも必要で、「表方」も「裏方」もプロフェッショナルであることが求められる。

ところが、
「裏方」は表から見えにくいので仕事の内容や必要な能力が理解されないことが多い。
見えないものは評価されなかったり不当な扱いを受けることがあるので、真っ当な企業・組織や業界は、人材確保や企業・組織の価値の認知・拡大などを目的に広報に力を入れている。

冒頭の記事もその目的で取材に応じたのだろう。
その観点で読むと、
・仕事がプロフェッショナルな仕事であることが分からない。
・この職場で働くプロフェッショナルな個人が見えてこない。
と感じた。

最近(60歳を過ぎて)就職活動したので、その職場で働く個人に着目する習慣が付いたのかもしれない。

閑話休題
昔は通信インフラの保守の仕事、今は情シスの仕事をやっている。いずれの仕事も「裏方」だ。
インフラ保守の仕事、情シスの仕事で、最も評価すべきは「インフラや情報システムが事故なく稼働していること」だが、これを評価する経営者や管理職は極めて少ない。
ともすれば、「事故が起きたときに迅速に対応したこと」やその能力を持っている人を評価しがちだ。

昔マネジメントをやっていた時には、真っ当な評価を得たとは言い難く苦い経験だ。
今は自分自身のことなので「動くことが当然のシステムが今日も動いていること」に対する評価を求めていこうと思う。

---

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

現場の業務改善 ＜省力化できるけど保守作業は無くならない＞

Xで↓こんなポストを見つけた

「手作業でExcel作るのしんどいよう」
↓
Excelできる人が入社
↓
「効率化しました」
↓
「何したのか分からないので評価できません」
↓
Excelできる人が退職
↓
「仕組みを保守できないので手作業で頑張ろう」
↓

— 筒井.xls@エクセル関数擬人化本著者 (@Tsutsui0524) December 4, 2024

よくある話だろう、共感する人も多くいるようだ。

ほぼ1人情シスをやっている職場で、M365ではExcelマクロは使いにくいので、LISTと PowerAutomateにしましょうと提案したら、
Excelマクロは分かる人がいるけど、LISTやPowerAutomateは分かる人がいないからだめと言われたことがある。

「作った人が退職したら保守できなくなる」という心配は分かるので、
「保守できないなら、昔みたいに手作業に戻したらよいのでは？」と提案すると、
「一度便利になると、元に戻れない」とおっしゃる。

つまり、「一度便利になると、元に戻れない」から、今便利にしないというロジックらしい。(?_?

閑話休題

結局、情シスで使うデータはPowerAutomateで自動的に収集・更新するようにしてLISTで管理するようにした。
そのデータをExcelで使いたいなら、LISTから Excel形式でエクスポートすることにした。

Excelを使う→Excelマクロを使う→RPAなどで作業を自動化すると、作業量が減るけれど、それらを保守する作業は必要だ。
保守作業はそれを使う作業より高い能力が必要になることが多い。
だから、

減った業務量 × 作業者の単価 > 保守の業務量 × 保守者の単価

ならばペイするはずだ。

経営者や管理者は、作業を自動化してそれを保守している人が、

減った業務量 × 作業者の単価

の価値を生み出していることに気付いていないのではないか。
さらに、
保守に必要な能力、その能力を持った人の単価を知らない（評価できない）
作成・保守する人の能力は高いから、当然労働単価も高いのだが、正当に評価できない経営者や管理者は、手作業(人海戦術)でやろうとする。
この判断をする人は、人件費≒ゼロと考えているから、手作業の方が単価が低いと考えるのだろう。

蛇足
作業を自動化してそれを保守している人は、

保守の業務量 × 保守者の単価

のコストを負担していることを認識していないのではないだろうか?
このコストは結構大きいから、自動化した人がいなくなると保守できなくなってしまう。

自動化した人の不満は、自分がいなくなると保守されないことではなく、自分が負担していた保守のコストを評価されないことではないだろうか?

---

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

保守業務のクオリティ

通信設備の保守、新増設の計画・実施の仕事をしていた経験がある。
新設、撤去はそうでもないが、移設は鬼門だ。
移設後元通りに動かなくなる可能性がある‘特に耐用年数を超えた機器は触りたくない。

移転計画を聞いていて、話が噛み合わないことが多くストレスが多い。
ストレスの原因を考えてみたら、職場の常識が違うと気が付いた。

昔働いていた職場の常識では「移設」に伴う停止期間はほぼゼロ、成功確率はほぼ100％だった。
この常識では、計画、準備の作業量が大きくなる。
可能な限り不確定要素を取り除いて、不足の事態に備えて、など考え始めるときりがない。

仕事を変わった今でも、仕事量を見積もるときに、
停止期間ほぼゼロ成功確率ほぼ100％のクオリティ
で見積もってしまう。

ところが、そのように厳しいクオリティは求められていないことは多い。
停止期間１週、成功確率75％くらいのクオリティなら、かなり楽になる。

失敗した時、誰が対応するのかという問題がある。
失敗によってはリカバリには多くの労力が必要なことがあるから、そのような失敗は発生しないようにしておけば、1人で段取りできてそうだからコスパ・タイパが良さそうだ。

最近銀行や決済サービス、ネットワークなどの社会インフラのシステム障害が多いのは、保守のクオリティを下げても良いという風潮があるのかもしれない。

---

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

システムの保守運用 ＜年寄りは若い人に何を伝えるのか＞

くだらない仕事と成り果てたシステムの保守運用、若者にやらせるのは犯罪的だぞ
木村 岳史 日経クロステック／日経コンピュータ
(2024/06/10)

木村岳志氏の指摘は、
汎用機+COBOLの保守業務についてだが、もう少し抽象化すれば、

将来ジリ貧になることが分かっている業務に若者を引っ張り込むな

ということだろう。

古い体質の組織で働いていると、「将来ジリ貧になることが分かっている業務「よくを見かける。
そのような業務は希望者が少ないから、右も左もよくわからない若者が引っ張り込まれるのも見てきた。

幸にしてそのような仕事は避けることができた。
尤も、空気を読まず不満を言うので、避けられていたのかもしれない。

ジリ貧の業務にニーズがあって年寄りしかできないなら、木村岳志氏が言うように年寄りがやればよいのだろう。
そして、年寄りがいなくなったら否が応でも変えなくてはならない。
そのときに若い人達は慌てなくてよいように、新しい技術や効率的な方法を習得すべきということだろう。

ジリ貧になる業務も昔は花形でだったに違いない。
汎用機+COBOLも昔は、新しい価値を生む出していて、その保守の仕事も新しい価値を生み出していたのだろう。
そのその保守の仕事が、価値を生み出していて、もっと多くの価値を生む方法が無いのなら、その仕事は重要だ。

しかし、今どき汎用機+COBOLより新しい価値を生み出したり、もっと多くの価値を生む方法は存在する。
だから、現状を維持するための保守の仕事に価値は無くなってしまった。

〇蛇足
若い人に何を伝えるのか？
今どきの年寄りは難しいなあ。

---

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

続・技術者への転職のススメ

続・技術者への転職のススメ、人月商売からの脱出に向け勇気を出せる話をしよう
木村 岳史 日経クロステック／日経コンピュータ (2024/06/24)

木村岳志氏から若い技術者に向けたエール。

木村岳志氏は

人月商売のITベンダーが手掛けるシステム開発や保守運用の仕事、つまりIT業界の大勢の技術者が取り組んでいる仕事の多くは、社会的に無意味、あるいは無価値なものである。

と容赦無い。

〇保守運用

保守運用を仕事にしている人は、自分の仕事に価値が無いと言われたら、カチンと来るだろう。
それでも、ちょっと冷静になって、自分の仕事は価値を生み出しているのか、もっと大きい価値を生み出す方法はないのか、客観的に考えてみるとよいと思う。

今現在は需要があるかもしれないが、昭和99年を維持する仕事に価値は無い。
昭和99年を維持する仕事は、大企業の古いITシステム以外にも結構ある。

再雇用や定年延長したような年寄りは「価値のない仕事」が無くなっても路頭に迷うことはないだろう。
しかし、「価値の無い仕事」をやっている若い人は、かなり大きなリスクを抱えている。

特に「価値の無い仕事」をあたかも価値があるかの如く刷り込まれた人は危ない。
「価値の無い仕事」をしている年寄りは、新しい技術を習得しようとしないだけではなく、新しい技術を習得しようとする人の邪魔をするから、新しい技術が習得できない体質になっている可能性がある。

昭和99年を維持する経営者や管理職が真っ当な経営者や真っ当な管理職に代わったら、もっと大きな価値を生み出す方法を選ぶだろう。
そうなった時にには、もっと大きな価値を生み出すための能力を持っていない者の仕事は無くなる。

若い人は、いつ辞めてもいいような年寄りと同じマインドで働いてはいけない。

〇1人情シス

情シス部門が置けないような職場では、低レイヤから高いレイヤまで何でもそこそここなせる人材は貴重だ。
つまり、需要がある。

ところが、新しい価値を創造していない仕事も多い。
そこそこできる情シスがいなければ、効率化や合理化を考えるだろう。
そこそこできる情シスがいるために、新しい価値を創造しない仕事が続いているという見方もできる。

「ほぼ1人情シス」を3年やってそんなことを思うようになった。

---

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

抽象化と具体化

「ほぼ1人情シス」をやっていて思うのは、

直面している障害や不具合は、すでに誰かが経験している。
そして、その情報はネットにある。

ということ。

「ほぼ1人情シス」は問題が発生しても訊ねる人がいないことが多い。
そこで頼りになるのがGoogle先生だ。

ヘルプデスク担当者は何でも知っているわけではなく、質問して人の代わりに検索しているだけだ。
こう言うと怪訝そうな顔をする人が多いのだが．．．

前々々職でヘルプデスクをやっていたときに、質問する人はなぜ検索しないのだろうかと思っていた。
よく聞いてみると、検索しているけれど有効な情報を見つけることができないらしいことがわかった。

そのころから、
同じ検索エンジンをつかって、有効な情報を見つけることができる人と、できない人がいるのはなぜか考えていた。
自分の行動を明文化するのは難しいのだが、当時はこんなことを考えていた。(ググる <調べる＋学ぶ> (2016/07/29))

重要なことは

• ノイズ混じりの検索出力から目的の情報を見つける

具体的な行動は

• 検索結果はコピペせず自分なりに解釈して使用する
• 検索結果は検証して使用する

おそらく、検索しても有効な情報が見つからない人は、ピッタリの答えを求めているのではないだろうか?
たとえば、「◯◯社ノートPCで◇◇アプリを使用するとイヤホンから音が出ない」不具合の解決方法を検索したときに、ピッタリの答えが見つかることもある。
ピッタリの答えが見つからない時にどうするかで差が出るのだろう。

最近気づいたことだけど、ピッタリの答えが見つからない時は、

• ピッタリではない出力をちょっと抽象化する
• 解決したい問題もちょっと抽象化する

すると、有効な情報が増える。
そして、有効と判断した情報を

• 直面している問題に合わせて具体化する

すると、解決手段が見つかる。
それでも解決手段が見つからないときは、

• 抽象化レベルをもう少し挙げてみる
• 抽象化、具体化の観点を変えてみる

先の例では、
PCからイヤホンに音が出る経路は

アプリ →デバイスドライバー →　BIOS → サウンドチップ → イヤホン

となる。

ハードウェアを抽象化すると、◯◯社以外の製品について記載された検索出力も対象になる。
また、アプリを抽象化すると別のアプリついて記載された検索出力も対象になる。

検索出力が有効な情報であれば、◯◯社の製品、◇◇アプリにに適用できるように具体化すれば良い。

見つからない場合は更に抽象度を上げて検索を繰り返す。
注意しなければならないことは、何を抽象化して、何を抽象しないかを明確にすることだ。
抽象化の観点がズレると大量のデータの海で溺れてしまう。

「抽象化、具体化」に必要なことは、経験と思考だと思う。

8年前に書いた「ググる」(2016/07/29)や「ググる」の功罪(2016/07/04)で書いた具体的な行動は、

• 検索結果はコピペせず理解して使用する
• 検索結果は検証して使用する

これをピッタリの答えが見つかった場合でも実行する。

googleは大量のデータからキーワードに対する検索結果を表示してくれるサービスであって、ユーザが欲しい情報を見つけてくれるものではない、ましてや自分にない知識を教えてくれるものではない。googleは機械であって先生ではないのだ。

---

• ググる <調べる＋学ぶ> (2016/07/29)
• 「ググる」の功罪 <考えることが必要>  (2016/07/04)
• ググれカス <ググったらカス> (2017/09/10)

---

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

思考法 ＜仮説を立てて検証する＞

アメリカのマイクロソフト本社で遭遇した｢私の人生でもっとも賢い人間｣の思考法は本当にすごかった PRESIDENT Online 牛尾 剛 
(2023/12/18)

牛尾 剛氏は

例えばプログラムに問題があったとき、一流のエンジニアは試行錯誤をしない。作業をすることより、自分の頭で仮説を立てることを優先する。その結果、生産性は天地ほど違ってしまう

とおっしゃる。

◯ハードウェアの修理
40年前に無線機の修理をやっていたときに同じことを教えてもらった。
当時はまだディスクリートの無線機が現役で障害の原因となったトランジスタや抵抗、コンデンサーなどの部品を交換していた。

教えてもらったのは

1. 取説を読め
2. 手当たり次第に触ってはいけない
3. 部品を交換しないで原因を推定する
4. それを複数の方法で検証する

3,4 が牛尾 剛のいう思考法だろう

故障が直る人と治らない人がいることに気がついた。
例えば、

• 治るまでの時間が長い
• 障害が再発する
• 修理中に障害が増える

などだ。

他の人の修理方法を観察すると、

• とりあえず調整箇所を触って、基準の性能に追い込んで良しとする人
• 障害の現象からよくある障害の修理方法を順に実行する人
• 正常動作している別の無線機と、比較して障害箇所を特定する人

などがいた。
しばらく働いていると、治せる人の行動はわかってくるものだ。

電子機器の修理は、電子回路の知識、測定技能、交換技能が必要で（今は違うかも）これらは研修で教えてくれる。
しかし、本当の修理方法（思考法）は教えてくれなかったような気がする。

技術者にとって不可欠なのだけれど。

◯プログラムのバグ取り
後にプログラミングを始めてたときにバグ取りは無線機の修理と同じだと気がついた。
そして、コンピュータシステムの保守も同じだった。

プログラミングはコンピュータ内で完結することが多い。
ハードウェアの交換が必要だと気軽に試行錯誤できないけれど、プログラミングは試行錯誤しやすい。
更にリソースとCPUパワーの増大で昔にあった「机上デバッグ」は死語になってしまった。

だから、エンジニアに必要な思考法を学ぶ前に、試行錯誤で解決する方法を覚えてしまうのだろう。

◯「治した」のか「治った」のか
もう一つ先輩から教えてもらったことは、「治した」のか「治った」のかということだ。
「治した」障害は再発しないが、自然に「治った」障害は自然に再発する。

保守の仕事をやっていると、障害の原因の探索中に「治る」ことがある。
　しまった‼︎。あー治っちゃったよ orz
なのである。
迂闊に「治ってしまう」ことを防ぐためにも、まず仮説を立てることは重要だ。

---

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