セミナーの最後に開催されたトークセッションでは、アジャイルに関しての研究報告に続き、アジャイルについて、品質や大規模開発、コストなどの課題をパネラーがそれぞれの立場から回答しました。

アジャイル開発QIMP研究会研究報告

第1部のアジャイル開発QIMP研究会研究報告発表について、研究会事務局を務めるテクノロジックアートの代表取締役である長瀬嘉秀氏から、研究報告の概要が紹介されました。

長瀬氏は「2009年10月から4回にわたり、メーカーやSIer、製品ベンダーなどの有志により議論された『アジャイル開発QIMP研究会』の成果報告をまとめました。大規模アジャイルプロジェクトにおける課題への対応策、課題解決の考え方を検討し、非常に踏み込んだ内容になっていますので、アジャイル開発をこれから始める方や、導入を検討している企業、担当者方などにとって大いに参考になると思います」と述べました。具体的な内容はダウンロードサイトからも閲覧できるのでぜひ見てほしいと語りました。

アジャイル開発の3つの課題

続けて行われた2部のトークセッションでは、長瀬氏が進行役を務め、登壇者はThoughtWorks社のJez Humble氏、独立行政法人 情報処理推進機構の松田晃一氏、日本アイ･ビーエムの榊原彰氏、日立システムアンドサービスの英繁雄氏、マイクロソフトの長沢智治氏、NECソフトの飯田治行氏の6人。それぞれの立場からアジャイルについて現在行っている取り組みやアジャイル開発についての考え方を、自己紹介と合わせてスピーチし、トークセッションがスタートしました。

アジャイル開発で品質は向上するか？

最初のテーマは「アジャイルで開発すると品質は上がるのか」という『品質』についてでした。

Jez Humble氏が口火を切り、「⁠日本はウォーターフォール型の開発で品質を担保できる稀有（けう）な存在といえます。アジャイル開発は、細かいチェックを繰り返し行い、問題があればすぐに回帰して修正ができるのが大きなメリットです。チーム全員が品質をコミットすることで品質向上が図れますし、繰り返しの作業の中で迅速にバグもつぶせるため、ムラなく質の高いものを開発できると考えます」とアジャイルの品質への考えをアピールしました。

続けてコメントした松田氏は、「⁠ウォーターフォール型開発では、日本は欧米と比較しても品質は非常に高水準だといえます。一方、アジャイル開発はベストプラクティスの集合ともいえますが、研究会などの報告を見てもまだエンジニアリングと呼べるまでには至っていないのが現状のようです。そういった意味からもアジャイルによる開発で高品質なものを作り出すことについて、疑問を持たれる方も多いのではないでしょうか」と、まだ普及の途にある現状を踏まえた意見を述べられました。

榊原氏は「やるべきことをやれば品質は上がる」と前置きした上で、「⁠ウォーターフォールとアジャイルではリスクヘッジのポイントが異なります。アジャイル開発で重要なことは、機能ごとに『スモールリリース』を繰り返し行うことです。これにより、リスクヘッジができ品質が向上できます」と述べました。

品質のポイントを確認という見地から捉えた英氏は、「⁠品質は確保するには、ユーザ確認を早く行えることが重要です。より早く確認まで行えるアジャイルは、繰り返しテストを行い、再構築も容易にできます。テストの作業量と品質はイコールではありませんが、ウォーターフォールに比べて、アジャイルの方が品質については優れていると思います」との見解を示しました。

エバンジェリストの視点から、長沢氏は「作る時の品質と、でき上がったものの品質は別物です。日本ではいいものができるという確信があれば、これまで培ってきたウォーターフォールの方がやりやすいでしょうし、無理に変える必要もないと思います。そうでない場合は、確信を持つためにアジャイルを使うことが役に立つこともあります。ソフトは建築と違い、でき上がった後でも修復が可能です。最後に直すのではなく、小さな段階で修正することが品質向上につながると思います」と比喩を用いながら、品質のポイントを上げました。

飯田氏はプログラムを行う現場の意見として、「⁠品質の中には操作性も含まれていますが、それは机上では分かりません。作って、使って、直すといった作業が必要ですので、繰り返しできるアジャイルは成果があるといえるでしょう」と述べました。

こうしたさまざまな意見が出た結果を受け、長瀬氏は総括して「ウォーターフォールは工程を踏んで、一方のアジャイルは短期開発を繰り返すことでともに品質を確保しています。アジャイルのチームの中には品質を担保する人が含まれているケースもいますが、より明確に、品質に気をつけていくことが重要です」と結びました。

大規模開発におけるアジャイルの活用法

次のテーマとして挙がったのは「大規模開発」です。人数をかけてプロジェクトを推進していくウォーターフォールと異なり、アジャイルではチーム編成により対応していくのが一般的です。大規模開発にアジャイルをどう適応していくかが議論されました。

長沢氏は、マイクロソフトの米国での事例を紹介し、「⁠Visual Studioの開発は、総勢3600人以上で、スクラムをベースとしたやりかたで透明性とアジリティを維持、確保しました。その際、フィーチャーごとに約10人で1つのチームを作成しました。決まりごとは段階的な期日のコミットと、クオリティゲートと呼んでいる約17項目の品式基準をクリアすることだけです。それを守れば、チームでのやり方は自由とし、アジャイルを実践しました」と例を挙げ、大規模開発におけるアジャイルの意義を語りました。

アジャイル開発の現状を踏まえ、英氏は「アジャイルはまだ普及段階です。問題はアジャイルを管理するマネージャのスキル、開発者のスキルで、ツールへの知識不足や交代要員によって起こる工程の遅延などが、経験上、プロジェクトを失敗に導いたこともありました。オフシュア開発も同様で、教育や人材が重要だと思います」と、教育と人材の重要性を説きました。

また、榊原氏もIBMの事例を挙げ、「⁠1,000名を超えるプロジェクトが稼働していますが、開発を小さくしていくのは賛成です。開発工数と負荷の相関関係はリニアではないので、小さい開発の方がいいと思います。ただし、規模が大きいとコミュニケーションロスが問題となりますが、規模が小さい場合は個人差が生産性に直結します。それを担保するのが実は大変難しいのです。『⁠アジャイルリリーストレイン』と開発を列車に見立て、遅い人が足をひっぱることを表した言葉があるように、機能を切り出し、ダイナミックに変動するスコープをどうやって管理していくか、その答えはまだ生み出されていないのが現状です」とアジャイルのメリットと課題を挙げました。

Jez Humble氏は自身の経験を元に、「⁠10年間アジャイル開発をしてきた立場からいうと、コンウェイの法則（ソフトウェアの構造はそれを作った組織を反映している）のとおり、どんなメソッドを使っても大規模開発を成功させるのは難しいことです。アジャイル開発では、小さいチームで動くのが基本ですが、そのためには機能を構成するコンポーネントごとにチームを作り、継続的に構築、統合していくことが重要です。また、分散した開発はコストの削減やアウトソーシングによる効率化が図れる反面、確認作業や修正作業など返って負荷がかかることもありますので注意が必要です」と、アジャイル開発のポイントをまとめて語りました。

このように、大規模開発でもアジャイルは活用できる一方、それをどう管理していくかが重要なことが再認識できました。

アジャイルのコストをどう見るか？

最後のテーマとなったのは「アジャイルの予算申請やコストについて」でした。従量課金のように増大するコストの確保について、Jez Humble氏は「ユーザの要件から納期と予算を出すのは不可能に近いです。そこで、これまでの経験を紹介すると、バジェットを小さくし、話し合いの中から『ワーキングプロトタイプ』を構築して、信頼関係を築くことが重要だと考えます。小さな模型からどのようなものができるかを早い段階でユーザに確認してもらい、例えば3ヵ月単位で予算を導き出すことを実践しています。最初から数字を出すことはせず、期間を切ってできることを提示しています」と語りました。

松田氏は、「⁠一括契約にするか、従量課金のようにかかった分だけを請求するかという判断になると思います。アジャイルの場合は、従量課金が適していると思います」と、契約形態についてポイントをコメントしました。

要件でコストを大筋で判断できるウォーターフォールとの違いを交え、榊原氏は「アジャイルはフィーチャーごとにチームで対応するため、予算化は難しいというのが現実です。ウォーターフォールの一部分をアジャイルにする場合でも、管理できる部分、つまり現実的な線でコストを算出し、確保することになると思います。これらはあくまでもユーザ次第で、承認する人がどれだけメリットを理解できるかによっても違うといえるでしょう」と述べました。

英氏はクライアントマターになるケースが多い点を指摘し、「⁠ユーザの予算編成の時期、例えば期末や半期、四半期に合わせるしかないのではないでしょうか。請負契約では全体コストを提示する必要がありますが、あとはバッファの取り方がポイントになってくるでしょう」と、増加する分の予算確保の難しさを上げました。

長沢氏は「ユーザのコスト意識も変わってきているので、事例などを参考にコストを算出する方法もあるのでは」と、事例をベースにしたコストを提言しました。

最後に、飯田氏は「アジャイルは、はみ出した部分を落とすことができます。ウォーターフォールではそうはいきません。逆な見方をすれば、納期前に終わればアジャイルでは新たなものを追加できる反面、ウォーターフォールはあらかじめ要件が決まっているのでそれはできません。つまり、予算に応じて開発できるのがアジャイルのメリットなのではないでしょうか」と語りました。

その意見を聞いた榊原氏は、「⁠製品開発とサービスデリバリは分けて考えるべきだと思います。製品開発であれば要件を追加することは可能です。しかし、請負では追加できるものではないので分けて考えましょう」と補足しました。

最後に長瀬氏が「契約や見積などさまざまな話が出ましたが、リスクを誰が持つかも重要。請負などでは成果物に対し、SIerやベンダがリスクを負います。一方、かかった分だけというケースでは、でき上がらなかった場合のリスクをユーザが持つことになります。そういった認識が浸透していくことを今後望みます。以上、3つの議題について、いろいろな有効な意見も出たと思うので参考にしてください」とスピーチし、トークセッションは幕を下ろしました。