ビジネス書の名著はどれ？

山口周さんがお勧めのビジネス名著をリストアップされていたのでメモ。

元電通・BCGの山口周さんが、「ビジネス書の名著くらいは読んでおこ」とまとめたのがこのビジネス書マンダラ。多分野の基本は押さえておくに越したことはないので私も大賛成。組織戦略に携わる全マーケターにおすすめしたい。定着のコツは3回読むこと。 pic.twitter.com/qo6amm1ypC

— 彩花｜マーケ屋さん?? (@saika_affi) August 14, 2023

自分が読んだ経験のある本があったので、共感できた。

経済学をベースにした戦略論、組織論は好き。
人間の意志を超えた次元で、自然法則のように戦略も組織も縛られる。
そういう原則を抑えていれば、悪循環に陥る状態を防ぐことができるはず。
「マンキュー入門経済学」
「戦略の経済学」
「イノベーションのジレンマ」
「組織の経済学」
「組織は戦略に従う」

戦略/組織/人事と組織の経済学シリーズを読んでいる: プログラマの思索

組織論一般の理論を解説しているのが分かりやすかった。
「組織行動のマネジメント」

とても薄い本なのだが、アイデアがどうやって生まれるか解説してくれている。
「アイデアの作り方」

佐藤さんの解説記事がわかりやすい。
素早く考える能力、じっくり考える能力 : タイム・コンサルタントの日誌から

IT業界の営業戦略、プロセス導入ではキャズム理論が必須と思う。
パッケージ製品の営業だけでなく、新しい開発運用プロセスを導入する時もキャズムの法則に似たような事象が見られるから。
「キャズム」

キャズムの感想～イノベータ理論とホールプロダクト理論: プログラマの思索

伝記本として読んだ。
「スティーブ・ジョブズ I」「スティーブ・ジョブズ II」

岩波文庫なので文章は硬い。
「プロテスタンティズムの倫理と資本主義の精神」
「君主論」

自分が弱いのは意思決定、ゼネラルマネジメント、財務会計の分野かな。
全部読み切るには１０年ぐらいかかりそうな感じ。

第85回IT勉強宴会の感想～概念データモデルからビジネスモデルを構築すべきという考え方

土曜に開かれた第85回IT勉強宴会で、真野さんがデータモデリングの観点でエンタープライズシステム設計を講演されたのでオンラインで聞いた。
講演内容を知った前提で、感想をラフなメモ書き。

【参考】
概念モデルの効用を知ろう - connpass

概念モデルの効用を知ろう(第88回IT勉強宴会inZOOM/大阪サテライト) | ＩＴ勉強宴会blog

第39回IT勉強宴会の感想～花束を作る花屋の業務モデルをT字形ERと三要素分析法で比較する: プログラマの思索

第62回IT勉強宴会のメモ～２人の方法論者によるデータモデリング激レア対談: プログラマの思索

「データモデリング入門－astah*を使って、TMの手法を使う－」はとても良いモデリング資料: プログラマの思索

業務ロジックをデータモデリングはどこまで表現できるか？: プログラマの思索

リソース数がビジネスの可能性に関係する理由: プログラマの思索

【1】講演のメッセージは、DXで新規ビジネスを創出したいなら、概念データモデルを描くことから出発しよう、ということ。

メッセージの背景にある課題は、昨今、IOTやSaaSなどのSoE、既存の業務システムのSoRなど色んなところから数多くのデータがビジネスの副産物として簡単に入手して蓄積できるようになった
そのデータをAIや機械学習に食わせて分析するようにしたい。
しかし、色んな入り口から源泉データが発生し、途中で加工されて雪だるま式に派生データが積み重なり、複雑なトランザクションデータになっている。
そのためにそのデータを利活用しようとすると、派生データを取り除き、源泉データを区別して本来のデータを抽出する仕組みが必要だ、という問題意識。

akipiiさんはTwitterを使っています: 「我々が扱おうとしているのは、大半が加工・集約された派生データである。データがどこで加工されたのか、出処はどこなのかを探ることが重要。源泉データを突き止めるためにデータの系統図、データの変遷をたどるのが必要。イベントを時系列に並べてリソースを抽出する、ということかな？ #benkyoenkai」 / Twitter

そこで、SoE領域、SoR領域などの源泉データからどのように加工されてデータ連携基盤ハブにたどり着くのか、をデータモデルの観点から整理分類し、データクレンジングしたきれいなデータをデータ活用基盤へ連携してAIや機械学習に使ってもらうという仕組みにする。

akipiiさんはTwitterを使っています: 「源泉データがレガシーなSoRだったり、SaaSのSoEだったり、データレイクからだったり色々ある。そういう風にデータが時系列で加工されていく過程が見える。 #benkyoenkai」 / Twitter

講演では、製造業のサプライチェーン全てをデータモデル化し、コスト最適化の観点でシミュレーションとして使う事例が紹介されていた。

akipiiさんはTwitterを使っています: 「取引先や原材料、中間加工品の調達関係を描いたデータモデルが必要となる。制約条件は、取引先や原材料、中間加工品の調達関係を描いたデータモデルが必要となること。事業部間のデータ統合ができていることが前提。プロセスの再現だけではデジタルツインは実現できない。 #benkyoenkai」 / Twitter

akipiiさんはTwitterを使っています: 「デジタルツインでは、データ連携基盤Hubが重要。SoRが源泉データ。SoRからデータ連携基盤Hubを経てデータ活用基盤へデータが流れることになる。 #benkyoenkai」 / Twitter

僕の感覚では、雪だるま式に加工されて複雑化したトランザクションデータを時系列に並べて、マスタ（リソース）をトランザクション（イベント）と区別して抽出し、イベントやリソースをそれぞれ管理する仕組みを作る、というように捉えた。
実際の分析手法では、データモデルの正規化も使うし、クラスとインスタンスを区別することでクラスを抽出しロールとしてポリモルフィックに振る舞わせるように整理する。

講演では、顧客というクラスは、顧客、消費者、代理店、法人客というロールがある例が紹介されていた。

akipiiさんはTwitterを使っています: 「データモデリングは分類学である、とデータ総研の方は言っておられた、と。顧客、消費者、代理店、法人客などのロールを分類して、特化・汎化のER図で描く。IDEF1Xなのでオブジェクト指向設計と同じ。パーティモデルの概念と同じ。 #benkyoenkai」 / Twitter

【2】データモデルを作る目的は3つ。

akipiiさんはTwitterを使っています: 「データモデルを作る目的。3つある。ビジネス構成要素や業務ルールを把握する。保有するデータをAI機械学習の入力源にする。新規ITシステム構築に活用する。 #benkyoenkai」 / Twitter

【3】概念データモデルを描くメリットは何か？
メリットは2つある。

1つ目は、ビジネス構成要素を資源（リソース）と活動（イベント）の2種類に整理統合することによって、今後新たなビジネスモデルを生み出す材料として扱えること。

akipiiさんはTwitterを使っています: 「ビジネスの構成要素は資源（リソース）と活動（イベント）からなる。リソースは普通のマスタ、イベントは普通のトランザクションとみなせるね。羽生さんの本ではイベントに注目するとデータモデルを作りやすいと言っていたなあ。時系列に並べれば自然にDFDみたいなER図が描けるから #benkyoenkai」 / Twitter

データモデルのエンティティをイベントとリソースの2種類に整理するアイデアは、T字型ER（旧）や羽生さんのデータモデリング手法でも出てくる。
羽生さん本では、イベントは必ず日付があること、そこからイベントとリソースを区別しましょう、と言っていた。

「データモデリング入門－astah*を使って、TMの手法を使う－」はとても良いモデリング資料: プログラマの思索

業務ロジックをデータモデリングはどこまで表現できるか？: プログラマの思索

ここで、イベントの数とリソースの数を数えて、もしイベントの数がリソースよりも少ないならば、リソースを組み合わせて新たなイベント（トランザクション）を生み出すことで、新たなビジネスモデルを考える切っ掛けの一つになりうる。

リソース数がビジネスの可能性に関係する理由: プログラマの思索

第39回IT勉強宴会の感想～花束を作る花屋の業務モデルをT字形ERと三要素分析法で比較する: プログラマの思索
（引用開始）
リソースの数よりもイベントの数が少ない場合、リソースの組合せで発生する可能性のある対照表というイベントは、その会社の業務として存在していない事実がある。
すなわち、新しい業務を生成することで、新規ビジネスを作り出す根拠になりうる。
（引用修了）

2つ目は、講演では、プロセス指向設計で使われる業務フロー図では、既存の業務フローで業務を入れ替え・削除したり、担当組織を入れ替える程度であって、BPRや業務改善しかできない。
DXで本来やりたい新規ビジネスモデルを生み出すことは、業務フロー図からでは発想できない弱点がある。

akipiiさんはTwitterを使っています: 「データモデルの活用例の１つはDXへの適用。経営者、業務部門、IT部門のコミュニケーションツールとして使う。ビジネス創出のためには業務フローアプローチではBPRや業務改善に留まり、新規ビジネス抽出につながらない。順序入れ替え、組織分担変更のレベルにすぎない #benkyoenkai」 / Twitter

akipiiさんはTwitterを使っています: 「都度受注モデルからサブリスクプション契約モデルへビジネスを変更する。エンティティの置き換えだけでなく、新規イベント、新規リソースの追加が必要になることが明確に分かる。すると、新規イベント、新規リソースを保守管理する組織も必要になるだろう。 #benkyoenkai」 / Twitter

概念データモデルでAsIsモデルを描き、そこからエンティティを出し入れすることで、新規ビジネスモデルを生み出せるはず、と講演では説明されていた。

この部分については、なるほどと納得できる部分もあるが、本当にそうなのかという疑問も生じる。
確かに、講演で例に出た、AsIsの受注契約モデルとToBeのサブスクリプション契約モデルでは、業務フロー図でAsIsからToBeは出てこないだろう。
なぜなら、サブスクリプション契約モデルは誰も知らない初めてのビジネスモデルなので、業務フローをそもそも描くことすら難しい。
どんな業務が必要で、どの組織が業務のどのプロセスを担当して回すのか、そういう具体的な細かい粒度まで落とし込むのは至難の業だ。

しかし、AsIsの受注契約モデルとToBeのサブスクリプション契約モデルでは、概念データモデルを描いてみると構造はかなり違う。
契約エンティティなどの一部のエンティティは同じだが、AsIsモデルでリレーションシップや新たなエンティティをちょっとだけECRSでいじればToBeが出てくる、というのはちょっと無理があると思う。
実際、QAタイムでは、既存のAsIsモデルの概念データモデルでエンティティをECRSで出し入れする程度でToBeモデルが作れるのか、という質問もあった。

概念データモデルで新規ビジネスモデルを描く重要性は理解できるが、具体的なデータモデルを整合性が取れるように生み出すことは、別次元の作業なのだろうと思う。

【4】概念データモデルとオブジェクト指向設計、ドメイン駆動設計の違いは何なのか？

講演で紹介された概念データモデルはIDEF1Xで描かれていた。

ER図 (Entity-relatonship Diagram) | astah* 機能ガイド

IDEF1Xのエンティティ同士の関連線はクラス図と異なるが、多重度を書いたりロールを書いたりするのでクラス図に似ている。
オブジェクト指向設計やドメイン駆動設計が好きな人は、たぶん違和感なくIDEF1Xの概念データモデルを理解できるだろうと思う。

akipiiさんはTwitterを使っています: 「受注出荷のデータモデルをIDEF1XのER図、DFDで描かれた事例。クラス図に読み替えやすい。 #benkyoenkai」 / Twitter

akipiiさんはTwitterを使っています: 「受注出荷モデルの例。受注と出荷の関係が1対1、1対多では何が違うか？受注単位の出荷、一括受注して分割出荷。IDEF1XのER図はクラス図に似てるのでドメイン駆動設計が好きな人は読みやすいと思う　 #benkyoenkai」 / Twitter

akipiiさんはTwitterを使っています: 「抽象化したエンティティはロール概念を用いて関連付けることができる。真野さんが説明されるデータモデルはクラス図にそのまま置き換えられるね。 #benkyoenkai」 / Twitter

データモデリングがなかなか普及しない原因の一つは、ドメイン駆動設計が好きな人はデータモデルを読み解きにくい現象が多いのではないか、と推測するので、この辺りは1つのきっかけになるかもしれない。

【4】渡辺さん式データモデルと真野さんの講演で出てくる概念データモデルの違いは何なのか？

真野さんの講演で出てくるデータモデルは概念モデルレベルなので、エンティティ名しか書かれていない例が多い。
一方、渡辺さん式データモデルは、すべての属性を書き出し、関係従属性の意図まで明確に表していて、実際のデータの例も書いているので、より具体的だ。
実装モデルそのものと言っていい。

だから、渡辺さん式データモデルではテーブル仕様書をそのまま出力できるレベルであり、Railsのようなフレームワークを使えばすぐにCRUD画面も作れる。
つまり、どんな画面や帳票が必要で、どんな業務や画面操作でデータが生成されて更新されていくか、というレベルまで全て把握できている。
だから、ローコード開発やノーコード開発と相性がいい。
たぶん、SalesforceやKintoneのようなローコード開発ツールと相性が良いと思う。

akipiiさんはTwitterを使っています: 「真野さんのデータモデルはIDEF1Xで描かれてるので、渡辺さんのER図とは見た目は違う。個人的には、渡辺さんは関係従属性の意図まで明確にしインスタンスも例示するので、より実装モデルに近いと思う。だからローコード開発と相性がいい。 #benkyoenkai」 / Twitter

しかし、関数従属性やキーの種類の理解が深くないと、データモデルを読み解くのは難しいと思う。

再入門：「正規化崩し」としてのサロゲートキー - connpass

（引用開始）
・候補キー(candidate key)：レコードを一意に特定するキー。１テーブルに複数存在することがある
・主キー(primary key)：代表として定めた候補キー。項目値の変更は許されない
・単独主キー(single primary key)：１項目で出来ている主キー
・複合主キー(composite primary key)：２つ以上の項目で出来ている主キー
・自然キー(natural key)：業務上意識されている候補キー。単独主キーか複合主キーかは問わない
・サロゲートキー(surrogate key)：業務上意識されていない単独主キー。代理キーともいう
（引用修了）

サロゲート単独主キー vs 複合主キーの話、予習編 - たなかこういちの開発ノート

アーキテクトは、データモデルから業務フロー図、画面帳票、組織構成までイメージできる能力を求められる。
たとえば、渡辺さんの本を読めば、ほとんどデータモデルばかりでDFDは少しだけしか紹介されていないので、実際にどんな業務フローが必要になってくるのか、は自力で考えなければならない。
渡辺さんの本に出てくるデータモデルでは、複合主キーや外部キー、特に2次識別子（Alternative Key）が巧妙に使われていて、業務ルールや制約条件を表しているので、注意深く読まなければ割と読み落としやすい。

【5】概念データモデルはどの工程で使われて、どんな役割の人が担当すべきなのか？

講演では明示的な説明がなかったように思うが、常識で考えると、企画フェーズや要件定義で概念データモデルが作られる。
担当者はアーキテクトのレベルの人になるだろう。

作られた概念データモデルの粒度は、講演で紹介された粒度ならば、エンティティ名だけでかなり曖昧。
渡辺さん式データモデルの粒度なら、論理モデルまで落とし込む必要がある。
その場合、そこからすぐに実装モデルに置き換えられるから、ローコード開発ツールを使うことを前提にしているだろう

最近はデータモデリングから離れていたので、講演を聞いてすごくワクワクしながら聞いていた。
改めて、データモデリングのテクニックを自分なりに整理してみたいと思う。

令和4年度春期試験のITストラテジスト試験第4問をastahでモデル化してみた

令和4年度春期試験のITストラテジスト試験第4問について、問題文の構造をastahで図式化してみた。
自分のメモ用に残しておく。

【参考】
ITストラテジスト試験 | 試験情報 | IPA 独立行政法人 情報処理推進機構

令和4年度春期試験のITストラテジスト試験

【1】ストラテジスト試験第4問は必ず組込みソフトウェア開発企業のテーマになる。
今回のテーマは「電力自由化や再生エネルギー切り替えの環境変化に対し、電力会社の子会社が局地的な気象予測システムを開発し、親会社と連携することで新規顧客開拓を狙う」事例。

SDGｓや二酸化炭素排出削減、環境意識の流れ、EV化などの最近の事情を考えると、よく考えられたテーマと思う。

【2】ストラテジスト試験第4問の特徴はいくつかある。

【2-1】１つ目は、登場人物が非常に多いこと。
今回の事例を３C分析で書いてみるとすごくよく分かる。

【2-2】特に、協力者が重要な要素になる。
なぜならば、組込みソフトウェア開発企業は特定のアプリケーションソフトウェア開発には強いが、ハードウェア製品の開発は弱かったり、GISや気象データ、特殊技術を持つソフトウェア企業と連携する必要があるからだ。
自社にない経営資源は、外部企業と提携することで解決するためだ。

この事例では、GISデータを持つ企業、気象測器を製品販売する企業が協力者になる。

【2-3】2つ目は、脅威として法規制や政治情勢、社会ニーズなどのPEST分析が必要になること。
特に、法規制が多い。
人命にかかわるソフトウェアやハードウェアであればなおさらだ。
法規制の要件により、ハードウェア機器もソフトウェアも制限を受けるし、その分、コストがかかったり、ソフトウェア開発の難易度が上がる。

一般に、法規制は国が定めるので、政府や国という登場人物が出たら、法規制に必ず関わることになる。

【2-4】3つ目は、事業戦略の方向性は、新規顧客開拓が基本である点だ。
一般に、今までの既存顧客だけでは売上が減少気味だったり、SSGｓなどの環境変化で新たなニーズが生まれている背景があるから、新たな市場へ乗り出さないといけない、という方向性になりやすい。

では、新規顧客開拓に必要な経営資源は何か？
一般には、地域に根ざした営業力、特定の分野に特化した技術力があげられる。
技術力の例には、ソフトウェア開発力もあるし、保守サービス、AIやハードに特化したソフトウェア技術などがある。

すると成長戦略として、今までに培った技術力で新製品や新サービスを開発し、営業力を活かして新たなニーズを持つ顧客へ販売する、という方向性になる。
つまり、かなり積極的な経営戦略になるだろうと思う。

【3】今回の事例をSWOT分析してみたモデルを描いてみた。
モデルを描いて気づいた点は、いくつかある。

【3-1】1つ目は、協力企業と連携する箇所は必ずシステムの機能追加が必要になること。
例えば、気象予測システムに「電力の融通量を計算する情報システム」と外部連携する機能が必要になる。
この外部連携機能により、他の電力会社に局地的な気象情報に基づく情報を連携し、電力の大きな変動に対応して、全国規模の効率化を図ることになる。

たとえば、気象予測システムにGISデータを取り込む機能が必要になる。
局所的な気象は土地の起伏や構成要素に密接に関係するので、GISと連動させる必要があるからだ。
よって、GISの地図データを扱う企業と連携する必要がある。

まあ考えてみれば、協力企業と情報連携するわけだから、外部連携機能は必須になるのは当たり前。

【3-2】2つ目は、政府の方針や法規制にかかわる要件は、システムの機能に埋め込まれていること。
たとえば、気象業務法により、定められた人数以上の気象予報士を雇用する必要がある。
よって、気象予測システムでAI分析したデータは、必ず気象予報士がチェックして、顧客へ広報するという業務がシステムに埋め込まれることになる。

たとえば、政府は電力自由化を促進する必要があり、電力不足を防ぐ必要があるので、電力会社間で電力を融通してほしい思惑がある。
よって、気象予測システムと電力会社が持つ電力量算出システムが連携して対応する必要がある。

つまり、法規制や政府方針に関わる要件は、システムのどの機能で実現するのか、を必ずチェックしておく必要がある。

【3-3】3つ目は、課題の解決や経営資源がシステムの機能と密接に関係していること。
たとえば、局地気象予測システムでは、気象測器を高密度に多数設置する必要があるので通信手段が必要になる。
そこで、親会社の電力会社が持つ通信インフラである有線・無線ネットワークを利用することで解決する。
つまり、経営資源を活用することで、システムに足りない機能や環境を補充することになる。

たとえば、局地気象予測システムでは、気象測器は修理対応や交換を伴う定期保守が必要になる。
しかし、観測成果を発表するには、気象測器は基本は検定合格品を使用しなければならないが、高価であり、製品販売する企業も少ない。
そこで、観測成果の発表を止める代わりに、検定合格しない安めの製品を利用すること、親会社D社の強みである災害時を想定した保守体制を活用して、検定合格しない製品販売のZ社と提携し、予備機の追加や製品修理だけの保守を契約することで対応する。
つまり、投資効果のバランスを取っているわけだ。

【4】ストラテジストの他の問題もastahでモデル化してみると、販路開拓を目指す新規事業とそれを実現するシステム要件がうまく関連していることがよく分かって面白い。
ベンチャー企業も、新規事業を起こしたい大企業も、こういう発想でシステムを開発しようとしているのだろう。
他にも試してみたいと思う。

経営戦略とIT戦略をつなぐ鍵は何なのか

経営戦略とIT戦略をつなぐ鍵は何なのか？
考えたことをラフなメモ書き。

【参考】
ITの地殻変動はどこで起きているのか？～今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること: プログラマの思索

【資格】ＩＴストラテジスト試験対策　この時期にすること（ＢＳＣ） | 三好康之オフィシャルブログ　「自分らしい働き方」Powered by Ameba

【1】外部環境をPEST分析や5Fsで分析し、内部環境をVRIO分析やバリューチェーンで分析できたとしよう。
そして、経営目標が定まり、経営方針として経営戦略が立てられたとしよう。
経営者としては、こういう経営目標を実現するためにこんな経営戦略を実現するんだ、とスローガンをあげる。
では、そこからどうやって、どんなシステムが必要でどんな順番でシステムを構築していくのか？

ITアーキテクトが、経営者から提示された経営戦略を元に、これだけの数のシステムの開発や改修が必要です、と言っても、投資効果がなければ経営者は納得してくれない。
数千万円から数億円、数十億円のシステム開発に投資するなら、どれだけの投資効果があるのか、その説明の根拠が欲しいのだ。

【2】では、経営目標や経営戦略からIT戦略までの枠組みはどんな体系図になるのか？
経営目標を達成するために、こういう戦略が必要で、こういうITシステムが必要なのです、するとこれだけの投資額が必要でこれだけのROIが出てきます、という因果関係を表す流れを説明したいのだ。

経営戦略からIT戦略、個別システム開発までの全体の枠組みはこんな感じになるだろう。

経営目標 --> CSFに基づいた経営戦略 --> 業務戦略 --> 全体システム化計画 --> 個別システム化計画 --> 個別プロジェクト計画

一般に、経営戦略は中長期の観点で作られる場合が多いので、3～5年ほどの期間で組み立てられるだろう。
そういう経営戦略の元に、事業にある各業務プロセスが新規で立ち上がったり、業務の効率化を目指す活動が実行される。
そんな業務を支えるためにITシステム、ITサービスがあるから、それらは各事業を支える裏方のシステムが多くなり、一般に基幹系業務システムが多いだろう。
たとえば、販売管理、発注管理、生産管理、会計、債権管理、顧客管理など。
もちろん、顧客を獲得するためのエンゲージメントに注力したシステムやサービス、たとえばECサイトなどもあるだろうが、それと同じくらいの規模のバックエンドのシステムも必要になるし、そちらのシステムの方がより巨大になりやすいからだ。

【3】こういう体系図はバランス・スコアカードで表現できるだろう。
財務＞顧客＞内部ビジネス・内部プロセス＞組織や人の学習と成長　の観点でレイヤ化できるだろう。

すると、各レイヤは業績測定指標というKPIでモニタリングできることになるので、下位のレイヤのKPIが良いから上位のレイヤのKPIも良くなって、最終的に売上向上になり、利益向上につながります、という因果関係で説明できることになる。

つまり、経営戦略とIT戦略をつなぐ鍵は、こういう業務測定指標の因果関係にあるのではないか、と思う。
各レイヤの業務測定指標であるKPIが階層化されていて、下位のレイヤの業務のKPIを上げることで、最終的にKGIという経営目標が達成できる、という流れになるだろう。

【4】では、財務・顧客・業務・成長の観点でどんなKPIがあって、どんな因果関係で結ばれているのか？

財務の観点では、一般的に経営指標だろう。
ROE、ROA、収益性、効率性、安全性など。

顧客の観点では、一般にマーケティング指標だろう。
新規顧客数、RFM分析の指標、顧客満足度、コンタクト件数など。

業務の観点では、業務の効率性を示す指標だけでなく業務を支えるITの観点の指標も含まれるだろう。
一般にはQCDの観点が多いだろう。
品質なら、不良品率、部溜率、稼働率、ライン停止時間など。
コストなら、製品別原価、作業工数、在庫費用など。
納期なら、サイクルタイム、リードタイム、納期遵守率など。
他に、研究開発費、アフターサービスの問い合わせ対応回数など。

学習と成長の観点では、従業員の能力向上やナレッジ蓄積に関する内容が多いだろう。
従業員満足度、従業員定着数、特許数、など。

これらのKPIを組み合わせると例えば、利益向上であれば、下位レイヤーのKPIに分解できるだろう。

利益＝売上ー原価
売上＝新規顧客数ｘ販売単価
原価＝時間単価ｘ作業工数
新規顧客数∝説明会の参加回数ｘ説明会に参加した新規顧客数ｘ営業訪問率ｘ見積依頼率ｘ成約率

説明会の参加回数、説明会に参加した新規顧客数、営業訪問率、見積依頼率、成約率というKPIをリアルタイムに測定するために、CRMのシステムが必要であると判断し、CRMを導入・開発・運用するコストがこれだけかかるが、これだけの売上が見込めるので投資効果があります、という説明の流れになるだろう。

こういう話を考えると、ECサイトで商品購入に至る導線作りと全く同じ。
たとえば、AARRRという指標でECサイトの購入率を分解して、ECサイトの導線となる画面設計を考えるやり方と同じ。

AARRRとは?サービスを成長させるための基本戦略【テンプレート付】｜ferret

AARRR（アー）モデルを活用する上で知っておきたいこと | Urumo！

【5】今の自分が経営戦略とIT戦略をつなぐロジックを考えている時、相手を説得できるだけのロジックがなかなか作れずに悩んでいた。
悩んでいた原因の一つは、経営戦略と業務を支えるITシステムの計画の間で、階層化されたKPIによって最終的に経営目標が実現されるから投資効果がある、という説明ができなかったためだろうと思ってる。
自分なりに考えているけれど、思いつきで理由を作ってそれをつなげているから、色んな突っ込みがあるとボロボロと漏れが出てしまうという感じだった。

KPIというツリー構造で考えれば、各指標は各要素に因数分解されて、各要素は下位レイヤーのKPIになるからさらに因数分解されていく、という形式になる。
つまり、経営目標KGIというトップから、下位レイヤのKPIまで数式として分解されるので、一つのロジックツリーという構造で一覧できる。
そういうロジックツリーの構造があるからこそ、KPIを繋いで説明することは数式をなぞるように論理的に説明することと同一になるので、相手も説得しやすくなる、という流れかな。

KPIツリーという考え方はおそらく、フェルミ推定の発想と同じ。
ゴールを達成するために、ゴールを測定するKGIを設定し、それを公式を使って因数分解し、各要素の数値は推定して仮説を立てて、KGIを推定するという流れと同じ。

おそらく既に理解できている人、実践できている人にとってはとても当たり前の考え方なのだろうが、現場で色んな経営課題に対して解決策を提示したり、経営戦略に基づくビジネスモデルを提案したりする時、こういう手法を持っておかないと短時間にそこそこ高品質な提案や仮説が出てこないのだろうと思う。

計量政治学と計量経済学の考え方の違い

経済セミナー2022年10・11月号 通巻728号【特集】いま、政治の問題を考えるを読んでいたら、計量政治学と計量経済学の考え方の違いの記事が面白かった。
以下はラフなメモ書き。

機械学習で反実仮想や自然実験が作れる: プログラマの思索

Pythonで微分積分や統計の基礎を理解しよう: プログラマの思索

経済学は信頼性革命や構造推定により大きく変貌している: プログラマの思索

経済学や心理学の実験で得られた理論は再現性があるのか？～内的妥当性と外的妥当性の問題点がある: プログラマの思索

Rによる計量経済学/計量政治学を読んでいる: プログラマの思索

【1】計量政治学と計量経済学の考え方の違い

政治学の方が特定地域のこだわりがある。
たとえば、NPO法人や政治家にインタビューするために、現地言語を習得したり、その国の文化に慣れる必要がある。
経済学はそこまでこだわらない。

一方、政治学は理論と計量をそこまで区別しない。
政治学は定性データを重視するし、時事問題を重視する。
たとえば、リーマン危機、ウクライナ戦争など。
しかし、経済学では、理論と計量を区別し、過去に蓄積してきた理論を使って、計量データを用いて、政策の効果を測定したりする。
だから、経済学では、理論の人は計量の論文を読め、計量の人は理論の論文を読め、と言われるらしい。

【2】計量政治学から得られた経験則

独裁者は暴力行使の利益とコストを勘案して多様な手法で大衆を制御しようとする。
ここに独裁者のジレンマがある。
権威主義的な国の選挙は実行がすごく難しい
選挙の不正がなければ、野党や反体制の人達がのさばり、自分たちの権力を脅かそうとする。
一方、選挙で不正を実施しすぎると、本当の支持率が分からないし、どこの地域が支持率が高く、どこの地域に反体制の人達が実は多いのか、分からない。
つまり、自発的な支持が得られないので、実は権力基盤が脆い事実を国民の皆が知っている。
だから、権威主義国の独裁者は実は裸の王様。
だから、独裁者は、自分の支持率はじつは高いのだ、というシグナルを国民に知らせる必要があり、あの手この手を使っている。

また、農業主体の国は人々が散在しており、組織化しにくい。
つまり、一体化して反抗しにくい傾向があるらしい。
すなわち、都市化した国の方が、民衆が組織化しやすく、一致団結しやすいので、民主化しやすい傾向があるらしい。

この話を読んで、フランス革命は実はパリ革命だった、という話を思い出した。
なぜなら、フランスは中央集権の王権国家であり、パリに人民も富も集中していたので、パリで体制変革されると全土にその余波が行き渡っていたから。

【3】民主化はいつどのように起きるのか？

色んな国の統計データを調査すると、与党と野党の間に、権力基盤の合意がある前提があるらしい。
つまり、信憑性のあるコミットメントが存在している。
だから、クーデターや内戦のような暴力行為による政権交代は必要なくなる。
たとえば、韓国や台湾、南アフリカなどがその事例に相当するだろう。

【4】計量政治学に機械学習や深層学習を用いて得られたノウハウ

権威主義国では統計データを不正に操作しているので信頼性が低い。
だが、夜間の光量データから経済活動の活発さを見る、という手法を取ることもできる。
その場合、衛星からの画像データをCNNに食わせて、計測アルゴリズムを作り出す、というやり方も取れる。

すると試行錯誤による発見的予測アルゴリズムの成果はどうだったのか？
4つある。

1つ目は、本来のアルゴリズムは藪の中。
真の因果関係を表すアルゴリズムは不明だった。
特に、深層学習の場合は、予測できたとしても説明可能性は低い。
正しいモデルアルゴリズムにこだわるのは不毛なことがある。

2つ目は万能なアルゴリズムは存在しないこと。

3つ目は、次元の恵みを活用せよ。
説明変数の次元が増えるほど、必要なデータ量は指数関数的に増えて計算できなくなる。
つまり、次元の呪いが発生する。

そこで、次元の呪いを解決するために、予測に必要な説明変数を絞り込む変数選択、過学習を防ぐ正則化などを用いる。
しかし、予測に使える変数は全て投入して、次元の恵みを最大限活用する方法もあるのでは、と。

4つ目は、予測可能性と説明可能性のジレンマがある。
深層学習は、予測性は高いが理屈は複雑で説明しにくい。
一方、線形回帰や決定木は、予測は微妙だが説明しやすく、因果関係を明確にしやすい。
そういうトレードオフがある。
つまり、政策介入の因果関係としての効果を測定することと、機械学習による予測は完全に調和しないのだ。

僕はこのトレードオフは、実際の政策を実行する上で、ハードルが高くなるリスクがあると思う。
たとえば、財政出動や補助金をばらまく政策を実行する時に、これだけの効果を予測できます、とアナウンスすることで、国民や利害関係者を納得させたいが、その効果の因果関係を説明できなければ、本当に効果があるのかと疑問に思う人も増えて、その制作に反対する人が増えてしまい、せっかく期待していた効果が実行しても得られないリスクが出てくるからだ。

経済学のルーカス批判のように、政治学でも自己予言的なリスクがあるのかもしれない。

経済学や心理学の実験で得られた理論は再現性があるのか？～内的妥当性と外的妥当性の問題点がある

経済セミナー2022年6・7月号 通巻726号【特集】経済学と再現性問題 | 日本評論社 を読んで、経済学や心理学の実験で得られた理論は再現性があるのか？という特集号が面白かった。
再現性の根本問題は、内的妥当性と外的妥当性の問題点があると思う。

経済学が理解できるようになってから、図書館から経済セミナーを借りて読む時が増えたけど、政治や経済、社会のニュースと直結しているので面白い。

ラフなメモ書き。

【1】Twitterのごく一部で話題になっていた「再現性問題」が経済セミナーの最新号に掲載されていたので斜め読みした。
「再現性問題」とは、心理学や行動経済学ですでに知られていた実験結果や通説が実は再現性がほとんどないぞ、という指摘。
プロスペクト理論の損失回避性、ナッジ政策も実は再現性がないと言う。
ナッジ政策が再現されないとなると、ナッジ政策を推進する政府の公共政策には意味がない、税金の無駄遣いということだから影響は大きい。

【2】再現性の根本問題には、内的妥当性と外的妥当性の2つの観点がある。

僕の理解では、内的妥当性とは、母集団の中のサンプルをランダムに採取したときに、どのサンプルも同じ傾向の統計データが取れて、同じ結論が出ること。
自然科学の実験であれば、これは当たり前。
しかし、心理学や経済学では、母集団の中のサンプルでは、個人の属性のばらつきが大きいので、同質な属性を持つ集団を抽出する方法が難しい。
心理学ならば個人にバイアスがかかってしまって、そもそも客観的なテストができているか疑問がある。
何度も同じようなテストをすれば、個人も学習してしまって、過去と違う結果を返すかもしれない。

一方、外的妥当性とは、ある母集団で得られた統計データの傾向や結果が、他の母集団にも適用して、同じような統計データや結果が得られること。
自然科学の実験であれば、米国であろうが日本であろうが場所に関係しないし、現代でも100年前でも同じ結果が出る。
しかし、心理学や経済学では、欧米と日本では文化や価値観が異なる部分は多いし、100年前の人間集団と現代の人間集団では価値観も行動も全く異なるから、同じ統計データが得られるとは限らない。

つまり、内的妥当性は同じ母集団の中で採取したサンプルが同質であるか、外的妥当性は異なる母集団にも同質性を適用できるか、という問題点だと思う。

【3】「内的妥当性の再現性問題」の問題点は、仮説統計検定のp値に関する論点だろう。
p値が5％の基準で、仮説を棄却したり、棄却できないと判断する場合、4.9%と5.1%ではどんな違いがあるのか？
5％前後の僅かな差が、統計的有意であるかどうか決めるのであれば、その基準はそもそも妥当なのか？
pハッキングという話につながるらしい。

この仮説統計検定が使えなくなると、心理学の実験がすごくやりにくくなるだろう。
心理学で主張した意見の根拠をどこに求めればよいのか、大きな論点になるだろう。

【4】「外的妥当性の再現性問題」の問題点は、たとえば、欧米では大量データで実験して正しいと得られた通説が、日本では通用しないのでは、という点だろう。

経済学であれ他の学問でも、欧米で得られた統計データがすごく多い。
そこで得られた知見は、欧米人という母集団で得られた統計データに過ぎず、日本人という母集団に適用して、その真理が通用するのか？
この外的妥当性が通用しないとなると、経済学の理論は使い物にならなくなる。
経済学は規範的学問であるから、こういうエビデンスがあるから時の政府はこういう経済政策を打ち出すべきだ、という指針を提供できなければ、学問としての意義がないだろう。

経済セミナー2022年6・7月号 通巻726号【特集】経済学と再現性問題 | 日本評論社 を読むと、他の母集団に適用すると再現できなかったら、再現できない原因を探る方がより生産的な議論になる、という話があって、なるほどという気付きがあった。
再現できない差異要因が見つかれば、その要因をさらに分析することで、経済学の理論を補強することもできるだろう。

【5】内的妥当性、外的妥当性の話は、「データ分析の力 因果関係に迫る思考法」にも紹介されていたが理解できていなかった。
経済セミナー2022年6・7月号 通巻726号【特集】経済学と再現性問題 | 日本評論社 を読んで、やっと言わんとすることが理解できた気がする。

データ分析の課題はどこにあるのか: プログラマの思索

データ分析の面白さはどこにあるのか: プログラマの思索

【6】こういう話を読むと、人文・社会科学の真理を追求するために、客観的な妥当性を説明できる理論的根拠をいかに作り出すか、が論点なのだろうと思う。
自然科学と違って、心理学や経済学などの人間や社会に関する学問は、学問として成り立つ正当性を説明しようと努力して四苦八苦しているんだな、といつも思う。

そして、過去の優れた哲学者は、その正当性に関する議論を自分たちの脳内だけで色々試行錯誤してきたが、現代ではITやプログラミングという技術があり、それを使えば相当の内容を深く議論できるようになった点が大きく異なる。
過去の優れた哲学者の活動そのものを我々は検証できる道具を持っている点がすごく重要だと思う。

以前も、そんなことを考えていた。

計量経済学における統計上の根本問題: プログラマの思索

Rによる計量経済学/計量政治学を読んでいる: プログラマの思索

経済セミナーが面白いと思う理由は、最新のIT技術を使うことで色んな実験ができることだろう。
ITと統計学が融合している学際的な場所になっている。
プログラミングさえできれば、統計学の理論、経済学の理論は、実際に動かしながら後から理解すればいいと思う。

機械学習で反実仮想や自然実験が作れる: プログラマの思索

Pythonで微分積分や統計の基礎を理解しよう

みんなのPython勉強会#81 - connpassに出たら、『Pythonで微分積分の基礎を学ぼう』という講演が良かった。

みんなのPython勉強会#81 - connpass

Pythonで理解する微分積分の基礎：書籍案内｜技術評論社

Pythonで理解する微分積分の基礎 (Python × Math)の著者が話されていたのは、高校数学はPythonで理解してしまいましょう、ということ。
微積分にたどり着くまでに、三角関数、指数関数、対数とか色々出てきて、訳が分からないという学生も多い。
しかし、Pythonならば、関数をグラフで表示できて直感的に理解できるし、計算はプログラムに任せてしまえばいい。
簡単な線形微分方程式も、Pythonなら簡単に解を導いてくれる。

つまり、小難しい理論から理解するのではなく、具体例をPythonで色々プログラムを書いて試して、そこから理解した方が速い。

この話は僕も共感する。
例えば、統計学の理論は十分に揃っているのだから、Webログのようにビジネスの副産物として簡単に採取できるのだから、後はプログラムでいくらでも分析しまくればいい。
最近の心理学や経済学の動向は、コンピューティングパワー抜きではその発展の歴史を追跡できないだろうと思う。

また、こういう人文・社会科学系の理論を使って、組織論や人事制度、経営理論を試す話も最近多くなった。

直近の経済学の雑誌「経済セミナー2022年4・5月号 通巻 725号【特集】「職場」の経済学」をふと読んでみたら、あるべきリーダーシップやモチベーション向上、あるべき組織や人事制度の話があって、興味を惹いた。

あるべきリーダーシップやモチベーション向上、あるべき組織や人事制度の問題を実証的問題に変換し、アンケートを使ったランダムテストなどを使ったりして、社会科学上の問題の本質を探ろうとしている。

プログラミングという武器があれば、現場にある眼の前の個人の心理や集団の行動や意思決定にかかわる問題を統計で分析することで、本質的な変数を見出し、因果関係を見出したり、さらには予測することもできるわけだ。

そういう意味では面白い時代になったのだろうと思う。

Rによる計量経済学/計量政治学を読んでいる: プログラマの思索

戦略/組織/人事と組織の経済学シリーズを読んでいる: プログラマの思索

超高速開発でアジャイル開発を実現する話に違和感がある

超高速開発をやってます、これでアジャイル開発を実現しています、という話を聞いて違和感があった。
その違和感が何なのか、考えてみた。

違和感を感じた理由は3つある。
1つ目は、超高速開発ツールを使って短納期で少ない工数で開発できることをアピールしているのは違うでしょ、と思うから。
話を聞いてみると、要件定義さえ固めれば、後は設計を開発基盤に落とし込んで、超高速開発ツールという開発基盤を使えば、即座に動くアプリが作れる。
だから、顧客の現場でSEが常駐して、要件をヒヤリングして固めて、作った機能のユーザテストを定期的に行っています、と言っている。
大きな目で見ればアジャイル開発と言えるのかもしれないが、現場でユーザにヒヤリングしながら要件定義を固めること、そして、超高速開発ツールで短納期に開発するのがアジャイル開発と言えるのか、正直疑問に思った。

2つ目は、最近のアジャイル開発の風潮では、アジャイルコーチがきちんと指導したチームでアジャイル開発を回しているのでなければ、アジャイル開発とは言いにくい状況があることだ。
一般に、認定スクラムマスター、認定プロダクトオーナーなどの資格を持ち、スクラムの知識を熟知した技術者がチームを形成しているか、そういう資格を持ったアジャイルコーチが開発チームを指導しているか、を見なければ、アジャイル開発を実践しているか判断できないと思う。

他方、そういう認定資格を持っていない技術者やチームでアジャイル開発をやっています、と普通のソフトウェア企業が公開していたら、見知らぬ技術者は、この会社はアジャイル開発をやっているんだ、と勘違いして入社して、そのギャップに幻滅するのではないか。

昨今の風潮では、アジャイル開発と言えばスクラム一色なので、スクラムの認定資格を持っていない人がアジャイル開発をやっていると言う時、特に公的な場で表現するのは信憑性があるのかな、と疑問に思ってしまう時がある。
他方、スクラムはアジャイルコーチという職業を生み出し、認定資格によって、運用する人たちの資質や品質を担保する仕組みを整備したのはビジネス的に上手いな、と思う。

AgileTourOsakaでSCRUMMASTER THE BOOKの裏話を聞いた: プログラマの思索

3つ目は、超高速開発ツールを使っていると言いながら、データモデリングの技法を重視していない状況だったからだ。
単純に画面と帳票を設計して、それを超高速開発ツールの基盤に載せて、アプリを作っているだけだった。

一般に、超高速開発を標榜する人たちはデータモデリングの技術を背景にして、超高速開発ツールを自分たちで作り込んでいる。
彼らは、業務プロセスをデータモデルやDFDできちんと設計しているから、RDBさえ固めれば、後は画面と帳票のパターンを組み合わせて作るだけ、という方針でやっている。
しかし、超高速開発でアジャイル開発をやっています、という人たちの話を聞くと、確かに業務フローは書くけれど、データモデルが十分に考えられているとは見えなかった。
後で手直しできるから、と割と安易に作っているようにも見えた。

ちょっとそんな現場を見る機会があったので、超高速開発でアジャイル開発を実現しています、という話には気を付けた方がいいな、と思った。

知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る

SECIモデルの状態遷移図を描いて、ようやくSECIモデルを理解できた気がする。
ラフなメモ。

SECIモデルの状態遷移図 from akipii Oga

SECIモデルの具体例(Scrum・チケット駆動開発など) from akipii Oga

パターン言語の構造と事例 from akipii Oga

【1】2014年頃に、SECIモデルでパターン言語を理解しようと考えていた。
確かにパターン言語と相性は良いが、SECIモデルのイメージがまだピンときていない気がしていた。

SECIモデルは、PDCAみたいなマトリクスよりも、知識・経験の状態遷移図で描く方が理解しやすいと考えた。
形式知＝知識、暗黙知＝身体による経験。

【2】知識を使って身体に落とし込むのが内面化。
スポーツ、楽器、お絵描きなどの訓練が相当するだろう。

一方、身体で経験した内容を知識でまとめるのが表出化。
一流のスポーツマン、学者、音楽家、宗教家、哲学者たちは、自分たちの体験を何とか知識として言語化し、みんなに広めようとする。
走る哲学者と言われる為末大さんみたいな感じかな。

他方、形式知を組み合わせて新たな知識を創造するのが連結化。
感覚的に情報を受け取って暗黙知を高めるのが共同化。

【3】知識は経験よりも大切なのか？
経験は知識よりも勝るのか？

僕は両方を経験している。

IT技術者であれば、たくさんのプロジェクトで新技術や業務システム開発を経験した後で専門書を読み直すと、ああ、そういうことだったのか、と気づく時が多い。
中島聡さんは、プログラミングとは、座学で勉強するものではなく、実際にアプリ開発して体験した後で専門書で答え合わせするものだ、と言われていた。
そんな内容と似ている。

実践した後に勉強するのがエンジニアの本来の道: プログラマの思索

僕がRedmineにハマったきっかけも、XPやアジャイル開発の本はたくさん読んだが、何か腑に落ちることがなくて、Redmineでいろいろ試して初めて分かったという事があった。
知識がいくらあっても、やはり体験しなければ、本当に理解できた、という感覚がない。
肌感覚では分かった気にならなかった。

一方、IT企業やプロジェクトという組織形態では、いつもイライラするものがあって、その原因がなにか分からない時があった。
組織文化はトップが作るのか、ボトムアップで作られるのか、いつも疑問に思っていて、アジャイル開発の影響から、組織文化は現場からボトムアップで生まれるのだろうと思っていたが、診断士の先生に聞いたところ「組織文化を生み出す責任は社長にある。もっと社長が汗をかけ！」と言われて、ハッと気づいた時があった。

制度的リーダーシップの考え方が何となくしっくりきた: プログラマの思索

組織文化はトップが作るのか、ボトムアップで作られるのか: プログラマの思索

同様に、組織論、経営戦略論、経済学などを勉強してみて、メンバーに応じた教育方法ならSL状況理論やPM理論を使ってみたらいい、とか、プロマネとPMOの微妙な対立関係はエージェンシー問題に似ているな、とか、知識を使って、自分なりに理解が進んだ気がした。

管理職に求められる能力はPM理論そのものではなかったのか: プログラマの思索

ITの地殻変動はどこで起きているのか？～今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること: プログラマの思索

また、RedmineでRubyのソースコードは適当に触っていたがRubyはちゃんと理解できてなかった。
RubySilverやRubyGoldを勉強してみて、Rubyはオブジェクト指向言語を徹底しているんだな、と改めて理解し直した。

Ruby技術者認定試験の感想: プログラマの思索

そんなことを考えると、知識と経験の相互作用として、SECIモデルの内面化、表出化を行ったり来たりしながら自然に実践している。
そして僕はたぶん、実際に色々体験して、失敗を繰り返さないと腑に落ちないみたいだ。
そういう感覚はSECIモデルの状態遷移図で整理できるんだな、と改めて感じた。

オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった

オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かったのでメモ。
ラフなメモ。

【参考】
オープンソースERPパッケージに対する派生開発手法の提案～開発プロジェクトの事例をもとに～ - AFFORDD

オープンソースERPパッケージに対する派生開発手法の提案～開発プロジェクトの事例をもとに～ - 経験論文

オープンソースERPパッケージに対する派生開発手法の提案～開発プロジェクトの事例をもとに～ - スライド資料

オープンソースERPパッケージiDempiereはいつか、仕組みを習得して、ERPはこういうものですよと自分なりに理解したいと思っていた。
ネット上の情報から、普通にインストールできる。
PostgresSQLのDBの中身を見ると、テーブル数は1千個を越えるので、OSSのわりに作り込んでいるERPだと思う。

こういうOSSのERPを自社開発、受託開発したい場合、必ずカスタマイズが入る。
その時に、どんな方針でカスタマイズすべきか、という問題が出てくる。
無造作にカスタマイズしていくと、開発基盤のバージョンアップに追随できなくなるし、今後の運用保守もやりにくくなるからだ。

そこで、ERPのカスタマイズに派生開発手法であるXDDPを用いて解決してみよう、という流れは自然に理解できる。
基本方針は、カスタマイズする場合、標準機能をラッピングまたは継承する形で、独自ロジックを実装する。

上記の資料で興味深いと思った点は、OSSのERPのカスタマイズで発生する問題として、標準機能の知識習得が難しいこと、派生開発により基盤である標準の品質を損ねること、という2点があげられたことだ。
そして、その解決方法として、教育環境の整備、開発規約の整備、開発体制の強化があげられていた。

意外だなと僕が思った理由は、派生開発のプロセスやiDempiereの開発基盤のアーキテクチャに焦点が当たると思っていたからだ。
しかし、よく考えれば、プロセスや技術面よりも、技術の習得や教育の方が長期的な問題なのだ、と理解すればいいのだろう。

得られた情報や検索した情報は、社内のRedmineで一元管理して共有している点も面白い。
Redmineを組織のナレッジ資産として使っているわけだ。

今後の課題として、XDDPのトレーサビリティマトリクスを利用して技術上の課題を解決していく点があげられていた。
iDempiereはOSSとはいえERPなので、相当な機能数があるから、すべてを理解するのが難しいのだろう。
そのために、XDDPのトレーサビリティマトリクスを利用したいのだろうと思う。