金融PMのアジャイル導入実務ガイド：勘定系刷新現場のハイブリッド運用術

「うちもアジャイルでやりたいんです」——ある地方銀行の情報システム部長が、勘定系サブシステム刷新のキックオフミーティングでそうおっしゃったのを、僕は今でも覚えています。会議室の空気は前向きでしたが、僕の頭の中では「さて、どこまで本気だろう」という声が響いていました。

結論から言うと、金融PMの現場で「フルアジャイル」がそのまま成立するケースは、僕の体感ではかなり限られています。監査証跡や変更管理といった金融特有の制約があるため、多くの現場では要件定義をウォーターフォール的に固めたうえで、開発フェーズだけをスプリントで回す「ハイブリッド型」に落ち着きます。今日は、このハイブリッド型をどう設計し、どこでつまずきやすいかを、僕自身が関わった案件の実感を交えてお話しします。

1. なぜ「アジャイルでやりたい」に金融PMが身構えるのか

金融機関のシステム開発には、一般の事業会社にはない制約がいくつも重なっています。まず変更管理です。金融庁検査やシステム監査の対象になる基幹系・勘定系では、仕様変更のたびに変更履歴と承認記録を残す運用が前提になっています。スプリントごとに要件が動くアジャイルの発想とは、そもそも相性がよくありません。

次に契約形態です。多くの金融PM案件は準委任契約か、要件を固めたうえでの請負契約で進みます。請負契約のまま「走りながら仕様を決める」進め方をすると、追加開発分の費用負担や責任範囲でベンダーと揉める火種になります。この契約とアジャイルのミスマッチについては、後段の失敗パターンで詳しくお話しします。

さらに、業務部門の意思決定の速度も無視できません。銀行や保険会社の業務部門は、稟議や部門間調整に時間をかける文化が根強く残っています。スプリントレビューのたびに「この場で決めてください」と迫っても、実際には持ち帰りになるケースが多いんですね。アジャイルの前提である「速い意思決定」がそもそも成立しにくい、という構造的な事情があります。

僕が駆け出しのPMだった頃、ある証券会社のポートフォリオ管理システム刷新で「アジャイルっぽく」進めようとして、要件定義をあいまいなまま開発に着手したことがあります。結果として、スプリントを重ねるたびに業務側から新しい要望が積み上がり、当初3ヶ月で終わる予定だった開発フェーズが実質5ヶ月に伸びました。あのとき学んだのは、「アジャイル」という言葉だけを輸入しても、金融の制約構造そのものは変わらないということです。

2. フルアジャイルではなく「ハイブリッド型」が現実解になる理由

では金融の現場でアジャイルの良さをまったく取り入れられないかというと、そうではありません。僕が実務で使っているのは、要件定義フェーズと開発フェーズで進め方を切り替える「ハイブリッド型」です。要件定義は業務要件・非機能要件・監査対応要件をドキュメントとして固め、承認を得たうえで開発フェーズに入ります。開発フェーズでは、固めた要件をバックログとして分解し、2週間前後のスプリントで実装・レビューを回します。

この表からもわかる通り、勘定系のコア部分にフルアジャイルを持ち込むのは無理があります。一方で、チャネル系や周辺システムのように変更影響が限定的な領域であれば、ハイブリッド型、場合によってはフルアジャイルに近い進め方も現実的になってきます。僕がこれまで関わってきた勘定系・基幹系刷新案件を思い返すと、ハイブリッド型で進んでいるものが全体の7割前後、フルウォーターフォールが2割程度、フルアジャイルに近い進め方は1割に満たない、という比率感です。あくまで僕の携わった案件の範囲での体感値ですが、参考にしていただければと思います。

3. ハイブリッド型を回す実務手順

3-1. 要件定義フェーズ：ウォーターフォール的に固める

要件定義フェーズでは、業務部門・システム部門・監査部門の三者を早い段階で巻き込みます。特に監査部門には、要件定義書のレビュー段階で「この変更管理フローで監査上問題ないか」を確認してもらうようにしています。ここを後回しにすると、開発フェーズの終盤で監査対応の手戻りが発生し、結局スケジュールが延びるからです。

3-2. 開発フェーズ：スプリントに変更管理を組み込む

開発フェーズに入ったら、固めた要件をエピック・ストーリー単位に分解し、スプリントバックログとして管理します。ここで大事なのは、スプリントレビューの成果物として「変更履歴表」を必ず残すことです。誰が・いつ・どの要件を・なぜ変更したかを記録しておくことで、監査対応とアジャイルの回転を両立させています。僕の現場では、スプリントレビューの最後15分を変更履歴の確認に充てるルールにしていて、これだけで監査対応の手戻りがかなり減りました。

3-3. 経営層・業務部門への報告リズムを揃える

スプリントの粒度と、経営層への報告の粒度は必ずしも一致しません。2週間ごとにスプリントレビューをしても、経営層への報告は月次や四半期ごとという金融機関は珍しくないんですね。僕はスプリントレビューの内容を毎回そのまま経営層に報告するのではなく、月次でまとめ直して「進捗率」「主なリスク」「今後の意思決定事項」の3点に絞って報告するようにしています。細かい開発の話をそのまま持ち込むと、経営層の判断が遅れる原因になるからです。

4. 失敗パターンと対処法

ハイブリッド型の導入でよく見る失敗は、大きく3つあります。

一つ目はスコープクリープです。要件定義を固めたつもりでも、開発フェーズに入ってから「やっぱりこの機能も欲しい」という要望が業務部門から上がってくることがあります。先ほどの証券会社の案件がまさにこれでした。対処法としては、開発フェーズに入る前に「変更管理委員会」のような小さな意思決定の場を設け、追加要望はそこで工数とスケジュールへの影響を提示したうえで判断してもらう運用にすることです。PMが一人で抱え込んで調整しようとすると、板挟みになって疲弊します。

二つ目は契約形態とのミスマッチです。準委任契約でスプリントを回しているつもりが、実態としては「成果物ベースの進捗管理」を求められているケースがあります。ある地銀の案件では、準委任契約なのに月次の進捗報告で「今月のリリース物」を求められ、スプリントの区切りと報告のタイミングがずれてPMも開発チームも消耗した、という話を同業のPMから聞いたことがあります。契約形態とプロジェクト管理の型は、キックオフの段階で発注側と揃えておく必要があります。

三つ目は監査対応の後回しです。開発のスピードを優先するあまり、変更履歴の記録や監査部門への説明を「後でまとめてやればいい」と先送りにしてしまうケースです。スプリントを10回、20回と重ねてから変更履歴を遡って整理しようとすると、記憶も記録も曖昧になっていて、結局リリース直前に大きな手戻りが発生します。変更履歴の記録は、スプリントごとにその場で終わらせておくのが結果的に一番早い、というのが僕の実感です。

5. アジャイル導入を主導する金融PMに求められるスキル

ハイブリッド型を回すPMに求められるのは、技術力よりもファシリテーション力と説明力だと僕は考えています。業務部門には「なぜ要件を先に固めるのか」を、監査部門には「なぜスプリント単位で開発を回すのか」を、それぞれの言葉で説明できる力が必要です。専門用語を並べるだけでは、どちらの部門も動いてくれません。

経営層への説明では、「アジャイル導入によってリリースまでの期間がどれだけ短縮できるか」を具体的な数字で示すことも欠かせません。僕の場合、要件定義後の開発フェーズをハイブリッド型に切り替えた案件では、同規模のフルウォーターフォール案件と比べて、リリースまでの期間が体感で2〜3割ほど短縮できた実感があります。ただしこれはあくまで僕が関わった数件の比較に基づく体感値であり、案件の規模や業務の複雑さによって変わる点はご留意ください。

もう一つ大事なのは、「アジャイルを導入すること」自体を目的化しないマインドです。ハイブリッド型はあくまで手段であって、監査対応や品質を犠牲にしてまでスプリントのスピードを優先する必要はありません。僕自身、スプリントの回転を優先しすぎて変更履歴の記録が雑になり、後で監査部門から指摘を受けたことがあります。速さと正確さのバランスを取り続けることが、金融PMとしてアジャイル導入を主導するうえでの一番の腕の見せどころだと感じています。

(結論)

金融PMの現場でアジャイルを導入するというのは、「アジャイルか、ウォーターフォールか」の二択ではなく、「どこにアジャイルの発想を持ち込み、どこは金融特有の制約を守るか」を設計する仕事だと僕は考えています。要件定義は固く、開発は柔らかく。この線引きをPM自身が持てるかどうかが、ハイブリッド型を成功させる分かれ目になります。皆さんいかがでしたでしょうか。では今日もがんばりましょう。