JSTQBのテストプロセスの概念モデルを描いてみた

JSTQB Fondation試験を勉強した時に、JSTQBのテストプロセスの概念モデルを描いてみた。
気づきを書き残す。
まだ理解があやふやなので、間違えていたら後で直す。

【参考】
テストアイテムとは何か？概要や定義、現場での使われ方について解説

JSTQB_テストマネジメントとレビュープロセス.pdf from akipii Oga

JSTQB_テストプロセスの概念モデル.pdf from akipii Oga

【1】JSTQBのテストの専門用語は、普段使っている言葉と意味が違っていたり、別の言葉で置き換えられる時があると分かった。
たとえば、テストレベルはテスト工程のテストプロセス、テストタイプはテストの種類に相当するだろう。

テストオラクル、テストベースなどはJSTQBで初めて知った。
たぶん、テストケースの発生源や出処となる概念を明確に区別すべきという考え方があるのではないか。

テストオラクルの用語定義: プログラマの思索

また、テストプロセスの概念モデルを描いてみて気づいたのは、JSTQBにたくさん出てくるテストの専門用語は、テスト管理ツールやテスト支援ツール、テスト自動化ツールなどのツールで使う場面をかなり意識しているのではないか、と直感している。

たとえば、テストスイートは、一般にテスト自動化ツールに読み込ませるテストケースやテストデータをイメージできる。
テストハーネスはドライバやスタブみたいなものだし、テスト環境そのものも今ならDockerで最初から環境構築を自動化できる。

【2】エラー(誤り) error、欠陥 defect、故障 failureは明確に区別される。

エラー・欠陥・故障の用語定義: プログラマの思索

一般に不具合と言われる事象は故障に相当するだろう。
不具合をバグ、障害と断定しない理由は、実際に調査してみたら、仕様通りで問題ないとか、テスト手順ミスやテスト環境の不備が原因だった、という場合があるからだろう。
不具合は、故障、不正の事象も包み込む曖昧な現象を指す場合が多いと思う。

欠陥があったからといって、故障が発生するわけではない。
欠陥のあるプログラムが実行されて初めて故障が発生する。
欠陥がプログラムに埋め込まれても、テストで発覚せず、運用していても発生しなければ、システムは問題なく動く。
しかし、欠陥そのものは存在しているわけだから、いつかは故障として発生する。
いわゆる潜在バグに相当するのだろう。

欠陥の根本原因の分析はなぜなぜ分析がよく使われるだろう。
しかし、なぜなぜ分析を現場で実際に使ってみると、なかなか効果を出すのが難しい。
メンバの力量にかなり依存するので、原因があらぬ方向に行ってしまいがち。

【3】JSTQBでは、テストチームの役割には、テストマネージャとテスト担当者の2つが少なくとも定義されている。
テストマネージャはテスト計画フェーズで中心的役割を果たす。
テスト実行フェーズ以後の具体的な作業はテスト担当者に任せるようだ。
つまり、テストマネージャはプロジェクトマネージャやストラテジストに近いイメージを持った。

JSTQBのAdvancedLevelはテストマネージャ試験がある。
ただし、業務経験が必須らしい。

【4】テスト管理や品質管理については、TestLinkを試していた頃に随分色々考えていた。

TestLink: プログラマの思索

プログラミングやシステム設計とは異なる考え方を知ったり、試したりするのが面白かった。
残念なのは、テスト管理ツールはほとんどが有償であり、OSSのTestLinkしか試せなかったことだった。

テスト管理ツールTestRail、CAT、QualityForwardの感想: プログラマの思索

テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク: プログラマの思索

今持っている問題意識は、2023年の現在、ソフトウェアテストを支援するテストツールはどんな方向に進化しようとしているのか、ということ。
上記の記事にも書いたが、日本のIT企業やユーザ企業が考える品質と、欧米企業が考える品質は異なる。
日本人は機能の細かい品質までこだわるが、現代はアジャイル開発が普及して一般的になっていて、その考え方が時代に合わない部分もある。
アジャイル開発に適した品質とは何なのか？
そして、AIなどを使ってもっとテストそのものを進化させることはできるのか？

この辺りは色々考えてみたいと思っている。

第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】概念データモデルはどの工程で使われて、どんな役割の人が担当すべきなのか？

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

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

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

ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2～プロセスのレイヤと達成目標のレイヤが異なる

ストラテジストとプロジェクトマネージャの役割の違いは何なのか？
ITコーディネータ研修を経験して、IPAが定義するストラテジストとプロジェクトマネージャの役割の違いを自分なりに理解したことをメモ。
ラフなメモ書き。

【参考】
IPA 独立行政法人 情報処理推進機構：制度の概要：ITストラテジスト試験

IPA 独立行政法人 情報処理推進機構：制度の概要：プロジェクトマネージャ試験

【1】ストラテジストとプロジェクトマネージャでは、担当するプロセスのレイヤが異なる。

プロジェクトマネージャの担当領域は、個別プロジェクトのキックオフからリリースまでが一般的だ。
たとえば、SIerのプロジェクトマネージャであれば、請負契約でシステム開発を請け負っているはずだ。

一方、ストラテジストの担当領域は、複数のプロジェクトの内容が固まってRFPやプロジェクト計画書が完成するまでの企画フェーズと、プロジェクトが完了してリリースしたシステムが稼働した後の効果検証フェーズの2つだ。

たとえば、ユーザ企業の事業戦略に基づき、その事業を成功するためのシステムを構築したり、事業を支える業務を支援するシステムが必要になったとする。
事業の規模や業務の規模が大きければ、複数のシステムを構築する必要があるから、複数プロジェクトを並行で走らせる計画を作る。
そういう複数のプロジェクトではそれぞれ、どんなシステムが必要なのか、いつまでにシステムをリリースする必要があるか、を決める。
一般に企画フェーズで、事業戦略に基づくシステム化構想が練られることになる。

さらに、そのシステムをリリースした後、当初想定していた投資対効果が得られているか検証し、さらに改善していく必要がある。
それがリリース後の効果検証フェーズになる。

すなわち、ストラテジストの役割は、プロジェクトマネージャにプロジェクト計画書をお膳立てすることと、プロジェクトマネージャがリリースしたシステムが経営戦略の目標に合致しているか検証することになる。

ストラテジストはシステム化計画とシステムの効果測定だけであり、プロジェクトの実行フェーズはプロジェクトマネージャに委ねる。
よって、ストラテジストとプロジェクトマネージャの担当領域は明確に異なる。

【2】ストラテジストとプロジェクトマネージャでは、彼らの評価指標が明確に異なる。

プロジェクトマネージャは既に決められたQCDを元にリリースする責務がある。
たとえば、SIerのプロジェクトマネージャならば、ユーザ企業と握ったRFPを元に、初期投資予算、マスタスケジュール、体制図、システム要件が基本は確定した範囲内で、それを具体化してシステムとしてリリースする責務がある。
つまり、プロジェクトマネージャの評価指標は、当初決められたプロジェクトのQCDとの差異分析で決まる。

一方、ストラテジストは事業戦略に基づくシステムを構想したからには、そのシステムが事業に貢献したという投資対効果、つまりROIがストラテジストの評価指標になる。

たとえば、ユーザ企業が新規顧客を開拓するような新規事業を実行しようと決めて、ECサイトが必要になったと検討したとする。
ストラテジストは、そのECサイトは5カ年計画でどれだけの売上と営業利益を確保できるか、初期投資で数千万円や数億円をかけて投資してどれだけ売上を確保できるか、売上と営業利益のシミュレーションを計画する。
その売上を確保するには、ECサイトにはどんなシステム要件、業務用券が必要なのか、洗い出して確定する。
そして、そのECサイトの構築をプロジェクトマネージャに委ねてリリースしてもらった後、数ヶ月や数年をかけて、ECサイトの売上や利益を計測していく。
当初の計画と5カ年の実績の差異分析、つまり投資対効果がストラテジストの評価指標になる。

プロジェクトマネージャの評価指標がプロジェクトのQCDである事実より、プロジェクトマネージャへのプレッシャーはとても大きい。
しかし、ストラテジストの評価指標がシステムの投資対効果である事実を考えると、ストラテジストへのプレッシャーの方がはるかに大きいと思う。
なぜならば、プロジェクトマネージャの担当範囲は所詮、個別プロジェクトだけだが、ストラテジストの担当範囲は事業目標を達成するために平行に走らせるように計画された複数プロジェクトなのでとても広いからだ。

【3】ストラテジストとプロジェクトマネージャでは、利用するモデルや管理手法が明確に異なる。

プロジェクトマネージャは当初定められたプロジェクトのQCDを守るために、WBSとガントチャートによる進捗管理と課題管理が必須だろう。
もちろんそれ以外にも変更管理、品質管理など色々あるが、PJ管理手法のベースにはWBSとガントチャートがある。

一方、ストラテジストは、事業目標よりブレイクダウンされたシステムの投資対効果を達成するために、CSFとKGI、KPIのPDCA管理が必要になる。
事業目標を達成するために、BSCのように財務・顧客・業務・組織と人材の観点での中間目標（CSF）に分解したり、事業部内の各部署に業務分掌となる達成目標（CSF）が定められることになるだろう。

このCSFの考え方は、WBSみたいなものだ。

ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1～CSFはWBSみたいなものと捉える: プログラマの思索

そして、CSFという中間目標を達成できたか否かを定量的に判断するために、KGI/KPIが必要になる。

たとえば、売上や利益の確保という財務レイヤの最終目標に対し、売上高や営業利益率というKGIが出てくる。
そのKGIを達成するには、顧客や市場の観点で、新規顧客獲得数や購買単価、顧客満足度などのKPIが出てくる。
たとえば、BtoCビジネスのECサイトで出てくるAARRRも該当するだろう。

それらを実現するためにさらに業務レイヤで、顧客訪問回数、受注獲得率、顧客提案回数、業務効率化につながる工数削減の度合い、作業時間の短縮度合いなどのKPIも出てくるだろう。
さらに、それらの業務を実行する人材や組織の観点で、有能な人材を示す専門資格者数、研修回数、社内教育、従業員エンゲージメント率などのKPIも出てくるだろう。

つまり、ストラテジストが計画した諸々のシステムは計画時点でそれらKGI/KPIの目標値が設定されて、リリースされたシステムが稼働している間、KGI/KPIをシステムで自動的に測定して、投資対効果を評価することになる。

【4】自分がJavaアプリ開発者だった頃、プロジェクトマネージャの仕事ぶりは実際に見ることができたから、彼らの役割や責務は想像することができた。
しかし、ストラテジストを実際に見かける機会はなかったから、彼の役割や責務を想像することは難しかった。

ストラテジストはユーザ企業の経営戦略や事業戦略をベースにシステム化構想を検討するので、MBAで出てくるような経営戦略ツールを使って、外部環境・内部環境分析を行い、経営課題やCSFを洗い出す技法が必要になる。
つまり、ストラテジストに求められるスキルには、経営課題を解決するためのシステムの骨格を生み出すためにシステムアーキテクトのスキルは必要な前提の上で、外部環境・内部環境分析と経営課題・CSFを確定するための経営戦略ツールも必要になってくる。

たとえば、外部環境分析なら5Fs, PEST分析、内部環境分析ならVRIO分析やバリューチェーンなどのフレームワークを使う。
たとえば、経営課題の抽出であれば、SWOT分析で各要素を洗い出した後、経営戦略の方向性や企業の制約条件を元にクロスSWOT分析から、あるべき姿という経営課題を洗い出す。
その経営課題をCSFへ置き換えたり因果関係にまとめてBSCに当てはめて、各レイヤや各部署のCSFとKGI/KPIに落とし込む。
そこから、どんなシステムが必要になるか、複数個のシステムを洗い出して、具体的なシステム化計画を策定していく。
たぶんそういう流れ。

よって、ストラテジストの所在はユーザ企業の経営層や経営企画部、事業企画部、情報システム部門の領域にある。
つまり、SIerの中の一人の開発者から見れば、ストラテジストははるか遠くのところに位置しているので、彼らの目に止まりにくい。

【5】しかし、アプリ開発の専門技術者とプロジェクトマネージャ、ストラテジストは役割が異なるだけであって、そこに優劣があるわけではない。

実際にシステムを構築するために、システムアーキテクト、ネットワークスペシャリスト、データベーススペシャリスト、エンベデッドスペシャリスト、セキュリティスペシャリストなどの各専門技術者も必要だ。
色んな専門スキルを持つ人達が集まって、彼らが一つのチームとして形成して初めて、一つのシステムのリリース、さらには事業目標が達成される。

現代のシステム開発は色んな領域の専門家集団が必要であり、彼らがチームとして成り立ち、協働することが必要になっているわけだ。

UMTPモデリングフォーラムのパネル討論の感想

先週11/24に行われたUMTPモデリングフォーラムのパネル討論だけを聞いた。
ラフな感想をメモ。

【参考】
MF2022プログラム - UMTP 特定非営利活動法人UMLモデリング推進協議会

30、50、100人の壁の正体｜山本 正喜 / Chatwork CEO｜note

データモデリングの立場の中山さん、渡辺さんに対し、ドメイン駆動設計の増田さん、スクラムの原田さんという割りと立場や意見も異なる人達の討論だった。
話は色々あったが、その中で気になった点は2つある。

1つは、少人数のベンチャー企業から大人数の大企業へ進化する時にどんな壁があるのか？

スパン・オブ・コントロールの原則通り、1人の社長が統率できる人数はせいぜい5～7人まで。
そこから20名、50名、100名、300名と増えるごとに、ピラミッドのような階層構造を持つ組織になっていく。
すると、必ずその会社特有の業務システムが必要になってくる。

興味深かったのは、30名未満の少人数ベンチャー企業が、従業員数よりも多い個数のSaaSを運用している会社があるよ、という話。
おそらく、10名未満の少人数ベンチャー企業であれば、自社だけに作り込んだ業務システムは不要であり、SaaSを導入するだけで十分やっていけるだろう。
しかし、事業や業務がどんどん拡大していき、従業員も増えるが、それ以上に業務が複雑化して、その業務を支えるSaaSを次々に導入して運用してしまった。
しかし、SaaSにインポートするデータは、各事務員がExcelで作りこんで準備して取り込んで修正する作業を行っている、と。
これは、いわゆる「人間バッチ」と同じですね、と。

「人間バッチ」と揶揄する理由は、本来は事業や業務を回すための業務システムを独自に作って自動化する必要があるのに、それをさぼって、事務員が労力をかけて業務データをExcelで作り込んでSaaSに流し込むという手作業をこなっているからだろう。
結局、今はどんな企業であれ、税務会計だけでなく、事業や業務を回すためのシステムも必要になっているわけだ。

そんな状況ではデータモデリングがとても威力を発揮すると思う。
なぜならば、業務を回すための仕組みを分析するには、業務フローだけでなく、事務員が作り込んでいるExcelデータを抽象化したデータモデルが必要になってくるからだ。
そのデータモデルさえきちんと分析できれば、業務フローも画面もバッチも帳票もほぼ決まってしまう。
業務分析とデータモデリングは表裏一体と思う。

もう一つは、データモデリングが業務分析、ビジネスモデルの分析でとても有用なのに、なぜその技術が普及せず、軽んじられているのか？

パネラーの方も色々話されていたが、僕は本当の原因が他にあるような気がした。
単にIT技術者や事務員にデータモデリングの知識が足りないから、だけではないだろう。
データモデリングを習得するモチベーションがそもそもないことに真因があるだろう。

特に昨今のアジャイル開発に興味を持つ人であれば、古臭いデータモデリングよりもドメイン駆動設計の方に惹かれるだろう。
実際、増田さんが主催されるドメイン駆動設計の勉強会にはたくさんの開発者が集まるのに、データモデリングの勉強会はあまり開催されていないし、開催されたとしても正直あまり人は集まらない。

それはなぜなのか？
その理由は僕もわからない。
このテーマは今後も考えてみたい。

【追記】
@sakabaさんからこんなコメントを頂いた。

さかばさんはTwitterを使っています: 「@akipii 開発者がソフトの寿命を短く考えがちなことや、利益が出てから作り直した成功例のあることが根底にあると思います。このため目先の利益を得ることに走りがちで、モデルが後回しになっていると思います。」 / Twitter

ベンチャー企業では売上重視のビジネスモデルなのでSoEのようなWebサービスのシステム開発が中心になる。
一方、大企業になって安定してくると、社内の業務を安定して回す基幹系システム（SoR）が重要な役割を占めてくる。
つまり、ベンチャー企業では、社内の業務システムが必要になる状況になるまでは、基幹系システムは作らないし、作る必要がないと認識しているのだと理解した。

Go言語でできることは何なのか

Go言語でできることは何なのか、について考えたことをメモ。
全くのGo初心者がいろいろ考えたことのメモ。
間違えていたら後で直す。

【参考】
とほほのGo言語入門 - とほほのWWW入門

Go言語（golang）とは？ 特徴・できること・将来性を徹底解説 | 【テックストックMAGAZINE】エンジニア向けスキル・キャリア情報

Go言語にできることってなに？人気の理由をくわしく解説 | 株式会社パソナ（旧パソナテック）｜ITエンジニア・ものづくりエンジニアの求人情報・転職情報

Go言語の強みと得意分野を探る（上） - Go言語の強みと得意分野を探る：Computerworld

Go言語の強みと得意分野を探る（中）１ - Go言語の強みと得意分野を探る：Computerworld

Go言語の強みと得意分野を探る（中）２ - Go言語の強みと得意分野を探る：Computerworld

Go言語の強みと得意分野を探る（下） - Go言語の強みと得意分野を探る：Computerworld

Go言語でできることとは？Go言語で作れるアプリの事例を紹介 | プログラミング大陸

Ruby->Go->Scalaという習得順序がエンジニアの爆速の成長に最適である理由 - Qiita

Go言語の書籍を色々読んでみて色々気づきはあった。

Go言語は、マイクロサービスアーキテクチャを実装するプログラミング言語であるらしい。
色々記事を読んでみて、Go言語は、CLIやAPIを作るのに最適な言語であると感じた。

他システムがWebサーバーからデータを取得したり更新しようとする時、APIという公開IFを設けて疎結合な設計にしたい。
Go言語であれば簡単にHTTPでやり取りできるのでWebサーバを立ち上げる必要もなく、普通のクライアントアプリケーションみたいに作ればいい。
また、Go言語では並行プロセスの実装も割と簡単なので、負荷に応じてプロセスを増やせば良く、クラウド上でAPIを公開するためのアプリとして最適。

Go言語でCLIを作るイメージは、Unixコマンドを作るイメージだろうか。
Unixであれば、/binの中に各種コマンドがexeで配置されている。
別システムがバッチ処理をキックしてシステム連携したい場合、CLIという公開IFを叩けば良い。

そんなことを考えると、Go言語はかなり特殊な状況で使うもののように思う。
業務ロジックを実装するレイヤではなく、OSやアプリの間で処理するためのミドルウェア、ないしフレームワークみたいな役割を持つレイヤで実装すべき。

また、Go言語はクラウドと相性がいい。
Go言語はクロスプラットフォームでバイナリファイルを作れるので、CLIやAPIに向く。
また、Go言語で作ったバイナリファイルのサイズを小さくできれば、クラウドのリソースを少なく押さえられる。
また、メソッド呼び出し時のアプリ起動時間を短くでき、並行プロセスで走るアプリの起動時間（ロード時間）も短くできる

クラウド上の開発がJavaに与えた影響は何なのか: プログラマの思索

Javaのモジュールシステムの考え方をまとめてみた: プログラマの思索

つまり、Go言語はクラウド上でCLIやAPIを実装したプログラムに特化した言語なのだろう。
だから、マイクロサービスアーキテクチャと相性が良いと言われているのだろう。
そして、マイクロサービスアーキテクチャはドメインごとの境界で使われるので、ドメイン駆動設計とも相性がよく、それらの設計技法と密接に絡む。

そんなことを考えると、一昔前のオンプレ環境でのWebシステム構築で経験されて蓄積されたアーキテクチャ設計技法は古くなっており、クラウドに特化したアーキテクチャ設計技法をもっと探究していくべきだ、という方向性が出てくるのだろう。
このあたりの考え方もいろいろ調べている。

クラウド上の開発がJavaに与えた影響は何なのか

クラウド上の開発がJavaに与えた影響は何なのだろうか。
考えがまとまっていないがラフなメモ。
自分はAWSも知らないし、Go言語も知らないので、間違っていたら後で直す。

【参考】
Javaがサーバレスに至るまでの道のり

元JavaエンジニアがGoに感じた「表現力の低さ」と「開発生産性」の話 - DMM inside

Ruby->Go->Scalaという習得順序がエンジニアの爆速の成長に最適である理由 - Qiita

Javaがサーバレスに至るまでの道のりの記事を読むと、いかに軽量のWebアプリケーションを実現するか、に注力しているように思える。

従来のWebアプリケーション開発では、PerlのCGIのようなプロセス指向ではなく、JavaのServletのようなマルチスレッドの方が無駄にリソースを食わず、効率が良いと歌われていた。

しかし、サーバーレス環境では、AWS Lambdaのようにアプリをキックするような仕組みなので、アプリの処理時間だけでなく、アプリのロード時間も短いほど優位だからだ。
サーバーレス環境では、アプリを常駐させて、マルチプロセスで動く。
そして、処理が終わり、無駄に多くなったプロセスはすぐに破棄される。

つまり、クラウドでは、DockerやK8sのようなコンテナのおかげで、アプリ環境を使い捨てにできるメリットがある。
アプリも、負荷分散に応じて必要なだけ常駐プロセスを増やして、不要になれば捨てればいい。

すると、アプリのビルド、デプロイの時間も短い方がいい。
さらに、「起動時間がレスポンスタイムに含まれる」ために、アプリの起動時間も短くできれば、サーバーレス環境ではレスポンスタイムをもっと短くできて、使い勝手が良くなる。

そういう発想がJavaにどんな影響を与えているのか？
クラウド上の開発がJavaに与えた影響は何なのか？

たまたま、Javaのモジュールシステムの話の中で、jlinkコマンドがなぜ必要なのか？という話があった。
JDK9以後は、JREが配布されないので、Javaファイルを実行できない。
そこでjlinkで実行ファイルを作る必要があるという話だったが、さらにもう一つ興味深い話があった。

Java Module System 入門 その1 - YouTube

Java Module System 入門 その2 - YouTube

jlinkコマンドを使うとランタイム専用アプリを作れるが、必要なJDKライブラリだけを読み込んで、Jarファイルを作成する。
すると、jlinkで作られたランタイム専用アプリのサイズは、従来のランタイム専用アプリのサイズよりもかなり小さくなる。
不要なライブラリを除いているからだ。
実際、デモ画面では200Mから30Mまで小さくできた例があった。

つまり、jlinkコマンドを使えば、クラウドのサーバーレス環境でアプリを実行する時、コンパイルしたアプリのサイズを小さくできる。
その分、クラウドのリソースを抑えられるし、アプリの起動時間（ロード時間）も短くできるメリットが出てくる。

すなわち、jlinkコマンドはクラウド上で配布するアプリに適合するように作られたものなのだろう。
Javaもクラウドに特化したアーキテクチャ設計を取り込んでいるのだろう。

そんな話を聞くと、サーバーレス環境のアプリでは、ランタイム専用アプリはバイナリファイルでサイズが小さいほど優位性が高いことになる。
マイクロサービスの実装言語はGoが主流であると聞くが、その理由は、Goで簡単にバイナリファイルが作れて、さらにそのサイズが小さいので、性能的にも優れている点があるのではないだろうか？
そして、Javaもそういう流れの設計手法を取り入れるために、jlinkコマンドのようなアーキテクチャが必要になってきたのではないだろうか？

ここで、クラウド上のシステム設計では、ドメインごとにアプリを細分化したマイクロサービスアーキテクチャが流行していて一般的になってきている。
マイクロサービスアーキテクチャが必要な理由は、普通のWebシステムでもクライアントからのアクセスがブラウザだけでなく、スマホだったりタブレットだったり、色んな端末に対応する必要があるので、公開APIを通じて制御できるよに、色々分割したほうが楽になる点があるだろう。
また、逆コンウェイ戦略のように、システム開発しやすいチーム組織の観点で設計すると、小さなコンポーネントの集まりになるようにシステムを分割して、マイクロサービスアーキテクチャで連携できるようにした方がよい点もあるだろう。

マイクロサービスアーキテクチャのそんな特徴を活かすには、おそらく、Go言語やjlinkコマンドのような実装言語やビルド方法も必要になってくるのだろう。

そんなことを考えると、クラウド上のシステム開発では、フロントWebシステムをRubyやJava、Pythonで作ったとしても、AWS lambdaやマイクロサービスの部分はGo言語やjlinkを使う、といったように、複数のプログラミング言語を適材適所に当てはめて開発する必要性があるのではないか。
つまり、クラウド上の開発は、単にコンテナ部分のアーキテクチャを使いこなすだけでなく、複数のプログラミング言語を適材適所で使い分けるノウハウも必要になってくるのだろう。

この辺りは妄想に近いかもしれないので間違っているかもしれない。
ただ、クラウドというアーキテクチャは、Webリソースをふんだんに使える富豪プログラミングを可能にしたからこそ、それに特化した設計手法がどんどん現れているのだろうと思う。

この発想が正しいのか、これから検証していく。

「ソフトウェアアーキテクチャの基礎」本はアーキテクトが読むべき本だった

ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ 著者 : Mark Richards オライリージャパン 発売日 : 2022-03-08 ブクログでレビューを見る»

「ソフトウェアアーキテクチャの基礎」は良い本と思う。
アーキテクトが読むべき本だったと思う。
ラフなメモ。

【1】ソフトウェアアーキテクチャの定義とは何か？
以前の定義は、ソフトウェアアーキテクチャとは後から変更することが難しいモノだった。
しかし、今は、マイクロサービスの出現により、変化しやすい設計を指すようになって、ガラリと変わった。

【2】アーキテクチャの重要な要素は、トレードオフの決定だ。
品質、コスト、スケジュール、スコープのバランスから、一番最良のものを選ぶ。
それぞれの要素を最大限にするのではなく、トータルでバランスが取れているものを選ぶ。

【3】アーキテクトに期待されている役割。

アーキテクチャ決定を下す。
アーキテクチャを継続的に分析する。
アーキテクチャの最新のトレンドを把握している。
アーキテクチャ決定の順序を徹底している。
様々な技術に精通している。
事業ドメインに詳しい。
対人スキルや政治力を持つ。

【4】ソフトウェアアーキテクチャを語る上で、XPの偉大さがある。

XPでは、プロセスよりも経験的に知られていたプラクティスを重視した。
たとえば、テストが多いほど品質が良くなる経験から、テスト駆動を生み出した。
継続的インテグレーション、コードの共同所有、継続的デプロイなど。

【5】ソフトウェアアーキテクチャの法則は2つ。

1つは、トレードオフが全て。
トレードオフが見つからないならば、分析が不十分な事実を知るべきだ。

2つ目は、HowよりもWhyが大事。

【6】モジュール性とは何なのか？

モジュール分割するアーキテクチャのテクニックの利点は分かる。
しかし、モジュールの実現方法はあまり知られていない、とメイヤーは言った。
この話は、コンポーネント志向につながる。

Javaならば、当初のJDKはパッケージで分割した。
しかし、それだけでは扱いづらいので、Jarというコンポーネントが導入された。
しかし、Jar同士でパッケージ名が衝突する場合があるから、module systemがJava9から導入された。
つまり、Javaもモジュール性の実装方法に苦労している。

【7】本の途中のコラムがとても参考になる。

【7-1】スウェーデンで軍艦ヴァーサ号を製造したが、初めて処女航海に出ようとした時に、すぐに港で沈没した話。

失敗の原因は、アーキテクチャ特性を全部盛り込みすぎて、軍艦が重すぎてしまい、バランスが取れなくなり沈没した。
数多くの利害関係者の要求を最新鋭の軍艦に盛り込んだために、軍艦として実現できなかった。

今のソフトウェアアーキテクチャの話も同じ。
ユーザのたくさんの要望を盛り込みすぎると、結局使い勝手の悪いシステムになってしまうし、それ以前にスケジュールが伸びすぎて永遠にリリースされないシステムになるリスクすらある。

【7-2】ドメイン駆動設計の意義は、境界づけられたコンテキストという概念により、アーキテクチャ設計手法が大きく変わった点にある。

ドメイン駆動設計の出現以前は、組織内の共通エンティティは再利用を重視していた。
しかし、再利用を重視しすぎて、ビルドが困難になり、チーム間の調整が難しくなり、ソフトウェアの複雑さが増大し、多くの問題を引き起こした。
たぶん、ソフトウェアプロダクトラインの話も同じ。

ドメイン駆動設計の出現後、境界づけられたコンテキストの考え方により、各エンティティは局所化されたコンテキストの中で最もよく機能すればいい。
つまり、組織全体の共通エンティティは不要であって、問題領域ごとにエンティティを自由に作り、その中で最適化されたエンティティを作ればいい。
問題領域のドメインの境界上で調整すればいい。
つまり、この考え方がマイクロサービスにつながるわけだ。
マイクロサービスの実装言語はGo言語が主流である。

各ドメイン内のシステムはRailsだったりPythonだったりPHPでもよく、複数のプログラミング言語で作られたシステムとGo言語によるマイクロサービスがAWSのようなクラウド上で動くアーキテクチャが多いわけだ。

【8】コンポーネント設計では、分割の観点は何か？

コンポーネント設計とは、アーキテクチャの分割であるという考え方。
レイヤーアーキテクチャがよく使われる。
たとえば、Javaの依存性注入（DI）、DLLやJarなどのコンポーネント。

この考え方を進めると、開発スタイルはコンウェイの法則に縛られることになり、複雑な組織構造が反映された複雑なアーキテクチャになってしまう。
だから、逆コンウェイ戦略という考え方が出てきた。

一方、コンポーネント設計とは、ドメインによる分割であるという考え方。
これはドメイン駆動設計であり、マイクロサービスアーキテクチャにつながる。

ドメインごとに開発チームを作ることにより、コンウェイの法則のリスクを避けられる。
逆コンウェイ戦略をそのまま実現しやすい。

【9】アーキテクチャスタイルとは、アーキテクチャのパターン集。

モノリシックアーキテクチャと分散アーキテクチャに分かれる。

モノリシックアーキテクチャ：

レイヤーアーキテクチャ　→TCP/IPとか。
パイプラインアーキテクチャ　→Unixとか。
マイクロカーネルアーキテクチャ　→コアシステム＋プラグインの構造。Eclipse、Jira、Jenkinsとか。

分散アーキテクチャ：

サービスベースアーキテクチャ　→フロントエンド＋バックエンド
イベント駆動アーキテクチャ　→デスクトップアプリ。非同期システム。
スペースベースアーキテクチャ　→ロードバランサー。インフラの仮想化。クラウド。
オーケストレーション駆動サービス指向アーキテクチャ　→よく分からない。使われない。
マイクロサービスアーキテクチャ　→ドメイン駆動設計とか。

分散アーキテクチャが今の流行だが、8個の誤信がある。
ネットワークは信頼できる。
レイテンシーがゼロ。
帯域幅は無限。
ネットワークは安全。
トポロジーは決して変化しない。
管理者は1人だけ。
転送コストはゼロ。
ネットワークは均一。

他にも、分散ロギング、分散トランザクションなどもある。

これらの観点をトレードオフとして考えるべき。

組込みソフトウェア開発でUMLを使う手法を説明した書籍のリンク

組込みソフトウェア開発でUMLを使う手法を説明した書籍のリンクがあったのでメモ。

【参考】
組み込みUMLでの、分析モデリングでのクラスの識別アプローチについて文献まとめ - 千里霧中

組込みソフトウェア開発と設計をちょっと調べている。
やっぱり設計手法にはUMLを使っている方が僕は理解しやすい。
それに関する書籍のリンクの記事があったので、メモしておく。

【１】組込みソフトウェア開発のためのオブジェクト指向モデリング (組込みエンジニア教科書) | SESSAME WG2

この本はとても分かりやすかった。
湯沸かしポットを題材として、実際にクラス図、状態遷移図まで落とし込んでくれている。
この本の感想は以前書いた。

組み込みソフトウェアの根本問題～対象物の状態遷移を記述できれば、制御が可能だ: プログラマの思索

組込ソフトウェア開発のための3部作「構造化モデリング」「オブジェクト指向モデリング」「リバースモデリング」を読んでいて楽しい: プログラマの思索

【２】リアルタイムUML―オブジェクト指向による組込みシステム開発入門 (Object Oriented Selection) | ダグラス,ブルース, Douglass,Bruce Powel, 博之, 渡辺, 株式会社オージス総研

【３】リアルタイムUMLワークショップ | ブルース・ダグラス, 鈴木 尚志

持っているけど理解できていない。

【４】組み込みUML―eUMLによるオブジェクト指向組み込みシステム開発 (OOP Foundations) | 博之, 渡辺, 和人, 堀松, 政彦, 渡辺, 和記, 渡守武

古本屋で見たことがある。
今度読んで見る。

【５】UML動的モデルによる組み込み開発―分析・設計・実装・テスト | 政彦, 渡辺, 哲史, 石田, 康二, 浅利, 周作, 飯田, 修二, 山本 | Amazon

今度読んで見る。

【６】オブジェクトデザイン (Object Oriented SELECTION) | レベッカ・ワーフスブラック, アラン・マクキーン, 株式会社オージス総研 藤井 拓, 株式会社オージス総研 藤井 拓, 辻 博靖, 井藤 晶子, 山口 雅之, 林 直樹

オブジェクト指向設計のうち、責任の割当に注力して書かれている。

【７】実践UML 第3版 オブジェクト指向分析設計と反復型開発入門 | クレーグ・ラーマン, 依田 智夫, 今野 睦, 依田 光江

僕は第１版、第２版を読んだ。
第１版では「オブジェクト指向設計の肝はコラボレーション図（協調図）です」という一節がすごく心に響いた。
クラスへ責務を割り当てるときに、UML2.0ならコミュニケーション図を書いて、責務が集中しないように疎結合にしたり、関連する責務は集めて凝集度を高くする、などのアドバイスがあった。

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

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

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

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

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

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

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

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

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

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

事業活動のシステム化は非差別化しない汎用ドメインや支援ドメインに注力すべき

ドメイン駆動設計勉強会に参加してみて、事業活動のシステム化は非差別化しない汎用ドメインや支援ドメインに注力すべきという指摘になるほどと思えたのでメモ。
ラフなメモ。

【参考】
【ドメイン駆動設計勉強会】事業活動を理解して設計しよう！ - connpass

増田さんの講演がすごく分かりやすかった。
問題意識は、事業活動をどのようにモデル化していくか？
事業活動をシステム化する時に、どこに注力すればいいのか？

まず、自社と外部の事業活動は、ピクト図で商品やお金の流れをシーケンス図のように表して、モデルにする。
自社の内部プロセスは、ポーターのバリューチェーンを使って、主活動と支援活動に分類する。

ドメイン駆動設計のアプローチでは、バリューチェーンの主活動や支援活動をサブドメインに分割する。
すると、基本は、主活動は企業価値を生み出すコアドメイン、支援活動は管理業務等の支援ドメイン、汎用ドメインになる。

ビジネスロジックの複雑度や差別化の重要度の観点では、コアドメインが重要であり、支援ドメイン、汎用ドメインの順になる。
一般に、汎用ドメインや支援ドメインの品質は当たり前品質で十分であり、コアドメインの品質は魅力的品質まで高める必要がある。

増田さんの講演でもっとも興味を引いた発言は、増田さんの経験では、事業活動のシステム化では、他社との差別化につながるコアドメインよりも、他社と差別化しなくて良い支援ドメインや汎用ドメインに注力すべき場合が多かった、という内容だった。
なぜならば、他社と同じような業務では、汎用ドメインや支援ドメインで構築すれば安く仕上がるし、その分野の人材も市場から確保しやすいからだ。
そもそもそういう分野では差別化せず、市販のサービスやパッケージをそのまま流用すればいい。

また、自社の弱点として実は、支援活動の業務があるケースが多いらしい。
すると、支援活動のシステム化に注力した方が投資効果が大きいらしい。
なぜなら、支援活動にある総務・財務・人事などの部門の業務は既存のパッケージ製品が多数あるからだ。

一方、本来の自社で価値を生み出すコアドメインは、独自のシステムになるから、コストをかけて当たり前品質以上の魅力的品質まで作り込むべきだ、という流れだと理解した。

一般に、支援活動にある総務・財務・人事などの部門の業務はどこの会社でも似たような内容であり、財務報告も法律で決められた書式で報告する必要があるから、できるだけ汎用ドメインで構築した方が運用が楽だし、コストもかからない。

むしろ、コストを掛けるべき部分はコアドメインであるから、汎用・支援ドメインにはコストを掛けずにメリハリを付けた方がいい。
そんな内容だと理解した。

たぶん、一般に、支援活動の業務は汎用のERPで導入した方が良いのだろう。
今ならば、汎用的なSaaSを導入すればいいのだろうと思う。

普通は、コアドメインに当たる主活動のモデル化に注力したくなるが、むしろ、支援・汎用ドメインに当たる支援活動のモデル化の方に企業の問題がある場合が多く、投資効果が大きいという経験談が面白かった。