開発支援ツールのバックアップ(No.32) - マイクロソフト系技術情報 Wiki

[ トップ ] [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

戻る

目次 †

概要 †

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

トレンド †

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

世界的には、 †

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

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

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

日式SIer的には、 †

EUC、RADツール †

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

統合CASEツール †

その一方、日本のSI事業者では、
「業務システム開発」の作業を単純作業化する志向が強い。

そのため、「業務システム開発」に特化した、

統合CASEツール

その他、以下を行うためのツール
- 標準化
- 共通化
- 自動生成
  リポジトリから自動生成
   （Excelなど）設計書型から自動生成

が多数開発されてきた。

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

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

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

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

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

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

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

業務システム開発に特化した開発効率の向上施策は、
- IDEベースのテンプレートと
- パッケージ（最小限のフレームワーク & ライブラリ）

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

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

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

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

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

参考

Javaエンジニアに知ってほしい、Springの教科書「TERASOLUNA」 #jjug_ccc #ccc_f3
https://www.slideshare.net/jjug/javaspringterasoluna-jjugccc-cccf3

機能スタック †

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

下位スタック：ランタイム・フレームワーク
上位スタック：開発支援ツール、開発基盤など。

導入時の考慮点 †

技術面 †

KPIとKGI（Open 棟梁 Wiki） †

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

その他 †

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

非技術面 †

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

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

サポート力
- セルフ・サポート・コンテンツの充実度合い
- オンライン or オンサイトのサポート力
  - 緊急の対応に応じることができるか（バグ対応、仕様拡張）？

セルフ・サポート可能か？
- 要求事項の実現に支障を与えるような制限事項は無いか？
- 案件独自のカスタマイズが可能か？（OSSであること）

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

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

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

, etc. †

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

STP †

STPとは †

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

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

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

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

STPの例 †

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

@mizchiさんのツイート:
https://twitter.com/mizchi/status/957851145531043840
そもそも、汎用的であれば「AltJS」は登場していないものと思われる。

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

参考 †

内部リンク †

開発支援ツールの種類 †

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

OSSコンソーシアム †

Wiki †

Open棟梁

開発基盤部会

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/
技術トレンドと、開発支援ツールの盛衰の一例。

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

高品質・高信頼性 †

個人情報漏洩させたらこうなった - vol. 02 - 648 blog
http://www.kyamaneko.com/entry/personal-information-outflow-02
「ひでえ。DBアクセスのところ、フレームワーク無視してる……」
そう。問題の箇所においては、コーディングルールが守られていなかったため、
SQLインジェクションを許してしまっていたのだ。
※ 規約の遵守にフレームワークは有用だが無視されたら無効。

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

超高速な開発ができるわけ | Yakst
https://yakst.com/ja/posts/4668
「10倍の生産性での開発」が適合する場合と、しない場合があり、
実験的プロトタイプ、本番アプリケーションを区別することが重要である模様。
※ 冒頭にあるように「開発者の話ではなく、状況（前提条件）が大きなカギ」らしい。

プロセス / 手法 / ツール †

最新システムエンジニアリング情報館
http://se.rdy.jp/importance.html
- システムエンジニアリング概要 > プロセスと手法の関係
  http://se.rdy.jp/process.html
```
    [プロセス]
活用↓↑サポート
    [手法]
活用↓↑サポート
    [ツール]★★
```

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

ハードウェアやソフトウェアにかかわらず、
システムを開発するエンジニアリング。

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

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