私は過去何回も資格試験に不合格になっています。最初は情報処理２種（現在の基本情報処理試験）に始まり、現在の高度情報処理試験に至るまで何度となく不合格をい突きつけられています。
ただ、現在50代の私が、過去、この資格を持っていないことで仕事での評価を下げてきたかというと、はっきりと否！ということが言えます。
今の私の立場としては、どちらかというと人を面談するような立場だったりするのですが、その時に資格の有無を最上位の評価基準にしているかというとそんなことはなく、むしろ参考程度にしか見ていないのが現実です。
では、なんで今でも資格試験に挑戦しているのか？と言われれば、社内の制度の問題で、給与をより上げていきたければ資格を持っていた方がやりやすいという１点に尽きます。
ただ、これがないからまったく上がれないかといえばそうでもなく、仕事で成果を出せば、それを覆すことも可能です。
資格試験の苦手な私は、今まで資格持っていなくても仕事ができれば！とある意味言い訳をしながら過ごしてきました。
そんな資格を持っていない私でも、会社からの評価が年間通して最高ランクだったこともあり、そのことからも資格だけで全てが決まらないのも事実です。
若手で、ものすごく技術力があるが評価されなかったり、中堅は資格は持っているが、なぜか仕事での成果が出しきれないという人をたくさん見てきました。
そこには、どういう違いがあるのでしょうか？
私自信、資格の重要性はもちろん知っていますが、現場で本当に差がつくのは「非技術的スキル」だと思っています。
特に中堅以降、昇進や転職で評価されるのは以下の3 点であると思っています。この３点をより持っていることで、評価される人と、されない人に差が出るのではと思います。
50 代で SE 経験 28 年の私が、資格の壁に立ち向かいながらも最高評価を得てきた中で見出した「キャリアを左右する 3 つの非技術的スキル」を、この記事ではご紹介します。
私はこれで定年、もしくはそれ以上、この業界で生きていけると確信しているので、参考になれば嬉しいです。
本記事から 3 回にわたり、これら 3 つの非技術的スキルを個別に深掘りする連載シリーズとしてお届けします。今回は、最も重要な「スキル 1」の解説です。
1. なぜ「技術力 × 熱意」では失敗するのか？
技術者の共通認識の誤り
多くの SE は「技術的に正しいことを言えば、相手は動く」と信じていると思います。しかし、これは社内政治や部門調整では通用しません。
むしろ技術スキルを盾に正論を振りかざし過ぎると、話すら聞いてもらえず評価を下げる結果を生むことすらあるのです。
過去私が参画していたプロジェクトでのことでの失敗をお話しようと思います。
ある程度設計が終わっているタイミングで後から参画した時のことです。設計も程度終わってこれからプログラミングのフェーズという時に、参画した際の勉強も兼ねて設計書を読んでいました。
私はバッチ処理が得意で、いろいろな知見を持っていたこともあり、設計書を見て直ぐに実際に使い始めた時に苦労するイメージがついてしまいました。それを会議の場で主張したところ、会議自体が凍りつきました。
その主張は結果的にバッチ処理を３本ほど作りを見直して、プログラムにも影響が出るものでした。
設計自体遅れ気味で、早くプログラミングのフェーズに入って進捗を進めないといけないのが、全体の総意だったのに、その空気を読めず、こうあるべきで正論を振りかざしてしまったせいで、その後のプロジェクトでの立ち位置が微妙になってしまい、やりづらくなってしまったのを覚えています。
この苦い失敗から私は、コミュニケーションはただの情報伝達ではなく、「利害調整と信頼構築」のツールであり、特に「部門間」という利害が交錯する場では、言葉を「相手の利得」に翻訳する戦略が必要不可欠だと学びました。
2.【プロジェクト内の利害調整】「3 つの翻訳力」で衝突を避ける
2-1.翻訳力 ：失敗の本質は「視点の固定化」にある
プロジェクト内であっても、「設計者が重視する安定性」と「開発者が重視する納期」は常に衝突する。
私の失敗は、「バッチ処理のあるべき姿（技術的な正論）」という一つの視点に固執し、「進捗遅延という管理者の視点」や「手戻りへの不満という開発者の視点」への翻訳を怠ったことにある。
人を動かすには、技術的根拠を「相手の最も関心のある利益・不安」に翻訳する戦略的コミュニケーションが必要である。
自分の立場、考えだけを押し付けては人は動かない。どこまで相手の立場で考えられるかが重要になる。
2-2. 翻訳力１：技術的正論 「プロジェクトの安定性（リスク）」
現在、管理者（PM）をしている私の立場から考えると、「リスクの回避」と「プロジェクトの完遂」が命題です。
そこには売上、利益の達成、顧客からの信頼を得るということを継続的に実施していかなければなりません。
開発者の立場だった時、そのあたりを考えがなく、正論を振りかざしたことが失敗でした。それも言い方や相手の立場を考えた振る舞いであれば、問題にならなかった、もしくはよりよい方向に進んだ可能性もあります。
「こうあるべき」ではなく、「このまま進めると、3ヶ月後に誰にも見えない重大な障害が発生し、炎上するリスクが80%ある」という明確な数値化をして、管理者目線の言葉に翻訳することで、その立場の人に意図が正確に伝わり、プロジェクトをよりよい方向に導き、存在感を示して評価されるという方向に進んだかもしれません。
このように、技術的な正しさを「炎上リスク回避」という管理者目線のメリットに翻訳することで、会議を凍らせることなく建設的な議論に持ち込めたはずです。
2-3.翻訳力 2：課題 → 「相手の利益」
次に実際の現場、つまりは開発者の立場で考えてみましょう。
開発を実施している時、開発者は「自分の作業の効率化」や「作業の不満の解消」といったところに意識が行きがちです。
それはプログラムをいち早く作成することで成果を上げ、評価される。
そんな中、いきなりこれが正しいから設計書を直せと言われても、すぐ受け入れて実施するのは難しい。
もちろん理由が明確であれば実施する人も多いが、進捗がギリギリだったり、当初の設計がレビューまで通っているものであった場合、簡単に受け入れられるものではない。
なので、「設計を直せ」ではなく、「設計を１日見直すだけで、開発フェーズ後半でのテスト・デバッグ工数を10日間削減できる」という相手のメリット（工数短縮）に翻訳する。
人はメリットがあれば行動するという特性がある。
気づいた「～であるべき」を実施してもらうためのメリットを明確にして伝える。
これができるかが一番大事な翻訳である。
例えば、私の失敗を例にすると、「バッチ処理を直すことで、プログラミングや単体テストの難易度が下がり、ベテランでなくても作業しやすくなる」という「開発者の視点に立ったメリット」を伝えたら、設計見直しへの協力が得やすかったのではないかと今は思う。
2-4. 調整 → 「個人の貢献とリーダーシップ」
ここでは開発者の中でも自分が正しいと思って、それを行動原理としているプライドの高い開発者を対象に話そうと思う。
こういう人は「～あるべき」の正論を振りかざして、指摘されることをものすごく嫌う。それは自分が正しいと思っていることを否定されると感じるからである。
自分は正しいというのを盾に、指摘＝否定と捉えて猛烈に反発するということが多い。このような場面でこそ、相手のプライドとリーダーシップに貢献して協力を仰ぐことが大切です。
それは「間違いを指摘する」のではなく、「改善案を出すことで、あなたの設計がプロジェクトの最終的な成功に不可欠なものになる」という、個人のプライドとリーダーシップに翻訳して協力を仰ぐことが大切です。
ベテランの経験を活かして、これを実施するには、改善案を「私の指摘」ではなく、「〇〇さんの知見を活かして、より強固な設計へと昇華させる」という二人称の言葉で伝えるのが大事である。
まとめ
本記事では、50代SEである私が28年のキャリアで最も重要だと痛感した非技術的スキル3つのうち、最重要の「戦略的コミュニケーション能力」について、私の失敗談を交えて深掘りしました。
戦略的コミュニケーション能力とは、単なる会話術ではありません。 それは、プロジェクト内の異なる利害グループに対し、技術的な主張を「相手の利益」や「プロジェクトの安定性」という言葉に翻訳し、人を動かすための「翻訳力」です。
このスキル 1（翻訳力）を身につけることで、あなたは「正論を振りかざす技術者」から「プロジェクトを成功に導くリーダー」へと進化できます。
しかし、人を動かす力は、この翻訳力だけでは完成しません。あなたの知識や経験を「価値」として認めてもらうためには、もう一つの重要な能力が不可欠です。
次回予告：
次の【キャリア 3部作】第2弾では、「あなたの経験や知識を、確実に相手に伝え、資産化する力」に焦点を当てます。
このスキルがなければ、どんなに素晴らしい設計やアイディアも、誰にも理解されずに終わってしまいます。
【非技術的スキル2】50代SEの資産化戦略！知識を人に伝える「ドキュメント・言語化技術」
ぜひ次回の記事もご覧ください。
