SIerで幸せな技術キャリアを築くために

この記事はNTTコムウェア Advent Calendar 2021 20日目の記事です。

NTTコムウェアの古西です。AI・データサイエンス推進室で技術マネージャをしています。

システムインテグレーター、略してSIerは、顧客のためにITシステムやサービス・ソリューション・プロダクトを開発・運用する会社です。一部自社サービスがあるものの、特定の顧客企業に対してシステムを提供することが多いです。

ネット上では 「SIerはオワコン」¹と言われることもありますが、私自身は入社のときに 「人と技術を仲介する仕事がしたい」 と言って仕事をしはじめてから約25年間、SIerで顧客や自社の人と技術を仲介する仕事をしてきました。私がこれまでの経験から 「SIerで幸せな技術キャリア」 を築くために意識したほうがいいと思うことを、若年層とベテラン層にわけて3つずつ、書いておこうと思います。

• 若年層(20代～30代前半)

  • 会社の上位層に技術者・エンジニアとしての個人を認知される
  • 技術のわからない人に自分の技術成果を伝える方法を獲得する
  • 目の前の仕事で必要な技術に取り組むとともに、ITの世界でよく使われる技術を抑えておく

• ベテラン層(30代後半以降)

  • 手を動かすことを手放さない
  • 長期スパンでは技術トレンドが変わることに柔軟に対応する
  • 自分の価値がどこにあるのかを自問自答し続ける

若年層（20代～30代前半）

会社の上位層（部長職以上）に技術者・エンジニアとしての個人を認知される

若い頃にピンと来ていなかったのですが、今思えば、若いうちに 「技術の人」 のレッテルを張られるのは自分のキャリアにおいていろんな意味で重要でした。

ひとくちにSIerの仕事といっても、業務要件定義や業務フロー設計など、IT技術そのもの実装からは比較的遠いものや、営業や経理、人事、経営企画など、会社の機能としては必要ではあるものの技術職でない仕事もあります。技術者・エンジニアのキャリアを歩もうとすると「コーディング・実装などのIT技術」に近い仕事から離れずに続けてキャリアを積む必要があります。会社内でのキャリアトラックが明確に業務トラックと専門職トラックにわかれていれば専門職トラックに乗ればいいのですが、明確に分かれていない場合、案件アサインや人事のアヤで、技術から遠いところの仕事をする場合もあります。

そうならないためにも 「この人は技術がやりたいんだな/技術が得意なんだな」 と仕事をアサインする会社の上位層に、認知される必要があります。積極的に手を挙げて、技術仕事をとりにいったり、周りが知らないことも自分で調べて薦めたりすることで、認知度があがります。そうすることで、異動があっても、技術の人材として異動先となる部署やポストが考慮されますし、大きなSIerではたいてい技術支援・技術開発の総本山のような部署もあり、そのような部署に異動することで、より技術に近い仕事をすることができます。パーソナルブランディングを意識することは非常に大切だと思います。

なお、技術キャリアのちょっとした注意点として 「顧客に個人が評価されて継続契約の要望を受ける」 というのがあります²。顧客に技術者としての個人を認知・評価され、次の契約でも継続の要望をうけると、エンジニア冥利を感じてうれしいものです。しかしながら、短期的には顧客に気に入られ有効ではあるものの、長期的にはその仕事から放してもらえず、個人のキャリア形成の支障になる場合があります³。客先常駐などでは特に自分の担当する仕事や技術を選べないため 「今後のためにも担当をかわりたい」 とおもったら適切に上司に相談をし、今後のキャリアについてコミュニケーションをはかっておくのがよいと思います⁴。

技術のわからない人に自分の技術成果を伝える方法を獲得する（自分が翻訳できる、または翻訳者を確保する）

技術が得意であっても、SIerの顧客が技術が得意であることはごくまれです⁵。顧客に成果が伝わらなくては、対価をはらっていただけません。技術が得意でない、わからない人にも、自分の技術成果をわかりやすく伝える術（翻訳術）を身に着けておく必要があります。たまに、技術的には圧倒的なスキルを持ちながら、他人に伝えることは得意でない方がいらっしゃいます⁶。その場合は、身近に自分の技術成果を翻訳してくれる協力者が必要になります。自分の価値観に閉じこもらず、顧客に伝わる方法はどうすればいいのか、常に考えて試行錯誤をしてみる必要があります。

なお、専門的な知識になればなるほど、コミュニケーションコストは高くなるため、コミュニケーションコストを下げる努力をする必要があります。ビジネス上でも注目されている技術の類、例えば、 AIやセキュリティなど、経営・業務層とエンジニアで捉え方や見ている世界が違い、コミュニケーションが難しいものもあります⁷。ビジネスの現場に実装しているところは、コミュニケーションコストを下げる努力をしていると思っています⁸。

目の前の仕事で必要な技術に取り組むとともに、ITの世界でよく使われる技術を抑えておく(プログラミング、OS、Web(MVC)フレームワーク、RDBMS、ネットワーク、クラウド、等)

かつて、私が若い頃サーバ・ネットワークエンジニアとしてキャリアを積もうとしていたときに、上司⁹に 「データストアのない業務システムはないよ」 と言われて、RDBMSを勉強するようにアドバイスされました。自分の担当範囲以外のよく使われる技術は、広く抑えておいたほうが技術キャリアに幅がでます。その際に、長く使える汎化された技術知識と、製品が変わったら使えない知識をわけて考える必要があると思います。情報処理技術者試験やベンダー資格の勉強も有効でしょう。OSSなどであれば、自分で動かしてみることもいいと思いますし、最近はオンライン学習もよいと思います。

余談ですが、後年OpenStackのSEだった自分にいきなり 「Ruby on Rails開発のスクラムマスターをやって！」 と言われても、おろおろしつつもなんとかやってみる心とスキルの準備が必要です¹⁰。顧客もSIer自身も無茶ぶりは多いものです。

ベテラン層（30代後半以降）

手を動かすことを手放さない（あきらめない）

30代も半ばを過ぎると、職場ではリーダー職や管理職であったり、家庭をもったりと技術スキルを磨く時間が限られがちです。プログラミングや実装等の実務で使う技術から離れると、エンジニアとしての現場感覚が失われます。また、異動に伴いこれまでと全然違う技術が求められる場合もあり、また一から技術習得するのもなかなかしんどいものがあります。

ただ、エンジニアとしての強みは事実に基づく根拠説明、方針・動くものとしての成果の積み上げが重要になりますので、土地勘が狂わない程度に少しでも実装部分に関わっておいたほうがいい と思います。極論、チュートリアルをやるだけでも、顧客への説得力が違いますし、若手エンジニアとのコミュニケーションが円滑になると思います。まだまだエンジニアの少ないAIの分野など、タイタニック号の生存者予測やCIFAR-10の画像クラス分類等、初心者向けチュートリアルをやってみると何をやっているのかわかると思います¹¹。これまで、私がお世話になった凄い技術者の方は、管理職の仕事をしつつも、どこかで技術実装をさわっていました¹²。

RailsでのWebシステム開発のプロジェクトマネージャだった自分に、いきなりAIの技術マネージャやってといわれたときは、「またまた、そんな無茶ぶりで大丈夫かいな」 と思ったものですが、まずははじめて触るJupyter NotebookでNumpy/Pandas/Matplotlibでぽちぽちするところから始めてみました¹³。今は書籍やオンライン教材も充実しているので、とっかかりのハードルは小さくなっていると思います。1年で技術のキャッチアップ、3年で他者へのアドバイスや指導ができるぐらいになるのが理想ではないかと思います。¹⁴

長期スパン（10年単位）では技術トレンドが変わることに柔軟に対応する

20代から仕事を始めて、60代まで仕事するとざっと40年ほど仕事をすることになります。ITの世界は動きが早く、40年のキャリアのうちに新しい技術が生まれます。ディープラーニングが注目を浴びたのが2012年、Dockerコンテナが生まれたのが2013年、比較的新しいもので、今40代の人が仕事をしだした頃にはなかったものです。

一つの技術にこだわりすぎると、トレンドが変わったときに技術スキルが負債化する可能性があります。また、過去の経験で身に着けたことが時代が変わり世の中の考え方がかわることもあります。例えば、開発と運用の分離原則からDevOpsへの転換など、求められる考え方がかわることもあります。ウォーターフォール思考だった私にいきなりスクラムやカンバン方式と言ったアジャイル開発の洗礼をあびたときも 「なんだこれは」 と思ったものです¹⁵。

自分の考え方が狭い世界に閉じこもって固くなっていないかチェックするためにも、社内外の勉強会やセミナーなどで自分以外のエンジニアと交流して、気づきを得ることは有効だと思います。また、自分の技術スキルを負債化しないために、製品よって変わるコマンドや構文よりも、Web APIやSQLのようなよりプリミティブな技術、汎用化して覚えることができる技術を抑えておくとよいかと思います。また、実装やシステム方式設計よりも一段上流の、非機能要件定義やモデリング・アーキテクチャ設計などのスキルを磨くのもスキルが陳腐化しにくいです¹⁶。提案や要件定義の段階で論理設計、物理実装がイメージわくと、後の工程の設計や実装への筋道ができるため開発がスムーズに進むと思います。脱線ついでに付け加えると、上流下流、技術レイヤ、抽象的な要望から具体的な実装への階段の上り下りができる思考が身についていると、相手が伝えたいことにすぐにフィットする会話ができるようになります。

私が駆け出しのネットワークエンジニアだった頃に、ベテランSEでも新しい技術の勉強が必要だと実感した経験があります。IBMホスト(メインフレーム)を、TCP/IPネットワークに接続する仕事だったのですが、IBMホストのTCP/IPスタックであるTCPIP for MVSをつかい、Ciscoルータにホスト接続モジュールを積んでホストと接続するというものでした。見た目50歳代くらいのIBMホストのSEの方が、おもむろにIPルーティング設計を説明しだしたとき 「この人の若かった時はSNAの時代で、TCP/IPはなかっただろうにこの年でも勉強されているんだ」 と今から思うと少し失礼な感動を覚えました¹⁷。この仕事をやる以上、いくつになっても新しい技術の勉強が必要だと思っています。

自分の価値がどこにあるのかを自問自答し続ける

SIerでの技術キャリアをカテゴリ分けしようとすると、それこそいくらでも様々な軸で分けられるとは思いますが、例えば、次の3つにわけることもできるのではないかと思います。

• マネージャコース
  • プロジェクトマネージャ、プロダクトマネージャ、エンジニアリングマネージャ、等
  • プロジェクトやプロダクトの舵取り、進捗管理、課題管理等を行う。
  • 日本企業の昇進・昇格の仕組み上、リーダー、管理職トラックと親和性があり、SIerでもよく見られるキャリアである。
  • 技術以外のピープルマネジメントや予算管理などの知識も幅広く必要。興味が持てるか問題がある。
  • マネージャ特化だと技術から遠くなりがち。
• 専門エンジニアコース
  • ソフトウェアアーキテクト、DBエンジニア、ネットワークエンジニア、機械学習エンジニア、等
  • 技術を極める、職場の後輩を育成する、技術トラブル発生時等のいざというときに頼られる。
  • 技術が時代遅れになったときに負債化しないよう、最新技術への追随が必要。
  • 日本企業だと専門エンジニアのまま昇進・昇格するキャリアトラックが整備されていることは少ない。今後は変わることに期待。
  • 身近ではこのコースの人がわりといらっしゃいます。技術が好きな人が多く、楽しそう。
• 技術コンサルタントコース
  • ITコンサルタント、ソリューション営業、等
  • 顧客に対して技術コンサルやソリューション提案をする。橋渡し役。
  • 顧客に分かりやすく説明するスキルが必要。
  • トークスキル、コンサルスキルに特化した 「おしゃべり課題解決コンサルおじさん」 でよいか、技術キャリアでは迷うときがある。¹⁸
  • なんとなくですが、最初からこのコースを目指す人は少なくて 「結果的にそうなってしまった」 人が多い気がします。¹⁹

実際は、このどれか、というよりも、この3つの軸のレベルが混ざっていて「どちらかと言えばマネージャタイプ」「どちらかと言えば専門エンジニアと技術コンサルタントの中間」といった感じではないでしょうか。人間、誰しも得意・不得意があり、自分が一番得意で価値発揮できる仕事でキャリアを積んでいくのが幸せないのではないかと思っています。技術が好きで技術を極めたい、と思う人がいれば、エンジニアを取りまとめてゴールに導くのも、顧客と技術の橋渡しをするのも立派なキャリアです。

私自身は、技術は幅広く携わってきたものの、つよつよエンジニア²⁰の人からみればどれもこれも中途半端なので全然専門エンジニアではないのですが、いろんな顧客、プロジェクト、技術を経験してきたおかげで、「マネージャタイプ」と「技術コンサルタントタイプ」の中間ぐらいではないかと勝手に思っています。これまでの上司の温かく厳しい指導や、顧客からの感謝の言葉、同僚や後輩との議論など、すべてが今の私を作り上げています²¹。

エンジニアとして「なりたい自分になる」

エンジニアがビジネスリーダーをめざすための10の法則に

• 真摯に相手の話を聴き、本質的な課題を引き出し、プロフェッショナルとして解決策を導出し、相手にわかりやすく説明し、相手を突き動かしていくことが、真の問題解決

という言葉が出てきますが、私はこの考えに共感します。また、どこで読んだのか忘れたので参考文献や引用を引けないのですが、

• エンジニアに対して 「こうしてみてはどうだろう」「それは外に助けを頼もう」 といったアドバイスをするにはエンジニアとしての知識が必要。
• 顧客からの要望・問い合わせに対してその場で 「できる」「できない」「時間をください」 と言ったこともエンジニアだから答えられる。

もそのとおりと思っています。

今も仕事では身の回りにたくさんのエンジニアの方がいます。当然、ここには書いていないしんどい仕事や理想論だけではない世界もあります。私自身が不安ながらも幸せなキャリアを歩みたかったように、皆さんにも今後幸せなキャリアを歩んで欲しいと願っています。IT技術の進歩は早く、トレンドもどんどん変わるとは思いますが、それでも人を幸せにして自分も幸せになることが理想なのは変わらないと思います。ITはより社会生活に不可欠なものになり、エンジニアは社会生活を支える人だと思います。

「人と技術の仲介をしたい」 と言って始めたキャリアですが、幸せなことに、私はこれまでずっとそこから外れることなく、人と技術の仲介をしてきました。それは私の心の中で小さな誇りとなり、明日への仕事の原動力になっています。

参考文献

エンジニアのキャリア論の書籍はいろいろありますが、私が読んだもので代表的なものを3冊上げておきます。

• エンジニアのためのマネジメントキャリアパス――テックリードからCTOまでマネジメントスキル向上ガイド(Camille Fournier　著、武舎 広幸、武舎 るみ　訳、及川 卓也　まえがき、オライリー・ジャパン)
  • 海外のサービス会社を事例に、エンジニアからのマネジメントキャリアパスを書いています。日本でも十分参考になる内容だと思います。
• エンジニアがビジネスリーダーをめざすための10の法則 (ベイカレント・コンサルティング 著、翔泳社)
  • 顧客に評価されるエンジニアの行動を、10件のケースごとに良い例、悪い例の比較で示しています。少し極端な例とも思えますが、顧客側からどう見えるか、ビジネスシーンでの価値発揮という点で気づきがあると思います。
• 完全SIer脱出マニュアル (池上純平 著、C&R研究所)
  • SIerに勤めていて、転職を考えない人は正直いないと思います。刺激的なタイトルですが、すべてのエンジニアにSIerからの転職を進めているわけでは無く、エンジニアの就業環境やキャリア論について真っ当なことが書いてあります。

---

※ 文中に記載されている会社名、商品名、製品名は各社の商標または登録商標です。
2024/12 Qiita Markdownパーサー変更に伴う表示崩れを修正

1. 企業は時代や顧客の求めに応じて事業形態を変えていく必要があるので、SIerがオワコンと言われる理由の分析と、企業としてどのように変化していくべきなのかは今後の事業戦略を考える上で大変重要です。というか、多かれ少なかれ、それが仕事そのものです。 ↩

2. 顧客との請負契約や準委任契約では管理責任者名のみ取り交わすことが通常ですが、顧客が「作業者にxxさんがいるから次も頼みたい」と思うのは作業者の品質やスピードが重要なITの世界では極めて普通の感覚だと思います。少し脱線しますが厚生労働省の「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）関係疑義応答集」に最近第3集が追加され、アジャイル型開発に対応した議論が進んでおり、注目しています。なお、同第2集問13および第3集A.7の回答のように、現状でも請負契約/準委任契約で作業員を個人指名をすることは偽装請負と見なされる恐れがあります。 ↩

3. SIerは顧客からの要望に弱いです。 ↩

4. 客先常駐はエンジニアにとって、気づきと成長の宝庫です。しかしながら、2～3年と長期化すると、自社の状況がわからなくなるなど、思い悩むことも多くなります。かつての私がそうでした。 ↩

5. たまに逆に顧客が技術つよつよの現場があります。その場合は、虎の穴と思ってよろこんで鍛えられましょう。 ↩

6. 口下手だけどこの人がいないと成り立たない現場、というのは普通にあります。そういう貴重な人が埋もれない仕組みが必要だといつも思っています。 ↩

7. ディープラーニングやゼロトラスト等、バズワード化している最近の技術は、業務適用の際の導入効果、ガバナンスと利便性のトレードオフなど技術以外にも検討が必要であり、苦労することが多いです。 ↩

8. たとえば、経営・業務側が勉強する、翻訳がうまいコンサル/SEを雇う、わからなくても使えるようパッケージングする、等があるかと思います。 ↩

9. 「師匠」と呼べる上司や先輩に出会えることは技術キャリアで重要なポイントかとも思います。この時の上司は、社内からも一目置かれている技術者の方で、厳しくも優しい方でした。 ↩

10. 私はここで初めてRailsやWebフレームワークに触れたのですが、それまでMVCモデルとは何かよくわかっていませんでした。 ↩

11. 今は、KaggleやQiita等、すぐに始められるチュートリアルがたくさんある状況です。良い時代になったと思います。 ↩

12. どこにそんな時間があるんだろうとか、うまく時間作るもんだなとか、いろいろ思います。 ↩

13. 学生時代に、実験データの統計分析をしていたことが役に立ちました。また、かつてOpenStack案件に携わっていてPythonをあらかじめてかじっていたのもよかったです。昔取った杵柄、芸は身を助けます。 ↩

14. 年をとってくると、後輩からいかに上手く教えてもらえるかのスキルも重要になります。 ↩

15. その時の顧客がアジャイル開発を取り入れていたからなのですが、なぜか最初に触れたのはスクラムでなくカンバン方式でした。 ↩

16. これができる人をシステムアーキテクトやITアーキテクトと呼びますが、貴重な人材だと思います。 ↩

17. それまで高齢のITエンジニアに会ったことがなかったので、新鮮でした。最近は時代も変わり、60代後半の技術顧問やIT営業の方にお会いすることもあります。元気に活躍されていて、私も今後の理想のキャリア像の一つになっています。 ↩

18. 自分が実装も触ったことがないものをさも知っているように話することに抵抗感がなくなると、エンジニアとは呼べないと思います。 ↩

19. 「次に××の顧客に会うんだけど、話聞くだけでいいので、ちょっと同席してくれない?」と言われていたのに、当日なぜか中心で説明していたりなど。このパターン、そのまま進むには危険だなと思ったら、後で問題にならないように、議事メモを起こしてエスカレーションします。 ↩

20. スーパーエンジニアのネットスラング。一点突破型、フルスタック型などいろいろいらっしゃって、仕事や社外勉強会などでたまに出くわします。レアキャラだと思いますが、目立ちます。いろんな意味で刺激になることが多いです。 ↩

21. 恥ずかしい失敗もたくさんしてきていますが、反省はするものの、忘れるようにしています。実際忘れています。 ↩