DX DXは一過性のプロジェクトじゃない!継続的なマネジメント活動 「DXプロジェクト」と言うが、プロジェクトは一過性の活動で終わりが来る。しかし、DXの求める「変革」はそのような一過性の活動では成し得ないもの。デジタルを導入したら変革が完了するわけではなく、継続的なマネジメント活動であり、PDCAサイクルを回す必要がある。 2024.09.08 DX
ソフトウェア 変化に適応する!システム機能分解の妙 システムの機能をどのように分解すればよいかという点について、これといった正解や法則が見当たらず悩ましい。ひとつの視点として、適切に機能分解されていると変更に対して全体を改造しなくても「組合せ」を変えるだけで容易に対応が可能となる。 2024.08.31 ソフトウェア
DX 本気で変革するなら、市民開発にも統制を! ノーコードでアプリを誰もが開発するという「市民開発」が認知され、DXでも有効とされている。しかし、各部署の市民が思い思いに自由にアプリを開発しては困ったことになることがある。社内の各プロセスを統制するプロセスオーナーがしっかりと身を寄せ本腰を入れた「市民開発」をしてもらいたいもの。 2024.08.25 DX
DX 「苦肉の策」としての「ゆるふわなアジャイル外注」 アジャイル開発を外注する場合に請負契約では難しい面があるとして、準委任契約を前提とした情報システム・モデル取引・契約書(アジャイル開発版)がある。しかし、準委任契約は完成時期が不透明だ。そこで「苦肉の策」(折衷案)としての「ゆるふわなアジャイル外注」がある。 2024.08.17 DXプロジェクト管理
DX システム再構築の落とし穴ー正攻法だけでは勝てない! システム再構築では業務分析・要件定義から進めるトップダウン・アプローチだけでは思わぬ落とし穴におちることがある。現行システムを開発した当時のシステム担当者や業務担当者が居なくなっているから、ソースコードを解読して業務要件を把握するボトムアップ・アプローチも必要。 2024.08.03 DXレガシシステム
DX 生成AIと協業する未来 生成AIのアウトプットを意図したものにするためには、何がして欲しいのか、その前提条件は何か、目的は何かなどを明確に伝える必要がある。また、生成されたアウトプットが意図したものであるかどうかを評価できなければならない。特に重要なのはファクト(事実関係)を確認することだ。 2024.07.27 DX
DX DX銘柄の歩き方~レポートの情報を自社に持ち帰る時の注意事項 経済産業省が選定、発表している「DX銘柄」の取り組み事例を紹介するレポートを読んで、その情報を自社に持ち帰る時の注意事項。レポートの内容は成功事例が理路整然と描かれており、泥臭い内情などは書かれていない。レポートの「美しい」内容だけを鵜呑みにして自社に持ち帰るのは危険だ。 2024.07.21 DX
DX 2025年の崖:業務とシステム連携の隙 個別分散のレガシシステムは統合化されたERPのようにリアルタイム連携ができず、関連データの一貫性・整合性の保証が難しく業務との間に隙が発生する。そのためDXや第四次産業革命における業務変革の足枷となる恐れがあり、2025年の崖の一因とされている。 2024.07.14 DXレガシシステム
孫子 用意周到の上でやるときはやる!「風林火山」 諸般の事情を知らずして契約ごとは危険ですし、現地の状況を知らずして進むことはできません。現場の声を無視して、まともな改善はできません。戦略を以って、利益を重視して行動し、分散したり統合したりして柔軟に変化すること。風林火山のごとく、やるときには素早くやる。 2024.07.07 孫子
DX “見せかけ”のFit To Standard 2025年の崖はすぐそこ。DX推進のため基幹システムを短期間に更新する「FitToStandard(FTS)」という考え方がある。FTSでは業務パッケージの標準機能に合わせて業務を行う。ところが現場の抵抗に合い、周辺システム側を作り込むという"見せかけ"のFit To Standardが横行する。 2024.07.07 DX雑記帳