グループウェア・システム論

ソフトウェア開発への応用-1

グループウェアとソフトウェア工学のかかわり

グループウェアをどう開発するか

  • グループウェアの特徴
    • 立場の異なる複数のユーザによって使われる
    • 全てのユーザの詳細な要求を獲得しきれない恐れ
    • 柔軟に対処できるシステム構成

グループウェアはソフトウェア開発にどう役立つか

  • ソフトウェア開発は多人数で行う協調活動の一つなので,グループウェアによる支援の対象
  1. 開発という作業の特性に着目した支援
    1. 仕様書などの技術文書の管理に関する支援
      • 分担執筆
      • 改版管理
      • 一貫性の保持
    2. 顧客との折衝に関する支援
      • アイディアの整理,記録
      • 顧客が開発者と頻繁にコミュニケーション
    3. プロジェクト管理支援
      • 進捗管理
      • 要員管理
      • 労務管理
      • 技術管理
      • プロセスの変更
    4. プロセス評価と品質保証支援
      • コミュニケーション量からプロセスを評価
      • 記録文書を残す
  2. 扱う対象がソフトウェアであることに着目した支援
    • プログラム構造エディタのマルチユーザ版
    • コードインスペクション支援ツール

分散開発の問題点

分散開発におけるグループウェアの役割

  • CASEに期待される機能
    • 調整(coordination)
    • 誘導(navigation)
    • 通信(communication)
    • 制御(control)
    • 適応(adaptation)
  • コミュニケーションの効率を上げる
    • ツールよりも方法論

国際分業開発の問題

  1. インフォーマルコミュニケーションの不足
    • 潜在的な問題点を顕在化させる効果が大きい
  2. コンタクト先に関する知識の不足
    • 誰が何の担当をしているのか
    • 誰とコミュニケーションをとってよいのか
  3. コミュニケーション開始が困難
    1. 誰がコンタクト可能かが判断できない
    2. 時差の問題
      • 昼休み
      • 習慣
    3. 反応の問題
      • 面識が薄い
  4. コミュニケーション技術の問題
    1. 同じものを見ない
    2. ツール問題
      • プラットフォーム
      • バージョン
    3. 文化と言語の問題
      • 電話よりも電子メールを好んだ
      • 問題の考え方や語彙が異なる
  5. コミュニケーション意欲の問題
    • 早期の相互訪問は重要

議論支援と設計理由記録

設計理由*1とは

  • 設計上の結論を得るに至った理由
  • 比較検討と討論の履歴
  • 議論・検討を記録することの利点
    • 未検討課題のまま放置されるものがないように管理できる
    • 設計項目同士の依存関係が明らかになる
    • 過去の議論を蒸し返すような無駄がなくなる
    • 仕様見直しの機会を逸するような不合理が減少する
    • 新メンバの教育に利用できる
    • ドキュメントの自動生成ができる
    • 容易に変更できる部分や変更不可能な部分などをより正確に同定できる
    • カスタマイズのための資料となる
  • 集中開発環境においてすら重要
  • 分散組織環境ではノウハウ等の開発情報の共有のためにより一層有益

記録方法とモデル

  1. 記録方法
    • 同時に行う方法
      • リアルタイム会話の場合
      • 非同期型の場合
      • 発言の要点を記録させるくらいが限界
      • 記録コストがほとんどかからない
    • 後で行う方法
      • 手間が発生
      • 簡潔かつ正確に記録することが可能
      • 検索や種々の処理が行いやすい
      • 議論の誤りを発見できる
    • 意見を全て記録する方法
    • 結論のみを記録する方法
  2. 記録モデルの分類
    • 過程を含めて記録するモデル
      • IBIS系モデル
      • 知識処理指向モデル
    • 結論のみを記録するモデル
    • 検索や処理ができなければ価値はない
    • 特殊な記録技術と記録コストを必要とするようでは一般の実用にならない
  3. IBIS(Issue Based Information System)系モデル
    • わかりやすい
    • 表現力が乏しい
    • Pottsのモデル
      • 議論の結果選択されたPositionが次の改版ステップに反映される
  4. 知識処理指向モデル
    • 記録の処理を指向
    • 専門的なテクニックと時間が必要
    • DRL(Decision Representation Language)
      • ER(Entity-Relationship)形式のグラフで議論の過程を表現
      • 5種類のノードGoal,Alternative,Claim,Question,Procedure
      • 14種類の関係
  5. 結論のみを記録するモデル
    • QOC(Question-Option-Criteria)モデル
      • 設計理由の記録に特に適したモデル
      • 最終的な設計結果と主な代替案,およびそれらの比較検討結果を簡潔に記録
      • QuestionはIBISのIssue(DRLのGoal)
      • OptionはIBISのPosition(DRLのAlternative)
      • Criteriaは基準となった評価項目

IBISモデルによる設計理由記録事例

  • gIBISによる利点
    • 問題の理解が速く,問題点が早期に発見される
    • 議論されたこと,議論の未熟な部分が明らかで理解しやすい
    • 視点の異なるレビューが行える
    • agenda(議事進行予定)の作成に役立つ
    • 内外のコミュニケーションに役立つ
  • 欠点
    • 誰の意見なのかが分かりにくい
    • 何が決まったのかが分かりにくい

非構造的記録

  • GIMMe
    • 電子メールをそのままの形で蓄積
    • 自然言語処理による索引付け
    • Webのインタフェイスで容易に検索
    • 添付ファイルをHTMLに変換して管理
    • 動画情報も含めて記録し,これらの情報とのリンクも行える

まとめ

  • 設計理由の記録
    • コミュニケーションの促進のためには重要
    • 記録コストの点などからまだ不充分
    • インフォーマルな形式で情報を蓄え,検索をしやすくする
  • 今後重要なもの
    • 良質のツール
    • 現場の意識改革

*1 disign rationale

トップ   編集 凍結解除 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2006-12-14 (木) 10:55:28 (4632d)