yyyoichi blog

悲しい。悲しい。悲しい。

中小企業xDXデジタル人材のマッチングイベントは、日本の製造業の将来への悲観と私がDX人材として参加したことへの罪悪感を感じるには十分な時間でした。

本来の意味でのDXは、人材不足や供給能力に依拠した経営判断を実現するための変革のはずです。具体的な経営判断はたとえば「従業員がX年後にX人減っても生産を落とさないようにせよ」とか「急増するXX需要でもシェアを維持できるように現状資産のまま生産を最低でもX%上げよ」「新規ビジネスのための人員をX年までにX人捻出せよ」であるはずです。それに伴う変革がたとえば「受注してから生産ラインに乗せるまでの間接工数をX日にする」であり「生産ラインの効率をXX%上げてX人削減する」です。

DXに必要なものは経営者の命令であり、それを解決するアルゴリズムを組織に実装することです。

逆に言えば、DXは、現場のデータリテラシーをあげたり、データを見える化して現場に掲げてみたり、部署間のシステムを統合して巨大システムを三年かけて構築してみたり、全社の業務システムを整理して最適化しようとしたり、データに基づいたミーティングを期待したり、AIにデータ食わせて相談してみたり、紙運用をデジタルに置き換えたり、データに基づいた経営判断を行うためのものではないです。 これらのほとんど「どうでもいい」です。工場の生産能力が上がって世界シェアを維持できる生産体制と組織設計があるならバックオフィスが紙でもいいです。立派なハンコを押してください。

冒頭イベントで素晴らしかったのは、上流の皆さんが各企業の理想の姿を整理し必要なスキルまで落とし込んだ構想3ヶ月の「A4一枚」のプリントをもとに、そのスキルを持った私たち「DX人材」がその穴埋めするために、これまた同フォーマットの「A4一枚」程度の提案と経歴を書いてエントリーするという、極めてシステマチックで単純で合理的な運用フローと、各企業毎に「できるだけ多くの方と対話してほしい」という前座と「エントリーはかならず弊社経由で」という締めの言葉が十分に訓練された司会によって計5分間アナウンスされる会議が、厳格な発言ルールのもと安全に進行したことでした。

そのA4一枚から、だいたい読み取れたことはこうです。

このものづくりの国ジャパンでは、国をあげてBIダッシュボードを製造現場に提供します。 いわゆる上流のコンサルは、いまだにハンコを使っているのですよというメーカー担当者の渾身の自虐ネタを華麗にツッコミをいれてみたりして、私達が「伴走支援」しますとボケの続きを「対話」します。「データドリブン経営」という世界標準を言って聞かせ、「データを活用」すれば「DX」できますと希望で落としてみせます。 そうして「見える化」ダッシュボードが「将来的」に課題を「具体化」できるのだとして、ベンダーへ各システムや自動化スクリプトを「全体把握」して「最適化」して「一元化」したシステムを注文します。 ベンダーはシステムを全体を俯瞰して最適化したいという「中・長期目標」を具体的に要件定義して「ロードマップ化」することを迫られ、現場の声を聞いてみたり、既存システムの現状を聞いてみたりします。どんなに頑張っても答えがないので、要件定義に6ヶ月かければ検討して最善を結論したことになるのでしょうか。ここでベンダーのみなさんは「顧客が本当に必要だったもの」という名言が胸の中でチクチクしたり、「要件定義が一番難しい」というアイロニーに感動して救われたりするのでしょうか。 いざ完成した「ダッシュボード」では、毎秒微妙に変化するマテリアルデザインのキレイなグラフと、赤と黒がローテーションする96ピクセルの特大フォントの数字が描画されているのでした。この動くホワイトボードは現場とってもっと効率よく生産しろというスローガンに成り代わり、いつしか神棚に置いたほうが良いという改善案の生産を実現します。今度はもっと「小さく始める」ことで「現場のハレーション」を減らせるに違いないと「仮説」をたてて、6ヶ月かけて1日に1回"しか"更新されないダッシュボードを開発して「全社員型DX」でデータ活用の素晴らしさが隅々まで伝わるか「検証」してみたりします。あるいは「データ人材」を育成すれば業務が改善できるとPythonを勉強させたりするのでしょうか。ある人は、データとAI活用しでみんなで話し合ったら営業成績の改善施策が生まれはずだと「AI搭載BIツール」を導入してみましたが、しばらくして「CIソリューション」到来の予感に震えたりしています。

データドリブン経営？第六感？

必要なことは来る人手不足に対策することです。人手不足でも生産が維持できることです。 逆算してなにが必要か結論することです。そうしたら社内のDX担当に命令してください。

その命令が具体的に何になるのか、プログラマの私には分かりません。 もっともよく知っているのはコンサルでも社内の労働者では無く、経営者のはずです。 他の人間が半年かけて集めたデータで専門家と市場分析した結論よりも、１週間で出した経営者の判断が覆ることはないはずです。

経営者判断のための完璧なデータは世の中に存在しないはずです。 「データドリブン経営」がほんとうに正でも、他人は絶対に上手くいく経営のためのデータを提示しません。DXについては「効率化がゴール」と無邪気にごまかされるか、具体的な手段に話をすり替わってしまうのが関の山です。

最後は勘しかないはずです。 第六感が完全に悪なら人間は機械に代替可能です。

労働者はそれが暗黙知である可能性に掛けます。 テクノロジーが進歩するまでは、ある地域の人たちは豚肉を食べないほうが良かったのです。

とにかく「XXでなければ会社は潰れる」を教えてください。 単純な話ではないかもしれませんが、複雑な事情は経営者以下が知る必要ないです。 もし他人の給与を知らなければ仕事をしない従業員がいれば、それは個別的な問題があるので話を聞いてあげてください。

経営問題がないなら何も変える必要はないです。皮肉ではなく、本当に。 私はそのくらいの危機感をもって、世の中のメーカーはDXを挑んでいるものだと想像していました。私は「人手不足」のニュースに踊らされていたのでしょうか？

どうするべきなのか？

上のような原理は極論でしょう。 いくつかメーカーに対してもう少しまともな提案を添えてエントリーしました。 とても迷いましたが、何もしないでポエム書くよりはマシでしょうか。

‘私が知恵を絞って実行するのだ’という決意です。

DXの精神主義的な傾向についてのお話でした。以上。

※追記 2025-10-26T21:09 stdout で詰まっている説。 SetDefaultの前後でログを出力していて、AWS Lambdaのデフォルトのレポート出力と競合している？ デフォルトのレポート出力中に、SetDefaultがスイッチをしようとしてロック？ 解決策 「関数の起動直後のSetDefaultをしてかついる場合は、ログを極力出さない」かもです。こんなんでいいのか、という気もします。 経過見て、余力あれば追記します。

以下、発生していた問題です。

独自に slog.Handler 実装して slog.HandlerOptions.Levelを指定すると、slog.SetDefaultした瞬間に動かなくなる。

// main.go
logger := slog.New(mylog.NewJSONHandler(os.Stdout, 
    &slog.HandlerOptions{Level: slog.LevelDebug},
))
slog.SetDefault(logger) // ここで死ぬ

// mylog.go

type mylogHandler struct {
	slog.Handler
}

func NewJSONHandler(w io.Writer, opts *slog.HandlerOptions) slog.Handler {
	return &mylogHandler{Handler: slog.NewJSONHandler(w, opts)}
}

※ AWS Lambda だと動かない問題が発生して、ローカルで動かすとなんの問題もない、という不思議状態。

問題点以上。上のコードに加えて、前後でslog.Debugなどを2,3コ出力していた。 以下、誤った解決策。

一応、下で解決した。

logger := slog.New(mylog.NewJSONHandler(os.Stdout, nil))
slog.SetDefault(logger)
slog.SetLogLoggerLevel(slog.LevelDebug)

// いける
// slog.HandlerOptions で渡さずに、 slog.SetLogLoggerLevel で指定する。

内部でデッドロックしているかもで、関連するISSUEもあるよう。 原因は正直不明で、気が向いたら調査します。 わからん。

ブログを始めました。目的は、これまでQiitaやnote、はてなブログに書いたものを集約することと、作ったものを紹介する記事を書くため。

フルリモートでエンジニアをやっています。

好きな言語はGo。

自己紹介は、こちらから。https://blob.yyyoichi.com/page/about/