SIer では思考停止で PM になるよりも、システムアーキテクトのポジションを目指した方がいい、というツイートを見かけた。
SIerならPM目指すよりシステムの全体構成などを検討するシステムアーキテクチャのポジションを目指した方が絶対にいい。
— にむ|SIer→ITコンサル (@nimu_normalSE) May 24, 2023
流れに身を任せて、SIerだからPM!というキャリアを選ばない方がいい。
思考停止で PM になるよりもアーキテクトの経験を積んだほうがいい、というのは全面的に同意する。その通りだ。
一方で、「実際に経験が積めるのか?」というと、「運次第」としか言いようがない。
ツイ主にも私にもバイアスがかかっているので、読者の人生のアテにはならないかもしれないが、私の目線で「アーキテクトという選択肢を取りうるかどうか」を論じていく。
運用・保守プロジェクトにアサインされた場合
SIer では「どんな仕事をするか」を選べない。少なくとも新卒で入社した場合は、人事が適当にアサイン先を決めていくので、「こんな業務をやりたい」の希望が通る確率は低い。 大学で情報工学を専攻していて、その専門性を活かした部署に配属される可能性もあるかもしれないが、基本は人事次第といったところだろう。
SIer の業務で多くの人がアサインされるのは「既に稼働している大規模システムの運用・保守」である。
運用・保守の担当者は、動いているシステムが正常に動作するように監視したり、メンテナンスしたり、お客様の要望に応じて機能追加を行っていく。
運用・保守を行うチームにおける「プロジェクト」とは、「◯◯ 機能の追加対応」であったり、「◯◯ データの洗い替え」であったり、大きなものだと「◯◯ の基盤更改」のようなものがある。
それに加えて、システムコールの対応やデータメンテナンスが入ってくるのが主だ。
そんな中で、「システム全体の構成」を考える機会があるか?と言われると「それほど多くない」というのが実情だろう。
新規に構築するのではなく、そもそもアサインされたときには既に動いているからである。
といっても、「今あるシステムに加えて、新しいサブシステムを構築する」みたいなプロジェクトが生まれることもある。サブシステムの構築では、アーキテクチャを考える機会があるかもしれない。 だがそこでも新たな問題が発生する。
PM や重鎮を押しのけてアーキテクチャを考える機会がない
「システムアーキテクチャを考える方向にシフトする」というと、「自分がやりたいと考えればシフトしていける」という風に考えがちだが、実際は難しいだろう。
私が知る限り、どのプロジェクトにも PM と重鎮がいる。 重鎮とは、システムの開発当初から開発を主に担ってきた「協力会社」の凄腕である。
SIer のプロジェクトでは、PM に権力が集中している。 決してフラットな組織ではない。
「何ができるか」とか「何を言うか」よりも「誰が」がいちばん重要なのだ。
システムアーキテクチャの設計は、「PM が、既存のシステムを参考にして」行うケースが圧倒的に多い。
システム設計の自由度は低く、基本的には「既存を参考にする」ように言われる。 フレームワークの選定などの自由度もなく、社内でしか使われていないフレームワークの利用を半強制される。
そもそもデプロイ先のサーバがガチガチにインターネットから遮断された環境なので、かなりの制約がある状態で設計を考えなければならない。
さらには、どのプロジェクトにも必ず重鎮がいて、そういう人を押しのけて自分が主担当になるには、相当の信頼を勝ち取らなければならない。 無理とは言わないが、かなりの時間がかかるのは間違いない。
まぁ、信頼を勝ち取らなければならないのはどの会社でも一緒である。
SIer でミッションクリティカルなシステム開発経験を積む
SIer でシステム開発を行うメリットとしては、「絶対に落とせないシステム」の開発経験が積める点にある。 また、顧客は基本的に既に存在している状態から始めるので、「最初からたくさんのお客様が使う」システムを作る点も、ウェブとは異なっている。 顧客がいないとシステム開発が始まらない、ともいえる。
耐障害性を考慮して、遅延なく正しく動作するシステムを作る経験は貴重である。
SIer でうまいこと「システムアーキテクト」としてのポジションを勝ち得たならば、他では得難い良い経験を積み重ねていけるに違いない。 仕事自体も楽しいと思う。やりがいもあるだろう。
ただし、「システムアーキテクト」的なポジションを得られる人はほとんどいないし、プロジェクトのめぐり合わせによる運の要素も強い。
自分の意志だけではどうしようもなく、時間もかかるのは間違いない。
これも他の会社でも一緒だが、SIer だと
- ピラミッド型の構造
- プロパーに設計経験が求められないケースが多い
- 前例踏襲の強力な圧力
などがあり、アーキテクトとしての地位を勝ち取るのが難しい印象がある。
プロジェクトが発足したら、「アーキテクチャの設計ができる部署のあの人に頼もう!」という流れになりがちで、そもそもチャンス自体回ってこないケースも多い。
SIer の「運用・保守」は経験としては無意味
ただし、「経験」といっても、単純作業で運用・保守しているだけでは何の役にも立たない。 SIer での「運用・保守」は時間を垂れ流して給料に変えるだけの単純作業の繰り返しである。
「どんな仕事にも意味がある。意味が見出だせないのはお前が怠惰だからだ」などと上から目線で言う人もいるだろうが、馬鹿なので無視していい。 SIer の「運用・保守」に意味などない。誰かがやらなければいけない仕事ではあるが、キャリアとしては無価値なので、自分がやる必要はないだろう。
動いているシステムから設計を学べるのでは?と思うかもしれないが、動いているものを眺めるよりも、自分で作って動かす方が 100 倍意味のある経験になる。
「お勉強しました!今のシステムは設計書によるとこう動いているはずなんです!」
だと他所で活かせないのだ。実際に手を動かして、作ってみる経験がないと正しく理解もできないし、自信も持てないだろう。
手を挙げればチャンスはあるのか?
口を開けて待っていても何も得られない、というのはその通りである。 信頼を勝ち取った上で、「やらせてください!」といえば「やってみろ」と言ってくれる上司は多いような印象がある。
色々と制約も多く、本質的でない作業に忙殺されがちだが、積極性と覚悟があれば、SIer でもやれなくはない。 ただし、システムアーキテクトに限らず、SIer でソフトウェアエンジニアとしての経験を積むのは下りのエスカレーターを逆走するようなもので、余計な努力をしなければいけなくなるので、個人的にはさっさとソフトウェア開発ができる企業で働くのをおすすめしたい。
年収を上げたいなら転職ドラフトが断然おすすめできるので、登録して企業にアプローチしてみてはどうだろうか。