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/