こんにちわ。
やっと話が戻ってきました。前々々回に予告した「PESTLEはすでに管理されている」とはどういうことかを解説いたします。
なお、本日のこのブログで使われる言葉は、各企業においては全く違う定義で用いられている場合があります。そのため、この先出てくる言葉が自社と同じ文言であったとしても同じレイヤの文章であることを保証はできません。ご注意ください。
まず、再掲。
PESTLEとコーポレート部門との関係
前の記事で、上記のようにPESTLEの６つの要因を実はコーポレート部門がそれぞれの専門性を持って管理しているのである、というお話しをしました。では、「どうやって」コーポレートの各組織はPESTLEを管理しているのか？
それは、実は「内規」なんです。会社員、特に上場企業にお勤めの方はご存知と思いますが、会社には「各種規程」とか「内規」「ポリシー」などと呼ばれる文書がありませんか？実はこれら文書群がPESTLEを管理する「システム」なんです。
文書がシステム？と思われる方もいらっしゃると思いますが、文書もシステムなんです。正確にいえば、これら内規は、それぞれのコーポレート部門が定めた「方針」から始まります。よく聴かないでしょうか？「XXX方針」「XX規程」「XX手順」など。何書いてあるのかちゃんと読まれていますか？そして、これらは大体、「ポータルサイト 」から直接リンクが貼ってあります。これら文書、本来であれば大切なものなのに、意外と読んでいる方いないと思います。
なぜなら、それら規程類を満たした形で現場で運用できるように「ITシステム化」されていたり業務管理部門がコーポレート部門と調整しているからなんですね。
現場がなすべきことのみに注力できるように、管理部門はそれぞれの規程の監督コーポレート部門の文書を読み込み、仕組みやシステム化することで「読まなくても仕事ができる」ようにしている。そういう構造なんです。
これらは、ガバナンスの一環で定義されるものです。ガバナンスと聞いて、下記の図を見たことないでしょうか？このガバナンスとそれに基づき定義されている文書群が、システムとして(完全とは言い難いものの)PESTLEを制御している証でもあります。
ガバナンスにおける文書の階層
最上位文書として、目指すべき方向性や達成したい姿を書いたポリシーを据え、その下に、その方針を満たすためのガバナンスの実務（例えば、責任を負う役割が定義されていたり、どこまでを全社/グループ全体の共有事項として定めるのかなどを定義する）レベルの文書として標準を置きます。さらにその下には、具体的にどのような手続き・手順を満たせばルールを守ったこととするのか、のプロセス文書をおき、その下にそれぞれの組織でどのような手続きとするのかの手順文書がある。上から下ろすとこのような構造です。
私の感覚ですが、コーポレート部門は、プロセスまでを定義し、その下の手順はそれぞれの企業文化によって違う（コーポレート部門が定める場合もあれば、各事業部門でプロセスを参照しながら作ることもある）ように思います。
これは、トップダウン で見ると分かりにくいのですが、下から見ると理解しやすくなります。つまり、手順を読んでいて、「なぜ？」と思ったことを調べようとするとプロセスや標準当たると大体わかるという構造になっています。
これを前職では「本社の歩き方」と読んでいる人がいました。言い得て妙ですね。（笑）
下位文書は参照した上位文書を必ず明記します。このように文書でシステムを構成するための絶対的な不文律です。
そうしなければ、文書間同士の繋がりがわからず、「なぜ？」と思った時のリファレンス先がわからなくなります。結果、ガバナンスが崩壊します。このシステムの恐ろしい所は、ここなのです。文書なのでこのシステム全体を知らなくても、またこの文書に従わなくても業務は作れてしまうし、システム化もできてしまう。文書なので下位文書を変更する場合も、上位文書を参照しなくても変更できてしまう。だから文書内にちゃんと上位文書を参照しながら変更しなさいよ、という意思を込めて上位文書を明記する。
日本語そのものがアプリケーションでいうところのコードになっているため、ちゃんと読めばシステム化されていることは理解できるのですが、そもそものコード（文書）の可読性が低いと定義されているガバナンス（システム化され事業が各種法令や規制に抵触しないことを担保する）そのものが崩壊しかねない。
こう言った状況を踏まえ、「本社の歩き方」と言ったのだろうなぁと今更ながら懐かしく、そして素晴らしい日本語のセンスだなと思います。（笑）
言葉だけだと分かりにくいので、具体例として、今まで固定資産でなかった物が固定資産になったというような事例で例えてみます。
(事例)固定資産の分類が増えてしまったら
なお、私は管理会計 を齧った程度のど素人なので、微妙な言葉の使い方の違いがある部分はお目こぼしいただければ幸いです。ここで伝えたいのは、何かが変わったときにどのようにインパク トを受けるのか、の事例なので。
今回は会計基準 の変更などではなく、あくまで固定資産の考え方が変わっただけなので実態として標準から影響が起きていますが、この例のように、PESTLEの「法的要因」の分析に基づき、上位文書からレビューを行うことになります。その結果、すべての階層で変更の要否がレビューされ、このガバナンスという名のシステムが変更されてゆく、という構造になっています。
つまり、ビジネスの現場、実際の業務に近づけば近づくほど、「この手順を守っていれば、会計上、関連の法規制上などのルールを無視していない」ことを担保した手順になっているわけです。もし、これらの文書類がなかったとしたら、都度都度法律上問題がないか、会計基準 に照らして正しく財務処理がなされているかなどをチェックしなければなりません。取引ごとに。そんなこと面倒くさくてやってられませんよね？それらを「この手順通りにやっていれば、ミスはないよ」としたものが最下位文書の「手順」な訳です。
なので、特に商業や税制に関わる法律や法令の変更、今までの解釈と異なる判例 が出ると、すわ一大事と企業の会計や経理 の担当者、会計士の方は大慌てをするわけです。
このように、PESTLEはビジネス(価値を提供し対価を受ける)を進めていく上で非常に大きな影響を与えます。そのため、これらの影響を早期に検知し問題なくビジネスを進めていく上で予めガイドとして定義するものがこの文書によって定義されたシステム、これこそがガバナンスなのです。裏返すと、ガバナンスは、ビジネスを進めていく上で遵守し注意し生かすための地図に似たシステムなんですね。このまま進むと崖があるぞ！だけどショートカットにもなるよ。じゃあ、崖に対応しながらどうやって進もうかと考える、または崖を迂回する、などの対策も考えられますよね。
これこそが、私が「文書と人間の読解力、注意力を合わせたシステムでPESTLEを制御しているのである」という理由です。
しかしながら、ここ20年（私の感覚だと2005年）ぐらいから、人間の注意力や既存の組織力 だけでは如何ともし難いレベルでPESTLEの対処が難しくまたスピードが上がってきたように思います。簡単にいうと、PESTLEという影響分類のフレームを使って各組織の専門性でもって個別対応するには物事が複雑であり、失敗の及ぼす影響が再起不能 なレベルにまで重篤 になり、その場その場で適切に判断する必要性が出てきている。
別の例えをするなら、20年ほど前までは、野球です。
野球の裏表の中で、球が放たれて、ワンプレーが完結するタイミングまでは臨機応変 にプレーヤーが自分の意思で決定し動く必要がありますが、そのワンプレーが完結すれば、監督やコーチが様々な情報を分析し判断して戦術を駆使すれば良かった。３アウトを迎えるまでに順序を組み立て、状況に応じて様々な戦術を駆使していけば良かった。それを考える時間もあった。
それに対して、今の状況は、野球のワンプレーが延々と続いているイメージです。「常に球がとんでおり、バッターが打ち返し、隙を見ては野手が盗塁を試みてる」みたいな。プレーが中断しないサッカーやラグビー と捉えてもいいかもしれません。そんな状況下で監督やコーチが情報を収集し分析し意思決定を下したとしても、おそらくすでに陳腐化しています。それだけ目まぐるしく状況が変わる状態にあって、特定の瞬間断面の情報を収集し分析したところで、「試合はすでに動いている」のです。
つまり、PESTLEの状況を収集し分析したところで時間の経過により何の役にも立たないのです。現場で判断できる状況を作り上げなければいけない。そんな状況下で文書と読解力と注意力で機能するシステムはあまり役に立たないと言わざるを得ません。
断っておきますが、今まではそれで良かったが、今はそれでは対処できないということであって、文書と読解力と注意力で動くシステムを否定するものではありません。
つまりは、スピードが早く目まぐるしく変化する状況にあって文書と読解力と注意力以外の要素を加えることで、PESTLEに対処するための新しい仕組みを生み出す必要があるよ、ということです。
Agile やDevOpsで言われている「デプロイメントパイプライン」は一つの解と言えます。デプロイメントパイプラインとは、簡単に言えば、テスト自動化の仕組みです。このテスト自動化の仕組みを経由したすべてのサービスは文句なくいつでもリリースできると約束されています。つまり、デプロイメントパイプラインには、ガバナンス観点でのテストも入っており、文書と読解力と注意力がこのテスト自動化の仕組みに組み込まれているという状態を維持しています。なので、法務・財務/経理 ・内部統制・IRの観点でもコード化されているとベストです。法務観点でコード化できるようなプログラマ が存在するのかという問題はありますが(笑)、概念的にデプロイメントパイプラインはそういうものです。人間の注意力や読解力によらず機械でPESTLEの全ての観点で静的テストが実装できるなら、可能となります。
今までは、人力と読解力と気合(注意力)で保ってきたこれらPESTLEへの対処の方法を新しくしてゆく必要があります。
昔と違い、PESTLEの要素が増加し、複雑になり、かつ、それを受け対処する我々働く側の人が減り、働く人が貴重になってゆく今の時代にあって、同じように維持して行かなければならない。新しい価値を生み出すための仕組みにPESTLEの対処を含めなければいけない。
今はまだ文書と読解力と注意力で保てていますがそれが限界を迎える日も近いと思います。この危機に挑むのはITSM実務者の挑戦だと思います。
