Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

開発基盤のプログラム・マネジメントの際の注意点。

  • 事業ポートフォリオから
    乖離しないようにプログラムを作成する。
  • 以下に注意して、
    • 個々のプロジェクトを組立る。
    • そして、プログラム・マネジメントする。

方針

ポートフォリオ

事業ポートフォリオに合わせて個々のプロジェクトをプログラムする。

オープン or クローズド

  • 利用するモノと開発するモノがある。
  • 何を利用し、何を開発する(≒どのような価値を生む)か?明確にする。

オープン

主に利用するモノ。

  • コモディティ。
  • 内製する意味が無いモノ。
  • 利用する分には、オープンなモノの方がイイ。
  • OSSであれば、ライセンス・フィー無しで利用できる。
    (ただし、付帯費用が発生するケースがある)
  • 特に、言語やプラットフォームは、オープンな技術である方が、
    ライセンス(使用許諾)などに縛られず組み合わせられる。

クロースド

主に独自開発するモノ。

  • オープンなモノを利用するダケでは差別化不可能(ネットの情報で良い)。
  • クロースドな要素(≒独自性の有るコンテンツ力)がどこかしらに必要になる。
    • オープンなモノを組み立てて独自性があるモノにする。
    • クローズドにする(マネタイズするにはイイが開発基盤には適合しない)。
  • クロースドなモノより、オープンなモノの方が利用させ易い。
    単独でマネタイズできない開発基盤は開示した方がイイ。

要素

以下のような要素を準備した上で組み立てる。

言語やプラットフォーム(オープン)

  • コモディティであるため、シェアが重要。
  • 実際の組み立ての際は、STPの見極めが必要。

言語

シェア - .NET 開発基盤部会 Wiki > 言語

プラットフォーム

シェア - .NET 開発基盤部会 Wiki > OS, クライアント, サーバ, プラットフォーマー

独自性の有るコンテンツ力(クローズド)

ライブラリ、フレームワーク → テンプレート

  • 技術分野毎に開発され得る。
  • テンプレートとパッケージ・マネージャを使用して、
    スタックを組んで、TODOコメントを提供する。
  • ライブラリ、フレームワークは、
    テンプレートの機能強化によって出来上がる。
    • Asakusa Framework
    • Open Touryo

ランタイム

ランタイムは毛色が少々異なる。

  • opensource COBOL

言語やプラットフォーム(オープン)と対比すると「ニッチ」と言える。

ドキュメント(形式知)

インターネットに書いた方がイイ(イントラは誰も見ない)。

ノウハウ(暗黙知)

  • メリット
    • ノウハウ(暗黙知)≒ 遂行能力
    • 更なる差別化が必要になる場合、遂行能力で差別化が可能。
    • マネタイズ・レベル可能になる(が、開発基盤にはむしろマイナス)。
  • デメリット
    • 暗黙知に近いと、文書化し難いので、オープンにし難い。
    • 依存度が高いと、セルフサポート化が難しくなる。

業務パッケージ

  • 業務分野毎に開発され得る。
  • MosP
  • Pleasanter
  • 以下の検討が必要。
    昨今、後者が増えている。
    • 自分が主体となって開発するか?
    • ソリューションの一角として利用するか?

組立

パターン

スタック(前提)

上位と下位をスタックさせて組み立てる。

  • アプリケーションの場合
    プラットフォーム → ランタイム → ライブラリ → フレームワーク
  • インフラストラクチャーの場合
    ホスト → ゲスト → コンテナ(docker) → コンテナ・イメージ(docker image)

上位・下位にズレると専門外になるので、組合わせに専門家間での連携が必要になる。
(ただ、単純に乗るケースも多いので、1ユーザとして使用するダケで済む場合も多い)

※ 昨今、オープンなものは、大概、スタックは出来るようになってきた。
(スタックすること自体は独自性が低く、施策の必要条件ではあるが十分条件では無くなって来ている)。

コラボレーション(差別化)

  • 同じレイヤで横の繋がりを意識する。
    • 繋ぎ目は、オープンなプロトコルである必要がある(HTTP、JSON、OAuth2, etc.)
    • スタックは単純に上に乗るが、コラボレーションはカナリ意図的に組み合わせる必要がある。
    • 同じレイヤ内なので、当該レイヤ内でかなり詳しくならないと「差別化可能な組み合わせ」に到達しない。
  • IoT
    • デバイス
    • エッジ
    • クラウド
  • ビッグデータ
    • ストレージ
      NoSQL
      データレイク
      データマート
    • EAI/ETL
    • 分散処理
  • AI
    • ...。
    • ...。
    • ...。
  • 業務パッケージ
    ありものの業務パッケージでソリューションを構築。
    • 財務・会計
    • 勤怠・人給・人財
    • ワークフロー
    • など

組立のポイント

STPの見極め

実際にあるニーズに、自身が応えることが出来るか?と言う事。

  • 上位の方が明確だが、下位のモノにも存在する。
  • 開発ツール(上位)
  • Visual Studio + ASP.NET
    プロフェッショナル・ツール
  • PowerApps?
    EUCツール
  • プラットフォーム(下位)
  • Linux
    サーバー、サービス基盤
  • Windows
    デスクトップ、情報システム部
  • セグメント&ターゲットを見誤ると各プロジェクトの
    成果物がベネフィットを生まないので注意する。
    • テスト自動化
    • CI / CD
  • ニーズはあってもポジショニングが取れないと言うのは、
    既存事業的に優位なポジション取りが出来ないケース。
    • クラウドポータル
    • Open PaaS
    • , etc.
  • 参考
    ...。

必要となるモチベーションやAS-IS

前述のポジショニングのために重要になる。

  • 開発基盤は、先ずは、自社事業の治工具として出てくる(自社事業への貢献)。
  • OAuth2の習得には、SaaS開発したいというモチベーションが必要だった。
  • ビッグデータを勉強するには、AS-ISでデータ分析業務が必要と思われる。

制度設計の重要性

プログラムを構成する個々のプロジェクトが
正確に評価されるようにする必要がある。

  • プログラムとして組み立てて
    • プロジェクト同士が互いに争わないようにする。
    • プロジェクトが自律的にスタック&コラボレーションするようにする。
  • KPIを悪用できるものにしない。
  • ベネフィットを適切に測定できるものにする。
  • 自助努力で伸びない数値をKPIに設定しない。
    若しくは、KPIが伸びない組織の環境要因を取り除く。
  • ベネフィットを伸ばさず、KPIだけが
    「数値的に」伸びる工夫がされていないか監視する。

参考

プログラム・マネジメントで生成されたコンセプト

.NET 開発基盤部会 Wiki

組織的プロジェクト・マネジメント(OPM)

ステークホルダー・エンゲージメント・マネジメント

OSSコンソーシアム

2018年度 第3, 4Q 投稿記事とWikiアクセス・カウントまとめ

2018年度 第3, 4Q は「サプライサイド・デマンドサイド対立」を分析してみました。

https://www.osscons.jp/jog2ubp4p-537/#_537

組織的プロジェクトマネジメント(OPM)関連


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2019-06-20 (木) 10:54:21 (26d)