クラウドデザインパターンの実装から見るCMMIなモノを一度窓から投げ捨てるタイミング

ソフトウェア開発の世界で何が起きてるか、っていう話は、CMMIなシステム開発・ソフトウェア開発の成熟度の観点で、現実世界での捉え方と実践の違いを用いれば説明ができるのではないか、という仮説を今日、というか今、考えた。

例えば、リトライパターンの実装に関する行動でモデリングの例が示せるのではないか。

ここに、業務の一連の手続きのうちに、外部システムを呼び出す、というプロセスがあるとする。決済の最中に別のシステムから与信枠を引き算する指示を投げるようなイメージでいい。そしてこの処理は、似た振る舞いをする10個の業務で同様に発生するとする、とする。

オンプレだろうがなんだろうが、全ての呼び出し行為は当然に失敗する可能性がある。しかしながら、単一のビルド範囲に閉じてるコードで、またはその実行が単一プロセス内に閉じてる場合などでは、その呼出が失敗する可能性は、業務データに不正がない限りは、まぁ低い。外で（物理的なあの）台風が暴れていようが関係がない。

クラウド時代というか、マイクロサービス時代というか、マッシュアップ時代というか、なんでもいいのだけど、外部システムが提供するAPIを呼び出すような処理を業務手続きの最中に実行するのが当然な時代のシステム基盤の「作り」だと、この「呼び出し」という行為は、かなりの頻度で失敗するだろうことを想定したほうがいい。台風で（物理的なあの台風だ）通信経路の途中が停電し、疎通ができなくなることだって本当に起こるし、そんなに大層な話でなくても、相手方のサーバーが何かしらのメンテナンスで数秒の断が発生することなど、ザラ。

なので、外部システムを呼び出す場合には、リトライすることを考慮すべきだ、というのが、今の流れ。当然っちゃー当然。オンプレ単一サーバーでもホントはやったほうがいいことだけど、蓋然性が低いのでこれまで無視してきた、という領域。

このあたりだけを話しても相当長くなるので割愛なのだけど、ホントはここが全ての肝で運用コストのコントロールの意味で根幹部分だったりするのだけど、それでも割愛。（過去にスライド書いてるし）

業務仕様書上、この「リトライをx回しなさいよ、だめならどうこうしなさいよ」の業務的な位置づけと、その振る舞いのシーケンスを、果たしてどこに書くかで、未来は大きく変わってしまう。なのだけど、ではSEさんは業務シーケンスの一部だとしてこれを理解し業務として書くだろうか。非機能要件だと見做して違う定義をするだろうか。

CMMIで例えばレベル3以上にいるSIerにて、これを並列開発するとしてWBSを引く行為を踏まえて、開発を定量的に管理されてるとするならば、この「リトライ」処理は、どのように定義され、いかなる手続きを経由し実装されていくだろうか。

現実世界のコーディングの理想的なモデルでは、このリトライ処理は、業務の粒度とは極力分離し、非機能要件のコントロールとしてライブラリが提供する振る舞いの機能として、業務プロセスの外側に押し出される流れだと思う。

つまりは業務処理のなかで、失敗したら数秒後に再度実行し、合計3回失敗したらエラーとする、みたいなことは、業務の粒度と同じ場所には書かない。

具体的な例でいえば、 .NET な ASP NET Core な DI 環境なら、これは Polly を利用したリトライを含めたパターンの指定だ。業務処理の粒度にはリトライが出てこない。リトライは、外部呼び出し処理を業務が呼び出した先で調整されているので、業務に落ちてきた時点では、リトライが終わったあとになっている。だから、業務フローでは、業務としての成否と、それを超える異常事態かを見るだけでいい。結果だけを考慮することで、粒度を混在させないような工夫ができる。

でもこの動きの指定は、業務仕様書に適切に書けるだろうか。

当然に、優れた経験がある組織では、その管理プロセスがあるが故に、この実装仕様を、仕様書として十二分に書き定義しているだろうし、10個の業務処理に対して適切にコードを共有しながら無駄なく重複なく、書くだろうと思う。

でも、優れた管理プロセスがあるものの、業務シーケンス上にハードコードされたリトライパターンしか知らない世界では、優れた再現性故に、ハードコードされた、将来の修正作業には向かないコードが、量産される可能性は、否定ができない。

リトライパターンを、つまりは、非機能要件を、いかに分離し、コントロールしようとするのか。CMMIの管理や構造把握の文脈で、ソフトウェアの実装構造のデザイン（設計）に当てはめ理解しようと試みる行為の結果は、多分に、これまでの開発プロセスの標準化とは、やはりミスマッチする部分があるはず。

というアイデアを先程、思いついた。というメモ。