開発支援ツール

戻る（開発ツール）
- 開発支援ツール
- 開発支援ツールの種類
- 開発支援ツールの自動生成方式

概要

開発支援ツールには色々なものがあり、分類は参考にまとめた。

トレンド

開発支援ツールには、昨今、以下のようなトレンドがある。

世界的には、

IT ビッグ 5（ Microsoft, Apple, Amazon, Oracle, etc. ）など
がリリースする開発ツールの殆どは以下の特性を持っている。

IDE であり、柔軟性と汎用性が非常に高い。
設計情報（デザイナ操作、スキーマ定義）型の自動生成方式
（開発支援ツールの自動生成方式）が採用されている。

IDE 周辺の動向を見ると、
自社のプラットフォームを利用させるための
IDE を中心とした言語・ライブラリ・開発ツールのエコシステムに、
非常に大きな投資を行い、大きな投資対効果を期待していることが解る。

補足（この構図はさらに強まった）: 「IDE を中心としたエコシステムへの
大きな投資」という観察は、その後いっそう顕著になった。

【投資の主戦場が移った】★
   2010年代  IDE 本体・言語・ライブラリ
   2020年代  【AI アシスタント】へ ★
     ・Microsoft  → GitHub Copilot / VS・VS Code 統合
     ・Google     → Gemini Code Assist
     ・Amazon     → Amazon Q Developer（旧 CodeWhisperer）
     ・JetBrains  → AI Assistant / Junie
     ・Anthropic  → Claude Code

   → 狙いは当時と同じ
     【開発者を自社プラットフォームに囲い込む】
     → 生成されるコードが
       自社のクラウド／ライブラリを前提にする

【もう一つの潮流：開発環境そのもののサービス化】
   ・GitHub Codespaces / Dev Container
   ・「環境構築」がコード化され、
     【IDE がクラウドへ移動しつつある】★

日式SIer的には、

EUC、RADツール

（開発支援ツールの種類の該当節を参照）

EUC 向けの差別化を行っているため、SI 事業に適合しない。
故に、商材として担いでいるケースはあるが、自事業で利用することは殆ど無い。

統合CASEツール

（開発支援ツールの種類の該当節を参照）

その一方、日本の SI 事業者では、
「業務システム開発」の作業を単純作業化する志向が強い。
そのため、「業務システム開発」に特化した、
- 統合 CASE ツール
- その他、以下を行うためのツール
  - 標準化
  - 共通化
  - 自動生成
    リポジトリから自動生成
    （Excel など）設計書型から自動生成
    （いずれも開発支援ツールの自動生成方式を参照）
が多数開発されてきた。
しかし、多様化の時代に、これらのツールは衰退の一途を辿っている。
- これらのツールは柔軟性と汎用性が低く、
  多様化するアーキテクチャに追随できない。
- 多様化の時代、エンジニアの価値は右肩上がりだが、
  自身の価値を高めないツールをエンジニアが積極的に習得しない。
- ベンダ目線でできている。
  - 従って、エンド・ユーザ目線でできていない。
    （ベンダ内でも案件向けサポートが必要なケースが多い）
  - このため、導入の際に、
    「過去にｘ社のツールに辛酸なめさせられた。」
    的なエンド・ユーザの経験を聞くことがある。

補足（「エンジニアが習得しない」という指摘の重要性）: 3 つの理由のうち、
2 番目が最も本質的であり、しばしば見落とされる。

【ツールが定着しない構造】★
   独自ツールの習得
     → その組織／その案件でしか通用しない
     → 【個人の市場価値が上がらない】
     → 学習の動機が生まれない
     → 「言われたから使う」状態になる
     → 使いこなされず、効果が出ない
     → 「ツールが悪い」と評価される

   汎用技術（Git / Docker / TypeScript …）の習得
     → どこでも通用する
     → 【自発的に学ぶ】
     → 深く使いこなされる

【設計への示唆】★
   社内ツールを作るなら
     ・【汎用技術の薄いラッパー】にする
       （素の技術も見えるようにする）
     ・独自 DSL・独自 IDE を作らない
     ・出力が【普通のコード】であること
       → 最悪ツールを捨てても資産が残る ★
   → これは AI コード生成にも同じことが言える

テンプレートとパッケージ

業務システム開発に特化した開発効率の向上施策は、
- IDE ベースのテンプレートと
- パッケージ（最小限のフレームワーク & ライブラリ）
が現代のベストプラクティスとなってきている。
パッケージは、NuGet などのパッケージ・マネージャー経由で取得する。
テンプレートには以下の役割がある。
- プロジェクト構成や（、パッケージ・マネージャーで）、下位スタックを決定する。
- DI & AOP や OOP の技術を使用して、共通化とその呼出を行う。
事例
- Open棟梁は、初期からこの設計思想で開発されている。
  また、IDE と同様に、設計情報（デザイナ操作、スキーマ定義）型の自動生成方式
  （開発支援ツールの自動生成方式）を採用している。
- TERASOLUNA は、v5.0 からこの方式に変わっているもよう。
  ※ TERASOLUNA では、テンプレートをブランク・プロジェクトと呼んでいる。
参考
- Javaエンジニアに知ってほしい、Springの教科書「TERASOLUNA」 #jjug_ccc #ccc_f3
  https://www.slideshare.net/jjug/javaspringterasoluna-jjugccc-cccf3

移行メモ（誤字）: 移行元では製品名が「TERASORUNA」と
記載されていたが、正しくは「TERASOLUNA」（NTT データ）である
（2 箇所）。
また「ブランク・プロジェクト呼んでいる」を
「ブランク・プロジェクトと呼んでいる」に修正した。

補足（「テンプレート + パッケージ」は .NET でどう実現するか）: この
見立ては現在の .NET でそのまま実践できるので、手段を補っておく。

【dotnet new のテンプレート機構】★
   ・テンプレートは【NuGet パッケージとして配布できる】
       dotnet new install MyCompany.Templates
       dotnet new mycompany-webapi -n Sample
   ・テンプレートの実体は
       .template.config/template.json ＋ 普通のプロジェクト
     → 【出力は普通のコード】★
     → 前述の「捨てても資産が残る」条件を満たす

【共通機能の配り方】
   ・NuGet パッケージ（ライブラリ）
   ・【Directory.Build.props】… ビルド設定の共通化
   ・【中央パッケージ管理】… 版の統一
   ・【Roslyn Analyzer】★
     → 規約違反を【コンパイル時に検出】する
     → 「フレームワークを無視された」を防ぐ手段
       （後述の情報漏洩の事例への直接的な回答）★
   ・【ソース ジェネレータ】
     → 自動生成を「ビルド時」に行う
     → 生成物をリポジトリに置かなくて済む

【現在のもう一段の進化】★
   ・【.NET Aspire】
     → 複数プロジェクト＋依存サービスの構成を
       C# で記述するテンプレート的な基盤
   ・【Dev Container】
     → 「開発環境」ごとテンプレート化する
   ・【AI へのプロジェクト指示】（AGENTS.md 等）
     → 規約を【自然言語でも配る】時代になった
     → [GitHub Copilot CLI](MS_GitHubCopilotCLI) を参照

機能スタック

以下のように構成される。

下位スタック：ランタイム・フレームワーク（OTR_RuntimeFramework.md）
（フレームワークの機能について。も参照）
上位スタック：開発支援ツール、開発基盤とは（OTR_WhatIsDevelopmentInfrastructure.md）など。

導入時の考慮点

技術面

KPIとKGI（Open 棟梁 Wiki）

開発基盤のKPIとKGI（OTR_DevInfraKPIandKGI.md）

KGI（QCDF 向上）を達成するための KPI の達成度合い。

その他

Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
https://qiita.com/tmknom/items/08b69594e32a92bccee5

非技術面

信頼性（やり切ってくれるか？）

SI 案件は規模、契約価格が大きくリスクが高いので、
サポート・エンジニアは最後までやり切ってくれないと厳しい。

サポート力
- セルフ・サポート・コンテンツの充実度合い
- オンライン or オンサイトのサポート力
  - 緊急の対応に応じることができるか（バグ対応、仕様拡張）？
セルフ・サポート可能か？
- 要求事項の実現に支障を与えるような制限事項は無いか？
- 案件独自のカスタマイズが可能か？（OSS であること）

プロダクトのライフサイクル

数画面のアプリケーション開発と異なり、多数の業務画面を持つ大規模なプロダクトでは、
開発支援ツール、開発基盤（OTR_WhatIsDevelopmentInfrastructure.md）の
ライフサイクルは長くなければならない。

コミュニティの継続性
後方互換性の維持

, etc.

思い付いたら追加します。

補足（「非技術面」の観点はむしろ重要度が増した）: ここに挙げられた
2 つの観点は、現在のサプライチェーンリスクの議論とそのまま重なる。

【OSS 依存のリスクとして現在語られること】★
 ・【メンテナが 1 人】のパッケージに依存していないか
     → left-pad 事件（2016）
     → xz Utils のバックドア混入（2024）★
       → 保守を引き継いだ人物が
         長期間かけて信頼を得てから仕込んだ
 ・【突然のライセンス変更】
     → jqGrid（→ [Gridのヘッダ固定方法](MS_GridHeaderFix)）
     → HashiCorp Terraform の BSL 移行（2023）
 ・【リポジトリのアーカイブ】
     → 本 Wiki の移行作業でも多数遭遇している

【現在の実務的な備え】
   ・【SBOM】（部品表）を出力し、依存を可視化する ★
   ・Dependabot / Renovate で更新を追う
   ・重要な依存は【フォークを保持】する
   ・「後方互換性の維持」を
     【自分たちの側でも】守る（原文の指摘の裏返し）

STP

STPとは

開発技術、開発支援ツール選定をする上で、
STPマーケティングの

セグメンテーション（segmentation、セグメント化）
ターゲティング（targeting、ターゲット選定）
ポジショニング（positioning、ポジションの明確化）

ST（セグメンテーション・ターゲティング）ぐらいは、
前述の技術面、非技術面含め考えたほうが良い。

※ STPマーケティングはマーケティング用語

STPの例

例えば、「HTML/CSS/JavaScript」は、
HTML を修飾したり、Google の広告系の処理を埋め込んだりと、
そのような用途に最適化されているプログラム言語なので、
UI、業務処理開発と汎用的に適合するか？と言えばそうではない。
- @mizchi さんのツイート:
  https://twitter.com/mizchi/status/957851145531043840
- そもそも、汎用的であれば「AltJS」は登場していないものと思われる
  （JavaScriptの該当節を参照）。
特にエンタープライズ分野では、このような問題が解決され、
成熟したタイミングで、やっと利用できるようになることが多い。

移行メモ（参照先の欠落）: 「前述の「HTML/CSS/JavaScript」は」の
リンク先アンカー（#ae5ae778）は、本ページ内に存在しない
（他ページからの転記時に残ったものと思われる）。
文意は通るため、リンクを外してテキストにした。

補足（「AltJS が登場した」という論拠のその後）: この推論は
正しく、しかも決着がついた。

【AltJS の淘汰】★
   CoffeeScript（2009）… ほぼ消滅
   Dart（2011）        … Flutter の言語として生き残る
   TypeScript（2012）  → 【事実上の標準になった】★

   → 「JavaScript は大規模開発に向かない」という
     問題意識は【型システムの追加】で解かれた
   → 現在、業務システムのフロントエンドは
     TypeScript が前提
     （→ [TypeScript](MS_TypeScript)）

【原文の主張の妥当性】
   ・「HTML を修飾する用途に最適化された言語」
     という指摘は【当時の JavaScript】には当てはまる
   ・ただし現在の ECMAScript は
     クラス、モジュール、async/await、
     Optional Chaining 等を備えており、
     【言語としては十分に汎用化した】★
   → 論点は「言語の素性」から
     「エコシステムの複雑さ・変化の速さ」へ移った

内部リンク

開発支援ツールの種類

開発支援ツールの自動生成方式

参考

OSSコンソーシアム

Wiki

Open棟梁
- ランタイム・フレームワーク（OTR_RuntimeFramework.md）
- プロジェクト・テンプレート（OTR_ProjectTemplate.md）
- 開発基盤とは（OTR_WhatIsDevelopmentInfrastructure.md）
開発基盤部会

Blog

開発支援ツールとは？その種類と特徴を、まとめてみした。
https://www.osscons.jp/jowaxn8yr-537/

そもそも、開発支援ツールとは？
自動生成 ⇔ ランタイム・ライブラリ
という開発基盤の方式変遷の話。
https://www.osscons.jp/jo2blwgfh-537/

開発基盤の方式変遷の話、最近は、
リポジトリや Excel 設計書からの自動生成が廃れ気味です。
本質的なエンジニアリング・ツール？
テンプレートについて再考する。
https://www.osscons.jp/josbadhor-537/

最近は「 IDE + テンプレート + パッケージ」方式が強力。
最近重宝している開発環境、ツール、ライブラリなどの紹介
https://www.osscons.jp/jo0gmt3qu-537

最近重宝している開発環境、ツール、ライブラリなどを紹介します。
統合CASEツールの類は何故、廃れたのか？
https://www.osscons.jp/joeii3bn2-537/

技術トレンドと、開発支援ツールの盛衰の一例。
そろそろノーコード・ローコードについて言及しておく。
https://www.osscons.jp/jonn28s49-537/

最近流行りのノーコード・ローコード、RPA と同じで、新しいモノではない。

その他、開発基盤の必要性

高品質・高信頼性

個人情報漏洩させたらこうなった - vol. 02 - 648 blog
http://www.kyamaneko.com/entry/personal-information-outflow-02

「ひでえ。DB アクセスのところ、フレームワーク無視してる……」
そう。問題の箇所においては、コーディングルールが守られていなかったため、
SQL インジェクションを許してしまっていたのだ。

※ 規約の遵守にフレームワークは有用だが無視されたら無効。

超高速な開発ができるわけ

超高速な開発ができるわけ | Yakst
https://yakst.com/ja/posts/4668

「10 倍の生産性での開発」が適合する場合と、しない場合があり、
実験的プロトタイプ、本番アプリケーションを区別することが重要である模様。

※ 冒頭にあるように「開発者の話ではなく、状況（前提条件）が大きなカギ」らしい。

移行メモ（体裁）: 移行元では上記 2 箇所の注記に PukiWiki の
&color(red){...};（赤文字）が使われていたため、
GitHub Wiki で表現できる太字に置き換えた。

プロセス / 手法 / ツール

最新システムエンジニアリング情報館
http://se.rdy.jp/importance.html
- システムエンジニアリング概要 > プロセスと手法の関係
  http://se.rdy.jp/process.html

    [プロセス]
活用↓↑サポート
    [手法]
活用↓↑サポート
    [ツール]★★

システムエンジニアリング
- ハードウェアやソフトウェアにかかわらず、
  システムを開発するエンジニアリング（技術の該当節を参照）。
- ツールは「エンジニアリング」を補完する。

補足（「ツールはエンジニアリングを補完する」）: 本ページの結論に
あたる一文であり、冒頭のトレンド分析と首尾一貫している。

【本ページ全体の主張】★
   ① 統合 CASE ツールは
      「エンジニアリングを【置き換えよう】」とした
      → 柔軟性を失い、衰退した
   ② IDE + テンプレート + パッケージは
      「エンジニアリングを【補完する】」
      → 生き残っている

   → ツールの成否は
     【エンジニアの判断力を奪うか、増幅するか】で決まる

【この観点を AI コード生成に当てはめると】★
   ・置き換えようとする使い方
       「仕様を投げれば全部できる」
       → 出てきたものを検証できず、
         【判断力が育たない】
   ・補完する使い方
       調査・定型作業・レビュー観点の提示
       → 判断は人が行い、
         【判断の材料を増やす】

   → 本ページが 2023年に書いた枠組みが、
     そのまま現在の論点に通用する ★

Tags: 移行, .NET開発, ツール類

MS_DevelopmentSupportTools - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

開発支援ツール

概要

トレンド

世界的には、

日式SIer的には、

EUC、RADツール

統合CASEツール

テンプレートとパッケージ

機能スタック

導入時の考慮点

技術面

KPIとKGI（Open 棟梁 Wiki）

その他

非技術面

信頼性（やり切ってくれるか？）

プロダクトのライフサイクル

, etc.

STP

STPとは

STPの例

内部リンク

開発支援ツールの種類

開発支援ツールの自動生成方式

参考

OSSコンソーシアム

Wiki

Blog

その他、開発基盤の必要性

高品質・高信頼性

超高速な開発ができるわけ

プロセス / 手法 / ツール

⚠️ GitHub.com Fallback ⚠️

MS_DevelopmentSupportTools - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

開発支援ツール

概要

トレンド

世界的には、

日式SIer的には、

EUC、RADツール

統合CASEツール

テンプレートとパッケージ

機能スタック

導入時の考慮点

技術面

KPIとKGI（Open 棟梁 Wiki）

その他

非技術面

信頼性（やり切ってくれるか？）

プロダクトのライフサイクル

, etc.

STP

STPとは

STPの例

内部リンク

開発支援ツールの種類

開発支援ツールの自動生成方式

参考

OSSコンソーシアム

Wiki

Blog

その他、開発基盤の必要性

高品質・高信頼性

超高速な開発ができるわけ

プロセス / 手法 / ツール

⚠️ **GitHub.com Fallback** ⚠️

⚠️ GitHub.com Fallback ⚠️