Image for post
Image for post

当方が経営するチームシロッコ社。ぱっと見、何をやってるかわからないと良く言われるのですが、美味しい台湾茶の販売、その活動を通じて蓄積されるコンシューマ消費の旬なノウハウと元金融系システム屋な勤め人の経験を最大限に活かした迅速で安全なシステム開発のご支援を、事業の二本軸として日々頑張っております。

後者のシステム開発では、クラウドを利用した小回りの効く金融サイドクオリティの業務システム開発を法人向けに提供させてるのですが、そのお客さんと、来年1~3月の開発計画MTGをやってきました、と。

そのメモというか、記録というか。雑感日記です。

楽しいアイデアを自分たちで実現していきたいっていう想いと、自分たちこそが自社のビジネスを守り創り上げているんだ、っていう強い自信、そして、自分たちだけでは出来ないことの領域はこれだ、っていう認識を同時に持ち合わせておられる方々なのですが、やはりその手の方々とのMTGは楽しいんですよね。

あまりの直近リリースな相談を聞いて思わず「近っ」と言葉にしても、むしろ、ではこうやって作ろう、これならいける、と話題が前に倒れていく感じがすぐに飛び出てくるといいますか。相当に配慮して頂いた上での相談なので、いわゆる「発注元の横柄な態度」からは、もっとも遠い短期決戦ですね(?

当社は全般的にお客さんに恵まれてるのですが、そのなかでも業務アイデアがとてもぐぃぐぃとくる会社さんだと、当社側はむしろ、金融経験を活かした上での専門領域の知識・実装力の発揮に特化することで、キレイな分業が成立します。

共創っていうほどに共創してないんですが、まぁでもこれも、広義の共創だと思います。

「そのアイデアをこの期間で実現するなら、この作りにしますが、これは安全だとはいえ暫定なので、先々これを直していきましょう」

「こちらを優先することで、こういう今どきな機能まで発展することが出来ます。その動きをみてからとして、これを後回しにしましょう」

そんな開発バックログの調整・整理を中心に、その会社が目指してる未来のサービス像を共有しながらのディスカッションもある場です。

そんなディスカッションベースの場で共有されたアイデア・業務の有り様をたたき台に、向こう3ヶ月を目処に、順次コードを生み出しながら、既存の実装とすり合わせ改良しつつ創り上げていきます。

当社が絡む案件の場合、業務仕様側でさえも随時調整し更新していくことが殆どです。

画面の要素が法務都合で変わったり、入力フォームの必須判定が連携システムの都合で変更に、打ち出しの都合で値の拾い方を変えたい、リリース直前でのそんな仕様変更、よくありますよね。

当社の場合、顧客の業務にあわせた「変わりそうな部分」を、当初からほどほどに想定した上で開発しますので、出来る限り変えられるものは変えます。

申し訳無さそうに「すいません今更ここ変えたいんですがどうですか?」と相談されることもありますが、快く返信します。「そこは変えやすいように作ってあるので大丈夫ですよ」

この「安心」を、当社のシステム開発では、売りの軸足にしようと奮闘してます。

結果的に、ザ「受託開発での工数を想定した積み上げ算な見積もり」には、あまり意味がありませんので、そのようなご依頼はお断りしています。概要設計・見積・詳細設計・開発・納品・検収 なフローをトレースする「ザ・受託開発」を、当社は好みません。好まないといいますか、当社は小さい組織ですので、その見積もり失敗が原因で容易に会社がコケてしまい、それは先方にもご迷惑をおかけしてしまいます。

そしてなによりも、新しいことを実現しようと自分たちが奮闘されてる会社さんは皆一様に、新しいものを作ろうとしてる開発で、アイデア時点で出せる見積もりは大概で雑な、もっとはっきり言って「意味がない=実効性がない」ものであることを知っています

ですので、実現可能な方法を提示し、実際に形にすることが当社側の専門性の発揮として、明確な期待につながっていきます。

契約自由の原則が大好きな当社ですので、その開発に掛かる関係性の構築の意味では(言い換えれば、そのIT開発の実践は)「なんちゃって」アジャイルになっています。

スクラムマスターもいませんし、リリースサイクルには幅があり、1日以内のこともあれば1ヶ月のこともあります。単体テストも意図的に業務的に臭い部分に絞るのでコードカバー率でいえば低いものです。

それでも、成立してます。

実際にモノは出来上がり、運用が開始され、世界に向けてそのポートを開いていきます。

常に何かしらのエンハンスが待機し、技術的な負債の解消は日々実践され、業務機能の継続的な開発が行われていきます。

ノリの「なんちゃって」アジャイルでも、飛び抜けてしまえば、亜種だろうが、超絶アジャイルの実践にはなります。それは結果として、新たな価値を生み出します。実際に、生み出してます。

他の組織では再現が出来ないだろう開発プロセス論には意味がないのでしょうけれども、でも今のお客さんと当社のメンバーであれば、それは継続的な価値生成の再現が出来ているわけで、我々にとっては、それはとても有効なメソッドとして、自信に繋がっています。

「楽しいなぁ、システム開発って」

と今回も思ったのでした。(オチはないです)


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Image for post
Image for post

TL;DR

この記事は、

  • ASP.NET Core + EF Core + ORM like Dapper 環境下で
  • RDB に対する複数の ORM による操作を
  • 単一のDB接続と単一のDBトランザクションとしてDI側で管理し
  • ASP NET Core の Scoped = ユーザーセッションの範囲での
  • 複数のDIを跨いだ DBトランザクションの Commit, Rollback を実現する

ための苦労や理屈、実装の挑戦が書かれています。

また、その成果として、 OneWorldDbClient という(壮大な名前の)コンポートを作成し、公開 することが出来ました。

<https://github.com/SiroccoHub/OneWorldDbClient>

このコンポーネントを利用することで、

  • 複数のORM …

Image for post
Image for post

度重なる事件で、貧者国家の武器的なノリさえ感じられた仮想通貨界隈への久々の明るい系話に見えるこの件。

この件について、ツイートからの転載。

https://twitter.com/arichika/status/1140961823526539264

地味に真面目なFacebookの仮想通貨、Libra。ザ暗号資産でなく、集団的投資での電子決済基盤向け集金構造とプール資産の運用益の分配、というか、株式出資分と通貨発行分がペッグで現実世界に投資され運用に使うようなモデルなので、集団的銀行運営スキームったほうが適切な気も。全体設計はキレイ。

以前に仮想通的なエネルギー単位としてのエネルギペッグ型の話を一部してたことあるけど、まんまそれとして読んでも違和感ないですわ。当時の内部の方どうぞ中身を見てくだされ。許可型からの滑らかな移動とか、利益を出す部分をマイニングにしてないとことか。

ブロックチェーン部分もかなり意識して設計し直してるようにみえてて、トランザクションの確定の支援とログの共有に主軸あるモデルに見えるので(ちゃんと読んでないけど)、今みたいな、泥臭い騙し合いのための無駄な計算資源の浪費というマイニングからは、距離が取れるような設計に寄せる。

マネロン対策も視野には入れてるし(簡単な明記しかないけど)、アホなスマートコントラクトに対しても言語開発してるぐらいなのでなかなかですな。マネロン系は、エンドでの既存体制を使うことになるかもねこれ。

良くも悪くも、ビットコインのネガ=個性を潰したので、今の社会の、自然利子率がプラスである限りは金が金を生み続ける、いうプロセスを、グローバルにうっすく展開したような、でも地味にでかい絵に落ち着けた、って感じ。

彼らはベッグ先の運用が可能で(というかそれしかないし、だから意味がある)、それを分配することでシステムの維持を、とは言ってるので、透明性でしょうな。結果的に、長生き出来る要素がかなり揃ってる。なかなか感心。偉そうで我ながらアレだけど、これは感心した。

どーでもいいけど、参加企業の現地APIを経由していけば、アービトラージ、なんとかなる気がややするね。10万個ぐらいのアカウント調達しておけば、案外となんとかなるかもしれん。(それはそれとして

結局は、既存のマネー運用と同じ構造を保ったことが大きい。リザーブの運用益での配分は肝だけど、動き出せば誰もそれを気にしなくなるところ、要は透明性だと思う。壮大な詐欺にならないような相互監視のモデルにまでなるか、否か。

実装の仕方・方向性次第では、落ち目のFBの集金システムかよ!ってなるのかもなぁと思ってものの、現時点ではその色よりかは、現状の社会がモザイク状であることを利用したテクノロジーベースでの効率的な資金運用の方法の模索に見える。

結果それは悪くないんだ。でもそれって資金運用の方法って話に軸足が出てくるので、正直、所謂古典的なブロックチェーンが持っていた、アルゴリズムによるモチベーションのマネジメント、って感じではないよね。多少その色を残す意図があるようには見えはするので、これは今後読み込んでみる。

そりゃ Visa も乗るわって構図。でもこのメッセージで出せるのが米国主軸の力だなぁ。

我らがジャパンはどう出るかですな。これ地味に運用のメリットがある話だったはずで、海外資産ベースでの運用主体にもなれは話だと思う。電子決済で○○ペイだと言い放っていた時代がもう既に過去になってしまいましたな。あっはっは。

以降追記。

国内での扱い、どうするかね。

○○Pay に盛り上がってる国内だけど、結局やってることは、非常に近視眼的なビジネスでのパイの奪い合いに着地し、クラウドのときと同じ構造になったなこれ、と。

国内○○ペイ平成の陣は、国内ビジネス的にはよく見る光景だった。資本を利用し初期シェアを奪い合い、行政に食い込んでみたりして、プラットフォーム化を確実のものにする。関係者を逃げられなくし足場を作る。潰せなくする。よかったね、と。そして平成と共に終焉を告げる。あ、これって Suica で良かったやつね、と。

事実、単なる電子決済なら、ブロックチェーンなんていらない。QRコードなんてホントどうでもいい話だったりするわけで、そこにプラットフォーマーとしてのなにかを見出して争うなんて可愛い話なんだけれども、でも当人達はホントに真剣。わかる。零細企業だけど経営してるからわかるよ。本気の1万円の決済もあるし、勢いの500万円の決済もある。(何の話

デカイ夢と理想には、小手先の賢さでは勝てない。

電子計算技術では負けっぱなしですが、国内有力メディアが話題にし、新進気鋭なネットメディアで識者が熱く語った国内電子決済の戦いも、多分地味に焦げ付いてドメスティックな熱意に消費され、クラウドの戦いと同じ様相を見せそう。

主戦場は、そこでは無かった。

そこではない、というか。ここでもまた、社会の運用実装と、物理を忘れた哲学の議論が、物理の上に成立している電子計算の革命の力と、社会が現実として運用可能な状態でしか成立しないことと、そのバランスのなかで無限の可能性で流動することを、すっかり忘れてしまった、というか。

主戦場を避けて新たな競争の場を作るのが、上手い人達が集まりやすい国というのは、強いですねこれホント。


原因は、LocalDB のプロセスがファイルをアタッチしたままだから。これは、コード側で Dispose() しても GC してもダメ。呼び出し元のプロセスが落ちるまでは mdf ファイルは握られている。

単体テストを並列で走らせたりした際に困ることになる。

で、この問題は、利用し終わった際に、自分で自分をデタッチしてあげることで解決する。

例えば、単体テスト用のラッパー DbContext で、以下のように、生コンテキストを使って、自分をデタッチしてあげるだけ。

protected virtual void Dispose(bool disposing)
{
if (!disposedValue)
{
if (disposing)
{
var sql =
"declare @dbname varchar(max);"
+ "set @dbname = quotename(db_name());"
+ "exec('ALTER DATABASE ' + @dbname + ' SET OFFLINE WITH ROLLBACK IMMEDIATE;'); "
+ "exec('sp_detach_db ' + @dbname + ';'); ";
Context.Database.ExecuteSqlCommand(sql);
Context.Dispose();
}
disposedValue = true;
}
}

これで mdf ファイルはデタッチされ解放される。あとは、コードのなかで File.Delete() してもよし、ディレクトリ毎消してもよし。


課題の概要

Azure Web App (Windows) で動作している ASP.NET Core の Memory Dump を取得し、その Dump File を JetBrains の dotMemory で解析する際に、ファイルを開く時点で、以下のエラーが発生することがあります。

Image for post
Image for post
---------------------------
dotMemory
---------------------------
Unable to import the dump: The matching DAC file (mscordaccore.dll, v4.6.27110.04, x86) was not found neither on local machine nor on public Mi …


この NuGet モジュールは、Azure Functions 2.0 runtime / .NET Core 2.0 環境下で、デバッグや xUnit を利用した単体テストなどの実行環境にあわせてユーザーが指定する設定値をどのようにプログラムに渡すか、という課題に対して、 ASP.NET Core で定評がある ConfigurationBuilder() を利用して解決する、幾つかのアプローチのうちの一つの実装例です。

NuGet is here.

Project site on GitHub is here.

TL;DR;

ASP.NET Core で導入された ConfigurationBuilder() はとても便利で使いやすい実装です。これを、Azure Functions 環境下でも便利に使い …


タイトルは派手だけど言わんとしてる事はシンプルで、こりゃ日本だと大変じゃの的な。

ガートナーさんが最近伝えてるメッセージの、 DevSecOps と CARTA continuous adaptive risk and trust assessment アプローチ、Run / Build / Plan のプロセスに象徴されるトレンドの話(の入り口、エッセンス)を今更ですが聞きましたと。

聞いていて最初に、マイクロソフトが Windows XP で苦労し改善してきた歴史としての SDL Security Development Lifecycle を思い出し、そのあと、OSS 時代のアジャイルスクラムな開発サイクルでの情報セキュリティ、サイバーセキュリティ、非機能要件を意識したアーキテクチャをどこで担保するかを思い出し、そして、あぁ、Trust は Assurance でよねえ、となり。

つまりは少なくともガートナーさんは、ITでモノを造るという事はそういう事だと認識してメッセージを発してる。これそのものは、大変同意するメッセージだ。

広義の意味でのセキュリティでいいのだけど、大半のセキュリティ対策の現実は、まず何かを作り出そうとした時点の組織構造で、概ね決まってしまう。正確にはそれは、組織の構造ではなく「誰がどのフェーズで何をどの程度言えて合意形成していけるか」に尽きる。

んなもん全ての話においてそうだろ。

そうなんす。

だから課題であって、既存のサービスや製品、何かの体制維持で成功したからといって、今我々が抱えている課題の解決に、それが役立つとはまるで言えないのよ、という当たり前の話を、今一度我々は声に出して理解しなきゃならんフェーズにきてる。

残念ながら相手は、サイバーセキュリティである。情報セキュリティである。DOHC16バルブ+ダブルウィッシュボーンだから速いなんて牧歌的なノリの世界ではないのであるよ。

そもそもでセキュリティ人材派遣などと銘打って勉強させれば出来る話でもなく、有効で妥当で低コストな対策は、開発工程のありとあらゆる所にチャンスがあり、そして少なくともエクセル仕様書では表現は困難で、見積という行為の意味さえ難しい。

その中で、チームとして知恵を出し合い、直すことに変えることに怯えず、ベターとベストの間で模索を続ける CI なアジャイルスクラムなDevOpsなサイクルの上で、恒常的なプロセスとして普通にセキュリティを考えていきましょう、という事を、そんなことに慣れてない人材を軸足として、組織戦でこなせるだろうか。それで成功するほどのプラクティスなんてあるのか。Googleには、マイクロソフトには、ありそうだけど、国内の業界のモデルで、成立するだろうか。

知らない間に三途の川の向こう側にいて、気がついたので戻ろうとしたのだけと、あれ、三途の川って、こんなに深くて広かったっけ?あぁ、そういや活動してる地溝帯だったっけか、って感じ。

DevSecOps 的な事も CARTA なアプローチも、マイクロSIで程よく丸投げしてくれている方が楽に着地する。船頭少ないので。ウチではそう感じる。

なんか、大変よね。だからエンジニアは経営視点を持てという話になるし(情報セキュリティ対策なんて経営課題なんすよ?)、コード書けないSEなんて、という話だし、社員全員にプログラミングとは、を教える訳で、なのにそれに現場から小言もでて勘違いするわ茶化し合うわ経営や管理は率先してコード書かないわ(挙げ句COBOLなら書いてたとか言い出すわけ)で、そりゃー、難しいですわよ。

解決には、言うこと。話すこと。言葉で表明し、認識がずれてることに双方気が付いて、言葉を交わし続けながら、実践し続けるしかない。


Image for post
Image for post
今は無き親父がエンジンをベースに自分で作ったコンプレッサー。結構な勢いで動作効率が悪い。

Fintechブームのなかで、SoR (System of Record)系に手を出す若手技術者中心の企業もちらほら出てきました。いざお金や契約が絡むシステムを創ることになりますと、やはりというかいろいろとビビるそうです。いやー多分、ソシャゲ界隈の営業や顧客サイドからの圧力のほうが厳しいんじゃないかな、と想像するんですが、それは本題ではありません。

今回の資料は、SoRなシステムを創る際に、創ってる最中に、そのシステムは妥当なんだろうか、という不安に苛まれた際、ちょっと横目に見てみる資料です。余計不安になるとか言わないの。最近、このネタを若手中心、業務系分散システム初心者に向けて話すことがあったので公開します。

業務システムっていうよりは I/O の塊の処理系っていう話よね。

今回の公開の背景

SoRなシステムに携わっている人達も当然、SoEでハイトランなシステムを担ってる人達と同様に、システムを設計し構築し運用していく際には、様々な事にぶつかり、いろいろと考えを新たにする機会を噛みしめ、失敗こそ糧だなぁと確信しつつも不安の中で模索していくわけです。

(ゲームやネット事業系やガチの交通機関系とか)大規模なシステムの開発や運用に、技術や部署の壁を越えて知見を得る程度に携われる経験は、実際には限られてるわけで、派手だけとモノシリックなシステムで完結してしまう規模のFintech企業や、大規模でも組織の壁が高く誰かが書いた書く前から終わってる仕様書からコードを転記する仕事に従事してたりすると、職務経歴書の割に、考える事を知らずに転職することになるなんてことも、ままある話です。

特に課題になるのは、若手の育成でしょう。大学で高専でCやJavaを書いていたっていう経験と、実務現場での分散系の業務システムとは、その実践においてやはり、考慮することに違いがあるのは事実です。

でも、その違いを知る、考慮する際の取っ掛かりというか、モデルがないよねぇ、と常々思ってまして、その整理をした資料です。

あわせて、以下の資料も面白く使えるんではないか、と期待してます。

ディスカッション、ご意見ほか

arichika.taniguchi は、https://twitter.com/arichika とか、https://www.facebook.com/arichika.taniguchi このあたりにいます。

arichika.taniguchi

President of team Sirocco, LLC / Financal Technology を中心に、技術界隈を実務もやりつつ見続けてます。

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store