「Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
開発基盤のプログラム・マネジメントの際の注意点。
- 事業ポートフォリオから
乖離しないようにプログラムを作成する。
- 以下に注意して、
- 個々のプロジェクトを組立る。
- そして、プログラム・マネジメントする。
方針 †
ポートフォリオ †
事業ポートフォリオに合わせて個々のプロジェクトをプログラムする。
オープン or クローズド †
- 利用するモノと開発するモノがある。
- 何を利用し、何を開発する(≒どのような価値を生む)か?明確にする。
オープン †
主に利用するモノ。
- OSSであれば、ライセンス・フィー無しで利用できる。
(ただし、付帯費用が発生するケースがある)
- 特に、言語やプラットフォームは、オープンな技術である方が、
ライセンス(使用許諾)などに縛られず組み合わせられる。
クロースド †
主に独自開発するモノ。
- オープンなモノを利用するダケでは差別化不可能(ネットの情報で良い)。
- クロースドな要素(≒独自性の有るコンテンツ力)がどこかしらに必要になる。
- オープンなモノを組み立てて独自性があるモノにする。
- クローズドにする(マネタイズするにはイイが開発基盤には適合しない)。
- クロースドなモノより、オープンなモノの方が利用させ易い。
単独でマネタイズできない開発基盤は開示した方がイイ。
要素 †
以下のような要素を準備した上で組み立てる。
言語やプラットフォーム(オープン) †
- コモディティであるため、シェアが重要。
- 実際の組み立ての際は、STPの見極めが必要。
言語 †
シェア - .NET 開発基盤部会 Wiki > 言語
プラットフォーム †
シェア - .NET 開発基盤部会 Wiki > OS, クライアント, サーバ, プラットフォーマー
独自性の有るコンテンツ力(クローズド) †
ライブラリ、フレームワーク → テンプレート †
- テンプレートとパッケージ・マネージャを使用して、
スタックを組んで、TODOコメントを提供する。
- ライブラリ、フレームワークは、
テンプレートの機能強化によって出来上がる。
- 例
- Asakusa Framework
- Open Touryo
ランタイム †
ランタイムは毛色が少々異なる。
言語やプラットフォーム(オープン)と対比すると「ニッチ」と言える。
ドキュメント(形式知) †
インターネットに書いた方がイイ(イントラは誰も見ない)。
ノウハウ(暗黙知) †
- メリット
- ノウハウ(暗黙知)≒ 遂行能力
- 更なる差別化が必要になる場合、遂行能力で差別化が可能。
- マネタイズ・レベル可能になる(が、開発基盤にはむしろマイナス)。
- デメリット
- 暗黙知に近いと、文書化し難いので、オープンにし難い。
- 依存度が高いと、セルフサポート化が難しくなる。
業務パッケージ †
- 以下の検討が必要。
昨今、後者が増えている。
- 自分が主体となって開発するか?
- ソリューションの一角として利用するか?
組立 †
パターン †
スタック(前提) †
上位と下位をスタックさせて組み立てる。
- アプリケーションの場合
プラットフォーム → ランタイム → ライブラリ → フレームワーク
- インフラストラクチャーの場合
ホスト → ゲスト → コンテナ(docker) → コンテナ・イメージ(docker image)
上位・下位にズレると専門外になるので、組合わせに専門家間での連携が必要になる。
(ただ、単純に乗るケースも多いので、1ユーザとして使用するダケで済む場合も多い)
※ 昨今、オープンなものは、大概、スタックは出来るようになってきた。
(スタックすること自体は独自性が低く、施策の必要条件ではあるが十分条件では無くなって来ている)。
コラボレーション(差別化) †
- 同じレイヤで横の繋がりを意識する。
- 繋ぎ目は、オープンなプロトコルである必要がある(HTTP、JSON、OAuth2, etc.)
- スタックは単純に上に乗るが、コラボレーションはカナリ意図的に組み合わせる必要がある。
- 同じレイヤ内なので、当該レイヤ内でかなり詳しくならないと「差別化可能な組み合わせ」に到達しない。
- ビッグデータ
- ストレージ
NoSQL
データレイク
データマート
- EAI/ETL
- 分散処理
- 業務パッケージ
ありものの業務パッケージでソリューションを構築。
組立のポイント †
実際にあるニーズに、自身が応えることが出来るか?と言う事。
- Visual Studio + ASP.NET
プロフェッショナル・ツール
- セグメント&ターゲットを見誤ると各プロジェクトの
成果物がベネフィットを生まないので注意する。
- ニーズはあってもポジショニングが取れないと言うのは、
既存事業的に優位なポジション取りが出来ないケース。
- 例
- クラウドポータル
- Open PaaS
- , etc.
必要となるモチベーションやAS-IS †
前述のポジショニングのために重要になる。
- 開発基盤は、先ずは、自社事業の治工具として出てくる(自社事業への貢献)。
- OAuth2の習得には、SaaS開発したいというモチベーションが必要だった。
- ビッグデータを勉強するには、AS-ISでデータ分析業務が必要と思われる。
制度設計の重要性 †
プログラムを構成する個々のプロジェクトが
正確に評価されるようにする必要がある。
- プログラムとして組み立てて
- プロジェクト同士が互いに争わないようにする。
- プロジェクトが自律的にスタック&コラボレーションするようにする。
- 自助努力で伸びない数値をKPIに設定しない。
若しくは、KPIが伸びない組織の環境要因を取り除く。
- ベネフィットを伸ばさず、KPIだけが
「数値的に」伸びる工夫がされていないか監視する。
ツールと技法の利用 †
プログラム・マネジメントのツールと技法を使用して、
ビジネス・ニーズからベネフィット・マップへの落とし込む。
- シーズ(種)
- > ニーズ(想い)
- > ウォンツ(意欲)
- > デマンド(需要)
- > ベネフィット(提供された価値)
ビジネス・ニーズ †
ニーズ †
開発基盤のオープン化が必要
- オープン・アーキテクチャ
- オープン・スタンダード
- オープン・ソースソフトウェア
背景 †
- ロックインされない
- ポータビリティ(可搬性)
- インターオペラビリティ(相互運用可能性)
- 費用の軽減
- 初期投資費用の軽減
- その後のサポートサービスとの契約締結も可能
- 様々なプラットフォームをサポート可能
- 様々なディストリビューション上でスタック可能。
- 様々なシステムとコラボレーション可能。
戦略目標とベネフィット †
戦略目標 †
「顧客が望む」、オープン化に対応できるよう、開発基盤を変更する。
- オープン・アーキテクチャ
- オープン・スタンダード
- オープンソース・ソフトウェア
ベネフィット †
- 生産性の向上
基盤化によるナレッジの高集積化
- WikiやQiitaでは集積密度は低い。
- 最低限、テンプレート化が必要。
- 可能であれば、ライブラリ化、フレームワーク化し、
パッケージ・マネージャーへ登録できると、尚良。
- クラウド、スマホ環境のサポート
- 様々なディストリビューション上でスタック可能。
- 様々なシステムとコラボレーション可能。
↓ ↓ ↓
ビジネス・ケース †
前提条件 †
- オープン・スタンダード&オープンソース・ソフトウェア縛り
- 行動変容はプロダクトの品質次第となる(高品質なプロダクトが必要になる)。
制約条件 †
- 各種リソース面はコミュニティからとなる
- マネタイズは困難(昨今、OSSはサービサーが必要な設備として開発するケースが多い)
リスク †
- 脅威
- 連携OSSコミュニティ・プロダクトの破綻
- 採用オープン・スタンダードのダウン・トレンド
- プロダクト品質が上がらない(オレオレ・フレームワークのレベルを脱しない)
- 好機
- .NET5の登場(.NET Coreのメインストリーム化)
- WebAPI、SAML2、OAuth2 / OIDC のアップ・トレンド
- 一般的な対応計画
状況をOODA的にウォッチし迅速にピボットする。
費用/財務 †
OSSコミュニティで実施
投資収益率(ROI) †
-
市場分析 †
- OSSがデファクト・スタンダード(.NET5の登場)
- クラウド・スマホのニーズは高まっている。
競合分析 †
- 某ペイの状況などを見ると酷い有様。
- ある意味、日式エッスアイの限界
組織の検討事項 †
技術情報開示決裁
プログラム記述 †
- Open棟梁の.NET5 対応
- WebAPI、SAML2、OAuth2 / OIDC / FAPIサポート
- GUI開発スタックにNode.jsを採用
- IoT、ビッグデータ、AI分野への進出
実行計画 †
ベネフィット・マップ
ベネフィット・マップ †
オープン・アーキテクチャ化 †
- オープンソース・ソフトウェア
コンポーネント | 行動変容 | ベネフィット | 行動変容 | プログラム目標 |
OSSの利用 | ---(開発/利用)---> | 生産性向上、迅速に最新技術へ追随 | ---(活用の拡大)---> | 「顧客が望む」、オープン化(オープンソース・ソフトウェア)に対応 |
自身のOSS化 | 個別契約不要、ロックイン無しの安心感 |
OSSスタックに乗る | 様々なディストリビューション上でスタック可能。 |
- オープン・スタンダード
コンポーネント | 行動変容 | ベネフィット | 行動変容 | プログラム目標 |
REST WebAPI | ---(開発/利用)---> | 様々なシステムとコラボレーション可能。 | ---(活用の拡大)---> | 「顧客が望む」、オープン化(オープン・スタンダード)に対応 |
SAML2 | ・クロスドメイン認証1 |
OAuth2 / OIDC | ・クロスドメイン認証2 |
某弊開発基盤 †
- Open棟梁の.NET5 対応
- ベネフィット:フロントエンド、バックエンドのWrite once, Run anywhere化
- プログラム目標:生産性の向上、更なる好循環を生む。
- WebAPI、SAML2、OAuth2 / OIDC / FAPIサポート
- ベネフィット:様々なシステム間連携を実現する。
- プログラム目標:クラウド、スマホ環境のサポート、生産性の向上
- GUI開発スタックにNode.jsを採用
- ベネフィット:フロントエンドのWrite once, Run anywhere化
- プログラム目標:クラウド、スマホ環境のサポート、生産性の向上
- IoT、ビッグデータ、AI分野への進出
- ベネフィット:トランスフォーメーションの促進
- プログラム目標:日式エッスアイ(項目移送おじさん)事業のシュリンクに伴う出口戦略を提供
コンポーネント | 行動変容 | ベネフィット | 行動変容 | プログラム目標 |
Open棟梁の.NET5 対応 | ---(開発/利用)---> | フロントエンド、バックエンドのWrite once, Run anywhere化 | ---(活用の拡大)---> | ・生産性の向上 ・クラウド、スマホ環境のサポート ・更なる好循環を生む。 |
WebAPI、SAML2、OAuth2 / OIDC / FAPIサポート | 様々なシステム間連携を実現する。 |
GUI開発スタックにNode.jsを採用 | フロントエンドのWrite once, Run anywhere化 |
IoT、ビッグデータ、AI分野への進出 | トランスフォーメーションの促進 | 日式エッスアイ(項目移送おじさん)事業のシュリンクに伴う出口戦略を提供 |
ガバナンス構造の確立と、監視・制御 †
サポートとメンテナンスの移管 †
- セルフ・サポート化の達成
- 保守フェーズをコミュニティへ移管
参考 †
プログラム・マネジメントで生成されたコンセプト †
.NET 開発基盤部会 Wiki †
OSSコンソーシアム †
2018年度 第3, 4Q 投稿記事とWikiアクセス・カウントまとめ †
2018年度 第3, 4Q は「サプライサイド・デマンドサイド対立」を分析してみました。
https://www.osscons.jp/jog2ubp4p-537/#_537
組織的プロジェクトマネジメント(OPM)関連 †
- QCDよりベネフィット。プログラム・マネジメントの必要性