このコラムは、株式会社エル・ティー・エスのLTSコラムとして2019年4月から連載を開始 した記事を移設したものです。
当コラムの最新の内容は、書籍『Business Agility これからの企業に求められる「変化に適応する力」（プレジデント社、2021年1月19日）』でご紹介しております。
ライター
私（山本）は、過去の書籍やコラムではビジネスのアイデアである戦略に対するビジネスの実行力を 「ビジネスプロセス」として説明してきました。このコラムではこれを「アーキテクチャ」として表現しています。近年、デジタル化が進む中で企業構造を示す言葉としてビジネスプロセスよりも、アーキテクチャという表現の方が優勢になったことを受けてのものですが、意味的には同じものと考えて頂いてかまいません。また文脈的に「ビジネスプロセス」を使った方が意味の通りやすいところはこちらの表現としています。
アイデアを素早く実行するための“ビルディングブロック”の把握
第3回でふれた戦略は立案しただけではただのアイデアで、実際にビジネス上の価値として実現するためには、アーキテクチャに落とし込む必要があります。これがどういうことか、一つの例でみてみましょう。
戦略はアーキテクチャに落とし込まれなければ意味がない
最近“サブスク”という言葉をよく聞くようになりました。「サブスクリプション」の略で、一般的には「商品に対価を払うのではなく、契約期間の間に自由に商品を利用できる“権利“に対価を払う契約形態」といった説明がされます。わかりやすく言えば月会費や年会費を払うとその期間は商品が使いたい放題といったものです。鉄道の定期券は古典的なサブスクリプションモデルの契約ですし、最近であればアマゾンが提供している月額で電子書籍（キンドル）が読み放題となるサービス「Kindle Unlimited」などが分かりやすい例です。お客様を囲い込んでキャッシュフローを安定させたり、旧来の売り切り型のビジネスモデルよりもお客様の商品の利用状況を精緻に把握することができるため、お客様との関係を強化したり商品開発に活かすことができるビジネスモデルとして、近年さまざまな業界で大変注目を集めています。
さて、あなたの会社はファッションブランドを展開しているとします。これまでは直営の店舗と、自社サイトでの通販（ネット通販）で商品を販売していました。そして今、あなたの会社もサブスクリプションモデルの新サービスを導入するという、新たな戦略を考えています。このサービスでは定額の会費で、自社の様々な洋服やアクセサリーを自由に交換しながら使うことができます。
既に新サービスのサービスラインナップやターゲットユーザー、課金モデルといったビジネスモデルの初期設計は終えました。前回（第3回）の“戦略“でも話した通り、今の戦略はただ考えるだけでなく素早く実行してPDCAを高速でまわすことが大切です。ですから、あなたの会社でも早くサービスを開始したいと考えています。そうなると次に必要になるのはサービスを提供するための基盤であるアーキテクチャを整えることです。これには素早く業務を設計することと、業務を支えるためのツール（情報システム等）を開発することが含まれます。
新しいサービスといっても、すべての仕事がこれまでと変わってしまうわけではありません。例えば商品の生産工程はサブスクリプションモデルでも変わりません。一方で物流は大きく変わりそうです。ネット通販のサービスを行っているのでお客様に対する出荷オペレーションを担う機能は既にあります。しかし、サブスクリプションモデルであればこれまでの売り切りの契約とは異なるオペレーションも必要となります。
サブスクリプションモデルには利用商品の返却を伴う“シェア型”と、伴わない“売り切り型”に分かれますが、衣料品や時計、カバンといったファッション業界では、使わない商品は返却してもらい、それと入れ替わりで新たな商品を届ける“シェア型”が多いようです。そうなると物流は出荷だけではなく、返却された商品の受け入れ機能が必要になります。これまで商品の返却は不良品対応などの限定的な業務でしたが、これからは定常業務として発生します。サブスクリプション契約で出荷した商品の状況も管理し、返却情報やクリーニング状況と合わせて管理しなければなりません。もちろん、出荷時の処理も、売り切りかサブスクリプションかを識別して、サブスクリプションであれば梱包時に返却キットを同梱するといった変更が必要になります。このような業務に対応するために、現行の出荷管理に特化した倉庫システムも改修が必要になります。
主に物流の例を取り上げましたが、このような業務や情報システムの変更は社内のいたるところで起きます。お客様の注文機能も変わりますし、カスタマーサポートは起きうるトラブル等を予測して対応方針を決め、コンタクトセンターのオペレーターを教育しなければなりません。管理会計の考え方も大きく変わりますので、新たなレポート機能を追加する必要もあります。
このように新しい戦略を素早くアーキテクチャに展開するためには、まず既存のビジネスを構成している要素を分析して、「１．変更の必要がない業務」「２．変更が必要な業務」「３．新たに追加が必要な業務」に分類しなければなりません。場合によってはここに「４．今後は必要なくなる業務」が加わることもあるでしょう。ここで言っている“業務の変更“とは単純に業務手順の変更だけでなく、ルールの変更、人員の増強や教育の変更、さらに情報システムや設備の導入や既存機能の変更も含まれます。戦略を素早くアーキテクチャに展開する上では、新たな業務を素早く設計できること以前に、この既存のアーキテクチャとの差異分析がとても大切になります。しかしこれは決して簡単なことではありません。
あなたの会社は自社の業務の構造を把握できているだろうか
あなたの会社では “サブスクリプションモデル導入”の例のように、何か既存のビジネスモデルに変更があった際に「影響する業務を整理して報告せよ」と言われたらすぐに対応できるでしょうか。このためには自社の現行業務や、それを支える情報システムや設備といったツールの構造が可視化され、共有可能な状態となっている必要があります。もちろん現行業務の中には異常時の対応プロセスや、事業状況を管理するための管理プロセスも含まれます。これらも含めて、社内の業務やITが全て識別されているでしょうか。
以前に、あるネット通販の会社で業務の可視化を行ったところ、一つのフローとして記述すべき業務の塊（＝プロセス数）が全部で500ほどありました。現実に変更箇所を特定する際には、各業務フローの中に登場する細かいアクティビティ（作業）を分析して変更が発生する具体的な箇所を特定していきます。ですから分析対象となるアクティビティは500ではなく、この数倍から数十倍になるでしょう。
さて、何か変革が必要な際に、このネット通販会社のように現行業務の可視化がされていて、すぐに業務の分析が可能になっている会社と、そうでない会社があったとします。この二つの会社で、変革活動に素早く入ることができるのはどちらか？と聞かれたら、当然ですが現行業務の可視化が既にされている会社の方が圧倒的に優位なわけです。
ここでは既存の業務フローの有無を例にしましたが、分析対象は決して業務フローで表現される「プロセス」だけに限りません。業務上の判断に使われる各種の「ルール」、業務上必要となる「情報」、業務の「責任組織（部署）」、活用している「情報システム」など、たった一つの業務を分析する上でも、その分析観点はさまざまな要素があります。このような要素の集合体を「アーキテクチャ」と呼んでおり、このアーキテクチャを構成している“要素”のことを専門用語で「ビルディングブロック」と言います。プロセスもルールも情報システムもアーキテクチャを構成するビルディングブロックです。戦略が変われば、これらの無数のビルディングブロックの中から交換させるべきブロックを抽出しなければなりません。アーキテクチャの変革の実態はこのビルディングブロックの交換作業なのです。戦略実現のための計画策定を行う担当者が、このようなビルディングブロックの集合体としての自社のアーキテクチャを理解し、分析可能な状態となっているか、いないかは、企業のビジネスアジリティを決定的に左右します。
なお、この時に大切なのは既存のアーキテクチャを“理解すること“であって、決して“文書化すること“ではないことには注意する必要があります。現実にはアーキテクチャの要素を全て文書化して表現することは不可能に近く、仮に文書化したとしてもその内容を最新に保つために、多大な労力がかかってしまいます。海外の企業でこのようなアーキテクチャ管理を行っている事例を見ると、アーキテクチャの文書化は粗い粒度の業務フローにとどめ、それ以上の細かい要素は、業務の詳細を理解している担当者間のコミュニケーションで補完しているケースが目立ちます。ただそのような粗い粒度の資料でも、全く文書の支援がないよりもはるかに効率的にアーキテクチャを理解し、関係者間で共有することができます。文書化はあくまでも人の理解とコミュニケーションを助けるものとして、効果と労力のバランスをとることが大切だということは付け加えておきます。
変化のアジリティを決めるのは実は既存のアーキテクチャへの理解
何か企業が変革を行う時、まずは現行アーキテクチャの可視化や分析から入ることは多いと思います。これを現行業務の問題を発見するためと思っている方も多いのではないでしょうか。そのような要素がないとは言いませんが、実は真のビジネスの問題は現行のビジネスをどれだけ分析しても見つかりません。なぜなら、アーキテクチャ上の問題とはあるべき姿、つまり戦略や新しいビジネスモデルから想定される将来像に対して、現行のアーキテクチャが適応できていない箇所を指すからです。ですから、問題発見には未来像を明確にすることがとても大切で、将来像が明確であれば“問題”はアーキテクチャの将来像と現状との差異として自然と“見つかる”ものとなります。このように現行のアーキテクチャを理解することの目的は、問題を見つけるためというよりも、変化に際して変えるべきところと現行を維持するところを識別する「差異分析」の基準（ベースライン）となる情報を準備しているということになります。もちろん、現場の不満や、誰が見ても明らかな非効率は現行アーキテクチャからの問題分析で見つけることもできるので全く無駄ではないですが、現行アーキテクチャだけをどれだけ分析しても小改善に留まるということはご理解頂いた方が良いかと思います。
さて、この現行アーキテクチャの可視化や分析ですが、これまでは特定の変革の際に、プロジェクトの初期フェーズとして行われることが大半でした。例えば基幹システム更新の際に、現行プロセスを可視化し、それを元にシステム更新の計画を策定ということは一般的な手順でした。しかし、ここでせっかくの作成した新旧の業務フローや関連する資料群は、プロジェクトが終わるとその役割を終えてしまい、更新されることもなく陳腐化していくことが大半でした。ビジネスアジリティという観点から見ると、これは大変もったいないことをしています。アジリティを重視するのであれば、現行アーキテクチャの可視化は特定の変革プロジェクトの作業の一環として行うのではなく、戦略マネジメントの基盤情報として常日頃から用意しておくべきです。現行アーキテクチャを管理し、常に最新の状態にしておき、さまざまな変革の際に基盤情報として提供するのです。このようなことを行うには普段から一定のコストがかかりますが、そのような普段からの努力が変化の速い時代における戦略実現のスピードを決定的に左右します。
過去のアーキテクチャ情報を受け継ぐことは、スピードだけではなく変革のリスクも低減させます。“変革”というと変えるべきところばかりに関心がいきがちですが、実は現行アーキテクチャに存在している「戦略が変わっても確実にひきつがなければいけないこと」を識別することも大切です。ビジネスの複雑さが急速に増す中で、現行のアーキテクチャに埋め込まれたさまざまなノウハウは大変貴重なインプットです。異常時や例外処理に対する処理ルールや、コンプライアンス違反やリスクを除去するためのチェック機能、情報セキュリティの決め事などは、過去のさまざまな経験や失敗からの反省などを反映した結果です。このような過去の経験を活用せずに、一から新たにルールや処理フローを定義することは非効率なだけでなく、重大な要求の漏れや見落としを引き起こします。
なかには「既存の業務を知りすぎると、現状に引きずれて大きな変革ができなくなる」と言う人もいますが、よく考えるとこれは的外れであることが分かります。既に述べたように本来、アーキテクチャの設計思想は戦略や目指すビジネスモデルからやってくるものです。現行業務を理解していることが、変革の方向性に影響を及ぼしてしまうのであれば、それはそもそもの戦略や目指すビジネスモデルをしっかり理解していないか、そもそもそれらが不明確だということを示しています。
このようにアーキテクチャ視点からのアジリティとは、現行アーキテクチャの理解を元に、実効力のある変革計画を素早く立案することが第一歩となります。
以上までが「ビジネスアジリティにおける“アーキテクチャ”」の前編となります。後編では、アジリティの高い組織を作っていくための人材育成の仕組み、組織能力を高める方法についてご紹介します。
