第60回 SEA関西プロセス分科会「納品をなくせばうまくいく～アジャイル開発のビジネスモデル！」の感想 #seakansai

SEA関西で「納品をなくせばうまくいく～アジャイル開発のビジネスモデル！」を聞いて、パネルディスカッションにも出てきた。
感想をメモ書き。

【元ネタ】
9月27日 第60回 SEA関西プロセス分科会(大阪府)「納品をなくせばうまくいく～アジャイル開発のビジネスモデル！」

第60回　SEA関西プロセス分科会のご案内　納品をなくせばうまくいく～アジャイル開発のビジネスモデル！

「納品をなくせばうまくいく」の感想part1～ソフトウェア業界のビジネスモデルが抱える問題: プログラマの思索

「納品をなくせばうまくいく」の感想part2～「納品のない受託開発」のビジネスモデル分析: プログラマの思索

「納品をなくせばうまくいく」の感想part3～「納品のない受託開発」のビジネスモデルの不明点とあるべき姿: プログラマの思索

「永和さんの「価値創造契約」が大苦戦を強いられている件」の記事がすごく参考になる: プログラマの思索

「納品」をなくせばうまくいく?アジャイル開発のビジネスモデル！ from Yoshihito Kuranuki

第60回SEA関西プロセス分科会ポジショニング資料「納品をなくせばうまくいく～アジャイル開発のビジネスモデル！」 #seaknasai from akipii Oga

【0】今回開催された発端

Twitterでsakaba37さん、@agnozingdaysさんとやり取りした結果、今回の開催となった。

akipiiさんはTwitterを使っています: "的確な表現 @sakaba37: 常駐しない保守契約という言葉が浮かびました。 RT @agnozingdays 読んだ→アジャイルサムライとは大きく異なるソニックガーデンの見積りと計画作り - give IT a try http://t.co/QYIXfk1uWO"

Kent IshizawaさんはTwitterを使っています: "@akipii @sakaba37 「納品」をなくせばうまくいく事と、「常駐」をなくせばうまくいく事と整理してみたい感じです。割とこれが混ざっている気がしています"

akipiiさんはTwitterを使っています: "@agnozingdays @sakaba37 @kuranukiさんが提唱する「納品のない受託開発」は単なるオフサイトの保守契約ではなく、ビジネスモデルの構造として、SIとエンドユーザがお互いに利益になる方向に動くような仕組みがあると思います。この辺りを整理したいですね～"

Yoshihito KuranukiさんはTwitterを使っています: "一度ディスカッションしましょうか?？ RT @akipii: @agnozingdays @sakaba37 「納品のない受託開発」は単なるオフサイトの保守契約ではなく、ビジネスモデルの構造として、SIとエンドユーザがお互いに利益になる方向に動くような仕組みがあると思います。"

akipiiさんはTwitterを使っています: "@kuranuki @agnozingdays @sakaba37 はい、是非お願いしたいです。@kuranukiさんのBlogに書かれた経営者観点の話がようやく腑に落ちてきた所があるので、整理させて欲しいです。アジャイル開発のビジネスモデルはまだまだ研究の余地があると思います"

Yoshihito KuranukiさんはTwitterを使っています: "@akipii @agnozingdays @sakaba37 SEA関西、いいっすね！企画してもらえたら行きますよ！"

【1】提起した問題

パネルディスカッションでは、以下の問題を提起した。
倉貫さんも含めて、皆と議論できるかなと思ったが、宿口さんいわく「あきぴーさんの質問は、倉貫さんのビジネスの範疇でないので空振りでしょう」とのことなので、ほとんど触れずじまい笑。

【問1】Agile開発に向く契約は何か？

【問2】ソフトウェア開発のあるべき体制は何か？

【問3】技術者のQoELを高めるには？
　※QoEL = Quality of Engineer Life (@hiranabe)

【問4】基幹系業務システムはAgile開発に向かないのか？

【問5】開発したシステムは、どちらの資産ですか？
　　ユーザ企業？　ソニックガーデン(株)？

【問6】システムの投資の回収計画は作りますか？
　　業務システムでは10年先を見越した回収計画を作ります

【問7】エンジニアの稼働率は気にしていますか？
　　弁護士や会計士のコンサルサービスに似ているならば、
　エンジニアの要員表の管理が必須になるのでは？

【問8】業務システム開発でも「納品のない受託開発」は可能か？
　　導入の前提条件は何か？　阻害条件をクリアするには？

但し、懇親会で他の参加者から感想を聞いたら、あきぴーさんと同じく、今日の参加者は業務システム開発に携わる技術者がほとんどでしょう。
だから、あの質問は倉貫さんではなく、聴衆の皆に投げかけて、もっと議論すべきだった、と言われた。
その点は今後の反省点かな。

【2】パネルディスカッションの議事録

たくさん深い議論をしたので、まとめた時に自分の意見が混じりこむのも嫌なので、メモした内容をそのままアップしておく。

【Q1】業務システムにアジャイル開発は導入できますか？
【A】業務システムは相手にしない(By　倉貫さん)
　アジャイル開発を押し売りしない
　押し売りは失敗するから

　あきぴーさんの質問は空振りするでしょう(By　宿口さん)

　「納品のない受託開発」は業種が違うという認識(By　倉貫さん)
　八百屋さんのセミナーに、レストランオーナーが来た感じ
　業務システム開発や他のSIのビジネスモデルには興味が無い。

【Q】顧客満足度は定量化してますか？
【A】顧客満足度の定量化はあきらめています
　定性データで見せてます
　事業のKPIは取ります
　(伊藤さんの話では)
　対客サービスで感じ取ります
　信頼貯金で何とかやりくりします

【Q】日本全国のITコミュニティで倉貫さんは講演されているが、どういう意図で話しているのか？
【A】ギルドを増やしたい意図もある
　エンジニアの人に知って欲しい

【Q】営業はしてますか？
【A】営業していないから(By　倉貫さん)
　お客さんが私のBlogを見ている
　Blogはマーケティングツールとみなしている
　ソニックガーデンの営業は全てインバウンド
　お客様からの問合せで受注している

　対面の営業はやっている(By 伊藤さん)
　但し、Skypeでやっている
　紙に書いて、iPhoneで写して、アップするので十分

【Q】受託開発がメインなのですか？
【A】会社の売上は、自社サービスと受託開発
　自社サービスの顧客から、受託開発を頼まれる時もある

【Q】ふりかえりはどんな感じですか？
【A】ふりかえりをワークレビューと言っている
　師匠が弟子の作業をレビューする

　仕事量を減らした方が褒められる(By　伊藤さん)
　成果の方が大事
　社員は管理職と同じ
　社員もセルフマネジメント
　給与は年俸制(By　倉貫さん)

【Q】入社したいエンジニアはどんな採用基準なのか？
【A】入門したプログラマには、Railsレベルで評価して、採用可否を検討している
　レベル5以下は、プログラマに向いていない
　他に、Rubyライブラリを知っているかどうか。
　JavaやC#から乗り換えた技術者も多数いる。
　DRYが分かっているかどうか。我々は凄く重視する。
　20レベルになれば、合格して採用する。

【Q】Railsレベルはどうやって決まっていますか？
【A】正確なレベルの評価ではない
　CTOや他のエンジニアのコードレビューでレベルを決める
　どのエンジニアがやってもレベルは似通っている
　スクラムの相対見積りに似てますね

【Q】開発したシステムは、どちらの資産ですか？　ユーザ企業？　ソニックガーデン(株)？
【A】システムはお客様の資産
　資産計上は管理会計上の話
　予算を決めて何億ものシステムを作っているわけではない

【Q】価値創造契約の話の感想は？
【A】気にしていない、というスタンス
　我々は、顧客へ価値を提供することに注力しているので、他の競合他社は気にしていない
　以前、木下さんと話した時に、ビジネスモデルは全然違うね、とお互いにそういう話になった

【Q】成果報酬契約はうまくいきますか？
【A】成果報酬契約はうまくいかない
　役割分担する所で間違っている
　ビジネスの売上は、ユーザ企業があげる
　ユーザ企業が頑張るかどうか、SIは関知しない
　SIはシステムを納品することに注力しがち
　
akipiiさんはTwitterを使っています: "受託開発のレベニューシェア契約は、ユーザ企業もSIも双方ともにWin-Winになりにくい、という記事があったけれど、何故なのか？　システムを導入した利益がどこにあるのか、が分かりにくいから。システムが良かったのか、システムによる運用が上手だったのか、判別しにくい。"

　システムから売上をあげる責任とシステムを作る責任が結局分離しているので、顧客とSIは同じゴールでない、という印象を持った(By　あきぴー)

【メモ1】AsMamaのお話
　この話は、いつも懇親会で話すネタなのだが、という前置きで。
　「PGが顧客を泣かせた」という経験がある。
　AsMama社長は、ベビーシッタが欲しいママさんとベビーシッターができる人のマッチングサイトを作りたい、という気持ちでサービスを作り始めた
　当初は、AsMama社長は、電話とメールでサービスを始めたが、規模を拡大するうちに無理になって、システム化を図ることになった
　しかし、普通のSIに持って行くと、要件定義だけでびっくりな金額を取られる提案を受ける
　我々の会社に来た時は、SI不信またはIT業界不信だった
　でも、我々は、顧客が何をしたいのか、という話から何度も聞き出してシステムを作り始めた。

　打ち合わせ中、AsMama社長は、マッチングサイト上で、地図にママさんとベビーシッターを表示できたら便利だろうに、と話した。
　そこで、顧問PGはGoogleMapのAPIでを使えばすぐに開発できる、と気付き、ファシリテーターの藤原副社長に話を向けて、二人が話している間に、顧問PGはプロトタイプの地図サービスを作った。
　PGが作った地図ービスを見て、AsMama社長は、感動して泣き出した、とのこと。
　このサービスこそ、彼女が求めていたものだったから、とのこと。

【メモ2】昔の社長は親分肌だった
　俺が、すべての社員の面倒を見るから、と。
　でも、今の情勢では言えない
　自分の会社が倒産しても、社員が自立して働けるようにするのが社長の努め

オープンソースのワークフローエンジンActivitiの感想

オープンソースのワークフローエンジンActivitiを使ってみた。

【参考】
オープンソースのワークフローエンジン「Activiti」入門 - Tech-Sketch

aegif Labo Blog: Activiti BPM Platformことはじめ（インストール方法とか）

aegif Labo Blog: Activiti BPM Platformことはじめ2（Activiti Explorerの使い方とか）

aegif Labo Blog: Activiti BPM Platformことはじめ4（レポートを追加してみよう）

aegif Labo Blog: Activiti BPM Platformことはじめ3（Activiti Modelerの使い方）

【1】インストール

Tomcatへactiviti-explorer.warをデプロイするだけ。
↓
http://localhost:8080/activiti-explorer/
へアクセス
↓
デモユーザのいずれかでログイン。パスワードは同じ。
kermit, gonzo, fozzie

fozzie：申請ユーザ
gonzo：承認ユーザ
kermit：管理者

インストールはすごく簡単。

【2】操作した画面

「Vacation request（休暇申請）」のワークフローサンプルがある。
BPMNで描かれていて、すごく簡単なワークフロー。
休暇の申請・承認をやってみる。

fozzieでログイン
↓
「プロセス」をクリックして、「Vacation request（休暇申請）」のプロセス・フローを選択
↓
休暇申請の内容を入力し、[Start process]ボタンを押下
↓
gonzoでログイン
↓
キューに1件あるので、管理(1)をクリック
↓
宣言ボタン押下
↓
Approve（承認）／Reject（却下）のいずれかを選択
↓
承認or却下が完了

【3】感想

warファイルのワークフローエンジンなので、インストールがすごく簡単。
Web画面上で、BPMNのワークフローサンプルが表示されるので、申請承認フローが誰でも分かる。
但し、承認者が誰かは出てない。

色々疑問はある。
組織人事マスタはどこから登録するのか？
その組織はどこからインポートして、ワークフローにどのように紐づけるのか？

また、Activitiと他の業務アプリをリアル連携する手法はどのように実装するのか？

オープンソースのワークフローエンジン「Activiti」入門 - Tech-Sketchを見ると、「「Activiti Engine」の２つの利用方法」の方法②として、他の業務アプリからActivitiへアクセスするパターンがある。
例えば、別の業務アプリがREST APIでActivitiにアクセスして経費申請したり、Activitiで承認したらその結果が業務アプリへ通知されて、後続の業務処理がキックされるパターンがあるだろう。
このような業務は意外に多いので、使いたい場合が多い。

そんな疑問を思い浮かべながらも、ワークフローエンジンをベースにした業務アプリはすごく作りやすくなっているなあ、と思う。
10年以上前に言われていたモデル駆動開発(MDD)は、実は、BPMNで描かれたビジネスワークフローをワークフローエンジンがシステムとして動作させる手法として、既にその概念は実現されているのではないか？

業務は詳しいがプログラミングは詳しくないユーザが、ワークフローをBPMNでお絵描きすれば、動くモデルが作れてしまうからだ。
UMLも、BPMNのように図を書いたら、モデルが動くようにしたいのだろうと思う。
超高速開発も、BPMNのように、モデルを作れば簡単に業務アプリが作れるような仕組みが作りたいのだろうと思う。

ワークフローエンジンはもう少し調べてみる。

【公開】第11回ドメイン駆動設計勉強会の発表資料「ドメイン駆動設計で気づいたこと～権利の概念とERP分析への適用」 #dddosaka

DDD読書会@大阪の最終回に参加してきた。
LT資料と合わせて感想をメモ。

【元ネタ】
ドメイン駆動設計LT会（DDD読書会@大阪の最終回） - ドメイン駆動設計(DDD)読書会@大阪 | Doorkeeper

vol11_20140713_lightning_talks · dddosaka/reading_ddd_report Wiki

DDD読書会@大阪(最終回)のLT資料「ドメイン駆動設計で気づいたこと～権利の概念とERP分析への適用」 #dddosaka from akipii Oga

第10回ドメイン駆動設計勉強会の感想 #dddosaka: プログラマの思索

第7回ドメイン駆動設計勉強会の感想　#dddosaka: プログラマの思索

第6回ドメイン駆動設計読書会の感想: プログラマの思索

第４回ドメイン駆動設計読書会の感想: プログラマの思索

オブジェクト指向設計の４つの流派からドメイン駆動設計へ: プログラマの思索

[ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場

[ 技術講座 ] Domain-Driven Designのエッセンス 第2回｜オブジェクトの広場

[ 技術講座 ] Domain-Driven Designのエッセンス 第3回｜オブジェクトの広場

【1】DDD読書会@大阪に参加して良かったと思う。
10年前からオブジェクト指向設計の本の大半は読んできたから、「ドメイン駆動設計」の中身もこんな感じだろう、と自分勝手に思い込んでいたが、良い意味でたくさん裏切られた。
「ドメイン駆動設計」に関する自分の理解が浅かったと思う。

「ドメイン駆動設計」は、特定の業務に関するモデリングのパターンではなく、モデリング技術そのもののパターンだ。
たとえば、第4部の戦略的設計は、大規模システム設計に関する設計技術そのもののモデリングパターンだ。
特に、設計方法だけでなく、複数チームの編成や体制に関わるノウハウはすごく役立つ。

【2】ドメイン駆動設計が従来のナイーブなオブジェクト指向設計と違う箇所は、まず、サービスクラスや仕様クラスにあると思う。

手続きそのものや、ビジネスルールや制約そのものもオブジェクトにしてしまう。
これらのオブジェクトはステートレスだが、オブジェクトにした方がプログラムはスッキリする。
また、サービスや仕様クラスをインターフェイスにして実装クラスを継承させれば、ポリモルフィズムを実現できるので、機能追加もやりやすい。

さらに、サービスや仕様クラスが含まれる「コアドメイン」を「抽象化されたコア」へ蒸留して、機能の実現はポリモルフィズムで多様化するように実装すれば、DDDの理想郷である「着脱可能なコンポーネントのフレームワーク」になる。

【3】「ドメイン駆動設計」「UMLモデリングの本質」「SysML/UMLによるシステムエンジニアリング入門」の本を読み漁っていると、深いモデルには「権利」という概念が自然に現れることに気づいた。
公開資料では、下記4つの例を出してみた。

【例1】貨物輸送システムと船荷証券
【例2】利息計算と発生主義会計
【例3】鉄道の自動改札システムの乗車権
【例4】レンタカーの組込装置での車の使用権

権利という概念は何故必要なのか？
権利は何かを受け取る権利があるので、資産になる。
つまり、権利は売れる。

鉄道の切符、航空券、ホテルの予約券はいずれも、何らかの権利を意味する。
そして、権利に種類をつければ、色んなビジネスができる。
切符は、定期券やICカード、プリペイドカードなどで販売できる。
飛行機の座席、ホテルの部屋は、グレードによって料金体系を変えて、数多くの人にリーチして販売できる。

権利は論理的概念なので、基本は物理的制限がない。
だから、ネット販売と相性が良い。
楽天も、ECサイトだけでなくホテル・旅館のWebサイトも販売している理由はそこにあるのだろう。

但し、権利に個数の制限がある場合、そのモデルは在庫管理のモデルに似てくる。
権利の予約は在庫引当の機能と同じ。
鉄道の座席、飛行機の座席、ホテルの部屋の個数は無限ではないから、予約したら、その権利は引当されて、他の人は予約できなくなる。

在庫引当のロジックの実装は、先勝方式による排他制御などの特有のロジックがあり、それなりに深い技術も必要とする。
排他制御のロジックは「汎用サブドメイン」「凝集化されたメカニズム」に相当するだろう。

【3】ERPのフィットギャップ分析にドメイン駆動設計が使えないか、というアイデアもある。

ERPの機能分析にドメイン駆動設計が使えないか #dddosaka: プログラマの思索

色々試してみたい。

【追記】
懇親会で、@hidenorigotoさんからインスピレーションを受ける言葉をたくさんもらったのでメモ。

akipiiさんはTwitterを使っています: "#dddosaka 昨夜は@hidenorigotoさんからインスピレーションを受ける言葉をたくさんもらった。メモの一部を公開。「DDDの仕様クラスやサービスクラスはオブジェクトからメソッドを剥がすモデリング技法。それによって、プログラムがかなりスッキリする」"

akipiiさんはTwitterを使っています: "#dddosaka 昨夜は@hidenorigotoさんの言葉のメモ。「DDDのユビキタス言語は謎。「ユビキタス」という言葉は外した方がいい。ユビキタス言語を声に出して、ユーザと会話できるか。モデルから業務(暗黙知、ビジネスルール)が思い浮かべられるか。」"

akipiiさんはTwitterを使っています: "#dddosaka 昨夜は@hidenorigotoさんの言葉のメモ。「PHPのドメイン駆動設計は、Javaのそれと相性が良い。Javaのやり方がそのまま適用できる。Rubyは、Javaのやり方がそのまま当てはまらない。Javaのコードで書くとRubyらしくなくなる(らしい)」"

BonitaBPMを動かしてみた感想～BPMツールに必要な必須機能

オープンソースBPMツールBonitaBPMを動かしてみたのでメモ。

【参考】
ProcessSampleKit - オープンソースBPMジャパン株式会社

ProcessLib - オープンソースBPMジャパン株式会社

Bonita BPMの国内Webサイトが公式オープン、BPMN2 サンプル図を一挙公開 | 岩田研究所

オープンソースのBPMツールBonitaのメモ: プログラマの思索

ちょい図解！使って覚える始めてのBonita

【1】インストール方法

BonitaのWebサイトから、Bonitaをインストールするだけ。
Eclipseベースらしいが、ツールのUIは赤色と銀色のメタリックな感じ。

【2】BPMサンプルの動かし方

ProcessSampleKit - オープンソースBPMジャパン株式会社から、サンプル組織マスタとサンプルプロセスをインポートする。

BonitaBPMの画面から実行ボタンを押すと、Webサーバーが起動し、localhostで画面が開く。
画面のUIは今風で使いやすそう。
PCだけでなく、スマフォやタブレットでも使えるようなUIの作りになっている感じ。

ログインユーザごとに、申請・承認・経理精算などのロールが異なり、BPMNの業務フローに従って、フローが進む。

【3】感想とねらい

業務システム開発に携わっていると、ワークフローエンジンをベースにして、ある特定の業務のBPMを開発する場合が多い。
たとえば、従来は紙ベースでやっていた出張申請フロー、部内のファイルサーバーのID発行管理、倉庫へ原材料の入庫や製品の出荷などを指示するフローなどがある。
つまり、従来は紙ベースで手作業していた業務をシステムで自動化するだけでも、業務は大きく効率化できる。

BPMツールでは、このようなワークフローエンジンが組み込まれていて、簡単な業務フローならば、管理画面からノンコーディングで簡単に作れる。
業務フローをBPMNというワークフローで書くのが最近のツールの流行みたい。

BPMツールで重要なポイントはいくつかある。

【3－1】多種多様な利用状況を考慮すること。

たとえば、稟議申請フローでは、承認する際に他の課長にも回覧する必要があったりする。
稟議内容を情報共有するためだ。

あるいは、ある企業の稟議フローでは、10人いる課長のうち3人の課長の承認が必要という機能とか、代理承認の機能が必要だったりする。
あるいは、承認時に動的に承認者を設定する機能が必要な場合もある。
つまり、単純な分岐フローというわけではない場面がある。

その企業の特有の事情をどこまで把握できるか、業務分析が大切。

【3－2】BPMツール上のワークフローを担当する担当者の組織マスタを別途準備する必要があること。

業務フローは、業務を担当する人の組織構造に依存している。
たとえば、出張申請を承認する人は課長、出張旅費の立替または精算を担当する人は庶務の女性のように、複数の人が特定のフローを担当する。
だから、BPMNで書いた業務フローのプロセスには、組織構造のロールがアサインされる。

故に、業務フローを分析するだけでなく、組織人事マスタをBPMツールに取り込む処理も必要になる。
普通の企業ならば、組織人事マスタを社内の別システムで保守しているから、日次バッチで組織人事マスタを変換して取り込めばいい。
つまり、組織人事マスタというデータモデリングが必要であり、BPMツールへ取り込むためのデータ移行が発生する。

さらに、注意すべき点は、大企業の場合、正式な組織構造ではなく、非公式な組織構造による申請・承認のロールが複数存在する時の考慮だ。

たとえば製造業では、正式な組織構造の元に部長・課長・係長・主任のような承認ラインがあるが、遠隔地の工場や販売店では、正式な組織階層の上級職がいないために、その現場だけの組織構造に基づく申請承認フローが必要だったりする。
特に日本の製造業は、売上を出す工場ほど現場の作業員の力を大きいため、非公式な組織構造で現場の業務を切り盛りしている場合が多いのだ。

すると、BPMツールとしては、正式な組織構造を反映した組織マスタだけでなく、特定の現場で使われる非公式な組織階層に基づく非公式組織マスタを複数個登録しておく必要がある。
そして、業務フローごとに、どの組織マスタを適用するか、予め設定しておく必要があるのだ。

貧弱な機能のBPMツールには、非公式な組織構造を持つ機能がないツールもあり、そのようなツールは、特に日本企業では使いづらい。
日本企業は、売上をあげる現場が強いので、非公式な組織階層に基づく業務が意外に多いためだ。
この辺りは、業務モデリングでも重要。

【3－3】BPMツールを複数の外部の業務システムとデータ連携する場合も考慮すること。

例えば、企業内に社内ポータルのWebサイトがあり、そのポータルサイトにログインしたら、ログインユーザごとの申請状況をBPMツールから取得して表示したりしたい時がある。
あるいは、営業見積りシステムや経理システムが既にあり、その業務フローの中にBPMツールのワークフローエンジンを流用して、申請承認フローを使いたい時がある。

または、申請承認した結果を毎月末に集計した結果を別の業務システムに取り込み、申請承認データを分析することで、業務の利用度合いや投資対効果を見たい時がある。

つまり、他の業務システムからBPMツールとデータ連携する方式設計が重要になってくる。
連携方式としては、バッチ連携かリアル連携としてSOA連携が普通だろう。

オープンソースのワークフローエンジンActivitiの解説記事にも、SOA連携の仕組みが載っている。

オープンソースのワークフローエンジン「Activiti」入門 - Tech-Sketch

有償・オープンソースのBPMツールも含めて、外部接続の連携方式はかなり研究されており、機能も豊富であるのが普通だ。

但し、BPMツールをデータ連携する場合、通信要件や性能要件のような非機能要件に注意すべき。
ネットワーク遮断、大量データのリアル連携、障害発生時の対応など、非機能要件の設計がうまくないと、BPMツールの外部連携は安定稼働しにくいだろう。

【4】個人的には、BPMツールはERPからワークフローエンジンの機能だけを抽出したサブシステムであると思っている。
だから、BPMツールはそんなに難しいわけではない。
ERPの導入・運用による長年の経験があるから、BPMツールの適用場面や適用した効果はおそらく既に知られているはず。

逆に言えば、BPMツールの機能や効果はおそらく20年以上前からさほど変わっていないだろうから、技術的にはあまり進化していないとも言える。
つまり、BPMツールを適用できる場面や得られる効果は、昔も今もほとんど変わっていないわけだ。
そういう意味では単純な技術の範疇かもしれない。

でも、最近の傾向として、BonitaやActivitiのようなオープンソースBPMツールが出現して、有償製品でなくても十分に使えるレベルになっている。
つまり、昔ならベンダーから高価なBPMツールを導入して保守費用を払っていたけれど、現代では、自社に技術力さえあれば、オープンソースのBPMツールを駆使して、安く自社に導入できる手段も取れる。

そんな背景を見ると、BPMツールに限らず、CRMやERPでもオープンソース製品のレベルが上がっており、パッケージ製品を導入するよりもオープンソース製品を導入した方が利点がある傾向があると思う。
その範疇にRedmineも含まれるだろう。

そんなわけで、オープンソースの業務システムに今後も着目していく。

「永和さんの「価値創造契約」が大苦戦を強いられている件」の記事がすごく参考になる

XP祭り2014で発表された「俺の価値創造契約」の発表資料がすごく参考になるのでメモ。
「この資料、非常に衝撃的だった。中の人がここまで公開していいものなのか、という意味でも。」という指摘はまさにその通り。

俺の価値創造契約 from Fumihiko Kinoshita

【参考】
永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance

新しい契約形態での受託開発サービス「価値創造契約」 ｜ 永和システムマネジメント

価値創造契約の件の感想

これだけはマスター！情報戦略キーワード - レベニューシェア型契約：ITpro

理想と現実 | 検索結果: | cloud42

エンタープライズの開発における、プロダクトオーナーとしての組織（前編）。Developers Summit 2014 Summer － Publickey

エンタープライズの開発における、プロダクトオーナーとしての組織（後編）。Developers Summit 2014 Summer － Publickey

【1】僕の立場としては、アジャイル開発のビジネスモデルが確立して欲しいと思っているので、永和さんの「価値創造契約」やソニックガーデンさんの「納品のない受託開発」モデルも応援したい。
しかし、「価値創造契約」の資料を読むと、色々考えさせられる。

初期投資不要、チケット制の追加開発、受託開発したシステムはレンタル、などというビジネスモデル。

3年やり始めて、受注実績は2社、3システム。
テレアポ800社やっても、テレアポからの受注実績はゼロ。

アジャイル開発をやりたい、という気持ちがあっても、ビジネスは別。
売上を上げて、利益を確保するのは、また別のテクニックが必要なのだろう。

でも、この辺りは、最初に誰かが始めなければ、その仮説が正しいかどうかも分からない。
やってみて初めて、何が必要なのか、が分かる。

【2】日本企業の情報システム部門が業務システムの開発を委託する場合、彼らの開発計画に失敗や損はない。
そんな予算や計画を立てたら、首になる。

だから、情報システム部門は、システムの開発を委託する場合、その投資に対する費用回収計画を作る。
1年目は5千万とか1億とか投資して、その後、1年目の投資を5年で償却しながら、保守料を毎年支払っていく。
その時、投資したシステムがいつ元が取れるのか、がすごく重要になってくる。

受託開発がメインになりがちな、企業の社内業務システムでは、社員がどれだけ使ってくれるか、が重要だ。
だから、社員の操作頻度ないしシステム利用料から、投資したシステムの売上を計測する。
その売上の累積が、費用回収計画での損益分岐点にぶち当たり、損益分岐点が前倒しになるほど、システムは成功したことになる。

しかしながら、業務システムはさほど使ってくれないものだ。
経営者が業務の効率化で導入するのであり、社員が楽しく使ってくれるために入れるのではない。
普通の業務システムは、機能は豊富でも、使い勝手が悪いのが普通。
すると、利用者が増えず、CIOは経営者から、あんなに高い金額で投資したのに何故システムは使われないのか、元が取れないぞ、と文句を言われがち。

そんな立場にいる情報システム部門から見れば、価値創造契約は不向きなのかもしれない。

システムはレンタルなので資産計上できない。
つまり、お金を支払ったのに、システムは使い捨てに等しい。
投資したお金は、資産にならず、その時限りの使い捨ての費用にしてしまっていいのか？
そもそも、システムは重要な資産ではないのか？

システムの機能改善を依頼しようとしても、チケット制の場合、社内の稟議に引っかかってしまい、なかなか発注できない、という話もありがちだ。
日本の大企業では、例えば、20万円以上の仕入れは部長決裁が必要だったりするので、部長に逐一説明しなければ稟議は通らない。
部長も忙しいし、詳細まで知っているわけではないから、理解できないモノは決裁してくれない。

また、社内のシステム化方針が変わったことにより、せっかくの受託開発が中止となり、簡単に契約が破棄された、という話も、よくあるなあ、と思う。
特に、社内の基幹系業務システムは、スクラッチの受託開発よりも、ERPパッケージ製品を導入する場合が多い。
スクラッチで一から作るには、情報システム部門が社内のたくさんの利用部門から要求を集めて、要件定義を確定する必要があるが、政治力がなければ、開発スコープが収束しない。
また、普通の情報システム部門はシステム開発のマネジメント力がないから、スクラッチの受託開発は赤字になりやすい。
そんなリスクを考えると、ERPをノンカスタマイズで導入し、ベンダーの保守サポートを受ける方がはるかに楽だ。

【3】他にも下記の反省点が書かれていた。
実際に試したからこそ、得られたノウハウ。

(引用開始)
失敗する前提でシステム開発をしないため、解約をメリットとして社内に説明できない。
解約すれば金銭的な損害は受けないかもしれないが、再び、別の会社に発注してシステムを作り直さなければならない。
ユーザー企業の情シスは絶対に失敗を認めない。

『価値創造契約』で開発したシステムをリリースした直後、経営者（CIO）が交代し、『価値創造契約』で運用しているシステムをERPに入れ替える方針となった。方針転換は想定外。
解約手数料なし。

チケットの使用に承認が必要なため、あまり使われていない。
チケットの使用にお客さまの社内決裁が必要となり、追加開発のために予算を確保する場合と同じフローになるという状況が発生した。

最終的な仕様は弊社で決めるという『価値創造契約』のルールは受け入れられにくい。
仕様は弊社で決めると言っておきながら、知っていて当たり前の業務知識についてまったく不勉強であった。知識・勉強不足により、お客さまに確認すべきことが確認できていないことがあった。

『価値創造契約』で開発したシステムはお客さまに納品せず、弊社の資産になるため、弊社の開発者が分かるレベルの仕様書しか残してこなかった。お客さまが自分たちのシステムとして運用していくために、必要な情報が不足した。

開発時は新しいものが段階的にできていく姿を見せながらお客さまの要望を取り入れていくため、お客さまに加点法で評価していただける。しかし、運用に入ったシステムは障害発生や過去のシステムと比較して使いづらくなったなど、お客さまは減点法で評価されることが多い。

システム利用料に対する成果を求められる。
エンジニアの稼働に対する対価を支払うという考え方が抜けきらず、ステムの運用に入ってから、対価に対してエンジニアの稼働が少ないという不満を抱かれるケースがあった。
(引用終了)

【4】「価値創造契約」の記事を読むと、なぜ、ソニックガーデンの「納品のない受託開発」は成功したように見えるのか、不思議になる。

どちらのビジネスモデルも、クラウドとRubyとアジャイル開発を前提としており、開発技術そのものは変わらない。
どちらの収益の獲得方法も、受託開発からの保守利用料だ。

あえて違いが見える部分を探してみれば、開発体制とマーケットだろう。

「納品のない受託開発」の開発体制は、ビジネスオーナー、プロダクトオーナー、開発チームというスクラムチームに似たような体制を作る。
この体制の利点は、仕様を決める人の責任が明確であることと、システムの方向性を経営者(ビジネスオーナー)が決める事実が可視化されていることだろう。
だから、システム開発の要件定義で右往左往しづらいように思える。

また、「納品のない受託開発」のマーケットは、ベンチャー企業のWebサービスや中小企業のWebシステムだ。
つまり、社内の業務システムというエンタープライズ系のシステムが対象ではない。

「納品をなくせばうまくいく」の感想part3～「納品のない受託開発」のビジネスモデルの不明点とあるべき姿: プログラマの思索

「納品をなくせばうまくいく」の感想part2～「納品のない受託開発」のビジネスモデル分析: プログラマの思索

「納品をなくせばうまくいく」の感想part1～ソフトウェア業界のビジネスモデルが抱える問題: プログラマの思索

【5】僕の直観では、企業の基幹系業務システム開発、つまりエンタープライズ・システムの開発は、アジャイル開発に向かない気がする。
「納品のない受託開発」のビジネスモデルの成功要因の一つは、エンタープライズ系のシステム開発を避けているからではないか、とも思う。

エンタープライズアジャイルは袋小路に陥っているのではないか: プログラマの思索

鈴木雄介さんの記事を読んで思うのは、やはり、エンタープライズ系のシステム開発では、上流工程はウォーターフォール型開発で要件をある程度仕様凍結し、方式設計や分析である程度、アーキテクチャを固めることが重要なのだろう。

また、下記の記事を読むと、開発体制の面でも、プロダクトオーナーを人ではなく組織に担当させて、組織が定期的に意思決定できる仕組みを整えている。
つまり、スクラムチームに似たような開発体制を作る事が重要なのだろう。

エンタープライズの開発における、プロダクトオーナーとしての組織（前編）。Developers Summit 2014 Summer － Publickey

エンタープライズの開発における、プロダクトオーナーとしての組織（後編）。Developers Summit 2014 Summer － Publickey

エンタープライズ系のシステム開発では、技術一辺倒では成功しづらい。
社内の利用者を巻き込む政治力やファシリテーション力、業務ノウハウをまとめたドキュメントや利用者への手厚いマニュアルなど、技術とは別の要素の比重が高い。
アジャイル開発は動くシステムと言う現物主義だが、「プロフェッショナルCIOの教科書」を読むと、エンタープライズ系のシステム開発では、それだけでは通用しづらい面があるのだ。

「プロフェッショナルCIOの教科書」の感想～調整型CIOは必ず失敗する: プログラマの思索

でも、こんな赤裸々な資料を公開されている永和マネジメント様はすごく太っ腹で、すごいな、と思う。
事例が少ないだけに、すごく貴重だ。

【追記】
9/27土に関西に倉貫さんをお呼びして、アジャイル開発のビジネスモデルについて議論します。
まだまだ座席はありますので、是非ご参加下さい。

9月27日 第60回 SEA関西プロセス分科会(大阪府)「納品をなくせばうまくいく?アジャイル開発のビジネスモデル！」

Redmineが今後発展する方向のアイデア

Redmineについて、今まで考えたことと、これから考えたいことをメモ。

僕が持つRedmineのテーマは下記がある。
【1】～【5】については、自分のアイデアを過去にコミュニティで発表してきた。

【1】アジャイル開発への適用
【2】チケット駆動開発のプラクティス集 or パターン言語
【3】Redmine運用のアンチパターン集
【4】Redmineの運用パターン集
【5】開発基盤としてのRedmine
【6】メトリクス収集ツールとしてのRedmine

【1】アジャイル開発への適用

デブサミ2011の発表資料がそのイメージ。
アジャイル開発に初めて上手く適用できたという経験に基づいている。

デブサミ2011(17-B-3)講演資料「チケット駆動開発～タスクマネジメントからAgile開発へ」 from akipii Oga

Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ from akipii Oga

【2】チケット駆動開発のプラクティス集 or パターン言語

XP祭り関西2010や品川Redmine勉強会の資料がそのイメージ。
Redmineの背後にあるプロセスは「チケット駆動開発」というプロセスフレームワークに昇華できる、と僕は考えている。
チケット駆動開発についても色々考えてきたが、Scrumのようなプロセスフレームワークよりも、eXtremeProgrammingのようなプラクティス集またはパターン・ランゲージとして表現する方が適切ではないか、という感触を持っている。

でも、未完成。
成功体験をプラクティスとして抽出し、さらにパターン・ランゲージまで洗練はできていない。

第4回品川Redmine勉強会資料「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ(ベータ版)」 from akipii Oga

XP祭り関西2010発表資料「チケット駆動開発のプラクティス集」 from akipii Oga

【3】Redmine運用のアンチパターン集

RxTStudyの資料がそのイメージ。
2011年の資料だから、まだまだ、たくさんあるはず。
Redmineコミュニティで、色んな人達の意見を吸い上げてまとめたい。

RedmineのFAQとアンチパターン集 from akipii Oga

AgileJapan2012講演資料「チケット駆動開発の課題と展望」 from akipii Oga

【第7回redmine.tokyo勉強会】RedmineのFAQとアンチパターン集～WBS駆動からチケット駆動へ from akipii Oga

【4】Redmineの運用パターン集

SRAプライベートセミナーの資料がそのイメージ。
Redmineをソフトウェア開発以外に適用できないか、というアイデアを元に、色んな経験を収集してまとめてみた。
多分他にも事例はあるはず。
RedmineがITにあまり詳しくないデザイナーや事務員でも使えるようなツールになると面白いだろうと思う。

「Redmineの運用パターン集～私に聞くな、チケットシステムに聞け」 from akipii Oga

【5】開発基盤としてのRedmine

品川Redmine勉強会の資料がそのイメージ。
Redmineをプロジェクト管理ツールというERPの開発基盤とみなした時、オープンソースのツールとは思えないくらい、豊富な外部接続の機能を持つ。
社内にある他の品質管理システムや原価管理システムと連携したら、面白いだろうと思う。

第6回品川Redmine勉強会発表資料「開発基盤としてのRedmine～Redmineをカスタマイズするポイント」 from akipii Oga

【6】メトリクス収集ツールとしてのRedmine

このアイデアはまだまとめてきれていない。
ソフトウェアメトリクスに関しては、ソフトウェア工学の長い歴史の中でたくさんの仕様、運用事例、ノウハウが編み出されてきた。
チケット駆動ツールは、ソフトウェアメトリクスを簡単に収集できて、色んな観点の集計方法によって、色んなビューを表示できる。
そこから、ソフトウェア開発のプロジェクト管理における多種多様な場面で利用できるようになるはず。

現状では、Redmineを長らく運用しているのに、チケットに蓄積された情報をビッグデータと見なして活用できていない現場が多いのではないか。

このアイデアは今度まとめてみたい。

testlinkをwindowsにインストールする時の注意点

testlinkをwindowsにインストールする時に、エラーが出た時の対処をメモ。

【参考】
testlinkをwindowsにインストールする - shouhの日記

TestLink1.9.10へのバージョンアップ時の調査 - Qiita

エンジニアがお薦めする 現場で使えるツール10選（5）：脱Excel！ TestLinkでアジャイルにテストをする (1/6) - ＠IT

WindowsでXAMPPにTestLinkをセットアップすると、ログイン画面で、
「Fatal error: Uncaught exception 'SmartyCompilerException'」
というエラーが出る時がある。

対処方法は下記の通り。

(引用開始)
この問題に関しては、下記のフォルダを最新のSmarty3に置き換えれば回避できる。

testlink\third_party\smarty3

http://www.smarty.net/download

Smarty 3.1.18(安定板）をダウンロードする。
(引用終了)

ユースケースの疑問

「ドメイン駆動設計」を読みなおすうちに、ユースケースとは一体何なのか、ユースケースはどこで役立つのか、という疑問が湧いてきた。
以下ラフなメモ書き。
理解できたら後で追記していく。

【0】ユースケースは謎だ。
ユースケース記述の書き方、ユースケース図の良い書き方、などを色々読んできたし、試してみたけれど、何かしっくりこない。

結局、画面設計書やバッチ設計書、システム構成図、DB定義書などのような大量のExcelドキュメントばかり作って、システムの全体概要がすぐには理解できない。
本来、ユースケースは、ユーザ観点でシステムが提供するサービスをまとめたものであり、ユースケースを見れば、システムの機能概要が分かるはずなのに、僕の経験ではユースケースが使われる場面が少ない。

理由を考えてみると、ユースケースの使い道が分かっていない気がした。
以下、疑問をリストアップしてみる。

【1】ユースケースの粒度は？

ユースケースを書く時、粒度を揃えるのが難しい。
ユースケース記述をおおまかに書くと、その後の設計工程で使いづらい。
かと言って、ユースケース記述を詳細設計のように書くと、ユースケース記述の量が増えて読みにくくなる。

「ユースケース実践ガイド」では、ユースケース記述にユーザインターフェイスは入れない方がいいと言う。
「ユースケース駆動開発実践ガイド」では、ユースケース記述で、バウンダリとして画面などのGUIを入れて具体的に書いた方がいいと言う。
どちらが正しいのか？

「ユースケースはユーザに提供するサービスを示す」「ユースケースはアクターとシステムの相互作用を示す」ことを考えると、要件定義ではユーザの目的が分かる概略レベル、外部設計以降ではシステムとの相互作用が分かるレベルで書いた方がいいのだろうと思う。

僕は概略レベルのユースケース記述は、ユーザであるアクターと対象システムの間で相互作用を示すシーケンス図を描く場合が多い。
システムコンテキスト・レベルのシーケンス図なので内容はシンプルだが、アクターがトリガーとなり、システムが操作の結果を返すやり取りを記述しやすい。
まずは、シーケンス図レベルのユースケース記述が書けなければ話にならない。

詳細レベルのユースケース記述は、ICONIXプロセスのように、ユースケースのシナリオをロバストネス図で描けるように、具体的なバウンダリも記述して相互作用を書く方が好きだ。
その方がイメージも湧きやすい。

しかし、工程ごとにユースケースの粒度を区別した時に、工程間のユースケースのトレーサビリティをどのように保証するのか？
ユースケースを細分化していく方法はあるのか？

【2】要求とユースケースの関係は？　機能要件とユースケースの関係は？

ユースケースは、要求を詳細化した(refine)もの。
ユースケースは、機能要件をストーリーの形で表現したもの。

したがって、ユースケースから要求まで前方追跡できるし、ユースケースから機能要件へ追跡できる。
その関連を表現したダイアグラムやモデリングツールはあるか？

SysMLの要求図には、ユースケースと要求(Request)を洗練(refine)で関連付けることができる。
また、SysMLの要求が非機能要件(性能、使いやすさ、保守性など)であれば、ユースケースから非機能要件へ追跡(trace)の関係を作ることもできる。

つまり、ユースケースと要求は表裏一体の関係。

【3】ユースケースの網羅性はどこで担保するのか？

「UMLによるオブジェクト指向モデリングセルフレビューノート」では、ユースケースは20個ぐらいにした方がいいという指摘がある。
しかし、ちょっとした業務システムならば、ユースケースの数はかなり膨大になる。
だから、ユースケースとアクターの集合をパッケージ図として分けるやり方を導入して、分割しようとする。

でも、ユースケースの網羅性はどこで担保するのか？
ERPのような業務システムならば、膨大な数のユースケースが必要で、それらがすべての要求を満たし、詳細化したものになるとどのように保証するのか？

ユースケースもカテゴリ化、階層化していく手法は必要ではないのか？
ユースケースとSysMLの要求を紐づけて、XDDPのようなトレーサビリティマトリクスによって、要求と実現すべきユースケースの網羅性を担保する方法はないのか？

【4】ユースケースを機能分割していく方法はあるか？

ユースケース記述をたくさん書くと、複数のユースケースに共通のロジックがあり、その共通ロジックをまとめて切り出したくなる。
ユースケース図では、包含関係(include)で共有のユースケースを抽出して再利用できる形式にする。

しかし、「ダイアグラム別UML徹底活用」ではユースケースを機能分割するのは良くない、ユースケースの機能分割は3段階以上すべきではない、という指摘もある。
だが、共通ロジックを括り出して再利用するために、細分化するのは常套手段だ。

includeなユースケースの粒度も問題だ。
includeなユースケースはどこまで細分化すべきか？
普通は、アクターが実行できるレベルまでであり、共通関数のようなユースケースにすべきではない。
しかし、共通関数のようなユースケースを作りたくなる時もある。
どのように折り合えばいいのか？

【5】ユースケースのextendの使い道は？

「UMLによるオブジェクト指向モデリングセルフレビューノート」では、ユースケースは条件分岐を作らない方が良いという指摘がある。
「ユースケース駆動開発実践ガイド」では、基本フローと代替フロー、晴れのシナリオと雨のシナリオで作るべきと言われる。

しかし、シナリオに条件分岐をどうしても入れたくなる時がある。
また、設計において、例外処理を洗い出す作業はすごく重要だ。
実際の実装内容としては、基本フローよりも例外処理の実装の方がコード量が多いし、例外処理の実装に頭をかなり使う。
そのような例外処理を全て書き出していたら、ユースケース記述はすごく読みにくくなる。

ユースケースでIF文を書きたい時、拡張ポイントを定めて拡張(extend)形式を使え、というフォースがある。
例えば、注文ユースケース中に、ログイン認証の分岐ロジックが途中であれば、extendを使った方がいい。

だが、extendを使うのは難しい。
「ユースケースによるアスペクト指向ソフトウェア開発」に書かれているようなアスペクト指向の考え方が必要だから。

結局、複雑な条件分岐や例外処理をユースケース上でどのように表現すれば良いのか？

【6】ユースケースからクラス図へどのように展開していくのか？

従来のオブジェクト指向設計では、ユースケース記述から名詞を抽出してクラスに設定し、概念モデルを描く手順で進める。
しかし、このやり方はとても素朴なやり方のため、実際の詳細設計に落とす時にひどく苦労する。
概念モデルのクラス図と詳細設計のクラス図は粒度があまりにも違うからだ。

個人的には、ICONIXプロセスのように、ユースケース記述からロバストネス図でオブジェクトの絵を描く手法が最もスムーズな気がしている。
ロバストネス図が描ければ、バウンダリ→View層、エンティティ→クラス、コントローラー→クラスのメソッドに責務を割り当てることで、クラス図とシーケンス図へ詳細化できるようになる。
ロバストネス図をDFDのように描ける点も良い。

だが、他にはどんな方法があるのか？
「実践UML」ではコミュニケーション図、「オブジェクト開発の神髄」ではコンポーネント図に詳細化していくが、どんなコツがいるのか？

また、ユースケースとクラス図、シーケンス図、ステートマシン図、アクティビティ図などのモデル間のトレーサビリティはどのように保証するのか？

Enterprise Architectやastah Professionalには、モデル相互をリンクする機能がある。
相互リンクすれば、モデルからユースケースへ追跡できる。
但し、手作業なのでモデルの数が増えたり、変更箇所が多くなると面倒になる。

モデルのトレーサビリティは、UMLよりもSysMLの方がよく考えられている。
SysMLでは、モデル間のトレーサビリティを仕様に含んでいるから。
UMLでも同様に、モデル間のトレーサビリティを表現できないか？

【7】2次開発や保守におけるユースケースの使い方は？

新規開発で作ったユースケースに対し、2次開発でそのユースケースを機能拡張したり、機能修正する時がある。
システム保守では、障害修正や機能改善のために、ユースケースを修正する時がある。
その場合、ユースケースはどのように修正すれば良いのか？

ユースケース全体を修正すると、再テストの工数が増えてしまう。
できれば、ユースケース記述の一部分に拡張ポイントを置いて、extendを使って機能追加するように修正したい。
そうすれば、機能追加したロジックだけをテストするだけで良いから。

でも、全ての場面で、既存のユースケースを拡張する方法で解決できるわけではない。
機能改善や機能修正をユースケースに反映する時に、他の良いテクニックはあるのか？

【8】反復開発がユースケース修正の試行錯誤にならないようにする工夫点は？

ユースケース駆動の開発は、反復型プロセスのオブジェクト指向開発と同一だ。
だが、反復型プロセスは、ノウハウがないと非常に難しいと個人的に思う。
スコープが揺れてしまいがちなので、スコープがどんどん拡大してしまい、分析麻痺になったり、単なる手戻り修正になってしまいがちだから。

本来のあるべき姿では、ユースケースを作り、開発スコープを定めて、ユースケース記述からシナリオを細分化していき、実装しながら反復的に開発していく。
だが、ユースケース記述の品質が悪ければ、何度も手戻り作業が発生し、いつまで経ってもシステムが完成しない。

特に、代替フローや例外処理を十分に洗い出しておかないと、詳細設計と実装で痛い目にあう。
でも、要件定義や外部設計のレベルで、代替フローや例外処理を洗い出しておくのは非常に難しい。
実際に開発してみないと分からない時がある。

そのような試行錯誤で開発する時に、ユースケース記述の構成管理や変更管理も重要だ。
品質が安定しているバージョンやリリース対象のバージョンのユースケースにはタグを付ける。
もちろん、ユースケースに関連するクラス図などの設計モデルにもタグを付けて管理する。
そのような管理手法がユースケース記述にも反映されているか？

EnterpriseArchitectやAstah Professionalには、クラス図などのモデルの履歴を残し、マージできる機能がある。
しかし、モデルのマージ作業は結構、面倒な作業だ。

もっとうまいやり方はないのか？

チケット駆動におけるメトリクス集計方法～「メトリクスによる「見える化」のススメ: エッセンシャル・リーン」資料から分かるもの

「メトリクスによる「見える化」のススメ: エッセンシャル・リーン」の資料が良かったので、リンクしておく。

メトリクスによる「見える化」のススメ: エッセンシャル・リーン from Hiroyuki Ito

【参考】
XP祭り2014で、メトリクスについてLTしてきました - THE HIRO Says

Agile2014に参加してみて分かった昨今の世界のアジャイル事情 - THE HIRO Says

上記の資料で気になる内容は、アジャイル開発で有用なメトリクスを提示している点だ。
これらメトリクスを読むと、こんな疑問が湧いてくる。

これらのメトリクスはどんな場面で有効なのか？
そして、チケット駆動開発に置き換えると、これらのメトリクスはどのような集計方法で実装されるべき仕様なのか？

以下の4つのメトリクスを考えてみた。

【１】Cumulative Flow Diagram (CFD)

いわゆる累積フロー図。
「リーン開発の現場」の第12章にも紹介されている。
仕組みとしては、ステータス毎にタスクカードを集計した枚数を、時系列に並べた図になる。

累積フロー図の発端は、かんばんのメトリクスでよく出てくる「製造業の追番管理」そのものだ。
製造業では、第1工程→第2工程→・・・の順に製品が作られる場合、工程ごとにかんばんの枚数を集計し、時系列に並べる。
その図から、どこにボトルネックが発生しているか、が分かるのが利点。
実際、どこかの工程でカンバンの枚数が多ければ、その工程で何かの事情で、無駄な在庫が溜まっていると推測される。

「リーン開発の現場」の感想part6～累積フロー図は生産管理の流動曲線管理または追番管理である: プログラマの思索

「受注生産に徹すれば利益はついてくる」の感想～ERP普及が上流工程の軽視を助長している: プログラマの思索

しかし、「リーン開発の現場」では、累積フロー図は良いと色んな人が言っているが、実際に使い物にはまだなっていない、というコメントもある。
たとえば、ソフトウェア開発の現場では、仕掛りチケットが溜まった状況が一気に消化された場合、あとで聞いてみると、定期的にチケットの棚卸しをしているに過ぎない時もある。
つまり、棚卸しするまで、仕掛りチケットがずっとたまり続けており、その状況を誰も気にしていない。
そして、ある一定の時期になれば、溜まった仕掛りチケットを消化する運用になっていて、そんな状況では余り意味が無いかもしれない。

【２】スループット

ある一定期間で、どれだけのチケットが終了しているのか？

ScrumのVelocityに相当するだろう。
Scrumなら4週間のスプリントで、終了したチケットの枚数を数えれば、それがVelocityになる。
TOCのスループットの概念に似ている。

XPの「持続可能な開発プロセス」というプラクティスに従えば、Velocityは変動すべきものではなく、安定すべきもの。
つまり、Velocityが急激に増えたり、減ったりするような性質にしない方がいい。

開発チームが安定して出荷可能な製品をリリースできるような仕組みを作るべきだろう。

【３】サイクル・タイム

チケットが次のフェーズに移動するのに、 どれだけ時間がかかっているのか？

この資料のサイクルタイムは、次ステータスへ遷移するまでのステータス間の作業時間で定義される。
つまり、かんばんのボードで区切られたステージ(ステータス)を横切る時に、どれだけの作業時間がかかったのか、を示す。

サイクルタイムが短いほど、スムーズに各工程で作業が流れていることになる。
また、各工程(各ステータス)のサイクルタイムの変動量が小さいほど、安定して作業していることになる。

普通は、プログラム実装や設計書作成の作業はスムーズに進んでも、コードレビューや設計レビューで長時間待たされて、フィードバックを受けて再修正するうちに、どんどん時間だけ浪費してしまう時も多い。

サイクルタイムが長いという事実は、作業時間そのものが長くて作業の効率が悪いか、または、作業は終わっているのに次の工程の作業のキューに溜まって待ち時間が発生しているか、のどちらかだ。
多くの場合、無駄な待ち時間が長い時の方が多い。
特に、レビューアが少なければ、レビューがボトルネックになりやすい。

なお、「リーン開発の現場」のサイクルタイムの定義は「ある機能が「次の10機能」ステージから「受入テスト準備OK」ステージに到着する時間」としているので、ちょっと違う。
「リーン開発の現場」のサイクルタイムの定義は、この資料のリードタイムの意味に近い。

「リーン開発の現場」はアジャイルサムライの再来となるかpart3～サイクルタイムとリトルの法則の関係: プログラマの思索

チケット駆動開発におけるサイクルタイムの計測方法～リーン開発で最も重要なメトリクス: プログラマの思索

また関連して、プロセスサイクル効率というメトリクスも計算してみると良い。
作業時間よりも待ち時間が多いかどうかという指標として有効だからだ。

「リーン開発の現場」の感想part4～トレーサビリティ、プロセスサイクル効率、構成管理: プログラマの思索

【４】リード・タイム

チケットが開始してから終了するまで、どれだけ時間がかかっているのか？

チケットの平均完了日数に相当する。
古くからある障害管理ツールMantisでは、平均完了日数というメトリクスが最初から表示されている。

平均完了日数は、ユーザから見れば、システム改善要望の待ち時間と同等である。
つまり、改善要望のチケットを起票したら、平均完了日数の日数はかかるだろう、と見ておかないといけない。
すると、平均完了日数が長いシステムほど、顧客満足度は低くなるだろう。

アジャイル開発であれば、リードタイム(平均完了日数)は基本はイテレーションの期間よりも短くなるのが前提。
イテレーション計画で立てたタスクカードは、イテレーション終了時には全て完了しているはずだから。

逆に言えば、イテレーションの期間に収まり切らないようなチケットがあれば、イテレーション終了時にはリリースすべき機能の残作業が残っていて、リリースできなかったことを意味するだろう。

【５】以上をまとめると、チケット駆動開発では、上記のメトリクスは下記で置き換えられる。

Cumulative Flow Diagram (CFD)
→累積フロー図と同等。
→ステータスごとに集計したチケット枚数を時系列に並べたグラフ。

スループット
→Velocityと同等。
→各スプリントの完了チケットの平均枚数。

サイクルタイム
→チケットをステータスごとに集計した時の平均作業時間。

リードタイム
→チケットの平均完了日数。

チケット駆動開発で考えれば、上記のメトリクスの仕様はすぐに分かるし、Redmine上ですぐに実装できるだろう。
そして、それらメトリクスを使うことで、プロジェクト管理に役立てることもできるだろう。

他にも役立つメトリクスはないのか？
その他のメトリクスはどんな場面で役立つのか？
いろんな課題が出てくるだろう。

Redmineのガントチャートに担当者を表示するプラグイン

Redmineのガントチャートに担当者を表示するプラグインを見つけたのでメモ。

【参考】
stgeneral/redmine-progressive-gantt-mods

Redmine - 無題

Redmineのガントチャート機能では、「担当者も表示してほしい」という要望が非常に多い。
MSProjectやExcelのように、WBSの作業単位に、アサインされた担当者を一覧表示して、担当者の作業負荷を見たいのだ。
特に、マネージャやプロジェクトリーダーはそんな要望をよくあげてくる。

上記のプラグインを使うと、ガントチャートのチケット名や担当者名の表示幅を自由に変更できるらしい。
担当者名が表示されるだけでもすごくありがたい。

しかし、Redmineチケットの担当者を固定にする手法はWBS駆動に凝り固まり過ぎ: プログラマの思索に書いたように、チケットをWBSのように扱えるけれども、WBSごとに担当者を固定化する管理手法はチケット駆動開発と相性が悪い。

WBSは、担当者を固定して、滝のように作業を後工程に流していく。
すると、手戻り作業が発生したタスクは、いつまで経っても進捗率があがらず、終わらないように見える。

チケットはステータスごとに担当者がコロコロ変わりながら、チケットを完了していく。
チケットのやり取りを見れば、なぜチケットが完了できていないのか、その理由が見えてくる。

この辺りがチケット駆動開発の面白さだろう。

Redmineのプロジェクト単位で進捗を集計して一覧表示するプラグイン

Redmineのプロジェクト単位で進捗を集計して一覧表示するプラグインを見つけたのでメモ。
しかし、2種類見つけたが、いずれもja.ymlがないので、日本語では正常表示されない。

【背景】

現状のプロジェクトの進捗を把握したい時、進捗管理の運用手順がRedmineのどの機能にマッピングできるか、フィットギャップ分析が必要になってくる。
例えば、ある大きな機能要件によって基幹システムの全てのサブシステムに影響が及ぶ案件があり、そのリーダーをあなたが担当したとしよう。
そして、それらのサブシステムを各チームに割り当てて進捗管理したいとする。

僕なら、全システムとサブシステムの進捗管理を以下のようにRedmineへマッピングするだろう。

・サブシステムを横断する課題管理←→Redmineプロジェクト(親プロジェクト)
・サブシステム←→Redmineプロジェクト(子プロジェクト)

しかし、各サブシステムの進捗状況を一目で横断して見たい要望があった時、現状のRedmineにはそんな機能がない。

たとえば、子プロジェクトにある全チケットの進捗をサマリした結果を一目で見たいなら、一つのバージョンに固定するか、一つの親チケットの下に全タスクを子チケットとしてぶら下げるか、などの手法がある。
しかし、この手法では、全てのサブシステムの進捗を横断してみることができない。

つまり、「Redmineのプロジェクト単位で進捗を集計して一覧表示する」機能が欲しいのだ。

【参考1】
stgeneral/redmine-progressive-projects-list

Redmine - 無題

(引用開始)
Show overall projects status in progress bars
Show project status in progress bars at project overview page
Quick links to issues, new issue, version, etc directly from the projects list
Show due date of the projects and versions
Recently viewed projects sidebar block
Configurable: admin set default settings, user may override them per session
Translated into 7 languages: English, German, French, Italian, Simplified Chinese, Russian, Ukrainian.
(引用終了)

プロジェクトごとの進捗率を「見かけの進捗率」と「実質の進捗率」で一覧表示する。
進捗率の表示機能を見ると、Redmineの標準機能であるロードマップ機能に似ている。

プロジェクトを横断的に確認できる上に各プロジェクトのメニューリンクも表示でき、直接リンクも飛ばせるらしい。
チェックボックスにより表示／非表示の切り替えができるらしい。

子プロジェクトも表示してくれるので便利そうだ。
DBマイグレーションがないのが良い。

【参考2】
mbasset/project_overview

project_overviewプラグインでは、プロジェクトごとに、ステータス(活動中 or 停止)や最新のバージョン、そのバージョンの期日、プロジェクト内に含まれる全チケットの進捗率を表示する。

つまり、各プロジェクトの状況を定量的に表示する。
パーキングロットチャート・プラグインの機能に似ている。

DBマイグレーションがないのが良い。

【追記】
redmine-progressive-projects-listにja.ymlが追加されたみたい。

redmine-progressive-projects-list/ja.yml at master · stgeneral/redmine-progressive-projects-list

ERPの機能分析にドメイン駆動設計が使えないか #dddosaka

オージス総研の「ドメイン駆動設計」の記事に、「戦略的DDDをエンタープライズアーキテクチャに適用した事例」の内容があったのでメモ。

【参考】
[ 技術講座 ] Domain-Driven Designのエッセンス 第3回｜オブジェクトの広場

(引用開始)
DDDの「戦略的デザイン」パターンは企業の経営戦略レベルに適用できるとは言っても、具体例がないとなかなかイメージしにくいと思います。DDDの公式サイトにて、エンタープライズアーキテクチャ（EA）の改善に「戦略的デザイン」パターンを適用した、ノルウェーの大手石油／ガス会社StatOil社の事例が紹介されています。
(引用終了)

Architectural Improvement by use of Strategic Level Domain-Driven Design

(引用開始)
同じくStatOil社の事例として、ERPなどの商用パッケージ製品の評価に「戦略的デザイン」パターンを適用した事例も紹介されています。こちらの事例では、コンテキストマップと責務の階層の組み合わせが、パッケージ製品の評価に不可欠な暗黙知の顕在化に役立ったと報告されています。
(引用終了)

Using Domain-Driven Design to Evaluate Commercial Off-The-Shelf software

【1】いわゆる基幹システムの設計をしていると、長年の保守や機能追加のために、中身のソースも設計もグチャグチャになっている場合が多い。
最悪な場合は、検索しようとしたら3分以上かかってセッションタイムアウトで使えなかったり、画面の機能がそもそも会社の業務をカバーしておらず、結局手作業でカバーしている時もある。

そうすると、業務システムは「膨大なお金を払ったのに投資対効果が赤字」とか「動かないコンピュータとして負債になっている」場合もよくある。
一時期は、日経の記事で盛んに「動かないコンピュータ」の事例が載っていた。

その原因の一つは、基幹系業務システムの設計がまずく、モデルとして抽象化されて開発チームやドメイン専門家が共有しなかったために、度重なる機能追加や障害修正でどんどん設計が劣化していったことだろう。

そんな場面でドメイン駆動設計が生きるのではないか。

【2】たとえば、「ドメイン駆動設計」の第4部「戦略的設計」では、ソフトウェアプロダクトラインに似たような概念「コアドメイン」やコア資産抽出プロセスに似た概念「蒸留」がある。
また、「大規模な構造」では、大規模なシステムの設計戦略が提示されている。

つまり、ドメイン駆動設計のスコープやゴールは、図書館の貸出システムのような簡単なモデルだけでなく、大手石油会社の輸送システムや製造業の生産管理システムなど、大規模な業務システムの設計も意識しているように思える。

PHPメンターズ -> Practical DDD #3: モデルの深さ

以前、「ドメイン駆動設計」を読んだ時は「オブジェクト指向設計の先祖返り」という観点しか持っていなかったが、DDD読書会＠大阪で皆と輪読しているうちに、自分の理解が非常に浅かったことに気づいた。
「ドメイン駆動設計」で言う「モデル」は、UMLでのクラス図のレベルではなく、開発チームやドメイン専門家が共通してつかる言葉「ユビキタス言語」をベースに、かなり抽象化されたモデルを指している。

つまり、デザインパターンのようなプログラミングレベルでもないし、アナリシスパターンのような特定のドメイン(会計、金融、組織人事など)のモデリングパターンだけを指しているのではない。
アナリシスパターンの「知識・操作レベル」のパターンで言えば、「知識レベル」の層に当たる所で、より抽象化されたドメイン(問題領域)で、モデルを捉えようとしている。

だから、「ドメイン駆動設計」のモデルは「ドメインモデル」というよりも「メタモデル」に近い印象を受ける。

【3】基幹システムのような大規模な業務システムの設計が難しいのはいくつか原因があると思う。

一つは、現場の人達が使う業務のドメインと、所要量計算のアルゴリズムや経路探索によるグラフ計算などの数式モデルのようなコンピュータの世界に近いモデルが入り組んでいること。

もう一つは、特定の現場の人達が使う「業務の言葉」が、その業界で一般に使われている「業務の言葉」と意味合いが違っていること。

前者については、「ドメイン駆動設計」の輸送モデルの事例が参考になる。
輸送システムでの経路探索システムは、現場の人が貨物を最短の経路で経路探索の業務を使う時に、その背後では、グラフ計算のようなかなり高度な数式モデルがある。
「ドメイン駆動設計」では、ドメイン専門家が理解するモデルを「コアドメイン」として分離し、グラフ計算のようなモデルは「汎用サブドメイン」として、さらに分離する。
つまり、モデルにおいて、「境界づけられたコンテキスト」でそれぞれのモデルのスコープを決定し、分離することを主眼においている。
そして、コアドメインのモデルと汎用サブドメインのモデルは、「コンテキストマップ」によって、モデル間の関連が明確にされる。

この手法は例えば、製造業の生産管理システムにおいて、ある製品の部品の種類と数量、リードタイムをInputに入れると、どの部品をどのタイミングでどの数量だけ発注したらよいか、を自動計算する所与量計算のモデルにも使えるだろうと思う。
つまり、ドメイン専門家が理解する「コアドメイン」と、その背後にある数値計算のアルゴリズムのモデル「汎用サブドメイン」を分離することで、理解しやすくなるはずだ。

後者については、データベース設計でよく出るホノニム、シノニムの話に似ている。
「ドメイン駆動設計」では請求システムにおける「料金」の話があった。
請求システムのコンテキストとしては、複数のチームが開発に携わっており、顧客に請求する料金とベンダに請求する料金では、必要な金額の項目の意味が微妙に異なっており、その金額計算に必要な項目で混乱した事例があった。
この問題の原因が分かった後、開発チームは、顧客料金クラスと供給者料金クラスを別々に作り、各チームはそれぞれでロジックを定義して、今まで同じように作業し始めた、という。

他にも、僕が最近知った経験では、SIにおける請負契約または委任契約の経費は、とあるERPの製品では「委託費」で呼んでいるが、社内の用語では「外注費」と呼ぶので、社内の人達は「委託費」という言葉を知らなかったことがある。

【4】2014年になった現在では、基幹システムを一からスクラッチで作り直す案件は非常に少ないだろう。
SAPで全ての業務システムを統一するか、各サブシステムを汎用的なERPパッケージ製品で多少カスタマイズして導入してSOAないしEAIで連携するパターンが多いだろうと思う。

すると、現場の業務とERPの機能を比較検討して導入対象を見極めるフィットギャップ分析が重要になってくる。
その作業に、ドメイン駆動設計が使えないか？

つまり、ドメイン駆動設計を大規模な基幹系業務システムの設計に用いて、より高い視点でモデル化して、本来あるべきモデルへ近づけていく手法に使えないだろうか。

この観点でドメイン駆動設計を改めて読み直してみたいと思っている。

ステートマシン図の履歴状態の使い道

ステートマシン図の機能の一つに「履歴状態」(Hに○の記号)がある。
使い方をメモ。

【元ネタ】
誤解しがちなモデリングの技：第3回：ステートマシン図（Ｉ） | 豆蔵ソフト工学ラボ

状態マシン図(State Machine Diagram) - UML入門 - IT専科

第4回 シーケンス図とステートマシン図を学ぼう | Think IT（シンクイット）

誤解しがちなモデリングの技：第3回：ステートマシン図（Ｉ） | 豆蔵ソフト工学ラボでは、エアコンのステートマシン図において、履歴状態を使っている。

履歴状態を使いたい状況は、割り込みが発生した時に、基本フローから一度離れるが、元の基本フローに戻った時に、元の状態から実行したい状況をモデル化したい時だろう。

たとえば、エアコンのリモコンのボタンで冷房→暖房→除湿の順に遷移する仕組みなっている場合としよう。
除湿の状態で運転停止した後に、湿気が多いのでエアコンを再開したら、除湿の状態から再開する状況で、履歴状態を使えばいい。

ステートマシン図の履歴状態を使う場面は少ないと思うが、組込システム機器の割り込み処理やイベント駆動処理などで使えるのではないかと思う。

なお、ステートマシン図の履歴状態には2種類がある。
「浅い履歴状態」では、割り込み処理後に元の基本フローを復活する時、中断時点の状況まで再現しない。
「深い履歴状態」では、元の基本フローを復活する時に、中断時点の状況を再現して、再開される。

状態マシン図(State Machine Diagram) - UML入門 - IT専科

この辺りのモデリングは、astahのステートマシン図を使えば、より簡単に書けるだろう。

エンタープライズアジャイルは袋小路に陥っているのではないか

最近のアジャイル開発の事情を書いた記事があったのでメモ。
ラフなメモ書き。

【元ネタ】
Agile2014に参加してみて分かった昨今の世界のアジャイル事情 - THE HIRO Says

もはやウォーターフォールだけでは通用しない：エンタープライズアジャイルが難しい理由と、実践の「現実解」 - ＠IT

動き出した エンタープライズアジャイル - 導入効果を「最大化」する5箇条：ITpro

(引用開始)
一方で今年参加してみて、下記の図にあるような傾向が見えるようになってきました。

Agile/Scrum/Lean/XP 自体は既に当たり前になっており、それらをどうよりうまく活用するかに焦点が移ってきている。
アメリカのコンサルを中心に「Enterprise Agile」が流行っているが、一方でこれに嫌悪感を持つ勢力も増えつつある。
BDD/ATDD を中心に、Testing のセッションに改善がみられる。
Metrics のセッションが増えてきた。
(引用終了)

(引用開始)
1. Enterprise Agile
「Enterprise Agile」とは、簡潔に言うと、企業全体レベルでのアジャイルを実現しようという考え方・方法論のことです。
（一部で「大規模アジャイル」と表記されていることもありますが、この表現だと「大規模プロジェクトでのアジャイル」だと誤解されやすい／そのような意味で使う人もいるので、「企業全体レベルでのアジャイル」とした方が妥当だと私は考えています。）

なのですが…技術面などの実現基盤については一切語らず、「メンバー全員が幸せになれるモチベーションを作るべきだ」のように空虚な「精神論」だけを言っている人が非常に多いのが気になりました。
こういうことを言う人は、アメリカでコンサルをやっている人に多かったです。
こうした発表は、アメリカ人参加者には非常に受けが良いのですが、他の国の人（カナダ含む）はしらけていました。
弊社のアメリカ人の多くが「アジャイル」と耳にすると「いい加減なこといいやがって！」と反応するのが不思議だったのですが、今年カンファレンスに参加してようやく理解できました。

例えば、コチラの動画を観ていただきたいです。ダンスをして楽しくなっても、良いプロダクトは作れないと思うのですよ。

そうした一方で、昨年一部で物議を醸していたSAFe(Scaled Agile Framework) が着々と勢力を広げつつあり、特に今年は SAFe をテーマにしたセッションが５つほどありました。
(引用終了)

エンタープライズアジャイルの定義は色々あるだろうが、僕は「企業向けの基幹系業務システム開発にアジャイル開発を取り入れた手法」と理解している。
日本のSIでも、B2Bの業務システムの受託開発案件が非常に多いだろう。

しかしながら、上記の記事では、エンタープライズアジャイルを標榜する人達が、技術面の話よりもチーム運営や精神論に走っているという指摘をしているが、非常に興味深い。

僕もアジャイル開発に興味を持った理由は、従来にない技術を持っていたことや、スピーディな開発を支える技術を揃えて開発プロセスをIT化する点だったから、この手の話はイマイチのりにくい。

基幹系業務システム開発にアジャイル開発を取り入れた場合、我々がよく知っているアジャイル開発プロセスは実現しづらいと思う。
基幹システムだから大規模にならざるを得ず、最初に開発スコープのブレを抑えつけないと、その後の開発が迷走しがち。
だから、仕様凍結に近い手法を取らざるを得ず、ウォータースクラムフォールまたはハイブリッドアジャイル開発のように、下流工程のみアジャイル開発のような手法を取らざるをえない。

また、業務システム開発の場合、CIOの観点では、システムを開発するだけでなく、システムをいかに利用してもらうか、という点の方が重要だ。
情報システム部門の役割は社内にシステムを導入して、利用者を増やして、業務を効率化することにあるので、いかに社員を巻き込むか、という点が重要になる。

つまり、「プロフェッショナルCIOの教科書」に書かれた内容のように、社員の意識改革に注力するようになる。
すると、オペマミやら運用ガイドラインなど、たくさんのドキュメントを作らざるを得ず、アジャイル開発の良さである「動くソース重視主義」が取りづらい。
また、情報システム部門のメンバーは、プログラミングよりも、利用部門にシステムの良さやシステムの使い方を説明する方に力を注ぐから、技術一辺倒とはなりにくい。

「プロフェッショナルCIOの教科書」の感想～調整型CIOは必ず失敗する: プログラマの思索

そういう観点があるから、プログラミング技術一辺倒よりも、利用部門の人達を巻き込むためのファシリテーション力や業務改革を推進するエバンジェリストのような能力の方が重要視されるだろうと思う。

したがって、アジャイル開発が生み出した「開発プロセスを支える技術」を深く掘り下げるよりも、人を巻き込むためのファシリテーションやリーダーシップ、エバンジェリストなどの能力が必要とされる。
それは最終的には、社内政治のようなスキルに近いだろう。

そんなことを思うと、エンタープライズアジャイルは袋小路に入っていると思う。