Friday is awesome

SAPについて個人的なメモをまとめたブログです

MENU

グリコのシステム障害から考えるSIer(主にSAP)の問題点(と未来?)

前回のエントリ(グリコがSAP S4 HANAへの切替に失敗したとか・・ - Friday is awesome)に引続き、グリコのシステム障害の裏側にあるSIerの問題点と未来について思ったことを書いてみようと思います。あくまで私の主観的な意見なので、その点はよろしくお願いします。
SIer・・システム開発を請け負うIT企業。NEC/富士通/NTTデータなど
私は、クライアントから請け負ってシステムを開発するシステムインテグレータの業界には2つの大きな問題があると考えています。

①慢性的な人材不足
様々な業界で人手不足が言われていますが、SI業界でも人手不足になっていることを感じます。
①-1 業界が魅力的ではない
SI業界が魅力的ではないため、若い人が入ってきていないのではないかと考えています。新3K(きつい、帰れない、給料が安い)と言われることもありました。
ただ、私の意見としては、他の業界と比較してそれほど給料が低いとは思えません。帰れないことはたまにありましたが。。
一番の問題点は客先常駐型の働き方にあったのではと思っています。つい数年前までこの業界では客先で働くということが当たり前でした。客先常駐のメリットとしては、客に近いところで働くので、コミュニケーションが容易であることや自社オフィスの賃料を下げれることがありまあす。一方でデメリットとしては、自分の会社ではないため色々なルールに縛られることになります。「客先に合わせた勤務時間」、「勤務中の無断外出は禁止」、「机でお菓子を食べてはダメ」など色々あります。同じITエンジニアでもベンチャー気質のあるWeb界隈のエンジニアとは働き方に雲泥の差があります。
こういうこともあり、アンテナの感度高い若い人からは避けられてたのかなと。。

①-2 SAPアップグレードで仕事急増
ERPのメインシステムであるSAPは現行のSAP ERPを2027年(以前は2025年だった)でサポート終了として、それ以降は新製品であるSAP S/4 HANAへの移行を促しています。そのことから既にSAP ERPを導入している企業にとってはSAP S/4 HANAへのアップグレードを迫られています。このアップグレードというのが曲者なんです。通常はソフトウェアのバージョンを上げるだけだと最新版ソフトをダウンロードして
インストールすることになりますが、SAPアップグレードの難しい点は単純アップグレードだと各企業が個別に追加開発したアドオン機能が動かなくなる場合があるので、下記2点が必要となります。
・アップグレードしても既存アドオン機能がすべて想定通り動くことの担保
・想定通り動かない場合は最新版に合わせてプログラム改修する
アップグレードプロジェクトはアドオンの海と格闘することとなります。そのため、アップグレードの時期に差し掛かりSAP関連の仕事が急増しているのです。ただ、これだけだと日本だけではなく外国企業も同じではないかと思われるかもしれませんが、特に日本企業は標準SAPに対して、追加機能を開発しがちだと指摘されています(理由は色々あります・・)


②アドオン多すぎ問題
①-2でも書きましたが、日本企業のSAP導入ではアドオン開発が多くなる傾向にあります。私が思う理由は利害関係です。だいたいのSAP導入企業では、経営層はともかく、現場のユーザ部門としてはSAP導入を快く思っていません。せっかく、自社にカスタマイズした使いやすいシステムを作ってきたのに、SAPに変えるのか・・と
なので、ユーザ向けにSAPのデモなんかすると、ボロクソに言われることもあります。そして、「ユーザ部門」からは現行業務をシステムに合わせて変えるという意識はなくなり、従来システムに合った機能をSAPでも実装したいと追加要件を出してきます。追加要件を対応するほうがいいかどうかはケースバイケースで、本来であれば、精査して開発を決めるべきなのですが、追加機能を開発する「SIer/コンサル」側としては断る動機が弱いのです。なぜなら追加開発すればするほど、開発費を請求できるので。
経営陣がERP導入といったIT事情にそれほど詳しくない。また、「情報システム部門」は「SIer/コンサル」に頼りきりで自分たちで「ユーザ部門」とディスカッションしようとしない。結果、追加開発の精査が十分に行われないまま、なし崩し的にアドオン機能が増えていき、導入・その後の保守が難しいシステムとなってしまう。
※ちなみにアドオン開発自体が悪いことだとは思っていません。アドオンすることで他社とは違う強みを作ることもできますし、元々ITはツールなので、自社の強みとなるような使い方をできればいいですよね。
以上、つらつらと最近のERP導入で思うことを書きました・・

ここからは業界の明るい未来を書いていきます。
従来、SI業界の主要企業は歴史ある伝統的な企業が多かったです。しかし、最近では
コンサル業界とSI業界の境目は曖昧になり、コンサルであっても要件定義など上流工程だけではなく、要件定義~開発~テスト~稼働・保守と実際のシステム開発領域を担うことが増えています。伝統的な企業に比較して、コンサル会社のほうが給与は高い傾向にありますし、働き方の柔軟性も認められやすいと感じています(あくまで私の所感ですが)。残業時間としても、徹夜してでも納期に間に合わすという無理な働き方はずいぶん減ったはずです。
一番大きいと感じるのはコロナ禍を経てSI業界でもリモートワークがある程度定着したことでしょうか。また、通勤を伴う日も以前のように客先へ通うことは大きく減りました。同じ通勤の場合でも、客先で働くのと自社で働くのでは心理的負担は、後者がずっと楽になると思います。
S/4 HANA移行に伴いシステム障害がある程度増えるのは仕方ないかなと。これは今始まったことではなく、過去からずっとアドオン開発してきた「ツケ」でもあるので。現役のエンジニアだけで責任を追うのは酷過ぎますね。
アドオン多すぎ問題については、コンサル依存をなくすこと、つまり、事業会社側でもITへの理解を深めて、自社主導でシステム導入を勧めていくことが大切だと思います。それには経営層の理解も必要となります。グリコはS/4 HANA移行でシステム障害になりましたが、システム子会社の紅栄情報システムではSAP人材を採用しており、そういう意味では内製化途中であったのかもしれません(江崎グリコ本体のCIOがIT子会社代表しています)。近年のAI技術の進化もありITをコストとして考えるのではなく、事業発展の戦略的なツールとして考えるとシステム開発業界もより魅力的になるのだと思います。

グリコがSAP S4 HANAへの切替に伴うシステム障害とか・・

お菓子で有名な江崎グリコがSAP S/4 HANAへの切替えに失敗して冷蔵品の出荷を
4月19日から5月中旬まで停止するとしています。同社は4月3日に旧基幹システムから
SAP S/4 HANAに切替えたところシステム障害が発生し、4月18日から再開していましたが、再度、データ不整合などの障害が発生していました。

江崎グリコ 「プッチンプリン」「カフェオーレ」など全冷蔵商品が出荷できず | NHK | 小売業
ネット記事によると、元々グリコはSAP ERPを使用していたので、SAP ERP→SAP S4 HANAへの刷新だったことが考えられます。https://www.jsug.org/2022casestudy/opentext

いずれにしても、システム再開を約1ヶ月後としていることから、一般論としてはちょっとした「データ移行ミス」や「SAP標準機能のバグ」とは考えにくいです。大規模SAPシステム導入の失敗事例としてアドオン機能の不具合が障害を誘発したと考えることが一般的かと思います。
グリコの2023年12月期の通期決算説明資料を読むとERPシステム投資額は340億円となっていることから純粋なサーバやソフトウェア購入費用とは別にコンサルフィー(つまり追加開発費用)も相当にかかっていると予想されます。

こうした事例の場合、導入会社は大手企業なので、お金で優秀なテクノロジー人材を獲得できなかったのかと思われる方もいるかと思いますが、ここがERPシステム導入の難しいところです。単純にプログラミングスキルがあっても業務観点での詳細仕様がわかっていないと開発した機能が意図しない挙動になることもありえます。また、開発期間でのシステム投資額が想定より大きくなるとシステム稼働時には人員を減らしていくので、キーパーソンが残っておらず解決に時間を要することもありえます。
最近は、SAP S4 HANAへのバージョンアップや様々なDX・AI活用など需要が増える一方で、コンサル・エンジニアが不足しているので、今後もこのようなケースが増えてくることが予想されます。ITシステムに投資して事業を進めていくためにも、企業としても国としてもよりIT人材の育成が重要課題となりますね。また、一度獲得した人材を離さないような働きやすい職場環境も大切かと思います(必ずしもそれは金銭的なインセンティブではありません)

更に続きを以下エントリに記載しました。

https://amzn.to/4aEHsNU「3カ月で改善!システム障害対応 実践ガイド」

ABAPというプログラミング言語を学習するメリット(とデメリット)

ちょくちょく聞いている、ドリキンさんがやっているPodcast番組「backspace.fm」でJSOLの方がSAP/ERPについて解説されていたので、それに関連してABAPを学ぶメリット・デメリットについて考えてみようと思います。
ABAP(Advanced Business Application Programming)は、SAPシステムで使用されるプログラミング言語であり、SAP環境におけるアプリケーションの開発に使用されます。
例えば、iPhoneを例に考えてみます。SAPが工場出荷後のiPhoneだとすると、ABAPは素のiPhoneに追加アプリを開発できる言語です。Apple社標準アプリ自体に対する変更はできない。SAPも「SAP標準」としてインストールされますが、それだけでは使い物にならず、標準の挙動に処理を追加したり、別途欲しい機能をアドオン開発することになります。iPhoneを使うときに工場出荷後の状態のまま使っている人はいませんよね。どんどんアプリを入れながら使いやすくしていくはず。SAPでも同じ考えで、どんどんアドオン機能を追加していくことになります(そうして、SAP導入コストは莫大に膨らんでいきます。良かれ悪かれ・・)。

■メリット

①収入の増加
SAP自体が大手企業、グローバル企業で使用されているため、エンジニア単価が高くなりがちです。そのため、コンサルではなくてプログラマー(ここで言うプログラマーは、SIerでの下請けという文脈での意味合い。ウェブアプリ開発などの開発者とは別の意味)でも比較的、高単価の報酬となります。
Top 10 highest paid programming languages in 2023によるとABAPは第6位!)
プログラマーからコンサルへの転身
SAPはERPシステムであるため、販売・出荷・売上・請求・購買・入庫・在庫・財務会計管理会計・生産など会社の企業活動と密接に関わっています。ABAPプログラマーであっても、単にコーディング能力だけでなく、ビジネスプロセスやSAPシステムに関する知識も必要とされます。そのため、ABAPを習得することで、プログラマーからビジネスコンサルタントへのキャリアパスを選択することも可能です。実際に私の知り合いでも高専卒でコンサル会社へプログラマーとして入社し、経験を積んでコンサル職へ転身した方がいます。
③大規模なシステムでの開発経験
SAPのプロジェクトは大規模なシステム開発プロジェクトであることがほとんどです。ABAPを学習することで、大規模なシステムでの開発経験を積むことができます。

■デメリット
①SAP特有の難しさがある
①-1 業務的な難しさ
純粋なプログラミング能力だけではなく、上述した販売・出荷などの業務内容もある程度は理解する必要があります。ABAPでコーディングが完了すると次にテストします。例えば、受注伝票のチェック機能を実装した場合、テストとして受注伝票を作成しますが、業務に精通していないと伝票登録ができなかったり(正しくできなかったり)して、テストを進められないこともあります(ここら辺は要件元であるコンサルと調整するのが一般的)

①-2 技術的な難しさ
ABAP(SAP)特有の技術であるBAPI/Function Moduleを使いこなしていく必要がある。新規でプログラム開発する場合もSAP標準のBAPI/Function moduleを呼び出すことがあります。この場合、標準プログラムがどのような振る舞いになっているか、どのようなデータモデルになっているかを知っておく必要があります。他の言語でいうと標準ライブラリ/メソッドのようなものでしょうか。ABAPの場合はこれらの文書やSample CodeがWeb上に多くないのも習得を難しくしていると思う。実際にはそれらをすべて網羅している技術者はいないので、チームで協力して進めていくことが多いです。
②学習の取っ掛かりがない
ABAPはSAPという特定のビジネスアプリケーションに特化した言語であり、そのため一般的なプログラミング言語と比較して学習コストが高いです。HTML/Javascriptのように自分のPCで手軽に触ってみるということはできず、"ABAPを学習する" ≒ "SAPをビジネスにしている会社に入る"ということになります。
③市場の限定性
②と関連しますが、ABAPの需要はSAPシステムを利用する企業に限定されます。そのため、ABAPのスキルを獲得しても、もしSAPの仕事から離れれば、その知識は活用できなくなります(もちろん一般的なプログラミングスキルとしては似通っているところもあるので、すべてが無駄にはならないでしょうが)

同じIT技術者でも分野が違うと話が通じないくらい、ITが色々な領域で使われているんだなと思います。Web系の業界ほど派手さはないもののビジネス系IT領域も奥が深くて(技術だけではなくクライアントの業務領域も!)学び甲斐はあると思います。メリット①で述べたように収入も高いですし。

【SAP Tips】エラーメッセージから原因を特定する

SAPでエラーメッセージからエラー原因を特定する方法はいくつかありますが、比較的簡単かつ有効な手段としてTr-Cd:SE91から使用先一覧でメッセージ出力のロジックを特定する方法があります。

①メッセージクラス、メッセージ番号の特定
SAPでエラーが出ると画面下のステータスバーに表示されると思います。メッセージをクリックするとメッセージ番号が表示されます。SU01Dで存在しないユーザを検索すると、「ユーザXXXXXは未登録です」というメッセージが表示され、クリックするとMsg番号 01124とあります。下3桁がメッセージ番号で、上2桁がメッセージクラスとなります
②メッセージ検索から使用先一覧を辿る
Tr-Cd:SE91でメッセージクラスに01、メッセージ番号に124と入力して照会ボタンを押します。該当メッセージを選択した状態で、メニューの「ユーティリティ」→「使用先一覧」をクリックします。
③ロジック箇所の特定
このメッセージの場合は、使用しているプログラムが多いので、たくさん出てきますが、、プログラムIDをダブルクリックするとメッセージ出力している箇所のコードが表示されます。

標準プログラムだとメッセージ出力箇所も多くて、特定に苦戦することもありますが、アドオンメッセージだとこの方法で問題特定できることが多いです。

追記
メッセージをクリックできない場合(ユーザからエラーメッセージのスクショだけ送られてきた場合など)は、メッセージクラス、メッセージ番号が特定できません。ユーザにエラーをクリックしてもらってメッセージクラスと番号を聞き出すのも一つのやり方ですが、T100というメッセージテーブルでメッセージを検索条件に検索して、メッセージクラス、メッセージ番号を特定するというやり方も有効です。

SAPのアプリケーション運用保守とは?

SAPのアプリケーション運用保守とはどのような仕事をするかについて述べたいと思います。

■どういうチームなのか?
運用保守チームは本番稼働したシステムをメンテナンスするチームで、システム導入後に構築されるチームとなります。導入会社がそのまま運用保守チームになることもありますし、導入後、半年ほどで別会社へ引き継ぐこともあります。どちらの場合でも、導入時のメンバーがずっと運用保守チームに残ることは少なく、運用保守チーム作りは長い目で見ていく必要があります。

■チーム構成の分類
運用保守チームをさらに分類して、「販売」、「購買」、「財務会計」、「管理会計」、「生産」などのITチームに分割されています。SAPシステム全体でカバーする業務領域は非常に広いため、ITのチームも業務領域に従い、分かれていることがほとんどです。分ける基準はプロジェクトごとに異なります。例えば、販売と購買はまとめていることや、財務会計管理会計はまとめていることもあります。また、SAPのモジュールに従いSD(販売)やMM(購買)チームと命名している場合もあります。
SAPのチームと言っても、各チーム間で持っている知識は異なるため、領域をまたがるような課題は複数チームで対応することとなります。


■仕事の分類
仕事の大枠としては、SAPの運用保守でも、一般的な情報システムの運用保守の仕事と大きく変わるところはなく下記3つになります。

①ユーザ問合せ対応
システムを使い業務しているユーザからの問合せに対応します。運用保守チームがどこまで対応するかはプロジェクトの体制によります。一次受けはヘルプデスク・サービスデスクと呼ばれるチームが対応していて、マニュアルを読めばわかることなどは、運用保守チームが対応することは少ないと思います。マニュアルに記載がない複雑な問合せや、よりシステム的な内容は運用保守チームが対応することとなります。
ぱっと見て分からない場合は、アドオンプログラムの設計書を読んだり、SAP標準カスタマイズの設定を確認して解決策に辿り着けるようにします。
一例を上げると、販売店からの注文情報をSAPシステムで自動受信しているが、エラーが出ているため取り込まれていないので調査してほしいなどです。エラーが出ている箇所を特定してプログラムに問題があるのかデータに問題があるのかなど調べていきます。参画当初はユーザが使っている言葉が分からないこともありますが、運用保守の担当年数が経つほどユーザ業務にも詳しくなり、チームでも一目置かれる存在になります。

②不具合改修
新しくSAPシステムを導入する際、当然、システム不具合は解消した状態で本番稼働を向かえますが、業務に与える影響のない軽微なプログラムバグなどは稼働後対応として残っていることもあります。また、業務をしていく中で新たに発覚することや新規に開発した機能から不具合につながることも多く、不具合解消は運用保守チームのメインタスクと言っても過言ではないです。開発・導入フェーズと違い、すでに稼働しているシステムで不具合発覚した場合は業務への影響確認やすぐにバグ修正できない場合は業務観点での暫定策を講じる必要があります。
SAPプロジェクトでは、ユーザと調整したり設計書を作成するチームとプログラミング開発をするチームが別々なこともあり、その場合、プログラム修正は開発チームに依頼して修正するようになります。
また、プログラムバグはシビアに見られることも多く、クライアントからなぜ発生したかと再発防止策を強く要求されるケースが度々あります。

③新規要件対応
既存のシステムでは不足している機能があれば、新規に機能追加をすることがあります。新たな商流ができたり、新規事業ができると、既存システムでは対応できずに新規の機能開発を要求されます。要件定義、設計、開発、テスト、プログラムリリースという一連のシステム開発工程を実施することとなります。
また、開発規模が大きい場合は保守チームで対応しないで、別途、体制を組んで保守費用以外の追加コストを出して対応することもあります。

以上、簡単ですが運用保守チームの紹介でした。運用保守の仕事の醍醐味としては実際に業務で使用しているシステムを触れるというところでしょうか。業務影響が出てしまうと、、という緊張感もありますが、ユーザ業務が滞りなく行われたり新規機能で業務改善できたときはそれなりに嬉しい気持ちになります。

【ABAP Tips】サブルーチンの検索方法はあるのか?

プログラミングである値を入力して一定の処理をして結果を返す場合に関数として定義しておくことはよくあると思います。SAP ABAPにも同様の仕組みがあり、Subroutineとして作成します。呼び出し元はPerform サブルーチン名、呼び出し先ではForm サブルーチン名で記述します。
プログラム内で使用されているサブルーチンを一覧表示するような機能はあるか調べましたが、どうやらそのような機能は無いようで、調べたい場合はプログラム表示してFind(双眼鏡のボタン)からPerformで検索するしかないようです。

【英語学習向け】映画やドラマを「英語音声・英語字幕」で見る方法を探してみる(アマプラなど)

英語学習に映画やドラマを活用している方は多いと思います。好きな作品を吹き替えではなく、生の英語で理解したいということもありますよね。最近のネットフリックス作品なんかだと英語音声で英語字幕という表示も可能ですが、過去の名作だと、「英語音声・日本語字幕」という形式になっていて、「英語音声・英語字幕」では視聴できないことが多いです。どうやってこれを実現できるかを探ってみました。

Google Chromeの設定で補助機能(PC利用)

まずは、天下のGoogle先生にお願いしてみます。ブラウザの標準機能だけで実現できるのでとてもシンプルです。ブラウザの右上にある「3つ並んでいる点」をクリックして、設定をクリックします。ちなみにPCのみでAndroidスマホのブラウザには無い機能でした。

「ユーザ補助機能」メニューに自動字幕起こしという項目があるので、ここをONにします。

あとは、動画を視聴すると右下の方に英語字幕が表示されるようになります。

この方法だとアマプラに限らず他の動画サイトでも利用可能ですし、設定も簡単なので、大方カバーできそうです。デメリットとしては、文字起こしの精度はめちゃくちゃ高いわけではないです。ミス・マープルというドラマを見ていましたが、「What's the matter」のところを「the matter」としていたり、「No ill effects from our gardening」をほとんど文字起こしできていませんでした(実際、Native以外だと非常に聞き取りにくいんだと思います)。とはいえ、自動処理でここまで実現できれば、大抵の場合、事足りますかね。

Google Chrome拡張「Subtitles for Language Learning (Prime Video)」

アマプラ用に字幕を表示するChrome拡張があります。Chrome拡張とはブラウザの標準機能以外に有志が開発している追加機能のことです。

https://chromewebstore.google.com/detail/subtitles-for-language-le/hlofmmmlhfelbfhcpapoackkglljfcnb?hl=ja

今度はローマの休日を見てみましょう。拡張をインストールするとSubtitles for LLというボタンが表示されるので、クリックします。

そして、右側の検索タブを開き、英語で作品タイトルを入力して検索します。「Roman Holiday」と入力すると下の方に関連タイトルがいくつか出てきます。だいたい、上の方にヒットする字幕を選べば問題ないですが、なぜかGossip Girlが出てきます。これはGossip Girlにもローマの休日というタイトルの話があったので、検索に出るようになっています。Gossip Girlは有名作品のタイトルをもじっていることが多く、いろいろな作品に混乱を招きそうですw
字幕を選択するとダウンロードが始まり、画面の右側に字幕が表示されるようになります。

字幕スクリプトの精度はその作品の知名度によって変わることもありそうですが、有名な作品であれば、精度は相当に高いと思われます。そもそも、英語を勉強するために過去作品を使用する場合は、有名作品が多いので、かなり活用できる方法だと思います。
いくつか試した感じでは上記のChromeの自動文字起こしよりも精度は高いです。

③各種AIサービスによる「Speech to Text」(お試し程度)

①と②でほぼOKですが、Chrome拡張以外かつアマプラ以外を試したい場合はなにかあるでしょうか?字幕というトランスクリプトを作成するという意味合いになりますが、音声ファイルを作成して、各種AIサービスによる「Speech to Text」を利用が考えられます。この分野は日進月歩で進んでいますが、2024年3月段階だと無料かつ高性能なものは存在しない認識です。なので、お試し程度に聞いて下さい。
1. まず、作品の音声ファイルを作成します。PCで作品を再生して、それをスマホで録音します(この時点で挫折しますよね・・)
2. 録音した音声ファイルをSpeech to Text処理する
私はVEEDというサービスを使いました。
MP3ファイルをテキストへ - MP3ファイルをTXTへオンラインで文字起こし - VEED.IO
試しに6分ほど録音して試してVEEDのサイトにアップロードすると文字起こしをしてくれました。作業は煩雑だし長時間だと有料版を求められるので限定利用になりますが、文字起こしの精度は高いと言えます。先程、ブラウザ拡張で表示できていなかった「No ill effects from our gardening」という箇所もVEEDのサービスだと正確に文字起こしできているんですよね。いずれは、このSpeech to Textという技術をAmazonNetflixなど動画配信プラットフォーム側が組み込んでいき、過去作品も自動字幕起こしシていくようになるんだと思います。

チャットツールは仕事の生産性を高めているのか?

最近、Google meet・Slack・MS Teamsなどのチャットツールは仕事の生産性を低下させているのではと疑っています。。チャットツールは2000年代からあると思いますが、一般的に普及したのは2010年代中盤くらいだと思います。それまでの電話・メールに続く第3のコミュニケーションツールとして普及してきました。
チャットの良い点としては、リアルタイムのコミュニケーションが可能になるため
迅速な情報共有や問題の解決がでるところがあると思います。また、メールに比べて肩肘張らずに気軽にコミュニケーションできる点もいいところです。メールだとちゃんとした文章を書いて送らないとという意識がありますが、チャットだとこんにちは等の
挨拶から入り本題へ移っていくというリアルの会話に近い感覚でコミュニケーションできます。他部門の初対面の人に連絡する際も、メールを書くよりはチャットするほうがハードルは低いです。
これらの良い点の裏返しになりますが、日常的に仕事のチャットのやり取りはめちゃくちゃ増えていると思います。じっくりと資料を作り込んだりシステムの設計を考えているところに、連続的に通知が来ると、その度に思考が中断されるというデメリットがあります。それなら通知を切ればいいのではないかという話もありますが、中には本当に急ぎのチャットもあるので、そう簡単な話ではなく。また、自分自身もチャットで気軽に聞きたいということもあり恩恵にも預かっていますしね。対策としては集中したい作業があるときは一時的に離席中のステータスにしたりすることですかね。
どんなツールも使いようなのでしょうが、新しいツールが導入されると便利な点が強調されがちでデメリットは軽視されがちです。特に上述したような生産性の阻害は、表に現れにくくく改善ポイントとして上がることが少ないです。コミュニケーションが活発なのはいいことではあるんですが、相手の時間を奪っているというのも事実でそこら辺の塩梅を考えながらチャットツールと向き合って行こうと思います。

Salesforceの売上がSAPを超えたとか

2021年を境にSalesforceの株価は陰りを見せて2022年~2023年は過去から考えると低迷していましたが、2023年後半から再び上昇して2024年に入り株価は最高値を更新しました。2021年にSalesforceの売上がSAPに迫っているという記事を書きましたが、

あれから3年、時間の経過は早いものです。もうパリオリンピックの年になってしまいました。つい最近、東京オリンピックがどうたらと話していたのに・・。

両者の売上比較はどうなったでしょうか?
SAP/Salesforce売上比較

2021年以降もSalesforceの売上は右肩上がりに増えていきました。一方でSAPは微増なので、両者の差は縮まりグラフでは超えたか微妙なラインですが、2023年度の第3四半期ではSalesforceがSAPの売上を超えています。
ちなみに、純利益ベースの比較ではSAPとSalesforceでは3倍以上の開きがあります。

SalesforceティッカーシンボルであるCRMが示す通りメインのソフトウェアは顧客管理システムです。そこからコミュニケーションツールのSlackやデータ分析のTableau(タブロー)を買収してビジネスソフトの領域を拡張しています。2020年度と2023年度の製品群別の売上内訳を見ていくと、2020年・2023年ともSales/Serviceの売上が高いことはわかりますが、それと同時にPlatform・Dataの領域が伸びていることがわかります。PlatformはSlackが売上に寄与し、DataはTabluau・Mulesoftが寄与しています

カテゴリ 2020 2023
Sales 4,598 6,831
Service 4,466 7,369
Platform 2,787 5,967
Market 2,506 4,516
Data 1,686 4,338
合計 16,043 29,021

※単位はミリオンドル
一方でSAPはERPと言って、社内の基幹業務を司るシステムとなります。販売管理、調達・在庫管理、生産管理、財務・管理管理などカバーする業務分野は広いです。調達管理のFieldglassや出張経費精算のコンカーを買収して、ユーザに利便性をもたらしつつ、データはSAPと連携して一元管理するなどERPの領域を拡張しています。
社内システムと言っても色々あり、一般的にはSalesforceがやっているビジネスのほうが分かりやすいですかね。売上・時価総額ではSalesforceがSAPを上回りましたが、Salesforceがビジネス拡張している領域はマイクロソフトとも一部競合しているので、今後も売上を伸ばしていけるかは難しいところですね。
例えば、データ分析の分野でタブローとマイクロソフトPower BI(Business Intelligence)を比較した場合、デザイン性や分析機能ではタブローが優位性を持っていてもPower BIは通常業務で使っているエクセルなどマイクロソフト製品との連携がいいため使いやすさはあります。
また、コミニュケーションツールのSlackもマイクロソフトのTEAMSと競合することになり、マイクロソフトの資金力を考えると、SlackがZOOMのように落ちぶれていく可能性だって十分あり得るわけです。
今後もSalesforceが売上を伸ばしていくにはさらにビジネスITの領域を拡張していく必要があります。ServiceNowなどのワークフロー領域やAnaplanなどの計画業務領域への進出も考えられますし、企業情報システムの本丸であるERPを取りに行くことだって不可能ではないはずです。
B to Cのウェブ系サービスほど進化は早くないですが、ビジネスソフトも着実に新しい動きがあり、変化を感じられることは仕事していても楽しいところです。

ウーバーが世界的に市民権を得つつある

配車大手のウーバー・テクノロジーズが初の黒字化年度を経て70億ドル規模の自社株買いを発表ということで、同社の株価は11%も上昇しています。

先日の2023年決算では11億ドルの営業利益を達成し、2022年の18億ドルの損失からの大幅な好転を示しました。

Uber unveils maiden $7 billion share buyback after first profitable year By Reuters

思えば、2020年のコロナ真っ只中に購入したウーバー株は長期的に低迷していました。

他のハイテク銘柄が暴騰する一方で指を加えて待っている状況が長かったですが、ここに来て転換してきた感じがあります。ウーバーが出始めた頃、タクシー会社との軋轢があったり、Uber Eats配達員の自転車が危ないと、世間からは冷ややかな目で見られることが多かったですが、アメリカでは空港の案内にウーバーのピックアップ場所が出ていることなど生活の一部になっています。私も香港旅行で活用しましたが、ちょい乗りには便利でした。


(https://losangelestravel.jp/?p=3329)
日本では先に配車よりも、コロナ禍の恩恵として料理の宅配として有名になりましたが、最近では著名人の方が声を上げられていることや、現実問題として海外旅行者のタクシー捕まらない問題や過疎化した地方での交通手段がない問題の解決策としてライドシェア導入の機運は高まっています。家庭の不要品をメルカリで売ったり、airbnbを使って宿泊したりと、スマホの発達により「シェア」という概念が広まったのも大きいと思います。

Lyftという同業他社との競合もありましたが、世界的にはウーバーの普及率が高くシェア争いでウーバーに軍配が上がりそうです。新興企業との競合という点では、SNSやゲームなどの分野と異なり、現実世界の車を配車するという点が新規参入の障壁になっていて、この点でもそう簡単に配車でウーバーを超える企業は出てこないでしょう。
完全自動運転タクシーの時代になれば、WaymoやTeslaと競合する可能性はありますが、それはまだ少し先の話ですね。

生成AIが登場してもコンサル業界の地位に変動はなさそう


2023年は生成AIという言葉を大小様々なメディアで聞くこととなりました。ビジネスメディア「Pivot」では落合陽一さんが超AIによりコンサルは不要となると言われています。

現状のビジネスシーンでChat GPTが可能としているのは、翻訳や文章の要約、コーディング補助、あるいは、課題分析から問題点を整理するということだと思っています。動画の中では、データを集めて表を作成したりという作業は生成AIができるので、トップコンサル以外はいらなくなるという論調です。このような作業はコンサルの仕事の一部ではあるでしょうが、他にも事業改善のためにしていることはたくさんあるはずです。一部がAIに任せることが出来るとしても、事業会社側がAIに任せきりになることはなく、結局それも含めてコンサル会社に依頼するのではないでしょうか。

また、アクセンチュアは誰に聞いてもコンサル会社というでしょうが、会社の事業規模でいうと戦略コンサルよりもITコンサルのほうが圧倒的に大きいと思います。世間一般的にはコンサルというと企業の経営判断をサポートするような戦略コンサルをイメージしがちですが、アクセンチュアの利益の源泉はITシステムの導入がメインだと思っています(具体的に何割かは不明ですが)。世界のアクセンチュアの社員数は70数万人もいますが、その大部分はIT事業に携わっているはずです。

会計的な数字の観点で、アクセンチュアの2024年1Qの売上を見ていくと、16.2ビリオンドル(2兆3000億円!)となっていて、2022年1Q、2023年1Qと比較しても十分成長していることが分かります。

2022年1Q $15.0B
2023年1Q $15.7B
2024年1Q $16.2B

これは世の中の企業がより、デジタル化を進めようとしている証拠であり、生成AIにより人間のタスクは効率化されるでしょうが、それらも含めて、ビジネスITの市場規模は大きくなっていくんだと思います。Chat GPTは一つのブレークスルーでしたが、このようなブレークスルーは毎年発生するものではないので、少なくとも今後、10年ではアクセンチュアなどITコンサルの勢いはますます増加していくと読んでいます。

イギリス郵便局事件から考える富士通の将来性

イギリス郵便局に富士通子会社が納品した、システム「ホライゾン」の欠陥が
話題になっています。

イギリスの郵便局をめぐる史上最大規模のえん罪事件で、富士通の幹部が公的な調査委員会に出席し、会計システムに導入当初から欠陥があったことを、富士通関係者が認識していたと証言しました。

なぜこのようなことが起こったのか自分なりに考えていきたいと思います。

富士通は何で儲ける会社なのか?

富士通の事業は大きく下記の3つに分かれています。
①テクノロジーソリューション・・ システム開発、サーバなど
ユビキタスソリューション ・・ パソコン・タブレット
③デバイスソリューション  ・・ 半導体・電池

2022年度、2012年度の決算資料を見ているとこれらの事業別売上は以下のようになっています。

【2022年度】
テクノロジーソリューション:3兆1000億円
ユビキタスソリューション :2300億円
バイスソリューション  :3800億円

【2012年度】
テクノロジーソリューション:2兆9000億円
ユビキタスソリューション :1兆円
バイスソリューション  :5000億円

ソリューションが伸びている一方でユビキタス、デバイスといったモノづくり系は減少していることがわかります。NEC、日立などにも言えることですが、やはり中国、台湾とのコスト競争に負けてハードウェアからは撤退しています。また、日系だけではなく、IBMなどにも同じことが言えます。IBMThinkpadを2004年ころにレノボに売却していて、そこからはシステム開発などのソリューションビジネスに舵を切っています。


ホライゾン問題とは?

Horizonは2000年に稼働したが、それ以降、原因不明の不一致や損失が郵便支局支局長(サブポストマスター)から報告されるようになった。郵便事業会社は、Horizonは堅牢であり、支局長による支局口座の不足や不一致はHorizonに起因する問題ではないと主張していた。(Wikipediaより)
イギリスのシステム会社「ICL」を買収したことはソリューションビジネスに特化していく一貫だったと思います。
今回の一連の出来事を時系列に並べると以下になります。

1990年代・・イギリスICL社の子会社Pathway社がホライゾン(Horizon)を開発
1998年 ・・富士通がICLの単独株主となる
1999年 ・・ホライゾンをイギリス全国の郵便局に展開
2000年 ・・ホライゾンデータに依存した有罪判決が6件
2001年 ・・副郵便局長41名が起訴される
2002年 ・・副郵便局長64名が起訴される
               郵便局側はシステム不具合を否定
2002年 ・・ICLは社名をFujitsu Servicesに改名
2009年 ・・副郵便局長のアラン・ベイツは正義のための郵便局長同盟を設立
2017年 ・・ベイツ率いる郵便局長のグループが郵便局に対して集団訴訟
2019年 ・・原告側が勝訴。原告それぞれ2万ポンド(現レートで376万円)支払われた。
2024年 ・・『ミスター・ベイツ vs 郵便局』ドラマが2024年1月1日から放送
      (再び世間と政治の注目を集める)

Horizonの前身システムから訴訟になるようなシステムバグが潜在していたようで、中々複雑なシステムだったんだと思います。バグを作ったのはICL社・Pathway社の問題ですが、ITシステムである以上、バグはつきものというか、郵便局長からおかしいという声も多くあったのに、郵便局側・裁判所側が頑なに不具合を認めなかったことも大きな問題でしょう。一度、システムが納品されると、それ以降は郵便局のシステム部門で保守していたはずでなぜシステム不具合が表面化しなかったのかは疑問です。
富士通社が単独株主になったのが1998年で現在は富士通子会社なので、今後、富士通がどの程度の賠償責任を問われるかは不明ですが、現時点では「道義的責任」があると述べるに留まっています。システム納品時には受入側(郵便局)のテストも通った上で納品するので、それ以降は郵便局側が不具合と認めなかったので、郵便局側・司法の問題な気もします。
なぜ今、クローズアップされるのか?について。このタイミングでドラマを制作したりと、ドラマは見ていないですが、富士通にも責任の一端を押し付けようとしているのではと勘ぐってしまいます。事実、X上ではFujitsuを非難する声が多く上がっています。。

今後の富士通が抱えるリスク

日本のSIビジネスに特に顕著なのがシステム開発プロジェクトを実行する際、自社では開発をしないで下請け・孫請けに仕事を依頼することが慣習に行われています。こうなるとシステムの中身を自分たちは知らないで、子会社・下請け会社の技術・コンサル力に依存することになります。本来であれば、システム会社を買収するにしても富士通社が持っている開発方法論を適用していったり、富士通社員も子会社のプロジェクトに参画して細かいところまで見ていく必要がありますが、そういうことをしていないんだと推測します。私自身も過去、日系大手SIerの仕事に関わったことがありますが、みんないい人ではあるんですが、自分たちで仕様を考えたり、開発したり、コンサルするということをしないです。問題が発生したときに顧客と下請け会社の板挟みになり、そこをどう取り持つかに注力して本質的な問題解決を図ろうとしないというか・・。
東大生・京大生の就職人ランキングに上がるアクセンチュアアビームコンサルティングなどITコンサル会社も同じような業種ですが、彼ら・彼女らは自分たちで考えて、自分たち手を動かしてシステムを作っていきます。東大生・京大生の就職ランキングに富士通NECが入らないのは収入の問題だけではなく、日系老舗IT企業では生きた知識・スキルが手に入らないことを東大生・京大生はよく知っています。
今後も富士通NEC・日立も)はITビジネスを拡張していき、この事業の売上は増えていくんでしょうが、同じような問題が発生することはありえますし、ビジネスリスクとして考えておく必要があります。