TOP
クラウド
DXカオスから抜け出すならIT方言とはお別れしたい～「上流」や「業務」って何？～

2022/05/24

DXカオスから抜け出すならIT方言とはお別れしたい～「上流」や「業務」って何？～

今回のタイトルは、過去に筆者が年次のアクションプランを社内プレゼンした時に、「やらない事」の一つとして「IT方言ではなくビジネス用語を使う」と宣言したことがあったことから命名しました。

※「やらない事」とは、ムダな戦いを省略する「戦略」の一要素であります。

この「IT方言」というパワーワードは、以前の記事で紹介した戦コン（戦略系コンサルティングファームのコンサルタント）から教えていただいたものです。

過去職の当時、IT部門に在籍していた筆者は、月次の役員レビューのたびに「君たちの専門用語ではなく一般用語・ビジネス用語に言い換えて説明できるようになりなさい」と口を酸っぱくして叱られ続けていたこともあり、以降のビジネスキャリアにおける大事な教訓の一つとなりました。

※言い換えや比喩表現は、円滑な言語コミュニケーションにすごく役立ちます！（実感）

拡大する一方のDXカオスという渦の中で、もがき苦しむ状況から抜け出すための一助となれば、これに勝る喜びはございません。

以下、名曲の「川の流れのように」でもBGMに流しながら、「上流」というIT方言がいかにタコツボ化・サイロ化の進むレガシーIT村を表すものなのか、しみじみと思いめぐらせていただければ幸いです。

そもそも「IT方言」ってどんな方言？
グローバル発想ができる「デジタル人材」なら英語センスも高めたい
- 言語コミュニケーションのキモは文脈：コンテキストの共有？

そもそも「IT方言」ってどんな方言？

肝心な「IT方言」については出典が見当たりませんので、ひとまず「方言」について聞いてみましょう。

方言 - Wikipedia

方言（ほうげん、英: accent, dialect[3]）は、ある言語が地域によって別々な発達をし、音韻・文法・語彙などの上で相違のあるいくつかの言語圏に分かれた、と見なされたときの、それぞれの地域の言語体系のこと[4]。ある地域での（他の地域とは異なった面をもつ）言語体系のこと。地域方言とも言い、普通、「方言」は地域方言を指す。一方、同一地域内にあっても、社会階層や民族の違いなどによって言語体系が異なる場合は社会方言と言う[5]。

ということは、IT業界というくくりで方言を定義するなら「社会方言」の一つであり、かつて筆者が叱られたように一般事業会社の経営層には通じないという特性から考えれば、経済界における下流階層の方言となるのでしょうか。

IT方言がもしそんな定義になるなら、下流なのに「上流（工程）」というジレンマが生じる点はひとまずスルーしておきましょう。

以前の記事で戦コンが教えてくれたIT方言は「業務」でしたね。

「何でもかんでも“業務”と一括りにするからエッジが立たないんです。プロセスなのかタスクなのかワークなのか、カタカナでよいので英語に翻訳してからさらに日本語にしてみれば、自ずとシャープで具体的な対象物がイメージできるようになるはずですから、ぜひ覚えておいてください。」

実は、戦コンから賜ったこのお言葉には続きがありまして、

「ただ、IT業界の方々ってつくづく英語センスのない方が多いようですから、プロセスとタスクとワークという語彙が理解できていないと、対象物を具体化すること自体ができないのかもしれません。」

という身もふたもない話で締められたのでした。

ちなみに、筆者の職務に「IT方言ではなくビジネス用語を使う」というレギュレーションを設定した結果、変化が生じた公開情報がこちらです。

Excel定型業務をITで自動化　実現のポイントを事例で学ぶセミナー

というセミナータイトルは

Excel定型作業の機械化・自動化セミナー

としたように、IT方言の“業務”は一般用語の“ワーク：作業”に変わりました。（そもそもExcelは“IT”ですし。）

その発端は、

Excelを開発・販売する会社以外に、“Excel業務”なんてものがあるのか？

という違和感が生じたことがまずあり、

営業事務や経理・人事といった職務：ロールの中に、Excelを使った集計・更新作業があるだけなんじゃないか？

ということで、戦コンが指摘したように「対象範囲をごまかしたかのようなIT方言：“業務”」という単語をタイトルや関連コンテンツからバッサリ外したのでした。

これ以外にも、IT方言を使ってしまう人材もしくは組織を見極めるポイントを2つほどご紹介しておきましょう。

一つ目は、当記事をご覧いただいている方なら、きっとご覧になったことがあるはずの、IT村独特の表記例です。

サーバ
ユーザ
メンバ

英単語の最後にある“er”の長音：伸ばし棒「ー」をトルツメ：省略するという謎文法(?)。

※JISではいまだに認められている

※「エンジニアあるある」的な言及もありますが、少なくともエンジニアリングの本丸では目にしたことはなし

でも、このような謎文法？を使う方々も、それぞれ口頭なら

サーバー
ユーザー
メンバー

と、明らかにジョン万次郎英語で長音記号を発音しているのにもかかわらずですから、なおさら不思議に感じてしまうのは筆者だけでしょうか。

日本で義務教育を受けている方なら違和感を持たないことが不思議なぐらい、筆者らが暮らすIT村（下の図では左端）ではよく見る表記です。

【再掲】わりと知らないIT産業マップ

ド真ん中に鎮座するインターネット（デジタル）業界ではまず目にすることができませんが、右端の通信業界になると会話の中で「エヌテーテー」や「ケーデーデーアイ」」が登場するように、カタカナよりは平仮名が似合いそうな、ホントの方言っぽい「ICT方言」があるあたりは興味深いところです。

IT業界で、このような謎文法がはじまったのはIT黎明期にさかのぼるメインフレームの時代ではないかと筆者は考えます。

コンピューターの記憶容量が限りなく小さかった時代ですから、1バイトでもプログラムを小さくしたい、ムダなデータは極力削りたいという同調圧力が働いていた中での習慣が、なぜか現代にまで、世代を超えて伝承されながら生き残ってしまったのではないかと見ています。

ついでにもう一つの謎、これは細かすぎて伝わらないかもしれませんが、「半角ｶﾀｶﾅ」です。

やはりこれも、メインフレーム時代にプログラムソースを連続帳票（略してレンチョウ）に印刷してレビューしていた頃に、少しでも紙の枚数を減らそうとする涙ぐましい努力の名残と思われます。

さすがに文字化けしやすかったメールで使う方はほとんど見受けられなくなり、最近では顔文字をはじめとするネットスラング、ギャル文字ぐらいでしか見かけなくなりました。

例）ｷﾀ━━━━(゜∀゜)━━━━ッ!!

ところがレガシーIT人材（注：Windowsユーザーなのに［F8］キーを知らない場合あり）の中には、いまだにワープロや表計算ドキュメント、RDBのテーブル名などの中にこっそり紛れ込ませている方が散見されますので、肩身の狭い場所に追いやられた「半角ｶﾀｶﾅ」を目にするたびに、涙があふれそうになるのは筆者だけではないはずです。

以前の記事で、「インターネット・テクノロジーを使いこなせているか」というインターネット・リテラシーの概念を紹介しました。

さらにデジタル人材に求められているのは、30年前の、今では価値のなくなった習慣を、何も考えずにただ惰性で踏襲している場合ではなく、「デジタルを自らのビジネスに適用できるか」という上位のレイヤーがあるはずですから、少なくとも経営層をはじめとするビジネス人材に通じる言葉や文字表記で、ロジックとパッションをミックスさせながらコミュニケーションできるようになりたいものです。

「上流」って川の流れなの？それともプロレタリア闘争なの？

筆者がIT方言の一つと勝手に認定している表現に「上流（工程）」があります。

そんな方言に常々違和感を抱いていた筆者が、本記事を投稿するきっかけとなったのがこちらのニュース記事であります。

三菱商事・NTT連合がDXコンサルで最強アクセンチュアに挑戦状

　業界には、戦略立案、データ分析、システム開発・導入、保守・運用といった、上流から下流に至るバリューチェーンが存在する。例えば米ボストンコンサルティンググループや米マッキンゼー・アンド・カンパニーといった外資系コンサルティングファームは最上流の戦略立案、NECや富士通などのSIerはシステム開発・導入といった中流域をそれぞれ得意とし、顧客のDX支援において明確なすみ分けがあった。

～中略～

　その情勢下で巨大化しているのがアクセンチュアだ。一気通貫型のDX支援を得意とし、パッケージ化されたソリューションを大量生産・販売する。3月、富士通が3000人規模のリストラを公表したのは、「上流から下流へ利益の源泉を移したアクセンチュアに案件を奪われた影響だ」（冒頭のSIer幹部）とみられている。

この記事を書かれた記者さんは、全国紙の支局・社会部～ビジネス誌というご経歴のようですから、DXもコンサルティング業界も、さらにはIT業界さえもご専門でないことは致し方ないと思います。

ところが、戦略系のBCGやマッキンゼーを他の会計系と同様に「外資系」とくくってしまったことで、後になって名前の出るアクセンチュアは「内資・日系なのか？」という突っ込みどころを露呈させてしまったあたりは、歴史あるビジネス誌とは言え校閲の限界を感じたのでした。

特に、アクセンチュアについては前身の旧アンダーセン・コンサルティング時代のOBたち（略してAC軍団）と交流のある筆者からすると、本体が会計事務所にあるまじき不祥事を起こして解体されて以降、優秀かつ有能だったコンサルタントが大量流出してからは「世界最大のITコンサルティングファーム」という打ち出し方をされてましたから、この記者さんが言うところの「上流」すなわちビジネス戦略レベルは捨てて、「下流」すなわちIT領域に注力されているものと記憶しておりました。

さらにこの記事では、言うに事欠いて「DXコンサルティング」のように「DXカオス」を助長してしまっているあたりは、記者さん自らがカオスの渦に巻き込まれてしまっている姿が垣間見えてしまいます。

そしていよいよ、「上流から下流に至るバリューチェーン」という、パッと見ではそれらしく見えてしまう謎表現については、この記者さんが専門とされている（はずの）一般産業界でバブル前にあった「川上から川下へ」という事業ドメイン拡張（その多くは手を広げ過ぎて失敗）の話と、サプライチェーンというビジネスプロセスの話とが、ものの見事にごっちゃになってしまったのであろうと推測します。

【再掲】ビジネスプロセス：顧客中心経営を具現化する3CとLTVの関係

この図は、先述した戦コンとご一緒したのが人材管理関連のプロジェクトだったことから、IT化要件に踏み込む前段階で、自社のコア・コンピテンスを明らかにし、そもそもの人材戦略を明文化するフェーズで示していただいたビジネスプロセスを改変したものです。

市場から評価される自社の価値：儲けの源泉は何であるか、さらに継続的な事業成長を果たすためにはプロセスのどこにどんなKSA（Knowledge、Skill、Attitude）を持った人材が必要なのか、プロジェクト関与者が視座を高く持って俯瞰でき、議論が紛糾・頓挫した時にも、原点に立ち返ることができるようにしたわけですね。

DX：デジタルトランスフォーメーションが、事業戦略や成長戦略という上位にあるはずの目的・目標をすっ飛ばして、クラウドシフトやAI導入、よりによってERP再構築なども含めてしまったことでDXカオスになってしまっている組織では、ぜひ見直しの際に参考にしていただきたいグローバルスタンダードなフレームワークの一つと言っても過言ではないでしょう。

本来のビジネスコンサルティングもITプロジェクトも、時系列で先行工程や後工程があるだけで、情緒的に誤解されやすい上流も下流もないと思うのですがいかがでしょう？

「上流」のようなIT方言が流通してしまった背景を推測すると、IT業界で問題視されがちな多重下請け構造の構成メンバーになってしまっている一部のベンダーさんが、単価の高いコンサルタントやPMを見積もりにねじ込むためだけに、あるいは単価の差額にさも付加価値があるかのように見せかけるためだけに、かつて日本が「1億総中流」と言われた時代を知っているオジサンたちの手によって、「上流」という耳障りのいいコトバがお化粧に使われていると捉えるのは、うがったものの見方でしょうか。

それとも、IT方言が指す「上流」とは本来の上流階級を表すのであって、庶民は決して名乗ってはいけないものであり、「プロレタリア闘争でもやっていろ」という意図が含まれているのであれば、そのご指摘は謹んで甘受いたします。

セレブリティーのように、日本で「成金」のようなものと誤解されて広まってしまった英語しかり、「その上流ってコトバ、使い方おかしくない？」と感じていただける方が、筆者以外にもいらっしゃることを願ってやみません。

せめて、「upper stream」のことなのか「upper classes」のことなのかぐらいは、ハッキリさせていただきたいところです。※多分前者なんだとは思いつつ

少なくとも、下記のようにレイヤーの違う仕事を「ワン・ストップ」で外注してしまうような失敗プロジェクトが繰り返されないことを祈るばかりです。例えるなら、それなりの規模の建造物を建てる時に、設計事務所と建設会社の契約を一本にまとめるようなことはしませんもんね。

なぜコンサル業界のSIer化が進むのか、SIerが抱えるジレンマとは？

　クライアント企業としても、依頼した戦略や業務の領域におけるプロジェクトが絵に描いた餅に終わらないよう、そのままITの実装や実行まで一気通貫で支援してくれた方が安心です。コンサルが最後まで面倒を見てくれるのであれば、ありがたいとすら思います。

IT方言の古典「業務」をビジネスプロセスの中で具体化してみる

先行工程や後工程などビジネスプロセスの話が出たついでに、IT方言の中でも圧倒的な登場頻度を誇る「業務」についてハッキリさせておきましょう。

以前の記事で紹介した戦コンから賜ったお言葉を再掲します。

「何でもかんでも“業務”と一括りにするからエッジが立たないんです。プロセスなのかタスクなのかワークなのか、カタカナでよいので英語に翻訳してからさらに日本語にしてみれば、自ずとシャープで具体的な対象物がイメージできるようになるはずですから、ぜひ覚えておいてください。」

IT方言の古典でありラスボスでもあろう「業務」について、具体的にイメージしていただけるよう図にしてみました。

IT方言の古典「業務」をビジネスプロセスの中で具体化してみる

ビジネスプロセスが「工程」であるならば、先行工程や後工程などはあるにしても、上流が細くて急で、下流が広くて緩やかなものではないことが、なんとなくイメージしていただけるのではないでしょうか？

このビジネスプロセスが、先に掲載した3Cの図のように事業全般を表す場合、「調査・企画」という役割を持った人材のタスクやワークは、以下のような構成になるでしょうか。

ロール：調査・企画
タスク：〇〇年〇月・半期定点リサーチ
ワーク：調査企画書作成、結果集計、レポート作成・討議

冒頭に掲載した筆者の担当職務における戦略であれば、スポット開催だったセミナーを常設にする際に、セミナーのタイトルを「業務」から「ワーク：作業」に変えて具体化しました。

Excel定型業務をITで自動化　実現のポイントを事例で学ぶセミナー

というセミナータイトルは

御社の基幹システムが”Excel”になっていませんか？～ Excel定型作業の機械化・自動化セミナー～

としたように、IT方言の“業務”は一般用語の“ワーク：作業”に変わりました。

もう一つ、「業務」の派生形としてIT村からよく聞こえてくる「業務効率化」については、ITツールに依存した他人事にせず属人化も防止して、「標準化・機械化・自動化」という改善サイクルで個々人のスキルアップやナレッジ共有をベースにしていくことで、労働生産性の向上を組織のカルチャーとして根付かせていくことが大事なのかと考えます。

ちなみに、以前の記事「ジョブ型雇用で整理・淘汰される「仕事してるフリ」社員にならないための特効薬」で、ジョブ型雇用の三種の神器の一つとした「ロールマップ」は、この図に記載した「ロール：役割」を一覧したものになるはずです。

ちょっと特殊な例としては、ERP刷新やBI・DWHリニューアル、IoT導入といった期限のあるITプロジェクトであれば、ビジネスプロセスは当該プロジェクトの中で完結する小型のものになり、顧客：プロジェクトオーナーは組織内になるでしょう。

ロール：PM・プロジェクトマネージャー
タスク：与件整理・プロジェクトオーナー合意
ワーク：プロジェクト企画書を具体化した与件ドキュメント提出・討議

この場合、プロジェクトオーナーは対象となるITシステムの利用部門であり、ERPならCFO、BI・DWHならCIOもしくはCMO、IoTであれば商品・生産部門長となるでしょうから、プロジェクトが役目を終えた後には、当該システムの運用管理者のロールが新たに追加されるのでしょう。

さらに、本記事のテーマは「DXカオスから抜け出す」方策を考えることですから、以前の記事「DXがわかりにくいのはCX：生活者の視点で考えていないからではないか？」で考察したように、ビジネスプロセスにおける顧客・市場・社会との接点にインパクトをおよぼす部分をDX領域とし、90年代から続くIT化の領域は、組織内部における業務効率化：労働生産性向上の対象と捉えていただけるとよいのではないでしょうか？

組織における本当の「上流」は経営理念・社是・社訓（行動規範）

ビジネスプロセスは時流に応じて常に変化が生じているはずで、変化に対してスピーディに適応できる組織には、ステークホルダーの誰もが納得・共感できる経営理念・社是・社訓（行動規範）「ミッション・ビジョン・ポリシー（バリュー）」の3点セットがあるはずです。

そんな経営理念・社是・社訓は、競争優位の源泉になる組織のカルチャー：社風を醸成していく土台となる普遍の要素であり、時流に応じて変化しなければならない経営戦略・成長戦略・事業戦略なども、普遍の3点セットに基づいたものになるはずです。

戦略・戦術・戦法と経営理念・社是・社訓

参考までに、GAFAの一角をなすGoogleの経営理念・社是・社訓を覗いてみましょう。

▼Googleのミッションはビジョンと一体になっている　※WhyとWhatで表すとわかりやすくなる

Google の使命は、世界中の情報を整理し、世界中の人がアクセスできて使えるようにすることです。

▼ポリシー：社訓と読み取れる「Google が掲げる 10 の事実」　※日本では10訓や7カ条などが用いられる

Google がこの「10 の事実」を策定したのは、会社設立から数年後のことでした。Google は随時このリストを見直し、事実に変わりがないかどうかを確認しています。Google は、これらが事実であることを願い、常にこのとおりであるよう努めています。

ユーザーに焦点を絞れば、他のものはみな後からついてくる。

1 つのことをとことん極めてうまくやるのが一番。

遅いより速いほうがいい。

ウェブ上の民主主義は機能する。

情報を探したくなるのはパソコンの前にいるときだけではない。

悪事を働かなくてもお金は稼げる。

世の中にはまだまだ情報があふれている。

情報のニーズはすべての国境を越える。

スーツがなくても真剣に仕事はできる。

「すばらしい」では足りない。

10の事実をはじめて知った時、過去職のマネージャー研修におけるグループワークのテーマとして取り上げたのですが、10項目それぞれの文頭に「〇〇はするな。」と付け足す時にどんな言葉が入るのかというディスカッションは、十人十色で突飛な意見が噴出したこともあって、大いに盛り上がったことが思い出されます。

特に筆者が気に入っている逸話は6番目にひもづく「邪悪になるな」であり、コンプライアンスとガバナンスの違いがあいまいになりがちな企業はぜひ参考にしたい、行動規範：philosophy（哲学）と呼ぶにふさわしいものではないでしょうか。

グローバル発想ができる「デジタル人材」なら英語センスも高めたい

日本のIT村の特徴の一つとして、例えば“業務”というあいまいな言葉を、プロセスなのかタスクなのかワークなのか、一度英語に置き換えてから具体化できる人が少ないらしいと書きました。

DX：デジタルトランスフォーメーション／Digital Transformation であれば、形容詞＋名詞である以上、大事なのは Transformation なのでしょうけれども、IT村では最初にある Digital ありきで考えてしまうことから、IT化の延長線上にDXを位置付けてしまうことで、DXカオスを拡げてしまっているように見受けられます。

最近であれば、パッケージソフトウェアが SaaS になっただけで、IT媒体などではそれまで「製品：プロダクト」と呼んでいたものを「サービス」と呼び変えたがる風潮があるように感じます。

プロダクトの価値が「ソフトウェアに盛り込まれたノウハウの使用権」であることが、変わったわけではないのにもかかわらずです。

例えば、皆さんご存じ、Gmail：Googleのメールアプリケーションのことを、Googleの社員たちはサービスと呼んでいるでしょうか？

狭い観測範囲ではありますが、筆者が知る限り、答えはNoです。

Googleの社員は、GmailのこともGoogleカレンダーのこともGoogle広告のことも、少なくとも口語では Product と呼んでいましたし、Webサイトでも「どのようなプロダクトをお探しですか？」と記載されています。

※英語版Wikipediaでは Products_and_services とくくられていますが。。。

日本では商品＝製品・サービスと長ったらしく表記されるところが、商品＝product と極めてシンプルなんですね。

そのシンプルさが、イノベーションを起こせる会社、儲けられる会社の思考法なのかなとも思います。

なぜこんなややこしい話になってしまったかと推測するに、昭和の頃の日本で「サービス」と言うと英和辞書にある service ＝奉仕から「接客」という職種が想起されたり、「アフター（保守）サービス」や「ごはんのお代わり無料」といったオマケ的な響きが想起されてしまったりという蓄積があり、片や「モノ消費からコト消費へ」のような消費財マーケットのトレンドをそのまんま、自らの産業財マーケットに当てはめてしまう方が少なくないことの現れかと見ています。

パッケージソフトウェアであろうが SaaS であろうが、提供形態よりも先に考慮すべきは CX：Customer experience（顧客体験）であるにも関わらずですね。

義務教育の英語でさえまともに理解できていない筆者が、少なくともビジネスにおける英語センスを学んだ方法をお伝えします。

それはTOEICでもTOEFLでもなく、趣味の時間におけるたった3つの心がけです。

音楽はできるだけ洋楽を聴く（カラオケで嫌われるので歌詞までしっかり覚える必要はない）
外国映画は字幕版で見る（なんとなく文脈を外さずにクスッと笑うところがわかれば通ぶれる）
小説を読む時に分厚い翻訳ものを毛嫌いしない（ロマンチックな比喩表現は心の機微の勉強になる）

ごくたまに、翻訳者の中に「バラエティー」を「ヴァラエティ」と表記するような、原典文字に忠実すぎる方がいますがそこはご愛嬌。

言語コミュニケーションのキモは文脈：コンテキストの共有？

日本語だろうが英語だろうが、きっと大事なことは文脈：コンテキストが共有できているか、共有まではムリでもおおよそのイメージぐらいはできているかなんだろうと思います。

具体的には、行間に潜む「心のヒダ」を読み解く情報リテラシーを高めようという試みであります。

外国語のセンスを磨く大前提として、母国語の「語彙力」さえ高めておけば、まずは日本語および現代日本文化のコンテキストで考えて、あてはまりそうな外国語表現をググればよいわけですから、令和の時代における言語コミュニケーションの壁はそう高いものではないのでしょう。

その上で、英語をはじめとする外国語に耳だけ慣れておき、彼らがどういう文章表現が好みなのか、時代背景も踏まえておおよその傾向さえ感覚的につかんでおけば、たとえ外資系企業の日本支社駐在員と商談しなければならないようなシーンでも、身体の大きさや顔の濃さ以外には気後れすることもなく、ボディーランゲージと筆談でどうにかなってしまうものだ（90年代の成功体験）と考える今日この頃です。

そんな観点で、DXカオスを紐解いてみましょう。

まず、英語的には“D”ではなく“X”が主であろうことは先に述べた通りです。

この時の“D”は、20世紀までの概念だったデジタイゼーション（Digitization）：電子化ではなく、21世紀のデジタライゼーション（Digitalization）：インターネットテクノロジーの活用というコンテキストで捉えれば、DXカオスから抜け出すのに役立つでしょう。

肝心な“X”は、ビジネス用語としては“事業変革”を指すはずでから、ITの得意な「業務効率化」や「改善」というコンテキストで捉えるのではなく、いっそのことハリウッド映画の「トランスフォーマー」や、国内であれば「ウルトラマン」や「仮面ライダー」をイメージして、「変身」と捉えるぐらいでよいのかと考えます。

その変身は、決して内向きの「IT化の延長」ではなく顧客や市場から見てもわかるような事業変革でなければ、評価してもらえないはずです。

IT村でよく聞く内向きの「業務プロセス改革」ではなく、「ビジネスプロセス／ビジネスモデルの変革」によって、顧客や市場から変化を認知してもらい、以前よりも「うまい、やすい、はやい」に変わったね・便利になったねと評価してもらえるようになることを、「DX」と位置付ければよいのではないでしょうか。

そんなコンテキストを踏まえた上で、クラウドシフトやAI・RPAの導入が「DX」なのかIT化の延長：機械化・自動化なのか、皆さんの脳内でクッキリ識別できれば、余計なストレスを抱えることなく割り切って取り組んでいけるでしょうし、DXカオスの渦から抜け出す最初の一歩なのではないかと考える今日この頃です。

以上、今回も筆者のよた話にお付き合いいただき、衷心より御礼申し上げます。

DXカオスのような渦に飲み込まれるようなことなく、粛々とITプロジェクトの現場で汗をかいていらっしゃる読者の皆さまにおかれましては、ITプロジェクトに先行させてほしいコンサルティング・フェーズなども解説した下記記事がご参考になれば幸甚の限りです。

ERP移行・基幹系システムの再構築を成功させる5つのステップ

企業内の情報システムを形容する時に、“美しい”という言葉を聞いた体験をお持ちの方はいらっしゃるでしょうか？

皆さんが企画されているERPの移行や基幹系システムの再構築は、“美しい”と称されるようなものになるでしょうか？

経営資源である“ヒト”の動きも“モノ”の動きも世界共通言語である“カネ”や“時間”に置き換えて、発生ベースできちんと記録され、いつでも取り出せるようになっているわけですから、ERP：Enterprise Resources Planning どころか ERO：Enterprise Resources Optimization／経営資源最適化システムと呼べるレベルになっているのでしょう。

基幹系システムの構築は、ビッグピクチャーを描ける数少ないチャンスだと思いますので、ビジネスエグゼクティブや監査法人はもちろんのこと、税務当局からも“美しい”と評されるような絵を描いてみようではありませんか。