エンジニアはどうすれば評価され、生き残っていけるのか？
どんな業界でも長期間継続するとピラミッド構造ができあがります。
ヒエラルキー型の階層構造…と言った方がいいでしょうか。
この構造は建設業界が有名です。
建設業界は、少数の元請け、下請け、大多数の孫請けという構造になっています。
このような構造だと労働環境の悪化を招くという人もいますが、業界が成長していくにつれてこういった構造になることは必然です。
大きなビルをつくる場合には複数の技術が必要です。
エレベーターの技術者はビルの外壁までは担当できません。
ビルの外壁を担当する技術者は鉄骨を組み立てることはできないでしょう。
個人宅をつくるのであればすべて自前でこなす工務店もあるでしょうが、開発物件が大きくなればなるほど専門技術が細分化されていきます。それぞれ技術の守備範囲が違う企業が、それぞれの領域を最大限活かしながらお互いに存続しあうにはこの形態は非常に都合がいいのです。
ですが、そうやってお互いに不足している部分を補い合うことが本来の目的だったはずが、そうした専門業者をお客さま自身が一つひとつ選定するのはなかなかに難しいという側面があります。結果として、資本金等の責任的体力の高低で元請けへの発注が決定してしまうなかで、その元請けに細かい業者選定の権限も与えることになってしまうわけです。
そうすると、元請けにとって都合のいい（安いところ、聞き分けのいいところ、つながりがあるところ等）業者選定が行使されるために、どうしても業者側のなかで上下関係のようなものが成り立ってしまいます。結果として下請けというとただ言いなりになるだけのブラックな環境が多くなりがちとなってしまうわけです。
そして同じことはＩＴ業界の中でも起きています。
現在（2021年度）は中小企業数が42,454社と言われていますので少々古い情報かもしれませんが、構成はこのようになっています。
ＩＴ業界のなかでも、大きなシステム開発になるとお客さまは大手元請けに発注します。これは与信の関係で、途中で逃げたり、破綻したりしない企業でなくては発注側としても困るためいたしかたのないことですが、これがあまりうまく機能していないことが多いのが現状です。
元請けはシステムの設計をして業務分担を考えて複数の下請けを選定し発注します。
たとえば、画面機能は操作性をよく知る会社が受け持ち、バッチ機能は夜間や繁忙期などの一括業務を詳しく知る会社が担当する…といった形です。そしてさらに、これらの下請けは作業を細分化して別会社（孫請け）に発注したりするわけです。
お客さま自身がこのような孫請け会社に直接発注してもプロジェクト全体を調整、管理する能力はありません。ソフトウェア開発そのものの専門性が高くお客さまからではかろうじて進捗を見て早い／遅いくらいしかわからないため、ただ「何とかしろ」という程度のことしかできません。ピラミッドの段階ごとに対応できる能力がそれぞれ違うため、それらを取りまとめるのは難しく、むしろカオスとなることのほうが圧倒的に多いようです。
近年このピラミッドの階層は下にいけばいくほど、機械化やオフショア開発による代替がきくようになってきました。「考える」力をほとんど必要としない領域まで、業務を細分化しているという背景もあります。
この点が、何年か前から言われている
「ＩＴ業界も、いずれＡＩにとってかわられるかも」
と言われている部分になります。実際、すでに機械化や自動化は進んでいて、エンジニアでなければ実現できない領域というのは減りつつあります。ＩＴ企業自身が変革を嫌い、いまだにエンジニア任せとしているところもまだまだ多いため、実感できていないエンジニアたくさんいらっしゃるでしょうが、そういった企業はコストが非常に高い傾向が強く、薄利多売が今後も続けばいずれ労働人口減少のあおりを直接受けるようになり、今後どんどん縮小していくことは目に見えています。
当然、エンジニアにとっても安住の地はピラミッドの最下層にありません。ピラミッドの少しでも上の階層に登らなければ仕事にならなくなってきています。
また、国内と新興国では人件費が100倍近く違うこともあります。
時給が缶ジュース１本ほどで済んでしまう国のエンジニアと、日本のエンジニアがまったく同じ技術力を持って競争しようとしても、価格的に勝ち目はありません。
では、常に新しい技術を追い求め、次々と新しい分野に鞍替えしていけば生き残れるのでしょうか。
もちろん技術者である以上、新しい技術をキャッチアップしていくことは必要です。しかし安価な代替手段が次々と現れる時代、それだけやっていてもいずれ追いつけなくなってしまいます。
では、旧来のエンジニアリングモデルが会社やお客さまからの評価を得て、必要とされるためにはどうすればいいのでしょうか。
ピラミッドを這い上がるためには、顧客の要望をよく聞くのはもちろん自ら提案できるようになることが求められます。定型的なプランにばかり落ち着くのではなく、常にお客さまにとっての最適解となるよう考えて、考えて、考えつくす努力が必要になります。
言われたことを言われたとおりに実現するだけなら、無駄に人件費の高い国内のエンジニアに頼む理由はないからです。
グローバルの時代、機械化が進む時代、人件費の高い日本には「人にしかできない仕事」だけしか残りません。言い換えるなら企業自体の価値が小さくなっていると言っていいでしょう。今、少なくとも日本国内では『人』自身の価値が重要視され、人自身の価値の高さこそがビジネスを形作るようになっています。
では、『人』にしかできない仕事とはなんでしょう。
それは、ユーザーが言語化できていないモヤモヤした不安や不満のなかから適切な要求・要望を拾い、それを案件化して実現可能な最適解という形で提案するということです。
日本語でのコミュニケーションは他国から見ると参入障壁が高いため、技術がいかに変化しようと陳腐化することはありません（逆もまた然りで、英語普及率が決して高くない日本では他国への参入障壁もまた高いという事実があります）。
また日本では、大手企業のシステム導入がほぼ完了して新規システムを構築する仕事自体が減っています。このような時代に仕事を得るためには、お客さまの話をよく聞いて問題点を抽出し、本当に必要なものはなんなのかということを提案して、営業と一緒に仕事を取りにいくためのコミュニケーション能力がどうしても必要となってくるのです。こればかりは、まだしばらくの間ＡＩにとってかわられることはないのではないでしょうか。
お客さまから見たエンジニア像
現代のエンジニアには純粋な「技術力」のほかに、コミュニケーション能力が必要です。それは間違いありません。
ここでいうコミュニケーションとは、
お客さまの信頼を得るためのコミュニケーション
会社から評価されるためのコミュニケーション
の２つにわけることができます。
そもそも、お客さまであるユーザー企業の担当者は私たちＩＴ企業やそこで活動するエンジニアのことをどのように見ているのでしょうか。
お客さまから見たエンジニア像を営業の印象と比較してまとめると、だいたい表のようになるかと思います。
実際、昔からＩＴ企業の多くは新卒採用時に理系大学出身者を優遇しがちな傾向があります。これは大学時代にプログラミングを学ぶ機会があったり、なかには情報処理技術者資格などの斡旋をしていることが多いためですが、それだけのために文系スキルやコミュニケーションスキルが度外視されがちなのは否めません。
少なくとも、プログラミングやアルゴリズム、機能アーキテクチャを検討するのに、人間関係の機微を察知する能力は不要ですしね…対人スキルが劣っているとお客さまに思われているのも、これまで実際にそういったエンジニアが多かったことの証左でもあります。
この表を見ると、お客さまから見たエンジニア像にはいくつかの問題点があることがわかります。
コミュニケーション能力に劣る
営業活動が得意な方は、お客さまとの雑談のなかから問題点を把握して、その問題を案件化するという能力を磨いています。そのため、相手がわかりやすいように説明をする能力にも必然的に長けていることが多いでしょう。
しかし、エンジニアに話をさせると専門用語や技術用語ばかりで相手のレベルに合わせた会話など期待できるはずもなく、お客さまにとっては何をいっているのやらよくわからない…「エンジニアは言葉がむずかしい」と一般には認識されているのです。
ですから、お客さまから信頼を得るためには、専門用語をお客さまに合わせて翻訳する必要があります。このあたりは「例え話」を使いこなせるかどうかで、おおよその能力が見てとれます。
しかし、話すことだけがコミュニケーションではありません。
実際には「説明資料１つ作る」、「メールを送る」といった行動もコミュニケーションの一種です。相手と情報を共有し、認識の相互理解を図るための行為はすべてコミュニケーションといっていいでしょう。
これらを含めると、エンジニアの日頃行っている活動の多くはどこかしらコミュニケーションのエッセンスを含んでいるものが多く、それこそエンジニアと営業間のコミュニケーション上の差と言うものは意外と縮まるはずなのですが、現在はそれを差し引いても営業に軍配が上がっている…とお客さまには思われていることでしょう。
融通がきかない
お客さまは、納品されたシステムが設計どおりに動くことがあたり前だと思っています。そもそも契約がそういうものなのですから、これを当然と思えなければビジネスパーソンとして失格です。
（請負）
第632条 請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。
しかし、システムをよく理解しているエンジニアほど完壁な約束などできないことを知っています。特に要件定義～基本設計などと呼ばれている工程では「仕様（何を作るか、どれだけ作るか）」が未確定だったりすることもたびたびですし、その後の工程であってもお客さまの都合で変更依頼を受けることだってよくあります。
よく知られる「不確実性コーン」も示す通り、設計確度が高まらないといつまで経っても約束…すなわち請負契約を順守することは難しいでしょう（だからこそ、ＩＰＡ（経産省から移管）の契約モデルなどでも推奨されているわけですが）。
さらに、日本においてはプロジェクトのなかでも縦割りに業務が分配されていることが多く、エンジニアの多くは自分の担当している部分しか関ることができないし、関わろうとしないため、知恵を絞れば実現できる要望に対しても「できません」という回答をしてしまいがちです。計画全体を見渡せば問題を解決するためのアイデアや代替案が出るかもしれないのに、です。
そしておそらくは「できない」という回答にも段階があるはずです。
面倒くさいからできない
これ以上作業を増やしたくない
条件つきでならできる
本当にできない
面倒くさいから、増やしたくないからできないというのは論外として、本当にできないことは解決しようがありません。
しかし業種によっても違いますが、一般論として９割近くの事案は「条件つきでならできる」の範囲に入るのではないでしょうか。「条件つき」とは、ユーザーに手順を変えてもらったり、ソフトウェアかハードウェアの追加もしくは変更をしてもらったり、調査する時間をいただいたり、コスト面で妥協してもらったり、日程的にずらしてもらったりといった調整で妥協点を探り、問題を解決するということです。
そのためには、お客さまの要望をより理解するために担当者や仕事を取ってきた営業の方と問題解決の方法についてよく話し合うことが大切です。そもそも日頃からこういった姿勢を見せ続け、努力をし続けてさえいれば、お客さまから「融通がきかない」と思われることはなくなります。
ただし、このときエンジニアは受注や予算について直接お客さまに口を出してはいけません。せめて予算管理の責任を担っている立場でなければなりません。
しかし、一般的には受注についてのいっさいの窓口というと営業の役割となっていることが多いのではないでしょうか。窓口を営業に一本化しなくては、商流の混乱を招く元になりかねません。社内のガバナンスだけではなく、お客さまにも迷惑をかけることになりますので気をつけましょう。
かろうじてできるとすれば、工数や規模についての調整までになるかと思います。直接的な金額についてではなく、金額換算のベースとなる工数や規模についてならエンジニアから口にすることが許されるケースもあるでしょう。
受動的（いわれたからやる）
営業は主体的／能動的に動きます。
主体的に動かなければ仕事を取ってくることができませんし、受注できなければ売上予測も立たず、当然予算も達成できないからです。営業というと「売上」でも「利益」でもなく、「受注」が経営層からミッションとして与えられていることが多いですよね。そのため、営業は必然的に
能動的なアクション
を取らざる得なくなります。
仮に既存顧客だけを相手にしていても同様です。定期的に収入が入ってこなくては経営が成り立ちません。あまりにも受動的で「売上はお客様しだいです」という営業では心もとないものです。経営者としてもそれでは困ることでしょう。
一方のエンジニアはというと、恐ろしく受動的です。
お客さまや上司、あるいは営業から「やって」といわれたから動くのであって、自ら勝手に動くことはあまりありません。これも契約が一役買っているというところがあります。
（請負）
第632条 請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。
契約は、プロジェクト開始前に締結するするもので、そのなかで「やること」「その範囲」「いつまでに」といったことが定められていますし、定められたこと以外を勝手にし始めた結果、定められたことが完遂できなければ債務不履行といって報酬請求権を失いかねませんし、場合によっては存在賠償請求対象ともなりかねません。
そのため、あまり能動的に動こうとしない上司やプロジェクトマネージャーというのも多いことでしょう。そうした人たちを頭に据えてプロジェクトチームがあるわけですから、頭の日ごろからのアクションを見ていると、その下で活動するエンジニアたちも受動的になっていってしまうのは、やむを得ないと感じることでしょう。
しかし、集団活動内部においてもこのような姿勢で仕事をしていると、自分の担当した業務にしか関わろうとしない姿勢につながっていきます。そうすると、その活動は集団活動やチーム活動とは呼べず、ただの烏合の衆となってしまいかねないリスクが生じます。
さらに、「まかされたからやる」という認識だと被害者意識を持ってしまうかのうせいがでてきます。
「そういわれたからやっただけ」
「（間違っていても）自分は悪くない」
という姿勢や根性が浸み込んでいきます。やらされ仕事と感じてしまうのです。
エンジニアが主体的に行動するためには、お客さまに対して単純に「どうしますか？」と判断を丸投げする（オープンクエスチョン）のではなく、「手段はＡ・Ｂ・Ｃと３通りありますが、現状を考えるとＢが理想です」というように提案するよう促す（クローズドクエスチョン）ようにすればいいのです。
このように、自身の担当範囲を超えてできるかぎりシステムの全体像を把握する努力や相手のことを考え続け最適解を模索する姿勢を続けていると、営業の人間にはできないような専門性を有しつつもお客さまにとって有意義な提案をすることができ、信頼を得ることができるようになるのです。
最後に
ここまでの話をわかりやすくまとめると、エンジニアがお客さまからの評価を得るためには、
ＩＴに関する知識のない相手にもわかっていただけるような説明を心がける
簡単に「できない」という結論を出さず、お客さまにとって本当に必要な価値を提供するために知恵を絞る
「やらされ仕事」という意識を捨てて、必要なときは自ら提案する
という３つの要素をクリアすることが必要だということがわかります。
このように、お客さまから見たマイナスイメージを解消すれば、お客さまから求められる存在になることができることでしょう。
②などは、私が新人教育などでも再三説明してきたことでもあります。
「NO」を安易に言ってしまう人間は信頼されません。「条件付きYES」だけで大抵は乗り切れるはずなのに、その努力もしないで条件を模索もせず安直に「NO」としか言えない人には重要な仕事は任せることができません。
かと言って、無条件に「YES」と言う人も実は信用なりません。ちょっと頭のいい人であれば「どうやったら実現できるのか」心配になって聞きます。
通常、常に何かしらの仕事を持っているはずなわけですから、何かしら作業を頼むのであればかならず既存業務との折り合いが必要になってきます。逆に仕事を持っていないのであれば「それほど周囲から信用されていないのか」「それほど能力が無いのか」概ねこの２択が懸念されるため、あまり頼みたくありませんよね。
仮に「ちょうどキリがいいところなんで」と言うラッキーな状況で、頼みたい相手が優秀な人だというのであれば「どうやったら実現できるのか？」と聞いた際に即答で返ってくることでしょう。無条件と言うのはそれほどとんでもないことなのです。
もちろん、無条件で「NO」と言うのはもっと言語道断で、本来サラリーマンであれば存在しない言葉です。労働の対価によって賃金を受け取る以上、上司や顧客からの依頼、要望を無条件で「NO」と言うなんてこと、既に賃金をもらう資格を放棄しているとしか思えません。
理由もなく、無条件に「NO」と言うその背景には
やりたくない
という個人的感情しかないからです。
仮に、
「やったことないからできません」であっても、
「教えてもらえればできます(条件付きYES)」にできますし、
「忙しいからできません」であっても、
「日程調整させていただければできます(条件付きYES)」にできます。
「環境がないからできません」であっても、
「環境さえ用意していただけるならできます(条件付きYES)」にできます。
しかし、「条件付きYES」を模索することなく無条件で「NO」を言ってしまうということは、どんなにきれいに言い訳したとしても要するにやりたくないという気持ちをオブラートに包んだ姿にしかなりません。
「条件付きYES」は裏を返せば、「条件付きNO」と言うこともできます。
ビジネスは常にこの選択肢しかありません。
「条件さえ満たしてくれればYESだけど、
条件を満たせないってことは、不可能に挑めってことだから当然NOでいいよね？」
つまりはそう言っているということなのです。
お客さまにとっても、私たちにとっても、一方的に押し付けることなく受動的にもならず、主体的過ぎることもない、相互に譲り合いができる最もビジネスらしいビジネスの姿、それが「条件付きYES」です。
これなら条件を満たせない側に責任が移譲され、「NO」を言うことなく満たせない側が「諦めてくれる」という図式が成立します。
そもそも、見積書１つとっても「条件付きYES」の集大成でしかありません。
見積書は
「この提示額、このスコープ(範囲)、この前提条件を満たしていただけるなら、
受注することができますよ」
という提案資料です。お客さまは「条件をすべて満たす」という誓約の代わりに注文します。そうして企業は注文書を受領した時から『プロジェクト』として活動することになるわけです（たまに注文書もないまま仕事を進めたり、見積書を形骸化させたまま案件を進めたりすることがありますが、それによってトラブルや問題が発生しやすいのはYESと言うための「条件」と「制約」を一切考えないまま… つまりは無計画／無策のまま進めようとしているからに他なりません。見積書や注文書を取り交わすという行為をただの面倒で形式的な作業だと思っている人は、いま一度見直すといいでしょう）。
ビジネスは原則としてすべて「条件付きYES」で成り立つ世界であるにも関わらず、それを理解しないで安易に「NO」を言ってしまうこと自体が、お客さまからみたエンジニア一人ひとりに対する評価を下げる要因になってしまっているのです。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。