SIerはどこがヤバい?SIer現役がリストアップしてみた。

1週間ほど前に、完全SIer脱出マニュアルを読んでいた。
とりあえず1章を読み終わったので、自分の状況も含めてまとめていこうと思います。

こんな人には役に立つかも?

  • SIerで仕事をしている人で現状に不満がある人
  • 自分の仕事はSIerなのかわからない人

SIerの商法には難がある

普通の仕事は仕事の効率をあげて、生産性を上げるのは非常に良いことです。
そうすることで、残業を減らしたり、売上をあげられます。
プログラマーの場合だと、ソースコードを簡潔にして管理するソースコードを減らし、可読性も高めてメンテナンスコストを下げます。

しかし、SIerは仕事を受注する際、この内容でどれだけの作業時間が必要か?という見積を出します。
この工数に従って、必要な予算が上がっていきます。つまり、合意がとれたら完成後売上として計上されます。

つまり、この工数が下がっていけば下がるほど、売上は下がっていきます。
生産性を上げていくとなんと売り上げが減っていくのです…。

SIerの仕事の特徴

要件を満たすことが目的になりやすく、リスクを取って新しいものを導入する可能性が低い

会社や案件にもよりますが、その内容を満たす方法については問われないことが多いです。

自分たちの手元に来るときは方法が決められている状態のこともあります。

 

前者の場合、新しい方法を選ばないのはなぜか?というと、SIerは開発と共に保守も行うことが多いです。

保守をできるメンバーや技術の習得等考えると、優秀な人間を選出するか、学習する時間が必要です。

そのリスクを背負ってくれるユーザーはあまりいないと言わざるを得ません。

 

後者であれば考える余地がほぼありません。

その際にはスケジュールが決まっているパターンが多いので、その方法でやらざるを得ないからです。

開発に使用する技術や検証の工数を顧客と合意する必要がある。

基本的に、新しいものを取り入れるときはユーザーへの合意が必要になります。

何故合意が必要なのか?

受託開発の場合はユーザーから依頼されている仕事なので、ユーザーへの合意がとれなければ仕事は受けられないわけです。

利益にならないので、合意を取るために情報を用意しなければいけません。

問題はその時何を考えなければいけないのか?だと思いますが、ここがSIerには無理なポイントです。

  • 新技術・新しいものを取り入れることでのメリットを説明できる必要がある
  • 現在のシステム改修となると、システムに関しての知識が多く必要(新しいものを入れる際)

これをユーザーにしっかり説明して、合意がとれる人はほぼいないかと思います。

そのため、新しい技術ではなく今のレガシー(古い実績のある)な技術を使おうとなったりするわけです。

ソースコードの修正以外の作業時間の方が長い

これがいわゆる「なんちゃってプログラマー」と言われるSIerの習性です。

設計書をExcelで作ったり、ユーザーの説明にPowerPoint使ったり、WBSをExcelで作ったりなど。

正直プログラムを一度も触らずに仕事が終わる日もあります。

 

少なくともすべての時間をプログラムに割いている、割けるわけではありません。

従ってプログラマーより、プログラムにかけた時間は短く、知識や技術も劣ってしまいます。

プロジェクトごとに技術ノウハウはあるが、部門間で連携されにくい

大体SIerというのは依頼主の会社に常駐することが多いです。

そこは、ツールの制限があったり、自社のことをやるのは許されなかったりします。

 

常駐は部署内のプロジェクトにもよりますし、部署によっても異なります。

この状況で技術ノウハウなどの情報を連携することは、困難を極めます。

そもそも新技術をしらない。

SIer全体とは言い難いですが、新しい技術や手法等について無知なことが多いです。

確かに仕事上で新技術の話題になることは、ユーザーから話がない限りほぼあり得ないので、仕方がないのかもしれません。

 

また、仕事上で勉強会をすることがあっても、COBOLとか開発につかうことはなさそうなものを勉強することがあります。

独自技術を使っているところもある

歴史のある会社や案件に携わると、たまに聞いたことのない謎のフレームワークや技術があります。

それに携わったとして、身につくのは独自技術の知識のみであまり役に立ちません。

 

その中身や作り方が分かれば知識として十分活用できますが、ドキュメントがちゃんとしているところは少ないです。

酷いとドキュメントが存在しない・誰も知らないということもあります。

顧客に納品するシステムの要件・スケジュールが決まっていることが多い

これはSIerで下流で働く人に限った話です。

我々の手元に届くときには、システム要件・スケジュールが決まっています。

いくらその設計がクソでも、構造がクソでも、スケジュールが短くても、どうにもならないケースが多いです。

おかしいのではないか?と提案しても、大体は「今更のスケジュール変更は無理」と突っぱねられます。

 

その際下流の人たちは、血肉を流しながら仕事をして何とかします。

まぁ、新技術とか今の手法はどうなんだ?とか考える余裕もありません。仕事をこなすのだけで精一杯です。

もはや使う技術が古いレベルですらない

とにかく技術が古い。

ソース管理ツール VSS(VisualSourceSafe)
プログラム言語 Java6(現在の最新はJava12だよ)

また、技術もそうだが使っているその他ツールも古いことが多い。

今の時代に非同期通信ツールがメールのみだったり、タスク管理ツールすら使っていなかったり…など。

コードレビューが軽視されている

レビューというのはSIerで言えば、設計書レビュー、仕様レビュー、コードレビュー、テスト・試験レビューなどがあります。

しかし、現場によっては何のレビューもしないところもあります。

普通は多少レビューをしますが、せいぜい外部仕様のレビューだけだったり、設計書のレビューだけだったりします。

なぜコードレビューが軽視されるのか?

それは、「外部仕様さえ満たせばやり方の是非は問わない」ことが多いからです。

また、プログラムについてレビューできる人材が少ないというのも理由の1つです。

 

従って、SIerの作ったプログラムは、ソースコードがスパゲティコードになってたり、意味の分からないコードをしていることが多いのです。

昔あったウンコード・マニアとか本当にあった怖いプログラムで検索すると、おかしなコードがたくさん見受けられるはずです。

自動テストやらない

これは簡単な理由です。
一番は、自動テストを作る工数がないからだよサムソン君( ˘ω˘ )。

加えて、手動テストをユーザーが許容するか?という問題もあります。

全体的に「テスト」という項目をないがしろにしている風潮があります。

上司にツールを知らない人が多い

何故問題になるかというと、下流が知っていても導入される可能性が低いということです。

SlackやTrelloなど有名ツールを知らない人もいます。

 

また、前述したように効率的に動くのは、売上落とすことにもつながりますからね。

ここに関しては商法に問題があるかと思います。

このご時世でウォーターフォール開発

何故かSIerの人たちはウォーターフォールで作業を進める傾向があります。

確かに、その手法は仕事の範囲・進捗管理が把握しやすいです。

 

問題は、ウォーターフォールは確実性の高いものでなければ、あまり有用ではないことです。

そして、ユーザーの意向は変わりやすく、別の人がやった基本設計・詳細設計がおかしいなんてことも多々あります。

その際、後戻りして直すことは難しいです。ユーザーからしたらその分お金かかるってことですからね。

なんちゃってウォーターフォール型の存在

ウォーターフォールのように段階的な構造をしておきながら、成果物は特に管理しないところもある。

受入試験で、基本仕様・詳細設計仕様についての要望や、そもそもそんな仕様聞いてないということもある。

 

つまり、ウォーターフォールでもなく、アジャイルでもない適当な進め方が存在しているわけです。

そういう意味ではこのSIer業界は闇に染まっているかと思いますね。

SIerはなぜヤバイのか

エンジニアとして生産性を高くして、楽しく働きたいと考えると、SIerの開発現場は適した環境でないことが多いです。
これは個人のミスマッチだけでなく、SI業界全体の構造・商慣習によるものもあります。

それを考えて、3つだけ致命的な問題をあげます。

  1. 生産性を上げることが意味をなさない
  2. プログラムに集中できない環境である
  3. 無駄・最善でない仕事をすることに対して疲弊する

生産性を上げることが意味をなさない

これの問題点はたった1つ。

仕事の効率が上がる見込みがないという一点に尽きます。

このため、楽になることもありませんし、無駄な作業をすることにもなります。

 

正直楽になる見込みがないのがしんどいですね…。

プログラムに集中できない環境である

IT企業を志望した人は少なからず、プログラムを書きたい、書いてもいいと思った人だと思います。

しかし、SIerは人との交流や根回しなど、プログラム外のことの方を重要視します。

 

プログラミング能力自体はあまり重要ではありません。

だからこそ、「志望条件にプログラム経験を問わない」と書けるわけです。

 

プログラマーを目指して入った人にとっては、最高の地獄です。

無駄・最善でない仕事をすることに対して疲弊する

理想や間違いだとわかっていて仕事をするのは、思ったよりも精神疲労します。

このモヤモヤした感情を仕事でいつまでも引きずるのは、精神上よくないです。

どうすればいいのか?

まず、転職活動をしましょう。

今のご時世は、転職活動と言っても会社の面接を多く受けるとかそんなのではありません。

 

プログラミングの学習や、サービスを作ったりするのも立派な転職活動になります。

そんな時間ないですって人は?

まず時間を確保することに集中した方がいいです。

とにかく、何をするにあたっても時間が絶対に必要です。

 

これがないのであれば、まずは時間を確保する方向に進んだ方がいいです。

この記事のまとめ

まとめです。

SIerの商法には難があり、生産性を上げれば売り上げが下がってしまいます。

その影響でプログラマーとしての質や技術力を磨きにくいところが多いです。

結果として精神疲労をしたり、楽しく働けずに一日を終わることが沢山でてきます。

我々にできるのは、転職活動など自分を磨く活動をして、価値をあげることです。

おしまい。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です