ホットセッション

■第1回ホットセッション「短期開発を成功に導く技術動向」 ■

  1. 「Agile開発の動向」
  2. 藤井 拓(株式会社 オージス総研)
    • Agile(カタカナでの表記名の統一見解はまだない模様。
      現在は、アジャイルまたはアジャルのどちらかで呼ばれている)とは、「機敏な」という意味。

    • アジャルなソフトウェア開発(ASD:Agile Software development)は、その名の通り、機敏なソフトウェア開発がテーマ。
      これは近年の開発の小規模化、短期間化と、変化への対応を求められる背景から出てきた。

    • 2001年2月アジャル宣言(Agile Manifesto)により、アジャルな方法論の共通な価値と原則が宣言された。
      アジャルな方法論としては、プロジェクト管理中心の方法論としてScrumとAdaptive Software Development、より包括的な方法論としてXPとCrystal Clearがある。
      今回の講義では、XPとScrumについて詳細な内容を紹介。

    • さらにアジャル・モデリング(モデリングテクニックを活用し、ソフトウェア開発を効率的に行うための方法論)を解説。


    <質疑応答>
    [質問]アジャルな開発において、開発途中に発生する技術的な問題を解決する役目は誰か
    [回答]⇒ScrumではScrumマスター、XPではペアプログラミングがそれを解決する。
    Scrumマスターは上級技術者のような存在である。
    日本ではそのような職種が見当たらず、これから育成する必要がある。
    例えば、技術者にScrumマスターになってみないかと誘うのも手だ。
    今のプロジェクトマネージャーは、予算管理中心の仕事になっており、技術者にとって必ずしも技術の上級パスとして考えられないのではないか。

  3. 「UMLによるオブジェクト指向開発と短期開発」
  4. 青山 幹雄(南山大学)
    • 変化への対応が強く要求されるようになり、進化型開発と再利用という観点からUMLによるオブジェクト指向開発が注目されるようになってきた。

    • UML1.xの特徴と問題点に基づいて、標準化の進展をメタモデル、XML、MDA(Model Driven Architecture)の観点から解説し、UML2.0の言語仕様を紹介。

    • なお、UML2.0は現在審議中であり、2003年あたりに投票というペースで進んでいる。
    • UMLによるインクリメンタル開発の事例紹介により、具体的な開発イメージを説明。

    • 最後にインクリメンタル開発によるオブジェクト指向開発と従来型のイタラティブ開発を、工数と生産性の面から比較した。

    <質疑応答>

    [質問]インクリメンタル開発によるオブジェクト指向開発の工程別工数配分によると、従来型に比べて設計工数がかなりかかるようになっている。
    これだと、設計は自社内で行い、実装以降を外注にだす日本型の開発形態では、外注でコストを減らすメリットがなくなるのではないか。

    [回答]⇒確かに実装で再利用をしないと工数削減にはならないので、外注のメリットは減るかもしれない。
    しかし、オブジェクト設計でうまく設計すれば変更に対するリスクが下がる。
    その実践には、ソフトウェアアーキテクトという存在が必要であり、日本ではソフトウェアアーキテクトの育成を進めなければならない。
    しかし、これを実践すれば、トータルとして改善されるはずだ。
    今まで分析・設計をきちんとしなかったのをきっちり実行することになる。
    最近の海外利用でいうと、たとえばインドへの発注において、分析・設計をきっちり実施して発注すれば、もっとうまく活用できるようになるのではないか。

  5. 「RAS 再利用のためのスタンダード」
  6. 藤井 智弘(日本ラショナルソフトウェア?)
    • RAS:Reusable Asset Specificationとは、再利用を前提とした開発環境をいい、Assetとは、ある問題に対する解決策(要求項目、モデル、ソースコード、テスト資産等)の集合体をいう。

    • Asset-based Developmentとは、Assetをしっかり蓄積して再利用して開発すること、それを実現するよう体制・プロセス・成果物などのソフトウェア開発全般を編成することをいう。
      これに対して、従来型はプロジェクト指向であり、プロジェクト内での再利用を中心としていた。
    • Asset-based Developmentでは、アーキテクチャに沿ったチーム編成が行われる。
      また、再利用側となるApplication Developersに対して、再利用するパーツを作るTechnology & Domain SpecialistsのなかのHarvesterという存在が重要であり、このHarvesterが、再利用するパーツを検討し選択する。

    • 今回紹介したRASは、まだ日本語訳も途中段階の本邦初公開の内容である。
      今後OMGへ提案して標準化を図る予定。

    <質疑応答>

    [質問]再利用するパーツが増えて、複数のドメインをまたがるような状況になったとき、どのようにして再利用しやすいように整理するのか

    [回答]⇒その役目は、Harvesterが担う。
    ただし、Harvesterの視点をある程度標準化しておくことは必要になろう。
    また、整理されたものを見やすいしくみにするのはLibrarianの役目である。