Skip to content

MS_DevelopmentSupportTools

Jump to bottom
nishi_74322014 edited this page Aug 21, 2026 · 1 revision

開発支援ツール

概要

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

トレンド

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

世界的には、

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

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 ツール

    • その他、以下を行うためのツール

    が多数開発されてきた。

  • しかし、多様化の時代に、これらのツールは衰退の一途を辿っている。

    • これらのツールは柔軟性と汎用性が低く、
      多様化するアーキテクチャに追随できない。

    • 多様化の時代、エンジニアの価値は右肩上がりだが、
      自身の価値を高めないツールをエンジニアが積極的に習得しない。

    • ベンダ目線でできている。

      • 従って、エンド・ユーザ目線でできていない。
        （ベンダ内でも案件向けサポートが必要なケースが多い）

      • このため、導入の際に、
        「過去にｘ社のツールに辛酸なめさせられた。」
        的なエンド・ユーザの経験を聞くことがある。

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

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

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

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

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

  • 業務システム開発に特化した開発効率の向上施策は、

    • IDE ベースのテンプレートと
    • パッケージ（最小限のフレームワーク & ライブラリ）

    が現代のベストプラクティスとなってきている。

  • パッケージは、NuGet などのパッケージ・マネージャー経由で取得する。

  • テンプレートには以下の役割がある。

    • プロジェクト構成や（、パッケージ・マネージャーで）、下位スタックを決定する。
    • DI & AOP や OOP の技術を使用して、共通化とその呼出を行う。

  • 事例

    • Open棟梁 は、初期からこの設計思想で開発されている。
      また、IDE と同様に、設計情報（デザイナ操作、スキーマ定義）型の自動生成方式
      （開発支援ツールの自動生成方式）を採用している。

    • TERASOLUNA は、v5.0 からこの方式に変わっているもよう。
      ※ TERASOLUNA では、テンプレートをブランク・プロジェクトと呼んでいる。

  • 参考

移行メモ（誤字）: 移行元では製品名が「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）
    （フレームワークの機能について。（MS_FrameworkFeatures.md）も参照）
  • 上位スタック：開発支援ツール、開発基盤とは（OTR_WhatIsDevelopmentInfrastructure.md）など。

導入時の考慮点

技術面

KPIとKGI（Open 棟梁 Wiki）

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

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

その他

非技術面

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

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マーケティング（DNET_STPMarketing.md）の

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

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

※ STPマーケティング（DNET_STPMarketing.md）はマーケティング用語

STPの例

  • 例えば、「HTML/CSS/JavaScript」は、
    HTML を修飾したり、Google の広告系の処理を埋め込んだりと、
    そのような用途に最適化されているプログラム言語なので、
    UI、業務処理開発と汎用的に適合するか？と言えばそうではない。

  • 特にエンタープライズ分野では、このような問題が解決され、
    成熟したタイミングで、やっと利用できるようになることが多い。

移行メモ（参照先の欠落）: 「前述の「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）

  • 開発基盤部会

    • オレオレ・フレームワーク（DNET_OreOreFramework.md）
    • 言語等に依存しない汎用開発支援ツール（DNET_GeneralDevTools.md）
    • ノーコード・ローコード（DNET_NoCodeLowCode.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 で表現できる太字に置き換えた。

プロセス / 手法 / ツール

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

  • システムエンジニアリング

    • ハードウェアやソフトウェアにかかわらず、
      システムを開発するエンジニアリング（技術（DNET_Technology.md）の該当節を参照）。

    • ツールは「エンジニアリング」を補完する。

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

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

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

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

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

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

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally