今日は、
最近、GitHubでSPAアプリケーションのテンプレートを公開して、それをGitHub Pagesなるサイトで公開している、とある業務系のエンジニアの方のサンプルを見て、「あー、パラダイムシフトとかゲームチェンジが現在進行系で進んでるんだなぁ。」などと思った背景など
を少々書こうと思います。
フロントエンド（スマホネイティブやSPA）のアプリケーション開発を少々やってみて思ったのですが、これらのアプリケーション、アーキテクチャ的には、単なる物理３層構成のアプリケーションなんですが、
Open棟梁で実装可能な３層C/S（Desktop + Binary Serialize電文 + ServerサイドB、D層）の開発と比べると、
...生産性が非常に低いです。 なので、単位画面あたりの単価が高くないとキツイ感がありますが、そもそも、こういったアーキテクチャを選定するアプリケーションって、業務系では少ないですよね。
...若しくは、大手が見栄張ってミス・チョイスしている。 業務系は、データ項目数や画面数が多く非常に複雑で、もっぱら「
処理するデータ項目の量」（ ≒ 業務的な機能数 ≒ 開発規模 ≒ 人月工数）で価値を判断されているんだと思ったりしますが、しかし、世の中には、「
単位トランザクション自体の価値」や、「
利用ユーザー数」、または、その両方などの指標で、アプリケーションの価値を判断できるケースがあると思います。
具体的には、
- 金融系の決済や
- 鉄道系のチケット予約、
- ユーザー・エンゲージメント向上が必要な各種Webサービス
などがコレに該当すると思います。
要するに
「単位データ項目（単位画面）あたりの生産性を落としてでも、各種ユーザー・エンゲージメント向上に貢献することの意味が大きい分野があるんじゃないかな？」
と。そう考えると、昨今、ユーザー・エンゲージメントって重要なんだなぁ。と、改めて思ったりしました。確かに、こう言った分野のアプリケーションは、デザインも洗練されています。
...こういう分野にSPAは適合するのでしょう。 また、単位データ項目（単位画面）あたりの価値が低い場合は、
前にも書いたような理由で（単純に割に合わない仕事になって来ているので）、パッケージやサービスの活用がより推奨されるようになっていくと思われます。
...と、昨今、価値基準が大きく変わって来ているので、
（
前提として、ユーザー・エンゲージメントが
必要とされているようなシーンにおいて、）
「古い日式SIer脳で、フロントエンド（スマホネイティブやSPA）アプリケーション開発の見積を、StepやFPの規模 * 組織のプロセス資産である生産性データなんかで見積もってしまわないように。」
と言う話ですが、それ以前に、規模の割に難易度が高く、古い日式SIerでは受注できないケースも多いなど、
「脱労働集約型、人員リンク・ビジネスからのパラダイムシフトとかゲームチェンジとか、そういう感じのモノが現在進行形で起きている。」
と言う事をもっとシッカリと認識した方が良くないか？などと思ったりした次第です。
＜参考＞
トップページ
お知らせ
開発基盤部会
フロントエンドと単位画面あたりの単価的な話
