「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。

-[[戻る>開発ツール]]

* 目次 [#vdb51828]
#contents

*概要 [#c2d64c21]
開発支援ツールには色々なものがあり、分類は[[参考>#md49fd9e]]にまとめた。

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

**世界的には、 [#q4573886]
ITビッグ 5( Microsoft, Apple, Amazon, Oracle, etc. )など~
がリリースする開発ツールの殆どは以下の特性を持っている。
-[[IDE>開発支援ツールの種類#b818d91a]]であり、柔軟性と汎用性が非常に高い。
-[[設計情報(デザイナ操作、スキーマ定義)型の自動生成方式>開発支援ツールの自動生成方式#fe4a7148]]が採用されている。

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

**日式SIer的には、 [#n91ce970]

***[[EUC、RADツール>開発支援ツールの種類#fb3f61c9]] [#p5cb4d9f]
-EUC向けの差別化を行っているため、SI事業に適合しない。
-故に、商材として担いでいるケースはあるが、自事業で利用することは殆ど無い。

***[[統合CASEツール>開発支援ツールの種類#xb5fa00b]] [#abb347ae]

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

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

--[[統合CASEツール>開発支援ツールの種類#xb5fa00b]]

--その他、以下を行うためのツール
---標準化
---共通化
---自動生成~
[[リポジトリから自動生成>開発支援ツールの自動生成方式#ed279100]]~
[[(Excelなど)設計書型から自動生成>開発支援ツールの自動生成方式#fe4a7148]]

>が多数開発されてきた。

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

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

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

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

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

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

***テンプレートと最小限のフレームワーク & ライブラリ [#o75389df]
-上記を鑑みると、~
ドメイン(ここでは≒業務システム開発)に特化した開発効率の向上施策は、~
[[IDE>#q4573886]]ベースのテンプレートと最小限のフレームワーク & ライブラリが最善と解る。

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

-ただし、独自開発のフレームワーク & ライブラリ部分は、以下に影響を受ける。

--独自開発部分は、対象規模が大きくなると、SI事業の商習慣上、逆に薄くなる傾向がある。~
(ビッグ・アカウントの場合、力関係でフル・スクラッチを強要されるケースがあるため)

--また、下位スタックの安定性に影響を受ける。~
([[Windows Forms]]や[[ASP.NET Web Forms]]の安定性は非常に高いが、~
昨今のJSのMV*など、安定が非常に低いフレームワークの上では維持できない。)

-事例
--[[Open棟梁>http://opentouryo.osscons.jp/]]は、初期からこの設計思想で開発されている。~
また、[[IDE>#q4573886]]と同様に、[[設計情報(デザイナ操作、スキーマ定義)型の自動生成方式>開発支援ツールの自動生成方式#fe4a7148]]を採用している。

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

-参考

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

*その他 [#h9d29cde]

**UIサブシステム [#ae5ae778]

***概要 [#b16e939d]
-UIサブシステムは、基本的に、
--プラットフォームに組み込まれており、
--また、[[IDE>#q4573886]]とフレームワークが提供されているため、

>「[[Windows Forms]]」や「[[WPF]]」など、その開発が容易にできるようになっている。

-しかし、そのクロスプラットフォーム性が注目され、昨今、~
UIサブシステムと認識されつつある「[[HTML/CSS/JavaScript>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?HTML%2FCSS%2FJavaScript]]」は、~
下位スタックの進化が著しく、不安定で、フレームワークのライフサイクルが短いことが多い。~
(これは、「[[HTML/CSS/JavaScript>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?HTML%2FCSS%2FJavaScript]]」が、テキスト修飾・閲覧のためのUIから~
アプリケーション開発のためのUIに変化している最中と言えるのかも知れない)

***参考 [#pdd4d55d]
-短命なJavaScriptフレームワーク~
https://www.infoq.com/jp/news/2018/02/javascript-lifespan-limited#.WobeHSDzdlo.twitter

**Dry (Don't repeat yourself) [#gbdb10f2]
***概要 [#w3e98c70]
-観測範囲で、Webやフリーランス界隈では、Dryが尊ばれている様に見えるが、~
下記の「Dryで書いたものが負債になっていく。」という発言もあり、~

-小規模なスクラップ・アンド・ビルド案件が、

--大規模化して維持・保守が必要になった場合に、

--密結合なDryの状態で開発されていたら、
---≒ デファクトなフレームワークの生のAPIを触りたい為、レイヤ分割を避けている。
---≒ モジュール強度が強く、結合度が弱くなる境界で分割されていない。

>標準化・共通化などによるコントロールが必要になった時点で、対応できなくなる。

-例えば、[[Open棟梁>http://opentouryo.osscons.jp/]]導入案件でも、案件毎に、更に追加のレイヤが追加される。

***参考 [#p990ff46]

-@mizchiさんのツイート:~
https://twitter.com/mizchi/status/959297746908856320
>DRY、よかれと思って書かれたものが負債になってることのほうが多くないですか

-DRYと不当な抽象化によるコストについて | POSTD~
https://postd.cc/on-dry-and-the-cost-of-wrongful-abstractions/
>抽象化のコストがコードを重複させるコストを上回らない限り、必ず抽象化する。

**オレオレ・フレームワーク [#v8ef209c]
-明確な定義は無いが、
--案件レベルで作成した、
--質の低い独自実装

>全般を指すモノと思われる。

-しかし、([[上記>#gbdb10f2]]の様な)Dryを脱却した後に、~
案件レベルで追加するレイヤは、きっとオレオレ・フレームワークになる。~
(従って、殆どの開発者はオレオレ・フレームワークを開発していることになる)

-フリーランスなどからしてみると
--習得したい知識では無いし、
--足枷のように見えるようだが、~

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

-従って、以下は、二者択一になる。
--恐れて何もしないか?
--大規模化した時に、維持・保守できないものにするか?

*導入時の考慮点 [#r9c3e3ec]

**技術面 [#n874445c]

***[[KPIとKGI>https://opentouryo.osscons.jp/index.php?%E9%96%8B%E7%99%BA%E5%9F%BA%E7%9B%A4%E3%81%AEKPI%E3%81%A8KGI]](Open 棟梁 Wiki) [#n213c992]
KGI(QCDF向上)を達成するためのKPIの達成度合い。

***その他 [#i659aa89]

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

**非技術面 [#sf3691d2]

***信頼性(やり切ってくれるか?) [#t94a23bd]
SI案件は規模、契約価格が大きくリスクが高いので、~
サポート・エンジニアは最後までやり切ってくれないと厳しい。

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

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

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

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

***, etc. [#se43b1d2]
思い付いたら追加します。

**STP [#obb9fb87]
開発技術、開発支援ツール選定をする上で、[[STPマーケティング>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?STP%E3%83%9E%E3%83%BC%E3%82%B1%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0]]の

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

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

※ [[STPマーケティング>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?STP%E3%83%9E%E3%83%BC%E3%82%B1%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0]]はマーケティング用語

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

--@mizchiさんのツイート:~
https://twitter.com/mizchi/status/957851145531043840
--そもそも、汎用的であれば「[[AltJS>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?JavaScript#d11cd6c3]]」は登場していないものと思われる。

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

*参考 [#md49fd9e]

**[[開発支援ツールの種類]] [#x05f3b2a]

**[[開発支援ツールの自動生成方式]] [#f2cb790e]

**[[VS系コンテンツ]] [#o277ca15]

**その他 [#w76b0ec4]

***開発支援ツールとは? [#xba64325]
そもそも、開発支援ツールとは?

-開発支援ツールとは? その種類と特徴を、まめてみした。 - OSSコンソーシアム~
https://www.osscons.jp/jowaxn8yr-537/#_537

***開発基盤の必要性 [#n8ffdb60]

-超高速な開発ができるわけ | 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