今回の記事では「レジェンドインタビュー第2弾」として、長年当社に勤務しているレジェンド社員にインタビューを実施しました！入社当初の思い出から、元号が平成に変わったその時のエピソードなどなど、貴重なお話盛りだくさんです。ぜひお楽しみください！

レジェンド社員紹介

入社当時の思い出

ーーー早速ですが、西條さんが入社された当時のお話を教えてください。

入社したてはシステム開発事業部という部署に所属してました。主にお客さま向けのシステム開発を生業としている部署で、最初は銀行さん向けのシステムを担当していましたね。
第三次オンラインって聞いたことありますか？

ーーーいえ…初耳です。

第三次オンラインは、それまでの第二次オンラインで構築されたシステムでは対応の難しい高度な要求を叶えるために実施された大規模なシステム刷新のことです。

私自身は、第三次オンラインそのものではなく、銀行が自身や顧客のために債権や株式を扱うための仕組みを担当していました。開発の規模としては小さかったんですが、その分全体を見渡しながら進めることができたので非常に勉強になりましたね。

ーーー役割としてはどんなことをされていたんですか？

若手なのでまずはテスト実施やプログラム開発がメインでした。その開発ではゼロから開発するだけでなく他社で使用しているものを購入し、納品先の企業標準に書き換える作業をやっていたりもしました。購入したJCL（Job Control Language）を見て、プログラムの入出力先や割り当てメモリ量などを書き換えたり、あとはエラーメッセージの定義なども実施してました。

ーーーその頃はお客さま先へ常駐する開発スタイルでしたか？

はい、お客さまのところに常駐でした。今と違ってパソコンが1人1台なかったので、共用の端末（ダム端末）を使用していて、混んでいるときは順番待ちするときもありましたね。
あと、うちの会社の中ではプログラムを書いたときに量が多いときはパンチカードに出していたんですよ。

パンチカードには1枚に80文字入れることができます。それはプログラム上では1行分の情報なので、もし500行のプログラムだとパンチカードは500枚も必要になりました！そして作成したパンチカードを今度はコンパイルしていくのですが、メインフレームに本番処理が走っていたりすると、それを待たないといけないので2時間待ち。そんでもってコンパイルエラーが出ると、その2時間も無駄になってしまうんです。だから、パンチに出す前に机上でしっかりとデバッグする習慣がつきましたね。

ーーー頭の中でデバッグもされていたのですね。

頭の中で紙に書いてある通りに仮想データを一通り流してみて、無限ループしないかなどを検証してましたね。

ーーー現代は恵まれていますね…

昭和から平成へ　年号切替の裏側

ーーー昭和から平成に元号が変わることは令和の時と少し違い、前々からわかっていたものではなかったと思いますが、最初はどのように見られていたんですか？

たしかに、急な部分はありましたね。ただ1988年ごろから昭和天皇のご体調が悪化しており、社内でも元号が変わるかもしれないという話は出ていました。そのため、秋口に影響調査を始めて大体の修正箇所は特定して変更を迎えることができましたね。

ーーー事前に調査をされていたんですね。

当時、システムの中では西暦で持っているところが多かったのだけれども、紙に出すときは元号で出すことがほとんどだったので、アウトプットに関するところは全部やらなきゃいけなかったな…。

ーーーかなり影響範囲は大きかったんですね。実際に改修するぞとなった動き始めはどんな感じでしたか？

あらかじめ計画された改修で悪影響がないことを確認していたので、もう新元号を待つ状態でした。

ーーーなるほど。世間一般的にシステム界隈ではそのようにやっていたのでしょうか？

おそらくは。私も銀行の中しかわからなかったですが、アウトプットされた紙に元号が出ることがデフォルトになっているような業界では皆同じことをやっていたと思います。
あと改修するときには、それになる確率が一番高いといわれていた漢字2文字を仮案として設定しましたね。

ーーーおお！実際はあっていたんですか？

実際に1月7日になって発表されて平成と出てきたときに、もう全然違うじゃん！となりました（笑）。

品質管理のお仕事　高額案件のレビューと勘所

ーーー現在は経営企画部品質管理グループに所属されておりますが、その中で実施されている高額見積もりの品質管理レビューについて立ち上げの経緯からお聞きかせいただけますか。

まず前提として、本レビューが立ち上がる前は大規模な開発プロジェクトには成功したものの実際には危うい場面のあったものがいくつかありました。大規模プロジェクトは開始前に稟議を上げることになっており、当然役員は確認するのですが、稟議で上がってくる情報だけではなかなかリスク等を把握することは難しいです。
また、以前は役員が部門長を兼任して現場に近い状況でしたが、次第に経営に専念するように変わり、リスクの把握がより難しい状況になりました。そうした背景から稟議の品質確保ひいてはプロジェクト全体の品質向上のために、事前説明の場として品質管理レビューが始まりました。

ーーー制度検討にも動かれていたんですか？

制度検討はしましたが長期間やっていたわけではなく、すぐにこれは必要だという話になり実施が決まりましたね。

ーーーすぐにも施行が始まったんですね。施行開始直後と現在とでレビュー実施の基準や条件は変わりましたか？

元々は「対象が開発プロジェクトであり、基準額を超えた時には実施する」というガイドで運用していましたが、実施の基準は曖昧な部分もありましたね。現場の解釈で本来実施すべきものも実施されていないことがいくつかありました。なので、そういった基準をより明確にして曖昧さをなくしたものが今の仕組み・基準になっています。

ーーー運用の場面では、品質管理のみなさんへ急にレビュー依頼がきて、かつ短時間でそれを見切らないといけない事もあるのかと思います。そうした時間も限られた中にあっても品質を確保するためにレビューの勘所として意識されていることはありますか？

はい、まずは見積もりガイドの中でレビューに盛り込むポイントを提示していますので、基本的にはそれに沿った形で見ます。例えば、顧客が新規顧客であれば、それはどのような経緯から生じた案件であるか、顧客はシステムに対してどれくらい知見を持っているかなどがポイントとしてあります。また個人情報を扱う場合には、どのような管理策を考えているかも重要な要素です。私が情報処理安全確保支援士でもあるので、使用する技術に対するリスクヘッジや認証許可の観点も見ています。
そして、特に気にしているのはステークホルダーです。お客さまはどういった組織で、カウンターパートにはどんな方がいて、最終的に意思決定するのは誰なのかといったところです。こうした点は重点的に見ていますね。

ーーーこれまで多くのレビューを行ってきた中で会社として何か変化は見られますか？

以前と比べて、よりよいプロジェクト運営が考えられるようになってきているなと感じます。以前は機能の積算でスケジュールが引かれており人員体制が具体的に見えていないものもありましたが、今はだいぶ減ってきました。

ーーー会社としてよい変化を生んでおり、こうした取り組みは継続させていきたいですね。西條さんのように的確なレビューを行うためには、どのような経験やスキルが必要になると思われますか？

まずはシステム開発の工程を一通り経験しておくこと。また、1度くらいは失敗経験があるとなおよいですね。

ーーーその失敗とはどのようなものをイメージされていますか？

プロジェクトでいうとQCDを守れなかったこと。スケジュールが予定より延長してしまうことや、当初の想定より規模が増え、スコープ管理がうまくできなかったことがあげられます。

ーーーこの2つは主に経験として積み重ねるところですね。加えて先程資格を活かしたレビューのお話がありましたが、体系的な知識も必要なポイントになりますか？

それもありますね。最近プロジェクトマネジメント研修を受けている方が多いと聞いていますので、PMBOKは押さえてほしいと思っています。また、各種の開発方法論についても実際に経験することがベターではありますが、教科書で学べるものは一応やっておいた方がよいです。
あと、若い人は広く網羅的に勉強することも必要なことだと思うので、全体を押さえる意味で基本情報技術者試験は取得してほしい。それを取得したうえで高度情報資格を1つ取得できているとよりよいかなと思います。

これからに向けて　西條さんご自身について

ーーーここからはこれからの未来に向けてのお話をお聞きしたいのですが、西條さんが今後やってみたいと思っていることはありますか？

まだあまり先のことは考えていませんが、退職したら職業訓練をさせてもらってフォークリフトの運転をできるようになりたいです。

ーーーおお！前々からやってみたいと思われていたんですか？

なんとなく（笑）。
何かを運びたいというわけではなく、機械を操りたいです。あとはこれまでの趣味を継続していければと思います。

ーーー合唱は三団体入られていますよね。

もう学生のころからずっとやっていますね。慣れると三つぐらいは大丈夫です。練習時間が重ならないのは前提ですけど。

これからに向けて、メンバーへのメッセージ

ーーー最後にこれからのインテージテクノスフィアメンバーへメッセージをお願いします。

1つ目はアプリケーションやインフラのどちらか一方に知識を偏らせるのではなく両面を学んでほしいことです。これから先、AWSの構築を考えたり、コードでインフラを管理することを考えると、どちらかだけではうまく立ち行かなくなると考えています。そのため、両者の間に垣根を作らずに学んでもらうことが大事だと思います。
2つ目は基本を学ぶことの重要性です。私自身、元号の対応や古い第一種情報処理技術者試験などでアセンブラ言語に取り組み、コンピュータの動作原理をプリミティブな形で理解できるようになりました。そのおかげで、ノイマン型計算機であれば、どんな言語であろうが、どんなツールを使おうが基本的な動作は何も変わらないと思っています。またRDBを使うにしても、単にSQLを知っているだけでなく集合論や関数従属性といった理論的な背景を理解していると効率のいいSQLを書くことができます。
なので、基本の基本を知っていると、この先技術が変化しても活躍できる人材になれるかと思いますので、ぜひ学びを深めてほしいです。

ーーーまずは基本を理解すればすべてはそこから発展していけると学ばせていただきました。西條さん、貴重なお話をありがとうございました！

終わりに

今回の記事では、レジェンドインタビュー第2弾として西條さんに入社当時の思い出から、知られざる年号切替の裏側、レビューの勘所など大変貴重な話をお聞きできました。また最後のメッセージからは長年勤めてきたからこその想いを感じ取り、若手に限らず今後働くうえで大事なポイントを学ばせていただきました。
いつか西條さんのように活躍できる日を夢見てこれからも精進していきます！