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

目次

概要

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

トレンド

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

世界的には、

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

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

日式SIer的には、

EUC、RADツール

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

統合CASEツール

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

が多数開発されてきた。

  • しかし、多様化の時代に、これらのツールは衰退の一途を辿っている。
  • これらのツールは柔軟性と汎用性が低く、
    多様化するアーキテクチャに追随できない。
  • 多様化の時代、エンジニアの価値は右肩上がりだが、
    自身の価値を高めないツールをエンジニアが積極的に習得しない。
  • ベンダ目線でできている。
  • 従って、エンド・ユーザ目線でできていない。
    (ベンダ内でも案件向けサポートが必要なケースが多い)
  • このため、導入の際に、
    「過去にx社のツールに辛酸なめさせられた。」
    的なエンド・ユーザの経験を聞くことがある。

テンプレートと最小限のフレームワーク & ライブラリ

  • 上記を鑑みると、
    ドメイン(ここでは≒業務システム開発)に特化した開発効率の向上施策は、
    IDEベースのテンプレートと最小限のフレームワーク & ライブラリが最善と解る。
  • テンプレートには以下の役割がある。
    • プロジェクト構成や、下位スタックを決定する。
    • AOPやOOPの技術を使用して、共通化とその呼出を行う。
  • ただし、独自開発のフレームワーク & ライブラリ部分は、以下に影響を受ける。
  • 独自開発部分は、対象規模が大きくなると、SI事業の商習慣上、逆に薄くなる傾向がある。
    (ビッグ・アカウントの場合、力関係でフル・スクラッチを強要されるケースがあるため)
  • また、下位スタックの安定性に影響を受ける。
    Windows FormsASP.NET Web Formsの安定性は非常に高いが、
    昨今のJSのMV*など、安定が非常に低いフレームワークの上では維持できない。)
  • 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のために、
    案件レベルで追加するレイヤは、きっとオレオレ・フレームワークになる。
    (従って、殆どの開発者はオレオレ・フレームワークを開発していることになる)
  • フリーランスなどからしてみると
    • 習得したい知識では無いし、
    • 足枷のように見えるようだが、

チーム開発には必要なレイヤになる。

  • 従って、
    • 恐れて何もしないか?
    • 大規模化した時に、維持・保守できないものにするか?

二者択一ではなく、バランスをとることが重要になる。

導入時の考慮点

技術面

KPIとKGI(Open 棟梁 Wiki)

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

その他

非技術面

信頼性(やり切ってくれるか?)

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

  • サポート力
    • セルフ・サポート・コンテンツの充実度合い
    • オンライン or オンサイトのサポート力
      • 緊急の対応に応じることができるか(バグ対応、仕様拡張)?
  • セルフ・サポート可能か?
    • 要求事項の実現に支障を与えるような制限事項は無いか?
    • 案件独自のカスタマイズが可能か?(OSSであること)

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

数画面のサービスと異なり、
多数の業務画面を持つ大規模なプロダクトでは、
開発基盤のライフサイクルは長くなければならない。

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

, etc.

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

STP

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

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

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

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

  • 例えば、前述の「HTML/CSS/JavaScript」は
    HTMLを修飾したり、Googleの広告系の処理を埋め込んだりと、
    そのような用途に最適化されているプログラム言語なので、
    UI、業務処理開発と汎用的に適合するか?と言えばそうではない。
  • 特にエンタープライズ分野では、このような問題が解決され、
    成熟したタイミングで、やっと利用できるようになることが多い。

参考

開発支援ツールの種類

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

VS系コンテンツ

その他

開発支援ツールとは?

そもそも、開発支援ツールとは?

開発基盤の必要性

  • 超高速な開発ができるわけ | Yakst
    https://yakst.com/ja/posts/4668

    「10倍の生産性での開発」が適合する場合と、しない場合があり、
    実験的プロトタイプ、本番アプリケーションを区別することが重要である模様。
    ※ 冒頭にあるように「開発者の話ではなく、状況(前提条件)が大きなカギ」らしい。

  • 個人情報漏洩させたらこうなった - vol. 02 - 648 blog
    http://www.kyamaneko.com/entry/personal-information-outflow-02

    「ひでえ。DBアクセスのところ、フレームワーク無視してる……」
    そう。問題の箇所においては、コーディングルールが守られていなかったため、
    SQLインジェクションを許してしまっていたのだ。

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

ツールはエンジニアリングに必要。


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


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-10-30 (火) 13:22:50 (48d)