前回（１）の続きになりますが、その前回（１）で、タイトルにある「.NET for Apache Spark」は一旦、吹き飛んでしまって、PySparkを使っての技術検証を粛々と進めていますが、お陰様で（？）、Databricks上でKafKaと連携したSpark Structured Streaming的なモノを動かせたような気がします（現時点で、標準出力での出力を確認できてませんがｗ）。

　ソコで、気が付いた事は、既に前回（２）で書いたんですが、昨今の生産技術の施策、「BFマーケティング → コンセプト設計（ココが肝） → 情報展開 → FEニーズとの適合度合いを測定。」と言う流れを念頭にプロジェクト選定した方が良いんじゃないか？なんて思ったりしました。

　そして、「オーケストレーター（パッケージャ」～「パーソナルエージェント（購買代理業者」辺りに、どのようにポジショニングして行くか？という点が、パーソナルエージェント寄りということもあると思いますが、弊部会が「繋ぎ目部会」と別称を名乗っているのも納得で、「より、繋ぎ目が重要になってきている。」と思います（上記のコンセプト設計も、この繋ぎ目と言うキーワードを意識した内容になる）。

　...と言うのも、今回の検証、やはり、世間で騒がれているキーワード（≒ ハズワード）に照らし合わせると、どうしても Spark が中核に見えるんですが、全体をやってみると、重要なのは、クラウドやDockerを用いたIaCだったなぁ。...感が強いんですよね。


　...で、ココまでやって、漸くテンプレートが作成されるに到るのですが、テンプレートの段階で十分複雑なので、恐らく、ココに到達するまでに、環境構築や開発物のビルド＆デプロイもある程度、自動化されていると思います。そして、ココから更に、DevOps Pipelineに乗せるとか、そう言う感じの事をヤって行くと言うのもアリだと思います。

　で、...ですね、最後になりますが、ここ最近の投稿で、既に、言及しましたが、問題は、この、世間の認知から若干、乖離した「繋ぎ目」をどうやって予算化するか？と言う話になります。確かに、「DX 系 DataPipeline の開発を DevOps Pipelineに乗せて行くタメの各種リサーチ」って言っても販社や受託の頃のVC（バリュー・チェーン）と同じ認識の人達には意味が解らないですから。なので、AIとかノーコードとか言って騙すしか無くなってくるんですが（≒ バズ単品問題）、コレだとココからブレークダウンする際に誤解を生んでしまって上手く行きません（と言うか、実際は、考えてないからバズ単品で妥協するんで、ココでの誤解は、そう言う人達にとっては誤解ではないんでしょうね）。

　なんとなくですが、この問題、伝言ゲームの中間で起こっているようなので、なんだかんだ言って、「天地人」を待つしか無いのかもしれませんが、「モノ売りからコト売りへ」（モノ＝バズ単品から、コト＝組立てられた価値）と言う変化が、配管工おじさんの更なる多能工化（マーケティング、企画、プログラム・マネジメント、開発）の追い風になっている気がします。