先見性のない「はずれコンサル」が増殖、彼らが発する“危険なひと言”

先見性のない「はずれコンサル」が増殖、彼らが発する“危険なひと言”
https://diamond.jp/articles/-/283988

 ※ 「コンサル」と言っているが、「ITコンサル」のことのようだ…。

 ※ 「オンライン選挙」の例は、まあ置いておくとして(国政の根幹にかかわる重大性、それと比較しての、そもそもの「オンライン」に纏わる脆弱性…、などの問題があるんで、一私企業のDX推進と同列には論じられないと考える)、「参謀」の「企画立案」における「先見性」の問題を考える上で、参考になる…。

 ※ ただ、素人の「感想」を言わせてもらえば、しょせん「コンサル」なるものは、ある局面における「策」の「企画立案」の役割を振られた者に過ぎない…。それも、相応の「報酬」と引き換えにだ…。

 ※ 「局面」というものは、時々刻々と変化していく…。

 ※ それに応じて、打つべき「策」も変化させていかざるを得ない…。

 ※ さらには、事が「デジタル化」「DX化」である場合は、そもそも、その「組織全体」に、末端の構成員の隅々までに「デジタル化」の「動因」が浸透しているのか…。日々の業務の「デジタル化」への「構成員の行動のベクトル」が、そういう方向に向かっているのかこそ、点検されるべきだろう…。

 ※ 「デジタル化」「DX化」とは、結局のところ、「コンピューター(電子計算機)」の応援・支援を受けることが可能な形態に業務執行の体制を、”変えていく”(「トランスフォーメーション」とは、そういう意味)ということだろう…。

 ※ みずほの例でも分かるように、話しは「システム要員」だけに限ることじゃ無いんだ…。

 『白紙の状態からプログラム開発をしなければならない昔のプロジェクトでは、その規模にもよるが、企画から導入まで3年ほどかかるケースもたくさんあった。

 しかし、3年という期間は、その企業のビジネスの周辺環境を一変させるには十分な時間だ。

 例えば、家電メーカー各社は、たった3年で出荷するテレビをアナログテレビからデジタルテレビに移行完了した。

 2010年には10%に満たなかったスマートフォンの所有率は、2013年には60%を超えた。

 2012年に6割ほどあった従来型の光源はLEDに取って変わられ、2015年には3割程度まで減少し、2018年には1割程度にまで落ち込んでいる。』

 『また、プロジェクトの期間が長ければ投資金額もより多く必要になる。企業は、ビジネスの環境変化への追従性を高め、システム開発の投資費用を抑制するために、より短期間で安くシステム化を実現する選択をするのが当然だ。

 こうした背景から、パッケージシステムと呼ばれるセミオーダー型のシステムを開発するIT企業が現れ、システム開発プロジェクトの工数と期間のボリュームゾーンを効率化させることに成功した。基幹業務の領域にパッケージシステムを導入する場合、現在では企画から導入までを1年ないし1年半程度で完了できるケースもざらである。

 さらに、近年はクラウド化やシステムのサービス化、アジャイル開発などの手法により、その期間はますます短くなっている。』

 『こうした環境が、もしかすると悪影響を及ぼしているのでは、と思わせるのがコンサルの先見性のレベルの低下である。』

 『しかし私は、便利な世の中になって、必要なシステムが短時間で手に入るからといって、コンサルに先見性が不要になるわけではないと思っている。

 金額の多寡によらず、システム投資をした場合、企業は「将来的に会社に収益をもたらすことが期待される」という前提のもとシステム投資にかかった費用を、「資産」として計上する。

 その後、企業は会計上、一般的には5年程度、減価償却費を負担しなければならない。サービス型やサブスクリプション型の経費扱いのシステムであっても、当初のもくろみが狂うと減価償却費とは別に追加の費用が発生するし、いざ別のシステムに切り替えようとなると案外手間が発生する。

 私が顧客であれば、自分が思い描く2年先3年先のビジネスを理解してくれなかったり、想像できなかったりするコンサルとは仕事はしない。また、買えばすぐ自分で使えるようなシステムの導入にコンサルを活用することもないだろう。

 臨機応変に対応できる身軽さやスピード感は重要だが、それだけでは本質的な変革は果たせまい。』

 『先見性のない「はずれコンサル」に共通する危険なひと言

 今、この瞬間にもさまざまな場所でさまざまな企業がDXに取り組んでおられることだろう。そうした現場で、コンサルやITベンダーが「このシステムを導入すれば御社のDXがかないます」とか「弊社のサービスで今日から御社はデジタル化できます」などとうそぶいているのを想像すると、うすら寒い思いがするのである。

 こんなひと言をささやくタイプの人たちは、「1年後、2年後なんてどうなっているか分かりませんからね。今、チャチャッとシステム化しちゃった方が得ですよ」とまで言う。』

『さらに、もっと残念に思うこともある。将来を予見したり想像したりすることを放棄し、脇に追いやるコンサルは、時に、上記とは真逆に「この先どうなるか分かりませんから、いったんここは様子を見ておきましょう」と真顔で言うのである。』

『つまり、「今できることしかやらない」コンサルと「この先どうなるか分からないから今は様子を見る」コンサルは、先見の明を持たない発想しかしないという点では考え方の根源が同じなのである。』

『もし、日本でオンライン選挙の検討が進んでいないようにみえる理由が「任期満了前に解散・総選挙があると、どうせそれには間に合わないから、オンライン投票の検討はじっくりやろう」という人のせいなのであれば。

 もし、とても重要なプロジェクトであるにもかかわらず「将来どうなるか分からないから様子を見よう」「先のことはさておき、今できることだけやればよい」と考える怠惰なコンサルがいるなら。

 私はこうした人たちに自分や会社の未来を任せたいとは決して思わない。』

ソフトウエアの「中の人」が消える

ソフトウエアの「中の人」が消える、日本企業が犯した愚かな過ちの本質
2021.9.2
5件のコメント

木村 岳史=日経クロステック/日経コンピュータ
https://business.nikkei.com/atcl/gen/19/00322/082300009/?n_cid=nbpnb_mled_mre

『普通ならブラックボックスには必ず「中の人」がいるものである。何の話かと言うと、ソフトウエアのことだ。ソフトウエアはとても便利だが、それを利用する人を「無知」にする。なぜ無知になるかは単純な話で追々説明するが、利用者が無知になっても大丈夫なようにするのが、中の人である。ところが日本企業や官公庁のシステムでは往々にして、その中の人がいなくなる。これはもう真夏の夜の怪談より恐ろしい。

 ソフトウエアによってブラックボックスが生じるというのは、企業システムでは常識だと思っていたが、どうやらそれも分からない「非常識」な人も多いようだ。なぜそう言えるのかというと、これも後で改めて触れるが、RPA(ロボティック・プロセス・オートメーション)の一大ブームが日本企業の間で続いているからだ。本当に後が怖いのに、後先を考えずに導入を進めるIT部門などの愚かさを見せつけられると、ブラックボックス化の問題を認識していないのだと思わざるを得ない。

 そんな訳なので、まずはソフトウエアが生み出すブラックボックスについて説明しよう。ソフトウエアによるブラックボックス化は3つの領域で起こる。1つ目はコンピューターシステム自体のブラックボックス化だ。もっと正確に言えば、ソフトウエアは自分より下位レイヤーのハードウエアやソフトウエアをブラックボックス化する。

 つまりこういうことだ。今、業務アプリケーションなどを開発している技術者は、コンピューターが「なぜ動くのか」について分かっているだろうか。恐らく分かっている技術者はほとんどいないだろう。つまり、自分がつくっている業務アプリがなぜ動くのかも分かっていないはずだ。コンピューターのハードウエア上では全てのソフトウエアがデータと共に、0と1のビットとして論理回路などで処理されるが、そうしたコンピューター処理の原理をしっかり説明できる人は少ない。

 ソフトウエアの領域でもそれは同じことだ。業務アプリを開発する技術者は、いわゆるOSやミドルウエアがどんな働きをするかという概要と、それを利用するためにはどうすればよいかを知っていればよく、その中身(ソースコード)は知らなくてよい。ITベンダーの製品なら全く知らないし、オープンソースソフトウエア(OSS)でも中身を知る人は限られている。業務アプリを開発する技術者でさえこうであるから、業務アプリを利用するユーザーに至っては全く知るよしもない世界である。

 だがコンピューターの黎明(れいめい)期には、そうではなかった。業務アプリを書く技術者もハードウエアやOSなどに精通している人が多かったし、中にはユーザー企業の技術者なのに独自のプログラミング言語を開発してしまう人もいた。時代は下ってインターネットが普及し始めた頃は、ネットワーク技術者でもないのに通信プロトコルを熟知する人がごろごろいた。そして今、その辺りの下位レイヤーは全てブラックボックス化され、業務アプリの技術者は知るよしもない。つまりその分、技術者は無知になったのである。
パソコン画面の「こちら側」までブラックボックス化

 さて、2つ目のブラックボックスだ。こちらは1つ目のテクノロジーサイドと違って、業務サイドのブラックボックス化だ。こちらは極めて分かりやすい話だ。例えば、企業そして官公庁などの基幹系システムは、その組織の業務のやり方や業務プロセスなどをソフトウエアの機能として組み込んでいる。以前に人が紙とペンとそろばんなどで行っていた個々の業務や、一連の業務の流れ(プロセス)がシステムによって機械化されている。

 随分前の話だが、日本企業にコンピューターシステムが導入され始めた頃を知るシニア技術者から、当時の話を聞いたことがある。昔、企業には社内の業務に精通した「生き字引」みたいな人が何人かいた。初めてシステムを導入する際には、そうした生き字引たちの協力も得て、自社の業務プロセスなどをほぼ全てあぶり出したそうだ。

 あぶり出した業務プロセスは紙に書いて、システム導入プロジェクトの推進室の壁一面に貼り出したとのこと。で、壁に貼り出された業務プロセスを眺めながら、会計処理など各業務のプロセスのどの部分を機械化(システム化)するのかを、業務担当者やITベンダーの技術者などを交え、かんかんがくがくの議論をして決め、会計などのシステムを順次構築していったという。

 そんな訳なので、企業システムの黎明期には、多くの日本企業で業務プロセスが完全に見える化されていた。それを基に業務の一部をソフトウエアによりシステム化したものだから、システム導入によって業務はものすごく効率化された。ただ、業務プロセスなどがソフトウエアの機能として組み込まれた途端、ブラックボックス化も進んだ。業務担当者は時を経るに従って、システム化する前にやっていた業務を忘れてしまうからだ。

 しかも半世紀近くの時を経て、今やソフトウエアでブラックボックス化された業務の範囲は広大になった。特に大企業では、従業員はパソコン画面の「向こう側」で処理されている業務プロセスについてほとんど無知と言ってよい。そういえば、システム化の進んだ大企業では、従業員が自社の業務を知らな過ぎることにIT部門が危機感を持ち、ソフトウエアのブラックボックスの中で粛々と処理されている業務プロセスを、何らかの形で従業員に「見せよう」というプロジェクトを進めていると聞いた。

 このソフトウエアによる業務のブラックボックス化は、もう行き着く所にまで行き着いた感があったが、さらに「延長戦」があった。それが日本で一大ブームのRPAの導入である。RPAではご存じの通り、システムからデータを「コピペ」して他のシステムに入力するなどの作業を自動化するソフトウエアロボットを多数つくり出す。これによりパソコン画面の向こう側だけでなく、「こちら側」に残されていた業務までをブラックボックス化してしまうわけだ。

 ソフトウエアロボが代行する作業の多くは、単純作業だけれどもシステム化できなかった領域だから、目先の業務の効率化への貢献度は大きい。人海戦術でデータ入力などをしてきた企業では、コンピューター黎明期のシステム導入に匹敵するくらいの効果があったりする。だから、業務の変革でも何でもないのに「我が社のDX(デジタルトランスフォーメーション)の成果だ」と悪ノリする経営者は多い。しかも、既存のシステムだけでなくRPAで業務を二重にブラックボックス化する恐ろしさに気づいていないのだ。

ブラックボックス化しても「中の人」さえいれば

 ソフトウエアによるブラックボックス化の3つ目の領域は、ソフトウエア自身のブラックボックス化だ。これは1つ目に挙げた「下位レイヤーのハードウエアやソフトウエアのブラックボックス化」とは意味合いが全く違う。抽象度を高くして述べたので「何のことだ」と不審がる読者もいると思うが、種明かしをすれば「何だ、そのことか」と言うだろう。例のトホホなブラックボックス化である。

 つまり、基幹系システムなどのソフトウエアが長年の改修作業でスパゲティ化して、改修を担当する技術者以外はプログラムコードを「解読」できなくなる現象である。そういえば、「2025年の崖」で有名になった経済産業省の「DXレポート」では、基幹系システムでのこのブラックボックス化を、企業のDXを阻む深刻な問題として取り上げていたな。

 こちらのブラックボックス化が深刻な問題となるのは、2つ目に挙げた業務のブラックボックス化ともつれ合うように進むからだ。業務のブラックボックス化が進行するのは、単に業務担当者がシステム化以前の業務を忘れてしまうからだけではない。その後の業務の変化もブラックブックス化に寄与する。業務の変化は、新商品の発売に伴ってのことかもしれないし、法制度対応のためかもしれない。はたまた何らかのカイゼン活動の「成果」を取り入れたのかもしれない。いずれにせよ、そのたびにソフトウエアは改修されていく。

 結果として、業務はどんどん変わり複雑になっていくが、その複雑さの大半はソフトウエアの機能として、つまりシステムで処理されるから、従業員の仕事が複雑になっていくわけではない。ただし業務プロセスなどはますます分からなくなっていく。しかも、こうした業務の変更に伴うソフトウエアの改修などによって、ソフトウエアもどんどん訳が分からなくなる。技術者不足や緊急の改修要求などのせいで場当たり的な改修が繰り返されるケースが多いから、いつの間にか担当の技術者以外には理解できないスパゲティ状態となる。

 ただし、ソフトウエアによるブラックボックス化は、ただちに大きな問題になるわけではない。記事の冒頭で書いた通り、ブラックボックスには「中の人」がいるからだ。中の人とは、ハードウエアやOS、ミドルウエアなどの場合で言えば、それらの製品を開発・保守しているITベンダーの技術者たちだ。一方、2つ目と3つ目、つまり業務のブラックボックス、そしてスパゲティ化によるソフトウエア自体のブラックボックスでは、システムの保守運用を担う技術者が中の人に相当する。

 中の人がいるからといって、安心してよいというわけではない。中の人が突然いなくなることもあるからだ。あっ、そうだ。「突然いなくなる」というのは表現がおかしいな。十分に時間があったにもかかわらず、事の重大性を認識しようとせずに放置し、そのうちに中の人がいなくなるケースがほとんどだ。3つの領域のブラックボックスの全てで中の人がいなくなり、「このシステム、どうするんだ」とぼうぜんとしている企業もあるから、まさに中の人の消滅は真夏の夜の怪談より恐ろしいのだ。

RPA導入が恐ろしい理由は「中の人」の不在

 基幹系システムなどを利用する業務担当者から自身の絡む業務プロセスが見えなくなっても、保守運用を担当する技術者はブラックボックスの中の人として、少なくとも自身の担当する範囲の業務を把握している。プログラムコードがスパゲティ化して他の技術者にはソフトウエアがブラックボックスになっても、担当の技術者は自身がぐちゃぐちゃにしてきたコードだから、そのコードに手を入れられる。

 そんな訳なので、これらのブラックボックスの中の人である技術者は、本来ならとても貴重な存在だ。ところが、その価値はあまり認知されておらず、中の人が「外の人」だったりする。何の話かと言えば、IT部門が丸投げ体質で、システムの保守運用をITベンダーの常駐技術者に頼り切っているケースだ。これは企業だけでなく官公庁でもおなじみの話。自分たちの業務もシステムも「外の人」しか知らないのだから本当に恐ろしい。

 で、この中の人ならぬ外の人がいなくなるという事件が起こる。例えば、企業なら毎年のように保守運用料金の値下げをITベンダーに要求し続けた場合に起こり得る。ITベンダーは当初、値下げ要求をのんで常駐技術者の人数を減らすなどして対応するのだが、そのうち採算面で耐えられなくなり、常駐技術者の疲弊や不満も限界に達する。ついにITベンダーが撤退を通告し、ブラックボックスの中の人は誰もいなくなる。これは「本当にあった怖い話」だ。

 ちなみにRPAによる業務のブラックボックス化の場合、そもそも初めから中の人がいない。RPAの導入前にデータの入力業務などを担っていた人は、派遣など非正規雇用の人が多く、RPA導入から時を置かずにいなくなってしまう。正規雇用の従業員も別の業務に就くから中の人ではない。RPA導入を支援した技術者も中の人を続けることはない。かくして中の人がいないままソフトウエアロボは動き続ける。さて将来、何が起こるか。乞うご期待、である。

 もう1つのブラックボックス、つまりハードウエアやOS、ミドルウエアなどの中の人がいなくなるというのは、なかなか想定しにくいかもしれない。だが、これは極めて頻繁に発生する。何せ日本企業は最新の製品、最新バージョンのソフトウエアを使いたがらない。古い製品、古いバージョンのソフトウエアを使い続けているうちに、ITベンダーが製品に対する保守サポートを停止し、開発や保守に携わった中の人である技術者も担当を外れていなくなるというわけだ。

 企業によっては、3つのブラックボックスの全てで中の人がいなくなったという悲惨な話もある。中堅クラスの企業での悲話だが、随分前に構築した基幹系システムを延々と使っているうちに、ハードウエアやOSなどはサポートが切れた。それでも問題ないと判断して使い続けているうちに、今度は基幹系システムのブラックボックスの中身を知る唯一のIT担当者が退社し、中の人は消滅してしまった。社長が事の重大性に気づいたときは、まさに後の祭りだったという。

 さて、いかがだったであろうか。この「極言暴論」ではブラックボックス化問題を何度か取り上げているが、今回は「中の人問題」の観点でまとめてみた。結局のところ、企業が何もしなくても、いつまでも中の人として献身的に尽くしてくれる技術者やITベンダーなどいないということだ。付加価値の少ない基幹系システムにはITベンダーに中の人が大勢いるパッケージソフトウエアやクラウドなどをそのまま使い、どうしても独自システムが必要ならば自社で中の人を育てるしかない。そう思うが、いかがか。』

〔RPAとは…。〕

※「RPA」…。語句は聞いていたが、「なんか、業務を自動化するしかけなんだろう…。」程度しか、知らんかったので、ちょっと調べた…。

ロボティック・プロセス・オートメーション
https://ja.wikipedia.org/wiki/%E3%83%AD%E3%83%9C%E3%83%86%E3%82%A3%E3%83%83%E3%82%AF%E3%83%BB%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E3%83%BB%E3%82%AA%E3%83%BC%E3%83%88%E3%83%A1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3

RPAを導入しなさい!とトップに言われたら?
働き方改革を成功させる
「業務自動化」「業務改善」実現コラム
https://www.hulft.com/special-column/rpa-01

10分で理解する「RPA」、今求められるRPA人材の教科書
https://www.sbbit.jp/article/cont1/37189

※ 大体イメージは、掴めた…。

※ 要するにだ、ExcelやWordのVBA使ったマクロ組んでたみたいなことを、もっと大がかりにやろう…、という話しのようだ…。

※ しかし、言うは易く行うは難しだろう…。

※ 大体、業務で使っている「各ソフト」は、そういう「自動化」に対応していないものが多くあるだろう…。

※ そういうものは、どうするのか…。

※ Windows上の共通のプラットフォームと言っても、.NETフレームワークあたりまで降りて行って、構築するのか…。そうなると、殆んど「新しいソフトを開発する」と言うに等しい話しになるんじゃないのか…。

※ そうでは無く、スクリプトみたいなもので、昔(むかし)のバッチファイルみたいなものを作成する…、という程度だったら、狙った業務の自動化は達成できるのか…。

※ 上記の「RPA」製品は、そこら辺をうまく繋いでくれるのか…。

※ 何でも、出来上がったものを「使う」のは容易いが、自分で「作成する」のは、大変だ…。

※ 今の「会社員」は、大変だな…。そういうこともできないと、「給料」貰えないのか…。昔(むかし)に生まれて、良かったよ…。

3800人を1人で管理、新卒採用にRPAの効果

https://newswitch.jp/p/23650

『ユナイテッドは新卒採用にRPA(ソフトウエアロボットによる業務自動化)を導入した。夏期インターンシップでは3800人の応募者の進捗(しんちょく)管理を、ほぼ1人で担当できるようになった。1カ月当たり36時間分の工程削減につながった。こうした自動化を在宅勤務のリモート環境で実現。コロナ禍であっても業務の見直しと効率化を続けている。

「RPAは便利。使っていいことしかない」と、タレント&ストラテジー本部人材開発部の林由里恵マネージャーは目を細める。同社の夏期インターンシップは学生が七つの方法で応募する。学生向けメディアや応募時期によって書類審査や面接、グループワークのいずれかが免除されるなど応募方法により学生ごとにインターンシップの進捗が変わる。これまで手作業で学生のデータをまとめて管理していた。この作業を自動化した。

担当の加古晴香さんは「忙しい時期は管理作業だけで1日が終わっていた。自動化されて他の仕事ができるようになった」と振り返る。リアルタイムに情報が共有され、ミスもなくなる。学生の選考離脱率は33・1%から15・5%に半減した。

こうした自動化を在宅のリモート環境で進めた。RPAのサポート担当者にはビデオ会議でフォローしてもらう。以前は日時を決めて出向いてもらっていた。加古さんは「リモートは効率がいい。困ったところを尋ねると、その日のうちにミーティング時間を設定し、その場で問題が解消される」と説明する。

コロナ禍で在宅勤務が広がり、仕事の進捗状況を共有しづらくなった。手作業でも5分で済むが、その小さな作業をしないと周囲に情報が伝わらない。ただ、5分間の作業のために自分の仕事を止めたくない。このような作業の自動化にRPAは向く。林マネージャーは「次は面接のスケジューリングを自動化したい。RPAで1人分の時間を生み出す」と力を込める。(取材=小寺貴之)

日刊工業新聞2020年9月2日』