BizDeep

個人の見解です

【SIer先輩 v.s. プログラマー先輩】

大企業に潜む2パターンの「ソフトウェアエンジニア」

ぼくは割と大きめの会社でソフトウェアエンジニアをしています。働いて少し経つとソフトウェアエンジニアと名乗る人間には以下の2パターンあることが分かりました。ずばり

です。

同じ顧客から同じ要求が来た時、プログラマー先輩がアサインされると、彼は要求を聞くなり早々に関連論文を読み漁って最高の技術を選択し、実装にかかるスケジュールを算段し、それ通りにシステムを自分で作って提供します。
対して、SIer先輩がアサインされると、彼は顧客と何度も打ち合わせをして要求と価格を明確化し、ニーズと価格にマッチした人材を派遣として登用し、自分は管理者としてシステムを他人に作らせて提供します。

この2種類の人間達は同じ部署の中で敵対していて、片方と飲み会に行くと片方の悪口を一生しゃべっているような関係です。
僕が見る限り、どちらの言い分も正しくて、どちらが優れているとも劣っているともつけ難いような微妙な関係性を感じています。

ということで、今日は自分の今後のキャリアパスを考える意味も込めてこの両者の言い分と自分の考えをまとめたいと思います。 (ほとんどフィクションです!!!)

プログラマー先輩から見たSIer先輩へのディスり文句

中抜きしてるだけやん

あったまります。
受注して得たお金で人を安く雇って浮いたお金で飯食って美味いかアハーーン? ってことです。

SIer先輩からしたら、仕様設計をしてニーズを具体化してる所にお金が発生してるでしょ!と言いたいのでしょうが、プログラマー先輩は無形物に価値を見出し難い生き物なのでそんな会話は通じません。悲しい

人に作らせて楽しい?

これもあったまります。
結局実装を投げているので自分のスキル的な成長に繋がらなくて仕事してる意味なくねー? ってことです。

SIer先輩からしたら、人を動かしたり相手先と話をまとめることこそ一番楽しい部分でしょ!と言いたいのでしょうが、プログラマー先輩は基本機械以外と会話する事にストレスしか感じない生き物なのでそんな会話は通じません。悲しい

Qiitaを読まずに論文と仕様書を読め

ぐぬぬ、って感じ。
誰かが読みやすくまとめた資料をさらに斜め読みしただけで分かったつもりになって穴だらけの設計してんじゃねーよ! ってことです。

SIer先輩からしたら、読む時間が無いしそれよりお前はまずビジネス感を養うためにカーネギードラッガーを読め!と言いたいのでしょうが、プログラマー先輩は行き帰りの電車でニコニコしながら仕様書を読めるし最悪個人で起業してもなんとか生計を立てられるという謎の自信に溢れた人間なのでそんな会話は通じません。悲しい

SIer先輩からプログラマー先輩へのディスり文句

自分のキャリアを真面目に考えたら?

あったまります。
あなたはこれからも上がっていく年収に耐えられるだけの技術力を保証し続けられるのですか?無理なんだからマネジメントに回ったら?ってことです。

プログラマー先輩からしたら、それはそもそも日本のプログラマーの地位がおかしいし会社の人事を変えるべき!って言いたいのでしょうが、 SIer先輩は日々ビジネス書を読んでマネジメントの大切さを身に染みて理解しており日本が今後も変わらないことを確信しているのでそんな会話は通じません。悲しい

ビジネス感なさ過ぎヌルすぎ...

あったまります。
品質技術うんぬんよりニーズに合わせて柔軟に人をアサインしていち早く作らないと、顧客は待ってくれませんよ? ってことです。

プログラマー先輩からしたら、ちゃんと事前に技術的な検討をして要素技術の特定をしてスケジュールを練って確定させて進めれば成り立つ!って言いたいのでしょうが、SIer先輩は顧客が途中で手のひらを返してきたり新しい要望を出してきたりして仕様を大きく変更したりなどを何度も実際に経験しているのでそんな会話は通じません。悲しい

派遣の若い奴の方が仕事がデキるけど?

ぐぬぬ、ってなります。
あなたが作れば他人に出来ない技術を入れるか、さぞ品質が高いものを作れるだけの自信があるんですねすごいですねー?? ってことです。

プログラマー先輩からしたら、実際に俺の書いたコードと派遣が書いたコードを比較してみれば俺の方が発展性させやすくて綺麗じゃん!と言いたいのでしょうが、SIer先輩は基本動くものや定量的な指標以外に興味を持たない人間なのでそんな会話は通じません。悲しい


ぼくが思うこと

以上、だいぶ盛ってフィクションぽく書いてますが、実際に働いていて僕が体験したことです。
実際にこれ以外にもSIer v.s. プログラマーの議論は尽きないほどあると思いますが、僕が思うことは大きく以下2点にまとめられます。

以下に詳細をまとめています。

プログラマー先輩に教えられたこと

技術はなるべく1次ソースをしっかり読もう

Qiitaを含めプログラマの情報シェアがすっごい盛んで便利な時代で、論文や技術の名前で検索するとそれを解説してくれる人がいるのが当たり前の時代になっています。
でもやっぱりQiitaを読むだけでは分からないことや見落としていることが絶対にあります。

例えば、 Qiitaで論文のPreviousWorkやFutureWorkを取り上げてくれている人はほとんどいませんが、 実際技術を選択する上で大事なのは他に比べた優位性やその後の発展性 だったりします。

なのでたとえ自分はSIer先輩側に回ったとしても、少なくとも自分が担当する範囲では人がまとめた意見ではなくて自分が技術をしっかり理解して思ったことをベースに話を進めて行きたいと感じました。

目先の成果以外でもプロジェクトを評価できる人間になろう

コードを実際に書いていて思うのは洗練されたコードとただ動くだけのコードは東京大学と東京カスカビアン産業大学くらい違う!ってことです。

洗練されたコードは担当者が変わってもすんなり回りますし、新しい機能追加の要求が来ても既存のコードの抽象化の粒度を変えず美しく実装できます。
対してただ動くだけのコードは鉄の塊みたいな構成でREADMEとは呼べないRunbookが共有されているが、時間が立って依存パッケージがアップデートされて動かなくなると大規模なリファクタリングをしないともう誰も対応できない...みたいな状態になります。

ただ、単純に目先の成果ベースで評価だけしているとそこらへんの差異は見えないことが多いです。
特に派遣の人が書いたコードなどはプロジェクトが発展した時には自分はアサインされていないのでしーーらない!みたいな感じで書かれていることが多い印象です。

なので、 目先の成果とは別にしっかり定量的にプロジェクトの熟練度を評価する仕組みを自分の中で確立させておきたい と思っています。
例えばCMMIなどのフレームワークを使うのが良いと思います。

こちらについてはまた別の機会にじっくりまとめたいと思います。

SIer先輩に教えられたこと

技術者でもなるべく顧客と話そう

ぼくは実際に何度か機会をいただいて、技術者として顧客の人と直にお会いしてお話をした経験がありますが、一度話してみると本当に驚きます。

生粋のプログラマーの人だとイメージつきにくいかもしれないですけど、お客さんとビジネスの話をするのってめちゃくちゃ難しいです。
なんか 技術に関しては夢みたいなことを語って、それに見合ったお金は全然出してくれないけど、本人は技術のことは知らないから悪気は全然ない みたいな状態がほとんどでした。
これから実際にニーズを抽出して要件を定義してプロジェクトをまとめ上げるSIer先輩は本当に優秀だなと心から思いました。

なので、実際に顧客と話してくれる人が別にいたとしても、しっかり会議の議事録を読んだり相手側からのメールを転送してもらったり、マネジメントの人が説明に使ったパワポ資料をもらって顧客の意識を直で把握するのが技術者でも絶対必要だと思います。

お客さんの会社のビジョン・ミッションとか最近力入れてることとかをIR資料とかから探してくることもめちゃくちゃ重要だと思います。

これらは僕が今後どんな立ち位置になろうと絶対にマストな事項です。
僕が常日頃コード書きながら思っているのは、 プログラマーがコードを書いている時でも一番に考えるべきはお客さんへの思いやり であるということです。

プロジェクトで動いているお金を把握しよう

プログラマーの人、特に研究開発よりの人は自分が関わっているプロジェクトにどれくらいのお金が割り当てられているかとか考えたことある人少ないんじゃないかと思います。
マネジメントの人が立てたスケジュールやマイルストーンに合わせて開発をなんとかする、って感じのスタイルの人がほとんどじゃないでしょうか。

社内プロジェクトだと自分たちのチームの工数にかかってる費用((給料ではなく)、社内外から投資を受けている場合はその額を知っておくべきだと思います。
これも僕の持論ですけど、 仕事としてお金をもらっている以上、そのお金をくれた人に対してより多くの利益をもたらさすように動くべき と思ってます。

いっぱい給料もらったり投資してもらったらヤッター儲けたー!って思うのがプログラマーの人に多いような気がするので、僕は常に注意していたいと考えています。

最後に

本章は【SIer v.s. プログラマー】っていうお話でしたが、結局自分の結論は どっちもの悪いところを直して良いところをより伸ばした人材になれば良いじゃん ってことでした。おしまい