|  
             「第188回例会」報告 
            PMAJ 例会部会 生越 直人: 9月号 
			             
  
    | 【データ】 | 
   
  
    | 開催日: | 
    2014年7月25日(金)  19:00~20:30 | 
   
  
    | テーマ: | 
    「欧米流アジャイル開発導入の問題点と克服方法」 | 
   
  
    | 講師: | 
    長瀬 嘉秀 氏/株式会社テクノロジックアート 代表取締役 | 
   
 
 
【第188回例会 報告】 
~はじめに~ 
 日本でのアジャイル開発の導入は、ゲーム系とネットワーク系の企業で実施されている程度であり、欧米のような広がりを見せていません。XPやスクラムなど欧米のアジャイル開発プロセスを日本の現場に導入することは、難しいのが現実です。 
 この状況は、どこに問題があるのか、どのように対応すれば良いかについて、ご講演頂きました。 
 
~アジャイル開発の概要~ 
 2000年12月のXP(エクストリーム・プログラミング)ブームから、アジャイル開発は始まった。ウォーターフォール(WF)型開発から繰り返し型開発を経て、アジャイル開発が行われるようになった。 
 WF型開発は、事前にソフトウェアの仕様を決めて、2年程度の期間を使って開発されていた。繰り返し型開発では、3ヶ月程度で開発を行い、徐々に機能を拡大する。アジャイル開発では、2週間程度でソフトウェアをリリースする。アジャイル開発は、一部だけでも短期間で実現し、その後、段階的に価値創造していくようなソフトウェアに向いている。 
 
 XPのプラクティスには、「計画ゲーム」「コーディング規約」「短期リリース」「全員同席」「メタファクタ」「最適ベース」「シンプル設計」「常時結合」「テスト駆動開発」「コード共同所有」「ユーザーテスト」「ペアプログラミング」「設計改善」がある。XPは、実はルールが多く、自由が少ない開発手法である。 
 
 アジャイルプロセス(アジャイル宣言)は、以下の4点である。 
    1. プロセスやツールよりも個人との相互作用 
    2. 包括的なドキュメントよりも動作するソフトウェア 
    3. 契約交渉よりもユーザとの協調 
    4. 計画に従うよりも変化に対応する 
 
~日本のソフトウェア開発~ 
 日本のソフトウェア開発には、以下の特徴がある。 
    ・ ゼネコン式 
    ・ ウォーターフォールプロセス 
    ・ 大人数 
    ・ ドキュメント中心 
    ・ 日本的な品質確保方法 
    ・ 非オブジェクト指向 
 
 欧米では、WF型開発→イテレーティブ(UMLによる繰り返し)→アジャイル開発(2002年)と開発プロセスが変貌してきた。日本では、WF型開発から直接アジャイル開発(2011年)へと変貌しようとしている。日本は、間にイテレーティブが無いため、オブジェクト指向の考え方に慣れていない。 
 
 WF型開発とアジャイル開発では、品質基準が大きく異なっている。WF型開発では、ソフトウェア開発後にテストを行い、バグ件数の推移から品質を測定している。アジャイル開発では、テスト駆動開発(TDD)を行っている。TDDはコード作成とテストを繰り返すため、ソフトウェアのリリース時はテストが完了している。バグは、テストシナリオに抜けがあると発生する。アジャイル開発は、WF型開発に比べるとテストが多く、テストコードとターゲットコードは同じ位のボリュームになる。 
 
~欧米流アジャイル開発との違い~ 
 欧米と日本では、アジャイル開発の前提が異なるため、以下の項目をどのようにカバーするか検討する必要がある。
  
    | ・ | 
    契約 | 
   
  
       欧米:準委任契約で開発を行う、自分達の責任、受託契約はあまり行わない 
   日本:委託契約で開発を行う、受託者の責任 | 
   
  
    | ・ | 
    派遣法 | 
   
  
       欧米:ペアプログラミングを行っている 
   日本:派遣法の関係で、ペアプログラミングが困難である | 
   
  
    | ・ | 
    教育 | 
   
  
    |    教育コストは誰が負担するのか | 
   
  
    | ・ | 
    品質 | 
   
  
    | ・ | 
    テスト | 
   
  
    | ・ | 
    顧客の同席 | 
   
  
    |    要員構成が欧米と日本で異なる、日本ではチームに顧客がいない | 
   
 
 
 欧米の要員構成 
  
    | ・ | 
    ビジネスアナリスト(BA):2名 | 
   
  
    |    ビジネスプロセスを作る | 
   
  
    | ・ | 
    エンジニア(ENG):2名 | 
   
  
    |    設計ができてコードが書ける人 | 
   
  
    | ・ | 
    品質管理者(QA):2名 | 
   
  
    |    チームに入って、テストシナリオを作る | 
   
  
    | ・ | 
    顧客 | 
   
  
    |    ほぼチームのメンバーとして同席する | 
   
 
 
   1チームは10人位まで。(大規模になると、メンバーを増やさず、チームを増やす) 
 
 欧米流アジャイル開発との違いとして、以下の項目がある。 
  
    | ・ | 
    ソフトウェア開発の土壌が違う | 
   
  
    | ・ | 
    エンジニアの職種が違う | 
   
  
    |    SE、PG、テスター(日本のように分かれていない) | 
   
  
    | ・ | 
    最新ツールはアジャイル開発対応 | 
   
  
    |    WF型開発はできない | 
   
  
    | ・ | 
    品質、テストへの取り組み | 
   
 
 
   これらの違いを克服しないと、日本でアジャイル開発ができない。 
 
~日本流アジャイル開発~ 
 日立ソリューションズでは、日本でも適用可能な大規模システム開発向けのアジャイル開発手法「COMMONDATION-ReeL」を開発した。 
(「COMMONDATION」は、株式会社日立ソリューションズの登録商標です) 
 
 WF型開発のソフトウェア開発部分にて、「適用レベル(工程種類)の限定」「適用期間の限定」を行い、アジャイル開発を行う。メリットとして、「リスク制御(デリバリーの安定化)」「継続的改善効果(生産性の改善)」が得られる。 
 関西電力では3年程度実施しており、「開発費の削減」「早く作って市場に出す」というメリットを得ている。 
 
注 ) 関西電力の事例は、PMシンポジウム2014にて日立ソリューションズ 奈加様が「ハイブリッドアジャイルの実践 アジャイル開発導入の問題点と克服方法」と題してご講演されます。 
 
~今後の展望~ 
 日本のシステム開発でも、グローバル化が進んでおり「オフショア開発」「分散開発」が多く行われている。オフショア先であるインド、中国、ベトナムなどでは、WF型開発の教育は無く、アジャイル開発の基礎となる技術を習得している。そのため、オフショア開発でアジャイル開発が加速し、業務システムもアジャイル開発へ移行する。 
 また、アジャイル開発から新しいカンバン開発などへ移行し始める。欧米では、既に「XP → スクラム → リーン → カンバン」と移行している。 
 
注 ) カンバン:アジリティの対象がソフトウェア開発だけではなく、製品やサービスの企画からリリース運用までに拡張 
 
~まとめ~ 
 克服方法をきちんと考え、対応すれば、日本でもアジャイル開発は可能だと理解しました。 
 WF型開発が中心である日本では、WF型開発とアジャイル開発をマージしたハイブリッドアジャイル開発は有効であると思いました。 
 
 また、アジャイル開発を導入すると、短期間で簡単にシステム開発を行えるように感じていましたが、実際にはビジネスプロセスを理解して、テストシナリオを繰り返しながら開発する必要があり、向き・不向きがある開発方法であることが分かりました。 
 但し、早期にシステムが実現できるということは、競争環境下では多くの場合有利になることは間違いないので、アジャイル開発が適しているようなシーンでは積極的に活用できれば良いと思います。 
 
 最後に、我々と共に部会運営メンバーとなるKP(キーパーソン)を募集しています。参加ご希望の方は、日本プロジェクトマネジメント協会までご連絡下さい。 
 
以上 
 
  |