システム開発の標準化の話題が多いんですけど、それを見ていると、このおはなしに行き着いているみたい。
開発プロセス標準化への道（1）
開発プロセスに対する幻想を破壊する
やばやば。このお話の先の話をしないと、せっかく、かおる姫のすばらしさを書いても、ぜーんぜんつたわんないじゃないっすかあ！
ということで、メモ程度に書きます。
まず、今、学会に出ているような開発プロセス論は、そのまま使うと、現実の壁にブロックされてしまいます（後で、どんな感じか説明します）。
なんで、実務上、開発する場合、それらをひねって使います。
学会のいうように、ある開発プロセスをそのまま使って、ソフトウェアファクトリ（ソフトの自動生成工場をつくる）というのは、出来ないとは言わないけど、難しいと思います（たとえて言うなら、パワフルカナだけを使って、ブラジルに勝つようなもんだ。不可能ではないが、それには、爆発的なジャンプ力とアタック力が要る）。
で、実際、ウィリアムのいたずらの場合、どうやって、なにを基準にひねるかというと、まず、ユーザーの要求と、利用しようとする技術等に対する情報の正確さから大きく分けている。
■■ ユーザーの要求が矛盾があったり、業務を表現できない、正しくいえない場合
ユーザーの要求矛盾チェックをしないと、間違った方向に開発し、あとで結合テストのとき、結合しない！なんていうことになる。
なんで、要求矛盾チェックなんだけど、これは、データを追っていくことによって、見つけるのが早い。なんで、構造化分析、とくにＤＯＡによって、ＥＲ図を描くとわかりやすい。
ただし、ＤＯＡなどは、利用する技術が、ちゃんと仕様どおり動くことが前提になる。
■■ 利用しようとする技術に不明箇所があったり、抜けがあったりする
利用するクラスのJavadocが修正されていないで間違いだらけとか、ＢＲＥＷのように、マニュアルを信じてやるとえらい目にあう。マシンごとに動きが違うなどというとき。
このときは、自分の目的とする動作を要求仕様として、その機能がちゃんと動くか、たしかめながら作るしかない。っていうことで、ＴＤＤ的な開発論になる。
ただし、ＴＤＤを採用する場合は、要求に矛盾がない必要がある。
矛盾があると、ＴＤＤだと、まず、仕様を満たす実装しかしないので、要求がおかしく、あとで、全体的見直しで、仕様大幅変更になると、作り直しの手間が大きくなってしまう。
と、大きく分ければ、こんなかんじなんだけど、実際には、利用しようとする技術もはっきりわからないし、要求も矛盾だらけとなる。
なんで、単純にＴＤＤをやったり、単純にＤＯＡをやってもできない。ある程度ＴＤＤをいれながら、仕様の全体像を加味するようなひねりとか、ＤＯＡっぽいんだけど、局所的に分割して、そのある部分は、プロトタイプでテストを先行させてつくるといったようなひねりがいる。
で、具体的に、どうするかというと、実際に開発するときにサブシステムに分割するけど、その中で、ＴＤＤ的に開発したほうがいいものをわけ、その開発時期を確保し、さらに、ＤＯＡっぽく、全体のデータのデザインを明確化したほうがいいタイミングを見極める。
結果として、インクリメンタルモデルが採用しやすい（サブシステムごとの独立性が高いので）。さらにサブシステムごとの独立性を高めるため、オブジェクト指向を採用するが、とはいえ、そうすると、全体のデータのデザインを明確化する部分と矛盾してくるので、そのへんのさじかげんが、問題になる。
（スクラムの体制にするかどうかというのはこの後の話。ＸＰは、テストファースト部分以外、採用しにくい。で、テストファーストは、ＴＤＤのところになる）
とはいえ、あまりにもさじかげんを、みんなで自由に出来るようにしてしまうと、管理もできないし（特に意識あわせなどのコミュニケーション上の管理）、とにかく、先が読めない。そこで、（開発プロセスの標準化もふくめた）開発標準をつくり、ある程度先が読めるようにするけど（この、先が読めることがリスクヘッジにつながっていく）、これを固定的にしてしまうと、結局ＴＤＤか、ＤＯＡっぽい方法かということになり、上記の問題を、もろにかぶってしまう。
そこで、標準化に遊びをつくり、オブジェクト指向として、中は、ある程度自由に出来るようにさせ、その一方で、ＥＲも入れさせて、全体データの整合性の確認をとらせたりする（その成果を、標準化された枠組みの中で、どうクラスに反映させるかが、ＰＭの腕の見せ所になる。そのためには、クラスとＥＲの関連を読みきれないと、まずだめだけど）。
Ｅｘｃｅｌファイルで、仕様を書く場合も、固定的な枠で縛りを入れながら、フリーフォーマットで、自由度を持たせている。
そして、開発のタイミング的には、ＴＤＤの部分を前に持っていき、プロトタイプ、もしくは、全体共通の部隊が、その部分を明確にするようにさせ、利用技術を固めてから、全体データをみれるようにさせる。
この固めた成果を、パターンにしてしまうということもありますね。
っていうかんじかなあ。。。さいきんのおしごとの仕方は。。。
もちろん、あんまりにも、自由にしてしまうと、ＣＭＭなんかを推進してる人から怒られそうだし、先も読めないのでリスク管理になんないし、コミュニケーション管理にも支障が出るので、どこを標準化としてきつくしめ、どこを本質的には甘くする（ただし、外見上は、ここも、びしっと締めている）かというのが、マネージャーの才覚になってくるところになる。
で、大山さんの場合は、たとえば、「ＴＤＤだけしかできません。ＤＯＡだけしかできません。テストはＪＵＮＩＴでやって、時間頂戴ね」みたいな、状況がよければいいんだけど、そうでない場合（こっちが多いんだけどね）は困ってしまうというかんじ。ただし、生産性は、恐ろしく高い。
宝来さんの場合、それではいけないということで、最後にひねりをいれる。だから、得点に結びつく。これだけで、すごい進化。
そして、かおる姫は、ＤＯＡでもＴＤＤでもできるし、テストエンジニアも、プログラマもＳＥも、なんでもこなしているので、状況に応じて、開発方法論をえらべ、それを、開発標準の枠組みにとりいれて、押し込めることが出来る。なんで、次元が違ってすごい、ビジュアル系「だけ」ではない！（でも、ビジュアル系）というお話なのでした。
アクセス
トータル
ランキング
