ソフトウエアクライシス対応 3 アーキテクチャー

サービスインまでの仕様変更。そして勿論、サービスインして運用がはじまってからの機能追加。当然、あるべきものと考えておく。
システムは生きていれば成長する。成長の止まっているシステムは、使われない死んだシステムだ。言い過ぎかもしれないが、１００歩譲っても、世の中やビジネスが変わるのだから、それにあわせていかないシステムやサービスは、いずれ死ぬ。

おたおたするな、ガタガタするな。仕様変更や追加はある。そう割り切っておこう。費用などの点は営業的な話なので、今回は省略するが、問題は、それに耐えられるベースのアーキテクチャか否かだ。

オタオタしないための仕込み。それが安定したアーキテクチャだ。レガシーでいえば「方式設計」だが、オブジュクト思考でやるときには、インフラやベースラインのアーキテクチャ。機能を実現するレイヤ、ビジュアル（プレゼン）を担当するレイヤ。それぞれ独立してメンテできるようにしておく。MVCのフレームワークはいくつもある。その採用もいいだろう。

アーキテクチャがしっかりしていても、オタオタしないためには、条件がある。開発者が信頼に足り、物事の決定の場に立ち会えること。コミュニケーションが十分にとれていること。などなど、オブジェクト指向以外の要素があるが、XP(Extreme programming)について書くときにあらためて。

アーキテクチャの確立については、別途書き起こすが、ここでハッキリ書いておきたいのは、サービスイン前にクライアントからアーキテクチャの変更まで求められるような要望が出た場合、PM,PLは断固とした姿勢で挑むべき。なぜなら、それはプロジェクトのゴールが変更されたと同等のことで、このまま進めても、クライアントは満足するわけがない。もっとハッキリ言えば、必ず失敗する。ならば、プロジェクトの中止、仕切りなおしをするのが、誠意だと考えたい。

アジャイル宣言
契約交渉よりも、ユーザとの協調により価値をおく
計画に従うよりも変化に対応することにより価値をおく

ソフトウエアクライシス対応 2 見積もり

これをちゃんとやらないと、ソフト会社なんてすぐに潰れる。当たり前のことだが。いろいろな方法もあるから、一例を挙げるに留める。

機能の細分化。コードとUTは人日単位まで落とし込む。コード UT以外のやるべきタスクの洗い出し。それを積み上げる。
スケジューリングは、細分化された機能等を、タスクまたはwbs としてカレンダーにマッピング。優先順位もつける。

機能の細分化の際、オブジェクト指向でやる。すなわちオブジェクトや、それに含まれるメソッドが、ビジネスの要素にマッピングされるので、クライアントにも理解されやすい項目となり得る。同時にその見積もりの項目は、必要なクラス一覧にマッピングされる。

要求は変化する。要望は追加される。その要望を実現するために、どうして追加のリソースや工数が必要になるのか、クラス・メソッド一覧にマッピングできる見積もりは、クライアントへ、十分な説明が可能になる。

もっとも、開発論、技術論ではないところで、大枠の金額や納期は圧縮されるんだけど、オブジェクト指向とは関係ないので省略・・。

ソフトウエアクライシス対応 1 クライアントと握る

クライアントの考えていることをシステムデザインにキチンと反映する。当たり前のことなんだが、現実はキチンと決まらない。クライアントとの定例会議の最初の頃は、クライアント自身が考えが至らなかった事柄もある。要望は段階的に出てくる。

ダイナミック、インクリメンタルな開発は世の流れとして必要となる。そのためには、UMLなどを用いて、対クライアント、対内部のコミュニケーションコストを下げておく。オブジェクト指向はビジネスをモデル化することがキモであるから、うまく機能していれば、従来の設計レビューより、クライアントと握りやすい。

リリースは段階的に行う。一気に作るのは、このご時世では危険。小刻みにプロトを出す。外部仕様だけでも早い時期に見せていく。html紙芝居も有効な技。

クライアントの考えていることとは、「要求仕様」とは異なる。ここは大きなポイントだ。
今まで、システム開発の目的は、「要求通りの構築」だった。しかし時代のニーズは、システム開発の目的を「満足とビジネスの成功」にしてしまっている。
要求とは「確定させるよう吸い上げるもの」から「変化するもの、随時対応するもの」になっている。

ゴールとその効果測定（定量）まで、初期にヒアリングし、握っておく必要がある。