ITエンジニアのための「メンタル」入門

ITエンジニアに必要な能力はスキルだけではありません。それを支える精神力が伴っていないと、いくら高いスキルを持っていたとしても、十分にその力を発揮することはできません。
そして、受託開発というITビジネスの主戦場で戦い続けるITエンジニアが持つべき精神力は、特殊で歪んだものと言えるかもしれません。

■ITエンジニアのあるべき姿

ITエンジニアには、以下のような技術者としての倫理感や慣習を持つことが求められることも珍しくありません。
　
　・自律
　・自己責任
　・謙虚
　・信頼
　・継続学習

いわゆる、野心がなく、文句も言わず黙々と仕事をこなし、必ず約束を守ってくれる存在であることが求められます。

特に、受託開発では、スキルが高いだけではなく、従順で、献身的であるITエンジニアであることが当然のごとく求められます。

■ITエンジニアを取り巻く現実

ITエンジニアは、知識労働者であり、肉体労働者とは異なる職種です。しかし、受託開発においては、人月という時間労働が基本となるため、人海戦術が横行しやすく、単なる労働者として酷使されます。

・１秒の余裕もない日常

時間的な余裕のある作業スケジュールを組まれることはなく、コストを削減するためにギリギリの作業スケジュールが組まれます。さらに、プロジェクトが開始すると、想定していなった問合せ、打ち合わせ、事務作業などの雑用が湧き出てきて、一日の時間を埋め尽くしていきます。

・難易度が判断されない作業

ソフトウェアをつくることは、感情に左右されることも少なからずあります。特に、作業の難易度は、客観的に評価されるものではなく、主体的に評価されるものです。保有する経験やスキルなど属人的要素によって、大きく感じ方が変わってきます。一方、作業を割り当てる側は、実際に自分がやるわけではないので、かなり甘く難易度を考えます。
その結果、実際にITエンジニアに割り当てられる作業の難易度のギャップが大きくなり、無理を強いることが日常となっています。

・できることが有利に働くとは限らない

スキルを磨くことは、ITエンジニアにとっての正論であり、その先には正当な評価と昇格・昇進・昇給があると盲目的に信じられています。そうやって、次第にスキルの幅と深度を大きくし、なんでもできるフルスタック化が進んでいきます。
できることを周知のものとした瞬間、組織は、それを最大限、効率的に利用しようと考えます。仕事の幅と仕事量を増やし、仕事の難易度と責任を重くし、「できるITエンジニア」に”ふさわしい仕事環境”を用意してくれます。
ITエンジニア自身も、多忙を極めながらも、期待感と達成感に酔いしれることになります。そして、それに見合った報酬がない事実は、得られる社内的な優越感によってかき消されてしまいます。

・組織は味方にならない

組織は、常に、顧客の味方です。ITエンジニアにとって、組織が味方になることは、原則、ありません。たとえば、顧客で障害が発生した場合、組織の責任者も激しく詰められますが、結局、原因調査から解決まで実施できるITエンジニア個人へと、矛先が向けられます。

ITベンダは、元来、ITエンジニアが大多数を占める文鎮型の組織です。スタッフや管理職は最小限しかおらず、そもそも組織体としては薄く、対外的な対応にしっかりと対応できるような構造とはなっていません。

・メンバーとの一体感の欠如

プロジェクトのメンバーは、手に職を持ったITエンジニアであり、自分の仕事だけに没頭する人も多く、自分は自分、他人は他人というスタンスです。

しかし、ソフトウェアは個々の成果物を結合させ、全体の動作が想定通りか評価されます。結合時の整合性を確保するには、のりしろのようにオーバラップする部分については、お互いが強力する姿勢が必要です。スキルの高い人ほど、この点をきちんと認識して、必要な情報を提供してくれますが、そうでない人もいます。その結果、孤立してしまうこともあります。

・過去の仕事に容赦なく追いまくられる

ソフトウェア開発はつくったら終わりではなく、稼働し続けるかぎり、担当したITエンジニアは対応が求められます。
このような過去のソフトウェアのお守りは、実績があって経験の長いITエンジニアほどかなりの負担になっていきます。
そうなると、いずれ現業のパフォーマンスにも影響が出始め、悪循環へと陥っていきます。

■追いつめられ、変容するITエンジニアの意識

このような現状下において、ITエンジニアの精神の中には、以下のような意識が芽生えていきます。

・承認欲求

自分より立場の上の人の承認がないと、業務上の正否の判断ができなくなります。重要なことだけにとどまらず、些細なことでさえ、判断を誰かに委ねたいと決めることを放棄するようになります。
次第に「考える力」が消失し、ただひたすら上司や組織からの指示を待ち、それに即刻対応することこそが最も評価される仕事であると思い込むようになります。

・被害者意識

失敗した際、まず、自分の落ち度を責める前に、環境や他者の責任を追及するようになります。それだけでなく、失敗を恐れるため、、自分だけの狭い業務範囲（コンフォートゾーン）だけに閉じ籠るようになります。
業務範囲を広げられず、いずれ知識やスキルも固定化され、陳腐化していきます。

・無反応

会議で発言しないだけではなく、チャットやメールでさえも反応することも極端に少なくなります。情報を発信するようなことがなく、ただひたすら受け取るだけしかしなくなっていきます。そして、単に受け取るだけでは飽き足らず、ひたすら周りに問合せだけを繰り返す「Taker」となっていきます。
自ら調査をするなど行動を起こすようなことがなくなり、発信したくてもできない状態に陥ります。
他者とのやり取りは、「ギブアンドテイク」が基本であり、一方的な「テイカー」は、大事な時間や情報の搾取と変わりありません。

やがて、職業人としての自己が消滅し、組織に完全に溶け込んで一体化していきます。そうなると、創造性が徹底的に欠落し、使い勝手のよい組織の作業者として生きざるを得なくなります。

■ITエンジニアのハガネのメンタル

自由には、経済的自由と精神的自由の２つの種類があります。経済的自由を得るには、収入を増やし、資産を作ることで得ることができます。お金があれば、得られる自由です。経済的自由があれば、ある意味、精神的自由も得られるでしょう。

しかし、経済的自由が得られない場合は、お金では買えない精神的自由を獲得するためのメンタルが必要になります。ITエンジニアを長くできる人達の中には、前述した意識に侵されることなく、自律性と創造力を維持したまま働き続けている人も少なからずいます。彼らが持つメンタルとは、以下のようなものです。

１）スキルという見えない鎧を着る

スキルがあるということは、自分の仕事の生産性と品質を上げるだけでなく、精神的な余裕を生むことになります。強いプレッシャーをかけられても動じなくなります。

年度末の評価で、上司に対して自分が持つスキルをこれでもか見せびらかす行為は、前述したように周りからいいように利用されるだけです。そうではなくて、スキルは、自助努力として身に着けるという考え方に切り替えます。メンタルを包む見えない鎧として、スキルをまとうのです。

スキルは、仕事を通して学ぶことが基本です。
実際に仕事でプログラミングをすることで、実践的なプログラミングスキルが得られます。たとえ卓越したプログラミングスキルでなくても、2流・３流のプログラミングスキルさえ身に着けられれば、ITエンジニアとしてのスキルのコアを持つことができます。

このような手を動かす実務系の「ハードスキル」だけではなく、問題解決力のような思考系の「ソフトスキル」を身に着けることが、特にメンタル面では効果的です。

問題解決は、パターンがあって、それをいかにして多く蓄積（ストック）できるかがポイントになります。自分の身に降りかかる問題だけでは不十分です。他者の問題解決のパターンを引用できるように、身の回りで起こる問題を拾い集め、蓄積していきます。特に、プロジェクトの現場で日々起きている些細な問題でさえ、知っていればいつか役に立つことがあります。
その他にも、日常、メールでやり取りされる顧客の情報、技術的な見解、参考資料など、役に立ちそうな情報を自分のために保管しておくことだけでも、問題解決には有効です。

そして、持っているスキルを「いつでも、どこでも」使えるような汎用的なスキルとするには、独学が必要です。
業務から一歩離れ、業務に隣接する知識を獲得するため書籍を使って学んだり、資格取得によって、業務で得られた知識を体系的に整理しておきます。

２）できることに萎縮しない

優秀なITエンジニアであっても、他の人から上から目線で指摘や意見をされると、反論もせずに「申し訳ありません」と言って、萎縮してしまいます。

このように「できる人」であっても委縮してしまう理由は、要求が厳しすぎる（デマンディング）からです。たとえば、提案書をつくるやいなや事前検証を求めてきたり、テスト結果のメトリクスをみせるとログの解析結果やサブシステム毎の細かなプロファイリングの結果、レビュー議事録などのすべてのエビデンスを要求してきたり、気になる箇所のテスト再実施や追加を求めてきたりなどです。

このようなデマンディングな人たちからの指摘や意見に対し、反発することは、正論であるからこそ、意義があります。

所詮、「やらない人」「できない人」が言うことのすべては正論しかありません。開発現場の状況を無視した正論は、愚論です。こんな話を真面目に聞いていたら体がもちません。

少なくともITエンジニアは、「やる人」「できる人」であることを忘れてはいけません。いくら上から目線で言われたからといって、できる人が精神的にも下僕になるなんてことは悲劇です。
建設的な指摘や意見は、聞き入れるべきですが、行き過ぎた指摘や意見は、きちんと取捨選択する気概を持つべきです。

３）孤独を愛す

組織やプロジェクトの中にある「同調圧力」は、警戒心を持って、取り込まれないようにします。なんでも「みんなと一緒」に動くという考え方は、承認欲求を助長させるだけで、少なくとも個人にはメリットがないからです。
仕事が進まなない大きな理由は、この同調圧力です。個人のペースを乱し、集中力を分断し、そして何よりも他力本願に傾向していきます。

「一人でやるほうができる可能性が高い」という感覚を持ち、同調圧力への違和感を持ち続けることで、周りに順応しても同化しないことです。
時に疎外感を感じることもあるでしょう。しかし、所詮、ITエンジニアの仕事は個人作業であると割り切り、独立独歩で進めていくことです。

４）迷わず人を頼る、迷わず人を助ける

黙っていても仕事のできる人に仕事が集まります。できる人は自分の得意でないことも無理をしてでもやろうとします。そこに問題があるのです。よく考えてみてください。本当にそれが効率的で結果もよいものになるでしょうか。自分ができることを証明したいだけの自己満足ではないでしょうか。

そこで、「孤独を愛す」一方で、仕事を独り占めして自分自身を苦しめるより、他人を使って楽にすることを考えます。
自分だけが仕事をする状況を抜け出すには、積極的に他人に仕事をお願いすることが全体の効率を上げることにつながると考えるのです。

「頑張っていれば上司が仕事配分を考えてくれるはずだ」と思っていませんか？仕事の再配分をしてくれる気の利く上司はほとんどいません。最初に担当を決めたら放置プレイを決め込む人が多いのです。理由は、上から見ると、当然、できる人のほうが仕事のできがいいので、そこから仕事を別の人に回すのはリスクがあるからです。できる人ほど仕事の再配分は自分自身でやるしかありません。
俗にいう８０対２０の法則に従うと、２０％の人しか仕事を真面目にしていないことになります。２０％の人から直接、残りの８０％の人に、少しでも仕事を割り振ることで、組織やプロジェクトとしても大きな生産性の向上を図ることができます。

その逆に、困っている人を助けることも自分を助けることにつながります。周りの人が忙しくしてたり、困っているときに、自分ができる仕事でも知らぬふりをする人は案外多いものです。そこで、「どうしたの？」と口を挟むことができれば、相手から信頼され、協力関係を築くことができます。　

これができれば、相手も当然、あなたが困っているときや苦しいときに助言をくれたり、協力してくれることもあるでしょう。仕事では、「ギブアンドテイク」を心がけることが、自分のためにも、他人のためにも、さらに、組織やプロジェクトのためにもメリットがあることだと思います。

しかし、多くの人は、人の手助けをすることをしません。仕事ができない人ほどそうです。自分が常に忙しいふりをしたいがため、他の人を手伝うことは手が空いているように思われことを恐れるからです。そんな了見の狭いことを考えるよりも、そこから得られる情報がいずれ問題解決に役立つと考えましょう。

５）辞めるカードを持つ

少なくとも、これからの時代に生きていく「やとわれ人」にとって、「辞めれる」という精神状態を維持することは、非常に重要なことではないでしょうか。辞めれずに、萎縮するばかりでは、行き着く先は「死」をも考えなければならないほど、組織や会社の中では見えない重力が増しています。

そこからいつでもスルリと抜けだせるような「辞めれる」精神状態を保つためには、周りがどのように結果を評価しようが、自分としての最善を尽くすことをゴールにし、それでダメならクビでも仕方ないと開き直って仕事をすることです。

そのためには、いまの仕事に支えられているだけではなく、どうにかして、もう一つ、安定剤となる精神的・経済的な支えを作っておくことが生存条件になるのではないかと思います。特技や資格でもいいです。投資や貯蓄でもいいと思います。あるいは、共働きであればそれこそが、もう一つの経済的な支えになると思います。

私も、何度か失業の危機に陥った経験があります。リストラによる「追い出し部屋」への異動だであったり、入社した会社が業績不振により統合され消滅したりなど、退職せざるを得ないような状態に陥ったこともあります。このような経験から、「辞める」ことについて、他の人よりもずっと敷居が低くなったように思っています。
そして、今では、経験と資格、投資と貯蓄が精神的・経済的な支えとなり、開き直って、仕事ができるような状況にあります。

■　まとめ

ITエンジニアが過酷な商売であることは、以下の事実から明白です。

　①仕事に拘束される時間が長い
　②暗黙的に開発者としての責任を背負わされる
　③経験を積むことで仕事の範囲が広がっても賃金が一向に上がらない

そして、ITエンジニアは、「花を見れても果実を得られない」職業です。

ITエンジニアたちは、開発完了後、すぐに、別のプロジェクトに移行させられます。当然、継ぎ目なくソフトウェア労働者を稼働させ続けることが、ビジネスとして最も効率のいいことだからです。

開発したソフトウェアやそれが含まれる製品の売上が良かったとしても、成果としてITエンジニアの賃金に反映されることはありません。その成果は、結局、全員に分配されてしまい、実際に手を動かしたITエンジニアに多く分配されることもありません。

ITエンジニアによる開発の果実は、ITエンジニアを使用する立場の組織によって、開発したサービスや製品が市場で使われている限り、その恩得を享受されることになります。

しかし、本来、開発の当事者こそ、継続した成果の分配があってしかるべきです。
ITエンジニアは過酷な開発を延々とし続け、その一方で、組織だけが儲けを着々と積み上げる構図も、やはり搾取（さくしゅ）そのものでしかありません。このような不条理は、売れるものをつくればつくるほど大きくなっていくのです。

このような状況が、すぐには変わることはないでしょう。
ITエンジニアは「被害者意識」にさい悩まされることに陥らないよう、”意識的”にメンタルを保つ必要があります。その支えになるのは、自分自身のスキルそのものです。
次々と降りかかる課題や問題にできるだけストレスを感じることなく対処できるよう、日々、経験を積み、少しづつでも自信をつけていくことしか方法はありません。