元CTOに伺うWebSphereの軌跡と展望
今年、IBM MQとDb2は30周年。WAS(WebSphere Application Server)は25周年を迎えます。アニバーサリー・イヤーとして3製品に関わりのある方々へのインタビューを1年を通じて定期的に行っています。今回は、IBM技術理事(DE：Distinguished Engineer)、CTOのご経歴がある山本宏氏にインタビューを行いました。WAS、MQ、Db2の思い出や今後の期待などを伺いました。
山本 宏 (写真右)
組み込み系マイクロコードの開発を5年間従事したのち、システムエンジニアとして主にCORBAに代表される分散オブジェクトテクノロジーのエンタープライズシステム本番環境適用をWebSphere Application Serverの展開を通じて実現。2008年にIBM Distinguished Engineer、2013年にGlobal Electronics Industry CTOに任命後2018年IBM退社。同年東芝に入社後Digital Innovation Technology Center 長＆Digitization CTO＆常務執行役員として4年間勤務。2022年9月よりNECにてManaging Executive Chief ArchitectとしてOT/IT領域、Hybridクラウド及びDXの技術戦略の責任者として現在に至る。
中島千穂子 (写真左)
日本アイ・ビー・エムに入社後、1995年よりISEにて分散系DB2のスペシャリストとして、お客様プロジェクトや社内技術支援を担当。2003年よりMQを始めとするWebSphere系のAIM(Application Integration Middleware)、BPM(Business Process Manager)製品の技術支援を担当。2008年よりWebSphere事業部にて、Technical Sales ManagerとしてMQ, WMB(WebSphere Message Broker), BPMなどの多くの提案及び社内技術者のスキル育成を行う。その後、大手銀行担当アーキテクトとして様々な提案をしていく中で、API Connect, BPM, App Connectなどの提案および構築支援を実施。
1. 山本様のご経歴をお聞きしてもよろしいでしょうか。WASとの関わりやその時の印象など、お聞かせください
山本氏）
私はIBMの大和研究所で、前職と同じ組み込み系のファームウェアやOSのデバイスドライバの開発などを1988-1993の5年間担当しました。
中島氏）
ハードウェアに近いところですよね。
山本氏）
はい、プリンターやATMの制御部分の開発を担当した後、1993年にSEになりました。この頃はちょうどオブジェクト指向のトレンドがあった時期でした。
私はApple社が作った分散オブジェクトベースのOpenDocという複合文書のテクノロジーを担当することになり、テキサス州のオースティンで開発の仕事を行っていました。
その後日本に帰ってきて、主に開発者向けにOpenDocの普及活動を2年ぐらいやりました。当時MosaicやNetscape(1990年代米国企業のWebブラウザー・ソフトウェア)の出現により急速にインターネットが立ち上がった時期で、結局OpenDocの技術はNetscapeに吸収・統合となりました。
SOM ※1とDSOM ※2という技術を聞いたことありますか？2000年頃から関わった某自動車OEM様の部品表プロジェクトで、他社の分散オブジェクト（CORBA）製品と相互接続する必要があったのですが、DSOM（製品名ComponentBrokerのちのWAS）が使われました。このプロジェクトを2年くらい担当しました。その後、2002年に日銀が対外系ネットワークをCORBAベースにすることになり、市中銀行側に配置されるゲートウェイ（B-Gate）の設計・開発に従事することになりました。
※1 SOM(System Object Model)：オブジェクト指向の共有ライブラリシステム
※2 DSOM(Distributed System Object Model)：CORBAベースの分散バージョンの共有ライブラリシステム
山本氏）
このプロジェクトは0からの設計ということで、忘れられないプロジェクトでした。日銀の仕様書に基づいて、GBS(現在のIBMコンサルティング)のデリバリーチームと一緒に設計をすることになりました。ベースのアーキテクチャーを私が考えることになり、電文が流れる８つの論理パスの実装が大変だったことを覚えています。実行環境はWASを使うことを基本方針としました。WASは基本的にWebのアプリケーションサーバーとトランザクションマネージャーという2つの顔があります。私はトランザクションマネージャーとしての品質には自信があったので、そのトランザクションマネージャーをベースにどのように論理パスを作るかが鍵でしたが、EJB(Enterprise JavaBeans)をベースに設計することにしました。
当初ステートフル・セッションBeanを使うか、Message-driven BeanのQueueで論理パスを実現するかで議論が分かれましたが、検討のすえMessage-driven Beanを使う結論になりました。一部のメンバーはC++での独自開発を主張した人もいましたが、アプリケーションサーバーを使った方がマイグレーションとか、拡張性などで優位性があると考えてWASでいくことに決めました。
あとはトラブルがあった時のことを考えて、テキサス州にあるIBM Austin LabのWAS開発部門のメンバーに設計方針・アーキテクチャーを説明しフィードバックをもらうと共に、研究所のお客様支援サービス部門も巻き込んで万全の体制で開発に臨みました。大変な仕事でしたが、外国為替、国債、当座預金など、日本の金融基盤の一翼を担えたことは今でも誇りに思っています。
中島氏）
実際にトラブルはありましたか？
山本氏）
トラブルは、DB2とMQの同期処理の2-Phase CommitのところでMQ側でトラブルがありました。
中島氏）
リソースマネージャーの方がダメだったということですね。
山本氏）
はい、そうでした。だけどすぐに直してもらって、トラブルはそれぐらいだったと思います。
市中銀行側はほぼ全ての銀行が日本のあるSIer様が作った流量制御パッケージが前提になっていました。市中銀行から日銀ネットにつなぐためには同期・非同期処理変換を行う必要性がありましたが複雑な処理にはしませんでした。複雑な設計にするとトラブルは起きやすい傾向にあると思います。基本的にはベースの機能を使い倒して仕様を満たすことに徹しました。DB2に関してはリソースマネージャーとして長い歴史があったので、安定していたと思います。この時のシステムはこれまで何度かマイグレーションをしていると思いますけど今でも動いていると聞いています。
その後は、製造業様のWS-AT(Web Services Atomic Transaction)のプロジェクトを担当しました。WS-ATは、WASがトランザクションマネージャーになってインターネット越しに2-Phase Commitを実現する技術です。平たく言うとインターネット上の複数のデータベースを更新する際、どれか一つでも更新が失敗した場合、他のデータベース更新もすべてロールバックさせる技術です。当時WASのトランザクションマネージャーの開発部門にいたIan Robinsonとお正月をまたいで毎日電話会議をし、WS-ATの仕様を理解・確認したうえで、テストシナリオ作成とテストを繰り返し実施しました。数多くの障害対応をすることになりましたが、WS-ATの世界初のプロダクションシステムだったのでチームメンバーの士気は高かったです。
それが終わってからはODR※3、WXD(WebSphere Extended Deploymentの略)を担当して、ひたすらオンサイトでのODRトラブル対応をしていました。WXDの仕事をしているうちに、2008年にDEになりました。2010年にはイギリスのワイト島（Isle of Wight）で、東芝とIBMが組んでスマートコミュニティーのプロジェクトが始まりました。これがきっかけでIoT技術を担うことになりましたが、その後、2013年にGlobal Electronics Industry CTOに任命されました。
※3 ODR：WXDで提供されるコンポーネント。HTTPリクエストおよびSession Initiation Protocol(SIP)メッセージがバックエンド・アプリケーション・サーバーにフローする際に経由するゲートウェイ。
中島氏）
なるほど。以前、山本さんとMQTT(多数の通信主体の間で短いメッセージを頻繁に送受信する用途に向いた軽量なプロトコル)の話などもした覚えがあります。
山本氏）
そうですね。スマートメーターデータ転送の前提がMQTTでした。
中島氏）
アプリケーション開発プラットフォームとしてのWAS、トランザクションマネージャーとしてのWASやMQなど色々と担当されてきたのですね。
山本氏）
でもJSPとか、UIのところとかはあまり担当しませんでした。トランザクションの方を担当していました。中島さんは私と初めて会ったのを覚えていますか？
中島氏）
私がMQワークフローをやっていた時ですね。ビジネスプロセスを書いてちゃんと動かせるかみたいな所をやっていた頃だと思います。
山本氏）
そうそう、MQワークフローを必死になってフローチャート書いていましたね。中島さんもたくさんWAS/DB2の経験があると思いますが、当時どんなことをやりましたか？
中島氏）
私は最初ISE(IBM Systems Engineering)でDB2から入って某保険会社様などを担当しました。その後、あまりISEで担当プロダクトを変えることは少ないですが、MQや後にBPMになる製品などAIM製品の担当となりました。ISEでテクニカルサポートを担当した後は2008年にWebSphereの製品部門に移ってTechnical SalesのManagerを2年やって、その後2010年から金融CITA(お客様担当のアーキテクト)になりました。
山本氏）
そうなんですね。
中島氏）
金融CITAに移った後もWASやMQはもちろんAPI周りやBPM、App Connectなど、WebSphereとは何となく離れることなくきたと思います。
2.これまで様々なご経験をされている中で、WAS関連のプロジェクトで特に印象に残っているエピソードがあればお聞かせください。IBMの製品開発に対する取り組みやサポートについての感想もあればお聞かせください。
山本氏）
これまで多くの障害対応をしてきましたが、先ほども触れた関西のお客様でのWXD、ODRのトラブル対応はすごく大変だったことを覚えています。ほぼ毎週のように障害の電話をお客様側のマネージメントサイドから受けていたのですが、システムを入れた担当者としてはトラブルを放っておくこともできませんでした。
中島氏）
トラブルシューティングの時にこんな仕組みがあればよかったと思うことは何かありますか。
山本氏）
リグレッションテストの自動化やテストケースの自動実行があればいいなと当時本当に思いました。複数のパッチ適用がお客様のアプリケーションに悪さをしない事を保証する仕組みの必要性を実感していました。折角IBM製品を選んでくれたにもかかわらず、お客様に迷惑をかけなかなか期待に沿えなかったことは今でも痛恨の思い出として残っています。
中島氏）
山本さんは何もない状況から最初にまずやる人だったと思います(笑)。山本さんは苦労して大変だったと思いますけど、2社目3社目の時は製品がだいぶ安定して、ノウハウも蓄積されて、山本さんの経験や苦しさが後に繋がってきていると思います。
3. 今年WASは25周年を迎え、現在も多くのお客様に継続してご利用いただいています。これからもWASやIBM製品がお客様に選ばれ続けるために必要なこと、製品やIBMへの期待をお聞かせください。
山本氏）
本質的な話になりますが、WASはクラウドでいうと、PaaSのエリアだと思います。SaaS、PaaS、IaaS、EDGEがありますが、お客様の関心はSaaSに移っています。製品の機能についてお客様にいくら説明しても、それはお客様からしたら全く響かない時代になってしまいました。お客様はビジネスバリューが何か？、どうすればイノベーションを起こせるのか？が最大の関心事です。IaaS、PaaSのレイヤーはある意味コモディティになりつつあり、テクノロジーの尖がりだけでお客様に訴求できない状況になっています。
WASやIBM製品がお客様に選ばれ続けるためには、お客様のイノベーションの実現がまずありきで、それを最初に考える必要があります。イノベーションが実現できたのち、蓋を開けたらWASが使われているという仕組みに持っていかないといけないと思います。そうしないとお客様の関心とIBMのギャップは埋りません。WASありき、所謂プロダクトアウトではお客様には受け入れてもらえません。
以前ODRがお客様に受け入れられた理由は、サービス停止なしに新バージョンに切り替えられたからでした。サービスを止めないでマイグレーションできるところに、お客様にとっての価値がありました。お客様の要件、イノベーション、あるいはトランスフォーメーションはインダストリーごとに違うと思いますが、そこを起点にしないとどのITベンダーもお客様には選んでもらえない状況です。
最近のAWSなどに代表されるHyper Scalerは、お客様の環境や課題に興味がないのでは？と思うことがあります。自分たちのマネージドサービスの宣伝に精一杯のように見えます。皆さんにはテクノロジーボトムアップだけでなく、ビジネスインペラティブ（ビジネスの不可欠な要因）もキャッチアップし、その間を埋めることをやってほしいです。
中島氏）
そのためにはパートナー様やコンサルティングチームとの協業が重要だと思っています。お客様に一番近いところにいますから。それらのチームの人達と密に協業してお客様の課題は何かを理解した上で、製品機能を持って行くのではなく、何がどうよくなるかを示していく必要がありますね。
山本氏）
すべての事に言えるのは5W1Hが重要ということです。WAS、Db2、MQはHowにあたりますが、その前にWhy、Whatが明確になっているか？がこれからの技術者には求められると思います。
DEでインダストリーの仕事をするようになり、当初CXOレベルのお客様とのコミュニケーションに苦労しましたが、あの経験はテクノロジーがどうあるべきかを考える良い機会だったと思っています。そいう意味ではアカウントプランニングはとても重要で、自分には関係ないと思うTechnical Salesの人が多いかもしれないですけど、アカウントプランニング・セッションに出てみると、お客様の課題がよく分かります。自分の専門分野でなかったとしてもお客様の視点を知り得る貴重な経験になると思います。
中島氏）
今IBMも変わりつつあります。まだ道半ばだと思いますが、製品部門はSaaSや、AIを活用した運用自動化、ビジネスオートメーション、MQやKafkaなどのインテグレーションの領域など新しいテクノロジーへの積極的な投資を進めています。サポート体制についても今はTechnical Salesもテリトリーを持って、ある程度担当するお客様を決め、アカウントプランニング・セッションにも継続的に出席するように変わってきています。お客様やセールスの人たちと以前より密に連携する体制で向かおうとしています。おっしゃる通りプロダクトアウトで持っていくのではなく、Why、Whatをより明確にすることが本当に重要ですね。
本日は貴重なお話をいただきありがとうございました。
インタビュー・執筆：アニバーサリー広報チーム(Data, AI and Automation事業部)
撮影：鈴木智也(Data, AI and Automation事業部)