CCA

実際に働くメンバーから仕事のやりがいを紹介

鈴木
Suzuki

staff06

自己紹介

私は、この業界に高卒で入りました。
その当時はバブルの崩壊2年前、まだまだ景気が良く誰もが、浮かれていました。
もともと中学の頃からこの業界に入ることを目指していたので、高校も当時都内では2校しかない
コンピュータの専門校へ行きました。そして、就職。
ただ、仕事と学校での知識では、かなりギャップが大きく、最初に入った会社を修行の場と考え
5年間は我慢して、その会社で技術や業務の経験を積みました。
その後、今まで経験した知識や技術を生かして、中堅のコンピュータ会社の契約社員となり、
2年間で失敗を経験しました。いや、単に契約社員で居続ければ今でもやっては行けたのですが、
何かが足らないと感じ、その足らないものを探しに、また会社の組織に戻ることを決めました。
そこで、あることがきっかけで、大手証券会社の子会社に入社、そこで証券業務、リーダーとして
仕事をしていく中で、物足りなさを感じていました。
その物足りないものは、大手では、専任される業務となるため自己の能力を高めることに限界がある
ことに気づき、もっと広い視野がほしいと感じ、このシーシーエーに転職し現在に至っています。

システム開発の業務

システム開発の現場に携り、経験を積んでいく中でシステム開発業務とは何なのかを考えていました。
システム開発の基本的な流れは、要件定義(業務要件とシステム要件に大別されます。)、次に基本設計、
ここまでが一般的なSEであれば必要なスキルとなります。
しかし、私が考えるSEは、お客様とのコミュニケーションを密に取ることで、業務要件に隠されている
開発意図の思いをより引き出すことが必要だと思います。
次に詳細設計、プログラム設計へと工程が流れていきます。さらにテスト(単体テスト、連結テスト、
総合テスト、ユーザテスト)、最後にシステムリリース(本番です)、ここがプログラマーのメインステージとなります。

1.要件定義
通常は、お客様が作成する業務要件から、システムの構成を考えてシステムの外枠を設計していきます。
まれに、業務要件も作成することもありますが、基本的にはお客様とのコミュニケーションを深めて、
システム開発に至った経緯などを文章で表現できないところを、コミュニケーションで引き出し、
業務要件やシステム要件に反映できれば、よりお客様の要望に近いシステムができると考えています。
2.基本設計
こうして完成したシステム要件から、基本設計を作成します。
システム要件で出されたシステムの構成から、器機構成を理解し、プログラム開発に必要な情報やテスト
に必要な情報を記載していきます。また、システムをやみくもに作成していても、処理が遅いなどの問題
が発生してきます。そこで、この段階で性能も考えておく必要があります。
要件定義の性能は抽象的な人の思いが記載されているので、基本設計ではより具体化させていきます。
3.詳細設計
器機構成は、各機器メーカー等にお任せするとして、プログラムの動作を決めていきます。
入力画面や入力データ、内部処理、出力画面、出力帳票、出力データなどの細かい内容を取り決めて
いきます。お客様によっては、この設計がよりプログラミングに近いものになっているところも
あります。
4.プログラム
詳細設計から、お客様が意図している処理を組み立てていきます。
プラモデルでいうところの実体図のようなものです。
利用するプログラミング言語から、日本語で一つ一つ処理条件や編集内容を記載していきます。
5.テスト
テストの種類は、単体テスト、連結テスト、総合テスト、ユーザテストとあります。
単体テストは、プログラム(モジュール)ひとつについて動作を確認していく工程になります。
連結テストは、プログラム(モジュール)をつなげた時に正しくシステム要件通り又は、基本設計通りに
動作する事を確認していく工程です。
総合テストは、業務要件が満たされているかを確認します。
最後のユーザテストは、お客様に実際に利用してもらい業務要件を満たしているのかを確認する工程です。
6.システムリリース
本番稼働させる段取りを行い、稼働日に向けて準備を行います。
提供方法がお客様によって違うので、確認しながら実施していくことになります。

このように、単純にシステム開発をするSEだとこの工程をマスターすることで、そういったSEに
なれると思います。しかし、上記にも記載した要件定義には、さらに奥が深い部分が存在しています。
それが、次にお話しするお客様の業務です。

お客様の業務(証券系業務)

私がお客様の業務を知ることで、要件定義にかかるコミュニケーションの幅が広がります。
何もわからないまま、業務要件定義からシステム要件定義を作成しようとすると、業務要件に潜んでいる
不備に気づきません。ここでいう不備とは、業務要件は抽象的、システム要件はより具体的にという
ギャップを埋める作業に支障が出ること意味しています。
実際にあった事例をお話ししますと、証券商品の中に債券というものがあります。この債券の仕組みに供託
という法律上のルールがあり、債券という資産を受け入れされることが可能なのです。
当初のお客様の要望は、供託が管理できるようにシステムを作成してくれという要望(抽象的な表現です。)
のみで、提供された資料は、部分的な法律の文章のみでした。これを紐解きながら、色々な部署がシステムを
構築し、それを接続して完成したのですが、実際蓋を開けてみると、お客様自身がその業務の本質が理解され
ていなかったため、単純に管理するだけの仕組みとなり、また、最終顧客である債券という商品を所有し、
供託する資産に債券を選んだ人にどういう情報を提供するのか、これからもう一度考えるという結果に
なりました。仮に私が供託の仕組みを完全ではないにしろ知っていたなら、実際どういう風に業務を展開する
のかを提案することも可能で、作ったは良いけど、使えない仕組みを作りこまなくても良かった事になります。
長年、この業界をやっていてまだまだ知らないことが多いと実感させられた場面でした。

また、次の事例ですがこれは、業務を知っていた事でお客様に提案ができた事です。
それは、債券を所有していると、ある期間で利子が受け取れ、それを非課税にする制度があります。
その債券を所有している方が亡くなられ、それを相続しかつさらに数か月後、同じ非課税になった債券を所有
する人が亡くなり、それも相続する場合のことを、相次ぐ相続(法律用語)というのですが、発生するケースは
かなりまれなケースです。
このことが、業務要件から漏れていてシステムを作っている中で、どうするのかと業務手段まで含めた提案を
したところ、お客様は、そのような業務が発生することを理解していなかったため最初は困惑していましたが、
説明を続けていく中で、その提案を承諾していただきシステムに組み込むことができました。

ここで挙げている例は一例ですが、お客様の業務は奥が深いです。それを知ることは一層システムの質を良く
すると思います。
そういった知らないことを知ることも、この仕事をしている醍醐味になっています。
また、どのような仕事をしていても成功は、そのときはうれしいものです。
ただ、成功は経験に裏付けされた結果にすぎません。
失敗は、成功するための経験を積んでいくことと考え、より多く失敗を重ねて、より多く経験を積むことを
楽しさに変えて、このシーシーエーで一緒に働いてみませんか。