【メタエンジニアの戯言】古くて新しい、小さく大きな DX

2023.09.05松林弘治の連載コラム

もう30年以上前のことですが、大学入学直後に学科からブックレットが配布されました。数年前、32ページからなるそのブックレットを  たまたま発掘し、懐かしく読んだことがあります。

高校生から大学生へと立場が変化したタイミングにあわせ、学び方や心構えの変化を促す文章が多かったのですが、私が所属していたのは情報工学科でしたので、情報工学（コンピュータ科学）を学び始めることについて、当時の先生方や先輩方からのアドバイスがたくさん載っていました。

当時18歳の私が、どう思いながらこのブックレットを読んだのか、残念ながらその頃の心持ちは覚えていないのですが、改めていま読み返してみると、示唆に富むことが非常に多く書かれていることに驚き、同時に「重要なことって、いつの時代にも共通しているものなんだなぁ」と感じ入りました。

例えば、「コンピュータとつき合うときの心がけ」という節に、このようなくだりがあります。

「『このコンピュータ、どこかおかしいのとちがうか！』と言わなくなれば入門級を卒業」→「おかしいのは自分である」
「コンピュータは intelligence mirror（自分の頭の中をうつす鏡）である」

こんな箇所もあります。

「プログラミングしないことを学ぶ！」
「自分の仕事のうち、何をコンピュータにやってもらうかを考える」
「コンピュータを使うこと自体に意義があるのではなく、使って意義のあることに使ってこそ意義がある」

 

1989年当時、情報工学科に進学してきた新入生の中には、小中学生の頃からすでに8ビットマイコン等でBASICや機械語プログラミングに親しんできた学生もいたでしょう（私もその1人でした）し、そうでない同級生も多くいたでしょう。そんな新入生に向けて書かれた文章です。

それにしても、ここに書かれていることは全て、今となってはしみじみと深く本質的な意味を読み取れます。そして、どれひとつとってみても、21世紀の今もそのまま通じる箴言のように感じられます。教育文脈でも、エンジニア文脈でも、コンピュータ技術を活用するビジネス文脈でも、その他でも。

無理やり要約すると、小手先のテクニックやTIPSではなく、本質的・体系的な理解が重要であること。学び方を学ぶこと、そして、手段と目的の区別を認識すること。そんなところでしょうか。

 

—-

私事ですが、先日より新しい技術アドバイザリ的業務がスタートしました。某非技術系企業において、現状の業務がどのように行われているかの分析をサポートし、現在使われているソフトウェアやツールを精査し、どのように効率化し業務変革できるか、手元にある（はずの）データをどのように活用できるか、現場スタッフのお困りごと相談、など、ひらたくいうと巷で「DX」と呼ばれるような分野です。

データのインポート/エクスポートも満足にできないERPソフトの癖に振り回され、大変な目視確認と手入力に日々追われるスタッフの方々（本当にご苦労様です）からのヒアリングであったり。紙ベース、ときにはFAX（！）ベースで組まれてしまった業務フローに悩まされ、どこから自動化・効率化していいのか皆目見当がつかない、と悩まれている社内の方々（お疲れ様です。。。）からの相談であったり。もちろん、会社の中長期的なプランの見通しや、経営サイドが現在課題と感じている問題についても同時に伺ったりしながら、総合的に考え提案し実践のお手伝いをする、そんなとても楽しい（笑）共同作業です。

当然ながら、既存のソフトウェアを改修すれば万事解決するわけでもなく、新しいソフトウェアにリプレースすれば効率化されるわけでもありません。IT/ICTリテラシーを改善すればそれで終わりでもありませんし、ローコード・ノーコードを導入するだけでいい、なんてこともありません。

全てはバランスと関係性の把握であり、目的・目標を見据えた上での手段や価値判断の適切な選択の連続であり、各業務に従事される方々の体験価値を向上させる取り組みです。「DX推進」「AI活用」といったキャッチーな錦の御旗に振り回されることなく、時には目的そのものにも切り込み、森も木も見ながらの作業です。

—-

さて、前半の話（大学入学時に配布されたパンフレット）と、後半の話（技術アドバイザリ業務）に、なんの関連があるのか、と思われたかもしれません（笑）が、私の中では大いに関連しているのです。

業務を分析・理解し、テクノロジの利点や得意分野を理解した上で、そのテクノロジを最大限活用して業務を改善したり、業務そのものを変革していく。これを「DX」と呼ばれるジャーゴンの定義のひとつだとすると、やはり付け焼き刃的対応ではなく、領域横断した包括的・体系的な知見と深い理解、未知の領域の学び方などを備えた上で取り組まないと前に進めないのです。

また、冒頭で紹介した「プログラミングしないことを学ぶ」、これと全く同様に、「わざわざシステムを新規導入したり改修せずとも、ちょっとした工夫であったり、少しの業務フロー改良だけで、かなり楽になる」というケースに、先日まさに直面したのですが（笑）、小さなカイゼンの継続的な積み重ねが、やがて大きな業務改善につなげられる可能性が高まります。

一方で、つい先日まで一緒に仕事をしていた友人が  DXに関する連載記事で書いているように、経営陣から現場従業員への丸投げとならないよう、全体でのビジョン再認識と共有が不可欠であるのは言うまでもありません。

—-

あぁ、システムを作りたい、コードを書きたい、と思ってしまうエンジニアとしての自分もいますが（笑）、あくまでそれは手段のひとつに過ぎず、本質的な解決のためにはあらゆる可能性を念頭に、スモールステップで、かつ時には大胆に変革を起こしていかねば、そして皆さんが少しでも笑って楽しく業務に取り組めるようお手伝いしていければ、と改めて思った、もろもろのエピソードでした。

【他社事例から学ぶ】自社のDX推進を成功に導くために