DX

仕様には「一般的仕様」と「固有仕様」があり、さらに固有仕様の中には「表出的仕様」と「暗黙的仕様」があります。 　このうち特に厄介なのが暗黙的仕様です。 暗黙的仕様は文書化されておらず、現場の慣習や担当者の経験に埋め込まれているため、表に出して明文化するだけでも大きなコストと時間がかかります。 モダナイゼーションが難しいのは、単に古い技術を新しい技術に置き換えるからではありません。 「何を再現すべきか」が分からないからです。 だからこそ重要なのは、現行システムを丸ごと再現することではなく、業務の本質を見極めたうえで、何を残し、何を捨てるかを決めることです。 言い換えると、モダナイゼーションの成否は「暗黙的仕様をどれだけうまく扱えるか」に大きく左右されます。 　その延長線上にあ るもう一つの論点、すなわち現行仕様の複雑度について考えます。 続きはQiitaの投稿記事を参考願います。 https://qiita.com/ogi_kimura/items/0684f95269a381caf91d

DX推進に必要な要素として 3つの知識領域 と 3つの仕様領域 があり、とりわけ 「暗黙的仕様」（現場が言語化できていない／していない固有の仕様）をどう扱うかで、DXの進め方が大きく変わります。 進め方（案）は大きく3つあり、いずれにもメリット・デメリットがあります。 ただし現実のDX推進では、コストや期間、人員といったリソースに制約があり、理想に対して「どこかで割り切る」判断が必要になります。つまり、各案のトレードオフを踏まえて案を選定することになります。 今回は、前回の 知識×仕様（3×3）のマトリクス を、時間軸（=理解・合意形成に要する時間） も含めて捉え直し、どのように進めるのが現実的かを整理します。 続きはQiitaの投稿記事を参考願います。 https://qiita.com/ogi_kimura/items/8fe4af4b4fa1b4497315

会社として「DXを進める」と声高に言っている一方で、上層部がそれを自分事として捉えず、部下や担当者に対して叱咤だけが飛んでいる――そのような状況をよく目にします。 私自身、現場に入り込んでプロジェクトの動きを見てきましたが、うまくいかない理由は「担当者の知識不足」といった単純な話ではないと感じています。 一方、米国などではトップダウンが強く、かつ経営層がITの知識をある程度持っているケースも多いため、相対的にシステム変革が進みやすい印象があります（もちろん例外はあります）。 私はいくつものDX案件に関わる中で、「なぜうまくいかないのか」を考える機会が増えました。昔は「情シス部が先頭を切って推進しなければならない」という空気があり、弱い立場になりがちな情シス部がドメイン知識を十分に持たないままデスマーチに巻き込まれていくこともありました。事業部側はそれをどこか他人事のように見てしまう、という構図もあったように思います。 一方で現在は、「事業部こそが先頭を切って推進しなければならない」という風潮に日本全体が寄っています。しかしその結果、ITリテラシー