「Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
開発基盤のプログラム・マネジメントの際の注意点。
- 事業ポートフォリオから乖離しないようにプログラムを作成する。
- 以下に注意して、
- 個々のプロジェクトを組立る。
- そして、マネジメントする。
方針 †
オープン †
主に利用するもの。
- OSSであれば、ライセンス・フィー無しで利用できる。
（ただし、付帯費用が発生するケースがある）
- 特に、言語やプラットフォームは、オープンな技術である方が、
ライセンス（使用許諾）などに縛られず組み合わせられる。
クロースド †
主に独自開発するもの。
- オープンなものを利用するダケでは差別化不可能（ネットの情報で良い）。
- クロースドな要素（≒独自性の有るコンテンツ力）がどこかしらに必要になる。
- オープンなものを組み立てて独自性があるものにする。
- クローズドにする（マネタイズするにはイイが開発基盤には適合しない）。
オープン、クロースド †
言語やプラットフォーム（オープン） †
言語 †
シェア - .NET 開発基盤部会 Wiki > 言語
プラットフォーム †
シェア - .NET 開発基盤部会 Wiki > OS, クライアント, サーバ, プラットフォーマー
独自性の有るコンテンツ力（クローズド） †
コンテンツ力が必要になる。
業務パッケージ †
テンプレート †
テンプレートとパッケージ・マネージャを使用して、
スタックを組んで、TODOコメントを提供する。
- Asakusa Framework
- Open Touryo
ランタイム、ライブラリ、フレームワーク †
テンプレートの機能強化によって出来上がる。
- opensource COBOL
- Asakusa Framework
- Open Touryo
ドキュメント †
インターネットに書いた方がイイ（イントラは誰も見ない）。
ノウハウ（遂行能力 †
- メリット
- 更なる差別化が必要になる場合、ノウハウ（遂行能力）で差別化が可能。
- マネタイズ・レベル可能になる（が、開発基盤にはむしろマイナス）。
- デメリット
- 暗黙知に近いと、文書化し難いので、オープンにし難い。
- 依存度が高いと、セルフサポート化が難しくなる。
組立 †
パターン †
スタック †
上位と下位のスタックを組み立てる。
- アプリケーションの場合
プラットフォーム → ランタイム → ライブラリ → フレームワーク
- インフラストラクチャーの場合
ホスト → ゲスト → コンテナ（docker） → コンテナ・イメージ（docker image）
上位・下位にズレると専門外になるので、組合わせに専門家間での連携が必要になる。
（ただ、単純に乗るケースも多いので、１ユーザとして使用するダケで済む場合も多い）
※ 昨今、オープンなものは、大概、上下スタックは出来るようになってきた。
（独自性が低く、施策の必要条件ではあるが十分条件では無くなって来ている）。
コラボレーション †
- 同じレイヤで横の繋がりを意識する。
- 繋ぎ目は、オープンなプロトコルである必要がある（HTTP、JSON、OAuth2, etc.）
- スタックは単純に上に乗るが、コラボレーションはカナリ意図的に組み合わせる必要がある。
- 同じレイヤ内なので、当該レイヤ内でかなり詳しくならないと「差別化可能な組み合わせ」に到達しない。
- ビッグデータ
- ストレージ
NoSQL
データレイク
データマート
- EAI/ETL
- 分散処理
- 業務パッケージ
ありものの業務パッケージでソリューションを構築。
前提 †
- Visual Studio + ASP.NET
プロフェッショナル・ツール
- セグメント＆ターゲットを見誤ると各プロジェクトの
成果物がベネフィットを生まないので注意する。
- ニーズはあってもポジショニングが取れないと言うのは、
既存事業的に優位なポジション取りが出来ないケース。
- クラウドポータル
- Open PaaS
- , etc.
必要となるモチベーションやAS-IS †
例えば、
- 開発基盤は、先ずは、自社事業の治工具として出てくる（自社事業への貢献）。
- OAuth2の習得には、SaaS開発したいというモチベーションが必要だった。
- ビッグデータを勉強するには、AS-ISでデータ分析業務が必要と思われる。
制度設計の重要性 †
- プログラムとして組み立てて
- プロジェクト同士が互いに争わないようにする。
- プロジェクトが自律的にスタック＆コラボレーションするようにする。
- 自助努力で伸びない数値をKPIに設定しない。
若しくは、KPIが伸びない組織の環境要因を取り除く。
- ベネフィットを伸ばさず、KPIだけが
「数値的に」伸びる工夫がされていないか監視する。
参考 †
.NET 開発基盤部会 Wiki †
OSSコンソーシアム †
2018年度 第3, 4Q 投稿記事とWikiアクセス・カウントまとめ †
2018年度 第3, 4Q は「サプライサイド・デマンドサイド対立」を分析してみました。
https://www.osscons.jp/jog2ubp4p-537/#_537
組織的プロジェクトマネジメント（OPM）関連 †
- QCDよりベネフィット。プログラム・マネジメントの必要性
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
