プロジェクトストーリー
Project Story
同じ「IT関連」といっても、企業によってその仕事は大きく違います。
また、アベイルでは多種多様な現場で様々な仕事を手掛けています。
私たちがどんな仕事をしているか、どんな働き方をしているか。
あるプロジェクトチームに関わるメンバーに、プロジェクトを振り返ってもらいました。
プロジェクト
概要 金融機関のシステム更改プロジェクト
ゲートウェイシステムの更改プロジェクト。簡単に言えば「銀行の勘定システムの入口」を新しくするようなもの。アベイルは電文の形式やフォーマット変換に関わる部分を担当。
期間 15ヶ月
要件決定:3ケ月
設計期間:3ケ月
開発期間:3ヶ月
テスト期間:7ヶ月
それぞれの役割
統括マネージャー Y.A
制作担当 システムエンジニア T.M
テスト担当 システムエンジニア M.K
プロジェクトの位置付け
基盤の保守期限到来によるシステム更改。今回のプロジェクトでは基盤更改とアプリケーションの改修を併せて実施。
-
Y.A
金融システム第1グループ
統括マネージャー2000年入社
-
T.M
金融システム部
システムエンジニア2003年入社
-
M.K
金融システム部
システムエンジニア2019年入社
銀行の勘定システムの更改案件
interviewer
皆さん、金融機関のシステム構築に携わっていると聞きました。まずはプロジェクトの概要を伺いたいです。
Y.A
ゲートウェイシステムの更改プロジェクトです。簡単に言えば「銀行の勘定システムの入口」を新しくするようなものです。当社は主として電文の形式やフォーマット変換に関わる部分を担当しています。
T.M
このプロジェクト自体が本格的に動き出したのは、約1年前です。ただ、システム全体でみると当社はかなり前から案件に携わっています。継続してシステムの更改案件があるかたちです。
Y.A
勘定システムなので基本的には頻繁な入れ替えは生じません。ただそれなりの年数を経るとマシン交換は必要になります。そのタイミングで、システムの作り替えを行うんです。今回も入れ替えに伴うプロジェクトでした。
interviewer
グループマネージャーのAさんは、現場での統括を担うお立場ですね。他のお二方はどのような立ち位置で仕事をしていたのでしょうか?
M.K
Mさんが制作担当で、私がテスト担当でした。多種多様なバリエーションをテストする必要がありまして。私はAさんの指示のもと作業を一つずつこなしていただけですが、やはり大変ではありました。また仕様にあまり詳しくなかったので勉強しながらテストをしていたこともあり、色々と学びが多い案件でもありました。
T.M
確かに比較や突合は、かなりの数だったね。そのための専用ツールも作ったんですが、最初は処理速度が遅くて…。私はそれを改良しながら進めていくのに苦労した記憶があります。
リリースのタイミングで、まさかの自体が
interviewer
色々ありつつも、リリース後は大きな達成感も得られそうですね。
Y.A
実は今回、リリースした日に問題がおきまして…。稼働状況を監視していたところ、画面に大量の警告メッセージが出て。冷静な顔をしつつも、大量の冷や汗をかいていました。
interviewer
えっ!そうなんですね…。
T.M
私もリリースに立ち会っており、リリース直後に試しにいくつか作業をしてみたんです。その際1件だけAさんが話していた事象が起きていました。ただ1件だけだったので、他の人とも話したうえで「致命的なものではないだろう」と。それで、Aさんと入れ違いに帰宅しました。
Y.A
救いだったのが、銀行を利用するお客様には影響がなかったことですね…。ただ警告は大量に出るので、対策は必要です。
こればっかりは仕方がないことなのですが、どうも置き換え前の仕様のなかに、誰も把握していなかった機能があって。その為、取り扱うデータに対する考慮不足が原因で、システム改善の為に新たに開発した機能が誤検知を繰り返す…。久しぶりに血の気が失せましたね。
interviewer
あの、こういう時って、お客様に何と説明するんですか?
Y.A
そこはアベイルの経営陣がすべて担ってくれました。「システム稼働としては問題ないが、一部検知方法として最適でない部分があった」と。銀行のシステム担当者を不安にさせず、かつきちんと説明をして下さったようです。
そのおかげで私たち現場の人間は、新規モジュールづくりなどの業務に集中でき、発覚してから短期間で新たな形をリリースできました。
interviewer
聞いているだけでドキドキしますね。
T.M
再リリース時には、念には念を入れかなりの数のテストを行ったんで大丈夫だとは思っていましたが、やはり緊張はしましたね。
M.K
私は最初のリリース時に立会っておらず、後から問題発生の事実を知りました。それでも休日明けにメールを見て、ドキッとしました。どんなに経験を積んでも、なかなか慣れないですね。
Y.A
大規模な更改だったり、「複雑なことになりそうだな」と事前に予測できれば、例えばテストに割く時間を増やすなど手の打ちようがあります。今回は想定外の事態なんで、仕方がないと言えばそうですが…。でも、やはり他にやりようがあったのでは?と考えてしまいますね。
例えば急きょ新しいソフトウェアを使うことになり、検証や調査を行いながら作業を進めていたんです。その辺りも含め、全体的に事前準備がちょっと不足していたのが敗因の一つかもしれません。
「ゴールはリリースと安定稼働」
ではあるものの…
interviewer
無事リリースできたので、「負け」ではないような気もしますが…。
Y.A
当然最終的なゴールは、「リリースと安定稼働」ではあります。ただ、そこへ至る過程でもうちょっとうまくできた箇所は明らかにありますね。
interviewer
プロジェクト終了後には、「もっと最良の方法があったかもしれない」と考えがちですか?
Y.A
私は、現場を全部見る立場なので、それは考えますね。私の判断で皆さんに迷惑がかかることも出てくるので、この先も振り返りや反省をし続けると思います。何よりも私自身が、ちょっとずつ改良していくことが楽しいんです。
M.K
私は、Aさんがゴールを明確に設定したうえで作業を振って下さったので、今回乗り越えられたと思っています。「やり切るしかない」との思いで仕事ができたのは、Aさんがうまくスケジューリングして下さったおかげです。
Y.A
お!そんなことを言うなら、もっとできたかもしれない(笑)?
M.K
いや、そこはまだまだです(笑)。
Y.A
今回のプロジェクトは簡単ではありませんでした。ただ、例えば大量のテストをこなしてもらうなど、MさんとKさんには色々と無理を承知でお願いしたこともあり…。二人がいたお陰でなんとか無事リリースにこぎつけました。とても感謝しています。
それでもこの仕事を続けるには、理由がある
interviewer
ときには辛い思いをしつつも、この仕事を続けられる原動力は何でしょうか?
T.M
例えばシステム稼働中に発生する問題は何度経験しても、慣れはしないです。ただ経験を積むことで原因が推測できたり、解消方法が見えてきたりはするんです。
根本にあるのは、プログラムで何かをつくることへの楽しさですかね。大変なことがあっても、考えたりプログラムを書いたりしていると楽しくなっちゃって、忘れちゃうんです(笑)。
M.K
私も同じです。プログラミングが好きなんです。モノをつくること、システムを開発する楽しさがあるので、続けられているんだと思います。
Y.A
私は、実は問題発生自体は嫌いではなくて。原因を突き止める作業は、楽しめるんです。もちろん自分の案件のトラブルは、責任があるので嬉しいものではないですが。
あとは、向き不向きで言うと自分はこの仕事に向いているかなと。一人で考えたり試行錯誤するのが苦にならない。自分の長所を活かせる仕事ではあるので、続けられるのかな?と思います。