-

開発の進め方はオブジェクト指向で変わったのか

開発の基本はV字モデル

• V字の対面の工程とテストとが対応

  • 要件定義

    • 基本設計

      • 詳細設計

        • 実装
      • 単体テスト
    • システムテスト
  • 受け入れテスト

短期間で開発し修正と拡張を繰り返すことが重要になった

• 従来のアプローチ

  • 要件定義や基本設計に数カ月〜年単位の時間をかける

• そんなにじっくり時間をかけられなくなってきた

  • ビジネスは変化する
• 短期間の開発と変更を繰り返すのが重要に
• そのための、変更を楽で安全にするオブジェクト指向

オブジェクト指向の開発はうまくいっているのか/どちらのやり方でも変更がやっかいなソフトウェアが生まれやすい

• OOPやモデリング言語を取り入れても、オブジェクト指向らしくない開発はできてしまう

  • V字を短いサイクルで繰り返さない

    • 分析モデルと設計モデルとが乖離していびつになりがち

  • 分析や設計に時間をかけずにとにかくプログラミングしてしまう

    • ちょっと規模が大きくなるとすぐに手を付けられなくなる
    • 【所感】前職がこれでした
• 分析と設計を一体にやるオブジェクト指向らしい開発を

ドメインモデルを中心にしたソフトウェア開発の進め方

業務ロジックに焦点を当てて開発を進める

• オブジェクト指向らしい開発の2つの焦点

  • ドメインモデルに業務ロジックを集めて整理する活動
  • 要求の分析とソフトウェアの設計は同じ人間/チームが担当する体制

• 開発の進め方

  • 従来

    • ドキュメントベース

      • 機能一覧
      • 機能詳細説明
      • 画面一覧
      • 画面項目定義書

    • 大量にドキュメントを作ってから、それをプログラミング言語で置き換えていく

      • 別のチームが担当するため

  • オブジェクト指向らしい開発

    • 分析しながら理解した内容を直接ソースコードに起こす

ソースコードを第一級のドキュメントとして活用する

多くのドキュメントは不要になる

• 従来の開発手法のドキュメントの役割

  • 決定事項の記録(確認手段)
  • 伝達手段
  • 進捗の管理

• オブジェクト指向らしい開発では…

  • 決定事項の記録(確認手段)

    • ソースコード

  • 伝達手段

    • 分析者-設計者、設計者-実装者の伝達がそもそも不要

      • 同じ人間/チームが担当するため

  • 進捗の管理

    • ドメインモデルのソースコード
• 前提: 分析モデルと設計モデルとが一致していること

重要になる活動

• 分析と設計を同じ技術者が進めるためにより重要になる活動

  • 対面の質疑応答

    • ドメインモデル、ユビキタス言語を育てる基本手段

  • ラフスケッチ

    • 写真が便利

  • 質疑応答とその記録

    • 電子メール、チャット、To-Do管理ツール

• 初期の分析段階からコードでの表現を重視する

  • 正式なドキュメントは、可能な限りソースコードに集中する

更新すべきドキュメント

• 非技術者にとってはやはりドキュメントが必要

  • 利用者向けドキュメント

    • 技術者にとっても有用

      • ソースコードで表現しきれない業務の約束事や手順をわかりやすく説明

    • 外部仕様書

      • 開発初期から利用規約やユーザガイドのアウトラインを書いておく
      • 開発が進むにしたがって肉付け
      • 利用開始語のソフトウェアの変更を適切に反映

  • 画面や帳票

    • 利用者が実際に使っている、詳細な要求の実体
    • それ自体が要件定義書たりうる

  • データベースのテーブル名/カラム名とコメント

    • 技術者以外の関係者でも比較的理解しやすい

全体を俯瞰するドキュメントを作成して共有する

• システムの基本的な目的や方向性を共有するための情報

  • システム概要説明
  • プレスリリースに記載したセールスポイント
  • リリースノート
  • 利用者ガイド
  • 営業ツールのキャッチフレーズ
• ボトムアップを基本とするオブジェクト指向の分析設計に芯を通す

技術方式のドキュメントもソースコードで表現する

• 自動化スクリプトが自己文書化

  • ビルドスクリプト
  • テストスクリプト
  • 環境構築スクリプト
  • デプロイスクリプト

非機能要件はテストコードで表現する

• 多くはテストコードとして自動化・自己文書化できる

  • 監視ツールの設定/実行のスクリプト

  • 性能要件

    • 負荷生成プログラム

  • セキュリティ要件

    • 脆弱性テスト
    • 不正アクセスの防止テスト
  • 認証/認可のテスト
  • 疑似的に障害を発生させ自動復旧することを確認するテスト

• 完全に自動化できないものも、半自動化の余地はある

  • テストのログとして確認項目や手順をログとして書き出す等

分析と設計が一体になった開発のやり方をマネジメントする

見積もりと契約

• オブジェクト指向の開発のやり方では、開発初期から分析し、設計し、実装も始まる

  • フェーズモデルでいえば準委任契約の段階
  • 開発者がコードを書き始めているけれども、まだ分析の段階

• オブジェクト指向の変更容易性をより効果的に活かすには、開発後半も準委任にすべき

  • 仕様の変更や開発の優先順位を変えたいときに柔軟に対応できる
  • cf. 請負は契約に縛られて柔軟に対応できない。発注側も受注側もリスクが多い

進捗の判断

• ドメインモデルのソースコードで判断できる

  • 小さな単位、業務の関心事の単位で進捗判断可能

    • パッケージ、クラス、メソッド

  • cf. フェーズモデルだと進捗管理が難しい

    • とくにデータクラスと機能クラスに分割していて、かつクラスが巨大な設計の場合

品質保証

• 思わぬ勘違いや致命的な抜け漏れが起きにくい

  • 業務を理解している技術者が分析を行い、プログラムを直接書いているため

• 技術者と業務の言葉で会話することが試金石

  • うまくしゃべれていれば高品質

    • ミスや見落としがあってもきっと軽微

  • ぎくしゃくしていると危険信号

    • 大きな欠陥やとんでもない勘違いの疑いあり

要員と体制

• 育てるべき人材

  • プログラミングが一定レベルでできること
  • 業務要件に関心を持つこと