青空な日々

ITエンジニア関連で興味あることをアウトプットして共有したいブログ

Sierが悪なのではなく、あなたが悪だと感じたものが悪なのではないか?

はじめに

発端はこのツイート。

元のnoteはこちら。

note.com

このnoteの内容自体は非常に良く、SIerに詳しくない人にも分かりやすい内容でした。
ですが、以下の点が気になったのでこの記事を書きます。

  • Sierが悪なのか?という問いの答えが「つまみ食いをすることで悪になるのでは?」とのことだが、タイトルからするとミスリードだと思うのでもう少し補足したい
  • タイトルがSIerになっているが対象は「旧態依然の大手SIer」のみとのことなのでそこも補足したい

ちなみにこの気になった点については、記事を書いたご本人から直接回答を頂きました

目次

結論

タイトルにも書いたのですが、まず最初に結論を書いておきます。

Sierが悪なのか?

SIerが悪なのではありません。
(ある種あたりまえですが)あなたが悪だと感じたものが悪だと思います。

そしてそれは本当にSIerですか?

労働環境や商習慣、上司、開発手法、はたまた別のなにか、ではないでしょうか?

そういう意味で「つまみ食いをすることで悪になるのでは?」ということ自体は否定する気はありません。
それはその人がそう感じたことなので。

ですが、「Sierは悪なのか?」の問に対して「つまみ食いをすることで悪になるのでは?」という回答は誠実ではないでしょう。
Sierが悪であるかについては条件付きになっていて明確に答えていませんし、
条件付きなのであればSIerそのものではなくつまみ食いをすることの方が悪いのではないでしょうか。

例えば、するかどうかは別として、スタートアップ企業がつまみ食いしたら悪なのでしょうか?
悪なのであればSierは悪ではないですし、
逆に悪ではないのであればつまみ食い以外の要素で悪かそうでないかを判断していることになってしまいます。

よって、悪かどうかの判断とSIerは無関係だと言えるでしょう。

対象は旧態依然の大手SIer

元の記事ではタイトルがSIerとなっているため、Sier全体を指しているように見えますが、
実際にはその一部にしか言及していません。
記事を書かれた方も「今回のSIerの定義は旧態依然の大手SIer」が対象であると言っていますし、記事にも書いています。
(それが出てくるのが2/3ほど進んだ先に1行だけ出てくるだけですが・・・)

そして私も中小SIer出身なだけで、SIerと名のつく全てを回ってきたわけではありません。
なのでそういったバイアスがかかることを前提で表現すると以下の図のようになるでしょう。

f:id:fortegp05:20200729214810p:plain

今回はあくまで点線橙色の大手が対象であり、しかもその中の「旧態依然」とした会社のみです。
それがどれくらいあるのかは知りませんし、ここでは本質ではないので扱いませんが、
一言に「SIer」と言ったときの範囲に比べて「旧態依然の大手SIer」の範囲が狭すぎることがお分かりいただけると思います。

つまり元記事の結論が適用されるのはSIerのごく一部である、ということです。

悪であることについて

そもそも悪とはなんでしょうか?

悪(あく)とは - コトバンクを参照すると以下のように書かれています。

原義は人間にとって有害な諸事象,あるいはそれらの原因をいう。

とは言え原義であり人間にとってというのもあまりに広い概念です。
そのため同じページに以下のように書かれています。

便宜的に区分されるが,これらは視点の相違によるとも考えられる

よって、悪かどうかというのは視点の相違によって容易に変わります。
まずはこれを念頭に置いて考える必要があります。

再び「SIerは悪なのか?」について考える

あなたがSIerが悪だと思ったら、悪なのでしょう。
しかし私からみたら悪ではないということも同様に成り立ちます。

なぜならば視点の相違によって容易に変わるからです。

また元記事の方も「SIerか悪なのか?」という問いに「つまみ食いをすることで悪になるのでは?」と答えていますので、
SIerが主ではなくつまみ食いに主にした視点であると取れます。

つまり元記事で悪かどうかのやり玉に挙がっていたのはつまみ食いについてであり、
SIerはそれを元記事の方が経験した場所や環境でしかない、ということです。

交通事故にあったからと言って道路が悪になるか?

私にはそう言っているように聞こえてしまいます。

SIerが悪なのではない(悪だと感じる機会は多いかも…)

元記事については分かりやすい記事だなぁとは思いますが、
私の主観では少々主語が大きく、またバイアスがある記事でもあったと思います。

またSIerには労働環境やn次受けのような悪だと感じてしまうような出来事が多く、
それによりSIerをよく思っていない人が多いのは事実です。

ですが、だからといって十把一絡げにSIerを悪とは言えません。

私がいた中小SIerでやっていたこと

元記事は旧態依然の大手SIerのみが対象だったので、
私が新卒で入社した中小SIerでどんな業務をやっていたかを簡単に解説します。

ちなみにしがないラジオというPodcastでそのあたりを喋っているので、興味があればどうぞw


開発

元記事では大手SIerということで、SIerのITエンジニアがソースを書くということは殆どないと書かれていました。
しかし中小で元請け(顧客から直接仕事を受ける)だった私は、バリバリコードも書いていました。

プログラムの静的解析ツールの開発や業務用のWebシステム開発をしていたのですが、
プログラミング言語としてはJavaPerl、Tcl/Tk、BASIC、C/C++JavaScriptVBActionScriptを書いていました。
WebシステムなのでHTML、CSSSQLも書いてましたし、
バッチ処理としてシェルスクリプト、バッチも書いてました。

必要があればサーバーのキッティング、輸送手配、搬入、据え付け、障害テストもやりましたし、
データセンターに泊まり込んでのテスト、リリースの経験もあります。

他にもいろいろやりましたw

その他の業務

・営業に同行し、一緒に提案をする
・受注後のプロジェクトのPM
・外注先のマネジメント
・お客様からの問い合わせサポート

元記事にかかれていた上記のこともやっていました。
しかし、それは開発と並行しながら、です。

元請けのSIerでは案件がなければ成り立ちません。
そのため、割り当てられた予算を達成するために仕事を取ってきて、
それをなるべく安く仕上げて納品することで利益を出していきます。

この安く仕上げる部分の方法として元記事の大手SIerでは下請けに出す、という手法が使われていましたが、
中小のSIerではそんなことはできません。
そもそも下請けに出せるほどの規模でもないですし、
その契約やら準備やら、下請け先とやり取りしている暇があったら自分たち書いたほうが早いし安いからです。

もちろん1から10まで書くと他のことができないので、
仕様書と1から3くらいまでを自分で書いてあとは派遣のエンジニアに残りを依頼します。

ここで重要なのはSESではない、ということです。
派遣さんとして迎えるので指示命令系統は自分たちにありますし、
その管理責任も自分たちにあります。

そのためプロジェクトマネジメントスキルがないとすぐに炎上して大変なことになります。
というか、たくさんなりましたw

そんな感じだったので僕が居たSIerでは元記事とは違うということが分かると思います。
具体的にはn次受けの構造もないですし、
技術やスキルも広く深くたくさんのことを経験し学習できました。

これも結局は場所に依る、ということです。

余談

あまり元記事の主題とは関係ない重箱の隅をつついた話です。
読み飛ばし推奨w

一次請けと元請け

顧客から直接仕事を受ける企業(人)は元請け、
その元請けから仕事を受ける人は一次請けと言います。

その下からは二次、三次となっていきます。

私は元請けのSIerであり規模も小さかったのでSIer時代はあまりこの言い方を聞いていませんでした。
会社(企業グループ)の文化もあったのかもしれません。

元記事では顧客から直接仕事を受ける企業を一次請けとしていますが、
一般的にはその間に元請けが入ることが多いようです。

ウォーターフォールは問題?

元記事では日本特有のIT業界の構造と題した図の中にウォーターフォールが登場しています。
そしてそれが問題の一つだと書かれています。

ですが、問題の理由までは厳密に書かれていません。
図には50年前と書かれていたり、
そのあとに「新しい技術に対応するノウハウもリソースがほとんど無いと思っています」と書かれていたり、
対象が旧態依然とした大手SIerと仰っていたので、
「古いこと」が問題の理由であるように読み取れます。
(あくまで私の推測です)

なぜ古い(50年前の手法)と問題があるのでしょうか?

いま私がブログを書いているPCも、あなたがいまこのブログを見ている何かしらの端末も、
ノイマン型と呼ばれる約70年前のコンピュータアーキテクチャです。

ウォーターフォールより古いですが、なにか問題があるのでしょうか?

問題があるとしたら別にある

ウォーターフォールが古いから問題があるというよりは、
それを用いる我々人間だったり、
手段と目的のアンマッチだったり、
ウォーターフォールへの不理解などがありそうです。

具体的には間違ったウォーターフォールにしてしまうことで、
不確実な市場への対応力が低下したり、
不可能であるにも関わらずプロジェクト開始時点で全ての要求を集めようとしていたり、
不変にすべき要素である品質を犠牲にしたり、
明らかに継続できないのをわかっていて稼働時間を増やしたりしている、
そんなあたりが問題なのではないでしょうか?
(まだあるかもしれない)

ちなみにウォーターフォールの原典をみたことがありますか?

私はないです。
たぶん日本人で見たことがある人はほぼいないのではないでしょうか?

ちなみにそこには工程を戻しては駄目なんて書かれておらず、変化があれば対応すると書かれているそうです。

そもそも日本式のウォーターフォールと名のついた何かと、
厳密なウォーターフォールは分けて考えたほうが良いのかもしれませんね。

おわりに

同じSIer出身者として建設的に補足したい、ということでこの記事を書きました。
決して元記事の全てを否定するものではないですし、揚げ足を取りたいのでもありません。

あくまでSIerをなるべく正確に見てもらうための補足をしたかっただけです。

私が書いた内容も他の人からすればぜんぜん違うということがあるでしょう。
特に私は元請け出身なのでn次受けの悲哀などはよく分からない部分があります。

ですが私が居た元請けは大変だったので、元請けだから楽をしているとか、
Excelで管理ばかりしていてコードは書けないと一辺倒に思い込まない方が安全です。

SIer関係の記事、久しぶりに書いたなw