Access学習メモ 0-10. ユーザーのために

職場の社内システムに、10数年ぶりのリニューアル案が浮上した。

これまでは顧客に所定のExcelを提供して情報をとりまとめていただき、顧客から預かったExcelを受付担当(ちびメカ)が社内システムにアップロードし、編集・修正・登録を行い、仕上がったデータを顧客と相互確認し合う業務体制をとってきた。

今後は顧客向けポータルサイトが新設され、顧客と同一データベースを共有し合う、いわゆるクライアントサーバー型Webシステムへと移行する。

顧客にとっては、自社データ取得や部分編集が自在に行える一方で、これまで当社に一任してきた情報管理を自らの責任において行う必要が生じる。

これまでは、データ保管庫の整理や情報出し入れを、私たちに電話ひとつで要請でき、あとは仕上がりを待っていればよかった。

その対応窓口が突然、なくなり「明日からはセルフサービスでお願いします」「大丈夫、完璧なシステム用意しておきますから」と、案内を受けるわけだ。

計画案の施行にあたり、先ずは現場の声を・・・というわけで、私たちの住む怪獣島(仮名)に開発エンジニアがやってきた。

「パソコンに明るくない島々の人たちでも、画面上のボタン操作ひとつで簡単に扱えます」

その希望あふれるプレゼン冒頭に、ベテラン社員による直球が水を差す。

「あなたたちエンジニアが思う『簡単』は、不慣れなユーザーにとっての『簡単』ではないんですよ」

エンジニア(開発者)は「ボタンを数回押すだけの最低限の操作を」と、技巧面での理想を目指す。

ユーザー(顧客)にとっては「そのボタン操作を誤ってしまったら」「別の画面に迷い込んでしまったら」とする不安や抵抗感が拭えるわけではない。

Accessを通じ、データベース構造を学習してきた身としては、いろいろと考えさせられる現実問題。

作り手と使い手の温度差が埋まらないからこそ、10数年のうちに幾度となくシステム改修を繰り返したにもかかわらず課題は減らず、現場の工数は紙とFAXがメインだった頃よりも、むしろ増えてきた実績がある。

費用対効果が実現したのは、IT部門が稟議と査定のために用意したパワポ資料の世界のみ...という皮肉な結果を許してきた。

「DX推進」「業務効率化」の水面下にある実態として、私たちが請け負ってきた費消工数が「自己責任」を理由に顧客へ移行する結末は避けられない。

顧客の全面協力なしには実現し得ない構想であることは、誰の目にも明らかであろう。

顧客が新制度に納得し、システムを完全に使いこなせるまではケアやフォローが必要である。

課題1：

「システムに関する問合せ専用ダイヤルを開設し、担当窓口をIT部門に担ってもらう」

IT部門はシステム開発するのみで終わり、顧客の相談窓口を現場任せにしてきたからこそ、どれだけ予算と時間を費やしてみても、現場の思惑と乖離したシステムばかりが誕生してきた現状がある。

課題2：

「顧客の操作画面をリモート確認できる手段をつくること」

どれだけ事前説明を行ったとしても、未知のシステムに慣れるまでの間は不安要素が強く、突発的なエラー症状の回避はむずかしいものだ。

課題3：

「紙に印刷出力して利用可能な、顧客向け操作マニュアルを必ず用意する」

操作マニュアルは、Web画面上に手順メモとして埋め込まれることが少なくない。開発者としては、その方が手間がかからないからだろう。

しかし、システム操作を覚えることに必死なユーザーにとっては、マニュアルチェックのために更なる画面移動のストレスを感じながらの作業となる。

不慣れなユーザーほど、手元に全工程を示した紙資料を置き、パソコン画面とそれを相互に見比べながら、現在どの工程まで進めたか、必要な手順のひとつひとつを指さし確認しながら、慎重に進めたい心理が働く。

操作画面に端的なコメントを示したり、改ページプレビューが機能しない(印刷利用を想定しない)手順書は、そもそもマニュアルと呼ぶには値しない。

・・・等々。

打ち合わせを進める中、これまでAccessで作ってきた「見積書」についても、開発担当へ情報提供を行った。

発注内容に応じた見積金額について、顧客自らポータルから任意で出力できる未来を提案し、それが可能か今後、検証される形だ。

源泉徴収票や給与明細の照会、スーパーの会計、病院や薬局の受付。

かつては労務担当が帳票を配り、チェッカーが釣銭を数え、窓口の職員が保険証を確認してくれていた。

現代はそのいずれも、当事者の自己責任において情報の受け渡しを行うことが当たり前になっている。

Accessがマイナーになりつつある現代において、いつまで世に存在するかは分からないし、いつまでも存在し続けるってことはなさそうに思う。

ただ、DX化が急速に進む世の中だからこそ、日々の暮らしに何気なく存在するデータベースの仕組みについてAccessを通して学べてよかったとは思う。

ココナラの出品者から紹介いただいた資料をもとに、自身でまとめた内容をココに書き留めたいと思っている。SQL関連だけで50記事近くになりそう。

新しい分野の担当業務に右往左往している今、ブログを今年中に書き終えられるかは微妙。

私のブログなんて、世界の誰からも必要とされない、ネットの海に浮かぶゴミに過ぎないことは分かってる。

目的を果たしたら速やかに去ればいい。それまではマイペースで進めよう。

かつての自分と同じようにAccessの習得に悩み、最後の砦としてココナラを訪れた人の目に偶然ふれることができ、学習の孤独感を少しでも救えたなら、嬉しいなとは思う。

検索(AIアシスト含む)ではAccessに関する正確な情報を見つけ出せないことが珍しくない。

Accessユーザーが少なく、ネットの海から得られる情報量にも限りがあるからだろう。

たまにAIに質問しても収穫を得られないばかりか「同じ相談を受けた際に参考にしたいから、答えを教えてくれ」などと、依頼されたりもする始末。

学習や業務のアシストとして、生成AIの活用が推奨されることに異論はない。

ただ、AIを含む検索エンジンの活躍によって、真に評価されるべきはネットの海にストックされた宝の山を生み出してきた無数の先人たちの努力の結晶ではないだろうか。

私自身の学習も出品者を含む先人たちによる、人知れぬ苦労の成果が下支えとなっていることは紛れもない事実だが、生成AIを師とするケースの多くでは、真に評価されるべき人物が称えられることも、そこに想いを馳せられる機会も少ないだろう。

私だけは、忘れないようにしたい。

世の中には、たとえパソコンを一人前に使いこなせなくても、1枚の板からこつこつとモノ作りを行い、日本の産業や外交を支え続ける人々がいること。

生成AIによる作品は、無数のユーザーによって積み上げられた知識や研究、文化や技術、気が遠くなるような試行錯誤の恩恵であること。

Gemini Notebookに書き込んでみたところ、賛同してくれた様子だった。

（その模範回答も、結局は誰かのコメントの模倣でしょうけれど(σ-σ;）

顧客もエンジニアも笑顔になれるシステム開発や運用が現実になるよう願う。