astah*Professionalファーストインプレッション

ようやくastah*Professionalを購入した。
JudeCommunityを2004年に使い始めてから5年以上経ち、色んな機能を使ってみたくなった。

astah* professional6.0の新機能

EnterpriseArchitectやRationalRoseも使ってきたけれど、astah*ProfessionalのUIや操作感の簡便さにはかなわない。
EnterpriseArchitectは殆どのモデリングをカバーしていて機能も豊富でピカイチだけれど、僕は何かフィットしなかった。
自分のアイデアをUMLで色んなダイアグラムで書きながら分析していく時に、サクサク書けるスピードはastah*Professionalが一番かなと思う。

astah*Professionalで気付いたのは、UMLがVer2.0に対応している事。
UMLはVer2.0になってとても複雑になったように思うが、その理由はおそらく組込みシステム向けのモデリング記法を整備したかったからだろう。
業務系システムや普通の開発ならば、UMLのVer1.x台で十分と思う。

astah*Professionalで面白い機能と思うのは下記5つ。

1・ER図
2・マインドマップ
3・フローチャート、DFD
4・要求テーブル、テストケース
5・JudeAPI

ER図があるおかげで、astah*Professional上でデータモデリングも可能。

マインドマップは要求分析で要求の洗い出し、要件の定義に使える。
でも、FreeMindに慣れているので、FreeMindと互換性があると嬉しいのだが。

要求テーブルやテストケースは興味惹かれる機能。
SysMLに合わせた仕様らしく、まだ使い方が分からない。
TestLinkの要件やテストケースがそのまま使えるならば、「要求→モデル←テストケース」の形で追跡可能になる。
モデルのトレーサビリティが可能になるから、試してみたい。

また、JudeAPIはJavaやJRubyからastah*Professionalのモデル情報を取得できる。
下記のように、モデルからファンクションポイントを自動計算できれば、見積りの精度が上がる。

JUDE改めastah*、ファーストインプレッション - TECH-moratorium ： テクモラトリアム

JRubyでJUDE CRUD-APIを試す - TECH-moratorium ： テクモラトリアム

JUDE APIでFPを算出するアプリ - TECH-moratorium ： テクモラトリアム

astah* Community Site - フォーラム

分析設計モデルをわがままに活用しよう　JUDE API入門（1/5）：CodeZine

他にも色々試してみたい。

特徴(Feature)、粗筋(Story)、脚本(Scenario)とチケットの関係

ユースケースとストーリーカードの関係、特徴(Feature)、粗筋(Story)、脚本(Scenario)とチケットの関係についてメモ。

【1】「システム要求、システム要件をどのように書くか？」はどのSW開発手法でもバラバラ。
オブジェクト指向分析(OOA)なら、ユースケース記述書のフォーマットに従って、システム要件や要求、フローを書いて、そこからモデリングしていく。

ユースケース記述書の書き方で一番優れていると思うのは、コーバーン著の「ユースケース実践ガイド―効果的なユースケースの書き方」。
ユースケースの書き方、観点のノウハウが詰まっている。
特に、ユースケースの観点を、アイコン(雲・凧・海水面・魚・貝)で表示して区別するのを推奨しているのは要注意。

ユースケース記述書のサンプルは下記を参考。

ユースケースについて

システムユースケース記述 [C02あんしん電話（高齢者] ユースケース ...

ユースケース番号：
ユースケース名：動詞句で記述する
主アクター：
従アクター：
事前条件：
成功時保証：
トリガー：
主シナリオ(メインフロー)：
拡張シナリオ(代替フロー)：
備考：

とはいえ、ユースケース記述書を最初からきちんと書ききるのは非常に難しい。

例えば、非機能要件を明示的に書く欄がないため漏れやすい。
又、代替フローの定義から大きな要件漏れが発生しやすい。
あるいは、ユースケース記述をIF文できちんと書こうとして、どんどん複雑化し、要件ではなくフローチャートを描いているに過ぎない場合もよく見受けられる。

【2】XPならストーリーカードに要件を書いて、タスクカードに作業を書く。
重要なことは、ストーリーは顧客が分かる観点で書くこと。
ストーリーカードは顧客が優先順位付けしたり、操作する重要なカードだから。

ストーリーカードのフォーマットは、下記が分かりやすい。

Article 626 at 00/07/17 16:48:01 From: hiranabe Subject: [XP-jp:00626] Virtual XP ストーリカード (1)

顧客ストーリカード
────────────────────────────────
番号 : 1
────────────────────────────────
日付 : 2000/7/17
────────────────────────────────
アクティビティ種別 : ■新規 □ 修正 □ 拡張
────────────────────────────────
優先度 : ユーザ 技術
────────────────────────────────
リスク:
────────────────────────────────
技術見積り:
────────────────────────────────
記述:
メーリングリスト(以下ML)のユーザが，ML のアドレスにメールを
送信すると，ML に所属するメンバ全員に，そのメールが配信され
る．配信されるメールの Subject は，[ML名:23] のような文字が
先頭に付加される(XP-jp のような仕様)．ただし，そのメールに返
信した場合，[ML名:xxx]という文字は重複しないような配慮がなさ
れる．ML に属するメンバは，members というファイルに1行1名で
記述されている．メンバ以外から来たメールは，エラーとして差出
人に返す．
────────────────────────────────
備考:
後のストーリにて，メンバの追加，削除をメールにて行う方法が記
述されることを考慮にいれよ．また，特定のML のみをサポートす
るのではなく，設定によって ML 名，ML アドレス等は変更できること．
────────────────────────────────
タスク記録:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
日付 状態 ToDo コメント
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

上記のフォーマットは分かりやすいとはいえ、ユースケース記述書に比べると曖昧な部分が多く、要件漏れが発生しやすくなるかもしれない。

【3】Scrumのプロダクトバックログについて、下記の優れた解説記事がある。

特徴(Feature)、粗筋(Story)、脚本(Scenario) - masayangの日記（ピスト通勤他

[Agile]プロダクトバックログについて海外の例も踏まえ考えたこと | Ryuzee.com

以下、まとめてみる。

特徴(Feature)、粗筋(Story)、脚本(Scenario)を意識して区別することを推奨している。

特徴(Feature)は、顧客から見たシステムの特徴。
粗筋(Story)は、その特徴(Feature)を利用者が具体的に体験する過程を記述したもの。
脚本(Scenario)は、粗筋(Story)をより具体的に記述したもの。

Feature(特徴)：カンファレンス運営原価管理

粗筋(Story)：カンファレンス目標人数までの到達度を測定する
* (As a)カンファレンス主催者として
* (I want)カンファレンス申込状況の報告書を見たい
* (So that I can)これにより、申込目標人数までの到達度を知ることができる。

脚本(Scenario)：　一人の登録が1%進捗と表示される場合
* (Given: 前提) 200人が目標人数の場合
* (When: 操作) 一人が申込登録すると
* (Then: 結果) 1%進捗と表示される

Feature(特徴)はシステムの機能。

粗筋(Story)は、XPならストーリーカード、Scrumならプロダクトバックログに相当し、これを見積もりや計画ゲームに使う。
上記の例の構造は下記と対応付ければ、非常に分かりやすい。
(As a)は主アクター。
(I want)は目的または要求。
(So that I can)はサービス、ユースケース名、又はユースケース概要。

脚本(Scenario)は、受入テストの根拠、つまり受入テストケース。
Given＝受入テストケースの事前条件、When＝受入テストケースのテスト手順、Then＝受入テストケースの期待値のように対応付けることもできる。

上記をユースケース記述書の事前条件・ステップ・事後条件に該当できるように見えるが、そうするとユースケース数が受入テストケース数とほぼ同値になってしまって爆発してしまう。
脚本(Scenario)は受入テストケースとほぼ同値とみなし、ユースケース記述はもう一段抽象化した方が良いように思う。

上記がユースケース記述書やストーリーカードよりも優れていると思う点は、要求(変更理由)と要件(変更内容)を粗筋(Story)と脚本(Scenario)で区別していることだ。
特に、何故システムのこの機能が必要なのか、その目的や要求を表現する項目がある点に着目したい。
結局、目的や要求が曖昧な場合、何を実現すればいいのか、何度要件定義をやっても決まらないから。

【4】特徴(Feature)、粗筋(Story)、脚本(Scenario)をRedmineによるチケット駆動開発では、どのように表現できるか？

Feature(特徴)は、Redmineならチケットの属性である「カテゴリ」に相当するだろう。
カテゴリはシステムの機能であり、カテゴリ単位にチケットを分類しているからだ。

粗筋(Story)は、チケットのトラッカー(種類)を「ストーリーカード」で登録すればいい。
このストーリーカードを作業単位にチケットへ分割すれば、「タスクカード」になる。
ストーリーカードに見積もり工数・実績工数・作業期間も記入すれば、TiDD上で進捗管理できる。

脚本(Scenario)は、TestLinkの「受入テストケース」に相当するだろう。
この時、粗筋(Story)をTestLinkの「受入テストの要件」として登録すれば、要件管理ができるし、テストカバレッジや要件カバレッジをリアルタイムに出力できる。
つまり、ストーリーカード(粗筋(Story))を経由して、RedmineとTestLinkを紐付けることができるはず。

色々試してみたい。

モデリングとプログラミングの観点の違い

要求開発の記事を読みながら思ったことをメモ。
＃あくまでもメモ書きであり、ロジカルでない。

モデリングとプログラミングは、根底から考え方が違うと思う。
モデリングできたからと言って、プログラムがすぐにできるわけではないし、モデルだけではシステムは動かない。
でも、モデリングで分析し尽さないと、思想のないプログラムが増殖し、それらのプログラムはすぐにスパゲティになる。
モデリングとプログラミングは相互に補完する関係にある。

モデリング技法には、OOAやDOA、他にも色々あるけど、基本は、エンティティを中心にその関係を考える。
一方、プログラミングは、基本はやはり手続きを考える。

構造化分析とは異なり、モデリングという概念が出てきたのは、DOAからだと思う。
DOAはモデルからデータと処理を区別して、データだけを取り出し、その関係をまとめる手法。
DOAはエンティティという入れ物が最初にありき。

DOAでもT字型ERでは、エンティティをリソースとイベントという2種類に分けて考える。
リソースは、マスタ系Tbl。例えば、顧客・商品など。
イベントは、トランザクション系Tbl。例えば、注文・在庫など。

リソースの関係からイベントが生じるという発想の元に、リソース間の関係にビジネスルールの制約を課す。
この手法によってER図が生まれる。
羽生さんの本(楽々ERDレッスン (CodeZine BOOKS))、渡辺さんの本(業務別データベース設計のためのデータモデリング入門, 業務システムモデリング練習帳 業務システムを効果的に設計するための精選45題)が詳しい。

OOAは、UMLという技法とセットで現れて数年前に流行した(ように思う)。
UMLにある各種のダイアグラムのうち、モデリングで最も重要な技法は、クラス図と状態遷移図だと思う。

ビジネス分析において、OOAもDOAと同じようにエンティティをまず洗い出すのが重要。
そのエンティティは概念モデルに現れて、その概念モデルはクラス図で表現する。

概念モデルはER図のように、クラス同士の関連に動詞を書き込んで、トランザクションを表現する。
つまり、DOAにおけるリソースとイベントが自然に現れる。
児玉さん(UMLモデリングの本質)は、リソースとイベントの関係を「もの-こと-もの」パターンと呼んでいた。

状態遷移図は、概念モデルで現れた一つのオブジェクトに注目し、そのオブジェクトの状態の動的な遷移を表現する。
仕様を理解できているかどうかは、状態遷移図を正確に書けているか、にかかっているように思う。

例えば、小売Webシステムならば、商品は販売中・カート・注文中・配送中・在庫無しなど色んな状態が各タイミングで変わる。
特に、排他制御が絡んだ在庫チェック、注文取消しの業務がとても難しい。

又、組込システムならば、缶ジュースの自動販売機の状態遷移の例が情報処理試験に良く出てくる。
自動販売機の状態も、販売中・販売完了など色々あるけれど、「缶ジュースが詰まってボタンが押せない」とか「在庫切れで販売できない」など色んなパターンも考えると、どんどん複雑になる。

モデリングが難しいのは、二つあると思う。
一つは、エンティティを洗い出すのが難しいこと。
例えば、概念モデルに現れたエンティティで漏れがない、という事を説明するのは難しい。

また、ビジネスルールを理解し切れていないと、エンティティを最初からすぐに導き出せない。
だから、羽生さんの本(楽々ERDレッスン (CodeZine BOOKS))では、最初はトランザクションに注目し、そこからエンティティを洗い出す手法を勧めている。
このやり方が最も自然なように思う。

更に、エンティティをクラスから型(Type)へ抽象化するのが難しい。
アナリシスパターン―再利用可能なオブジェクトモデルは、その構造を知識レベル・操作レベルと呼んでいるが、これを理解するのは至難の技。
児玉さんの本(UMLモデリングの本質)で僕はようやく理解できるようになった。

このやり方は、ビジネスモデリングで最も重要な手法の一つだと思う。
抽象化することによって、新たなビジネスパターンが得られるし、ビジネスで最も重要な概念が何か、が分かるからだ。
例えば、児玉さんの本(UMLモデリングの本質)では、会計システムにおける勘定パターンは物流システムの在庫パターンにも使える、と指摘している。

二つ目は、エンティティ同士の関連にどこまでビジネスルールを反映できているか、すぐに分かりづらいこと。
そこで、クラス図はあくまでも抽象的な図なので、実際に検証する時は、インスタンスの関係を書いたオブジェクト図を使えばよい。
児玉さん(UMLモデリングの本質)はクラス図の検証はオブジェクト図を使うことを推奨している。

また、児玉さん(UMLモデリングの本質)は「揺さぶり」という手法で概念モデルを洗練させる手法を提案している。
つまり、概念モデルに対し、ビジネスルールが反映されているかという観点で概念モデルを揺さぶってみる、ということ。
この辺りは児玉さんの本に詳しく、モデリングで最も面白い部分。

こう書いてきて、やっぱりOOAは児玉さんの本、DOAは渡辺さんの本が一番分かりやすいと思う。
平鍋さんは、渡辺さんの本(業務別データベース設計のためのデータモデリング入門など)を「日本人が書いたアナパタ」と呼んでいた。

オブジェクト納涼祭の感想: プログラマの思索

モデリングはプログラミングに比べると歴史も浅く、その手法も統一されてない。
モデリングの一番の弱点は、プログラミングと異なり、モデルだけではシステムが動かないこと。
だから、モデルの検証作業が難しい点が弱点であるように思う。

モデリング主義者が一番やりたいのは、モデル駆動開発(MDA)。
モデルを書いたら、そのモデルから動くプログラムを自動生成する手法。
でも、MDAは未だ完成していないし、そもそも本当にMDAが実現できるのか、誰も知らない。

要求開発はBABOKに対抗できるか？

先月、要求開発のセミナーを聞いて思った事をメモ。

【元ネタ】
Requirement Development Alliance : 要求開発アライアンス

ＮＤＳ要求開発|社長対談|「学ぶべき道・進むべき道」

ＮＤＳ要求開発|公開ワークショップ

The future is better than the past: 次はBABOK（ビジネス分析知識体系）？

PMBOKの次は「BABOK」が来る？ - 記者の眼：ITpro

要求開発はBABOKも、プロジェクトの立上げ、要件定義以前のRFP作成のプロセスを対象にしているようだ。
つまり、ステークホルダーのビジネス要件、又はシステム開発の要件へ落とす作業をターゲットにしている。

これら2つに必要なスキルはビジネス分析、いわゆるビジネスモデリングだと思う。

BABOKは、ビジネス分析の知識体系を目指す。
要求開発は日本独自の分析技法を提示しているみたい。

要求開発の話を聞いた限りでは、面白そうだけれども、何から手を付けて、どんな技法を使えばいいのか、分からなかった。
要求開発を受け入れている会社の人が一言、BSC(バランス・スコア・カード)を使うといいですよ、と言っていたのを聞いて、そういうレベルでやっているのか、これは難しいな、と思った。

正直、技法も知識も曖昧なので、実践するのは難しそう。
「ＮＤＳ要求開発|公開ワークショップ」のように、もっと実例が欲しいと思う。

でも、「ＮＤＳ要求開発|社長対談|「学ぶべき道・進むべき道」」を読むと、受託システム開発専門のSIerが現状に危機感を持っている理由がよく分かる。
単なる技術屋だけではなく、ITコンサルも兼ねたSIを目指したい、そうしなければ今後のITビジネスに未来がない、という思いは非常に分かる。
特に、クラウドの概念が現実になっている昨今、もはやシステムはスクラッチで開発するのではなく、システムのレンタル販売に移る傾向が大きくなるだろう。

色々探ってみたい。

マネジメントのスピードが開発のスピードに直結する

倉貫さん(XPJUG代表)の記事を読んで、システム開発に関する洞察が優れている点についてメモ。

【元ネタ】
アジャイル開発のボトルネック - Social Change!

(中略)
つまり、発注側のかけるコスト（工数）の限界が、ソフトウェア開発における速度の限界点なのだ。プロジェクトが成功するかどうかの分水嶺と言える。
これは実はアジャイル開発に限らず、一般的なウォーターフォールのソフトウェア開発でも、まとめて要件定義や検収テストをしているだけで、結局、同じくらいの工数がかかっていたのではないだろうか。もちろん、要件定義の前のビジネスや業務検討のフェーズを含めれば、である。
アジャイル開発では発注側が行う作業へのコミットが細分化されて見えるので、開発と同程度の工数が必要だという傾向が顕著に見えるだけかもしれない。発注側と開発側にかかる工数比があるように思わせたのは、そうしないと儲からないSIerの罪であろう。
『ソフトウエア開発においては、開発側が必要とする工数と、発注側が必要する工数を同等にするべきである』こんな法則があるのではないだろうか。そして、『発注側は、自社がかけれる工数（コスト）以上の、発注をしてはいけない』というルールでもあれば、うまくいくのではないだろうか。
(後略)

上記の指摘は、昨今のシステム開発の現状において非常に的を得ていると考える。

僕は、Redmineによるチケット駆動開発を運用して初めて、アジャイル開発はこういう開発スタイルなんだ！と実感した。
即ち、チケット駆動開発では、ロードマップ画面でバージョンをイテレーションに見立てて、小刻みに機能拡張しながらリリースしていく開発スタイルになる。
つまり、XPの小規模リリースを自然に具体化した開発プロセスになる。

すると、チケット駆動開発を運用する開発チームの内部作業はスムーズに進むようになり、顧客と仕様やスケジュールを調整するプロセスがボトルネックになってしまう現象が頻繁に起こるようになった。
例えば、開発チームではこういう仕様で進めるし、無理ならば代替の仕様が選択肢としてありますよ、と顧客に提示するが、そこで決定に時間がかかってしまう。
実際に作ってリリースして、顧客に見せたら、ちょっと違うよと言われる機能があったり、本来の要件が間違っていた事実も判明するが、どんなスケジュールで直していくか、優先順位を顧客が付けれない。
リリーススケジュールを開発側が提示して、返事待ちという状況が多くなる場合がある。

この状況の原因は、開発の速度よりも仕様やリリーススケジュールを決める速度が遅い点にある。

従来ならば、システム開発そのものに工数もコストもかかっていたが、Railsなどの優れたフレームワーク等のおかげでプログラミングの速度が上がってきた。
そして、RedmineやTestLink、チケット駆動開発で開発チーム内部の作業も効率化し、品質も安定するようになってきた。
すると、開発チームで制御できないプロセスがボトルネックになって、開発の速度に制約がかかる。
特に、レビューと言うプロセスでこの症状が顕著に現れる。

XPにはオンサイト顧客というプラクティスがある。
顧客も開発チームに加わり、ストーリーカードの優先順位付け、受入テストなどを行う。
実際の開発では、顧客が開発チームに入るのは難しいので、要件定義を行うSEがその役割を担っている。
倉貫さんはこの手法を「顧客プロキシ」(オンサイト顧客の代理人)と呼んでいた。

ここで、オンサイト顧客(要件定義を行うSE)の重要な役割の一つに、開発チームが作ったシステム仕様をレビューして、品質チェック後、承認するという作業がある。
このレビュープロセス(デザインレビュー)はすぐに完了できるわけではないし、レビュー後にその仕様で実装していくから、レビュープロセスのキューにどんどんタスクが溜まって、開発速度が落ちる現象が頻繁に起きるようになった。
かと言って、レビュープロセスを簡略化したり、無視していいわけではない。
そして、SEの代わりに顧客を連れてきても、状況はおそらく変わらない。

今の僕の経験では、デザインレビューが開発のボトルネックになっている。
つまり、デザインレビューの速度が上がらなければ、開発の速度が現状以上に上がらない。

要求を洗い出す作業と、要件を仕様化する作業は別の能力だと思う。
要求開発やBaBOKのレベルでは、業務の全体最適化(つまりエンタープライズアーキテクチャ)の観点から、システムのあるべき姿を導き出す。
しかし、我々ITエンジニアは、要件をいかにシステムとして実装して稼動させるか、という作業に注力を注ぐ。
それらの作業は大きく異なる。

その作業をつなぐ部分にボトルネックがあるのかもしれない。

モデル検査ツールLTSAのメモ

モデル検査ツールLTSAについてのメモ。
LTSAについてのリンク一覧は、garyoさんのはてぶから辿ればいい。

はてなブックマーク - Junk☆Bookmark臥龍 - LTSA

【他の参考資料】
LTSAによる動作モデルの検証(ARM組み込みソフトウェア入門―記述例で学ぶ組み込み機器設計のためのシステム開発 (Design Wave Advanceシリーズ)の16章)
→これが一番分かりやすい。
　LTSAというツールが状態遷移図のモデリングに大変有効である理由と例が説明されている。
　特に組込み機器のように、デッドロックや並行性、セマフォなどを考慮する必要がある時に役立ちそう。

LTSA Tutorial ― Yamamoto Lab. Web Site
→LTSAのツールの使い方が説明されている。分かりやすい。

Concurrency スライド
→LTSAの英語本を大学の講義録として公開されている。読みやすい。

LTSA - Labelled Transition System Analyser
→LTSAの総本山

LTSA Eclipse - Imperial College London
→EclipseのLTSA用プラグイン

LTSA 　FrontPage - PukiWiki

UMLモデリング・ツール「Enterprise Architect」からモデル検査ツール「LTSA」用のファイルを出力できるらしい。

モデル検査やAUTOSARなどに関連したツールが登場　――第11回 組込みシステム開発技術展（ESEC）レポート（2）｜Embedded and Electronics Engineers Network

eSOL - イーソル株式会社 : リサーチコンサルティング

形式手法(Formal Method)、モデル検査(Model Checking)の目的は、設計工程で仕様をモデル化して、その矛盾をなくす作業に使う。
過去に、野中さん、藤倉さん、佐原さんなどの講演をSEA関西で何度か聞いてきたから、雰囲気は分かるが、率直に言って、あまり役立つとは思っていなかった。
これらの手法は、仕様をモデル化するためにある種のプログラミング言語で実装するが、そのプログラムは動作しないし、実装プログラミング言語と同じぐらいの労力がかかる。
だから役立たないと思っていた。

でも、今の僕の課題として、設計工程の品質アップ、テスト設計の品質アップがある。
形式手法を使って、設計工程で状態遷移図のモデリング作業に使えるかもしれない。
形式手法で書いたモデルからJavaなどのソースを自動生成するよりも、テストケースを自動生成してくれる方が正直ありがたい。

形式手法は色んな種類があるけれど、LTSAはJavaで作られたGUIアプリがあり、状態遷移図を生成してくれるので、他の手法よりも分かりやすい。

システム設計の一番の肝は、状態遷移図だと思う。
業務は知っているがシステム化を知らないSEと、システム化できるSEの差は、状態遷移図でシステムを表現できる能力があるか否かだと思う。
フロー図やクラス図はあくまでもお絵かき。たくさんの漏れがある。
システム化する時に一番大事なのは、状態を見抜き、そのパターンを全て洗い出すことだ。
それが状態遷移図であり、デシジョンテーブルになる。
そしてそれが仕様になり、テストケースになる。

組込みSEならば、例えば、CDプレーヤーの状態遷移図は書けるだろうか？
情報処理試験に受かっているならば、缶ジュースの自動販売機の状態遷移図は書けるだろうか？
状態遷移図に出てくる状態は普通は、Cのグローバル変数として表現されるだろう。
だから、状態を扱うのは慎重でなければならない。

業務系SEならば、状態はDBにあるテーブルのフラグとして表現される。
画面遷移やトランザクションの推移によって、フラグの値が状態遷移図として表現される。

フラグの個数が増えるたびに、フラグの値が増えるたびに、状態遷移図はどんどん複雑になる。
フラグのビジネスルールは条件分岐で表現されるから、プログラムも複雑になっていく。

システム開発が難しいのは、状態遷移図が複雑になりやすく、状態爆発しやすいからだ。
状態が多いほど、テストケースも増えて、開発期間中に全てのフローを検証できないままリリースに至ってしまう。
だが、むしろもっと危険なのは、設計された状態遷移図で実装してみたら、たくさんの穴が見つかったという事態だろう。
特に組込系ならば、並列に走らせて特別なタイミングでデッドロックに至るバグなどは、手書きの状態遷移図では分かりえない。
オブジェクト指向やDOAも確かに役立つけれど、状態遷移図を補完するモデリング手法と捕らえた方が使いやすいと思う。

この10年、RailsやSeasar、Ajax、MapReduce、レコメンドエンジンなど、下流工程では多くの技術革新があった。
しかし、プロジェクト管理やモデリングに関しては、XPを代表とするアジャイル開発が多少あるぐらいで、10年前の技術と何ら変わっていないように思う。
その間、システム開発の大規模化、短納期化が進み、システム開発の難易度は10年前よりもはるかに上がっている。

おそらく今の日本では、人海戦術や組織力でこの流れに対抗しようとしているが、技術力を軽視していないだろうか？
プロジェクト管理やテスト管理を人海戦術による手作業からIT化したり、設計手法にDSLや形式手法を用いてソフトウェアでモデリングしていくなどの発想はないのだろうか？

ソフトウェア開発の諸問題はソフトウェアでしか解決できない範囲が広がっているのではないだろうか？

マインドマップのメモ

マインドマップのツールFreeMindの使い方が下記で公開されている。
キー操作だけで、枝葉を増やしたり消したり、移動できれば十分だろう。

FreeMind使おう会 | FreeMind使おう会参加者の作例集

又、FreeMindでマインドマップを活用する事例として、雑誌の企画、プレゼン資料、原稿執筆に使った話が下記に書かれている。
「脳ミソの中をGoogleで検索できないかな？」という疑問からマインドマップに至る発想が面白い。

FreeMind企画術

僕は、プレゼン資料や1日のタスクの洗い出し、WBSの洗い出し、リスクの洗い出しなどにマインドマップを使っている。
完璧に作るとか詳細に書くとかは気にせず、思いついたことを書き並べて整理すれば、荒筋が見えてくる。

又、マインドマップを手書きで書く時も多い。
DFDや状態遷移図、配置図、ライフサイクルをラフに書きたい時があるから。
また、講演やセミナーを聞くときは、ノートにマインドマップでラフに書くことも多い。
後で読み返すと、色々気付きがある。

マインドマップは、間違いを気にせずにとにかく書きまくること。
自然にコツが分かってくる。
僕は「人生に奇跡を起こすノート術―マインド・マップ放射思考」でマスターした。

他の人のマインドマップも参考になる。
今ではインターネット上にたくさん例があるから参考にすればいいと思う。

XDDPと言う派生開発

初めて、XDDPと言う派生開発の提唱者である清水さんの話を聞いた。
本は2冊読んでいたけれど、自分の理解が不十分だったことに気付いた。
以下、メモ書き。

【1】XDDPの最大の特徴は、SW開発の殆どは機能追加という保守開発である、という認識を前提としたアジャイルっぽい開発スタイルにある。
ソースからリバースエンジニアリングで要求仕様書を作り、ソースをダラダラと修正するのではなく、一気に修正してしまう。

駄目なプロジェクトでは、ソースに手を入れては修正漏れが出て、それを直してはまたバグが出る、といった症状が多い。
影響範囲や修正方法を確実に見極めれずに、ソースに手を入れてどんどん劣化させてしまう最悪なパターン。

清水さんのフレーズで面白いと思ったのは「移植作業は、ソフトウェアでも拒否反応を起こす」という内容。
人体でも、風邪を引いた場合、抗生剤を飲む。
しかし、抗生剤は人によっては免疫機能が働いて拒否反応を起こす危険なもの。
そうでなくても、抗生剤は、悪玉だけであく善玉の細菌まで殺してしまう。

ソフトウェア開発でも、機能追加は慎重に行わなければ、既存の機能の品質まで劣化させてしまう。

そうなってしまう理由は、SW開発の殆どは、既存のソースに機能を追加してVerUpしていくスタイルが多い事実を見落としていないか？

SW開発のその特徴を類推すると、VerUpしていくたびにテストケース数が単調増加していく事実もあげられる。
過去の機能が正常動作する保証の元に、追加した機能のテストも行う。
影響範囲をきちんと見極めないと、既存の機能まで壊してしまう。

XPならば自動テストのプロセスがあるため、回帰テストによって、既存の機能の正常動作を保証できる。
しかし、そのプロセスがなければ、回帰テストのコストが大きすぎるため、デグレの危険をいつもはらむ。
デグレは、顧客の信用を激しく落とし、開発者自身のモチベーションも大きく落とすとても危険な現象だ。

【2】XDDPには、要求と仕様を厳密に区別し、変更管理をきちんと追跡していくプロセスがある。

要求と仕様の一番の違いは、要求は1回限りだったりするけど、仕様はVerUpしていく、という話にすごくピンと来た。
この話によれば、仕様書もソースと同じく構成管理の下に置くべき対象なのだ。

駄目なプロジェクトでは、中途半端に仕様書を直しては、設計漏れが出るたびに仕様書を修正するパターンの繰り返しだ。
XDDPでは、変更管理プロセスがしっかりしているため、CCB(変更管理委員会)の決定やレビューが終わらない限り、仕様書に修正が入ることはない。

清水さんは、この特徴があるおかげで、並行開発や五月雨式開発が可能になる、と言っていた。
例えば、組み込み製品ならば、普通は、似たような仕様を持つ製品ファミリーがたくさんあり、それぞれが並行開発されている。
機能追加が起きると、全ての製品ライン上でマージ作業を行わなければならない。
だから、変更管理プロセスを制御することで、デグレが起きないようにするのがポイントらしい。

僕は清水さんに、ブランチを巧く使えば制御できるのではないか？と質問したら、ブランチからマージするのは大変ではないですか？と切り換えされた。
確かに、タスクブランチは現実的な解決方法の一つであるが、制御するのが難しい技術の一つだから。

また、要件からテスト仕様書が作られる。
XDDPでは、要件仕様書がしっかりしているため、受入テストのテストケースを作るのがかなり楽になる印象を受けた。

TestLinkでテスト管理し始めてから、テストケースの元ネタである要件の重要性を痛感している。
テストケースを作る場合、一番重要な観点は、全ての要件を網羅できているか、という要件カバレッジだ。
実際にテストケースを作ってみると、テストで確認しない要件がポロポロ出てくる。
つまり、テストがMECEでないのだ。
そこから、検証できていない機能が発生して、潜在バグが生まれる。

実際は、全ての要件をテストでカバーするのは非常に面倒な作業だ。
一つのテストケースには複数の要件が混じっていたり、要件を検証するステップを追加するたびにテストケースは肥大化しがち。

そもそも要件IDが振られた要件定義書が存在しない場合もある。
そのプロジェクトは、テストケースの品質が非常に低いといえるだろう。

幸いなことにTestLinkでは要件解析の機能があり、テストしていない要件、要件に紐づかないテストなどをリアルタイムに一覧表示できる。
この要件解析の機能をフルに使うと、テストケースの品質を向上させることができる。

【3】清水さんの本にもあるが「SEはプロセスを自在に設計する能力が必要だ」というフレーズが僕は好きだ。
プロジェクト毎にそれに合った開発プロセスを設計して運用する能力がPLには必須。
そのためのツールがDFDっぽいPFDというツールらしい。

XDDPがアジャイル開発と似ている印象を持ったのは、SW開発の殆どは機能追加という保守開発である、という認識を前提として、ソースからリバースエンジニアリングで設計しようという開発スタイルだからだ。
XPは仕様書よりも動くプログラムを重視するが、XDDPも既存のプログラムを分析するのを重視する。
ウォーターフォール型開発のような上からの開発ではなく、下からの開発スタイル。

清水さんの話の中で「一人プロジェクトは危険だ」というフレーズがあった。
つまり、一人で設計し修正しテストして終わる作業は非常に危険だということ。
一人だけの作業は思い込みが生じたりして、品質が安定しない恐れがあるから。
大人数のチームであっても、運用保守の作業はコストをかけられないため、一人プロジェクトになっている時も多い。
だから、アフターケアやレビューの重要性を言っていた。

これは、XPのペアプロの発想に似ている。
一人だけでバグ修正してバグを検証すればOKというわけではない。
二人の目を通した作業の方が、時間はかかっても品質は安定する。

XDDPは運用保守に強い開発スタイルのような印象を持った。
色々調べてみる価値はある気がする。

要件定義をロジカルシンキングで解析する

「30の「勝負場面」で使いこなす ロジカル・シンキングの道具箱」を読んで、高度情報処理試験の論文問題を解いているような気がしてきた。
要件定義と問題解決、ロジカルシンキングについて考えたことをメモ。

【1】業務系システム開発のリスクは、Railsのような最新技術の習得、TiDDのようなプロジェクト管理、TestLinkのようなテスト管理など色々あるが、一番のネックは要件定義だ。
元々の要件が顧客の認識とずれていたら話にならない。
しかしながら、新規顧客の場合、顧客と一緒に開発してリリースして運用しなければ、顧客の本来の要求が何だったのか、が分からない時はすごく多い。

だから、SIerのビジネスモデルとしては、1次開発は赤字だったとしても2次開発や運用保守で黒字になるように仕向けるのが普通だろう。
特に大手SIerが政府の公共システムを受注する場合が当てはまるだろう。
だが、そういうリスキーなビジネスモデルもそろそろ割に合わなくなりつつある。

【2】要件定義を真正面から取り組む必要がある。

要件定義は結局は、顧客の業務で現れた問題や課題をシステム化で解決することだ。
IT業界の営業は、顧客の業務のソリューションに特化したITコンサルタントにならなければならない、といわれる理由は、結局そのことだ。

だが、顧客は自分の業務の問題点を把握しているとは限らない。
普通は、問題の本当の原因ではなく、起きた事象と間違った解答を要件として提示してくる。
それをそのまま仕様に落とすと、本来の問題を解決するシステムではない仕様で実装してしまい、役に立たないガラクタのシステムができるだけ。

だから、要件定義では、顧客の要望をそのまま鵜呑みにしてはいけない。
要望を整理して、本来の課題とその解決策を提示しなくてはならない。
つまり問題解決スキルが要求されている。

【3】「90分で学べるSEの思考術 (ITプロフェッショナルの基礎知識)」では、SEが上流工程で問題解決に関与する状況が多いと言う。
そして、多くのSEが思考の壁にぶち当たるのはこの当たりからだ、と言う。

つまり、要望を単なる箇条書きの仕様と見なすのではなく、構造化された一つのモデルとして提示する能力が必要になってくる。

今までUML、DOAなど色んなモデリング手法を学習してきたが、要件定義では、結局、ロジカルシンキングを中心として論理で整理するのがBetterな気がしている。

仕様とは一つの仮説であり、一つの論理的なモデル。
要望をロジックツリーで整理して、問題と解決策へ昇華できれば、解決策を仕様に落としてしまえばいい。

ロジックツリーがロジカルシンキングで基本なのは、論理的思考の基本スキルが全て含まれているからだろう。
ロジックツリーは、情報をツリー構造に整理するだけ。
しかし、MECEであるか、4Pや3C、PLMのフレームワークで整理されているか、因果関係が言い尽くされているか、などを検証するのは結構大変。

そして、その解決策を仕様へ落とす作業、つまり設計工程でも、整合性を取りながら一つの論理モデルを作るのはそれなりのスキルを必要とする。
僕の短い経験では、アクティビティ図、ステートチャート図、デシジョンマトリクスの3種類で業務分析していくのかな、と思う。

「SEは脳みそで汗をかく職業」とうちの上司は言っていたが、上記の作業はまさにその通り。

【4】羽生さんのBlogで下記の気になるフレーズがある。

【元ネタ】
株式会社スターロジックの羽生章洋が書いてるブログ:要件定義の営業コスト化 - livedoor Blog（ブログ）

株式会社スターロジックの羽生章洋が書いてるブログ:雑多な日々 - livedoor Blog（ブログ）

以前に要件定義の営業コスト化ということを書きましたけど、要するにお客様に「これ書いてくださいね」とお願いしてしまえば、そこに要件が整理されちゃうという感じです。

ネット注文では、顧客に商品を買ってもらうために、顧客自らに、自分の個人情報と欲しい商品情報を入力させる。
リアル注文に対するネット注文の比較優位の一つは、販売者が顧客の注文要望を受け付ける必要がないことだ。
要件定義でも、顧客自身に、仕様を書かせてしまえばいい。

つまり、顧客自身に、問題解決のテンプレートに書いてもらえれば、それがそのまま仕様書になるようにすればいい。

羽生さんの会社で提唱されている「マジカ！」「Buri」などのツールや製品を見ると、こんなイメージでシステムを作っているのかなと思う。
＃自分が理解した範囲内で書いている。間違ってたらスミマセン。

【元ネタ】
ワークフロー入門Buri-TECHSCORE-

マジカ！のシートに、顧客自身にシステム要件を書いてもらう
シートを並べれば、そのまま業務フローになっている
↓
上記のシートの組み合わせをBPMNのモデル(XPDL形式)に変換する
↓
BuriというフレームワークでJavaプログラムへ変換する
Seasarファミリーの一つみたい
↓
後はゴリゴリ書くだけ。

上記まで問題解決が自動化されたら、受託開発はもっと安価になり、ITビジネスもデフレになるだろう。
実際はそこまで自動化できていないが、オープンソースで提供されるツール群には市販のERPパッケージ製品に劣らないビジネス製品もある。

要件定義、問題解決、システム化をもっと綺麗に整理できないか？

リファレンスモデルの重要性

渡辺さんの本を読んで、昨今の業務システムの開発におけるボトルネックは、プロジェクト管理でもなくプログラミング技術でもなくオブジェクト指向技術でもなく、実はデータモデリングではないか、と思った。
その時に、有用な設計モデルにリファレンスモデルが不足している理由について優れた指摘があったのが面白かったのでメモ。

【元ネタ】
渡辺幸三の開発支援サイト「システム設計のこと、もっと知りたい」 - HOME

【1】ソフトウェア開発の歴史をさかのぼると、色んな設計手法が提唱されているにも関わらず、ソフトウェア開発がエンジニアリングと言えるレベルまで達していないように思える。

土木建築・工業に比べると、DOA・OOA・POAなどの方法論が乱立しているけれども、実際の現場ではどれも中途半端にしか適用していないのではないか？
だから、いつまで経っても同じような失敗を繰り返し、デスマーチを繰り返しているのではないか。

渡辺さんによると、システム設計で方法論が百家争鳴な理由はリファレンスモデルが欠如しているのではないか、と指摘する。

つまり、建築デザインや工業デザインでは、方法論と膨大な具体例がセットされて提示されている。
例えば、ピラミッドやローマの建築物から現代の高層マンションと併せて、その設計図が有償無償で手に入る。
音楽ならば、記法である楽譜とその手法がペアで提供されている。

しかしながら、業務システム開発では、例えば小売業界向けの業務システムのようなパッケージ製品(ERP)のリファレンスモデル(設計図)が提供されておらず、個人が入手するのは非常に難しい。
業務システムを設計するには何が必要か、その手法に関する書籍や情報があったとしても、そのサンプルが公開されていないのだ。

だから、いつまで経っても上流工程のスキルを身に付けるのが難しく、上流工程の作業に普通のPGがキャリアアップの中に組み込むのが難しい現状がある。

この状況に比べると、プログラミング技術は、そのライブラリと記法が書籍やネットなど、あるいはオープンソースで公開されており、やる気さえあれば個人がそのスキルを身に付ける事ができる。
普通は、サンプルソースや似たようなライブラリを真似ながら、プログラミング技術を身に付けて行く。
ゼロから書いていくスタイルは、もはや現代では少ないだろう。

実装技術としては、RailsやSeasarのような優れたフレームワークのおかげで、プログラミングのコストは非常に安価になった。

しかし、業務システム開発は、いつも最初からスクラッチ開発が多い。
肝心の業務モデリングという設計技術は今も昔も変わらない。
だから無駄が多く、同じ失敗を何度も繰り返しているように思える。

【2】渡辺さんの指摘で面白いのは、リファレンスモデルが欠如している理由の一つが、従来のパッケージ製品にある設計仕様をベンダーが公開しにくいから、という点。

理由は、実装コストがどんどん下がっている現状では、設計情報を下手に公開すると、最新のオープンソースのフレームワークで簡単に安く実装されてしまう危険があるからだ。

従来のパッケージ製品は、その時代の技術で実装しているため、オブジェクト指向やRailsなどのような最新の設計思想が取り込まれていない古い技術の塊。
中身のソースは非常に汚いだろう。

更には、特にベンダーのパッケージ製品は、多くの顧客でカスタマイズできるように膨大なパラメータで調整できるようになっている。
そのために複雑な設計でカスタマイズしにくく、公開したとしても割に合わないだろう。

だから、オープンソースで提供されるパッケージ製品は、ソースの中身が公開されているという特徴だけでなく、設計仕様そのものも公開されているという点で、重要な意味を持つ。

大抵のオープンソースのパッケージ製品は、シンプルな仕様で作られてるから可読性も高く、誰もがカスタマイズしやすい特徴を持つ。
たった一人のユーザ、あるいは会社が必要とする機能を実装した業務システムを、数多くのユーザが使って、バグを発見したり、UIや機能の改善要望を出す。
それらのバグ修正や機能改善を取り込んで、更にシステムがより良く育っていく。

業務システムは、たくさんの人に使ってもらえるほど知名度も上がるし、数多くのテストをユーザが自ら行ってくれる。
熱心なユーザの改善要望は、貴重な要件だ。
そのようなシステムのライフサイクルは、特にオープンソースの開発例でよく見られる。

【3】渡辺さんの指摘で面白いと思ったもう一つの点は、実装技術が安価になっていくのは必然であり、その結果、MDA(モデル駆動アーキテクチャ)も発展していくだろうということ。

実際、アセンブラやパンチカードの頃に比べると、今はTDDなどの開発技法、RailsやSeasarなどのフレームワークのおかげで、実装技術は非常に効率が高い。
これは、詳細設計とプログラミングが統合されていく傾向にあることを示している、と。

すると、設計モデルさえあれば、プログラムを自動生成する流れへ開発も向かうだろう。
実際、Railsの設計思想の中核をなすCoCなどは、まさにそれに当たるだろう。
これが、MDAの発想。

モデルもプログラミング言語で書いてしまえ、というMDAの発想は、Rubyのようにメタプログラミングの強い言語で威力を発揮すると思う。
いわゆるDSLはRubyの得意分野の一つだし。

渡辺さんの指摘で気付いたのは、MDAが実現できれば、開発者が昔から悩んできた「仕様書の保守問題」も解決されること。
設計モデルとプログラムが同期されているならば、動くプログラムを正として、リバースエンジニアリングすればいいだけ。

渡辺さんの言う通り、「仕様書の保守問題」は実装技術が発展途上だったが故に発生した現象だといえるだろう。

【4】MDAが今後の主流になっていくだろう、と言われても、肝心のモデルを作らなければ、実装できない。

渡辺さんは自身のHPで、「財務管理」「科目履修管理」「販売管理」「生産管理」「自治体」の5つの業務モデルを公開されている。
渡辺さん自身が作成された設計ツールXeadと併せて見ると良いだろう。

渡辺幸三の開発支援サイト「システム設計のこと、もっと知りたい」 - レファレンスモデル

非常に参考になるので、渡辺さんの本と併せて読むのを勧めたい。
昨今なら、上記のリファレンスモデルでテーブルが定義されているから、RailsやSeasarを使えば一瞬で実装できるはずだ。