あるべき姿をみんなが模索していた
大谷:今回のプロジェクトに参加した経緯や目指したゴールを教えてください。
高:僕がこのプロジェクトに関わった経緯でもあるのですが、先にプロジェクトに参加していた知り合いに「最新のGoogle Cloud上で本当のマイクロサービスやってるぜ」とちょっとドヤられたことがあったんですよね。それを聞いてすごく興味を持って、結果として縁があり、このプロジェクトに入ることになりました。
こうした経緯を振り返ると、やはり新しいことをやりたかったんですよね。僕が担当している預金システムって、昔ながらの重厚長大な基幹システムのイメージがあります。それこそちょっとした手直しでも3ヶ月ぐらいかかる感じ。でも、システムがそんなでは、これだけ世の中がスピーディに動いているのに、ついていけません。
僕も前職で基幹システムを扱ったことはありましたが、銀行のシステムを一から作れるなんて、めったにない機会です。だったら、まったく違うモノ、新しいモノとして作った方がよいのではと思いました。これが僕も含めてチーム全員が描いていたゴールです。
そのゴールのために途中で大きなリファクタリングもしているのですが、とにかく重厚長大なシステムではなく、柔軟で変化しやすいシステムを作りたいというのが根底にはありました。
大谷:山本さんはいかがですか?
山本:今までのウォーターフォール型の開発だと、いわゆる上流をコンサルが担当し、要件が決まったらエンジニアがものづくりをやり、そのエンジニアもサーバーだの、データベースだの役割が細分化していました。
でも、今回はあるべき姿を開発者もコンサルも現場のメンバーも、みんなで模索しながら作っていったというのが大きかった。これはお客様側、これはアクセンチュア側みたいな垣根を取り払い、みんなでフラットに仕事するという共通認識をみんなが持つことがすごく重要でした。
青柳:参加した頃には、アーキテクト側が技術やソリューションをおおむね決めていたのですが、やはりゴールもハードルも高かった。だから、つねに勉強しないといけない状態。チームとしては、つねに改善し続けるというマインドが必要で、プロセス自体も今のやり方が正しいとは限らない。だから、ここにゴールがあるからそこを目指すというより、模索を繰り返す中でゴールにたどり着いたみたいな感覚が強いですね。
アジャイルだからといって計画がないわけではない
大谷:銀行のシステム開発というと、ウォーターフォール型の重厚長大なプロジェクトという印象が強いのですが、今回はアジャイル開発ですよね。かなり特殊なアジャイル開発だったと思うのですが、違いや共通点をどう考えますか?みなさんは経験がありますか?
青柳:私自身はウォーターフォール型のプロジェクトしかやったことがなかったので、そもそもスクラムを組んでアジャイル型開発というのも初めてでした。もう3年もやっているので、素人のようなこと言ったら怒られると思うのですが、当時はアジャイル開発に慣れるのもちょっと時間かかりました。
たとえばクイックなやりとりが必要なことはわかっていたのですが、自分が思っているよりもさらなるクイックさが要求されました。スプリントが1ヶ月だとしたら、その1ヶ月の中で作りあげなければならないので、課題が出てきたらすぐエスカレーションするとか、意識的にやらないといけないんです。技術的な障壁よりも、マインドのアップデートの方が難しかった気がしますね。
大谷:なによりスピードや柔軟性が重要になるんですね。
青柳:しかも自分だけではなく、チームに浸透させなければならない。ここらへんは難しかったですし、慣れていくと面白いところでもあります。結局、課題ってチーム内だけでなく、前述したビジネスチームやアーキテクトチームなど、他のチームと連携しないと解決できないことも多い。他のチームを巻き込んで一丸となって解決するのは苦労したところです。
大谷:ウォーターフォールとの違いを感じるところはありますか?
青柳:おおまかに言えば、ウォーターフォール型というのは、先に長い計画があって、そこからぶれないように進める方法。仕様変更があったら、これを途中でやるのか、いったん終わってからやるのかを決めますよね。じゃあ、アジャイルになったから、ノープランで進めているかというと、そういうわけではない。ショートスパンだけど、計画がきちんとあるからプロジェクトが進むんです。
大谷:当たり前なんですが、ノリと想像で、次のアクションを決めているわけではないということですね。
青柳:アジャイル開発ではスプリントごとに次の計画を変えられるという点はあるのですが、エンタープライズの基幹系開発の世界では、計画という部分でアジャイル開発がウォーターフォール開発と極端に違うかというと、そんなことはないと思っています。だからもっとも違うのはマインドかなあと。