社員座談会 3

【 エンジニアの歩き方 前編 】

〜 現役ベテランエンジニアからのアドバイス 〜

エンジニア35歳定年説、果てして本当にそうなのでしょうか? どうすれば50歳、60歳を過ぎても現役を続けられるのか? 
リ・バースの現役ベテランエンジニアに語ってもらいました。

ハルオさん

1956年生まれ。中堅SIerに新卒入社。60歳の定年まで勤め上げ、再雇用契約で大手生保の基幹システムプロジェクトを牽引。契約終了後にリ・バースヘ参加。

ヒロシさん

1958年生まれ。ハルオさんと同じ中堅SIerに新卒同期入社。40歳ころに子育て中心の生活にシフトするために雇用形態を契約に切り替える。リ・バースには2015年から参加。

※本記事は2018年に発行した弊社タブロイド誌『Re・Birth!vol.2 Summer2018 特別編』に掲載されたものです。情報は2018年当時のものとなります。

現在のプロジェクトは

ハルオさん

生命保険会社の基幹システムの運用保守プロジェクトです。担当する大手SIerさまにPMOとして参加し、様々なプロジェクトのマネージャーを支援しています。具体的には、各プロジェクトに潜む課題やリスクにどう対応するのか、PMの方と一緒になって対応策を考え、支援するのと、各プロジェクトの横のつながりを見たうえでの問題点を掘り起こし、解決策を提示しています。特に新商品に関連するシステムは関係省庁の許認可が伴うため、認可されない場合のリスクを考慮した進行をアドバイスさせていただいています。ビジネスプロセスを鑑みながら、各プロジェクトを俯瞰しながら支援する。そんなポジションです。

ヒロシさん

わたしは通信事業者の全国のショップで使うレコメンドシステムのプロジェクトに参加しています。役割としては、コンサルテーション&ソリューションという感じでしょうか。このシステムの目的は、既存顧客をいかに離さないか。顧客ごとに履歴を管理して、お客さまが受け付けを済ませると、自動で最適なサービスの提案方法、スクリプトが店舗スタッフのデバイスに表示され、接客を行うという仕組みです。接客後の満足度も集計され、新たな企画やシステムに反映されていくようになっています。この仕組み全体の企画は、コンサルティング会社さんが担当し、企画をいかにシステムに落とし込み、使いやすくするかを考えながら、構築から管理、運用の全体のマネジメントをわたしが担っています。

これまでのご経歴を
教えてください。

ハルオさん

ヒロシさんとは同期入社で、新人のころ土木会社のプロジェクトは一緒だったよね。

ヒロシさん

そうだね。僕は入社して、ちょっとしてから参加した。

ハルオさん

わたしは入社2年目のときかな。プログラマーとして参加して、5年くらい担当したと思う。

ヒロシさん

橋とか、道路、トンネルの設計で使われる技術計算系のシステム開発と、そのメンテナンスをしていたね。その後は?

ハルオさん

わたしは営業に移ったんですよ。営業って一体何をするの?って。よく分かっていなくてね。笑 SIerさんへの営業を始めたけど、成績は出なかったですね。若いときは本当に仕事ができなかった。笑 使い走りで終わってしまって。数年後、また現場に戻りました。とある企業の基幹システムの開発で、どういったシステムにしていくか、要件定義から設計、開発と、お客さまの立場でシステム構築をしていましたね。

ヒロシさん

僕はその後、金融機関の外為システムや医療系システム、航空会社向けシステムと、いろんなシステムに携わって構築をしていたんですけど、ユーザー寄りで要件を決めるとか、システムの仕様決定をメインにやって、開発の人に指示を出していましたね。

ハルオさん

上流の仕事が多かったね。

ヒロシさん

結果的には。開発が得意じゃなかっただけなのかもしれない。笑

ハルオさん

わたしもそれ以降、30歳代半ばくらいからPMO的な仕事になっていった。

ヒロシさん

僕もPMOでしたけど、自分の中では、そっち寄りの意識ではなかったんですよ。ただ、プロジェクトを進めていくうえで次々と機能を追加していく繰り返しの中で、品質や生産性を高めるためにはどうすればいいかとか、開発プロセスはどうすれば標準化できるかということを考えていくと、結果的にPMOと同じ仕事になる。そういう意味では、障害分析や報告書のスタイルだとかを決めていくことは昔からやっていた感じはします。それと長く携わるプロジェクトが多く、開発だけ、その局面だけという仕事はなかった。

ハルオさん

前職がトータルで請け負うスタイルだったからね。プロジェクトをどう進めるべきかというノウハウがお互い蓄積できたんだと思う。

技術進化の早いIT業界で
どう対応していけば
いいですか

ヒロシさん

開発する立場だと言語やオープン系、C/Sだとかを知っていないといけない。でも、僕たちはそこをメインでやっていたわけじゃない、というのが一番の理由かな。設計をする場合、どういうふうに実現するかをイメージしますが、要件というのは、どのシステムを使うとか、どういうふうにつくるかではないですよね。お客さまが何を望んでいるのか、どういうふうにしたら利益が出るシステムになるのかということがメインになる。

ハルオさん

技術はあくまでも方法であり、ツール。

ヒロシさん

うん、確かに必要な技術が時代で変わるし、それに伴ってつくるシステムも変わるので、その情報は理解していないといけないです。若い方や開発をコントロールするという意味では知らないとダメな部分も当然あるんですが、それが一番ではない。

ハルオさん

わたしも今までこだわってやってきたことは、いま現場でいちばん何に困っているかってことなんです。とくに大規模プロジェクトになると、どうしても機能別に縦割りの組織になりがちです。その中でいま何に困っているのか。それに対して、どういった改善していかなきゃいけないのか、を自分で見つけ出すんです。見つけ出したら、それを解決するために、どの人に登場してもらえばよいかを考えて、人を集める。そして、開発するには何をしなくてはいけないのか、どういう整備が必要か、ひとつひとつ解決していく。そういうご提案をお客さまにしてきたし、今もしています。

ヒロシさん

そのスキルはどう磨いていくかで言うと?

ハルオさん

やっぱり先を読む、ということです。先を予測する。それと現場で何が起こっているのか、何に困っているのか、それをどういう優先順位で解決していけばいいのか。そこを考える。問題点は、ふだんの会話の中からを拾い上げていく。その積み重ねだと思いますね。

(後編へつづきます)

Re・Birth Recruit Page

TOPへ戻る