マイクロサービス化で2025年の崖を飛べ（中編）

納得感を持って機能を断捨離しよう

なぜシステムは肥大化・複雑化するのか

現行機能を捨てるには勇気がいる。業務が回らなくなってしまったらどうしよう、提供していたサービスが無くなることでお客様が離反したらどうしよう……不安は尽きない。
社会心理学の分野では「現状維持バイアス」と呼ぶが、人は得をしたときの喜びよりも、損をしたときのがっかり感を強く感じる（1万円損する可能性があるなら、同じ確率で2万円以上得しないと「やる」という判断に至らないらしい）ので、損をするより2倍以上得するメリットがない限り、変化の必要性を感じず、現状を維持しようとする。

判断の権限を持つ人が、その業務・機能に疎い場合は厄介だ。有識者の意見が頼みの綱になるが、属人化してしまった業務や機能ほど、有識者の主観による偏りが入りやすい。きっと過去には、その人にしか対処できないトラブルや、他者に教えたりする中で自己肯定感を高めるイベントがあったはずだ。再構築を計画する側からすれば「機能のシンプル化」でも、有識者からすれば、「自分のこれまで仕事を否定された」ともとれる。捨てることのデメリットやリスクを多めに並べる傾向が出るのは、心証としては理解できる。

しかし、こうしたしがらみが、誤った判断を導く可能性は大いにある。もちろん全ての人に当てはまるわけではないが、筆者が15年以上システム開発の現場に携わってきた中で言えば、長く基幹システムの維持保守にあたってきた関係者の半数以上はこの傾向を持っていたと思う。その業務・機能に精通している人数が少なければ少ないほど、傾向は強く出て、断捨離のハードルが上がってしまう。

もし、ここで現行踏襲する判断を下した場合どうなるか。機能がシンプル化されないだけでは済まない。基幹再構築には多大な労力とコストがかかるので、このプロジェクトの開始承認を得るには、新たな価値を生み出す提案も盛り込まないといけないことが多い。つまり、新たな機能が追加される。日本では人月契約でのシステム開発が一般的だ。現行機能を削るという助言・提案は既存システムのベンダーからは出るはずもなく、肥大化・複雑化したシステムにさらなる機能が上乗せされるので、プロジェクトの難易度は増す。
当初計画ではプロジェクトを完遂できず、良くて部分再構築、最悪は頓挫、サンクコストのわなにはまり、現行システムに新機能が追加されるだけのプロジェクトに終わるなんてこともある。そうやって基幹再構築のハードルが上がり続けて今に至っているのではないのか。

再構築できない基幹システムのネガティブスパイラル

さらに追い打ちをかけるようだが、そうした状況に陥った基幹システムほど、仕様書がない、または最新化されていないことが非常に多い。特に複雑化してつぎはぎで改修を重ねていると、単独の機能から、もとの業務要件を想像することも難しくなる。当初の開発関係者がいなくなっている場合（異動・離職・ベンダーであれば離任）もあるだろう。気付けば、この機能が何に使われているのか答えられる人が誰一人として存在しない……という最悪の事態になっていることもある。

「再構築できない基幹システムのネガティブスパイラル」を示すが、実はこの図は筆者が2014年に描いたものだ。あれから9年たつが、その間も同じような現場に多数遭遇してきた。残念だが、これが日本のITの現実だと受け入れざるを得ない。
このスパイラルを断ち切らない限り、2025年の崖を越えることはできない。期間的にも今が断捨離の最後のチャンスだろう。

しかし、このような状況下において、トップダウンで「とにかく断捨離しろ！AsIsなんて無視してToBeを考えればいいんだ！」と進めてもうまく行かない。最初はCIOの命令だから……と従うそぶりを見せるだろうが、UAT（ユーザ受入テスト）で要件定義の不備が大量に露呈し、到底リリースできる品質ではないことに絶望する日が訪れる。精神論でどうにかなるなら、現時点でこんなひどい状態にはなっていないはずだ。論理を立てて、解決に当たる必要がある。

正しく「現行調査」しよう

これには「現行調査」が有効だ。現行調査と言っても、ひたすらシステムの仕様書をかき集めて、不足分・最新化できていない部分をリバースエンジニアリングするということではない。以下の4ステップで「何のための機能なのか」を理解し、「本当に必要な機能なのか」を議論し、共通認識を持つことが、納得感のある断捨離につながる。

第一ステップ：業務・システムに関する資料を可能な限り収集しよう

業務一覧と各業務の業務フロー、システム一覧（I/Fがある場合は対向の社外システムも記載）と各システム内の機能一覧（社内システムのみ）がどれだけそろっているかを確認する。手始めに、業務部門とシステム部門ないしベンダーのリーダー格に、資料提供を依頼しよう。
一通り出そろった段階で、バラバラの資料を統合する。業務一覧、システム一覧、機能一覧をそれぞれ1シートにマージし、再度過不足のチェックを依頼する。
なお、不要なものを見つけた時は、物理削除せず、ステータスを「廃止」にして、その理由・経緯を備考に記載しておく。（後でヒアリングする時のためにコメントした人の名前と日付を入れておくことも重要）
追加した場合も同様。いつ誰が追加したのか、なぜ初回依頼時に漏れたのか、分かる範囲でコメントに残しておく。

第二ステップ：業務・システムの漏れを補完しよう

業務フローのウォークスルーを行う。各業務で利用されるシステムをメインで担当しているシステム部門メンバーが、業務担当者にヒアリングする形式だ。ここで明らかにしたいのは、業務内に登場するシステム・機能を、誰が・いつ・どこで・何のために・どのように使うのかだ。業務フローが無い場合は業務一覧に業務概要と利用システムを記載してもらい、それをベースにヒアリングを行う。
ヒアリング結果をシステム一覧や機能一覧側に反映していくと、第一ステップで登場しなかったシステム・機能や、業務上利用されていないシステム・機能が洗い出され、現行機能の重要度や課題が明確になるはずだ。ここでは、業務側視点の改善要望だけでなく、システム制約やシステム間の密結合度も見えてくることが多い。

業務部門の見解とシステム部門の見解に齟齬が発生することもある。システム部門側で廃止したはずの機能を業務上利用していたり、業務部門が独自に開発したローカルシステムやツールが存在していて、他の基幹システムの機能を前提として動かしていたり……ここでは判断せず、今見つけられて良かったと思って一度飲み込もう。

第三ステップ：断捨離案をシステム目線で考えてみよう

いよいよ断捨離するものを仕分けていく活動に入る。
まずはシステム部門側でヒアリング結果を反映したシステム一覧・機能一覧に一次判定として、システム部門の見解を示す。次に、業務上利用されているシステム・機能については、その利用概要を基に、「必須」と「任意（できれば廃止・シンプル化したい機能）」に分類する。
ヒアリングでは業務上利用されていないことになっているシステム・機能は基本的に「廃止」に分類するが、もし、システム部門側で利用シーンに思い当たる節があれば、「任意」に分類する。
この後は「任意」「廃止」と一次判定された機能について、第二ステップのヒアリングメンバーが再結集し、「残す」「シンプル化して残す」「断捨離する」に分類していく。
当時必要だったとしても、今となってはほとんど使われていない、別の改修テーマで作られた機能と重複していて要らなくなっている、という可能性もある。改めて「現時点の業務要件」として5W1Hを整理すれば、基幹再構築後に必要なものなのかを判断することができるし、文字になっているので後から覆ることも少ない。業務部門もシステム部門もお互い納得感を持って断捨離できるだろう。

第四ステップ：業務部門と徹底的に討議しよう

断捨離の最終判定を行う、ここが最難関。
第三ステップで「残す」と一次切り分けしたものを本当に残すのか。業務部門とシステム部門で相反する見解を持っているものなので、各システム・機能に対して、一つひとつ深い討議を要する。
この段階になるとヒアリングチーム内では解を出せないこともある。その場合は業務部門、システム部門それぞれの責任者に判断を仰ぐ、討議に参加してもらうことも必要になるだろう。

重要なのは討議の記録と納得感

断捨離を強要しているわけではない。必要なら残す判断をしても良いと考えている。筆者もある1機能の最終判定のために、週1回3時間の討議（その度ディスカッション用の資料を作成）を4週間にわたって展開したが、残すという結論に至った経験がある。しかしこの活動は無駄ではなかった。筆者自身、業務部門が何を重要と考えているのかを理解できたし、討議を重ねることで、この機能がなぜ必要なのか、いかに重要かを全員で納得できた。事業部門が現行機能の本来の業務要件を理解し、それを組織知化できたことも大きな価値だったと思う。

実はこの後、システム部門の有識者が相次いでプロジェクトを離脱するというピンチが訪れたのだが、要件定義工程の紆余曲折をドキュメントとして残しておいたおかげで、大きな混乱もなく、設計・開発・テスト工程を乗り切ることができた。旅にトラブル、プロジェクトにリスクは付き物。ドキュメンテーションには、属人化のリスクを軽減するという利点があることも是非覚えておいてほしい。

また、事業部門、システム部門、ベンダーがそれぞれの認識をお互いに理解しあい、やるべきことを自ら考え、行動できるようになってくれたことは、今後マイクロサービス化されたシステムを保守・運用していくうえでも非常に重要な成果だったと思う。いままでは、「現行通りで」とか「現行調査は不要、とにかくこれ作って」と、事業部門が真の業務要件を整理しないまま、システム部門に開発を依頼し、システム部門はその要件をそのまま機能分解して、各ベンダーに渡し、ベンダーはその要件に疑問を持つことなく言われたとおりに開発する、ということが多かった。答えが明確でウォーターフォール的に進められる案件であれば、それで良いかもしれないが、マイクロサービス化された基幹システムにおいては、アジャイル開発が基本となるため、事業部門、システム部門、ベンダーが互いにコミュニケーションを取り、意見を出し合う、一体的なチーム運営が求められる。

「現行調査」は単なるリバースエンジニアリングではない。本来の機能要件、業務要件を可視化することで、業務の意味・背景・付加価値を明確化することや、再構築した後の基幹システムを保守・運用していくために必要なチームビルディングも兼ねているということを強調しておきたい。