「[[Open棟梁 wiki>https://opentouryo.osscons.jp]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。

-[[戻る>開発基盤とは]]

*目次 [#gf3b084e]
#contents

*概要 [#e76b9bfb]
開発基盤のプログラム・マネジメントの際の注意点。

-事業ポートフォリオから~
乖離しないようにプログラムを作成する。

-以下に注意して、
--個々のプロジェクトを組立る。
--そして、プログラム・マネジメントする。

*方針 [#h7ce5259]

**ポートフォリオ [#la990fc4]
事業ポートフォリオに合わせて個々のプロジェクトをプログラムする。

**オープン or クローズド [#vb474f6e]
-利用するモノと開発するモノがある。
-何を利用し、何を開発する(≒どのような価値を生む)か?明確にする。

***オープン [#n24db47a]
主に利用するモノ。

-コモディティ。

-内製する意味が無いモノ。

-利用する分には、オープンなモノの方がイイ。

--OSSであれば、ライセンス・フィー無しで利用できる。~
(ただし、付帯費用が発生するケースがある)

--特に、[[言語やプラットフォーム>#wfc693dd]]は、オープンな技術である方が、~
ライセンス(使用許諾)などに縛られず組み合わせられる。

***クロースド [#i7d00014]
主に独自開発するモノ。

-オープンなモノを利用するダケでは差別化不可能(ネットの情報で良い)。

-クロースドな要素(≒[[独自性の有るコンテンツ力>#hb719a93]])がどこかしらに必要になる。
--オープンなモノを組み立てて独自性があるモノにする。
--クローズドにする(マネタイズするにはイイが開発基盤には適合しない)。

-クロースドなモノより、[[オープン>#n24db47a]]なモノの方が利用させ易い。~
単独でマネタイズできない開発基盤は開示した方がイイ。

*要素 [#o1b6d980]
以下のような要素を準備した上で組み立てる。

**言語やプラットフォーム(オープン) [#wfc693dd]
-コモディティであるため、シェアが重要。
-実際の組み立ての際は、[[STPの見極め>#n79b6d9a]]が必要。

***言語 [#v60de13f]
[[シェア - .NET 開発基盤部会 Wiki > 言語>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?%E3%82%B7%E3%82%A7%E3%82%A2#od7c604b]]

***プラットフォーム [#x147597f]
[[シェア - .NET 開発基盤部会 Wiki > OS, クライアント, サーバ, プラットフォーマー>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?%E3%82%B7%E3%82%A7%E3%82%A2#a113cbc4]]

**独自性の有るコンテンツ力(クローズド) [#hb719a93]
-コンテンツ力が必要になる。
-[[プロジェクトの定義にある独自性 / 有期的 / 段階的詳細化>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?PMP%EF%BC%9A%E5%85%B1%E9%80%9A#wfc1fef5]]がある。

***ライブラリ、フレームワーク → テンプレート [#mbb16b85]
-技術分野毎に開発され得る。

--テンプレートとパッケージ・マネージャを使用して、~
スタックを組んで、TODOコメントを提供する。

--ライブラリ、フレームワークは、~
テンプレートの機能強化によって出来上がる。

-例
--Asakusa Framework
--Open Touryo

***ランタイム [#h73c7094]
ランタイムは毛色が少々異なる。

-opensource COBOL

[[言語やプラットフォーム(オープン)>#wfc693dd]]と対比すると「ニッチ」と言える。

***ドキュメント(形式知) [#c3026b45]
インターネットに書いた方がイイ(イントラは誰も見ない)。

***ノウハウ(暗黙知) [#x94d62c4]
-メリット
--ノウハウ(暗黙知)≒ 遂行能力
--更なる差別化が必要になる場合、遂行能力で差別化が可能。
--マネタイズ・レベル可能になる(が、開発基盤にはむしろマイナス)。

-デメリット
--暗黙知に近いと、文書化し難いので、オープンにし難い。
--依存度が高いと、セルフサポート化が難しくなる。

**業務パッケージ [#k33bcd8c]
-業務分野毎に開発され得る。

--MosP
--Pleasanter

-以下の検討が必要。~
昨今、後者が増えている。
--自分が主体となって開発するか?
--ソリューションの一角として利用するか?

*組立 [#eb3c0529]

**パターン [#j96abef5]

***スタック(前提) [#r82db6ab]
上位と下位をスタックさせて組み立てる。

-アプリケーションの場合~
プラットフォーム → ランタイム → ライブラリ → フレームワーク

-インフラストラクチャーの場合~
ホスト → ゲスト → コンテナ(docker) → コンテナ・イメージ(docker image)

上位・下位にズレると専門外になるので、組合わせに専門家間での連携が必要になる。~
(ただ、単純に乗るケースも多いので、1ユーザとして使用するダケで済む場合も多い)

※ 昨今、オープンなものは、大概、スタックは出来るようになってきた。~
(スタックすること自体は独自性が低く、施策の必要条件ではあるが十分条件では無くなって来ている)。

***コラボレーション(差別化) [#o333f18d]
-同じレイヤで横の繋がりを意識する。
--繋ぎ目は、オープンなプロトコルである必要がある(HTTP、JSON、OAuth2, etc.)
--スタックは単純に上に乗るが、コラボレーションはカナリ意図的に組み合わせる必要がある。
--同じレイヤ内なので、当該レイヤ内でかなり詳しくならないと「差別化可能な組み合わせ」に到達しない。

-[[フロントエンド + OAuth2 + バックエンド>https://techinfoofmicrosofttech.osscons.jp/index.php?UserAgent%E3%81%A7OAuth2%E3%81%AEToken%E3%82%92%E5%8F%96%E5%BE%97%E3%81%99%E3%82%8B%E3%83%99%E3%82%B9%E3%83%88%E3%83%BB%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9]]
--モバイル
--AuthN / AuthZ Server
--Resource Server
--API Gateway

-[[IoT>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?IoT]] / [[ビッグデータ>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?%E3%83%93%E3%83%83%E3%82%B0%E3%83%87%E3%83%BC%E3%82%BF]] / AI

--[[IoT>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?IoT]]
---デバイス
---エッジ
---クラウド

--[[ビッグデータ>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?%E3%83%93%E3%83%83%E3%82%B0%E3%83%87%E3%83%BC%E3%82%BF]]
---ストレージ~
NoSQL~
データレイク~
データマート~
---EAI/ETL
---分散処理

--AI
---...。
---...。
---...。

-業務パッケージ~
ありものの業務パッケージでソリューションを構築。
--財務・会計
--勤怠・人給・人財
--ワークフロー
--など

**組立のポイント [#q8f06927]

***[[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]]の見極め [#n79b6d9a]
実際にあるニーズに、自身が応えることが出来るか?と言う事。

-上位の方が明確だが、下位のモノにも存在する。

--開発ツール(上位)

---Visual Studio + ASP.NET~
プロフェッショナル・ツール

---PowerApps~
EUCツール

--プラットフォーム(下位)

---Linux~
サーバー、サービス基盤

---Windows~
デスクトップ、情報システム部

-セグメント&ターゲットを見誤ると各プロジェクトの~
成果物がベネフィットを生まないので注意する。

--例
---テスト自動化
---CI / CD

--参考~
OSSコンソーシアム
---SIでCIやテスト自動化が、なかなか上手く行かない理由~
https://www.osscons.jp/jo46pq2ts-537/
---Open PaaS系が某弊界隈で微妙だった件について分析してみた。~
https://www.osscons.jp/joqtakc2c-537/
---生産技術界隈でBuzzったケド、~
ダメだった過去の生産性向上施策の一覧~
https://www.osscons.jp/joy5hs42t-537/

-ニーズはあってもポジショニングが取れないと言うのは、~
既存事業的に優位なポジション取りが出来ないケース。

--例
---クラウドポータル
---Open PaaS
---, etc.

--参考~
...。

***必要となるモチベーションやAS-IS [#a9549376]
前述のポジショニングのために重要になる。

-開発基盤は、先ずは、自社事業の治工具として出てくる(自社事業への貢献)。
-OAuth2の習得には、SaaS開発したいというモチベーションが必要だった。
-ビッグデータを勉強するには、AS-ISでデータ分析業務が必要と思われる。

***制度設計の重要性 [#e1a0676e]
プログラムを構成する個々のプロジェクトが~
正確に評価されるようにする必要がある。

-プログラムとして組み立てて
--プロジェクト同士が互いに争わないようにする。
--プロジェクトが自律的にスタック&コラボレーションするようにする。

-KPIを悪用できるものにしない。

--ベネフィットを適切に測定できるものにする。

--自助努力で伸びない数値をKPIに設定しない。~
若しくは、KPIが伸びない組織の環境要因を取り除く。

--ベネフィットを伸ばさず、KPIだけが~
「数値的に」伸びる工夫がされていないか監視する。

*ベネフィット・マップの作成 [#f14d9515]

-シーズ(種)
-> ニーズ(想い)
-> ウォンツ(意欲)
-> デマンド(需要)
-> ベネフィット(提供された価値)

**ビジネス・ニーズ [#s11d4441]
-開発基盤のオープン化が必要
--オープン・スタンダード
--オープン・アーキテクチャ
--オープン・ソースソフトウェア

-理由
--ロックインされない
---ポータビリティ(可搬性)
---インターオペラビリティ(相互運用可能性)

--費用の軽減
---初期投資費用の軽減
---その後のサポートサービスとの契約締結も可能

--様々なプラットフォームをサポート可能
---様々なディストリビューション上でスタック可能。
---様々なシステムとコラボレーション可能。

**戦略目標とベネフィット [#ka119017]

-戦略目標~
「顧客が望む」、オープン化に対応できるよう、開発基盤を変更する。
--オープン・スタンダード
--オープン・アーキテクチャ
--オープン・オープンソース

-ベネフィット
--受注貢献
--クラウド、スマホ環境のサポート
--開発基盤導入比率の向上

**ビジネス・ケース [#l53ecacc]

**ベネフィット・マップ [#ed461699]
オープン・アーキテクチャ

***オープン・オープンソース [#z1ae1128]
|コンポーネント|行動変容|ベネフィット|行動変容|戦略目標|h
|OSSの利用|||||
|自身のOSS化|||||
|OSSスタックに乗る|||||

***オープン・スタンダード [#dce6666d]
|コンポーネント|行動変容|ベネフィット|行動変容|戦略目標|h
|REST|||||
|SAML2|||||
|OAuth2/OIDC|||||

*参考 [#l69c62c6]

**プログラム・マネジメントで生成された[[コンセプト]] [#z89b3c17]

**.NET 開発基盤部会 Wiki [#a46bc273]

***[[組織的プロジェクト・マネジメント(OPM)>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?PMP%EF%BC%9A%E5%85%B1%E9%80%9A%20-%20%E7%B5%84%E7%B9%94%E7%9A%84%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%83%BB%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88%EF%BC%88OPM%EF%BC%89]] [#g1f26077]

-[[ポートフォリオ・マネジメント>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?PMP%EF%BC%9A%E5%85%B1%E9%80%9A%20-%20OPM%20-%20%E3%83%9D%E3%83%BC%E3%83%88%E3%83%95%E3%82%A9%E3%83%AA%E3%82%AA%E3%83%BB%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88]]

-[[プログラム・マネジメント>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?PMP%EF%BC%9A%E5%85%B1%E9%80%9A%20-%20OPM%20-%20%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0%E3%83%BB%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88]]

***[[ステークホルダー・エンゲージメント・マネジメント>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?PMP%EF%BC%9A%E5%85%B1%E9%80%9A#qac125bd]] [#e9f4fb97]

**OSSコンソーシアム [#d1b65b67]

***2018年度 第3, 4Q 投稿記事とWikiアクセス・カウントまとめ [#g887b195]
2018年度 第3, 4Q は「サプライサイド・デマンドサイド対立」を分析してみました。

https://www.osscons.jp/jog2ubp4p-537/#_537

***組織的プロジェクトマネジメント(OPM)関連 [#ae89481f]
-ステークホルダーも納得するポートフォリオ・プログラムを再定義する。 ~
https://www.osscons.jp/joz2vckgh-537/

-組織的プロジェクトマネジメント(OPM)について考える。~
https://www.osscons.jp/joyxvre8h-537/

-ポートフォリオを読みプログラムを造り込む準備をする。~
https://www.osscons.jp/jo6hgeb0j-537/

-組織的プロジェクトマネジメント(OPM)に関する現時点の問題点。~
https://www.osscons.jp/jol4hhbjg-537/

-QCDよりベネフィット。プログラム・マネジメントの必要性
--(前編)~
https://www.osscons.jp/jo9mda53s-537/
--(後編)~
https://www.osscons.jp/jo7lzgvc1-537/

トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS