大規模金融機関システムへのアジャイル手法

以前から金融機関要員の開発への関与が非常に少ないというのを書いたことがあります。
http://thinkit.co.jp/article/909/1
もう、要するに今までのやり方が通用しなくなっているのです。
よくある失敗としては、ウォーターフォールで要件定義、開発としているうちに要件が変更したりすると、すべて手戻りになります。

金融機関で大々的にやったことはないかもしれませんが、アジャイルという考え方もおもしろいと考えました。
この場合、私が想定するにすべてJavaで構築したとして、まず各階層に機能が分解されます。最下層のI/O階層、次の階層にはI/Oレイヤーに対してどのような処理をするかを定義する。
実はここまではIMS/SAILと考え方は全く同じです。
次は機能（ファンクション）を洗い出した際に冗長する部分をコモンフレームワークとして利用する。
実はこれを実装するフレームワークは多い。おそらくどうやっても同じになるのだと思う。
このフレームワークを使っていかに構築するかという部分が違うだけだ。

最後は業務ロジックになるが、この部分においてアジャイルを用いたらどうでしょうと考えてみました。
おそらく、結構な数の小さい規模のチームがたくさんできます。
そのチームにプロパー要員とパートナーさんを配置します。
このチームで各ファンクションを作っていきます。
ファンクションの品質、生産スケジュールは管理しないといけません。
こういう手法の場合なら実機でさっさとやったほうがいいと思う部分も多い。仮にメインフレームで構築となった場合にそれぞれに実機を提供するのは非常に難 しい。RDT/zのようなPCでメインフレーム環境を用意するか、VMでそれぞれのチーム用にゲストOSとして用意をしてなるべくチーム用に用意していた ほうがよいと思う。
とにかくマシンタイムの制限をなくして生産性を上げるべきと考えます。

このやり方をすると、実際にファンクションを構築するチームのスキルはあまり必要がなくなります。職人肌の人には出番がないような状態になります。
ただし、マネージメントなどの上位層には今よりさらに高度な要員がいないと実現できないかもしれません。

だって、ITでシステム作るのに人海戦術でSE不足（安くでそこそこな人）と言っている状況。
これでは大規模ウォーターフォールは失敗しやすいことになると考えます。
せっかくITのシステムを作っているのにITを活用してないのはと不思議に思う。
アジャイルを否定する前にウォーターフォールで成功させてから言ってほしいね（笑）
すべての部分にアジャイルが適用できるのかは分からないけど、業務に近い部分はできるだけアジャイルのほうがいいように感じる。

これをユーザー側でリスク回避をするならここまでプロジェクト自体を再設計、再構築する必要があるように感じます。

まずはしっかりとしたプロジェクトの設計を。これが重要かもしれませんね。