OTR_DevInfraProgramManagement

開発基盤のプログラム・マネジメント

• TOP > マーケティング > 開発基盤とは > 開発基盤のプログラム・マネジメント

概要

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

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

詳細

方針

ポートフォリオ

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

オープン or クローズド

何を利用し、何を開発する（≒ どのような価値を生む）かを明確にする。

区分	主に	内容
オープン	利用するモノ	コモディティ。内製する意味が無いモノ。言語やプラットフォームは、オープンな方がライセンスに縛られず組み合わせられる
クローズド	独自開発するモノ	オープンなモノを利用するだけでは差別化できない。独自性の有るコンテンツ力がどこかに必要

• クローズドなモノより、オープンなモノの方が利用させやすい。
  単独でマネタイズできない開発基盤は、開示した方がよい（Open 棟梁が OSS である理由）。

要素

要素	性質	内容
言語・プラットフォーム	オープン	コモディティなので、シェアが重要
ライブラリ・フレームワーク → テンプレート	クローズド（独自性）	テンプレートとパッケージ・マネージャーでスタックを組み、TODO コメントを提供する。ライブラリ・フレームワークはテンプレートの機能強化で出来上がる（例：Open 棟梁、Asakusa Framework）
ドキュメント（形式知）	—	インターネットに書いた方がよい（イントラは誰も見ない）
ノウハウ（暗黙知）	—	遂行能力として差別化できるが、文書化しにくく、依存度が高いとセルフサポート化が難しい
業務パッケージ	—	自ら開発するか、ソリューションの一角として利用するか（昨今は後者が増えている）

「テンプレートで TODO コメントを提供する」は、コーディング・エージェントの時代には
「エージェントが埋めるスロットを提示する」ことと同じ意味になる（コーディング・エージェント時代の開発基盤）。
暗黙知をスキルや AGENTS.md として形式知化すると、セルフサポート化の難しさも緩和できる。

組立

スタック（前提）

• アプリケーション：プラットフォーム → ランタイム → ライブラリ → フレームワーク
• インフラストラクチャ：ホスト → ゲスト → コンテナ → コンテナ・イメージ
• 昨今、オープンなものは大概スタックできるようになった。
  スタックは施策の必要条件ではあるが、十分条件ではなくなっている。

コラボレーション（差別化）

• 同じレイヤで横の繋がりを意識する。繋ぎ目は、オープンなプロトコル（HTTP、JSON、OAuth2 など）である必要がある。
• スタックは単純に上に乗るが、コラボレーションは意図的に組み合わせる必要があり、
  当該レイヤにかなり詳しくならないと「差別化可能な組み合わせ」に到達しない。
• 例：フロントエンド＋OAuth2＋バックエンド、IoT / ビッグデータ / AI、業務パッケージを組み合わせたソリューション。

組立のポイント

• 組織都合をベースにしない：アリバイ作りのメトリクス、手段の目的化、予算の付きやすい BuzzWord 狙いなど。
• ポートフォリオとの整合性を維持する。
• STP を見極める：実際にあるビジネス・ニーズに、自分が応えられるか。
  自動生成・テスト自動化・CI/CD なども、セグメントとターゲットを見誤ると、ベネフィットを生まない。
• モチベーション、スポンサーシップ：ポジションを取るには魅力的な品質が必要で、そのためにはモチベーションとスポンサーシップが要る。
  開発基盤は、まず自社事業の治工具として出てくる。
• ガバナンス構造の確立と活動：プロジェクト同士が争わず、自律的にスタック＆コラボレーションするようにする。
  メトリクス（KPI）を悪用できないものにし、ベネフィットを適切に測定する（開発基盤のKPIとKGI）。

ビジネス・ニーズからベネフィットへ

シーズ → ニーズ → ウォンツ → デマンド → ベネフィット と落とし込む。

• ニーズ：開発基盤のオープン化（オープン・アーキテクチャ、オープン・スタンダード、オープンソース・ソフトウェア）。
  • 背景：ロックインされない（ポータビリティ、インターオペラビリティ）、費用の軽減、様々なプラットフォームのサポート。
• 戦略目標：顧客・ユーザが望むオープン化に対応できるよう、開発基盤を変更する。
• ベネフィット
  • 基盤化によるナレッジの高集積化（Wiki やブログでは集積密度が低い。最低限テンプレート化、できればライブラリ化してパッケージ・マネージャーへ登録）。
  • クラウド・スマホ環境のサポート。
  • 魅力的な品質を持つプロダクトは、受注貢献・導入比率の向上という好循環を生む。

Open 棟梁でのプログラム

Open 棟梁では、このプログラム・マネジメントから次のプログラムを実施してきた。

プログラム	ベネフィット	状況（2026 年 10 月時点）
.NET（旧 .NET Core / .NET 5）対応	フロントエンド・バックエンドの Write once, Run anywhere 化	.NET 10.0 に対応
WebAPI、SAML2、OAuth2 / OIDC / FAPI のサポート	様々なシステム間連携の実現	汎用認証サイトとして提供
クラウド / スマホ、IoT / ビッグデータ / AI 分野への進出	トランスフォーメーションの促進	コンセプト V3（DX 開発基盤）として整理
コーディング・エージェント対応	開発基盤の処理方式を、エージェントの作業手順として配布する	AGENTS.md・領域ごとの ANALYSIS.md・エージェント用スキルを整備

実行と終結

• メトリクス（KPI）を設定し、測定し、監視・制御する。
• サポートとメンテナンスの移管：セルフ・サポート化の達成、保守フェーズのコミュニティへの移管。

参考

• コンセプト（このプログラム・マネジメントで生成されたコンセプト）
• PMP：共通 - 組織的プロジェクト・マネジメント（OPM）
  • ポートフォリオ・マネジメント
  • プログラム・マネジメント
  • プログラム・ライフサイクル
• スタック＆コラボレーション
• OSSコンソーシアム 開発基盤部会 Blog
  • PMP視点で見る開発基盤開発プロジェクトのマネジメントについて。
  • プログラム・マネジメントについて書いてみた。 開発基盤編
  • 自出を知ればプロダクトのコンセプトが見えて来る。的な。

---

Tags: 再構築