アジャイル開発
読み: アジャイルかいはつ
アジャイル開発とは反復型の開発手法
アジャイル開発は、短いサイクルで要件定義から設計、実装、テストまでを繰り返しながらプロダクトを育てていく開発手法の総称。完成品を一括で納品するのではなく、動くソフトウェアを小刻みに届けることで、市場や顧客の変化に素早く対応する。
かんたんに言うと
料理のフルコースを全品作り終えてから出すのではなく、前菜から1皿ずつ提供し、客の反応を見ながら次の皿の味付けを変えるレストランのようなもの。
半年後のリリースでは遅すぎる時代のアジャイル開発の基本概念
従来のウォーターフォール型は、要件定義から設計、実装、テスト、リリースまでを順番に進める。各工程が完了しないと次に進めない。半年かけて要件を固め、さらに半年かけて作り、リリースしたら「もう市場が変わっていた」という話は珍しくない。
アジャイルはこの直線的なプロセスを否定する。1週間から4週間の短い反復サイクルを回し、各サイクルの終わりに動くソフトウェアを見せる。顧客が触って初めて「ここは違う」と気づくことが大半だからである。
とはいえ、ウォーターフォールが完全に時代遅れかというとそうでもない。医療機器や航空宇宙のように、要件が法規制で厳密に定まっている領域ではウォーターフォールのほうが適している場合もある。
Scrumとカンバンはどこがどう違うのか
アジャイル開発の具体的なフレームワークとしてよく使われるのがScrumとカンバンの2つ。
Scrumは「スプリント」と呼ばれる固定期間のサイクルを回す。プロダクトオーナーが優先順位を決め、開発チームがスプリント内で完了させるタスクを選び、スクラムマスターが障害を取り除く。毎朝15分の朝会で進捗を共有し、スプリント終了時にレビューと振り返りを行う。役割と儀式が明確に定義されている。
カンバンはもっと緩い。タスクを「待機中」「作業中」「完了」のボードに貼り出し、作業中の上限数を設けることでボトルネックを可視化する。トヨタの生産方式が原型で、スプリントのような固定サイクルがない分、割り込みタスクが多い保守運用チームに向いている。
どちらを選ぶかは組織の文化次第で、正解はない。
AI開発とアジャイルの相性
AIプロジェクトは要件が曖昧なまま始まることが多い。「精度80%」と言われても、何をもって80%とするかの定義が揺れ動く。機械学習モデルの性能はデータの質に大きく左右されるため、作ってみないとわからない部分が大きい。
この「不確実性の高さ」がアジャイルと相性がいい。2週間でモデルのプロトタイプを作り、実データで検証し、精度が足りなければデータの前処理を見直す。ウォーターフォールで半年かけて設計書を書いても、学習データの偏りは設計書からは見えない。
ただし注意点もある。AIの学習には時間がかかるため、1スプリントで完結しないタスクが頻繁に発生する。スプリントの長さを柔軟に調整するか、学習タスクとそれ以外を分離する工夫が求められる。
導入する前に確認しておくべきこと
アジャイルを導入すれば開発が速くなる、というのは誤解に近い。速くなるのではなく、方向転換が速くなる。作る量が減るわけではないし、むしろ顧客との対話が増える分、コミュニケーションコストは上がる。
経営層の理解も欠かせない。「半年後にこの機能が全部揃います」というコミットメントが出しにくくなるため、従来の予算承認プロセスと衝突することがある。
まず小さなチームで試してみるのが現実的である。全社一斉導入は混乱を招く。3人から5人のチームで1つのプロダクトにScrumを適用し、3ヶ月回してみる。その経験から自社に合うやり方を見つけるのが、結局は近道になる。
当社の見解
当社はツール選定において実用性を第一方針にしている。カタログスペックやベンチマークスコアではなく、実務で1週間使い倒して初めて判断する。フレームワークを増やすほど管理コストが増える経験もした。フックを増やしすぎてAIが情報過多でパニックになったこともある。足し算だけでなく、引き算の判断が選定の質を決める。検証せずに導入したツールは、ほぼ例外なく3か月以内に使わなくなった。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。