「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
開発支援ツールには色々なものがあるが、分類は参考にまとめた。
※ 下記の理屈は、今後のインフラ界隈（IaaC）にも適用できる可能性がある。
（恐らく、DSL系のツールは、不要なのではないか？と予想している）
トレンド †
開発支援ツールには、昨今、以下のようなトレンドがある。
世界的には、 †
ITビッグ 5（ Microsoft, Apple, Amazon, Oracle, etc. ）など
がリリースする開発ツールの殆どは以下の特性を持っている。
IDE周辺の動向を見ると、自社のプラットフォームを利用させるための
IDEを中心とした言語・ライブラリ・開発ツールのエコシステムに、
非常に大きな投資を行い、大きな投資対効果を期待していることが解る。
日式SIer的には、 †
- その一方、日本のSI事業者では、
「業務システム開発」の作業を単純作業化する志向が強い。
が多数開発されてきた。
- しかし、多様化の時代に、これらのツールは衰退の一途を辿っている。
- これらのツールは柔軟性と汎用性が低く、
多様化するアーキテクチャに追随できない。
- 多様化の時代、エンジニアの価値は右肩上がりだが、
自身の価値を高めないツールをエンジニアが積極的に習得しない。
その他、 †
- 様々なツールの開発が継続されているが、強力なIDEとの競争に晒されている。
- どちらもIDEより柔軟性が低いので、要求仕様に応えられないケースがある。
従って、UXを重視したり仕様をコントロールできない案件では問題になり易い。
テンプレート & 最小限のライブラリ †
- 上記を鑑みると、ドメインに特化した開発効率の向上施策は、
IDEベースのテンプレート & 最小限のライブラリが最善と解る。
- TERASORUNAは、v5.0からこの方式に変わっているもよう。
※ TERASORUNAでは、テンプレートをブランク・プロジェクト呼んでいる。
- ただし、これらの独自開発部分は、以下に影響を受ける。
- 独自開発部分は、対象規模が大きくなると、SI事業の商習慣上、逆に薄くなる傾向がある。
（ビッグ・アカウントの場合、力関係でフル・スクラッチを強要されるケースがあるため）
その他 †
UIサブシステム †
- UIサブシステムは、基本的に、
- プラットフォームに組み込まれており、
- また、IDEとフレームワークが提供されているため、
「Windows Forms」や「WPF」など、その開発が容易にできるようになっている。
Dry (Don't repeat yourself) †
- 密結合なDryの状態で開発されていたら、
- ≒ Fx生のAPIを触る為、レイヤ分割を避けている。
- ≒ モジュール強度が強く、結合度が弱くなる境界で分割されていない。
標準化・共通化などによるコントロールが必要になった時点で、対応できなくなる。
- 例えば、Open棟梁導入案件でも、案件毎に、更に追加のレイヤが追加される。
オレオレ・フレームワーク †
全般を指すモノと思われる。
- しかし、（上記の様な）Dryを脱却した後に、
案件レベルで追加するレイヤは、きっとオレオレ・フレームワークになる。
（従って、殆どの開発者はオレオレ・フレームワークを開発していることになる）
- フリーランスなどからしてみると
- 習得したい知識では無いし、
- 足枷のように見えるようだが、
チーム開発には必要なレイヤになる。
- 従って、以下は、二者択一になる。
- 恐れて何もしないか？
- 大規模化した時に、維持・保守できないものにするか？
STPのST †
- 開発技術、開発支援ツール選定をする上で、STPマーケティングの
- セグメンテーション（segmentation、セグメント化）
- ターゲティング（targeting、ターゲット選定）
- ポジショニング（positioning、ポジションの明確化）
STぐらいは考えたほうが良い。
（STPマーケティングはマーケティング用語）
- 特にエンタープライズ分野では、このような問題が解決され、
成熟したタイミングで、やっと利用できるようになることが多い。
参考 †
開発基盤の必要性 †
スクラッチが良い場合と悪い場合があり、
実験的プロトタイプ、本番アプリケーションを区別することが重要である模様。
※ 冒頭にあるように「開発者の話ではなく、状況（前提条件）が大きなカギ」らしい。
Tags: :.NET開発, :ツール類
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
