「user-driven」タグアーカイブ

基幹システムを自前開発した中小企業は、経営者のレベルが低い

投稿日時: 投稿者:

たいていの日本の中小企業は、ITの活用レベルが高くありません。これは世間で言われているとおりと、わたしも感じています。ただし、例外にも思えるような中小企業が時々見つかります。なかには、会社のコアとなる基幹システムを自前で構築してしまったという中小企業も存在しています。

大企業が完全内製で基幹システムを構築、という例はほとんどないと思われますが、中小企業の場合、事業規模があまり大きくないことも手伝い、実は自分で作ろうと思えばできてしまうという側面があります。そうかといって社内にスキルの高い技術者がいないと当然不可能ですが、たまたま1人くらい「できる人」が社内にいると、その人が根気強く取り組んで構築を果たしてしまう、ということが起こるわけです。

うらやましい会社だ、と思うでしょうか。ベンダーに頼んで作ってもらうよりコストもかからなくて素晴らしい、と感じるでしょうか。わたしが見る限りでは、そうした会社は「経営者に問題がある」おかげで、大きなリスクを抱えていることが多いと考えています。

経営者が自ら手掛けてシステムを作ってしまった、というなら結構です。しかし、技術者が独力で作ってしまった、という状態は、経営者の情報システムに対する知識や理解の欠如、関与しようとする意欲の低さ、会社にとっての情報システムの位置づけの設計不足、等々の欠陥によって引き起こされた結果なのです。

そのとき、その会社の経営者は、何らコントロールができていません。言い換えれば、放任です。情報システムに対する知見がないがために、自分がコントロールしなければならないという発想さえも浮かばないのだろうと思います。それが、事業運営に大きなリスクを抱えることにつながります。

では、基幹システムが事業の根幹をなすクリティカルなシステムであることを十分に理解する経営者ならば、どのようなことを発想できることが求められるのでしょうか。

いくつもありますが、長くなりますので、そのうちの数点を以下に書き連ねてみたいと思います。「自分はこんなことを考えるに及ばない」と思われるなら、少なくとも社内のIT担当者が「作っちゃいました」と言い出してこないような業務環境にするよう努めるべきでしょう。

●　中小企業の自前開発は、たいていは特定の技術者が単独あるいは少人数で進め、達成します。そしてそのシステムの仕様を設計した技術者はまともに形式知化せず、その構築ノウハウは属人化します。それは、会社にとって大いなるリスクです。一刻も早く、システムに関するノウハウや詳細仕様をドキュメントとして完全に網羅し、保守を長く継続できるような組織と仕組みを整備することを考える必要があります。

特に、開発した技術者が高齢であるほど、その技術者が会社を去るまでの時間の制約が厳しくなります。そして、そういう技術者に限って、言葉や図式による表現やわかりやすい説明が上手くなかったりすることが往々にしてあります。システムの仕様や、細かい（けれど重要な）属人的ノウハウを引き継ぐ時間が限られる可能性を、十分念頭に入れる必要があります。

このとき、多くの経営者は、「若い技術者を採用して、開発したベテランの下に付けよう」ということくらいは思いつきますが、その程度ではまったく十分ではありません。必要なことは、「属人化から脱却すること」です。単に若手を採用すればよいという考えは、属人化した「人」に新たに属人化させる「人」を付けているだけのことです。属人化の継承では意味がありません。「組織で実行するにはどうすればよいか」を考える必要があります。
●　中小企業の基幹システムの自前開発は、その多くが10年近くかけて少人数の特定の技術者だけで実行されます。それほどの時間をかけて技術者に業務遂行させることの是非を、本来ならまず経営判断すべきです。

仮に是と判断したとしても、10年経たないと完成しないようなシステムで事業に役立つのか、その認識を経営者が示さない限り、技術者は好きな方法で、適当なスケジュール感で、システム開発を進めるでしょう。技術者の優先度と、経営者の優先度は、何のすり合わせもしなければまったく違ったものであるのが常です。技術者が優先するのは、技術の追求、技術の都合、技術の制約、です。経営者が自分から考えを示さない限り、彼らは経営の優先事項には何の関心もありません。逆の立場で、経営者にはIT技術者の発想がしづらいのと、同様のことです。
●　自前でシステムを開発できる技術者でも、態度には決して出しませんが、万能ではありません。プログラム開発には長けているがネットワーク設計は知識が低い、システム設計は得意だが情報セキュリティ設計には疎い、等々、だれでも得意分野と不得意分野はハッキリしているのがフツウです。IT分野に関する、会社としての知見の甘さを的確に検知して補強する努力は、ITを操る以上は必ず要求されると心得るべきです。

それを怠り、「うちの技術者は基幹システムが作れたのだから他のことも何でもできている」などと考えているなら、自社のシステムに知らずのうちに大きな欠陥を抱えるリスクがあります。そのリスクを軽減するには、まず経営者自身が、ITの技術分野のポートフォリオについて知ることです（技術に詳しくなれという意味ではありません）。そのうえで、自社では疎い技術分野を認識し、知見を持つ人材を（採用、外部支援両面で）採り入れ、組織を強化する努力をすることです。
●　自前でシステムを構築するにも知識が必要ですが、自前で作ったシステムを運用保守していくにも（別の）知識が必要である、と発想できるかどうかが問われます。構築出来たら終わり、使えていれば問題なし、ではありません。自前でシステムを運用保守するのに相応な知識体系を構築して、人材の育成を組織として継続実施することが求められます。

ましてITは常に進化し、またその進化は速く、既存の技術が陳腐化する可能性も高いです。ベンダーに依存していればベンダーが実行するようなことを、自前で情報システムを作った以上は自前で実行する義務がある、と心得るのが肝要です。

自社のエンジニアは、会社の費用で外部に修行に出すべきです。社内だけで教育しようとすれば、知識に偏りや淀みが起きやすいものです。まして人材に乏しい中小企業ならなおさらでしょう。外部で学ばせ、その知見を社内に持ち込ませ、社内の古い知識や偏った理解をアップデートさせるように図ります。または、外部の有識者を定期的に呼び寄せて、様々なテーマでレクチャーしてもらうことも考えられるでしょう。

優秀な人材に単に依存するなら、属人化するだけです。一流のシステム運営能力を持ちたければ、会社が「組織として」努力しなければなりません。それをリードするのは、経営者自身です。

”伴走支援もどき” と中毒症

投稿日時: 投稿者:

近年の DX や AI にまつわるニーズを受けて、国内でのビジネスコンサルティング事業は活況なようです。業界はここ数年 2桁パーセントの右肩上がりで成長を続けているといいます。そんな業界環境なせいか、新興のコンサルティング会社を多く見かけるようになりました。

そして新興か老舗かに限らず、コンサルティング会社はどこも挙って「伴走支援」を掲げているようで、一種のブームのような様相です。つまり、精緻な分析や海外のベストプラクティスを基に「あなたがたはこうあるべき」などと御託を授ける教授スタイルではなく、顧客企業の側に立って共に歩み、顧客が自走できるようになるよう能力開発を助ける支援を目指す、としています。

本当の意味でそのような支援が実行されているなら良い傾向といえますが、わたし個人が実態として知る限りにおいては、多くのコンサルタントはいまだに従来同様「業務代行」していると思って見ています。

それも実は、無理からぬ話です。巷でよく聞かれる顧客企業の要望というのは、典型的には次のようなものだからです。「○○業界の企業の責任者への人脈を紹介してほしい」「アドバイスではなく実務に対応してほしい」「エンジニアがいないのでプロジェクトを現場でリードしてほしい」

顧客企業のオフィスに常駐し、机を並べて「伴走支援」しているコンサルタントの多くは、実態として顧客の代わりに、資料作成、データ抽出や整理、情報分析、会議の取り纏め、などの実務の肩代わりを行っています。しかしこれは、少なくともわたしが定義するところの「伴走支援」ではありません。顧客が主体的に担うべき業務の「代行」です。

当社では、代行任務はすべてお断りしております。顧客のためにならないからです。

率直に言えば、コンサルティング会社の経営者として事業拡大を企図するなら、代行を請けたほうがビジネスとしては有益です。なぜなら顧客の困りごとの多くは、前記のとおり「代行してほしい」なのですから。

それをわかっていながら、代行の依頼はすべてお断りしています。なぜか。当社のミッションである「お客さまのビジネスシステムを強くする」を踏まえた行動を遂行するにあたり、顧客任務の代行は、顧客のビジネスを強くするどころか、結果的には弱くすることになるからです。

これは、人間社会に存在する構造的問題の典型のひとつです。ある問題を是正しようとしたときに、即効性があるように見える短期的な方策を解決策に採用するけれど、そういうお手軽な方策を選択するほどに、より根本的な問題を見て見ぬ振りするようになり、時間がかかる根本的解決策に手を付けなくなる。実は根本的解決策を打たなければ、その問題を根絶することはできない。それに気づいていてもいなくても、お手軽な策に一度味を占めると、次にまた問題が出ても、手近で安易な対症療法にばかり手を出すようになる。

そういう状態にある組織に根本的解決策を唱えると、それは「正論」だと位置づけて忌み嫌い、避けようとします。正論を振りかざす、というフレーズにはネガティブな響きがあり共感を呼びそうです。しかしこの状況においては単に、本質的な問題から逃げようとしているだけのことです。

このような問題構造に一度嵌ってしまうと、最終的には、根本的な解決策を自らの手で打つ能力さえも失ってしまいます。要するに「中毒症状」と同じ構造なのです。アルコール中毒、麻薬、ギャンブルなどの依存症の問題構造を想像してみてください。

コンサルティング会社にとっては、顧客企業が自社に「依存」してくれる構造が生み出せますから、ビジネスが安定し大変に有益です。しかし、顧客の側からすればそれは中毒症状であって、コンサルティング会社がいなければ業務が破たんする状態、コンサルティング会社がいなければ戦略も計画もまともに立てられない状態、になっていくわけです。わたしはこれを指して「顧客のためにはならない」と言っています。

「コンサルティング会社が代行してくれてうまくやってくれるのを、うちの社員が端から見て学ぶのだ」というようなことをおっしゃる向きもあるのは承知しています。少なくともわたしはそのようにして、本当に学んで自走し始めた会社をまだ知りません。思うに、ふつうの人間なら、非常にうまく仕事を捌いてくれる人たちを見て、彼らなしに自分たちだけで問題に対処する方法は学びません。彼らに任せておけばよい、と考えるのがフツウです。パソコンメーカーが効率よくパソコンを製造して供給してくれるのを見て、「パソコンを自作しよう」と思う人がどれだけ多いか、想像してみてください。

わたしは、本来コンサルタントというのは医者と同じだと考えています。医者は、患者の病気が治れば任務完了になります。完治した患者にいつまでも医療行為を継続することはありません。顧客のステージが上がった結果として新たなレベルの課題が生じたというなら別のコンサルティングになるので良いですが、そうではないのなら、課題を解決すればそのコンサルティングは完了なのです。同じ依頼で何年も顧客企業に常駐しているということは、自分が関与しても問題がいつまでも解決していないことを意味することになります。

任務代行を施せば、顧客は課題を根本的に解決できるリソースもケイパビリティも身につけられないどころか、身につける機会も学習能力も奪われると、わたしは考えています。課題の根本はいつまでも解決されず、顧客は半永久的に、その課題のモグラたたきを続けることになるわけです。しかも大抵、モグラは年々増殖し、土壌をむしばんでいきます。最後にどうなるかは、想像が難しいことではないはずです。

当社としてはそういう信念で事業をしているのですが、なかなかこうしたことを理解しない企業や人が存在することも事実です。それはそれで仕方がないことではあります。

デジタル化とは「最新のアプリを使うこと」ではない

投稿日時: 投稿者:

最近では中小規模の企業でも、クラウドサービスやアプリ開発ツールなどを積極的に活用するケースが増えてきたと実感しています。

ITを道具としてどんどん試してみようという機運が盛り上がっていること自体は、歓迎すべきことです。ただ一方で、それに伴って厄介な相談を受ける機会も増えてきたような気がしてなりません。

困ったことになっている企業の傾向として、大きく2つの特徴があると思います。

ひとつは、次々とアプリやサービスを使い始めたけれど、いろいろなものがありすぎる状態になってしまい、会社での管理が行き詰まっているという状態です。ひとつひとつのアプリは相応に便利だとは思っているものの、「こんな使い方でいいのだろうか」と薄々感じ始めています。

もうひとつは、あるひとつのプラットフォーム上で、便利だからといって次々と新しい機能を追加し続けているうちに、「なんだか使いにくくなってきた」「違和感を持ち始めた」という状態です。始めのうちは新しい機能がすぐに追加出来てよかったものの、そのうちに、何かをしようとすると別のことを考える必要が増えてきたり、追加した後に不具合が出てきたりなど、いろいろと問題を感じるようになってきます。

いずれのケースにも共通するのは、一言で言えば「カオス状態」とでも呼べるでしょうか。要するに、アプリやサービスを「使う」ことしか考えていなかった結果、複雑で分かりにくい状態になってしまった、というものです。

デジタル化というのは、「最新のITを使いこなすこと」ではありません。以前からこのコラムでも、企業にとっての IT というのは電気屋でモノを買ってきて使うこととは違う、と述べてきましたが、同じ趣旨のことがこの場面でも当てはまります。

始めにしなければならないのは、デジタルを前提に仕事のしかたを設計することです。このことへの意識が乏しいゆえに、設計を怠ってまず何かを買ってしまう、使い始めてしまう、ということなのでしょう。会社の中のシステムやデータの構成を設計できる人がいないと、だいたいこうした事態になります。

例えば、近年ではロボットや自動運転技術を導入しやすくなっており、モノによっては10万円台で買えるような製品があります。それを受けて、うちにもロボットを入れようと言って購入し使い始めたのはいいけれど、導入後に保守できない、トラブルが出ても対応できない、定期的なメンテナンスに苦労する、という事態になりがちです。

始めのうちは自動で動いてくれて便利だったけれど、周辺の配置が変わったり現場環境が変わったりしたことでロボットが上手く動かなくなり、よく考えてみたらその修正ができる人がいなかった、などという事態も聞かれます。

ロボットの他にも、例えばAIカメラによる画像判定などでは、現場の光加減や陰が少し変わっただけで、判定がうまく行かなくなることも実際にあります。

ITを導入するのは、案外簡単です。知識がなくても買うことはできます。ワクワクするような便利ツールを買うのは楽しいものです。しかし問題は、買った後の運用なのです。その技術の癖や特性を踏まえて、会社の中での運用が的確に設計され、中長期的にどう維持発展させていくかのシナリオができていることが重要なのです。

そして、設計するというアクションは、単にアプリやサービスの組合せや利用する技術を選べる、決められる、というだけでは用事が済みません。会社の戦略や方針を踏まえて、業務の将来像を設計することでもあります。現有の人材と今後の人材獲得の方針を見極めて、使いこなせるものを判断することでもあります。最新であればよいわけでもなければ、流行に乗ればよいわけでもありません。設計するというアクションができる人は、かなりハイレベルで広範な知見が要求されるわけです。

たちが悪いのは、聞きかじった程度の知識や経験で「自分は知っている」と思い込んでいるけれど、実際には知見が足りないので、設計や方針の判断を誤る人です。先月のコラムで述べたような「知らないを知る」ことに取り組んでほしいと切に願いたくなるような人です。こういう人が周囲の期待を集めて裁量を与えられてしまうと、ITに疎い人でも見てわかるほどに派手にコケるまで突き進んでしまいます。そうなってから取り返すのは、なかなか難しいのです。

最終的には、経営者に問いが突き付けられます。「ビジネスのしくみが設計できる人材を育てて、確保する努力をしていますか？」と。会社としてデジタルを使いこなそうと思うのなら、持たざる組織能力を得る努力もしないで丸投げしているのでは、いつまで経っても状況は変わらないし変えられないのです。

「デジタル化が遅れている」と言われて、安直に急がない

投稿日時: 投稿者:

マスコミがさかんに「日本企業はデジタル化が遅れている」とはやし立てるせいか、判断に必要な情報が足りない、業務が非効率で混乱している、などといった課題に直面したとき、「システムを入れよう」という発想になる経営者や経営幹部が、最近多くなってきたように思います。

今回のコラムは、その発想は悪いことではないが安直である、というお話です。

もう多くの方にとって忘却の彼方に行ってしまったことかもしれませんが、コロナ禍が始まった時、医療現場ではコロナ患者の動向に関する情報収集をめぐって、深刻な混乱が発生していました。

国は当初、全国に感染患者がどれだけいるのかを集計するのに、電話やFAXを使っていました。しかし、それでは不正確で不確実なことはすぐに明らかになり、すぐさま「システムを入れよう」という流れになりました。

ところがこのシステムに必要なデータとして列挙された項目や内容があまりの分量となり、そのデータ入力作業は医療現場の人々にとって、押し寄せる患者の看護や治療でひっ迫している業務へのさらなる負担となりました。

結果、どうなったか。医療機関によってはすべての項目を入力せずに報告したり、1週間分をまとめて入力して報告したり、などという行為が横行したのです。

テレビやネットで情報を見ていた我々一般人は、感染者数の動向などはリアルタイムで報道されていると思っていたわけですが、実態は「だいたいの数字」を見ていた、ということになります。

システムを導入する、デジタル化をする、ということは、要するに何をすることなのか。一度は深く考えてみる必要があると思います。

データが見たいというのなら、まず自らの手でデータを生み出さなければいけません。データは、そこに自然に置いてあるものではありません。自然に湧いて出るものでもありません。ほしいデータは、通常は自分で作り出さなければ存在しません。例えば、いま誰もが当たり前に毎日使っている「温度」や「湿度」でさえ、その昔それが知りたいと考えた学者が生み出した指標です。

そうしてデータを生み出したところで、それは多くの場合、人間の手で「入力」されて初めて実体になります。裏を返せば、それは人間の対応次第で誤ったデータにも、汚れたデータにもなる、ということです。データだから正確、という保証はないのです。では「正確なデータ」をどうやって収集するのか。何をもって「正確」だとするのか。人手を介さず自動でデータを収集できるのが理想ですが、そうしたいなら自動で収集するやり方を、また自ら編み出さなければなりません。

データを収集する、データを加工する、データを集約する、そうして処理したデータを使えるように反映する、等々、一連のデータ処理を実行する「しくみ」もまた、自ら考え出さなければなりません。

世間に売っているソフトウェアやクラウドサービスを採用すれば済むと思っている経営者や経営幹部は多くいますが、それらを導入して「帯に短し襷に長し」な状況に陥った実体験をしたことがないのでしょう。自分のやりたいことが具体的で明確であればあるほど、それに一挙に適合する出来合いのソフトもクラウドサービスも、ますます見つからないのです。逆に自分のやりたいことが曖昧で明確でないほど、今度はソフトウェアやクラウドサービスの都合に振り回されることになります。

そのような、自分がやりたいことを実現する「しくみ」を設計する源泉は、どこから来るのでしょうか。

それは、データが見たい、業務を合理化したい、という課題解決を必要とする「目的」です。なぜそれが重要なのか、それをしないと会社はどうなってしまうのか、いままでのやり方を曲げてでも新しいやり方を採用してデータ入力の仕事を負担する必要がなぜあるのか、それが説明できなければなりません。

新しいやり方を採用しようとしたとき、そのやり方の実践には、一定の「デジタルの素養」が必要な場合もよくあります。その場合は、現場に対するデジタル分野の知識強化のサポートも必要になります。勝手に覚えてシゴトしてくれ、では通用しません。

的確に説明ができなければ、また現場に対する的確な支援が提供できなければ、現場は黙って、データ入力を実行しないか、正確性を追わずいい加減な対応でお茶を濁す行動に出ます。コロナ禍で、感染者数の正確な情報提供が重要であることは十分に理解していたはずの医療現場でも、前記したようなことが発生しているのです。

的確な説明を考え、説得できるのは、その取り組みを主導する経営者や経営幹部以外にいません。デジタル化を進めるとき、全体構想を考案し、実現シナリオを設計すべきなのは、取り組みを主導する経営者や経営幹部です。「ITに詳しい人」ではありません。

よく「経営トップが主導せよ」「経営者の意識が低いのではデジタル化はできない」などと言われているのは、こうしたことが本質なのです。「デジタル化をするぞ」「データを見える化するぞ」と掛け声をかけるのがトップの役割、などと考えていたら、道を誤ります。

デジタル化を進めたい、という思いがふつふつと湧いてきた経営者の方々は、一度立ち止まって、「それ、どういう仕組みで実行するの？」ということから絵に描いてみてください。わたしに聞いていただければ、その絵にいろいろなツッコミを入れさせていただきます。

「自分自身でできること」が、限界を決める

投稿日時: 投稿者:

昨年中の仕事の活動を振り返ると、結局のところ「自分でできることが自分の限界を決めてしまう」のだという（当たり前の）ことを多く実感させられたように思います。

昨年は、製造業の企業に触れる機会が複数ありました。これまで脈々と広まってきた「現場のカイゼン」に基づくシゴトの仕組みは、どの工場にも一定程度カタチがあるのは確かなようです。ただし現場に至る前の、事業戦略から生産計画を立ててそれを現場に作業展開するまでの「生産管理」については、企業によって相当にレベル差があることを実感しました。その理由は、生産管理をロジカルに仕組み化して実践することは、難易度が高いからです。その会社にとって「できないこと」は放置されがちだということです。

また、営業組織の支援を様々に行ってきて感じたのは、課題があることも、変えなければこの先成長しないことも、頭では理解しているはずなのに、強制力が働かない限り、いつまでも同じ所を堂々巡りしているチームが圧倒的に多いことでした。慣習を変えられない理由は、変えるための具体的な行動を自分たちの力では組み立てられず、目指すべき姿が彼らにとって「できないこと」になるからです。何の実にもならないようなつまらない進捗報告でも、毎回毎日だと、みんな慣れてしまってそれがフツウになっていきます。まるで生活習慣病のようで恐ろしいことです。でも実はその「できないこと」は、ちょっと背伸びすればできてしまうことに、無理やり取り組んでみてようやく気づきます。

従来からの取り組みがうまく行かなくなり方針転換を図ろうとする時、その前に、組織としてのそれまでの取り組みを総括するべきです。しかし、当事者たちの力だけではまともな言語化というのはできないものです。考えてみれば当然なのかもしれませんが、うまくできなかった人たちが、自分の出来なかったことを自分の力だけで分析評価するというのは、無理難題と思われます。解けなかった数学の問題について、解答を見ずに自分で解答をつくろうとしていることと同等です。そうかといって、彼らが第三者による指摘を素直に受け入れるかどうか、受け入れたとしてもその内容を咀嚼し応用できる能力があるか、というのは、また別の「できないこと」かもしれません。こうした課題には、最終的には自ら気づいて自ら腹落ちしないと、本当の意味での課題にはならないのです。

ある時、某社のCIOの話を聞く機会がありました。顧客ではないので書きますが、この方はデジタルマーケティング畑で長く勤めて経験が長く、一方でシステムを作ったことがありません。話の筋はおよそ、デジタルを「使う」観点からくるもので占められ、デジタルで「つくる」発想がないがために、CIOとしては世界観が限定されているように感じられました。残念ながら、CIOという役職は、マーケティングを知っているだけでは務まりません。そのことに、ご本人は気づきがないのかもしれません。要職を務める人たちからよく聞く悩みのひとつは、率直に言ってくれる人が周囲にいなくなること、です。もったいないなという感想を、内心では持ったことが思い出されます。

自戒を込めて言えば、結局のところ、自らが「できること」をできるだけ増やし拡げていく努力を不断につづけなければ、自分の出来ないことに気付くこともできずになおざりにし、最終的には、できないことに飲まれて衰退していくのだろうと思います。

もちろん、ひとりで何でもできるようになることは、当然ながらできません。できる他人に何かを任せることが必要になります。ただし、自分では全くできないことを他人に任せるのは、簡単そうですが実際は容易なことではありません。実際にやってみるとわかることですが、そもそもどのように仕事を頼めばいいのかさえ、わからないはずです。さらに、ある程度はわかっているうえで他人に委ねるのでなければ、他人のアウトプットの良し悪しを判定できません。結果として、相手にコントロール権を奪われることになります。

渡してはならないコントロールを相手に渡してしまうのが最悪の筋書きになりますが、自分にできないことについては、それがクリティカルなのかどうかさえも往々にして判別がつきません。

例えば、英語の読み書きのスキルは、生成AIの登場によって、もう必要ないかもしれません。英語が不得意だった人たちにとっては福音と言えます。ただし、ChatGPTが生成した電子メールの本文を本当にそのまま相手先に送っても問題が起こらないか、ChatGPTが作ったスピーチの原稿をそのまま顧客や社員に向けて流してしまっても本心が伝わるのか。その判断は、自分がある程度は英語ができないと、判別がつかないはずです。日常会話レベルの事務的なやり取りであればどうでもよいかもしれませんが、適用したい場面がクリティカルであるほど、気持ちを漏れなく的確に伝えたいと思う場面ほど、生成AIの言うとおりでよいか否かの判断は重要になります。こうしたこともまた、英語という言語が、日本語と比べるとハイコンテクストな言語的特徴があり、ひとつの言葉の意味の守備範囲が日本語のそれよりも一般的に狭いということを知っていなければ、他人から重要だと言われてもまったくピンとこないかもしれません。

企業におけるデジタルの選択肢は、この先もますます増えていきます。技術の向上に比例して、デジタルがビジネスに発揮できる影響力や破壊力は、さらに増していくでしょう。無数に出てくるデジタルソリューションやツールの中から、自社に相応しいものを探し出して選び取る能力が、利用する企業にますます重要になっていくことになります。

さらに言えば、そうしたソリューションやツールを適材適所で活用するには、会社の仕事のしくみをデザインする能力がますます重要になっていきます。自分でデザインできる会社ほど、デジタルをテコにした独自のしくみを発展させて成果に繋げるでしょう。自分でデザインできる能力を持たない会社ほど、デザインすることの必要性さえ理解ができず、自身で自身を変えることができずに衰退していくでしょう。

自分で考えることが「できない」企業ほど、ITは、丸投げ対象のコスト要因にしか見えないはずです。自分で考えることが「できる」企業ほど、ITは、ビジネスで利益を出して必ず手に入れたい魅力的な道具に見えることでしょう。業界で一流を目指すなら、どちらになりたいですか？

わたしがこれまで見てきた「元気のいい会社」は、総じて健全な危機意識を常に高く持っていて、それでいてメンバーの多くがビジネスへのチャレンジを楽しんでいるように見える組織でした。新しい年の初めに際して、わたしは「自分でできることをさらに増やす」ことを肝に銘じて、新しい提供価値を増やせるように、また仕事を始めていきたいと考える今日この頃です。

DXを語る前に、まず「ITの運用」ができるか

投稿日時: 投稿者:

2022年10月末に、大阪急性期・総合医療センターという病院でシステム障害が発生し、通常診療が全面停止する事態になりました。

その原因となったのは、ランサムウェアによる攻撃でした。電子カルテシステムを含む院内のデータが暗号化されて利用できなくなり、緊急手術以外の外来診療の一時停止を余儀なくされたのです。同病院は、攻撃者から脅迫を受けながらも、全システムを再構築により完全復旧させる方針を決断し、それに3カ月程度かけることにしました。

聞くところでは、この規模の大病院になると、医療機関としての総合的な運営コストは、1日当たり1億円程度になるのだそうです。通常診療ができないということであれば、そのコストがただ毎日出ていくだけの日々を、約3カ月の間過ごすという決定を下したことになります。それでもシステムの全面再構築の道を選んだわけですから、容易な判断ではなかったでしょう。

その攻撃被害の原因や再発防止策を検討した調査報告書が、2023年3月末に公表されました。

報告書では今回の攻撃を許した原因を整理して指摘しており、部外者の我々も対策を考えるうえで参考になる内容になっています。その中でわたしが注目したことのひとつに、攻撃者の侵入のきっかけになったとされている、外部の給食事業者の存在があります。

攻撃者は、同病院の入院患者向けの給食提供を業務委託で行っていたこの事業者が所有するファイアウォールを破って侵入し、その会社の業務サーバーを乗っ取りました。そこで、同病院のサーバーへの認証情報を得て、同病院が管理する給食サーバーへ横展開していったということです。

このファイアウォールは、給食事業者のシステム構築を担当したベンダーがリモート保守で用いるために、外部からのアクセスを可能にするように認証設定されていました。ところが、ファイアウォールの装置自体がもつ脆弱性が放置されていた状態でした。その脆弱性を突かれたため、アクセスのためのIDとパスワードが窃取されたといいます。

わたしがなぜこの給食事業者に注目したかと言えば、この事業者は侵入のきっかけを作ったそのファイアウォールについて、「存在を知らなかった」と答えているというからです。

このような話、つまり、自分たちがどのような装置や機器を使っているのかを全く把握していない（特に中小）企業というのは、典型的な「あるある話」です。厳に改めるべきことなのです。

そもそも、ITを導入する企業が十分認識すべきことがあります。それは、何らかのITを導入する時点で、その企業には「運用業務」が発生するということです。

運用業務とはつまり、自社が管理すべきIT関連の資産をすべて把握し、それらの資産の適切な取り扱い方法や設定を定めて、適切な動作を継続するように業務を設計して遂行する、というようなことを指します。このとき、自社の管轄ではないが自社のシステムへの影響が避けられない外部の装置やシステムについても、管理責任は軽減されはするものの、自社管理とほぼ同等のケアが必要です。

問題になったファイアウォールが、この給食事業者の資産だったのであれば、管理責任は給食事業者にあります。「存在を知らなかった」では済まされません。

もしベンダーの所有だったとしても、給食事業者がその装置の存在を知らなかったということは、由々しき事態です。ベンダーから説明を聞いていたにもかかわらず忘れていたのだとしたら、給食事業者の責任は免れません。そもそもファイアウォールのような装置では、外部からリモート接続させるなら必要な時だけに限定すべきであり、保守作業の必要がないときでも外部から内部へつながることを許容していたことが問題だと思います。

そうではなく、もし保守ベンダーが給食事業者に許可を得ずに黙って設置していたのだとしたら、ベンダーに対する損害賠償責任が問われかねないようなことに思えますが、装置は会社の管轄区域内に設置されていたのですから、自社内に置いてあるものに何も関心を示さないというのもまた問題です。犯罪者が無断で置いた盗聴器や盗撮カメラに、何の関心も示さず放置するのと同じことです。

ベンダーの説明責任などの問題は多かれ少なかれあると考えられる一方で、装置の運用に対するユーザー企業の認識の甘さ、管理責任の欠如、利用者としての管理努力不足といった道義的な責任は、免れるものではないと、わたしは考えます。仮に、導入したシステムの運用を全面的にベンダーに委託したとしても、最低限の運用管理業務は必ずユーザー企業側に残り、それを負わなければなりません。運用を完全放棄することは、いずれにしてもできないのです。

そういう自覚がないままITを導入する企業が、特に中小レベルでは多すぎるように、個人的には感じています。

ここで経営者の方々に申し上げたいのは、このランサムウェア攻撃被害における給食事業者の責任問題のことではありません。ITを利用する企業はいずれも、ITを会社として利用する時点で、それがいかなるハードウェアやソフトウェア、またはクラウドサービスやツールであったとしても、社内には必ずなんらかの「運用業務」が発生すること、そのために何らかの体制面での措置が必ず要求されること、です。

その対応には、ITを用いたシステムの構成や設定などについて、ユーザー企業自身が少なからず勉強し理解する必要が出てきます。

それがどうしても出来ない、やりたくない、のであれば、会社でITを使ってはいけません。気安く使えば、いつか然るべき時に、この事件の給食事業者のようなことになるでしょう。

いま一度、「企業におけるIT利用は、電気屋で家電を買ってきて使うのとは違うのだ」と認識いただきたい。切に願う次第です。

「クラウドがやられる可能性」を考えているか

投稿日時: 投稿者:

「クラウドファースト」などとして、日本のマスコミはクラウド事業者に情報システムを「すべて」預けることが今の常識だという論調でしきりに語りたがると思っているのは、わたしだけでしょうか。

もちろん、リスクを取ってでもクラウドに完全移行したほうがその企業にとって価値が高いと判断して、そのようにした事例も認められます。納得感のある判断です。ただ個人的な見解ではありますが、そんな目利きをしたようには思えないクラウドシフト事例ははるかに多数あると思っています。マスコミが生み出したそんな後者の企業を、マスコミが多数取り上げる結果、ますます拍車がかかっているように思えてなりません。

実際のところ、目が利くITユーザー企業は、自社管理であるオンプレミスとパブリッククラウドサービスを、うまく使い分けて利用しています。

両方を使い分けるのには、いろいろな理由があります。単にパブリッククラウドに移すのは都合が悪いという理由もあります。個別の都合は様々でしょうが、総合的に考えれば、選択肢がいろいろあるにもかかわらず「クラウド一択」というのは賢い選択とは言えないはずです。だから使い分けるのだろうと思います。

クラウド事業者やベンダーが示す事例はもとより、マスコミが紹介する事例も、有名企業が自社のシステムをすべてクラウドシフトしたなどと大々的に取り扱っていますが、その企業が考え抜いた末にそういう判断をしたのだとしたら、そのリスクについてどう考えたのか詳しく聞いてみたくなります。

クラウドも人が運用するシステムである以上、オンプレと同様に障害は起こりますしシステム停止も発生します。問題なのは、障害が発生した後から復旧するまでのところです。オンプレミスなら自ら手を下して復旧に取り組むことができますが、パブリッククラウドの場合は復旧を待っていることしかできません。

クラウド事業者のほうが技術に長けているから自分で直すよりましだ、という論もあるでしょう。それは否定しませんが、彼らが取り扱っているのは超巨大システムですから、技術力があるエンジニアがあなたの会社の面倒を見てくれるわけではありません。年間何億円も支払っているような、よほどのお得意様企業なら別かもしれませんが、障害が発生して「あなたの会社のシステムは救えませんでした」と言われても、全く不思議ではありません。実際、過去のパブリッククラウドの障害においては、ユーザーのデータがバックアップもろとも消去された事例が複数あります。

あまり論じられることがないように思いますが、パブリッククラウドもITシステムである以上、サイバーセキュリティ攻撃に常にさらされています。いつ何時、脆弱性を突かれて顧客情報に攻撃者の手が届くともわかりません。それはオンプレミスと同じです。クラウド事業者だからリスクゼロということはありません。実際、国内のあるクラウド事業者で、内部の脆弱性を突かれて攻撃者に不正アクセスされてしまったケースが報告されています。

脆弱性を突かれる外部からの攻撃でなくても、クラウド事業者の内部で特権を悪用して利用者のデータに影響を及ぼそうとする事件が起こらないとも言い切れません。内部犯行の脅威もまた、オンプレミスと同じです。もしそのようなことが可能だとしたら、場合によっては全世界の利用者にリーチできてしまうという、前代未聞の漏えい事件になりえることも想像できます。

攻撃や犯行の脅威に限らず、そもそも外国資本の事業者に、自社のデータや資産をすべて預けてしまうのはリスクが高いのではないか、という考え方も、あって当然です。ご承知の通り、いま3大クラウドと呼ばれるクラウド事業者はすべて米国資本の企業です。欧州の企業では当初から、米国資本の企業に完全に委ねるのは危険であるという考えのもと、利用においては重要資産はパブリッククラウドに預けないなどリスク分散させる考え方が根強くあることが知られています。

日本国内でもここ最近、経済安保というキーワードのもとで、行政システムのクラウドシフトに一定の歯止めをかけ、国内の事業者に重要資産を預けるよう義務付けるべきだという意見が出始めました。冷静に考えれば当たり前のことです。これまでそのような話が出なかったのは、政府や行政もまた、トレンドセッターを自任する識者諸氏やマスコミの論調に盲目的に同調していたことの表れなのではないでしょうか。

米国の政府がパブリッククラウド事業者に行政システムをどんどん預けていると知らされて、日本の政府もクラウドシフトの動きを強めたのかもしれませんが、実際の所、米国政府はパブリッククラウド事業者に、政府専用の「物理的領域」を設けさせて、そこに行政システムを置いています。最近そうし始めたのではなく、始めからそうしているのです。要するに、（政府の手が滞りなく及ぶ専用の）データセンターにシステムを預けるという、従来のやり方と実質変わりはありません。

そして、パブリッククラウドのおひざ元ともいえる当の米国内の企業においてさえも、パブリッククラウドに預けたシステムを再びオンプレミスに戻すという揺り戻しの動きが顕著にあることが（米国内では）伝えられています。

言い出せばきりがないことです。また、だからといってクラウドサービスが有用であることを否定するつもりもまったくありません。

クラウド一択の何が結局問題なのかと言えば、パブリッククラウドは利用者自身のコントロールが（特に利用者にとって一番肝心なところで）事実上効かないこと、パブリッククラウド事業者にコントロールの主体があること、なのです。それが、およそすべてのクラウド利用にまつわる利用者側のリスクを生み出しているように思います。

目が利くITユーザー企業はそのことを理解し、何があっても決して自分のコントロールを失ってはならない情報資産を、自分の支配が及ぶ領域に置いておこうとしている、ということです。

マスコミが記事として出すクラウドシフト事例の企業も、実はよくよく聞いてみると、ちゃんとオンプレミスをうまく使って資産保護しているケースが多数あります。要するに、記者が見たい事実にだけ着目して報道しているだけであることが多いのだと、わたしは理解しています。少なくとも、記事の見出しだけ見て鵜呑みにするのはリスクが高いと、心得ておきたいものです。

ITを「ツール」にしている会社のザンネンな誤解

投稿日時: 投稿者:

ここ最近は、中小規模の企業でも、ITを一切使っていないという企業に出会うことはほぼなくなりました。どの企業でも、何らかのソフトウェアやデジタル機器が使われています。

ただし、典型的な誤解のもとにITがうまく使えていない企業も、いまだ多いように感じられます。

例えば、バックオフィス周りは結構IT化しました、勤怠管理、会計処理、給与等々。でもその程度で、会社の中でITの存在感は特に大きくありません、というケース。

別の例で、ウチは結構ITは使っている、いろんなツールを入れて使ってきた、でもこれでいいのか、なんだかモヤモヤしながら使っているんだよね、というケース。

ITはずいぶんその適用範囲のすそ野が広がり、安価で手軽に使えるようになりました。それはとてもよいことなのですが、企業が自らの事業の強化のためにITを使おうとするのなら、素人考えでの使い方から脱しないと、なかなか「強化」するには至りません。

ITがうまく事業の強化につなげられていない会社というのは、ITが「便利なツール」程度にしかなっていません。

例えば、あるA社では、外回りしなければならない営業担当者が、会社に戻らないと客先に電話連絡できなかったところに、会社がひとり一台のスマホを支給したところ、出先からでも顧客に電話ができるようになった、という話をしているとします。

一方で、同様にスマホが営業担当者に支給されているB社では、客先に定期的に送っている情報は頃合いを自動的に見計らってメールで送信されるようにしていて、もしそれに反応があった場合には担当者に通知が自動でスマホに届くので、その時に初めて客先に連絡を入れる。直接の訪問先は厳選されるので、そもそも外回りの頻度自体は多くない、と言っているとします。

A社とB社では、同じ外回り営業のことでも、全然質の異なる話をしています。あくまでわかりやすく丸めた例ですが、概ねこんな雰囲気の違いが見られるのです。

どこで、こうした違いが生まれるのでしょうか。

たしかに、どこででも自由に電話ができるようなったのは、ひとつの効率化でしょう。しかしA社は、そもそも出先で電話のやり取りが必要になるのはなぜか、という疑いは持っていません。B社は、その根本要因を問うことから始めているから、A社とは根本的に異なる営業プロセスの発想が生まれるわけです。

A社のITの使い方は、素人の域を脱していません。フツウの人が、電気屋で家電を買ってきて使う、カーディーラーで車を購入して運転する、といったレベルと同じです。

こうした使い方では、ITは単なるツールです。もちろん、それで満足できるケースもあるでしょう。しかし、その程度の適用なら、他の会社でもできます。事業の強化になっているようで、実はその程度の活用は世間的には平均レベル、当たり前の活用でしかありません。

一方でB社の場合、ITを使うことによって「システム」にしている、と言えます。

システムというものの意味は、実はけっこう誤解・曲解されています。「システム」という語は当然ながら英語から来ているのですが、辞書を引くとこんな定義が書いてあります。

a group of related parts that work together as a whole for a particular purpose

出典：Longman Dictionary of Contemporary English

つまり、「特定の目的のもとで」「一体となって連動する」「関連した部品の」「集まり」、ということです。

何らかの目的を定め、それを達成するための仕組みを設計し、仕組みに必要な部品を集め、連動するように組み立てる。そのための基盤やパーツとして、ITを使っているのです。

これが、本来の「システム」です。

単にITという「ツール」を使っているだけなのに、「ウチはシステムを入れている」と主張する企業が結構いるのですが、まったく誤解しています。「システムは設計しないとできない」という事実が抜け落ちているのです。

いわゆる ”DX” に必要なこととは、これまで行ってきた習慣ややり方が本当に必要なことなのかを疑い、自社のあり方をデザインし、それを実装できる、組織としての能力です。

大正時代ならクルマを持っているだけで強力なアドバンテージだったのが、いまやクルマの所有はたいして感心はされないフツウのこととなっています。ITもまた、単なるツールで使っているだけなら何のアドバンテージにもならないフツウのことであると、改めて認識して、その先へ早く進みましょう。

データがある会社とない会社の、大きすぎる差

投稿日時: 投稿者:

おおよそそうではないかと思っているのですが、ビジネスの仕組みが明らかではない会社には、使えるデータもありません。

使えるデータをたくさん持っているのにビジネスの仕組みはいまいちだという会社を、わたしは寡聞にして知りません。逆に、ビジネスの仕組みづくりに長けている企業には、たいていは多くの使えるデータが存在しています。

そういう傾向になるのは、データに次のような特性があるからです。

まずデータは、使おうとする人が自分で「取ろう」と思わなければ、存在すらしません。自然にそこにあるように思われがちですが、そうではありません。自然にそこにあるデータも見つけることはできますが、それは誰かほかの人が取ろうと意図して取得したデータに違いありません。そしてそういうデータは大抵、自分にとって使えるデータにはなっていません。

次に、データは何らかの目的をもって取らなければ、そもそも意味を成しません。意味をなさないのなら、使えないデータです。何かの情報システムやソフトウェアを入れたりすると、それが勝手に内部でデータを取っていたりします。しかしそのデータ取得が自分が持つ目的に合ったものでないなら、きっとそのデータが参照されることはありません。見たところで意味がないからです。漫然とデータが取られているだけならば、自分に見えてくるものは何もありません。

さらに、データというのは、使わないのなら持っていないのと同じです。出してくれと言われれば多くのデータを揃えて提出できる会社はたくさんあります。しかし、それらのデータを普段から自分で使っていないのだとしたら、実はそれらのデータを出力できない会社とあまり変わりはありません。

最近、AIを適用して業務能力を向上させる事例が、業種を問わず出てきています。ただ一方で、AIを使える企業と使えない企業の差が、かなり顕著になってきている側面もあります。その要因は、技術力の差というよりも、つまるところデータの差です。AIはデータを食べさせることで育成されます。自社内に使えるデータがない会社は、そもそもスタートラインに立てないのです。

データというのはまた、過去から現在までの蓄積の賜物という側面もあります。ある企業では、職人技の調整を要する業務にAIを適用して判断精度の向上を図ろうとした際、数十年にわたって記録してきた作業日報を活用したそうです。そこには、調整のノウハウと、成功失敗の履歴が詰まっていました。

おそらくこの会社では、「どう調整したらうまく行くのか」を長年追究し続けてきた結果、一定の「仕組み」が出来上がっていたのではないでしょうか。その蓄積が、作業日報でした。もちろん紙の情報でしたが、これをデジタル化してAIに学習させたのです。

職人技に依存する多くの企業は、その技を言葉にしようとする努力を欠いています。実際、言葉にしようとすると大変な労力を要します。それでもなお言葉で表現しようとする取り組みは、つまり属人的な仕事を仕組み化しようとするものにほかなりません。仕組みを構築するマインドがある会社はおよそ、データ化する取り組みは自然に実行しているものなのです。

コンサルが「正しい」助言をしにくいとき

投稿日時: 投稿者:

先日、同業のある知人から、こんな話を聞きました。

ある中小企業の社長から、DX推進に関してどうしたらよいか支援してほしいと打診を受けて、事情をヒアリングしに行ったのだそうです。会社を訪問すると、社長からその場で経営計画からDX推進の体制案まで、いろいろな文書を見せてもらったと言います。すでにその計画は社内に展開され、社長自ら社員向けに説明も行っているということでした。

訪問先の社長はかなり勉強熱心な方だったようで、計画は自分で立案したがコンサルタントを入れたことはこれまで一度もない、と言っていたそうです。

随分と完璧に見えますが、提示された文書を知人がつぶさに見通すと、その計画は相当に未熟なものに映ったと言います。ミッション、ビジョン、行動指針といった企業理念の３点セットは高らかに謳われているのはいいけれど、それを実現するロジックがまるで考えられていない。

現場の社員たちには、社長が掲げる経営計画に従って自部門の目標をブレークダウンさせたそうですが、その内容を見ると、部門視点の発想から生まれるようなお決まりの目標しかない。それは無理もないことで、スローガンだけ掲げられて経営シナリオが提示されないから、社員から見ると全体の構図がなにもイメージできないわけです。そのため結果的に、過去の経緯と自部門の課題意識の範疇でしか発想ができない。

ヒアリングの席では、進め方に対する社員からの反発はすごいという話だったそうです。それは当然そうなるだろうと、わたしは思います。

それを受けてこの知人はどういう提案を考えたか。結局、その社長の経営計画に沿ってDXを推進する支援企画を考えたのだそうです。

本来ならば、経営計画のレベルからやり直すのが正論です。経営計画が納得感をもって現場まで降りていないそもそもの要因は、社長が立案した経営計画が未熟だからです。漠然としたビジョンを具体的なシナリオにしない限り、起こっている問題は根本的には解決しません。しかし、そうはしない。なぜかといえば、すでにその計画は社内に展開され、社長が自ら説明してしまっているからです。

もし正論を通せば、その経営計画を全否定するように聞こえる。社長自身のモチベーションも低下するし、プライドも傷つくかもしれない。社内も、突如として方針転換がなされたように見えて混乱する可能性もある。支援を推進して成功裏に完了させるには、未熟な計画なことは承知で、それとなく促して良い方向になるように仕向ける支援をし、うまく立ち回ることを選択する。こういう判断です。

この判断は、まったく妥当だと思います。しかし一方で、この社長は損をしたなと、わたしは思います。勉強熱心なのはよいことですが、社長業をしていれば専門家ほどに究めることはほぼ無理です。勉強不足により我流に陥りすぎる結果に嵌るが、自身はそれに気づかない。そのまま他人に相談せずに、計画を実行してしまいました。計画を展開する前に識者に相談していれば、おそらく適切な助言がもらえ、実効性の高い計画立案ができ、それを良い形で社内に展開して円滑に浸透させられていたのではないでしょうか。

専門家であっても外部の人間がアドバイスしにくい状態になっている場合がある。それによって、本来なら得られていた助言が得られなくなる。そういうことがありえると、経営者のみなさんには頭の片隅に置いておいていただきたいと思います。