第25回 四方山話（8） ITエンジニアだったとき、本当に役に立ったこと
こんにちは、キャリア・コンサルタント高橋です。
筆者は現在キャリア・コンサルタントの仕事をしていますが、元ITエンジニアでもあります。今回はITエンジニアの時期を振り返り、今現在に至るまで、本当に役に立ったと感じていることをご紹介したいと思います。
■職業柄、役に立ったこと
ITエンジニアという職業柄、役に立ったと思えることを考えてみると、一般的には要件定義、設計、プログラミング、テスト技法などの技術や知識、ツールの使い方やテクニックなど、ITエンジニアとして仕事を効率良く進めるノウハウなどが思い浮かびます。筆者の場合でも、
- どうすれば効率良く網羅性の高いテストができるか
- どうすれば誰にでも分かりやすい無駄のないプログラミングをすることができるか
- どうすれば論理的に筋道を立て、行間を読まなくても理解ができる要件定義や設計ができるか
- どうすればプロジェクトを成功に導くためのプロジェクト管理を行えるか
などは経験の中から身に付けてきたと思います。ただ、これはITエンジニアであれば誰しもが少なからず経験していることです。そう思うと、これらのことは、どちらかと言えば当たり前のイメージがあり、今現在に至るまでに本当に役に立ったと思えるものとは少し違うような気がしています※。
※少し違うような気がしています：違うような気がしているだけで、役に立ってないわけではないですよ（念のため）。
■職制柄、役に立ったこと
職制とは、社長、取締役、部長、課長、係長、主任、リーダーといった会社における役職のことを指します。筆者もいくつかの役職で仕事をした経験がありますが、こういった役職では職制に応じた仕事を達成することが求められます。例えば、自分の部署の目的を達成させるためというミッションでは、人との繋がりや活用の仕方が求められることがあります。筆者の場合でも、
- 上司との上手な付き合い方
- 部下のパフォーマンスを向上させる有効な方法
- 他部署からの協力を取り付けるための交渉
- 社外の協力会社との折衝
などは経験の中から身に付けてきたと思います。ただ、これも何かしらの職制に就かれている人であれば誰しもが少なからず経験していることです。そう考えると、職業の時と同様に、これらについてもどちらかといえば当たり前のイメージがあり、こちらも、今現在に至るまでに本当に役に立ったと思えるものとは少し違うような気がしています※。
※少し違うような気がしています：くれぐれも、違うような気がしているだけで、役になっていないわけではないですよ（念のため）。
■ITエンジニア1年生のときのあるできごと
それでは、筆者が印象に残っている、役に立ったこととは何か？ 筆者が社会人1年生の時に経験した最初の案件でのあるできごとがそれに当たります。
当時、筆者は官公庁向けのシステム開発に従事していました。しかし、筆者は開発担当ではなく、運用保守担当として開発業務のサポートを行うような仕事をしていました。そのシステムはメインフレーム（汎用機）で構築されており、一言で運用保守業務といっても、非常に多種多様な業務を行わなければなりませんでした。
その中に、本番環境にロードモジュールを提供する申請業務がありました。開発部隊が作成したテスト環境にあるロードモジュールを本番環境にリリースする仕事で、リリースの際は申請書とCMT※をセットにして運用保守チームの所まで持ってきてもらう運用になっていました。その運用では、ロードモジュールのリリースタイミングが1日に1回16時と決まっていたため、締切間際には申請が殺到することもあったり、締切後にも無理矢理ねじ込もうと依頼してくることもあり、作業が煩雑で提供ミスが起こりやすい運用になっていました。
※CMT：Cartridge Magnetic Tape（カートリッジマグネティックテープ)のこと。IBMが開発していた磁気テープ補助記憶装置でメインフレーム（汎用機）で良く使われています。CMTより前によく使われていたMT（オープンリール型磁気テープ補助記憶装置）と違いコンパクトになっています。ただ、10本もあると結構重かった気がします……。
あるとき、開発部隊の人と話す機会があり、この運用について話を聞いてみたところ、こんなことを教えてくれました。
- 本番環境に提供するロードモジュールはCMTに入れて申請しなければならない。そのため、毎日午後は提供用CMT作る人でマシン室が混み合い、順番で提供用のCMTを作成するような状況になっている
- CMTは開発部隊の各チームがそれぞれ持っている所有物のため、提供作業が終わったCMTを返却するタイミングが遅れてしまうと、次のCMTを作れず、本番リリースに影響を及ぼすことがある
これを聞いた筆者は、運用保守チームの責任者に相談し、運用を簡略化したいと申し出ました。そのとき、こんな運用を提案しました。
- 運用保守チームは、提供用データセットを提供日別に作成し、開発部隊は提供を希望する日にロードモジュールを置き、申請書のみ運用保守チームに提出する
- 運用保守チームは、提供日の締切を過ぎると、データセットへのアクセスができないようにし、作成したロードモジュールと申請書を突け合わせ、提供するロードモジュールに不備がないことを確認する
- 運用保守チームは、提供するロードモジュール一式をテスト環境からCMTに吸い上げ、本番環境にロードモジュールをリリースする
- 運用保守チームは、リリース作業が終わった申請書を開発部隊に返却する
この運用の変更は開発部隊に喜ばれました。中でも、提供日ごとにデータセットを作ったことで、開発部隊は計画的なリリースができるようになりました。また、突発的なことを除いて締切後は翌日のリリース依頼に回してもらえるようになり、無理矢理ねじ込もうとする依頼もなくなりました。そして、何より作業が簡素化され、ミスも極端に減りました。
この時、筆者は「こんな運用にしたら開発の人が喜んでくれるだろうなぁ」という単純な考えだけで運用を変えようとしました。そういった意味では、今にして思えば少し浅はかな行動だったかもしれません。しかし、社会人1年生のITエンジニアが開発部隊のためを思い、浅はかながら考えを巡らし、運用を変えたことで、結果的に提供にかかる作業工数を下げ、ミスを減らすことが実現できました。そして、このことをキッカケに筆者は、仕事でこんなことを考えるようになりました。
この仕事で相手が望んでいることはなんだろうか？
この考えは、筆者がITエンジニアだったとき、どのような場面においても役に立ちました。ITエンジニアの仕事には、必ず仕事の依頼主やサービスの提供者がいます。彼らの要求に答えること、そのためには彼らが望んでいることを考えなければなりません。それを考えることで、うわべだけではない、その仕事の本質に近づいているような感覚にもなりました。
本当にその仕事の本質に近づけたかどうかは分かりません。しかし、その考えを持つのと持たないのとでは、仕事をする上で大きな違いがあることは、周囲の人の対応を見る限り確かのようでした。
この考えは一見すると当たり前の話ですし、何かしらの自己啓発本には真っ先に書かれていることだと思います。その意味では目新しさも何もありませんが、筆者の場合、偶然この考え方に気付き、自分なりにこのことにこだわって仕事をしてきたことで、自分なりにこの言葉の意味を体験できました。そして、その結果が今の自分につながっていると考えています。
そう考えると、この考え方は、筆者がITエンジニアだったとき、本当に役に立ったことであり、今現在、筆者がキャリア・コンサルタントとして活動する上でも欠かせないものとなっています。