- 追加された行はこの色です。
- 削除された行はこの色です。
「[[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/