ソフトウェアアーキテクチャと考古学 — Part 1

「お客様のアーキテクチャを分析しているといつも考古学者になった様な気持ちになる。どんどん掘り下げていくと、あぁちょっと前にEJBを試してみたんだなぁとか、この辺りのシステムはCORBAで通信しているから2000年代初頭のものかとか、やはり基幹の部分の多くはCOBOLのまま残っているな、とか。ただ考古学ともっとも違うのは、これら化石がまだ生きて暴れている点である。」

10年程前、キャップジェミニの誰だか名前は覚えていないが著名なアーキテクトが講演の冒頭で語った一節である。私のアーキテクトとしての思考はここからスタートしたように思う。

ソフトウェアアーキテクチャの最も難しい課題の一つは、これら化石（失礼）を生きたまま掘り起こして延命治療をしないといけない所であり、大規模なITポートフォリオを前に仕事をする際我々も常に意識しておかなければならない点である。そして昨今問われているデジタルトランスフォメーションの達成度を上げる為に、この化石発掘作業をどう改めて行くかは重要な課題である。

稼働している古いシステム、特に企業の基幹システムとどう向き合うべきなのか。私は前職で事業会社のアーキテクトという立場で、デジタルトランスフォーメーション推進イニシアチブに従事していた。ここで経験したものを土台に、実際基幹システム付近までメスを入れようとした場合、どのような技術的な選択肢があるのかを考察したいと思う。

Part 1の今回は、解法を急がず状況把握と問題提起を主に述べる。

企業の情報システム部では何が起こっているか

情報システム部の業務上の命題の一つは、基幹システムを延命しなるべく効率よく維持運用する事である。これらは化石とは言っても現役でビジネスをサポートしているシステムであり、往々にしてビジネス上最も重要な基幹システムでもあったりする。1秒も止めれない。1項目でも値を誤れば新聞に載ったり偉い方々が監督省庁に報告に上らなければならない。全てがそうではないが、ビジネスクリティカルなシステムであることには変わりなく、変更を加える必要がある場合には特に慎重に扱われる。

変更は必要悪である。システムを使い続けるには変更は適用し続けなければならない。ただ、変更の影響範囲は常に最小限に留めたい。技術的負債だろうが何だろうが、これが無いと今日のビジネスが止まってしまう。

同時に、これらシステムは非常に有益なデータを有している為、無数のサブシステムがこれらからデータを吸い上げ、加工し、様々な用途に活用している。そして逆に他のシステムからも基幹システムにデータが投入され基幹業務で活用されている。これらデータ連携は1日1回、夜間誰もシステムを使っていない時間帯にバッチ処理にて実施されるものが多い。他にも基幹システムのアドオンとしてサブシステム自体が追加されたり、サブシステムから基幹システムのデータベースに直接繋げたりする場合もある。結果として基幹システム周りには複雑かつ時として見えにくい依存関係の蜘蛛の巣が張られる事になる。

この為、これらシステムに変更を加える事自体容易なことではない。画面と帳票に1つ項目を追加する。ページ間に一つステップを追加する。Aシステムで見れるこの項目をBシステムのここにも表示する。業務部署から見ると簡単に見えるこれら要求は、ソフトウェアアーキテクチャの観点からは難しいものも多い。

何より1つの変更がもらたす影響を正確に把握する事が難しい。例えば、Aサブシステムへの変更の為に必要な基幹システムへの変更がBサブシステムに与える影響を、Bサブシステムの担当チームがその全てを正確に把握する事は容易ではない。変更も多数あり、サブシステムも多数ある。その変更が同時進行する為把握はさらに難しくなる。

時間かコストかアーキテクチャか

一方、情報システム部にはこれらへの最適解を模索する為に充分な時間も予算も与えられない。高度に抽象化され洗練されたアーキテクチャ設計のような曖昧な基準にあまり価値は置かれない。プロジェクトのスポンサーである事業部門の理解も得にくい。これらスポンサーが気にするのは「いつまでに出来ていくらかかるのか」であり、最終的な承認を受けるにはこの2点を強く主張する方が合理的である。彼らも抱える案件の進捗をチェックされる立場にあり、スムーズに線表を進めるというのは自らの効率を上げるうえで大事な指標である。

結果として、解法の策定は主にコストと時間という評価軸で決定するという文化が30年以上続いてきた。そしてこれら解法の設計から運用までSIerと呼ばれるパートナーベンダーに依存する事でより柔軟なコスト体質を確立してきたという背景がある。

いま企業の情報システム部署が目にするソフトウェアアーキテクチャは、動く恐竜の化石を最も安直な方法で繋げ、それが崩れない様にレビューやテストといった鎖で雁字搦めに巻かれている様な複雑かつ不安定なものになる。大袈裟かもしれないが、これら基幹系システムはそれくらい変更を加えるのが難しい。

直接的なり間接的なり、真剣にこれら化石の発掘作業をどう改善するのかを真剣に検討し実行に移す時期に来ているように思う。実際多くの企業ではこの発掘作業にかかるコストと時間が少しずつ増え続けてきた結果新しく出来る事の選択肢が狭まり、安直だが聞こえは新しいがビジネス価値を生む算段もついていない新規開発が増えているよう感じている。もう末期に近い企業は多いのではないか？本当は今どこに向けて何をすべきなのだろうか？

事業会社からみるアーキテクチャ

情報システム部にとってアーキテクチャの評価は非常に難しい仕事であり、数年先を見越したIT全体のロードマップの策定は更に難しい仕事である。彼らはデータとコストと工程と業務プロセス管理を責任範疇とするチームである。その多くの部分もパートナーSIerに依存している状況の中、システムの技術的な構成を理解し、何が潜在的な課題で、本来はどうあるべきであるかを把握するというのは大変難しい。

一方、彼らは内部のビジネスのニーズに素早く応える事によっても評価される為、時間とコストの為には相当不恰好な統合でもあえて採用することがある。結果として一見では理解が難しい統合や、ちょっと間違えると大事故を引き起こす危険な統合がシステム間の要所に多数生まれる。多くのシステムが複雑に絡み合い、要所では設計作業が完全に属人化し、これらを簡潔に表現すべきドキュメント類も難解かつ最新状態にはない事も多い。

アーキテクチャについて何も検討していない訳では決してない。しかしそれはあくまで機能要求をシステムがどれだけ満たしているかという視点が主である。アーキテクチャの策定には必ず数社の提案を募り評価するが、この評価基準では提示される差は非常に少ない。当然各社（これはパッケージ製品も開発案件も）も長所を主張するより短所を減らす努力をする事で提案の相対評価を上げようとする為、結果としてどの提案も一見似たり寄ったりな場合が多い。結果評価軸はさらにコストに寄りがちになる。

事業会社におけるアーキテクトチーム

この悪循環から抜け出す為に、アーキテクチャを専門に見るチームを起こす企業も多い。専門職として外から採用するケースが多いが、企業内部の人間がアサインされる事もある。私は後者であったが、前者の方がおそらく多数派である。なかなかスキルセット的に社内の人間をアサインするのは容易ではないというのと、現状から打開したいから外から招くという両方の意味合いがあるかと思う。事業会社がITベンダーから人を採用するケースもこの職種には多い。

アーキテクトと言ってもインフラからアプリケーションまでレイヤーは多層だが、一般的にはエンタープライズアーキテクト（TOGAFの守備範囲）が多い。必然的に開発の一員としてソフトウェアアーキテクチャを受け持つというよりチームとしてレビューという形でガバナンスとして機能する。チーム規模としてもさほど大きくなく、個別の案件にまで深く介入するだけの余裕もない場合がほとんどである。「各システムのアーキテクチャを横断的に見る」という設立動機から離れてはいないが、会社上層部が求めるデジタルトランスフォメーションの一貫やイノベーションを生む土台という成果とはかけ離れている。

私の場合はプロジェクトの早期に参画し、自分でアーキテクチャドキュメントを書き、サービスのプロダクトオーナーにもなり何ならデリバリー責任も部分的に負っていたので、あまり一般的なアーキテクトでは無かったと思う。当然守備範囲は限定されたが、狭いエリアながらプロジェクトの立ち上げから会話に参加できたり、自分でプロダクトを取り仕切れる事は有益に感じていた。

しかしこのような変則的な水準をチーム全体で保つ事は難しく、チームとしてガバナンスの枠を超えると提供サービスにムラが大きく出たのは事実である。私はデリバリー畑出身だった為か、他のメンバーに比べて性急にビジネス成果を求める事が多かったように思う。ガバナンスの枠を全く超えないチームメンバーもいたので、チームに対する期待値の乖離も至る所で発生した。途中で我々はチームとして何をしようとしているのかと自問する事もあった。

失望と小さな成功

経営上層部のチームへの期待はそれなりに高く、デジタルトランスフォメーションの基盤として新しい技術/やり方の導入指導（と成功）をチームに求めた。そして実際チーム規模はそれなりに大きかったが、大規模なシステム刷新では苦難続きだった。複数のメンバーがアサインされるが、アーキテクトとしての足並みが揃わない。

そして誰も開発者までの距離を充分縮める事が出来ない。ここが大きな問題で、抽象的なダイアグラムをいくつ描いたところで、設計と実装に意図に即して反映されないと意味がない。結局設計は現場で起こっているのであり、彼らに意図を理解してもらって初めて実現する。彼らから離れた位置でソフトウェアアーキテクチャは成就しない。

私が経験したいくつかの成功は、開発者と向き合って進めた案件、特にそれが必要となる小さめのプログラムばかりだった。経営上層部が求める人を中心としたイノベーションを生む土台とまでは行かないが、変更が期待するスピードで進み、変化への恐怖心が減り、要望が乱立するような状況においても自信を持って導入を進める事が出来た。会議はまだまだ多かったが、開発者と事業担当者が直接コミュニケーションを取る機会も随分増えた。そして、私はここでこそソフトウェアアーキテクトとしてある程度納得出来る成果が出せたと思っている。

私はこの時点で会社を去ったが、果たしてこの小さな成功を元に大きな成果に繋げれたかどうかまでは分からない。心からチームのさらなる飛躍を願っている。

小さな成功に見る大きな夢

実際に小さな変革を目の当たりにし、これは素晴らしい事だと思うが、果たして巷で言われるデジタルトランスフォメーションの基盤となりうるのだろうか？一般的なアプローチに照らし合わせて、私が経験したものはどう当てはまるのか？そしてどうすれば変革を加速し飛躍できるのか？これらを事業会社のアーキテクトとして従事している間自問自答してきた。組織を離れた今もその自問自答は続いている。

次回は大きな目標である、基幹システムに対してどう向き合うのか、理論を交えながら考察をしていきたいと思う。

-続く

Pivotal Labsでは、定期的にワークショップ型イベントを開いたり、ブログでプロダクト開発やチームビルディングなどについて紹介しています。

イベントの最新情報：
Meetupグループに参加すると、いち早く案内が届きます😎📩

公式ブログ：
Product Runも是非フォローお願いしますっ🙌🏻🗒