Agile開発に足りないもの～モデリング技術

@hatsanhatさん、@sugimoto_keiさんと議論していて、TiDD＋DOAで開発できないか、と考えたことをメモ。
ラフなメモ書き。
下記はあくまでも僕の一意見。
間違っていたら後で直す。

【1】「DOAとRailsは相性が悪い」という意見はよく知られている。
でも、逆に、Railsだからこそ、DOAがより重要になってきた気がしている。
RailsでWebアプリを作っていると、どのようなテーブル設計が良いのか、という問題に結局ぶち当たる。
更新時異常が発生しないようなテーブルを設計するのは、そんなに簡単な技術ではない。
以前、Ruby関西の勉強会でも渡辺さんが講演した時もあったが、その講演の発端もその問題にあったのだろうと思う。

丁度それは、Agile開発がシステム開発をHowの問題に落とせれば高速・高品質に開発できるけれども、WhatやWhyの部分ではまだ手持ちの武器が少ない状態に似ていると思う。
最近は、XPのオンサイト顧客の概念を発展させて、Scrumがプロダクトオーナーと呼ばれる役割を提唱しているが、ユーザにいきなりプロダクトオーナーの役割を求めるのは非現実的な場合が多いと思う。

なぜなら、ユーザに自分たちの業務をモデリングできるレベルを要求しているから。
つまり、ユーザに、ビジネスをITの言葉で翻訳するアーキテクトの役割をいきなり求めているから。
ユーザは自分たちの業務は詳しいだろうが、それをソフトウェアという一つの論理モデルへ抽象化する技術は又別の技術だ。
それはモデリングの範疇だろうと思う。

【2】ユーザにプロダクトオーナーの役割を求めることやAgileな契約作りの前に、開発チームにはやるべき作業がまだたくさんあると思っている。
僕はSW技術者だから、まず技術にこだわりたい。
Agile開発しやすいビジネス環境があったとしても、肝心の技術力が低ければ無意味だ。
実際、WF型開発しか知らない開発チームがいきなりAgile開発を実践しようとしても、契約以前に技術上の課題がたくさんある。

そもそも、ユーザの業務をモデリングして、ストーリーを引き出すのが難しい。
そして、引き出したストーリーを1ヶ月単位で頻繁にリリースするのは、たとえAgile開発であってもそう簡単な技術ではない。

前者の問題に対しては、牛尾さんはAgileTourOsaka2010で、プロダクトオーナーに必要な技術として、ストーリー供給力とストーリー検証力という概念を提唱された。

Agile Tour 2010 Osakaで講演してきました - メソッド屋の日記

僕の解釈では、ストーリー供給力は文字通り、ストーリーをユーザから引き出す能力。
普通は、スプリント0ないしアーキテクチャスパイクの期間で、開発対象の8割ぐらいのストーリーを引き出さないといけない、と言われていたように思う。

ストーリー検証力は、ストーリー間の整合性をチェックしたり、ストーリーがユーザのビジネスの目的に合致しているか、という能力。
ストーリー間の整合性チェックは、リリースの優先順位に密接に関係する。それはチケットの優先度(開発チーム観点の作業の優先順位)で表現できるだろうと思う。
ストーリーとビジネスの目的の整合性チェックは、リリース後の売り上げや削減コストの計測のようなKPIやKGIで実際に評価できるだろうと思う。
それはチケットの重要度(ユーザ観点のビジネス上の優先順位)で表現できるだろうと思う。

後者の問題に対しては、頻繁にリリースできる開発環境が必要で、チケット駆動開発がその解決手段の一つになるだろうと思っている。
最終的には、月曜にストーリーをもらって金曜にはリリースできるように、1週間単位で本番リリースできる環境と技術がなければ、Agile開発をいくら実践したくても無理だろうと思う。

【3】モデリングそのものに関する問題は、オブジェクト指向分析では、ドメイン駆動に関する優れた本が出ていて、モデリング技術を補完してくれている。
特に、「エリック・エヴァンスのドメイン駆動設計」と「アナリシスパターン」の2冊の知識は、オブジェクト指向分析で要件定義しようとするときに必須だろうと思う。
だが、その2冊の本を読んでみると、DOAの技術から発展しているようにも読めるし、その概念モデルの背後には会計の概念が隠れていることに気づく。

@sugimoto_keiさんがTwitterで「エリック・エヴァンスのドメイン駆動設計」の感想を書かれていて、それを理解しようとしたら、オブジェクト指向分析(OOA)でもその概念モデルの背後に簿記のモデル(例：荷為替手形、経過勘定科目(前払保険料など))が出ているのに気づいた。

Twitter / @sugimoto_kei: （モデルと現実⑦）Eric Evans 氏が Domain-Driven Design 本で、「浅いモデル」と「深いモデル」を区別している（原著P190）。でも本当は彼が挙げた貨物配送の２つの違いは深さでは無くて、前者はビジネスの、後者は帳簿のモデルであるということだと思う。

Twitter / @akipii: @sugimoto_kei @hatsanhat　とても勉強になります。DDD本では貨物輸送システムのモデルに出てくる貨物の移動オブジェクトは最終的に船荷証券オブジェクトに変わったとありますが荷為替手形の事ですね。219頁の発生主義会計は経過勘定科目を指すと考えられますね(続く)

「エリック・エヴァンスのドメイン駆動設計では、貨物輸送システムのモデルを洗練させると、船荷証券(荷為替手形)というオブジェクトが主要な役割を果たすと書かれている。
荷為替手形とは「輸出代金決済のために輸出者（売主）が振り出す為替手形に船積書類が添付されたもの」であり、下記の解説が分かりやすい。

荷為替手形を徹底解説！【簿記検定ナビ】

荷為替手形は、誰が船に積まれた商品の保全に対して責務を持っているのか、誰が船に積まれた商品を受け取る権利を持っているのか、という概念を含んでいる。
権利や責務の概念が発生する場合、そこにはビジネス(お金)が必ず絡んでいて、それは複式簿記による仕訳(債権や債務)という概念で既に実現されている。
多分、横浜や神戸のような港町の銀行が荷為替手形を扱っている場合が多いだろうと思う。

また、発生主義とは会計の一原則で「現金の収入や支出に関係なく、収益や費用の事実が発生した時点で計上する」考え方。期中の取引が過去や来期の取引に影響を及ぼす場合、経過勘定科目を使って仕訳を起こす。
つまり、お金が発生した時点ではなく、役務(サービス)の提供又は受領が発生した時点で仕訳が発生する。
ここでも、権利と義務、債権と債務の概念がモデルに絡んでいる点が面白い。

「グラス片手にデータベース設計 ~会計システム編」で会計の原則がSE向けに分かりやすく解説されている。
又、下記の解説が分かりやすかった。

経過勘定と未決済項目

業務システムのモデリング技法としては、OOAよりもDOAと簿記が一つの解決法を示唆していると思う。

そして、Agileな開発スタイルをビジネス化するよりも、優れたソフトウェア製品を作るという根本問題に立ち戻る方が重要だろうと思っている。