小規模システム開発の最終成果物とプロセス

小規模システム開発の最終成果物は、以下の2つだけ*1でいい気がするという妄想をメモしてみた。

  • チェックリスト形式の Prerequisites(Problem Definition, Requirements, Architecture)
    • リリース直前にチェックリストを全てチェックすることにより、ソースコードが Prerequisites を満たすことを証明できる。
    • チェックリスト形式にすることにより、Prerequisites とソースが乖離してしまうリスクがなくなる。
    • Prerequisites は何でもアリ。*2
    • 外部仕様をすべて入れる(決定稿でなくても仮置きで入れる) *3
    • 初期 Prerequisites 完成までのコストは、プロジェクト全体のコストのうち、工数的には10-20%、リードタイム的には20-30%を割く感じ。*4
    • 初期 Prerequisites 作成はソースコード開発を含むイテレーションを開始する前にすべて完了する必要がある点に注意。*5
    • 実現可能性検証を Prerequisites 開発フェーズに含めてしまうという手もアリ。*6
  • ソースコード
    • Prerequisites に含まれない全情報は全てソースコードとして記述することにより、資料の分散を防ぐ。
    • リリース直前に全ソースコードのレビュー(一字一句すべて目を通す)をすることにより、全情報の一貫性を保証できる。

*1:プロジェクトの規模が小さく、長期保守が不必要で、プロジェクトチーム自体がアプリの要求定義に関わる唯一のステークホルダーであり、メンバーの入れ替えもないということであれば、Prerequisites はプロジェクト完成後に破棄して、『ソースコードの現状をもって仕様とする』としてもいいと思われる。Prerequisites の保守コストはそれなりに大きいので。

*2:『要求定義とは一般的にこういうものだ』的な思考は危険。例えば、要件定義に実装技術を入れるべきではないというべき論は、顧客が特定の実装技術を要求する場合に矛盾を引き起こす。このような場合に顧客の要求と開発者のべき論の辻褄合わせのために顧客の要求を Prerequisites に入れず設計書に入れたりすると、事情を知らない後任者が別の実装技術を使ってしまう危険がある。

*3:システムを扱うユーザを全て識別し、システムがユーザに提供するインタフェース仕様をすべて定義する。GUIの見た目や画面遷移、CUIの接続仕様、それらの振る舞い、など全てが含まれる。これらの仕様は往々にして抜けや矛盾をはらみ、開発後期には誰にも使われないお荷物となるため、ドメインモデルの作成を通じて抜けおよび矛盾を排除する。そのため、ドメインモデルは Prerequisites としての成果物となる。

*4:工数とリードタイムに差が出るのは、一般的に、初期 Prerequisites 完成までの段階では開発者の人数が少なく、それ以降の工程で開発者が増えるため。

*5:建築に例えるなら、小さな家からイテレーション開発しても漸近的に高層ビルは作れないし、建築開始後に家の場所は変更できない。また、防音要件・電磁遮蔽要件・部屋の積載荷重・柱の位置などは一見後で決められそうな細かな条件により変わる可能性があり、アーキテクチャに大きな影響を及ぼす詳細仕様のみを洗い出そうとしても判断に多くの工数が必要とされる上に正しく洗い出せていることを証明する方法が無く、それなら思いつくだけの細かな条件を全部出してしまったほうが早いし抜けが少ない。どこまで詳細化するかの判断は最終的には勘と経験に依存するが、これ以上の詳細化は明らかに必要ないと断言できるまで詳細化しておくというのが安全策。

*6:基本的にはソースコード開発フェーズの最初にやって、問題があれば Prerequisites を修正すればよいのだが、会社やプロジェクトメンバにとって経験のないライブラリやミドルウェアなどを採用する場合や、ソースコード開発フェーズに人数を増やす場合は、実現可能性検証用の使い捨ての仕様作成と実装を Prerequisites 開発フェーズに中に行い、一通りのアーキテクチャ検証をこなしておくのは有効だと思われ。