自プロダクト開発に注力しているため、なかなか言及する機会がありませんでしたが、今回は、某弊「開発基盤部会」らしく、最近、私が重宝している「開発環境、ツール、ライブラリ」など、導入し易く、「エンタープライズ分野のアプリケーション開発」であっても、
生産性を上げるには最低限、コレ位は導入した方がイイと思われるモノを以下に列挙してみます。
＜アウトライン＞
ボリュームが増えたのでアウトライン。
- IDE (Visual Studio, Visual Studio Code)
- パッケージ・マネージャー (NuGet, npm)
- テンプレート (dotnet new, npm系)
- シェル・スクリプト (BAT, PowerShell)
- 構成管理ツール (Git, GitHub)
- .NET Core
- Linuxで動かす (WSL, Docker)
- まだまだ、これから？
- OAuth2 / OIDC / FAPI, FIDO2
- DevOps（Git → CI → PaaS/CaaS ）
IDE
先ず始めは、言わずと知れた「IDE : Integrated Development Environment（統合開発環境）」です。流石にこれを知らない人はいないでしょう。以下でも言及しているように、IDEは、多くの場合、開発の起点になっています。
Visual Studio、.NET開発やVC++開発、その他、SPA開発（バックエンドは.NET）など、非常に便利です。Cordova開発などもサポートされていますが、その後、Visual Studio Code側で注力されるなどの経緯があったので、Openなモノについては、下記のVisual Studio Codeを使用した方が良いかと思います。
Windows, Linux, macOS 上で動作するクロスプラットフォームのデスクトップ・アプリで、特に（.NETに縛られない）JavaScript系のフロントエンド開発に利用しています。JavaScript以外でも、PythonやPHP等の言語を用いた開発で利用可能です。勿論、C#を用いた、.NET Core開発も可能です。
パッケージ・マネージャー
昨今、パッケージ・マネージャーを使用しない開発と言うもの考え難くなってきました。パッケージ・マネージャーは、開発環境構築で重宝します。.NETで開発を行っていると、NuGetやnpmをよく使用します。
言わずと知れた？マイクロソフト系のパッケージ・マネージャー（.NETが中心だけど、VC++のパッケージなども追加できる）。
NuGetを使用すると、パッケージをインターネットやファイルサーバーから容易に取得できるので、開発環境構築やビルドを自動化できます。また、自作のパッケージの登録は、他の人に使って貰う目的もありますが、自プロダクトを使用した開発のビルド・システムのエンハンスにも繋がります。
また、高度な使い方をマスターすると、NuGetのWebサイトを、
シンボル・サーバー＆ソース・サーバーとして動作させることもでき、これによって、パッケージ・マネージャーに登録した
パッケージのデバッグ手順を簡素化することができます。
こちらは、Node.jsのパッケージ・マネージャーで、NuGetと同様に開発環境構築やビルドを自動化できます。Node.jsのパッケージ・マネージャーなので普通に考えると、JavaScriptでの開発をサポートするツールの筈ですが、npmについては、クロス・プラットフォームのフロントエンド開発ツールになっている気がします。
例えば、Node.js系のフロントエンド開発ツールと組み合わせることによって、トランスパイラによってTypeScriptやECMAScriptを使用して開発することもできますし、Electronと組み合わせてPythonを使用して開発することもできるようです。
テンプレート
Visual Studioで言う、[新規作成] -> [プロジェクト]で生成されるプロジェクトは、プロジェクト・テンプレートと言うものをベースにして生成されています。テンプレートは、前述のIDE＋パッケージ・マネージャーのUXを向上させ、これらの機能をユーザに有効活用させることが出来ます。
そのため、私も、独自に
「エンタープライズ分野のアプリケーション開発」のドメインに適合したテンプレートを開発しています。ここでは、Visual Studioを除く、プロジェクト・テンプレートを実装するツールについて言及します。
dotnet new
.NET Coreからは、プロジェクト・テンプレートを実装するツールが、IDEから分離されて「dotnet new」に実装されました。こちらを参照すると様々なプロジェクトを生成可能であることが解ります。「dotnet new -l」で生成可能なプロジェクトを確認できます。また、アドオンを追加することで、Vue.jsなどを使用したプロジェクトを生成することもできるようです。
npm系
npm系のものには、代表的なものに「create-react-app」や「cordova create」などがあります。.NETに縛られない開発をする場合は、「dotnet new」ではなく、こちらを使用して、IDEとしては、Visual Studio Codeを使用すると良いかと思います。詳しくは
コチラをご参照下さい。
シェル・スクリプト
BAT以外と言えばGUIシェルばかりで、展開にも
sysprepが必要になる（しかも、追加した役割によっては、サポートされない）など、プロのインフラ屋さんには不評だったWindows Serverですが...。
BATもまだまだ現役で使用されているかと思いますが、BATは昨今、ちょっと貧弱になってきました。
PowerShellは、新しく追加された強力なCUIシェルです。...と言っても結構昔からありますが（調べると登場時期は2006年11月）、昨今、機能も拡充し、ネット上にもイイ感じのスニペットが落ちているので、かなり実用的になったように思います。スクリプト化する事で、
色々なタスクを自動化することが出来ます。
構成管理ツール
昨今、利用される構成管理ツールとしては、Git, GitHubがポピュラーです。一般的には「VSSやSVNや、TFSの後継に当たる、プログラムの構成管理ツール。」だと思います。
VSSやSVNや、TFSの後継に当たる、プログラムの構成管理ツールですが、「分散型」であることが大きく異なります。
Gitは、Linuxカーネルのような巨大プロジェクトのソースコード管理に用いるためにリーナス・トーバルズによって開発され、変更履歴を記録・追跡でき、動作速度に重点が置かれている他、ローカルやサーバーでも動作して、各リポジトリ間で同期をとれるので「分散型」と呼ばれます。「分散型」の構成管理ツールは、その機能から、使いこなすのが難しいと言われており、一昔前ではエンタープライズ界隈では敬遠されていましたが、昨今は、割と一般化してきていると思います。
GitHubは、Gitのホスティング＋セルフサービス・ポータルのGUIを実装したようなWebサイト（Webサービス）です。
GitのUIとしての機能以外で、GitHubによって独自に追加される機能としては、issue、milestone、release、アクセス制御などの管理から、Wiki作成などが行える機能があるかと思います。また、プルリクエスト（Pull Request）という言葉が有名だと思いますが、これは、Git自身の機能ではなくGitHubが最初に提供した、修正の取込（プル）を依頼（リクエスト）する機能だそうです。最近では、脆弱性報告等の機能も追加されています。
今は買収されてマイクロソフトによって運営されています。GitHubに似た、GitHubクローンと呼ばれるGitLab、GitBucket、GitblitなどのOSSやWebサイト（Webサービス）もあるようです。
.NETは、勿論サーバーサイド開発で利用されることもありましたが、サーバーサイドJavaのシェアが大きく、フロントエンド開発や、EUC (End-User Computing) での利用が中心でした。
しかし、.NET Coreの登場により、Linux上で.NETを動かすことがサポートされた事によって、.NETでサーバー・サイドのミドルウェアを書くようなケースでもペイラインに乗るようになり、.NETを利用する幅が広がりました。
私も最近、.NET Coreを使用して、サーバーサイドのミドルウェアの移植を始めています。 .NET Coreで開発を進めると、クロス・プラットフォームのサポート状況を確認するために、サクッとLinuxで動かすための何某かが必要になります（Windowsがメインマシンの場合）。これには、Linuxサブシステムや、コンテナ技術が利用できます。
WSL（Windows Subsystem for Linux）はLinuxサブシステムです。
Linuxサブシステムなので、エミュレーション環境（互換レイヤ）を経由して動作しますが、軽い動作確認には、十分かと思ます（Windowsのファイル システムのフィルタ ドライバを経由するため、I/Oが遅くなるらしい）。
DockerはLinuxネイティブのコンテナ技術です。
Windows上で、
Docker for Windows や
Visual Studio Tools for Dockerを有効にして、Visual StudioからLinuxコンテナのサポートを有効にすると、Hyper-V上のLinux上で動作するDockerと言うLinuxコンテナ上にデプロイされて実行されます。より厳密な動作確認を行いたい場合はコチラを利用すると良いかと思います。
まだまだ、これから？
以下は、「
この辺り」で少々言及したトレンド入りしている技術ですが、我々周辺では「まだまだ、これから」の技術を列挙していきたいと思います。その中で、どの辺に課題があるか？についても言及していきたいと思います。
OAuth2 / OIDC / FAPI, FIDO2
OAuth2 / OIDC / FAPI や
FIDO2などの、認証 / 認可 / フェデレーション技術は、クラウド・ネイティブなアプリケーション開発に必須になって来ていますが、難しくて中々導入されて行かないと思っています。
従って、
プロダクト含めた一式を使用したプログラムをテンプレート提供することによって、これら構成のアプリケーションの稼働を、容易に実現する事を検討中です。
DevOps（Git → CI → PaaS/CaaS ）
「DevOpsの
PaaS/CaaS や
CI って、なかなか浸透しないけど、云々...。」と書こうと調べていたら、"↓" えぇえぇぇー！？。
しかし、コレに係わってる人ってサプライサイド人が多過ぎるタメなんじゃないですかね？日式のベンダ比率が高いのも問題かもしれないです。中を確認すると「協議会メンバーの多くはIT（情報技術）ベンダーであり、”IT提供者としてDevOpsを進めるためのノウハウや成果物は蓄積したものの、非IT事業者との間で実践する取り組みにはなかなか行き着かない、という限界を示していた。”」とありました。やっぱり。
コレを読んで、近々「サプライサイド限界説」ってのを提唱したいな。なんて思ったりしました。サプライサイドに近い人達（の特に運営側）って緩いんじゃないですかね？日式はサプライサイド（ベンダ側）が75%、米国は30%以下です。だからこそ、
適応型ライフサイクル（アジャイル）の導入などにおいて、グローバルと足並み揃わない感あります。
と、少々脱線しましたが、DevOpsが浸透しない理由は、
以前にも書いた通りで、「LL言語を用いたWebサービス開発」と「エンタープライズ分野のアプリケーション開発」で、適合するプラクティスが異なるためと思います。「LL言語を用いたWebサービス開発」と比べると、「エンタープライズ分野のアプリケーション開発」は、ステージング環境ではなく、ローカルの開発環境でのテストの比率が高く、リリース後に、あまり修正しないのだと思います。
このため、SI向きのプラクティスは、ローカルでのビルド＆デプロイを自動化し、ContainerやOpen PaaSを使用してテスト環境を迅速にキッティングし、テストデータ投入やエビデンス取得を効率化するツール（シナリオ・テストの能力はなくてもイイ）を整備する。と言った所かもしれません。そういったものも、まだまだ効率化する余地はあるかと思います。
...と、導入し易く、
「エンタープライズ分野のアプリケーション開発」であっても、生産性を上げるには最低限、コレ位は導入した方がイイと思われる「開発環境、ツール、ライブラリ」についてご紹介させて頂きました。
本ブログ記事を書いていて、一つ思ったことは、私は、結構デマンドサイドに立ってるんじゃないか？と言う事です。そういう意味で、サプライサイドとは話が噛み合わないのかもしれない。という自覚が芽生えて来ました。
...さて、次回は、日本の著名なOSS（.NET）が、どんな開発環境、ツール、ライブラリなどを使用しているのか？ベンチマーキングをしてみようと思います。そのまた次回は、各種の要素技術についても言及してみようと思います（後々のロードマップ作成のため）。
Open COBOL Solution WG
最近重宝している開発環境、ツール、ライブラリなどの紹介
