DX御伽噺:イマドキ開発のちょっぴり怖い話
夏のリレー連載2024この記事は夏のリレー連載2024の3日目の記事です。
暑い日が続きますね。そんな時には寒気を感じるような怖い話が聞きたくなります(よね?)。
ということで、今日は最近出てきている公開情報などをベースに、筆者が怖いと思ったことに基づいた作り噺をお届けします。登場人物や組織名は架空のものですし、見解については筆者個人のものであって所属会社の見解などは一切関係ありません。それでは、はじまりはじまり～!!
トータス社のこと
#あるところにトータス社という老舗眼鏡メーカーがありました。庶民の手が届く高品質眼鏡で一世を風靡したあとはコンタクトレンズやサングラスなどの周辺事業にも手を広げて堅実な成長を遂げた会社です。
業務拡大に成功した裏には、数十年前から取り組んだ業務のシステム化がありました。書類中心で仕事をしているライバル企業に先んじて営業、生産、物流などの基幹業務の管理を支援するシステムを構築・運用していたのです。
長年にわたり業績を支えてくれたシステムですが、機器が老朽化してきていることにあわせ熟練エンジニアたちの引退が近いこともあり今後を見据えた再構築を考える必要がありそうです。
亀山社長:「せっかくコストをかけて再構築するのですから、最近の動向を踏まえた技術を選定してデジタルトランスフォーメーションとやらを進めるべきだと思うのですよ[1]。亀田システム部長、今回の刷新をどうすべきかアイデアはありますか。」
亀田部長:「そんなこと急におっしゃられても、我々は現行のシステムについては詳しいのですが最近の技術はニュースで見るくらいの知識しかありません。しかも、扱う業務ごとにシステムを構築しているので業務全体を見通した戦略なんてとてもとても。移行後の望ましい姿のイメージなどございますか、亀梨営業本部長?」
亀梨本部長:「いやいや、我々はモノを売るのが仕事ですから、顧客提案から受注処理がサクッと結び付けられれば何も文句はありませんよ。あ、でもマーケティング技術の流行は移り変わるから、その時その時の技術を採り入れられるようにしておいてもらいたいな。餅は餅屋、そのためにどういうシステムを構築すべきかを考えるのはシステム部門の仕事でしょ?」
亀田部長:「そんなに曖昧な要求を持ってこられても、、、色々な状況に対応できる拡張性を備えたシステムにしようとするならばエース級の開発者を総動員してキッチリと作り込む必要があるのでコストも高くなりますよ。今出たようなお話を全部取り込むとすると、、、エンジニアも増強しないといけないですし、概算ですがこのくらいの投資は覚悟していただかないと。」
亀山社長:「いやいや、わが社も無尽蔵に貯えがあるわけではないからちょっとこの額はねぇ。。。期待効果が見積れれば投資できない額ではないけれど、システム刷新で売り上げが上がるというわけでもないし。」
喧々諤々、会議は踊れど一歩も進みません[2]。
ふと、亀山社長は先週のパーティーで知り合ったラビットコンサルティングの兎塚CEOのことを思い出しました。彼は最近の技術動向にも明るいようで、IT技術の未来について熱く語ってくれていたのです。そうだ、彼に相談したら良いアドバイスをくれるかもしれない。
ラビットコンサルティングの提案
#亀山社長は兎塚CEOに連絡して、何か良いアイデアは無いか尋ねてみました。するとどうでしょう、兎塚CEOが状況をヒアリングしに訪問してくれると言うではないですか。忙しそうに飛び回っているCEOを思い浮かべると少し申し訳ない気もしましたが、相談だけならサービスでやってくれるとのことなのでお願いしてみることにしましょう。
亀山社長:「実はかくかく しかじかで、途方に暮れているのですよ。システム刷新は早晩必要なのですが、どうせ作り直すならDXを見据えた先端のシステムに作り替えたいと思っています。しかし、最新技術に明るい人材を集めて1から構築するとなるとお金も時間も大量にかかりそうで。」
兎塚CEO:「社長～、そんなに遅い計画をたてちゃうなんてアンテナ低いっすよ。イマドキそんな、世界で一番遅い[3]ような計画をたてちゃうなんて、石橋を叩きすぎてヒビ入っちゃってるんじゃないですか？？」
亀山社長:「ふむ、CEOには私の要望を叶えてくれるアイデアがあるということですか。」
兎塚CEO:「まずですねー、全部を自分達で作るつもりで計画してるんじゃありませんか。これだけ技術がオープン化してきている時代にそんな発想がナンセンス。世界的に実績のあるパッケージやオープンソースで公開されている技術を組み合わせて御社好みのカスタマイズをちょちょいと入れれば、1から作るのと同じようなものが半額、いや1/10くらいのコストで作れちゃうんですね。既製品と同じようなものを頑張って作り出すことを車輪の再発明 って言うことはご存じ？？」
亀田システム部長:「いやいや、弊社のビジネスには独自の業務プロセスがありまして、既製品で賄うことは難しいのです。例えば・・・」
兎塚CEO:「うーん亀田さんは技術の進歩をご存じない。そりゃ完成品を買ってきて使うのは無理かもしれないですがね、最近の技術は実現したいことの基礎部分を提供するもんなんですね。なのでデータ管理パッケージを買ってきてその上に御社の業務に基づいたアプリケーションを構築すれば業務プロセスに寄り添ったシステムが開発できますよ。しかもセキュリティやら監視やら、構築に手間がかかる部分に関してはサービス提供してくれるところもありますから、御社が本当に必要とする部分に開発リソースを集中することでコストが最適化できますしね。」
この業界では使われやすい格言で、「既に確立されている技術を(知らずに、または無視して)再度1から作り直す」ことを直感的に理解し易い「車輪」をつかって表しています。
筆者は右も左も分からない新人エンジニア時代に配列のソート(並び替え)処理を1～2週間かけて自作した記憶があります。お勉強込みという意味では良い経験になったものの、アリモノを使えば(選定・テストを含めても)数時間で終わる仕事を、まさに10倍以上のコストをかけてやっていたことになりますネ。
怖いというよりお恥ずかしい話でした。
亀山社長:「さすが、技術動向に明るいとの評判は伊達ではありませんね。しかし、弊社には最近の技術に詳しい技術者が少なくて、、、」
兎塚CEO:「そう言われると思ってましたよー、実はシステム刷新のお手伝いをするサービスも取り扱っていましてね。他社さんでも導入実績のある技術を使って御社のシステム刷新のお手伝いができますよ。必要なリソースはこちらで準備しますから技術者のことは心配する必要もなし！しかも御社の要望をFBしながらアジャイルに開発を進めて、そうですねー、、、うんザックリですけどお話のとおり御社計画の1/10くらいには納められそうです。」
ただほど高いものはない という格言が一瞬頭をよぎりましたが、このまま自社だけで頑張っても埒が明かないと感じ始めていた亀山社長、ラビットコンサルティングの提案に乗っかってシステムの刷新をお願いすることにしました。
システム刷新は続くよ
#さて、トータス社のシステム刷新プロジェクトが開始されることとなりました。キックオフに集まったメンバーを見て、亀山社長は一抹の不安を覚えます。
亀山社長:「兎塚さん、兎塚さん、御社のエンジニアさんはずいぶんカジュアルな感じと言うか、皆さんお若そうに見えるのですが最近の技術者さんはそういった感じなんでしょうか。。。」
兎塚CEO:「あ、亀山社長。その辺の開発体制については弊社側のリーダからご説明したほうが良いですね。兎樫クン、こっちの体制をサマってあげてもらっていいかな。」
兎樫チーフ：「確かに今回のプロジェクトは現場レベルでは若手メンバーが中心になります。経験面でご不安もあるかと思いますが、弊社は開発支援にAIを活用していましてね。AIのサポートを活かせるので多少の経験不足はカバーできますし、最終的な納品物の品質は私がしっかりとチェックしますのでご安心ください。」
亀山社長:「なるほど。昔はどこも弊社のようにエンジニアを何年もかけて育成しないと使いものにならなかったのですが、AIってのは凄いものなんですね。」
そして順調に開発は進み、ドラフト版のテストに進みました。
亀田システム部長:「兎樫さん、この条件で受注を進めようとするとエラーになりますよ。これは業務上ありうるパターンなので代替処理に入る仕様にしたはずですが。」
兎樫チーフ：「うん、確かにこの挙動はバグですね。兎山くん、君の書いたこのコードだけど、ここの仕様と挙動が合ってないみたいなんだ。修正しちゃってくれるかな。」
兎山エンジニア：「え、ボクのせいすか？？あー、このソースはAIが作った部分なんで ボクの責任じゃないっすね。AIに直させて下さいよ。」
昨今の生成AIの技術進歩は目覚ましいもので、ソースコードであればある程度動作しそうなものを生成させることができます。上手く使いこなせば劇的な効果を生み出すこともできる可能性を感じますよね。
とはいえ、現時点では「AIが責任を取る」ことはできていないので、「経験が浅くてもAIがサポートするから大丈夫」というのは少し危険な香りがします。
少し前のGoogleゴリラ問題[4]や大阪万博中止問題[5]ではないですが、今のAIは収集した情報や判定の条件に偏りが生じた場合、事実と異なる結果を出力してしまうリスクから逃れられません。
これから進歩していく領域なのでどう活用するのが正解なのかは分かりませんが、何か問題が起きたときに「このコードはAIが生成したものだから直せません」という事態に陥らないよう、用法には注意しつつ利用側のスキルも育てていきたいものです。
兎樫チーフ：「え、誰もココの部分直せないの？しょうがない、私が修正しますよ。うーん、、、ちょっと根が深いなぁ。直せなくはないけども対応を入れると私の作業が取られるからちょっとスコープ調整が必要そうだな。亀田さん、この機能は代替のフローも発生しないですしスタート時には正常系だけが通常動作すれば業務には問題ないと思われるのですが、エラー時動作の作り込みなどは調整できませんか？」
亀田システム部長:「うーん、さすがにプロジェクトのスコープにも関わるので社長にも確認しないといけないですが、、、このバグが直らないと業務には使えないですし、作り込みは保守フェーズでの対応という形でちょっと確認してみますよ。」
少し前の情報になりますが、アメリカではアジャイル開発を採用している企業が多数派なのに対して日本ではアジャイルの採用がなかなか進んでいないという状況のようです。
原因は定かではないのですが、1つには日米のソフトウェア開発に対するスタンスの違いがあるように思います。Jenkinsの川口氏がAgile Expoで語ってくれた内容ですが、アメリカのソフトウェア開発は子育てのような感覚があるということです。相手が子供のように、日々成長していくものであればできるだけ寄り添って短いループで改善を回すという考え方は自然ですよね。対して日本では家造りのようにちゃんと作ったものを修繕しながら使い続けていく考え方が近いようです。
だから日本にアジャイルが馴染まないんだ なんて言うつもりは無いですし、日本では日本の文化に合った開発スタイルがあるのだろうとは思います。しかし、アジャイルの形だけを真似るスタンスであれば、先の川口氏の講演で述べられた「こんなに良いアメリカ車がなんで日本で売れないんだ！(そもそも日本では道路や駐車場のサイズが違うから一般的な人は買わないよ)」といった状況に陥ってしまいがちですよね。
なんとかスコープ調整もまとまって、最後のシステムテストを進めている段階で、兎塚CEOから亀山社長に連絡が入りました。
兎塚CEO:「亀山社長、実はご相談事項が持ち上がってましてね。今回のプロジェクトの総コストですが当初見積もりよりもだいぶ高くなってしまいそうなんですよ。」
亀山社長：「なんですって！？開発も順調に進んで、あとはシステムテストで問題が無ければ稼働できる状況だという報告を弊社の亀田からは受けているのですが。」
兎塚CEO:「いやー、まいりました。今回のプロジェクトで採用したオラオラ社のパッケージに突然ライセンス料の値上げ通告がありましてね。なんでもオラオラ社が買収されてしまったために親会社の意向で次回の契約からはライセンス料が変わってしまうんですよ。もちろん保守契約を結ばずに現行バージョンを使い続けるという戦略も取れなくはないんですけどね。」
亀山社長：「いや、さすがに保守されないパッケージを使ったシステムで業務を行うのはリスクが高すぎますよ。うーん、予算の見通しはだいぶ変わるのですが、、、致し方ないですね。それでも弊社で最初から開発するよりはコストが抑えられそうですし。。。」
システムに限らないお話ですが、業務を行うにあたってのコアにあたる技術を他者に握られてしまうと意思決定において他者の意向に逆らう余地がなくなってしまいます。
ことシステム開発においては、OS/開発言語/ミドルウェア/フレームワーク・・・と様々な技術を組み合わせて成果物を作成するという性質上他者の影響を受ける可能性がある領域が広くなってしまいます。
OSSや割安な有償技術を採用することは一見妥当な選択にも思えますが、昨今はJavaやVMware、Docker Desktopなど様々な技術においてライセンス変更の話題に事欠きません。無償や低コストで利用できることは魅力的ではありますが、システム実現にとってコアとなる技術領域についてはコスト面だけで決定することはリスクを伴います[6]。選定においては何か問題が発生しても継続できるように対策をたてたり、提供元が安定してサービス提供できるように妥当な対価は払ったりすることも検討しておいたほうが良さそうです。
システム稼働、そして混沌へ
#紆余曲折はありましたが、無事システムの移行は完了して新システムでの業務が開始できました。イマドキっぽいユーザインタフェースも好評で、兎塚CEOに依頼してよかったと胸をなでおろした亀山社長。順調に業績を伸ばしていったある朝、営業本部長からの電話で目を覚まします。
亀梨本部長:「社長、大変です。今朝から業務システムが使えなくなりました。本日分の業務データは全部システムに入っているので、このままでは今日は仕事になりません。」
亀山社長：「え、ラビット社は保守対応できていないのですか。」
亀梨本部長:「兎樫さんには連絡して対処を依頼したのですが、ラビットさんのほうでも原因が突き止められていないみたいなんですよ。このままでは本日分の出荷もできないですし、顧客とのアポも漏らしてしまうかもしれないです。」
亀山社長：「うーん、、復旧を待っていてもいつになるか分からないということですか。今日の分の予定であれば誰かメモに残したりしてないですかね。まずは分かる情報を共有してできる業務から進めていくことにしましょう。並行して亀田さんにも調査をお願いしておきます。」
システム開発に携わる方ならご存じかもしれないですが、ある要素に問題が起きることでシステム全体の動作を損なうような要素を単一障害点と呼びます。
冗長化などによって単一障害点を生まないようにシステムを構成しましょうのようなお話は耳にされた方も多いのではないでしょうか。
その文脈とは少し違いますが、業務をシステムに一本化するということはシステムそのものを単一障害点にするということだと筆者は考えます。例えば以前にご紹介した全銀システムの振込トラブルやグリコやユニ・チャームの出荷トラブルなど、昨今はシステム起因の業務停止トラブルが増えてきているように思います。
もちろんシステムトラブルが起きないように心掛けておくことは前提なのですが、トラブルを完全に避けることは不可能ですので状況によってはシステムを介さずに業務を続行できるように構えておくことも大切です。頑健であるということはその分のコストをかけることに他なりませんので、所要コストと事業継続の要求を比較しての判断になるかとは思いますが。
亀田システム部長:「兎樫さん、このセーフティボム社って今回採用したセキュリティサービスですよね。先程障害についてのプレスリリースが出ていましたが、今回の事象の原因ではないですか。」
兎樫チーフ：「ふむ。アップデートした機能に問題があってOSの起動をブロックする事象ですか。まさしくこれが原因みたいですね。ちょっと回避策を試してみるのでお待ちください。」
亀田システム部長:「お、回避策を入れたらうまく起動したみたいですね。それでは弊社側でもこの状態で他に影響が無いか検証を進めます。御社側では恒久対策を進めていただけますか。」
昨今のシステム開発は公開された技術を組み合わせることで効率的に価値を提供できるようになってきています。しかし、その帰結としてシステムを「どこまで保証するべきか」については非常に難易度が上がってきています。最近発声したCrowdStrike起因のシステム停止トラブルやpolyfill.ioによるマルウェア混入などの事例は開発したアプリケーションが持つ問題というよりもシステムに含まれる要素に起因した、アプリケーションそのものに問題が無くても発生する事象になります。
このように問題の発生前には予測して備えることが困難な事象に対して、何をどこまで保証するかを考えることの重要性は高まっていくように感じます。
原因は分かってなんとか業務は再開できましたが、待てど暮らせどラビット社の恒久対策は実施される気配がありません。
亀山社長：「ちょっと兎塚さん、先日起きた障害の対策はまだできませんかね。確かに回避策で業務はできているのですが、毎日回避策を実施する必要がある状態なので利用者からも不満が溜まっているんですよ。」
兎塚CEO:「社長、対応が後手々々で申し訳ない！言い訳ですけど弊社は大変な状態でしてね。御社では幸い実害を出さずに済んだのですが、他社さんでは出荷停止状態になってしまって損害賠償を請求されてしまっているんですよ。御社を軽く見ている訳では決してないんですが、ちょっとその辺の対応にリソースを割かれてしまってなんとも対応が遅れてしまっている訳でして。」
亀山社長：「なんと、損害賠償ですか。それで御社の経営状態は大丈夫なんですか。自分の心配ばかりで申し訳ないんですが、御社に倒れられてしまったら弊社のシステムを保守できるものか心配で。」
兎塚CEO:「いや、ワタシとしてもなんとかしたいところなのですが、賠償額によっては存続が厳しいかもしれない状況です。金策にも走ってはいるんですが、社員の給料もちょっと遅れてしまっていましてね。。。社長、そこでご相談なんですが弊社の兎樫を雇っていただくことは可能でしょうか。実は兎樫から退職の相談を受けていましてね。御社のシステムを把握している兎樫であれば、win-winなお話になるんではないかと。」
亀山社長：「兎樫さんが優秀なのは刷新プロジェクトで十分に感じました。ご本人に依存が無いようであれば、御社での給与水準と同程度で構いませんから是非とも来ていただきたいですね。」
こうして兎樫チーフを迎え入れることになった亀山社長。システム部門の亀田部長とは時々言い争いをしているようなのですが、俊敏な兎樫チーフと堅実な亀田部長ですから意見が合わないことは仕方がないこと。まだまだゴールとは言えませんが、ゆっくりでもトータス社に合ったシステム開発文化が作っていけたら良いですね。
なんでも新しい技術を使って効率よく というスタンスにはリスクが伴いますが、逆にすべてを堅実に自分の力で というのも世の流れに遅れていくリスクがあります。
筆者は「ではどうしたら良いか」という問いに対する回答を持ち合わせていませんし、神ならぬ人間にはどんな条件にも当てはまる解答は不可能[7]です。
現時点ではそれぞれが置かれた状況に対して「どのリスクをとってどこはリスク回避するべきなのか」を選択していくしかないものだと考えます。分からないながらも決めて進んでいかないとならないことが一番怖い話なのかもしれませんね。
あとがき
#思いのほか長い文章になってしまいましたが、お付き合いいただいた皆様ありがとうございました。
最近、今年に入ってから特に、システム絡みのトラブルの話を聞くことが増えたような気がします。こういったトラブルの事例を他山の石として、ヒヤっとするのは物語の中だけになってくれることをお祈りして本日の締めとさせていただきます。
経済産業省のいわゆる「2025年の崖」レポートでも老朽化/サポート切れのシステムを使い続けることで、データ利活用の遅れや保守コストの増大などによる経済的損失が危惧されています。 ↩︎
この時点で背筋が寒くなった方もいるかもしれませんね。さきの経済産業省レポートでも述べられていますが、いわゆる「デジタルトランスフォーメーション」とはデジタル技術の採用によるビジネスの創出や改変を意味します。つまりは経営者や事業部門も含めた関係者がそれぞれ果たすべき役割を果たす必要があります。まあ、わかっちゃいるけどなかなか理想どうりには、というところでしょうか。 ↩︎
はい、お気づきだとは思いますがこの御伽噺は「うさぎとかめ」の本歌取りでございます。とはいえシステム開発で競争して開発することはまずないと思いますので、この後は競争開発する展開でも堅実なかめさんが最後に勝つ展開でもありません。 ↩︎
Googleフォトの画像認識が黒人の写真をゴリラに分類してしまった問題です。10年近く前の事象ではあるものの、現時点でも有効な対策はできていない模様で類人猿の分類をしない形で対応されているようです。機械的に判定をする場合はこのような誤認識は避けようがないものだとは思いますが、間違いがセンシティブな部分で出てしまったためにひと騒動になってしまいました。最近ではセンシティブな部分に対処するためのファインチューニングによって誤った結果を導いてしまう事例もあり、機械的な判定と人間的な反応との隙間を埋めるのは難しそうです。 ↩︎
大阪万博の開催について賛否が盛り上がっていた時期に大阪府の提供するチャットボットが大阪万博は中止になったと回答をしてしまったためにちょっとした盛り上がりになりました。生成AIはその仕組み上、確率的に妥当に見える会話を作り上げるものであって提供するものの正しさを保証するのではないのですが、受け取る側が正しいものだと誤解(曲解?)するとこのようなトラブルに繋がり兼ねないという良い事例だと思います。 ↩︎
企業とは本質的に活動によって利益をあげることが目的なので無料や割安で提供されるものについては何らかの収益意図が潜んでいる可能性は否定できないものと思います。利用側にとって魅力的な選択肢とは反対側では提供側が「得られる可能性がある利益」をとっていないということであるはずです。提供側が収益を必要とする状況になったり、買収などで提供側のスタンスに変化が起こった際には、提供側の都合でコストが変化する可能性があります。 ↩︎
いや、これが完璧な解答なんです なんて言う人からは全速力で逃げておくことをお勧めします。その人が実は神様だったら貴重な解答を逃がすことになってしまうのですが、、、皆まで言うのはやめておきます。 ↩︎
