「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
- 分散処理
- 業務パッケージ
ありものの業務パッケージでソリューションを構築。
組立のポイント †
そもそも、ビジネス・ニーズからブレークダウンすればあまり考えなくてイイ事だが、
組織都合から施策（プロジェクト）がスタートしている場合は、組立に注意が必要。
組織都合をベースにしない †
組織都合の例
- 組織のミッションを達成しているというアリバイ工作のようなメトリクス（KPI）
- 予算認可にのみフォーカスする
（ベネフィットにコミットしない）
- 予算の付き易いBuzzWord?狙い。
- カタストロフィ狙い。
ポートフォリオとの整合性 †
- 例
- 事業ポートフォリオ
- デジタル・マーケティング
- スマート・マニュファクチャリング
- ワークスタイル変革の促進
- ビジネスデータの活用・促進
- 位置情報のデータ活用
- コネクテッド・モビリティ
- トータル・セキュリティ
- 開発基盤のポートフォリオ
- インフラストラクチャ
- 言語、IDE（統合開発環境）
- テンプレ＆パッケージ
- その他、各種要素技術
実際にあるビジネス・ニーズに、自身が応えることが出来るか？と言う事。
- Visual Studio + ASP.NET
プロフェッショナル・ツール
- Microsoft PowerApps?
EUC(End User Computing)ツール
- 手段の目的化などでセグメント＆ターゲットを見誤ると
各プロジェクトの成果物がベネフィットを生まないので注意する。
- ビジネス・ニーズはあってもポジショニングが取れないと言うのは、
既存事業的、若しくは、能力的に、優位なポジション取りが出来ないケース。
- 例
- クラウドポータル
- Open PaaS
- , etc.
スポンサーシップ、モチベーション †
AS-IS -> TO-BE（スポンサーシップ、モチベーション）が、
前述のポジショニング（STの次のP）のために重要になる。
- 例
- 開発基盤
- 開発基盤は、先ずは、自社事業の治工具として出てくる（自社事業への貢献）。
- OAuth2の習得には、SaaS開発したいというモチベーションが必要だった。
- 全体的に、ボトムアップでスポンサーシップが弱いのが日式。
- ビッグデータ
- ビッグデータを勉強するには、AS-ISでデータ分析業務が必要と思われる。
ガバナンス構造の確立と活動 †
プログラムとプロジェクトが、戦略目標と整合性維持し、正確に評価されるようにする必要がある。
- 戦略目標との整合性維持と監視・制御の活動
- プロジェクト同士が互いに争わないようにする。
- プロジェクトが自律的にスタック＆コラボレーションするようにする。
- 自助努力で伸びない数値をメトリクス（KPI）に設定しない。
若しくは、メトリクス（KPI）が伸びない組織の環境要因を取り除く。
- ベネフィットを伸ばさず、メトリクス（KPI）だけが
「数値的に」伸びる工夫がされていないか監視する。
ツールと技法の利用 †
プログラム・マネジメントのツールと技法を使用して、
ビジネス・ニーズからベネフィット・マップへの落とし込む。
- シーズ（種）
- > ニーズ（想い）
- > ウォンツ（意欲）
- > デマンド（需要）
- > ベネフィット（提供された価値）
ビジネス・ニーズ †
ニーズ †
開発基盤のオープン化が必要
- オープン・アーキテクチャ
- オープン・スタンダード
- オープン・ソースソフトウェア
背景 †
- ロックインされない
- ポータビリティ（可搬性）
- インターオペラビリティ（相互運用可能性）
- 費用の軽減
- 初期投資費用の軽減
- その後のサポートサービスとの契約締結も可能
- 様々なプラットフォームをサポート可能
- 様々なディストリビューション上でスタック可能。
- 様々なシステムとコラボレーション可能。
戦略目標とベネフィット †
戦略目標 †
「顧客が望む」、オープン化に対応できるよう、開発基盤を変更する。
- オープン・アーキテクチャ
- オープン・スタンダード
- オープンソース・ソフトウェア
ベネフィット †
- 生産性の向上
基盤化によるナレッジの高集積化
- WikiやQiitaでは集積密度は低い。
- 最低限、テンプレート化が必要。
- 可能であれば、ライブラリ化、フレームワーク化し、
パッケージ・マネージャーへ登録できると、尚良。
- クラウド、スマホ環境のサポート
- 様々なディストリビューション上でスタック可能。
- 様々なシステムとコラボレーション可能。
↓ ↓ ↓
- 魅力的な品質を持つプロダクトは更なる好循環を生む。
ビジネス・ケース †
前提条件 †
- オープン・スタンダード＆オープンソース・ソフトウェア縛り
- 行動変容はプロダクトの品質次第となる（魅力的な品質を持つプロダクトが必要になる）。
制約条件 †
- 各種リソース面はコミュニティからとなる
- マネタイズは困難（昨今、OSSはサービサーが必要な設備として開発するケースが多い）
リスク †
- 脅威
- 連携OSSコミュニティ・プロダクトの破綻
- 採用オープン・スタンダードのダウン・トレンド
- プロダクト品質が上がらない（オレオレ・フレームワークのレベルを脱しない）
- 好機
- .NET5の登場（.NET Coreのメインストリーム化）
- WebAPI、SAML2、OAuth2 / OIDC のアップ・トレンド
- 一般的な対応計画
状況をOODA的にウォッチし迅速にピボットする。
費用/財務 †
OSSコミュニティで実施
投資収益率（ROI） †
－
市場分析 †
- OSSがデファクト・スタンダード（.NET 5 の登場）
- クラウド・スマホのビジネス・ニーズは高まっている。
競合分析 †
- 某ペイの状況などを見ると酷い有様。
- ある意味、日式エッスアイの限界
組織の検討事項 †
技術情報開示決裁
プログラム記述 †
- Open棟梁の.NET 5 対応
- WebAPI、SAML2、OAuth2 / OIDC / FAPIサポート
- GUI開発スタックにNode.jsを採用
- IoT、ビッグデータ、AI分野への進出
実行計画 †
ベネフィット・マップ
ベネフィット・マップ †
オープン・アーキテクチャ化 †
- オープンソース・ソフトウェア
| コンポーネント | 行動変容 | ベネフィット | 行動変容 | プログラム目標 |
| OSSの利用 | ---(開発 / 利用)---> | 生産性向上、迅速に最新技術へ追随 | ---(活用の拡大)---> | 「顧客が望む」、オープン化（オープンソース・ソフトウェア）に対応 |
| 自身のOSS化 | 個別契約不要、ロックイン無しの安心感 |
| OSSスタックに乗る | 様々なディストリビューション上でスタック可能。 |
- オープン・スタンダード
| コンポーネント | 行動変容 | ベネフィット | 行動変容 | プログラム目標 |
| REST WebAPI | ---(開発 / 利用)---> | 様々なシステムとコラボレーション可能。 | ---(活用の拡大)---> | 「顧客が望む」、オープン化（オープン・スタンダード）に対応 |
| SAML2 | ・クロスドメイン認証１ |
| OAuth2 / OIDC | ・クロスドメイン認証２ |
某弊開発基盤 †
- Open棟梁の.NET 5 対応
- ベネフィット：フロントエンド、バックエンドのWrite once, Run anywhere化
- プログラム目標：生産性の向上、更なる好循環を生む。
- WebAPI、SAML2、OAuth2 / OIDC / FAPIサポート
- ベネフィット：様々なシステム間連携を実現する。
- プログラム目標：クラウド、スマホ環境のサポート、生産性の向上
- GUI開発スタックにNode.jsを採用
- ベネフィット：フロントエンドのWrite once, Run anywhere化
- プログラム目標：クラウド、スマホ環境のサポート、生産性の向上
- IoT、ビッグデータ、AI分野への進出
- ベネフィット：トランスフォーメーションの促進
- プログラム目標：日式エッスアイ（項目移送おじさん）事業のシュリンクに伴う出口戦略を提供
| コンポーネント | 行動変容 | ベネフィット | 行動変容 | プログラム目標 |
| Open棟梁の.NET 5 対応 | ---(開発 / 利用)---> | フロントエンド、バックエンドのWrite once, Run anywhere化 | ---(活用の拡大)---> | ・生産性の向上
・クラウド、スマホ環境のサポート
・更なる好循環を生む。 |
| WebAPI、SAML2、OAuth2 / OIDC / FAPIサポート | 様々なシステム間連携を実現する。 |
| GUI開発スタックにNode.jsを採用 | フロントエンドのWrite once, Run anywhere化 |
| IoT、ビッグデータ、AI分野への進出 | トランスフォーメーションの促進 | 日式エッスアイ（項目移送おじさん）事業のシュリンクに伴う出口戦略を提供 |
実行と終結 †
ガバナンス構造の確立と、監視・制御 †
- メトリクス（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]")
