「[[Open棟梁 wiki>https://opentouryo.osscons.jp]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>開発基盤とは]] *目次 [#gf3b084e] #contents *概要 [#e76b9bfb] 開発基盤のプログラム・マネジメントの際の注意点。 -事業ポートフォリオから乖離しないように[[プログラム>#reb6b28f]]を作成する。 -以下に注意して、 --個々のプロジェクトを組立る。 --そして、マネジメントする。 *方針 [#h7ce5259] **オープン [#n24db47a] 主に利用するもの。 -コモディティ。内製する意味が無いもの。 -利用する分には、オープンなものの方がイイ。 --OSSであれば、ライセンス・フィー無しで利用できる。~ (ただし、付帯費用が発生するケースがある) --特に、[[言語やプラットフォーム>#wfc693dd]]は、オープンな技術である方が、~ ライセンス(使用許諾)などに縛られず組み合わせられる。 **クロースド [#i7d00014] 主に独自開発するもの。 -オープンなものを利用するダケでは差別化不可能(ネットの情報で良い)。 -クロースドな要素(≒[[独自性の有るコンテンツ力>#hb719a93]])がどこかしらに必要になる。 --オープンなものを組み立てて独自性があるものにする。 --クローズドにする(マネタイズするにはイイが開発基盤には適合しない)。 *オープン、クロースド [#o1b6d980] **言語やプラットフォーム(オープン) [#wfc693dd] ***言語 [#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] コンテンツ力が必要になる。 ***業務パッケージ [#k33bcd8c] -MosP -Pleasanter ***テンプレート [#mbb16b85] テンプレートとパッケージ・マネージャを使用して、~ スタックを組んで、TODOコメントを提供する。 -Asakusa Framework -Open Touryo ***ランタイム、ライブラリ、フレームワーク [#b0c7be01] テンプレートの機能強化によって出来上がる。 -opensource COBOL -Asakusa Framework -Open Touryo ***ドキュメント [#c3026b45] インターネットに書いた方がイイ(イントラは誰も見ない)。 ***ノウハウ(遂行能力 [#x94d62c4] -メリット --更なる差別化が必要になる場合、ノウハウ(遂行能力)で差別化が可能。 --マネタイズ・レベル可能になる(が、開発基盤にはむしろマイナス)。 -デメリット --暗黙知に近いと、文書化し難いので、オープンにし難い。 --依存度が高いと、セルフサポート化が難しくなる。 *組立 [#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だけが~ 「数値的に」伸びる工夫がされていないか監視する。 *参考 [#l69c62c6] **.NET 開発基盤部会 Wiki [#a46bc273] ***[[ステークホルダー・エンゲージメント・マネジメント>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?PMP%EF%BC%9A%E5%85%B1%E9%80%9A#qac125bd]] [#e9f4fb97] ***[[組織的プロジェクト・マネジメント(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]] **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/