そろばんでやれ

経理なのに「Excel？何それ？あんた日本人でしょ？日本語使え」と言われた女性【前編】 キャリコネ (2023/2/4)

Excelで集計しようとしたら「そんなうさん臭いものを使うな。そろばんでやれ」と言われたという。
おとぎ話のような記事だけど、本当にあるかもしれないと思ってしまう。

コメントを読むと、Excelが使えないからそろばんにこだわり他人にまでそろばんの使用を強要する年寄りを批判する投稿が多い。

しかしである。
クラウド環境で「ほぼ1人情シス」をやっている立場では、クラウドを導入したのならExcelは禁止にしてほしい。
(Excelの功罪 2023/01/31)
Excelを使うとデータが散逸するし共有できなくなるから、せっかくクラウドを導入しても業務は効率化もできないし、DXないんて夢のまた夢だ。

しかしExcelで成功体験がある人や勉強してデータベース関数が使えるようになった人、マクロが使えるようになった人は、Excelを手放そうとしない。
さらに、他人にExcelの使用を強要する。

そう！まるで、キャリコネの記事に登場するそろばんを強要する人のように．．．

そろばんにこだわる人とExcelにこだわる人に共通するのは、手段と目的を混同することだ。
多くの場合目的はそろばんを使うことでもExcelを使うことでもないもちろんクラウドを使うことでもない。
TPOに合わせて効率的な手段を選ぶことだ。

---

• Excelの功罪 2023/01/31

---

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

MSの大規模障害

マイクロソフト、1月25日に発生した大規模障害の原因を説明

1/25日に発生したMSの大規模障害の原因速報。
今回の障害の原因は、WANルータに投入したコマンドで一斉にルーティングテープルの再計算が行われたことらしい。

〇テーブルの再計算は鬼門
ルーティングプロトコルのおかげでルーターはルーティングテーブルを自動的に計算してくれるので、新設、交換が容易になっている。
ところが、大規模なネットワークではルーティングテーブルの再計算は鬼門だ。

一斉にテーブルを再計算するとパケットロスが増えたり遅延が増大するだけではなく、何日経ってもテーブルが収束しなくなる。
昔見たことがある。

予算の都合でメモリが少ないルータを使うと、新設した時にはなんとか動いているけれど、再計算が始まるとルーティングテーブルが溢れ、特定のLAN間で通信できなくなる。

ルーティングテーブルを溢れさせる原因になっているルーターが別のLANにあると、原因究明は困難だ。
ルータを設置するときには、通信できることを確認すると安心してしまう。
設定ミスで他所のルータのテーブルが溢れさせるとは思わないのである。

〇ネットワーク屋さん
ネットワーク屋さんは普段注目されることも感謝されることも無いのだけれど、障害が発生した時には非難される。
損な役回りだ。

速報で直接的な原因は発表されたけれど、問題は、なぜそのような危険なコマンドが承認なしに実行されたかだろう。
本当の原因を追求して対策しなければ、同じ事故が発生する。
多くの場合、ネットワーク屋さん個人の資質より組織風土などが要因になることが多い。
大型連休の度に止まる銀行のシステムのように。

詳細なレポートが発表されたら読んでみよう。

---

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

Excelの功罪

〇 Excelの功罪(功)

Excelがなかった頃や使い物にならなかった頃に少し大きなデータを扱おうとすると、自分でプログラムを書くか、データベースソフトを使わなければならなかった、処理、入力フォーム、出力フォームは別に作らなければならなかった

ところが、PCの性能が向上し、ストレージとメモリが潤沢に使えるようになると、全てExcelでできるようになった。

データベースの設計を間違えると、痛い目にあうけれど、Excelを使うとデータベースを考える必要がなく、なんとかなってしまう。

そういえば、「データ」という言葉の概念がずれていると感じることがある。
「データ」＝「ファイル」(主にExcelファイル)と考えている人がいるのだ。

Excelファイルは

• ・データ
• ・入力フォーム
• ・出力フォーム
• ・処理（計算式、マクロ）

がセットになってパックされている。

パソコンがネットワークに繋がっていなかったころには、重宝だった。
入力フォーム、出力フォーム、処理（計算式、マクロ）は、使い回しできるからファイルをコピーして別のデータセットで使っていた。
この方法で随分作業が省力できたのだ。

〇 Excelの功罪(罪)

クラウドが使えるようになって、大量のデータをクラウド側で処理し、リアルタイムで共有できるようになったが、未だにExcelで個人的に管理している。

同じデータを複数のExcelファイルに記録し、複数の個人が別々に管理しているとデータの同一性が保たれなくなる。
その結果、複数のファイルに似たようなデータが記録されているが、どのファイルのデータが正しいかわからなくなる。

データが少ないか、Excelファイルを共有している範囲が狭い場合や献身的にデータの管理をする人がいれば何とか機能する。
だから、手っ取り早く、クラウドストレージに業務ごとのExcelファイルを保存して、便利になったと安心してしまう。

しかし、データは拡大するし、個人が管理できるデータ量には限りがあるから、遅かれ速かれ破綻する。
これが、DXが進まない一因だろう。

組織が扱うデータは個人のものではないから、組織的に管理して、共有するのが当然だ。
ところが、データは個人のもので、データを入力した個人が管理して、ファイルとして共有ストレージ(個人のストレージ)に置いている。

その昔紙ベースで仕事をしていたときに、重要なデータが記録された物理的なファイルを共有のキャビネットには置かず、自分の机の引き出しに入れているオジサンがいた。
それと同じだ。
データは自分が使えたらそれで良いという、意識はICTが発達しても変わらないのかもしれない。
そして、それが草の根DXで超えられない壁かもしれない。

---

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

Share Point＜SharePointはデータベース＞

M365のウェビナーを片耳で聴きながら仕事をした。興味があるとこだけまじめに聞く。

まじめに聞いたことは。
Sharepointの基本はデータベースだということ。
なるほど腑に落ちた。

〇 Share PointとファイルサーバーとExcel

用途によってはファイルサーバーとして使えなくもない。
移行ツールもあるから、ファイルサーバーを置き換えて使っているところもある。

ところが、ファイルサーバーとデータベースは根本的に違う。
どちらもデータが記録されているのは同じだが、データベースは記録されたデータから新しいデータを生み出すことができるのに対して、ファイルサーバーは新しいデータを生み出すことはできない。

「ほぼ1人情シス」を始めてから1年以上わからなかったことは、SharePointをファイルサーバとして使っていること。
SharePointにExcelをファイルが保存されていて、その都度ダウンロードして編集している。
しかも、同じデータが記録されたExcelファイルが複数あって、手動で同期している。

せめて、データだけでも分離すれば省力化できるのに、頑なにExcelにこだわっているように見える。
そういえば、「データ」という言葉の概念がずれていると感じることがある。
「データ」＝「ファイル」(主にExcelファイル)と考えている人がいるのだ。

クラウドが使えるようになって、大量のデータをクラウド側で処理し、リアルタイムで共有できるようになったが、未だにデータをExcelで個人的に管理している例は多い。

同じデータを複数のExcelファイルに記録し、複数の個人が別々に管理しているとデータの同一性が保たれなくなる。
組織が扱うデータは個人のものではないから、組織的に管理して、共有するのは当然だ。
ところが、データは個人のもので、データを入力した個人が管理して、ファイルとして共有ストレージ(個人のストレージ)に置いている。

その昔紙ベースで仕事をしていたときに、重要なデータが記録された物理的なファイルを共有のキャビネットには置かず、自分の机の引き出しに入れているオジサンがいた。
それと同じだ。
データは自分が使えたらそれで良いという、意識はICTが発達しても変わらないのかもしれない。
そして、草の根DXで超えられない壁かもしれない。

〇 Share PointとDBS

データが大量になって管理工数が増えたら、ICTの専門家ならば、データベース・システムを導入しようと考えるだろう。
ところが、Excel大好きな人は、データベース・システムを知らない。Excelがデータベースだと思っているので、話は噛み合わないことが多い。

そのようなときには、

「とりあえず共通したデータのファイルを分けて、それぞれの業務で使うExcelシートから参照しましょう。そして、データを更新する人を決めましょう。」

と提案するのが良さそうだ。

共通したデータが分離できれば、Excelファイルから、データベース・システムに変更すればよい。Excelにはデータベース・システムのデータを参照する機能がある。

◯ どうしてもShare Pointをファイルサーバとして使いたい場合は

Share Pointでファイルを保存するライブラリ（ドキュメント）は、

• ファイルメタデータ
• ファイル本体
• 保存パス
• ファイル本体へのLink(表示はファイル名)

が保存されたDBと、

• ファイル本体へのリンク(ファイル名)
• 更新日
• 更新者

のリスト(Share Pointでデータをテーブル形式で一覧できる仕掛け)でできている。

ファイルの一覧はまるでNASのファイル一覧のように見えるが実態はDBだから、追加の属性を保存するカラムを付加できる。
他の属性を持たせてビュー(見え方)を変えると、データの一貫性を保ちながら業務毎に異なるデータセットになる。
そうすると、あちらこちらのフォルダに同じファイルをコピーしなくて良くなる。

---

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

2要素認証(2) ＜その後＞

2要素認証に使うAuthenticatorがインストールできないから、単一認証にしてくれと言われていた人達の後日談。
2要素認証　＜対応できないからってねぇ．．．＞(2022/12/14)

その後、関係部署と調整して、私物スマホでAuthenticator を使えるようになったらしい。
なんでも、業務に私物スマホを使うこと、私物スマホに業務に関係するアプリをインストールすることがセキュリティポリシーで許可されていなかったらしい。

セキュリティの基本に立ち返って判断すると、
私物スマホに2要素認証に使うAuthenticatorをインストールして、自組織以外の2要素認証に使用したら、その組織のセキュリティレベルは、向上するのか？それとも低下するのか？

Authenticatorは業務上の情報を扱わないから、セキュリティレベルが低下することはない。
一方で、単一認識にするとセキュリティレベルは確実に低下する。

セキュリティポリシーの目的はセキュリティ憲法を盲目的に遵守することでも、セキュリティ警察の取り締まりの根拠にするることでもないだろう。
スマホが無いときに作ったセキュリティ憲法に縛られているのだろう。

閑話休題

全員に業務用スマホを支給できれば良いが、コストや管理を考えると現実的ではないことは多い。そこで、私物スマホを使いたいわけだ。

情シス的には、メールアドレスやPCを共有しているユーザは個人の特定ができないから、業務用の共用スマホではなく私物スマホでAuthenticatorを使ってほしい。
さすがに私物スマホを他のユーザと共有したりしないだろうから。

---

• 2要素認証(2) <その後＞ (2023/02/04)
• 2要素認証　＜対応できないからってねぇ．．．＞(2022/12/14)

---

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

2要素認証 ＜対応できないからってねぇ．．．＞

最近2要素認証が増えてきた。
使う側は面倒だけれど、「ほぼ1人情シス」としては、全て2要素認証にしてほしいくらいだ。
2要素目は、E-mail、SMS、OneTime PassWord(Authenticator)、生体認証などがある。
個人を特定したいので、認証に使用するデバイスはスマートフォンを使うのが現実的だ。

最近とある人から、単一認証にしてほしいと言われた。
なんでも、セキュリティポリシーで、私物のスマートフォンを使えないらしい。
しかも、E-mailアドレスを共有していたりするから、個人が特定できない。
そこで、単一認証にできないか？ということらしい。

立派なセキュリティポリシーもあるし、セキュリティ警察もいるようだが、杓子定規的な運用なのか回避策がないらしい。

セキュリティ警察が釈定規的に運用するのは勝手だ。
しかし、他所のセキュリティレベルを下げてくれは無いだろう。

そんなところは、切ってしまえばよいのだが、情報を持っていたりするので、「一昨日来やがれ (ーーメ」と言えない。

世間からズレていることを認識することは重要だよなぁ

---

• 2要素認証(2) <その後＞ (2023/02/04)
• 2要素認証　＜対応できないからってねぇ．．．＞(2022/12/14)

---

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

マイクロソフト 再始動する最強企業

マイクロソフト　再始動する最強企業　上阪 徹　ダイヤモンド社

MSの人と話す機会があった。
とある中央省庁の偉い人に、良かれと思い人材交流の提案をしたら、規則があって簡単ではないことを懇々と説教されたのだそうだ。
さもありなん！と思ったのだが、後からMSはそんな会社だったのか？と思い、この本を読んでみた。

MSはパソコン(昔はマイコンといった)が16Bitになったとき、OSの覇権争いをしている頃から知っている。
そして、競合するソフトや会社をを次々と潰すことで拡大した会社で、「帝国」のイメージだ。

おそらく、某中央省庁の偉い人もそのイメージがあったのではないだろうか。

ところで

1年前からM365を使っている職場で「ほぼ1人情シス」をやっている。M365を使って分かったことは、MSはOSやアプリを売る会社ではなく、クラウド・サービスの会社だということ。

今でも、OS(Windows)やOfficeは売ってはいるが、Windows10、11は無償でアップグレードできるし、Office Onlineは無償だ。
まだまだ、Windows、Word、Excel、PowerPointは手放せない。しかし、これらの、OSやOfficeソフトよりTeamsやSharePointが中心になっているということだ。

Office Online版

Office Online版はブラウザで動くので、OSは Windowsでなくてよい。
Intuneを使うとWindowsだけでなく、iOS、Androidデバイスを管理することができる。MSはWindowsにこだわっていないように見える。

昔は、
データは個々のPCにあった。
ネットワークが使えるようになったころから、オンプレのファイルサーバーを置いて共有していた。
ファイルサーバーは、ストレージ(ファイル置き場)だから、データを加工したり、新しいデータを創るためには、ファイルをPCにダウンロードして、PCにインストールしたアプリを使う必要があった。

今時は、
データはクラウドにあって、データの処理はクラウド側で行われる。
オンライン版のアプリはUIだ。

オンライン版のアプリは、デスクトップ版のアプリ同じようなUIなので、昔の感覚の人は、つい、アプリの機能に着目しがちだ。
データと処理の実態がクラウドにあることで、新しい価値を生み出せるこ、新しい働き方ができることに気づいていないのかもしれない。

MSは、新しい価値を生み出せること、新しい働き方を提供・提案する会社になったということのようだ。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【雑誌・書籍】

システムの「作り逃げ」を許すな

システムの「作り逃げ」を許すな、運用保守を担う技術者の時間が奪われる 沢渡 あまね (2020/03/25)

今に始まった問題ではないだろう。
昔大手ITベンダは、この問題を悪用してベンダロックオンしていたのだから。
一時期、一円入札が問題になった。システム開発を破格の低額で落札する大手ITベンダは多かった。
そして、長期間の保守費で元を取り、「作り逃げ」をちらつかせてリプレースの選考も有利に進める。
その結果、ITベンダはたくさんのIT土方を抱えたITゼネコンになったのが、今の日本のIT業界だ。

つい最近、開発中のとあるシステムで、メールを取得しなければならなくなった。
一部の機能のためにメールサーバーを立てるのは大変だから、運用担当は、Exchangeのメールボックに開発中のアプリでアクセスすれば良いと安易に考えていたようだ。

ところが、ExchageはBASIC認証ではアクセスできなくなっているから、OAuthで認証するコードを書かなければならなくなった。
サンプルは沢山あるからそんなに負担ではないけれど。

OAuthで使うクライアントシークレットはAzureADから取得するのだが、最長2年の期限付きだから、定期的に更新しなければならない。
更新は難しくはない。

クライアントシークレットの期限が切れると、当然だけどメールボックスにアクセスできなくなる。

このシステムの運用がはじまって、メールが取得できなくなった時には、システムの運用者、システムの開発者、M365の管理者が協力しなければ解決できないだろう。
構築に携わった人達がいる間は、運用できるけれど、いなくなったら障害が発生する可能性は高い。

経験では運用前に懸念があることは、必ず発生する。しかも、忘れた頃に。

M365の管理者なので、Exchangeを使わないことを主張したのだが、運用開始を優先する声に押切られてしまった。
クラアンとシークレットの有効期限など覚えていられない。PowerAutomateで通知することはできるけれど、システム開発者の知らないところで動いているPowerAutomに依存するのはいかがなものか。

「ほぼ一人情シス」だから、引き継ぎは結構なリスクなのだが．．．

技術者は、とりあえず稼働すれば後は関係ないという、易きに流されない良心が必要だと思う。

---

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

デジタルカイゼン

SharePointのリストとPowerAutomateで簡単な承認システムを作ってみた。
テンプレートがあるのでプロトタイプは半日くらい、
ユーザの要望に応えるために手直しして3日くらいでできた。
入力画面や印刷画面をPowe Appsで作りこむと見栄えは良くなるけど、なるべく標準機能を使って、作り込まないようにした。

減ったのは、ハンコが3個と、Excelの様式くらい。最後は物理的にファイリングするらしく、紙は減らない。
紙を減らしたり無くすには。業務の全体見直しが必要で、承認システムやアプリを導入したから紙が減るわけではない。

デジタル・カイゼンの域を出ないのだが、ユーザの立場ではハンコとExcelが減ったら良しとしよう。

ところで、
「DX」「内製化」は旬な話題だけど、内製でDXはかなり難しいのではないかと思う。
内製化すると、業務の細部もわかっているから言語化し難いノウハウも取り込むこともできるかもしれない。

重要なことは、
社会DXチームに権限が与えられていることだ。
業務を改革しようととすれば、総論賛成、各論反対になる。
改革は利害の調整ではなくて、目的を実現するための合理的な方法だから、大多数が抵抗勢力になる可能性もある。
そのような状況下で改革を進めるためには、権限がなければならない。

「ローコード・ノーコード」も旬な話題だ。
今時、システムを作るために、何年もかかっていたのでは、DXは難しい。
ローコード・ノーコードで開発すると、開発→運用→改修　のサイクルを短くできる可能性はある。

ローコード・ノーコードでの開発は、高いコーディングスキルは必要なくなるが、プログラミング技術が不要になるわけではない。
しかし、プログラミングとコーディングの区別ができない人は多いような気がする。

RPAなどの売り方を見ていると、
ローコード・ノーコードで開発すると、プログラミング技術も不要で簡単に内製化できるようにミスリードしていると感じることがある。

---

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

SlackもTeamsもダメ

「SlackもTeamsもダメ」、そんな企業にオープンイノベーションは100年早い 沢渡 あまね あまねキャリア工房 (2021.05.26)

非同期コミュニケーションができない人達や会社は結構あるようだが、それは置として、
違う会社に属する人たちが参加するプロジェクトでは、ビジネスチャット使用の可否、どの製品を使うか、誰が招待するのか(どの会社のシステムを使うか)が問題になる。
E-mailしか使えないという会社・組織もまだあって、今流行りのオープンイノベーションの障害になっている。

沢渡氏はE-mailしか使用を許可していない会社を非難するのだけれど、
本質はセキュリティポリシーの不整合だろう。
世の中の会社がSlackやTeamsを使うようになってもこの問題は残る。

冒頭の記事に登場する、フリーランスE氏のセキュリティポリシーは自分自身が決めて自分がコントロールすれば良いから、Slackでだれに招待されても対応できる。

Teamsしか使えないB氏は会社でM365を導入しているのだろう。
M356で完結すればセキュリティポリシーをクリアしやすい。
ところが、招待するのと招待されるのは、セキュリティ上大きな差がある。

招待すれば、チャットの投稿や添付ファイルは、自社のスペースにあるから、コントロールは容易だ。
ところが、招待されると情報が相手のスペーに保存されるから、コントロールできない。
もし機密性が高い情報が投稿された場合、招待していれば、管理者権限で削除することができるが、招待されていると完全に削除できない。

セキュリティがしっかりしている組織はたいてい、他組織のTeamsに参加を禁止しているようだ。
Teamsしか使えないという会社は招待すれば使えるということだ。しかし、ちゃんとした組織同士だとどちらかが参加できない。

E-mailしか使えないC社は、サンプルを真似てセキュリティポリシーを作り、情勢に合わせて改訂していない会社・組織だろう。
セキュリティポリシーを決めた時にビジネスチャットは想定していない。

コロナ禍でビジネスチャットを使わなければならなくなっても、セキュリティポリシーに規定が無いと(当たり前)使用を禁止したままなのだろう。

余談だけど、ビジネスチャットを禁止して、コロナが流行していてもリアル出社の会社・組織もあるようだ。改革、改善、イノベーションを全て否定する潔さはある・・・

社外の人とビジネスチャットのでコミュニケーションする際に招待するかされるかを気にする人は少ない。気にしているのはセキュリティ担当くらいだ。
普通のユーザは忖度して、「お手間でしょうからウチが招待しますよ」となるのだが、セキュリティの甘い会社・組織には招待されたくないよね。

今は、コロナ禍で急激に変わったから、問題の本質が見えていないユーザが多いのだと思う。
TeamsはよくてSlackはダメとか、逆にSlackはよくてTeamsはダメという話を聞くことがあるのだが、禁止されている行為、許可されている行為は伝わってなくて、禁止されたツール、許可されたツールにすり替わっているのだろう。

システム担当としては、SlackでもTeamsでもいいから招待してほしい。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【働き方改革】