.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

テクノロジやエンジニアリング関連のベネフィット創出プロジェクト、プログラム、
(...ある意味、ソフトウェア生産技術、開発基盤開発プロジェクト)の結果の過去情報から教訓をまとめる。

区分毎の事例

UIサブシステム関連

概要

  • 過去事例を見てみると、セグメント、ターゲットにハマっているかが重要と言える。
  • また、昨今では、Webサービスなどで利用されることが≒トレンドに乗る条件と
    なっているため、IDEなどにロックインされていないことが重要になってきている。

事例

  • VB6のフォームアプリケーション
    (その後の.NETのWindows Forms)
    • 非常に高い生産性で、エンプラで多用されている。
    • UIコントロールをD&D、ダブルクリック、コードの実装
      と非常に直感的な手順で、簡単に習得・実装できるのが当時ウケた。
  • Webアプリケーション(MPA → AJAX)
    • エンプラのWebアプリでは、コレがデファクト。
    • また、Webサービスのスタートアップなどでも
      コレの技術で開発されるケースは、まだまだ多い。
  • 方式
  • MVC
    柔軟な対応が可能なMVCが流行っている。
  • Web Forms(JSF)
    柔軟な対応が可能なMVCが流行ってはいるが、
    セグメント的にはハマる分野もまだまだ多い。
  • Webアプリケーション(SPA
  • 「狭い帯域幅でもコンテンツにユーザがリーチできるように。」
    的な要件コンテキストで採用されるUI技術であると考える。
    • 故に、エンプラの生産性にリーチしないことがある。
    • しかし、ミドルウェアなどの管理画面には使用される。
  • スタートアップ後の成功したWebサービスなどで利用される。
    (如何にエンドユーザにリーチするか?的な要件のコンテキストで)
  • スマホ(ネイティブ)アプリ
    • 基本的にSPAと同じだが、
    • ネイティブなので、
      • 性能的に優れている。
      • ネイティブ・アクセス的に優れている。

参考

データ・アクセス関連

概要

  • 過去事例を見てみると、セグメント、ターゲットにハマっているかが重要と言える。
  • 色々なタイプのORMが出てきたが、結局は、要件に沿って使い分けている。

事例

参考

テスト関連

概要

  • 過去事例を見てみると、セグメント、ターゲットにハマっているかが重要と言える。
  • テスト関連は、プラクティスなので、そのプラクティスが誕生したセグメント以外にはハマらない可能性がある。

事例

  • CI / CD
  • テスト自動化
    • TDD(テストコードを書く系)
    • UIオートメーション系

参考

プライベート・クラウド関連

概要

  • SI事業者でアレコレ検討がされた。
  • ハイブリッド・クラウド・ポータルは上手く行かない。
    ハイブリッド・クラウドに投資できる企業が出現しないので。
  • 最終的に、メガ・クラウド謹製の垂直統合に落ち着く感じ。
    • Azure Stack
    • AWS Outposts

事例

  • ハイブリッド・クラウド・ポータル的な。
    • ハイブリッド・クラウド・ポータル(社内みたいな)
    • 一昔前、PrimeCloud ControllerというOSSがあった。
  • 担ぐ系
  • プラクラ
    • VMware vCenter Server
    • Microsoft System Center
    • Cloud Stackなど

参考

アーキテクチャ関連

概要

  • 書籍レベルにまでなればいいが、組織内での取り組みは微妙。
  • デザインパターンなど空気的な存在になってようやく効果が出てくる。
  • マイナーな状態ではナカナカ効果が出てこない
    (テンプレートやIDEなどのサポートがない状態では難しい)。

事例

  • オブジェクト指向 分析/設計/プログラミング(OOA、OOD、OOP)
    OOD、OOP辺りは空気化してイイ感じになっている。OOAは普及しなかった感。
  • サービス指向(SOA)、マイクロサービス
    しかし、SOAやマイクロサービス系は、理論をこねくり回したわりに、
    Webメソッド実装できりゃーエエとかそのレベルになっている。
  • ドメイン駆動設計(DDD)→ クリーンアーキテクチャ
    DDDも≒クリーンアーキテクチャ位で落ち着くのが良いのかも知れない。
  • クラウド・アーキテクチャ
    • 主語がデカイのでは?オンプレをクラウドにもっていくなら変更は不要
    • ただし、要件次第で、以下のような対応が必要になるケースは多い。
      • クロスドメイン認証に対応
      • WebAPIやDBのリトライポリシー策定&実装

参考

プロセス関連

マネジメント・プロセス

エンジニアリング・プロセス

  • 特に下流の開発方法論については、大きな変化は見られない。
  • 2001~2010あたりで大方、Fixした感がある。

要件定義と適応型ライフサイクル

  • 要件に係る上流に関しては、近年重要性を増している。
  • そういう動きが、2010以降の生産技術で見られる。

マーケティング組織的プロジェクト・マネジメント(OPM)

事業戦略と組織戦略 に関しては、近年重要性を増している。

, etc.

必要に応じて追記していく。

教訓登録簿

基本的にトレンドは無視できない。

以下のような話で、結局、トレンドは無視できない。

  • トレンドに乗ってない技術は、disconになってサポートが切れる。
  • クラウド、スマホなどの浸透により、デマンドサイドのニーズとしても増えてくる。

トレンドだからと言って成長していない事業に投資してもダメ

  • 例えば、垂直統合型のソフトウェア産業が斜陽化しているとする。
  • そんな中で、クラウド(プラットフォーム)が出てきて、
    焦って、垂直統合型スキームのまま投資しても勝てる訳が無い。

トレンド無視のニッチ系は事業と深い関連が必要だが短期的な話。

  • トレンドに乗っていない、ニッチである場合、
    • トレンドを無視して良いケースもある。
    • ただし、事業と深い関連が必要になる。
  • これは、つまり、
    • トレンド ≒ 外部要因(環境要因)であるが、
    • ニッチ ≒ 内部要因(自社事業要因)である

と言うことになる。

  • また、
    • ニッチは、短期的には重要である。
    • トレンドは、長期的に重要性を増して行く。

と言う傾向がある。

ベネフィット系は現場(プロフィット)のニーズ駆動だと失敗する。

  • ベネフィット系は現場のニーズ聞いて愚直にやって成功した事例は一つも無い。
  • 理由は、現場のミッションがプロフィットなので、ベネフィットに関する考察が浅いため。

ライフサイクルは早くなってきている(同時に注力ポイントでもある)。

ライフサイクルの変化

SoRだけでなく、SoEでのIT利用が進み、

  • 一応、技術は(基礎部分というより、応用部分が)、進歩していると言える。
  • その結果として、ランタイム系のライフサイクルは短くなっている。
  • 代表的な例が、Javaや.NET Coreの長期商用サポート(LTS : Long Time Support)の提供。

注力ポイントの変化

  • 早いライフサイクルの中で、廃れない技術を見極め、ピックアップすることの重要性が高まっている。
    • ただし、SPA系のフレームワークの栄枯盛衰をみると、予測不可能と思われるケースも多い。
    • 事業的に、急いでいなければ、慌てず待つ。と言う選択肢を選択する事も重要になる。

と言える。

競争のレイヤは上がっていく(スタックは積み上がっていく)。

ハード → ソフト

  • ハード
    • オンプレ
    • 仮想化
    • クラウド
  • ソフト
    • OS → ミドル → 上モノ
    • IaaS → PaaS → SaaS

インフラ → フロントエンド

  • インフラ →(仮想化/クラウド)→ アプリ
  • バックエンド →(PaaS/SaaS)→ フロントエンド

参考

ゲームチェンジやパラダイムシフトは起きる。

概要

以下のような変化の積み重なりで当然、起きうる。

事例

  • ソフトはハードのオマケ → ハードはソフトのオマケ。
  • 垂直統合事業 → オープン・アーキテクチャ → 垂直統合事業
  • プロダクト → OSS
  • オンプレ → クラウド

参考

天地人が揃う、時勢を読む必要がある。

概要

  • 色々、時勢を読む必要がある。
  • 少子・高齢化社会 → 生産年齢人口の減少
  • 国際競争力の低下(新興国が伸びた)
  • 終身雇用の崩壊
    • メンバシップ雇用による新50代問題の発生。
    • メンバシップ雇用からジョブ型雇用へ。
  • 天地人
  • 孟子の「公孫丑章句上」の中の一節「天時不如地利。地利不如人和」に由来
    • 天:天の時=タイミング
    • 地:地の利=おかれた環境
    • 人:人の輪=人心の一致
  • 意味としては、
    • 「天<地<人」だが、人心の一致には天・地も必要な訳で、
    • 戦に勝つことや物事を成功させるには(天地人の)3条件が必要。

参考

, etc.

必要に応じて追記していく。

教訓のサマリ

サマリすると、大枠で以下のように言える。

ミクロではセグメント&ターゲットが重要

ミクロな技術のフィッティングでは、その技術が、
適切にセグメンテーションされたターゲットにフィットするかどうかという話。

マクロではゲームチェンジやパラダイムシフトを考慮

マクロな事業戦略と組織戦略では、

  • ゲームチェンジやパラダイムシフトに備えた対応が必要になる。
  • 変化が起き無い分野は斜陽の分野であり、注力ポイントではない。

戦略性が低いと、Buzzに乗った予算認可やカタストロフィ芸になる。

論理的ではない未来予測にありがちなパターン。

Buzzに乗った予算認可

  • 自分ではあまり考えていないが、Buzzってるので、予算認可され易い。
  • 予算認可されたはいいが、あまり考えていないので結果が出ず苦しむことも。

カタストロフィ芸

プロフィットとベネフィットの混同

ベネフィット系のプログラムはプロフィット系のミッションからは創出されない。

  • Q&A型の技術サポート
  • 作業負荷のオフロード型のサポート
  • 火消し(火消し要員のプール)

※ プロフィット系のミッションからは、
 ベネフィット系のプログラムに必要とされる戦略が練られないタメ。

戦略立案のため、適切な、組織的プロジェクト・マネジメント(OPM)を行う。

ポートフォリオ・マネジメント

ポートフォリオ・マネジメントでは、経営戦略、組織戦略などが対象になる。

プログラム・マネジメント

ベネフィット創出の対象は、プログラム(プログラム・マネジメント)になる。

プロジェクト・マネジメント

参考

トレンドの分析(シェア)

マイクロソフト系技術情報 Wiki > VS系コンテンツ

UI系

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

OSSコンソーシアム > 開発基盤部会 Blog

生産技術界隈でBuzzったケド、ダメだった...

カタストロフィ的芸風について考える。

UIサブシステム関連

データ・アクセス関連

テスト関連

プライベート・クラウド関連

アーキテクチャ関連

ゲームチェンジやパラダイムシフト

時勢を読む


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2020-09-21 (月) 13:43:50 (7d)