昨日は終戦記念日でありましたが、私の２０年来の呪縛がと消えた1日でありました。
仕事面で５０歳までに達成して終わらせたいことを書こうと思います。

前にもSlideshareにも掲載しておりますが、IBMメインフレームで稼働している国内銀行勘定系システムの近代化です。

確かに決済系は儲からないといってあえてやっていない銀行さんもあります 。
でもないと困る社会インフラですし。２４時間全銀ネット稼働となると国内での現金の流動性が上がり、どの程度の効果はわかりませんが多少なりとも経済効果あるとは考えています。 国際的な話では日本銀行などの中央銀行オンラインの稼働時間が拡大すれば、多国間通貨同時決済（SWIFT CLS 同日決済）こちらのメリットを補完できるものと考えます。 すでに海外から日本へくる観光客が日本の決済インフラの不便性がかなり指摘をされていて、かなり従来の勘定系システムのスピード感のあるサービス追加が必要になってきています。

これを実現するための決済インフラはすでに24時間対応を盛り込んだと言われている新日銀ネットに接続をして、２４時間稼働対応の全銀システムに接続するにも改修が必要になります。 とにかくスピードが命になると思ってます。

これを期待して、Java＋IBMメインフレームで構築しようとした例があり、失敗した例があります。
私の考えもJavaで構築するという考えですが、UMLなどで部品や処理を明確にしたいという思いがあり、そのような考えを持っています。

今のところ、 IBM メインフレームで稼働するシステムは開発言語は PL/I が主に使われており、 DB/DC については IMS FP DEDB と IMS の使い方の中でもかなり特殊な部類で確かに早いのはいいのですが、メンテナンスがバカにならない仕組みです。
まだ余裕のある、メガバンクさんはこの辺の要員についての心配はまだ先ですが、今のIT業界の構造から言ってあまり良いとは思えません。
現に地銀さんではアウトソーシングをしていますが、あれは個人的には新しい商品を出す際にどうしても遅れが発生することと、完全にブラックボックスになるのは良いとは思えません。
では、アメリカのようにほとんど内製化というのはある意味今の日本では現実味がありません。ただ、開発、構築主体は昔のように銀行に戻すべきです。
銀行内にも実際に手を動かしている人間がいないと、なにか起こった時のインパクトや原因を詳細に把握することは難しいうえに、このような障害が連発してしまうと、その他の手数料ビジネスやそういった部分にもなんらか悪いイメージがつくのではないかと考えます。

じゃ、どうするんですか？ということで私の意見を書きたいと思います。
実は細々に書いていた部分はありますが、全てこれにつながります。

１つ目はホワイトカラーの生産性の向上です。
私も銀行勤務経験から、紙がとにかく多いうえにりん議プロセスが長いうえに、余計なことをたくさん説明しないといけない状況になっています。
私から言わせれば、いきなりなくすという考えは毛頭ありませんが、実行部隊と切り離して銀行の社内文化に対応するチームと実行部隊の連携しながらというほうがいいような気がします。実行部隊が一緒になるとこの処理に追われすぎて実際、目的はなんでしたっけ？という状態になります。最終的な目的は全員で共有し、ここのミッションを明確にイメージすることでモチベーションを高めようと考えなので、極力分業化して自分のミッションをできるだけ狭くしつつ、全体ではこの部分をやっているというイメージを持ってもらうのはとても重要です。

２つ目は内製化により、自行の業務を伝承する
銀行が過剰なほどのリスク対策を行う理由の一つにプロパーが自行のシステムを把握していないというのがあります。知らないものにはよくわからないのでリスクを対策をしすぎてしまい、どうも過剰と言えるテストが多いと思います。
やらないよりやったほうがいいですが、この部分で時間がかかり過ぎています。

３つ目はプロバーだけで要件定義を行う、生産性向上のための開発手法の工夫
システム開発の一番失敗する原因は要件定義の部分での不十分さにあります。
もっとも多いのが突然の要件定義変更により手戻りですが、こちらもプロジェクト体制設計において、緻密なルール作りが必要と考えます。
手戻り対策しては、ステアリングコミッティーを必ず定期的に開催して、そこで変更のインパクト、変更の必要性をある一定の役職者で審議する仕組みを作ることがいいと考えます。ヘルプでベンダーさんに入ってもらう必要はありますが、あくまで主体は銀行です。
ベンダーさんにRFPを書いてもらっているレベルではお話にならないでしょうね。
あとは開発手法ですが、ウォーターフォールかアジャイルか？
個人的にはハイブリッドがよいと思います。システム基盤に近くなる部分はウォーターフォールになるとは思いますが、業務レイヤーでは併用してもよいと考えます。

今の大規模開発は要員数が多すぎます。
質が悪いといってしまえばそれまでなんですが、お金を出しても来るかどうかという状況で、出したら出したで中抜きさんの利益になるだけでこちらとしてはお金の出し損です。
今時は偽装業務請負も横行して、そもそもそれだけ中抜きされた人にモチベーションがあるかも謎です。かと言って、再委託禁止としても、また今度は偽装契約社員と。

なのでなるべく少ない人数、少数精鋭でやれたほうがマネージメントも効率はいいです。

多分これを実現するなら、プロジェクト設計、体制検討、要件定義にかなり時間がかかります。
私はここまでいろいろ細かいキーワードを出して、今回はこれを全部くっつけて最終的に何がしたいのかを書きましたが、これを５０歳までに完成して達成させたいのですが、自分の性格的には木を見て森を見ずではなくて、森をみて木をみるというのが性格に合っているので、これをやらせてもらえる舞台はあるかなー。
ご用がありましたら是非連絡ください。