magnoliaさんのLT概要
見事に意表を突くような内容であり、例外的な業務の考え方や、
通常業務と例外業務との分け方、すなわち両者をどのくらいの結合度合いで管理したかによる、メリットデメリットのお話がありました。
前提
ここでいう例外業務はtry-catchの例外処理のことではない。
めったに発生しない通常業務以外の業務処理のことを【例外】と呼ぶことにする。
たとえば、年末年始だけ特別なルールが適用された業務になるとか、
普段の通常業務とは違った流れの業務フローのことを【例外業務】と呼んでいる。
例外業務の特徴
組織を成立させる業務には、その背後に様々なルールが存在している。
プロセスの面における業務ルールから、データの取り扱い方に関するルールまで。
多岐にわたる。
身の回りのの例外業務
数年前に、「よいコード悪いコード」の著者のミノ駆動さんから伺った、
クリスマスシーズンにおけるピザ？の発注トラブル問題のことを思い出しました。
この時、クリスマスシーズンは普段とは桁違いな注文が殺到するそうです。
にもかかわらず、普段の在庫数やスタッフ数というカオスな状況であったがゆえに、
エンドユーザーの所に届くのが非常に遅れて大混乱になった。
というお話を聞いたことがあります。
これはまさに、今回の記事でいう例外業務といえることではないでしょうか？
通常業務では適用されない業務ルールが適用されるべき状況であるにもかかわらず、
通常業務と同じルールが適用されてしまって大混乱という事例がある。
事務処理と例外の関係性
年末調整の入力などの事務的な処理のお話が出てきました。
実はこの事務的な処理は、例外だらけであるし、大量のルールから成り立つ。
しかもやっかいなことに、先月まで例外業務であったものが、今は通常業務に。
通常業務であったものが、今は例外業務に変化するなんてこともある。
たとえば法律の変化とか、外部環境変化に伴って事業戦略を変更した際などに
それは発生する。
通常業務と例外業務の分け方
通常業務との結合度合いを密にしても疎にしてもメリットデメリットが共存しあう。
ここでは、その分け方についてのお話をまとめておく。
個人の見解
２つの業務の分け方は非常に重要であり、かつ頭を悩ませるものである。
これはビジネスアーキテクトとして、あまり前職で意識ができていなかったものである。
というのも抱えていた案件の片方は、メインで例外業務を扱っており、
その際のビジネスアーキテクチャを考える案件であったからだ。
対して、もう片方の民間ビジネスの大規模システムの案件では、
どちらかというと、通常業務がメインの対象であり、例外業務はそんなに扱う場面がなかったからだ。
脅威モデリングとの組み合わせ
全体のLTが終わってから振り返ってみると、小笠さんの脅威モデリングとの親和性が非常に高いと感じました。
ビジネスの脅威として、例外業務であったものが環境変化で通常業務へと変化する
脅威は避けられないし、無視してはならない。
さらにそれらの業務の結合度合いを疎にしているがために、発生するトラブルもある。
(疎結合にしてるメリットももちろんあるが)
勿論、密にしているがために起こる脅威だってある。
しかしながら、それらは実際に業務を運用してみないことには不明な部分が多い。
個人の見解①
小さくABテスト的に疎結合にしてる時と、蜜結合にしている時の両パターンを
小さい実験室的環境を用意して、どちらがより良いかを比較してみるのは、
１つの良い方法だと感じる。
もちろんその実験環境を用意するコストはかかるものの、
小さく検証してみれば、後からのリターンで回収できるし、
その実験の知見は組織にとって、ナレッジとして蓄積できるはずだ。
個人の見解②
ABテストを行えない場合には、時間をかけてでも、脅威モデリングを使って
蜜結合にした場合と、疎結合にした場合のそれぞれの脅威を
アーキテクチャから要求にフィードバックかける形で明らかにする必要があると感じる。
(下図のように、アーキテクチャから前工程の要求へ反映)
しかもそれは、ビジネスアーキテクトやアプリケーションエンジニアが、コラボしながらプロセスの観点でステークホルダーにどんな脅威が想定されるのか？
ビジネスアーキテクトとデータエンジニアが、コラボしながら情報の観点でステークホルダーにどんな脅威が想定されるのか？
などを説明し、蜜結合と疎結合どちらがより避けたい事象が起きやすいのか？
を定性的にジャッジしてもらうしかない。
疎結合のデメリット
疎結合にしておくことで、業務の認知すべき範囲を減らすことができ、
運用者含む利害関係者にとっての認知負荷の量は明らかに減らせるものの、
デメリットも存在する。
組織的な問題
疎結合の度合いによっては、大きなデメリットになりかねないと
Magnoliaさんから直接聞きました。
というのも、同じ組織であるにもかかわらず、
通常業務と例外業務という違いだけで、完全に疎結合状態にしてしまったら、
そもそもそれって同じ組織である意味がない とのこと。
同じ目的に向いて動いているにもかかわらず、業務特性が違うというだけで、
完全に分離してしまうのは、確かに全体として見た時に違和感しかない。
全体像を考えられない
急遽、例外業務としての振る舞いを求められた際に、
通常業務のことしか知らないというだけで対応できないなんてことにもなる。
切り替わる可能性
しかも、通常から例外。例外から通常へと切り替わる可能性が低いなら
疎にしておくのもありだが、可能性高いことが予想されるのなら、
疎結合にしておくことによって、誤ってどちらか一方しか変更されていない
なんてことになりかねない。
蜜結合のメリットデメリット
メリット
上記で疎結合状態にすることによるデメリットを記載した。
あえてLeSS型の組織のように１つに蜜結合にしているのも、それはそれでメリットがあるともいえる。
確かに認知負荷はかかるし、変更の際のコストもかかるものの、通常と例外の境界をなくし、自分たちの管理する業務の全体像を俯瞰しやすいからである。
コロコロと例外と通常と変わるビジネス
あまり見かけないものではあるものの、通常業務と例外業務とがコロコロと入れ替わるようなビジネスがもしかしたらあるかもしれない。
その場合には、疎結合にしているよりも、蜜結合にしている方が、変更のし忘れなどのリスクを低減できる。
デメリット
しかしながら、結局蜜結合にした場合にも、やはりデメリットが存在する。
通常業務と例外業務とが密に結合した状態では、データモデルの認知範囲も広がり、
かつ コードの量が増え、複雑化した泥団子アプリケーションになりやすい。
なぜなら例外業務は、ルールの量が膨大であり、業務フローが複雑。
すなわちコード自体が増加傾向になったり、非常に複雑化しやすい。
結果、品質保証がしにくくなり、リリースが遅れるという状況が生まれやすい。
戦術的フォークの注意点
私は発表の中で、
「リファクタリングの際に、まずは余計なコードを削りましょう(戦術的フォーク)」
と言ってしまったものの、ある意味これはミスリーディングと感じました。
戦術的フォークの内容は以下の記事を参照ください。
なんでかというと、通常業務と例外業務のコードが１つのモノリスにまとまっていた場合、
仮に通常業務のことしか深く理解していない開発者が、
例外業務のコードを見て「使われていないコード」と誤解して消してしまう可能性ある。
つまり、
消すことによる脅威として、そのコードが例外業務コードであった場合
という懸念事項がある。
消すにしても、全体の業務を俯瞰して理解してる者が、
消したことによるリスクも抑えた上で、戦術的フォークを使って消す必要がある。
例外業務とセキュリティ
Q&Aコーナーでの小笠さんからの感想で得た知見になります。
例外業務部分の脆弱性
脆弱性診断をコンサルとしてやっている小笠さん曰く、
例外業務の処理の部分は、意外とアクセス権が誰でも見られてしまうことが多いとのこと。
なので、内部不正を想定したシナリオを考えた場合、セキュリティがガバガバなままだそう。
理由としては、メインの通常業務に関心が行きがちであったり、
後付けで急いで開発しがちなので、どうしてもバリデーション甘かったりして、いろんな脆弱性が沢山見受けられるのだそう。
通常業務と例外業務とを完全疎結合にした場合の脆弱性
通常業務と例外業務とを別システムで開発の場合、プラットフォーム側に脆弱性を持ち始めてしまうのだそう。
この部分はなぜそうなるのか？ メカニズムがよくわかっていないため、
今後の宿題としたいと思っております。
まとめ
通常業務と例外業務との間に一定の距離をあける戦略的設計が重要。
しかしながら、蜜結合にした場合と疎結合にした場合には、どちらにもメリットデメリットが存在する。
脅威モデリングと組み合わせて検討し、常に業務の一貫性と整合性のリスクを抑えた設計を心掛ける。