今回の内容は、
前回の内容の続きになります。最近、以下のようなコンテンツを眺めてたんですが、
「クラウドコンピューティングの流行やいわゆるローコードツールやRPA（Robotic Process Automation）などの普及が進むと、ITエンジニアが専門性を発揮する場が徐々に少なくなってくる。ベンダーがモノづくりをしなくても、ユーザー自身が自分の望むシステムを作れてしまう時代が、徐々にではあるがやってきている。そうしたときにベンダーは、細かいモノづくりよりも自分たちが得意とする業務ソフトウェアやサービスを武器に、ユーザーの業務を変えることをミッションとすることが多くなってくるだろう。」
昨今、SEはアカウント全振りが基本になって来た感があります（大手の元請けなんかは比較的、昔からそうでしたが）。
そうすると、昨今のテクノロジ面の多様化の中、ウワモノのテクノロジ面は手薄になって行くんですが、テクノロジ面を手厚く高度化しろと言う話なら、結局、ウワモノ自体のシェアを上げろ。と言う極論になりガチです...が、まぁ、大多数のプロジェクトは、シェアとは無縁なので、先ずは、シェアを上げないで事業を継続する場合、どうしたら良いのか？と言う事を、本投稿中では考えて行きたいと思います。
...で、全部自力でやろうとすると、シェアが無くて自力だったらコストも制限され、原始的にしかならないので、色々な意味でダメなんだろうな...と。...で、色々と組み合わせてソリューション化して行く必要が出て来ているんですが、この中で、テクノロジ系のリスク・マネジメントをどうするか？が課題となって来ています。
...となると、私のポジションからすると「”リスク評価とリスク対応計画”が重要になりそうだな。」と思っています。...と言うのも、前回も書きましたが、最近のプロダクトの多くは、セルフ・サポート化が進んでおり、「リスク対応」の多くは、ベンダのサポート・エンジニアに投げる事になるので、「リスク評価とリスク対応計画」をどう立てるか？って話が中心になって来た感があるなぁ...と。
よくよく考えると、Open棟梁 v1も大規模開発やオフショア開発のリスク対応だったりはしました。しかし、昨今、テクノロジ面の多様化が進んで来て、テクノロジ面のリスク評価やリスク対応計画段階の重要性が高まって来ている様に思います。と言う事で、Open棟梁 v2以降では、確かに、リスク評価やリスク対応計画に関連する所が増えて来そうな気がします。
ただ、「ライブラリを入れないサポートは無責任になる」問題があるので（と言うか、開発していない範囲の知識量だと、サポート・エンジニア的に不安がある）、この辺りを両立させるために、関連するOSSにコントリビューションして行くなどの対応が求められるんじゃないか？などと思っています。
余談：
最初の方に出て来た、ローコードツールやRPAですが、最近、某ローコード・ツールの話を聞いてきたんですが、コレ、EUC（End-User Computing）というより、次世代RAD（Rapid Application Development）なのでは？という気もしました。確かに、EUCっぽい簡単なユースケースもあるんだと思いますが、機能を見ていくと、次世代のRADツールと言う様な感じの機能を持っている様なので。と言う事で、技術的には簡単どころか難しくなっている様にも思います。
反対の回答として、「シェアを取って行く。」と言う話もあるんですが、最近のMicrosoftが、「モバイルファースト、クラウドファースト」と言った辺りから大きく復活したように、昨今、単体プロダクトのシェア一本勝負は難易度が高く、エコシステム系を考慮する必要があるんだろうとは思います。
Open COBOL Solution WG
