TDDの革新性

　平鍋さんが最近、

「テストしやすい設計が良いオブジェクト指向設計である」

と述べている意見に触発されて、TDD（テスト駆動開発）が他の開発手法と異なる革新性はどこにあるのか？について考えてみた。
　下記の3点があげられるのではないか？

【１】インターフェイス中心に考えるようになる

　テストしやすいモジュール設計を突き詰めると、業務ロジックのようなアルゴリズムよりもインターフェイスの方が重要になる。更に、テストの効率を考えると、メソッドの粒度は小さいほどやりやすい。シーケンス図で書くと10ステップ以上もあるメソッドはテストしにくいはず。

【2】開発プロセスそのものが変わってしまう

　テストを実装前に置くことで、開発プロセスの順番が変わってしまう点に着目せよ。

　仕様決定→詳細設計→実装→単体テスト

という従来のプロセスではなく、

　計画ゲーム→テスト設計→実装（以下、繰り返し）

というプロセスに大きく変更される。
　つまり、ウォーターフォール型開発から、XPのようなアジャイル開発に取って代わる。
　だから、従来の経営者・管理者にとって、アジャイル開発では、従来の開発プロセスのノウハウを生かすことができないので、心理的に受け入れにくいのではなかろうか？

【３】テストできる範囲（仕様、技術）を確定するため、スコープマネジメントを暗黙のうちに行っている

　アジャイルプロセスを勉強してみると、アジャイルの長所は「チーム・ビルディング」と「スコープマネジメント」にあるという印象を持った。
　テストしやすいシステム設計を突き詰めると、プログラムの粒度は、効率よく単体テストできる大きさになる。つまり、システムはテスト設計の視点から分割される。開発時にテストしにくい部分を切り離すことによって、プログラムの品質を制御しやすくなる利点がある。
　又、イテレーションのサイズを守ることができる範囲内でタスクを分割するので、進捗を管理しやすくなる。つまり、管理するスコープをイテレーションのサイズと連携させることによって、リスクを減らしている。
　XPではきちんと書かれていないが、モジュール分割やタスク分割でスコープマネジメントを暗黙のうちに行っていることを忘れてはいけない。

　TDDとアジャイルには、プログラミング技術とマネジメントの最新のテクニックが含まれているので、研究する余地がまだあるように思う。

豆蔵が新規上場

　「システム開発の豆蔵が11月9日にマザーズに新規上場」の記事があった。
　日本のITベンチャーの中でも最も実力のある企業のせいだろうか、上場後の株価は公開価格の2倍にもなるらしい。
　ちなみに、豆蔵の社名はJava Beansに由来することを初めて知った。
　やっぱりネーミングは重要だ(^^)

ER図モデリングツール DBDesigner

　ビジネスに絡む情報システムはシステム基盤がRDBにあるので、OOAよりもDOAの方が設計に向いていると常々思っているのだが、肝心のモデリングで使いやすいツールがなかなか見つからなかった。
　ようやく、DBDesigner というフリーのER図作成ツールを見つけた。MySQLと連動しているらしく、XMLでデータを保存でき、見た目もいい。

　UMLでクラス図を描く時はJudeを愛用しているが、DOAならDBDesignerを使おう。

　ちなみに、DBDesigner4 マニュアル(日本語)はここ。

DBDesigner で書いたER図

ペアプロの重要性

　「実用企業小説 プロジェクト・マネジメント」を立ち読みしたら、「ペアシステムでメンバーのモチベーションを高める」という一節に引っかかり、興味を引いた。

　上記の本は、病院のシステム開発のプロジェクトを泥沼の状況から解決していくストーリーで、各章の最後にまとめがある。その中の一節に、「ペアシステム」という概念があった。要するに、二人ないし複数人のチームで一つの作業を進めていくことを意味しているらしい。パッと読んだ限りではペアプログラミングと同じ。

　「ペアシステム」を採用した理由が面白かった。
　IT技術が普及しない一昔前まで、一つの作業を進めるのに複数人の人手がかかっていたが、IT技術の普及で、一人で一つの作業をさせることができる環境になり、名目上の作業効率が上がった。
　しかし、一人で作業することによって、品質が甘くなったり、仕事への動機が薄れてしまったという。
　だから「ペアシステム」の導入で、以前行われていたチームによる作業の長所を生かすという。

　とある勉強会で、能力差のある二人がペアプロをすると、逆に効率が悪いのではないか、というアジャイルに否定的な意見が出た。確かに経験者に聞いたら、そういう状況は一人でドライブするようなものだから、と言っていた。
　しかし、上記の本の内容から推測すると、ペアプロの意義は、メンバーのモチベーションを高めたり、レビューを自然に行うことで品質を制御できたり、プロジェクトで作られた知識を継承することに役立つ。

　但し、ペアプロの意義は認めるが、実践して結果を出すには色んなノウハウが必要なのだろう。
　アジャイル開発には、プロジェクトマネジメントのエッセンスが含まれている。

建設では許されない設計書が当たり前のIT業界

　 「抵抗と戦い自治体の『丸投げ意識』を変えた」――長崎県総務部参事監 島村秀世氏　の記事を読んで、参事監が手がけたシステム設計の手順は、非常に参考になった。
　「建設では許されない設計書が当たり前のIT業界」という言葉は耳に痛い。
　記事では、要求から設計まで下記のような流れが紹介されていた。

【１】画面イメージ
　職員に業務フローに基づいた画面イメージを書かせて、デザイナーに書き直してもらう。

【２】データベース・フォーマット
　SEが画面イメージを基にDB設計する。

【３】システム連携
　ベテランSEが画面イメージとデータベース・フォーマットを基に、システム間連携まできちんと書かれた設計書を書き上げる。

　【１】は画面定義書、【２】はDB定義書、【３】は外部設計書に相当すると思われる。
　手順を解読するとDOAではなかろうか？
　
　また、マネジメント手法として「業務を分割する」ことが大事だ、という。業務を分割する目的は、担当職員が1人で無理なく携われるようにしてベンダーに丸投げする意識をなくすことがあるという。更に、サイズが小さければ失敗のリスクが小さいので、思い切ってやれる、と。

　上記の話を読むと、IT業界で身に着けたテクニックが他の業界でも使えるのではないか、という感触を持った。
　業務を分割する作業は、要件を分割してプログラムに落としていく作業に似ている。
　SEの仕事は何かといえば、業務フローを洗い出し、業務を分割して、外部設計をすること。更に、プロジェクトを運営して、きちんとCloseさせること。
　論理的に業務を設計することとプロジェクト・マネジメントという手法は、公務員だろうが、土建業界だろうが、どこでも通用するのではないか？

実用企業小説 プロジェクト・マネジメント

　「実用企業小説 プロジェクト・マネジメント」なる本をネットで知った。
　「The Goal」の日本版なのか？　内容が気になる。

実用企業小説 プロジェクト・マネジメントの表紙

設計原則の一覧

　「アジャイルソフトウェア開発の奥義」に出てくる設計原則の要約を一覧にしているHPを見つけたので、リンクしておく。

　全部覚えるのはしんどいなあ(^^)

スコープ管理はプロジェクト計画書から始まる

　プロジェクト管理の肝はスコープ管理。「スコープ管理はプロジェクト計画書の作成から始まる」という記事を読んで、スコープ管理のテクニックの重要性を改めて知った。

　プロジェクト立ち上げ期に、プロジェクト計画書の作成に時間をかけるということには、二つの意味がある。
　一つは、プロジェクトのゴール、スケジュール、リソースを洗い出すことによって、スコープを把握すること。
　もう一つは、プロジェクト計画書をステークホルダーの同意の積み重ねで作成することによって、ステークホルダーに「プロジェクト途中でのスコープ変更は難しい」という意識付けをすること。

　前者の内容はすぐに理解できる。
　後者は、プロジェクト計画書が単にドキュメントであるだけでなく、ステークホルダーのコミットメントが含まれていることを示している。CMMIの構成管理の考えに似ている。

　XPならば、プロジェクト計画書作成は、計画ゲームに相当するだろう。計画ゲームに顧客が混じっていることで、顧客のコミットメントもストーリーカード作成に含まれていることを示している。しかし、XPではコミットメントの意識がチームにあまりないので、ステークホルダーの利害調整に足元をすくわれる時が多いのではないか？

　スコープ管理が難しいのは、コミットメントが含まれているからだろう。つまり、プロジェクトマネージャーは、プロジェクト管理のスキルだけでなく、ステークホルダーの利害調整の橋渡しをするという政治的役割も担っている。
　その意識がないプロジェクトマネージャーが多いのではなかろうか？

開発プロセスにも構造化とオブジェクト指向の路線対立がある

　有名なシステム開発プロセスとして、ウォーターフォール・RUP・CMM/CMMIという重量級プロセスとXP・スクラムという軽量級プロセスがあるが、構造化対オブジェクト指向という軸で分類することで、より理解できるのではなかろうか？

　重量級プロセスの考え方の背景には、プロセス指向があるのではないか。重量級プロセスのリーダーは、作業手順を命令すること、作業手順の優先順位を決定することばかり考えている。その発想は、構造化設計と全く同じ。プロセスを積み上げていくと、プロジェクトが完了する、という発想。
　ウォーターフォール・RUP・CMM/CMMIはいずれもドキュメント駆動。
　RUPはウォーターフォールのV字型プロセスを小さく分割だけにすぎないのではないか？
　CMM/CMMIの肝は構成管理。仕様書や成果物のバージョン管理だけでなく、コミットメントまでReDo/Undoの仕組みを取り入れている。承認というプロセスをすごく重要視するので、経営者層の受けがいいのではないか？（倉貫さんのBlogを読むと、ユーザは承認プロセスがないと安心できないらしい）
　リーダーの立場から重量級プロセスを眺めると、プロジェクト管理の技術習得の示唆になるのですごく役立つ。特にCMM/CMMIの構成管理・履行検証のプロセスは非常に大事。

　しかし、これらのプロセスをプロジェクトに当てはめると、部下を管理している、という思いが強くなる。以前、僕も重量級プロセスから得た知識を自分なりに考えてプロジェクトを進めてみたことがあったが、部下をスケジュール通りに制御する気持ちが強すぎて、コミュニケーションがうまく行かない時があった。
　弱点は、プロジェクトメンバーのモチベーション維持が難しいことではないか。

　アジャイルプロセスの考え方の背景には、オブジェクト指向があるとはっきり言える。その発想は、責任駆動と全く同じ。チームメンバーに責任と権限の範囲内で開発の自由を与える発想。
　だから、PMBOKで言うチーム・ビルディングが非常にうまい。コミュニケーションやモチベーション維持をすごく重要視している。例えば、コーヒーブレイクとか、部屋のレイアウトとか、ペアプロとか。アジャイルプロセスのスキルは、システム開発だけでなく、オフライン勉強会やサークル活動のようなプライベートな活動にも応用できる所が素晴らしいと思う。

　XPの肝は、イテレーションのサイズをずっと守り続けること。そのためには、ストーリーとタスクの粒度をそろえることが重要になる。開発者のスキルに応じてタスクを分割すること（実際は開発者にタスクを見積もりさせるだろうが）、ユーザの要求から大きく外れないようにストーリーを分割し、ストーリーの優先順位を決定することの2点が重要に思える。
　しかし、この2点を実行する際に必要とされる技術については、誰も触れていない気がする。だから、すごく敷居が高い。
　とある勉強会で、アジャイル開発を経験しているプロジェクトマネージャが何故ビジネスモデリングに興味を持っているのか、尋ねてみたら、タスク分割時にモデリングのスキルがないと、滅茶苦茶な設計になってしまい、リファクタリングでも収拾がつかず、ゴールが見えなくなるから、と返事を受けた。
　XPはケント・ベックとマーチン・ファウラーのペアプロ経験に基づいたプロセスだから、普通の人が実行できる代物ではない。

　アジャイルプロセスには、単なる開発プロセスだけでなくプロジェクト管理の技術も含まれているのに、はっきりと認識されていない。アジャイルプロセスに必要なスキルを誰か理論として整理してくれないのだろうか？

プレゼンの極意

　昨日は母校の大学で会社説明会を開き、今日はストリームライン・モデリング発表会のためリハーサルを行い、プレゼンを2回やったが、どちらも自分としては納得できなかった。
　ビジネスマンとしてプレゼン技術は重要だから、テクニックについて改めてまとめておく。

【１】結論から入り、１つのことを違うふうに繰り返す
　SDIの佐藤正美さんが解説したプレゼンテーションの技法。
　プレゼン資料を作成する時、同じフレーズを延々と繰り返したり、あちこちに内容が発散してしまいがち。
　「１つのことを違うふうに繰り返す、というのがプレゼンテーションのルールです」という主張は目から鱗が落ちた。
　この記事を読んでから、資料の骨組みはこの考え方を基本にして作るようにしている。
＃ちなみに佐藤正美さんは、T字形ERというDOAの大家です。

【２】「分かりやすい表現」の技術

　分かりやすいプレゼン資料を書くためには、絵や記号のレイアウトまで気を使う必要がある。

【３】日本語の作文技術

　日本語による作文の技術を詳しく解説している。句読点の打ち方や、理解しやすい文を書くための単語の並べ方など、意図を正しく伝えるための技術を説明していて役立つ。

【４】プレゼンテーション・パターンズ ―― 匠に学ぶ，プレゼンの奥義 ――
　平鍋さんが解説したプレゼン・パターン。アジャイルプロセスに詳しい平鍋さんらしく、いかにオーディエンスを惹きつけるか、オーディエンスとのコラボレーションを重視している。まだどのパターンも試していないから効用は分からないが納得できるものがある。
　
　【１】はプレゼンの思想の基本。
　【２】が分かりやすい表現のための戦略なら、【３】は戦術に相当するだろう。この2つの本はどこかのHPで、プログラマが仕様書を書かざるを得ない時、参考にしたら良いとあげられた本。結構使える。
　【４】はプレゼンのテクニック。アジャイル開発プロセスに慣れている人は、システム開発をうまく制御できるだけでなく、プライベートな集団を同様に統率できるとか、プレゼン中に聴衆をアジャイル・チームに変えてしまうとか、マネジメントのテクニックに優れているのかもしれない。

　アジャイル開発は、マネジメントの技術として今後も要注意！

SL＝StreamLine Object Modeling

　ストリームライン本の表紙が機関車（列車NoはUML！）である理由は、「SL＝StreamLine」だとえがぴ～さんに教えられました。最大の謎の一つが解決できました（笑）

　ストリームライン本は非常に読みにくいです。

　協調パターン→協調ルール→サービス→実装

という目次を読むと理解しやすそうなんですが、

協調パターン定義→クラス図例示→法律みたいな説明→具体例→・・

な感じで延々と続きます。数学の本のスタイル：

公理系→補題→定理→証明→系→具体例→・・・

に似てます。

　とはいえ、ストリームライン本を読むとアナパタで出てくるパターンが実はすごく自然に導かれることが分かります。下記に「特徴」「利点」「欠点」をあげておきます。

【特徴】
　オブジェクト指向の発想に基づくクラス図に出てくるエンティティやトランザクションは、12個の協調パターンのいずれかに当てはまる。（証明できるのか？）
　協調パターンに付随するビジネスルールを詳細化していくと、モデリングから実装まで一気貫通できる（らしい）。

【利点】
　クラスよりも関連に着目することで、エンティティやトランザクションの存在意義をはっきりと説明できる。
　特に、「トランザクションが多くの協調パターン間を調整する」という重要な役割を何度も指摘している。ストリームライン本では、トランザクションを「オブジェクトモデルの糊」と呼んでいる。

●例：「本質」に出てきた「ものーことーもの」パターン
　　→「ストリームライン」で翻訳すると、二つのエンティティ（もの）が関わる時、必ずトランザクション（こと）が協調パターンとして自然に（！）導かれる。
　例えば、人と場所が関わると必ず事象の履歴（例：住民票の履歴）を表すトランザクションが発生する。
　そんな例が延々と続く（疲れます）

●例：「本質」に出てきた「予定ー実績」パターン
　→「ストリームライン」で翻訳すると、「ロールートランザクションー品目」と「ロールー後続トランザクションー特定品目」を組み合わせたものになる。

●例：アナパタの勘定パターン「会計取引ー明細ー勘定科目」
　→「ストリームライン」で翻訳すると、「コンポジットトランザクションー明細ー特定品目」の協調パターンになる。
　コンポジットトランザクションとは、トランザクションの集約です。

【欠点】
●どの章から読み始めても、すごく読みにくい。
●協調パターンに基づくビジネスルールの説明は法律のような文体で読みにくい。
●モデリングは面白いが、実装の方法は大したことはない。付属サンプルソースはしょぼい！！（テストクラスはせめてJUnitを使え！！）

　詳細の続きは、発表会で。

思考系UMLモデリング即効エクササイズ

　「思考系UMLモデリング即効エクササイズ」を立ち読みしながら、13個の問題をその場で解いてみた。

　モデリング道場MLでも紹介された本なのだが、パズルを解くのと似た感じで面白い。プログラミング言語を知らなくても楽しめそう。

　僕の頭では、最初の「正義の味方」「アイスクリーム」のモデルはすぐに理解できたが、「じゃんけん」「待ち合わせ」のモデルは間違いに引っかかった。感想は、やっぱりオブジェクト図がすぐに思い浮かばないと駄目そう。

XPはスコープ管理を重視する

　XP（eXtreme Programming）は色々な要素のスコープをすごく重視している。しかも、あまり意識しなくとも実践できる所が良い気がする。

　とある勉強会で、「イテレーションのサイズを守ることは要求のスコープ管理を行っていることと殆ど同じだ」と聞いた。
　計画ゲームでイテレーションの順番を決める事は、要求の優先順位を決定する事と同義だ。イテレーションのサイズを守るために、顧客からの要求を後回しにすることもある。
　XPを実践したプロジェクトでは、経験上、最初のイテレーションは非機能要求が多いため、どうしても長くなるが、2回目以降はなるべく長くならないようにする。
　タスクのサイズは極力小さくする。基本は1人日（！）。3人日もかかるタスクは進捗をコントロールできなくなるから、などなど。

　いずれの話も、ストーリー作成やタスク分割のテクニックとも言える。
　ストーリーやタスクのスコープが小さければ、たとえ失敗しても取り戻すコストは必然的に小さくなる。イテレーションが短ければ、結合テストできる時間帯が多いことを意味している。

　XPのようなアジャイル開発で一番気になるのは、管理工数（例えば、「タスクカードを作成する」というタスクカード）を意識しているのか、という点なのだが、話を聞くと、非機能要求や開発環境整備などのタスクも作成しているらしい。
　5人ぐらいのチームならばそのような管理工数は殆ど無視できようが、10人とか100人の規模になれば、管理工数は爆発的に増える。スコープ管理するための管理工数も必要になるだろう。

　スコープ管理が気になるのは、システム開発のボトルネックそのものだから。
　どのプロジェクトにも通用するスコープ管理のテクニックはあるのだろうか？
　何となくCMM/CMMIにヒントが隠されている気がする。

アジャイルソフトウェア開発の奥義

　アジャイルソフトウェア開発の奥義はすごくいい！
　レガシーなオブジェクト指向よりも、奥の深い以下の根本的原理が説明されている。

【１】開放閉鎖原則　(Open-Closed-Principle)
【２】Liskovの置換原則　(The Liskov Substitution Principle)
【３】依存反転原則　(The Dependency Inversion Principle)
【４】単一責任原則　(The Single Responsibility Principle)

　まだきちんと読み込んでいないが、興味を引いた箇所は、「全ての場合に通用できる自然なモデルは存在しない」「モデルの正当性は立場によって異なり、立場を抜きにした正当性を証明することは無意味」という主張があらゆる原則の説明で出てくる。
　つまり、シンプルな設計が重要だ、ということ。将来の仕様変更に対応しようとして、不必要な複雑さをシステムへ織り込んでしまうのは危険である、と書かれている。すごく納得。

　しかし、内容がアジャイル開発だけに限らないように感じるのは、理解不足なためか？

　上記原則を説明しているHPは、オブジェクト指向の法則集しか見当たらない。
　今度、まとめよう。