BrightTALKサミットの登壇者が語る「ソフトウェア開発の新時代」：業界でも有数のソートリーダーが解説

TechTargetは、「BrightTALKサミット」のレポートを公開した。同サミットでは、適切なソフトウェア開発プロセスを選択し、AIとMLを最大限に活用するための戦略について話し合われた。

[Alicia Landsberg，TechTarget]

　TechTargetは2024年3月14日（米国時間）、同年2月に開催された「BrightTALKサミット」のレポートを公開した。

サミットの講演者がソフトウェア開発の新時代を解説（提供：TechTarget）

　ソフトウェア開発は、正しく進めるべき重要なプロセスだ。企業のソフトウェアアプリケーションへの依存度はこれまで以上に高まっており、自社のソフトウェアアプリケーションによって多くの収益とエクスポージャー（リスク）を生み出している。こうした中で成功するためには適切な開発へのアプローチが不可欠だ。

　2024年2月にTechTargetが主催したBrightTALKサミット「Software Development Methodologies」では、業界でも有数のソートリーダー（新たな考え方を持ち込み、特定分野をリードしている人）の6人が、適切なアプローチを選ぶヒントや、AI（人工知能）とML（機械学習）のような新しいテクノロジーを取り入れる方法などについて講演した。

適切なソフトウェア開発モデルの決定

7つのソフトウェア開発ライフサイクル

　コンサルタント企業EKENG CJSCのイェギサベト・アラヴェルディアン氏（システム統合責任者）は、ソフトウェア開発ライフサイクルを7つの段階に分けて説明した。

1. 計画と実現可能性
2. 要件分析
3. ソフトウェア設計フェーズ
4. コード開発フェーズ
5. ソフトウェアの検証とテスト
6. ソフトウェアのデプロイメント
7. ソフトウェアのメンテナンスとレガシーコードのサポート

　アラヴェルディアン氏は、ウォータフォールモデルやアジャイルプロセスなど、一般的によく使われるソフトウェア開発モデルの概要を説明。サミットの参加者に対し、開発のアプローチとして有効な「ソフトウェアの再利用」を検討するよう訴えた。同氏はプロジェクト管理の状況や目標、予算、チーム構造、経験によって適切なアプローチは異なることを伝え、講演を締めくくった。

スケーラブルなテスト計画の立案方法

　マウリシオ・アニッシュ氏（『Effective Software Testing』の著者、大学教授）はソフトウェア開発プロセスの重要な構成要素である「テスト」に注目した。同氏は、スケーラブルなテスト計画の立案方法のヒントとして「拡張性のある、時間をかけない素早いテスト」を推奨している。

　「大半の企業はGoogleほどの規模ではないし、Google規模のインフラを抱えているわけでもない。大規模なテストを可能な限りシームレスに実施することを全体的な目標とし、共有リソースに注意しながらテストの対象範囲を狭めるのがいいだろう」（アニッシュ氏）

　同氏は、結合前のテストに重点を置き、自社独自のテストピラミッド（何をどのレベルでテストするか）の定義から始めることを提案している。

　「問題は分割して対処すべきだ。統合テストで複雑なバグを見つけようとしてはならない。誰もそこまで優秀ではないし、創造的でもないからだ」（アニッシュ氏）

　アニッシュ氏によると、こうしたテスト構造は開発者体験を高め、機能しないコードを後工程に持ち込むのを防ぐのに役立つという。

　また同氏は、スケーラブルなテスト計画を立てるためのもう一つのヒントとして「テストの作成を容易にすること」を提案している。「難しいテストに時間を費やすことはない。テストプロセスを終えることは開発プロセスの一つのステップにすぎず、テストだけでなく、開発プロセス全体を調整する努力を続けなければならない」と指摘している。

企業が利用するソフトウェア開発アプローチのトップ12

　Intellectsoftでプロジェクトマネジャーを務めるアナスタシア・シロタ氏は、企業が利用するソフトウェア開発アプローチのトップ12を紹介した。講演では、各開発モデルの長所と短所が詳しく解説され、予算、チーム規模、プロジェクト規模、顧客の期待値に応じて最適なモデルを選択する方法が紹介された。同氏が取り上げたのは、以下のアプローチだ。

1. ウォータフォールモデル
2. アジャイルモデル（Agile Model）
3. スパイラルモデル（Spiral Model）
4. ラショナル統一プロセス（RUP：Rational Unified Process）
5. プロトタイピング（Prototyping）
6. 共同アプリケーション開発（JAD：Joint Application Development）
7. 高速アプリケーション開発（RAD：Rapid Application Development）
8. 動的システム開発手法（DSDM：Dynamic Systems Development Method）
9. ユーザー機能駆動開発（FDD：Feature-Driven Development）
10. リーン（Lean）
11. エクストリームプログラミング（XP：eXtreme Programming）
12. スクラム（Scrum）

　これらの手法の中で最も人気が高かったのがアジャイルとスクラムで、いずれもシンプルで柔軟性が高く、急速に変化する環境に適しているとシロタ氏は語る。

生成AIを使う際の課題

AIのバイアスにどう対処すべきか

　生成AIには、それを作った人間と同じ「認知バイアス（偏見）」があることに利用者は気付いている。ソフトウェア品質エンジニアとして働くジェリー・オーウェン氏は、AIにおける認知バイアスをテストして認識する方法と、バイアスがかかったデータから生じる問題のある結果を管理する方法について講演した。

　バイアスの基になるのはデータで、そのデータの基になるのは人間だ。つまり「人間にとってバイアスは避けられない問題だ」と同氏は説明している。バイアスがかかったデータが現実に問題を引き起こした例としてAmazon.comを挙げている。

　Amazon.comはAIツールを使ってWebサイトをスキャンし、ある職種に向いている有望な人材を探した。このAIのトレーニングには、過去にAmazon.comに同職に応募した人の履歴書が使われていた。ただ、その職種に応募した人の大半は男性だったため、AIは「同職には男性が適している」と学習した。これは、2つの概念が誤って関連付けられ、固定観念を植えつける可能性のある典型的なバイアスの例だ。

　同氏はもう一つのバイアス「相互作用バイアス」を例に挙げる。これは、誤って使われた単語を正しいものとしてAIが学習してしまう、または「Microsoft Tay」（※）のように不適切な行動を認識できず、悪意のある単語を学習してしまうといったバイアスだ。

Microsoftが構築した対話型人工知能の一つ。ユーザーとの対話で言葉を学習する仕組みだったが、一部のユーザーが悪意のある言葉を学習させ、問題のある発言をするようになってしまった。その結果、サービスが停止された。

参考リンク：Learning from Tay’s introduction（Microsoft）

　このバイアスが問題なのは、誤った答え、微妙な差別、最適ではない結果を生み出す点にある。例えば、フィットネスジムのロッカーキーを管理するAIが「医師は男性である」と誤って学習しており、ロンドンを拠点に活動する女性医師がロッカールームへの入室を許可されなかったことがあったという。

　オーウェン氏は、AIが企業に提示する大きな疑問を無視しないように呼び掛ける。

　「AIが社会に徐々に浸透していくにつれ、結果に深刻な影響を及ぼす可能性のあるバイアスを排除するために、データをテストすることが重要だ。人間の意思決定者の協力を得て、実際のデータとペルソナを使ってデータをテストすべきだ」とオーウェン氏は提案している。

　「ソフトウェアは予期しない動作をすることがある。人間が介入するには、機械の反応は速過ぎる。コードはインテリジェンスを生み出すことはできない。アルゴリズムは、実際には人間のように考えることはできない。選ぶデータによって、バイアスが生じる可能性があることを認識することが重要だ」（オーウェン氏）

コーディング支援AIのライセンス問題

　レンセラー工科大学（Rensselaer Polytechnic Institute）で講師を務めるクリストファー・トッツィ氏が取り上げたのは、コーディング支援AIを利用する際に直面するソースコードのライセンス問題だ。トッツィ氏は、知的財産を巡る訴訟に長年巻き込まれてきたオープンソースコミュニティーの歴史について語る。同氏は「ソフトウェア開発において生成AIコーディングアシスタントの利用が急増しているため、企業はオープンライセンス違反について検討しなければならない」と指摘している。

　「検討すべきかどうかは状況によって異なる。例えばコードの利用はコピーに該当するかどうか、ライセンス違反となるコードのコピー量の多寡、生成AIツールのベンダーが自社製品でのオープンソースの利用方法を認識しているかどうかなどによって状況は異なる」（トッツィ氏）

　この課題は難解だ。例えば大半のオープンソースライセンス契約には「開発者がコピーできるコード量」の規定はない。また、オープンソースの開発者は自身のコードが悪用されるのを望まないし、生成AIツールを利用する開発者の全てが他人のコードを利用している可能性を認識しているわけではない。これらの背景が問題を複雑にし、法的な難題を経営者にもたらしている。

　トッツィ氏は企業と開発者の双方に、AIを用いる際の指針として「AIが生成するコードのコピーを最小限に抑えること」「コードの利用者と利用場所を追跡し、コードベースをスキャンしてオープンソースコードを見つけること」を提言している。また、The New York Times、OpenAI、Microsoftなどの大手企業が関わったライセンス訴訟を調べ、オープンソースAIが向かう方向性を理解することも重要だと付け加えた。「ただし、この件は流動的でダイナミックな問題なので、現時点での正解はない」とトッツィ氏は注意を促している。

AIの誇大表現に惑わされない

　AIにまつわる“誇大表現”が広がっているが、AIはその期待に本当に応えられるのか。この大きな疑問に取り組んだのは、マット・ホイサー氏だ。ホイサー氏は、AIの変化をGartnerの「ハイプサイクル」になぞらえて説明する。なお、ハイプサイクルは技術の成熟度を示すグラフで、「黎明（れいめい）期」から始まり「流行期」を経て「幻滅期」を迎える。そして「回復期」へと進み、やがて「安定期」に到達するという流れになっている。

　「現在は、AIに関する否定的な報道が始まっており、流行期の終わりに近づいていると感じる。私の考えでは、OpenAIの『ChatGPT』は決まり文句や同じ単語の繰り返しを生成するもので、生成AIの基になったデータと同程度の知性しか持っていない。そのため、『生成AIは驚くべきもの、画期的なもの』という宣伝には警戒した方がよい」とホイサー氏は語る。

　一方で同氏は「テストデータやコードの生成、要件の分析など、テスト目的で使うならAIは大きな可能性を秘めている」とも言う。

　「AIを実装したいのであれば、導入前に『正しいテストデータを用意できるかどうか』に注目すべきだ。テストデータの正確性を確保するには“懐疑的”になる必要がある。例えば仕事を依頼した人にその成果についてサンプルを要求する。そのサンプルがあなたのためにきちんと動作するかどうかを確認する、つまり自身がテスターになれば正確なテストデータを用意できるだろう」（ホイサー氏）