2010年6月28日月曜日

主語 ← ユースケースの最初の一歩

最近入った開発部隊で、ユースケースらしきものが作られていたが、どうにも酷すぎる。

最初のページにスティックマンを書いたら、残りのページのシナリオに何を書こうがOKなんて思ってるんだろうか・・・

ユースケースを知らないライタが命ぜられるまま書いて、それと同じくらいユースケースを知らないレビュアーが検定して、「どう役に立つか知らないけど、とりあえず何となく意味が通じない事もない気がする。スティックマンと楕円が、何となくユースケースっぽさをかもし出しているし。」みたいなレベルなのが見え見え。

これではいけないので、チェックリストを作って、ライタがレビュー前にそれを使って、ユースケースとしての最低レベルに自力で持って行けるようにしたい。レビュアーも自分が本来意識を向けるべきところにのみ集中できるはず。

という訳で、いつものとおり「まずは必ず他人の成果を利用する事から始める」ポリシーに従って、手持ちの本とかWebでみた資料をいろいろ思い浮かべる。で、Cockburn のユースケース本 に何かあったのを思い出し、実物を開いて裏表紙に載っている「Pass/Fail Tests for Use Cases Fields」 というリストを確認。

以下のような内容。
◆ Use Case Title
1. Is it an active-verb goal phrase that names the goal of the primary actor?
2. Can the system deliver that goal?

◆ Scope and Level
3. Are the fields filled in?

◆ Scope
4. Does the usecase treat the system mentioned in Scope as a black box?
5. If the system in Scope is the system to be designed, do the designers have to design everything in it and nothing outside it?

◆ Level
6. Does the use case content match the stated goal level?
7. Is the goal really at the stated goal level?

◆ Primary Actor
8. Does he/she/it have behavior?
9. Does he/she/it have a goal against the SuD that is a service promise of the SuD?

◆ Preconditions
10. Are they mandatory, and can they be set in place by the SuD?
11. Is it true that they are never checked in the use case?

◆ Main Success Scenario
15. Does it have 3-9 steps?
16. Does it run from trigger to delivery of the success guarantee?
17. Does it permit the right variations in sequencing?

◆ Each Step in Any Scenario
18. Is it phrased as a goal that succeeds?
19. Does the process move distinctly forward after its successful completion?
20. Is it clear which actor is operating the goal--who is "kicking the ball"?
21. Is the intent of the actor clear?
22. Is the goal level of the step lower than the goal level of the overall use case? Is it, preferably, just a bit below the use case goal level?
23. Are you sure the step does not describe the user interface design of the system?
24. Is it clear what information is being passed in the step?
25. Does it "validate" as opposed to "check" a condition?

◆ Extension Condition
26. Can and must the system both detect and handle it?
27. Is it what the system actually needs?

◆ Overall Use Case Content
29. To the sponsors and users: "Is this what you want?"
30. To the sponsors and users: "Will you be able to tell, upon delivery, whether you got this?"
31. To the developers: "Can you implement this?"

ユースケースを書く上での重要なエッセンスだけ抽出した、非常に濃いチェックリストなんだけど、うーん・・・

これは、すでにある程度の経験を積んだ人か、少なくともこの本をじっくり読了した人になら有用だけど、未経験者にはほとんど意味が通じない予感(日本語に訳したとしても)。もうちょい機械的というか事務的に作業できるのを作る必要があるなあ。

まあ、それは後で何とかするとして、ユースケースに余り自信のない人は、とりあえず各ステップの主語をちゃんと書く事から始めるのがお勧め。ただし主語といっても、定義が若干あいまいな日本語文法のそれというより、英語のような動詞に対するものとしての主語。もう少し言うと、状態動詞ではなくて動作動詞で、さらに能動態の主語。

動作の主体、ボールをキックするその人、動きが生じて状況が前進する瞬間の主役を主語として、ステップを記述する。そうすると、ユースケースにまつわる他の事も分かってくる。つうかそれが駄目だと、ユースケース全体の他のすべての項目も多分駄目。

つうわけで、主語だけはしっかりと書くべし。まずはそこからだ。
・・・なんて、上から目線で言ってみる。

2010年6月27日日曜日

AntiPatterns over DesignPatterns

日ごろからデザインパターンよりアンチパターンの方にこそ着目すべきだと、常々考えている。

GoFのデザパタ本の最終章で、デザイン・パターンこそがリファクタリング(再分解)に方向性を与えるといった有名な記述があって、後にファウラーのリファクタ本が出た時に、みんな読み返して「やっぱデザパタだね」なんて頷いたりしたが、それでも自分は、アンチパターン(の回避)こそがリファクタリングの指針としても優先されるべきだと思う。だからこそリファクタ本でも先にCodeSmell が語られていたはずだし。

さらに古い話だけど、コプリエンの『C++プログラミングの筋と定石』というのが出たときにも、イディオムの記述もさることながら、やってはいけない事について割と力をいれて書いていたのが、非常に有益だった(業界でもそれで高評価を得ていたような記憶があるし)。

こういう、アンチパターンへの感覚は、日常生活においての「格好いい事を主張する以前に、まずは人並みであるべき」という常識だとか、学歴やスキルの高さ以前に犯罪歴や暴力性向が無いことが前提とされたりする事のような、ごく当たり前の感覚にも通じていると思う(芸術家は別だけど)。

そんな自分の思いに反して、アンチパターン系の知識は、パターンやベストプラクティスが歓迎されるほどには省みられない。当たり前すぎて語られないのならまだしも、そもそも知られていなかったり、無視され、読み飛ばされてしまっている。減点方式っぽい思考法なので日本人に向いているような気がするけど、現実は逆だったりする。

それどころか、こういう割と普通の感覚が、既に動いているプロジェクト・チームに新たに参入した時に、場合によっては地雷を踏むきっかけになったりする。

アンチパターンを解消するには、まずはそれを発見する事から始まるが、上手くやらないと、上から目線であら捜しをしていると捉えられる。また、現行メンバの仕掛中作業を妨げないように、自分がリファクタリングや後付テストコード記述をするなんて申し出たりしても、自分だけ手を汚さずに当て付けがましい事をしているように見られる事もある。(もちろん「お前ら全員今からリファクタしろ」なんてストレートに言うと、さらに楽しくない状況になる。つうか、そんな事言えない。)

門外漢には、そんな子供っぽい現場は滅多にないだろうと思われるかもしれないが、プロジェクトが1年も続くといろいろな事があるし、特に一旦火を噴いてやっと沈静化しかけた頃のような現場だと、かなりのメンバの心の中に、大人でもなかなか笑って水に流せないトラウマがわだかまっていて、至るところ地雷だらけだったりする。

まあでも、自分が最近、途中から参入した現場はそんな危険な雰囲気も少なく、アンチパターン/ワーストプラクティス/コードスメルが大量にある割には、メンバの精神状態もおおむね良好で割と気楽なんだけど、それでも油断できない。上の人間は早く成果を出せと思っているっぽいが、やはりここは、ゆっくり慎重に行こうと思う。

本当に技術者ってデリケートなんだよなあ・・・

Typemock--コンストラクタの呼び出しチェックが・・・

テスタビリティの悪いシステムに後付のユニットテストを書く事になりそうなので、モッキング・フレームワークを検討中。

フリーの Moq やら何やらは、バーチャル・メソッドしかモックできないなんて制約があって、最初から最大限にテスタビリティを考慮したシステムにしか適用できそうにない。それ以前に、そもそも.net フレームワーク自体がテスタビリティを下げる犯人でもあったりして、悩ましい。

そんなこんなで、Typemock Isolator という有料のものを見つけて、個人ライセンスで試用しているが、どうやらこれしか選択肢はないらしい。静的メソッドや sealed までモックテストできたりする。

さすがに有料だけあって、非常に強力なのだが、ちょっとモッキングが難しいパターンを発見したのでメモしておく。
class Class1
{
    public string Name {get; set;}
    public Class1(string name)
    {
        this.Name = name;
    }
    public void ShowName()
    {
        MessageBox.Show(Name);
    }
}
class Program
{
    static void Main(string[] args)
    {
        Class1 class1 = new Class1(args[0]);
        class1.ShowName();
    }
}

上記のようなコードで、Main()メソッドの後付をテストコードを書くとすると、モックテストとしての要点は、
  1. Main()が引数の先頭要素を Class1 コンストラクタに渡している事を検証する
  2. 生成したインスタンスの ShowName()メソッドを呼ぶ事を検証する。
  3. 但し、実物の ShowName()は実際に呼ばれてはいけない。
というものになる。

ここで仮に、1)の要件が無いとすると、以下のような EDSL 風のコードで2)と3)をテストできる。
[Test, Isolated]
public void Test1()
{
    string[] args = {"arg1"};
    //Arrange
    var fake = Isolate.Fake.Instance<Class1>();
    Isolate.Swap.NextInstance<Class1>().With(fake);
    //Act
    Isolate.Invoke.Method<Program>("Main", new object[] { args });
    //Assert
    Isolate.Verify.WasCalledWithAnyArguments(() => fake.ShowName());
}

テスト対象メソッドの中で生成されるオブジェクトを、実行前に生成した贋物にすりかえてしまえるのが面白い。

ところが上記のような、Isolate.~~(AAA APIと言うらしい)を使う方法だと、要点 1)のコンストラクタにへの引数を検証するやり方がどうも見当たらない。

調べると、Typemockには AAA API の他に、より古いAPIセットがあって、こっちにはコンストラクタ引数の検証メソッドがあるという。
以下のようなコードで、要点1)を検証できる。
[Test]
public void Test2()
{
    string[] argument1 = {"arg1"};

    MockManager.Init();
    Mock theMock = MockManager.Mock<Class1>(Constructor.NotMocked);

    theMock.ExpectConstructor().Args(argument1[0]);
    theMock.ExpectCall("ShowName", 1);

    Isolate.Invoke.Method<Program>("Main", new object[] { argument1 });

    MockManager.Verify();
}
ところがTest1()とTest2()を、どうしても一つのテストメソッドにマージできない。
Test2()の古いAPIセットを使う方式だと、一個のメソッドで、1)~3)までテストする事もできない事はなさそうだが、陳腐化しはじめているし、そもそもTest1()のAAA APIが推奨されているし、やっぱり嫌だ。

上のような状況の後付テストを書くときは、1メソッドに対して2系統のテストを書く事になるのか・・・
それとも、AAA に未発見の API があるのか・・・
後者に期待したいが。

====
と言うかそれ以前に、これを使うとした場合、プロジェクトとして調達するためにステークホルダに説明しなければならない事として、
  • 現状のシステムのテスタビリティが低すぎる事。
  • モックテストとは何か、その必要性はどんなものか
  • 既存の書きかけのテストコードが、下手糞すぎて使えない事
  • functional test と unit test が混同されていたり(違いはここ)、何のテスト方針も定まっていない事
などなど、いろいろあって、そこから面倒くさい。

2010年6月21日月曜日

証券外務員2種合格

今日、プロメトリックで証券外務員2種の試験を受けて合格した。

勉強量は、休日を利用しての(10H~12H)×3日に、平日の空き時間の勉強を加えて40時間強くらい。日本経済新聞社から出ているノースアイランド編の問題集を使ったが、これより少し難しく感じた。ただ以前に取った簿記2級やFP2級と被っている出題範囲が多く、その分だけ楽だった。

取得目的は、いま携わっている開発案件が証券のシステムなので、その勉強のためだったけど、やってみると知識の範囲がかなり違っている事が分かった。開発中のシステムではユーザは証券会社のディーラーだけど、一方、証券外務員が相対するのは一般投資家だったりして、知識のジャンルが思いのほか大きく違う。まあ、証券業界人にとっては常識的な事柄ばかりだろうから、SI屋としても知っておいて損ではない情報なのだろうとは思う。

こんな感じで業務知識(とその資格)を貯めていって、そのうちドメインモデルの分析からちゃんとやりたいと思う。今の自分の状況だと、何というかIT色・オブジェクト指向色の濃い、アーキテクチャ周りの仕事を受け持つ事が多くて、自分がフレームワークを選定したりアーキテクチャを考えているうちに、いわゆる業務系SEとかいう人達が、何の分析も何の洞察もないまま体裁だけまとめた「設計書」を作っちゃっていたりする。

「業務知識なら割と自信がありますよ」なんてサラっと言えて、その証明らしきものも提示できる様になれば、ドメイン分析の担当に志願しても、それほど反対される事はないのではないかと思う。

2010年6月14日月曜日

The Test Smells

xUnit Test Patterns』 に載っている、CodeSmell の xUnit バージョン。

どうもこの本は、まとめ方が若干惜しい。掲載されているテストのノウハウは、量も多く網羅的で、プログラマなら(特にプログラマのリーダ的な立場の人は)、知って置きたいテクニックが満載なんだけど、見せ方がいまいち。

自分は、特に「Test Smell」のパートがこの本の中でも重要な部分だと思っているけど、ここも違和感がある。一個の Test Smell のカタログ項目として、複数の Causes(原因)が列挙されているが、これら自体が Test Smell だったりして、何だかややこしい。

以下のような Test Smells が掲載されている。
  • Project Smells
    • Production Bugs:
      公式なテストで(開発チームの手を離れてからのテスト)、または出荷した後に見つかるバグが多すぎる
    • Buggy Tests:
      テスト自体にバグが多い
    • Developers Not Writing Tests:
      テストコードが書かれていない
    • High Test Maintenance Cost:
      メンテするのが大変すぎる
  • Behavior Smells
    • Fragile Test:
      テスト対象コードに含まれない、他所の部分の改修によって、テストが通らなくなる
    • Assertion Roulette:
      テストメソッド中の、どのアサーションが失敗してるのか分かりにくい
    • Erratic Tests:
      その時々で、あるテストが通ったり通らなかったりする
    • Frequent Debugging:
      テストが通らない原因が、いちいち手動デバッグしないと分からない
    • Slow Tests:
      テストの実行に時間かかりすぎる
  • Code Smells
    • Obscure Test:
      何がどうなる事を検証しているのかが不明瞭
    • Conditional Test Logic:
      テストロジックの中に条件分岐があって、場合によって実行パスが通ったり通らなかったりする
    • Hard-to-Test Code:
      テスト対象コードのテスタビリティが低すぎて、テストが書けない
    • Mannual Intervention:
      いちいち手作業で何らかの介入をしないと進まない
    • Test Code Duplication:
      テストコードが重複している
    • Test Logic in Production:
      製品コードにテストコードが含まれてしまっている

xUnit に慣れているプログラマなら、上記のほとんどの Test Smells について、常識だと思うかもしれないけど、熟練者がいないチームで暗中模索しながら書かれたテストコードなんかだと、かなりの頻度で遭遇するアンチパターンだったりする。

2010年6月9日水曜日

Concurrency patterns

並行/並列実行とかマルチスレッドのパターンの情報源。

まずは POSA 第2巻。並行とネットワークのパターン集から。
Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects
Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects


直接的には、「Concurrency patterns」 にカテゴライズされている以下のパターン。
  • アークテクチャ・パターン
    • Half-Sync/Half-Async
    • Leader/Followers
  • デザインパターン
    • ActiveObject
    • MonitorObject
    • Thread-Specific
また、関連するカテゴリとして「Event Handling Patterns」と「Synchronization Patterns」があり、以下のような内訳
■ Event Handling Patterns
  • アークテクチャ・パターン
    • Reactor
    • Proactor
  • デザインパターン
    • Asynchronous Completion Token
    • Acceptor-Connector
■ Synchronization Patterns
  • デザインパターン
    • StrategiedLocking
    • Thread-SafeInterface
    • Double-CheckedLockingOptimization
  • C++ イディオム
    • ScopedLocking

上述のパターン群のうち多くは、下リンクの『パターン言語』でも、分散・並行化設計パターンのパートに含まれている。
プログラムデザインのためのパターン言語
プログラムデザインのためのパターン言語

ただし POSAv2 に無い、以下のパターンも含まれている。
  • ObjectSynchronizer
  • ObjectRecovery
  • Bodyguard


.NET 4.0 の Parallel Patterns というものもある。以下のリンクから C# 版とVB 版 がダウンロードできる。
PATTERNS OF PARALLEL PROGRAMMING
  • Delightfully Parallel Loops
  • Fork/Join
  • Passing Data
  • Producer/Consumer
  • Aggregations
  • MapReduce
  • Dependencies
  • Data Sets of Unknown Size
  • Speculative Processing
  • Laziness
  • Shared State
実はさっき見つけたばかりで、まだ読んでいない。C# の仕事をする事になりそうなので興味深いが、現場では多分 .NET 3.5 を使う事になりそうな模様。

2010年6月7日月曜日

mocking の要点

モックを使うと何がどう変わるかを、単なる assertion と比較して考えてみる。

例として、以下のような testTarget のテストを考える。testTarget オブジェクトは foo() 呼び出しの中で、collaborator の bar() を呼び出す。この testTarget → collaborator の関連は、クラス図や CRCカードにも明記されるような、れっきとしたクラスの仕様であるとする。

これを xUnit の昔ながらの assertion でテストすると、下図に示すように、テスト・コード管理下に入るのは foo() 呼び出しの条件と結果となり、カバレッジに含まれるのは赤の網掛けの部分となる。

ここでまずい点が三つある。

① testTarget と collaborator の協調がテストされていない。collaborator を正しい条件で呼び出しているか、また得られた結果を正しく扱っているかが検証されない。(それどころか、collaborator を呼ばないダミーコードが実装し忘れたまま残されていたとしても、テストコード側では認識しようもない。)

② テスト対象外のコードまでがカバレッジに含まれてしまっている。collaborator のコードは、collaborator のテストコードが書かれて始めてカバレッジに含まれるようにしないと、網羅率が正味のテスト実施状況と乖離してくる。テスト漏れも生じやすくなる。

③ collaborator の bar() を実行するために、リソースやらコンテナやらのセットアップが必要な場合、テストコードが煩雑になる。また多くの場合、テストの実行速度も物凄く遅くなる。

これに対し、xMock を導入して assertion と併用すると、上述の問題が改善できる。

上図は collaborator をモック化した場合のもの。collaborator 呼び出しの条件がちゃんと検証され、返される結果もテストコードからコントロールできるようになる。カバレッジはテスト対象コードのみとなり、リソースをセットアップする手間もなくなって実行時間も早くなる。

デメリットがあるとすれば、テクニック的に assertion よりは若干難しい事くらいだろうか。他のクラスとの協調も検証対象になる分、書かなきゃならないテストコードの量が多くはなるが、本来テストすべきだった事ができるようになっただけなので、別にデメリットという事にはならない。

PMBOK と waterfall

ソフトウェア業界にいていろんな人と会話する中で、たまに PMBOK の話題になるが、PMBOK とはウォーターフォール型開発のためのプロジェクト管理手法であって、アジャイル系のプロセス・モデルには馴染まないと思っている人が結構多い。

そもそも PMBOK は、ソフトウェア開発のための知識体系ですらないけど、まずそこからして誤解が多い。

ちなみに、手元の PMP の参考書に載ってるケーススタディを適当に抜き出すと、
  • オリンピック支援チームを収容する建物の建設プロジェクト
  • 映画製作のプロジェクト
  • 郵便局に新しい料金システムを導入するプロジェクト
  • 高速道路を拡幅するプロジェクト
とかだったりする。ソフトウェア開発に限ったものでは全くないし、ましてウォーターフォールとか、なおさら関係ない。

(もしかすると PMBOK 関連の記事をチラ見して、「立ち上げ、計画、実行、監視コントロール、終結」からなる5つのプロセス群に、ウォーターフォールのフェーズ「要件定義、設計、実装、テスト、移行」を勝手に脳内マッピングしちゃったりしてるのかも。)

だからと言ってアジャイルに親和性が高いのかというと、そう言うわけでもない。結局、相当の応用力が要求されるという点では、どんなプロセスモデルを採用しようと変わらない。例えば経営学という知識体系が、どんな会社の経営を対象とするのか問題にしていないのと似ていると思う。

ただし、アジャイル開発者が PMBOK を勉強するのをためらっている理由が、冒頭に書いたような誤解だとしたら、決してそんな事はないので、お勧めしておきたい。プロセスについて日頃から考えている人ほど、面白く感じられると思う。

2010年6月6日日曜日

Systems thinking のパターン

システム・シンキング入門』という本で、「システムの原型」として把握される5つのパターンが紹介されている、。ソフトウェア開発プロジェクトの分析にも、大いに使えそうなので、以下にまとめておく。

■ 応急処置の失敗
・対症療法が予期せぬ悪影響を発生させて、問題が悪化していく因果ループ
・分類:悪化ループ

開発現場で実によく見かけるもの。例えば「時間が無い」という「問題」に対して、「応急処置」として何かのタスクを省略したりすると、大抵このパターンにはまって後で大変な事になる。

あと切羽詰ったプロジェクトで、下手に増員して却って火に油を注ぐのも、ほぼこのパターン(ほんの少し構造が違うが)。

■ 問題の転嫁
・対症療法による目先の効果により、本来必要な根本的対応が先送りされてしまう因果ループ
・分類:悪化ループ
これもよくある。例えば、「根本的な解決策」がアーキテクチャの変更を伴うような場合に、重い作業を避けてベタな暫定対応に逃げたりすることが良くあるが、やればやるほどコードのメンテ性が低下して、抜本対応が遠のいていったりする。

■ エスカレーション
・双方の行為が脅威となって、互いに行動をエスカレートしていく因果ループ
・分類:悪化ループ
システム開発プロジェクトでは、意外と見ないかも。ちょっと思いつかない。現実の社会では、軍拡競争など、分かりやすいサンプルが豊富。

■ 成功の限界
・拡張プロセスがバランスプロセスに変化して、勢いを失い進歩が止まる因果ループ
・分類:停滞ループ
リファクタリングが実践されていないチームでは、機能追加/変更によるアプリケーションの成長の陰で、重複コードの増殖やメソッドの長大化により変更コストが増加して、結局アプリケーションの成長も鈍っていく事になる。開発者なら分かりやすいパターンだと思う。

あと、組織やユーザが大きくなればなるほど、それ自身の重さが進化を鈍らせるという点では、昨今、Java がパターンにはまっているような気がしないでもない。

■ 成功が成功を生む
・両立すべき事柄の一方での成功が、他方に一層の失敗をもたらす事になる因果ループ
・分類:悪影響ループ

Java と .NET の間で、このパターンが生じる事がある。Java にも .NET にも、それぞれ長所短所があるので、合理的に使い分けられるのが理想だけど、ある局面での Java の選択は、Java 技術のスキル向上を促す一方で、.NET 技術の スキル低下を引き起こす事にもなり、次の局面での Java の選択圧力を強める。これがループして、Java/.NET 間の格差が一定限度を超えると、.NET を使えば低コストに開発できるような場面でも、スキル的に Java しか選択できなくなったりもする(逆も成立する)。結構、優秀な技術者でもこうなってる人が意外と多い。

====
アンチ・パターン/プラクティスのうち、プロジェクト管理や開発プロセスの領域に該当するものは、Systems Thinking の方法を使うと統一的に現象を記述できるような予感。因果ループ図を取り入れて、アンチ・パターンのカタログを再編集してみるのも良いかも。

2010年6月5日土曜日

ブラック・ショールズ方程式の解のグラフ

wikipedia のブラックショールズ方程式の解の式をグラフ化してみる。

以下の条件で、
権利行使価格(K)110
安全利子率(r)0.07
ボラティリティ(σ)0.2
期間(τ=T-t)0.25
横軸にとった原資産価格に対するコールオプションプレミアムの適正価格を、Excel で折れ線グラフにしたものが下図。


原資産価格110のところがアットザマネー(ATM)で、左側がアウトオブザマネー(OTM)、右側がインザマネー(ITM)ということになる。OTMからATMに近づく辺りで上昇し始めて、ITMではK・exp(-rτ)≒108 から右上45℃に延びる線に漸近する形になる。

式だけ見ても全然想像がつかないけど、グラフに描いてみるとなんとなくイメージがつかめる。正規分布なんかでも、誰でもそのグラフ形状ならしってるけど、式自体は結構難しかったりするし。

2010年6月3日木曜日

usecase の本

久しぶりに仕事でユースケース書く事になりそうなので、以下に手持ちのユースケースの資料を整理。

Writing Effective Use Cases
Writing Effective Use Cases

言わずと知れたユースケースライターのバイブル。読めば読むほどユースケースを書く作業が面白くなってくる。書いているうちに沸いてくる疑問や迷いについても大抵答えが提示されている。

実用的には、とりあえずこの一冊があれば十分じゃないだろうか。チームで作業するときも、この本から要点を抜き出してガイドラインにして配布するようにすればいい効果が期待できる。

Patterns for Effective Use Cases
Patterns for Effective Use Cases

内容は『Writing Effective Usecases』に載っている事がほとんどだけど、パターンカタログの体裁をとっているので、そういうスタイルが好きな人には良い本。

Applying Use Case Driven Object Modeling with UML
Applying Use Case Driven Object Modeling with UML

タイトルからは分かりにくいけど、ほぼ ICONIX というアジャイルプロセスの解説書。
ICONIX では ユースケース が重要視されていて、他の成果物やタスクとも絡んだプロセス全体の中での活かし方とか位置づけとか、結構参考になる。他に、Domain Model や Robustness 分析についても上手に解説されていて、なかなかの良書。

ユースケースによるアスペクト指向ソフトウェア開発
ユースケースによるアスペクト指向ソフトウェア開発

ユースケースの開発者のヤコブソンが、アスペクト指向をとりこんで発展させたもの。

アスペクトって、ログとかトランザクションとか実装レベルかつ非機能要件の領域で語られる事が多いけど、もっと高い抽象度でドメインよりの話題としても語られても良いのではなかろうかと思ってるときに見つけた本。

と言っても実は、正直まだよく理解できていなかったりする。上の3冊はサクサク読めて現場でもすぐに役立てられる本だけど、この本はある程度時間をかけてじっくり読む必要がありそう。

====
他にも何冊か UML の参考書があって、中でユースケースにも触れられているけど割愛。なんかユースケースのスティックマンのおかげで、ユースケース本来の重要性が見失われ続けている気がしないでもない。

2010年6月2日水曜日

プロジェクトの英語化

楽天で英語が社内公用語になったらしい。[→この記事]

この施策が、事業の国際化に正味どれだけ貢献するか知らないけど、技術者としてはちょっと興味深い。例えば、システム開発プロジェクトへの英語の導入を想像してみたくなるが、ちょっと思案してみると、まんざら不毛なアイデアでもなさそうな予感。期待したいのは、国際化なんかじゃなくて、システム開発を合理化したいという、それだけなんだけど。

まあ、進捗会議やら朝会やらでの英会話は無理っぽい。「日本人は読み書きはできるが会話は苦手」なんて言われてもいる程だし、とりあえず読み書きのみの英語化にとどめて良いと思う。


話を簡単にするために、自社で販売するパッケージ製品の開発や、英語でコミュニケートできるクライアントのための開発を想定して、クライアント組織の言語はとりあえず考えなくて良い事にすると以下のような感じだろうか。

☆ まずユースケースの英語化。これが最も効き目の大きなところだと思う。

そもそもオブジェクト指向においては、要件定義に現れて来るドメインの語彙が、そのまま 名詞 ⇒クラス名、動詞 ⇒メソッド名という形でソースコードに直接的に投影されるという事が重要で、同時に開発者が留意すべき点でもあったはず。プログラム中の識別子の語句と、ユースケース/ドメインモデルの語句が同一である事が、内部品質(≒保守性≒生産性)にも大きく貢献していたのだと思う。

ところが日本のプロジェクトでは、日本語の上流成果物から英語ベースのソースコードに至る過程のあちこちで、脳内和英変換でエネルギーを浪費させながら作業する羽目になる。あまりに常態化しているのでなかなか反省されにくいが、洋書に載っているような演習やケーススタディ、つまりユースケースにもソースコードにも共に英語を使っているものと比較すると、明らかな不経済だと分かる。

やはりまずは英文ユースケースが欲しい。投入すべき労力も大きそうだが、得られる見返りも大きいと思う。

☆ で次に、ユースケースが英語化できたら、ソースコードに至るまでの中間的なドキュメントも、やはり英語化。まあユースケースが英語になった時点で、後続の成果物の英語化も大分楽になってるはず。ハードルは低いと思う。

JavaDoc 等のいわゆるヘッダコメントも英語で記述。当然ながら、識別子に用いられるコトバと、その説明に用いられるコトバは統一されている方が、別々の言語からとった語をそれぞれに適用するよりも合理的と思われる。

ソースコメントについては、昨今の流儀では「コメントを書いている暇があったら、コメント無しでも読みやすいコードを書くよう工夫すべし」とされているが、英語を意識して開発できるようになれば、各ステートメントが英文ライクな構造に、自然とフツーに近づいていくはず。まあ、どうしてもコメントを書くなら英語で書くべきだろう。

☆ その他の英語化対象としては、WBS、スケジュール表といったところか。
Trac のチケットや wikiも英語化によるメリットがありそう。

====
てか、そもそも普段使っているプログラミング言語のキーワードや API の識別子のほとんど全てが、英語話者が何百年も前から使っている人間の言葉だったりする。それに文法の面でも、大抵のオブジェクト指向言語では、なんとなく英語構文の語順を意識している節がある。
(SVO と subject.verb(object) みたいな)

こういう事を考えると、なんだか全面的に英語で開発するというのがプログラミング本来の姿なのではという気さえしてくる。

なんていろいろと書いたが、現実のIT業界では「会話はできないけど読み書きはできる」という前提からして、まず怪しかったりする。そこそこ読み書きできる開発メンバを集めるだけでも、実は大変かもしれない。