成功するデジタル化のためには、あなたの人々に焦点を当ててください

著者: Marcus Bole

デジタル化という言葉は、2017年に私に紹介されました。情報技術(IT)の利用や技術を使用した顧客とのやり取りに直接的な影響を与えたとは言えませんが、おそらくソフトウェアの販売とマーケティングの経験が含まれます。イギリスでは、私の世代は1980年代中盤のコンピュータリテラシープロジェクトを通じてコンピュータに触れ、BBC Microのサポートを受けました。プログラミングを学び、エンジニアリングドローイングとヨットデザインの愛情から、初期の3D CADや初期サイジングルーチンのアイデアを追求しました。これは、10代の若者ができるだけ多くの本や論文を消化する過程でした。

私の職業生涯はここから成長し、エンジニアリングプロジェクトまたはソフトウェアソリューションの提供に焦点を当てていたかどうかにかかわらず、ITテクノロジーを使用して成果を向上させる機会は私にとって重要でした。新しいテクノロジーやツールを仕事に取り入れることは常に進化するプロセスであり、デジタル化やデジタルトランスフォーメーションといった用語の登場がそれを変えることはありませんでした。これらの言葉に対する私の皮肉な見方は、他の人々が使っている同じトロープやクリシェで私が提示する提案や解決策が汚染されるのを避けるためでした。このデジタル化の見方は私が誇りに思っていたものではなく、明らかに見落としている何かがあるのではないかと感じていました。2022年にCadmatic Information Managementチームに参加したことで、情報管理がデジタル化の中心にあるため、より深く調査する動機が生まれました。私は何かに呼び出される前に、この皮肉な見方を変える必要があると感じました!

デジタル化やデジタルトランスフォーメーションという用語は、以前はIndustry 4.0やそれに先行するものと同様に、高度なソフトウェアマーケティングのための統一された標語となっています。これらの言葉自体は、概念や変化の期待を十分に捉えていません。理解を得るためには説明が必要であり、巧妙に作られたメッセージと熟練したセールス担当者が、変革的で先見的なソリューションを売るために調整された学習を提供できます。しかし、現在のビジネスプロセスと実践の現実はまだ露呈されていません。言い換えれば、「最初の敵との接触で計画は生き残らない」と言う言葉通りです。成功したプロジェクトはソーシャルメディアで広く取り上げられ、失敗したプロジェクトは抑制されてしまい、価値ある学びを得る機会がなくなります。デジタル化は、深い学びにアクセスするために営業とマーケティングのプロセスに非常に結びついてしまい、チーム、部門、またはビジネスを成功裏に変革する方法を理解することが難しくなっています。

業界調査(McKinsey、Forbes、Grubenmann、[Ref1]で言及)によれば、完全に成功したデジタルトランスフォーメーションプロジェクトの割合は低い一桁のパーセンテージであることに驚かれるでしょうか? 部分的に成功したプロジェクトははるかに多く、この成功率の低さはデジタル化がどれほど推進されているかと比較してかなり驚くものです。これらの調査では、成功の欠如の理由としてデジタルスキルの不足、一般的な文化の問題、デジタル化を改善の投資ではなくコスト削減の対象としていることが挙げられています。Mik Kerstenの著書である「Project to Product: How Value Stream Networks Will Transform IT and Business: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework」は、これらの課題に対する洞察を提供し、ビジネスがあらゆる規模でアジャイルなアプローチを受け入れ、これをソフトウェア開発や電子産業から採用し、ビジネス開発、顧客サポート

、物流、人事などの伝統的な機能と統合し、適応しています。Mik Kerstenの本はコンサルタントを売るための手段として止まっており、提案されたツールであるValue Stream Mappingを使用するための十分な学習を提供していません。実際、さらに調査すると、Value Streamは1950年代の製造改善プロセスに起源を持っています。ご覧の通り、成功したデジタル化のベストプラクティスは、過去の世紀にわたる産業とビジネスの改善イニシアティブの基盤に見出されます。

ソフトウェア開発と船の設計プロジェクトの類似点は常に私を興味づけてきました。ソフトウェア開発は実質的にゼロの製造プロセスを持っている一方で、両方とも人々、しばしばチームが関与し、課題の研究と一意の複雑な相互依存システムおよび解決策の作成が含まれます。効率的にデリバリーするためにチームを組織することは芸術の一環です。アジャイルプラクティスは過去二十年間のソフトウェア開発業界の最大の変化の一つです。アジャイルベストプラクティスはDevOps(Development-Operations)として規定されています。デジタル化と同様に、ほとんどのソフトウェア開発者はDevOpsを自動テストなどのツールの導入として理解しています。しかし、DevOpsの起源にさかのぼると、最初の焦点は人々とチームのベストプラクティスにあります。DevOpsはLEANおよびその相当するものであるトヨタ生産方式(TPS)に基づいており、問題解決とソフトウェアプロセスに適応しています。TPSの使命は、顧客が必要とし、支払いたい物質やリソース以外のものを排除することでしたが、DevOpsはこれを人々中心の焦点として「日々の仕事の苦労と退屈を減少させ、組織の目標を達成するために継続的な学習を通じて」という使命で再構築しています。これはエンジニアリングや他の多くの分野にも適用可能な使命です。デジタル化とIndustry 4.0では、製造の時代とソフトウェアの時代が明確に異なる二つの技術時代とされています。しかし、DevOpsの基盤は明らかにLEANおよび製造のベストプラクティスから進化しています。船舶建造では、LEANプラクティスは、例えばブロック構築戦略、プリアウトフィッティング、生産の外部委託、パネルラインなどの使用で見られます。LEANは通常、反復、再利用、自動化の最適化を通じてコストを最小化する大量生産と関連付けられています。しかし、船の建造の多くはLEANプロセスの非典型的な部分である独自の部品の製造を含みます。伝統的に、これは繰り返し可能で適応可能な製造プロセスを通じた最適化を提供してきました。ソフトウェア開発もまた、各開発課題が通常ユニークであるため、繰り返し可能な出力が不足しています。実際、DevOpsは小規模バッチ生産の最適化概念を導入しており、これは船の設計にも同様に適用可能かもしれません。

私にとって最も驚くべきことは、リーンについて読んでいることでした。大学卒業後、リーンとトヨタ生産方式について熟知していたにもかかわらず、私はこれまでに一度も興味を示す組織で働いたことがありませんでした。それは私にとって常識的な良い慣習のように思えましたが、小規模な組織では上司があまり興味を示さず、大規模な企業では私の上司が私と同じくらい影響力を持っていないことが明らかでした。私が関与したビジネストランスフォーメーションは常にトップからリードされ、それらの取り組みは最初に効果的であったものの、18か月から2年後には「古いやり方」に戻る傾向がありました。リーンが導入されてから数十年が経過していることを考えると、これにはより深い理由についての議論があるべきです。Google検索でMartial Durin(シンゲオ・シンゴの弟子)の記事[Ref4]にたどり着き、企業がリーンを実装できない理由について論じているのに気づきました。リーンの失敗の理由は、デジタイゼーションの失敗の理由と同じであるとされています - ビジョンの欠如、時間、リソース、従業員の遵守の不足です。
シンゲオ・シンゴは、成功するリーンの実装では成功の30-40%がツールの成功から来るべきであり、60-70%は人々の成功から来るべきだと述べています。デジタイゼーションでは、デジタルツールに焦点を当てているため、成功が限定されていることは驚くべきことではないかもしれません。現代のビジネスリーダーは短期から中期のリターンを期待していますが、シンゲオ・シンゴによれば、リーン変革のためには文化の変化を達成するには5-10年かかるとのことです。従業員が過去数十年で不当に評価され、一部のプロセスを自動化できる機会が存在する現代のビジネス環境では、単純化された変革の取り組みによる痛みの失敗の可能性が示唆されています。
リーンとDevOpsの両方が成功した導入のためのロードマップを提供しています。ソフトウェア業界でのアジャイルプロセスとDevOpsの成功は、大きな改善が可能であることを示しています。これは開発コミュニティによって推進された変化であり、管理から強制されたものではありません。ソフトウェアエンジニアリングには退屈な作業が多くあります。自動化を使用しても、製品のテストやコードベースの品質を維持することは、しばしば退屈なプロセスが必要です。サポートされた作業環境のチームは頻繁に、退屈でエラープローンなタスクを排除する機会について話し合います。これは、継続的な学習を通じてリーンの実践を自然に受け入れるポジティブな文化の本質です。適切な条件が整えば、これはソフトウェア開発やエンジニアリングに焦点を当てたクリエイティブな環境で起こります。

デボプスハンドブックの提案されたロードマップは、作業グループの形成から始まり、変革の可能性を学び、変化を肯定的な進化としてサポートするための合意形成を築くことを目指しています。チーム全体の完全なサポートがあれば、変化は持続可能な方法で実現されるでしょう。リーンと同様に、デボプスの変革は2〜3年の期間の長期投資が推奨されています。変更は一度にすべてではなく、価値の流れとシステムをモニタリングして期待される改善を確認し、望ましくない結果が経験された場合には決定を取り消すために段階的に計画されるべきです。これは実質的に、産業4.0の本質を反映しており、製造オートメーションではなく人々に適用され、1924年にベル研究所でWalter Shewhartによって考案された最初の品質管理プロセス、Plan-Do-Check-Actに基づいています。実際には、デジタリゼーション、リーン、トヨタ生産方式、アジャイル、デボプス、5つの"S"、およびシックスシグマは、ビジネスプロセスの優れた実践の世紀に基づいて構築されています。

過去20年間、私は顧客に船舶設計および製造ソフトウェアを提供しているさまざまな組織のメンバーでした。この重要なツールセットを変更することは容易ではなく、車両組み立てラインのツールを変更するのと同様です。良い時期はありませんし、初期のトレーニングの深さと範囲を判断するのは難しく、最も論理的な変更の時期であるプロジェクト間の期間が頻繁に急がせるプロセスを進める方向に向かいます。私が最も成功したのは、最初に知識の移転をサポートできる選択された主要ユーザーグループに焦点を当てたときでした。つまり、変更は内部から起こっています。結果は偶然よりもデザインよりも多かったですが、これは変更の影響を受けるチームメンバーが新しいソフトウェアをどのように学び、採用すべきかを考えることが重要であることを示しています。リーンまたはデボプスの実践の理解は、魅力的な実装プログラムを設計するのに役立つ情報を提供できます。ただし、これは堅い枠組みとして扱われるべきではありません。継続的な学習プロセスが効果的に機能するためには、先行経験と良い実践の立場から始め、進化する状況から学び、チームメンバーとアイデアをテストし、情報が明らかになるにつれてアプローチを適応させることが不可欠です。

造船生産CAD/CAMシステムの採用では、私が取り組んだほとんどの顧客は、「そのまま使える」設定のソフトウェアを採用したいという希望を持っていました。つまり、ソフトウェアのカスタマイズを限定したものであり、予測できないコストを避けるためのものでした。このアプローチは、トレーニングと知識移転プログラムに不当なプレッシャーをかけ、トレーニングを受けた人々が新しいシステムを現行のプロセスにどのように適用

するかを理解するだろうという仮定に基づいています。造船の実践の多くは共通していますが、技術的な知識の移転だけで実装が失敗するリスクを重く見るのは単純な考えかもしれません。さらに、造船所のチームは、ソフトウェアシステムの能力を現行の実践に適用し、プロセスへの変更を公式に提案するためのミニプロジェクトに参加する必要があります。これらのプロジェクトは、以前の実装からの経験を持つソフトウェアベンダーのドメインエキスパートによってファシリテートされると最適です。さらに、デボプスの実践によれば、プロセスと実践の変更は価値の流れでボトルネックを移動させる可能性があると警告しています。変更を1回ずつ対象にすることが推奨されていますが、即座のビジネスとプロジェクトの要求のために、重要なソフトウェアシステムの変更をこのように制御された方法で提供することはほとんどありません。そのため、以前は成熟し頑健と考えられていた予測できない領域にボトルネックが移動する可能性に十分に注意する必要があります。最も重要なのは常に製造プロセスです。

予測できない問題がプロジェクトの納期に直接影響を与える可能性がありますが、変更へのチームメンバーのサポートが揺れる影響は、失敗したデジタルトランスフォーメーションプロジェクトの数が示すように、はるかに破壊的である可能性があります。変更を強制したり、さらには強制したりするのではなく、チームが学習を通じてデジタルトランスフォーメーションを受け入れ、既存の実践を新しいツールの能力に調整し、成果をテストすることに焦点を当てたテクノロジーの採用戦略は、成功を計画することに関係しています。技術の進化が組織が適応する速さよりも遥かに速くなったことから、単に対処するのではなく、優れた戦略を見つけることがビジネスの持続可能性に不可欠です。半世紀以上経った今もなお、リーンの実践は今日でも重要であり、ビジネス変革プロジェクトに使用される用語に関係なく、成功したデジタルトランスフォーメーションの最前線に人々を配置するための重要な示唆を提供するかもしれません。

参考文献:

[Ref1] System Lifecycle Management: Engineering Digitalization (Engineering 4.0), Martin Eigner, Springer Books, 2021.

[Ref2] Project to Product: How Value Stream Networks Will Transform IT and Business: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework, Mik Kersten, IT Revolution, 2019.

[Ref3] The Devops Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations, Gene Kim, Jez Humble, Patrick Debois, John Willis, Nicole Forsgren, 2nd Edition, IT Revolution, 2022.

[Ref4] Why are most companies failing with Lean implementation?, Martial Durin, Managing Director, Kaizen Institute China. https://kaizen.com/insights/why-are-most-companies-failing-with-lean-implementation/