「令和」二発目は、某弊、生産技術界隈でBuzzったケド、ダメだった過去の生産性向上施策の一覧を作成してみようと思います。別に古傷をえぐろうという話ではなく、ココでAS-ISの総括を行い、最後に、TO-BE的な何かを見出してみたいと思います。

＜アウトライン＞

---

＜分散オブジェクト（COM、CORBA）＞

　私は、2000年入社当時、分散オブジェクト技術を基幹系システムに適用すると言う事で、COM+を用いた案件の基盤側に携わっていました。

　当時、分散オブジェクトは、標準化により相互運用可能なコンポーネントをネットワーク越しに再利用可能にすると言う事で、QCDF(品質(Quality)、価格(Cost)、納期や入手性(Delivery)、柔軟性(Flexibility))向上に寄与すると言われていましたが、分散トランザクションや、インターフェイス継承によるバイナリ互換は、ブラック・ボックス化されたVBで業務を書くエンジニアにとっても難しい概念でした。

　その後、流行った技術は、下記のSOAPを経由してのRESTやJSON-RPCのWebAPIでした。端的に言うと、分散オブジェクトはオーバースペックだったように思います。

＜オブジェクト指向の分析・設計（OOA、OOD）＞

　こちらは、「オブジェクト指向の分析・設計・プログラミング（OOA、OOD、OOP）」と言うプロセスを経る事で、QCDF向上に寄与するという話でしたが、プログラミング（OOP）は、ワリと一般化したトコロまで来たかと思いますが、分析・設計（OOA、OOD）に関しては、特に業務系アプリケーションでは、あまり良いメソッドが産まれませんでした。

　一方で、「オブジェクトの状態」と言う概念が重要になる制御系やゲーム系のアプリケーションでは、OOA、OODは、ワリと、使われているかもしれないので、手段がドメインに適合していない場合、無理矢理ハメようと試行錯誤しても効果が出難い。と言う事かと思います。

＜SOAP、SOA（Service-Oriented Architecture）＞

　SOAPは、分散オブジェクトの後継と考えて良いと思います。仕様が、HTTP＋XMLベースになったため、より容易に、多様なランタイム上に実装可能になりました。

　しかし、昨今、XMLベースのSOAPではなく、JSONベースのRESTやJSON-RPCのWebAPIが隆盛しています。単純に、WS-*がダメだったという話かもしれませんが、XMLで仕様を策定すると（、SAMLなんかもそうですが）、色々と難しくなりガチで、多様なランタイム上にライブラリが着いて来ない。という話のようにも思います。

　そして、SOA（Service-Oriented Architecture）ですが、コノ、"ナントカArchitecture"と言う用語も、「アーキテクチャ宇宙飛行士」的なのかもしれません。「アーキテクチャ宇宙飛行士」については下記の記事を参照ですが、


　ざっくり、


　と言う人達を指して言うらしいです。

＜この新しい開発言語は生産性が高い！的な。＞

　過去に打ち出された「この新しい開発言語は生産性が高い！」的な節操のないマーケット略奪戦略は、戦略レベルで悉く失敗しましたね...。何故か？何故なら、ステップ規模が減っても、FP生産性って大差無いジャン？（ちなみに、ステップ生産性も下がったりするが、これは指標の問題）

　以上。

＜テスト自動化（GUIテストツールとTDD）＞

　こちらは、コチラに書いた通りです。適合しないドメインに目的化された手段を持ち込んでしまった感じで、前述の「オブジェクト指向の分析・設計」に近い話のように思います。

　簡単に言うと、


　と言う事かと思います。

　また、GUIテストツールはUIA（UI Automation）系の技術を使用していますが、これらは、難しく、RPAなんかも「UIA（＋AI）」みたいなものだと思うので、案外、暗礁に乗り上げる気がしています。

＜DevOps（CI/CD、IaaC、OpenPaaS）＞

　こちらも、≒、前述のテスト自動化です。コチラに書いたように、自ドメイン（SI事業領域）に適合させるという話ではなく、自ドメインをパッケージ・サービス領域にまでシフトさせれば行けるのかもしれません。

＜Microservice & Serverless Architecture＞

　PaaSないしはFaaSは、PoC的な案件をRADするには良い環境かも知れません。ただ、これも、"ナントカArchitecture"系なので、全体像は「アーキテクチャ宇宙飛行士」系のように思います。丁度、「DDD 指向マイクロサービスの設計」という記事もあり、コレに、


　に近いノリを感じてしまうのは、私ダケでは無い気がします。

　コレら「アーキテクチャ宇宙飛行士」系は、一見すると結果に結び付きそうな感がありますが、実際は、


　と言う事で、研究し続けても実を結び難い事が多い事を先ず理解し、「結局、定量的に評価できないとデマンドサイドも納得しない。」という点を肝に銘じて取り組んだ方がイイかと思います。

＜ユーザインタフェースとデータアクセス＞

　ユーザインタフェースだとクロスプラットフォームなテクノロジ、データアクセスだとORM（Object-relational mapping）ライブラリなどが、この20年の間に出て来ましたが、何れも、大きな問題は決していない気がします。

　この理由を以下の様に考えています。


　他にも色々と理由は考えられますが、何れにせよ、生産技術界隈で、上記のようなテクノロジに取り組んで、結果を出した人と言うのは存在しない訳で、仮に上記が大きな生産性向上に寄与したとしても、それは単なるレギュレーション変更でしかないように思います。

＜フロントエンド系全般＞

　フロントエンド自体は隆盛していますが、付随する生産性向上施策はホボ、野放し状態ではあります。しかし、特にSPAのJavaScriptフレームワークのライフサイクルが短く、積み上げたスタックが崩れる「賽の河原」状態であることが問題である気がします。

　このように、ライフサイクルが短いケースでは、基礎的なテンプレートやライブラリの整備ぐらいやったらイイんじゃないか？と思いますが、フロントエンドに限らず、技術系は難易度が高いので、やりたがる人間が少ない気がします。

　また、実働できる人間が居ないのに、ペイラインだけが上がって、何も結果が出なくなっているケースが多いので、逆転狙いでBuzzに飛びつく現象が常態化しているように思います。


　こう言うBuzzに予算をつけて「結果０でフィニッシュ」する系が未だに無くならないのは、プロジェクト選定委員会のプロジェクト選定能力が不足している事が原因では無いか？と言う気がします。

　「結果０でフィニッシュ」と言うのは、なんとなく未知なものが既知になった状態でリサーチを終えているダケのような気がして、それでならばネットの情報だけで足りるのではないか？という感じですね。

＜サプライサイドの担ぐ系全般＞

　コチラにも書きましたが、メーカー系SIerのサプライサイド的な役割は終焉を迎えつつあるので、メーカー系の垂直統合プロダクトの復活を夢見てプロダクトを担いでも意味が無いということでしょうか。

　そんな中で、デマンドサイドへの提案力が重要になってくる気がします。注力ポイントがそちらにシフトしていく中で、プロダクトは、内製品ではなく、コモディティやOSSになるんだと思います。コレらの現象は、既にAIなどでも観測されているように思います。

＜統合CASEツール系全般＞

　コレに関しては、Buzzったのは、一体、何時の時代なんだろうか？と言う程、昔のモノで、調べてみると、なんと1980年代にBuzzった形跡を見て取れます。


　こんな昔に生まれた統合CASEツールではありますが、大手で死につつあるのも、ようやく、最近の事ではあります。ダメな理由は、ほぼ、ココに書いてありますので、そちらをご参照ください。

＜バックオフィスのプロセス改善全般＞

　SIにおける「フェーズゲート」、「テストとプロダクト評価」、「スコープの妥当性確認」、「情報セキュリティマネジメントシステム」などのプロセス改善は、基礎として、まだガバナンスが十分に利いていない企業では効果があります。

　しかし、ある程度、基礎的なガバナンスが利いてくると、プロセス改善系の業務は、能力仕事でもない、どちらかと言えばポジション上の事務仕事なので、プロセス改善系は注力ポイントから外れて行き、替わりに、「プロダクト・事業開発」や「ポートフォリオ、プログラム・マネジメント」などが重要になって行く印象があります。

＜総括（何処が注力ポイントか？）＞

　上記から、ダメな施策のリストを抽出すると以下の様に「事業の基幹に注力している体だが、結果として、そこに注力出来ていない。」と言う傾向があることが解ります。

• オーバースペック
  オーバースペックな技術に注力している。
  
  
• アーキテクチャ宇宙飛行士
  　テンプレート化された問題を、方法論やプラットフォーム化によって解決しようとするが、サンプルアプリを実装するレベルで解決可能な目の前の実際の問題を解かない。
  
  
• 手段の目的化
  　他のドメインのベストプラクティス的な手段を自ドメインに持ち込み、無理矢理ハメようと試行錯誤するが、結局ハマらず結果が伴わない。
  
  
• 進歩していない新技術
  　進歩していない（≒大きな問題を解決しない）新技術が多い。これは、ユーザインタフェースやデータアクセス系の新技術で顕著。
  
  
• 単なるレギュレーション変更
  　新技術を皆が採用すれば、それは差別化ではなく、レギュレーション変更でしかない。そして、何か特別なことをしないと適用＆運用できない新技術は、浸透しない。
  
  
• プロジェクト選定に問題があるケース
• 役目を終えたポートフォリオ・プログラムに注力しているケース
• 技術系は難易度が高いため、実働できる人間が居ないケース
• 逆転狙いでBuzzに飛びつく現象が常態化しているケース

　と言う事で、

　今後の生産性向上施策の注力ポイントは、

• 事業の基幹に貢献する、基礎的な
• プロセス改善
• テンプレートやライブラリの整備

　を皮切りに、徐々に、

• 脱労働集約事業を意識した、
• プロダクト・事業開発
• ポートフォリオ、プログラム・マネジメント

　等に、シフト（と言うよりレベルアップ）して行くのが王道なのではないか？と考えています（選定した施策の結果を有耶無耶にするんじゃなくて、選定した側も、責任もって、どうやったら結果が最大化できるか考えろ。って話じゃないかな？と）。