Interview
プログラミングとマネジメントの領域で、ITエンジニアとしての自分の価値を問い続けた。
IT系 生涯プロエンジニア(R)
エンジニア略歴
- 1978年~情報処理プログラムの開発
- 1981年メイテック入社
- 1981年~ホテル向けシステム開発
- 1982年~土地改良システムにおける台帳作成開発
- 1984年~放射性元素の在庫管理システム開発
- 1984年~システム開発言語作成支援ツール開発
- 1985年~販売在庫システムの開発
- 1987年~ホテル向けシステム開発
- 1989年~受注システムの開発
- 1992年~資材発注システムの開発
- 1992年~受注ホストのサポート業務
- 1995年~生産管理システムの開発
- 1996年~戸籍情報システムのコンサル・販売支援
- 1998年~生産管理システムの改修
- 1999年~電力系会社社内インフラシステムの開発
- 2004年~通信カラオケ装置の企画立案
- 2005年~通信機器ソフトウェア開発のプロジェクト管理
- 2014年~電力会社向けシステムの提案活動
- 2014年~電力会社向けノウハウ共有システムの開発
- 2015年~電力会社向けモバイルデバイス管理の構築
- 2016年~システム開発業務の品質改善
- 2020年3月定年到達
アナログな情報処理の時代に
スタートラインに立つ
将来はエンジニアとして「情報処理を手掛ける」と決めたのは中学3年の春。
情報処理の知識を学ぶために、工業高校の電気科に進学し、「HITAC-10」と呼ばれるミニコンピュータを使って情報処理の勉強をしていたことを思い出します。
そんなエンジニア人生のスタートでしたが、定年を迎えるまでエンジニアとして歩めたのですから、時代の環境にも恵まれたいいエンジニア人生だったと思っています。
卒業後はガソリンスタンドや気象協会などの情報処理を行う計算センターにプログラマーとして入社。
ガソリンスタンドの売り上げ伝票をキーパンチャーがデータ化し、それを汎用機で処理するためのプログラムをつくったり、気象協会のシミュレーション用データを2昼夜かけて処理したりしながら、プログラムの基礎を学びました。
しかし、会社の経営状況に不安を覚え、2年後に退職。
1981 年3月、前職の先輩の紹介で、メイテック(当時は名古屋技術センター)を訪ねることになったのです。お茶とお菓子が用意され、ドラフターで設計をしている部署を見学しただけで帰宅した2週間後、なんと採用通知が届きました(笑)。
驚きましたが入社を即決し、すぐにホテル向けのシステム開発に携わることになったのです。
「設計は後ろからやれ」
行動の基礎を得た、先輩の助言
テンプレートと文房具が置かれたデスクで、定規を使って150 ~ 200 枚のフローチャートの設計書を描き始めてしばらくたったころ。
要件定義に悩んでいた私を見て、先輩が「設計は後ろからやれ」とアドバイスをくれました。それは、お客さまにどんな形で納めるかを第一義にし、実現のためにいつまでに何をするか、どうすれば実現可能かを逆算して考えなさい、という意味だったのです。
目の前の課題に対応しがちな新人の私にとって、衝撃的な言葉でした。以後、この言葉は私のエンジニアとしての行動の軸になります。
そして、この業務の後は切れ目なく案件に対応することに。土地改良システム、大学での放射性元素の在庫管理システム、システム開発言語作成の支援ツール開発、販売在庫管理や受注システム、資材発注システムの開発など、多様な業務に対応しました。
その間、ハードウェアの急激な進化やプログラミング技術の広がりと競い合うように、知識を増やし、業務経験を積んだことで、開発業務全体への目配りができるようになりました。
例えば、COBOL を学んだのは、土地台帳を作成する業務でしたし、その経験からオフィスコンピューター専用の簡易プログラミング言語BPLを入力して変換するツールの開発にも関わりました。
住民票管理システムに連携した、OEMの戸籍情報システムのコンサルテーションと販売支援を担当したこともあります。
個人情報管理システム・人事管理システムから認証システムへの情報連携システム開発では、2000年問題に遭遇し、大晦日から正月までの泊り込みを懇願されたことも懐かしい思い出です。
思い返せば私の基底には、お客さまがイメージする「こうなればいいな」に素早く応えて実現し、喜んでもらいたいというモチベーションがありました。
働く環境や企業文化が異なっても、メイテックのエンジニアとして仕事を任される以上、自分のスキルといただく対価のはかりをきちんと均衡させ、常に結果を出すことを強く意識していたのだと思います。
だから「自分が経営者なら、この対価で雇うか」を念頭に置き、評価されるようスキルを磨き、足りなければ業務がどんなに立て込んでいても勉強するか、周囲の人に徹底的に聞きました。
プログラミング言語一つにしても、習得が目的ではなく、ツールとしての使い方と作法を知り、それを駆使してお客さまの思い描くイメージで動かせるかを優先して考えてきたのです。
プロジェクト管理の業務で気付いた
エンジニアとしての価値
その後、総合電機メーカーでシステム設計から納品までの全工程のドキュメント製作に携わることに。
その業務が終盤に差し掛かったころ、PHS のキャリア向け通信機器製作のプロジェクトマネージャーをしてほしいという依頼を受けます。
これが自分のキャリアの大きな転機になったように思います。
100 人規模のプロジェクトをまとめることになり、腹を括って未経験だったマネジメントの知識を得るべく、本を読み込む生活が始まりました。
100 人を管理することは難しいため、10人ずつ10グループに分け、各グループのミーティングに必ず顔を出し、課題や進捗を整理することから始めました。
試行錯誤しながら600 項目におよぶ試験やスペックテストを1年かけて終え、本稼働後は1件の不具合もない製品を送り出すことができました。
さらにそれを見ていた別部署から、今度は280 人をまとめるプロジェクトに呼ばれることに(笑)。
4G スマートフォン開発のプロジェクト管理で、以後6年間、マネジメント業務に専念しました。
プログラミングのできるエンジニアとして呼ばれたのですが、これ以降プログラミングとはほとんど縁がなくなります。
ですが、自分の技術、経験や対価を考えてみれば当然の流れで、プログラムを組むだけでは対価に見合わず、並行してプロジェクトの管理もこなせることが、私の価値だと考えました。
これはメイテックのエンジニアの「必然」かもしれません。
マネジメントは経験してみれば、プログラミングとはまた違った面白さに満ちています。
何より100% 計画通りには進まないところがまた面白い(笑)。お客さまとの綿密な調整やプロジェクト内での濃いコミュニケーションを重ねながら、計画通り進むよう的確な手を打てるのがマネジメントの面白さと言えます。
しかし、就業環境や企業文化が異なる点は念頭に置く必要がありますし、国・会社・顧客・部門、それぞれのルールを厳守した上で、現場の声から状況を判断し、自分に何ができるか、メンバーに何を指示するかを瞬時に考え、実行していかなければなりません。
メンバーの歩く先につまずきそうな問題があると気付いたら、事前に取り除くのがマネジメントというものですから。
私は現在、自動車のコネクテッド開発に関わる業務品質改善のマネジメントに取り組んでいます。
上から順に工程を追っていくウォーターフォール方式の開発ではなく、品質はプロセスがつくるものという考え方の下、どんどんつくり込んでいく中で、品質改善を進めていく業務です。
ありがたいことに、定年後もエンジニアを続けていくことができそうですし、これからもお客さまに喜んでもらえるアウトプットを出していきたいですね。
自分の経験を振り返って思うのは、IT分野に限らず、技術を取り巻く環境も、それに伴うシステムもすぐに変わってしまうということ。だからこそ、変化を恐れることなく、次はどんな変化が起きるのかを見極めて対応していけば、おのずと次の展望も拓けていくのです。
(インタビュー:2019 年12月10日)