背景
副業や本業でBPR系のことをやっている中で、去年ECRS原則というものを知った。
これは簡単に言うと、業務改善に使う原則であり、
おもに以下の図のエンタープライズアーキテクチャモデルのBA(ビジネスアーキテクチャ)の層で改善を考えるときに使うものです。
しかしながら、ソフトウェアアーキテクチャハードパーツに出てくるような
AA(アプリケーションアーキテクチャ)の層での改善活動である、
戦術的フォークやコンポーネントベース分割を見るうちに、
「あれ？これってECRSでやってることじゃん！」という発見になったのがきっかけです。
ECRS原則
まずはこのECRSについて触れましょう。
ECRS（イクルス、イーシーアールエス）は、業務の「ムダ」を洗い出し、改善措置を講じるための基本的な原則です。
ビジネスプロセスマネジメントとかの業務をされている方なら目にされたことがあると思います。
実は素早さが求められるアジャイル開発には、この原則から派生したであろう業務改善が多々あります。モブプロとかはいい例かもです。
でもどっちが先なんでしょうね。アジャイルとこのECRS。まあそこは置いておきましょう。
またこのECRS、順番を変えたりしてもいいと誤解してはいけないです。
必ずこの順番であることに意味があります。
そのプロセスを無くすことが怖いからと、他のCRSをやってからEというのはアンチパターンです。
以下の図が理由で、順番の通り検討していかないと効果が薄く、費用対効果が感じられません。まずは不要なプロセスはバッサリカット！
では、それぞれ１つずつ見ていきましょう。
Eliminate（排除）
「不要なプロセスを取り除くこと」を意味しています。
ワークフローを構成する業務活動中に、生産価値の向上に寄与していないものが必ずあります。
それをカットしていく考え方です。
LeanとDevOpsの科学にも出てきた、
【意味のない承認プロセスは組織のパフォーマンスを遅らせるだけ】みたいな一文がありましたが、あれで言っていることはまさにこれを意味します。
また戦術的フォークでは、アプリケーションアーキテクチャレイヤーにて不要なプロセスを削除していますが、あそこからボトムアップにビジネスアーキテクチャにも反映させて、不要な業務活動を無くさなくてはいません。(下図みたいに)
そう言った意味でも戦術的フォークとは、まさにこのEliminate（排除）をやっていることになります。
事例
・目的が曖昧な会議や定例会の頻度・参加人数を減らす、または廃止する
・慣習となっている報告書や帳簿作成、押印のプロセスをやめる
・出張をweb会議に切り替えることで出張費を削減する
Combine（統合）
「全体のプロセスを要素ごとに把握し、適切に区分けすること」がCombineの本質です。
これはプロセスの粒度を揃え、構造化することも含んでいます。
業務を細分化し過ぎているがゆえに、変な組織の分断が起きてしまっている場合には、
チームの境界を超える際に、セキュリティ上の問題点から承認プロセスがあるかもしれません。
そんな場合には上記のEで不要な承認プロセスを排除し、１つにまとめてしまうのです。
またこのCは統合にフォーカスされがちですが、分割という意味も含んでいます。
それぞれのプロセスを要素に分解し、統合あるいは分離することで適性化を図ることを指している。
そうすることでコンテキストマップを作成できます。
これなんだか皆さん見たことないですか？
そうです！ コンポーネントベース分割によるモジュラーモノリス構造です。
さっきのこの図を再度見てください。
もしも１つにまとめられてしまって複雑化した業務サービスがあるとします。
これをアプリケーションアーキテクチャの層で、適切にコンテキスト境界を定義してプロセス面で疎に分割します。
するとプロセス面において疎結合なモジュールに分割されたモジュラーモノリス構造が完成します。そしたらその結果を上図のBAに反映させるのです。
これも立派な逆コンウェイ法則だと私は思っています。
Rearrange（組み替え）
業務プロセスを要素に分解したうえで、その順序などを入れ替えたりする「再構築」を意味する。
ここには誰がそのプロセスを行うのか？という組み換えも含めます。
たとえば、ある目的を果たすのに、同じ粒度の処理XとYを
X→Yの順に同期的に実行しているとしましょうか。
この時、Xでは落ちたり遅延しにくいけど、何らかの理由でYは頻繁に落ちたりするとします。
そしてシステムを開発する際に、
いきなりシステム化することを目的にしては絶対にいけません！！
いきなりシステム化することを目的にしては絶対にいけません！！
大事なことなので２回言いました。うんうん。
必ず業務分析をした上で、上記のEとCを行った上で、
ワークフローの中のどのリソース(ヒト)でやっている部分をシステムを使って簡素化したら費用対効果高いかな？と考えるのです。
EとCをすっ飛ばして、ワークフロー全部をシステムで実現しようとするとか、
マジで全力で止めます。 絶対それ費用対効果悪いので。
また「この領域内にある業務プロセスは自社で行っている」という領域の中で、
必須なんだけども、直接的な価値を生んではいないような部分に関しては、外部リソースを使うことを検討。
その上で自社ではどこの範囲をデジタル化するのか？を考える。
Simplify（簡素化）
業務のプロセスや作業内容そのものを簡潔にわかりやすくすることを指します。
人間が行っていた作業を、RPAツールを用いて機械化・自動化することとかもこれに含まれますね。
業務が複雑になるほどヒューマンエラーは発生しやすくなりますので、
トラブルを防止するためにも、学習容易性のためにも、簡素化することで業務の難易度や複雑さを軽減できないか検討する。
これはプルリクの単位を意味にある単位とかにするとか、１チームに複数の責務を割り当てないといったことを含みます。
まとめ
ECRS原則はBPRで使われる原則ですが、
アプリケーションの目的はそもそものビジネスのプロセス側面の設計ですよね？
てことは当然ECRS原則の思想がアプリケーション層にも適用できるわけです。
そう考えると、AA層にて
①戦術的フォークと対応したEからまず始める
は、効果がもっとも大きく出やすいと言えないでしょうか？ その上で
②コンポーネントベース分割になるCをする
そうすることで、無理にマイクロサービス化しなくても充分事足りることは大いにあり得ます。
そしてAA層をこの２つのパターンで改善したら、
③ボトムアップ式にBA層の業務フローとかに反映して相似形にする。
(逆コンウェイ活動)
注意事項
もちろん、戦術的フォークとコンポーネントベース分割は、
AA層からのボトムアップ式アプローチになりますので、ビジネス側の理解も必須になってきます。
それだけでなくBA層からのトップダウンとの折衷式が最も望ましいです。
よって、
BA層での継続的ECRS原則を使った改善案を考える
(BA層では削除とかしても問題ないかの検証とか難しいので、下位のAA層とかで検証)
→AA層で果たして上位BA層での理想形は実現できるかを
戦術的フォークとコンポーネントベース分割を使いつつ検証
→ダメならその結果をBA層に反映
→OKだったらその形へBA層を修正
といったようにBA層～AA層まで、場合によってはEAの一番下のTA層までのサイクルを回し続けます。
また、すべてにおいてBA層とAA層を相似形にする必要はありません。
それによって素早さが損なわれてしまっては本末転倒。
特に【ここは絶対に乖離があってはならない】というハイリターンハイリスクな領域から濃淡をつけて相似形へなるようにすることの方がムダなコストを抑えられます。
是非ともアプリケーションエンジニアの方々も、このECRS原則おさえてみてください。