MSはCMMに取り組む必要なし

　とある勉強会MLで「ソフトウエア企業の競争戦略」の話が出た折、著者クスマノ氏が「MSはビジネス上CMMに取り組む必要はない」という指摘を昨年の講演で話したらしい。
　うーむ、すごすぎ(^^)

　どんな文脈でそんな話があったのか知らないが、インパクトがある。
　僕の少ない経験では、日本のソフト会社でCMMに取り組んでいるとしたら、それは製造業のISO等の品質管理のソフトウェア版に相当する。その作業はドキュメントが非常に多すぎて、普通の業務にも支障が出るぐらいなのに、やらざるを得ない。
　CMMでレベル5を取ったからと言って、それでビジネスの利益に結びつくのか、と言われると、心もとない所は確かにある。

　CMMのようなプロセスはウォーターフォール型開発に近い。しかし、今のソフト開発の流れは、繰り返し型開発プロセスが主流。
　重要な点は、ウォーターフォール型開発では、設計や実装を重視してテストを軽視するが、繰り返し型開発プロセスでは、ビルドやテストの方を重視していることだと考える。

　「ソフトウエア企業の競争戦略」感想文が載っているここのBlogでは、下記の問いが投げられている。

「Windows開発プロジェクトチームのうち、最も強い「権力」を持っていた
のはどれか?

　　1.プログラマ
　　2.テスタ
　　3.ビルダ
」

　僕は「テスタ」だと思っていたが、実は「ビルダ」だった。
　ビルドって、1日の最後に夜間バッチで働いてくれるぐらいしか思いつかないし、ビルド担当者は新人SEが任せられる時が多いけれど、実は一番重要なんだよね。

　最近、「構成管理」という言葉が流行しているけれど、その概念は「ビルド」プロセスに密接に絡んでいる。
　なのに、構成管理の概念はCMMなどのプロセス管理の本でよく出るのに、ビルドプロセスとの関連を説明している本は少ないらしい。

　日本人は品質管理にうるさい面はある。その特徴が製造業では有利に働くが、IT産業では実は優位性がそれほどないのだろう。少なくとも、日本のどのソフト会社よりもMSの方がITビジネスで成功しているし。
　ソフトウェア開発のプロセスはもっと研究する余地があるように思う。

継承→Aspect→DI へプログラミング言語は進化している

　オブジェクト倶楽部の定期MLで、「オブジェクト指向の再定義」と題して平鍋さんが連載記事を書かれているが、すごく面白い！
　記事の中で印象に残った言葉は、下記の二つの文章。

「EoT(Ease of Testing、テスト容易性)の高い設計が、よいオブジェクト指向設計である」
「EoC(Ease of Changing、変更容易性)の高い設計が、よいオブジェクト指向設計である」

　オブジェクト指向言語のあらゆる機能は「テスト容易性」を実現するためにある、と言い切っている。実際、下記のことが思いつく。

１．MockObjectを作るには、無名クラスで実現するために継承を用いる。
２．インターフェイス優先は、テストしやすくさせるため。
３．パッケージ循環依存性を排除するのは、テストしやすくするため。
４．オブジェクトの責務割り当ては、テストしやすいモジュール分割をするため。

　更に、「再利用性」よりも「変更容易性」の方がオブジェクト指向設計で重要だと主張している。最近のアジャイル開発の流行を見ると、そのことを強く感じる。プログラムの変更リスクが低い方がはるかに変化に強い。
　一昔前はコンピュータやネットワークのリソースが高価だったため、変化への対応能力はあまり重要視されていなかった。でも今は違う。変化に強くないと、プログラムの品質そのものも低下するから。

　変更容易性を実現する技術が、継承や委譲だったり、最近ならAspectやDIだったりする。それらの技術を比較してみると、「継承→Aspect→DI」の方向へプログラミング言語が進化しているのが分かる。

A．継承・・・実装時に既に依存関係がある。最も強固な依存関係ゆえ、できるだけ避けるべき。
B．委譲・・・OOでは継承よりも良いと言われるが、無駄な空メソッドが増える。
C．Aspect・・・コンパイル時に依存関係ができる。プログラム同士の依存関係はないが、バイナリ同士には依存関係がある。
D．DI・・・・ランタイム時に依存関係ができる。プログラム同士にもバイナリ同士にも依存関係はない。

　ランタイム時に依存関係ができるということは、パソコンの組み立てと同じく、プログラムを部品と見なすことができることを意味する。インターフェイスさえ合致していれば、いくらでも部品を組み合わせることができる。
　とはいえ、プログラムではインターフェイスを合わせることに四苦八苦することが多いが。。。

　平鍋さんの記事を読むと、プログラミング言語の将来像について深く考えさせられる。

再帰SQL

　Javaやモデリングを検索すると、2chのスレッドにたどり着いてしまうのだが、面白い記事を見つけた。
　「部品表から、未来のある時点での在庫の推移・過不足を見たいが、どのようなデータモデリングとSQLを使えばよいのか？」という質問に対し、「再帰SQLを使うしかないだろう」という答えがあり、下記のリンクが張られていた。

　オブジェクト指向、Javaを取り入れた新しい業界標準「SQL99」詳細解説 (共通表式 WITH句/再帰SQL)

　共通表式は、外部結合等でFROM句にあるサブクエリを何度も使わざるを得ない時に使った経験があるので知っていたが、再帰SQLについては知らなかった。
　上記HPの例題を読むと、「部品構成表から、自転車を構成する全部品と各部品の所要数の一覧を作る」時のSQLが再帰SQLとして書かれている。
　更に、「パリからサンフランシスコまでの乗り継ぎのある経路のうち、最少費用の経路を探す」ためにも再帰SQLを使っている。
　こんな問題の解決に再帰SQLを使うんだなーと感心した。（感心してはいけないが）

　この方法は、MSProjectで作ったスケジュール表のリソース平準化のアルゴリズムにも使われているのだろうか？
　クリティカルパスの検索や工数最適化にもこのアルゴリズムは使えるのではないか？
　再帰SQLを使えば、最短経路検索の問題が全て解けてしまうのでは？と思ってしまうが、無限ループの問題とかあるみたい。

　上記の記事には、再帰SQLの他に、渡辺さんの本「生産管理・原価管理システムのためのデータモデリング」に載っている「LLCを使ってシングルレベル展開して最後の階層まで集計する」アルゴリズムが回答されていた。
　LLC(ローレベルコード)の意味は、「ある部品が部品構成表でどれくらい最下位にあるかを示す位置」なのだが、恥ずかしながら僕もLLCの使い道がよく分かっていなかった。

　渡辺さんの本にある「MRPの所要量計算アルゴリズム」は理解し切れていないけれど、再帰SQLのアルゴリズムと似ている感じがするのだが、正しいだろうか？　もう少し考えよう。

Javaを突き詰めるとEJBの壁にぶち当たる

　JavaでWebシステムを開発していくと、必ずEJBという大きな壁にぶち当たる。
　EJBを使えば確かにプログラミングは楽になるが、その技術を使いこなすには手間がかかる上に、APサーバーに更にEJBサーバーまで動かしてリソースを派手に浪費するから、使い勝手はイマイチ。
　
　EJBの弱点を更にもう一つ見つけた。
　EJBはAPサーバーに依存しているから、他のAPサーバーに使えない。少なくとも、JBossとWASでは、Deploymentの記述が全く違うから、動くわけがない。Javaのメリットが全く生きていない。そもそもAPサーバーに依存しているようでは話にならない。

　IT業界に入ってJavaだけで開発してきたが、いつも最終的に、EJBとO-Rマッピングの技術にぶつかる。
　僕の少ない開発経験を振り返ると、EJBはO-Rマッピングの最適解ではない。その思いは僕だけでないのだろうと思う。何故なら、Hibernate等のO-Rマッピング・フレームワークや、SpringとかSeasarのようなDIコンテナが雨後の竹の子のように流行しているから。
　最近、O-Rマッピングの最適解はHibernateよりもS2Daoではないか、と思っているけれど、本当の所はどうなのだろうか？

「ソフトウェア企業の競争戦略」

　「「ソフトウエア企業の競争戦略」」の本が、ここやあそこに紹介されていた。
　内容は、ソフトウェア・ビジネスとして成立させるために必要なことは「製品とサービスのハイブリット形態」である、ということで興味津々。しかし、立ち読みしてみたが、いまいちピンと来なかった。

　ソフトウェア・ビジネスは製造業や小売業などのサービス業と異なるのではないか、と漠然としたイメージは常々持っていたが、本質はまだ分からない。
　僕の少ない現場経験を整理すると、システム開発は普通の製品開発と異なるプロセスなのに、現場の環境が古いため、ちぐはぐな印象をずっと持ち続けている。
　例えば、いくらJavaでWebシステムを作ったところで、請求処理など一番大事な基幹システムはメインフレームで動かしているため、データ転送で無駄なインターフェイスを作ったり、オブジェクト指向技術が徹底できなかったりする。
　更に、Webチームとメインフレームチームに分かれているため、Webチームがいくらオブジェクト指向に則った開発プロセスを応用しても、旧式プロセスでやっているメインフレームチームと共同作業せざるを得ない。
　又、日本のITビジネスは土建業界のような下請構造で成立しているため、いくらアジャイル開発をやろうとしても、ウォータフォール型プロセスから脱却できない。
　この辺りの矛盾をきちんと説明しているのか、と思ったがよく分からなかった。どこかにいい本はないのだろうか？

機能スコープと設計スコープ

　あるビジネスのシナリオを書く時、スコープを意識するのが重要なのだが、機能スコープと設計スコープを意識して使い分けるのが重要と改めて認識した。

　「ユースケース実践ガイド―効果的なユースケースの書き方」で、機能スコープと設計スコープの話が出てくる。
　機能スコープは、システムが提供するサービスを意味する。成果物は、アクタ・目的リストとユースケース概要の2つ。これらは、ペルソナ・シナリオ法を使えば、アクタごとのシナリオとして洗い出すことができる。
　これらのユースケースは、受け入れテストで使える。

　設計スコープは、ハードやソフトもこめて設計するシステムの集合を意味する。このイメージがなかなか湧かなかった。本の例を見ていると、イメージとしてはDFDやER図に似ていないか？
　つまり、システムとして設計すべき機能なのか、設計外の機能なのか、を把握するには、企業・システム・サブシステムの視点からデータの受け渡しをイメージしないと書けない気がする。

　とある勉強会でシナリオを書くタスクを背負ったが、メンバーのシナリオに対するイメージがバラバラで、どんなシナリオを書けば概念モデルや詳細モデルが書けるのか、プロセスすら分からなかった。
　今になってようやく、下記の成果物は必須だと分かった。

１．各シナリオ・機能がスコープ内にあるかチェックするためのIn/Outリスト
　→議論が発散しそうになったら、どんな要求がシステムに必要なのか、原点に立ち戻る時に使う。

２．アクタ別のシナリオを書いたユースケース概要
　→ペルソナ・シナリオ法はオブジェクト図の位置づけに相当する。アクタ・目的リストはクラス図の位置づけに相当する。受け入れテストで使える。

３．色んな視点からシステムを眺めた時の設計スコープの図
　→モデリングを行う時、どのシステムに着目して詳細化していくのか、を確認するのに使う。

　ユースケースなんてモデリングで意味があるのか、と常々思っていたのだが、モデリングを行う前の仕込み段階であるシナリオを書きまくっていくうちに、ユースケースの威力が分かってきた。
　モデリングへ辿りつくには、シナリオを具体化したユースケースが必要。そのシナリオはスコープに大きく依存している。

　シナリオやユースケースを書いていると気づいたのは、IF文を極力排除していること。IF文を使う箇所はアクタ別のシナリオに分けられる時が多い。

　ユースケースは奥が深い！

プロジェクトマネージャ＝ディレクター＋プロデューサー

　はぶさんの本「幸せなＩＴパーソンになるためのいきいきする仕事とやる気のつくり方」に、「プロジェクトマネージャの職務をディレクターの役割とプロデューサーの役割へ意識して使い分けるとうまくいく」という一節があって、何故プロジェクトマネージャは普通の管理職の仕事と違うのか、という疑問に答えられそうな気がした。

　本では、2つの役割を下記のように説明している。

【ディレクターの役割】
→成果物を作成するプロセスを管理する。
　課題達成重視。
例：計画策定・遂行、進捗管理

【プロデューサーの役割】
→全ての成果物に責任を持つ。
　問題解決型。
例：
プロジェクトの目的と成果物の明確化
プロジェクトの運営体制の構築
リスク管理
利害関係の調整

　丁度、演劇や映画の「監督」「演出家」に相当するのではなかろうか？
　Wikipediaでは、「監督」「演出家」を下記のように説明している。

演出家の職務は、劇を作品的成功に導いていくことである。そのために俳優の演技や、舞台に必要な様々な要素をコーディネートし、演出していく。演劇は複数の人間・芸術分野のコラボレーションから成り立つ芸術だが、一つの劇をつくる際に必要な様々な部門の中でも、演出家は戯曲の解釈、コンセプトや作品の芸術的方向性、表現手法などについて具体的なヴィジョンを持ち、なおかつ最終的な決定権を握っている。（中略）
演出家の仕事は通常、本番開始後には舞台監督に引き継がれる。その場合、舞台監督は演出家の定めたコンセプトや劇の進行を、公演期間中維持する責任を持つ。

　つまり、演出家は成果物に最終責任を持つから、成果物をより良い物にするためのあらゆる問題を技術面、政治面から解決する。監督は、そのプロセスを管理する。
　「はぶさんの本」に書かれている通り、監督の役割に固執すると、問題解決の糸口が見つからない。むしろ演出家の役割から、困難な状況を変えてくれそうな本質的問題を発見して、解決することで、現実を変えることができる。

　僕の少ない経験では、プロジェクト管理者はどうしてもスケジュール管理ばかり追われて、スケジュールが遅延する真の問題を考えることまで頭が回らない。つまり、現状を維持するプロセスにしか能力を使っていないわけだ。
　会社の中間管理職は、普通はプロセス管理しかやらないから、監督の役割だけで演出家の役割を担っていない場合が多いのではなかろうか？
　プロジェクトマネージャの仕事は奥が深い。

　「はぶさんの本」はいい本です。是非ご賞味あれ(^^)

口酸っぱく言われていること--スコープ管理とマイルストーン設定--

　仕事でプロジェクト管理していても、勉強会の発表資料作りでも、同僚から指摘されていることは、「スコープ管理」と「マイルストーン設定」の二つ。

　スコープ管理は、プロジェクトを成功づけるだけの成果物とその仕様範囲、成果物のレベルに密接に絡んでいる。どうしてもより良い成果物を作ろうとして、スコープがどんどん広がってしまう時に指摘を受ける(m_m)
　マイルストーン設定は、成果物を披露する期限を公開することでプロジェクトをコントロールする所に意義がある。一度マイルストーンを守れなくなると、どんどん遅れてしまい、プロジェクトだけでなく自分自身の作業目標すら制御できなくなる。マイルストーンを無視したより良い成果物を作ろうとした時に指摘を受ける(m_m)

　スコープ管理もマイルストーン設定も、プロジェクトの範囲と期限に連動する。この二つがいつも念頭にないと、プロジェクトは予想しない方向へ走ってしまい、制御できなくなる。
　二つとも当たり前だけれど、もっと良い成果物を作ろうと作業に没頭してしまうと忘れやすい。気をつけよう。

プログラミングの基本はIF文を極力排除する

　「IF文を極力減らすと見晴らしのいいプログラムになる」を読んで、プログラミングの基本を改めて痛感した。

　新人のプログラムをレビューすると、メソッドが長すぎたり、IF文が入れ子構造になっていたりして、後で保守しにくい。
　オブジェクト指向の強みは、ポリモルフィズムを使えば、IF文を排除できる所にある。ループ処理もIteratorやJDK1.5の新しいAPIを使えば、for文を排除できる。
　Seasarのように、Dependency Injectionを使えば、IF文で呼び出されるロジックの依存関係をdiconファイルに書くことで、より綺麗なプログラム構造になる。

　そんなことを考えると、プログラミング言語は条件分岐やループ処理がない逐次実行形式で書けるように進化してきたように思える。

要件定義はスコープ管理から始まる

　仕様のすり合わせプロセスは、まず仕様のスコープを決めることから始まる、という当たり前だが最も忘れやすいことを再認識した。

　仕事でも勉強会でも、あるビジネスのイメージからビジネスルールを一つずつ確定していき、最終的に設計書という成果物を作っているのだが、各設計者のイメージが異なると、いくら議論しても仕様が確定しない。
　「ユースケース実践ガイド―効果的なユースケースの書き方」には、議論のスコープを追跡するために「In/Outリスト」を提唱している。In/Outリストは、各トピックが作業スコープ内にあるのかスコープ外にあるのか、を示すテーブルに過ぎないのだが、実際、議論はよく食い違う。

　作業スコープが定まったら、更に「アクター・目的リスト」を作成することを提唱している。アクター・目的リストは、システムが要求するユーザ目的のリストに過ぎないが、各トピックの整合性を考えると、不一致が生じたり、トピック漏れが起きたりすることが実際多い。

　最近はプログラミングよりも、ユースケースの妥当性を確認するテクニックをひたすら追いかけている気がする。
　管理職や経営者のような部下をマネジメントする立場にある人は、まずスコープを意識してコントロールするというテクニックが最も基本的なスキルとして要求されているのかもしれない。