「HSP／HSS目線で語る職業のメリット・デメリット」について当事者の方々に書いていただいています。
今回はプログラマー＆SEのご経験をかたやんさんに語っていただきました。
HSS型HSPのお仕事経験談No.35：かたやんさんについて
まず最初にかたやんさんについてご紹介します。
| ご年齢 | 30代前半 |
| HSP？ HSS型HSP？ | HSS型HSP |
| ご職業 | プログラマー システムエンジニア （以下、SEと記載） |
| 職場環境 | オフィス勤務 |
| 雇用形態 | 正社員 |
| 就業期間 | 2010年4月～2017年1月 (現在は職種転向して同じ会社に在籍中) |
HSS型HSPのお仕事経験談No.35：お仕事内容
お仕事内容について教えてください。
新卒で入社したIT企業で、地方自治体（市役所・町村役場）に基幹系システムを導入・運用サポートを行う部所に在籍し、そこでプログラマーやSEとして従事しておりました。
地方自治体の基幹系システムとは何かを分かりやすくいうと
といった仕組みです。
どんな環境で働いていましたか？
事業本部（オフィスの同じフロア）レベルで見ると300人ほど在籍していました。
しかし、お客様の業務（税、住民記録、福祉、水道、内部事務）によって細かくチーム分けされ、普段一緒に働くのは10人ほどのチームでした。
年齢は22～60歳まで幅広い年齢層がいました。
新卒１～３年目はプログラマーとしてシステムの構造を学び、若手～中堅になるとSEとして自治体職員様と打ち合わせしてシステムの仕様を話し合って決める、ということをしていました。
このお仕事を始めたきっかけは何ですか？
大学生活では情報学部に在籍しプログラムやネットワークの基礎を学んだので、新卒で就職活動をする際、大学で学んだことを活かせると考えIT企業への就職を選択しました。
また、生まれ育った地元の中では大きな企業ということもあり、仕事を通して大好きな地元への地域貢献にも繋がるのではないかというのも大きな理由でした。
HSS型HSPのお仕事経験談No.35：お仕事のメリット
どんなところがHSS型HSPに合っていましたか？
SEに求められるスキルの１つとして、「分野の幅は狭くても良いが、深い知識・専門性」だと思います。それをさらに掘り下げると２つ必要なことが出てきます。
1つ目は、技術的な部分の知識についてです。
システムを作る際には、プログラム言語を正しく理解してプログラミングする必要があります。プログラムを作ったらそれが正しく動作するか、様々なテストケースを設けて何度もテストをします。
プログラムが完成したら、システムの仕組みに合わせて適用することで、システムが正しく動くようになります。
このように、1つ1つの工程に対して漏れ抜けがないよう確実に遂行する必要があります。そのためには深い知識をしっかり習得している人が、社内からもお客様からも信頼を得られます。
2つ目は、お客様が従事する業務の知識です。
私は地方税のシステムを担当しておりましたが、地方税法で定められたルールを理解できていないと、プログラムやシステムの仕様がそもそも正しいのかどうかがわかりません。
例えば、軽自動車税では「90cc以下の二輪車は年2,000円の税額が掛かる」ということが定められていますが、そのルールを知らないと「90cc以下の二輪車の場合は税額を2,000円にするシステム」を作ることはできません。
税目（固定資産税・住民税・軽自動車税）ごとに、多岐にわたるルールが地方税法で定められているので、それらを1つ1つ正しく理解する必要があります。
また、税目ごとにいろんな専門用語が出てきますが、この意味を理解していないと自治体職員様と会話ができません。
意思の疎通が図れないと何が正しいかわからないので、「誤ったシステムを作ってしまい、誤った税額を住民に払わせた」ということにも繋がりかねません。
上で述べた2点とも、物事を深く理解する力が必要になります。
この点はHSPの長所である、「じっくり物事を考えられる」ということに繋がるので、職場環境やお客様との関係次第で、大きな力を発揮できる可能性があると思います。
システムを作る前に、専門用語の理解や特殊なルールを理解する必要があるんですね。
かたやんさんご自身に合っていたところはありますか？
「1つのことを深く掘り下げて考える」という部分は自分の特長です。
そのため、プログラム言語やシステムを深く知り、仕様やプログラムを作ることで自分が作ったモノが社会の役に立っているという喜びを感じられました。
その点は、自治体向け税システムのSEをやって良かったな、と思います。
HSS型HSPのお仕事経験談No.35：お仕事のデメリット
HSS型HSP、かたやんさんに向いてないなと感じた点を教えてください。
プログラマーやSEなど、システムの導入や運用を行う業務は決められた予算と納期で確実に遂行することが求められます。
そのため、可能な限り、機械的に効率よく確実に遂行することが求められる世界でした。
QCD（※）が１つでも欠けると、会社かお客様に何らかの損失が生まれます。
そんな状況なので、どうしても１人が複数の職務を行わないと業務が滞ってしまいます。
そうなると残業が増えて、体力的にも精神的にも疲弊することに繋がり、頭の回転が悪くなって効率が落ちる、という負のスパイラルに陥りやすいです。
そういったマルチタスクの状況でも自分の中で整理して、折り合いを付けながらこなせる人でないと難しい職種だなと思いました。
※Quality（品質）・Cost（コスト）・Delivery（納期）
かたやんさんが辛いと感じたことはなんでしたか？
お客様が自治体ということで、システムの不具合によって住民に迷惑が掛かると、それがすぐに新聞やローカルテレビ局で報道されてしまうということです。
「住民票の名前が正しくない」
「納税通知書の税額が正しくない」
「税金を納付済みの人に誤って督促状を送った」
どれも、一市民から見ると「役所がそんな間違いをするわけない」と思います。
だからこそ、失敗できないというプレッシャーが大きかったです。
もし失敗したら、自治体が悪いようにメディア報道され、間接的に自分の会社も悪いようにメディア報道される、ということは常に不安として頭の中にありました。
もちろん、大きな組織の中の1人のプログラマー、1人のSEでしかなく、なにかあれば責任を取るのは上の人になります。
それでも自分の失敗がキッカケで、顔の見えない住民の人に迷惑をかけるということは、とても怖いことだと常々思っていました。
どの仕事もミスは許されないかもしれませんが、役所に携わっている場合はより緊張感が高まりますね…。
お仕事をお辞めになった理由はなんですか？
同じ事業本部の営業部長に、「SEから営業に転向しないか」と声をかけていただいたのが、SEを辞めたキッカケでした。
当時の営業部では「行動力はあるが、お客様の業務のことを全然理解できていない営業マンばかり」という悩みを抱えていた。
また、その当時は多忙により自分は心を病んで会社を休むことがあったが、営業部長はそこに目を付けて「『心を病む』ということは『感じ取れる力がある』ということ。営業マンは、相手の考えていることを感じ取る力がすごく必要なので、営業で力を発揮できるのでは？」と言っていただいた。
「SEの経験からお客様の業務を知っている」
「相手のことを感じ取れる」
という点に目を付けられた営業部長からオファーをもらったことをキッカケに、同じ事業本部内で営業へと職種転向し、SEを卒業しました。
HSS型HSPのお仕事経験談を聞いて感じたこと
SEとしてのスキルはもちろん、クライアント先の独自のルールや指示を考慮して作業を進める必要があるお仕事ですよね。
SE自体は深い知識を習得し、それを活かせる職種だと思います。
ですが、ミスをすると大きな問題に発展しやすいということは、その分責任感やプレッシャーも大きい…
それによって精神的に辛くなると続けられないですし、かたやんさんの選択は賢明だなと感じました。
かたやんさん、ご経験を語っていただきありがとうございました！
※かたやんさんのお話は次回（No.36）へ続きます〜！
