今回は私がエンジニアとして評価を頂けるようになった経緯について書きます。
昨今評判がよくないSESが主戦場だった私も一定の評価を得ることができた方法を伝えて、
今SESで頑張っている人やエンジニアを目指している人の励みや参考になればと思います。
私について
私はいま大阪でソフトウェア開発の会社を経営しております。
現役でエンジニアもやりつつ経営もやっているという状況です。
エンジニア歴は16年ぐらいで主にJavaでの開発を中心に行ってきました。
エンジニアには簡単になれる？
私は誰もがシステムエンジニアになれると思いますがどれぐらいの期間でどのぐらいの能力が得られるかについては個人差も大きいですしかなりの努力も必要だと思います。
半年や1年で高収入を得るようになったと言う人もいますが、私は3年ぐらいしてやっと一定の評価を頂けるようになったと感じました。それまでは絶対やめてやると思いながら毎日仕事していました。
もちろんすごいエンジニアはいて1～2年でとんでもない成長を遂げる人もいますが、1～2年ではまだまだ独り立ちできないように見える人がほとんどです。エンジニアになって1年で独り立ちできていると皆が認める人がもし近くにいらっしゃるならその人は並々ならぬ努力をした人だと思っていいと思います。
具体的になにをしたのか
私の経験をもとに3つにまとめてみました。
- 標準化チームに入る
- 人の世話役を進んでやる
- プロジェクト管理を学ぶ
1. 標準化チームに入ること
標準化チームとは
複数人でシステムを開発するときに「どういうふうに作りましょうね」と認識を合わせるための決め事をするのですが、
その決め事をするにはすごい労力がかかるのでチームが結成されたりします。
プロジェクトにもよりますが呼び名や作業範囲は多少異なる場合があります。
呼び名は「標準化チーム」とか「基盤チーム」とか「共通化チーム」って呼ばれたりします。
仕事の内容は開発者のみんながどう作ればいいかを検討したり検証することです。
開発者がそれぞれ思い思いの作りをすると効率も悪ければ保守性もよくありません。
そこで作り方を決めたり先に調査したりして各開発者が躓かないようにするわけです。
作業例
- UIを定義してシステム全体の統一性をはかる
- 利用技術の検討と決定、またその利用方法をまとめる
- 各開発者が調べなくてもいいようにする
- 設計書のフォーマットを検討して各開発者に配布する
- 効率的に開発を進められる方法の検討
細かくはこんなことも
- アプリケーションのレイヤー構成を決める
- アスペクト指向で述べられる「横断的関心事」の抽出
- 各開発者が気にしなくても自動的にログ出力される仕組みを設計・開発
- ソースコード管理のためにバージョン管理サーバを立てる
- リリース運用を検討
など
狭き門
9割の開発者はこういうチームやこういう役割をしている人たちが決定した事項や調査結果をもとに開発しているので、設計書に基づいてひたすらコードを書くことに注力することになります。もちろんそれはそれで大事なのですが、技術を効率よく伸ばすならこのような役割になることが近道のひとつだと思います。
2. 人の世話役を進んでやること
実は、標準化チームなど技術色の濃いチームに配属されたりそういう役割をもらうことはかなり幸運なことです。
先程お伝えしたように9割の人はそういう役割ではないからです。
ではどうしたらそういう役割をもらえるかというと、
「人の世話役を進んでやること」だと思います。
例）
- 誰かが不具合で悩んでいたら一緒に原因に考えたり少しググってみて自分なりの解決方法を調べて伝えてあげる
- IDEなどのツールの使い方で困っている人がいたら知っている範囲でもいいから教えてあげたりする
可能ならチーム全体として改善した方がいいと思われる運用のことを思いついたらリーダーに提案してみるなどもいいと思います。
自分の仕事が少し早く終わった時は他の人の仕事を自発的にもらってあげるのもいいと思います。ただ、その場合は作業を管理しているリーダーなどの了承を得てからにしましょう。
自分の担当分の仕事もあるのでかなり大変ですが、こういう意識で仕事している人と自分の担当分さえ終わればいいという人とでは経験値が全然違います。
忙しいよ
忙しいと自分の仕事もなかなかこなせないということもあると思いますので、まず合間に他の人に声をかけることからはじめるといいと思います。
そうすると他の人が今やっている作業のことや直面している問題などを話してくれると思います。そこから相手がどんなことをしているのかとかどんなことに困っているのか少しずつ把握できますし、よく話しかけていると自分が困ったときも他の人が手を差し伸べてくれると思います。
みんな忙しそう
昼休みになったタイミングや定時になったタイミングなら話しかけやすいと思います。ぜひ「お疲れ様でした」だけじゃなくて「作業は順調ですか？」とか聞いてみてください。
チーム内技術担当もアリ！
標準化などのチームではなくとも現在のチーム内の技術担当になることがあります。
標準化などのチームで決めたことをチーム内に啓蒙する役割だったりチーム内の問題発生時の相談役になれるのです。
このような立場を経験しながら技術どっぷりのチームに入ることを目指しましょう。
3. プロジェクト管理を学ぶこと
設計やコーディングだけが技術ではない
これまでの方法がなかなか実らないとかそもそもチャンスがないという方は
プロジェクト管理について学ぶという方法もあります。
開発プロセス
プロジェクト管理を学ぶうえで必ず出てくる言葉が「開発プロセス」です。
ウォーターフォールやアジャイルに代表されるシステム開発の進め方のことです。
まずは周りに関心を持つことから
開発プロセスもいいのですが、プロジェクトの進め方は型にはまったやり方だけではないと思います。
設計やコーディングだけではなく人がどう動いていてどういうところに問題があってこうすれば少しよくなりそうなどと
考えたりさらにそれを提案できることが大事だと思います。
技術は真面目にやっていれば一定のレベルまでみんな到達しますが、
プロジェクトがうまくいかないほとんどの原因は人の問題にあると思います。
- 話したことが伝わらない
- 遅れているけど報告しない
- 誰かさんが気に入らない
「プログラムは裏切らないけど、人は期待を裏切る」ものですよね。
だからこそ少しずつ周りの人に関心を持ってほしいと思います。
技術力がある人の方がむしろ人に冷たくしたり厳しくあたったりする傾向があると感じます。
問題は問題として捉えて「人のせい」ではなく「仕組みを改善」するようにしましょう。
私の体験
100人ぐらいのプロジェクトで30人ぐらいのチームにいたときに、チームの管理メンバーがメンバーにうまく作業を振れない状況を見たとき、チームを数人のサブチームに分けて各サブチームに「サブリーダ」という役割をつくることで各機能をサブリーダが責任をもってメンバーに指示を出すことを提案をしたことがあります。結果としてサブリーダの責任感も向上しサブリーダたちもサブチーム内の信頼も得られよい体制になりました。
私はそのとき、いち外注の一人という立場でしたが発言力のある人にその提案をしチームリーダたちの会議に参加して提案する機会を得ることができました。
開発プロセスの勉強
開発プロセスもいろいろありますが、ウォーターフォールとアジャイル開発を中心に書籍で勉強して、プロトタイプ型など別の方法論をインターネットで調べてみるというのがおすすめです。
ちなみに私はプロジェクト参画のときは顔合わせなどで必ず「開発プロセスはなにを採用していますか」という質問をするようにしています。
あえてこのような質問をすることで管理意識があることをアピールできますし、相手の返答に答えられるだけの勉強を前もってやることに繋がると思います。
まとめ
高収入までの過程
人の世話役をする → プロジェクト管理を学ぶ → 標準化チームなど技術職の濃い役割を狙う
という順序で頑張ってみましょう。
いい意味での「変態」を目指しましょう
一度標準化チームなどの経歴がつくとびっくりするぐらいそういう仕事ばかり話が舞い込んできます。
なぜかというと常にやったことない技術を調査したり人にあまり聞けない仕事なので大変なのも確かだからです。ほとんどの人が進んでやりたがらないのが実情です。だからこそ価値があり少数のそういうことを喜んでやる「いい意味での変態さん」が評価を得るんです。
おまけ
悲しい点もあります。
こういう技術色の濃いチームにはほぼ女性がいません。
エンジニア歴16年ぐらいの半分ぐらいはそういうチームにいたのですが、チームに女性がいたのは1～2人だったと思います。
各画面や機能を担当するチームにいるときはもちろん女性もいらっしゃいますけどね。
これからどんどん女性にも活躍してほしいと願います。
今でも女性がいるチームを作ることが私の夢です。（笑）
高単価の人は満了になりやすいときがある
プロジェクトの予算の関係上、高単価のエンジニアから満了になることもあります。
さいごに
単価は営業力や地域やプロジェクトの事情など色々影響しますが
エンジニアとしての価値を上げるひとつの参考になれば幸いです。