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

表計算｢作った本人が退職｣会社で起きる大混乱 東洋経済　鈴木 純二 （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】

ベンダーが開発しても内製?

ベンダーが開発しても内製？モヤモヤする「システム内製」の意味を改めて考えてみた
鈴木 慶太 日経クロステック／日経コンピュータ
 (2022/11/15)

鈴木慶太氏は

内製で重要なのは、正社員がソースコードを書くか否かではなく、ユーザー企業がきちんと全体をコントロールし開発と運用を密接に結びつけ、リリース後の不具合や改善要望に即座に対応できる体制を整えているかだ。そのため繰り返しになるが、先の開発をしておらず運用フェーズもおろそかにしている「システム企画や設計だけ内製している」という企業は内製とはほど遠いと思う。

IPAによると「内製化とは自社でプロダクトをコントロールすること」らしい
自社でプロダクトをコントロールするって、当たり前ぢゃないか!?
「なる早くで感じでいい具合に作ってよ」でベンダーに丸投げしてるのか？

要件定義書から実際に実装するのは専門的な知識が必要だ。
クラウドサービスとノーコードプログラミングでハードルは下がっているとはいえ、実際に自社内で完結できるのは体力がある企業くらいだろう。

鈴木慶太氏がおっしゃるとおり、
・全体をコントロール
・開発と運用を密接に結びつけ
・リリース後の不具合や改善要望に即座に対応できる体制
が重要だ。
中でも全体をコントロールすることは外注できない。
（できなくはないが、機能するとは考えにくい）

不具合や改善要望への対応は、自社内でコードを書いた方が早いように見える。
事務手続き手間と時間がかからず仕様明確にできるならば、外注した方が短時間、高品質になる可能性は高い。
しかし、部署間の調整ができず仕様が明確にできなかったり、事務手続が煩雑で時間がかかることはよくあることだ。
そもそも、部署間の調整ができないとか、事務手続きが煩雑という問題がある時点で、内製か外注かという問題以前である。

DXを考えるときにICTへの知見や、内製化、ノーコードプログラミングに目が向きがちだけれど、風土を変えることが最も重要だと思う。
風土を変えなければ、内製化しても、外注しても、期待通りにはならない。

---

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