こんにちは！
複数の億規模プロジェクトでPLやってるやまさんです！
ボクは新人時代、ポンコツエンジニアでした。
どれぐらいポンコツだったかというと…
- 簡単なプログラムなのにバグを作りこんで上司から頭を抱えられる
- 協力(下請け)会社の方から”センスないなお前”と言われる。
- 優しいで有名だったら先輩から”なんでSEになったの？”と言われる。
- 相談した同期からはなぐさめるのを通りこして半笑いされる。
技術力を身につけるために勉強もしてみたんですが、見事に挫折…
当時は本当にしどかったです。
会社に行くのに恐怖すら感じていました。
なんとか気持ちをふり会社に行っても、周囲にまったくついていけず肩身の狭い思いを数えられないほどしました。
一言でいって地獄でした。
エンジニアを辞めようかと、「会社 辞め方」でGoogle検索しいろんな転職サイトを徘徊した時期もあります。
ただ、最近ではようやく次のような感じで仕事ができるようになったんですよね。
- ボーナス評価で最高のＳ評価を６回連続で達成
- 社内で最短昇格
- 先輩後輩問わず、同僚から”頼りになる人”として認識される
- 同期の平均年収に100万以上の差つける
- etc…
その他にもありがたいことに、新しいプロジェクトが立ち上がるときには上司や同僚から声をかけてもらえたりなんてことも^^
「エンジニアは才能だ」、そう一部で言われていますが、決してそんなことはありません。
たしかに、凄腕のITスキルを身につけ活躍していくには才能が必要でしょう。
トップレベルのITスキルを身につけるのに才能が必要なのは、ボク自身、ポンコツだったので痛いほどわかります…
ですが、技術力だけがエンジニアの武器ではないんですよね。
実際、今でもボクのITスキルは平凡、もしかすると平凡以下かもしれません。
では、そんな凡人SEのやまさんがなぜボーナス評価で6回連続Ｓランク評価を達成し、最短最速で昇格することができたのか…
一言でいうと、「エンジニアとしての戦い方を変えた」からなのですが、この記事ではそのあたりのことを詳しく紹介してみたいと思います^^
この記事は次のような方に一度読んでみてほしい記事です。
- エンジニアとして活躍したいけど、イマイチ結果を残せていない
- 仕事への貢献のわりに自分の評価が低い
- プログラミングなどのIT系スキルのレベルアップに限界を感じる
- 実はプログラミングにセンスがないことに気づいてしまった
- ITの勉強がしんどくてエンジニアを辞めるか迷っている
- 正直なところ、今より出世したい/給料をたくさんもらいたい
ぜひ読んでみてください！！
Contents
凡人SEでもボーナスでS評価を得て最短最速で昇格できた理由：自分で提案できるエンジニアになったから
なぜ、たいしたITスキルを持っていないやまさんがボーナス評価を6回連続で最高ランクのS評価をもらい、さらに、同期と差をつけ最短最速で昇格できたのか…
結論から言ってしまうと、
”問題に対し解決に向けた方向性を提案する”
これができるようになったのが理由です。
というもの、解決策の方向性を示されて実際どうやったらいいのかを考えられるエンジニアは割といるんですよね。
言い換えると、こういうシステムにしたいけど、どうすれば実現できるかという視点で考えられる人は結構いるんですよ。
ですが、
- どんな仕様を持ったシステムにすればいいのか
- 実装すべき機能って何なのか
- そもそもシステムのあるべき姿って何なのか
こういったことを考えられるエンジニアはあまりいないんですよね^^;
つまり、逆に言うと、こういったことを考えて提案できるエンジニアは希少価値が高いってことです。
解決策の方向性を考えられるエンジニアはめちゃ重宝されるんですよ。
「こういった仕様が良いのではないでしょうか」
「お客さんの業務の目的や今回のプロジェクトの目的を考えると、この機能は必ず必要になります」
凡人SEのやまさんがボーナスＳ評価を6回連続で達成し、最短最速で昇格できた理由は解決策を示す提案を社内、社外問わずできるようになったからです。
これは実際の開発現場を思い出してもらえれば、思いあたるところもあるんじゃないでしょうか。
結局現場で一番困るのはどんなシステムができたらいいか分からないとき
システム開発の現場で次のような場面に出会ったことありませんか？
- お客さんが仕様を決めてくれない
- 仕様変更で前提がひっくり返される
- 方針はあるけど抽象的すぎてどんなシステムを作ればいいのか分からない
- etc…
こういった問題ってシステム開発の現場では「あるある」なんじゃないでしょうか^^;
たしかに、要件定義をはじめ、仕様を決めるのはお客さんです。
システムの仕様を決める権利はお客さんが持っていますからね。
どんなシステムを作るべきか決めてもらう必要があります。
ですが、システム仕様を決める権利をお客さんがもっていることと、実際にお客さんが仕様を決められるかは別の話…
正直なところ、「こんなシステムを作るべきだ！」って言えるお客さんはかなり珍しいです。
「いない」と言っていいぐらいに全然いません。
なので、仕様はなかなか決まりません^^;
結果、仕様が決まらないとどうなるかというと、開発スケジュールが遅延し炎上し始めます。
実際、要件定義の工程が延長して、全体スケジュールが遅れてしまっているようなプロジェクトを見たことありませんか？
要件定義工程が延長するのって、結局のところ、全体感をもって仕様をお客さんが決めきれないケースが大半なんですよね^^;
そして、延長に延長を重ねて最終的には無理やり仕様を決めます。
で、プロジェクトの後半に仕様変更の嵐…
これが炎上プロジェクトの正体です。
実はこれは数字としても結果が出ています。
問題(炎上)プロジェクトの原因のトップが「要件定義が不十分」であったため、となっていますね^^;
限られたスケジュール中、いかに高い精度でお客さんに仕様を決めてもらうか
これがプロジェクトを成功さえるための最重要ポイントです。
理想のシステムを提案できるエンジニアは貴重
でも、システムの仕様って仕様はお客さんが決めるものだよね？ エンジニア側はどうすることもできないんじゃない？
そうですよね。
ボクもシステムの仕様を決めるのはお客さんの仕事だと言いました。
実際、勝手にエンジニア側が仕様を決めて開発を始めてしまうと怒られてしまいます^^;
たしかに、エンジニアがシステム仕様を決めてしまうのはNGでしょう。
ですが、お客さんが仕様を決められるようにサポートすることはできます。
むしろ、ボクの感覚としてはシステム仕様はお客さんに決めてもらうものではなく、「仕様はお客さんに決めさせるもの」だと考えています。
正直なところ、お客さんに仕様を決めてもらうというスタンスだといいことがありません^^;
これまで紹介したように、お客さんに仕様を決めてもらうというスタンスだと
- お客さんが仕様を決めてくれなくてスケジュールが遅延する
- 仕様変更で前提がひっくり返される
- 方針はあるけど抽象的すぎて、結局どんなシステムを作ればいいのか分からない
- etc…
こういった問題がガンガン出てきてしまいますからね。
一方で、こちらから次のような提案ができればどうでしょうか。
- 今回のプロジェクトの背景や目的を考えると、システムの仕様はこうあるべきだと考えます
- こういった仕様だと、お客さんの業務や経営方針に合うのではないでしょうか
システム開発のプロジェクトで、お客さんはどんな仕様にするか決める役割を持っています。
ですが、必ずしも決められるだけの知識や能力がお客さんにあるとは限りません。
なので、お客さんがシステム仕様を決められるようにエンジニア側から提案を行うのです。
提案を行えば、状況はかなり変わりますよ。
しっかりとした理由と一緒に仕様の提案を行えば、「たしかに」と言って提案内容がそのままシステム仕様になります。
お客さんが提案仕様の理由に納得をいかない様子でしたらNGを出してきます。
ですが、NGという答えをもらうことができれば、理由を聞いてもう一度提案を行えば先に進むことができますよね。
「あーでもない、こうでもない」といって時間を浪費しスケジュールが遅延するといった状態を避けることができるんです。
さらに、提案の精度を上げることができると、開発後半での仕様変更(結果、泥沼化して炎上)も避けることができます。
なので、「提案」できるというのはエンジニアとって重要な能力なんですよね。
ではこういった提案ができるエンジニアはたくさんいるかというと…
提案ができるエンジニアはとても少ないです…
問題プロジェクトのアンケート上位に「要件定義が不十分」があがったり、「要件定義が延長してプロジェクトが遅延」するのが”あるある”な状況からも見ても、これは明らかなのではないでしょうか。
なので、逆に言うと、プロジェクト炎上を防ぐような提案ができるエンジニアというのは希少価値が高いってことになりますよね。
プロジェクトにとって、提案ができるエンジニアの存在はプロジェクトを成功させるために必要不可欠な存在なんですよ。
でも、実は提案ができると、プロジェクトがうまく進むだけではなくエンジニア個人としてもメリットがあるんです^^
提案できるようになったやまさんにおきた出来事
システム仕様を提案できると、プロジェクトの炎上を避けることができるだけでなく、エンジニア個人としてもプラスになります。
例えば、ボクは提案できるようになったことでこんなことがありました。
- ボーナス査定で6回連続Sランク(最高)評価を獲得
- 同期の中で最短最速で昇格
- 先輩後輩問わず、同僚から”頼りになる人”として認識される
- 新規プロジェクトが立ちあがるときは声をかけてもらえる(おもしろそうならそのまま参加)
- プロジェクトの炎上を防げるので平日も早めに切り上げてゆっくり休める
- もちろん、休日も家族との時間などプライベートも充実
- etc…
ボク自身なかなかのエンジニアライフをおくれているんじゃないかなと感じています^^
ちなみに昇格速度は社内最速のようでした。
というのも、ボクは大手SIerに働いているんですが、年功序列というのが残っているんですよね。
〇年以上働かないと昇格できない、みたいな感じです。
なので、上司から「社内規定で昇格させられない。すまん(だから辞めないで)」と言われ、勤務年数の規定を満たしたら即昇格しました。
ぶっちゃけると、ボクはせっかく働くならたくさん給料もらいたいと思っています ←
なので、ボーナス評価も良くなったし、昇格もできベースとなる給料もあがったので単純にうれしかったです(苦笑)
上がったボーナスや給料で次のようなこともできました。
- 前々からほしいと思っていたいいキーボード買ったり
- 最新のPCを買ったり
- 嫁さんや子どもといっしょにおいしいものも食べたり
- 友人とちょっと遊びに行ったり
- etc…
「人生、お金じゃない」なんて言いますが、給料やボーナスが上がって感じたのはお金は無いよりもあった方がいいなってことでした(苦笑)
… … …
… …
…
ちょっと話がそれましたね^^;
お金の話だけでなくて、周りからもいろいろ頼りにしてもらえたりもします。
この記事の冒頭で少し触れましたが、ボクは新人の頃、ポンコツと言われていました。
ポンコツすぎて先輩から直接「エンジニアに向いてないね」と言われましたし、
周りからも「コイツやばいわ」って思われていたと感じています。
それが今となっては先輩、同僚、後輩問わず、いろいろ頼りにしてもらえるようになりました。
頼りにしてもらえるのが認めてもらえた気がしていて、ボク自身うれしかったです^^
だって、昔は「お前センスないな」って言われていたヤツが「やまさんに頼みたい」とか「これはお前じゃないとやばいやつだ」とか言われるんですよ。
人の役に立ててる感じがしてやっぱりうれしいじゃないですか。
こういった感じで”提案”ができるようになると、プロジェクトでだけでなく個人的にもいいことがあるんですよね。
では提案できるエンジニアになるためにはどういったことができるようになれば良いのでしょうか。
- 日々勉強して最新のIT知識を身に着ける？
- 休日にプログラミングなどのスキルを磨く？
- 流行りのスクールに通って技術力を根本からたたきなおす？
すべてＮＯ(ノー)です。
提案できるエンジニアになるのに、高いレベルのIT知識はいりません。
提案できるエンジニアになるのに必要なのはビジネスの構造を理解することです。
提案できないのはビジネスの構造を理解してないから
提案できるエンジニアになるためにはビジネスの構造を知る必要があります。
ビジネスの構造というのはお客さん業務の流れのことですね。
お客さんの業務の流れは「業務フロー」という図で表現されることがあります。
具体的には次のような図ですね。
結局のところ、システムはツールなんですよ。
- 何万ものデータを集計する
- ECサイトでサイト閲覧者にモノを購入してもらう
- 企業HPで求人する
- etc…
情報革命と呼ばれる今の世の中にはいろんなシステムがあります。
ですが、システムは「素早く」「正確に」「自動で」処理するためのツールでしかありません。
システムはお客さんの業務の中に組み込まれている作業の一部っていうことですね。
なので、お客さんの業務、つまりはビジネスの構造を理解していかにシステムに作業を肩代わりしてもらうか、というのがシステム開発を行う上で重要なポイントになります。
この肩代わりしてもらう作業によって決まるのがシステム仕様ということですね。
ビジネスの構造（お客さんの業務フロー）が分かれば、実のところ「提案」というのはそれほど難しくはありません。
「今ある業務フローはこの流れになっていて、システムを入れるとこうなります。結果、お客さんにはこんなメリットがあります」
これが提案の基本の型なんですよね。
この型がしっかりしていないと、提案にならないんですよ。
交渉術とかきれいな資料の作り方とかいろんなテクニックがありますが、これは基本ができているのが大前提。
言ってみると、交渉術とかきれいな資料は見栄えの問題で提案内容という土台がしっかりしてないと意味がないってことです。
一方でこういった提案に最新技術の仕組みとかプログラミングスキルって関係あるでしょうか。
ないですよね^^;
ITの知識が必要になるのはお客さんのビジネス構造(業務フロー)を把握した後なんですよ。
- 今のお客さんの業務フローはこうなっている
- 業務フローを俯瞰してみると、この作業が負荷が高そうで規則性がありそうだ
- システム化できそうだけど、いい技術ないかな
といった感じですね。
「この作業、システム化できそうかな」とあたりを付けられる時点で周りのエンジニアとはかなり差がつきますよ。
でも、業務の流れってお客さんごとに変わらない？ 毎回勉強するのってかなり大変な気が…
たしかに、業務の流れはお客さんごとに変わります。
お客さんごとに歴史や文化がありますからね。
ですが、基本的な業務の流れ(ビジネスの構造)は同じというのをご存じでしょうか。
結局のところ、お客さんも商売をやってるんです。
当たり前ですが、システムを納品する先のお客さんも何かしらモノやサービスを売ってますよね。
お客さんが変わっても同じ商売なので基本的な流れは同じにならざるおえないです。
枝葉の部分に業界やお客さんごとに多少違いはでますが、基本的な業務フロー(ビジネス構造)は同じってことですね。
正直、業務フロー(ビジネス構造)の基本を理解しているだけでも、一般的なエンジニアとかなりの違いがでますよ。
なぜかというと、ビジネスの基本構造を理解しているということはある程度正解が分かった状態からスタートできるからです。
例えば、 ECサイトを新規開発してお客さん企業の売上向上を目指すプロジェクト を行う場合、次のような要件が出てくると思われます。
- 商品検索
- 検索結果の表示
- 商品送付先(住所情報)の入力
- 購入情報の入力
- 商品の購入
- 購入完了画面
断言しますが、この要件で設計やコーディングに進むとプロジェクト後半でほぼ確実に仕様変更が発生しますよ。
何が問題か分かりますか？
商品検索の方法が決まってないとか、クレジットカードとか〇〇Pay決済の機能が必要とか、そういった実現方法はここでは除きます。
正解は………
「購入完了画面」での”他商品の訴求”です。
Amazonでも「他のお客さんはこんな商品も買ってます」ってでますよね？
ボクがこれに気づけるのは基本的なビジネスの構造を知っているからなんですよ。
ここでのポイントは「1度商品を購入した顧客は購入したことがない顧客よりも別の商品を購入する可能性が高い」というビジネスの基本構造を知っているかどうかです。
実際、通販サイトで何か購入すると、宣伝メールや郵送でチラシのようなものが送られてきますよね。
メールやチラシがくるのも同じ理由ですよ^^
ビジネスの基本構造である「1度商品を購入した顧客は購入したことがない顧客よりも別の商品を購入する可能性が高い」このポイントを理解していれば、「購入完了画面におすすめ商品の情報を表示すればお客さんの売上UPにつながるかと思います」という提案ができるんですよね。
ぶっちゃけると、ビジネスの基本構造を理解しているかというのは才能でもなんでもなくて、「知っているか」「理解しているか」だけの話ですよ。
基本的なビジネス構造だけでも理解できるようになると、希少性は格段に上がる
エンジニアの勉強といえば、どんなことが思い浮かびますか？
- プログラミングスキル
- AIの知識
- クラウド技術に関する最新の情報
- 基本情報や応用情報などの資格
- etc…
エンジニアの勉強といえば、こういったIT技術に関する勉強が多いのではないでしょうか。
そうなんです。
エンジニアといえば、ITの勉強ばかりで、提案に必要な「ビジネスってどんな仕組み？」といった知識を持っている人はごく少数なんですよね。
システムはお客さんの業務を効率化するためのツールなのにも関わらず…
なので、業務フローの理解に必要なビジネスの基本的な構造を知り、基礎知識を入れて提案するだけで格段に差がでます。
エンジニアの中でほとんどの人がビジネスの構造に関する知識はないですからね^^;
プログラミングでもそうですが、知ってればできるけど、知らないとほとんどできないですよね。
変数の型の定義があって、
命令文があって条件分岐の文があって、
変数を設定して…
こういった基本的なパターンみたいなのがありますよね。
提案に必要なお客さんの業務フロー、つまりはビジネスの構造を分析するのもの同じです。
基礎的な知識を知っているのと知らないのではビジネス構造の分析に大きな差が出てしまうんですよ。
しかも、ビジネス構造の基礎的な知識なんて一般的なエンジニアのほとんどは知りません(苦笑)
なので、基礎知識、初級レベルの情報だけでも入れておくとかなりの差がでますよ^^
まとめ
この記事では次のようなことをお話しました。
- 凡人SEだったやまさんが活躍できたのは提案できるエンジニアになったから
- 現場で一番困るのはシステムの仕様がはっきりしないとき
- お客さん自身もどんな仕様にすべきか分かっていない
- あるべき仕様を提案して方向性を明示できるエンジニアは貴重
- システムはお客さんの業務の一部。ビジネスの基本的な構造を知って提案できるエンジニアは希少性が高い
いかがでしたでしょうか。
今回は凡人SEのやまさんが最高のボーナス評価を得て最短最速で昇格できたのかという点に触れてみました。
結論としては基本的なビジネス構造の知識を使ってお客さんの業務を把握し、システム仕様の提案を行えるからというものでした
この記事でいろいろ書きましたが、ボク自身「ビジネスの構造」なんて最初から知っていたわけではありません^^;
ぶっちゃけ、開発の現場ではもちろん、研修などでも、 「ビジネスの構造」 なんて教えてもらったことはないので普通は知らないと思います。
ビジネスの仕組みってどうなってるんだろうと、ボク自身でいろいろ調べて情報を集めました。
せっかくなので、情報を集める中で一番参考になった動画をここで紹介しておきますね。
こちらから期間限定で見れる動画になります。
もちろん動画は無料で見れますよ^^
ただ、動画の無料視聴は期間限定みたいなので、この記事を読んだ勢いで↓のリンク先をタップしてそのまま見ちゃうのがオススメです。
起業とかいろいろ出てきますが、一度、そのあたりを無視して見てみてください。
LINEかメールアドレスを登録をしたら動画のリンクが送られてくるのでそこから見る形式になってます。
起業したい人向けの動画だけあって、ビジネスの構造や業務フローはどうやって作られるのか解説されていますよ。
見る前と後ではかなり知識の差を感じられると思います^^
それでは！！
最後に（おまけ）
ボクは新人の頃、部署内でも有名なポンコツエンジニアでした^^;
プログラミングなど、ITに関するスキルが壊滅的だったのです。
ですが、今となっては社内で最短昇格を達成し、ボーナスも6回連続最高評価を達成しました。
こう言うと、なかなかの怪しさですよね（苦笑）
ということで、やまさんのエンジニア人生をプロフィールとしてまとめてみました。
ITスキル壊滅だったボクがどうやってエンジニアとしての活路を見つけたのか、気になる人は見てみてくださいね^^
プロフィールを読んでもらえれば察してもらえると思いますが、ボクはITスキル平凡な凡人SE。
めちゃくちゃプログラミングができるなど、特別なITスキルは持っていないです。
そのためか、昔は
- エンジニアになったはいいものの、IT技術に関して興味を持てない…
- 平凡なITスキルしかもってないのにエンジニアとしてやっていけるのだろうか…
- IT技術を身につけていくだけでエンジニアとして食べていけるのかな…
- 移り変わりの早いITの世界で永遠とIT技術の勉強を続けられる自信が…
このような悩みを抱えていました。
おかげさまで、プロフィールに書いたあるきっかけから↑のような悩みは解決してます。
ですが、実はバリバリのエンジニアの方でも「ITの勉強しない→エンジニア失格」という空気感にしんどさを感じてる人は多いみたいなんですよ…
というのも、「勉強しない→エンジニア失格」の空気感について、こちらの記事でまとめてみたところ、かなり人気なんですよね。
このブログの中でも人気の記事なので、気になった方は一度見てみてください^^
最後まで読んでいただきありがとうございました！！
