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