「Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
開発基盤のプログラム・マネジメントの際の注意点。
- 事業ポートフォリオから
乖離しないようにプログラムを作成する。
- 以下に注意して、
- 個々のプロジェクトを組立る。
- そして、プログラム・マネジメントする。
方針 †
ポートフォリオ †
事業ポートフォリオに合わせて個々のプロジェクトをプログラムする。
オープン or クローズド †
- 利用するモノと開発するモノがある。
- 何を利用し、何を開発する（≒どのような価値を生む）か？明確にする。
オープン †
主に利用するモノ。
- OSSであれば、ライセンス・フィー無しで利用できる。
（ただし、付帯費用が発生するケースがある）
- 特に、言語やプラットフォームは、オープンな技術である方が、
ライセンス（使用許諾）などに縛られず組み合わせられる。
クロースド †
主に独自開発するモノ。
- オープンなモノを利用するダケでは差別化不可能（ネットの情報で良い）。
- クロースドな要素（≒独自性の有るコンテンツ力）がどこかしらに必要になる。
- オープンなモノを組み立てて独自性があるモノにする。
- クローズドにする（マネタイズするにはイイが開発基盤には適合しない）。
- クロースドなモノより、オープンなモノの方が利用させ易い。
単独でマネタイズできない開発基盤は開示した方がイイ。
要素 †
以下のような要素を準備した上で組み立てる。
言語やプラットフォーム（オープン） †
- コモディティであるため、シェアが重要。
- 実際の組み立ての際は、STPの見極めが必要。
言語 †
シェア - .NET 開発基盤部会 Wiki > 言語
プラットフォーム †
シェア - .NET 開発基盤部会 Wiki > OS, クライアント, サーバ, プラットフォーマー
独自性の有るコンテンツ力（クローズド） †
ライブラリ、フレームワーク → テンプレート †
- テンプレートとパッケージ・マネージャを使用して、
スタックを組んで、TODOコメントを提供する。
- ライブラリ、フレームワークは、
テンプレートの機能強化によって出来上がる。
- 例
- 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]")
