「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
テクノロジやエンジニアリング関連のベネフィット創出プロジェクト、プログラム、
（...ある意味、ソフトウェア生産技術、開発基盤開発プロジェクト）
の結果（過去情報）から、プロジェクト選定委員会で活用可能な教訓をまとめる。
区分毎の事例 †
UIサブシステム関連 †
概要 †
- 過去事例を見てみると、
セグメント、ターゲットにハマっているかが重要と言える。
- また、昨今では、Webサービスなどで利用されることが≒トレンドに乗る条件と
なっているため、IDEなどにロックインされていないことが重要になってきている。
事例 †
- VB6のフォームアプリケーション
（その後の.NETのWindows Forms）
- 非常に高い生産性で、エンプラで多用されている。
- UIコントロールをD&D、ダブルクリック、コードの実装
と非常に直感的な手順で、簡単に習得・実装できるのが当時ウケた。
- Webアプリケーション（MPA → AJAX）
- エンプラのWebアプリでは、コレがデファクト。
- また、Webサービスのスタートアップなどでも
コレの技術で開発されるケースは、まだまだ多い。
- Web Forms（JSF）
柔軟な対応が可能なMVCが流行ってはいるが、
セグメント的にはハマる分野もまだまだ多い。
- 「狭い帯域幅でもコンテンツにユーザがリーチできるように。」
的な要件コンテキストで採用されるUI技術であると考える。
- 故に、エンプラの生産性にリーチしないことがある。
- しかし、ミドルウェアなどの管理画面には使用される。
- スタートアップ後の成功したWebサービスなどで利用される。
（如何にエンドユーザにリーチするか？的な要件のコンテキストで）
- スマホ（ネイティブ）アプリ
- 基本的にSPAと同じだが、
- ネイティブなので、
- 性能的に優れている。
- ネイティブ・アクセス的に優れている。
- スマホUX的に優れている。
参考 †
データ・アクセス関連 †
概要 †
- 過去事例を見てみると、
セグメント、ターゲットにハマっているかが重要と言える。
- 色々なタイプのORMが出てきたが、結局は、要件に沿って使い分けている。
事例 †
参考 †
テスト技法ツール関連 †
概要 †
- 過去事例を見てみると、
セグメント、ターゲットにハマっているかが重要と言える。
- テスト技法ツール関連は、プラクティスが重要なので、
そのプラクティスが誕生したセグメント以外にはハマらない可能性がある。
事例 †
- テスト自動化
- TDD（テストコードを書く系）
- UIオートメーション系
参考 †
プライベート・クラウド関連 †
概要 †
- ハイブリッド・クラウド・ポータルは上手く行かない。
ハイブリッド・クラウドに投資できる企業が出現しないので。
- 最終的に、メガ・クラウド謹製の垂直統合に落ち着く感じ。
事例 †
- プラクラ
- VMware vCenter Server
- Microsoft System Center
- Cloud Stackなど
参考 †
アーキテクチャ関連 †
概要 †
- 書籍レベルにまでなればいいが、組織内での取り組みは微妙。
- デザインパターンなど空気的な存在になってようやく効果が出てくる。
- マイナーな状態ではナカナカ効果が出てこない
（テンプレートやIDEなどのサポートがない状態では難しい）。
事例 †
- オブジェクト指向 分析/設計/プログラミング（OOA、OOD、OOP）
OOD、OOP辺りは空気化してイイ感じになっている。OOAは普及しなかった感。
- サービス指向（SOA）、マイクロサービス
しかし、SOAやマイクロサービス系は、理論をこねくり回したわりに、
Webメソッド実装できりゃーエエとかそのレベルになっている。
- ドメイン駆動設計（DDD）→ クリーンアーキテクチャ
DDDも≒クリーンアーキテクチャ位で落ち着くのが良いのかも知れない。
- クラウド・アーキテクチャ
- 主語がデカイのでは？オンプレをクラウドにもっていくなら変更は不要
- ただし、要件次第で、以下のような対応が必要になるケースは多い。
- クロスドメイン認証に対応
- WebAPIやDBのリトライポリシー策定＆実装
参考 †
プロセス関連 †
マネジメント・プロセス †
- PMPの改訂履歴を参照すると良い。
- 基本的に大きな変化はない。
- 近年の大きな変更は、
エンジニアリング・プロセス †
要件定義と適応型ライフサイクル †
事業戦略と組織戦略 に関しては、近年重要性を増している。
サプライサイド・デマンドサイド †
捻じれ †
SIは、本質的にデマンドサイドだが、
以下のケースで、サプライサイド気質が残るケースがある。
能率主義 †
捻じれが起きているケースで、
ニーズが効率向上ではなく能率向上に終止するケースがある。
自前主義 †
捻じれが起きているケースで、
自前主義からの脱却が遅れるケースがある。
プロフィット・ベネフィット †
捻じれ †
SIは、プロフィット偏重の傾向がある。
- ベネフィット系のプログラムは
プロフィット系のミッションからは創出されない。
- ただし、世の中は、ベネフィットの重要性が増してきて来ている。
売上至上主義 †
- プロフィット偏重の一例
- 売上は重要だが、原因と対策に注力されていない。
労働集約型産業 †
- プロフィット偏重の一例
- 時間の切り売りを行うのは、
- プロフィット偏重、ベネフィット軽視。
- 能力的にベネフィット創出が出来ない。
, etc. †
必要に応じて追記していく。
教訓登録簿 †
基本的にトレンドは無視できない。 †
以下のような話で、結局、トレンドは無視できない。
- トレンドに乗ってない技術は、disconになってサポートが切れる。
- ハイプ・サイクルによりトレンドが浸透に代わるなどすると、
クラウド、スマホなど、デマンドサイドのニーズとしても増えてくる。
トレンドだからと言って成長していない事業に投資してもダメ †
- 例えば、垂直統合型のソフトウェア産業が斜陽化しているとする。
- そんな中で、クラウド（プラットフォーム）が出てきて、
焦って、垂直統合型スキームのまま投資しても勝てる訳が無い。
トレンド無視のニッチ系は事業と深い関連が必要、だがソレは短期的な話。 †
- トレンドに乗っていない、ニッチである場合、
- トレンドを無視して良いケースもある。
- ただし、事業と深い関連が必要になる。
- これは、つまり、
- トレンド ≒ 外部要因（環境要因）であるが、
- ニッチ ≒ 内部要因（自社事業要因）である
と言うことになる。
- また、
- ニッチは、短期的には重要である。
- トレンドは、長期的に重要性を増して行く。
と言う傾向がある。
ベネフィット系は現場（プロフィット）のニーズ駆動だと失敗する。 †
- ベネフィット系は現場のニーズ聞いて愚直にやって成功した事例は一つも無い。
- 理由は、現場のミッションがプロフィットなので、ベネフィットに関する考察が浅いため。
ライフサイクルは早くなってきている（同時に注力ポイントでもある）。 †
ライフサイクルの変化 †
SoRだけでなく、SoEでのIT利用が進み、
- 一応、技術は（基礎部分というより、応用部分が）、進歩していると言える。
- その結果として、ランタイム系のライフサイクルは短くなっている。
- 代表的な例が、Javaや.NET Coreの長期商用サポート(LTS : Long Time Support)の提供。
注力ポイントの変化 †
- 早いライフサイクルの中で、廃れない技術を見極め、ピックアップすることの重要性が高まっている。
- ただし、SPA系のフレームワークの栄枯盛衰をみると、予測不可能と思われるケースも多い。
- 事業的に、急いでいなければ、慌てず待つ。と言う選択肢を選択する事も重要になる。
と言える。
競争のレイヤは上がっていく（スタックは積み上がっていく）。 †
ハード → ソフト †
- ソフト
- OS → ミドル → 上モノ
- IaaS → PaaS → SaaS
インフラ → フロントエンド †
- インフラ →（仮想化/クラウド）→ アプリ
- バックエンド →（PaaS/SaaS）→ フロントエンド
参考 †
, etc. †
必要に応じて追記していく。
教訓のサマリ †
サマリすると、大枠で以下のように言える。
中長期でゲームチェンジやパラダイムシフトは起きる。 †
概要 †
以下のような変化の積み重なりで当然、起きうる。
事例 †
- ソフトはハードのオマケ → ハードはソフトのオマケ。
- 垂直統合事業 → オープン・アーキテクチャ → 垂直統合事業
- プロダクト → OSS
- オンプレ → クラウド
参考 †
天地人が揃う、時勢を読む必要がある。 †
概要 †
- 少子・高齢化社会 → 生産年齢人口の減少
- 国際競争力の低下（新興国が伸びた）
- 終身雇用の崩壊
- メンバシップ雇用による新50代問題の発生。
- メンバシップ雇用からジョブ型雇用へ。
- 孟子の「公孫丑章句上」の中の一節「天時不如地利。地利不如人和」に由来
- 天：天の時＝タイミング
- 地：地の利＝おかれた環境
- 人：人の輪＝人心の一致
- 意味としては、
- 「天＜地＜人」だが、人心の一致には天・地も必要な訳で、
- 戦に勝つことや物事を成功させるには（天地人の）３条件が必要。
事例 †
...
参考 †
ミクロ・マクロ †
ミクロではセグメント＆ターゲットが重要 †
ミクロな技術のフィッティングでは、その技術が、
適切にセグメンテーションされたターゲットにフィットするかどうかという話。
マクロではゲームチェンジやパラダイムシフトを考慮 †
マクロな事業戦略と組織戦略では、
- ゲームチェンジやパラダイムシフトに備えた対応が必要になる。
- 変化が起き無い分野は斜陽の分野であり、注力ポイントではない。
戦略性が低いと、Buzzに乗った予算認可やカタストロフィ芸になる。 †
論理的ではない未来予測にありがちなパターン。
- 自分ではあまり考えていないが、Buzzってるので、予算認可され易い。
- 予算認可されたはいいが、あまり考えていないので結果が出ず苦しむことも。
ポートフォリオ・マネジメントでは、経営戦略、組織戦略などが対象になる。
ベネフィット創出の対象は、プログラム（プログラム・マネジメント）になる。
参考 †
Subsystem & Framework
- Windows Form vs WPF
- ASP.NET Web Forms vs ASP.NET MVC
- 従来型のWebアプリ vs SPA（Single-page Application）
- 様々なSPAフレームワーク
- ネイティブ vs ハイブリッド
- IDE vs RAD vs EUC vs Template & Package (開発支援ツールの種類)
- ADO.NET vs ORM (Entity Framework, Dapper)
- SVN vs Git vs TFS
- ASP.NET Forms認証 vs ASP.NET Identity
UIサブシステム関連 †
データ・アクセス関連 †
テスト技法ツール関連 †
→ , etc.
プライベート・クラウド関連 †
→ , etc.
アーキテクチャ関連 †
ゲームチェンジやパラダイムシフト †
時勢を読む †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
