「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
開発支援ツールには色々なものがあり、分類は参考にまとめた。
トレンド †
開発支援ツールには、昨今、以下のようなトレンドがある。
世界的には、 †
ITビッグ 5（ Microsoft, Apple, Amazon, Oracle, etc. ）など
がリリースする開発ツールの殆どは以下の特性を持っている。
IDE周辺の動向を見ると、自社のプラットフォームを利用させるための
IDEを中心とした言語・ライブラリ・開発ツールのエコシステムに、
非常に大きな投資を行い、大きな投資対効果を期待していることが解る。
日式SIer的には、 †
- EUC向けの差別化を行っているため、SI事業に適合しない。
- 故に、商材として担いでいるケースはあるが、自事業で利用することは殆ど無い。
- その一方、日本のSI事業者では、
「業務システム開発」の作業を単純作業化する志向が強い。
が多数開発されてきた。
- しかし、多様化の時代に、これらのツールは衰退の一途を辿っている。
- これらのツールは柔軟性と汎用性が低く、
多様化するアーキテクチャに追随できない。
- 多様化の時代、エンジニアの価値は右肩上がりだが、
自身の価値を高めないツールをエンジニアが積極的に習得しない。
- 従って、エンド・ユーザ目線でできていない。
（ベンダ内でも案件向けサポートが必要なケースが多い）
- このため、導入の際に、
「過去にｘ社のツールに辛酸なめさせられた。」
的なエンド・ユーザの経験を聞くことがある。
テンプレートと最小限のフレームワーク & ライブラリ †
- 上記を鑑みると、
ドメイン（ここでは≒業務システム開発）に特化した開発効率の向上施策は、
IDEベースのテンプレートと最小限のフレームワーク & ライブラリが最善と解る。
- テンプレートには以下の役割がある。
- プロジェクト構成や、下位スタックを決定する。
- AOPやOOPの技術を使用して、共通化とその呼出を行う。
- ただし、独自開発のフレームワーク & ライブラリ部分は、以下に影響を受ける。
- 独自開発部分は、対象規模が大きくなると、SI事業の商習慣上、逆に薄くなる傾向がある。
（ビッグ・アカウントの場合、力関係でフル・スクラッチを強要されるケースがあるため）
- TERASORUNAは、v5.0からこの方式に変わっているもよう。
※ TERASORUNAでは、テンプレートをブランク・プロジェクト呼んでいる。
その他 †
UIサブシステム †
- UIサブシステムは、基本的に、
- プラットフォームに組み込まれており、
- また、IDEとフレームワークが提供されているため、
「Windows Forms」や「WPF」など、その開発が容易にできるようになっている。
- しかし、そのクロスプラットフォーム性が注目され、昨今、
UIサブシステムと認識されつつある「HTML/CSS/JavaScript」は、
下位スタックの進化が著しく、不安定で、フレームワークのライフサイクルが短いことが多い。
（これは、「HTML/CSS/JavaScript」が、テキスト修飾・閲覧のためのUIから
アプリケーション開発のためのUIに変化している最中と言えるのかも知れない）
Dry (Don't repeat yourself) †
- 密結合なDryの状態で開発されていたら、
- ≒ デファクトなフレームワークの生のAPIを触りたい為、レイヤ分割を避けている。
- ≒ モジュール強度が強く、結合度が弱くなる境界で分割されていない。
標準化・共通化などによるコントロールが必要になった時点で、対応できなくなる。
- 例えば、Open棟梁導入案件でも、案件毎に、更に追加のレイヤが追加される。
オレオレ・フレームワーク †
全般を指すモノと思われる。
- しかし、（上記の様な）Dryを脱却した後に、
案件レベルで追加するレイヤは、きっとオレオレ・フレームワークになる。
（従って、殆どの開発者はオレオレ・フレームワークを開発していることになる）
- フリーランスなどからしてみると
- 習得したい知識では無いし、
- 足枷のように見えるようだが、
チーム開発には必要なレイヤになる。
- 従って、以下は、二者択一になる。
- 恐れて何もしないか？
- 大規模化した時に、維持・保守できないものにするか？
導入時の考慮点 †
技術面 †
以下が参考になる。
非技術面 †
信頼性（やり切ってくれるか？） †
SI案件は規模、契約価格が大きくリスクが高いので、
サポート・エンジニアは最後までやり切ってくれないと厳しい。
- 制限事項は無いか？
- 緊急の対応に応じることができるか（バグ対応、仕様拡張）？
- 案件独自のカスタマイズが可能か？（OSSであること）
プロダクトのライフサイクル †
数画面のサービスと異なり、
多数の業務画面を持つ大規模なプロダクトでは、
開発基盤のライフサイクルは長くなければならない。
, etc. †
思い付いたら追加します。
STP †
開発技術、開発支援ツール選定をする上で、STPマーケティングの
- セグメンテーション（segmentation、セグメント化）
- ターゲティング（targeting、ターゲット選定）
- ポジショニング（positioning、ポジションの明確化）
ST（セグメンテーション・ターゲティング）ぐらいは、
技術面、非技術面含め考えたほうが良い。
※ STPマーケティングはマーケティング用語
- 特にエンタープライズ分野では、このような問題が解決され、
成熟したタイミングで、やっと利用できるようになることが多い。
参考 †
その他 †
開発支援ツールとは？ †
そもそも、開発支援ツールとは？
開発基盤の必要性 †
- 超高速な開発ができるわけ | Yakst
https://yakst.com/ja/posts/4668
「10倍の生産性での開発」が適合する場合と、しない場合があり、
実験的プロトタイプ、本番アプリケーションを区別することが重要である模様。
※ 冒頭にあるように「開発者の話ではなく、状況（前提条件）が大きなカギ」らしい。
Tags: :.NET開発, :ツール類
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
