オブジェクト指向Wiki

コンテンツをどういう粒度で書くかが、Wikiを利用していく上で
ポイントになると思っています。
一つのコンテンツ単体で完結しており、それだけで意味の
ある内容になっている状態。
もしくは、コンテンツの下にいくつかのサブコンテンツを設け、
内容的に切り分けるにしても、トップレベルのコンテンツが
あれば、外側から見た時に、独立して存在しているような
構成にする。

これって、どこかで見たような気が・・・。
そう、オブジェクト指向におけるクラス(又はコンポーネント)です。
Wikiの一つ一つのコンテンツが、クラスにあたるわけです。
クラスの責務が、各々明確になっていなければならないように、
Wikiの一つ一つのコンテンツも独立性の高い内容で
作成する。
あとは、そのコンテンツをnewするメニュー的なコンテンツを
用意する。複数のコンテンツを組み合わせて、さらに
意味のあるフローを作る。

例えば、
(1)ヒアリングの方法
(2)OracleEnterpriseManagerのインストール
(3)TH法のモデリングルール
(4)DFDの書き方
(5)ER図の書き方
のようなコンテンツがあった時に、
メニューコンテンツ"要求定義のガイドライン"では、(1)(3)(4)(5)等を組み込む。
また、"DOAによるモデリング方法"というメニューコンテンツには(3)(5)を
組み入れる。
十分に独立性の高いコンテンツであれば、それ単体の内容を変更しても
メニューコンテンツあるいは別コンテンツでnewされていても、
呼び側への影響はない。
さらに、Wikiは外部URL(外部ライブラリ)を参照することもできる。
自前で足りないコンテンツは、外部から調達すれば良い。

・・・なんて考えながら、楽しくWikiを活用しています。

WF型でもいいじゃない。

ウォーターフォール(以下WF)型の開発と言えば、
とかく誹謗されがちです。
その理由の一つが、
「工程を後戻りする際のコストが大きすぎる。」
でしょう。
「実際のところ、顧客の要求は要求定義、設計工程以降も
　思い出したように出てくるため、後戻りは容易に予測される。
　柔軟に変化に対応できにあWF型の開発は時代遅れで、
　使えない。」
といったところでしょうか。

実際そうですよね。
せっかく試験工程まで行ったのに、実は仕様に漏れがあって
設計工程まで巻き戻らないといけない機能が出てきたり。
あるいは、その機能の「あるべき論」をもう一度行う必要性が
出てきたりして、要求定義を今更始めたり・・・。

それにも関わらず、SIerの持っている方法論は、大抵WF型が中心で、
滝つぼに向かって、粛々と開発が進むことを前提としている。
（滝つぼに向かうというか、単に墜落だったりすることも）

一方、アジャイルという考え方があります。
顧客の要求は変化するものだ、変化を柔軟に受け入れよう、
プラクティス重要…。
それぞれが置いている前提が違います。
顧客の要求を固められる＝WF型の前提
顧客の要求は固められない＝アジャイル型の前提

現在の開発スタイルに対する考え方については、
アジャイル型の肯定＞WF型の肯定で、アジャイル型で
開発をしたいが、いくつかのしがらみがあって、
それができない（→どうしたらいい？悶々）という状況では
ないでしょうか。

以上が、前振りです。
私の意見としては、「WF型でもいいじゃない。」です
方法論が先にあるのではなく、顧客を念頭に置いて、
取るべき方法論を考えなくてはならないと思うわけです。
顧客の特徴や、システム規模、自社の体制といった変数を元に
方法論は決めるべきで、方法論を先に決めて、案件に臨む
のはナンセンスです。
その点で、SIerに、WF型くらいしか方法論を用意されていない
というのは、顧客にとっての損失です。
単一の方法論で、どんな案件にも常に当てはめれるほど、
システム構築というのは単純なものなのでしょうか。
もし、そうであれば、デスマなんて言葉はとっくの昔に死滅しているはずです。

WF型＝悪という図式ではなく、顧客と、このプロジェクトにとって
ベストな方法論を選びましょうよ、そして、SIerはその選択肢の幅を
用意しましょうよ、というのが結論。

最後に、少し実体験を。
昔、私が携わった組み込み開発は、WF型での開発しか考えられなかったです。
プログラムはC言語で書いて、それを実機に似せた
シミュレーターに乗せてテストを実施する。
そのテストが合格すれば、実機でのテストを実施する。
この、シミュレーターのテスト、実機のテストというのが、恐ろしく
手間がかかるんです。物理的な実機が絡むので、テストパターン一つをこなすに
しても、人間の動作が関わるわけで、非常に時間がかかる。
製造した自動車の試験の際に、この自動車のデザイン仕様を今から変える！
ということには絶対ならないですよね。
品質を設計工程で確保するという、WF型の開発はとても理に叶ったものでした。