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

くだらない仕事と成り果てたシステムの保守運用、若者にやらせるのは犯罪的だぞ
木村 岳史 日経クロステック／日経コンピュータ
(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人情シス】

表計算｢作った本人が退職｣会社で起きる大混乱

表計算｢作った本人が退職｣会社で起きる大混乱 東洋経済　鈴木 純二 （2024/02/08）

東洋経済らしく読者層を考慮して、表計算ソフトの利用を例に会社のデジタル化を説明しておられる。

※どれか1つにでもチェックが入れば初期段階。改善が必要です
□ 定例業務を回すためには表計算ソフトの使用が必須である
□ 社内で紙の伝票が回っている
□ お客さまから対応の遅さを指摘されている
□ お客さまに紙やファックスで帳票を送っていただくようお願いしている
□ 同じ仕事をしている担当者間で仕事のやり方が違う・作業効率が違う
□ 事務職の社員が「テレワークはできない」と言っている

らしい。

鈴木 純二 氏はデジタル化の初期段階を、電卓仕事からパソコンを使った仕事に切り替わった段階で、

「会社に1つ以上のメールアドレスがあり、ホームページも業者に作ってもらった。簡単な計算は表計算ソフトでやっている。パソコンはネットワークに接続されており、ファイルやプリンターの共有ができている」といった状態

とおっしゃる。
感覚的には25年くらい前だろうか。

表計算ソフト（Excel）の進化は著しい。
機能も増えたし、データベースや統計用の関数も増えた。
初期のExcelは扱えるデータ量に制限があったから個人的に使用する便利ツールだった。

表計算ソフトが実用になった頃から作業効率が格段に良くなった。
そして、いつしか
　パソコンが使える＝Excelが使える
のようになっ多様な気がする。

「Excelが使える」から「Excelの関数が使える」の壁は大きいようだ。
便利な関数を使うと、更に作業効率が上がる。
他人が作ったExcelシートは手を入れないで使えるなら便利だが、変更しようとしたり、不具合を治そうとすると、心が折れることが多い。

一般的に、コンピュータを使って入力データを処理して結果を出力するには
　処理を分析→アルゴリズム検討→コーディング→実行
というステップを踏む。
逆の流れをたどるのは大変だ。
便利な関数が使われたExcelシートはコード（プログラム）が書いてあるだけだから、アルゴリズムや作者の意図がわからない。
Excelで業務が効率化したとしても、それは業務ソフトではなく使い捨てツールだと思ったほうが良い。
この問題はExcelシートだけではなく、今流行のRPAで作成したアプリにも当てはまる。

因みに、冒頭の記事には解決方策が無い。記事で紹介された本を買えということか？

解決方策
「ほぼ1人情シス」が考える解決法作は、
　知識と技能に投資すること

ICTに関して設備やソフトに投資しただけで、デジタル化するのは無理で、知識と技能が必要だ。
知識と技能を持った人（技術者）を雇用しても良いし、社内で素養を持った人を教育してもよい。

必要なのは、設備やソフトと知識と技能だ。

最近、豊川悦司がCMでやっている「俺文系管理職なのに～」を信じてはいけない。

---

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

情シス頑張ったことアンケート 2022 ＜他人のやりかを変えることは難しい＞

情シス頑張ったことアンケート 2022

IIJが毎年「情シス頑張ったことアンケート」を公開している。

『最も「イラッと」したこと』の中に、↓のような回答があった。

MS365の導入で、完全にTeamsというWeb会議システムになってしまっていること。例えば、チャット機能の利用を推進しようとして経営層が出席している会議で説明を行ったが、鼻で笑われて相手にされなかった。
また、チームやOneDriveを利用して、Excelでの情報共有をリアルタイムに行う方法も現場に指導してみたが、結果的には使われておらず、今まで通りファイルサーバ上に置いてあるExcelファイルで共有しているため、時々、誰も使っていないのに使われていることになるOSのバグが発生し続けている。どのようにすれば、Web会議以外の機能を業務に有効活用できるかを悩んでいる。（100～500人／機械・電気製品）

目に浮かぶようだ。

Excel＋NASから離れられない人は多いようだ。
だから、SharePointをNAS代わりに使う。（わかりやすいから）

SharePointに置いてあるファイルはロールバックできるけれど、その機能を知らないから古いバージョンのファイルがたくさん置いてあったりする。
でも、バージョン管理は意識していないようだ。

SharePointのリンクを送って編集すれば共同編集できるのだが、わざわざダウンロードしてメールに添付して送る（白ヤギさん黒ヤギさん方式だ）から、コピーが増える。
そして、どのファイルのデータも最新でない状態になる。

今や業務チャットは不可欠だ。
ところが、「メールで送ってほしい」という人がいたりする。
どうしてもメールで受けたければ、チャットでメンションされたら自動的にメールに転送するようにすればよいと思うのだが．．．

他人に労力を強いるのは、Exceでなく算盤、メールでなく電話の使用を強要する構造と同じだ。
古いやり方に固執し、他人に労力を強いる人がいると、今時のシステムを導入しても効果は 無い 限定的だ。

情シスをやっていると、「ああ゙～率化できるのに．．．」と思うことはたくさんある。
ところが、他人のやりかを変えることはとても^2難しい。
業務改善はボトムアップだけでは無理だ。

---

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

DMARCレポート

◯DMARC
Googleがメール送信者のガイドライン(https://support.google.com/a/answer/81126?hl=ja)を発表してから、あちらこちらに影響が出ている。

メールを大量送信するユーザでなくてもDMARC対応を求められている。
たとえば、SAKURA internetはレンタルサーバから送信されるメールのDKIM,DMARCに対応したようだ。
【さくらのレンタルサーバ / マネージドサーバ】DKIMおよびDMARC対応に関するお知らせ

「ほぼ1人情シス」をやっているサイトでは1年くらい前にDMARCに対応した。
DMARCに対応すると毎日DMARCレポートが送られてくる。まじめに見ると結構な負担だ。

◯ところで、
CISCOさんのDMARCレポートは迷惑メールフォルダーに配送されていた。

冗談みたいなはなしだけど、DMARCレポートのメールヘッダーを見たら、dmarc=fail になっている。
これまでCISCOのDMARCポリシーは none だったから迷惑メールフォルダーに配送されていたが、最近ポリシーを rejectに変えたようで、リジェクトされるようになった。
cisco.comを使っているユーザのメールは dmarc=pass なのでユーザには影響はないようだ。

◯情シスは気がつくのか?
情シスはDMARCレポートがリジェクトされていることに気がつくのか考えてみた。
ユーザのメールはリジェクトされていないので、ユーザからの申告はない。
DMARCレポートを受け取っている組織の情シスは気が付くけれど、CISCOに知り合いがいないとなかなか連絡しにくい。

CISCOの情シスさんは、DMARCレポートを見ていれば気が付くけれど、CISCOさんくらい大きなサイトだとDMARCレポートも多いだろうからツールを使わないと難しいのではないかと思う。

◯DMARCの説明
Eメール認証のベストプラクティス – SPF、DKIM、およびDMARCを導入する最適な方法

---

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

細心の準備をして、大胆に行動する

悲観主義でもないし、ゼロリスク教の信者でもないのだが、最初に就いた仕事がインフラの保守・運用だったからだろうか「自分の行動は失敗する」ことを前提にしている。

世の中には「自分の行動は成功する」ことを前提にしている人がいる。

「成功を前提にしている人」はトラブルが発生した時に、損失と回復コストを考えて、リソースを手配して、最善の回復作業を行う。
この行動様式は、意思決定が速いし、成功した時のリターンが大きい。失敗した時の損失が大きくなる。

一方「失敗を前提にしている人」は、発生する可能性があるトラブルを考えて、あらかじめリスク回避する、致命的なトラブルが想定できる場合は、発生確率が低くても可能な限り回避する。
この行動様式は、意思決定が遅くなり、成功した時のリターンは少なくなる。失敗した時の損失は少ない。

どちらが正しいか、間違っているかではないのだが、
昨今の、大手キャリアの大規模回線障害や銀行のATMの障害などインフラ障害のレポートを読むと、「失敗を前提にしている人」(保守・運用部門)の意見が蔑ろにされているのではないかと感じる。

Windows11にアップグレードすることになった。
自分が使っているPCをアップグレードでも問題は発生しなかったし、数台Windows11にアップデートしたPCは問題は無いようだ。
「一斉にアップグレードすればいいじゃないか」という人がいるのだけれど、直観的にリスクが大きいと思ったので、段階的にアップグレードすることにした。

クラウドサービスを使っているので、ネットワークに接続できないトラブルが発生すると、業務がすべて止まってしまう。
これは致命的なトラブルだから、可能な限り対策しておく。

回復できないトラブルが発生する可能性は低いが、些細なトラブル対応でも、それが数十台一斉に発生すると、多くの時間が必要だ。
だから、トラブルが発生しても、「ほぼ1人情シス」で対応できる範囲にとどめたい。

細心の準備をして、大胆に行動する。

---

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

Eメールはかなり不確実な通信手段

「ほぼ1人情シス」をやっていて感じることは、Eメールはかなり不確実な通信手段だということ。

インボイス制度に対応するために請求書発行を外注したらしい。
請求書発行業務をデジタル化したわけではなく、請求書を送る前までは、紙に印字してハンコを押している。(^^;

システム管理業務の委託を受けて「ほぼ1人情シス」をやっている職場に保守料の請求書を送ったと聞いたので、メールの配送履歴を確認したら、なんと、SPAMメール判定されている。

確認すると無事、ジャンクメールフォルダで発見されたようだ。
ヨカッタ。給料がもらえる。

請求書発行の担当曰く「難しいことはわからない!! メールがちゃんと届いて、請求金額が振り込まれたらOKだから!!」って、そのメールがちゃんと届いていないんですけど。

日本中でこんなことが起きているんだろうな。

最近政府はDMARCを推進している。
普通の会社はなりすましの被害を受ける可能性は低いから、他人事で普及しないだろうと思っていたのだが、請求書が届かないとなると、他人ごとではなくなるのでDMARCの普及が進むかな。

よくある誤解

• Eメールで送ったら郵便と同じように相手に届くのだろう
  　郵便事業は国の許可・認可が必要で、郵便法という法律もある。だから、ほぼ確実に届くし、届けられない場合は戻ってくる。
  　しかし、Eメールは途中でなくなることがよくある。
  　昨今、迷惑メールや、詐欺メール、ウイルス付きメールが増えているから、危険なメールと判定されると相手に届かない。
  　★しかも、届かなかったことは通知されない。
  
  
• 危険なメールでなければ届くのだろう
  Eメールはインターネットに善人しかいなかった頃にできた仕組みだから、昔は、他人に成りすましてEメールを送ることができた。
  今時は、送信側がなりすましでないことを証明しなければ、受け取ってもらえなかったり、ジャンクメール扱いされる。
  大企業や通信事業者はこの仕組みを導入していていることが多い。中小企業は通信事業者のメールシステムを使用していることが多いから、なりすましでないことを証明できない場合、Eメールを受け取ってもらえないことがある。
  ★この場合、Eメールを送った人も、送られた人も、届かなかったことを知ることができない。
  
  
• 迷惑メールフォルダでも届いていればよいだろう
  自分が知り合いの家に書類を届けるときに相手の家まで行って届けることを考えてみる。
  留守だった場合にポストに投函しておくのはOKだろう。しかし、勝手口においてあったゴミ箱中に入れて帰ったらどうだろう。
  届けたのだから、「ゴミ箱の中を漁ってよ」と言うのだろうか？
  「メールソフトの迷惑メールフォルダを探して」と言うのは「ゴミ箱を漁って」と言うのと同じことだ。

「ほぼ1人情シス」をやっていて感じることは、「届くはずのメール」を捜索することがよくある。
Eメールはかなり不確実な通信手段だと思う。

---

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

10℃・2倍則 ＜専門家の想定リスクは聞いとけ＞

10℃・2倍則を初めて聞いたのは40年くらい前だった。
10℃・2倍則をざっくり説明すると、材料の寿命に関する法則で、使用している環境の温度が10℃下がると寿命が2倍になり、10℃上がると寿命が1/2になるという法則だ。

インフラ保守では寿命予測が重要だ、寿命に近づくと障害率が急に上がって、サービス停止時間が増える。
インフラがサービス停止すると影響が大きいので、寿命が来てサービス停止に至る前に交換しなければならない。
ということを、厳しく教育された。

そこで、重要になるのが10℃・2倍則だ。
だから、インフラの通信機器は、空調の効いた専用の部屋に設置して温度管理するのが普通だ。
三子の魂なとやらで、今でもマシンルームやサーバールームに入ると温度が気になる。

「ほぼ1人情シス」をやっている職場で、ハイスペックPCを増やす計画が持ち上がったのだが、設置スペースが足りないので、サーバールームにPCをまとめて設置して、サーバールームの外から接続する案が出た。

サーバールームの19”ラックはサーバーが増えてきたので、室温が上がっている。
ここにハイスペックのPCを設置して24時間運用するなら、それなりの空調設備が必要だが、建屋との関係で、簡単に空調設備を増設できない。

10℃・2倍則はインフラ屋では常識だけど、ユーザにとっては常識ではない。
専門分野では具体的なリスクが想定できるけれど、専門分野以外のリスクは想定できない。
インシデントで被害が拡大するのは、専門家が想定するリスクを信じないからだと思う。

---

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