Skip to content

OTR_KeyMessages

Jump to bottom
nishi_74322014 edited this page Oct 28, 2026 · 2 revisions

訴求メッセージ

概要

マーケティングの主張を、今のトレンド（コーディング・エージェント）と融合させ、
プロモーションで使うメッセージに落とし込む。

訴求するのは、特定のプロダクトの利用ではなく、
リードエンジニアが Open 棟梁のノウハウとコーディング・エージェントを活用して、ソリューションの提供をサポートすることである
（ソリューション提供のサポート）。

詳細

ひとことで言うと

Open 棟梁のノウハウとコーディング・エージェントで、リードエンジニアがソリューションの提供を支えます。

トレンドとの接点

  • コーディング・エージェントの登場で、「コードを書く手」は安くなった。
  • 一方で、エージェントは解空間が広いと「もっともらしいが、方式と違う」コードを書く。
    レビューと手戻りのコストは、むしろ増えやすい。
  • 足りないのは手ではなく、方式を決め、エージェントの出力を揃えるリードエンジニアとノウハウである。
  • 手が安くなったことで、ここ十年コスパが合わずに取り込みが遅れた SoE・SoI の技術も、射程に入ってきた。
  • 標準化フレームワークは、他案件で役立て難いため、技術者に習得を敬遠されてきた（需給の問題）。
    スロットを埋める主体がエージェントになったことで、この需給が変わりつつある
    （標準化フレームワークの習得の需給とコーディング・エージェント）。

メッセージ

主メッセージ（ソリューション）

# メッセージ 根拠
1 リードエンジニア＋ノウハウ＋エージェントで、ソリューションの提供を支える リードエンジニアが方式を決めて書き出し、エージェントが中を埋め、リードエンジニアが検証する（ソリューション提供のサポート）
2 SoR から SoE・SoI まで、守備範囲を広げられる 業務システムに加え、OAuth2 / OIDC アーキテクチャ（汎用認証サイト、FrontendTemplates、Resource Server テンプレート、Docker）、Jupyter 系の AI / BI、クラウド・デプロイ
3 不安定な技術ほど、標準化のノウハウが効く 安定した中核と変化の速い周辺を緩衝層で分ける。追随の手間はエージェントに任せ、方式のブレはノウハウで抑える

裏付けとなるメッセージ（ノウハウ）

# メッセージ 根拠
4 解空間を狭め、エージェントの作業を「スロットを埋める作業」にする P・B・D 層、ベースクラス、処理方式が先に決まっている。開発者（エージェント）は UOC_ メソッドに業務処理だけを書く（コーディング・エージェント時代の開発基盤）
5 人間の現場で 20 年近く鍛えた仕組みが、そのまま効く 2007 年から 100 件以上の SI 案件、オフショア・一括外注で「実装者が誰でも方式がブレない」ことを実証してきた。もともと丸投げ支援ツールとして生まれた（コンセプト）
6 方式は、エージェントが読める形で配布されている AGENTS.md、領域ごとの ANALYSIS.md、処理方式ごとのエージェント用スキル（OpenTouryoCodingAgentAssets）
7 OSS なので、ロックインも DISCON の心配も無い Apache License 2.0。ソース・文書・開発状況が公開されている
8 .NET Framework 4.8 から .NET 10 まで、同じ方式で書ける 既存資産の移行と新規開発を同じ枠組みで扱える（適用効果のマイグレーション・再構築）

習得と体制のメッセージ（需給）

標準化フレームワークの「覚えたがられない」という弱点への答え（標準化フレームワークの習得の需給とコーディング・エージェント）。

# メッセージ 根拠
9 標準化の効果はそのままに、覚える人を絞れる スロットを埋めるのはエージェントで、エージェントには他案件で使えるかどうかの損得が無い。フレームワークを深く理解するのは、方式を決めて検証するリードエンジニア・纏め者に絞れる
10 ノウハウは、人ではなくリポジトリに残る 方式は AGENTS.md とスキルとして書き出され、導入スクリプトで案件に持ち込める。要員が替わっても、方式は失われない
11 纏め者の経験は、持ち運べるスキルになる 方式を決め、書き出し、エージェントに埋めさせ、検証する経験は、フレームワークや領域（SoE・SoI）を越えて使える。技術者にとって、標準化フレームワークに関わることが割に合うようになる
  • 9・10 の前提として、固有 API の面が小さいこと（スロット）と、真似る具体例があること（サンプル・テンプレート）を併せて伝える。
    エージェントも、学習データに少ない固有の API は苦手で、文書を渡すだけでは足りない、という調査があるためである。

誰に向けて言うか

ターゲットごとに、強調するメッセージを変える。

ターゲット 主に使うメッセージ
ソリューションを求める事業会社（DX・内製化） 1、2、7（少人数＋エージェントで、SoE・SoI まで含めたソリューションを作る）
SIer の PM・アーキテクト 1、4、5、9、10（品質のバラツキとレビュー負荷を抑え、要員の教育・入れ替わりに強くして、守備範囲を広げる）
.NET Framework 資産を持つ組織 8、3、5（エージェントを使った移行・再構築と、その先の SoE・SoI への展開）
リードエンジニア・纏め者（技術者個人） 11、6、4（標準化フレームワークに関わる経験を、エージェントを導くスキルとして持ち運ぶ）

言わないこと

  • 「エージェントを使えば工数が○割減る」「SoE・SoI がすぐ安く作れる」といった、根拠の無い数値・断定。
    エージェント使用時の定量データはまだ無い（適用効果）。
  • 「誰でも作れる」。方式を決めて検証するリードエンジニアが要る（導入前の御相談）。
  • 「Open 棟梁を使えば解決する」。プロダクトは手段の 1 つで、訴求の中心はソリューションである。
  • 「開発者はフレームワークを覚えなくてよい」。覚える人を絞れるだけで、検証できる人は要る
    （AI に任せるほど人の理解が落ちる、という調査もある）。
  • 外部の調査の数値を、Open 棟梁の効果として示すこと。いずれも Open 棟梁を対象に測ったものではない。

参考

Tags: 再構築

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

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki
開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally