いわゆる仕様と業務例外について
最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。
モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。
（なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多いのですが、業務系の仕様へのアプローチは、どうみても片手落ちに見えます・・。）
まず、仕様の詰め方についてです。
1.仕様の「成立している背景のロジック」を押さえるといいです。
まず基本は「考え方そのもの」を押さえましょうということです。なぜ、こうなったのか？というところを押さえる癖をつけると良いです。どういうロジックでこうなったか？という考え方を全部押さえます。えっと経験的には、業務仕様は大抵は以下の三つメタロジックです。それぞれに背後にあるものが違うので、そのロジックの流れを押さえる必要があります。
1-1 「（事実上の）法律で決まっている」
これは明示・黙示を含みます。明示では本とか参考資料が絶対あるので、これをゲットすることが第一歩です。黙示のものは識者に聞くしか無いです。知っている人は少ないけど、必ずいるので、捕まえてしつこく聞くが必要です。とんでもない量になることもあるけど、逃げたら負けです。事前にある程度の最低限の知識はあった方がよいのですが、いっそのことお客さんに参考書と聞くのも手ではあります。ググれなんとか、って言われたら、ググってからひつこく聞く事。コロンボの如く聞く。あきらめたらそこで試合終了ですよ。
1-2 「一応、試行錯誤があってこういう事情になった。」
これは資料は普通はありません。複数の関係者あたるしかないわけですが、それぞれに「事情」があります。その事情をどのように反映したか？ということがポイントになるので、この「反映の仕方」ってのを押さえます。「システムは妥協である」という名言の通り、なぜここで妥協したのか？ということは非常に重要なポイントです。一番いいのは、休み時間とか立ち話しながら、聞くのがいいです。お客さんが目の前にいるのにドキュメントを棒読みする時間があったら、それはまじめに時間の無駄なので、「内容はこんな感じなんで、あとで読んでおいてもらってですね。実は気になるのはここなんですがああ」って追求しましょう。ググれなんとか、って言われたら、ググってからひつこく聞く事。古畑任三郎の如く聞く。あきらめたらそこで試合終了ですよ。
1-3「適当に決めた。」
・・・・残念ながら大半はこれです。これは全力スルーします。まぁ大抵既存のコード見ればわかります。これは無視すること。ただし、その適当には「度合い」があるのでそれは見極めること。業務を知っている人が決めた適当、と素人SE（含む、素人ユーザー）が決めた適当は意味がまるで違います。前者ならば、それなりに理由があります。それを見逃さないこと。ググれなんとか、って言われたら、以下略。
要は仕様自体を押さえるのではなくて、成立した過程を押さえるということが必要です。仕様はそのまま人間模様になることがあります。そこまで踏み込んで、理解をしておくということが、やはり必要でしょう。「仕様自体はころころ変わるが、メタロジックはかわらないことが多い。」ということは理解すべきです。その区別を理解することが必要です。それがわからないと個別の仕様に振り回されて、切ることができない。んで、なんか極端にふれてしまって、んで、曰く、受託は駄目だ、全部アジャイルだ・・・そうではありません。
尚、こういった「事情」をまとめた資料はきわめて貴重です。しかし残念ながらこれをまとめる「公式のUML的ドキュメント」は存在しません。なので勢いこのようなNarrativeな情報は埋もれてしまいがちですが、これをまとめておくことは有効です。メモでもなんでもいいので、残しておくとあとあと有効な資産になります。
さて次です。
2.特に業務系例外を把握する。
これは難しいですが、非常に有用です。世の中のほとんどは例外でできているということをまずは頭におくことです。しかも世の中の大半の例外系の参考書はシステム例外であって、業務例外には触れていません。挙げ句の果てに、設計漏れを全員でスルーして運用でカバーという決着になり、なんのためのシステムかわからない、ということもあります。・・・まずもって注意すべきは「業務例外は大概は、システム的には正常処理になる」ことが多いですね。
2-1. どこまで戻れるのか？
基本的に業務例外の大半は、「やっぱりやめた。取消・修正・変更です」ってケースだと思ってもらってよいです。まず前提として、どのような業務であっても必ず取消・修正・変更は存在するということは押さえましょう。お客さんが「いや取消はないから」と言っても、なぜかあるので、スルーしないこと。絶対にあるのがオペミスです。入力ミス。徹底的にチェックしても必ず起きる。なので、修正はしなくてはならない。
その場合は、どこまで業務を戻せるか？ということがポイントになります。このときに考慮すべきは、手当されるデータとそれに関わる人間の負荷です。理想は戻せるところまで戻す。ただし、現実は戻れば戻るほどコストが上がります。したがって、現実はある時点までしか遡れません。それを見極めることが重要になります。特にオペミスの場合は、かなり問題になる。そもそも素早く取消・修正を反映して、可能な限りロールバックしないと、確実に損害賠償の話になります。これは金融・証券から始まって、消費材流通の仕組みまで同じこと。
どこまで戻すか？ということの設計・実装は、まぁ・・・こういうと不謹慎ですが、一番厄介で、労力が割かれるし、しかしもっとも面白いところではあります。非常に簡潔に例外業務を捌き、かつ影響度を少なく押さえる「技術」や「ノウハウ」は、完成されている仕組みとしては、”芸術的”に見える事すらあります。個別対応の積み上げは誰でもできますが、一定の方針に基づいて、スマートに「もっとも効率的」に業務ロールバックを行う方針は、言ってみれば、碁の定石・将棋の定跡に似て、「双方よし」の形になっていることが多いです。これは、経験の積み上げによるものであり、自分で発明している場合ではありません。これはマスターしておきたい。簡単じゃないないですけど。上記の仕様の押さえ方の一つの例にもなります。・・現実の問題として、業務例外発生の影響範囲を押さえるのは、関係者の無駄な時間を削減することにもつながりますし、トラブルの発生を未然に防ぐことにもつながります。
2-2. もう、ちょっと具体的に考えましょう。
どこまで例外をハンドルできるかは、業務要請によります。これはユーザー内部は勿論、社外の関係者や、社会的な事情まで依存します。これに加えて、ITの実装技術に精通している必要があります。「技術的にできるのか？できないのか？」という問題は実装を知っている必要があります。よって、時代の流れとともに変わります。
例えば「取消」をする場合を考えてみましょう。
もっとも重要な場合は、今の情報をどこまで活かすか？ということになります。勿論、正常データに影響させないのが原則です。（ただ、抗がん剤と同じで、一気にカタをつけるために影響範囲をみて、正常データも含めて、一部サクリファイさせて再登録をするという事もあります。褒められた対策ではありませんが。これも「技術」の一つです。）正常系を活かす手法は、情報のスプリットです。その上で、元データのうち活かすべきものは、フローを分離して続行させ、取消のフォローは新規でフローを起こし直す形がもっとも影響度が少ないです。ただし、最終のエンドが全部そろって、業務処理の成功判定をする場合は、最初から全部失敗させる方がいいでしょう。
えっと、具体例を挙げましょう。あなたはAmazonさんです。んで、お客さんから本を受注しましたよ。んで在庫を引き当てました。んで、出荷バッチに放りこみました。さて、「いや、すまんさっきの注文したうちの一冊は前に買ったわ、なのでキャンセル。でも同時に注文した別の本はそのまま送ってねw」っていう、かなり、ありがちなキャンセルが入ったとします。
出荷成功の判定が初期の注文と一致したときのみ成功とする場合は、まず原則全部キャンセルです。出荷金額総額で値引きとかやっているケースですね。あとは、入荷先がスプリットなしで、まとめてでしか受け取らない場合も同じです。
そうでない場合は、受注データはスプリットします。それで、正常系の処理はそのまま続行します。キャンセル・アイテムはキャンセルフローに流します。ただし、どの時点にまでこの処理ができるのか、実装依存＋業務依存になります。受注確定->在庫引当->出荷指示->物理ピッキング->・・・という流れで、できる範囲が異なります。実際問題、すでに物理的に出荷のディスパッチが行われていれば、どうしようもないですし。
・・・と、こんな案配で、例外処理の切り戻しは行われます。これはまだ、簡単な方です。では、取消の代わりに別の商品に差し替えてくれ、という話になったらどうしましょう？また、出荷ハンドリングの最中に物理事故で物品が損傷した場合はどうしますか？・・枚挙に暇がないことはすぐにわかるでしょう。これらのケースは修正に当たるわけで、この場合は単純に正常系から分離すればよい、という話ではなく、元データの上書き（ただし部分的）とスプリットを併用することになることが多いです。
いずれにしろ、このときに考慮されるのは、技術的にどこまで戻れるか？という話と、戻ることによる影響のコストを考慮する必要があるのは、わかると思います。上記の例であれば、取消のロールバックがどこまで可能かは、まさに業務的なコストに依存します。このような例外はごく一部だから無視してよい、という意見は、あえていいますが非常に大きな間違いです。実際の業務例外系のデータ量が金額ベースで正常系に比較してたったの1%ですが、その対応に総人件費のコストの30%がかかっているということも珍しくありません。また、その1%の例外処理が、業界慣行や法令また会社の評判に大きく影響するケースもあり、定量化できないリスクになる場合や、そもそも期待リスクが大きすぎて（例、医療系や航空・運輸系といった間違うと人が死ぬようなケース）対応せざるを得ないケースが多いということは知っておくべきです。
2-3. 運用でカバーは最後の手段であって、最初の手段ではないですよ。
とはいえ、全部個別に聞いていたら終わらないというのも事実であります。手法がわからない場合や、実装ができない場合は、仕方がないので「運用でカバー」で逃げますが、これは魔法の呪文ではありません。常に通用するわけではありません。どこまで逃げるかどうかは、まさにコストと経験知によります。仕方がないから運用で逃げますか？という話になったときには、必ず既存の仕組みではなく新規の仕組みでなんとかならないか？ということは考えるようにしましょう。ユーザーさんから見るとこういった部分は積年の負担がかかっている部分です。ここを手当するだけでも、相当にメリットがあることが多いです。
こういった例外を丁寧に押さえることが、「仕様を押さえる」ことにもつながります。もっとも労力がかかりますが、しかし、必ずカバーしなければいけない部分ですね。
・・・・とまぁ、こんな感じで、業務仕様と業務例外を押さえておくと、なにかと役に立ちます。漫然とモデリングの教科書を読んだり、既存の仕様書やプログラムの辻褄合わせに時間をさくよりも、現場に出て「具体的な解決案」の背景やロジック、実績を学ぶ方がよっぽど「ソリューション」を手に入れる事ができます。頭でっかちにデータこねくりまわしたり、出来合いのパッケージをカスタマイズしたところで、限界があるのは誰でもわかることです。それでは一時のブームには乗れるでしょうが、まったく生き残ることはできません。現場で試行錯誤しながらできた解決案には、それなりに根拠があります。それを押さえましょう。
ま、超個人的なメモなので、適当に読み飛ばしておいてください。
